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:   Fri, 11 Jun 2021 13:40:59 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Ioana Ciornei <ciorneiioana@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>,
        Grant Likely <grant.likely@....com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Jeremy Linton <jeremy.linton@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        Pieter Jansen Van Vuuren <pieter.jansenvv@...boosystems.io>,
        Jon <jon@...id-run.com>, Saravana Kannan <saravanak@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Calvin Johnson <calvin.johnson@....nxp.com>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Florin Laurentiu Chiculita <florinlaurentiu.chiculita@....com>,
        Madalin Bucur <madalin.bucur@....com>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Diana Madalina Craciun <diana.craciun@....com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux.cj" <linux.cj@...il.com>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        Len Brown <lenb@...nel.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: [PATCH net-next v9 03/15] net: phy: Introduce phy related fwnode functions

On Fri, Jun 11, 2021 at 1:26 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> On Fri, Jun 11, 2021 at 1:54 PM Ioana Ciornei <ciorneiioana@...il.com> wrote:
> >
> > From: Calvin Johnson <calvin.johnson@....nxp.com>
> >
> > Define fwnode_phy_find_device() to iterate an mdiobus and find the
> > phy device of the provided phy fwnode. Additionally define
> > device_phy_find_device() to find phy device of provided device.
> >
> > Define fwnode_get_phy_node() to get phy_node using named reference.
>
> using a named
>
> ...
>
> > +struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
> > +{
> > +       struct fwnode_handle *phy_node;
> > +
> > +       /* Only phy-handle is used for ACPI */
> > +       phy_node = fwnode_find_reference(fwnode, "phy-handle", 0);
> > +       if (is_acpi_node(fwnode) || !IS_ERR(phy_node))
> > +               return phy_node;
> > +       phy_node = fwnode_find_reference(fwnode, "phy", 0);
> > +       if (IS_ERR(phy_node))
> > +               phy_node = fwnode_find_reference(fwnode, "phy-device", 0);
> > +       return phy_node;
>
> Looking into the patterns in this code I would perhaps refactor it the
> following way:
>
>      /* First try "phy-handle" as most common in use */
>      phy_node = fwnode_find_reference(fwnode, "phy-handle", 0);
>      /* Only phy-handle is used for ACPI */
>      if (is_acpi_node(fwnode))
>               return phy_node;
>      if (!IS_ERR(phy_node))
>               return phy_node;

I'm not sure why you want the above to be two if () statements instead of one?

I would change the ordering anyway, that is

if (!IS_ERR(phy_node) || is_acpi_node(fwnode))
        return phy_node;

And I think that the is_acpi_node() check is there to return the error
code right away so as to avoid returning a "not found" error later.

But I'm not sure if this is really necessary.  Namely, if nothing
depends on the specific error code returned by this function, it would
be somewhat cleaner to let the code below run if phy_node is an error
pointer in the ACPI case, because in that case the code below will
produce an error pointer anyway.

>      /* Try "phy" reference */
>      phy_node = fwnode_find_reference(fwnode, "phy", 0);
>      if (!IS_ERR(phy_node))
>               return phy_node;
>      /* At last try "phy-device" reference */
>      return fwnode_find_reference(fwnode, "phy-device", 0);
>
> > +}

Powered by blists - more mailing lists