> Yes, we can't cover all the eeprom types, but I think people need > one example with all the function can be used. If somebody need use > at24.c for another eeprom, he only need to do the change > "s/at24/eeprom type", which maybe helpful to others. Anyway, > current code aren't work because of the lack of these members. The instantiation of devices is described here: Documentation/i2c/instantiating-devices I'd think that would do to help people? > > 2. Since the at24 driver are tightly coupled with i2c bus > > driver, make ï ïsure it's init priority is lower than i2c bus. > > Can you describe a scenario where the current method fails? > > In my board, at24_init() is called before i2c-bus driver, because > the bus driver is initialized with module_init. But some i2c bus > used subsys_initcall to replace module_init, those i2c bus should > be ok without the change. I think only do one modification is > better than change all the i2c bus driver. But they should still match, even if at24 comes first, no? Otherwise there is a bug somewhere. (BTW changing i2c-bus-drivers to subsys_initcall() looks better to me, too, because if there is something like a PMIC or GPIOs connected to the bus, you usually want them early). Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
