netdev - Re: [net-next PATCH v2 02/14] net: phy: Introduce phy related fwnode functions

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:   Thu, 17 Dec 2020 13:02:24 +0530
From:   Calvin Johnson <calvin.johnson@....nxp.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     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>,
        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>,
        Marcin Wojtas <mw@...ihalf.com>,
        Pieter Jansen Van Vuuren <pieter.jansenvv@...boosystems.io>,
        Jon <jon@...id-run.com>, "linux.cj" <linux.cj@...il.com>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        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-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [net-next PATCH v2 02/14] net: phy: Introduce phy related fwnode
 functions

On Tue, Dec 15, 2020 at 07:23:26PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> <calvin.johnson@....nxp.com> wrote:
> >
> > 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.
> 
> ...
> 
> > +#include <linux/acpi.h>
> 
> Not sure we need this. See below.

This is required to use is_acpi_node().
> 
> ...
> 
> > +/**
> > + * fwnode_phy_find_device - Find phy_device on the mdiobus for the provided
> > + * phy_fwnode.
> 
> Can we keep a summary on one line?

Ok
> 
> > + * @phy_fwnode: Pointer to the phy's fwnode.
> > + *
> > + * If successful, returns a pointer to the phy_device with the embedded
> > + * struct device refcount incremented by one, or NULL on failure.
> > + */
> > +struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode)
> > +{
> > +       struct mdio_device *mdiodev;
> > +       struct device *d;
> 
> > +       if (!phy_fwnode)
> > +               return NULL;
> 
> Why is this needed?
> Perhaps a comment to the function description explains a case when
> @phy_fwnode == NULL.

I think this function should be modified to follow of_phy_find_device() which
has NULL check. I'll add fwnode_mdio_find_device() also.
Here is a case where of_phy_find_device() is called without checking phy_np.
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/qualcomm/emac/emac-phy.c#L145
> 
> > +       d = bus_find_device_by_fwnode(&mdio_bus_type, phy_fwnode);
> > +       if (d) {
> > +               mdiodev = to_mdio_device(d);
> > +               if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY)
> > +                       return to_phy_device(d);
> > +               put_device(d);
> > +       }
> > +
> > +       return NULL;
> > +}
> 
> ...
> 
> > + * For ACPI, only "phy-handle" is supported. DT supports all the three
> > + * named references to the 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;
> 
> So, what is the problem with going through the rest on ACPI?
> Usually we describe the restrictions in the documentation.

Others are legacy DT properties which are not intended to be supported
in ACPI. I can add this info in the document.

Thanks for the review, Andy!

Regards
Calvin