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

[Ulrich Prinz]

Hi!
>>>
>> 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?
>
You're right, but the code that requests link information from the PHY 
and sets up the EMAC is already in, it only requests the information 
from the wrong regoster of the PHY. And it is most likely a two-liner to 
do it correctly instead of doing it not.

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

That is right, but I will limit that to one. If you need dozens of PHYs 
(up to 32 are possible) you need someone managing that and for that 
Nut/OS was not intended.

> 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.
>
The PHY driver will be separated from the (E)MAC driver in the new 
design. With a single PHY driver over 90% of all PHYs are covered 
without any extra code. The PHY driver will rely on two function 
pointers provided by the MAC driver, the phy_inw() and the phy_outw().

The (E)MAC driver has to first set up the EMAC basics, GPIO/Peirpheral 
Ports and then calls the PhyInit( addr, &phy_inw, &phy_outw) while addr 
is the PHY address on the MDIO bus.

With this all basic situations are handled. Any emac driver can still 
initialize a PHY by GPIO and Reset toggle as the at91_emac is doing it. 
It also can prepend some special handling for unusual things.
In most of the systems, nothing is to do but calling PhyGetLink() or 
PhyGetStatus() or in some conditions PhySetLink() or even 
PhySetRegister() or something similar can be done.

To not blow up the code, standard support for PHY is enabled and any 
extra things for special PHYs can be enabled by nutconf if thus things 
are needed.
I think about enabling access to the real error packet counters from the 
PHY for hardware failure analysis if I design my own Ethernet AddOn 
board for the STM32 series. But that can be enabled optionally.

So how about that idea?

Best regards
Ulrich

Ps: If I don't answer this weekend, I am moving with my hobby room to 
another room of the house. Just continue sending ideas, I catch up later.