Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34285 )
Change subject: soc/intel: Fix regression with hidden PCI devices ......................................................................
Patch Set 4:
The device responds back with all 1s. Basically, the EDS says that when the hide bit gets set, this device will read 1s for any PCI config read. All other transactions are unaffected. I am not sure if it is a violation of spec to return back all 1s. That is a special value which basically indicates no device. But, I am not a PCI spec expert.
Huh.. so you can write but cannot read? Or did you mean "unaffected -> not decoded" ?
Old PCI 2.3 had this phrase: 6.1. Configuration Space Organization "A device's Configuration Space must be accessible at all times, not just during system boot."
Could not find exact same in PCIe 3.0. So let's call it borderline compliant.
IIRC, Linux kernel follows a similar way of doing this i.e. accessing P2SB device.
You mean kernel also does this unhide/hide thingy? Would that not imply that hiding devices in the first place was a quirk for firmware that was not able to allocate fixed addresses for critical BARs like ACPI / PM ?
I would rather make that one an explicit quirk, complain in the logs (maybe BIOS_DEBUG, not BIOS_ERR) of having to do so, and maybe even make it require a "select PCI_QUIRK_SPECS_VIOLATION" in the platform configs. I did not check PCI space of that device, I bet there would be bunch of interesting bits for firmware, maybe even OS. Like SERR/PERR perhaps.
What purpose would this "PCI_QUIRK_SPECS_VIOLATION" be used for?
I would guard pcidev_path_on_root_debug() and/or dev_find_slot() behind this. So seeing that in the platform Kconfig would serve as a reminder that some ugly hack is in place and needs attention. We can call it DEBUG_PCI_TREE but I would like to select it for affected soc/intel.