Re: Haswell systems & i801 i2c driver

Re: Haswell systems & i801 i2c driver

[Bjorn Helgaas]

[+cc Rafael, Matthew, linux-acpi]

Hi Prarit,

On Mon, Apr 7, 2014 at 12:00 PM, Prarit Bhargava <prarit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdf
>
> I see the following warning:
>
> i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> ACPI: resource 0000:00:1f.3 [io  0xefa0-0xefbf] conflicts with ACPI region SMBI
> [io 0xefa0-0xefaf]
> ACPI: This conflict may cause random problems and system instability
> ACPI: If an ACPI driver is available for this device, you should use it instead
> of the native driver
>
> It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the
> SMBus to use, but there is no ACPI driver available for the SMBus (at least
> AFAICT).

Is this on a production BIOS?  It seems like a BIOS bug to expose a
PCI device with resources that are used by ACPI.  The spec you pointed
to does mention an "SMBus Disable" bit (sec 10.1.54) that claims to
disable PCI config space for this device.  Maybe the BIOS forgot to
set that?

If we (the Linux PCI core) discovered this device (00:1f.3), we
believe we own it and can assign a driver to it and potentially change
the resources assigned to it.

Changing the [io  0xefa0-0xefbf] BAR would likely break the SMBI
opregion because the AML using it wouldn't know about the change.

Assigning a driver, e.g., i801_smbus, seems likely to cause conflicts
with the AML that uses the SMBI opregion.  These could be difficult to
reproduce and debug.

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?)

Bjorn

Re: Haswell systems & i801 i2c driver

[Matthew Garrett]

> 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.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

Re: Haswell systems & i801 i2c driver

[Jean Delvare]

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 :(

-- 
Jean Delvare
SUSE L3 Support

Re: Haswell systems & i801 i2c driver

[Prarit Bhargava]

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.
>