On Thu, Jul 18, 2013 at 12:11 AM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> Hi Andy,
>
> On Wed, 17 Jul 2013 13:53:08 -0700, Andy Lutomirski wrote:
>> The new DIMM-bus code can detect eeproms, so give the eeprom driver
>> an appropriate modalias.
>>
>> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
>> ---
>> drivers/misc/eeprom/eeprom.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
>> index c169e07..1ec85b8 100644
>> --- a/drivers/misc/eeprom/eeprom.c
>> +++ b/drivers/misc/eeprom/eeprom.c
>> @@ -215,6 +215,7 @@ static const struct i2c_device_id eeprom_id[] = {
>> { "eeprom", 0 },
>> { }
>> };
>> +MODULE_DEVICE_TABLE(i2c, eeprom_id);
>>
>> static struct i2c_driver eeprom_driver = {
>> .driver = {
>
> Nack. The eeprom driver will eventually die, I don't want to see
> anything like that added to it. Please use the at24 driver for anything
> new.
at24 doesn't have .class=I2C_CLASS_SPD (and I still am not really a
fan of the i2c class mechanism). 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?
(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.)
--Andy
>
> Thanks,
> --
> Jean Delvare
--
Andy Lutomirski
AMA Capital Management, LLC
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
