On Tue, Dec 05, 2023 at 02:31:41PM +0300, Serge Semin wrote: > On Tue, Dec 05, 2023 at 10:49:47AM +0000, Russell King (Oracle) wrote: > > On Tue, Dec 05, 2023 at 01:35:27PM +0300, Serge Semin wrote: > > > If the DW XPCS MDIO devices are either left unmasked for being auto-probed > > > or explicitly registered in the MDIO subsystem by means of the > > > mdiobus_register_board_info() method there is no point in creating the > > > dummy MDIO device instance in order to get the DW XPCS handler since the > > > MDIO core subsystem will create the device during the MDIO bus > > > registration procedure. > > > > > Please reword this overly long sentence. > > Ok. > > > > > If they're left unmasked, what prevents them being created as PHY > > devices? > > Not sure I fully get what you meant. If they are left unmasked the > MDIO-device descriptor will be created by the MDIO subsystem anyway. > What the point in creating another one? The MDIO bus scan looks for devices on the MDIO bus by probing each address. If it finds a response, it creates a PHY device (struct phy_device), and stores a pointer to the mdiodev embedded in this structure in the array. This device then gets registered as a PHY device, and becomes available for use by phylib and PHY drivers. This is something that needs to be avoided, but I don't see anything in your series that achieves that. > > No, this makes no sense now. This function is called > > xpcs_create_mdiodev() - note the "create_mdiodev" part. If it's getting > > the mdiodev from what is already there then it isn't creating it, so > > it's no longer doing what it says in its function name. If you want to > > add this functionality, create a new function to do it. > > AFAICS the method semantics is a bit different. It's responsibility is to > create the DW XPCS descriptor. MDIO-device is utilized internally by > the DW XPCS driver. The function callers don't access the created MDIO > device directly (at least since some recent commit). So AFAIU "create" > means creating the XPCS descriptor irrespective from the internal > communication layer. So IMO the suffix is a bit misleading. I'll > change it in one of the next commit anyway. Should I just merge that > patch back in this one? This function was created (by me) to also create the mdiodev. The function for use with a pre-existing mdiodev was xpcs_create(). But what do I know, I was only the author of this function, and of course you're correct. I don't like this patch anyway. Moving the mdio_device_get() etc out of xpcs_create() is wrong. Even if you get a mdiodev from some other place, then having xpcs_create() take a reference on it is still the correct thing to do. My conclusion is you don't understand refcounting. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
