Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)

On 30.09.2021 12:30, Rafał Miłecki wrote:

On 30.09.2021 12:17, Russell King (Oracle) wrote:

quoted

On Thu, Sep 30, 2021 at 11:58:21AM +0200, Rafał Miłecki wrote:

quoted

This isn't necessarily a PHY / MDIO regression. It could be some core
change that exposed a PHY / MDIO bug.

I think what's going on is that the switch device is somehow being
probed by phylib. It looks to me like we don't check that the mdio
device being matched in phy_bus_match() is actually a PHY (by
checking whether mdiodev->flags & MDIO_DEVICE_FLAG_PHY is true
before proceeding with any matching.)

We do, however, check the driver side. This looks to me like a problem
especially when the mdio bus can contain a mixture of PHY devices and
non-PHY devices. However, I would expect this to also be blowing up in
the mainline kernel as well - but it doesn't seem to.

Maybe Andrew can provide a reason why this doesn't happen - maybe we've
just been lucky with out-of-bounds read accesses (to the non-existent
phy_device wrapped around the mdio_device?)

I'll see if I can use buildroot to test unmodified kernel.

I've used buildroot to use unmodified 5.10.57 kernel.


Let me start with explaining that there are 2 b53 drivers.

1. OpenWrt downstream swconfig-based b53 driver
Its b53_mdio.c registers as PHY driver by calling phy_driver_register()

2. Upstream DSA-based b53 driver
Its b53_mdio.c registers as MDIO driver by using mdio_module_driver()


With buildroot + kernel 5.10.57 + upstream DSA-based b53 driver I can't
see phy_probe() called for the /mdio-mux@18003000/mdio@200/switch@0 .
I'm not sure why as I have CONFIG_B53_MDIO_DRIVER=y . Maybe it's some
PHY device vs. MDIO device thing?

I'll proceed with Russell's request for checking MDIO_DEVICE_FLAG_PHY
now.