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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 24 Jun 2024 09:23:55 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Krzysztof Olędzki <ole@....pl>,
 Heiner Kallweit <hkallweit1@...il.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Bartosz Golaszewski <brgl@...ev.pl>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Wolfram Sang <wsa@...-dreams.de>
Cc: stable@...r.kernel.org, linux-i2c@...r.kernel.org,
 linux-hwmon@...r.kernel.org,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor
 in the SPD case" - "sysfs: cannot create duplicate filename"

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