* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Marco Scardovi @ 2026-06-16 9:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mika Westerberg, Linus Walleij, Bartosz Golaszewski,
Mario Limonciello, linux-gpio, linux-acpi, linux-kernel
In-Reply-To: <ajEX8L63vAhhndv7@ashevche-desk.local>
Hi Andy,
> 'slow'? Did you mean 'low'?
Yes, sorry, that was a typo. I meant 'low'.
> What is this interrupt for? Touchpad?
It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
Specifically, it triggers on pin 21, appearing in /proc/interrupts as
"amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.
Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
"gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
bypassed the 36-second delay, which confirms this specific pin/handler is the
culprit stalling the boot process.
Thanks for the review!
Marco
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Bartosz Golaszewski @ 2026-06-16 9:54 UTC (permalink / raw)
To: Mika Westerberg
Cc: Mika Westerberg, Andy Shevchenko, Linus Walleij,
Bartosz Golaszewski, linux-gpio, linux-acpi, linux-kernel,
Marco Scardovi
In-Reply-To: <20260612085257.GY2990@black.igk.intel.com>
On Fri, 12 Jun 2026 10:52:57 +0200, Mika Westerberg
<mika.westerberg@linux.intel.com> said:
> Hi,
>
> On Wed, Jun 10, 2026 at 05:42:02PM +0200, Marco Scardovi wrote:
>> Hi all,
>>
>> 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?
Bart
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Andy Shevchenko @ 2026-06-16 9:58 UTC (permalink / raw)
To: Marco Scardovi
Cc: Mika Westerberg, Linus Walleij, Bartosz Golaszewski,
Mario Limonciello, linux-gpio, linux-acpi, linux-kernel
In-Reply-To: <RqcbSmnzQWas394Kq-TG7w@disroot.org>
On Tue, Jun 16, 2026 at 11:43:56AM +0200, Marco Scardovi wrote:
...
> > What is this interrupt for? Touchpad?
>
> It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
> Specifically, it triggers on pin 21, appearing in /proc/interrupts as
> "amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.
>
> Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
> "gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
> bypassed the 36-second delay, which confirms this specific pin/handler is the
> culprit stalling the boot process.
Mika, do you see any problems with disabled (deferred?) interrupt for this type
of event? I think it might break the suspend-resume (on touchpad event). Also
do you remember if we ever had touchpad event to be ActiveBoth?
What I'm trying to understand if this is pure BIOS issue (typo) or HW really
wants to
- be able to generate events to the OS (at boot time?)
- have the reaction on any edge
Mario, do you know anything more? It's AMD platform at the end, what the TP
model and if it requires both edges...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 7.1-1
From: Bartosz Golaszewski @ 2026-06-16 9:59 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Linux GPIO, Linus Walleij, Andy Shevchenko
In-Reply-To: <aiZglQb9hQwNeApB@ashevche-desk.local>
On Mon, Jun 8, 2026 at 8:26 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, May 12, 2026 at 11:13:04PM +0300, Andy Shevchenko wrote:
> > On Fri, May 08, 2026 at 08:03:57AM +0200, Andy Shevchenko wrote:
> > > Hi Linux GPIO maintainers,
> > >
> > > A single fix for ACPI interrupts handling on boot. Have been in Linux Next for
> > > a while without reported regressions. Please, pull for the current, v7.1 cycle.
> >
> > Bart, any issues with this PR?
>
> What's going on with this PR, please?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Hi! Sorry, I have no idea why this didn't trigger my PR filters.
Now pulled. I'll see about fixing the filter, in the future if I don't
respond to your PR within a week, send me a direct email to
brgl@kernel.org.
Bart
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Mika Westerberg @ 2026-06-16 10:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Marco Scardovi, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, Mario Limonciello, linux-gpio, linux-acpi,
linux-kernel
In-Reply-To: <ajEeLL5u3hf7lvWD@ashevche-desk.local>
On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 11:43:56AM +0200, Marco Scardovi wrote:
>
> ...
>
> > > What is this interrupt for? Touchpad?
> >
> > It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
> > Specifically, it triggers on pin 21, appearing in /proc/interrupts as
> > "amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.
> >
> > Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
> > "gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
> > bypassed the 36-second delay, which confirms this specific pin/handler is the
> > culprit stalling the boot process.
>
> Mika, do you see any problems with disabled (deferred?) interrupt for this type
> of event? I think it might break the suspend-resume (on touchpad event). Also
> do you remember if we ever had touchpad event to be ActiveBoth?
For starters, why this is ACPI event in the first place? The AML is not
supposed to use the touchpad.
Touchpad should be using just regular GpioInt(). Does it still work after
this patch? If yes then I think this is definitely okay.
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 7.1-1
From: Andy Shevchenko @ 2026-06-16 10:25 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: Linux GPIO, Linus Walleij, Andy Shevchenko
In-Reply-To: <CAMRc=MeGFJFs-zL4+Q23HAnW6C+Y5JTvHBntQ9+4+UNNjkU-kg@mail.gmail.com>
On Tue, Jun 16, 2026 at 11:59:02AM +0200, Bartosz Golaszewski wrote:
> On Mon, Jun 8, 2026 at 8:26 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, May 12, 2026 at 11:13:04PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 08, 2026 at 08:03:57AM +0200, Andy Shevchenko wrote:
> > > > Hi Linux GPIO maintainers,
> > > >
> > > > A single fix for ACPI interrupts handling on boot. Have been in Linux Next for
> > > > a while without reported regressions. Please, pull for the current, v7.1 cycle.
> > >
> > > Bart, any issues with this PR?
> >
> > What's going on with this PR, please?
>
> Hi! Sorry, I have no idea why this didn't trigger my PR filters.
>
> Now pulled. I'll see about fixing the filter, in the future if I don't
> respond to your PR within a week, send me a direct email to
> brgl@kernel.org.
I will try to remember this, thanks for pulling!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Andy Shevchenko @ 2026-06-16 10:26 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij, linux-gpio,
linux-acpi, linux-kernel, Marco Scardovi
In-Reply-To: <CAMRc=Mcv7SWVYA6rNZo+-tYx_ohOdedkewLZOa=X1Eei=1fTzA@mail.gmail.com>
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Bartosz Golaszewski @ 2026-06-16 10:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij, linux-gpio,
linux-acpi, linux-kernel, Marco Scardovi, Bartosz Golaszewski
In-Reply-To: <ajEkvstS6RgRTATK@ashevche-desk.local>
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.
Bart
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Marco Scardovi @ 2026-06-16 10:58 UTC (permalink / raw)
To: Andy Shevchenko, Mika Westerberg
Cc: Mika Westerberg, Linus Walleij, Bartosz Golaszewski,
Mario Limonciello, linux-gpio, linux-acpi, linux-kernel
In-Reply-To: <20260616102451.GC2990@black.igk.intel.com>
On Tue, Jun 16, 2026 at 12:24:51 +0200, Mika Westerberg wrote:
> On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> > Mika, do you see any problems with disabled (deferred?) interrupt for this
type
> > of event? I think it might break the suspend-resume (on touchpad event).
Also
> > do you remember if we ever had touchpad event to be ActiveBoth?
>
> For starters, why this is ACPI event in the first place? The AML is not
> supposed to use the touchpad.
>
> Touchpad should be using just regular GpioInt(). Does it still work after
> this patch? If yes then I think this is definitely okay.
Hi Mika, Andy,
Yes, the touchpad continues to work perfectly after this patch (even the
suspend/resume you asked about).
The touchpad itself is initialized and driven by the i2c-hid driver using a
standard GpioInt() resource defined in the touchpad device's _CRS method.
The ACPI event handler (pin 21) registered under the GPIO controller's _AEI
is distinct from this.
The DMI quirk (.no_edge_events_on_boot = true) only prevents the initial
boot-time trigger of this ACPI event handler when the line is asserted low
during initialization. It does not prevent the touchpad driver from
requesting and receiving its interrupts.
Furthermore, unlike using the "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21"
workaround (which would completely disable the ACPI handler), this patch still
keeps the ACPI event handler registered. If any edge events occur on this pin
post-boot (for example, if the BIOS needs to toggle touchpad states or track
device status), the handler will still run normally, avoiding any potential
breakage of runtime ACPI functionality.
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.
^ permalink raw reply
* Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series
From: Andy Shevchenko @ 2026-06-16 11:04 UTC (permalink / raw)
To: Marco Scardovi
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, Mario Limonciello, linux-gpio, linux-acpi,
linux-kernel
In-Reply-To: <KW1oy3-UQRW73tAAP5-cWQ@disroot.org>
On Tue, Jun 16, 2026 at 12:58:31PM +0200, Marco Scardovi wrote:
> On Tue, Jun 16, 2026 at 12:24:51 +0200, Mika Westerberg wrote:
> > On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> > > Mika, do you see any problems with disabled (deferred?) interrupt for
> > > this type of event? I think it might break the suspend-resume (on
> > > touchpad event). Also do you remember if we ever had touchpad event to
> > > be ActiveBoth?
> >
> > For starters, why this is ACPI event in the first place? The AML is not
> > supposed to use the touchpad.
> >
> > Touchpad should be using just regular GpioInt(). Does it still work after
> > this patch? If yes then I think this is definitely okay.
>
> Yes, the touchpad continues to work perfectly after this patch (even the
> suspend/resume you asked about).
>
> The touchpad itself is initialized and driven by the i2c-hid driver using a
> standard GpioInt() resource defined in the touchpad device's _CRS method.
> The ACPI event handler (pin 21) registered under the GPIO controller's _AEI
> is distinct from this.
>
> The DMI quirk (.no_edge_events_on_boot = true) only prevents the initial
> boot-time trigger of this ACPI event handler when the line is asserted low
> during initialization. It does not prevent the touchpad driver from
> requesting and receiving its interrupts.
>
> Furthermore, unlike using the "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21"
> workaround (which would completely disable the ACPI handler), this patch still
> keeps the ACPI event handler registered. If any edge events occur on this pin
> post-boot (for example, if the BIOS needs to toggle touchpad states or track
> device status), the handler will still run normally, avoiding any potential
> breakage of runtime ACPI functionality.
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
From: Sneh Mankad @ 2026-06-16 11:18 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Linus Walleij, Neil Armstrong,
Krzysztof Kozlowski
Cc: linux-arm-msm, linux-gpio, linux-kernel, stable, Maulik Shah
In-Reply-To: <2ba8b020-c8b9-4c60-9fa8-545642bde1fb@oss.qualcomm.com>
On 15-May-26 5:02 PM, Konrad Dybcio wrote:
> On 4/30/26 11:20 AM, Sneh Mankad wrote:
[...]
>
> $ b4 diff 20260430-enable_wakeup_capable_gpios-v2-1-8c26ac795318@oss.qualcomm.com
>
> [...]
>
>
> ## drivers/pinctrl/qcom/pinctrl-msm.c ##
> @@ drivers/pinctrl/qcom/pinctrl-msm.c: static int msm_gpio_irq_reqres(struct irq_data *d)
> + /*
> + * If the wakeup_enable bit is present and marked as available for the
> + * requested GPIO, it should be enabled when the GPIO is marked as
> +- * wake irq in order to allow the interrupt event to be transfered to
> +- * the PDC HW.
> ++ * wake irq in order to allow the interrupt event to be transferred to
> ++ * the PDC/MPM HW.
> * While the name implies only the wakeup event, it's also required for
> * the interrupt event.
> */
>
> This is not what I asked for.
>
> Instead, please focus on explaining what skip_wake_irqs is, perhaps under
> what conditions it is set, and how that differs for PDC vs MPM
>
I raised v2 in reply to Maulik's comment. By that time I had not seen your reply, apologies for that.
Will raise v3 with added description.
Thanks,
Sneh
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Andy Shevchenko @ 2026-06-16 11:28 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mika Westerberg, Mika Westerberg, Linus Walleij, linux-gpio,
linux-acpi, linux-kernel, Marco Scardovi
In-Reply-To: <CAMRc=MeKdP46ohf=hJQRo=afe8WhTQ5yo+Zu3f34h-E4BiuSmQ@mail.gmail.com>
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 :-)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 0/2] gpiolib: acpi: Add robust bounds-checking and safe address handling
From: Mika Westerberg @ 2026-06-16 11:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Mika Westerberg, Linus Walleij, linux-gpio,
linux-acpi, linux-kernel, Marco Scardovi
In-Reply-To: <ajEzQDcuDAG_mHaS@ashevche-desk.local>
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.
^ permalink raw reply
* [PATCH v3] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
From: Sneh Mankad @ 2026-06-16 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Neil Armstrong,
Krzysztof Kozlowski
Cc: linux-arm-msm, linux-gpio, linux-kernel, stable, Sneh Mankad,
Maulik Shah
GPIO interrupts that are wakeup capable need to be forwarded to wakeup
capable parent irqchip. This is done via writing to it's wakeup_enable bit.
Currently the bit is set only for PDC irqchip by checking skip_wake_irqs.
skip_wake_irqs is set to differentiate between parent irqchips MPM and
PDC. It is set when the parent irqchip is PDC to inform pinctrl about
skipping the IRQ setting up at TLMM.
However, the functionality to forward GPIO interrupts during SoC low
power mode is needed regardless of which parent irqchip it is.
Without the functionality it is impossible for MPM irqchip to detect the
GPIO interrupt during SoC low power mode since for MPM irqchip the
skip_wake_irqs is always false.
Remove skip_wake_irqs condition when setting wakeup enable bit to allow
forwarding GPIO interrupts for SoCs using MPM irqchip too.
Fixes: 76b446f5b86e ("pinctrl: qcom: handle intr_target_reg wakeup_present/enable bits")
Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Reviewed-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
Changes in v3:
- Added explanation about skip_wake_irqs in commit message.
- Link to v2: https://lore.kernel.org/r/20260430-enable_wakeup_capable_gpios-v2-1-8c26ac795318@oss.qualcomm.com
Changes in v2:
- Modified comment to specify MPM HW as well.
- Spelling correction.
- Link to v1: https://lore.kernel.org/r/20260430-enable_wakeup_capable_gpios-v1-1-5de39bf06094@oss.qualcomm.com
---
drivers/pinctrl/qcom/pinctrl-msm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 45b3a2763eb85405fecdd4770ba3d4ab684563f0..6a24f9b5e4a979528ba6b5b87fd297c2783ec765 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -1242,12 +1242,12 @@ static int msm_gpio_irq_reqres(struct irq_data *d)
/*
* If the wakeup_enable bit is present and marked as available for the
* requested GPIO, it should be enabled when the GPIO is marked as
- * wake irq in order to allow the interrupt event to be transfered to
- * the PDC HW.
+ * wake irq in order to allow the interrupt event to be transferred to
+ * the PDC/MPM HW.
* While the name implies only the wakeup event, it's also required for
* the interrupt event.
*/
- if (test_bit(d->hwirq, pctrl->skip_wake_irqs) && g->intr_wakeup_present_bit) {
+ if (g->intr_wakeup_present_bit) {
u32 intr_cfg;
raw_spin_lock_irqsave(&pctrl->lock, flags);
@@ -1275,7 +1275,7 @@ static void msm_gpio_irq_relres(struct irq_data *d)
unsigned long flags;
/* Disable the wakeup_enable bit if it has been set in msm_gpio_irq_reqres() */
- if (test_bit(d->hwirq, pctrl->skip_wake_irqs) && g->intr_wakeup_present_bit) {
+ if (g->intr_wakeup_present_bit) {
u32 intr_cfg;
raw_spin_lock_irqsave(&pctrl->lock, flags);
---
base-commit: b4e07588e743c989499ca24d49e752c074924a9a
change-id: 20260430-enable_wakeup_capable_gpios-cb9439ae8772
Best regards,
--
Sneh Mankad <sneh.mankad@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH RESEND] pinctrl: imx1: fix device_node leak in dt_is_flat_functions()
From: Felix Gu @ 2026-06-16 12:14 UTC (permalink / raw)
To: Dong Aisheng, Fabio Estevam, Frank Li, Jacky Bai,
Pengutronix Kernel Team, NXP S32 Linux Team, Linus Walleij,
Sascha Hauer
Cc: linux-gpio, imx, linux-arm-kernel, linux-kernel, Felix Gu
for_each_child_of_node() holds a reference on the iterator node that
must be released on early return. imx1_pinctrl_dt_is_flat_functions()
has two early return paths inside the loop that skip this cleanup.
Replace both loops with the scoped variant so that the reference is
automatically dropped when the iterator goes out of scope.
Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/pinctrl/freescale/pinctrl-imx1-core.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
index b7bd4ef9c0db..4a6bdaefa42f 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
@@ -547,14 +547,11 @@ static int imx1_pinctrl_parse_functions(struct device_node *np,
*/
static bool imx1_pinctrl_dt_is_flat_functions(struct device_node *np)
{
- struct device_node *function_np;
- struct device_node *pinctrl_np;
-
- for_each_child_of_node(np, function_np) {
+ for_each_child_of_node_scoped(np, function_np) {
if (of_property_present(function_np, "fsl,pins"))
return true;
- for_each_child_of_node(function_np, pinctrl_np) {
+ for_each_child_of_node_scoped(function_np, pinctrl_np) {
if (of_property_present(pinctrl_np, "fsl,pins"))
return false;
}
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260523-pinctrl-imx-b198f8391abf
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-16 12:53 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260610153329.937833-2-v@baodeep.com>
On Wed, 10 Jun 2026 17:32:10 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
Sigh... Ok let's try this. This limits users of shared pins to using them from
process context exclusively but maybe there is in fact no need to do it from
atomic context. After all: bit-banging can't work if we're using the voting
mechanism.
>
> drivers/gpio/gpio-shared-proxy.c | 43 +++++++-------------------------
> drivers/gpio/gpiolib-shared.c | 9 ++-----
> drivers/gpio/gpiolib-shared.h | 31 +++++++++--------------
> 3 files changed, 23 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
> index 6941e4be6cf1..856e5b9d6163 100644
> --- a/drivers/gpio/gpio-shared-proxy.c
> +++ b/drivers/gpio/gpio-shared-proxy.c
> @@ -109,7 +109,7 @@ static void gpio_shared_proxy_free(struct gpio_chip *gc, unsigned int offset)
>
> if (proxy->voted_high) {
> ret = gpio_shared_proxy_set_unlocked(proxy,
> - shared_desc->can_sleep ? gpiod_set_value_cansleep : gpiod_set_value, 0);
> + gpiod_set_value_cansleep, 0);
> if (ret)
> dev_err(proxy->dev,
> "Failed to unset the shared GPIO value on release: %d\n", ret);
> @@ -222,13 +222,6 @@ static int gpio_shared_proxy_direction_output(struct gpio_chip *gc,
> return gpio_shared_proxy_set_unlocked(proxy, gpiod_direction_output, value);
> }
>
> -static int gpio_shared_proxy_get(struct gpio_chip *gc, unsigned int offset)
> -{
> - struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
> -
> - return gpiod_get_value(proxy->shared_desc->desc);
> -}
> -
> static int gpio_shared_proxy_get_cansleep(struct gpio_chip *gc,
> unsigned int offset)
> {
> @@ -237,29 +230,15 @@ static int gpio_shared_proxy_get_cansleep(struct gpio_chip *gc,
> return gpiod_get_value_cansleep(proxy->shared_desc->desc);
> }
>
> -static int gpio_shared_proxy_do_set(struct gpio_shared_proxy_data *proxy,
> - int (*set_func)(struct gpio_desc *desc, int value),
> - int value)
> -{
> - guard(gpio_shared_desc_lock)(proxy->shared_desc);
> -
> - return gpio_shared_proxy_set_unlocked(proxy, set_func, value);
> -}
> -
> -static int gpio_shared_proxy_set(struct gpio_chip *gc, unsigned int offset,
> - int value)
> -{
> - struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
> -
> - return gpio_shared_proxy_do_set(proxy, gpiod_set_value, value);
> -}
> -
> static int gpio_shared_proxy_set_cansleep(struct gpio_chip *gc,
> unsigned int offset, int value)
> {
> struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
>
> - return gpio_shared_proxy_do_set(proxy, gpiod_set_value_cansleep, value);
> + guard(gpio_shared_desc_lock)(proxy->shared_desc);
> +
> + return gpio_shared_proxy_set_unlocked(proxy, gpiod_set_value_cansleep,
> + value);
> }
>
> static int gpio_shared_proxy_get_direction(struct gpio_chip *gc,
> @@ -302,20 +281,16 @@ static int gpio_shared_proxy_probe(struct auxiliary_device *adev,
> gc->label = dev_name(dev);
> gc->parent = dev;
> gc->owner = THIS_MODULE;
> - gc->can_sleep = shared_desc->can_sleep;
> + /* Always a sleeping gpiochip: see the lock comment in gpiolib-shared.h. */
> + gc->can_sleep = true;
>
> gc->request = gpio_shared_proxy_request;
> gc->free = gpio_shared_proxy_free;
> gc->set_config = gpio_shared_proxy_set_config;
> gc->direction_input = gpio_shared_proxy_direction_input;
> gc->direction_output = gpio_shared_proxy_direction_output;
> - if (gc->can_sleep) {
> - gc->set = gpio_shared_proxy_set_cansleep;
> - gc->get = gpio_shared_proxy_get_cansleep;
> - } else {
> - gc->set = gpio_shared_proxy_set;
> - gc->get = gpio_shared_proxy_get;
> - }
> + gc->set = gpio_shared_proxy_set_cansleep;
> + gc->get = gpio_shared_proxy_get_cansleep;
> gc->get_direction = gpio_shared_proxy_get_direction;
> gc->to_irq = gpio_shared_proxy_to_irq;
>
> diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
> index de72776fb154..495bd3d0ddf0 100644
> --- a/drivers/gpio/gpiolib-shared.c
> +++ b/drivers/gpio/gpiolib-shared.c
> @@ -627,8 +627,7 @@ static void gpio_shared_release(struct kref *kref)
>
> shared_desc = entry->shared_desc;
> gpio_device_put(shared_desc->desc->gdev);
> - if (shared_desc->can_sleep)
> - mutex_destroy(&shared_desc->mutex);
> + mutex_destroy(&shared_desc->mutex);
> kfree(shared_desc);
> entry->shared_desc = NULL;
> }
> @@ -659,11 +658,7 @@ gpiod_shared_desc_create(struct gpio_shared_entry *entry)
> }
>
> shared_desc->desc = &gdev->descs[entry->offset];
> - shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> - if (shared_desc->can_sleep)
> - mutex_init(&shared_desc->mutex);
> - else
> - spin_lock_init(&shared_desc->spinlock);
> + mutex_init(&shared_desc->mutex);
>
> return shared_desc;
> }
> diff --git a/drivers/gpio/gpiolib-shared.h b/drivers/gpio/gpiolib-shared.h
> index 15e72a8dcdb1..5c725118b1af 100644
> --- a/drivers/gpio/gpiolib-shared.h
> +++ b/drivers/gpio/gpiolib-shared.h
> @@ -6,7 +6,6 @@
> #include <linux/cleanup.h>
> #include <linux/lockdep.h>
> #include <linux/mutex.h>
> -#include <linux/spinlock.h>
>
> struct gpio_device;
> struct gpio_desc;
> @@ -42,35 +41,29 @@ static inline int gpio_shared_add_proxy_lookup(struct device *consumer,
>
> struct gpio_shared_desc {
> struct gpio_desc *desc;
> - bool can_sleep;
> unsigned long cfg;
> unsigned int usecnt;
> unsigned int highcnt;
> - union {
> - struct mutex mutex;
> - spinlock_t spinlock;
> - };
> + struct mutex mutex; /* serializes all proxy operations on this descriptor */
> };
>
> struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev);
>
> +/*
> + * Under this lock the proxy may call gpiod_set_config()/gpiod_direction_*(),
> + * which can reach pinctrl paths that take a mutex (e.g. gpiod_set_config() ->
> + * gpiochip_generic_config() -> pinctrl_gpio_set_config()), independent of the
> + * underlying chip's can_sleep. A spinlock would run that sleeping call from
> + * atomic context, so the descriptor lock must be a mutex and the proxy
> + * gpiochip is therefore sleeping (can_sleep=true).
> + */
> DEFINE_LOCK_GUARD_1(gpio_shared_desc_lock, struct gpio_shared_desc,
> - if (_T->lock->can_sleep)
> - mutex_lock(&_T->lock->mutex);
> - else
> - spin_lock_irqsave(&_T->lock->spinlock, _T->flags),
> - if (_T->lock->can_sleep)
> - mutex_unlock(&_T->lock->mutex);
> - else
> - spin_unlock_irqrestore(&_T->lock->spinlock, _T->flags),
> - unsigned long flags)
> + mutex_lock(&_T->lock->mutex),
> + mutex_unlock(&_T->lock->mutex))
Just drop these wrappers altogether then, let's open-code mutex locking in
the proxy.
>
> static inline void gpio_shared_lockdep_assert(struct gpio_shared_desc *shared_desc)
> {
> - if (shared_desc->can_sleep)
> - lockdep_assert_held(&shared_desc->mutex);
> - else
> - lockdep_assert_held(&shared_desc->spinlock);
> + lockdep_assert_held(&shared_desc->mutex);
Same here, move it to the proxy.
> }
>
> #endif /* __LINUX_GPIO_SHARED_H */
> --
> 2.54.0
>
>
>
Bart
^ permalink raw reply
* Re: [PATCH RFC 1/2] pinctrl: qcom: eliza: Fix HDMI_RCV_DET function slot
From: Konrad Dybcio @ 2026-06-16 13:10 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio,
linux-kernel
In-Reply-To: <U4Ou8tzXQzd_9s7-BdFTARdlOQdxQ2P7o9Lx8kaqvvbPd-Jm16U26MFqvYUFkEGiOZ_yhO0GNref9oLmgbtMe9_8yUodoRODhYxWH_0c2Z0=@pm.me>
On 6/8/26 8:41 PM, Alexander Koskovich wrote:
> On Monday, June 8th, 2026 at 7:55 AM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
>
>> On 5/28/26 7:24 PM, Alexander Koskovich wrote:
>>> On Thursday, April 23rd, 2026 at 7:08 PM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
>>>
>>>> On 4/23/26 6:51 AM, Alexander Koskovich wrote:
>>>>> The hdmi_rcv_det function was placed at alt function slot 2, but the
>>>>> correct mux value for this function on GPIO 19 is slot 3. Move it
>>>>> accordingly and leave slot 2 unassigned.
>>>>
>>>> No, 2 is the desired one per docs
>>>>
>>>> 0 -> GPIO
>>>> 1 -> QUP2_SE5_L3
>>>> 2 -> HDMI_RCV_DET
>>>
>>> Is it possible that CQ7790S is a special case? The pin assignment I have for it
>>> here is:
>>>
>>> 0 -> GPIO
>>> 1 -> QUP2_SE5_L3
>>> 2 -> N/A
>>> 3 -> GP_PDM_MIRA[0]/HDMI_RCV_DET
>>
>> I was reassured that my source has the latest information
>>
>> For reference, does your reference doc have any 80-xxxx-xx-like number?
>
> Yes, the document I am referencing is 80-97791-1A, though since you've double
> checked likely just means this is is incorrect?
Yes, I got confirmation from 2 separate people
Konrad
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Rob Herring @ 2026-06-16 13:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260615071836.362883-10-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:15AM +0200, Luca Leonardo Scorcia wrote:
> From: Val Packett <val@packett.cool>
>
> Add the dts to be included by all boards using the MT6392 PMIC,
> providing support for regulator, keys, pinctrl and RTC.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
> 1 file changed, 75 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
Nothing is using this so it is a dead file that doesn't get tested.
Rob
^ permalink raw reply
* Re: [PATCH v7 0/9] Add support for MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:42 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-1-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:06AM +0200, Luca Leonardo Scorcia wrote:
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
>
> This series is mostly based around patches submitted a couple
> years ago by Fabien Parent and not merged and from Val Packett's
> submission from Jan 2025 that included extra cleanups, fixes, and a
> new dtsi file similar to ones that exist for other PMICs. Some
> comments weren't addressed and the series was ultimately not merged.
>
> These patches enable four functions: keys, regulator, pinctrl and RTC.
> Mono speaker amp will follow later as I need to work further on the
> audio codec.
>
> I added a handful of device tree improvements to fix some dtbs_check
> errors, added support for the pinctrl device and addressed the comments
> from last year's reviews.
>
> Please note that patch 0006 and 0008 depend on patch 0005 as they need the
> registers.h file, but belong to different driver areas. I'm not sure if
> I'm supposed to squash them even if they belong to different driver
> areas of if it's fine like this. Any advice is welcome.
>
> The series has been tested on Xiaomi Mi Smart Clock X04G and on the
> Lenovo Smart Clock 2 CD-24502F.
>
> Changes in v7:
> - Removed patch 0008 dependency on patch 0003.
> - Reintroduced the regulator driver. In earlier revisions of this series,
> it was proposed to remove the dedicated compatible for the regulator
> device [3]. The driver does not use actually it, but it is not possible
> at this time to remove it from the bindings since it's a required
> property.
>
> Making the regulator-required property conditional was NACKed in [5],
> with the suggestion to create a separate binding altogether for devices
> that do not require the compatible property. I tried implementing this,
> but since the parent device needs to be declared as compatible with
> mt6323, it leads to a warning in dt_binding_check since mt6323 would
> be declared as a compatible in both mt6392 and mt6397.
>
> In the end the only regulator driver from the mt6397 documentation that
> still declares an of_match is mt6397-regulator and it does not seem
> to be necessary, so it should be possible to remove it and make the
> regulator compatible optional for all regulators, but that change would
> probably deserve its own separate patch series.
I don't really follow what the issue is here, but compatible should
never be optional.
Rob
^ permalink raw reply
* Re: [PATCH v7 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Rob Herring (Arm) @ 2026-06-16 13:43 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Lee Jones, Mark Brown, linux-input, linux-pm, Louis-Alexis Eyraud,
linux-kernel, Julien Massot, Macpaul Lin, Krzysztof Kozlowski,
Liam Girdwood, Linus Walleij, Conor Dooley, Dmitry Torokhov,
Akari Tsuyukusa, AngeloGioacchino Del Regno, Chen Zhong,
Fabien Parent, linux-mediatek, Val Packett, linux-arm-kernel,
Matthias Brugger, devicetree, Sean Wang, Sen Chu, linux-gpio
In-Reply-To: <20260615071836.362883-2-l.scorcia@gmail.com>
On Mon, 15 Jun 2026 09:16:07 +0200, Luca Leonardo Scorcia wrote:
> Describe the MT6392 PMIC and its RTC and regulator devices. This device
> is mostly based on MT6323 with some similarities to MT6397 and is usually
> found on boards using the MT8516/MT8167 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl
From: Konrad Dybcio @ 2026-06-16 13:44 UTC (permalink / raw)
To: contact, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Guru Das Srinagesh, Linus Walleij, Rob Clark, Kees Cook,
Tony Luck, Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel
In-Reply-To: <20260609-mainline-send-v1-sending-v4-2-83768fbf404d@alex-min.fr>
On 6/9/26 10:13 AM, Alexandre MINETTE via B4 Relay wrote:
> From: Alexandre MINETTE <contact@alex-min.fr>
>
> pinctrl consumers can request states while the pinctrl core enables the
> controller. On Qualcomm pinctrl drivers this can happen before the SoC
> function list has been registered, which leaves the function table
> incomplete during state lookup.
>
> On APQ8064 this can fail while claiming pinctrl hogs:
>
> apq8064-pinctrl 800000.pinctrl: invalid function ps_hold in map table
> apq8064-pinctrl 800000.pinctrl: error claiming hogs: -22
> apq8064-pinctrl 800000.pinctrl: could not claim hogs: -22
>
> Register Qualcomm pinctrl with devm_pinctrl_register_and_init(), add the
> SoC pin functions, and only then enable the pinctrl device.
>
> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 6/6] ARM: dts: qcom: Add Samsung Galaxy S4
From: Konrad Dybcio @ 2026-06-16 13:45 UTC (permalink / raw)
To: contact, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Guru Das Srinagesh, Linus Walleij, Rob Clark, Kees Cook,
Tony Luck, Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel
In-Reply-To: <20260609-mainline-send-v1-sending-v4-6-83768fbf404d@alex-min.fr>
On 6/9/26 10:13 AM, Alexandre MINETTE via B4 Relay wrote:
> From: Alexandre MINETTE <contact@alex-min.fr>
>
> Add a device tree for the Samsung Galaxy S4, codenamed jflte.
>
> This has been tested on a Samsung Galaxy S4 GT-I9505. The initial support
> covers UART, USB peripheral mode with USB networking, the front LED and
> the physical buttons.
>
> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v7 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Val Packett, Julien Massot,
Louis-Alexis Eyraud, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-4-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:09AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 234 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 258 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..197041df4ba1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,234 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +description:
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
> +
> + vproc-supply:
> + description: Supply for buck regulator vproc
> + vcore-supply:
> + description: Supply for buck regulator vcore
> + vsys-supply:
> + description: Supply for buck regulator vsys
> + avddldo-supply:
> + description: |
Don't need '|' if no formatting to preserve. Elsewhere too.
> + Supply for AVDD LDOs (vm, vio18, vcn18, vcamd, vcamio). According to the data sheet
> + this is an internal supply derived from vsys.
> + ldo1-supply:
> + description: Supply for LDOs group 1 (vaud28, vxo22, vaud22, vadc18, vcama, vrtc)
> + ldo2-supply:
> + description: Supply for LDOs group 2 (vcn35, vio28, vmc, vmch, vefuse, vdig18)
> + ldo3-supply:
> + description: Supply for LDOs group 3 (vusb, vemc3v3, vcamaf, vgp1, vgp2, vm25)
> +
> +patternProperties:
> + "^v(core|proc|sys)$":
> + description: Buck regulators
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
minItems: 1
maxItems: 2
? Because if there are only 2 modes, can't have more entries than that,
right? Though wouldn't 2 entries be the same as no property present
because I would assume the default is all modes. I shouldn't have to
assume though.
> + unevaluatedProperties: false
Place this after $ref. Easier to read than after indented blocks.
> +
> + "^v(adc18|camio|cn18|io18|xo22|m25|aud28|io28|rtc|usb)$":
> + description: LDOs with fixed output and mode setting
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^v(cama|dig18)$":
> + description: LDOs with fixed output without mode setting
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> + "^v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
> + description: LDOs with adjustable output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes: false
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + regulators {
> + compatible = "mediatek,mt6392-regulator";
Drop the example. Put 1 complete example in the MFD schema rather than
incomplete examples.
Rob
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-06-16 15:32 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260616133918.GA2335264-robh@kernel.org>
> > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
>
> Nothing is using this so it is a dead file that doesn't get tested.
Hi, it's not referenced as the dtsi inclusion was removed in the
original patch from 2019 for an easier merging of support for mt8516
pumpkin boards [1][2].
If you prefer in the next revision I can add another patch to readd it
to the existing pumpkin board.
I am working on a few boards with MT8167 (Xiaomi Mi Smart Clock,
Lenovo Smart Clock 2, Sony Playstation Classic) that reference it and
these have been used to test it locally too.
[1] https://lore.kernel.org/linux-mediatek/20190323211612.860-25-fparent@baylibre.com/
[2] https://lore.kernel.org/linux-mediatek/20200229170401.1287324-2-fparent@baylibre.com/
Thank you
Luca
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Conor Dooley @ 2026-06-16 15:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+4EquYcUHEnoq0N_p7vCmDpPONEhVrmAfO1eX_RNMYbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
On Mon, Jun 15, 2026 at 07:09:39PM +0200, Luca Leonardo Scorcia wrote:
> Hi,
> yes, sorry about that, series v6 has been superseded by v7 (I replied
> to the thread and marked it as archived in patchwork, please let me
> know if I have to do something else to mark it as obsolete).
> Sashiko was correct, the regulators node is required for this device.
I have no idea what regulator node you're referring to here or what
patchwork. Please don't delete context when you reply.
If it's the devicetree patchwork I don't you need to do anything.
> Sashiko also has suggestions for v7, a few pre existing issues and a
> few nits here and there but some are actual improvements. One bit that
> caught my eye is the use of the modeset register in the
> mt6392_ldo_get_mode function. I have to double check that with the
> data sheet and the android kernel sources. Not sure if I can do that
> before next week though.
>
> Is there any way I can trigger a Sashiko review before sending patches
> to the ML?
I don't know sorry.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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