linux-kernel - Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device number

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZKKA6K44mp_vjwtp@hovoldconsulting.com>
Date:   Mon, 3 Jul 2023 10:03:52 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Mark Brown <broonie@...nel.org>
Cc:     johan+linaro@...nel.org, perex@...ex.cz, tiwai@...e.com,
        lgirdwood@...il.com, ckeepax@...nsource.cirrus.com,
        kuninori.morimoto.gx@...esas.com, linux-kernel@...r.kernel.org,
        pierre-louis.bossart@...ux.intel.com, alsa-devel@...a-project.org,
        Stable@...r.kernel.org
Subject: Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device
 number

On Mon, Jul 03, 2023 at 09:48:34AM +0200, Johan Hovold wrote:
> On Wed, Jun 28, 2023 at 10:24:04AM +0100, Srinivas Kandagatla wrote:
> > For some reason we ended up with a setup without this flag.
> > This resulted in inconsistent sound card devices numbers which
> >  are also not starting as expected at dai_link->id.
> >  (Ex: MultiMedia1 pcm ended up with device number 4 instead of 0)
> > 
> > With this patch patch now the MultiMedia1 PCM ends up with device number 0
> > as expected.
> 
> This appears to fix the intermittent probe breakage that I see every
> five boots or so:
> 
> [   11.843320] q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23
> [   11.867467] snd-sc8280xp sound: ASoC: adding FE link failed
> [   11.867574] snd-sc8280xp sound: ASoC: topology: could not load header: -517
> [   11.867725] qcom-apm gprsvc:service:2:1: tplg component load failed-517
> [   11.867933] qcom-apm gprsvc:service:2:1: ASoC: error at snd_soc_component_probe on gprsvc:service:2:1: -22
> [   11.868379] snd-sc8280xp sound: ASoC: failed to instantiate card -22
> [   11.873645] snd-sc8280xp: probe of sound failed with error -22
> 
> and which I've reported here:
> 
> 	https://lore.kernel.org/lkml/ZIHMMFtuDtvdpFAZ@hovoldconsulting.com/
> 
> as unrelated changes in timings resulting from that series made the
> problem much harder (but not impossible) to hit.
> 
> With this fix, I've rebooted 20+ times without hitting the issue once.
> 
> I'm guessing that you found this issue while investigated that probe
> race, Srini? It does look related, and it does seem to make the problem
> go away, but I'm not comfortable claiming that the intermittent probe
> breakage has been resolved without some analysis to back that up.

Ok, scratch that. I just hit the race again also with this patch
applied:

[   11.815028] q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23
[   11.838667] snd-sc8280xp sound: ASoC: adding FE link failed
[   11.838774] snd-sc8280xp sound: ASoC: topology: could not load header: -517
[   11.838916] qcom-apm gprsvc:service:2:1: tplg component load failed-517
[   11.838996] qcom-apm gprsvc:service:2:1: ASoC: error at snd_soc_component_probe on gprsvc:service:2:1: -22
[   11.839430] snd-sc8280xp sound: ASoC: failed to instantiate card -22
[   11.844801] snd-sc8280xp: probe of sound failed with error -22

Sorry about the noise.

Johan