1. Home
  2. Ethernet LAN
  3. Question about MII (Media Independent Interface) in PHY

Question about MII (Media Independent Interface) in PHY

Hi,

I've implemented an Ethernet driver based upon some example code we received from a parts vendor. This driver is running in a small embedded system - a DHCP server of sorts. The example code we received essentially blocked the world from starting up until someone inserted an RJ-45 cable - something which, in our product, is not a guarantee. The main reason for the block is that the example code sits around waiting for an MII negotiation to complete with some peer device on the LAN, e.g. Hub, switch, etc.

Our system cannot block waiting for a cable, so I removed the code that performs the MII negotiation and so far everything is working just fine. Our PHY chip is a broadcom part and I carefully compared the default register settings with the values that were loaded into them after the MII negotiation was complete. They were practically identical, so no big problem and I've never see our ethernet connection fail to come up and allocate IP addresses to a client (via DHCP).

The question is, does anyone out there know if there are any pitfalls waiting for me by not allowing the MII negotiation to complete? I'm also wondering whether the DHCP client device (e.g. laptop) will perform its own MII negotiation and learn our settings. I haven't been able to discover the rules for what peer must initiate the negotiation

- I'm guessing both do.

Regards

RealTimer

Reply to
rf1ler
Loading thread data ...

I'm not familiar with Broadcom's PHY specifically, but....

MII is an interface between the Ethernet controller and the PHY. So it doesn't involve any negotiation. The negotiation is between the two PHYs. The operation of the negotiation is controlled by registers set over the MII interface. For example, should the PHY advertise support for full duplex operation to the peer? However, for every PHY I've worked with, operation over the MII interface during the actual negotiation is not required.

It is common for the PHY to generate an interrupt back to the Ethernet controller to tell it when something related to the status on the wire has changed (eg, link up or auto negotiation complete) although an interrupt line is not strictly required for MII operation. This allows the driver and upper stack to take action when the wire is plugged in rather than waiting for it.

Regards, Steve

Reply to
steve_schefter

Your question is really about auto-negotiation (AN) rather than MII.

The two things that AN determines are speed and full/half-duplex. If these end up being different at either side of the link then you will problems.

If you disable AN it is possible that the link partner will do something called parallel detect and adjust itself to match your capabilities. However what you are doing has risks and puts the burden of bringing the link up correctly on the partner device.

Reply to
Marris

Hi

Thank you both for your replies; I was pretty casual with my use of terminology, but yes, it was the Autonegotiation that I was wondering about. In the example code we got, it is the MII package that is running the autonegotiation, and that only starts up when the PHY chip has detected a peer out there.

Marris confirms my suspicion that our solution won't work in all cases, depending upon the peer device in the network. Your reference to Parallel Detect is interesting; it implies that one side, not both, is responsible for kicking off the autonegotiation. I had been hoping that the process was defined so that both sides could initiate autonegotiation; that way, if one of the devices didn't start it off, the other side would kick in and do it - a kind of redundancy.

Nevertheless, Steve points out that there is often an interrupt available - something I have yet to confirm for our PHY chip - which we could use to detect when to perform the autonegotiation if/when a peer device eventually connects.

So I think I have enough information to proceed with a better solution than the one I've already got.

Thanks again for your replies!

RealTimer

Reply to
rf1ler

Auto-Negotiation is indeed fully symmetric; if both partners have AN capability, they will both initiate AN and come to an agreement on operating parameters. Parallel detection comes in when one partner has AN, but the other does not. The AN device will notice that the other device is not performing AN; the other device may have a single-speed-capable interface that has nothing to "negotiate" (e.g., a legacy 10BASE-T device). In this case, the AN device will try to determine the speed and coding being used by the non-AN partner; if the AN device has a capability that matches the non-AN's transmission, it will adopt the same scheme and proceed to network operation.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Again, speaking about PHYs I've used and not yours specifically: The interrupt is used to report when something has changed, such as link up, auto-negotiation complete, etc. Exactly what results in an interrupt depends on what interrupt enable bits are set in the PHY control registers.

So it's there to tell you something has completed, not to actually do that something. If configured appropriately, the PHY will do autonegotiation on its own and the interrupt will just tell you that it's complete so that you can read status registers and learn what got negotiated (so that you can print a status or otherwise pass on the report). If you don't read the registers, the same thing gets negotiated, you just don't know what that was.

Steve

Reply to
steve_schefter

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.