On Wed, Jan 14, 2015 at 5:13 PM, Linus Walleij [off-list ref] wrote:

On Wed, Dec 10, 2014 at 9:51 AM, Alexandre Courbot [off-list ref] wrote:

quoted

On Fri, Dec 5, 2014 at 12:38 PM, Zhou Wang [off-list ref] wrote:

quoted

In function gpiochip_find_base, base number of a GPIO controller
is found in decreasing order. ARCH_NR_GPIOS is used to define from
which number we begin to search for base number of a GPIO controller.

In fact, ARCH_NR_GPIOS brings us some multiplatform problems, like:
http://www.spinics.net/lists/devicetree/msg60433.html

This patch adds the support to find base number of a GPIO controller
in increasing order. It will assign base number from 0.
A new dts property called gpio-number-forward must be add to the related
GPIO dts nodes if you want it works well.

Global GPIO numbers are a Linux-only concept, so your property should
be named linux,gpio-number-forward.

But even that way I don't think I like this idea. This just adds some
more mess to how the GPIO number space is constructed, and it is
already quite messy as it is. You have no guarantee over the probe
order of your GPIO controllers, so they may very well be probed in a
different order and end up with different base numbers anytime.

Yup.

The way stuff is usually forced ordered in device tree is to use
aliases, e.g.:

        aliases {
                serial0 = &pb1176_serial0;
                serial1 = &pb1176_serial1;
                serial2 = &pb1176_serial2;
                serial3 = &pb1176_serial3;
                serial4 = &fpga_serial;
        };

By getting the alias ID with of_alias_get_id(np, "serial")
a certain serial port is assigned to be
0, 1, 2 ...

I think I could accept a tweak of this patch that will register
GPIOs beginning from 0 if and only if the alias mechanism is
used.

        aliases {
                gpio0 = &foo_gpio0;
                gpio1 = &expander;
        };


The actual Linux-specific integer base will *NOT* be in the
device tree, but if you know how many GPIOs are on each
controller the number space is still stable and predictable
beginning from 0. If one want to keep track of the Linux
number space one can do so with comments in the device
tree or something.

quoted

I know we pushed back against this kind of solution in the past, but
it is still more reliable than having a property that affects how the
kernel's base finding function works, and will offer us a way to
eventually put ARCH_NR_GPIOS and gpiochip_find_base() to rest (at the
cost of backwards-compatibility, but we just cannot do without it).
Linus, do you agree?

What do you think about the above?

It would definitely help with the probe order, but unfortunately not
with the fact that GPIO bases are allocated in decreasing order
starting from the potentially varying ARCH_NR_GPIOS. So that alone
will not be able to ensure stable GPIO numbers.