On Tue, Aug 17, 2021 at 3:31 PM Vladimir Oltean [off-list ref] wrote:

Hi Alvin,

On Tue, Aug 17, 2021 at 09:25:28PM +0000, Alvin Šipraga wrote:

quoted

I have an observation that's slightly out of the scope of your patch,
but I'll post here on the off chance that you find it relevant.
Apologies if it's out of place.

Do these integrated NXP PHYs use a specific PHY driver, or do they just
use the Generic PHY driver?

They refuse to probe at all with the Generic PHY driver. I have been
caught off guard a few times now when I had a kernel built with
CONFIG_NXP_C45_TJA11XX_PHY=n and their probing returns -22 in that case.

quoted

If the former is the case, do you experience that the PHY driver fails
to get probed during mdiobus registration if the kernel uses
fw_devlink=on?

I don't test with "fw_devlink=on" in /proc/cmdline, this is the first
time I do it. It behaves exactly as you say.

quoted

In my case I am writing a new subdriver for realtek-smi, a DSA driver
which registers an internal MDIO bus analogously to sja1105, which is
why I'm asking. I noticed a deferred probe of the PHY driver because the
supplier (ethernet-switch) is not ready - presumably because all of this
is happening in the probe of the switch driver. See below:

[   83.653213] device_add:3270: device: 'SMI-0': device_add
[   83.653905] device_pm_add:136: PM: Adding info for No Bus:SMI-0
[   83.654055] device_add:3270: device: 'platform:ethernet-switch--mdio_bus:SMI-0': device_add
[   83.654224] device_link_add:843: mdio_bus SMI-0: Linked as a sync state only consumer to ethernet-switch
[   83.654291] libphy: SMI slave MII: probed
...
[   83.659809] device_add:3270: device: 'SMI-0:00': device_add
[   83.659883] bus_add_device:447: bus: 'mdio_bus': add device SMI-0:00
[   83.659970] device_pm_add:136: PM: Adding info for mdio_bus:SMI-0:00
[   83.660122] device_add:3270: device: 'platform:ethernet-switch--mdio_bus:SMI-0:00': device_add
[   83.660274] devices_kset_move_last:2701: devices_kset: Moving SMI-0:00 to end of list
[   83.660282] device_pm_move_last:203: PM: Moving mdio_bus:SMI-0:00 to end of list
[   83.660293] device_link_add:859: mdio_bus SMI-0:00: Linked as a consumer to ethernet-switch
[   83.660350] __driver_probe_device:736: bus: 'mdio_bus': __driver_probe_device: matched device SMI-0:00 with driver RTL8365MB-VC Gigabit Ethernet
[   83.660365] device_links_check_suppliers:1001: mdio_bus SMI-0:00: probe deferral - supplier ethernet-switch not ready
[   83.660376] driver_deferred_probe_add:138: mdio_bus SMI-0:00: Added to deferred list

So it's a circular dependency? Switch cannot finish probing because it
cannot connect to PHY, which cannot probe because switch has not
finished probing, which....

Hi Vladimir/Alvin,

If there's a cyclic dependency between two devices, then fw_devlink=on
is smart enough to notice that. Once it notices a cycle, it knows that
it can't tell which one is the real dependency and which one is the
false dependency and so stops enforcing ordering between the devices
in the cycle.

But fw_devlink doesn't understand all the properties yet. Just most of
them and I'm always trying to add more. So when it only understands
the property that's causing the false dependency but not the property
that causes the real dependency, it can cause issues like this where
fw_devlink=on enforces the false dependency and the driver/code
enforces the real dependency. These are generally easy to fix -- you
just need to teach fw_devlink how to parse more properties.

This is just a preliminary analysis since I don't have all the info
yet -- so I could be wrong. With that said, I happened to be working
on adding fw_devlink support for phy-handle property and I think it
should fix your issue with fw_devlink=on. Can you give [1] a shot?

If it doesn't fix it, can one of you please point me to an upstream
dts (not dtsi) file for a platform in which you see this issue? And
ideally also the DT nodes and their drivers that are involved in this
cycle? With that info, I should be able to root cause this if the
patch above doesn't already fix it.

So how is it supposed to be solved then? Intuitively the 'mdio_bus SMI-0:00'
device should not be added to the deferred list, it should have everything
it needs right now (after all, it works without fw_devlink). No?

It might be the late hour over here too, but right now I just don't
know. Let me add Saravana to the discussion too, he made an impressive
analysis recently on a PHY probing issue with mdio-mux,

Lol, thanks for the kind words.

so the PHY
library probing dependencies should still be fresh in his mind, maybe he
has an idea what's wrong.

[1] - https://lore.kernel.org/lkml/20210818021717.3268255-1-saravanak@google.com/T/#u (local)

Thanks,
Saravana