linux-kernel - Re: [PATCH] ASoC: amd: acp: Set gpio_spkr_en to None for max speaker amplifer in machine driver

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: <YfmCWuD88sT8YxfG@sirena.org.uk>
Date:   Tue, 1 Feb 2022 18:56:26 +0000
From:   Mark Brown <broonie@...nel.org>
To:     V sujith kumar Reddy <vsujithkumar.reddy@....com>
Cc:     alsa-devel@...a-project.org, Vijendar.Mukunda@....com,
        Basavaraj.Hiregoudar@....com, Sunil-kumar.Dommati@....com,
        ajitkumar.pandey@....com, Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        open list <linux-kernel@...r.kernel.org>,
        Curtis Malainey <cujomalainey@...gle.com>
Subject: Re: [PATCH] ASoC: amd: acp: Set gpio_spkr_en to None for max speaker
 amplifer in machine driver

On Tue, Feb 01, 2022 at 02:02:15AM +0530, V sujith kumar Reddy wrote:

> Maxim codec driver already enabling/disabling spk_en_gpio in form of sd_mode gpio
> hence remove such gpio access control from machine driver to avoid conflict

> -	.gpio_spkr_en = EN_SPKR_GPIO_NK,
> +	.gpio_spkr_en = EN_SPKR_GPIO_NONE,
>  };
>  
>  static struct acp_card_drvdata sof_rt5682s_rt1019_data = {
> @@ -56,7 +56,7 @@ static struct acp_card_drvdata sof_rt5682s_max_data = {
>  	.hs_codec_id = RT5682S,
>  	.amp_codec_id = MAX98360A,
>  	.dmic_codec_id = DMIC,
> -	.gpio_spkr_en = EN_SPKR_GPIO_NK,
> +	.gpio_spkr_en = EN_SPKR_GPIO_NONE,
>  };

This looks like a good fix for the immediate issue which fixes the
MAX9360A systems without breaking the RT1019 ones, however as I said in
the thread about Curtis' revert it's not clear what the ideal thing is
here.  There's no documentation about the RT1019 that I can find so it's
not clear to me what exactly the GPIO is controlling, if it's part of
the RT1019 or something else.  That influences where the most tasteful
place to control this GPIO is.  Curtis noted that the RT1019 driver
includes gpiolib headers but that could just as easily be cut'n'paste as
intentional.  What's the story here?

I do also note that the current code just turns the GPIO on and leaves
it on which presumably isn't great from a power management point of
view.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)