[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5a4e735-7b24-4933-b431-f36305689a79@lunn.ch>
Date: Wed, 5 Apr 2023 18:06:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: 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 <f.fainelli@...il.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Richard Cochran <richardcochran@...il.com>,
Radu Pirea <radu-nicolae.pirea@....nxp.com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Jassi Brar <jaswinder.singh@...aro.org>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Iyappan Subramanian <iyappan@...amperecomputing.com>,
Keyur Chudgar <keyur@...amperecomputing.com>,
Quan Nguyen <quan@...amperecomputing.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
devicetree@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH 06/12] net: phy: add phy_device_atomic_register helper
> The current fwnode_mdio.c don't provide the proper helper functions yet.
> Instead the parsing is spread between fwnode_mdiobus_register_phy() and
> fwnode_mdiobus_phy_device_register(). Of course these can be extracted
> and exported but I don't see the benefit. IMHO it just cause jumping
> around files and since fwnode is a proper firmware abstraction we could
> use is directly wihin core/lib files.
No, assuming fwnode is the proper firmware abstraction is wrong. You
need to be very careful any time you convert of_ to fwnode_ and look
at the history of every property. Look at the number of deprecated OF
properties in Documentation/devicetree/bindings. They should never be
moved to fwnode_ because then you are moving deprecated properties to
ACPI, which never had them in the first place! You cannot assume DT
and ACPI are the same thing, have the same binding. And the same is
true, in theory, in the opposite direction. We don't want the DT
properties polluted with ACPI only properties. Not that anybody takes
ACPI seriously in networking.
> I know and I thought about adding the firmware parsing helpers first but
> than I went this way. I can split this of course to make the patch
> smaller.
Please do. Also, i read your commit message thinking it was a straight
copy of the code, and hence i did not need to review the code. But in
fact it is new code. So i need to take a close look at it.
But what i think is most important for this patchset is the
justification for not fixing the current API. Why is it broken beyond
repair?
Andrew
Powered by blists - more mailing lists