linux-kernel - Re: [PATCH] net: phy: phy_ethtool_ksettings

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: <Z03aPw_QgVYn8WyR@shell.armlinux.org.uk>
Date: Mon, 2 Dec 2024 16:03:11 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Nikita Yushchenko <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.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!