[U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

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.