Re: [PATCH] Add a new-style driver for most I2C EEPROMs

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

On Mon, 2 Jun 2008 12:33:46 -0700, David Brownell wrote:
> On Monday 02 June 2008, Jean Delvare wrote:
> > Not really. The 24C00 might answer to 8 I2C addresses, but how do you
> > care? You only need one address to access the whole data range.
> > Registering the extra clients is a waste of time and memory, so just
> > don't do it.
> 
> One reason the driver claims all the EEPROM addresses used by
> each chip is to address review feedback from Jean Delvare.

You shall not listen to what that guy says. He's a notoriously clueless
idiot! ;)

> ISTR the point was safety:  letting other drivers potentially
> access the device was a bad idea.  ;)

I'm not even sure what problem it could cause in practice...

> > Problem solved :)
> 
> Not really.  The "eeprom" driver, or various other legacy
> drivers knowing about the 0x50..0x57 address range, could
> bind to those addresses.  That problem would not be solved.

If you're using the at24 driver on that bus, you're most certainly
using only new-style drivers and not even setting a "class" for legacy
i2c drivers to probe the i2c adapter. So, nothing will attach to the
extra addresses unless you explicitly ask for it - and then you're on
your own.

Yes, the eeprom driver currently doesn't check for i2c_adapter.class,
and yes, it's a bug. We need to define a class flag for it
(I2C_CLASS_SPD?), set it in all PC SMBus host drivers, and have the
eeprom check for (I2C_CLASS_SPD | I2C_CLASS_DDC).

Once this is fixed, I really see zero benefit in requesting all the
addresses the 24C00 replies to in the at24 driver.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c