Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

[Andy Lutomirski <luto@amacapital.net>]

On Mar 13, 2015 9:15 PM, "Guenter Roeck" <linux@roeck-us.net> wrote:
>
> On 03/09/2015 01:55 PM, Andy Lutomirski wrote:
>>
>> Sandy Bridge Xeon and Extreme chips have integrated memory
>> controllers with (rather limited) onboard SMBUS masters.  This
>> driver gives access to the bus.
>>
>> There are various groups working on standardizing a way to arbitrate
>> access to the bus between the OS, SMM firmware, a BMC, hardware
>> thermal control, etc.  In the mean time, running this driver is
>> unsafe except under special circumstances.  Nonetheless, this driver
>> has real users.
>>
>> As a compromise, the driver will refuse to load unless
>> i2c_imc.allow_unsafe_access=Y.  When safe access becomes available,
>> we can leave this option as a way for legacy users to run the
>> driver, and we'll allow the driver to load by default if safe bus
>> access is available.
>>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> ---
>>   drivers/i2c/busses/Kconfig   |  17 ++
>>   drivers/i2c/busses/Makefile  |   1 +
>>   drivers/i2c/busses/i2c-imc.c | 567 +++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 585 insertions(+)
>>   create mode 100644 drivers/i2c/busses/i2c-imc.c
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index ab838d9e28b6..50e3d79122dd 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -149,6 +149,23 @@ config I2C_ISMT
>>           This driver can also be built as a module.  If so, the module will be
>>           called i2c-ismt.
>>
>> +config I2C_IMC
>> +       tristate "Intel iMC (LGA 2011) SMBus Controller"
>> +       depends on PCI && X86
>> +       help
>> +         If you say yes to this option, support will be included for the Intel
>> +         Integrated Memory Controller SMBus host controller interface.  This
>> +         controller is found on LGA 2011 Xeons and Core i7 Extremes.
>> +
>> +         There are currently no systems on which the kernel knows that it can
>> +         safely enable this driver.  For now, you need to pass this driver a
>> +         scary module parameter, and you should only pass that parameter if you
>> +         have a special motherboard and know exactly what you are doing.
>> +         Special motherboards include the Supermicro X9DRH-iF-NV.
>> +
>
> I think the current approach of issuing warnings here and in the driver on load
> is the wrong one. For the most part, users will just run with distributions.
> If a distribution enables the driver, it will end up being used, warning or not.
>
> A much better approach, in my opinion, would be to only enable the driver for
> systems where it is known (or presumed) to be good, such as the Supermicro board
> mentioned above. This can be done with DMI data.
>
> For other boards, a 'force' module parameter can be added. This would ensure
> that the user _has_ to do something manually to load the driver. The warning
> on load would then only be displayed if the force module parameter is set.
>

This driver already has that: that's what "allow_unsafe_access" does.

I wouldn't be opposed to adding a DMI whitelist, although I really
don't want DMI entries to proliferate.

> Having said that, I am still not convinced that the driver should be in the kernel
> to start with. Browsing through Intel's datasheets, the registers are supported
> in E5-2600 v1, v2, and v3. However, in v3 Intel added a note saying that the registers
> should not be accessed by the OS directly, but only through the bios. Given that,
> and if that is possible, it might make more sense to rely on ACPI. It would then
> be up to the board and/or BIOS vendor to decide if the information should be available
> to the OS or not.

I think the plan is to add something to ACPI to tell us when we can
use these registers.  Unfortunately I'm not privy to whatever the ACPI
committee is doing.


--Andy