[U-Boot] [PATCH RFC] NET: TSEC: make PHY addresses software configurable
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'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?
drivers/net/tsec.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index f5e314b..e86e48c 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -567,6 +567,26 @@ static phy_interface_t tsec_get_interface(struct tsec_private *priv) return PHY_INTERFACE_MODE_MII; }
+static void update_phy_addr(int phy_nr) +{ + char *str, buf[32]; + + sprintf(buf, "tsec_%d_phy_addr", phy_nr); + + str = getenv(buf); + + if (str) { + ulong val = simple_strtoul(str, NULL, 16); + + debug("FIX TSEC%d_PHY_ADDR : %d => %ld\n", + phy_nr, tsec_info[phy_nr].phyaddr, val); + + tsec_info[phy_nr].phyaddr = val; + } else { + debug("FIX TSEC%d_PHY_ADDR : %s not set\n", + phy_nr, buf); + } +}
/* Discover which PHY is attached to the device, and configure it * properly. If the PHY is not recognized, then return 0 @@ -671,7 +691,10 @@ int tsec_eth_init(bd_t *bis, struct tsec_info_struct *tsecs, int num) int i; int ret, count = 0;
+ debug ("tsec_eth_init()\n"); for (i = 0; i < num; i++) { + update_phy_addr(i); + ret = tsec_initialize(bis, &tsecs[i]); if (ret > 0) count += ret;
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
participants (2)
-
Andy Fleming -
Wolfgang Denk