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

[Bernd Walter]

On Fri, Nov 12, 2010 at 06:56:56PM +0100, Ulrich Prinz wrote:
> 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.

I've missed that point.
Those registers are basicly standardized so it should also be possible
to add some kind of generic PHY driver - at least as fallback.

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

As long as I can still read and write to all PHY addresses it can
still be hacked for special requirement.
Switches usually use multiple PHY addresses, also they only provide
a single virtual link.

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

Sounds good - so for the switch case I just add a PhyGetLink() delivering
fixed values.
I assume the PHY driver maintains pointer to the MACs MDIO functions?

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

I'm only aware of error counters within the MAC and not the PHY.
The switch case is different, since the switch checks ethernet CRC,
but I assume that's too specific, since the counters are for different
links.
But error counters can be very helpfull in some situations.


Another point, since you are already deep into the NIC drivers.
I would like to add multicast support and therefor I need a list of
IP (multicast and later unicast) addresses (as a list of IPv4 and
another list of IPv6 addreses).
I thought about a static compiletime sized list to simplify codesize.
Which are the propper structs to add those lists?
Those lists are identic for for all MACs and each MAC has it's own
routine to setup the propper filter hashes.
My intention is to get IPv6 running for obvious reasons.

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