I thought about this in the background the past few days. I think
there are a couple of options:
1. We (community/Andrew) agree that this driver would only work with
fw_devlink=on and we can confirm that the other upstream uses of
"realtek,rtl8366rb" won't have any unprobed consumers problem and
switch to using my patch. Benefit is that it's a trivial and quick
change that gets things working again.

I don't think realtek,rtl8366rb is doing anything particularly
unusual. It is not the only switch driver with an MDIO bus driver with
its internal PHYs on it.

2. The "realtek,rtl8366rb" driver needs to be fixed to use a
"component device".

Again, i don't think "realtek,rtl8366rb is doing anything unusual,
compared to the other DSA drivers. If you are suggesting it needs to
make use of the component driver, you might also be suggesting that
all the switch drivers need to be component devices. I don't fully
understand the details here, but it might be, you are also suggesting
some Ethernet drivers need modifying to use the component framework?
And that is not going to fly.

This has all worked until now, things might need a few iterations with
deferral, but we get there in the end. Maybe we need to back out the
phy-handle patch? It does appear to be causing regressions.

	   Andrew