On Tue, Jul 19, 2022 at 11:46:23AM -0400, Sean Anderson wrote: > I'm saying that patches 4 and 5 [1] provide "...a working migration > path to [my] PCS driver model." Since enetc/ocelot do not use > devicetree for the PCS, patch 9 should have no effect. > > That said, if you've tested this on actual hardware, I'm interested > in your results. I do not have access to enetc/ocelot hardware, so > I was unable to test whether my proposed migration would work. > > --Sean > > [1] I listed 6 but it seems like it just has some small hunks which should have been in 5 instead Got it, thanks. So things actually work up until the end, after fixing the compilation errors and warnings and applying my phy_mask patch first. However, as mentioned by Russell King, this patch set now gives us the possibility of doing this, which happily kills the system: echo "0000:00:00.5-imdio:03" > /sys/bus/mdio_bus/drivers/lynx-pcs/unbind For your information, pcs-rzn1-miic.c already has a device_link_add() call to its consumer, and it does avoid the unbinding problem. It is a bit of a heavy hammer as Russell points out (a DSA switch is a single struct device, but has multiple net_devices and phylink instances, and the switch device would be unregistered in its entirety), but on the other hand, this is one of the simpler things we can do, until we have something more fine-grained. I, for one, am perfectly happy with a device link. The alternative would be reworking phylink to react on PCS devices coming and going. I don't even know what the implications are upon mac_select_pcs() and such...
