On Wed, 16 May 2018 00:22:40 +0200, Tzung-Bi Shih wrote:
We noticed the issue because in some rarely case the code will be executed by worker of workqueue (i.e. deferral probe since v3.4) instead of udevd. As a result, applications rely on the change uevent of sound card (fired from 78-sound-card.rules) will be signaled prematurely. The applications assume when they receive the signal, everything of the sound card should be ready. But in the case, they are still initializing.
We have tried to change the order of SNDRV_DEV_CONTROL to the last one to fix the bug we met and it was doing great. So if there will not bring any side effect, it should be fine to apply the patch.
The register and disconnect should be OK, as they are merely the parts to expose to and hide from user-space.
By the way, out of curiosity, prior to the commit 289ca025ee1d, it seems the list is merely a FIFO. How to ensure control device is the last one to register at that time?
It's just the fact that snd_ctl_new() is called inside the snd_card_new(), i.e. it's the very first one to be added.
If the patch works for you, please give your tested-by tag, so that I'll merge it to for-next branch. It looks like a too intrusive change for 4.17-rc6, so maybe safer to queue for 4.18.
thanks,
Takashi