linux-kernel - Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation

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]

Date:	Thu, 06 Feb 2014 16:44:18 +0100
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de, Roger Quadros <rogerq@...com>,
	Mark Rutland <mark.rutland@....com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Stephen Warren <swarren@...dotorg.org>
Subject: Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset
 binding documentation

Hi Arnd,

Am Freitag, den 10.01.2014, 12:25 +0100 schrieb Philipp Zabel:
> 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

do you have further comments on this?

I'd like to request a pull of the changes in
http://git.pengutronix.de/?p=pza/linux.git;a=shortlog;h=refs/heads/reset/for_v3.15
and I wonder whether I should submit that now without the GPIO patches
or hold it back a bit and add them on top.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/