[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65d140fb.5d0a0220.81be3.7138@mx.google.com>
Date: Sun, 18 Feb 2024 00:27:53 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Michael Hennerich <michael.hennerich@...log.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"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>,
"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
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 11:21:44PM +0100, Andrew Lunn wrote:
> 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.
>
> To me, this makes the code look ugly. I also expect many text editors
> which understand indentation will be unhappy, saying the indentation is
> wrong.
>
Yes, it was done to limit the patch delta, if I had to account for the
tab for each new section we would be in the order of 2000+ changes I
think.
> > 64 files changed, 737 insertions(+), 291 deletions(-)
>
> These statistics are not good. If you had deleted more lines than you
> added, then maybe it might be an O.K. idea.
>
> Sometimes KISS is best.
>
Well IMHO these stats are a bit flawed, the additional code is really
just extra check if ops is defined and the new .ops variable in each
phy_driver.
If you check patch 2 and 3 you can already see some code is removed.
Also while minimal the final .o produced results in bcm7xxx going from
53kb to 45kb and the aquantia driver from 48kb to 45kb.
I understand that this major rework might be too much, so I think the
only way to handle this is with introducing support for declaring
multiple PHY ID for one phy_driver struct.
--
Ansuel
Powered by blists - more mailing lists