From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "Uwe Kleine-König"
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
"David S . Miller"
<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
"Nishanth Menon" <nm-l0cyMroinI0@public.gmane.org>,
"Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"Pawel Moll" <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
"Ian Campbell"
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Kumar Gala" <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
Date: Wed, 28 May 2014 12:44:35 -0700 [thread overview]
Message-ID: <53863CA3.7040000@codeaurora.org> (raw)
In-Reply-To: <20140528171219.GD5099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 05/28/14 10:12, Mark Brown wrote:
> On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-König wrote:
>> On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote:
>>> On 05/24/14 05:48, Mark Brown wrote:
>>>> 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
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
Date: Wed, 28 May 2014 12:44:35 -0700 [thread overview]
Message-ID: <53863CA3.7040000@codeaurora.org> (raw)
In-Reply-To: <20140528171219.GD5099@sirena.org.uk>
On 05/28/14 10:12, Mark Brown wrote:
> On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-K?nig wrote:
>> On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote:
>>> On 05/24/14 05:48, Mark Brown wrote:
>>>> 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
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mark Brown <broonie@kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"David S . Miller" <davem@davemloft.net>,
"Nishanth Menon" <nm@ti.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Pawel Moll" <pawel.moll@arm.com>,
"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
linux-arm-msm@vger.kernel.org,
"Kumar Gala" <galak@codeaurora.org>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Rob Herring" <robh+dt@kernel.org>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
Date: Wed, 28 May 2014 12:44:35 -0700 [thread overview]
Message-ID: <53863CA3.7040000@codeaurora.org> (raw)
In-Reply-To: <20140528171219.GD5099@sirena.org.uk>
On 05/28/14 10:12, Mark Brown wrote:
> On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-König wrote:
>> On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote:
>>> On 05/24/14 05:48, Mark Brown wrote:
>>>> 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
next prev parent reply other threads:[~2014-05-28 19:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 19:57 [PATCH v2 0/4] ks8851 DT/regulator/gpio updates Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-23 19:57 ` [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-24 12:20 ` Mark Brown
2014-05-24 12:20 ` Mark Brown
2014-05-24 12:48 ` Mark Brown
2014-05-24 12:48 ` Mark Brown
2014-05-27 21:40 ` Stephen Boyd
2014-05-27 21:40 ` Stephen Boyd
2014-05-28 9:44 ` Mark Brown
2014-05-28 9:44 ` Mark Brown
2014-05-28 15:16 ` Uwe Kleine-König
2014-05-28 15:16 ` Uwe Kleine-König
2014-05-28 16:38 ` Rob Herring
2014-05-28 16:38 ` Rob Herring
2014-05-28 17:12 ` Mark Brown
2014-05-28 17:12 ` Mark Brown
[not found] ` <20140528171219.GD5099-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2014-05-28 19:44 ` Stephen Boyd [this message]
2014-05-28 19:44 ` Stephen Boyd
2014-05-28 19:44 ` Stephen Boyd
2014-05-28 19:49 ` Mark Brown
2014-05-28 19:49 ` Mark Brown
2014-05-23 19:57 ` [PATCH v2 2/4] net: ks8851: Use devm_regulator_get_optional() Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-23 19:57 ` [PATCH v2 3/4] net: ks8851: Add optional vdd_io regulator and reset gpio Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-23 19:57 ` [PATCH v2 4/4] net: ks8851: Add of match table Stephen Boyd
2014-05-23 19:57 ` Stephen Boyd
2014-05-24 18:03 ` [PATCH v2 0/4] ks8851 DT/regulator/gpio updates David Miller
2014-05-24 18:03 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53863CA3.7040000@codeaurora.org \
--to=sboyd-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nm-l0cyMroinI0@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.