Bug 110041 - Dell XPS 13 9350 and many other laptops interfere with i2c_i801
Summary: Dell XPS 13 9350 and many other laptops interfere with i2c_i801
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Mika Westerberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-27 13:12 UTC by Andy Lutomirski
Modified: 2016-06-20 02:29 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.4-rc5
Tree: Mainline
Regression: No


Attachments
Dell Latitude E6440 - SBUS device from ACPI DSDT (8.96 KB, text/plain)
2015-12-27 13:24 UTC, Pali Rohár
Details
acpidump output from XPS 13 9350, firmware 1.2.3 (854.54 KB, application/octet-stream)
2016-03-10 02:08 UTC, Andy Lutomirski
Details

Description Andy Lutomirski 2015-12-27 13:12:30 UTC
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?
Comment 1 Pali Rohár 2015-12-27 13:22:59 UTC
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.
Comment 2 Pali Rohár 2015-12-27 13:24:30 UTC
Created attachment 198351 [details]
Dell Latitude E6440 - SBUS device from ACPI DSDT
Comment 3 Pali Rohár 2016-03-09 16:47:56 UTC
@Aaron is there any way to fix this problem without patching ACPI DSDT table? Or do you have idea what we can do?
Comment 4 Aaron Lu 2016-03-10 01:50:58 UTC
Nothing right from my head, in the meantime, can you please upload the acpidump?
# acpidump > acpidump.txt
And dmesg, thanks.
Comment 5 Andy Lutomirski 2016-03-10 02:08:32 UTC
Created attachment 208581 [details]
acpidump output from XPS 13 9350, firmware 1.2.3
Comment 6 Pali Rohár 2016-03-10 10:23:27 UTC
(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...
Comment 7 Aaron Lu 2016-03-10 12:07:36 UTC
Looks like adding acpi_enforce_resources=lax to kernel cmdline should help here?
Comment 8 Pali Rohár 2016-03-10 12:10:01 UTC
(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.
Comment 9 Zhang Rui 2016-06-20 02:29:41 UTC
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

Note You need to log in before you can comment on or make changes to this bug.