Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

[Andy Lutomirski <luto@amacapital.net>]

On Fri, Apr 29, 2016 at 2:42 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Apr 29, 2016 at 2:00 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> On Friday 29 April 2016 20:10:23 Andy Lutomirski wrote:
>>> On Fri, Apr 29, 2016 at 2:03 AM, Pali Rohár <pali.rohar@gmail.com>
>>> wrote:
>>> > On Thursday 28 April 2016 11:34:38 Andy Lutomirski wrote:
>>> >> On 04/28/2016 03:23 AM, Mika Westerberg wrote:
>>> >> >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 ASL methods that that the BIOS can use to
>>> >> >access these fields. Most of the systems in question ASL 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 ASL
>>> >> >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 execute the read/write operation under a lock
>>> >> >which prevents ASL and OS from messing each other.
>>> >>
>>> >> Tested-by: Andy Lutomirski <luto@kernel.org> # Dell XPS 13 9350
>>> >>
>>> >> This successfully works around:
>>> >>
>>> >> https://bugzilla.kernel.org/show_bug.cgi?id=110041
>>> >>
>>> >> but the BIOS people should still fix their ASL.  Sigh.
>>> >>
>>> >> On the Dell laptop, the observable effect is that the driver loads
>>> >> and finds the iTCO thing.
>>> >>
>>> >> Pali, this may be considerably more useful on your laptop.
>>> >
>>> > Andy, I am right that I will be able to load i2c-i801.ko driver
>>> > without acpi_enforce_resources=lax parameter?
>>>
>>> Yes, and it works on my laptop.
>>
>> Looks like it is working also on my laptop.
>>
>>> > If yes, then it sounds good! Finally I would be able to bind
>>> > lis3lv02d_i2c.ko driver for accelerometer which is on my E6440
>>> > machine.
>>> >
>>> > Andy, is there any way to tell i2c-i801.ko driver that on i2c bus
>>> > (which that driver exports) is present some i2c device? Months ago
>>> > I got list of Latitude machines on which i2c address is that
>>> > accelerometer present.
>>> >
>>> > It is possible to hardcode that mapping (DMI name of laptop --> i2c
>>> > address) into dell-laptop driver, so i2c-i801.ko and
>>> > lis3lv02d_i2c.ko will be automatically loaded and lis3l binded
>>> > correctly to i801 i2c address?
>>>
>>> I don't know how this part works, but I doubt that doing it in
>>> dell-laptop will be convenient.  After all, dell-laptop can load
>>> before i2c-i801.
>>>
>>> Jean and Wolfram: is there a quirk mechanism to add i2c devices that
>>> aren't directly enumerable but are known to exist due to DMI?
>>
>> Maybe something like i2c_register_board_info()?
>
> Maybe.  i think that wants to be called before the adapter shows up, though.

i2c_probe_optional_slaves may be a more appropriate place to put this.

Also, is there any indication in your DSDT that this thing exists?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html