Re: [PATCH RFC] i2c: i801: Add i801_register_jc42, similar to i2c_register_spd

Heiner Kallweit
2023-11-14T15:00:13Z

On 14.11.2023 15:44, Heiner Kallweit wrote:
> On 14.11.2023 15:00, Jean Delvare wrote:
>> Hi Heiner,
>>
>> On Wed, 08 Nov 2023 11:28:45 +0100, Heiner Kallweit wrote:
>>> On 08.11.2023 08:27, Heiner Kallweit wrote:
>>>> As discussed, this is a RFC version of changing jc42 auto-detection
>>>> with the goal to get rid of I2C_CLASS_SPD completely mid-term.
>>>>
>>>> Code of i801_jc42_probe() was copied from jc42 driver, just w/o
>>>> the device id check. I think it's safe enough w/o this check.
>>>>
>>>> I don't have hw to test this, therefore it's compile-tested only.
>>>>
>>>> Link:
>>>> https://lore.kernel.org/linux-i2c/a22978a4-88e4-46f4-b71c-032b22321599@gmail.com/
>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> ---
>>>> drivers/i2c/busses/i2c-i801.c | 48
>>>> ++++++++++++++++++++++++++++++++--- 1 file changed, 44
>>>> insertions(+), 4 deletions(-)
>>>
>>> That's quite some code for more or less nothing. I2C_CLASS_SPD is
>>> relevant only for users:
>>> - having one of the specific old ASUS machines with i2c-muxing
>>> - having RAM with a jc42-compatible temperature sensor
>>> - manually loading module jc42 to expose the temp sensor
>>
>> People running such systems would typically run sensors-detect to setup
>> their hardware monitoring, so the jc42 driver would be loaded at boot
>> by the lm-sensors service. This is "manual" from the kernel's
>> perspective, but still this is integrated and has been working for
>> years. If you break that, this is a functional regression.
>>
>> There is nothing fundamentally specific to i2c-i801 or these Asus
>> boards here. The only reason why we are discussing it in this context
>> is because SMBus multiplexing adds some implementation constraints, and
>> it turns out that right now only the i2c-i801 driver has support for
>> PC-style boards with multiplexed SMBus.
>>
>> The solution however needs to work on all PC-style systems, Intel or
>> AMD (or anything else that exists), with SMBus multiplexed or not.
>>
>> Originally, I2C_CLASS_SPD was there, the eeprom and jc42 drivers were
>> using it, and just loading these drivers would instantiate all the
>> devices. This is the level of user-friendliness we must aim at.
>>
>> Now, the eeprom driver is gone, so class-based SPD device support no
>> longer exists. This was replaced by i2c_register_spd(), but is
>> currently only working on non-multiplexed Intel-based systems. Ideally
>> this should be extended to non-Intel systems (I'm surprised nobody
>> reported about that regression yet) and Intel systems with multiplexed
>> SMBus (that would be achieved by calling i2c_register_spd explicitly on
>> these segments, possibly with a few changes, as discussed earlier).
>>
>> The jc42 driver still works the way it used to. If you remove
>> I2C_CLASS_SPD, this will still work on most non-SMBus-multiplexed
>> systems (thanks to I2C_CLASS_HWMON), but will stop working on the
>> multiplexed Asus boards (because the bus segments which host the memory
>> modules don't have I2C_CLASS_HWMON, and can't have it), or any other
>> board using SMbus multiplexing which we would like to support in the
>> future. I believe there are still many such systems out there, as
>> server systems with more than 8 memory slots are legions and this is
>> the hard limit of how many memory slots can be connected to a single
>> SMBus segment. We could receive a request to support such recent server
>> boards at any time, so we better be ready for it.
>>
>> This is the reason why I asked for jc42 devices to be instantiated
>> automatically on multiplexed SMBus segments. The function doing that
>> should however not live in the i2c-i801 driver, it must be usable by
>> any SMBus controller driver. Also, while we only need this for
>> multiplexed SMBus segments, we could still use it everywhere
>> i2c_register_spd() is used, so that jc42 devices get instantiated at
>> boot-time without the need for user-space support.
>>
>>> From a maintenance point of view the easiest solution would be:
>>> - set flag I2C_CLASS_DEPRECATED in addition to I2C_CLASS_SPD
>>> to encourage potential users to switch to explicit instantiating
>>
>> Bad idea. That's just going to spam a warning message on millions of
>> systems while there's just nothing most users can do about it. That's
>> not helpful, we are already aware of the problem, and we are the guys
>> looking into it.
>>
> I'm afraid I wasn't precise enough when writing this. What I meant is
> adding I2C_CLASS_DEPRECATED for the mux'ed child segments in i801.
> So it should affect users of the few Asus systems only.
> i2c_register_spd() isn't used there, so I'd assume these users don't
> miss the temp sensors on their RAM modules.
>
>>> - wait few kernel versions and remove class-based instantiation
>>
>> Assuming you only refer to I2C_CLASS_SPD and not I2C_CLASS_HWMON, then
>> yes. I2C_CLASS_HWMON must stay as there's no suitable replacement for
>> it yet (and sadly I can't foresee any).
>>
> Sure, I was referring to I2C_CLASS_SPD only. A lot of hwmon drivers
> support auto-detection, so getting rid of I2C_CLASS_HWMON would be
> much harder.
>
>> I think the steps to follow are:
>> * Extend i2c_register_spd() to support up to 8 memory modules (I'm
>> already working on that, patch is coming).
>> * Call i2c_register_spd() on the mux'd SMBus segments on the Asus
>> boards.
>> * Extend i2c_register_spd() to also instantiate jc42 devices in
>> addition to at24 (or ee1004) devices. I think this is better than
>> writing a separate function as I initially suggested. The reason why
>> I think so is because the SPD EEPROM does contain the information
>> about thermal sensor presence. So the code which instantiates the at24
>> or ee1004 device could also read from it to figure out whether a jc42
>> device must be instantiated. This removes the need for probing.
>
> I miss some insight here on which type of memory modules we can expect
> jc42-4 compatible temp sensors. I saw DDR3 mentioned (including LPDDR3?),
> not sure about DDR4. In case of DDR4 we would have to read the EE1004
> data structure to check the "temp sensor present" bit. So I wonder
> whether instantiating the temp sensor should be in ee1004 driver.
>
ee1004 driver supports a single I2C bus only. So maybe we have to extend
this driver too?

>> * Get rid of I2C_CLASS_SPD.
>>
>