On 08/20/2012 05:35 PM, Andy Fleming wrote:
On Monday, August 20, 2012, Troy Kisky wrote:

It is useful to be able to try a range of
possible phy addresses to connect.



This seems like it just encourages a bad habit. How do you envision this
working on a system with multiple Ethernet controllers? Or with more PHYs
than Ethernet controllers? While it is often the case that the PHY is the
only one on a bus, I think it's a bad idea to codify that notion in the
driver (I know, it was already like that).

It's best if the driver make the reasonable assumption that its PHY address
is known when it comes up, and let the board code, which can be aware that
the PHY may exist in varying locations, search for the PHY.

A mask with a single bit set is about as specific as you can get, right?

Are you asking for something more extensible, like a callback into
board-specific code?

> With that approach, the driver won't have to change when some board
> designer makes the PHY topology even stranger, and I would support
> a PHYLIB function to do searching much as you've specified.

The primary reason for this change is that it's not only the board
designer, but also the purchasing manager or manufacturer who can
change the address.

Since the PHY addresses are often driven by the state of LEDs on
an ethernet connector, swapping part numbers can result in different
PHY addresses. We run into this on our Nitrogen6X boards where
PoE-enabled jacks result in a different PHY address from a standard jack.

> But the board-specific code needs to be able to tell the driver definitively
> which PHY belongs to it.


Andy
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to