On Tuesday, October 14, 2014 at 07:21:06 PM, Simon Glass 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.
Speaking of eeprom command, I am now in the process of cleaning up common/cmd_eeprom.c . Simon, do you have anything related to DM which explicitly touches this file ? If not, I'd suggest you wait a bit until I manage to resolve the ifdef maze in there and look into it only after the cleanup is done. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
