linux-kernel - Re: [PATCH v2] pinctrl: bcm2835: Start GPIO numeration at zero

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] [day] [month] [year] [list]

Date:	Sat, 1 Nov 2014 15:13:31 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Matthias Klein <matthias.klein@...ux.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-rpi-kernel@...ts.infradead.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] pinctrl: bcm2835: Start GPIO numeration at zero

On Fri, Oct 31, 2014 at 6:49 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Tue, Oct 28, 2014 at 12:05 AM, Matthias Klein
> <matthias.klein@...ux.com> wrote:
>> Am 27.10.2014 um 23:44 schrieb Stephen Warren:
>
>>> What's the motivation for this? The GPIO IDs should all come from DT,
>>> which encodes everything as an ID relative to a particular controllers, and
>>> hence the actual value of the base address should be irrelevant.
>>
>> - To be in sync with the GPIO numbers in the datasheet / documentation
>
> We are moving away from global GPIO numbers because they are
> an eternal pain. We would replace them with a local offset number
> just as the second column in /proc/interrupts
>
> Hm we should patch <debugfs/gpio> to show local offsets...
>
>> - For userland applications which rely on these GPIO numbers
>
> ARGH!!!
>
> A much better idea is to add labels to your GPIOs so you can
> identify them by name. Augment the driver with labeling capability
> if need be, see e.g. commit 781f6d710d4482eab05cfaad50060a0ea8c0e4e0
> "gpio: generic: Add label to platform data"
>
> You just need to figure out how to do the same naming from the
> device tree. Maybe some new binding is needed, others are
> discussing how to do exporting of GPIOs from devicetree
> anyway, see the mailing list.

On a related note we are feeling more and more pressure for a way to
unambiguously access GPIOs from user-space, and we should probably try
and come with a solution for this. Ideas so far:

1) Export GPIOs with a name - it seems like this one will happen soon.

2) Export GPIOs using their controller-relative number (instead of
their global number) under the controller's sysfs node. But since
controllers are also named after the first global number they manage,
we would still have a problem here.

In any case this reliance of user-space on particular GPIO numbers is
becoming a burden. We will soon get rid of the global
ARCH_NR_GPIOS-sized array of gpio_descs, and the next step would be to
get rid of the ARCH_NR_GPIOS itself. However, this macro is used to
decide the starting number for GPIO chips without an explicit "base"
attribute, so I am not sure whether we can remove it at all, unless we
can agree that GPIO numbers are variable and not part of the ABI.
--
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/