linux-kernel - Re: phy_attach_direct()'s use of device_bind

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:   Wed, 10 Feb 2021 15:29:22 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Jon Hunter <jonathanh@...dia.com>
Subject: Re: phy_attach_direct()'s use of device_bind_driver()

On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> > Hi,
> >
> > This email was triggered by this other email[1].
> >
> > Why is phy_attach_direct() directly calling device_bind_driver()
> > instead of using bus_probe_device()?
>
> Hi Saravana
>
> So this is to do with the generic PHY, which is a special case.
>
> First the normal case. The MDIO bus driver registers an MDIO bus using
> mdiobus_register(). This will enumerate the bus, finding PHYs on
> it. Each PHY device is registered with the device core, using the
> usual device_add(). The core will go through the registered PHY
> drivers and see if one can drive this hardware, based on the ID
> registers the PHY has at address 2 and 3. If a match is found, the
> driver probes the device, all in the usual way.
>
> Sometime later, the MAC driver wants to make use of the PHY
> device. This is often in the open() call of the MAC driver, when the
> interface is configured up. The MAC driver asks phylib to associate a
> PHY devices to the MAC device. In the normal case, the PHY has been
> probed, and everything is good to go.
>
> However, sometimes, there is no driver for the PHY. There is no driver
> for that hardware. Or the driver has not been built, or it is not on
> the disk, etc. So the device core has not been able to probe
> it. However, IEEE 802.3 clause 22 defines a minimum set of registers a
> PHY should support. And most PHY devices have this minimum. So there
> is a fall back driver, the generic PHY driver. It assumes the minimum
> registers are available, and does its best to drive the hardware. It
> often works, but not always. So if the MAC asks phylib to connect to a
> PHY which does not have a driver, we forcefully bind the generic
> driver to the device, and hope for the best.

Thanks for the detailed answer Andrew! I think it gives me enough
info/context to come up with a proper fix.

> We don't actually recommend using the generic driver. Use the specific
> driver for the hardware. But the generic driver can at least get you
> going, allow you to scp the correct driver onto the system, etc.

I'm not sure if I can control what driver they use. If I can fix this
warning, I'll probably try to do that.

-Saravana