Re: [PATCH] gpio: document how to order GPIO controllers

[Alexander Stein <alexander.stein@systec-electronic.com>]

On Tuesday 05 July 2016 20:04:47, Uwe Kleine-König wrote:
> That is we have:
> 
> 	Hardware name | software gpiochip
> 	    GPIO4     |      gpiochip0
> 	    GPIO3     |      gpiochip1
> 	    GPIO1     |      gpiochip2
> 	    GPIO2     |	     gpiochip3
> 
> I bet that's the probe order because when sorted by address (and so
> by order in the device tree) we have exactly this ordering. (Compare
> with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)

This is rather straight forward and rather simple for controller internal GPIO 
controllers but when using GPIO expanders both on SPI and I2C thing will get 
much more volatile especially on SMP systems. What would be the correct 
"order" here? Unless they are cascaded they are independent and there is no 
such thing as an order. Probe order _is_ unpredictable so they will vary on 
different boots. Having 4 internal GPIO controllers which creates 4 gpiochips 
with more or less fixed names is rather a special case. Dunno if they might 
change on a SMP system. Can a driver probe be called multiple times 
simultaneously? Well, when drivers are used as modules I think things are even 
more unpredictable.

> For a new interface this is OK, still I predict users will complain if
> the numbers used don't match naturally the hardware names. And IMHO they
> are right.

Given the fact that hardware names and gpiochip number relation is not fixed 
IMHO the simplest way to identify them is using the DT label. You need them 
anyway to identify them in DT itself at other places why not using this on 
Linux userspace too? So gpiochip[0-9]* should still be created but using udev 
you can create appropriate symlinks with more recognizable names.

Best regards,
Alexander

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html