sound: Standardize mixer_init() call order

[christos]

Summary

Device drivers call mixer_init() in a non-standard order - some before
pcm_init(), and some after pcm_register(). However, both approaches are
potentially risky, and logically weak, since pcm_register() is supposed
to be the function that finalizes sound(4) attach.

Standardize the call ordering by moving all mixer_init() calls after
pcm_init(). This is also necessary for a follow-up patch, which expects
pcm_init() to have run first and initialized the PCM lock.

Sponsored by: The FreeBSD Foundation
MFC after: 1 month

[christos]

Bump, including the whole commit stack.

[christos]

Friendly bump (including the rest of the commit stack).

[kib]

In D59069#1370752, @christos wrote:

Friendly bump (including the rest of the commit stack).

I suggest you to go ahead with your changes. I suspect you are the only one who has the good understanding of the audio driver architecture. If there is any problem afterward with devfs integration, I will help.

[markj]

In D59069#1371357, @kib wrote:

In D59069#1370752, @christos wrote:

Friendly bump (including the rest of the commit stack).

I suggest you to go ahead with your changes. I suspect you are the only one who has the good understanding of the audio driver architecture. If there is any problem afterward with devfs integration, I will help.

+1

sys/arm/allwinner/a10_codec.c

1153

This is allocating some resources, e.g., unit number allocators. Now there are some extra error paths which make it easier to leak those resources. The problem already existed in most drivers, I think, but this makes it worse.

[christos]

sys/arm/allwinner/a10_codec.c

1153

I will address the clean ups in follow-up patches.

[christos]

Committed but Phab didn't close this automatically.