On 02/01/2017 11:10 AM, Russell King - ARM Linux wrote: > On Wed, Feb 01, 2017 at 01:59:38PM -0500, David Miller wrote: >> From: Florian Fainelli <f.faine...@gmail.com> >> Date: Wed, 1 Feb 2017 10:55:46 -0800 >> >>> You are right, but there is still a fundamental problem IMHO in that you >>> should not be able to rmmod a PHY driver as long as a network device is >>> attached to the PHY, and if the PHY driver is attached from several >>> different network devices, they should all have a way to prevent a PHY >>> driver rmmod, each of them incrementing the driver refcount, which is >>> what the patche from Maowan does here. >> >> It briefly occurred to me that we might want to be able to disconnect >> PHYs to allow an unload using notifiers, the same way that when you >> take a netdevice down we emit notifiers so that all of the references >> to the netdevice can release themselves. >> >> I have no idea how well that would work, or whether it is valuable or >> not. But it is another way to handle this. >> >> But that is a longer-term thing even if we want to go that way, and >> thus grabbing the proper refs is the right things to do for now. > > It's something I'm effectively already doing as part of my phylink > project for SFP support, since you can hot-unplug a copper SFP > module, and the PHY on the copper SFP module will be gone. phylink, > however, sits between the network driver and phylib, which isn't > ideal.
So, for the "net" tree what should we do? I don't really think that we should be able to let the PHY state machine run without a PHY driver bound to the device, at best nothing happens, at worse, we just crash and burn without further chance of recovering. -- Florian
