On 05/18/2017 01:36 PM, Geert Uytterhoeven wrote: > Hi Andrew, > > On Thu, May 18, 2017 at 9:34 PM, Andrew Lunn <andrew@xxxxxxx> wrote: >>>> This most certainly works fine in the simple case where you have one PHY >>>> hanging off the MDIO bus, now what happens if you have several? >>>> >>>> Presumably, the first PHY that returns EPROBE_DEFER will make the entire >>>> bus registration return EPROB_DEFER as well, and so on, and so forth, >>>> but I am not sure if we will be properly unwinding the successful >>>> registration of PHYs that either don't have an interrupt, or did not >>>> return EPROBE_DEFER. >>>> >>>> It should be possible to mimic this behavior by using the fixed PHY, and >>>> possibly the dsa_loop.c driver which would create 4 ports, expecting 4 >>>> fixed PHYs to be present. >>> >>> mdiobus_unregister(), called from of_mdiobus_register() on failure, >>> should do the unwinding, right? >>> >>> And when the driver is reprobed, all PHYs are reprobed, until they all >>> succeed. >> >> That is the theory. I looked at that while reviewing the patch. But >> this has probably not been tested in anger. It would be good to test >> this properly, with not just the first PHY returning -EPROBE_DEFER, to >> really test the unwind. > > Unfortunately I don't have a board with multiple PHYs, so I cannot test > that case. > > Does unbinding/rebinding a network driver with multiple PHYs currently > work? Or module unload/reload? Usually there is a strict 1:1 mapping between a network device (not driver) and a PHY device, switch drivers however, would have multiple PHYs (one per port, aka net_deice). NB: binding and unbinding of PHYs is pretty broken at the moment though, because there is a complete disconnect between what the Ethernet MAC expects, and the state in which the PHY is. I had some patches to fix that, but this turned out to be playing whack-a-mole which I typically suck at. -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
