[U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x
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, ®_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 +
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, ®_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.
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
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
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.
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
participants (4)
-
Ben Warren -
Jean-Christophe PLAGNIOL-VILLARD -
Michael Schwingen -
rincewind＠discworld.dascon.de