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

[Vadim Pasternak]

Hi Andrew,

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+yanivab=mellanox.com at lists.ozlabs.org] On Behalf Of Andrew
> Jeffery
> Sent: Friday, June 30, 2017 4:31 AM
> To: Milton Miller II <miltonm at us.ibm.com>; Mykola Kostenok
> <c_mykolak at mellanox.com>
> Cc: openbmc at lists.ozlabs.org
> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num.
> 
> 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.

The motivation to control GPIOs though SYSFS.
We have a couple of reasons for that:

Need it to support production - they used to verify all the connected GPIOs.

Some GPIOs used to allow access to remote  components like  NC-SI SPI flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices.

And we are doing it through /sys/class/gpio.

Cheers,
Vadim.
> 
> Cheers,
> 
> Andrew
> 
> >
> > milton
> >