Paul Durrant wrote: > Steven Stallion wrote: >> mac.h >> ----- >> >> I added an enum for link_speed_t; this was made since we already >> maintain the link_duplex_t and link_state_t. link_speed_t is very useful >> when setting a specific speed via MII. >> >> The IFSPEED macro was added as an afterthought; I find it generally >> annoying that the ifspeed kstat typically is reported using a magic >> multiple (1000000). *val = IFSPEED(foop->speed) is much clearer than >> *val = foop->speed * 1000000. >> >> mac_ether.h >> ----------- >> >> This contains the bulk of the changes. I've added what I thought the >> minimal MII/GMII interface should be. There are of course a number of >> features supported by MII which probably arent useful in the day-to-day >> (i.e. collision test, loopback, and so forth). >> > > Do the mii)read/mii_write entry point names make sense? There don't seem > to be enough arguments. The interface across which you talk to a > MII/GMII PHY is usually clause 22 MDIO (and a driver could make it look > like this even if it isn't), so you need function prototypes taking a > context, a register offset and then a data buffer to read into or write > from. For clause 22 the register space is 8 bits wide and the data 16 > bits wide. Also, I'd call them mdio22_read/mdio22_write to make it clear > what their purpose is.
My only exposure to dealing with MII is with the original mii module and the 2002 edition of 802.3 (basically, I have _no_ knowledge at all about XGMII). The gist of the entry points was that when the MII bits needed to read from the MII registers, it would result in a call to mii_read. (There probably needs to be more context than the driver private structure). mii_register_t is a typedef to a uint32_t *, so the idea was that a sufficiently large buffer (mii_register_t *, or uint32_t **) would be passed via the entry point for the driver to write too (likely from a PIO register). I had wanted to hide any PIO/MDIO type behavior from the MII guts as much as possible. I believe the existing mii module follows similar behavior. The register offset may make more sense; It does not make sense to request the entire register set since that can be of a fairly good size on each call, especially for GMII and beyond (MII only isnt as big of a deal since there would only be control and status passed back). It's also better from the standpoint that the driver simply has to provide access to the information, not decide how much to provide (i.e. the status register should indicate if extended registers are available). > Once you get to PHYs talking XGMII or XFI you're likely to need clause > 45 MDIO and that requires an extra 'MMD' argument, which is 8 bits wide, > and the register space increases to 16 bits wide. > > Also, since the MII/GMII register space is an IEEE standard I'd prefer > to see enumerations for the register offsets. As for 10G PHYs, each MMD > has an IEEE register space (< 0x8000) and a vendor specific register > space (>= 0x8000) so you could also partially enumerate those. > > Do you have implementations for the mii functions you have? Also be > aware that not all link modes available through a given PHY will be > supported by the MAC it is attached to (e.g. 1G half-duplex, which is > not required by the IEEE IIRC) so you need to make sure the driver can > veto things appropriately. Not completely. Right now most of what I have is bootstrap code and initializing mii_handle_t. I was wanting to have a better defined interface before focusing on the actual implementation. As far as veto goes, I was going to follow the IEEE spec and honor the status register and use the selection rules provided for the best possible link. -- Yet magic and hierarchy arise from the same source, and this source has a null pointer. Reference the NULL within NULL, it is the gateway to all wizardry. _______________________________________________ networking-discuss mailing list [email protected]
