On Monday 02 June 2008, Jean Delvare wrote: > > 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...
Who knows what protocol the "other drivers" expect to work. It might happen to look like writing to arbitrary addresses. Not unlike "read with 16-bit address" starts out with bytes that look just like "write to 8-bit address"... > > > 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. Not yet true. There are systems that still need to use legacy drivers. In a few years, I hope you're correct about this. > 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. I personally won't worry much about 24c00 chips; I have some for testing, but haven't seen new systems using them for some time. It was news for me that they exist on DDC links! _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
