Andrew Lunn <and...@lunn.ch> writes: >On Wed, May 27, 2020 at 03:41:22PM +0000, Amit Cohen wrote: >> Hi Andrew, >> >> We are planning to send a set that exposes link-down reason in ethtool. >> >> It seems that the ability of your set “Ethernet cable test support” >> can be integrated with link-down reason. >> >> >> >> The idea is to expose reason and subreason (if there is): >> >> $ ethtool ethX >> >> … >> >> Link detected: no (No cable) // No sub reason >> >> >> >> $ ethtool ethY >> >> Link detected: no (Autoneg failure, No partner detected) >> >> >> >> Currently we have reason “cable issue” and subreasons “unsupported >> cable” and “shorted cable”. >> >> The mechanism of cable test can be integrated and allow us report “cable >> issue” >> reason and “shorted cable” subreason. > >Hi Amit > >I don't really see them being combinable. First off, your API seems too >limiting. How do you say which pair is broken, or at what distance? What about >open cable, as opposed to shorted cable? > >So i would suggest: > >Link detected: no (cable issue) > >And then recommend the user uses ethtool --cable-test to get all the details, >and you have a much more flexible API to provide as much or as little >information as you have. > > Andrew
Thanks! Link-down reason has to consider cable-test or not? In order to report "cable issue", we assume that the driver implemented link-down reason in addition to cable-test? I'm asking about PHY driver for example that implemented cable-test and not link-down reason, so according to cable-test we should report "cable issue" as a link-down reason or do not expose reason here?
