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

[Andrew Jeffery]

Hi Vadim,

On Mon, Jul 3, 2017, at 20:22, Vadim Pasternak wrote:
> 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

This looks like what I'd expect.

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

Yes. For example, the openbmc userspace probes the GPIO chips here:

https://github.com/openbmc/skeleton/blob/master/pysystemmgr/obmc/system/__init__.py#L4

Hope that helps.

Andrew

> 
> 
> > 
> > Cheers,
> > 
> > Joel