All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Network Development <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	Vivek Unune <npcomplete13@gmail.com>
Subject: Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)
Date: Thu, 30 Sep 2021 13:30:16 +0100	[thread overview]
Message-ID: <YVWt2B7c9YKLlmgT@shell.armlinux.org.uk> (raw)
In-Reply-To: <f51658fb-0844-93fc-46d0-6b3a7ef36123@gmail.com>

On Thu, Sep 30, 2021 at 02:14:54PM +0200, Rafał Miłecki wrote:
> On 30.09.2021 13:44, Russell King (Oracle) wrote:
> > On Thu, Sep 30, 2021 at 01:29:33PM +0200, Rafał Miłecki wrote:
> > > On 30.09.2021 12:40, Russell King (Oracle) wrote:
> > > > In phy_probe, can you add:
> > > > 
> > > > 	WARN_ON(!(phydev->mdio.flags & MDIO_DEVICE_FLAG_PHY));
> > > > 
> > > > just to make sure we have a real PHY device there please? Maybe also
> > > > print the value of the flags argument.
> > > > 
> > > > MDIO_DEVICE_FLAG_PHY is set by phy_create_device() before the mutex is
> > > > initialised, so if it is set, the lock should be initialised.
> > > > 
> > > > Maybe also print mdiodev->flags in mdio_device_register() as well, so
> > > > we can see what is being registered and the flags being used for that
> > > > device.
> > > > 
> > > > Could it be that openwrt is carrying a patch that is causing this
> > > > issue?
> > > 
> > > I don't think there is any OpenWrt patch affecting that.
> > > 
> > > MDIO_DEVICE_FLAG_PHY seems to be missing.
> > 
> > Right, so the mdio device being registered is a non-PHY MDIO device.
> > It doesn't have a struct phy_device around it - and so any access
> > outside of the mdio_device is an out-of-bounds access.
> 
> I can confirm that.
> 
> of_mdiobus_register() iterates over node children. It calls
> of_mdiobus_child_is_phy() for the /mdio-mux@18003000/mdio@200/switch@0
> and that returns 0. It results in calling of_mdiobus_register_device().
> 
> So we have MDIO device as expected. It's not a PHY device.

Right - because it's a switch device - identified as having a
compatible but without having a PHY-like compatible.

	compatible = "brcm,bcm53125";

This will be created by mdio_device_create(), which will not have
its bus_match method populated. So the only way a driver registered
on the MDIO bus_type can match is via the DT-based matching I've
previously mentioned.

> > Consequently, phylib should not be matching this device. The only
> > remaining way I can see that this could happen is if a PHY driver has
> > an OF compatible, which phylib drivers should never have.
> 
> It's actually OpenWrt's downstream swconfig-based b53 driver that
> matches this device.
> 
> I'm confused as downstream b53_mdio.c calls phy_driver_register(). Why
> does it match MDIO device then? I thought MDIO devices should be
> matches only with drivers using mdio_driver_register().

Note that I've no idea what he swconfig-based b53 driver looks like,
I don't have the source for that to hand.

If it calls phy_driver_register(), then it is registering a driver for
a MDIO device wrapped in a struct phy_device. If this driver has a
.of_match_table member set, then this is wrong - the basic rule is

	PHY drivers must never match using DT compatibles.

because this is exactly what will occur - it bypasses the check that
the mdio_device being matched is in fact wrapped by a struct phy_device,
and we will access members of the non-existent phy_device, including
the "uninitialised" mutex.

If the swconfig-based b53 driver does want to bind to a phy_device based
DT node, then it needs to match using either a custom .match_phy_device
method in the PHY driver, or it needs to match using the PHY IDs.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2021-09-30 12:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  9:58 Lockup in phy_probe() for MDIO device (Broadcom's switch) Rafał Miłecki
2021-09-30 10:15 ` Rafał Miłecki
2021-09-30 10:17 ` Russell King (Oracle)
2021-09-30 10:30   ` Rafał Miłecki
2021-09-30 10:40     ` Russell King (Oracle)
2021-09-30 11:29       ` Rafał Miłecki
2021-09-30 11:44         ` Russell King (Oracle)
2021-09-30 12:14           ` Rafał Miłecki
2021-09-30 12:30             ` Russell King (Oracle) [this message]
2021-09-30 12:51               ` Rafał Miłecki
2021-09-30 13:07                 ` Russell King (Oracle)
2021-09-30 13:21                   ` Russell King (Oracle)
2021-09-30 13:32                     ` Andrew Lunn
2021-09-30 13:47                       ` Rafał Miłecki
2021-09-30 13:42                   ` Rafał Miłecki
2021-09-30 13:54                     ` Russell King (Oracle)
2021-09-30 11:22     ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YVWt2B7c9YKLlmgT@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=npcomplete13@gmail.com \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.