From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 14 Oct 2014 22:59:28 +0200 Subject: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices In-Reply-To: References: <1413303972-26143-1-git-send-email-alban.bedel@avionic-design.de> <1413303972-26143-2-git-send-email-alban.bedel@avionic-design.de> Message-ID: <201410142259.28957.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday, October 14, 2014 at 07:21:06 PM, Simon Glass wrote: > Hi, > > On 14 October 2014 18:26, Alban Bedel 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 > > --- > > 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