Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <f31b818cf8d682de61c74b133beffcc8a8202478.1660041358.git.christophe.leroy@csgroup.eu>
 <CACRpkdY53c0qXx24Am1TMivXr-MV+fQ8B0CDjtGi6=+2tn4-7A@mail.gmail.com>
 <CAK8P3a1Vh1Uehuin-u5QrTO5qh+t0aK_hA-QZwqc00Db_+MKcw@mail.gmail.com>
 <CACRpkdbhbwBe=jU5prifXCYUXPqULhst0se3ZRH+sWOh9XeoLQ@mail.gmail.com>
 <CAK8P3a0j-54_OkXC7x3NSNaHhwJ+9umNgbpsrPxUB4dwewK63A@mail.gmail.com>
 <CACRpkda0+iy8H0YmyowSDn8RbYgnVbC1k+o5F67inXg4Qb934Q@mail.gmail.com>
 <CAK8P3a0uuJ_z8wmNmQTW_qPNqzz7XoxZdHgqbzmK+ydtjraeHg@mail.gmail.com>
 <CACRpkdb5ow4hD3td6agCuKWvuxptm5AV4rsCrcxNStNdXnBzrA@mail.gmail.com>
 <87f2ff4c-3426-201c-df86-2d06d3587a20@csgroup.eu> <CACRpkdYizQhiJXzXNHg7TXUVHzhkwXHFN5+e58kH4udGm1ziEA@mail.gmail.com>
 <f76dbc49-526f-6dc7-2ef1-558baea5848b@csgroup.eu> <CACRpkdZpwdP+1VitohznqRfhFGcLT2f+sQnmsRWwMBB3bobwAw@mail.gmail.com>
 <515364a9-33a1-fafa-fdce-dc7dbd5bb7fb@csgroup.eu>
In-Reply-To: <515364a9-33a1-fafa-fdce-dc7dbd5bb7fb@csgroup.eu>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sun, 28 Aug 2022 12:04:29 +0200
Message-ID: <CAK8P3a36qbRW8hd+1Uhi88kh+-KTjDMT-Zr8Jq9h_G3zQLfzgw@mail.gmail.com>
Subject: Re: [PATCH] gpio: Allow user to customise maximum number of GPIOs
To:     Christophe Leroy <christophe.leroy@csgroup.eu>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Alexandre Courbot <gnurou@gmail.com>,
        Alexandre Courbot <acourbot@nvidia.com>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Jonathan Corbet <corbet@lwn.net>,
        Russell King <linux@armlinux.org.uk>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        "moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@vger.kernel.org>,
        Davide Ciminaghi <ciminaghi@gnudd.com>,
        Alessandro Rubini <rubini@gnudd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Sun, Aug 28, 2022 at 11:06 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 26/08/2022 à 23:54, Linus Walleij a écrit :
> >> But what do I do with:
> >>
> >> drivers/gpio/gpio-aggregator.c: bitmap = bitmap_alloc(ARCH_NR_GPIOS,
> >> GFP_KERNEL);
> >
> > That's just used locally in that driver to loop over the arguments to the
> > aggregator (from the file in sysfs). I would set some arbitrary root
> > like
> > #define AGGREGATOR_MAX_GPIOS 512
> > and just search/replace with that.
> >
>
> And what about gsta_gpio_setup() that requests base 0 with the following
> comment:
>
>         /*
>          * ARCH_NR_GPIOS is currently 256 and dynamic allocation starts
>          * from the end. However, for compatibility, we need the first
>          * ConneXt device to start from gpio 0: it's the main chipset
>          * on most boards so documents and drivers assume gpio0..gpio127
>          */
>
>
> And I guess there might be other drivers like that (I found that one
> because of its comment mentioning ARCH_NR_GPIOS.

This driver is clearly incomplete: there is an mfd portion in
drivers/mfd/sta2x11-mfd.c, the gpio provider in
drivers/gpio/gpio-sta2x11.c, one gpio consumer in
drivers/media/pci/sta2x11/, and some glue logic in
arch/x86/pci/sta2x11-fixup.c, but nothing that seems to set up
the platform data that these need to communicate with one another.

I think that just means the code that one would have to modify
is in vendor kernels of devices using this chip, but there is no
way to fix those if they are not in mainline. The last meaningful
patches on this SoC support were in 2012 by  Davide Ciminaghi
and Alessandro Rubini, though they still Acked patches after that.

I wonder if I was missing the interesting bit about it, if the driver
is just obsolete and can be removed, or if there is something
that is still worth fixing here.

        Arnd