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 <[email protected]> wrote: > > Hi all, > > On Sat, May 16, 2020 at 2:23 AM Keith Hui <[email protected]> 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 _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
