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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 1 Oct 2020 20:53:08 +0200
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Sameer Pujar <spujar@...dia.com>
Cc:     broonie@...nel.org, lgirdwood@...il.com, robh+dt@...nel.org,
        kuninori.morimoto.gx@...esas.com,
        pierre-louis.bossart@...ux.intel.com, perex@...ex.cz,
        tiwai@...e.com, thierry.reding@...il.com, jonathanh@...dia.com,
        alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
        sharadg@...dia.com, mkumard@...dia.com, viswanathl@...dia.com,
        rlokhande@...dia.com, dramesh@...dia.com, atalambedu@...dia.com,
        nwartikar@...dia.com, swarren@...dia.com, nicoleotsuka@...il.com
Subject: Re: [PATCH v3 01/13] ASoC: soc-core: Fix component name_prefix
 parsing

On Thu, Oct 01, 2020 at 11:02:55PM +0530, Sameer Pujar wrote:
> The "prefix" can be defined in DAI link node or it can be specified as
> part of the component node itself. Currently "sound-name-prefix" defined
> in a component is not taking effect. Actually the property is not getting
> parsed. It can be fixed by parsing "sound-name-prefix" property whenever
> "prefix" is missing in DAI link Codec node.
[...]
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1124,7 +1124,8 @@ static void soc_set_name_prefix(struct snd_soc_card *card,
>  	for (i = 0; i < card->num_configs; i++) {
>  		struct snd_soc_codec_conf *map = &card->codec_conf[i];
>  
> -		if (snd_soc_is_matching_component(&map->dlc, component)) {
> +		if (snd_soc_is_matching_component(&map->dlc, component) &&
> +		    map->name_prefix) {
>  			component->name_prefix = map->name_prefix;
>  			return;
>  		}

Hi,

It is not obvious how the patch fixes the problem described. I guess now
map->name_prefix is NULL on some level and overrides prefix found earlier?

Best Regards,
Michał Mirosław

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ