On Wed, 27 Jul 2016 20:04:56 +0200, Mark Brown wrote: > > On Wed, Jul 27, 2016 at 10:51:26PM +0530, Vinod Koul wrote: > > On Wed, Jul 27, 2016 at 07:57:05AM +0200, Takashi Iwai wrote: > > > > For unloading the module, yes, it should have been prevented by > > > managing the module refcount. However, unbinding can't be stopped by > > > that. It's a known problem. > > > Oh yes, unload is an issue. Are these any solutions to prevent this? > > > In core, should we de-register the card if one of the components exits. The > > .remove should be called for the driver, thus triggering unregister? > > That's the theory but it's full of holes at the minute. Someone needs > to sit down and fix all the holes in there. Yeah, and it's not so trivial. The unbind can be called at any time, even during a stream is running. This is a kind of hot unplug. The whole nightmare we've faced with usb-audio and co will strike again. I'm wondering whether it's a better option to block the unbind behavior, either in driver base (allowing to return an error) or in the sound side (waiting in remove() until the sane point). Takashi
