* Re: (subset) [PATCH] mfd: si476x: Modernize GPIO handling
From: Lee Jones @ 2026-06-17 16:15 UTC (permalink / raw)
To: Andrey Smirnov, Lee Jones, Bartosz Golaszewski, Linus Walleij
Cc: linux-kernel, linux-gpio
In-Reply-To: <20260327-mfd-si476x-v1-1-93298ca35d6d@kernel.org>
On Fri, 27 Mar 2026 09:37:26 +0100, Linus Walleij wrote:
> The SI476X driver depends on the legacy GPIO API. As it only
> really use a single GPIO for reset, and this can be easily converted
> to use a GPIO descriptor, modernize the driver.
>
> The "reset" GPIO is obtained from a device property, such as a
> device tree ("reset-gpios", which is standard, but this hardware has
> no DT bindings as of now) or a software node for static platforms.
>
> [...]
Applied, thanks!
[1/1] mfd: si476x: Modernize GPIO handling
commit: f3f0acd3768dfe71aa6b2618dbeaff69f25923c4
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 1/2] gpio: sch: use raw_spinlock_t in the irq startup path
From: Andy Shevchenko @ 2026-06-17 15:57 UTC (permalink / raw)
To: Runyu Xiao
Cc: Linus Walleij, Bartosz Golaszewski, Orson Zhai, Baolin Wang,
Chunyan Zhang, Andy Shevchenko, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Jan Kiszka, linux-gpio,
linux-rt-devel, linux-kernel, jianhao.xu, stable
In-Reply-To: <20260617154035.1199948-2-runyu.xiao@seu.edu.cn>
On Wed, Jun 17, 2026 at 11:40:34PM +0800, Runyu Xiao wrote:
> sch_irq_unmask() enables the GPIO IRQ and then updates the controller
> state through sch_irq_mask_unmask(), which takes sch->lock with
> spin_lock_irqsave(). The callback can be reached from irq_startup()
> while setting up a requested IRQ. That path is not sleepable, but on
> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
>
> This issue was found by our static analysis tool and then manually
> reviewed against the current tree.
>
> The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and
> used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported:
>
> BUG: sleeping function called from invalid context
> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
> sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
> sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]
>
> Convert the SCH controller lock to raw_spinlock_t. The same lock is
> also used by the GPIO direction and value callbacks, but those critical
> sections only update MMIO-backed GPIO registers and do not contain
> sleepable operations. Keeping this register lock non-sleeping is
> therefore appropriate for the irqchip callbacks and does not change the
> GPIO-side locking contract.
Okay, no objection.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Bart, you can take it to your branch directly in case it's not too late
for getting into v7.2-rc1, otherwise I can take via my branch and then PR
somewhere near -rc2.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/2] gpio: eic-sprd: use raw_spinlock_t in the irq startup path
From: Runyu Xiao @ 2026-06-17 15:40 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Orson Zhai, Baolin Wang, Chunyan Zhang, Andy Shevchenko,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Jan Kiszka, linux-gpio, linux-rt-devel, linux-kernel, jianhao.xu,
runyu.xiao, stable
In-Reply-To: <20260617154035.1199948-1-runyu.xiao@seu.edu.cn>
sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller
state through sprd_eic_update(), which takes sprd_eic->lock with
spin_lock_irqsave(). The callback can be reached from irq_startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and
used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep
reported:
BUG: sleeping function called from invalid context
hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]
sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The
locked section only serializes MMIO register updates and does not contain
sleepable operations, so keeping it non-sleeping is appropriate for the
irqchip callbacks.
Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
drivers/gpio/gpio-eic-sprd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c
index 50fafeda8d7e..3b7ebcf12fe7 100644
--- a/drivers/gpio/gpio-eic-sprd.c
+++ b/drivers/gpio/gpio-eic-sprd.c
@@ -95,7 +95,7 @@ struct sprd_eic {
struct notifier_block irq_nb;
void __iomem *base[SPRD_EIC_MAX_BANK];
enum sprd_eic_type type;
- spinlock_t lock;
+ raw_spinlock_t lock;
int irq;
};
@@ -149,7 +149,7 @@ static void sprd_eic_update(struct gpio_chip *chip, unsigned int offset,
unsigned long flags;
u32 tmp;
- spin_lock_irqsave(&sprd_eic->lock, flags);
+ raw_spin_lock_irqsave(&sprd_eic->lock, flags);
tmp = readl_relaxed(base + reg);
if (val)
@@ -158,7 +158,7 @@ static void sprd_eic_update(struct gpio_chip *chip, unsigned int offset,
tmp &= ~BIT(SPRD_EIC_BIT(offset));
writel_relaxed(tmp, base + reg);
- spin_unlock_irqrestore(&sprd_eic->lock, flags);
+ raw_spin_unlock_irqrestore(&sprd_eic->lock, flags);
}
static int sprd_eic_read(struct gpio_chip *chip, unsigned int offset, u16 reg)
@@ -628,7 +628,7 @@ static int sprd_eic_probe(struct platform_device *pdev)
if (!sprd_eic)
return -ENOMEM;
- spin_lock_init(&sprd_eic->lock);
+ raw_spin_lock_init(&sprd_eic->lock);
sprd_eic->type = pdata->type;
sprd_eic->irq = platform_get_irq(pdev, 0);
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] gpio: sch: use raw_spinlock_t in the irq startup path
From: Runyu Xiao @ 2026-06-17 15:40 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Orson Zhai, Baolin Wang, Chunyan Zhang, Andy Shevchenko,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Jan Kiszka, linux-gpio, linux-rt-devel, linux-kernel, jianhao.xu,
runyu.xiao, stable
In-Reply-To: <20260617154035.1199948-1-runyu.xiao@seu.edu.cn>
sch_irq_unmask() enables the GPIO IRQ and then updates the controller
state through sch_irq_mask_unmask(), which takes sch->lock with
spin_lock_irqsave(). The callback can be reached from irq_startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and
used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported:
BUG: sleeping function called from invalid context
hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convert the SCH controller lock to raw_spinlock_t. The same lock is
also used by the GPIO direction and value callbacks, but those critical
sections only update MMIO-backed GPIO registers and do not contain
sleepable operations. Keeping this register lock non-sleeping is
therefore appropriate for the irqchip callbacks and does not change the
GPIO-side locking contract.
Fixes: 7a81638485c1 ("gpio: sch: Add edge event support")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
drivers/gpio/gpio-sch.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 966d16a6d515..5e361742a11a 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -39,7 +39,7 @@
struct sch_gpio {
struct gpio_chip chip;
void __iomem *regs;
- spinlock_t lock;
+ raw_spinlock_t lock;
unsigned short resume_base;
/* GPE handling */
@@ -104,9 +104,9 @@ static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned int gpio_num)
struct sch_gpio *sch = gpiochip_get_data(gc);
unsigned long flags;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GIO, 1);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
return 0;
}
@@ -122,9 +122,9 @@ static int sch_gpio_set(struct gpio_chip *gc, unsigned int gpio_num, int val)
struct sch_gpio *sch = gpiochip_get_data(gc);
unsigned long flags;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GLV, val);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
return 0;
}
@@ -135,9 +135,9 @@ static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned int gpio_num,
struct sch_gpio *sch = gpiochip_get_data(gc);
unsigned long flags;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GIO, 0);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
/*
* according to the datasheet, writing to the level register has no
@@ -196,14 +196,14 @@ static int sch_irq_type(struct irq_data *d, unsigned int type)
return -EINVAL;
}
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GTPE, rising);
sch_gpio_reg_set(sch, gpio_num, GTNE, falling);
irq_set_handler_locked(d, handle_edge_irq);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
return 0;
}
@@ -215,9 +215,9 @@ static void sch_irq_ack(struct irq_data *d)
irq_hw_number_t gpio_num = irqd_to_hwirq(d);
unsigned long flags;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GTS, 1);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
}
static void sch_irq_mask_unmask(struct gpio_chip *gc, irq_hw_number_t gpio_num, int val)
@@ -225,9 +225,9 @@ static void sch_irq_mask_unmask(struct gpio_chip *gc, irq_hw_number_t gpio_num,
struct sch_gpio *sch = gpiochip_get_data(gc);
unsigned long flags;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
sch_gpio_reg_set(sch, gpio_num, GGPE, val);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
}
static void sch_irq_mask(struct irq_data *d)
@@ -268,12 +268,12 @@ static u32 sch_gpio_gpe_handler(acpi_handle gpe_device, u32 gpe, void *context)
int offset;
u32 ret;
- spin_lock_irqsave(&sch->lock, flags);
+ raw_spin_lock_irqsave(&sch->lock, flags);
core_status = ioread32(sch->regs + CORE_BANK_OFFSET + GTS);
resume_status = ioread32(sch->regs + RESUME_BANK_OFFSET + GTS);
- spin_unlock_irqrestore(&sch->lock, flags);
+ raw_spin_unlock_irqrestore(&sch->lock, flags);
pending = (resume_status << sch->resume_base) | core_status;
for_each_set_bit(offset, &pending, sch->chip.ngpio)
@@ -343,7 +343,7 @@ static int sch_gpio_probe(struct platform_device *pdev)
sch->regs = regs;
- spin_lock_init(&sch->lock);
+ raw_spin_lock_init(&sch->lock);
sch->chip = sch_gpio_chip;
sch->chip.label = dev_name(dev);
sch->chip.parent = dev;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] gpio: use raw spinlocks in irq startup paths
From: Runyu Xiao @ 2026-06-17 15:40 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Orson Zhai, Baolin Wang, Chunyan Zhang, Andy Shevchenko,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Jan Kiszka, linux-gpio, linux-rt-devel, linux-kernel, jianhao.xu,
runyu.xiao
This 2-patch series fixes two GPIO irqchip paths where IRQ startup or
unmask can update controller state under a regular spinlock. On
PREEMPT_RT, that lock can sleep while irq_startup() is running in a
non-sleepable context.
Both issues were found by our static analysis tool and then manually
reviewed against the current tree. The grounded PoCs kept the
request_threaded_irq() -> __setup_irq() -> irq_startup() carriers and
Lockdep reported "BUG: sleeping function called from invalid context" on
the corresponding driver update helpers.
Convert the affected register locks to raw_spinlock_t. The locked
sections only serialize MMIO register access and irqchip state updates,
so they should remain non-sleeping. The conversion does not move any
sleepable operation under a raw lock; it preserves the existing short
register-critical sections while making their non-sleeping requirement
explicit for PREEMPT_RT.
Runyu Xiao (2):
gpio: sch: use raw_spinlock_t in the irq startup path
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
drivers/gpio/gpio-eic-sprd.c | 8 ++++----
drivers/gpio/gpio-sch.c | 32 ++++++++++++++++----------------
2 files changed, 20 insertions(+), 20 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH libgpiod] build: gate subdirectories on the *_enabled variables
From: Bartosz Golaszewski @ 2026-06-17 13:46 UTC (permalink / raw)
To: Linus Walleij, Vincent Fazio, Kent Gibson
Cc: brgl, linux-gpio, Bartosz Golaszewski
The top-level meson.build descends into tests/ and dbus/ only when the
computed tests_enabled and dbus_enabled gates are true, so the test
helper libraries and D-Bus executables are only defined in those cases.
The per-component subdirectories instead re-checked opt_*.allowed(),
which is true under the default 'auto' even when the dependencies are
missing, and then referenced those undefined variables - failing the
configuration outright instead of quietly disabling the component.
Gate every subdirectory on the corresponding top-level *_enabled
variable for correct and consistent behavior.
Closes: https://github.com/brgl/libgpiod/discussions/190
Fixes: 97bab4cc87dd ("build: replace autotools with meson & ninja")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
bindings/cxx/meson.build | 4 ++--
bindings/glib/meson.build | 4 ++--
bindings/python/meson.build | 2 +-
dbus/meson.build | 2 +-
man/meson.build | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/bindings/cxx/meson.build b/bindings/cxx/meson.build
index e93d686d50e9cc28ee986f6236bc02dfaf25e6fc..f7f8d9c2fdf231304e3dedd8aa4fe8645da639e1 100644
--- a/bindings/cxx/meson.build
+++ b/bindings/cxx/meson.build
@@ -65,10 +65,10 @@ libgpiodcxx_dep = declare_dependency(
include_directories: cxx_inc,
)
-if opt_examples.allowed()
+if examples_enabled
subdir('examples')
endif
-if opt_tests.allowed()
+if tests_enabled
subdir('tests')
endif
diff --git a/bindings/glib/meson.build b/bindings/glib/meson.build
index 4c36cc5e23e56a843d03c9f939bef0643cb6b98c..b8f8f53c2a4e564de1012ccb4979077e9813e7b5 100644
--- a/bindings/glib/meson.build
+++ b/bindings/glib/meson.build
@@ -112,10 +112,10 @@ if opt_introspection.allowed() and gir_dep.found()
)
endif
-if opt_examples.allowed()
+if examples_enabled
subdir('examples')
endif
-if opt_tests.allowed()
+if tests_enabled
subdir('tests')
endif
diff --git a/bindings/python/meson.build b/bindings/python/meson.build
index efd99a9d8118106005a4a42edcb906d6a5b65818..f01923cf33cd9bf2f9a6d2c43c36f6b38622d1a2 100644
--- a/bindings/python/meson.build
+++ b/bindings/python/meson.build
@@ -5,6 +5,6 @@ py = import('python').find_installation('python3', required: true)
subdir('gpiod')
-if opt_tests.allowed()
+if tests_enabled
subdir('tests')
endif
diff --git a/dbus/meson.build b/dbus/meson.build
index 2df5906298c4edd20377d5f90d62189f46d17eb9..3b82f2d552526a41627a645ed2fdfe7549c44540 100644
--- a/dbus/meson.build
+++ b/dbus/meson.build
@@ -6,6 +6,6 @@ subdir('lib')
subdir('manager')
subdir('client')
-if opt_tests.allowed()
+if tests_enabled
subdir('tests')
endif
diff --git a/man/meson.build b/man/meson.build
index 27b99ac98afc873554cabd5a01a4a50439286298..f3a2d4e83698e3f9ca1a8ae35cdf3642dca90f23 100644
--- a/man/meson.build
+++ b/man/meson.build
@@ -4,7 +4,7 @@
man_template = files('template')
man1_dir = get_option('mandir') / 'man1'
-if opt_tools.allowed()
+if tools_enabled
foreach tool : ['gpiodetect', 'gpioinfo', 'gpioget', 'gpioset', 'gpiomon', 'gpionotify']
custom_target(tool + '.1',
output: tool + '.1',
@@ -24,7 +24,7 @@ if opt_tools.allowed()
endforeach
endif
-if opt_dbus.allowed()
+if dbus_enabled
gpiocli_cmds = [
'detect', 'find', 'info', 'get', 'monitor', 'notify',
'reconfigure', 'release', 'request', 'requests', 'set', 'wait',
---
base-commit: 3591a62952275f91388a4c80dfa95e4970093a7b
change-id: 20260617-meson-enabled-checks-491cb0d436af
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v3 2/8] irqchip/qcom-pdc: Move all statics to struct pdc_desc
From: Konrad Dybcio @ 2026-06-17 13:26 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-2-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> There are multiple statics used. Move all to struct pdc_desc to better
> align with versioning support. Document them.
>
> No functional impact.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
[...]
> static void pdc_enable_intr(struct irq_data *d, bool on)
> {
> - unsigned long flags;
> + guard(raw_spinlock)(&pdc->lock);
tglx suggested to use guard(irq) around "the other callsite"..
which I'm not sure where it'd be - maybe around __pdc_enable_intr()
in pdc_setup_pin_mapping()?
Otherwise this patch looks good to me
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-17 13:12 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-1-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> - ret = pdc_setup_pin_mapping(node);
> + ret = pdc_setup_pin_mapping(dev, node);
dev is enough, we can get the np in that function from dev->of_node
otherwise:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-17 11:19 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Bartosz Golaszewski,
Andy Shevchenko
Cc: linusw@kernel.org, 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 [戴志峰]
In-Reply-To: <61c053a5a8e6461f9e6fcd40b6b5064d@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Hi,
On Wed Jun 17, 2026 at 11:54 AM CEST, Yu-Chun Lin [林祐君] wrote:
> Hi Michael,
>
>> Hi,
>>
>> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] 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?
>>>>
>>>
>>> The panic was caused by my driver including
>>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>
>> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>>
>> -michael
>
> Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Honestly, I'm not sure. I've never done anything with irq domains
except for using the regmap_irq_chip. But from what I can tell is
that GPIOCHIP_IRQ_RESOURCE_HELPERS are tied to the handling with
gc->irq.chip, which isn't used at all if you add the domain via
gpiochip_irqchip_add_domain(). Please correct me if I'm wrong
though.
-michael
> Additional information: our GPIO controller receives 3 separate interrupt lines.
> Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
> this multi-line hardware design, we are forced to create our own IRQ domain and pass
> it via 'config->irq_domain'.
>
> Given this constraint (that we must use our own IRQ domain), are you suggesting
> that we should implement our own 'irq_request_resources' and
> 'irq_release_resources' callbacks instead of relying on
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
>
> But if that is the case, we would much prefer to let the core gpiolib handle
> these resource and state management tasks for us *as proposed in option 3), rather
> than duplicating the effort in our driver.
>
> Best Regards,
> Yu-Chun
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
From: Krzysztof Kozlowski @ 2026-06-17 10:20 UTC (permalink / raw)
To: Alim Akhtar
Cc: peter.griffin, robh, conor+dt, linusw, linux-samsung-soc,
linux-kernel, devicetree, linux-gpio, hajun.sung
In-Reply-To: <20260615085252.1964423-3-alim.akhtar@samsung.com>
On Mon, Jun 15, 2026 at 02:22:49PM +0530, Alim Akhtar wrote:
> Document pin controller support on Exynos8855 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
No wakeup-eint?
> Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 9:54 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, 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 [戴志峰]
In-Reply-To: <DJB6XO07EC8Q.1X9P752MLFB4N@kernel.org>
Hi Michael,
> Hi,
>
> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] 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?
>>>
>>
>> The panic was caused by my driver including
>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>
> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>
> -michael
Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Additional information: our GPIO controller receives 3 separate interrupt lines.
Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
this multi-line hardware design, we are forced to create our own IRQ domain and pass
it via 'config->irq_domain'.
Given this constraint (that we must use our own IRQ domain), are you suggesting
that we should implement our own 'irq_request_resources' and
'irq_release_resources' callbacks instead of relying on
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
But if that is the case, we would much prefer to let the core gpiolib handle
these resource and state management tasks for us *as proposed in option 3), rather
than duplicating the effort in our driver.
Best Regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH v1] pwm: Use named initializers for platform_device_id arrays
From: Laurent Pinchart @ 2026-06-17 9:58 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: linux-pwm, linux-gpio, linux-kernel
In-Reply-To: <b515eb1644e793d019163fd2a717d3fccef857f5.1781689255.git.u.kleine-koenig@baylibre.com>
On Wed, Jun 17, 2026 at 11:41:50AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Named initializers are better readable and more robust to changes of the
> struct definition. This robustness is relevant for a planned change to
> struct platform_device_id replacing .driver_data by an anonymous union.
>
> While touching these arrays drop a comma after a list terminator.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/pwm/pwm-adp5585.c | 4 ++--
For this driver,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> drivers/pwm/pwm-pxa.c | 12 ++++++------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pwm/pwm-adp5585.c b/drivers/pwm/pwm-adp5585.c
> index 806f8d79b0d7..f4aa74b44ed2 100644
> --- a/drivers/pwm/pwm-adp5585.c
> +++ b/drivers/pwm/pwm-adp5585.c
> @@ -203,8 +203,8 @@ static const struct adp5585_pwm_chip adp5589_pwm_chip_info = {
> };
>
> static const struct platform_device_id adp5585_pwm_id_table[] = {
> - { "adp5585-pwm", (kernel_ulong_t)&adp5585_pwm_chip_info },
> - { "adp5589-pwm", (kernel_ulong_t)&adp5589_pwm_chip_info },
> + { .name = "adp5585-pwm", .driver_data = (kernel_ulong_t)&adp5585_pwm_chip_info },
> + { .name = "adp5589-pwm", .driver_data = (kernel_ulong_t)&adp5589_pwm_chip_info },
> { /* Sentinel */ }
> };
> MODULE_DEVICE_TABLE(platform, adp5585_pwm_id_table);
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index 80d2fa10919f..b844bb2dd92e 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -32,12 +32,12 @@
> #define HAS_SECONDARY_PWM 0x10
>
> static const struct platform_device_id pwm_id_table[] = {
> - /* PWM has_secondary_pwm? */
> - { "pxa25x-pwm", 0 },
> - { "pxa27x-pwm", HAS_SECONDARY_PWM },
> - { "pxa168-pwm", 0 },
> - { "pxa910-pwm", 0 },
> - { },
> + /* PWM has_secondary_pwm? */
> + { .name = "pxa25x-pwm", .driver_data = 0 },
> + { .name = "pxa27x-pwm", .driver_data = HAS_SECONDARY_PWM },
> + { .name = "pxa168-pwm", .driver_data = 0 },
> + { .name = "pxa910-pwm", .driver_data = 0 },
> + { }
> };
> MODULE_DEVICE_TABLE(platform, pwm_id_table);
>
>
> base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v1] pwm: Use named initializers for platform_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-17 9:41 UTC (permalink / raw)
To: linux-pwm; +Cc: Laurent Pinchart, linux-gpio, linux-kernel
Named initializers are better readable and more robust to changes of the
struct definition. This robustness is relevant for a planned change to
struct platform_device_id replacing .driver_data by an anonymous union.
While touching these arrays drop a comma after a list terminator.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/pwm/pwm-adp5585.c | 4 ++--
drivers/pwm/pwm-pxa.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-adp5585.c b/drivers/pwm/pwm-adp5585.c
index 806f8d79b0d7..f4aa74b44ed2 100644
--- a/drivers/pwm/pwm-adp5585.c
+++ b/drivers/pwm/pwm-adp5585.c
@@ -203,8 +203,8 @@ static const struct adp5585_pwm_chip adp5589_pwm_chip_info = {
};
static const struct platform_device_id adp5585_pwm_id_table[] = {
- { "adp5585-pwm", (kernel_ulong_t)&adp5585_pwm_chip_info },
- { "adp5589-pwm", (kernel_ulong_t)&adp5589_pwm_chip_info },
+ { .name = "adp5585-pwm", .driver_data = (kernel_ulong_t)&adp5585_pwm_chip_info },
+ { .name = "adp5589-pwm", .driver_data = (kernel_ulong_t)&adp5589_pwm_chip_info },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(platform, adp5585_pwm_id_table);
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index 80d2fa10919f..b844bb2dd92e 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -32,12 +32,12 @@
#define HAS_SECONDARY_PWM 0x10
static const struct platform_device_id pwm_id_table[] = {
- /* PWM has_secondary_pwm? */
- { "pxa25x-pwm", 0 },
- { "pxa27x-pwm", HAS_SECONDARY_PWM },
- { "pxa168-pwm", 0 },
- { "pxa910-pwm", 0 },
- { },
+ /* PWM has_secondary_pwm? */
+ { .name = "pxa25x-pwm", .driver_data = 0 },
+ { .name = "pxa27x-pwm", .driver_data = HAS_SECONDARY_PWM },
+ { .name = "pxa168-pwm", .driver_data = 0 },
+ { .name = "pxa910-pwm", .driver_data = 0 },
+ { }
};
MODULE_DEVICE_TABLE(platform, pwm_id_table);
base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v9 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
From: Andy Shevchenko @ 2026-06-17 9:27 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <20260617065922.26004-3-hardikprakash.official@gmail.com>
On Wed, Jun 17, 2026 at 12:29:22PM +0530, Hardik Prakash wrote:
> 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
...
> +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 ||
> + !agpio->resource_source.string_ptr)
> + return 1;
I'm wondering if we simply can move to strncmp() instead of this check
> + /* Skip if we've already tracked this GPIO controller */
> + list_for_each_entry(ref, gpio_controllers, node) {
> + if (!strcmp(ref->path, agpio->resource_source.string_ptr))
if (!strncmp(ref->path, agpio->resource_source.string_ptr))
> + 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);
Make it a single line.
> + acpi_dev_free_resource_list(&res_list);
It's not critical double free (it will try to free an empty list) on error.
> + return ret < 0 ? ret : 0;
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 acpi_device *adev;
> + LIST_HEAD(gpio_controllers);
> + struct gpio_controller_ref *ref;
Reversed xmas tree order.
> + int ret = 0;
Useless assignment.
> + 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);
Make it a single line.
> + if (ret < 0)
> + goto cleanup;
> +
> + /* For each GPIO controller, check if its platform device is bound */
> + list_for_each_entry(ref, &gpio_controllers, node) {
> + acpi_handle handle;
> + acpi_status status;
> + struct acpi_device *gpio_adev;
> + struct device *gpio_dev;
Reversed xmas tree order.
> + 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) {
> + ret = -EPROBE_DEFER;
> + goto cleanup;
> + }
> + /*
> + * Defer probe until the GPIO controller is fully bound,
> + * ensuring its IRQ setup is complete before we enumerate
> + * I2C child devices.
> + */
> + scoped_guard(device, gpio_dev)
> + bound = device_is_bound(gpio_dev);
> + if (!bound) {
Some of the compilers might complain the use of uninitialised variable (they
might not parse properly scoped_guard() case).
> + ret = -EPROBE_DEFER;
> + goto cleanup;
> + }
To make it sure and deduplicate above the whole stuff can be written as
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 */
I'm not sure if it's good to have all this quirk here or simply start
a i2c-designware-quirks.c. Theoretically the PCI counterpart might,
but I think quite unlikely, want to have something similar in the future.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Marco Scardovi @ 2026-06-17 8:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, Mario Limonciello, linux-gpio, linux-acpi,
linux-kernel
In-Reply-To: <ajEtpY101OpZdtaF@ashevche-desk.local>
>
> Okay, perhaps this all needs to be elaborated and summarized in the commit
> message.
> > Sidenote
> > Personally I'd wait for Mario for further info: after all it's him the
> > maintainer for AMD side and surely knows more than me.
>
> Sure, I am with you on this.
>
What I'm saying below is purely based on my own speculations but it's the
most plausible thing I can think as for now.
When I tested Mario's patch back in April it totally used to work on my
device: I have an idea that the value probably happened to be equal 1, like
requested on the patch and making it working as intended.
In the meantime I updated the BIOS (from 310 to 315, released in May),
changing the value from 1 to 0 and breaking the boot time again (as said it's
my own speculation, I'm not sure if it is actually possible).
I didn't test the patch after the BIOS update 'cause I had the
gpiolib_acpi.run_edge_events_on_boot=0 option enabled and didn't think it
would stop working again.
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Marco Scardovi @ 2026-06-17 8:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, Mario Limonciello, linux-gpio, linux-acpi,
linux-kernel
In-Reply-To: <ajEtpY101OpZdtaF@ashevche-desk.local>
>
> Okay, perhaps this all needs to be elaborated and summarized in the commit
> message.
> > Sidenote
> > Personally I'd wait for Mario for further info: after all it's him the
> > maintainer for AMD side and surely knows more than me.
>
> Sure, I am with you on this.
>
What I'm saying below is purely based on my own speculations but it's the
most plausible thing I can think as for now.
When I tested Mario's patch back in April it totally used to work on my
device: I have an idea that the value probably happened to be equal 1, like
requested on the patch and making it working as intended.
In the meantime I updated the BIOS (from 310 to 315, released in May),
changing the value from 1 to 0 and breaking the boot time again (as said it's
my own speculation, I'm not sure if it is actually possible).
I didn't test the patch after the BIOS update 'cause I had the
gpiolib_acpi.run_edge_events_on_boot=0 option enabled and didn't think it
would stop working again.
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-17 8:44 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Bartosz Golaszewski,
Andy Shevchenko
Cc: linusw@kernel.org, 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 [戴志峰]
In-Reply-To: <39de4d4ada5446e7a33e48c43f410439@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Hi,
On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] 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?
>>
>
> The panic was caused by my driver including 'GPIOCHIP_IRQ_RESOURCE_HELPERS',
> which forced the call to 'gpiochip_irq_reqres()' and crashed.
But why did you use it if your irq domain isn't managed by the
gpiolib, but rather your own irq domain? Before going with option #3
I'd double check if that is correct in your driver.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 8:36 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, 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 [戴志峰]
In-Reply-To: <DJ3QVMZ6XLW9.1M9W541O92QWJ@kernel.org>
Hi Andy, Michael and Bartosz,
> Hi,
>
>On Mon Jun 8, 2026 at 4:10 PM CEST, Bartosz Golaszewski wrote:
>>> On Wed, 3 Jun 2026 02:34:40 +0200, Andy Shevchenko
>>> <andriy.shevchenko@intel.com> said:
>
>>> On Mon, May 25, 2026 at 12:04:09PM +0000, Yu-Chun Lin [林祐君] wrote:
>>>> > On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
>>>> > > Expose an accessor function to retrieve the gpio_chip pointer
>>>> > > from a gpio_regmap instance.
>>>> > >
>>>> > > This is needed by drivers that use gpio_regmap but also manage
>>>> > > their own irq_chip, where
>>>> > > gpiochip_enable_irq()/gpiochip_disable_irq() must be called with
>>>> > > the gpio_chip pointer.
>>>> > >
>>>> > > Add gpio_regmap_get_gpiochip() to allow drivers with complex
>>>> > > custom IRQ implementations.
>>>> >
>>>> > Hmm... Can't we rather add
>>>> > gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
>>>> > that take regmap or GPIO regmap (whatever suits better for the
>>>> > purpose) and do the magic inside GPIO regmap library code?
>>>
>>>> Thanks for the review! I apologize for the misleading commit message.
>>>> The real reason I need the struct gpio_chip pointer is to properly
>>>> set up a custom IRQ domain. Our SoC GPIO controller is quite
>>>> complex. It routes different trigger types to multiple parent IRQs,
>>>> which doesn't fit the generic regmap_irq framework.
>>>> Therefore, we have to create our own irq_domain and pass it to
>>>> gpio_regmap_config.irq_domain.
>>>>
>>>> The core problem occurs inside our custom irq_domain_ops.map() callback:
>>>>
>>>> static int rtd1625_gpio_irq_map(struct irq_domain *domain, unsigned int irq,
>>>> irq_hw_number_t hwirq) {
>>>> struct rtd1625_gpio *data = domain->host_data;
>>>> struct gpio_chip *gc = data->gpio_chip;
>>>>
>>>> /*
>>>> * The second argument MUST be struct gpio_chip *.
>>>> * If we pass our custom data structure here, the kernel will panic later
>>>> * in gpiochip_irq_reqres() when it calls irq_data_get_irq_chip_data()
>>>> * and strictly expects it to be a gpio_chip.
>>>> */
>>>> irq_set_chip_data(irq, gc);
>>>>
>>>> irq_set_lockdep_class(irq, &rtd1625_gpio_irq_lock_class,
>>>> &rtd1625_gpio_irq_request_class);
>>>>
>>>> irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
>>>> irq_set_noprobe(irq);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> 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?
>
The panic was caused by my driver including 'GPIOCHIP_IRQ_RESOURCE_HELPERS',
which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>> This is all good and needs to be depicted in the cover-letter and/or commit message.
Yes, I will do it.
>>>
>>>> Before I send a v4, I see 3 possible paths:
>>>>
>>>> Option 1: Keep the accessor (Current v3 approach) We keep
>>>> gpio_regmap_get_gpiochip() but I will completely rewrite the commit
>>>> message to explain the custom irq_domain_ops.map and lockdep requirements.
>>>>
>>>> Option 2: Let gpiolib create the irq_domain via gpio_regmap_config
>>>> Instead of creating the irq_domain in our driver, we add all
>>>> necessary IRQ fields (irq_chip, irq_handler, irq_parents, etc.) into
>>>> struct gpio_regmap_config. Then gpio-regmap.c populates the
>>>> gpio_irq_chip structure before calling gpiochip_add_data(). This
>>>> prevents an early return and allows the core gpiolib
>>>> (gpiochip_add_irqchip()) to automatically create the irq_domain for us.
>>>> Drawback: This adds a lot of fields to gpio_regmap_config and might
>>>> violate the original design philosophy of gpio-regmap.c (commit
>>>> ebe363197e52), which explicitly states that it does not implement
>>>> its own IRQ chip and delegates it to the parent driver.
>>>>
>>>> Option 3: Drop gpio-regmap entirely (Revert to v2 approach)
>>>> Currently, all drivers using gpio-regmap (mostly simple CPLDs and
>>>> external I/O cards) use regmap-irq to get their domain. Since our
>>>> SoC has a complex IRQ routing scheme with multiple parents, maybe
>>>> gpio-regmap is simply not the right tool for this hardware, and we
>>>> should just implement a standard GPIO driver directly using gpiolib.
>>>>
>>>> Which approach would you prefer upstream?
>>>
>>> This question to Bart, Linus, and poissibly gpio-regmap stakeholders.
>>> I'm not sure that my personal opinion will be the best fit here.
>>>
>>
>> My preference would be for #2 but I understand that this could risk
>> getting stuck in endless bikeshedding so I'm fine with going #3 with
>> potential for future refactoring if we have more similar users.
>
> Yeah, I'd like to keep that stuff out of gpio-regmap. But I'm on the same boat
> regarding the refactoring if we have more data and potential users.
>
> -michael
Got it. I will go with Option #3 in the upcoming v4 patch.
Therefore, I will drop the patches 2, 3 and 4 from this series, and address
Andy's feedback on patch 6.
Best-regards,
Yu Chun
^ permalink raw reply
* Re: [PATCH v9 0/2] i2c: designware: fix WACF2200 touchscreen probe ordering
From: Andy Shevchenko @ 2026-06-17 8:04 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <ajJU2wnx5wS7zmJh@ashevche-desk.local>
On Wed, Jun 17, 2026 at 11:03:44AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 17, 2026 at 12:29:20PM +0530, Hardik Prakash wrote:
> > Patch 1 reverts the broken v8 patch 2/2 which caused boot regressions
> > (NULL pointer dereference and probe deferral loop leading to CPU
> > starvation). Patch 2 is a corrected resubmission addressing all issues.
>
> When preparing patches, use existing tools. This series was half received by me
> as the second patch has incomplete Cc list. You may use `b4` tool (check in
> your Linux distro) or my "smart" script [1] which I use on a daily basis.
>
> [1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh
Ah, eventually got it. It was a glitch on my side, sorry for the noise.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 0/2] i2c: designware: fix WACF2200 touchscreen probe ordering
From: Andy Shevchenko @ 2026-06-17 8:03 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <20260617065922.26004-1-hardikprakash.official@gmail.com>
On Wed, Jun 17, 2026 at 12:29:20PM +0530, Hardik Prakash wrote:
> Patch 1 reverts the broken v8 patch 2/2 which caused boot regressions
> (NULL pointer dereference and probe deferral loop leading to CPU
> starvation). Patch 2 is a corrected resubmission addressing all issues.
When preparing patches, use existing tools. This series was half received by me
as the second patch has incomplete Cc list. You may use `b4` tool (check in
your Linux distro) or my "smart" script [1] which I use on a daily basis.
[1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v9 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
From: Hardik Prakash @ 2026-06-17 6:59 UTC (permalink / raw)
To: linux-i2c
Cc: linux-gpio, wsa, andriy.shevchenko, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah,
Hardik Prakash
In-Reply-To: <20260617065922.26004-1-hardikprakash.official@gmail.com>
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 | 133 ++++++++++++++++++++
1 file changed, 133 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3351c4a9ef11..51172fffa2b8 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,133 @@ 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 ||
+ !agpio->resource_source.string_ptr)
+ return 1;
+
+ /* Skip if we've already tracked this GPIO controller */
+ list_for_each_entry(ref, gpio_controllers, node) {
+ if (!strcmp(ref->path, agpio->resource_source.string_ptr))
+ 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);
+ acpi_dev_free_resource_list(&res_list);
+ return ret < 0 ? ret : 0;
+}
+
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+ struct acpi_device *adev;
+ LIST_HEAD(gpio_controllers);
+ struct gpio_controller_ref *ref;
+ int ret = 0;
+
+ 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) {
+ acpi_handle handle;
+ acpi_status status;
+ struct acpi_device *gpio_adev;
+ struct device *gpio_dev;
+ 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) {
+ ret = -EPROBE_DEFER;
+ goto cleanup;
+ }
+
+ /*
+ * Defer probe until the GPIO controller is fully bound,
+ * ensuring its IRQ setup is complete before we enumerate
+ * I2C child devices.
+ */
+ scoped_guard(device, gpio_dev)
+ bound = device_is_bound(gpio_dev);
+
+ 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 +267,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;
--
2.54.0
^ permalink raw reply related
* [PATCH v9 1/2] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Hardik Prakash @ 2026-06-17 6:59 UTC (permalink / raw)
To: linux-i2c
Cc: linux-gpio, wsa, andriy.shevchenko, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah,
Hardik Prakash
In-Reply-To: <20260617065922.26004-1-hardikprakash.official@gmail.com>
This reverts commit ef76a3a28c79b628890431aa344af633e892035b.
The patch causes boot regressions on multiple machines. A NULL pointer
dereference occurs when agpio->resource_source.string_ptr is NULL (i.e.
when string_length is 0), and a probe deferral loop causes CPU starvation
leading to kernel panic on Intel CI machines.
The patch needs a proper rewrite addressing these issues before resubmission.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com>
Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Tested-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/linux-i2c/90656be5-eca0-4a09-9b19-0c6e85f1d455@intel.com/
Closes: https://lore.kernel.org/20260602185339.GA404948@ax162/
---
drivers/i2c/busses/i2c-designware-platdrv.c | 156 --------------------
1 file changed, 156 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 1c01b0460385..3351c4a9ef11 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,8 +8,6 @@
* 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>
@@ -132,152 +130,6 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
return 0;
}
-#ifdef CONFIG_ACPI
-struct gpio_dep_ctx {
- struct list_head gpio_controllers;
- int ret;
-};
-
-struct gpio_controller_ref {
- struct list_head node;
- char *path;
-};
-
-static int check_gpioint_resource(struct acpi_resource *ares, void *data)
-{
- struct gpio_dep_ctx *ctx = data;
- struct acpi_resource_gpio *agpio;
- struct gpio_controller_ref *ref, *tmp;
- bool found = false;
-
- if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
- return 1;
-
- agpio = &ares->data.gpio;
- if (agpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_INT)
- return 1;
-
- /* Check if we've already tracked this GPIO controller */
- list_for_each_entry(tmp, &ctx->gpio_controllers, node) {
- if (!strcmp(tmp->path, agpio->resource_source.string_ptr)) {
- found = true;
- break;
- }
- }
-
- if (!found) {
- ref = kzalloc(sizeof(*ref), GFP_KERNEL);
- if (!ref) {
- ctx->ret = -ENOMEM;
- return 0;
- }
-
- ref->path = kstrdup(agpio->resource_source.string_ptr, GFP_KERNEL);
- if (!ref->path) {
- kfree(ref);
- ctx->ret = -ENOMEM;
- return 0;
- }
-
- list_add_tail(&ref->node, &ctx->gpio_controllers);
- }
-
- return 1;
-}
-
-static int check_child_gpioint(struct acpi_device *adev, void *data)
-{
- struct gpio_dep_ctx *ctx = data;
- struct list_head res_list;
-
- INIT_LIST_HEAD(&res_list);
-
- acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, ctx);
- acpi_dev_free_resource_list(&res_list);
-
- if (ctx->ret < 0)
- return ctx->ret;
-
- return 0;
-}
-
-static int i2c_dw_check_gpio_dependencies(struct device *dev)
-{
- struct acpi_device *adev = ACPI_COMPANION(dev);
- struct gpio_dep_ctx ctx = { .ret = 0 };
- struct gpio_controller_ref *ref, *tmp;
- int ret = 0;
-
- if (!adev)
- return 0;
-
- INIT_LIST_HEAD(&ctx.gpio_controllers);
-
- /* Walk all child devices and collect GpioInt controller references */
- ret = acpi_dev_for_each_child(adev, check_child_gpioint, &ctx);
- if (ret < 0 || ctx.ret < 0) {
- ret = ctx.ret ?: ret;
- goto cleanup;
- }
-
- /* For each GPIO controller, check if its parent device is bound */
- list_for_each_entry(ref, &ctx.gpio_controllers, node) {
- acpi_handle handle;
- acpi_status status;
- struct acpi_device *gpio_adev;
- struct device *gpio_dev;
- 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) {
- ret = -EPROBE_DEFER;
- goto cleanup;
- }
-
- /*
- * Check if the GPIO controller's device is bound. If not,
- * defer probe to ensure GPIO initialization (including IRQ
- * setup and quirks) is complete before we enumerate I2C
- * child devices.
- */
- scoped_guard(device, gpio_dev) {
- bound = device_is_bound(gpio_dev);
- }
- if (!bound) {
- put_device(gpio_dev);
- ret = -EPROBE_DEFER;
- goto cleanup;
- }
-
- put_device(gpio_dev);
- }
-
-cleanup:
- list_for_each_entry_safe(ref, tmp, &ctx.gpio_controllers, node) {
- list_del(&ref->node);
- kfree(ref->path);
- kfree(ref);
- }
-
- return ret;
-}
-#else
-static int i2c_dw_check_gpio_dependencies(struct device *dev)
-{
- return 0;
-}
-#endif /* CONFIG_ACPI */
-
static int dw_i2c_plat_probe(struct platform_device *pdev)
{
u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
@@ -286,14 +138,6 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
struct dw_i2c_dev *dev;
int irq, ret;
- /*
- * Check if any child devices have GpioInt resources, and if so,
- * defer probe until those GPIO controllers are fully bound.
- */
- ret = i2c_dw_check_gpio_dependencies(device);
- if (ret)
- return ret;
-
irq = platform_get_irq_optional(pdev, 0);
if (irq == -ENXIO)
flags |= ACCESS_POLLING;
--
2.54.0
^ permalink raw reply related
* [PATCH v9 0/2] i2c: designware: fix WACF2200 touchscreen probe ordering
From: Hardik Prakash @ 2026-06-17 6:59 UTC (permalink / raw)
To: linux-i2c
Cc: linux-gpio, wsa, andriy.shevchenko, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah,
Hardik Prakash
Patch 1 reverts the broken v8 patch 2/2 which caused boot regressions
(NULL pointer dereference and probe deferral loop leading to CPU
starvation). Patch 2 is a corrected resubmission addressing all issues.
Changes from v8:
- Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
- Remove gpio_dep_ctx wrapper struct, pass list_head * directly (Andy)
- Add const to gpio_controller_ref.path (Andy)
- Add NULL check for resource_source.string_ptr to fix crash on hardware
where GPIO resources have no named controller (Nathan Chancellor,
Chaitanya Kumar Borah)
- Use acpi_dev_get_resources() return value properly (Andy)
- Fix all error paths to call free_gpio_controller_list() (Andy)
- Change guard to #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
- Remove erroneous put_device() calls -- acpi_get_first_physical_node()
returns a borrowed pointer with no refcount increment
- Use LIST_HEAD() macro, split adev declaration and assignment (Andy)
- scoped_guard single statement without braces (Andy)
- Remove misused Reported-by/Closes tags (Andy)
Tested on Lenovo Yoga 7 14AGP11 (83TD), Fedora 44, kernel 7.1.0-rc5+.
Touch and stylus fully functional.
Kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221494
Hardik Prakash (2):
Revert "i2c: designware: defer probe if child GpioInt controllers are
not bound"
i2c: designware: defer probe if child GpioInt controllers are not bound
drivers/i2c/busses/i2c-designware-platdrv.c | 133 ++++++++++++++++++++
1 file changed, 133 insertions(+)
base-commit: ef76a3a28c79b628890431aa344af633e892035b
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Bartosz Golaszewski @ 2026-06-17 6:14 UTC (permalink / raw)
To: Mika Westerberg, Andy Shevchenko, Linus Walleij,
Bartosz Golaszewski, Marco Scardovi
Cc: Bartosz Golaszewski, linux-gpio, linux-acpi, linux-kernel
In-Reply-To: <20260610154204.110379-1-scardracs@disroot.org>
On Wed, 10 Jun 2026 17:42:02 +0200, Marco Scardovi wrote:
> The series adds explicit bounds checking for GPIO pin accesses and
> ensures safe handling of ACPI addresses in OperationRegion handlers,
> without referring to truncation or wrap-around behavior, which does
> not apply.
>
> Changes in v6:
> - Rebased onto next-20260609.
> - Corrected commit messages to describe bounds checking and
> safe ACPI GPIO address handling.
> - Removed references to truncation or wrap-around behavior.
> - No code changes compared to v5.
>
> [...]
Applied, thanks!
[1/2] gpiolib: acpi: Add robust bounds-checking for GPIO pin resources
https://git.kernel.org/brgl/c/dece79032f529d2c9fdbf63a9f2fc32244722775
[2/2] gpiolib: acpi: Prevent out-of-bounds pin access in OperationRegion handler
https://git.kernel.org/brgl/c/ae9f812df3149729643d27d2af488c112f62af9a
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Bartosz Golaszewski @ 2026-06-17 6:14 UTC (permalink / raw)
To: Mika Westerberg
Cc: Andy Shevchenko, Bartosz Golaszewski, Mika Westerberg,
Linus Walleij, linux-gpio, linux-acpi, linux-kernel,
Marco Scardovi
In-Reply-To: <20260616114855.GD2990@black.igk.intel.com>
On Tue, 16 Jun 2026 13:48:55 +0200, Mika Westerberg
<mika.westerberg@linux.intel.com> said:
> On Tue, Jun 16, 2026 at 02:28:00PM +0300, Andy Shevchenko wrote:
>> On Tue, Jun 16, 2026 at 06:42:34AM -0400, Bartosz Golaszewski wrote:
>> > On Tue, 16 Jun 2026 12:26:06 +0200, Andy Shevchenko
>> > <andriy.shevchenko@linux.intel.com> said:
>> > > On Tue, Jun 16, 2026 at 02:54:02AM -0700, Bartosz Golaszewski wrote:
>> > >> On Fri, 12 Jun 2026 10:52:57 +0200, Mika Westerberg
>> > >> <mika.westerberg@linux.intel.com> said:
>> > >> > On Wed, Jun 10, 2026 at 05:42:02PM +0200, Marco Scardovi wrote:
>> > >> >>
>> > >> >> The series adds explicit bounds checking for GPIO pin accesses and
>> > >> >> ensures safe handling of ACPI addresses in OperationRegion handlers,
>> > >> >> without referring to truncation or wrap-around behavior, which does
>> > >> >> not apply.
>> > >> >
>> > >> > I'm fine with these now.
>> > >> >
>> > >> > For both,
>> > >> >
>> > >> > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>> > >>
>> > >> Andy, Mika: do you want me to queue these directly for v7.2?
>> > >
>> > > I believe there is no hurry, but I have no objections if you pull it in.
>> >
>> > Your call, if you thknk these should wait until v7.3, I'll leave them for now.
>>
>> For the full consensus we need Mika's opinion :-)
>
> If we can get these for v7.2-rc2+ or so that would be good enough IMHO.
>
Then let me just queue them now then.
Bart
^ 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