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 for Android: free password hash cracker in your pocket
[<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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ