linux-kernel - Re: [PATCH v1 2/2] ASoC: codecs: wsa883x: Handle shared reset GPIO for WSA883x 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: <c1b2f651f73b4469a410f1f5027f974b4e07ddd2.camel@pengutronix.de>
Date: Mon, 23 Jun 2025 09:11:32 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Mohammad Rafi
 Shaik <mohammad.rafi.shaik@....qualcomm.com>, Srinivas Kandagatla
 <srini@...nel.org>,  Liam Girdwood <lgirdwood@...il.com>, Mark Brown
 <broonie@...nel.org>, Rob Herring <robh@...nel.org>,  Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Jaroslav Kysela
 <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Linus Walleij
 <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>
Cc: linux-arm-msm@...r.kernel.org, linux-sound@...r.kernel.org, 
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-gpio@...r.kernel.org, quic_pkumpatl@...cinc.com,
 kernel@....qualcomm.com
Subject: Re: [PATCH v1 2/2] ASoC: codecs: wsa883x: Handle shared reset GPIO
 for WSA883x speakers

On Fr, 2025-06-20 at 21:35 +0300, Dmitry Baryshkov wrote:
> On 20/06/2025 13:30, Mohammad Rafi Shaik wrote:
> > On some Qualcomm platforms, such as QCS6490-RB3Gen2 and QCM6490-IDP,
> > multiple WSA8830/WSA8835 speakers share a common reset (shutdown) GPIO.
> > To handle such cases, use the reset controller framework along with the
> > "reset-gpio" driver.
> 
> How does this handle the fact that resetting one codec will also 
> silently reset another one?

It's the other way around. Since shared reset controls have a common
deassertion refcount, actual reset assertion only happens once
reset_control_assert() has been called on all shared reset controls
[1]. The speakers would only be put back into reset once the last one
is unbound.

[1] https://docs.kernel.org/driver-api/reset.html#shared-and-exclusive-resets

regards
Philipp