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

[Vadim Pasternak]

Hi Joel,

> -----Original Message-----
> From: joel.stan at gmail.com [mailto:joel.stan at gmail.com] On Behalf Of Joel
> Stanley
> Sent: Friday, June 30, 2017 8:31 AM
> To: Vadim Pasternak <vadimp at mellanox.com>
> Cc: Andrew Jeffery <andrew at aj.id.au>; Milton Miller II
> <miltonm at us.ibm.com>; Mykola Kostenok <c_mykolak at mellanox.com>;
> openbmc at lists.ozlabs.org
> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num.
> 
> On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak <vadimp at mellanox.com>
> wrote:
> > 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.
> 
> You should be able to achieve this without any further kernel changes.
> OpenBMC on Aspeed uses the sysfs API to do this.
> 
> Can you show is the code that is using the GPIOs?

We just getting in /sys/class/gpio all with offset 280, like:
gpio281      gpio511      gpiochip280

It means we have to consider this offset in our user space applications, in case we can't have gpiochip0 here. Right?


> 
> Cheers,
> 
> Joel