The "Phy" interface is supplied by a different chip than the ethernet controller. This chip may be different (and often is) on each different board using the Zynq. If we intend to support other boards someday (and we do) it would pay off to give some thought to being able to accomodate different Phy chips easily.
Several terms (acronyms) pop up in a confusing way when talking about these chips. Other than "phy" itself, the most common are "mii" and "mdio".
The term "mii" (media independent interface) has to do with the electrical connections between the controller and the phy chip. The software driver author doesn't need to know much if anything about this. There are 4 signals for Rx data, 4 signals for Tx data, and 2 signals for "mdio". The mdio signals are a clock and data, so it is a serial scheme.
There is also "rmii" which is "reduced mii". The clock for mii is 25 Mhz, but for rmii it is 50 Mhz. The reduced aspect of things is less signals on the circuit board.
Once everything gets set up the Tx and Rx paths "just work" and never get dealt with directly by software. The mdio signals are used to set everything up and are what we are concerned with here. They boil down to housekeeping. The ethernet controller has a section that deals with these, and naturally each ethernet chip has its own registers and interface to deal with it.
The term "mdio" stands for "Management Data Input/Output". It is define in IEEE 802.3 - specifically Clause 22 and Clause 45. The basic idea is that there are a bunch of registers that you read and write to set up and monitor the phy chip. A nice chip will use only the standard registers, but naturally each chip tends to add a few special vendor specific registers, and that is why you go looking for the data sheet.
The kinds of things you do mostly take place at initialization. You indicate what speeds and duplex you are willing to work with, you setup autonegotiation and monitor the result of it. You may later get an mdio interrupt that lets you know that somebody disconnected the cable (or reconnected it) and such.
Decent software needs at least two layers. One is an IO layer that deals with whatever registers the ethernet controller presents to access mdio. Once you have that you can have a more generic layer that does standard setup. There may also be unique features of each Phy chip that need to be supported.
If you are writing, one write access does it all, selecting the register and providing 16 bits of data. If you are reading, you first do a write to specify what you want to read (and that you want to read), then follow it up with a read to get the data.
Well, actually a second register (the status register) gets involved. After a write, you poll a bit (likely with a timeout) to find out when your transaction is complete.
This register has a bit that "must be 1" for Clause 22 operation, otherwise things happen via Clause 45. You are instructed to check your Phy datasheet to find out which it will be happy with.
The U-Boot driver seems to set the bit indicating Clause 22, and the general description above fits with that. Clause 45 was introduced with the advent of 10 Gigabit devices and we won't say more about it.
With clause 22 we can have 32 registers in 32 different Phy devices (i.e. we have 5 bits allocated for each).
Tom's Computer Info / tom@mmto.org