uart-service: add default_mctp_serial constructor

[dymk]

Adds MctpSerialService<R> and default_mctp_serial() to uart-service — the MctpSerialMedium twin of the existing DefaultService / default_smbusespi pair.

The constructor hardcodes the canonical EC↔SP serial reply context (source = EC_EID, destination = SP_EID, message_tag = 0, medium_context = ()), mirroring default_smbusespi field-for-field. Serial consumers (the QEMU EC↔SP relay path) can then call one constructor instead of hand-assembling an MctpReplyContext. Enables mctp-rs/serial so the MctpSerialMedium type is available.

No behaviour change to existing callers — purely additive (a new type alias + constructor, plus turning on the serial feature of the mctp-rs dependency).

Unblocks the EC dev-qemu MCTP-over-serial work in odp-embedded-controller, which will call this constructor to speak the SP's DSP0253 framing over the two-QEMU serial link.

Assisted-by: GitHub Copilot:claude-opus-4.8

[Copilot]

Pull request overview

This PR extends uart-service with a convenience type alias and constructor for running the relay over DSP0253-framed MCTP-over-serial, mirroring the existing DefaultService / default_smbusespi pattern. It introduces MctpSerialService<R> (a Service<R, MctpSerialMedium> specialization) plus default_mctp_serial() that preconfigures the canonical EC<->SP reply context defaults. To make the medium type available, it also enables the serial feature on the workspace mctp-rs dependency for this crate. The change is additive and should not alter behavior for existing SmbusEspi users.

Changes:

• Add MctpSerialService<R> type alias to specialize Service for mctp_rs::MctpSerialMedium.
• Add MctpSerialService::default_mctp_serial() constructor that builds a Service with the canonical reply-context defaults used by the QEMU EC<->SP serial relay path.
• Enable mctp-rs’s serial feature (pulling in the serial medium implementation and its CRC support).

Step-by-step review guide

1. New serial-medium specialization

   • pub type MctpSerialService<R> = Service<R, mctp_rs::MctpSerialMedium>;
   • This matches the existing DefaultService<R> = Service<R, SmbusEspiMedium> pattern and gives callers a stable, intention-revealing name for the serial configuration.

2. Default constructor semantics

   • default_mctp_serial() calls Service::new(...) with MctpSerialMedium and a pre-filled MctpReplyContext using EC_EID, SP_EID, message_tag = 0, packet_sequence_number = 0, and medium_context = ().
   • Non-obvious detail to confirm: process_response() overrides destination_endpoint_id per response using handler_service_id, so the constructor’s destination_endpoint_id is effectively an initialization value (even if it matches the common case).

3. Dependency feature enabling

   • uart-service now depends on mctp-rs with features = ["serial"], ensuring MctpSerialMedium and the EC/SP EID constants are available.
   • This is a build-time surface-area change (more code gets compiled into mctp-rs for this crate), but it is consistent with other crates in this repo enabling the mctp-rs features they require.

Potential issues

#	Severity	File	Description	Code
1	Low	uart-service/src/lib.rs:198-202	The doc comment says destination = SP_EID is hardcoded, but process_response overrides destination_endpoint_id per response; the comment is a bit contradictory and could be clarified.	/// EC ↔ SP reply context (... destination = SP_EID ...) ... overridden per-response

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
uart-service/src/lib.rs	Adds a serial-medium service alias and default_mctp_serial() constructor with preconfigured reply context.
uart-service/Cargo.toml	Enables mctp-rs’s serial feature so the serial medium type and constants are available.

[kurtjd]

Is the plan to follow this up with a PR in odp-embedded-controller changing the constructor used (on all platforms, not just dev-qemu) then a co-PR in odp-platform-common updating the serial backend of the TUI to use this new framing?

[dymk]

@kurtjd Correct, that's basically the plan.