* Re: [PATCH] gpio: mvebu: add wake-up interrupt support
From: Bartosz Golaszewski @ 2026-07-01 10:34 UTC (permalink / raw)
To: linux-gpio, Rosen Penev
Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski,
linux-kernel
In-Reply-To: <20260628230202.1209991-1-rosenp@gmail.com>
On Sun, 28 Jun 2026 16:02:02 -0700, Rosen Penev wrote:
> Implement wake IRQ support for the mvebu GPIO controller:
>
> - Replace unused irqbase field with bank_irq[4] to store per-bank
> IRQ numbers for use in the wake-up callback.
> - Add mvebu_gpio_set_wake_irq() that forwards enable_irq_wake /
> disable_irq_wake to the correct parent IRQ based on hwirq.
> - Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags
> on both level and edge chip types.
> - Set IRQ_GC_INIT_NESTED_LOCK for the nested irq domain.
> - Add missing <linux/interrupt.h> include.
>
> [...]
Applied, thanks!
[1/1] gpio: mvebu: add wake-up interrupt support
https://git.kernel.org/brgl/c/b67e64d4eb9765d23010f423e29a627a25f5ac2e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 0/6] gpio: siul2-s32g2: add initial GPIO driver
From: Linus Walleij @ 2026-07-01 10:28 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Dong Aisheng, Jacky Bai, Greg Kroah-Hartman, Rafael J. Wysocki,
Srinivas Kandagatla, Alberto Ruiz, Christophe Lizzi, devicetree,
Enric Balletbo, Eric Chanudet, imx, linux-arm-kernel, linux-gpio,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot
In-Reply-To: <20260630125403.546375-1-khristineandreea.barbulescu@oss.nxp.com>
Hi Khristine,
thanks for the updated patches!
On Tue, Jun 30, 2026 at 2:54 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
> Andrei Stefanescu (2):
> pinctrl: s32cc: change to "devm_pinctrl_register_and_init"
> pinctrl: s32cc: implement GPIO functionality
>
> Khristine Andreea Barbulescu (4):
> pinctrl: s32cc: add/fix some comments
> pinctrl: s32cc: remove inline specifiers
> dt-bindings: pinctrl: s32g2-siul2: describe GPIO and EIRQ resources
I applied these 5 patches to the pin control tree.
> arm64: dts: s32g: describe GPIO and EIRQ resources in SIUL2 pinctrl
> node
Please funnel this one through the SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v10] i2c: designware: defer probe if child GpioInt controllers are not bound
From: Hardik Prakash @ 2026-07-01 10:12 UTC (permalink / raw)
To: linux-i2c
Cc: linux-gpio, wsa, andriy.shevchenko, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah,
Hardik Prakash
I2C controllers may have child devices with GpioInt resources that
depend on GPIO controllers to be fully initialized. If the I2C
controller probes and enumerates children before the referenced GPIO
controller has completed probe, GPIO interrupts may not be properly
configured, leading to device failures.
On Lenovo Yoga 7 14AGP11, the WACF2200 touchscreen (child of
AMDI0010:02) has a GpioInt resource pointing to GPIO 157 on the
pinctrl-amd controller (AMDI0030:00). When i2c-designware probes
AMDI0010:02 before pinctrl-amd finishes initializing, I2C transactions
fail with lost arbitration errors.
Add a generic dependency check in i2c-designware that walks ACPI child
devices, identifies any GpioInt resources, resolves the referenced GPIO
controllers, and defers probe if those controllers are not yet bound.
Uses acpi_gpio_get_irq_resource() to avoid duplicating GPIO resource
parsing logic from gpiolib-acpi. Skips resources with no resource
source string (string_length == 0 or string_ptr == NULL) to avoid
crashes on hardware where GPIO resources have no named controller.
The probe ordering race was confirmed via dynamic debug tracing:
0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
2.348157 lost arbitration
Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
Assisted-by: Claude:claude-sonnet-4-6
Assisted-by: GPT:gpt-5.4-mini
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
---
drivers/i2c/busses/i2c-designware-platdrv.c | 132 ++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 6d6e81242f74..d8331d1dead8 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,6 +8,8 @@
* Copyright (C) 2007 MontaVista Software Inc.
* Copyright (C) 2009 Provigent Ltd.
*/
+
+#include <linux/acpi.h>
#include <linux/clk-provider.h>
#include <linux/clk.h>
#include <linux/delay.h>
@@ -130,6 +132,132 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
return 0;
}
+#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
+struct gpio_controller_ref {
+ struct list_head node;
+ const char *path;
+};
+
+static void free_gpio_controller_list(struct list_head *gpio_controllers)
+{
+ struct gpio_controller_ref *ref, *tmp;
+
+ list_for_each_entry_safe(ref, tmp, gpio_controllers, node) {
+ list_del(&ref->node);
+ kfree(ref->path);
+ kfree(ref);
+ }
+}
+
+static int check_gpioint_resource(struct acpi_resource *ares, void *data)
+{
+ struct list_head *gpio_controllers = data;
+ struct acpi_resource_gpio *agpio;
+ struct gpio_controller_ref *ref;
+
+ if (!acpi_gpio_get_irq_resource(ares, &agpio))
+ return 1;
+
+ if (!agpio->resource_source.string_length)
+ return 1;
+
+ /* Skip if we've already tracked this GPIO controller */
+ list_for_each_entry(ref, gpio_controllers, node) {
+ if (!strncmp(ref->path, agpio->resource_source.string_ptr,
+ agpio->resource_source.string_length))
+ return 1;
+ }
+
+ ref = kzalloc(sizeof(*ref), GFP_KERNEL);
+ if (!ref)
+ return -ENOMEM;
+
+ ref->path = kstrdup(agpio->resource_source.string_ptr, GFP_KERNEL);
+ if (!ref->path) {
+ kfree(ref);
+ return -ENOMEM;
+ }
+
+ list_add_tail(&ref->node, gpio_controllers);
+ return 1;
+}
+
+static int check_child_gpioint(struct acpi_device *adev, void *data)
+{
+ struct list_head res_list;
+ int ret;
+
+ INIT_LIST_HEAD(&res_list);
+ ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, data);
+ if (ret < 0)
+ return ret;
+
+ acpi_dev_free_resource_list(&res_list);
+ return 0;
+}
+
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+ struct gpio_controller_ref *ref;
+ LIST_HEAD(gpio_controllers);
+ struct acpi_device *adev;
+ int ret;
+
+ adev = ACPI_COMPANION(dev);
+ if (!adev)
+ return 0;
+
+ /* Walk all child devices and collect GpioInt controller references */
+ ret = acpi_dev_for_each_child(adev, check_child_gpioint, &gpio_controllers);
+ if (ret < 0)
+ goto cleanup;
+
+ /* For each GPIO controller, check if its platform device is bound */
+ list_for_each_entry(ref, &gpio_controllers, node) {
+ struct acpi_device *gpio_adev;
+ struct device *gpio_dev;
+ acpi_status status;
+ acpi_handle handle;
+ bool bound;
+
+ status = acpi_get_handle(NULL, ref->path, &handle);
+ if (ACPI_FAILURE(status))
+ continue;
+
+ gpio_adev = acpi_fetch_acpi_dev(handle);
+ if (!gpio_adev)
+ continue;
+
+ gpio_dev = acpi_get_first_physical_node(gpio_adev);
+ acpi_dev_put(gpio_adev);
+ if (gpio_dev) {
+ guard(device)(gpio_dev);
+ bound = device_is_bound(gpio_dev);
+ } else {
+ bound = false;
+ }
+ /*
+ * Defer probe until the GPIO controller is fully bound,
+ * ensuring its IRQ setup is complete before we enumerate
+ * I2C child devices.
+ */
+ if (!bound) {
+ ret = -EPROBE_DEFER;
+ goto cleanup;
+ }
+ }
+
+cleanup:
+ free_gpio_controller_list(&gpio_controllers);
+ return ret;
+}
+#else
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+ return 0;
+}
+#endif /* CONFIG_ACPI && CONFIG_GPIOLIB */
+
static int dw_i2c_plat_probe(struct platform_device *pdev)
{
u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
@@ -138,6 +266,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
struct dw_i2c_dev *dev;
int irq, ret;
+ ret = i2c_dw_check_gpio_dependencies(device);
+ if (ret)
+ return ret;
+
irq = platform_get_irq_optional(pdev, 0);
if (irq == -ENXIO)
flags |= ACCESS_POLLING;
base-commit: 5a66900afbd6b2a063eebad35294038a654de2b0
--
2.54.0
^ permalink raw reply related
* [PATCH v2 9/9] MIPS: TXX9: Clean up txx9_iocled_init()
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski, Philippe Mathieu-Daudé
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
The sole caller already uses dynamic GPIO base allocation, so drop
support for static allocation.
While at it, drop the no longer used "lowactive" parameter.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/include/asm/txx9/generic.h | 3 +--
arch/mips/txx9/generic/setup.c | 12 ++++--------
arch/mips/txx9/rbtx4927/setup.c | 2 +-
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/mips/include/asm/txx9/generic.h b/arch/mips/include/asm/txx9/generic.h
index 5ce5b8579a444ec3..653315fb6ca559a7 100644
--- a/arch/mips/include/asm/txx9/generic.h
+++ b/arch/mips/include/asm/txx9/generic.h
@@ -79,8 +79,7 @@ static inline unsigned int __fls8(unsigned char x)
return r;
}
-void txx9_iocled_init(unsigned long baseaddr,
- int basenum, unsigned int num, int lowactive,
+void txx9_iocled_init(unsigned long baseaddr, unsigned int num,
const char *color, char **deftriggers);
void __init txx9_aclc_init(unsigned long baseaddr, int irq,
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index 32246f5f78f5070c..5f66236038c8f468 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -625,8 +625,7 @@ static struct gpiod_lookup_table txx9_iocled_table = {
},
};
-void __init txx9_iocled_init(unsigned long baseaddr,
- int basenum, unsigned int num, int lowactive,
+void __init txx9_iocled_init(unsigned long baseaddr, unsigned int num,
const char *color, char **deftriggers)
{
struct txx9_iocled_data *iocled;
@@ -652,14 +651,12 @@ void __init txx9_iocled_init(unsigned long baseaddr,
iocled->chip.direction_input = txx9_iocled_dir_in;
iocled->chip.direction_output = txx9_iocled_dir_out;
iocled->chip.label = "iocled";
- iocled->chip.base = basenum;
+ iocled->chip.base = -1;
iocled->chip.ngpio = num;
if (gpiochip_add_data(&iocled->chip, iocled))
goto out_unmap;
- if (basenum < 0)
- basenum = iocled->chip.base;
- pdev = platform_device_alloc("leds-gpio", basenum);
+ pdev = platform_device_alloc("leds-gpio", iocled->chip.base);
if (!pdev)
goto out_gpio;
iocled->pdata.num_leds = num;
@@ -689,8 +686,7 @@ void __init txx9_iocled_init(unsigned long baseaddr,
kfree(iocled);
}
#else /* CONFIG_LEDS_GPIO */
-void __init txx9_iocled_init(unsigned long baseaddr,
- int basenum, unsigned int num, int lowactive,
+void __init txx9_iocled_init(unsigned long baseaddr, unsigned int num,
const char *color, char **deftriggers)
{
}
diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index e904217a5fb20102..223889c031866ca3 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -373,7 +373,7 @@ static void __init rbtx4927_device_init(void)
tx4938_aclc_init();
}
platform_device_register_simple("txx9aclc-generic", -1, NULL, 0);
- txx9_iocled_init(RBTX4927_LED_ADDR - IO_BASE, -1, 3, 1, "green", NULL);
+ txx9_iocled_init(RBTX4927_LED_ADDR - IO_BASE, 3, "green", NULL);
rbtx4927_gpioled_init();
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 8/9] MIPS: TXX9: Convert gpio_txx9 to dynamic GPIO base allocation
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
Static allocation of GPIO base is deprecated, use dynamic allocation.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/include/asm/txx9pio.h | 3 +--
arch/mips/kernel/gpio_txx9.c | 5 ++---
arch/mips/txx9/rbtx4927/setup.c | 4 ++--
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/mips/include/asm/txx9pio.h b/arch/mips/include/asm/txx9pio.h
index 3d6fa9f8d5135411..c33a977244005479 100644
--- a/arch/mips/include/asm/txx9pio.h
+++ b/arch/mips/include/asm/txx9pio.h
@@ -23,7 +23,6 @@ struct txx9_pio_reg {
__u32 maskext;
};
-int txx9_gpio_init(unsigned long baseaddr,
- unsigned int base, unsigned int num);
+int txx9_gpio_init(unsigned long baseaddr, unsigned int num);
#endif /* __ASM_TXX9PIO_H */
diff --git a/arch/mips/kernel/gpio_txx9.c b/arch/mips/kernel/gpio_txx9.c
index 96ac40d20c238018..b2e73263d94c8419 100644
--- a/arch/mips/kernel/gpio_txx9.c
+++ b/arch/mips/kernel/gpio_txx9.c
@@ -76,13 +76,12 @@ static struct gpio_chip txx9_gpio_chip = {
.label = "TXx9",
};
-int __init txx9_gpio_init(unsigned long baseaddr,
- unsigned int base, unsigned int num)
+int __init txx9_gpio_init(unsigned long baseaddr, unsigned int num)
{
txx9_pioptr = ioremap(baseaddr, sizeof(struct txx9_pio_reg));
if (!txx9_pioptr)
return -ENODEV;
- txx9_gpio_chip.base = base;
+ txx9_gpio_chip.base = -1;
txx9_gpio_chip.ngpio = num;
return gpiochip_add_data(&txx9_gpio_chip, NULL);
}
diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index 75674b4cc91d7207..e904217a5fb20102 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -178,7 +178,7 @@ static void __init rbtx4927_gpio_init(void)
static void __init rbtx4927_arch_init(void)
{
- txx9_gpio_init(TX4927_PIO_REG & 0xfffffffffULL, 0, TX4927_NUM_PIO);
+ txx9_gpio_init(TX4927_PIO_REG & 0xfffffffffULL, TX4927_NUM_PIO);
rbtx4927_gpio_init();
@@ -187,7 +187,7 @@ static void __init rbtx4927_arch_init(void)
static void __init rbtx4937_arch_init(void)
{
- txx9_gpio_init(TX4938_PIO_REG & 0xfffffffffULL, 0, TX4938_NUM_PIO);
+ txx9_gpio_init(TX4938_PIO_REG & 0xfffffffffULL, TX4938_NUM_PIO);
rbtx4927_gpio_init();
--
2.43.0
^ permalink raw reply related
* [PATCH v2 7/9] MIPS: TXX9: Drop GPIOLIB_LEGACY select
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
TXx has been converted away from the old-style gpiolib interfaces.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/txx9/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/txx9/Kconfig b/arch/mips/txx9/Kconfig
index 92b759a434c0eedf..7335efa4d52801dc 100644
--- a/arch/mips/txx9/Kconfig
+++ b/arch/mips/txx9/Kconfig
@@ -37,7 +37,6 @@ config SOC_TX4927
select IRQ_TXX9
select PCI_TX4927
select GPIO_TXX9
- select GPIOLIB_LEGACY
config SOC_TX4938
bool
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/9] MIPS: TXX9: Use GPIO lookup table for iocled LEDs
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
Convert iocled LED description from legacy GPIO numbers to GPIO
descriptors using a GPIO lookup table.
For now, just ignore the "lowactive" parameter, and force
GPIO_ACTIVE_LOW, as that is what the sole caller wants.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/txx9/generic/setup.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index 611ccbe429cfe7e1..32246f5f78f5070c 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -19,6 +19,7 @@
#include <linux/clkdev.h>
#include <linux/err.h>
#include <linux/gpio/driver.h>
+#include <linux/gpio/machine.h>
#include <linux/platform_device.h>
#include <linux/platform_data/txx9/ndfmc.h>
#include <linux/serial_core.h>
@@ -615,6 +616,15 @@ static int txx9_iocled_dir_out(struct gpio_chip *chip, unsigned int offset,
return 0;
}
+static struct gpiod_lookup_table txx9_iocled_table = {
+ .table = {
+ GPIO_LOOKUP_IDX("iocled", 0, NULL, 0, GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP_IDX("iocled", 1, NULL, 1, GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP_IDX("iocled", 2, NULL, 2, GPIO_ACTIVE_LOW),
+ { },
+ },
+};
+
void __init txx9_iocled_init(unsigned long baseaddr,
int basenum, unsigned int num, int lowactive,
const char *color, char **deftriggers)
@@ -659,14 +669,14 @@ void __init txx9_iocled_init(unsigned long baseaddr,
snprintf(iocled->names[i], sizeof(iocled->names[i]),
"iocled:%s:%u", color, i);
led->name = iocled->names[i];
- led->gpio = basenum + i;
- led->active_low = lowactive;
if (deftriggers && *deftriggers)
led->default_trigger = *deftriggers++;
}
pdev->dev.platform_data = &iocled->pdata;
if (platform_device_add(pdev))
goto out_pdev;
+ txx9_iocled_table.dev_id = dev_name(&pdev->dev);
+ gpiod_add_lookup_table(&txx9_iocled_table);
return;
out_pdev:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/9] MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski, Philippe Mathieu-Daudé
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
The number of available GPIOs and LEDs on the TXx9 IOC FPGA depends on
the platform. Since commit 455481fc9a807798 ("MIPS: Remove TX39XX
support"), the only remaining platform (rbtx4927) supports just three.
Hence reduce the maximum number, to reduce allocation size.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/txx9/generic/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index 97102d3327d22828..611ccbe429cfe7e1 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -569,7 +569,7 @@ void __init txx9_ndfmc_init(unsigned long baseaddr,
#if IS_ENABLED(CONFIG_LEDS_GPIO)
static DEFINE_SPINLOCK(txx9_iocled_lock);
-#define TXX9_IOCLED_MAXLEDS 8
+#define TXX9_IOCLED_MAXLEDS 3 /* rbtx4927 */
struct txx9_iocled_data {
struct gpio_chip chip;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/9] MIPS: TXX9: rbtx4927: Use GPIO lookup table for TXx9 LEDs
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
Convert TXx9 LED description from legacy GPIO numbers to GPIO
descriptors using a GPIO lookup table.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by,
- Return early on platform_device_add() failure.
---
arch/mips/txx9/rbtx4927/setup.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index e57c409c318ca220..75674b4cc91d7207 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -327,11 +327,19 @@ static void __init rbtx4927_mtd_init(void)
tx4927_mtd_init(i);
}
+static struct gpiod_lookup_table rbtx4927_gpioled_table = {
+ .table = {
+ GPIO_LOOKUP_IDX("TXx9", 0, NULL, 0, GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP_IDX("TXx9", 1, NULL, 1, GPIO_ACTIVE_LOW),
+ { },
+ },
+};
+
static void __init rbtx4927_gpioled_init(void)
{
static const struct gpio_led leds[] = {
- { .name = "gpioled:green:0", .gpio = 0, .active_low = 1, },
- { .name = "gpioled:green:1", .gpio = 1, .active_low = 1, },
+ { .name = "gpioled:green:0", },
+ { .name = "gpioled:green:1", },
};
static struct gpio_led_platform_data pdata = {
.num_leds = ARRAY_SIZE(leds),
@@ -342,8 +350,13 @@ static void __init rbtx4927_gpioled_init(void)
if (!pdev)
return;
pdev->dev.platform_data = &pdata;
- if (platform_device_add(pdev))
+ if (platform_device_add(pdev)) {
platform_device_put(pdev);
+ return;
+ }
+
+ rbtx4927_gpioled_table.dev_id = dev_name(&pdev->dev);
+ gpiod_add_lookup_table(&rbtx4927_gpioled_table);
}
static void __init rbtx4927_device_init(void)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/9] MIPS: TXX9: rbtx4927: Use GPIO lookup table for SIO DTR
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
Convert SIO DTR handling from legacy GPIO calls to GPIO descriptors
using a GPIO lookup table.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/txx9/rbtx4927/setup.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index 31955c1d55550fd4..e57c409c318ca220 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -49,6 +49,7 @@
#include <linux/platform_device.h>
#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/leds.h>
#include <asm/io.h>
#include <asm/reboot.h>
@@ -157,11 +158,20 @@ static inline void tx4927_pci_setup(void) {}
static inline void tx4937_pci_setup(void) {}
#endif /* CONFIG_PCI */
+/* TX4927-SIO DTR on (PIO[15]) */
+GPIO_LOOKUP_SINGLE(sio_gpio_table, NULL, "TXx9", 15, "sio-dtr",
+ GPIO_ACTIVE_HIGH);
+
static void __init rbtx4927_gpio_init(void)
{
- /* TX4927-SIO DTR on (PIO[15]) */
- gpio_request(15, "sio-dtr");
- gpio_direction_output(15, 1);
+ struct gpio_desc *d;
+
+ gpiod_add_lookup_table(&sio_gpio_table);
+ d = gpiod_get(NULL, "sio-dtr", GPIOD_OUT_HIGH);
+ if (IS_ERR(d))
+ pr_err("Unable to get sio-dtr GPIO descriptor\n");
+ else
+ gpiod_put(d);
tx4927_sio_init(0, 0);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/9] MIPS: TXX9: Remove txx9_7segled_*() forward declarations
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski, Philippe Mathieu-Daudé
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
The actual implementation was removed in commit 5a8df9281b052ff3 ("MIPS:
TXX9: Remove rbtx4939 board support").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/include/asm/txx9/generic.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/mips/include/asm/txx9/generic.h b/arch/mips/include/asm/txx9/generic.h
index 3813ab9ccf717ada..5ce5b8579a444ec3 100644
--- a/arch/mips/include/asm/txx9/generic.h
+++ b/arch/mips/include/asm/txx9/generic.h
@@ -83,11 +83,6 @@ void txx9_iocled_init(unsigned long baseaddr,
int basenum, unsigned int num, int lowactive,
const char *color, char **deftriggers);
-/* 7SEG LED */
-void txx9_7segled_init(unsigned int num,
- void (*putc)(unsigned int pos, unsigned char val));
-int txx9_7segled_putc(unsigned int pos, char c);
-
void __init txx9_aclc_init(unsigned long baseaddr, int irq,
unsigned int dmac_id,
unsigned int dma_chan_out,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/9] MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init()
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven,
Bartosz Golaszewski, Philippe Mathieu-Daudé
In-Reply-To: <cover.1782900491.git.geert@linux-m68k.org>
The last user of tx4938_spi_init() was removed in commit
21d638ef9483d8cf ("MIPS: TXX9: Remove rbtx4938 board support").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2:
- Add Reviewed-by.
---
arch/mips/include/asm/txx9/generic.h | 1 -
arch/mips/include/asm/txx9/tx4938.h | 1 -
arch/mips/txx9/generic/setup.c | 17 -----------------
arch/mips/txx9/generic/setup_tx4938.c | 6 ------
4 files changed, 25 deletions(-)
diff --git a/arch/mips/include/asm/txx9/generic.h b/arch/mips/include/asm/txx9/generic.h
index 9a2c47bf3c4045e7..3813ab9ccf717ada 100644
--- a/arch/mips/include/asm/txx9/generic.h
+++ b/arch/mips/include/asm/txx9/generic.h
@@ -45,7 +45,6 @@ extern int (*txx9_irq_dispatch)(int pending);
const char *prom_getenv(const char *name);
void txx9_wdt_init(unsigned long base);
void txx9_wdt_now(unsigned long base);
-void txx9_spi_init(int busid, unsigned long base, int irq);
void txx9_ethaddr_init(unsigned int id, unsigned char *ethaddr);
void txx9_sio_init(unsigned long baseaddr, int irq,
unsigned int line, unsigned int sclk, int nocts);
diff --git a/arch/mips/include/asm/txx9/tx4938.h b/arch/mips/include/asm/txx9/tx4938.h
index 6ca767ee6467ca88..765f7d6a44d36ee6 100644
--- a/arch/mips/include/asm/txx9/tx4938.h
+++ b/arch/mips/include/asm/txx9/tx4938.h
@@ -281,7 +281,6 @@ void tx4938_wdt_init(void);
void tx4938_setup(void);
void tx4938_time_init(unsigned int tmrnr);
void tx4938_sio_init(unsigned int sclk, unsigned int cts_mask);
-void tx4938_spi_init(int busid);
void tx4938_ethaddr_init(unsigned char *addr0, unsigned char *addr1);
int tx4938_report_pciclk(void);
void tx4938_report_pci1clk(void);
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index 6c5025806914f989..97102d3327d22828 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -341,23 +341,6 @@ void txx9_wdt_now(unsigned long base)
&tmrptr->tcr);
}
-/* SPI support */
-void __init txx9_spi_init(int busid, unsigned long base, int irq)
-{
- struct resource res[] = {
- {
- .start = base,
- .end = base + 0x20 - 1,
- .flags = IORESOURCE_MEM,
- }, {
- .start = irq,
- .flags = IORESOURCE_IRQ,
- },
- };
- platform_device_register_simple("spi_txx9", busid,
- res, ARRAY_SIZE(res));
-}
-
void __init txx9_ethaddr_init(unsigned int id, unsigned char *ethaddr)
{
struct platform_device *pdev =
diff --git a/arch/mips/txx9/generic/setup_tx4938.c b/arch/mips/txx9/generic/setup_tx4938.c
index ba646548c5f694bd..bfd6540f8f6a406b 100644
--- a/arch/mips/txx9/generic/setup_tx4938.c
+++ b/arch/mips/txx9/generic/setup_tx4938.c
@@ -301,12 +301,6 @@ void __init tx4938_sio_init(unsigned int sclk, unsigned int cts_mask)
}
}
-void __init tx4938_spi_init(int busid)
-{
- txx9_spi_init(busid, TX4938_SPI_REG & 0xfffffffffULL,
- TXX9_IRQ_BASE + TX4938_IR_SPI);
-}
-
void __init tx4938_ethaddr_init(unsigned char *addr0, unsigned char *addr1)
{
u64 pcfg = __raw_readq(&tx4938_ccfgptr->pcfg);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/9] MIPS: TXX9: Legacy GPIO interfaces cleanup
From: Geert Uytterhoeven @ 2026-07-01 10:11 UTC (permalink / raw)
To: Thomas Bogendoerfer, Linus Walleij, Bartosz Golaszewski,
Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel, Geert Uytterhoeven
Hi all,
This patch series gets rid of legacy GPIO interface usage on the MIPS
RBTX4927 development board, preceded and followed by some cleanups.
No blinky LEDs were harmed during the production of this series.
Changes compared to v1[1]:
- Add Reviewed-by,
- Return early on platform_device_add() failure.
Thanks for your comments!
[1] "[PATCH 0/9] MIPS: TXX9: Legacy GPIO interfaces cleanup"
https://lore.kernel.org/cover.1782389357.git.geert@linux-m68k.org
Geert Uytterhoeven (9):
MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init()
MIPS: TXX9: Remove txx9_7segled_*() forward declarations
MIPS: TXX9: rbtx4927: Use GPIO lookup table for SIO DTR
MIPS: TXX9: rbtx4927: Use GPIO lookup table for TXx9 LEDs
MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3
MIPS: TXX9: Use GPIO lookup table for iocled LEDs
MIPS: TXX9: Drop GPIOLIB_LEGACY select
MIPS: TXX9: Convert gpio_txx9 to dynamic GPIO base allocation
MIPS: TXX9: Clean up txx9_iocled_init()
arch/mips/include/asm/txx9/generic.h | 9 +-----
arch/mips/include/asm/txx9/tx4938.h | 1 -
arch/mips/include/asm/txx9pio.h | 3 +-
arch/mips/kernel/gpio_txx9.c | 5 ++-
arch/mips/txx9/Kconfig | 1 -
arch/mips/txx9/generic/setup.c | 45 ++++++++++-----------------
arch/mips/txx9/generic/setup_tx4938.c | 6 ----
arch/mips/txx9/rbtx4927/setup.c | 41 ++++++++++++++++++------
8 files changed, 53 insertions(+), 58 deletions(-)
--
2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-07-01 10:01 UTC (permalink / raw)
To: Michael Walle
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <DJN3PDTPJ3L6.24P71OQFB6C98@kernel.org>
On Wed, Jul 1, 2026 at 11:44 AM Michael Walle <mwalle@kernel.org> wrote:
> On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> > On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
> >
> >> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> >> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> >> >>> map() function.
> >>
> >> Why is gpiochip_irq_reqres() called in the first place? Isn't that
> >> only called if the irq handling is set up via gc->irq.chip and not
> >> via gpiochip_irqchip_add_domain() like in gpio-regmap?
> >
> > Not really, the gpiochip_irq_reqres() is called to mark that a
> > GPIO line is used for IRQ, so the gpiolib cannot turn this
> > GPIO into an output line, gpiod_direction_out() will fail
> > on lines used for IRQ. So it's a failsafe.
> >
> > You can live without it of course, but then you don't get
> > this failsafe.
>
> Thanks for the explanation! So did I make a mistake years ago by
> adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
> ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
>
> As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
> to be a gpio_chip, which isn't the case (in general) for an
> externally allocated domain, is it?
So the whole issue comes from the fact that the IRQ chip is not marked
as immutable. For immutable IRQ chips (which all GPIO provides should
have) there is no such issue to begin with, id est there is no
gpiochip_irq_reqres() callback assigned (and respective _relres).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map
From: Andy Shevchenko @ 2026-07-01 9:45 UTC (permalink / raw)
To: Miao Wang
Cc: Bartosz Golaszewski, Miao Wang via B4 Relay, Huacai Chen,
Jianmin Lv, WANG Xuerui, Jiaxun Yang, linux-gpio, Yinbo Zhu,
Linus Walleij, Hongchen Zhang, Liu Peibao, Juxin Gao,
Mika Westerberg
In-Reply-To: <AA7111AC-196F-41F7-A47B-E5118F7D26F2@gmail.com>
On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
> > 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> >>> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> >>>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >>>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >>>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
...
> >>>>>>> This patch adds back the support for gsi_idx_map, which is used in the
> >>>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>>>>>> the index of the interrupt number in the declared interrupt resources.
> >>>>>>>
> >>>>>>> This property was removed in Loongson CPU Universal Specification for
> >>>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>>>>>> 2023, but still in use in firmwares released this year. A sample of
> >>>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> >>>>>
> >>>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
> >>>>> developers before adding non-standard and wrongly named properties, please?
> >>>>
> >>>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> >>>> that the removal might be because the maintainers suggestion against introducing
> >>>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> >>>
> >>> But what is the outcome of not using that mapping. Do you have something wrong
> >>> or not working?
> >>
> >> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> >> number of given interrupts in _CRS does not equal to ngpios. In my example,
> >> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> >> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> >> clarify, the entry is taken from the firmware I am currently using, and the
> >> firmware is released on February this year.
> >
> > Right, so with the given example everything can be done without using the (now)
> > unspecified property. Do you have more examples of DSDT of these platforms?
>
> Sorry, I only possess limited number of loongarch devices.
Yeah, we definitely need some input from Loongson people.
> >>>>>>> Device (GPO1) {
> >>>>>>> Name (_HID, "LOON000F")
> >>>>>>> Name (_CRS, ResourceTemplate () {
> >>>>>>> QWordMemory ( // Omitted, not related
> >>>>>>> )
> >>>>>>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>>>>>> 0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>>>>>> 0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>>>>>> }
> >>>>>>> Name (_DSD, Package (0x02) {
> >>>>>>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>>>>>> Package (0x03) {
> >>>>>>> Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> >>>>>
> >>>>> Yes, it's non-standard property. It's a broken one in terms of the style.
> >>>>> See DT binding documentation.
> >>>>
> >>>> To clarify, I agree that this property should be redundant and ignored by
> >>>> the driver and global gpio numbers should be assigned dynamically by the
> >>>> kernel.
> >>>>
> >>>>>>> Package (0x02) { "ngpios", 0x20 }
> >>>>>>> Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>> }}
> >>>>>>> }
> >>>>>>> }
> >>>>>>> }
> >>>>>>>
> >>>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
> >>>>>
> >>>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
> >>>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> >>>>> other examples with different mapping?
> >>>>
> >>>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> >>>> actually embedded into the CPU chip and the interrupt lines are hard wired so
> >>>> that all the gpio lines of the gpio controller share in total 8 irqs such that
> >>>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> >>>> are fixed. I have no idea about the behavior of other kinds of controllers, which
> >>>> should be answered by Loongson personales.
> >>>
> >>> OK.
> >>>
> >>>> So far, there are known to be 2 styles of DSDT entries. One is defined by
> >>>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> >>>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> >>>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> >>>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> >>>> number listed in the ResourceTemplate. The former should now be compatible with
> >>>> the current implementation of the driver in the kernel, while the later not. I
> >>>> believe that although being abandoned by the spec, the later should also be
> >>>> considered and supported by the driver, since it is used by the firmwares in the
> >>>> wild.
> >>>
> >>> This is clear. What's unclear is the necessity of adding this mapping. Is that
> >>> mapping shuffled in an arbitrary way?
> >>
> >> According to the partial information I currently have, I don't think the mapping
> >> would shuffle arbitrarily.
> >>
> >>> Second question, why one can't update firmware to fix this to follow the
> >>> specification? From above DSDT I do *not* see the need in this mapping.
> >>> Everything can be simply deducted from the number of Interrupt() resources
> >>> and ngpios at run-time without touching the property.
> >>
> >> I have no idea why on the firmware side the spec was not followed for three
> >> years. When ignoring this mapping, there would be a problem if the number
> >> of given Interrupt() resources is less than ngpios. When this mapping is
> >> referred, there will be a ground truth for which irq number a gpio line
> >> belongs to. To be specific, suppose the number of Interrupt() resources
> >> is m and ngpios is n. In the current spec, where m equals to n, such ground
> >> truth also exists. However, when m is less than n and this mapping is
> >> ignored, the mapping will become ambiguous. Should the irq number be i%m
> >> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
> >
> > My suggestion is to restore the logic in the code for the above-like mappings.
> >
> > You count Interrupt() resources, you have 'ngpios' property. Now, when you
> > do need to map an IRQ line, you simply do it in a way of
> >
> > IRQ line % amount of Interrupt() resources
> >
> > It will give you the same without reading that property. I believe that's why
> > the specification removed the need, because in this case it's not needed and
> > may be easily derived from the existing information.
>
> Yes, but actually from the hardware specs, the mapping between gpio lines and
> the irq lines is actually taking modulo of 8. If the given number of Interrupt()
> is 8, this will be right. What if the given number of Interrupt() is not 8, say
> 9 or anything else? I think to be fail-safe, when the amount of Interrupt()
> resources is less than ngpios, we should only allow 8 Interrupt()'s given.
But if amount is 6 or 5? I think it should be considered as a FW bug.
I would go KISS and probably just use modulo 8 unconditionally and
if something happens, we will get a report and hence will act accordingly.
> > Can somebody from Loongson shed a light on what's going on here?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [linusw-pinctrl:for-next] BUILD SUCCESS a1636f548c497cedf001238c879eae9e271b5809
From: kernel test robot @ 2026-07-01 9:14 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git for-next
branch HEAD: a1636f548c497cedf001238c879eae9e271b5809 gpio: tb10x: remove unnecessary braces
elapsed time: 750m
configs tested: 226
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260701 gcc-12.5.0
arc randconfig-002-20260701 gcc-12.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260701 gcc-12.5.0
arm randconfig-002-20260701 gcc-12.5.0
arm randconfig-003-20260701 gcc-12.5.0
arm randconfig-004-20260701 gcc-12.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260701 gcc-12.5.0
arm64 randconfig-002-20260701 gcc-12.5.0
arm64 randconfig-003-20260701 gcc-12.5.0
arm64 randconfig-004-20260701 gcc-12.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260701 gcc-12.5.0
csky randconfig-002-20260701 gcc-12.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260701 clang-23
hexagon randconfig-001-20260701 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260701 clang-23
hexagon randconfig-002-20260701 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260701 clang-22
i386 buildonly-randconfig-002-20260701 clang-22
i386 buildonly-randconfig-003-20260701 clang-22
i386 buildonly-randconfig-004-20260701 clang-22
i386 buildonly-randconfig-005-20260701 clang-22
i386 buildonly-randconfig-006-20260701 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260701 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260701 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260701 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260701 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260701 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260701 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260701 clang-22
i386 randconfig-011 gcc-14
i386 randconfig-011-20260701 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260701 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260701 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260701 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260701 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260701 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260701 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch loongson32_defconfig clang-18
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260701 clang-23
loongarch randconfig-001-20260701 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260701 clang-23
loongarch randconfig-002-20260701 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips db1xxx_defconfig clang-23
mips gpr_defconfig clang-23
mips rb532_defconfig clang-23
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260701 clang-23
nios2 randconfig-001-20260701 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260701 clang-23
nios2 randconfig-002-20260701 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260701 clang-17
parisc randconfig-002-20260701 clang-17
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc asp8347_defconfig clang-23
powerpc randconfig-001-20260701 clang-17
powerpc randconfig-002-20260701 clang-17
powerpc64 randconfig-001-20260701 clang-17
powerpc64 randconfig-002-20260701 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260701 clang-23
riscv randconfig-002 clang-23
riscv randconfig-002-20260701 clang-23
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260701 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260701 clang-23
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 clang-23
sh randconfig-001-20260701 clang-23
sh randconfig-002 clang-23
sh randconfig-002-20260701 clang-23
sh se7206_defconfig gcc-16.1.0
sh secureedge5410_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-13.4.0
sparc randconfig-001-20260701 gcc-13.4.0
sparc randconfig-002 gcc-13.4.0
sparc randconfig-002-20260701 gcc-13.4.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-13.4.0
sparc64 randconfig-001-20260701 gcc-13.4.0
sparc64 randconfig-002 gcc-13.4.0
sparc64 randconfig-002-20260701 gcc-13.4.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-13.4.0
um randconfig-001-20260701 gcc-13.4.0
um randconfig-002 gcc-13.4.0
um randconfig-002-20260701 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260701 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260701 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260701 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260701 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260701 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260701 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260701 gcc-14
x86_64 randconfig-002-20260701 gcc-14
x86_64 randconfig-003-20260701 gcc-14
x86_64 randconfig-004-20260701 gcc-14
x86_64 randconfig-005-20260701 gcc-14
x86_64 randconfig-006-20260701 gcc-14
x86_64 randconfig-011-20260701 gcc-14
x86_64 randconfig-012-20260701 gcc-14
x86_64 randconfig-013-20260701 gcc-14
x86_64 randconfig-014-20260701 gcc-14
x86_64 randconfig-015-20260701 gcc-14
x86_64 randconfig-016-20260701 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260701 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260701 gcc-14
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260701 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260701 gcc-14
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260701 gcc-14
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260701 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001 gcc-13.4.0
xtensa randconfig-001-20260701 gcc-13.4.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260701 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [linusw-pinctrl:b4/tb10x] BUILD SUCCESS 430af65f7d5b8271b53955da90198ba63817e2cd
From: kernel test robot @ 2026-07-01 9:18 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git b4/tb10x
branch HEAD: 430af65f7d5b8271b53955da90198ba63817e2cd pinctrl: tb10x: Mark base as __iomem
elapsed time: 754m
configs tested: 229
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260701 gcc-12.5.0
arc randconfig-002-20260701 gcc-12.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260701 gcc-12.5.0
arm randconfig-002-20260701 gcc-12.5.0
arm randconfig-003-20260701 gcc-12.5.0
arm randconfig-004-20260701 gcc-12.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260701 gcc-12.5.0
arm64 randconfig-002-20260701 gcc-12.5.0
arm64 randconfig-003-20260701 gcc-12.5.0
arm64 randconfig-004-20260701 gcc-12.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260701 gcc-12.5.0
csky randconfig-002-20260701 gcc-12.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260701 clang-23
hexagon randconfig-001-20260701 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260701 clang-23
hexagon randconfig-002-20260701 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260701 clang-22
i386 buildonly-randconfig-002-20260701 clang-22
i386 buildonly-randconfig-003-20260701 clang-22
i386 buildonly-randconfig-004-20260701 clang-22
i386 buildonly-randconfig-005-20260701 clang-22
i386 buildonly-randconfig-006-20260701 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260701 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260701 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260701 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260701 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260701 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260701 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260701 clang-22
i386 randconfig-011 gcc-14
i386 randconfig-011-20260701 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260701 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260701 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260701 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260701 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260701 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260701 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch loongson32_defconfig clang-18
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260701 clang-23
loongarch randconfig-001-20260701 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260701 clang-23
loongarch randconfig-002-20260701 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips db1xxx_defconfig clang-23
mips gpr_defconfig clang-23
mips rb532_defconfig clang-23
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260701 clang-23
nios2 randconfig-001-20260701 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260701 clang-23
nios2 randconfig-002-20260701 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260701 clang-17
parisc randconfig-002-20260701 clang-17
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc asp8347_defconfig clang-23
powerpc randconfig-001-20260701 clang-17
powerpc randconfig-002-20260701 clang-17
powerpc64 randconfig-001-20260701 clang-17
powerpc64 randconfig-002-20260701 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260701 clang-23
riscv randconfig-002 clang-23
riscv randconfig-002-20260701 clang-23
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260701 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260701 clang-23
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 clang-23
sh randconfig-001-20260701 clang-23
sh randconfig-002 clang-23
sh randconfig-002-20260701 clang-23
sh se7206_defconfig gcc-16.1.0
sh secureedge5410_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-13.4.0
sparc randconfig-001-20260701 gcc-13.4.0
sparc randconfig-002 gcc-13.4.0
sparc randconfig-002-20260701 gcc-13.4.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-13.4.0
sparc64 randconfig-001-20260701 gcc-13.4.0
sparc64 randconfig-002 gcc-13.4.0
sparc64 randconfig-002-20260701 gcc-13.4.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-13.4.0
um randconfig-001-20260701 gcc-13.4.0
um randconfig-002 gcc-13.4.0
um randconfig-002-20260701 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260701 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260701 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260701 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260701 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260701 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260701 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260701 gcc-14
x86_64 randconfig-002-20260701 gcc-14
x86_64 randconfig-003-20260701 gcc-14
x86_64 randconfig-004-20260701 gcc-14
x86_64 randconfig-005-20260701 gcc-14
x86_64 randconfig-006-20260701 gcc-14
x86_64 randconfig-011-20260701 gcc-14
x86_64 randconfig-012-20260701 gcc-14
x86_64 randconfig-013-20260701 gcc-14
x86_64 randconfig-014-20260701 gcc-14
x86_64 randconfig-015-20260701 gcc-14
x86_64 randconfig-016-20260701 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260701 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260701 gcc-14
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260701 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260701 gcc-14
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260701 gcc-14
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260701 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001 gcc-13.4.0
xtensa randconfig-001-20260701 gcc-13.4.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260701 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map
From: Miao Wang @ 2026-07-01 8:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Miao Wang via B4 Relay, Huacai Chen,
Jianmin Lv, WANG Xuerui, Jiaxun Yang, linux-gpio, Yinbo Zhu,
Linus Walleij, Hongchen Zhang, Liu Peibao, Juxin Gao,
Mika Westerberg
In-Reply-To: <akTRyQqXuSU6pl71@ashevche-desk.local>
Hi,
> 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>
> On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
>>> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
>>>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>>>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>>>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
>
> ...
>
>>>>>>> This patch adds back the support for gsi_idx_map, which is used in the
>>>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>>>>>> the index of the interrupt number in the declared interrupt resources.
>>>>>>>
>>>>>>> This property was removed in Loongson CPU Universal Specification for
>>>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>>>>>> 2023, but still in use in firmwares released this year. A sample of
>>>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
>>>>>
>>>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
>>>>> developers before adding non-standard and wrongly named properties, please?
>>>>
>>>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
>>>> that the removal might be because the maintainers suggestion against introducing
>>>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
>>>
>>> But what is the outcome of not using that mapping. Do you have something wrong
>>> or not working?
>>
>> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
>> number of given interrupts in _CRS does not equal to ngpios. In my example,
>> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
>> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
>> clarify, the entry is taken from the firmware I am currently using, and the
>> firmware is released on February this year.
>
> Right, so with the given example everything can be done without using the (now)
> unspecified property. Do you have more examples of DSDT of these platforms?
Sorry, I only possess limited number of loongarch devices.
>>>>>>> Device (GPO1) {
>>>>>>> Name (_HID, "LOON000F")
>>>>>>> Name (_CRS, ResourceTemplate () {
>>>>>>> QWordMemory ( // Omitted, not related
>>>>>>> )
>>>>>>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>>>>> 0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>>>>> 0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>>>>> }
>>>>>>> Name (_DSD, Package (0x02) {
>>>>>>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>>>>> Package (0x03) {
>>>>>>> Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>>>>>
>>>>> Yes, it's non-standard property. It's a broken one in terms of the style.
>>>>> See DT binding documentation.
>>>>
>>>> To clarify, I agree that this property should be redundant and ignored by
>>>> the driver and global gpio numbers should be assigned dynamically by the
>>>> kernel.
>>>>
>>>>>>> Package (0x02) { "ngpios", 0x20 }
>>>>>>> Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>> }}
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
>>>>>
>>>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
>>>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
>>>>> other examples with different mapping?
>>>>
>>>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
>>>> actually embedded into the CPU chip and the interrupt lines are hard wired so
>>>> that all the gpio lines of the gpio controller share in total 8 irqs such that
>>>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
>>>> are fixed. I have no idea about the behavior of other kinds of controllers, which
>>>> should be answered by Loongson personales.
>>>
>>> OK.
>>>
>>>> So far, there are known to be 2 styles of DSDT entries. One is defined by
>>>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
>>>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
>>>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
>>>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
>>>> number listed in the ResourceTemplate. The former should now be compatible with
>>>> the current implementation of the driver in the kernel, while the later not. I
>>>> believe that although being abandoned by the spec, the later should also be
>>>> considered and supported by the driver, since it is used by the firmwares in the
>>>> wild.
>>>
>>> This is clear. What's unclear is the necessity of adding this mapping. Is that
>>> mapping shuffled in an arbitrary way?
>>
>> According to the partial information I currently have, I don't think the mapping
>> would shuffle arbitrarily.
>>
>>> Second question, why one can't update firmware to fix this to follow the
>>> specification? From above DSDT I do *not* see the need in this mapping.
>>> Everything can be simply deducted from the number of Interrupt() resources
>>> and ngpios at run-time without touching the property.
>>
>> I have no idea why on the firmware side the spec was not followed for three
>> years. When ignoring this mapping, there would be a problem if the number
>> of given Interrupt() resources is less than ngpios. When this mapping is
>> referred, there will be a ground truth for which irq number a gpio line
>> belongs to. To be specific, suppose the number of Interrupt() resources
>> is m and ngpios is n. In the current spec, where m equals to n, such ground
>> truth also exists. However, when m is less than n and this mapping is
>> ignored, the mapping will become ambiguous. Should the irq number be i%m
>> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
>
> My suggestion is to restore the logic in the code for the above-like mappings.
>
> You count Interrupt() resources, you have 'ngpios' property. Now, when you
> do need to map an IRQ line, you simply do it in a way of
>
> IRQ line % amount of Interrupt() resources
>
> It will give you the same without reading that property. I believe that's why
> the specification removed the need, because in this case it's not needed and
> may be easily derived from the existing information.
Yes, but actually from the hardware specs, the mapping between gpio lines and
the irq lines is actually taking modulo of 8. If the given number of Interrupt()
is 8, this will be right. What if the given number of Interrupt() is not 8, say
9 or anything else? I think to be fail-safe, when the amount of Interrupt()
resources is less than ngpios, we should only allow 8 Interrupt()'s given.
> Can somebody from Loongson shed a light on what's going on here?
>
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-07-01 8:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Andy Shevchenko, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
wbg@kernel.org, mathieu.dubois-briand@bootlin.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <CAD++jLncD2ZjH3aedOkGNYP3FyZ=i7Pb0OcKKZKuMOPGNjM_nQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
On Fri Jun 19, 2026 at 11:08 PM CEST, Linus Walleij wrote:
> On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
>
>> >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
>> >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
>> >>> map() function.
>>
>> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>> only called if the irq handling is set up via gc->irq.chip and not
>> via gpiochip_irqchip_add_domain() like in gpio-regmap?
>
> Not really, the gpiochip_irq_reqres() is called to mark that a
> GPIO line is used for IRQ, so the gpiolib cannot turn this
> GPIO into an output line, gpiod_direction_out() will fail
> on lines used for IRQ. So it's a failsafe.
>
> You can live without it of course, but then you don't get
> this failsafe.
Thanks for the explanation! So did I make a mistake years ago by
adding the gpiochip_irqchip_add_domain(), see commit 6a45b0e2589f
("gpiolib: Introduce gpiochip_irqchip_add_domain()")
As Yu-Chun found, gpiochip_irq_reqres() expect the irq chip data
to be a gpio_chip, which isn't the case (in general) for an
externally allocated domain, is it?
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map
From: Andy Shevchenko @ 2026-07-01 8:37 UTC (permalink / raw)
To: Miao Wang
Cc: Bartosz Golaszewski, Miao Wang via B4 Relay, Huacai Chen,
Jianmin Lv, WANG Xuerui, Jiaxun Yang, linux-gpio, Yinbo Zhu,
Linus Walleij, Hongchen Zhang, Liu Peibao, Juxin Gao,
Mika Westerberg
In-Reply-To: <A12FA264-0A0B-4CB3-BBCC-51380591F0E1@gmail.com>
On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> > 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> >>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
...
> >>>>> This patch adds back the support for gsi_idx_map, which is used in the
> >>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>>>> the index of the interrupt number in the declared interrupt resources.
> >>>>>
> >>>>> This property was removed in Loongson CPU Universal Specification for
> >>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>>>> 2023, but still in use in firmwares released this year. A sample of
> >>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> >>>
> >>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
> >>> developers before adding non-standard and wrongly named properties, please?
> >>
> >> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> >> that the removal might be because the maintainers suggestion against introducing
> >> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> >
> > But what is the outcome of not using that mapping. Do you have something wrong
> > or not working?
>
> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> number of given interrupts in _CRS does not equal to ngpios. In my example,
> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> clarify, the entry is taken from the firmware I am currently using, and the
> firmware is released on February this year.
Right, so with the given example everything can be done without using the (now)
unspecified property. Do you have more examples of DSDT of these platforms?
> >>>>> Device (GPO1) {
> >>>>> Name (_HID, "LOON000F")
> >>>>> Name (_CRS, ResourceTemplate () {
> >>>>> QWordMemory ( // Omitted, not related
> >>>>> )
> >>>>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>>>> 0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>>>> 0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>>>> }
> >>>>> Name (_DSD, Package (0x02) {
> >>>>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>>>> Package (0x03) {
> >>>>> Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> >>>
> >>> Yes, it's non-standard property. It's a broken one in terms of the style.
> >>> See DT binding documentation.
> >>
> >> To clarify, I agree that this property should be redundant and ignored by
> >> the driver and global gpio numbers should be assigned dynamically by the
> >> kernel.
> >>
> >>>>> Package (0x02) { "ngpios", 0x20 }
> >>>>> Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>>>> }}
> >>>>> }
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>>>> for the line numbers largers than 7, it will fail with -ENXIO.
> >>>
> >>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
> >>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> >>> other examples with different mapping?
> >>
> >> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> >> actually embedded into the CPU chip and the interrupt lines are hard wired so
> >> that all the gpio lines of the gpio controller share in total 8 irqs such that
> >> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> >> are fixed. I have no idea about the behavior of other kinds of controllers, which
> >> should be answered by Loongson personales.
> >
> > OK.
> >
> >> So far, there are known to be 2 styles of DSDT entries. One is defined by
> >> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> >> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> >> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> >> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> >> number listed in the ResourceTemplate. The former should now be compatible with
> >> the current implementation of the driver in the kernel, while the later not. I
> >> believe that although being abandoned by the spec, the later should also be
> >> considered and supported by the driver, since it is used by the firmwares in the
> >> wild.
> >
> > This is clear. What's unclear is the necessity of adding this mapping. Is that
> > mapping shuffled in an arbitrary way?
>
> According to the partial information I currently have, I don't think the mapping
> would shuffle arbitrarily.
>
> > Second question, why one can't update firmware to fix this to follow the
> > specification? From above DSDT I do *not* see the need in this mapping.
> > Everything can be simply deducted from the number of Interrupt() resources
> > and ngpios at run-time without touching the property.
>
> I have no idea why on the firmware side the spec was not followed for three
> years. When ignoring this mapping, there would be a problem if the number
> of given Interrupt() resources is less than ngpios. When this mapping is
> referred, there will be a ground truth for which irq number a gpio line
> belongs to. To be specific, suppose the number of Interrupt() resources
> is m and ngpios is n. In the current spec, where m equals to n, such ground
> truth also exists. However, when m is less than n and this mapping is
> ignored, the mapping will become ambiguous. Should the irq number be i%m
> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
My suggestion is to restore the logic in the code for the above-like mappings.
You count Interrupt() resources, you have 'ngpios' property. Now, when you
do need to map an IRQ line, you simply do it in a way of
IRQ line % amount of Interrupt() resources
It will give you the same without reading that property. I believe that's why
the specification removed the need, because in this case it's not needed and
may be easily derived from the existing information.
Can somebody from Loongson shed a light on what's going on here?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Jürgen Groß @ 2026-07-01 8:33 UTC (permalink / raw)
To: Sean Christopherson, Ingo Molnar
Cc: Arnd Bergmann, linux-kernel, linux-pm, linux-edac@vger.kernel.org,
x86, linux-acpi, kvm, linux-coco, linux-pci, virtualization,
linux-ide, dri-devel, linux-fbdev, linux-crypto,
open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <akQR9YMtMHReJTfB@google.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1484 bytes --]
On 30.06.26 20:59, Sean Christopherson wrote:
> On Mon, Jun 29, 2026, Ingo Molnar wrote:
>> * Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>>>>> Note that most patches of this series are independent from each other.
>>>>>> Only the patches removing a specific interface (patches 7, 15, 26 and
>>>>>> 30) and the last two patches of the series depend on all previous
>>>>>> patches.
>>>>>
>>>>> It looks like you are touching most files twice or more here, to
>>>>> first convert from rdmsr to rdmsrq and then to change the
>>>>> two-argument rdmsrq() macro to a single-argument inline. If you
>>>>> introduce the inline version of rdmsrq() first, you should be
>>>>> able to skip the second step (patch 31) as they could be able
>>>>> to coexist.
>>>>
>>>> I've discussed how to structure the series with Ingo Molnar before [1]. The
>>>> current approach was his preference.
>>>
>>> Ok.
>>
>> Note that the individual patches are IMO significantly easier to review
>> through the actual 32-bit => 64-bit variable assignment changes done
>> in isolation (which sometimes include minor cleanups), while
>> the Coccinelle semantic patch:
>>
>> { a(b,c) => c = a(b) }
>>
>> which changes both the function signature and the order of terms as
>> well, is just a single add-on treewide patch.
>
> Is the plan for subsystem maintainers to pick up the relevant patches, and then
> do the treewide change one release cycle later?
Yes, please.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH 24/32] drivers/gpio: Stop using 32-bit MSR interfaces
From: Juergen Gross @ 2026-07-01 8:32 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-kernel, linux-gpio, Bartosz Golaszewski
In-Reply-To: <CAD++jL=D81BED5g36JRZ-+-rYwszsMmUhi1vLeby0KZVjbr00Q@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 492 bytes --]
On 01.07.26 10:13, Linus Walleij wrote:
> Hi Jürgen,
>
> On Mon, Jun 29, 2026 at 8:07 AM Juergen Gross <jgross@suse.com> wrote:
>
>> The 32-bit MSR interfaces rdmsr() and wrmsr() are planned to be
>> removed. Use the related 64-bit variants instead.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> Is this something the subsystem maintainera are supposed to apply
> directly on a per-subsystem basis? I was under that impression.
Yes, please do so.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-07-01 8:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, open list:GPIO SUBSYSTEM, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc @ vger . kernel . org,
linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <CAMuHMdWhv8i6tkmOJU_ee9LAV7mMcQHe9FXgqTHCjGiEMWvn8Q@mail.gmail.com>
On Tue, Jun 30, 2026, at 18:01, Geert Uytterhoeven wrote:
> On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
>> > Same results for instantiation using sysfs or configfs[1], although
>> > the latter does have optional support for specifying the name.
>>
>> I wonder how many of the other instances have the same problem
>> then. Would it be appropriate for gpiochip_fwd_desc_add() to set
>> a name itself to address this one?
>
> I don't think it would be appropriate for the GPIO aggregator to set
> that name. What we want to print here (for debugging) is the physical
> GPIO that an aggregator's GPIO is mapped to, not some consumer or line
> name (which is not guaranteed to be unique).
Ok.
> E.g. "<chip-name>.<offset>" would be fine. As gpiod_name() can only
> return a fixed string or an existing string, it can't return such a
> formatted string, though. And consumers don't have access to chip info?
The gpiod_hwgpio() function is exported to consumers, so they can
already print that instead of desc_to_gpio() if the local number
is sufficient. If we really care about the <chip-name> portion for
any of the debug prints, we could export another function that
returns maybe gpiod_to_chip(gpiod)->label or
dev_name(&gpiod_to_gpio_device(gpiod)->dev), which are both
constant strings we can print.
It looks like we can also replace most of the remaining callers
of desc_to_gpio() with gpiod_hwgpio().
Arnd
^ permalink raw reply
* Re: [PATCH] gpio: swnode: remove deprecated lookup mechanism
From: Linus Walleij @ 2026-07-01 8:17 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Dmitry Torokhov, Andy Shevchenko, linux-gpio,
linux-kernel
In-Reply-To: <20260629-gpio-swnode-drop-label-matching-v1-1-db1af36cf883@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 12:55 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> GPIO software node lookup should rely exclusively on matching the
> addresses of the referenced firmware nodes. Commit e5d527be7e69 ("gpio:
> swnode: don't use the swnode's name as the key for GPIO lookup") tried to
> enforce this but had to be reverted: it broke existing users who abused
> the software node mechanism by creating "dummy" software nodes named
> after the device they want to get GPIOs from, without ever attaching them
> to the actual GPIO devices. Those users relied on GPIOLIB matching the
> label of the GPIO controller against the name of the software node rather
> than on a real firmware node link.
>
> All such users have now been coverted to using attached software nodes
> via the fwnode address lookup path and the kernel documentation has been
> updated to recommend it as the correct approach. This allows us to remove
> the old behavior.
>
> This will allow us to leverage the upcoming support for fw_devlink for
> software nodes in GPIO core.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Nice, I like it.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 24/32] drivers/gpio: Stop using 32-bit MSR interfaces
From: Linus Walleij @ 2026-07-01 8:13 UTC (permalink / raw)
To: Juergen Gross; +Cc: linux-kernel, linux-gpio, Bartosz Golaszewski
In-Reply-To: <20260629060526.3638272-25-jgross@suse.com>
Hi Jürgen,
On Mon, Jun 29, 2026 at 8:07 AM Juergen Gross <jgross@suse.com> wrote:
> The 32-bit MSR interfaces rdmsr() and wrmsr() are planned to be
> removed. Use the related 64-bit variants instead.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Is this something the subsystem maintainera are supposed to apply
directly on a per-subsystem basis? I was under that impression.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox