On Tue, 05 Sep 2017 09:40:11 +0200, Kuninori Morimoto wrote: > > Hi Takashi-san > > Thank you for your feedback > > > This isn't something you shouldn't fiddle with the codec layer. > > If the driver gets removed during the operation, you have to cancel > > the operation and sync with it in a proper way, then proceed the rest > > of the remove, not only a codec-specific resource management. > (snip) > > Here I mentioned the codec driver, but it's applied to each lower-level > > component. It'd need some graceful way to communicate with the > > top-level card to assure the removal of the component. > > I agree. > I can't access to source code now (I'm in business-trip), but my head-acke is that kernel doesn't check return value from .remove when unbind case. > Thus, we can't "cancel" remove operation. > I'm happy if you can confirm it. Right, you can't cancel or return an error at that point. That is, you'd need to sync (wait) until the all top-level operations are canceled at remove callback. For example, snd_card_free() processes the disconnection procedure at first, then waits for the completion. That's how the hot-unplug works safely. It's implemented, at least, in the top-level driver removal. Now for the lower level driver, you'd need a similar strategy; notify to the toplevel for hot-unplug (disconnect in ALSA), and sync with the stop operation, then continue the rest of its own remove procedure. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
