Message-ID:
 <TYCPR01MB1047854DA050E52CADB04393A8E362@TYCPR01MB10478.jpnprd01.prod.outlook.com>
Date: Tue, 3 Dec 2024 14:05:07 +0000
From: Dennis Ostermann <dennis.ostermann@...esas.com>
To: Russell King <linux@...linux.org.uk>, nikita.yoush
	<nikita.yoush@...entembedded.com>
CC: Maxime Chevallier <maxime.chevallier@...tlin.com>, Andrew Lunn
	<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Michael Dege <michael.dege@...esas.com>,
	Christian Mardmoeller <christian.mardmoeller@...esas.com>
Subject: RE: [PATCH] net: phy: phy_ethtool_ksettings_set: Allow any supported
 speed

Hi,

according to IEE 802.3-2022, ch. 125.2.4.3, Auto-Negotiation is optional for 2.5GBASE-T1

> 125.2.4.3 Auto-Negotiation, type single differential-pair media
> Auto-Negotiation (Clause 98) may be used by 2.5GBASE-T1 and 5GBASE-T1 devices to detect the
> abilities (modes of operation) supported by the device at the other end of a link segment, determine common
> abilities, and configure for joint operation. Auto-Negotiation is performed upon link startup through the use
> of half-duplex differential Manchester encoding.
> The use of Clause 98 Auto-Negotiation is optional for 2.5GBASE-T1 and 5GBASE-T1 PHYs

So, purposed change could make sense for T1 PHYs.

BR
Dennis Ostermann

> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: Monday, December 2, 2024 5:03 PM
> To: nikita.yoush <nikita.yoush@...entembedded.com>
> Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>; Andrew Lunn
> <andrew@...n.ch>; Heiner Kallweit <hkallweit1@...il.com>; David S. Miller
> <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski
> <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Michael Dege
> <michael.dege@...esas.com>; Christian Mardmoeller
> <christian.mardmoeller@...esas.com>; Dennis Ostermann
> <dennis.ostermann@...esas.com>
> Subject: Re: [PATCH] net: phy: phy_ethtool_ksettings_set: Allow any
> supported speed
>
> On Mon, Dec 02, 2024 at 08:51:44PM +0500, Nikita Yushchenko wrote:
> > > > root@...-033:~# ethtool tsn0
> > > > Settings for tsn0:
> > > >          Supported ports: [ MII ]
> > > >          Supported link modes:   2500baseT/Full
> > > >          Supported pause frame use: Symmetric Receive-only
> > > >          Supports auto-negotiation: No
> > >
> > > Okay, the PHY can apparently only operate in fixed mode, although I
> > > would suggest checking that is actually the case. I suspect that may
> > > be a driver bug, especially as...
> >
> > My contacts from Renesas say that this PHY chip is an engineering
> sample.
> >
> > I'm not sure about the origin of "driver" for this. I did not look
> inside
> > before, but now I did, and it is almost completely a stub. Even no init
> > sequence. The only hw operations that this stub does are
> > (1) reading bit 0 of register 1.0901 and returning it as link status
> (phydev->link),
> > (2) reading bit 0 of register 1.0000 and returning it as master/slave
> > setting (phydev->master_slave_get / phydev->master_slave_state)
> > (3) applying phydev->master_slave_set via writing to bit 0 of register
> > 1.0000 and then writing 0x200 to register 7.0200
> >
> > Per standard, writing 0x200 to 7.0200 is autoneg restart, however bit 0
> of
> > 1.0000 has nothing to do with master/slave. So what device actually does
> is
> > unclear. Just a black box that provides 2.5G Base-T1 signalling, and
> > software-wise can only report link and accept master-slave
> configuration.
> >
> > Not sure if supporting this sort of black box worths kernel changes.
> >
> >
> > > it changes phydev->duplex, which is _not_ supposed to happen if
> > > negotiation has been disabled.
> >
> > There are no writes to phydev->duplex inside the "driver".
> > Something in the phy core is changing it.
>
> Maybe it's calling phylib functions? Shrug, I'm losing interest in this
> problem without seeing the driver code. There's just too much unknown
> here.
>
> It's not so much about what the driver does with the hardware. We have
> some T1 library functions. We don't know which are being used (if any).
>
> Phylib won't randomly change phydev->duplex unless a library function
> that e.g. reads status from the PHY does it.
>
> As I say, need to see the code. Otherwise... sorry, I'm no longer
> interested in your problem.
>
> --
> RMK's Patch system:
> https://www.arml/
> inux.org.uk%2Fdeveloper%2Fpatches%2F&data=05%7C02%7Cdennis.ostermann%40ren
> esas.com%7Cbfa991c0ba974db7c9ea08dd12eadd3d%7C53d82571da1947e49cb4625a166a
> 4a2a%7C0%7C0%7C638687522161126854%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=EBEG33bbhh3A7DQMfoVJNOXeGyJsQ%2FaVk8xjS8DK17s%3D&res
> erved=0
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
________________________________

Renesas Electronics Europe GmbH
Registered Office: Arcadiastrasse 10
DE-40472 Duesseldorf
Commercial Registry: Duesseldorf, HRB 3708
Managing Director: Carsten Jauch
VAT-No.: DE 14978647
Tax-ID-No: 105/5839/1793

Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

Powered by blists - more mailing lists