[PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Christophe Leroy]

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/9] gpio: Remove sta2x11 GPIO driver

[Christophe Leroy]

From: Davide Ciminaghi <ciminaghi@gnudd.com>

The Connext chip has 4 gpio cells looking very similar to those of the
Nomadik, whose gpio/pinctrl driver (already featuring devicetree support)
will be used instead of the sta2x11 specific one.

Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: New
---
 drivers/gpio/Kconfig        |   8 -
 drivers/gpio/Makefile       |   1 -
 drivers/gpio/gpio-sta2x11.c | 411 ------------------------------------
 3 files changed, 420 deletions(-)
 delete mode 100644 drivers/gpio/gpio-sta2x11.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0642f579196f..f7f620076b05 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -596,14 +596,6 @@ config GPIO_SPRD
 	help
 	  Say yes here to support Spreadtrum GPIO device.
 
-config GPIO_STA2X11
-	bool "STA2x11/ConneXt GPIO support"
-	depends on MFD_STA2X11
-	select GENERIC_IRQ_CHIP
-	help
-	  Say yes here to support the STA2x11/ConneXt GPIO device.
-	  The GPIO module has 128 GPIO pins with alternate functions.
-
 config GPIO_STP_XWAY
 	bool "XWAY STP GPIOs"
 	depends on SOC_XWAY || COMPILE_TEST
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a0985d30f51b..3ffd46ae6e02 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -140,7 +140,6 @@ obj-$(CONFIG_GPIO_SL28CPLD)		+= gpio-sl28cpld.o
 obj-$(CONFIG_GPIO_SODAVILLE)		+= gpio-sodaville.o
 obj-$(CONFIG_GPIO_SPEAR_SPICS)		+= gpio-spear-spics.o
 obj-$(CONFIG_GPIO_SPRD)			+= gpio-sprd.o
-obj-$(CONFIG_GPIO_STA2X11)		+= gpio-sta2x11.o
 obj-$(CONFIG_GPIO_STMPE)		+= gpio-stmpe.o
 obj-$(CONFIG_GPIO_STP_XWAY)		+= gpio-stp-xway.o
 obj-$(CONFIG_GPIO_SYSCON)		+= gpio-syscon.o
diff --git a/drivers/gpio/gpio-sta2x11.c b/drivers/gpio/gpio-sta2x11.c
deleted file mode 100644
index e07cca0f8d35..000000000000
--- a/drivers/gpio/gpio-sta2x11.c
+++ /dev/null
@@ -1,411 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * STMicroelectronics ConneXt (STA2X11) GPIO driver
- *
- * Copyright 2012 ST Microelectronics (Alessandro Rubini)
- * Based on gpio-ml-ioh.c, Copyright 2010 OKI Semiconductors Ltd.
- * Also based on previous sta2x11 work, Copyright 2011 Wind River Systems, Inc.
- */
-
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-#include <linux/gpio/driver.h>
-#include <linux/bitops.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/pci.h>
-#include <linux/platform_device.h>
-#include <linux/mfd/sta2x11-mfd.h>
-
-struct gsta_regs {
-	u32 dat;		/* 0x00 */
-	u32 dats;
-	u32 datc;
-	u32 pdis;
-	u32 dir;		/* 0x10 */
-	u32 dirs;
-	u32 dirc;
-	u32 unused_1c;
-	u32 afsela;		/* 0x20 */
-	u32 unused_24[7];
-	u32 rimsc;		/* 0x40 */
-	u32 fimsc;
-	u32 is;
-	u32 ic;
-};
-
-struct gsta_gpio {
-	spinlock_t			lock;
-	struct device			*dev;
-	void __iomem			*reg_base;
-	struct gsta_regs __iomem	*regs[GSTA_NR_BLOCKS];
-	struct gpio_chip		gpio;
-	int				irq_base;
-	/* FIXME: save the whole config here (AF, ...) */
-	unsigned			irq_type[GSTA_NR_GPIO];
-};
-
-/*
- * gpio methods
- */
-
-static void gsta_gpio_set(struct gpio_chip *gpio, unsigned nr, int val)
-{
-	struct gsta_gpio *chip = gpiochip_get_data(gpio);
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-
-	if (val)
-		writel(bit, &regs->dats);
-	else
-		writel(bit, &regs->datc);
-}
-
-static int gsta_gpio_get(struct gpio_chip *gpio, unsigned nr)
-{
-	struct gsta_gpio *chip = gpiochip_get_data(gpio);
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-
-	return !!(readl(&regs->dat) & bit);
-}
-
-static int gsta_gpio_direction_output(struct gpio_chip *gpio, unsigned nr,
-				      int val)
-{
-	struct gsta_gpio *chip = gpiochip_get_data(gpio);
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-
-	writel(bit, &regs->dirs);
-	/* Data register after direction, otherwise pullup/down is selected */
-	if (val)
-		writel(bit, &regs->dats);
-	else
-		writel(bit, &regs->datc);
-	return 0;
-}
-
-static int gsta_gpio_direction_input(struct gpio_chip *gpio, unsigned nr)
-{
-	struct gsta_gpio *chip = gpiochip_get_data(gpio);
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-
-	writel(bit, &regs->dirc);
-	return 0;
-}
-
-static int gsta_gpio_to_irq(struct gpio_chip *gpio, unsigned offset)
-{
-	struct gsta_gpio *chip = gpiochip_get_data(gpio);
-	return chip->irq_base + offset;
-}
-
-static void gsta_gpio_setup(struct gsta_gpio *chip) /* called from probe */
-{
-	struct gpio_chip *gpio = &chip->gpio;
-
-	/*
-	 * 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
-	 */
-	static int gpio_base;
-
-	gpio->label = dev_name(chip->dev);
-	gpio->owner = THIS_MODULE;
-	gpio->direction_input = gsta_gpio_direction_input;
-	gpio->get = gsta_gpio_get;
-	gpio->direction_output = gsta_gpio_direction_output;
-	gpio->set = gsta_gpio_set;
-	gpio->dbg_show = NULL;
-	gpio->base = gpio_base;
-	gpio->ngpio = GSTA_NR_GPIO;
-	gpio->can_sleep = false;
-	gpio->to_irq = gsta_gpio_to_irq;
-
-	/*
-	 * After the first device, turn to dynamic gpio numbers.
-	 * For example, with ARCH_NR_GPIOS = 256 we can fit two cards
-	 */
-	if (!gpio_base)
-		gpio_base = -1;
-}
-
-/*
- * Special method: alternate functions and pullup/pulldown. This is only
- * invoked on startup to configure gpio's according to platform data.
- * FIXME : this functionality shall be managed (and exported to other drivers)
- * via the pin control subsystem.
- */
-static void gsta_set_config(struct gsta_gpio *chip, int nr, unsigned cfg)
-{
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	unsigned long flags;
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-	u32 val;
-	int err = 0;
-
-	pr_info("%s: %p %i %i\n", __func__, chip, nr, cfg);
-
-	if (cfg == PINMUX_TYPE_NONE)
-		return;
-
-	/* Alternate function or not? */
-	spin_lock_irqsave(&chip->lock, flags);
-	val = readl(&regs->afsela);
-	if (cfg == PINMUX_TYPE_FUNCTION)
-		val |= bit;
-	else
-		val &= ~bit;
-	writel(val | bit, &regs->afsela);
-	if (cfg == PINMUX_TYPE_FUNCTION) {
-		spin_unlock_irqrestore(&chip->lock, flags);
-		return;
-	}
-
-	/* not alternate function: set details */
-	switch (cfg) {
-	case PINMUX_TYPE_OUTPUT_LOW:
-		writel(bit, &regs->dirs);
-		writel(bit, &regs->datc);
-		break;
-	case PINMUX_TYPE_OUTPUT_HIGH:
-		writel(bit, &regs->dirs);
-		writel(bit, &regs->dats);
-		break;
-	case PINMUX_TYPE_INPUT:
-		writel(bit, &regs->dirc);
-		val = readl(&regs->pdis) | bit;
-		writel(val, &regs->pdis);
-		break;
-	case PINMUX_TYPE_INPUT_PULLUP:
-		writel(bit, &regs->dirc);
-		val = readl(&regs->pdis) & ~bit;
-		writel(val, &regs->pdis);
-		writel(bit, &regs->dats);
-		break;
-	case PINMUX_TYPE_INPUT_PULLDOWN:
-		writel(bit, &regs->dirc);
-		val = readl(&regs->pdis) & ~bit;
-		writel(val, &regs->pdis);
-		writel(bit, &regs->datc);
-		break;
-	default:
-		err = 1;
-	}
-	spin_unlock_irqrestore(&chip->lock, flags);
-	if (err)
-		pr_err("%s: chip %p, pin %i, cfg %i is invalid\n",
-		       __func__, chip, nr, cfg);
-}
-
-/*
- * Irq methods
- */
-
-static void gsta_irq_disable(struct irq_data *data)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
-	struct gsta_gpio *chip = gc->private;
-	int nr = data->irq - chip->irq_base;
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-	u32 val;
-	unsigned long flags;
-
-	spin_lock_irqsave(&chip->lock, flags);
-	if (chip->irq_type[nr] & IRQ_TYPE_EDGE_RISING) {
-		val = readl(&regs->rimsc) & ~bit;
-		writel(val, &regs->rimsc);
-	}
-	if (chip->irq_type[nr] & IRQ_TYPE_EDGE_FALLING) {
-		val = readl(&regs->fimsc) & ~bit;
-		writel(val, &regs->fimsc);
-	}
-	spin_unlock_irqrestore(&chip->lock, flags);
-	return;
-}
-
-static void gsta_irq_enable(struct irq_data *data)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
-	struct gsta_gpio *chip = gc->private;
-	int nr = data->irq - chip->irq_base;
-	struct gsta_regs __iomem *regs = chip->regs[nr / GSTA_GPIO_PER_BLOCK];
-	u32 bit = BIT(nr % GSTA_GPIO_PER_BLOCK);
-	u32 val;
-	int type;
-	unsigned long flags;
-
-	type = chip->irq_type[nr];
-
-	spin_lock_irqsave(&chip->lock, flags);
-	val = readl(&regs->rimsc);
-	if (type & IRQ_TYPE_EDGE_RISING)
-		writel(val | bit, &regs->rimsc);
-	else
-		writel(val & ~bit, &regs->rimsc);
-	val = readl(&regs->rimsc);
-	if (type & IRQ_TYPE_EDGE_FALLING)
-		writel(val | bit, &regs->fimsc);
-	else
-		writel(val & ~bit, &regs->fimsc);
-	spin_unlock_irqrestore(&chip->lock, flags);
-	return;
-}
-
-static int gsta_irq_type(struct irq_data *d, unsigned int type)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	struct gsta_gpio *chip = gc->private;
-	int nr = d->irq - chip->irq_base;
-
-	/* We only support edge interrupts */
-	if (!(type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))) {
-		pr_debug("%s: unsupported type 0x%x\n", __func__, type);
-		return -EINVAL;
-	}
-
-	chip->irq_type[nr] = type; /* used for enable/disable */
-
-	gsta_irq_enable(d);
-	return 0;
-}
-
-static irqreturn_t gsta_gpio_handler(int irq, void *dev_id)
-{
-	struct gsta_gpio *chip = dev_id;
-	struct gsta_regs __iomem *regs;
-	u32 is;
-	int i, nr, base;
-	irqreturn_t ret = IRQ_NONE;
-
-	for (i = 0; i < GSTA_NR_BLOCKS; i++) {
-		regs = chip->regs[i];
-		base = chip->irq_base + i * GSTA_GPIO_PER_BLOCK;
-		while ((is = readl(&regs->is))) {
-			nr = __ffs(is);
-			irq = base + nr;
-			generic_handle_irq(irq);
-			writel(1 << nr, &regs->ic);
-			ret = IRQ_HANDLED;
-		}
-	}
-	return ret;
-}
-
-static int gsta_alloc_irq_chip(struct gsta_gpio *chip)
-{
-	struct irq_chip_generic *gc;
-	struct irq_chip_type *ct;
-	int rv;
-
-	gc = devm_irq_alloc_generic_chip(chip->dev, KBUILD_MODNAME, 1,
-					 chip->irq_base,
-					 chip->reg_base, handle_simple_irq);
-	if (!gc)
-		return -ENOMEM;
-
-	gc->private = chip;
-	ct = gc->chip_types;
-
-	ct->chip.irq_set_type = gsta_irq_type;
-	ct->chip.irq_disable = gsta_irq_disable;
-	ct->chip.irq_enable = gsta_irq_enable;
-
-	/* FIXME: this makes at most 32 interrupts. Request 0 by now */
-	rv = devm_irq_setup_generic_chip(chip->dev, gc,
-					 0 /* IRQ_MSK(GSTA_GPIO_PER_BLOCK) */,
-					 0, IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-	if (rv)
-		return rv;
-
-	/* Set up all 128 interrupts: code from setup_generic_chip */
-	{
-		struct irq_chip_type *ct = gc->chip_types;
-		int i, j;
-		for (j = 0; j < GSTA_NR_GPIO; j++) {
-			i = chip->irq_base + j;
-			irq_set_chip_and_handler(i, &ct->chip, ct->handler);
-			irq_set_chip_data(i, gc);
-			irq_clear_status_flags(i, IRQ_NOREQUEST | IRQ_NOPROBE);
-		}
-		gc->irq_cnt = i - gc->irq_base;
-	}
-
-	return 0;
-}
-
-/* The platform device used here is instantiated by the MFD device */
-static int gsta_probe(struct platform_device *dev)
-{
-	int i, err;
-	struct pci_dev *pdev;
-	struct sta2x11_gpio_pdata *gpio_pdata;
-	struct gsta_gpio *chip;
-
-	pdev = *(struct pci_dev **)dev_get_platdata(&dev->dev);
-	gpio_pdata = dev_get_platdata(&pdev->dev);
-
-	if (gpio_pdata == NULL)
-		dev_err(&dev->dev, "no gpio config\n");
-	pr_debug("gpio config: %p\n", gpio_pdata);
-
-	chip = devm_kzalloc(&dev->dev, sizeof(*chip), GFP_KERNEL);
-	if (!chip)
-		return -ENOMEM;
-	chip->dev = &dev->dev;
-	chip->reg_base = devm_platform_ioremap_resource(dev, 0);
-	if (IS_ERR(chip->reg_base))
-		return PTR_ERR(chip->reg_base);
-
-	for (i = 0; i < GSTA_NR_BLOCKS; i++) {
-		chip->regs[i] = chip->reg_base + i * 4096;
-		/* disable all irqs */
-		writel(0, &chip->regs[i]->rimsc);
-		writel(0, &chip->regs[i]->fimsc);
-		writel(~0, &chip->regs[i]->ic);
-	}
-	spin_lock_init(&chip->lock);
-	gsta_gpio_setup(chip);
-	if (gpio_pdata)
-		for (i = 0; i < GSTA_NR_GPIO; i++)
-			gsta_set_config(chip, i, gpio_pdata->pinconfig[i]);
-
-	/* 384 was used in previous code: be compatible for other drivers */
-	err = devm_irq_alloc_descs(&dev->dev, -1, 384,
-				   GSTA_NR_GPIO, NUMA_NO_NODE);
-	if (err < 0) {
-		dev_warn(&dev->dev, "sta2x11 gpio: Can't get irq base (%i)\n",
-			 -err);
-		return err;
-	}
-	chip->irq_base = err;
-
-	err = gsta_alloc_irq_chip(chip);
-	if (err)
-		return err;
-
-	err = devm_request_irq(&dev->dev, pdev->irq, gsta_gpio_handler,
-			       IRQF_SHARED, KBUILD_MODNAME, chip);
-	if (err < 0) {
-		dev_err(&dev->dev, "sta2x11 gpio: Can't request irq (%i)\n",
-			-err);
-		return err;
-	}
-
-	return devm_gpiochip_add_data(&dev->dev, &chip->gpio, chip);
-}
-
-static struct platform_driver sta2x11_gpio_platform_driver = {
-	.driver = {
-		.name	= "sta2x11-gpio",
-		.suppress_bind_attrs = true,
-	},
-	.probe = gsta_probe,
-};
-builtin_platform_driver(sta2x11_gpio_platform_driver);
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/9] gpio: aggregator: Stop using ARCH_NR_GPIOS

[Christophe Leroy]

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 <christophe.leroy@csgroup.eu>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/9] gpio: davinci: Stop using ARCH_NR_GPIOS

[Christophe Leroy]

Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
there is no global limitation anymore on the number of GPIOs in
the system so don't clamp the number of GPIOs with ARCH_NR_GPIOS.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/gpio/gpio-davinci.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 59c4c48d8296..1018860c83c2 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -217,9 +217,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	if (WARN_ON(ARCH_NR_GPIOS < ngpio))
-		ngpio = ARCH_NR_GPIOS;
-
 	/*
 	 * If there are unbanked interrupts then the number of
 	 * interrupts is equal to number of gpios else all are banked so
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 4/9] gpiolib: Warn on drivers still using static gpiobase allocation

[Christophe Leroy]

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 <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 5/9] gpiolib: Get rid of ARCH_NR_GPIOS

[Christophe Leroy]

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 upwards, allowing approx 2 millions of
GPIOs.

In order to still allow static allocation for legacy drivers, define
GPIO_DYNAMIC_BASE with the value 512 as the start for dynamic
allocation. The 512 value is chosen because it is the end of
the current default range so all current static allocations are
expected to be below that value. Of course that's just a rough
estimate based on the default value, but assuming static
allocations come first, even if there are more static allocations
it should fit under the 512 value.

In the future, it is expected that all static allocations go away
and then dynamic allocation will be patched to start at 0.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Enhanced commit description and change from 256 to 512.
---
 arch/arm/include/asm/gpio.h |  1 -
 drivers/gpio/gpiolib.c      | 10 +++----
 include/asm-generic/gpio.h  | 55 ++++++++++++++-----------------------
 3 files changed, 26 insertions(+), 40 deletions(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index f3bb8a2bf788..4ebbb58f06ea 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -2,7 +2,6 @@
 #ifndef _ARCH_ARM_GPIO_H
 #define _ARCH_ARM_GPIO_H
 
-/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
 #include <asm-generic/gpio.h>
 
 /* The trivial gpiolib dispatchers */
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 4e2fcb7b0a01..1846f24971e3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -183,14 +183,14 @@ EXPORT_SYMBOL_GPL(gpiod_to_chip);
 static int gpiochip_find_base(int ngpio)
 {
 	struct gpio_device *gdev;
-	int base = ARCH_NR_GPIOS - ngpio;
+	int base = GPIO_DYNAMIC_BASE;
 
-	list_for_each_entry_reverse(gdev, &gpio_devices, list) {
+	list_for_each_entry(gdev, &gpio_devices, list) {
 		/* found a free space? */
-		if (gdev->base + gdev->ngpio <= base)
+		if (gdev->base >= base + ngpio)
 			break;
-		/* nope, check the space right before the chip */
-		base = gdev->base - ngpio;
+		/* nope, check the space right after the chip */
+		base = gdev->base + gdev->ngpio;
 	}
 
 	if (gpio_is_valid(base)) {
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index aea9aee1f3e9..a7752cf152ce 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -11,40 +11,18 @@
 #include <linux/gpio/driver.h>
 #include <linux/gpio/consumer.h>
 
-/* Platforms may implement their GPIO interface with library code,
+/*
+ * Platforms may implement their GPIO interface with library code,
  * at a small performance cost for non-inlined operations and some
  * extra memory (for code and for per-GPIO table entries).
- *
- * While the GPIO programming interface defines valid GPIO numbers
- * to be in the range 0..MAX_INT, this library restricts them to the
- * smaller range 0..ARCH_NR_GPIOS-1.
- *
- * ARCH_NR_GPIOS is somewhat arbitrary; it usually reflects the sum of
- * builtin/SoC GPIOs plus a number of GPIOs on expanders; the latter is
- * actually an estimate of a board-specific value.
  */
 
-#ifndef ARCH_NR_GPIOS
-#if defined(CONFIG_ARCH_NR_GPIO) && CONFIG_ARCH_NR_GPIO > 0
-#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
-#else
-#define ARCH_NR_GPIOS		512
-#endif
-#endif
-
 /*
- * "valid" GPIO numbers are nonnegative and may be passed to
- * setup routines like gpio_request().  only some valid numbers
- * can successfully be requested and used.
- *
- * Invalid GPIO numbers are useful for indicating no-such-GPIO in
- * platform data and other tables.
+ * At the end we want all GPIOs to be dynamically allocated from 0.
+ * However, some legacy drivers still perform fixed allocation.
+ * Until they are all fixed, leave 0-512 space for them.
  */
-
-static inline bool gpio_is_valid(int number)
-{
-	return number >= 0 && number < ARCH_NR_GPIOS;
-}
+#define GPIO_DYNAMIC_BASE	512
 
 struct device;
 struct gpio;
@@ -140,12 +118,6 @@ static inline void gpio_unexport(unsigned gpio)
 
 #include <linux/kernel.h>
 
-static inline bool gpio_is_valid(int number)
-{
-	/* only non-negative numbers are valid */
-	return number >= 0;
-}
-
 /* platforms that don't directly support access to GPIOs through I2C, SPI,
  * or other blocking infrastructure can use these wrappers.
  */
@@ -169,4 +141,19 @@ static inline void gpio_set_value_cansleep(unsigned gpio, int value)
 
 #endif /* !CONFIG_GPIOLIB */
 
+/*
+ * "valid" GPIO numbers are nonnegative and may be passed to
+ * setup routines like gpio_request().  only some valid numbers
+ * can successfully be requested and used.
+ *
+ * Invalid GPIO numbers are useful for indicating no-such-GPIO in
+ * platform data and other tables.
+ */
+
+static inline bool gpio_is_valid(int number)
+{
+	/* only non-negative numbers are valid */
+	return number >= 0;
+}
+
 #endif /* _ASM_GENERIC_GPIO_H */
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 6/9] Documentation: gpio: Remove text about ARCH_NR_GPIOS

[Christophe Leroy]

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 <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 7/9] x86: Remove CONFIG_ARCH_NR_GPIO

[Christophe Leroy]

CONFIG_ARCH_NR_GPIO is not used anymore, remove it.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 arch/x86/Kconfig | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..0385d5273e37 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -345,11 +345,6 @@ config ARCH_HAS_CPU_RELAX
 config ARCH_HIBERNATION_POSSIBLE
 	def_bool y
 
-config ARCH_NR_GPIO
-	int
-	default 1024 if X86_64
-	default 512
-
 config ARCH_SUSPEND_POSSIBLE
 	def_bool y
 
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 8/9] arm: Remove CONFIG_ARCH_NR_GPIO

[Christophe Leroy]

CONFIG_ARCH_NR_GPIO is not used anymore, remove it.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 arch/arm/Kconfig | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 87badeae3181..5bfdb78a2d82 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1227,27 +1227,6 @@ config ARM_PSCI
 	  0022A ("Power State Coordination Interface System Software on
 	  ARM processors").
 
-# The GPIO number here must be sorted by descending number. In case of
-# a multiplatform kernel, we just want the highest value required by the
-# selected platforms.
-config ARCH_NR_GPIO
-	int
-	default 2048 if ARCH_INTEL_SOCFPGA
-	default 1024 if ARCH_BRCMSTB || ARCH_RENESAS || ARCH_TEGRA || \
-		ARCH_ZYNQ || ARCH_ASPEED
-	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \
-		SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
-	default 416 if ARCH_SUNXI
-	default 392 if ARCH_U8500
-	default 352 if ARCH_VT8500
-	default 288 if ARCH_ROCKCHIP
-	default 264 if MACH_H4700
-	default 0
-	help
-	  Maximum number of GPIOs in the system.
-
-	  If unsure, leave the default value.
-
 config HZ_FIXED
 	int
 	default 128 if SOC_AT91RM9200
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 9/9] arm64: Remove CONFIG_ARCH_NR_GPIO

[Christophe Leroy]

CONFIG_ARCH_NR_GPIO is not used anymore, remove it.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 arch/arm64/Kconfig | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fb9fff08c94..4d7158e484d2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2110,18 +2110,6 @@ config STACKPROTECTOR_PER_TASK
 	def_bool y
 	depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_SYSREG
 
-# The GPIO number here must be sorted by descending number. In case of
-# a multiplatform kernel, we just want the highest value required by the
-# selected platforms.
-config ARCH_NR_GPIO
-        int
-        default 2048 if ARCH_APPLE
-        default 0
-        help
-          Maximum number of GPIOs in the system.
-
-          If unsure, leave the default value.
-
 endmenu # "Kernel Features"
 
 menu "Boot options"
-- 
2.37.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 5/9] gpiolib: Get rid of ARCH_NR_GPIOS

[Andy Shevchenko]

On Fri, Sep 2, 2022 at 4:57 PM Christophe Leroy
<christophe.leroy@csgroup.eu> 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 upwards, allowing approx 2 millions of
> GPIOs.
>
> In order to still allow static allocation for legacy drivers, define
> GPIO_DYNAMIC_BASE with the value 512 as the start for dynamic
> allocation. The 512 value is chosen because it is the end of
> the current default range so all current static allocations are
> expected to be below that value. Of course that's just a rough
> estimate based on the default value, but assuming static
> allocations come first, even if there are more static allocations
> it should fit under the 512 value.
>
> In the future, it is expected that all static allocations go away
> and then dynamic allocation will be patched to start at 0.

Eventually we have to get rid of gpio_is_valid() completely...
But this is another story.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> v2: Enhanced commit description and change from 256 to 512.
> ---
>  arch/arm/include/asm/gpio.h |  1 -
>  drivers/gpio/gpiolib.c      | 10 +++----
>  include/asm-generic/gpio.h  | 55 ++++++++++++++-----------------------
>  3 files changed, 26 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> index f3bb8a2bf788..4ebbb58f06ea 100644
> --- a/arch/arm/include/asm/gpio.h
> +++ b/arch/arm/include/asm/gpio.h
> @@ -2,7 +2,6 @@
>  #ifndef _ARCH_ARM_GPIO_H
>  #define _ARCH_ARM_GPIO_H
>
> -/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
>  #include <asm-generic/gpio.h>
>
>  /* The trivial gpiolib dispatchers */
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 4e2fcb7b0a01..1846f24971e3 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -183,14 +183,14 @@ EXPORT_SYMBOL_GPL(gpiod_to_chip);
>  static int gpiochip_find_base(int ngpio)
>  {
>         struct gpio_device *gdev;
> -       int base = ARCH_NR_GPIOS - ngpio;
> +       int base = GPIO_DYNAMIC_BASE;
>
> -       list_for_each_entry_reverse(gdev, &gpio_devices, list) {
> +       list_for_each_entry(gdev, &gpio_devices, list) {
>                 /* found a free space? */
> -               if (gdev->base + gdev->ngpio <= base)
> +               if (gdev->base >= base + ngpio)
>                         break;
> -               /* nope, check the space right before the chip */
> -               base = gdev->base - ngpio;
> +               /* nope, check the space right after the chip */
> +               base = gdev->base + gdev->ngpio;
>         }
>
>         if (gpio_is_valid(base)) {
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index aea9aee1f3e9..a7752cf152ce 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -11,40 +11,18 @@
>  #include <linux/gpio/driver.h>
>  #include <linux/gpio/consumer.h>
>
> -/* Platforms may implement their GPIO interface with library code,
> +/*
> + * Platforms may implement their GPIO interface with library code,
>   * at a small performance cost for non-inlined operations and some
>   * extra memory (for code and for per-GPIO table entries).
> - *
> - * While the GPIO programming interface defines valid GPIO numbers
> - * to be in the range 0..MAX_INT, this library restricts them to the
> - * smaller range 0..ARCH_NR_GPIOS-1.
> - *
> - * ARCH_NR_GPIOS is somewhat arbitrary; it usually reflects the sum of
> - * builtin/SoC GPIOs plus a number of GPIOs on expanders; the latter is
> - * actually an estimate of a board-specific value.
>   */
>
> -#ifndef ARCH_NR_GPIOS
> -#if defined(CONFIG_ARCH_NR_GPIO) && CONFIG_ARCH_NR_GPIO > 0
> -#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
> -#else
> -#define ARCH_NR_GPIOS          512
> -#endif
> -#endif
> -
>  /*
> - * "valid" GPIO numbers are nonnegative and may be passed to
> - * setup routines like gpio_request().  only some valid numbers
> - * can successfully be requested and used.
> - *
> - * Invalid GPIO numbers are useful for indicating no-such-GPIO in
> - * platform data and other tables.
> + * At the end we want all GPIOs to be dynamically allocated from 0.
> + * However, some legacy drivers still perform fixed allocation.
> + * Until they are all fixed, leave 0-512 space for them.
>   */
> -
> -static inline bool gpio_is_valid(int number)
> -{
> -       return number >= 0 && number < ARCH_NR_GPIOS;
> -}
> +#define GPIO_DYNAMIC_BASE      512
>
>  struct device;
>  struct gpio;
> @@ -140,12 +118,6 @@ static inline void gpio_unexport(unsigned gpio)
>
>  #include <linux/kernel.h>
>
> -static inline bool gpio_is_valid(int number)
> -{
> -       /* only non-negative numbers are valid */
> -       return number >= 0;
> -}
> -
>  /* platforms that don't directly support access to GPIOs through I2C, SPI,
>   * or other blocking infrastructure can use these wrappers.
>   */
> @@ -169,4 +141,19 @@ static inline void gpio_set_value_cansleep(unsigned gpio, int value)
>
>  #endif /* !CONFIG_GPIOLIB */
>
> +/*
> + * "valid" GPIO numbers are nonnegative and may be passed to
> + * setup routines like gpio_request().  only some valid numbers
> + * can successfully be requested and used.
> + *
> + * Invalid GPIO numbers are useful for indicating no-such-GPIO in
> + * platform data and other tables.
> + */
> +
> +static inline bool gpio_is_valid(int number)
> +{
> +       /* only non-negative numbers are valid */
> +       return number >= 0;
> +}
> +
>  #endif /* _ASM_GENERIC_GPIO_H */
> --
> 2.37.1
>


-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 5/9] gpiolib: Get rid of ARCH_NR_GPIOS

[Christophe Leroy]

Le 02/09/2022 à 16:58, Andy Shevchenko a écrit :
> On Fri, Sep 2, 2022 at 4:57 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> 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 upwards, allowing approx 2 millions of
>> GPIOs.
>>
>> In order to still allow static allocation for legacy drivers, define
>> GPIO_DYNAMIC_BASE with the value 512 as the start for dynamic
>> allocation. The 512 value is chosen because it is the end of
>> the current default range so all current static allocations are
>> expected to be below that value. Of course that's just a rough
>> estimate based on the default value, but assuming static
>> allocations come first, even if there are more static allocations
>> it should fit under the 512 value.
>>
>> In the future, it is expected that all static allocations go away
>> and then dynamic allocation will be patched to start at 0.
> 
> Eventually we have to get rid of gpio_is_valid() completely...
> But this is another story.
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Yes that could be done as a follow-up.

There are about 300 call sites.

Should simply replace gpio_is_valid(gpio) by gpio >= 0. And then verify 
that the check is really required. But needs to check signness of gpio 
at every place.

First look seems already promissing:


int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
	struct gpio_desc *desc;
	int err;

	desc = gpio_to_desc(gpio);

	/* Compatibility: assume unavailable "valid" GPIOs will appear later */
	if (!desc && gpio_is_valid(gpio))
		return -EPROBE_DEFER;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Bartosz Golaszewski]

On Fri, Sep 2, 2022 at 2:42 PM Christophe Leroy
<christophe.leroy@csgroup.eu> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Arnd Bergmann]

On Wed, Sep 7, 2022, at 11:58 AM, Bartosz Golaszewski wrote:
> On Fri, Sep 2, 2022 at 2:42 PM Christophe Leroy <christophe.leroy@csgroup.eu> 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 <arnd@arndb.de>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Linus Walleij]

On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <arnd@arndb.de> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Andy Shevchenko]

On Wed, Sep 14, 2022 at 02:38:53PM +0200, Linus Walleij wrote:
> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <arnd@arndb.de> 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 <andriy.shevchenko@linux.intel.com>
for either of the variants if it helps.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Arnd Bergmann]

On Wed, Sep 14, 2022, at 2:38 PM, Linus Walleij wrote:
> On Wed, Sep 7, 2022 at 12:15 PM Arnd Bergmann <arnd@arndb.de> 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/Yw3LQjhZWmZaU2N1@arcana.i.gnudd.com/
https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/

    Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Christophe Leroy]

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 <arnd@arndb.de> 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/Yw3LQjhZWmZaU2N1@arcana.i.gnudd.com/
> https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/
> 

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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Bartosz Golaszewski]

On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
<christophe.leroy@csgroup.eu> 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 <arnd@arndb.de> 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/Yw3LQjhZWmZaU2N1@arcana.i.gnudd.com/
> > https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/
> >
>
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Bartosz Golaszewski]

On Fri, Oct 14, 2022 at 4:22 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> 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 <arnd@arndb.de> 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/Yw3LQjhZWmZaU2N1@arcana.i.gnudd.com/
> > > https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/
> > >
> >
> > 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Linus Walleij]

On Mon, Oct 17, 2022 at 11:05 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Fri, Oct 14, 2022 at 4:22 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Fri, Oct 14, 2022 at 4:13 PM Christophe Leroy
> > <christophe.leroy@csgroup.eu> 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 <arnd@arndb.de> 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/Yw3LQjhZWmZaU2N1@arcana.i.gnudd.com/
> > > > https://lore.kernel.org/lkml/Yw3DKCuDoPkCaqxE@arcana.i.gnudd.com/
> > > >
> > >
> > > 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 7/9] x86: Remove CONFIG_ARCH_NR_GPIO

[Thomas Gleixner]

On Fri, Sep 02 2022 at 14:42, Christophe Leroy wrote:
> CONFIG_ARCH_NR_GPIO is not used anymore, remove it.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2)

[Andy Shevchenko]

On Mon, Oct 17, 2022 at 11:06:49AM +0200, Linus Walleij wrote:
> On Mon, Oct 17, 2022 at 11:05 AM Bartosz Golaszewski <brgl@bgdev.pl> 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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel