[PATCH] Allow configuration of ARCH_NR_GPIO

[Arnd Bergmann]

On Sun, Jul 31, 2022 at 12:33 AM Billie Alsup (balsup) <balsup at cisco.com> wrote:
>   >On 7/30/22, 4:54 AM, "Arnd Bergmann" <arnd at arndb.de> wrote:
>
>   >What is the use case for manually setting this rather than deriving
>   >it from the selected platforms?
>
> A Cisco GPIO IP block supports 1022 pins.  A single FPGA can support
> multiple GPIO IP blocks (although typically 1 or 2).  A system may
> have two or three FPGAs directly accessible through the PCI bus, and
> an additional 8 to 36 FPGAS accessible through alternate means (e.g.,
> SLPC, i2c, or a proprietary point-to-point bus).  Although typically
> the full set of pins is not used, in total, it is very easy to exceed
> the limit.  Previous patches have simply bumped up the number, and I
> thought a more generic approach that would solve the use case for
> customer devices would be more appropriate.  I am also trying to keep
> the ARM and X86 implementations similar, as the devices are
> accessible from both an ARM-based BMC as well as an X86 type CPU.

It would be nice to keep it consistent between the major architectures,
at least arm64, powerpc, mips and riscv in addition to the two you already
have.

One way we could do this is to keep the existing
CONFIG_ARCH_NR_GPIO for on-chip GPIOs, and then add
a new Kconfig option for extra GPIOs on things like PCI cards or
programmable logic.

>  It is desirable to use the same kernel configuration for multiple
> products, even though the number of FPGAS, and therefore the number
> of supported GPIO pins can vary.  Such is also the case for Open NOS
> environments, such as SONiC and FBOSS, which attempt to use a single
> kernel configuration across multiple (multi-vendor) products. A
> platform specific option would not seem to work in such cases.
> Ideally, I would like to see this configuration knob go away
> completely, but that might be a more complicated and controversial
> change.  It is not used in very many places, but the problematic use
> is within the inline function gpio_is_valid.

I think the plan for making the option obsolete is to convert every user
of the legacy GPIO interface to use GPIO descriptors, which don't
have the limitation and don't need gpio_is_valid().

In your use case, can you identify a set of drivers that need access
to old-style GPIO numbers above the hardcoded on-chip numbers?
Maybe we can prioritize fixing those drivers.

>   >Have you tried to use both a platform-specific option for the minimum
>   >number of this setting, and then restictricting the
>   >CONFIG_ARCH_NR_GPIO
>   >setting with a 'range' statement?
>
> I have not tried a platform specific option, as we would need to
> choose the worst case platform for such a configuration (in order to
> share a kernel build across products), but this in turn may conflict
> with the chosen platform for some other “worst-case” setting of
> another variable.  It seems prudent to simply allow the kernel
> builder to choose the options they want.  This is just one example
> where the configuration is not directly available to the kernel
> builder, but must be set indirectly.  We have other configuration
> options that cannot be set directly, and instead require us to enable
> an unrelated (from a product standpoint) configuration item purely
> for the side-effect of enabling such an option.  CONFIG_ARCH_NR_GPIO
> is a similar issue, where you choose a platform to indirectly set the
> value, but that value really needs to be configurable by the builder.
> The last such patch for X86 simply bumped up the number.  I thought
> it better to simply allow configuration.  I have no issue with
> restricting the value to a minimum, if that is a worry.

I have no problem with allowing a kernel build to use larger values
than the default, I'm just worried that allowing smaller values than what
we know is needed for the existing platforms can break distro kernels
that have to work across many machines.

        Arnd