From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Subject: Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation
Date: Fri, 10 Jan 2014 12:25:36 +0100 [thread overview]
Message-ID: <1389353136.5854.13.camel@pizza.hi.pengutronix.de> (raw)
In-Reply-To: <201401081708.26679.arnd-r2nGTMty4D4@public.gmane.org>
Hi Arnd,
Am Mittwoch, den 08.01.2014, 17:08 +0100 schrieb Arnd Bergmann:
> On Wednesday 08 January 2014, Philipp Zabel wrote:
> > += GPIO Reset consumers =
> > +
> > +For the common case of reset lines controlled by GPIOs, the GPIO binding
> > +documented in devicetree/bindings/gpio/gpio.txt should be used:
> > +
> > +Required properties:
> > +reset-gpios or Reset GPIO using standard GPIO bindings,
> > +<name>-reset-gpios: optionally named to specify the reset line
> > +
> > +Optional properties:
> > +reset-boot-asserted or Boolean. If set, the corresponding reset is
> > +<name>-reset-boot-asserted: initially asserted and should be kept that way
> > + until released by the driver.
>
> I don't get this one. Why would you use a different reset binding for the case
> where the reset line is connected to the gpio controller rather than a
> specialized reset controller?
>
> I was expecting to see the definition of a generic reset controller that
> in turn uses gpio lines, like
>
>
> reset {
> compatible = "gpio-reset";
> /* provides three reset lines through these GPIOs */
> gpios = <&gpioA 1 &gpioB 7 <gpioD 17>;
> #reset-cells = <1>;
> };
>
> foo {
> ...
> resets = <&reset 0>; /* uses first reset line of the gpio-reset controller */
> };
That is what I initially proposed...
> I realize it would be a little more verbose, but it also seems more
> regular and wouldn't stand out from the rest of the reset interfaces.
... but it can also be argued that GPIO resets shouldn't stand out from
other GPIOs.
Mark Rutland spoke out against having a 'GPIO reset device' node in the
device tree:
http://comments.gmane.org/gmane.linux.drivers.devicetree/41596
and I see his point. Using different bindings for reset controller IPs
and for single GPIOs better describes the actual hardware and it is less
Linux specific: it still allows an OS without gpio-reset framework to
let each driver handle the GPIO itself.
Also Stephen Warren pointed out that we'll have to support the existing
GPIO bindings anyway: in the meantime there are a lot of GPIO resets in
various device trees that use the GPIO bindings.
regards
Philipp
--
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
next prev parent reply other threads:[~2014-01-10 11:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 11:11 [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Philipp Zabel
[not found] ` <1389179464-11963-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-01-08 11:11 ` [PATCH v3 2/2] reset: Add GPIO support to reset controller framework Philipp Zabel
2014-01-08 16:08 ` [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Arnd Bergmann
[not found] ` <201401081708.26679.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-10 11:25 ` Philipp Zabel [this message]
[not found] ` <1389353136.5854.13.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-02-06 15:44 ` Philipp Zabel
[not found] ` <1391701458.5008.15.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-02-14 10:20 ` Philipp Zabel
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=1389353136.5854.13.camel@pizza.hi.pengutronix.de \
--to=p.zabel-bicnvbalz9megne8c9+irq@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=rogerq-l0cyMroinI0@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).