Attention is currently required from: Arthur Heymans, Christian Walter, Cliff Huang, Felix Held, Johnny Lin, Jonathan Zhang, Lance Zhao, Lean Sheng Tan, Nico Huber, Patrick Rudolph, Tim Chu, Tim Wawrzynczak.
Shuo Liu has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81652?usp=email )
Change subject: acpi: Move acpigen_write_OSC_pci_domain to Xeon-SP ......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
This patch makes changes in 2 aspects, […]
Revisited the comments from Nico and Felix, and checking through Linux kernel 5.19.rc8 and CXL spec rev 3.1 - 9.18.2.1.4,
1. For CXL root with CXL UUID call, the _OSC should cover PCI bits and CXL bit both, instead of expecting OS to call PCI setting under another PCI UUID call. This seems not so clear however is the way how Linux implements, and not conflict with example provided in CXL spec rev 3.1 as well.
2. About query and non-query setting. This call doesn't support non-query setting, where the firmware changes its settings in runtime to fit OS calls. The non-query setting is rather trivial and is related to many register settings, which is not suitable for dynamic generated _OSC in this case. However in server Linux, only the query setting is used, hence this implementation is adequate to the server case.
3. About the sanity checks on the returned control bits in query setting, where specific control bits should be further unset according to OS's support flag (imagine a case where the OS has quite limited support capabilities which cannot fully manage the firmware granted feature list, the firmware needs to take back the unsupported ones), this call doesn't support yet. However, in server Linux, the OS will calculate the control quest based on its support capability, a.k.e. to generate reasonable inputs so that _OSC sanity check is not a must.
Due to this reason, we have to admit that, this version, though validated on server Linux, is not 100% compatible to a full spec point of view. If we take the criteria that acpigen codes should be fully conformed to specs (all aspects), we should put it to Xeon-SP as of now.
However, improvements could be made in this codes to increase its compatibility.
Point 1 - Could be fixed soon. Point 2 - Cannot be supported by design, we could clarify this by rename the call, e.g. acpigen_write_OSC_pci_domain -> acpigen_write_OSC_pci_domain_fixed_caps Point 3 - Could be added later on demand, e.g. add a sanity check subroutine to check the support flags and to suppress certain control flags, which is quite feature specific. Or we can leave a empty call placeholder for this as of now.