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]
Date:   Fri, 12 Feb 2021 11:44:25 +0200
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-power@...rohmeurope.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] regulator: bd718x7, bd71828, Fix dvs voltage
 levels

Hello Lee,

On Fri, 2021-02-12 at 09:16 +0000, Lee Jones wrote:
> On Fri, 12 Feb 2021, Matti Vaittinen wrote:
> 
> > The ROHM BD718x7 and BD71828 drivers support setting HW state
> > specific voltages from device-tree. This is used also by various
> > in-tree DTS files.
> > 
> > These drivers do incorrectly try to compose bit-map using enum
> > values. By a chance this works for first two valid levels having
> > values 1 and 2 - but setting values for the rest of the levels
> > do indicate capability of setting values for first levels as
> > well. Luckily the regulators which support setting values for
> > SUSPEND/LPSR do usually also support setting values for RUN
> > and IDLE too - thus this has not been such a fatal issue.
> > 
> > Fix this by defining the old enum values as bits and fixing the
> > parsing code. This allows keeping existing IC specific drivers
> > intact and only slightly changing the rohm-regulator.c
> > 
> > Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common
> > and bd718x7 specific parts")
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
> > ---
> > 
> > I just noticed this fix never made it in-tree. So this is a resend
> > of a
> > resend :)
> 
> Not sure what you mean.  Isn't this patch part of:
> 
>   [PATCH v2 00/17] Support ROHM BD71815 PMIC
> 
> ... which has just been reviewed and is awaiting rework?

Sorry for the confusion Lee.
It was originally part of the series but I did intend to submit it
separately. That's because it is a bugfix for existing drivers - and
because the  series "[PATCH v2 00/17] Support ROHM BD71815 PMIC"
is expected to take some time as it needs to wait the dependency
patches to get merged in relevant sub-systems. (The parent-data removal
patches to gpio, regulator and clk).

So my thinking was that that fix could've been merged in as it's own
patch to get existing things fixed in next release. I could then rebase
the "PATCH v2 00/17] Support ROHM BD71815 PMIC" - series on top of this
when it is in-tree.

I think I should have communicated this better. Sorry.

Please let me know what works for you guys the best.

Best Regards
    Matti Vaittinen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ