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: <20140814151958.GY17528@sirena.org.uk>
Date:	Thu, 14 Aug 2014 16:19:58 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Tim Kryger <tim.kryger@...il.com>
Cc:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Chris Ball <chris@...ntf.net>,
	Seungwon Jeon <tgih.jun@...sung.com>,
	Tim Kryger <tim.kryger@...aro.org>,
	Haijun Zhang <Haijun.Zhang@...escale.com>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olof@...om.net>,
	Yuvaraj Kumar C D <yuvaraj.cd@...il.com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask
 is empty.

On Thu, Aug 14, 2014 at 07:13:00AM -0700, Tim Kryger wrote:
> On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas

> > Without this patch, the following warning is reported when
> > a FET is used as a vmmc-supply:

> > dwmmc_exynos 12220000.mmc: Failed getting OCR mask: -22

> > Signed-off-by: Javier Martinez Canillas <javier.martinez@...labora.co.uk>

> https://lkml.org/lkml/2014/8/12/377

For the benefit of those reading here 

> Perhaps I misunderstood the discussion in that thread but couldn't
> this failure also be addressed by adding proper constraints for each
> FET in individual DTS files to reflect the range of voltages that are
> safe for all consumers of that supply on the board?

> I thought the main concern with your other change was that the
> constraints you listed in the DTSI represented the limits of the PMIC
> and not the consumers.

Right, there's two things going on here.  One is that as you describe we
shouldn't be putting constraints in .dtsi files if we don't know they're
OK for a given board.  The other thing is that on this particular board
it turns out that there's no support for varying the voltages at all so
it doesn't make sense to have to specify a range, there's only one value
anyway so the software really should be able to figure out that fixed
value all by itself.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ