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] [day] [month] [year] [list]
Message-ID: <ce796f36-11df-7f9c-55aa-9c0833f28b93@nvidia.com>
Date:   Mon, 4 Oct 2021 10:08:01 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        <broonie@...nel.org>, <lgirdwood@...il.com>, <robh+dt@...nel.org>,
        <thierry.reding@...il.com>, <jonathanh@...dia.com>,
        <catalin.marinas@....com>, <will@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <kuninori.morimoto.gx@...esas.com>
CC:     <devicetree@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
        <linux-tegra@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE



On 10/1/2021 12:30 AM, Pierre-Louis Bossart wrote:
>> 1. The original issue at my end was not just a configuration redundancy.
>> I realize now that with more stream addition following error print is seen.
>>     "ASoC: too many users playback at open 4"
>>
>>     This is because the max DPCM users is capped at 8. Increasing this
>> may help (need to see what number is better), but does not address the
>> redundancy problem.
> Going back to this DPCM_MAX_BE_USERS definition, it seems rather
> arbitrary and not so useful indeed.

>          /* first time the dpcm is open ? */
>          if (be->dpcm[stream].users == DPCM_MAX_BE_USERS) {
>                  dev_err(be->dev, "ASoC: too many users %s at open %d\n",
>                          stream ? "capture" : "playback",
>                          be->dpcm[stream].state);
>                  continue;
>          }
>
> The comment is no longer aligned with the code, wondering if this is a
> feature or a bug.

Looks like the comment is misplaced and the intention might have been to 
place it like below?

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index e30cb5a..5cb5019 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1508,7 +1508,6 @@ int dpcm_be_dai_startup(struct snd_soc_pcm_runtime 
*fe, int stream)
                 if (!snd_soc_dpcm_be_can_update(fe, be, stream))
                         continue;

-               /* first time the dpcm is open ? */
                 if (be->dpcm[stream].users == DPCM_MAX_BE_USERS) {
                         dev_err(be->dev, "ASoC: too many users %s at 
open %d\n",
                                 stream ? "capture" : "playback",
@@ -1516,6 +1515,7 @@ int dpcm_be_dai_startup(struct snd_soc_pcm_runtime 
*fe, int stream)
                         continue;
                 }

+               /* first time the dpcm is open ? */
                 if (be->dpcm[stream].users++ != 0)
                         continue;

>   There's no reason to arbitrarily restrict the number
> of users of a BE, or the check would need to use platform-specific
> information such as the number of inputs/outputs supported by a mixer/demux.
>
> Maybe Morimoto-san can comment since this was added in:
>
> 1db19c151819 ('ASoC: soc-pcm: fixup dpcm_be_dai_startup() user count')
>
> We're not done with soc-pcm.c cleanups :-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ