netdev - Re: [net-next RFC PATCH 0/3] net: phy: detach PHY driver OPs from phy

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]

Date: Sat, 17 Feb 2024 19:53:08 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Michael Hennerich <michael.hennerich@...log.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>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Ray Jui <rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>,
	Richard Cochran <richardcochran@...il.com>,
	Marek Behún <kabel@...nel.org>,
	Daniel Golle <daniel@...rotopia.org>,
	Qingfang Deng <dqfext@...il.com>,
	SkyLake Huang <SkyLake.Huang@...iatek.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Kevin Hilman <khilman@...libre.com>,
	Jerome Brunet <jbrunet@...libre.com>,
	Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
	Arun Ramadoss <arun.ramadoss@...rochip.com>,
	UNGLinuxDriver@...rochip.com, Peter Geis <pgwipeout@...il.com>,
	Frank <Frank.Sae@...or-comm.com>, Xu Liang <lxu@...linear.com>,
	Piergiorgio Beruto <piergiorgio.beruto@...il.com>,
	Andrei Botila <andrei.botila@....nxp.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Michal Simek <michal.simek@....com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Robert Marko <robimarko@...il.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	David Epping <david.epping@...singlinkelectronics.com>,
	Harini Katakam <harini.katakam@....com>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-amlogic@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, rust-for-linux@...r.kernel.org,
	linux-mediatek@...ts.infradead.org
Subject: Re: [net-next RFC PATCH 0/3] net: phy: detach PHY driver OPs from
 phy_driver struct

On Sat, Feb 17, 2024 at 08:41:11PM +0100, Christian Marangi wrote:
> Posting as RFC due to the massive change to a fundamental struct.
> 
> While adding some PHY ID for Aquantia, I notice that there is a
> big problem with duplicating OPs with each PHY.
> 
> The original idea to prevent this was to use mask on the PHY ID
> and identify PHY Family. Problem is that OEM started to use all
> kind of PHY ID and this is not doable, hence for PHY that have
> the same OPs, we have to duplicate all of them.
> 
> This is present in Aquantia PHY, but is much more present in
> other PHY, especially in the BCM7XXX where they use a big macro
> for common PHYs.
> 
> To reduce patch delta, I added the additional variable without
> adding tabs as this would have resulted in a massive patch.
> Also to have patch bisectable, this change has to be in one go
> hence I had to use this trick to reduce patch delta.
> 
> Other solution to this problem were to introduce additional
> variables to phy_driver struct but that would have resulted
> in having 2 different way to do the same thing and that is not O.K.
> 
> I took care to compile-test all the PHY, only exception is the unique
> RUST driver, where I still have to learn that funny language and
> I didn't had time to update it, so that is the only driver that
> I think require some fixup.
> 
> I posted 2 example that would benefits from this change, but I can
> find much more in other PHY driver.

Would it make more sense instead of this big churn, to instead
introduce into struct phy_driver:

	struct mdio_device_id	*ids;

which would then allow a phy_driver structure to be matched by
several device IDs?

We then would not need to touch any of the existing drivers initially,
and a later cleanup could be to identify those where all the ops are
the same for several phy_driver structures, and convert them over.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!