On Mon, 7 Apr 2014 20:30:39 +0000, Matthew Garrett wrote: > > If this is on a shipping BIOS, we might need to figure out some way to > > handle it. I don't remember anything in the ACPI spec that talks > > about issues like this, but maybe we should add something in PCI that > > notices if there's an ACPI device with the same resources and marks > > the PCI device to keep us from moving it or assigning a driver (maybe > > the warning you're seeing already handles the driver part?) > > This is, sadly, pretty typical. SMBus devices are often exposed via PCI > even though they're accessed directly via AML. The current behaviour > seems about as good as it gets - we warn the user that this could cause > problems, and they can pass a kernel parameter that allows them to do it > anyway. The proper way to handle it at the BIOS level is to expose the SMBus to the OS by implementing the ACPI SMBus CMI as supported by the i2c-scmi driver. Unfortunately most BIOS do not bother implementing that interface, effectively locking the OS out of the SMBus controller and everything behind it. This has been a major pain for years :( -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
