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 [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
