[U-Boot] [PATCH RFC] NET: TSEC: make PHY addresses software configurable

[Andy Fleming]

On Mon, Jun 10, 2013 at 8:45 AM, Wolfgang Denk <wd at 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 at denx.de>
> Cc: Joe Hershberger <joe.hershberger at 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