Wire accepted RequestUpdate to the orchestrator's UpdateRequest event - #442
Open
chrysh wants to merge 4 commits into
Open
Wire accepted RequestUpdate to the orchestrator's UpdateRequest event#442chrysh wants to merge 4 commits into
chrysh wants to merge 4 commits into
Conversation
The PLDM firmware-device loop now notifies an UpdateEventSink once per accepted RequestUpdate, detected as the FD's only Idle -> non-Idle transition, after the success response is sent. Rejected requests (already in update mode, bad transfer size) leave the state unchanged and never notify. The sink trait stays PLDM-flavored so this crate never depends on the orchestrator stack. The mapping to Event::UpdateRequest lives in the new orchestrator-pldm-adapter crate as UpdateRequestLatch, following the same rule that keeps HAL adapters out of orchestrator-capabilities. The latch is a bool, not a counter: the FD rejects a second RequestUpdate while one is in progress, and an undrained latch across update cycles coalesces into the single UpdateRequest the state machine would act on anyway. The firmware-update host test drives the latch end to end: the accepted RequestUpdate latches exactly one Event::UpdateRequest, the duplicate is rejected with AlreadyInUpdateMode and latches nothing, and no later command in the flow latches anything. Signed-off-by: Christina Quast <christina.quast@9elements.com>
chrysh
requested review from
FerralCoder,
leongross and
rusty1968
and removed request for
FerralCoder,
leongross and
rusty1968
August 25, 2026 19:07
hal-adapters moves to adapters/hal and the new PLDM adapter to adapters/pldm, so the growing family of producer-to-orchestrator adapter crates (HAL, PLDM, later SPDM) sits under one directory. Crate and target names are unchanged; each adapter keeps its own crate so composing one stack never pulls in another. Signed-off-by: Christina Quast <christina.quast@9elements.com>
More PLDM lifecycle events are coming (cancel, transfer/verify/apply complete, activate). Replace UpdateEventSink's per-event method with a non_exhaustive FdEvent enum and a single FdEventSink::notify, so new events are one variant instead of a trait break. Every variant payload stays Copy and lifetime-free: across the DSP0267 FD surface the orchestrator-relevant edges carry only small integers; buffer-shaped data (image chunks, package data, version strings) lands behind FdOps and events name it instead of carrying it. UpdateRequested is the only variant for now. The adapter latch keeps its semantics and drops unmapped events. Signed-off-by: Christina Quast <christina.quast@9elements.com>
chrysh
marked this pull request as ready for review
August 26, 2026 20:07
Clippy's single_match lint (denied under -D warnings in presubmit) rejects a one-arm match with a wildcard. FdEvent derives no PartialEq, so use matches! rather than an equality check. Signed-off-by: Christina Quast <christina.quast@9elements.com>
This was
linked to
issues
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The PLDM firmware-device loop (
run_terminus) now notifies anFdEventSinkwithFdEvent::UpdateRequestedonce per acceptedRequestUpdate, and a neworchestrator-pldm-adaptercrate maps that notification toEvent::UpdateRequestfor the orchestrator. OnlyRequestUpdateis wired; cancel/completion edges and the run-loop composition are untouched seams.How
#[non_exhaustive]FdEventenum plus a singleFdEventSink::notifymethod, so the coming FD lifecycle events (cancel, transfer/verify/apply complete, activate) are one new variant each instead of a trait break for every implementor.FdEventpayload isCopyand lifetime-free by design. Across the DSP0267 FD surface the orchestrator-relevant edges carry only small integers (result codes, component ids, bitmaps); buffer-shaped data (image chunks, package data, version strings) lands behindFdOpsand events name it instead of carrying it.RequestUpdateis detected as the FD's onlyIdle→ non-Idletransition, sampled around the responder poll, after the success response is sent. Rejected requests (ALREADY_IN_UPDATE_MODE, bad transfer size) leave the state unchanged and never notify.services/orchestrator/adapters/pldmasUpdateRequestLatch, following the same rule that keeps HAL adapters out oforchestrator-capabilities. The latch matchesUpdateRequestedand drops unmapped variants.RequestUpdatewhile one is in progress, and an undrained latch across update cycles coalesces into the singleUpdateRequestthe state machine would act on anyway.Tests
firmware_update_hostdrives the latch end to end: the acceptedRequestUpdatelatches exactly oneEvent::UpdateRequest, a duplicate is rejected withAlreadyInUpdateModeand latches nothing, and no later command in the flow latches anything.