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@xxxxxxxxxxxxxxxx> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
