netdev - 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: <5d62cf99-c025-42f1-99db-f1f872d1650a@lunn.ch>
Date: Fri, 9 Aug 2024 16:00:53 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Oleksij Rempel <o.rempel@...gutronix.de>
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 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?

> 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* ? 

      Andrew