v0.2 merge into main#855
Draft
jerrysxie wants to merge 93 commits into
Draft
Conversation
…penDevicePartnership#595) (OpenDevicePartnership#630) Mergeback commit 7a7f754 from main into v0.2.0 Co-authored-by: zhuyi2024 <79184862@qq.com> Co-authored-by: zhuyi <zhuyi@microsoft.com>
v0.2.0 mergeback: 01-05-2026
…ship#672) Mergeback commit c7f8e86 from OpenDevicePartnership#669 into v0.2.0 , which is failing CI.
…rvice (OpenDevicePartnership#670) This change breaks requests and responses sent over the comms bus into distinct types for each kind of service that leverages the bus to communicate to the host rather than a single enum with all possible request and response types. Previously, these were all defined in the embedded-service crate, which meant that new services couldn't be implemented without forking this repo and extending that enum. With this change, each service has an associated 'messages' crate that defines the types of requests and responses associated with that service and how to serialize/deserialize them. This incidentally removes a lot of boilerplate across all services associated with handling message types that are not intended for the service that receives them, since services no longer need to reason about other services' message types. In the course of this work, a few bugs in message serialization were found and fixed (out of order fields and the like).
…re (OpenDevicePartnership#673) This change factors out the boilerplate associated with generating relay types from the information about the set of types that are to be relayed. This should enable easier bringup of additional message relay services (e.g. UART). In the course of this work, I noticed that some of the nomenclature around results vs responses was a bit conflicting in the relay code, so also standardized that on Result meaning 'a specific generic type of the Result enum' and Response meaning 'the success case of a Result'. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Adds a basic uart service which can act a host service when eSPI is not available. Still uses the `SmbusEspiMedium` even though the SMBUS header isn't necessary just to keep code changes on the host side minimal when switching between UART/ESPI. Did some testing on the IMXRT board and can send/receive MCTP packets from host over a COM port successfully. Might catch additional bugs as I work on getting the ratatui app working over UART and will fix them as they come. Resolves OpenDevicePartnership#605
…nDevicePartnership#679) Some serialization/deserialization was omitted because it wouldn't be used by the EC, however the service-message crates can be used outside the EC, so add them in. I experimented with zerocopy for this in OpenDevicePartnership#678 but it's a bit clunky and getting it to work for Battery messages will be challenging, so just rolled it by hand for now since that's what we are already doing. Can revisit later once we've decided on a serialization strategy. Tested these by using the service message crates to serialize/deserialize messages over UART in the ratatui and works fine for the ones I could test (though many of the battery commands are not yet supported by the ratatui app). Was going to wait until OpenDevicePartnership/embedded-batteries#39 is merged, but it seems relying on an updated `embedded-batteries` causes a ton of breakage and headache, so just have functions for converting in here and can update a later time.
…context handling (OpenDevicePartnership#668) - Removed `static_cell` dependency from Cargo.lock and Cargo.toml in examples and type-c-service. - Updated Type-C service methods to accept a reference to `intrusive_list::IntrusiveList` for better context management. - Modified various service methods to pass the controllers list where necessary, ensuring proper context usage. - Commented out unused code related to power policy channels and service initialization. - Adjusted the task closure to work with the updated service structure. - Enhanced error handling and logging throughout the service methods.
…#681) The cargo-vet CI job is currently failing with 36 unvetted dependencies with a note `These audits may have been made with a more recent version of cargo-vet`. Updating to the latest version of cargo-vet gets rid of these unvetted dependencies as it seems the vetting was done with cargo-vet@0.10.2. Why this is not a breaking minor change is beyond me. ``` Vetting Failed! 42 unvetted dependencies: aho-corasick:1.1.3 missing ["safe-to-deploy"] anyhow:1.0.99 missing ["safe-to-deploy"] cc:1.2.33 missing ["safe-to-deploy"] encoding_rs:0.8.35 missing ["safe-to-deploy"] libc:0.2.175 missing ["safe-to-deploy"] loom:0.7.2 missing ["safe-to-deploy"] memchr:2.7.5 missing ["safe-to-deploy"] paste:1.0.15 missing ["safe-to-deploy"] proc-macro2:1.0.101 missing ["safe-to-deploy"] regex-automata:0.4.13 missing ["safe-to-deploy"] ryu:1.0.20 missing ["safe-to-deploy"] scoped-tls:1.0.1 missing ["safe-to-deploy"] serde_json:1.0.143 missing ["safe-to-deploy"] syn:1.0.109 missing ["safe-to-deploy"] syn:2.0.106 missing ["safe-to-deploy"] thiserror:1.0.69 missing ["safe-to-deploy"] thiserror:2.0.16 missing ["safe-to-deploy"] thiserror-impl:1.0.69 missing ["safe-to-deploy"] thiserror-impl:2.0.16 missing ["safe-to-deploy"] unicode-segmentation:1.12.0 missing ["safe-to-deploy"] unicode-width:0.1.14 missing ["safe-to-deploy"] windows:0.61.3 missing ["safe-to-deploy"] windows-collections:0.2.0 missing ["safe-to-deploy"] windows-core:0.61.2 missing ["safe-to-deploy"] windows-future:0.2.1 missing ["safe-to-deploy"] windows-implement:0.60.0 missing ["safe-to-deploy"] windows-interface:0.59.1 missing ["safe-to-deploy"] windows-numerics:0.2.0 missing ["safe-to-deploy"] windows-result:0.3.4 missing ["safe-to-deploy"] windows-strings:0.4.2 missing ["safe-to-deploy"] windows-sys:0.52.0 missing ["safe-to-deploy"] windows-sys:0.59.0 missing ["safe-to-run"] windows-targets:0.52.6 missing ["safe-to-deploy"] windows-threading:0.1.0 missing ["safe-to-deploy"] windows_aarch64_gnullvm:0.52.6 missing ["safe-to-deploy"] windows_aarch64_msvc:0.52.6 missing ["safe-to-deploy"] windows_i686_gnu:0.52.6 missing ["safe-to-deploy"] windows_i686_gnullvm:0.52.6 missing ["safe-to-deploy"] windows_i686_msvc:0.52.6 missing ["safe-to-deploy"] windows_x86_64_gnu:0.52.6 missing ["safe-to-deploy"] windows_x86_64_gnullvm:0.52.6 missing ["safe-to-deploy"] windows_x86_64_msvc:0.52.6 missing ["safe-to-deploy"] ```
Part of the larger embedded-services refactor work. Power policy v0.2.0 refactor - Make power policy context explicit, generic, and injectable - Remove all global/singleton usage, making the context generic over channel size and requiring explicit passing of context references - Updates all examples and Type-C service code to use explicit, generic policy context parameters
`cargo test` currently doesn't compile on Windows. It looks like this is because a couple crates have hard dependencies on libraries that don't work on desktop - in particular: - debug-service depends on defmt - espi-service depends on embassy-imxrt - partition-manager has an enabled-by-default dependency on defmt These don't build on desktop, so when you try to run `cargo test` against mocks, the build fails. We get away with it on Linux because it looks like the linker over there is more aggressive at pruning unused symbols than the MSVC linker, but the MSVC linker errors immediately when it can't find a referenced symbol, even if that symbol is not reachable from any entry points. This change mitigates this problem by making partition-manager not default-depend on defmt and disabling build of debug-service and espi-service in test contexts. This does unfortunately mean that we can't write tests in those modules, but those modules already didn't have tests, so we're not conceding any existing test collateral by doing this. In future, we can look into breaking the dependency espi-service has on embassy-imxrt by introducing traits. It's less clear to me how we would do this with the debug-service - perhaps a stub implementation of some of the defmt macros. Fixes OpenDevicePartnership#691
This change implements an ACPI time-and-alarm device as defined in section 9.18 of the ACPI 6.4 spec. Such a device needs to interface with the not-yet-existent power service to trigger wakes and subscribe to power source notifications, so those interface points are stubbed out for now. Resolves OpenDevicePartnership#138, OpenDevicePartnership#139, OpenDevicePartnership#140, OpenDevicePartnership#141, OpenDevicePartnership#142, OpenDevicePartnership#143, OpenDevicePartnership#144
Add support for examples with the [pico-de-gallo](https://github.com/OpenDevicePartnership/pico-de-gallo) development board. This PR sets up a new workspace for pico-de-gallo examples and adds an example that runs the battery service with the [bq40z50-r5](https://github.com/OpenDevicePartnership/bq40z50/) fuel gauge connected to the pico-de-gallo's I2C bus.
V0.2.0 mergeback: 02-02-2026
- Remove static `SERVICE` in battery service - Replace battery service free functions with methods on `Service` - Add battery `Device` as an argument to `battery_service::task()` to ensure all devices are registered before the state machine starts - Update examples
Depends on OpenDevicePartnership#700 Thermal service refactor - Enforce initialization order by forcing registration of all objects before a Service instance can be constructed - Replace free functions with methods on the Service - All tasks need an instance of Service to be initialized before any message passing logic starts - Updated std example
The eSPI memory map is no longer in use, so this change removes it to simplify. As part of this, also remove examples that were intended to exercise the now-removed functionality. Resolves OpenDevicePartnership#692
A few methods were mistakenly made `pub(crate)` during refactor that I didn't catch. This PR reverts them back to `pub`.
Refactor CFU service and move embedded_services::cfu module to cfu_service - Updated task function in cfu-service to accept a CfuClient reference directly. - Adjusted buffer and splitter tasks to utilize the new CfuClient for device registration and request handling. - Refactored examples As a consequence of moving CFU data structures out of embedded-service, type-c service needs to take a dependency on cfu-service. Chatted with @RobertZ2011 offline and verified that the eventual goal is to move CFU out of type-c service by abstracting out a firmware update trait that the type-c service will use and the CFU service will impl.
…cePartnership#709) - Mock battery is feature gated
Adds mock sensor and fan to thermal service and updates the thermal `std` example to make use of them (which simplifies the example quite a lot). Example can be tested with `cargo run --release --bin thermal`. Resolves OpenDevicePartnership#619.
During refactor, the battery-service was changed to only respond with a `AcpiBatteryResponse`. However, the comms service expects a `Result<AcpiBatteryResponse, Error>` so this PR just makes that fix.
…penDevicePartnership#553) * Instead of IPC between the power policy task and power devices, direct async function calls are used through the new `DeviceTrait` trait. * Power policy now holds references to types that `impl DeviceTrait` instead of using channels * There's now a per-device channel for sending events to the power policy instead of a single shared channel * Remove type-stated state machines, these just ended up in a shared enum so there wasn't much benefit while resulting in duplication of common logic. * Introduce first power policy integration test for default consumer switching logic * Update examples * Introduce temporary bridge code until type-C code is similarly refactored (types in `type_c_service::wrapper::proxy`).
…penDevicePartnership#716) This change adds a facility to allow relay services to be user-extensible by hoisting the knowledge of which types are relayable out of the relay service (e.g. eSPI service) into the application layer. The application layer can pass in a list of (name, address, relay-handler) tuples and use those to instantiate a relay service. This enables OEMs to add their own services and messages that can share the same message bus. This requires a few things: - Eliminating all static state from within the eSPI service (since type sizes are no longer known by the eSPI service) - Implementing a trait for each relayable service to do conversion between wire formats and function calls The time-alarm service has been ported to leverage this new facility as an example; the other relayable services (battery, debug, thermal) will be migrated in a future change. Because we're moving from the comms system to direct async calls, we incidentally also get rid of the requirement imposed by the comms system that services have lifetime 'static. This incidentally also allows making services that leverage this new facility generic over the lifetime of the hardware that they manage, which enables some integration testing scenarios. To demonstrate this capability, a couple simple tests were added to the time-alarm service.
…cePartnership#732) Refactors thermal, battery, and uart services to make use of the latest Relay trait for direct async calls so we don't need to go through comms service to interact with host/relay services. ## Thermal - Removes all statics - Removes all uses of intrusive list and instead just uses slices for maintaining lists of sensors and fans - Removes comms dependency entirely and only implements Relay trait ## Battery - Replaces communications with host from comms to Relay trait. But I've kept the comms system in place since the battery service seems to talk to other power services and I didn't want to try and change that in this PR. Likewise some uses of statics and intrusive lists still exist in battery since I'm not 100% sure yet on if changing any of that will break things so can be addressed in a future PR - The changes I did make allowed for some code reduction since we no longer have to differentiate between ACPI events and battery state machine events so could do a little refactoring there ## Uart - Completely removes legacy comms system and MCTP macro. Only relies now on updated Relay traits. ## Espi - Removed thermal and battery from the legacy handler. In a followup PR, I will update Debug service and then can compeltely remove all legacy code from the espi service, completing the transition. These changes were all tested on several dev platforms that can make use of the uart-service. Tested changes on an espi platform and things were mostly correct, but it appears there is a bug that existed even before these changes were made which we are investigating now. Resolves OpenDevicePartnership#721 OpenDevicePartnership#723 OpenDevicePartnership#725
Removes all legacy comms paths from the eSPI service and removes the `'static` lifetime (instead preferring a generic `'hw` lifetime). Also removes the legacy comms path from the debug service. However, the effort here was minimal. The debug service is due for a major overhaul in the near future so more effort will be made getting debug up to parity with the other services in a future PR. Resolves OpenDevicePartnership#703 Resolves OpenDevicePartnership#722
…icePartnership#711) Refactor the power policy service to achieve the following: * Move power policy and type-C code out of `embedded-service` and into their respective service implementations * Introduce `Psu` name instead of `Device`.
* Move PSU code away from `intrusive_list`. * Remove numeric PSU ids. * Remove `'static` lifetime constraints in service code and update integration tests accordingly. * Remove interior mutability from service.
…ecuting Hard Reset (OpenDevicePartnership#850) Mirrors PR OpenDevicePartnership#820 for v0.2.0 Resolves OpenDevicePartnership#849
V0.2.0 mergeback: 05-19-2026
jerrysxie
requested review from
RobertZ2011,
asasine,
chchongmsft,
Copilot,
felipebalbi,
madeleyneVaca,
makubacki,
philgweber,
seanbrns,
thdesil,
tullom and
williampMSFT
tullom
approved these changes
May 19, 2026
williampMSFT
approved these changes
May 19, 2026
RobertZ2011
approved these changes
May 19, 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.
Merge v0.2.0 into main, v0.2.0 will be deleted after merge.