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:	Fri, 16 Jan 2015 11:18:37 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Arnd Bergmann <arnd@...db.de>, Ray Jui <rjui@...adcom.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	Christian Daudt <bcm@...thebug.org>,
	Matt Porter <mporter@...aro.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Joe Perches <joe@...ches.com>,
	Scott Branden <sbranden@...adcom.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v5 1/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding

On Tue, Jan 13, 2015 at 12:41 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Tue, Jan 13, 2015 at 09:06:15AM +0100, Linus Walleij wrote:
>> On Wed, Dec 17, 2014 at 11:44 AM, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > On Wed, Dec 17, 2014 at 11:45:01AM +0900, Alexandre Courbot wrote:
>> >> Actually we are not that far from being able to do completely without
>> >> any GPIO number, and maybe that's what we should aim for. I think the
>> >> only remaining offender is the sysfs interface.
>> >
>> > And that is a user API, and there's lots of users of it (eg, on Raspberry
>> > Pi platforms.)  So changing it isn't going to be easy - I'd say that it's
>> > impractical.
>> >
>> > What you're suggesting would be like re-numbering Linux syscalls.
>>
>> The problem is that right now if we set the .base of a gpio_chip
>> to -1 for dynamic allocation of GPIO numbers and we have more
>> than one GPIO chip in the system, the numbers basically depend
>> on probe order, and may theoretically even differ between two boots.
>>
>> So in these cases preserving the ABI means preserving the
>> unpredictability of these assigned numbers or something.
>>
>> For the old usecases with a single GPIO controller and a fixed
>> base offset of e.g. 0 (which I suspect was implicit in the initial
>> design of the subsystem) things work fine as always, it's these new
>> dynamic use cases that destabilize the ABI.
>
> Since GPIOs are exported through sysfs into userland by GPIO number,
> and we know that there are users of it (see
> https://github.com/pilight/wiringX) which hard encode GPIO numbers,
> so this is *really* something that we as kernel developers can't
> change without breaking such users.

I agree.

In some other thread I came up with the idea that if
we add enumerated aliases for the GPIO controllers in the
device tree (so that each can be assigned a sequence number,
like we do on the PL011 ttys) we can assign them numbers
starting from 0.

The only reason that dynamic GPIO start from some random
high offset is that the on-chip GPIOs are assumed to be present
at offset 0+, so this is done so that the dynamic controllers
avoid colliding with them. (At least that is how I understand it.)
So on a fully DT-enabled system assigning numbers starting
from 0 should be kind of default.

Yours,
Linus Walleij
--
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