On Sun, Aug 28, 2022 at 11:06 AM Christophe Leroy
<christophe.leroy@xxxxxxxxxx> 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
