linux-kernel - Re: [RFC PATCH v2 2/3] ALSA: hda/realtek: Add support for Legion 7 16ACHg6 laptop Speakers

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: <s5hr1cgys0r.wl-tiwai@suse.de>
Date:   Wed, 20 Oct 2021 11:17:24 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Lucas Tanure <tanureal@...nsource.cirrus.com>
Cc:     Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.com>,
        "Jaroslav Kysela" <perex@...ex.cz>, Len Brown <lenb@...nel.org>,
        David Rhodes <david.rhodes@...rus.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        <alsa-devel@...a-project.org>, <linux-acpi@...r.kernel.org>,
        <patches@...nsource.cirrus.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 2/3] ALSA: hda/realtek: Add support for Legion 7 16ACHg6 laptop Speakers

On Wed, 20 Oct 2021 10:59:43 +0200,
Lucas Tanure wrote:
> 
> Find the associated Amps by dai name, and use dai ops to configure it.
> Disable support for Amps if ASoC not built.

Hrm, it's the question whether such a sneaking into DAI access in open
code is a good idea.  If any, it could be done by some helper function
instead.

And some more details:

> +static int alc_add_soc_dai_list(struct alc_spec *spec, const char *dai_name)
> +{
> +#if IS_ENABLED(CONFIG_SND_SOC)
> +	struct snd_soc_dai_link_component dlc;
> +	struct alc_soc_dai_node *dai_node;
> +	//struct snd_soc_component *comp;
> +	struct snd_soc_dai *dai;
> +
> +	dlc.dai_name = dai_name;
> +	dlc.of_node = NULL;
> +	dlc.name = NULL;
> +
> +	dai = snd_soc_find_dai(&dlc);
> +	if (!dai)
> +		return -EPROBE_DEFER;

The deferred probe won't work at this stage for HD-audio codecs unlike
many ASoC codec drivers.  And moreover, the fixup action doesn't
handle the error at all...

Second, this way may lead to use-after-free if the ASoC stuff is
unbound while the usage from HD-audio codec side.

Also, the dependency mess is still there.  Even if we allow the hard
binding to ASoC core here, IS_ENABLED() wouldn't work properly.  It
must be IS_REACHABLE().

thanks,

Takashi