Re: [PATCH v3 4/4] eeprom: Add a MODULE_DEVICE_TABLE

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

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