Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor in the SPD case" - "sysfs: cannot create duplicate filename"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/24/24 07:54, Guenter Roeck wrote:
[ ... ]

That said, I have some follow-up questions:

1. if the jc42 driver handles this already, I wonder what's the point of adding
at24_probe_temp_sensor()? Is there a situation where it would not do it properly?
Or do we expect to remove the probing functionally from jc42.c?


The jc42 driver is not auto-loaded. When suggesting to remove the "probing
functionally", I assume you mean to remove its detect function. That would only
work if SPD EEPROMs were only connected to I2C adapters calling i2c_register_spd(),
and if the systems with those adapters would support DMI.

In v6.9, i2c_register_spd() is only called from the i801 driver (Intel systems).
In v6.11, piix4 (AMD) will be added. Even after that, all non-Intel / non-AMD systems
would no longer be able to support jc42 compatible chips by just loading the jc42
driver. That would not be acceptable.


There is another reason to not remove the detect function, one that I just found in
my system when I tried to reproduce the problem: While SPD data is supposed to identify
if a DIMM supports a temperature sensor, this is not always the case. The DIMMs
in one of my systems (F4-3200C14-16GTZSW) do support temperature sensors, but the
respective bit in the SPD data is not set. From raw SPD data:

000000 23 10 0c 02 85 21 00 08 00 40 00 03 09 03 00 00
                                                 ^^
Bit 7 is supposed to be set but isn't.

This means that the thermal sensors on the DIMMs in my system would not be instantiated
without detect function and require manual instantiation.

Guenter





[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux