On Wed, 10 Oct 2018 10:25:30 +0200, Takashi Iwai wrote:
On Wed, 10 Oct 2018 10:14:12 +0200, Takashi Sakamoto wrote:
Hi,
On Oct 10 2018 16:04, Takashi Iwai wrote:
On Wed, 10 Oct 2018 08:34:58 +0200, Takashi Sakamoto wrote:
In a discussion for devres support[1], I realize difference of unbind behaviour of drivers in ALSA firewire stack and in the others. For consistency behaviour inner the same subsystem for users, it's better to imitate the behaviour.
Additionally, blocking .remove function simplifies codes to releasing device.
This commit uses 'snd_card_free()' instead of 'snd_card_free_when_closed()' in .remove function and performs refactoring for release codes.
Would the hot-unplug behavior change with this patch?
For most of other drivers (but for USB), the actual hot-plug/unplug are unlikely scenario, hence blocking makes sense to assure the safety unbind. (Yes, there is also PCI hotplug, but an audio device is rarely used there.)
But, FireWire is a beast to be plugged / unplugged more often, so the hot-unplug behavior change is more important to users.
In a point of user experience, a slight change there is. From ether bus driver or sysfs nodes, unbind operation is successful. But it's blocked till all ALSA character devices are released. The user use 'unbind' sysfs node, command execution waits. In typical use cases of desktop environment, it waits that pulseaudio releases the last ALSA control character device.
In bus driver for IEEE 1394 bus, a call of .remove in device driver is done in workqueue. This bus operations runs without blocking.
OK, then that's fine. The blocking in unbind can be considered rather safer than the device hog-unplug, and the behavior change is justified by that.
If unbind operation is blocked in command line, it means that any program runs without no care of state of ALSA character devices. For example, current implementation of alsactl has this bug in its monitor mode[1]. The blocking state reminds users of this kind of bug of any applications.
Anyway, hot-plugging/unplugging are still available.
Rather than the slight change, this patchset performs refactoring codes for releasing devices. This removes complications of current code and simplify error paths.
Yes, that's a good bonus. I'll read through your patches.
... and applied all four patches now. Thanks!
Takashi