linux-kernel - Re: [PATCH net v4 2/2] net: phy: aquantia: remove usage of phy_set_max

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: <262e7702-68aa-40c9-aa2a-60a18b7f747d@lunn.ch>
Date: Mon, 30 Sep 2024 14:18:26 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	"Abhishek Chauhan (ABC)" <quic_abchauha@...cinc.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,
	Andrew Halaney <ahalaney@...hat.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Brad Griffis <bgriffis@...dia.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Jon Hunter <jonathanh@...dia.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>, kernel@...cinc.com
Subject: Re: [PATCH net v4 2/2] net: phy: aquantia: remove usage of
 phy_set_max_speed

> I think this is getting overly complex, so let's rewind a bit.
> 
> I believe Abhishek mentioned in a previous review what the differences
> are between what the PHY reports when read, and what it actually
> supports, and the result was that there was not a single bit in the
> supported mask that was correct. I was hopeful that maybe Andrew would
> respond to that, but seems not to, so I'm putting this statement here.
> More on this below.

Yes, i did not really realise how wrong Marvell got this. As you point
out, it is more wrong than right.

My thinking with calling the usual feature discovery mechanism and
then fixing them up, is that we keep extending them. BaseT1 has been
added etc. If a PHY is mostly getting it right, we might in the future
get new features implemented for free, if the hardware correctly
declares them. But in this case, if it cannot get even the basics
mostly correct, there is little hope it will get more exotic features
correct.

So, i agree in Russell. Forget about asking the hardware, just hard
code the correct features.

Sorry for making you do extra work which you now need to discard.

However, please do keep it as two patches. It makes it easier to deal
with regressions on the device you cannot test if we can just revert
one patch.

	Andrew