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:	Tue, 29 Mar 2016 07:58:23 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Bjorn Andersson <bjorn@...o.se>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH 2/2] regulator: core: Ensure we are at least in bounds
 for our constraints

On Tue, Mar 29, 2016 at 02:00:52PM +0200, Geert Uytterhoeven wrote:
> On Sun, Mar 27, 2016 at 11:08 AM, Mark Brown <broonie@...nel.org> wrote:

> > The existing check in the patch should be an || not an ==, or possibly
> > we should just not bother looking for min_uV at all.  I just pushed out
> > a version of that, let's see how that goes.

> Has the fix really been pushed out?

Yes.

> WARNING: CPU: 1 PID: 31 at drivers/regulator/core.c:2223
> _regulator_disable+0x2c/0x128
> unbalanced disables for SDHI0 VccQ

> when booting on r8a7791/koelsch.

This seems like a bug somewhere else in your code, we're looking at
changes in the voltage setting code but this is an unbalanced disable.

> I'm a bit confused by the discussion of "&&" vs. "||" vs. "==", but the
> warnings do go away when using "!=", cfr. the whitespace-damaged patch below.

>         /* Voltage change possible? */
> -       if (constraints->min_uV && constraints->max_uV) {
> +       if (constraints->min_uV != constraints->max_uV) {

Do you have constraints that specify a maximum voltage but no minimum
(which I'd say are broken), or constraints that are just plain wrong but
are now being applied like specifying the entire range of the regulator?
The above might be some follow on error handling from something that
happened the change in handling of the constraints.  You need to look at
what the relevant regulator constraints are...

Previously both voltages needed to be non-zero and equal for anything to
happen, now they only need to both be non-zero.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ