netdev - 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]

Message-ID: <YCRjmpKjK0pxKTCP@lunn.ch>
Date:   Wed, 10 Feb 2021 23:52:10 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Saravana Kannan <saravanak@...gle.com>
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 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.

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.

   Andrew