I read the kernel sources before writing about the PCI quirks. From what I can see, quirks are enabled based on PCI VID/DID detected and are only disabled by compiling the entire thing out of the kernel aka PCI_QUIRKS=n. I haven't checked how the kernel would react if I do the latter and boot it with vendor firmware.
Now I know the warning message pops up on dmesg as the module i2c-piix4 is loaded.
The next message alludes to an ACPI driver. There is none, and I don't know how practical it is to write one. Or do the opposite and implement ATK0110 support into p3b-f (this is Asus' hardware monitoring interface over ACPI, replacing the native hwmon driver).
Thanks Keith
On Tue, May 19, 2020 at 1:53 PM Angel Pons th3fanbus@gmail.com wrote:
Hi all,
On Sat, May 16, 2020 at 2:23 AM Keith Hui buurin@gmail.com wrote:
Hi Nico,
I tried a few things. Looks like Linux kernel activated a couple PCI quirks and claimed the ACPI and SMBus port ranges on top of what we already reported. Seems to be the source of the conflict. I have to omit the SMBus port range in pwrmgt_read_resources() in southbridge/intel/i82371eb/smbus.c to make the conflict go away, but that is not exactly correct.
It is either this hack (which doesn't always work anyway), or rip the SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need, or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS off kills that workaround as well.
What is my proper next step?
I would say: check why the quirk is getting enabled, and try to make it not enable for coreboot. Otherwise, we have to make coreboot be wrong just to make the kernel happy.
Thanks Keith
Best regards,
Angel