On 05/28/14 10:12, Mark Brown wrote:

On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-König wrote:

quoted

On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote:

quoted

On 05/24/14 05:48, Mark Brown wrote:

quoted

So, according to the datasheet I managed to find this device has a
supply VDD_IO (so normally written vdd-io-supply here), some other
supplies which are tied to VDD_IO (so can probably be omitted) and a
supply VDD_A3.3 none of which are optional.  There is an internal
regulator which can be used to drop a higher voltage VDD_IO down for
some of the supplies tied to it but that's essentially a noop from
software as far as I can tell.  None of these supplies are obviously
optional, though I've not read the datasheet in detail so I may have
missed something here.

There is a difference between the supply being optional for the hardware
to work and the need to specify it in the device tree, isn't it? My
expectation is that when it's not specified there is just nothing the
the software needs to care for. 

If the supply must always be physically present the bindings should be
specified as it being mandatory and the code written in that fashion; as
an extension Linux will put a dummy in but this is attempting to handle
incorrect DTs.  This means we have functional error handling in cases
where there is something to worry about and simplifies the code using
the regulator.

Ok, you're saying the opposite of Rob. Should it be required or optional
in the DT binding?

regulator_get_optional() should *only* be used if the supply may be
omitted from the physical design and should generally always be
accompanied by code which does something substantially different such as
using an internal regulator or changing the source for a reference
voltage instead.

Ok. Dave M has already picked up all these patches so I'll send a patch
to replace regulator_get_optional() with regulator_get() and fix up the
error handling unless I hear otherwise.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html