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

[Joel Stanley]

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?

Cheers,

Joel