On Tue, Oct 14, 2014 at 12:21 PM, Simon Glass <s...@chromium.org> wrote: > > Hi, > > On 14 October 2014 18:26, Alban Bedel <alban.be...@avionic-design.de> wrote: > > Many ethernet devices use an EEPROM to store various settings, most > > commonly the device MAC address. But on some devices it can contains > > a lot more, for example USB device might also have many USB related > > parameters. > > > > This commit add a set of commands to read/write this EEPROM, write a > > default configuration and read/write the device MAC address. The > > defaults command allow priming the EEPROM for devices that need more > > than just a MAC address in the EEPROM. > > > > Signed-off-by: Alban Bedel <alban.be...@avionic-design.de> > > --- > > v2: * No changes since v1 > > v3: * Replace the dedicated 'eth_eeprom' command with a subcommand > > to the newly introduced 'eth' command > > I see a few EEPROM implementations in the code base. It feels to me > like we need an EEPROM interface. In driver model terms this could be > a uclass. I started something here: > > http://patchwork.ozlabs.org/patch/399039/ > > Of course we don't have DM for Ethernet yet - when we do I think a > child EEPROM device below the Ethernet would make sense. It could be > created by the Ethernet driver when it knows that this information > exists. But even without that I feel that the EEPROM should be > logically separated from Ethernet. > > So I suggest that instead of an #ifdef to adjust the Ethernet API, add > a pointer to another struct containing the EEPROM API and put it in > its own header. I also feel that there should ultimately be an eeprom > command which operates on these. Then the only Ethernet API call would > be to find the EEPROM pointer, if there is one. > > If someone feels like taking it on, driver model support for Ethernet > should be pretty easy. Or even EEPROM could be done now and this might > avoid churn. But I would be happy for this series to be applied as is > while working on a driver model version. I just don't feel we should > be adding new subsystems that don't use driver model.
I agree that we shouldn't add new subsystems that don't use DM. I think this (adding eeprom access to Ethernet) is a decent compromise until we have driver model for Ethernet. I do like your idea of having an eeprom class / subsystem / command that can operate on this type of thing the same way no matter where it's connected, but it probably isn't a good idea to add an "eeprom" command for that without using DM first. So your idea sounds good, but it leaves me with one question... if we want to accept this now as it is, then do we want to introduce a new command (eth eeprom) when we already know we want to change its behavior or delete it once we add a uclass for eeproms? BTW, speaking of DM for Ethernet, I'll take on moving it over around the end of this month if no one beats me to it. Cheers, -Joe
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
