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

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

[Mykola Kostenok]

Set maximum number of gpio for ARCH_ASPEED.

Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

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.
-- 
2.11.0

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

[Milton Miller II]

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@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.  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.  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.  

milton

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

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

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@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
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Vadim Pasternak]

Hi Andrew,

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

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

[Joel Stanley]

On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak <vadimp@mellanox.com> wrote:
> Hi Andrew,
>
>> -----Original Message-----
>> From: openbmc [mailto:openbmc-
>> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew
>> Jeffery
>> Sent: Friday, June 30, 2017 4:31 AM
>> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok
>> <c_mykolak@mellanox.com>
>> Cc: openbmc@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@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

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

[Vadim Pasternak]

Hi Joel,

> -----Original Message-----
> From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
> Stanley
> Sent: Friday, June 30, 2017 8:31 AM
> To: Vadim Pasternak <vadimp@mellanox.com>
> Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II
> <miltonm@us.ibm.com>; Mykola Kostenok <c_mykolak@mellanox.com>;
> openbmc@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@mellanox.com>
> wrote:
> > Hi Andrew,
> >
> >> -----Original Message-----
> >> From: openbmc [mailto:openbmc-
> >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew
> >> Jeffery
> >> Sent: Friday, June 30, 2017 4:31 AM
> >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok
> >> <c_mykolak@mellanox.com>
> >> Cc: openbmc@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@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

Re: [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@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
> > Stanley
> > Sent: Friday, June 30, 2017 8:31 AM
> > To: Vadim Pasternak <vadimp@mellanox.com>
> > Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II
> > <miltonm@us.ibm.com>; Mykola Kostenok <c_mykolak@mellanox.com>;
> > openbmc@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@mellanox.com>
> > wrote:
> > > Hi Andrew,
> > >
> > >> -----Original Message-----
> > >> From: openbmc [mailto:openbmc-
> > >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew
> > >> Jeffery
> > >> Sent: Friday, June 30, 2017 4:31 AM
> > >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok
> > >> <c_mykolak@mellanox.com>
> > >> Cc: openbmc@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@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

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

[Vadim Pasternak]

Hi Andrew,

> -----Original Message-----
> From: Andrew Jeffery [mailto:andrew@aj.id.au]
> Sent: Monday, July 03, 2017 2:33 PM
> To: Vadim Pasternak <vadimp@mellanox.com>; Joel Stanley
> <joel@jms.id.au>
> Cc: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok
> <c_mykolak@mellanox.com>; openbmc@lists.ozlabs.org
> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num.
> 
> Hi Vadim,
> 
> On Mon, Jul 3, 2017, at 20:22, Vadim Pasternak wrote:
> > Hi Joel,
> >
> > > -----Original Message-----
> > > From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of
> > > Joel Stanley
> > > Sent: Friday, June 30, 2017 8:31 AM
> > > To: Vadim Pasternak <vadimp@mellanox.com>
> > > Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II
> > > <miltonm@us.ibm.com>; Mykola Kostenok
> <c_mykolak@mellanox.com>;
> > > openbmc@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@mellanox.com>
> > > wrote:
> > > > Hi Andrew,
> > > >
> > > >> -----Original Message-----
> > > >> From: openbmc [mailto:openbmc-
> > > >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of
> > > >> bounces+Andrew
> > > >> Jeffery
> > > >> Sent: Friday, June 30, 2017 4:31 AM
> > > >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok
> > > >> <c_mykolak@mellanox.com>
> > > >> Cc: openbmc@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@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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fopenbmc%2Fskeleton%2Fblob%2Fmaster%2Fpysystemmgr%2F
> obmc%2Fsystem%2F__init__.py%23L4&data=02%7C01%7Cvadimp%40mella
> nox.com%7C7ab16551b30f433e3b1b08d4c20742fb%7Ca652971c7d2e4d9ba6a
> 4d149256f461b%7C0%7C0%7C636346783833758007&sdata=9DV5e4dERXNj93
> Mdet4dbMcQeryqiwysIzySnfxaBHk%3D&reserved=0
> 
> Hope that helps.

Thank you for the pointer.
This is good with us.

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