[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3fac2a3-dc89-440a-9958-f2e904c42f5a@sirena.org.uk>
Date: Wed, 22 Oct 2025 16:15:51 +0100
From: Mark Brown <broonie@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] regulator: rpmh-regulator: Fix PMIC5 BOB bypass
mode handling
On Wed, Oct 22, 2025 at 06:11:46PM +0300, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 04:58:15PM +0200, Konrad Dybcio wrote:
> > On 10/22/25 12:23 AM, Dmitry Baryshkov wrote:
> > > On Wed, Oct 22, 2025 at 02:38:53AM +0530, Kamal Wadhwa wrote:
> > >> Currently, when `rpmh_regulator_set_mode_bypass()` helper function
> > >> is called to set bypass mode, it sends PMIC4's BOB bypass mode
> > >> value for even if its a PMIC5 BOB.
> > > The universe will end, the Sun will explode and Ragnarök will be upon
> > > us. Please describe the issue, why sending bypass value is bad.
> > I think you misread, it sends the magic value which corresponds
> > to BYPASS, but one that worked for the previous generation
> I just wanted to point out that the commit message makes a statement
> that it sends some value. It should document, why the sent value is bad.
It seems fairly clear to me from the above that the driver is sending
the value for the wrong device type which is something so obviously
wrong I'm not sure it requires further explanation.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists