linux-kernel - Re: [PATCH 01/03] Make non-linear GPIO ranges accesible from gpiolib

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, 10 Oct 2013 14:47:24 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Christian Ruppert <christian.ruppert@...lis.com>
CC:	Patrice CHOTARD <patrice.chotard@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Sascha Leuenberger <sascha.leuenberger@...lis.com>,
	Pierrick Hascoet <pierrick.hascoet@...lis.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 01/03] Make non-linear GPIO ranges accesible from gpiolib

On 10/09/2013 05:58 AM, Linus Walleij wrote:
> On Tue, Oct 8, 2013 at 2:25 PM, Christian Ruppert
> <christian.ruppert@...lis.com> wrote:
>> This patch adds the infrastructure required to register non-linear gpio
>> ranges through gpiolib and the standard GPIO device tree bindings.
...
>> +Example:
>> +
>> +       gpio_pio_i: gpio-controller@...0 {
>> +               #gpio-cells = <2>;
>> +               compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
>> +               reg = <0x1480 0x18>;
>> +               gpio-controller;
>> +               gpio-ranges =                   <&pinctrl1 0 20 10>,
>> +                                               <&pinctrl2 10 0 0>,
>> +                                               <&pinctrl1 15 0 10>,
>> +                                               <&pinctrl2 25 0 0>;
>> +               gpio-ranges-group-names =       "",
>> +                                               "foo",
>> +                                               "",
>> +                                               "bar";
>> +       };
> 
> And here, I get a bit uneasy as I remember Stephen's stance that such
> groups must be a physical property of the controller. I am generally a
> bit soft on that, but that is from a driver point of view, and describing
> hardware in the devicetree must be reflecting an objective view of the
> hardware, not how the particular driver is written for Linux.
> 
> This is very questionable :-/

I think describing the GPIO ranges is an aspect of the HW; it's
describing actual routing of signal lines between the GPIO and pinctrl
HW blocks. It seems reasonable for DT to describe that concept (although
perhaps the actual mapping could be part of some driver rather than DT,
but that's a separate issue).

Using groups to describe aspects of this mapping doesn't seem totally
unreasonable either. We have named groups for muxing, which is a real HW
property. We can have named groups for GPIO/pinctrl routing, which again
is a HW property. Certainly in the muxing case, and hopefully for this
case too, the naming of those groups is driven purely by the HW design
of the SoC top-level or GPIO/pinctrl HW blocks, and hence it's
reasonable for a DT binding to define (or rather, use) those names.
Hopefully different OSs don't use different names for the groups, since
the naming is derived directly from HW.
--
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/