Hi Andrew, Florian, On 30.06.2020 06:35, Florian Fainelli wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 6/29/2020 5:45 PM, Andrew Lunn wrote: >> On Mon, Jun 29, 2020 at 10:26:36AM +0300, Claudiu Beznea wrote: >>> In case of_mdiobus_register_phy()/of_mdiobus_register_device() >>> returns -ENODEV for all PHYs in device tree or for all scanned >>> PHYs there is a chance that of_mdiobus_register() to >>> return success code although no PHY devices were registered. >>> Add a counter that increments every time a PHY was registered >>> to avoid the above scenario. >> >> Hi Claudiu >> >> There is a danger here this will break something. Without this patch, >> an empty bus is O.K. But with this patch, a bus without a PHY is a >> problem. >> >> Take for example FEC. It often comes in pairs. Each has an MDIO >> bus. But to save pins, there are some designs which place two PHYs on >> one bus, leaving the other empty. The driver unconditionally calls >> of_mdiobus_register() and if it returns an error, it will error out >> the probe. So i would not be too surprised if you get reports of >> missing interfaces with this patch. > > Agreed, the potential for breakage here is too high especially given > this is fixing a hypothetical problem rather an an actual one. Even if > we were taking this from the angle of power management, runtime PM > should ensure that a MDIO bus with no slave, or no activity gets runtime > suspended. I understand your points. Thank you for taking time on reviewing this. Claudiu Beznea > -- > Florian >
