linux-kernel - Re: [PATCH v2 1/4] regulator: rpmh-regulator: Fix PMIC5 BOB bypass mode handling

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: <hwsornfn3rv524pzrudgscxffbvexdr5c3ko3th6sdakx6zfdv@sg6awizr6mzw>
Date: Mon, 27 Oct 2025 16:31:31 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Mark Brown <broonie@...nel.org>,
        Konrad Dybcio <konrad.dybcio@....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 Fri, Oct 24, 2025 at 01:33:58PM +0530, Kamal Wadhwa wrote:
> On Thu, Oct 23, 2025 at 02:37:07PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Oct 22, 2025 at 04:15:51PM +0100, Mark Brown wrote:
> > > 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.
> > 
> > Okay. I'm sorry if I'm overreacting.
> > 
> > The bypass_supported field still needs to go away in my opinion.
> 
> @Dmitry - one way to avoid it is if i re-use `.pmic_bypass_mode` and
> keep it  `= -EINVAL` for the checking if the bypass mode is not
> supported? and drop the `.bypass_supported`.

You don't need .bypass_supported because the regulators that don't
support bypass don't have .set_bypass callback in their ops and as such
it is impossible to get the vreg->bypassed flag to be set.

> But do note that currently only BOB type regulator supports bypass
> mode, and this above change will also require modifying all of the
> existing (and future) configs for regulator types that do not support
> bypass control.

[...]

> 
> while in the current patch i dont need to touch any of these above
> structures and just add new property and define it whereever
> `bypass_supported` is set to true.
> 
> i.e just change these 2 bob nodes only.
> 
> static const struct rpmh_vreg_hw_data pmic5_bob = {
> static const struct rpmh_vreg_hw_data pmic4_bob = {
> 
> Please suggest, if we can do this in a better way.

Don't change any of the nodes, the necessary changes are already in
place. Just fix the value being programmed for PMIC5.

-- 
With best wishes
Dmitry