Bug 110041
| Summary: | Dell XPS 13 9350 and many other laptops interfere with i2c_i801 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Andy Lutomirski (luto) |
| Component: | BIOS | Assignee: | Mika Westerberg (mika.westerberg) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | aaron.lu, jdelvare, pali, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.4-rc5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Dell Latitude E6440 - SBUS device from ACPI DSDT
acpidump output from XPS 13 9350, firmware 1.2.3 |
||
Dell Latitude E6440. Same problem. In ACPI is defined SBUS device without _HID, but not referenced by any other ACPI code. This probably affects all Intel Haswell laptops, not only Dell. Created attachment 198351 [details]
Dell Latitude E6440 - SBUS device from ACPI DSDT
@Aaron is there any way to fix this problem without patching ACPI DSDT table? Or do you have idea what we can do? Nothing right from my head, in the meantime, can you please upload the acpidump? # acpidump > acpidump.txt And dmesg, thanks. Created attachment 208581 [details]
acpidump output from XPS 13 9350, firmware 1.2.3
(In reply to Aaron Lu from comment #4) > Nothing right from my head This is bug in DSDT table provided by Intel to Notebook manufactors. Intel should fix this "firmware" bug for future products... For existing products we need such "fix" in kernel code. Either allowing to load native PCI i2c-i801.ko driver or create new ACPI driver which use that existing ACPI interface in DSDT (already attached). There is already code for second option (ACPI driver), but for unknown reason it does not work. Code is in git repository: https://github.com/pali/i2c-acpi-sbus If you can help how to fix that ACPI driver or find reason why it does not work, it would be really nice! By "does not work" I mean that ACPI code always return zeros for all read/write i2c functions. But it looks like that ACPI DSDT code is "same" as what is in native PCI driver i2c-i801.ko. So maybe some initialization or something like that is missing... Looks like adding acpi_enforce_resources=lax to kernel cmdline should help here? (In reply to Aaron Lu from comment #7) > Looks like adding acpi_enforce_resources=lax to kernel cmdline should help > here? Yes, but it is very ugly hack and apply to all devices, not only that one PCI device... So it should be avoided. The problem has been fixed by this patch commit a7ae81952cdab56a1277bd2f9ed7284c0f575120 Author: Mika Westerberg <mika.westerberg@linux.intel.com> Date: Thu Jun 9 16:56:28 2016 +0300 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 |
On a bunch of laptops, i2c_i801 fails to load because of: ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150930/utaddress-254) The opregion in question is: 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 } I think that the firmware should be declaring and using a GenericSerialBus OpRegion instead of rolling its own polling SMBUS driver in ASL. For the Dell XPS 13 9350, this is particularly silly, because AFAICT nothing in any of the ACPI tables even references the SBUS device. All it does is create a conflict. My understanding is that the underlying ASL code for this actually comes from Intel. Could Intel fix this?