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.
Regards, Simon