linux-kernel - RE: [PATCH 2/3] ASoC: codec: wcd938x: Convert to GPIO descriptors

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:
 <PAXPR04MB845940BF9775DE957FFC6A1388A42@PAXPR04MB8459.eurprd04.prod.outlook.com>
Date: Mon, 24 Mar 2025 07:53:28 +0000
From: Peng Fan <peng.fan@....com>
To: Linus Walleij <linus.walleij@...aro.org>
CC: Steev Klimaszewski <steev@...i.org>, "Peng Fan (OSS)"
	<peng.fan@....nxp.com>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown
	<broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai
	<tiwai@...e.com>, Bartosz Golaszewski <brgl@...ev.pl>, Srinivas Kandagatla
	<srinivas.kandagatla@...aro.org>, "linux-sound@...r.kernel.org"
	<linux-sound@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>
Subject: RE: [PATCH 2/3] ASoC: codec: wcd938x: Convert to GPIO descriptors

Hi Linus,

> Subject: Re: [PATCH 2/3] ASoC: codec: wcd938x: Convert to GPIO
> descriptors
> 
> On Mon, Mar 24, 2025 at 8:33 AM Peng Fan <peng.fan@....com>
> wrote:
> 
> > > With this patchset applied, the wcd938x codec used in the
> Thinkpad
> > > X13s stops working:
> > >
> > > wcd938x_codec audio-codec: soundwire device init timeout
> > > wcd938x_codec audio-codec: ASoC: error at
> snd_soc_component_probe on
> > > audio-codec: -110
> > > snd-sc8280xp sound: ASoC: failed to instantiate card -110 snd-
> > > sc8280xp sound: probe with driver snd-sc8280xp failed with error
> > > -110
> >
> > Thanks for help testing. But per current in-tree DTS, the reset is
> > using GPIO_ACTIVE_LOW, so it should work.
> >
> > I am not sure whether you are using firmware published DTS, if yes,
> > could you please help check the codec node to dump the reset-gpios
> > property under /sys/firmware/devicetree/xx ?
> 
> I'm also a bit puzzled.
> 
> I think maybe this device has some DTB that comes from the vendor
> with the wrong polarity :/
> 
> If this is the case we need to add a quirk to gpiolib to force this GPIO
> into active low,  something like this:
> 
> From dfe3d2a12a63135e917abacd0d3a29ce347a6cf9 Mon Sep 17
> 00:00:00 2001
> From: Linus Walleij <linus.walleij@...aro.org>
> Date: Mon, 24 Mar 2025 08:44:45 +0100
> Subject: [PATCH] Fix WCD938x polarity
> 
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
>  drivers/gpio/gpiolib-of.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index
> 2e537ee979f3..3baaddedb7b6 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -220,6 +220,15 @@ static void of_gpio_try_fixup_polarity(const
> struct device_node *np,
>                  * treats it as "active low".
>                  */
>                 { "ti,tsc2005",         "reset-gpios",  false },
> +#endif
> +#if IS_ENABLED(SND_SOC_WCD938X)
> +               /*
> +                * This codec is used in laptops with deployed devicetrees
> +                * that fail to specify the correct active low property for
> +                * the reset line.
> +                */
> +               { "qcom,wcd9380-codec", "reset-gpios",  false },
> +               { "qcom,wcd9385-codec", "reset-gpios",  false },
>  #endif
>         };
>         unsigned int i;
> --
> 2.48.1
> 
> Maybe you can fold this into your patch if it helps. And if there are
> more of the codecs with this problem, we need a similar patch in each
> one of them.

Thanks for your quick reply. I am thinking whether we need
to force the polarity of remaining of_gpio users. 
Some old devices may not able to get tested,  and some
may use firmware to publish DTS during runtime(such as Fedora,
openSUSE using firmware based DT when doing System-Ready IR),
so we are not sure whether using gpiod api break the platforms
or not.

Thanks,
Peng.

> 
> Yours,
> Linus Walleij