All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Machata <petrm@mellanox.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Amit Cohen <amitc@mellanox.com>, mlxsw <mlxsw@mellanox.com>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"o.rempel\@pengutronix.de" <o.rempel@pengutronix.de>
Subject: Re: Link down reasons
Date: Thu, 28 May 2020 18:54:24 +0200	[thread overview]
Message-ID: <87r1v4t2yn.fsf@mellanox.com> (raw)
In-Reply-To: <20200528154010.GD840827@lunn.ch>


Andrew Lunn <andrew@lunn.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.

  reply	other threads:[~2020-05-28 16:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AM0PR0502MB38261D4F4F7A3BB5E0FDCD10D7B10@AM0PR0502MB3826.eurprd05.prod.outlook.com>
2020-05-27 21:38 ` Link down reasons Andrew Lunn
2020-05-28  5:56   ` Amit Cohen
2020-05-28  9:12     ` Petr Machata
2020-05-28 15:40       ` Andrew Lunn
2020-05-28 16:54         ` Petr Machata [this message]
2020-05-28 17:17           ` Michal Kubecek
2020-05-28 18:37           ` Andrew Lunn
2020-05-29  9:03             ` Petr Machata
2020-05-28  8:40 ` Oleksij Rempel
2020-05-28  9:22   ` Petr Machata
2020-05-28 10:28     ` Oleksij Rempel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1v4t2yn.fsf@mellanox.com \
    --to=petrm@mellanox.com \
    --cc=amitc@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=mlxsw@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.