[<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 |
Powered by blists - more mailing lists