acpi_tables: Update to latest RQSC specs #36
Conversation
lucido-simon
requested review from
jiangliu,
liuw,
rbradford and
sboeuf
as code owners
src/rqsc.rs
Outdated
| /// - 0: Cache | ||
| /// - 1: Memory | ||
| /// - 2-0x7F: Reserved | ||
| /// - 0x80-0xFF: Vendor Specific | ||
| resource_type: u8, |
There was a problem hiding this comment.
How about adding a ResourceType enum (that is #[repr(u8)]) with these values?
There was a problem hiding this comment.
Reserved and vendor specific can take a range of value. I'm not sure how to code this range in an #[repr(u8)] enum
There was a problem hiding this comment.
For now all we probably care about is Cache and Memory. If others have later use cases, they can add more values to the enum.
There was a problem hiding this comment.
Makes sense. I've put back the ResourceType enum
src/rqsc.rs
Outdated
| /// The byte must be the Resource ID Type. | ||
| /// The Vec must be Resource ID 1, Resource ID 2 and Resource Specific Data | ||
| /// serialized as aml_bytes. | ||
| VendorSpecific((u8, Vec<u8>)), |
There was a problem hiding this comment.
nit: this does not have to be a tuple, you can just use VendorSpecific(u8, Vec<u8>)
There was a problem hiding this comment.
Didn't know that, thanks!
src/rqsc.rs
Outdated
| ResourceID::Cache(_) => core::mem::size_of::<CacheResource>(), | ||
| ResourceID::MemoryAffinityStructure(_) => { | ||
| core::mem::size_of::<MemoryAffinityStructureResource>() | ||
| } | ||
| ResourceID::ACPIDevice(_) => core::mem::size_of::<ACPIDeviceResource>(), | ||
| ResourceID::PCIDevice(_) => core::mem::size_of::<PCIDeviceResource>(), |
There was a problem hiding this comment.
nit: I see lots of core::mem::size_of, might be worthwhile to import that and just call size_of everywhere
| assert_eq!( | ||
| bytes.len(), | ||
| TableHeader::len() + 4 + core::mem::size_of::<QoSController>() | ||
| assert_eq!(bytes.len(), TableHeader::len() + 4 + 28); |
There was a problem hiding this comment.
28 is the expected size of the QoSController record?
There was a problem hiding this comment.
If there are no resource structure associated, yes
lucido-simon
force-pushed
the
main
branch
2 times, most recently
from
3a4703d
to
dec7c59
Compare
|
LGTM |
The table definition for RQSC tables changed[0]. This commits updates the RQSC implementation to match the new specs. The new specs can be confusing to use, since some fields depends on others. Sometime they should be set, sometimes not. To prevent mishaps, enums are used to force the developer to be coherent in what he defines. [0] https://github.com/riscv-non-isa/riscv-rqsc Signed-off-by: Simon Lucido <simonl@rivosinc.com>
|
@lucido-simon you've introduced a merge commit. Please use |
Nevermind, you've already fixed it :) |
The table definition for RQSC tables changed. This commits updates the RQSC implementation to match the new specs.
The new specs can be confusing to use, since some fields depends on others. Sometimes they should be set, sometimes not. To prevent mishaps, enums are used to force the developer to be coherent in what he defines.
Also, I'm not sure about how to do vendor specific resource, I think it could be improved. If you have better idea, lmk.