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