linux-kernel - Re: [PATCH v5 1/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding

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: <20150113114101.GO12302@n2100.arm.linux.org.uk>
Date:	Tue, 13 Jan 2015 11:41:01 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Walleij <linus.walleij@...aro.org>
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 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.

So, what I'm saying is be very careful about moving to a fully
dynamic space: you could end up breaking userspace if you do.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/