[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1v4t2yn.fsf@mellanox.com>
Date: Thu, 28 May 2020 18:54:24 +0200
From: Petr Machata <petrm@...lanox.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Amit Cohen <amitc@...lanox.com>, mlxsw <mlxsw@...lanox.com>,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
"o.rempel\@pengutronix.de" <o.rempel@...gutronix.de>
Subject: Re: Link down reasons
Andrew Lunn <andrew@...n.ch> writes:
>> Andrew, pardon my ignorance in these matters, can a PHY driver in
>> general determine that the issue is with the cable, even without running
>> the fairly expensive cable test?
>
> No. To diagnose a problem, you need the link to be idle. If the link
> peer is sending frames, they interfere with TDR. So all the cable
> testing i've seen first manipulates the auto-negotiation to make the
> link peer go quiet. That takes 1 1/2 seconds. There are some
> optimizations possible, e.g. if the cable is so broken it never
> establishes link, you can skip this. But Ethernet tends to be robust,
> it drops back to 100Mbps only using two pairs if one of the four pairs
> is broken, for example.
OK, thanks. I suspect our FW is doing this behind the scenes, because it
can report a shorted cable.
In another e-mail you suggested this:
Link detected: no (cable issue)
But if the link just silently falls back to 100Mbps, there would never
be an opportunity for phy to actually report a down reason. So there
probably is no way for the phy layer to make use of this particular
down reason.
Powered by blists - more mailing lists