expose PMBus device info from build-i2c codegen; set IS_PMBUS#2519
expose PMBus device info from build-i2c codegen; set IS_PMBUS#2519hawkw wants to merge 4 commits into
build-i2c codegen; set IS_PMBUS#2519Conversation
This commit updates our Git dep on the `management-gateway-service` repo to oxidecomputer/management-gateway-service@745a508. This is primarily in order to pick up oxidecomputer/management-gateway-service#488, which adds new `DeviceCapabilities` bits for PMBus devices and for devices which have VPD.
This commit adds a new `PmbusDeviceDescription` to the `build-i2c` crate. `I2cDeviceDescription` now includes an optional `PmbusDeviceDescription` field which is `Some` for PMBus devices. The presence of this field can be used to determine when a device is a PMBus device, such as when determining if the `IS_PMBUS` capability should be advertised. I did this by adding a whole new optional struct rather than just sticking an `is_pmbus` bool on `I2cDeviceDescription`, because I felt like future code, such as what @jamesmunns is working on for #2463, will almost certainly want a way to get a PMBus device's rail and phase names in codegen that lives outside of `build-i2c` (i.e. in `task-validate-api`'s build script). Currently, there isn't a nice way to get this stuff in codegen that lives outside of `build-i2c`, so this should help make that nicer.
Now that we have the appropriate information available at codegen-time to know if an I2C device is a PMbus device, we can actually set this flag. Yay! Now the control plane can know which devices are PMBus!
hawkw
force-pushed
the
eliza/hi-im-a-pmbus
branch
from
732ab05 to
9526186
Compare
hawkw
changed the title
build-i2c codegen; set IS_PMBUS
hawkw
added
service processor
| .flatten() | ||
| .enumerate() | ||
| .map(|(i, rail)| { | ||
| let phases = if let Some(ref phases_list) = power.phases |
There was a problem hiding this comment.
nit: Might be worth hoisting this up to the top level, and doing one arm for "has phases" and one for "doesn't have phases"? Then we could do a single assert for "lengths match", and then zip together rails and phases_list, instead of doing .get/indexing by i.
|
@hawkw This generally looks good; can you do a smoke test to make sure this didn't break |
|
what the heck happened here: https://github.com/oxidecomputer/hubris/actions/runs/26239754200/job/77222643916?pr=2519#step:4:288 |
I've been seeing these pretty often in other PRs. I'm not sure if it's some kind of cache failure, a build getting cancelled when it shouldn't, or just GitHub jank. It's starting to happen often enough to worry about imo. |
|
sigh... |
3 participants
This branch consists of three separate commits which build upon each other, and which I would like to rebase-merge as three separate commits to
master. Overall, the primary goal here is to start populating theIS_PMBUSbit in the control-plane-agent inventory'sDeviceCapabilities, which was added in oxidecomputer/management-gateway-service#488. In addition, I also tried to do some prep for future changes that want to generate more code for all PMBus devices, such as what @jamesmunns is working on in #2463.In particular, the three commits do the following:
Update the
management-gateway-servicedep to pick up the newDeviceCapabilitiesflagsAdd code in
build-i2c's public API that is exposed to other build scripts (thedevice_descriptions()API) to indicate which devices are PMBus devices. In particular,I2cDeviceDescriptionnow includes an optionalPmbusDeviceDescriptionfield, which isSomefor PMBus devices. The presence of this field can be used to determine when a device is a PMBus device, such as when determining if theIS_PMBUScapability should be advertised.I did this by adding a whole new optional struct rather than just sticking an
is_pmbusbool onI2cDeviceDescription, because I felt like future code, such as what @jamesmunns is working on for want to read PMBus status registers via MGS #2463, will almost certainly want a way to get a PMBus device's rail and phase names in codegen that lives outside ofbuild-i2c(i.e. intask-validate-api's build script). Currently, there isn't a nice wayto get this stuff in codegen that lives outside of
build-i2c, so thisshould help make that nicer.
Then, I've modified the codegen in
task-validate-api, which is whatcontrol-plane-agentultimately consumes for its codegen inventory devices, to include anis_pmbusfield so that we can use this to populate theDeviceCapabilitiesflag.Finally, actually set the flag in
control-plane-agent. :)