[PATCH linux dev-4.10] aspeed: Set max gpio num.

[Andrew Jeffery]

On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote:
> On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote:
> > 
> > Set maximum number of gpio for ARCH_ASPEED.
> > 
> > > > Signed-off-by: Mykola Kostenok <c_mykolak at mellanox.com>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 186c4c214e0a..9d373685c628 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO
> > 	default 352 if ARCH_VT8500
> > 	default 288 if ARCH_ROCKCHIP
> > 	default 264 if MACH_H4700
> > > > +	default 232 if ARCH_ASPEED
> > 	default 0
> > 	help
> > 	  Maximum number of GPIOs in the system.
> 
> 
> This is a bad idea. 

I agree.

>  This sets the maximum total number 
> of gpios supported by the kernel, and setting it to this 
> value would not allow any space for the various pca 
> expanders to define additional gpios.
> 
> The logic in asm-generic/gpio.h says if the CONFIG 
> number is 0 use 512 else use the supplied value.
> 
> I'm guessing this was motivated to make the gpio numbers 
> match with the controller.

Right; what's missing is any mention of the motivation.

Mykola: What problem are you trying to solve with this patch? As Milton
mentions it might be making the GPIO numbers align with the controller,
but why do you need that? It should already be possible to describe the
system without this patch.

>   Unfortunately the gpios from 
> the device tree are assigned numbers from the end of 
> the number space.
> 
> If we need to assign a specific range, we should try 
> to define an optional property in the gpio chip binding 
> and assign the value to gpio-chip.base in gpio-aspeed.c, 
> but I am doubtful that such a patch would be accepted 
> upstream.  

I tend to doubt it as well. Describing GPIOs in the devicetree always
uses the GPIO controller phandle for a base reference and the pin
numbers are mapped at runtime as required.

If it's a userspace problem, then there are means via sysfs and the
chardev API to discover which controller you're talking to (e.g. chip
labels, named gpios). Either of those approaches should suffice.

Cheers,

Andrew

> 
> milton
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170630/82ed5d45/attachment.sig>