On 07/28/2016 10:42 PM, Takashi Iwai wrote: > On Thu, 28 Jul 2016 22:33:31 +0200, > Lars-Peter Clausen wrote: >> >> On 07/28/2016 05:46 AM, Vinod Koul wrote: >>> On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote: >>>> On Wed, 27 Jul 2016 20:22:33 +0200, >>>> Mark Brown wrote: >>>>> >>>>> On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote: >>>>> >>>>>> 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). >>>>> >>>>> That's certainly going to be a lot easier and part of the reason it's >>>>> never been looked at much is that (unlike USB) there's very little >>>>> reason why an ASoC sound card would ever be hotplugged - even in >>>>> development these days the normal development flow involves rebooting. >>> >>> I agree, it makese no sense for devices to be hotplugged. And for >>> developement flows people can do rmmond and insmod. That works fine! >> >> I don't agree. In my opinion hot-plug is an essential feature of a >> modern device driver framework and if ASoC wants to claim to fall in >> this category we ought to support it. Hotplug is something that always >> pops up sooner or later. E.g. if someone puts a ASoC supported CODEC on >> a hot-pluggable device (maybe USB) we don't want to duplicate the code, >> but be able to reuse. >> >> One area that e.g. requires hot-plug/-unplug and were ASoC supported >> devices are used is embedded development boards that support shields and >> devicetree overlays. Like e.g. RPI and similar. >> >> The reason why we don't support hot-unplug in ASoC at the moment is >> because it is not trivial to implement and nobody has cared enough yet. >> >> But if somebody wants to and has the resources to implement this we >> should not discourage this. >> >> I'd very much prefer to have proper hot-plug support instead of >> prohibiting unbinding even on systems that do not require hot-plug >> support normally. It's a much cleaner solution. > > Well, but hot-unplugging only a component like codec would be needed > in a real scenario? It's a different story from the hotplug in the > card level. With overlays I'm not sure if we can control the remove order. So the component might be removed before the card complex.
