[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201003180301.GD28093@lsv03152.swis.in-blr01.nxp.com>
Date: Sat, 3 Oct 2020 23:33:01 +0530
From: Calvin Johnson <calvin.johnson@....nxp.com>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Grant Likely <grant.likely@....com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Jeremy Linton <jeremy.linton@....com>,
Andrew Lunn <andrew@...n.ch>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Cristi Sovaiala <cristian.sovaiala@....com>,
Florin Laurentiu Chiculita <florinlaurentiu.chiculita@....com>,
Ioana Ciornei <ioana.ciornei@....com>,
Madalin Bucur <madalin.bucur@....nxp.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux.cj@...il.com,
netdev@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Diana Madalina Craciun <diana.craciun@....com>,
Laurentiu Tudor <laurentiu.tudor@....com>,
"David S. Miller" <davem@...emloft.net>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>, nd <nd@....com>
Subject: Re: [net-next PATCH v1 3/7] net: phy: Introduce fwnode_get_phy_id()
Hi Russell and Florian,
On Fri, Oct 02, 2020 at 04:50:26PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Oct 02, 2020 at 08:14:07AM -0700, Florian Fainelli wrote:
> > On 10/2/2020 4:05 AM, Grant Likely wrote:
> > > On 30/09/2020 17:04, Calvin Johnson wrote:
> > > > Extract phy_id from compatible string. This will be used by
> > > > fwnode_mdiobus_register_phy() to create phy device using the
> > > > phy_id.
> > > >
> > > > Signed-off-by: Calvin Johnson <calvin.johnson@....nxp.com>
> > > > ---
> > > >
> > > > drivers/net/phy/phy_device.c | 32 +++++++++++++++++++++++++++++++-
> > > > include/linux/phy.h | 5 +++++
> > > > 2 files changed, 36 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > > > index c4aec56d0a95..162abde6223d 100644
> > > > --- a/drivers/net/phy/phy_device.c
> > > > +++ b/drivers/net/phy/phy_device.c
> > > > @@ -9,6 +9,7 @@
> > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > > +#include <linux/acpi.h>
> > > > #include <linux/bitmap.h>
> > > > #include <linux/delay.h>
> > > > #include <linux/errno.h>
> > > > @@ -845,6 +846,27 @@ static int get_phy_c22_id(struct mii_bus *bus,
> > > > int addr, u32 *phy_id)
> > > > return 0;
> > > > }
> > > > +/* Extract the phy ID from the compatible string of the form
> > > > + * ethernet-phy-idAAAA.BBBB.
> > > > + */
> > > > +int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
> > > > +{
> > > > + unsigned int upper, lower;
> > > > + const char *cp;
> > > > + int ret;
> > > > +
> > > > + ret = fwnode_property_read_string(fwnode, "compatible", &cp);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + if (sscanf(cp, "ethernet-phy-id%4x.%4x", &upper, &lower) == 2) {
> > > > + *phy_id = ((upper & 0xFFFF) << 16) | (lower & 0xFFFF);
> > > > + return 0;
> > > > + }
> > > > + return -EINVAL;
> > > > +}
> > > > +EXPORT_SYMBOL(fwnode_get_phy_id);
> > >
> > > This block, and the changes in patch 4 duplicate functions from
> > > drivers/of/of_mdio.c, but it doesn't refactor anything in
> > > drivers/of/of_mdio.c to use the new path. Is your intent to bring all of
> > > the parsing in these functions of "compatible" into the ACPI code path?
> > >
> > > If so, then the existing code path needs to be refactored to work with
> > > fwnode_handle instead of device_node.
> > >
> > > If not, then the DT path in these functions should call out to of_mdio,
> > > while the ACPI path only does what is necessary.
> >
> > Rob has been asking before to have drivers/of/of_mdio.c be merged or at
> > least relocated within drivers/net/phy where it would naturally belong. As a
> > preliminary step towards ACPI support that would seem reasonable to do.
>
> I think even I have commented on specific functions while reviewing
> patches from NXP that the DT/ACPI code should use common bases...
>
> I have been planning that if that doesn't get done, then I'd do it,
> but really NXP should do it being the ones adding this infrastructure;
> they should do the job properly and not take advantage of volunteers
> in the community cleaning up their resulting submissions.
I'll work on it.
Thanks
Calvin
Powered by blists - more mailing lists