On 10.11.2023 12:08, Jean Delvare wrote: > 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. > Apart from the described extension of i2c_register_spd() I wonder where to best call it for the muxed smbus segments. At first I think we have to make the assumption that in case of muxing memory slots are on the muxed child segments only. At least I don't see an easy way to deal with the potential scenario that some memory slots are on the parent segment, and some on muxed segments. i801_add_mux() instantiates the i2c-mux-gpio platform device, and I think loading and probing the i2c-mux-gpio driver can happen asynchronously. This would mean we can't call i2c_register_spd() for the child segments from i801. So we may have to call it from the i2c-mux-gpio driver.
