Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
there is no limitation on the number of GPIOs that can be allocated
in the system since the allocation is fully dynamic.
ARCH_NR_GPIOS is today only used in order to provide downwards
gpiobase allocation from that value, while static allocation is
performed upwards from 0. However that has the disadvantage of
limiting the number of GPIOs that can be registered in the system.
To overcome this limitation without requiring each and every
platform to provide its 'best-guess' maximum number, rework the
allocation to allocate from 512 upwards, allowing approx 2 millions
of GPIOs.
In the meantime, add a warning for drivers how are still doing
static allocation, so that in the future the static allocation gets
removed completely and dynamic allocation can start at base 0.
Main changes in v2:
- Adding a patch to remove sta2x11 GPIO driver instead of modifying it
- Moving the base of dynamic allocation from 256 to 512 because there
are drivers allocating gpios as high as 400.
Christophe Leroy (8):
gpio: aggregator: Stop using ARCH_NR_GPIOS
gpio: davinci: Stop using ARCH_NR_GPIOS
gpiolib: Warn on drivers still using static gpiobase allocation
gpiolib: Get rid of ARCH_NR_GPIOS
Documentation: gpio: Remove text about ARCH_NR_GPIOS
x86: Remove CONFIG_ARCH_NR_GPIO
arm: Remove CONFIG_ARCH_NR_GPIO
arm64: Remove CONFIG_ARCH_NR_GPIO
Davide Ciminaghi (1):
gpio: Remove sta2x11 GPIO driver
Documentation/driver-api/gpio/legacy.rst | 5 -
arch/arm/Kconfig | 21 --
arch/arm/include/asm/gpio.h | 1 -
arch/arm64/Kconfig | 12 -
arch/x86/Kconfig | 5 -
drivers/gpio/Kconfig | 8 -
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-aggregator.c | 7 +-
drivers/gpio/gpio-davinci.c | 3 -
drivers/gpio/gpio-sta2x11.c | 411 -----------------------
drivers/gpio/gpiolib.c | 13 +-
include/asm-generic/gpio.h | 55 ++-
12 files changed, 33 insertions(+), 509 deletions(-)
delete mode 100644 drivers/gpio/gpio-sta2x11.c
--
2.37.1
ARCH_NR_GPIOS have been removed, clean up the documentation.
After this patch, the only place when ARCH_NR_GPIOS remains is in
translations/zh_CN/gpio.txt and translations/zh_TW/gpio.txt.
I don't have the skills to update that, anyway those two files are
already out of sync as they are still mentionning ARCH_REQUIRE_GPIOLIB
which was removed by commit 65053e1a7743 ("gpio: delete
ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB")
Signed-off-by: Christophe Leroy <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
Documentation/driver-api/gpio/legacy.rst | 5 -----
1 file changed, 5 deletions(-)
diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
index 9b12eeb89170..e17910cc3271 100644
--- a/Documentation/driver-api/gpio/legacy.rst
+++ b/Documentation/driver-api/gpio/legacy.rst
@@ -558,11 +558,6 @@ Platform Support
To force-enable this framework, a platform's Kconfig will "select" GPIOLIB,
else it is up to the user to configure support for GPIO.
-It may also provide a custom value for ARCH_NR_GPIOS, so that it better
-reflects the number of GPIOs in actual use on that platform, without
-wasting static table space. (It should count both built-in/SoC GPIOs and
-also ones on GPIO expanders.
-
If neither of these options are selected, the platform does not support
GPIOs through GPIO-lib and the code cannot be enabled by the user.
--
2.37.1
ARCH_NR_GPIOS is used locally in aggr_parse() as the maximum number
of GPIOs to be aggregated together by the driver since
commit ec75039d5550 ("gpio: aggregator: Use bitmap_parselist() for
parsing GPIO offsets").
Don't rely on the total possible number of GPIOs in the system but
define a local arbitrary macro for that, set to 512 which should be
large enough as it is also the default value for ARCH_NR_GPIOS.
Signed-off-by: Christophe Leroy <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
v2: Moved AGGREGATOR_MAX_GPIOS before code
---
drivers/gpio/gpio-aggregator.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
index 0cb2664085cf..6d17d262ad91 100644
--- a/drivers/gpio/gpio-aggregator.c
+++ b/drivers/gpio/gpio-aggregator.c
@@ -23,6 +23,7 @@
#include <linux/spinlock.h>
#include <linux/string.h>
+#define AGGREGATOR_MAX_GPIOS 512
/*
* GPIO Aggregator sysfs interface
@@ -64,7 +65,7 @@ static int aggr_parse(struct gpio_aggregator *aggr)
unsigned int i, n = 0;
int error = 0;
- bitmap = bitmap_alloc(ARCH_NR_GPIOS, GFP_KERNEL);
+ bitmap = bitmap_alloc(AGGREGATOR_MAX_GPIOS, GFP_KERNEL);
if (!bitmap)
return -ENOMEM;
@@ -84,13 +85,13 @@ static int aggr_parse(struct gpio_aggregator *aggr)
}
/* GPIO chip + offset(s) */
- error = bitmap_parselist(offsets, bitmap, ARCH_NR_GPIOS);
+ error = bitmap_parselist(offsets, bitmap, AGGREGATOR_MAX_GPIOS);
if (error) {
pr_err("Cannot parse %s: %d\n", offsets, error);
goto free_bitmap;
}
- for_each_set_bit(i, bitmap, ARCH_NR_GPIOS) {
+ for_each_set_bit(i, bitmap, AGGREGATOR_MAX_GPIOS) {
error = aggr_add_gpio(aggr, name, i, &n);
if (error)
goto free_bitmap;
--
2.37.1
In the preparation of getting completely rid of static gpiobase
allocation in the future, emit a warning in drivers still doing so.
Signed-off-by: Christophe Leroy <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
v2: unsplit the warning text.
---
drivers/gpio/gpiolib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index cc9c0a12259e..4e2fcb7b0a01 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -715,6 +715,9 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
* a poison instead.
*/
gc->base = base;
+ } else {
+ dev_warn(&gdev->dev,
+ "Static allocation of GPIO base is deprecated, use dynamic allocation.\n");
}
gdev->base = base;
--
2.37.1
On Wed, Sep 7, 2022, at 11:58 AM, Bartosz Golaszewski wrote:
> On Fri, Sep 2, 2022 at 2:42 PM Christophe Leroy <[email protected]> wrote:
>>
>> Documentation/driver-api/gpio/legacy.rst | 5 -
>> arch/arm/Kconfig | 21 --
>> arch/arm/include/asm/gpio.h | 1 -
>> arch/arm64/Kconfig | 12 -
>> arch/x86/Kconfig | 5 -
>> drivers/gpio/Kconfig | 8 -
>> drivers/gpio/Makefile | 1 -
>> drivers/gpio/gpio-aggregator.c | 7 +-
>> drivers/gpio/gpio-davinci.c | 3 -
>> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
>> drivers/gpio/gpiolib.c | 13 +-
>> include/asm-generic/gpio.h | 55 ++-
>> 12 files changed, 33 insertions(+), 509 deletions(-)
>> delete mode 100644 drivers/gpio/gpio-sta2x11.c
For the arch/arm*/Kconfig and include/asm-generic changes:
Acked-by: Arnd Bergmann <[email protected]>
sta2x11 is an x86 driver, so not my area, but I think it would be
best to kill off the entire platform rather than just its gpio
driver, since everything needs to work together and it's clearly
not functional at the moment.
$ git grep -l STA2X11
Documentation/admin-guide/media/pci-cardlist.rst
arch/x86/Kconfig
arch/x86/include/asm/sta2x11.h
arch/x86/pci/Makefile
arch/x86/pci/sta2x11-fixup.c
drivers/ata/ahci.c
drivers/gpio/Kconfig
drivers/gpio/Makefile
drivers/gpio/gpio-sta2x11.c
drivers/i2c/busses/Kconfig
drivers/media/pci/Makefile
drivers/media/pci/sta2x11/Kconfig
drivers/media/pci/sta2x11/Makefile
drivers/media/pci/sta2x11/sta2x11_vip.c
drivers/media/pci/sta2x11/sta2x11_vip.h
drivers/mfd/Kconfig
drivers/mfd/Makefile
drivers/mfd/sta2x11-mfd.c
include/linux/mfd/sta2x11-mfd.h
Removing the other sta2x11 bits (mfd, media, x86) should
probably be done through the respective tree, but it would
be good not to forget those.
Arnd
On Fri, Sep 2, 2022 at 2:42 PM Christophe Leroy
<[email protected]> wrote:
>
> Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
> there is no limitation on the number of GPIOs that can be allocated
> in the system since the allocation is fully dynamic.
>
> ARCH_NR_GPIOS is today only used in order to provide downwards
> gpiobase allocation from that value, while static allocation is
> performed upwards from 0. However that has the disadvantage of
> limiting the number of GPIOs that can be registered in the system.
>
> To overcome this limitation without requiring each and every
> platform to provide its 'best-guess' maximum number, rework the
> allocation to allocate from 512 upwards, allowing approx 2 millions
> of GPIOs.
>
> In the meantime, add a warning for drivers how are still doing
> static allocation, so that in the future the static allocation gets
> removed completely and dynamic allocation can start at base 0.
>
> Main changes in v2:
> - Adding a patch to remove sta2x11 GPIO driver instead of modifying it
> - Moving the base of dynamic allocation from 256 to 512 because there
> are drivers allocating gpios as high as 400.
>
> Christophe Leroy (8):
> gpio: aggregator: Stop using ARCH_NR_GPIOS
> gpio: davinci: Stop using ARCH_NR_GPIOS
> gpiolib: Warn on drivers still using static gpiobase allocation
> gpiolib: Get rid of ARCH_NR_GPIOS
> Documentation: gpio: Remove text about ARCH_NR_GPIOS
> x86: Remove CONFIG_ARCH_NR_GPIO
> arm: Remove CONFIG_ARCH_NR_GPIO
> arm64: Remove CONFIG_ARCH_NR_GPIO
>
> Davide Ciminaghi (1):
> gpio: Remove sta2x11 GPIO driver
>
> Documentation/driver-api/gpio/legacy.rst | 5 -
> arch/arm/Kconfig | 21 --
> arch/arm/include/asm/gpio.h | 1 -
> arch/arm64/Kconfig | 12 -
> arch/x86/Kconfig | 5 -
> drivers/gpio/Kconfig | 8 -
> drivers/gpio/Makefile | 1 -
> drivers/gpio/gpio-aggregator.c | 7 +-
> drivers/gpio/gpio-davinci.c | 3 -
> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> drivers/gpio/gpiolib.c | 13 +-
> include/asm-generic/gpio.h | 55 ++-
> 12 files changed, 33 insertions(+), 509 deletions(-)
> delete mode 100644 drivers/gpio/gpio-sta2x11.c
>
> --
> 2.37.1
>
I'd like to take it through the GPIO tree if we can get acks for ARM and x86?
Bart
On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
> >> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
(...)
> sta2x11 is an x86 driver, so not my area, but I think it would be
> best to kill off the entire platform rather than just its gpio
> driver, since everything needs to work together and it's clearly
> not functional at the moment.
>
> $ git grep -l STA2X11
> Documentation/admin-guide/media/pci-cardlist.rst
> arch/x86/Kconfig
> arch/x86/include/asm/sta2x11.h
> arch/x86/pci/Makefile
> arch/x86/pci/sta2x11-fixup.c
> drivers/ata/ahci.c
> drivers/gpio/Kconfig
> drivers/gpio/Makefile
> drivers/gpio/gpio-sta2x11.c
> drivers/i2c/busses/Kconfig
> drivers/media/pci/Makefile
> drivers/media/pci/sta2x11/Kconfig
> drivers/media/pci/sta2x11/Makefile
> drivers/media/pci/sta2x11/sta2x11_vip.c
> drivers/media/pci/sta2x11/sta2x11_vip.h
> drivers/mfd/Kconfig
> drivers/mfd/Makefile
> drivers/mfd/sta2x11-mfd.c
> include/linux/mfd/sta2x11-mfd.h
>
> Removing the other sta2x11 bits (mfd, media, x86) should
> probably be done through the respective tree, but it would
> be good not to forget those.
Andy is pretty much default x86 platform device maintainer, maybe
he can ACK or brief us on what he knows about the status of
STA2x11?
Yours,
Linus Walleij
On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
>> >> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> (...)
>> sta2x11 is an x86 driver, so not my area, but I think it would be
>> best to kill off the entire platform rather than just its gpio
>> driver, since everything needs to work together and it's clearly
>> not functional at the moment.
>>
>> $ git grep -l STA2X11
>> Documentation/admin-guide/media/pci-cardlist.rst
>> arch/x86/Kconfig
>> arch/x86/include/asm/sta2x11.h
>> arch/x86/pci/Makefile
>> arch/x86/pci/sta2x11-fixup.c
>> drivers/ata/ahci.c
>> drivers/gpio/Kconfig
>> drivers/gpio/Makefile
>> drivers/gpio/gpio-sta2x11.c
>> drivers/i2c/busses/Kconfig
>> drivers/media/pci/Makefile
>> drivers/media/pci/sta2x11/Kconfig
>> drivers/media/pci/sta2x11/Makefile
>> drivers/media/pci/sta2x11/sta2x11_vip.c
>> drivers/media/pci/sta2x11/sta2x11_vip.h
>> drivers/mfd/Kconfig
>> drivers/mfd/Makefile
>> drivers/mfd/sta2x11-mfd.c
>> include/linux/mfd/sta2x11-mfd.h
>>
>> Removing the other sta2x11 bits (mfd, media, x86) should
>> probably be done through the respective tree, but it would
>> be good not to forget those.
>
> Andy is pretty much default x86 platform device maintainer, maybe
> he can ACK or brief us on what he knows about the status of
> STA2x11?
I think the explanation given by Davide and Alessandro
was rather detailed already:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
Arnd
On Wed, Sep 14, 2022 at 02:38:53PM +0200, Linus Walleij wrote:
> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
>
> > >> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> (...)
> > sta2x11 is an x86 driver, so not my area, but I think it would be
> > best to kill off the entire platform rather than just its gpio
> > driver, since everything needs to work together and it's clearly
> > not functional at the moment.
> >
> > $ git grep -l STA2X11
> > Documentation/admin-guide/media/pci-cardlist.rst
> > arch/x86/Kconfig
> > arch/x86/include/asm/sta2x11.h
> > arch/x86/pci/Makefile
> > arch/x86/pci/sta2x11-fixup.c
> > drivers/ata/ahci.c
> > drivers/gpio/Kconfig
> > drivers/gpio/Makefile
> > drivers/gpio/gpio-sta2x11.c
> > drivers/i2c/busses/Kconfig
> > drivers/media/pci/Makefile
> > drivers/media/pci/sta2x11/Kconfig
> > drivers/media/pci/sta2x11/Makefile
> > drivers/media/pci/sta2x11/sta2x11_vip.c
> > drivers/media/pci/sta2x11/sta2x11_vip.h
> > drivers/mfd/Kconfig
> > drivers/mfd/Makefile
> > drivers/mfd/sta2x11-mfd.c
> > include/linux/mfd/sta2x11-mfd.h
> >
> > Removing the other sta2x11 bits (mfd, media, x86) should
> > probably be done through the respective tree, but it would
> > be good not to forget those.
>
> Andy is pretty much default x86 platform device maintainer, maybe
> he can ACK or brief us on what he knows about the status of
> STA2x11?
Actually I have no idea about STA2x11, but in some thread I have noticed that
there were people who know more on the topic and they told that removal is the
right thing to do.
Not sure how it should be done practically (driver-by-driver or altogether),
Acked-by: Andy Shevchenko <[email protected]>
for either of the variants if it helps.
--
With Best Regards,
Andy Shevchenko
Hi Linus,
Le 14/09/2022 à 15:03, Arnd Bergmann a écrit :
> On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
>> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
>>>>> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
>> (...)
>>> sta2x11 is an x86 driver, so not my area, but I think it would be
>>> best to kill off the entire platform rather than just its gpio
>>> driver, since everything needs to work together and it's clearly
>>> not functional at the moment.
>>>
>>> $ git grep -l STA2X11
>>> Documentation/admin-guide/media/pci-cardlist.rst
>>> arch/x86/Kconfig
>>> arch/x86/include/asm/sta2x11.h
>>> arch/x86/pci/Makefile
>>> arch/x86/pci/sta2x11-fixup.c
>>> drivers/ata/ahci.c
>>> drivers/gpio/Kconfig
>>> drivers/gpio/Makefile
>>> drivers/gpio/gpio-sta2x11.c
>>> drivers/i2c/busses/Kconfig
>>> drivers/media/pci/Makefile
>>> drivers/media/pci/sta2x11/Kconfig
>>> drivers/media/pci/sta2x11/Makefile
>>> drivers/media/pci/sta2x11/sta2x11_vip.c
>>> drivers/media/pci/sta2x11/sta2x11_vip.h
>>> drivers/mfd/Kconfig
>>> drivers/mfd/Makefile
>>> drivers/mfd/sta2x11-mfd.c
>>> include/linux/mfd/sta2x11-mfd.h
>>>
>>> Removing the other sta2x11 bits (mfd, media, x86) should
>>> probably be done through the respective tree, but it would
>>> be good not to forget those.
>>
>> Andy is pretty much default x86 platform device maintainer, maybe
>> he can ACK or brief us on what he knows about the status of
>> STA2x11?
>
> I think the explanation given by Davide and Alessandro
> was rather detailed already:
>
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
>
I can't see this series in neither linus tree nor linux-next.
Following the ACK from Andy + the above explanations from Arnd, do you
plan to merge this series anytime soon ?
Do you need anything more from me ?
Thanks
Christophe
On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
<[email protected]> wrote:
>
> Hi Linus,
>
> Le 14/09/2022 à 15:03, Arnd Bergmann a écrit :
> > On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
> >> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
> >>>>> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> >> (...)
> >>> sta2x11 is an x86 driver, so not my area, but I think it would be
> >>> best to kill off the entire platform rather than just its gpio
> >>> driver, since everything needs to work together and it's clearly
> >>> not functional at the moment.
> >>>
> >>> $ git grep -l STA2X11
> >>> Documentation/admin-guide/media/pci-cardlist.rst
> >>> arch/x86/Kconfig
> >>> arch/x86/include/asm/sta2x11.h
> >>> arch/x86/pci/Makefile
> >>> arch/x86/pci/sta2x11-fixup.c
> >>> drivers/ata/ahci.c
> >>> drivers/gpio/Kconfig
> >>> drivers/gpio/Makefile
> >>> drivers/gpio/gpio-sta2x11.c
> >>> drivers/i2c/busses/Kconfig
> >>> drivers/media/pci/Makefile
> >>> drivers/media/pci/sta2x11/Kconfig
> >>> drivers/media/pci/sta2x11/Makefile
> >>> drivers/media/pci/sta2x11/sta2x11_vip.c
> >>> drivers/media/pci/sta2x11/sta2x11_vip.h
> >>> drivers/mfd/Kconfig
> >>> drivers/mfd/Makefile
> >>> drivers/mfd/sta2x11-mfd.c
> >>> include/linux/mfd/sta2x11-mfd.h
> >>>
> >>> Removing the other sta2x11 bits (mfd, media, x86) should
> >>> probably be done through the respective tree, but it would
> >>> be good not to forget those.
> >>
> >> Andy is pretty much default x86 platform device maintainer, maybe
> >> he can ACK or brief us on what he knows about the status of
> >> STA2x11?
> >
> > I think the explanation given by Davide and Alessandro
> > was rather detailed already:
> >
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
> >
>
> I can't see this series in neither linus tree nor linux-next.
>
> Following the ACK from Andy + the above explanations from Arnd, do you
> plan to merge this series anytime soon ?
>
> Do you need anything more from me ?
>
> Thanks
> Christophe
I will take it after v6.1-rc1 is tagged.
Bart
On Fri, Oct 14, 2022 at 4:22 PM Bartosz Golaszewski <[email protected]> wrote:
>
> On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
> <[email protected]> wrote:
> >
> > Hi Linus,
> >
> > Le 14/09/2022 à 15:03, Arnd Bergmann a écrit :
> > > On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
> > >> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
> > >>>>> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> > >> (...)
> > >>> sta2x11 is an x86 driver, so not my area, but I think it would be
> > >>> best to kill off the entire platform rather than just its gpio
> > >>> driver, since everything needs to work together and it's clearly
> > >>> not functional at the moment.
> > >>>
> > >>> $ git grep -l STA2X11
> > >>> Documentation/admin-guide/media/pci-cardlist.rst
> > >>> arch/x86/Kconfig
> > >>> arch/x86/include/asm/sta2x11.h
> > >>> arch/x86/pci/Makefile
> > >>> arch/x86/pci/sta2x11-fixup.c
> > >>> drivers/ata/ahci.c
> > >>> drivers/gpio/Kconfig
> > >>> drivers/gpio/Makefile
> > >>> drivers/gpio/gpio-sta2x11.c
> > >>> drivers/i2c/busses/Kconfig
> > >>> drivers/media/pci/Makefile
> > >>> drivers/media/pci/sta2x11/Kconfig
> > >>> drivers/media/pci/sta2x11/Makefile
> > >>> drivers/media/pci/sta2x11/sta2x11_vip.c
> > >>> drivers/media/pci/sta2x11/sta2x11_vip.h
> > >>> drivers/mfd/Kconfig
> > >>> drivers/mfd/Makefile
> > >>> drivers/mfd/sta2x11-mfd.c
> > >>> include/linux/mfd/sta2x11-mfd.h
> > >>>
> > >>> Removing the other sta2x11 bits (mfd, media, x86) should
> > >>> probably be done through the respective tree, but it would
> > >>> be good not to forget those.
> > >>
> > >> Andy is pretty much default x86 platform device maintainer, maybe
> > >> he can ACK or brief us on what he knows about the status of
> > >> STA2x11?
> > >
> > > I think the explanation given by Davide and Alessandro
> > > was rather detailed already:
> > >
> > > https://lore.kernel.org/lkml/[email protected]/
> > > https://lore.kernel.org/lkml/[email protected]/
> > >
> >
> > I can't see this series in neither linus tree nor linux-next.
> >
> > Following the ACK from Andy + the above explanations from Arnd, do you
> > plan to merge this series anytime soon ?
> >
> > Do you need anything more from me ?
> >
> > Thanks
> > Christophe
>
> I will take it after v6.1-rc1 is tagged.
>
> Bart
Now queued.
Bart
On Mon, Oct 17, 2022 at 11:05 AM Bartosz Golaszewski <[email protected]> wrote:
> On Fri, Oct 14, 2022 at 4:22 PM Bartosz Golaszewski <[email protected]> wrote:
> >
> > On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
> > <[email protected]> wrote:
> > >
> > > Hi Linus,
> > >
> > > Le 14/09/2022 à 15:03, Arnd Bergmann a écrit :
> > > > On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
> > > >> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <[email protected]> wrote:
> > > >>>>> drivers/gpio/gpio-sta2x11.c | 411 -----------------------
> > > >> (...)
> > > >>> sta2x11 is an x86 driver, so not my area, but I think it would be
> > > >>> best to kill off the entire platform rather than just its gpio
> > > >>> driver, since everything needs to work together and it's clearly
> > > >>> not functional at the moment.
> > > >>>
> > > >>> $ git grep -l STA2X11
> > > >>> Documentation/admin-guide/media/pci-cardlist.rst
> > > >>> arch/x86/Kconfig
> > > >>> arch/x86/include/asm/sta2x11.h
> > > >>> arch/x86/pci/Makefile
> > > >>> arch/x86/pci/sta2x11-fixup.c
> > > >>> drivers/ata/ahci.c
> > > >>> drivers/gpio/Kconfig
> > > >>> drivers/gpio/Makefile
> > > >>> drivers/gpio/gpio-sta2x11.c
> > > >>> drivers/i2c/busses/Kconfig
> > > >>> drivers/media/pci/Makefile
> > > >>> drivers/media/pci/sta2x11/Kconfig
> > > >>> drivers/media/pci/sta2x11/Makefile
> > > >>> drivers/media/pci/sta2x11/sta2x11_vip.c
> > > >>> drivers/media/pci/sta2x11/sta2x11_vip.h
> > > >>> drivers/mfd/Kconfig
> > > >>> drivers/mfd/Makefile
> > > >>> drivers/mfd/sta2x11-mfd.c
> > > >>> include/linux/mfd/sta2x11-mfd.h
> > > >>>
> > > >>> Removing the other sta2x11 bits (mfd, media, x86) should
> > > >>> probably be done through the respective tree, but it would
> > > >>> be good not to forget those.
> > > >>
> > > >> Andy is pretty much default x86 platform device maintainer, maybe
> > > >> he can ACK or brief us on what he knows about the status of
> > > >> STA2x11?
> > > >
> > > > I think the explanation given by Davide and Alessandro
> > > > was rather detailed already:
> > > >
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > >
> > >
> > > I can't see this series in neither linus tree nor linux-next.
> > >
> > > Following the ACK from Andy + the above explanations from Arnd, do you
> > > plan to merge this series anytime soon ?
> > >
> > > Do you need anything more from me ?
> > >
> > > Thanks
> > > Christophe
> >
> > I will take it after v6.1-rc1 is tagged.
> >
> > Bart
>
> Now queued.
Thanks for reviewing and applying this!
Let's test it in linux-next we need wide coverage for this.
Yours,
Linus Walleij
On Mon, Oct 17, 2022 at 11:06:49AM +0200, Linus Walleij wrote:
> On Mon, Oct 17, 2022 at 11:05 AM Bartosz Golaszewski <[email protected]> wrote:
...
> Let's test it in linux-next we need wide coverage for this.
Yes, I believe the best if we can have this in the Linux Next as long as
possible before going to upstream. This is good change that needs good testing
coverage.
Speaking of the latter, and a bit of offtopic, I want to send a PR of cleaning
up the headers in pin control subsystem as soon as possible with the same
rationale underneath, i.e. testing and new drivers using a cleaned up headers..
--
With Best Regards,
Andy Shevchenko