Hi Andy, On Thu, 18 Jul 2013 09:15:47 -0700, Andy Lutomirski wrote: > at24 doesn't have .class=I2C_CLASS_SPD (and I still am not really a > fan of the i2c class mechanism). The class-based auto-detection has its merits but it's not the solution to all problems. .class=I2C_CLASS_SPD could be added to the at24 driver. If we ever want to kill the legacy eeprom driver, we will have to do exactly that. That being said this won't help in your case, as your bus driver does not support the SMBus transaction (Receive Byte) used to probe for EEPROM chips in address range 0x50-0x57. > Shall I play with ways to get known > DIMM-only busses to probe these things directly and instantiate with > i2c_new_device(..., .type="spd")? Do you have other plans for how > probing should work? You could indeed call i2c_new_probed_device() on addresses 0x50-0x57 at the end of your new i2c bus driver's probe function, in order to instantiate spd devices. This function takes a probe function as a parameter so you could use a transaction type supported (Read Byte.) > (For background in case you haven't been following the rest of the > thread: the Intel iMC (integrated memory controller) bus appears to > have only DIMMs attached, so everything on the bus is either the host > or is something attached to a DIMM. The latter devices have > well-defined addresses: four bits of type and three bits of slot > number. This makes it easy to probe accurately. I'm not sure that > the i2c core class mechanism is well-suited to this, it's easy to do > manually.) Ideally the BIOS/firmware/whatever would tell the OS which memory slots are used so that the kernel can instantiate all I2C/SMBus slave devices without even probing for them. I really wonder how many decades it will take to Intel and co to come up with a complete device typology description on the PC/x86_64 platfor, so that probing is finally history. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
