| Message ID | 1418342706-14755-2-git-send-email-rjui@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 11 December 2014 16:05:04 Ray Jui wrote: > + > +- linux,gpio-base: > + Base GPIO number of this controller > + > We've NAK'ed properties like this multiple times before, and it doesn't get any better this time. What are you trying to achieve here? Arnd
On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Thursday 11 December 2014 16:05:04 Ray Jui wrote: >> + >> +- linux,gpio-base: >> + Base GPIO number of this controller >> + >> > > We've NAK'ed properties like this multiple times before, and it > doesn't get any better this time. What are you trying to achieve > here? I am to blame for suggesting using this property to Ray, and I am fully aware that this has been rejected before, but look at what people came with recently to palliate the lack of control over the GPIO number space for DT platforms: http://www.spinics.net/lists/arm-kernel/msg384847.html https://lkml.org/lkml/2014/12/10/133 Right now GPIO numbering for platforms using DT is a very inconsistent process, subject to change by the simple action of adjusting the value of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO controller, or changing the probe order of devices. For users of the integer or sysfs interfaces, this results in GPIO numbers that change, and drivers and/or user-space programs that behave incorrectly. Ironically, the only way to have consistent numbers is to use the old platform files, where you can specify the base number of a gpio_chip. DT is actually probably not such a bad place to provide consistency in GPIO numbering. It has a global vision of the system layout, including all GPIO controllers and the number of GPIOs they include, and thus can make informed decisions. It provides a consistent result regardless of probe order. And allowing it to assign GPIO bases to controllers will free us from the nonsensical dependency of some arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it since we don't need it anymore after the removal of the global gpio_descs array. This will again interfere with the numbering of GPIO chips that do not have a base number provided. Note that I don't really like this, either - but the problem is the GPIO integer interface. Until everyone has upgraded to gpiod and we have a replacement for the current sysfs interface (this will take a while) we have to cope with this. This issue has been bothering users for years, so this time I'd like to try and solve it the less ugly way. If there is a better solution, of course I'm all for it.
On Friday 12 December 2014 22:05:37 Alexandre Courbot wrote: > On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Thursday 11 December 2014 16:05:04 Ray Jui wrote: > >> + > >> +- linux,gpio-base: > >> + Base GPIO number of this controller > >> + > >> > > > > We've NAK'ed properties like this multiple times before, and it > > doesn't get any better this time. What are you trying to achieve > > here? > > I am to blame for suggesting using this property to Ray, and I am > fully aware that this has been rejected before, but look at what > people came with recently to palliate the lack of control over the > GPIO number space for DT platforms: > > http://www.spinics.net/lists/arm-kernel/msg384847.html > https://lkml.org/lkml/2014/12/10/133 > > Right now GPIO numbering for platforms using DT is a very inconsistent > process, subject to change by the simple action of adjusting the value > of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO > controller, or changing the probe order of devices. For users of the > integer or sysfs interfaces, this results in GPIO numbers that change, > and drivers and/or user-space programs that behave incorrectly. > Ironically, the only way to have consistent numbers is to use the old > platform files, where you can specify the base number of a gpio_chip. > > DT is actually probably not such a bad place to provide consistency in > GPIO numbering. It has a global vision of the system layout, including > all GPIO controllers and the number of GPIOs they include, and thus > can make informed decisions. It provides a consistent result > regardless of probe order. And allowing it to assign GPIO bases to > controllers will free us from the nonsensical dependency of some > arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on > us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it > since we don't need it anymore after the removal of the global > gpio_descs array. This will again interfere with the numbering of GPIO > chips that do not have a base number provided. > > Note that I don't really like this, either - but the problem is the > GPIO integer interface. Until everyone has upgraded to gpiod and we > have a replacement for the current sysfs interface (this will take a > while) we have to cope with this. This issue has been bothering users > for years, so this time I'd like to try and solve it the less ugly > way. If there is a better solution, of course I'm all for it. I think the scheme will fail if you ever get gpio controllers that are not part of the DT: We have hotpluggable devices (PCI, USB, ...) that are not represented in DT and that may also provide GPIOs for internal uses. The current state of affairs is definitely problematic, but defining the GPIO numbers in DT properties would only be a relative improvement, not a solution, and I fear it would make it harder to change the kernel to remove the gpio numbers eventually. I wonder if we could instead come up with an approach that completely randomizes the gpio numbers (as a compile-time option) to find any places that still rely on specific numbers. Arnd
On 12/12/2014 5:05 AM, Alexandre Courbot wrote: > On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Thursday 11 December 2014 16:05:04 Ray Jui wrote: >>> + >>> +- linux,gpio-base: >>> + Base GPIO number of this controller >>> + >>> >> >> We've NAK'ed properties like this multiple times before, and it >> doesn't get any better this time. What are you trying to achieve >> here? > > I am to blame for suggesting using this property to Ray, and I am > fully aware that this has been rejected before, but look at what > people came with recently to palliate the lack of control over the > GPIO number space for DT platforms: > > http://www.spinics.net/lists/arm-kernel/msg384847.html > https://lkml.org/lkml/2014/12/10/133 > > Right now GPIO numbering for platforms using DT is a very inconsistent > process, subject to change by the simple action of adjusting the value > of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO > controller, or changing the probe order of devices. For users of the > integer or sysfs interfaces, this results in GPIO numbers that change, > and drivers and/or user-space programs that behave incorrectly. > Ironically, the only way to have consistent numbers is to use the old > platform files, where you can specify the base number of a gpio_chip. > > DT is actually probably not such a bad place to provide consistency in > GPIO numbering. It has a global vision of the system layout, including > all GPIO controllers and the number of GPIOs they include, and thus > can make informed decisions. It provides a consistent result > regardless of probe order. And allowing it to assign GPIO bases to > controllers will free us from the nonsensical dependency of some > arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on > us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it > since we don't need it anymore after the removal of the global > gpio_descs array. This will again interfere with the numbering of GPIO > chips that do not have a base number provided. > > Note that I don't really like this, either - but the problem is the > GPIO integer interface. Until everyone has upgraded to gpiod and we > have a replacement for the current sysfs interface (this will take a > while) we have to cope with this. This issue has been bothering users > for years, so this time I'd like to try and solve it the less ugly > way. If there is a better solution, of course I'm all for it. > Agreed. Since we are just starting to upstream all of our drivers for iProc/Cygnus, enforcing all of our new drivers to use the gpiod interface is not an issue and is something that should be done. Our current issue is really on the sysfs interface, as I mentioned earlier, a lot of our customers use the sysfs interface for GPIO access. Until the sysfs interface issue is resolved, we sort of need a way to maintain the GPIO base between different GPIO controllers.
On 12/12/2014 7:28 AM, Arnd Bergmann wrote: > On Friday 12 December 2014 22:05:37 Alexandre Courbot wrote: >> On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Thursday 11 December 2014 16:05:04 Ray Jui wrote: >>>> + >>>> +- linux,gpio-base: >>>> + Base GPIO number of this controller >>>> + >>>> >>> >>> We've NAK'ed properties like this multiple times before, and it >>> doesn't get any better this time. What are you trying to achieve >>> here? >> >> I am to blame for suggesting using this property to Ray, and I am >> fully aware that this has been rejected before, but look at what >> people came with recently to palliate the lack of control over the >> GPIO number space for DT platforms: >> >> http://www.spinics.net/lists/arm-kernel/msg384847.html >> https://lkml.org/lkml/2014/12/10/133 >> >> Right now GPIO numbering for platforms using DT is a very inconsistent >> process, subject to change by the simple action of adjusting the value >> of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO >> controller, or changing the probe order of devices. For users of the >> integer or sysfs interfaces, this results in GPIO numbers that change, >> and drivers and/or user-space programs that behave incorrectly. >> Ironically, the only way to have consistent numbers is to use the old >> platform files, where you can specify the base number of a gpio_chip. >> >> DT is actually probably not such a bad place to provide consistency in >> GPIO numbering. It has a global vision of the system layout, including >> all GPIO controllers and the number of GPIOs they include, and thus >> can make informed decisions. It provides a consistent result >> regardless of probe order. And allowing it to assign GPIO bases to >> controllers will free us from the nonsensical dependency of some >> arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on >> us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it >> since we don't need it anymore after the removal of the global >> gpio_descs array. This will again interfere with the numbering of GPIO >> chips that do not have a base number provided. >> >> Note that I don't really like this, either - but the problem is the >> GPIO integer interface. Until everyone has upgraded to gpiod and we >> have a replacement for the current sysfs interface (this will take a >> while) we have to cope with this. This issue has been bothering users >> for years, so this time I'd like to try and solve it the less ugly >> way. If there is a better solution, of course I'm all for it. > > I think the scheme will fail if you ever get gpio controllers that are > not part of the DT: We have hotpluggable devices (PCI, USB, ...) that > are not represented in DT and that may also provide GPIOs for internal > uses. > > The current state of affairs is definitely problematic, but defining > the GPIO numbers in DT properties would only be a relative improvement, > not a solution, and I fear it would make it harder to change the kernel > to remove the gpio numbers eventually. > > I wonder if we could instead come up with an approach that completely > randomizes the gpio numbers (as a compile-time option) to find any > places that still rely on specific numbers. > > Arnd > Okay, if people think defining the GPIO base number in DT properties as a temporary, transient solution is not acceptable, I can switch the driver to use dynamic GPIO number allocation (by setting gpio base to a negative number and let gpiochip_add find a usable base number). Like I said previously, dynamic GPIO allocation works fine in the kernel, as long as all of our GPIO clients in the kernel use gpiod based API, which is what we will enforce going forward. The only problem is with some of our customers who use GPIO through sysfs and expect fixed global GPIO numbers. Thinking about this more, it's probably not that difficult to add a script for those customers to convert/map the GPIO numbers based on readings parsed from sysfs, so I guess that's fine. I'll submit v6 patchset with DT property "linux,gpio-base" removed.
On Monday 15 December 2014 13:35:47 Ray Jui wrote: > > Like I said previously, dynamic GPIO allocation works fine in the > kernel, as long as all of our GPIO clients in the kernel use gpiod based > API, which is what we will enforce going forward. The only problem is > with some of our customers who use GPIO through sysfs and expect fixed > global GPIO numbers. Thinking about this more, it's probably not that > difficult to add a script for those customers to convert/map the GPIO > numbers based on readings parsed from sysfs, so I guess that's fine. > I think we discussed the user space interface a number of times in the past, but I forgot the outcome. Either there is already a way to name gpio lines uniquely in sysfs, or there should be one. Can you reach the gpio interfaces using /sys/devices/0001234.bus/1234566.gpiocontroller/...? Arnd
On 12/15/2014 1:57 PM, Arnd Bergmann wrote: > On Monday 15 December 2014 13:35:47 Ray Jui wrote: >> >> Like I said previously, dynamic GPIO allocation works fine in the >> kernel, as long as all of our GPIO clients in the kernel use gpiod based >> API, which is what we will enforce going forward. The only problem is >> with some of our customers who use GPIO through sysfs and expect fixed >> global GPIO numbers. Thinking about this more, it's probably not that >> difficult to add a script for those customers to convert/map the GPIO >> numbers based on readings parsed from sysfs, so I guess that's fine. >> > > I think we discussed the user space interface a number of times > in the past, but I forgot the outcome. Either there is already > a way to name gpio lines uniquely in sysfs, or there should be > one. > > Can you reach the gpio interfaces using /sys/devices/0001234.bus/1234566.gpiocontroller/...? > > Arnd > We use entries under /sys/class/gpio/ to control GPIOs. All base, label, and ngpio info specific to a GPIO controller can be found there.
On Sat, Dec 13, 2014 at 12:28 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 12 December 2014 22:05:37 Alexandre Courbot wrote: >> On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> > On Thursday 11 December 2014 16:05:04 Ray Jui wrote: >> >> + >> >> +- linux,gpio-base: >> >> + Base GPIO number of this controller >> >> + >> >> >> > >> > We've NAK'ed properties like this multiple times before, and it >> > doesn't get any better this time. What are you trying to achieve >> > here? >> >> I am to blame for suggesting using this property to Ray, and I am >> fully aware that this has been rejected before, but look at what >> people came with recently to palliate the lack of control over the >> GPIO number space for DT platforms: >> >> http://www.spinics.net/lists/arm-kernel/msg384847.html >> https://lkml.org/lkml/2014/12/10/133 >> >> Right now GPIO numbering for platforms using DT is a very inconsistent >> process, subject to change by the simple action of adjusting the value >> of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO >> controller, or changing the probe order of devices. For users of the >> integer or sysfs interfaces, this results in GPIO numbers that change, >> and drivers and/or user-space programs that behave incorrectly. >> Ironically, the only way to have consistent numbers is to use the old >> platform files, where you can specify the base number of a gpio_chip. >> >> DT is actually probably not such a bad place to provide consistency in >> GPIO numbering. It has a global vision of the system layout, including >> all GPIO controllers and the number of GPIOs they include, and thus >> can make informed decisions. It provides a consistent result >> regardless of probe order. And allowing it to assign GPIO bases to >> controllers will free us from the nonsensical dependency of some >> arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on >> us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it >> since we don't need it anymore after the removal of the global >> gpio_descs array. This will again interfere with the numbering of GPIO >> chips that do not have a base number provided. >> >> Note that I don't really like this, either - but the problem is the >> GPIO integer interface. Until everyone has upgraded to gpiod and we >> have a replacement for the current sysfs interface (this will take a >> while) we have to cope with this. This issue has been bothering users >> for years, so this time I'd like to try and solve it the less ugly >> way. If there is a better solution, of course I'm all for it. > > I think the scheme will fail if you ever get gpio controllers that are > not part of the DT: We have hotpluggable devices (PCI, USB, ...) that > are not represented in DT and that may also provide GPIOs for internal > uses. > > The current state of affairs is definitely problematic, but defining > the GPIO numbers in DT properties would only be a relative improvement, > not a solution, and I fear it would make it harder to change the kernel > to remove the gpio numbers eventually. You are absolutely right that this would be only a partial solution. However this is a situation where there is no absolute fix (besides dropping the GPIO numbers completely) and the relief this property would brings makes it up for its shortcomings IMHO. > I wonder if we could instead come up with an approach that completely > randomizes the gpio numbers (as a compile-time option) to find any > places that still rely on specific numbers. A.k.a. Linus and Alex' hate mail generator. :P 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. If we could reach GPIO controllers through a fixed path and just export their GPIOs there, I believe we would have fixed the whole issue.
On Tue, Dec 16, 2014 at 6:57 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 15 December 2014 13:35:47 Ray Jui wrote: >> >> Like I said previously, dynamic GPIO allocation works fine in the >> kernel, as long as all of our GPIO clients in the kernel use gpiod based >> API, which is what we will enforce going forward. The only problem is >> with some of our customers who use GPIO through sysfs and expect fixed >> global GPIO numbers. Thinking about this more, it's probably not that >> difficult to add a script for those customers to convert/map the GPIO >> numbers based on readings parsed from sysfs, so I guess that's fine. >> > > I think we discussed the user space interface a number of times > in the past, but I forgot the outcome. Either there is already > a way to name gpio lines uniquely in sysfs, or there should be > one. > > Can you reach the gpio interfaces using /sys/devices/0001234.bus/1234566.gpiocontroller/...? No, but it seems like this is exactly the solution we need. We could have an "export" node there that takes a relative GPIO number and exports it under /sys/devices/0001234.bus/1234566.gpiocontroller/exported/ the same way the current sysfs exporter does. Then for convenience we could also allow exported GPIOs to take names to be used under the shorter /sys/class/gpio/ (named GPIOs is another request we pushed back many times but that keeps coming). Let's see if I can come with a patch. That would at least give us something to reply to the many people that hit this issue.
On Wednesday 17 December 2014 11:45:01 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. If we could reach GPIO > controllers through a fixed path and just export their GPIOs there, I > believe we would have fixed the whole issue. What about the hundreds of board files and device drivers that still reference hardcoded gpio numbers? The problem seems mostly solved for anything that uses DT, but there are some architectures and a number of ARM platforms that don't use DT and probably never will. I would assume they could all be changed to use gpiod_lookup tables, but that's a lot of work. Arnd
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.
On Wed, Dec 17, 2014 at 7:44 PM, Russell King - ARM Linux <linux@arm.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. Uh, I expressed myself poorly. What I intended to say is that once we have a sysfs alternative that does not rely on GPIO numbers (and thus have the same feature coverage as the integer interface), we can require new platforms to exclusively rely on gpiod/sysfs2, and encourage older users to switch to it if they have an issue with the way integers are handled or need one of the new features. I don't foresee that we will ever be able to retire the integer interface, however I would like to be able to say "your problem will be solved if you switch to gpiod" instead of having to juggle with potentially conflicting integer range requirements from different platforms. Right now the only thing that prevents us to say that is the lack of a consistent sysfs interface.
On Wed, Dec 17, 2014 at 7:26 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 17 December 2014 11:45:01 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. If we could reach GPIO >> controllers through a fixed path and just export their GPIOs there, I >> believe we would have fixed the whole issue. > > What about the hundreds of board files and device drivers that still > reference hardcoded gpio numbers? The problem seems mostly solved for > anything that uses DT, but there are some architectures and a number > of ARM platforms that don't use DT and probably never will. > > I would assume they could all be changed to use gpiod_lookup tables, > but that's a lot of work. Indeed, that's not something to expect, as I replied to Russell. Sorry about the confusion.
On Mon, Dec 15, 2014 at 10:57 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 15 December 2014 13:35:47 Ray Jui wrote: >> >> Like I said previously, dynamic GPIO allocation works fine in the >> kernel, as long as all of our GPIO clients in the kernel use gpiod based >> API, which is what we will enforce going forward. The only problem is >> with some of our customers who use GPIO through sysfs and expect fixed >> global GPIO numbers. Thinking about this more, it's probably not that >> difficult to add a script for those customers to convert/map the GPIO >> numbers based on readings parsed from sysfs, so I guess that's fine. >> > > I think we discussed the user space interface a number of times > in the past, but I forgot the outcome. Either there is already > a way to name gpio lines uniquely in sysfs, or there should be > one. There is one. The struct gpio_chip contains a .names field with strings giving names to the GPIOs on the chip. This field does not have standardized DT bindings or anything but should be used. Overall the sysfs interface is an abomination for relying on the notoriously unstable GPIO numberspace and other things. It was merged when the subsystem lacked a maintainer. Yours, Linus Walleij
On Wed, Dec 17, 2014 at 11:44 AM, Russell King - ARM Linux <linux@arm.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. Yours, Linus Walleij
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@arm.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.
On Tue, Jan 13, 2015 at 12:41 PM, Russell King - ARM Linux <linux@arm.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@arm.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
diff --git a/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt new file mode 100644 index 0000000..0e446d4 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt @@ -0,0 +1,87 @@ +Broadcom Cygnus GPIO Controller + +Required properties: + +- compatible: + Must be "brcm,cygnus-gpio" + +- reg: + Define the base and range of the I/O address space that contain the Cygnus +GPIO controller registers + +- ngpios: + Total number of GPIOs the controller provides + +- linux,gpio-base: + Base GPIO number of this controller + +- #gpio-cells: + Must be two. The first cell is the GPIO pin number (within the +controller's domain) and the second cell is used for the following: + bit[0]: polarity (0 for normal and 1 for inverted) + bit[18:16]: internal pull up/down: 0 - pull up/down disabled + 1 - pull up enabled + 2 - pull down enabled + bit[22:20]: drive strength: 0 - 2 mA + 1 - 4 mA + 2 - 6 mA + 3 - 8 mA + 4 - 10 mA + 5 - 12 mA + 6 - 14 mA + 7 - 16 mA + +- gpio-controller: + Specifies that the node is a GPIO controller + +Optional properties: + +- interrupt-controller: + Specifies that the node is an interrupt controller. Not all Cygnus GPIO +interfaces support interrupt, e.g., the CRMU GPIO controller does not have its +interrupt routed to the main processor's GIC + +- interrupts: + The interrupt outputs from the GPIO controller. + +- no-drv-strength: + Specifies the GPIO controller does not support drive strength configuration + +Example: + gpio_asiu: gpio@180a5000 { + compatible = "brcm,cygnus-gpio"; + reg = <0x180a5000 0x668>; + ngpios = <122>; + linux,gpio-base = <0>; + #gpio-cells = <2>; + gpio-controller; + interrupt-controller; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + }; + + gpio_crmu: gpio@03024800 { + compatible = "brcm,cygnus-gpio"; + reg = <0x03024800 0x50>; + ngpios = <6>; + linux,gpio-base = <146>; + #gpio-cells = <2>; + gpio-controller; + no-drv-strength; + }; + + /* + * Touchscreen that uses the ASIU GPIO 100, with internal pull-up + * enabled + */ + tsc { + ... + ... + gpio-event = <&gpio_asiu 100 0x10000>; + }; + + /* Bluetooth that uses the CRMU GPIO 2, with polarity inverted */ + bluetooth { + ... + ... + bcm,rfkill-bank-sel = <&gpio_crmu 2 1> + }