[En-Nut-Discussion] detecting an unplugged network cable

[Bernd Walter]

On Thu, Nov 11, 2010 at 11:20:03PM +0100, Ulrich Prinz wrote:
> Hi!
> 
> Funny, I thought to open a new thread for some improvements on EMAC 
> handling :)
> 
> > I assume this can be handled much better in that the DHCP is retriggered
> > and just drop connections if - and only then - the host can't reestablish
> > the former IP, because if it loose it's IP the connections technically
> > can't be used anymore.
> 
> I thought about the problem a bit and have an opinion how to solve that 
> all a bit more elegant but without blowing up the code to much.
> 
> >
> > Ulrich is right that the PHY renegotiates the link and that the MAC
> > has to be reconfigured to the new negoatian, but I don't consider this
> > as a major problem unless the new link has different setup and I consider
> > almost all upstream ports today to be 100M/FDX cpable.
> >
> But if you ask the PHY for what features have negotiated for the MAC 
> setup you should ask the register of the actual established ones, not 
> the possible ones :)

That's basicly true - all I wanted to say is that the link speed/duplex
don't change that often in real world today.
Of course someone can reconnect an ethernut device from a 10M hub
to a 100M/FDX switch, but how likely is that?

> But to keep it simple:
> 
> I intend to add some NutEvents to the EMAC as this is something you 
> might use or you might not. The EMAC has three major events:
> 1) EmacFailEvent
> Posted at bootup, informs system about EMAC not ready to do anything.
> Posted again on errors in EMAC/PHY system caused by stack errors, 
> persistent disconnection and other big problems.
> 
> 2) EmacConnectEvent
> Posted if link is established, negotiated and ready for transmission.
> Reposted if recovering from 1) or 3)
> 
> 3) EmacDisconnectEvent
> Posted immediately if link failed.

If you think that's possible and work reliable.
AFAIK under FreeBSD the PHY gets polled for link state, but this might
have different reasons, because it is possible to connect multiple PHY
to one device, which naturally have different link states.
I'm currently a bit unsure about my SAM7X device using RTL8305SC.
The RTL8305SC is a switch using a pseudo-PHY interface and has a
slightly different signaling on MII, but I need to review the design.
The switch has 5 ports - 4 of them to the outer world.
It has different PHY IDs for each port, but none of them tell
anything about the link to the EMAC, which is nailed to 100/FDX.
Insteaxd of asking the PHY you need fixed values, but it still might
be interesting for an application to ask the link state of the
external ports, although they don't have any meaning for the EMAC.
Exporting the MDIO functions can be usefull in that case.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.