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:	Tue, 26 May 2015 13:41:56 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Linus Walleij <linus.walleij@...aro.org>
CC:	linux-arm-kernel@...ts.infradead.org,
	Stéphane Marchesin 
	<stephane.marchesin@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Alexander Holler <holler@...oftware.de>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Alexandre Courbot <gnurou@...il.com>,
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/21] ARM: tegra: Add gpio-ranges property

On 05/25/2015 08:53 AM, Tomeu Vizoso wrote:
> Specify how the GPIOs map to the pins in T124, so the dependency is
> explicit.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
> ---
>   arch/arm/boot/dts/tegra124.dtsi | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> index 13cc7ca..5d1d35f 100644
> --- a/arch/arm/boot/dts/tegra124.dtsi
> +++ b/arch/arm/boot/dts/tegra124.dtsi
> @@ -254,6 +254,7 @@
>   		gpio-controller;
>   		#interrupt-cells = <2>;
>   		interrupt-controller;
> +		gpio-ranges = <&pinmux 0 0 250>;

We should be consistent between SoCs. Why not make the same change for 
all Tegra SoCs?

I think this change will cause the GPIO subsystem to call into the 
pinctrl subsystem and create/add/register a new GPIO<->pinctrl range 
structure. The pinctrl driver already does this, so I think we'll end up 
with two duplicate entries in the pinctrl device's gpio_ranges list. 
This probably won't cause a problem, but I wanted to make sure you'd 
thought about it to make sure.

Right now, I think we get lucky and pinctrl ends up probing first (or at 
least very early) anyway. Somewhat related to this series, I wonder if 
we shouldn't add pinctrl client properties to every node in the Tegra DT 
that describes a controller that makes use of external pins that are 
affected by the pinmux. Such a change would guarantee this desired 
probing order. In order to preserve the "program the entire pinmux at 
once" semantics, these new pinctrl client properties would all need to 
reference empty states, yet would still need to exist to represent the 
dependency.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ