On Mon, Jun 10, 2013 at 8:45 AM, Wolfgang Denk wd@denx.de wrote:
Some systems use a SoM (system on module) in such a way that the PHY addresses depend on the carrier board used, or even on the geographic position of the SoM on the carrier board. This patch adds support for runtime assignment of the PHY addresses for the TSEC ports through environment variables "tsec_1_phy_addr", "tsec_2_phy_addr", ...
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Joe Hershberger joe.hershberger@gmail.com
This is a RFC patch to have a base for discussing the approach. There are a few things I dislike - all comments welcome:
- It would be nice if there was a generic approach that works for all types of network interfaces instead of only TSEC ports, but I could not find a good generic place for such a hook.
I suppose we could define an interface which the various drivers could implement. Currently, the drivers all have their own mechanisms for tracking that (and many of them are just hardcoded). There are a number of freescale boards which do solve part of this problem. Are the carrier boards variable in design? Currently, all of our systems are able to anticipate all the possible configurations, but I can certainly see that this would not always be possible. For an example of a particularly complex setup, see board/freescale/t4qds/eth.c. We have a function implemented in the fm driver which changes the PHY address: fm_info_set_phy_address(), which the board code calls whenever the address will stray from the default.
One of our carrier cards changes addresses depending on which slot it is in, and we account for that, as well. However, we don't support arbitrary addresses at the moment. If you can avoid user intervention on that level, it'd be preferable. I can't imagine the headache of having to start almost every network debug session with checking to see if the PHY addresses have been set correctly by hand.
For a much simpler example, see board/freescale/common/sgmii_riser.c
- I'm not sure if "tsec_1_phy_addr" etc. is a good name ;-)
- Maybe there is another way to address this issue? I can't believe we're the first to run into this type of problem?
Perhaps we should make that part more generic? ethNphyaddr, to conform to the mac addresses?
Andy