linux-kernel - Re: [PATCH net-next v2 2/3] phy: Add Open Alliance helpers for the PHY framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZrcLpXS5dd_rZq6F@pengutronix.de>
Date: Sat, 10 Aug 2024 08:41:41 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/3] phy: Add Open Alliance helpers for the
 PHY framework

On Fri, Aug 09, 2024 at 04:00:53PM +0200, Andrew Lunn wrote:
> On Fri, Aug 09, 2024 at 07:17:50AM +0200, Oleksij Rempel wrote:
> > On Thu, Aug 08, 2024 at 03:54:06PM +0200, Andrew Lunn wrote:
> > 
> > > Please could you give a reference to the exact standard. I think this
> > > is "Advanced diagnostic features for 1000BASE-T1 automotive Ethernet
> > > PHYs TC12 - advanced PHY features" ?
> > > 
> > > The standard seem open, so you could include a URL:
> > > 
> > > https://opensig.org/wp-content/uploads/2024/03/Advanced_PHY_features_for_automotive_Ethernet_v2.0_fin.pdf
> > 
> > I already started to implement other diagnostic features supported by the
> > TI DP83TG720 PHY. For example following can be implemented too:
> > 6.3 Link quality – start-up time and link losses (LQ)
> > 6.3.1 Link training time (LTT)
> > 6.3.2 Local receiver time (LRT)
> > 6.3.3 Remote receiver time (RRT)
> 
> These three are the time it takes for some action. Not really a
> statistic in the normal netdev sense, since it does not count up. But
> they are kind of statistics, so it is probably not abusing statistics
> too much, so maybe O.K.
> 
> > 6.3.4 Link Failures and Losses (LFL)
> 
> This is a count, so does fit statistics. 
> 
> > 6.3.5 Communication ready status (COM)
> 
> Similar to the BMSR link bit. Do it add anything useful?

Probably. I can leave it for now

> > 6.4 Polarity Detection and Correction (POL)
> > 6.4.1 Polarity Detection (DET)
> > 6.4.2 Polarity Correction (COR)
> 
> Could these be mapped to ETH_TP_MDI* ? 

Yes, but it will look confusing in the user space. To make better
representation in ethtool we will probably need a new port type. For
example instead of PORT_TP it will be PORT_STP (single twiste pair) or
PORT_SPE (single pair ethernet). What do you think?

Beside, there are some not standard specific fail indicators. It can show RGMII
and SGMII specific errors. For example R/S_GMII FIFO full/empty errors. If
i see it correctly, it will not drop MDI link, so I won't be able to
return a link fail reason for this case.

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 |