[U-Boot] Handling different ethernhet phys on the same system.

[vb]

On Fri, Sep 26, 2008 at 10:03 AM, Ben Warren <biggerbadderben at gmail.com> wrote:
>
> This is a topic that has been brought up many times before.  I actually
> started porting the Linux PHY stuff, but quickly realized that my limited
> CPU cycles would be better spent cleaning up the overall Ethernet driver
> architecture, with the PHY stuff to come later.
>
> I like your ideas.  In addition to the inflexibility that you've mentioned,
> there's a lot of code duplication (see, for example the number of PHYs that
> are listed in the TSEC driver).  One of the things that's difficult to
> balance, and I don't know too many other peoples opinions, is how much board
> C code is acceptable, versus how much information should be specified by
> CONFIG_x definitions.  If everybody suddenly has to define an elaborate
> array of structs in board code rather than a few CONFIGs, usability goes
> down.  I don't really care, since IMHO you should know what you're doing
> when you port a bootloader, but maybe others feel differently.
>
> Another thing to keep in mind is that we don't need to strongly bind a PHY
> type to an interface, really just a bus/ address (assuming we're using
> MDIO), since the devices are mostly probe-able.
>

Ben, great to hear that we think the same :-)

You are right that the PHYs can be probed, so there is no need to
attach any particular driver ahead of time, the only thing required
from the developer would the MDIO address defined in CONFIG_PHYSx_ADDR
as it is already done today.

Also, we can provide a 'catch all' driver relying on the standard PHY
register definition to fall back to if probing finds a PHY for which a
driver is not available.

> Good conversation - let's keep it going.  It would be great if you could
> work on this.
>

Absolutely, I'll look into implementing something along these lines,
it is interesting to see what others think,

cheers,
Vadim

> regards,
> Ben
>