linux-kernel - Re: [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API

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: <CAOY=C6HTRFY=rXOAhTwuR3NvtaRFbfbkkpn7FeyK+eqG7sVcKg@mail.gmail.com>
Date:	Mon, 28 Jan 2013 12:39:05 +0100
From:	Stijn Devriendt <highguy@...il.com>
To:	Roland Stigge <stigge@...com.de>
Cc:	gregkh@...uxfoundation.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de,
	jbe@...gutronix.de, plagnioj@...osoft.com,
	broonie@...nsource.wolfsonmicro.com, daniel-gl@....net,
	rmallon@...il.com, sr@...x.de, wg@...ndegger.com,
	mark.rutland@....com, nicolas.ferre@...el.com
Subject: Re: [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API

On Sun, Jan 27, 2013 at 3:29 PM, Roland Stigge <stigge@...com.de> wrote:
> On 27/01/13 14:07, Stijn Devriendt wrote:
>>> +Example:
>>> +
>>> +        blockgpio {
>>> +                compatible = "linux,gpio-block";
>>> +
>>> +                block0 {
>>> +                        gpios = <&gpio 3 0 0>,
>>> +                                <&gpio 3 1 0>;
>>> +                };
>>> +                block1 {
>>> +                        gpios = <&gpio 4 1 0>,
>>> +                                <&gpio 4 3 0>,
>>> +                                <&gpio 4 2 0>,
>>> +                                <&gpio 4 4 0>,
>>> +                                <&gpio 4 5 0>,
>>> +                                <&gpio 4 6 0>,
>>> +                                <&gpio 4 7 0>,
>>> +                                <&gpio 4 8 0>,
>>> +                                <&gpio 4 9 0>,
>>> +                                <&gpio 4 10 0>,
>>> +                                <&gpio 4 19 0>;
>>> +                };
>>> +        };
>>
>> How do you see bindings for other kinds of drivers?
>>
>> In my patchset, it's possible for other drivers to use gpio-blocks.
>> One example we have is a power sequencer with 2 pins attached
>> to GPIO pins. These 2 pins form a 2bit word to select power margining.
>> These 2 pins need to be set synchronously (as otherwise when going
>> from profile 0 to profile 3 you pass either profile 1 or profile 2 which
>> could be bad for hardware)
>>
>> In the device-tree this is specified as:
>>
>> powr@...0 {
>>    // other properties
>>
>>   gpios = <&gpio 4 0
>>                &gpio 5 0>;
>> };
>>
>> Is this kind of integration also possible?
>
> You can reference the gpio block via a phandle, e.g.:
>
>         blockgpio {
>                 compatible = "linux,gpio-block";
>
>                 selector1 {
>                         gpios = <&gpio 4 0>,
>                                 <&gpio 5 0>;
>                 };
>         };
>
>         powr@...0 {
>                 // ...
>
>                 gpios = <&selector1>;
>         };
>
>
> In the driver, you can get the gpio block like this:
>
> block = gpio_block_find_by_name(of_parse_phandle(powr, "gpios", 0)->name);
>
> (Simplified by removed error/NULL handling!)
>
> If this turns out to be a common pattern, I can add a convenience "get"
> function for this.

Given the pick-up of device-tree in ARM and MIPS, I think this stands
a good chance
of becoming a common pattern. Do mind the "gpios" name; it's already used by the
normal GPIO request functions...

This is one of the things I liked about my patch, there's little
difference between
using a group of GPIOs versus multiple separate GPIOs. The device-tree
description
is the same, only the driver handles them differently.
You could ask the question whether the device-tree should make a
difference between
1 GPIO, 2 separate GPIOs or 3 GPIOs in a block. For a H/W description
language it's
all the same. It is an implementation detail of the OS/drivers whether
they handle them
as a block or as separate GPIOs.

Regards,
Stijn
--
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/