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

[Simon Glass]

Hi,

On 14 October 2014 18:26, Alban Bedel <alban.bedel at 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 at 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.

Regards,
Simon