i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR
Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900: Device (SBUS) { OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10) Field (SMBI, ByteAcc, NoLock, Preserve) { HSTS, 8, Offset (0x02), HCON, 8, HCOM, 8, TXSA, 8, DAT0, 8, DAT1, 8, HBDR, 8, PECR, 8, RXSA, 8, SDAT, 16 } There are also bunch of AML methods that that the BIOS can use to access these fields. Most of the systems in question AML methods accessing the SMBI OpRegion are never used. Now, because of this SMBI OpRegion many systems fail to load the SMBus driver with an error looking like one below: ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F conflicts with OpRegion 0x0000000000003040-0x000000000000304F (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver The reason is that this SMBI OpRegion conflicts with the PCI BAR used by the SMBus driver. It turns out that we can install a custom SystemIO address space handler for the SMBus device to intercept all accesses through that OpRegion. This allows us to share the PCI BAR with the AML code if it for some reason is using it. We do not expect that this OpRegion handler will ever be called but if it is we print a warning and prevent all access from the SMBus driver itself. Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041 Reported-by:Andy Lutomirski <luto@kernel.org> Reported-by:
Pali Rohár <pali.rohar@gmail.com> Suggested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by:
Pali Rohár <pali.rohar@gmail.com> Tested-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@vger.kernel.org
parent
af8c34ce
Please register or sign in to comment