Question about MII (Media Independent Interface) in PHY

Question about MII (Media Independent Interface) in PHY
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.lans.ethernet  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Question about MII (Media Independent Interface) in PHY rf1ler 10-01-2007
Posted by on October 1, 2007, 9:04 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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


Pure Networks
Posted by on October 2, 2007, 10:33 am
If you were  Registered and logged in, you could reply and use other advanced thread options
On Oct 1, 9:04 pm, rf1...@shaw.ca wrote:
> 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.

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


Posted by Marris on October 3, 2007, 3:54 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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.

> 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
>



Posted by on October 3, 2007, 8:56 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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


Posted by Rich Seifert on October 4, 2007, 10:44 am
If you were  Registered and logged in, you could reply and use other advanced thread options
rf1ler@shaw.ca wrote:

> 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.
>

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

Similar ThreadsPosted
media independent interface June 6, 2006, 10:33 am
An interface on many VLANs November 24, 2005, 3:05 pm
vlan and interface September 10, 2008, 1:22 am
Interface cycles down-up, no STP TCN apparent January 9, 2008, 8:11 pm
Ethernet 802.3(csma/cd) with host interface March 31, 2005, 8:54 pm
Suggest a media converter? February 7, 2005, 11:00 am
autonegotiation and media converters August 23, 2005, 4:26 pm
Media converter vs Switch with Fiber port January 12, 2006, 1:04 am
Question regarding 802.1x March 2, 2005, 4:32 pm
A question for the NG November 28, 2006, 4:37 pm

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map