[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140815095528.GH17528@sirena.org.uk>
Date: Fri, 15 Aug 2014 10:55:28 +0100
From: Mark Brown <broonie@...nel.org>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc: Tim Kryger <tim.kryger@...il.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Chris Ball <chris@...ntf.net>,
Seungwon Jeon <tgih.jun@...sung.com>,
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 Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote:
> But now I wonder why regulator_list_voltage() even list the voltage for
> fixed regulators (desc->fixed_uV) since they don't have the ability to
> vary voltage. The regulator_list_voltage() documentation says:
That's because it's very cheap to do and there is a comprehensible thing
we can return - if we have to read the voltage that means potentially
asking the hardware in an I2C transaction which is not cheap.
> > It seems odd to make callers be the ones to handle this subtlety.
> If regulator_list_voltage() didn't list the voltage for fixed regulators,
> then this subtlety should had been handled by callers before but they
> didn't because they rely on regulator_list_voltage() to always return a
> voltage even for fixed regulators.
There's plenty of potentially variable regulators used in these
situations, I expect it's more likely that people were just ignoring the
warning since it has no practical effect.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists