linux-kernel - Re: [PATCH v1 2/2] of: property: fw_devlink: Add support for "phy-handle" property

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:   Mon, 16 Aug 2021 13:43:19 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>, kernel-team@...roid.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH v1 2/2] of: property: fw_devlink: Add support for
 "phy-handle" property

On Sat, Aug 14, 2021 at 8:22 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> Hi Saravana
>
> > Hi Andrew,
> >
>
> > Also there
> > are so many phy related properties that my head is spinning. Is there a
> > "phy" property (which is different from "phys") that treated exactly as
> > "phy-handle"?
>
> Sorry, i don't understand your question.

Sorry. I was just saying I understand the "phy-handle" DT property
(seems specific to ethernet PHY) and "phys" DT property (seems to be
for generic PHYs -- used mostly by display and USB?). But I noticed
there's yet another "phy" DT property which I'm not sure I understand.
It seems to be used by display and ethernet and seems to be a
deprecated property. If you can explain that DT property in the
context of networking and how to interpret it as a human, that'd be
nice.

>
> > +     /*
> > +      * Device tree nodes pointed to by phy-handle never have struct devices
> > +      * created for them even if they have a "compatible" property. So
> > +      * return the parent node pointer.
> > +      */
>
> We have a classic bus with devices on it. The bus master is registers
> with linux using one of the mdiobus_register() calls. That then
> enumerates the bus, looking at the 32 possible address on the bus,
> using mdiobus_scan. It then gets a little complex, due to
> history.
>
> Originally, the only thing you could have on an MDIO bus was a
> PHY. But devices on MDIO busses are more generic, and Linux gained
> support for Ethernet switches on an MDIO bus, and there are a few
> other sort device. So to keep the PHY API untouched, but to add these
> extra devices, we added the generic struct mdio_device which
> represents any sort of device on an MDIO bus. This has a struct device
> embedded in it.
>
> When we scan the bus and find a PHY, a struct phy_device is created,
> which has an embedded struct mdio_device. The struct device in that is
> then registered with the driver core.
>
> So a phy-handle does point to a device, but you need to do an object
> orientated style look at the base class to find it.

Thanks for the detailed explanation. I didn't notice a phy_device had
an mdio_device inside it. Makes sense. I think my comment is not
worded accurately and it really should be:

Device tree nodes pointed to by phy-handle (even if they have a
"compatible" property) will never have struct devices probed and bound
to a driver through the driver framework. It's the parent node/device
that gets bound to a driver and initializes the PHY. So return the
parent node pointer instead.

Does this sound right? As opposed to PHYs the other generic mdio
devices seem to actually have drivers that'll bind to them through the
driver framework.

-Saravana