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

[Marek Szyprowski]

Hi Mark,

On 18.12.2019 17:24, Mark Brown wrote:
> On Wed, Dec 18, 2019 at 03:48:14PM +0100, Marek Szyprowski wrote:
>> On 18.12.2019 14:26, Mark Brown wrote:
>>>> - 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
> That's not what the analysis I was replying to said :(
>
> This log makes no sense to me, if this is the same card that was
> registered and announced earlier what caused it to become unregistered
> so that we are registering it now?

I've checked again the exact probe order and here is what happens in the 
system:

1. first call to odroid_audio_probe() is just after:

[    2.942428] samsung-i2s 3830000.i2s-sec: DMA channels sourced from device 3830000.i2s

2. That time, i2s dai and max98090 devices are already registered. 
However the snd_soc_of_get_dai_link_codecs() return -EPROBE_DEFER, 
because it cannot get the HDMI codec component.

3. HDMI codec is being registered when Exynos DRM initializes. This 
happens later:

[    3.127833] [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on 
minor 0

4. Then odroid_audio_probe() is called again from the deferred probe 
worker and succeeds:

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

5. Then userspace starts:

[    3.603825] Run /sbin/init as init process

6. when userspace init scripts (alsactl) enumerates devices in the 
system the lockdep warning is triggered:

[   10.068990] ======================================================
[   10.070970] WARNING: possible circular locking dependency detected
[   10.077136] 5.5.0-rc2-next-20191218 #7188 Not tainted
[   10.082168] ------------------------------------------------------
[   10.088332] alsactl/1106 is trying to acquire lock:

7. then alsa utils probably tries to load the saved values for the controls, what triggers the NULL ptr dereference:

[....] Setting up ALSA...[   10.502672] 8<--- cut here ---
[   10.502772] Unable to handle kernel NULL pointer dereference at virtual address 000000b0

>
>> If there are any useful logs for tracking this issue, let me know how to
>> enable them, so I will provide more logs.
> It'd be good to understand this unregistration/probe deferral for a
> start...  when did the card get unregistered and why?

I hope that the above description helps.

The same issue happens on OdroidXU, which uses simple-audio-card, so 
this is not related to odroid_audio_card only.

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