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@xxxxxxxxx/ >>>> Signed-off-by: Heiner Kallweit <hkallweit1@xxxxxxxxx> --- >>>> 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. >> >
