On 04/07/2014 04:56 PM, Jean Delvare wrote: > 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 :( Hey Jean, Thanks for the info. I'm about to RFC an algorithm patch for the i801 ACPI SBUS. I dunno if it is really a good thing to do outside of Intel or if we should wait for a CMI. OTOH it seems to work and your comment that "This has been a major pain for years" worries me that we'll never see a solution. P. > -- 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
