Hi,
We found an assumption in 78-sound-cards.rules and commit
289ca025ee1d78223e3368801fc2b984e5efbfc7 are conflict. The control device
will not be the last one to register.
The assumption in 78-sound-card.rules:
> The control device node creation can be used as synchronization point.
All other devices that belong to a card are created in the kernel before it.
The commit:
> commit 289ca025ee1d78223e3368801fc2b984e5efbfc7
> Author: Takashi Iwai <tiwai@xxxxxxx>
> Date: Wed Jan 29 15:53:35 2014 +0100
>
> ALSA: Use priority list for managing device list
>
> Basically, the device type specifies the priority of the device to be
> registered / freed, too. However, the priority value isn't well
> utilized but only it's checked as a group. This results in
> inconsistent register and free order (where each of them should be in
> reversed direction).
>
> This patch simplifies the device list management code by simply
> inserting a list entry at creation time in an incremental order for
> the priority value. Since we can just follow the link for register,
> disconnect and free calls, we don't have to specify the group; so the
> whole enum definitions are also simplified as well.
>
> The visible change to outside is that the priorities of some object
> types are revisited. For example, now the SNDRV_DEV_LOWLEVEL object
> is registered before others (control, PCM, etc) and, in return,
> released after others. Similarly, SNDRV_DEV_CODEC is in a lower
> priority than SNDRV_DEV_BUS for ensuring the dependency.
>
> Also, the unused SNDRV_DEV_TOPLEVEL, SNDRV_DEV_LOWLEVEL_PRE and
> SNDRV_DEV_LOWLEVEL_NORMAL are removed as a cleanup.
>
> Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
The device types:
> enum snd_device_type {
> SNDRV_DEV_LOWLEVEL,
> SNDRV_DEV_CONTROL,
> SNDRV_DEV_INFO,
> SNDRV_DEV_BUS,
> SNDRV_DEV_CODEC,
> SNDRV_DEV_SEQUENCER,
> SNDRV_DEV_HWDEP,
> SNDRV_DEV_JACK,
> };
The commit sorts device types ascendantly and registers them from the list
head. As a result, SNDRV_DEV_CONTROL devices will be registered before
most other devices.
We are writing to ask: Is add uevent of controlC still a reliable signal
for indicating everything is ready for a sound card? Or is there now a
better way to do so?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
