[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8106d02-e3b0-4f23-8c76-52840493dff2@lunn.ch>
Date: Sun, 18 Feb 2024 00:48:24 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Christian Marangi <ansuelsmth@...il.com>
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
> 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.
Yes, the problem is, it probably needs another 50 patches to remove
all the duplication. I have to question, is that really going to
happen? Are you going to keep working on this until every driver has
its duplicates removed?
It probably needs some tooling to help. Something which can decode the
object file, and tell you which ops structures are identical. That can
then guide you when editing all the PHY drivers.
Andrew
Powered by blists - more mailing lists