[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200607153034.GC1022955@lunn.ch>
Date: Sun, 7 Jun 2020 17:30:34 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Amit Cohen <amitc@...lanox.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
corbet@....net, jiri@...lanox.com, idosch@...lanox.com,
shuah@...nel.org, mkubecek@...e.cz, gustavo@...eddedor.com,
cforno12@...ux.vnet.ibm.com, f.fainelli@...il.com,
linux@...pel-privat.de, alexandru.ardelean@...log.com,
ayal@...lanox.com, petrm@...lanox.com, mlxsw@...lanox.com,
liuhangbin@...il.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH net-next 04/10] ethtool: Add link extended state
> +/**
> + * enum ethtool_ext_substate_cable_issue - more information in
> + * addition to ETHTOOL_EXT_STATE_CABLE_ISSUE.
> + */
> +enum ethtool_ext_substate_cable_issue {
> + ETHTOOL_EXT_SUBSTATE_UNSUPPORTED_CABLE = 1,
> + ETHTOOL_EXT_SUBSTATE_SHORTED_CABLE,
> +};
I'm not too happy about shorted cable. I can see this getting extended
to open cable, shorted to another pair, etc. It then becomes a
duplicate of the PHY cable testing infrastructure. A more generic
> + ETHTOOL_EXT_SUBSTATE_CABLE_TEST_FAILURE,
would be better, and then the user can use then use the cable testing
infrastructure to get the full details.
Andrew
Powered by blists - more mailing lists