[alsa-devel] [PATCH v2] ASoC: max98090: save and restore SHDN when changing sensitive registers

[Marek Szyprowski]

Hi Mark,

On 18.12.2019 14:26, Mark Brown wrote:
> On Fri, Dec 13, 2019 at 02:05:32AM +0800, Tzung-Bi Shih wrote:
>> I have no enough resources to test and trace the code temporarily.
>> But is it possible:
>> - snd_card_new( ) succeed in snd_soc_bind_card( ), so that userspace
>> can see the control
> This feels like snd_card_new() is being overly enthusiastic here, I'd
> expect that we might have other problems elsewhere with that.  I'd not
> expect userspace to see things until snd_card_register() since between
> _new() and that we're in the process of building the card up.  Given
> this we *will* need to handle partially constructed cards after all,
> unless we change the ALSA core.  Takashi?

I'm not sure if this is an issue about partially registered card. Here 
is the boot log:

https://paste.debian.net/1121543/

This oops happens when udev tries to do its job. The card is earlier 
fully registered and advertised by alsa:

[    3.501198] ALSA device list:
[    3.501300]   #0: Odroid-U3

If there are any useful logs for tracking this issue, let me know how to 
enable them, so I will provide more logs.

>
>> - code in later snd_soc_bind_card( ) decided to defer the probe
>> - soc_cleanup_card_resources( ) may forget to clean the control?  (not
>> sure about this)
> There's going to be a race condition where userspace can see the control
> on the partially built card regardless of if it gets cleaned up or not.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland