[U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices

[Marek Vasut <marex@denx.de>]

On Tuesday, October 14, 2014 at 07:21:06 PM, Simon Glass wrote:
> Hi,
> 
> On 14 October 2014 18:26, Alban Bedel <alban.bedel@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.bedel@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