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

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

[Michael Schwingen]

Hi,

the following patch adds support for an ethernet switch that is connected to
the MII port. In that case, there is no PHY with which auto-negotiation can
be done, and the MII port always runs in full-duplex 100MBit/s mode.

Signed-off-by: Michael Schwingen <michael@schwingen.org>

diff --git a/cpu/ixp/npe/npe.c b/cpu/ixp/npe/npe.c
index 7e4af44..88d0183 100644
--- a/cpu/ixp/npe/npe.c
+++ b/cpu/ixp/npe/npe.c
@@ -361,6 +361,10 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
 
 	debug("%s: 1\n", __FUNCTION__);
 
+#ifdef CONFIG_MII_ETHSWITCH
+	speed = _100BASET;
+	duplex = FULL;
+#else
 	miiphy_read (dev->name, p_npe->phy_no, PHY_BMSR, &reg_short);
 
 	/*
@@ -396,6 +400,7 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
 		printf ("ENET Speed is %d Mbps - %s duplex connection\n",
 			(int) speed, (duplex == HALF) ? "HALF" : "FULL");
 	}
+#endif
 
 	npe_alloc_end = npe_alloc_pool + sizeof(npe_alloc_pool);
 	npe_alloc_free = (u8 *)(((unsigned)npe_alloc_pool +

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:34 Sat 10 Nov     , Michael Schwingen wrote:
> Hi,
> 
> the following patch adds support for an ethernet switch that is connected to
> the MII port. In that case, there is no PHY with which auto-negotiation can
> be done, and the MII port always runs in full-duplex 100MBit/s mode.
> 
> Signed-off-by: Michael Schwingen <michael@schwingen.org>
> 
> diff --git a/cpu/ixp/npe/npe.c b/cpu/ixp/npe/npe.c
> index 7e4af44..88d0183 100644
> --- a/cpu/ixp/npe/npe.c
> +++ b/cpu/ixp/npe/npe.c
> @@ -361,6 +361,10 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
>  
>  	debug("%s: 1\n", __FUNCTION__);
>  
> +#ifdef CONFIG_MII_ETHSWITCH
> +	speed = _100BASET;
> +	duplex = FULL;
> +#else
>  	miiphy_read (dev->name, p_npe->phy_no, PHY_BMSR, &reg_short);
>  
>  	/*
> @@ -396,6 +400,7 @@ static int npe_init(struct eth_device *dev, bd_t * bis)
>  		printf ("ENET Speed is %d Mbps - %s duplex connection\n",
>  			(int) speed, (duplex == HALF) ? "HALF" : "FULL");
>  	}
> +#endif
>  
>  	npe_alloc_end = npe_alloc_pool + sizeof(npe_alloc_pool);
>  	npe_alloc_free = (u8 *)(((unsigned)npe_alloc_pool +

Hi,

	If you have a switch between your phy and your cpu the speed and
	the duplex must be specified by the phy driver.

	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.

Best Regards,
J.

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

[Michael Schwingen]

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 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.
 - 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.
 - 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.

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?

cu
Michael

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

[Ben Warren]

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.
>   
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.
>   

>  - 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.
> cu
> Michael
>
>   
regards,
Ben

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

[Jean-Christophe PLAGNIOL-VILLARD]

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.

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

[Michael Schwingen]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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.
>   
I have one of these - the MII bus is forced to 100/FULL, and the switch 
configuration happens in the reset_phy function.
I could imagine some setup where the MII bus needs to be set to 
100/HALF, but probably only for PHYs that lack MDIO configuration and 
not for switches.

>> 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.
>   
Now I understand what you wanted. Lets just decide which way it whould 
be done for now (before we have the PHY library), so I can modify the 
patch accordingly.

For the general case, the code will need to pass the number of the 
ethernet port - there may be configurations with one MII connected to a 
switch with hardwired speed, and one MII connedted to a normal 
single-port PHY.

cu
Michael