Hi Heiner, On Thu, 9 Nov 2023 17:34:15 +0100, Heiner Kallweit wrote: > On 09.11.2023 14:52, Jean Delvare wrote: > > For example, if DMI data says the system is using DDR4 and we were able > > to detect and instantiate an ee1004 SPD device at I2C address 0x50 then > > we should probe for a JC42.4-compliant temperature sensor device at I2C > > address 0x18. An SPD EEPROM at 0x51 would correspond to a possible > > JC42.4-compliant device at 0x19, and so on. > > Nice idea. How about our ASUS use case in i801? i2c_register_spd() isn't > called in case of muxing, neither for the parent nor for the mux children. When I introduced i2c_register_spd(), I wanted to go one step at a time, as I didn't know what to expect due to the wide variety of systems affected. For this reason, systems where the SMBus is multiplexed were originally excluded. There's also a limitation in the function itself, on the number of memory slots, which is 4 for now, but could be lifted to 8 (maximum number of memory slots connected to a single SMBus segment). The Asus boards we are talking about may have more than 8 memory slots, so they would fail the test. If we want to be able to use i2c_register_spd() on these boards, some adjustments will be needed. For example, we could add a parameter to bypass the memory slot counting, so that the function could be called on children segments (only a subset of the memory slots will be connected to that segment, so the total slot count it irrelevant). We would ignore the DMI data and hard-code dimm_count to 8 in that case, to probe all possible addresses. Another approach would be to add a parameter (probably a bit field) describing which addresses should be probed, instead of guessing that from the dimm_count collected from DMI data. For the Asus boards in question, the information is known, and this would speed things up a bit by not probing addresses which can't possibly correspond to a memory module on a given board. That's only a minor optimization though, so not necessarily worth it. OTOH having that possibility would give more control on the probing, which may be useful for specific boards. -- Jean Delvare SUSE L3 Support
