Re: [PATCH net-next v1 1/2] ethtool: provide UAPI for PHY Signal Quality Index (SQI)

On Tue, May 19, 2020 at 10:55:20AM +0200, Michal Kubecek wrote:

On Tue, May 19, 2020 at 09:51:59AM +0200, Oleksij Rempel wrote:

quoted

Signal Quality Index is a mandatory value required by "OPEN Alliance
SIG" for the 100Base-T1 PHYs [1]. This indicator can be used for cable
integrity diagnostic and investigating other noise sources and
implement by at least two vendors: NXP[2] and TI[3].

[1] http://www.opensig.org/download/document/218/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf
[2] https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf
[3] https://www.ti.com/product/DP83TC811R-Q1

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
 Documentation/networking/ethtool-netlink.rst |  1 +
 include/linux/phy.h                          |  1 +
 include/uapi/linux/ethtool.h                 | 11 +++++++++
 include/uapi/linux/ethtool_netlink.h         |  1 +
 net/ethtool/common.c                         | 10 ++++++++
 net/ethtool/common.h                         |  1 +
 net/ethtool/linkstate.c                      | 25 +++++++++++++++++++-
 7 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
index eed46b6aa07df..4485e622182fc 100644
--- a/Documentation/networking/ethtool-netlink.rst
+++ b/Documentation/networking/ethtool-netlink.rst

@@ -457,6 +457,7 @@ Kernel response contents:
   ====================================  ======  ==========================
   ``ETHTOOL_A_LINKSTATE_HEADER``        nested  reply header
   ``ETHTOOL_A_LINKSTATE_LINK``          bool    link state (up/down)
+  ``ETHTOOL_A_LINKSTATE_SQI``           u8      Current Signal Quality Index
   ====================================  ======  ==========================
 
 For most NIC drivers, the value of ``ETHTOOL_A_LINKSTATE_LINK`` returns

IIRC you need to update table markers (the "===" lines) so that cell
text does not overflow. Did you check it with "make htmldocs"?

yes. Seems to look OK.

quoted

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 59344db43fcb1..b2fd230460d77 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h

@@ -706,6 +706,7 @@ struct phy_driver {
 			    struct ethtool_tunable *tuna,
 			    const void *data);
 	int (*set_loopback)(struct phy_device *dev, bool enable);
+	int (*get_sqi)(struct phy_device *dev);
 };
 #define to_phy_driver(d) container_of(to_mdio_common_driver(d),		\
 				      struct phy_driver, mdiodrv)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f4662b3a9e1ef..e55caacd1886c 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h

@@ -1678,6 +1678,17 @@ static inline int ethtool_validate_duplex(__u8 duplex)
 #define MASTER_SLAVE_STATE_SLAVE		3
 #define MASTER_SLAVE_STATE_ERR			4
 
+#define SQI_STATE_UNSUPPORTED			0
+#define SQI_STATE_0				1
+#define SQI_STATE_1				2
+#define SQI_STATE_2				3
+#define SQI_STATE_3				4
+#define SQI_STATE_4				5
+#define SQI_STATE_5				6
+#define SQI_STATE_6				7
+#define SQI_STATE_7				8
+#define SQI_STATE_8				9
+
 /* Which connector port. */
 #define PORT_TP			0x00
 #define PORT_AUI		0x01

The shift by one between actual SQI values and attribute values is IMHO
quite confusing for anyone looking at the messages. As the UNSUPPORTED
value is only internal (the attribute is omitted in reply message in
such case), perhaps we could use int for linkstate_reply_data::sqi and
e.g. -1 for "unsupported". Then we could use native 0-7 range

OK

(SQI_STATE_8=9 is probably a mistake).

yes.

I'm also a bit worried about hardcoding the 0-7 value range. While I
understand that it's defined by standard for 100base-T1, we my want to
provide such information for other devices in the future. I tried to
search if there is something like that for 1000base-T1 and found this:

  http://www.sigent.cn/wp-content/uploads/2019/12/TE-1400_User-Manual_1000BASE-T1-EMC-Converter_v3.3.pdf

The screenshot on page 10 shows "SQI Value: 00015".

Nice, screenshot based reverse engineering :)

It's probably not
standardized (yet?) but it seems to indicate we may expect other devices
providing SQI information with different value range.

what maximal range do we wont to export? u8, u16 or u32?

Would it make sense to add ETHTOOL_A_LINKSTATE_SQI_MAX attribute telling
userspace what the range is?

sounds plausible.

[...]

quoted

diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index 423e640e3876d..f3c905e59124f 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c

@@ -310,6 +310,16 @@ int __ethtool_get_link(struct net_device *dev)
 	return netif_running(dev) && dev->ethtool_ops->get_link(dev);
 }
 
+int __ethtool_get_sqi(struct net_device *dev)
+{
+	struct phy_device *phydev = dev->phydev;
+
+	if (!phydev->drv->get_sqi)

You should check phydev for NULL first.

ok.

Michal

quoted

+		return -EOPNOTSUPP;
+
+	return phydev->drv->get_sqi(phydev);
+}
+
 int ethtool_get_max_rxfh_channel(struct net_device *dev, u32 *max)
 {
 	u32 dev_size, current_max = 0;

Regards,
Oleksij

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |