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: <CAOReqxiGW+8BR5VRVHDJuBXxkpB_oQ_4TTNBqm1tuK6shUKLpg@mail.gmail.com>
Date:   Tue, 1 Feb 2022 13:43:38 -0800
From:   Curtis Malainey <cujomalainey@...gle.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     V sujith kumar Reddy <vsujithkumar.reddy@....com>,
        ALSA development <alsa-devel@...a-project.org>,
        Vijendar.Mukunda@....com,
        "Hiregoudar, Basavaraj" <Basavaraj.Hiregoudar@....com>,
        "Dommati, Sunil-kumar" <Sunil-kumar.Dommati@....com>,
        "Pandey, Ajit Kumar" <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>
Subject: Re: [PATCH] ASoC: amd: acp: Set gpio_spkr_en to None for max speaker
 amplifer in machine driver

On Tue, Feb 1, 2022 at 10:56 AM Mark Brown <broonie@...nel.org> wrote:
>
> 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.

Yes that is correct, this is the quick fix that will alleviate the
gpio contention issue. But I think there is a better solution here.
According to the sheet I have, the pin for the alc1019 is the same as
the max98357a and its a shutdown pin for the amp.