linux-kernel - Re: [PATCH v4 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]

Message-ID: <20140417115820.GD4132@lukather>
Date:	Thu, 17 Apr 2014 13:58:20 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	linux-kernel@...r.kernel.org,
	Arnd Bergmann Arnd Bergmann <arnd@...db.de>,
	Mark Rutland <mark.rutland@....com>,
	Roger Quadros <rogerq@...com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	kernel@...gutronix.de
Subject: Re: [PATCH v4 1/2] Documentation: Add GPIO reset binding to reset
 binding documentation

On Mon, Apr 14, 2014 at 10:21:48AM +0200, Philipp Zabel wrote:
> This patch adds documentation clarifying the reset GPIO bindings most
> commonly in use (reset-gpios and <name>-reset-gpios properties).
> 
> Signed-off-by: Philipp Zabel <p.zabel@...gutronix.de>
> ---
>  Documentation/devicetree/bindings/reset/reset.txt | 26 +++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
> index 31db6ff..51f9e35 100644
> --- a/Documentation/devicetree/bindings/reset/reset.txt
> +++ b/Documentation/devicetree/bindings/reset/reset.txt
> @@ -2,8 +2,8 @@
>  
>  This binding is intended to represent the hardware reset signals present
>  internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
> -standalone chips are most likely better represented as GPIOs, although there
> -are likely to be exceptions to this rule.
> +standalone chips are most likely better represented as GPIOs, ideally using a
> +common scheme as described below.
>  
>  Hardware blocks typically receive a reset signal. This signal is generated by
>  a reset provider (e.g. power management or clock module) and received by a
> @@ -56,6 +56,20 @@ reset-names:	List of reset signal name strings sorted in the same order as
>  		the resets property. Consumers drivers will use reset-names to
>  		match reset signal names with reset specifiers.
>  
> += 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 still feel like we should really treat gpios like just another reset
controller, ie. using the resets property.

I understand that you chose this pattern to be pretty much compatible
with what have been done so fare, bu I don't see how to fulfill that
goal completely, since most of the devices are actually using
reset-gpios, but some are using other names too (including
reset-gpio).

So if we can't be fully backward compatible, I don't see the benefit
of being inconsistent with how reset controllers are used in general,
and more globally on how gpios are tied for regulators for example.

That would also make reset-gpio a regular reset driver, instead of
adding logic to the core itself to handle this special case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)