expose PMBus device info from build-i2c codegen; set IS_PMBUS#2519
Open
hawkw wants to merge 3 commits into
Open
expose PMBus device info from build-i2c codegen; set IS_PMBUS#2519hawkw wants to merge 3 commits into
build-i2c codegen; set IS_PMBUS#2519hawkw wants to merge 3 commits into
Conversation
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
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
1 participant
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.
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. :)