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