[U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x
Jean-Christophe PLAGNIOL-VILLARD
plagnioj at jcrosoft.com
Sun Dec 9 10:21:22 CET 2007
On 19:44 Sat 08 Dec , Ben Warren wrote:
> Michael Schwingen wrote:
> > Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> >> If you have a switch between your phy and your cpu the speed and
> >> the duplex must be specified by the phy driver.
> >>
> >>
> > Which PHY driver? The NPE code directly calls miiphy_read to acces
> > standard PHY registers, so where does a PHY driver come into play here?
> >
> >
> The way that you're doing it is correct - there is no PHY driver, only
> access methods. Hopefully this will change soon, but I'm unfortunately
> being distracted.
> >> The best way is to add a function that request the phy status
> >> and do not wait the phy autonegociation like done in the kernel
> >> by read_status callback and it's implementation
> >> genphy_read_status.
> >>
> >>
> > I do not really see how that should work, for multiple reasons:
> > - speed/duplex on the MII bus depend on the attached switch and may be
> > different from the speed/duplex on any of the PHYs that are attached to
> > the switch.
> >
You're right the speed depends on the switch, and as example for the marvell
88E6031/88E6060 this speed/duplex is determine by pull-up at the switch reset
(CPU port) and could be read through the MDIO bus but not modify.
You could also have a tree of switch that need to be configured and not
only forced the cpu port speed/duplex at 100/FULL.
But on other switch the could be determine and modify dynamicly.
The speed/duplex depends on the switch and may not hard code in the npe.
In this way you could use it with other mac layer.
> The only thing that matters is the speed/duplexity of the MII bus, which
> is fixed. When connected to a switch the link is always up, and the
> state of the network port needs to be determined by higher layers, most
> likely be a timeout.
> > - most switches (Marvell 88E6060 or similar) have multiple downstream
> > ports with PHYs - which one should I poll to get useful information?
> > Simply waiting for a link on any port will not guarantee that this is
> > the port via which the server is connected, so polling anything is
> > pretty useless IMHO.
> >
The link is not necessarily always up, you may won't to keep it down to
use less power.
The link of other phy/mii ports could be advertise by an interruption.
> > - there are switches (Marvell 88E6050) that have no MDIO interface -
> > they have a fixed MII speed/duplex, and the CPU has no way to know about
> > the status of any of the PHYs.
> >
> >
> There are others (Broadcom, anyway) that use SPI as control plane. The
> bottom line is that for fixed interfaces like this, software needs to
> hard-wire the link state, as you've done.
> > I am a bit confused - could you please clarify in what direction the
> > code should evolve to solve these problems better than my patch does?
> >
> >
> Change the CONFIG_MII_ETHSWITCH to CONFIG_FIXED_PHY (as done in Linux)
> and I'll be happy. Later on we need to change things to have port-wise
> granularity, but we're not there yet.
As I said before each as it's own way to determine the speed/duplex do
it as hard-code is not the best way.
I will prefer an external function that take care of the switch that
could me merge with the new phylib after.
Best regards,
J.
More information about the U-Boot
mailing list