Differential D59188
mdio: Add new mdio FDT driver Authored by jhibbits on Wed, Aug 26, 3:01 AM. Tags None Referenced Files
Details Add a new MDIO FDT driver to get the benefits of the OFW node This is opt-in, so any parent driver that wants to use it must
Diff Detail
Event TimelineComment Actions How does this correspond with the MII bus? Shouldn't we combine these two drivers into one? The MDIO bus can have real devices (PHY, switch) and/or emulated, synthetic ones (fixed-link) attached. How do you want to handle communication in these cases? Comment Actions @mmel this new driver is effectively the mii_fdt.c equivalent on the mdio side. From a physical perspective, my understanding is mdio is the low-level serial interface that can connect "anything", while MII is the higher level bus intended for PHYs, so MII "sits on top of" MDIO in reality, and they're separate entities in our driver architecture. Looking at the git log, mdio was pulled out of the etherswitch driver a decade ago by @adrian to support other MDIO-based devices that don't need all the MII plumbing. Comment Actions I see all this, but I'm not able to understand how it should work. Let's assume the most common situation: a standard NIC driver with an attached random switch chip. The NIC driver exposes the MII bus and its access methods. It also expects to have a PHY (real hardware or emulated fixed) to get speed, duplex, etc. But question is how you can connect this to the MDIO bus? That is the root of my question, as I am already searching for the right method to connect any existing NIC driver to any ether switch machinery (i.e. any existing switch driver) using DT properties (i.e. the MDIO bus). But I don't see how the MDIO driver (FDT or not) can work in this situation. imho, in an ideal world, MII should be a subclass of MDIO, and we should use MII in all these places. Have I missed something important? Comment Actions Will go a different route--move this functionality into fman_xmdio instead per @mmel. |