On Sun, Apr 19, 2020 at 06:29:28PM +0200, Andrew Lunn wrote: > On Sun, Apr 19, 2020 at 12:29:23PM +0200, Michael Walle wrote: > > Am 2020-04-17 23:28, schrieb Andrew Lunn: > > > On Fri, Apr 17, 2020 at 11:08:56PM +0200, Michael Walle wrote: > > > > Am 2020-04-17 22:13, schrieb Andrew Lunn: > > > > > > Correct, and this function was actually stolen from there ;) This was > > > > > > actually stolen from the mscc PHY ;) > > > > > > > > > > Which in itself indicates it is time to make it a helper :-) > > > > > > > > Sure, do you have any suggestions? > > > > > > mdiobus_get_phy() does the bit i was complaining about, the mdiobus > > > internal knowledge. > > > > But that doesn't address your other comment. > > Yes, you are right. But i don't think you can easily generalize the > rest. It needs knowledge of the driver private structure to reference > pkg_init. You would have to move that into phy_device. > > > > > > There is also the question of locking. What happens if the PHY devices > > > is unbound while you have an instance of its phydev? > > > > Is there any lock one could take to avoid that? > > phy_attach_direct() does a get_device(). That at least means the > struct device will not go away. I don't know the code well enough to > know if that will also stop the phy_device structure from being freed. Well, struct device is embedded in struct mdio_device, which in turn is embedded in struct phy_device. So, if struct device can't go away because its refcount is held, the same is true of the structs embedding it. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
