* [RFC] pinctrl: ingenic: impossible MACH_* guards can drop OF match data
From: Pengpeng Hou @ 2026-06-25 6:09 UTC (permalink / raw)
To: Paul Cercueil, Linus Walleij
Cc: linux-mips, linux-gpio, linux-kernel, Pengpeng Hou
Hi,
while auditing conditional data-provider paths, I noticed that
drivers/pinctrl/pinctrl-ingenic.c still derives some SoC descriptor exposure
from IS_ENABLED(CONFIG_MACH_*) style conditions whose corresponding Kconfig
symbols do not appear to exist in the current Ingenic Kconfig universe.
This looks like a data-symbol legality issue rather than a simple cleanup:
the OF match table .data entries carry SoC-specific pinctrl descriptors. If
the guard can never be true, a compatible string can lose the intended
descriptor provider even though the descriptor is still present in source.
I am not sending a patch yet because the correct policy is not obvious. The
possible directions include:
1. remove impossible MACH_* gates from the OF match data;
2. restore current Kconfig symbols for the intended SoC families;
3. split unsupported legacy SoCs from supported descriptor exposure; or
4. keep the gates and document that these descriptors are intentionally not
exposed.
Could you confirm which direction matches the current Ingenic pinctrl support
policy?
This is static source/Kconfig analysis only. I have not tested the affected
hardware.
Thanks,
Pengpeng
^ permalink raw reply
* Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Andy Shevchenko @ 2026-06-25 6:08 UTC (permalink / raw)
To: Marco Scardovi
Cc: w_armin, bnatikar, brgl, johannes.goede, linusw, linux-acpi,
linux-gpio, linux-kernel, mario.limonciello, westeri
In-Reply-To: <fDMIXYjSRMSLJNqjRmWA7Q@disroot.org>
On Wed, Jun 24, 2026 at 07:49:21PM +0200, Marco Scardovi wrote:
> Hi guys,
>
> I'm feeling like a complete idiot right now and have to make a
> mea culpa for it.
>
> I didn't notice that [1] wasn't still merged into the 7.1 stable. I took it
> for granted as it was on linux-next since april and newer patches made by me
> were already merged on stable. It sounded strange that a patch made that
> was working 2 months ago to stop working suddenly and now I know why.
>
> I'm truly sorry for all the noise: you can skip on it.
Okay, so this thread clarified that Mario's patch fixed your issue and any
other model that is affected.
Hence, no patch from _this_ thread is going to be applied.
If it's not the case, speak that up!
> [1] https://lore.kernel.org/linux-gpio/20260429025247.1372984-1-mario.limonciello@amd.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
From: Sneh Mankad @ 2026-06-25 4:33 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: <d9e778ea-8a67-4576-9c96-9cfd859a266a@oss.qualcomm.com>
[...]
>
> This is a much better commit message, thank you!
>
> One question remains - should we set skip_wake_irqs for MPM too?
>
> My understanding is that no, since the MPM HW is simpler and doesn't
> have a register for acking IRQs, so we need to do it from the recipient
> (TLMM). Is that right?
>
Yes that is correct. skip_wake_irqs is set for PDC since PDC can handle interrupts
during active time and SoC sleep time both, so any wakeup capable interrupt source can
be handled via PDC at all times. However MPM can only handle interrupts when
SoC is in low power mode, it does not have the functionality to detect them when SoC
is active. skip_wake_irqs differentiates this behaviour.
Thanks,
Sneh
^ permalink raw reply
* Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Marco Scardovi @ 2026-06-24 17:49 UTC (permalink / raw)
To: w_armin
Cc: andriy.shevchenko, bnatikar, brgl, johannes.goede, linusw,
linux-acpi, linux-gpio, linux-kernel, mario.limonciello,
scardracs, westeri
In-Reply-To: <f51df47c-0523-41ee-9e7d-0aa0177065e7@gmx.de>
Hi guys,
I'm feeling like a complete idiot right now and have to make a
mea culpa for it.
I didn't notice that [1] wasn't still merged into the 7.1 stable. I took it
for granted as it was on linux-next since april and newer patches made by me
were already merged on stable. It sounded strange that a patch made that
was working 2 months ago to stop working suddenly and now I know why.
I'm truly sorry for all the noise: you can skip on it.
[1] https://lore.kernel.org/linux-gpio/20260429025247.1372984-1-mario.limonciello@amd.com/
^ permalink raw reply
* Re: [PATCH 1/1] x86/vm86: fix vm86 struct leak on copy_from_user() failure
From: Borislav Petkov @ 2026-06-24 17:40 UTC (permalink / raw)
To: fffsqian
Cc: Thomas Gleixner, Ingo Molnar, Dave Hansen, x86, hpa, Kees Cook,
Andy Lutomirski, Brian Gerst, linux-gpio, Qingshuang Fu
In-Reply-To: <20260624092629.271618-1-fffsqian@163.com>
On Wed, Jun 24, 2026 at 05:26:29PM +0800, fffsqian@163.com wrote:
> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
> index b4c1cabc7a4b..cde077f2c97e 100644
> --- a/arch/x86/kernel/vm86_32.c
> +++ b/arch/x86/kernel/vm86_32.c
> @@ -202,7 +202,8 @@ static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
> struct vm86 *vm86 = tsk->thread.vm86;
> struct kernel_vm86_regs vm86regs;
> struct pt_regs *regs = current_pt_regs();
> - unsigned long err = 0;
> + bool newly_allocated = false;
What for?
Take a look at kfree()'s implementation.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH libgpiod] build: fix dependencies for generated files
From: Bartosz Golaszewski @ 2026-06-24 15:22 UTC (permalink / raw)
To: Linus Walleij, Vincent Fazio, Kent Gibson, Luca Weiss,
Bartosz Golaszewski
Cc: linux-gpio, brgl
In-Reply-To: <20260623-dbus-meson-deps-v1-1-b37604ecce3f@oss.qualcomm.com>
On Tue, 23 Jun 2026 13:40:17 +0200, Bartosz Golaszewski wrote:
> Depending on the timing, we may try to build generated files that don't
> exist yet. Generated .c and .h files need to be included in the sources
> of the dependencies that need them so that they get generated before we
> try to build them. Fix issues observed in dbus and GLib bindings.
>
>
Applied, thanks!
[1/1] build: fix dependencies for generated files
https://git.kernel.org/brgl/c/7d7b07738885d051a28bdfb5025c8eb73cdf23f8
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH libgpiod 0/4] build: fix problems with meson build option guards
From: Bartosz Golaszewski @ 2026-06-24 15:22 UTC (permalink / raw)
To: Linus Walleij, Vincent Fazio, Kent Gibson, Bartosz Golaszewski
Cc: brgl, linux-gpio
In-Reply-To: <20260622-build-catch2-issue-v1-0-be95e28f310b@oss.qualcomm.com>
On Mon, 22 Jun 2026 15:58:06 +0200, Bartosz Golaszewski wrote:
> This series fixes several issues with how meson handles build options
> for libgpiod. Most notably: the problem with catch2 becoming a
> hard-dependency if tests and C++ bindings are merely "allowed".
>
>
Applied, thanks!
[1/4] build: don't make catch2 mandatory when C++ bindings and tests are enabled
https://git.kernel.org/brgl/c/7edfd6b7746c612195765649523ef6618b9eb37f
[2/4] build: include all test dependencies in the tests_enabled gate
https://git.kernel.org/brgl/c/372a5da1d8fc408bdac362d22eb7396e74519eab
[3/4] build: fix incomplete dependency gate for glib bindings
https://git.kernel.org/brgl/c/829eebf6a085141314bb80522b6678df58fc9d4b
[4/4] build: fix incomplete dependency gate for introspection
https://git.kernel.org/brgl/c/1f38ba3928eb16acf85512ce1767226ce5413425
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Armin Wolf @ 2026-06-24 14:42 UTC (permalink / raw)
To: Hans de Goede, Marco Scardovi, bnatikar
Cc: andriy.shevchenko, brgl, linusw, linux-acpi, linux-gpio,
linux-kernel, mario.limonciello, westeri
In-Reply-To: <9237988a-2f5a-4c4e-8586-12899957bfea@oss.qualcomm.com>
Am 21.06.26 um 13:00 schrieb Hans de Goede:
> Hi Marco,
>
> On 17-Jun-26 20:50, Marco Scardovi wrote:
>> Hi Basavaraj,
>>
>> Thank you for your review: this is the v2 with the rewording as requested.
>>
>> Changes in v2:
>> - Reworded the commit message and the code comment to explain the actual
>> boot-time replay mechanism as suggested by Basavaraj.
>> - Explicitly noted that the touchpad itself is driven by i2c-hid and functions
>> normally, and that the ACPI event handler is preserved for post-boot events.
>> - Rebased against linux-next-20260616
>>
>> Marco Scardovi (1):
>> gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
> Have you tried adding this patch to your kernel instead of adding a quirk? :
>
> https://lore.kernel.org/linux-gpio/20260429025247.1372984-1-mario.limonciello@amd.com/
>
> This modifies the code which does an initial sync of edge-run ACPI GPIO
> interrupt event handlers to match Windows and to skip it in certain
> circumstances.
>
> If that does not help, we should wait for Armin to get a chance to check
> your DSDT to see if the magic _DSM which inverts the polarity check for
> the initial sync run is there.
I checked the ACPI tables, and the _DSM is missing. However i think that the
affected GPIO is actually declared as being edge-triggered, so the aforementioned
patch from mario should fix the problem without requiring another quirk entry.
Thanks,
Armin Wolf
>
> By matching what Windows this we can hopefully fix this for a whole bunch
> of devices rather then having to rely on per model quirks.
>
> Regards,
>
> Hans
>
>
^ permalink raw reply
* Re: [PATCH v2] pinctrl: qcom: Avoid assigning unused private context in test cases
From: Linus Walleij @ 2026-06-24 13:28 UTC (permalink / raw)
To: Sneh Mankad, Bartosz Golaszewski
Cc: Bjorn Andersson, Yuanjie Yang, linux-arm-msm, linux-gpio,
linux-kernel
In-Reply-To: <20260610-tlmm_test_changes-v2-1-f34536da4717@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 8:17 AM Sneh Mankad
<sneh.mankad@oss.qualcomm.com> wrote:
> tlmm_test_rising_while_disabled() sets thread_op_remain to 10, but this
> variable is only used by the threaded IRQ handler to control the number
> of GPIO pin toggles. Since tlmm_test_rising_while_disabled() does not
> register a threaded IRQ handler, the assignment is never used.
>
> Similarly, tlmm_test_high() and tlmm_test_low() set intr_op_remain to 9,
> but the variable is used to denote the IRQ handler the number of times
> GPIO signal has to be toggled from the hard IRQ handler.
>
> Since tlmm_test_high() and tlmm_test_low() themselves toggle the
> signal and do not require the hard IRQ handler to do it, the assignment is
> never used.
>
> Remove the thread_op_remain assignment from
> tlmm_test_rising_while_disabled() and intr_op_remain assignment from
> tlmm_test_high() and tlmm_test_low() test cases.
>
> This does not cause any change in functionality.
>
> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
I don't understand this patch, qcom pinctrl maintainer Bartosz will
decide about it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] gpio: htc-egpio: use managed gpiochip registration
From: Pengpeng Hou @ 2026-06-24 13:18 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Russell King, Philipp Zabel, linux-gpio, linux-kernel,
Pengpeng Hou
egpio_probe() registers each nested gpio_chip with gpiochip_add_data()
but ignores the return value. If one registration fails, probe still
returns success even though one of the chips was not published to
gpiolib.
Use devm_gpiochip_add_data() and fail probe if any chip registration
fails. This lets devres unwind already registered chips and prevents
the driver from publishing a partially initialized device.
Fixes: a1635b8fe59d ("[ARM] 4947/1: htc-egpio, a driver for GPIO/IRQ expanders with fixed input/output pins")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v2:
https://lore.kernel.org/all/20260622153204.72071-1-pengpeng@iscas.ac.cn/
- Add the Fixes tag requested by Bartosz Golaszewski.
drivers/gpio/gpio-htc-egpio.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-htc-egpio.c b/drivers/gpio/gpio-htc-egpio.c
index d15423c718d0..25a4d4494f3c 100644
--- a/drivers/gpio/gpio-htc-egpio.c
+++ b/drivers/gpio/gpio-htc-egpio.c
@@ -268,6 +268,7 @@ static int __init egpio_probe(struct platform_device *pdev)
struct gpio_chip *chip;
unsigned int irq, irq_end;
int i;
+ int ret;
/* Initialize ei data structure. */
ei = devm_kzalloc(&pdev->dev, struct_size(ei, chip, pdata->num_chips), GFP_KERNEL);
@@ -326,7 +327,10 @@ static int __init egpio_probe(struct platform_device *pdev)
chip->base = pdata->chip[i].gpio_base;
chip->ngpio = pdata->chip[i].num_gpios;
- gpiochip_add_data(chip, &ei->chip[i]);
+ ret = devm_gpiochip_add_data(&pdev->dev, chip, &ei->chip[i]);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to register gpiochip %d\n", i);
}
/* Set initial pin values */
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v3] gpio: mvebu: fail probe if gpiochip registration fails
From: Pengpeng Hou @ 2026-06-24 13:16 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Thomas Petazzoni, Jason Cooper, linux-gpio,
linux-kernel, Pengpeng Hou
mvebu_gpio_probe() registers the GPIO chip with
devm_gpiochip_add_data() but ignores the return value. If registration
fails, probe continues and leaves later code operating on a GPIO chip
that was never published to gpiolib.
Return the registration error so the device fails probe cleanly.
Fixes: fefe7b092345 ("gpio: introduce gpio-mvebu driver for Marvell SoCs")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v2:
https://lore.kernel.org/all/20260622153137.69065-1-pengpeng@iscas.ac.cn/
- Add the Fixes tag requested by Bartosz Golaszewski.
drivers/gpio/gpio-mvebu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index c030d1f00abc..689dc6354c2d 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -1221,7 +1221,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
BUG();
}
- devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
+ err = devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
+ if (err)
+ return dev_err_probe(&pdev->dev, err,
+ "failed to register gpiochip\n");
/* Some MVEBU SoCs have simple PWM support for GPIO lines */
if (IS_REACHABLE(CONFIG_PWM)) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v11] PCI: Add support for PCIe WAKE# interrupt
From: Krishna Chaitanya Chundru @ 2026-06-24 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Bjorn Helgaas, Bartosz Golaszewski,
Linus Walleij, Bartosz Golaszewski, Rob Herring, Saravana Kannan,
Linus Walleij
Cc: linux-pm, linux-kernel, linux-pci, linux-gpio, quic_vbadigan,
sherry.sun, driver-core, devicetree, Manivannan Sadhasivam,
Krishna Chaitanya Chundru
According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
two link wakeup mechanisms are defined: Beacon and WAKE#. Beacon is a
hardware-only mechanism and is invisible to software (PCIe r7.0,
Section 4.2.7.8.1). This change adds support for the WAKE# mechanism
in the PCI core.
According to the PCIe specification, multiple WAKE# signals can exist in
a system or each component in the hierarchy could share a single WAKE#
signal. In configurations involving a PCIe switch, each downstream port
(DSP) of the switch may be connected to a separate WAKE# line, allowing
each endpoint to signal WAKE# independently. From figure 5.4 in sec
5.3.3.2, WAKE# can also be terminated at the switch itself. Such topologies
are typically not described in Device Tree, therefore it is out of scope
for this series.
To support this, the WAKE# should be described in the device tree node of
the endpoint/bridge. If all endpoints share a single WAKE# line, then each
endpoint node shall describe the same WAKE# signal or a single WAKE# in
the Root Port node.
In pci_device_add(), PCI framework will search for the WAKE# in device
node. Once found, register for the wake IRQ through
dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with a device
and requests it, but the PM core keeps the IRQ disabled by default. The
IRQ is enabled by the PM core, only when the device is permitted to wake
the system, i.e. during system suspend and after runtime suspend, and
only when device wakeup is enabled.
If the same WAKE# GPIO is described in multiple device tree nodes, only the
first device that successfully registers the wake IRQ will succeed, while
subsequent registrations may fail. This limitation does not affect
functional correctness, since WAKE# is only used to bring the link to D0,
and endpoint-specific wakeup handling is resolved later through
PME detection (PME_EN is set in suspend path by PCI core by default).
When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume() to
bring the device back to an active power state, such as transitioning from
D3cold to D0. Once the device is active and the link is usable, the
endpoint may generate a PME, which is then handled by the PCI core through
PME polling or the PCIe PME service driver to complete the wakeup of the
endpoint.
WAKE# is added in dts schema and merged based on below links.
Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
Link: https://github.com/devicetree-org/dt-schema/pull/170
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
PCIe WAKE# interrupt is needed for bringing back PCIe device state from
D3cold to D0.
This is pending from long time, there was two attempts done previously to
add WAKE# support[1], [2]. Those series tried to add support for legacy
interrupts along with WAKE#. Legacy interrupts are already available in
the latest kernel and we can ignore them. For the wake IRQ the series is
trying to use interrupts property define in the device tree.
WAKE# is added in dts schema and merged based on this patch.
https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
[1]: https://lore.kernel.org/all/b2b91240-95fe-145d-502c-d52225497a34@nvidia.com/T/
[2]: https://lore.kernel.org/all/20171226023646.17722-1-jeffy.chen@rock-chips.com/
---
Changes in v11:
- Add device_init_wakeup() as client driver is not expected to enable
bridge dev wakeup capability.
- Link to v10: https://patch.msgid.link/20260511-wakeirq_support-v10-0-c10af9c9eb8c@oss.qualcomm.com
Changes in v10:
- As sashiko pointed, shared irq has plenty of race conditions.
- So we are moving away from the shared IRQ patch and registering with
dedicated wake irq only, as part of wake irq the link will come to D0
as the parent controller driver will be runtime resume first and then
pme service will kick in wake up correct endpoint driver.
- Removed device_init_wakeup() since it enabling wakeup explicitly,
which is not intended as this should be set by endpoint driver only.
- Link to v9: https://lore.kernel.org/r/20260403-wakeirq_support-v9-0-1cbecf3b58d7@oss.qualcomm.com
Changes in v9:
- Call device_init_wakeup() only if
dev_pm_set_dedicated_shared_wake_irq() succeeds (Mani).
- Change the IRQ_TYPE from IRQ_TYPE_EDGE_FALLING to IRQ_TYPE_LEVEL_LOW (Mani).
- Link to v8: https://lore.kernel.org/r/20260313-wakeirq_support-v8-0-48a0a702518a@oss.qualcomm.com
Changes in v8:
- Moved the stub functions under CONFIG_OF_IRQ(mani).
- Added the description of how dev_pm_set_dedicated_shared_wake_irq()
works.
- Link to v7: https://lore.kernel.org/r/20260218-wakeirq_support-v7-0-0d4689830207@oss.qualcomm.com
Changes in v7:
- Updated the commit text (Mani).
- Couple of nits like using pci_err instead of dev_err,
use platform_pci_configure_wake(), platform_pci_remove_wake() instead
of calling directly calling pci_configure_of_wake_gpio() & pci_remove_of_wake_gpio() etc (Mani).
- Add a new fwnode_gpiod_get() API that wraps fwnode_gpiod_get_index(..0..), similar to
devm_fwnode_gpiod_get() (Mani).
- Link to v6: https://lore.kernel.org/r/20251127-wakeirq_support-v6-0-60f581f94205@oss.qualcomm.com
Changes in v6:
- Change the name to dev_pm_set_dedicated_shared_wake_irq() and make the
changes pointed by (Rafael).
- Link to v5: https://lore.kernel.org/r/20251107-wakeirq_support-v5-0-464e17f2c20c@oss.qualcomm.com
Changes in v5:
- Enable WAKE# irq only when there is wake -gpios defined in its device
tree node (Bjorn).
- For legacy bindings for direct atach check in root port if we haven't
find the wake in the endpoint node.
- Instead of hooking wake in driver bound case, do it in the framework
irrespective of the driver state (Bjorn).
- Link to v4: https://lore.kernel.org/r/20250801-wake_irq_support-v4-0-6b6639013a1a@oss.qualcomm.com
Changes in v4:
- Move wake from portdrv to core framework to endpoint (Bjorn).
- Added support for multiple WAKE# case (Bjorn). But traverse from
endpoint upstream port to root port till you get WAKE#. And use
IRQF_SHARED flag for requesting interrupts.
- Link to v3: https://lore.kernel.org/r/20250605-wake_irq_support-v3-0-7ba56dc909a5@oss.qualcomm.com
Changes in v3:
- Update the commit messages, function names etc as suggested by Mani.
- return wake_irq if returns error (Neil).
- Link to v2: https://lore.kernel.org/r/20250419-wake_irq_support-v2-0-06baed9a87a1@oss.qualcomm.com
Changes in v2:
- Move the wake irq teardown after pcie_port_device_remove
and move of_pci_setup_wake_irq before pcie_link_rcec (Lukas)
- teardown wake irq in shutdown also.
- Link to v1: https://lore.kernel.org/r/20250401-wake_irq_support-v1-0-d2e22f4a0efd@oss.qualcomm.com
To: Bjorn Helgaas <bhelgaas@google.com>
To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
Cc: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
drivers/pci/of.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci.c | 11 ++++++++
drivers/pci/pci.h | 2 ++
drivers/pci/probe.c | 2 ++
drivers/pci/remove.c | 1 +
include/linux/of_pci.h | 6 ++++
include/linux/pci.h | 2 ++
7 files changed, 100 insertions(+)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 8b18c4ba845c..0f5effe1d702 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -7,6 +7,7 @@
#define pr_fmt(fmt) "PCI: OF: " fmt
#include <linux/cleanup.h>
+#include <linux/gpio/consumer.h>
#include <linux/irqdomain.h>
#include <linux/kernel.h>
#include <linux/pci.h>
@@ -15,6 +16,7 @@
#include <linux/of_address.h>
#include <linux/of_pci.h>
#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
#include "pci.h"
#ifdef CONFIG_PCI
@@ -586,6 +588,80 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
return irq_create_of_mapping(&oirq);
}
EXPORT_SYMBOL_GPL(of_irq_parse_and_map_pci);
+
+static void pci_configure_wake_irq(struct pci_dev *pdev, struct gpio_desc *wake)
+{
+ int ret, wake_irq;
+
+ wake_irq = gpiod_to_irq(wake);
+ if (wake_irq < 0) {
+ pci_err(pdev, "Failed to get wake irq: %d\n", wake_irq);
+ return;
+ }
+
+ /*
+ * dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with the
+ * device and requests it, but the PM core keeps it disabled by default.
+ * The IRQ is enabled only when the device is allowed to wake the system
+ * (during system suspend and after runtime suspend), and only if device
+ * wakeup is enabled.
+ *
+ * When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume()
+ * to bring the device back to an active power state (e.g. from D3cold to D0).
+ * Once the device is active and the link is usable, the endpoint may signal
+ * a PME, which is then handled by the PCI core (either via PME polling or the
+ * PCIe PME service driver) to wakeup particular endpoint.
+ */
+ ret = dev_pm_set_dedicated_wake_irq(&pdev->dev, wake_irq);
+ if (ret < 0) {
+ pci_err(pdev, "Failed to set WAKE# IRQ: %d\n", ret);
+ return;
+ }
+
+ ret = irq_set_irq_type(wake_irq, IRQ_TYPE_LEVEL_LOW);
+ if (ret < 0) {
+ dev_pm_clear_wake_irq(&pdev->dev);
+ pci_err(pdev, "Failed to set irq_type: %d\n", ret);
+ return;
+ }
+
+ device_init_wakeup(&pdev->dev, true);
+}
+
+void pci_configure_of_wake_gpio(struct pci_dev *dev)
+{
+ struct device_node *dn = pci_device_to_OF_node(dev);
+ struct gpio_desc *gpio;
+
+ if (!dn)
+ return;
+ /*
+ * fwnode_gpiod_get() may fail with -EBUSY (e.g. shared WAKE#), but the
+ * actual WAKE# trigger from the device would still work and the host
+ * controller driver will enable power to the topology.
+ *
+ * -EPROBE_DEFER cannot be propagated here since pci_device_add() has no
+ * retry mechanism.
+ */
+ gpio = fwnode_gpiod_get(of_fwnode_handle(dn), "wake", GPIOD_IN, NULL);
+ if (!IS_ERR(gpio)) {
+ dev->wake = gpio;
+ pci_configure_wake_irq(dev, gpio);
+ }
+}
+
+void pci_remove_of_wake_gpio(struct pci_dev *dev)
+{
+ struct device_node *dn = pci_device_to_OF_node(dev);
+
+ if (!dn)
+ return;
+
+ device_init_wakeup(&dev->dev, false);
+ dev_pm_clear_wake_irq(&dev->dev);
+ gpiod_put(dev->wake);
+ dev->wake = NULL;
+}
#endif /* CONFIG_OF_IRQ */
static int pci_parse_request_of_pci_ranges(struct device *dev,
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d34266651ad0..9d9777fe099a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -17,6 +17,7 @@
#include <linux/lockdep.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/of_pci.h>
#include <linux/pci.h>
#include <linux/pm.h>
#include <linux/slab.h>
@@ -1123,6 +1124,16 @@ static inline bool platform_pci_bridge_d3(struct pci_dev *dev)
return acpi_pci_bridge_d3(dev);
}
+void platform_pci_configure_wake(struct pci_dev *dev)
+{
+ pci_configure_of_wake_gpio(dev);
+}
+
+void platform_pci_remove_wake(struct pci_dev *dev)
+{
+ pci_remove_of_wake_gpio(dev);
+}
+
/**
* pci_update_current_state - Read power state of given device and cache it
* @dev: PCI device to handle.
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index e8ad27abb1cf..8633c093385c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -284,6 +284,8 @@ void pci_msix_init(struct pci_dev *dev);
bool pci_bridge_d3_possible(struct pci_dev *dev);
void pci_bridge_d3_update(struct pci_dev *dev);
int pci_bridge_wait_for_secondary_bus(struct pci_dev *dev, char *reset_type);
+void platform_pci_configure_wake(struct pci_dev *dev);
+void platform_pci_remove_wake(struct pci_dev *dev);
static inline bool pci_bus_rrs_vendor_id(u32 l)
{
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b63cd0c310bc..143b0bd35b3c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2775,6 +2775,8 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
/* Establish pdev->tsm for newly added (e.g. new SR-IOV VFs) */
pci_tsm_init(dev);
+ platform_pci_configure_wake(dev);
+
pci_npem_create(dev);
pci_doe_sysfs_init(dev);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index e9d519993853..d781b41e57c4 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -35,6 +35,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
if (pci_dev_test_and_set_removed(dev))
return;
+ platform_pci_remove_wake(dev);
pci_doe_sysfs_teardown(dev);
pci_npem_remove(dev);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 29658c0ee71f..649fe8eafcfa 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -30,12 +30,18 @@ static inline void of_pci_check_probe_only(void) { }
#if IS_ENABLED(CONFIG_OF_IRQ)
int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
+void pci_configure_of_wake_gpio(struct pci_dev *dev);
+void pci_remove_of_wake_gpio(struct pci_dev *dev);
#else
static inline int
of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin)
{
return 0;
}
+
+static inline void pci_configure_of_wake_gpio(struct pci_dev *dev) { }
+
+static inline void pci_remove_of_wake_gpio(struct pci_dev *dev) { }
#endif
#endif
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..4289b60dcc83 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -588,6 +588,8 @@ struct pci_dev {
/* These methods index pci_reset_fn_methods[] */
u8 reset_methods[PCI_NUM_RESET_METHODS]; /* In priority order */
+ struct gpio_desc *wake; /* Holds WAKE# gpio */
+
#ifdef CONFIG_PCIE_TPH
u16 tph_cap; /* TPH capability offset */
u8 tph_mode; /* TPH mode */
---
base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
change-id: 20251104-wakeirq_support-f54c4baa18c5
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH 1/1] x86/vm86: fix vm86 struct leak on copy_from_user() failure
From: fffsqian @ 2026-06-24 9:26 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
hpa, Kees Cook, Andy Lutomirski, Brian Gerst
Cc: linux-gpio, Qingshuang Fu
From: Qingshuang Fu <fuqingshuang@kylinos.cn>
When copy_from_user() fails during vm86 setup in do_sys_vm86(),
the newly allocated vm86 structure is not freed, leading to a
memory leak that can be exploited by users with appropriate
privileges to cause DoS through resource exhaustion.
The leak occurs in multiple error paths after kzalloc_obj()
successfully allocates the vm86 structure and assigns it to
tsk->thread.vm86. Subsequent copy_from_user() failures for
vm86_struct, int_revectored, int21_revectored, or vm86plus data
leave the allocated memory orphaned.
Fix this by introducing a 'newly_allocated' boolean to distinguish
between newly created and pre-existing vm86 contexts. Use a
centralized cleanup path via goto to properly release memory in
all error scenarios while preserving existing vm86 states.
Security impact: This memory leak can lead to system DoS via OOM if
exploited by unprivileged local users, provided the system has
mmap_min_addr set to 0. The regression was introduced in commit
9fda6a0681e0 ("x86/vm86: Move vm86 fields out of 'thread_struct'") back
in 2015, and affects all 32-bit x86 kernels built with CONFIG_VM86
enabled.
Fixes: 9fda6a0681e0 ("x86/vm86: Move vm86 fields out of 'thread_struct'")
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
---
arch/x86/kernel/vm86_32.c | 38 ++++++++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index b4c1cabc7a4b..cde077f2c97e 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -202,7 +202,8 @@ static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
struct vm86 *vm86 = tsk->thread.vm86;
struct kernel_vm86_regs vm86regs;
struct pt_regs *regs = current_pt_regs();
- unsigned long err = 0;
+ bool newly_allocated = false;
+ long err = 0;
struct vm86_struct v;
err = security_mmap_addr(0);
@@ -235,20 +236,24 @@ static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
if (!(vm86 = kzalloc_obj(*vm86)))
return -ENOMEM;
tsk->thread.vm86 = vm86;
+ newly_allocated = true;
}
if (vm86->saved_sp0)
return -EPERM;
if (copy_from_user(&v, user_vm86,
- offsetof(struct vm86_struct, int_revectored)))
- return -EFAULT;
+ offsetof(struct vm86_struct, int_revectored))) {
+ err = -EFAULT;
+ goto cleanup;
+ }
/* VM86_SCREEN_BITMAP had numerous bugs and appears to have no users. */
if (v.flags & VM86_SCREEN_BITMAP) {
pr_info_once("vm86: '%s' uses VM86_SCREEN_BITMAP, which is no longer supported\n",
current->comm);
- return -EINVAL;
+ err = -EINVAL;
+ goto cleanup;
}
memset(&vm86regs, 0, sizeof(vm86regs));
@@ -275,16 +280,22 @@ static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
if (copy_from_user(&vm86->int_revectored,
&user_vm86->int_revectored,
- sizeof(struct revectored_struct)))
- return -EFAULT;
+ sizeof(struct revectored_struct))) {
+ err = -EFAULT;
+ goto cleanup;
+ }
if (copy_from_user(&vm86->int21_revectored,
&user_vm86->int21_revectored,
- sizeof(struct revectored_struct)))
- return -EFAULT;
+ sizeof(struct revectored_struct))) {
+ err = -EFAULT;
+ goto cleanup;
+ }
if (plus) {
if (copy_from_user(&vm86->vm86plus, &user_vm86->vm86plus,
- sizeof(struct vm86plus_info_struct)))
- return -EFAULT;
+ sizeof(struct vm86plus_info_struct))) {
+ err = -EFAULT;
+ goto cleanup;
+ }
vm86->vm86plus.is_vm86pus = 1;
} else
memset(&vm86->vm86plus, 0,
@@ -340,6 +351,13 @@ static long do_sys_vm86(struct vm86plus_struct __user *user_vm86, bool plus)
memcpy((struct kernel_vm86_regs *)regs, &vm86regs, sizeof(vm86regs));
return regs->ax;
+
+cleanup:
+ if (newly_allocated) {
+ tsk->thread.vm86 = NULL;
+ kfree(vm86);
+ }
+ return err;
}
static inline void set_IF(struct kernel_vm86_regs *regs)
base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
--
2.25.1
^ permalink raw reply related
* [brgl:gpio/for-current] BUILD SUCCESS 4e8eb6952aa6749726c6c3763ae0032a6332c24f
From: kernel test robot @ 2026-06-24 7:49 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git gpio/for-current
branch HEAD: 4e8eb6952aa6749726c6c3763ae0032a6332c24f gpio: davinci: fix IRQ domain leak on devm_kzalloc failure
elapsed time: 913m
configs tested: 218
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260624 gcc-15.2.0
arc randconfig-002-20260624 gcc-15.2.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260624 gcc-15.2.0
arm randconfig-002-20260624 gcc-15.2.0
arm randconfig-003-20260624 gcc-15.2.0
arm randconfig-004-20260624 gcc-15.2.0
arm sama5_defconfig gcc-16.1.0
arm vexpress_defconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260624 clang-21
arm64 randconfig-002-20260624 clang-21
arm64 randconfig-003-20260624 clang-21
arm64 randconfig-004-20260624 clang-21
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260624 clang-21
csky randconfig-002-20260624 clang-21
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260624 gcc-11.5.0
hexagon randconfig-001-20260624 gcc-9.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260624 gcc-11.5.0
hexagon randconfig-002-20260624 gcc-9.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 gcc-12
i386 buildonly-randconfig-001-20260624 gcc-12
i386 buildonly-randconfig-002 gcc-12
i386 buildonly-randconfig-002-20260624 gcc-12
i386 buildonly-randconfig-003 gcc-12
i386 buildonly-randconfig-003-20260624 gcc-12
i386 buildonly-randconfig-004 gcc-12
i386 buildonly-randconfig-004-20260624 gcc-12
i386 buildonly-randconfig-005 gcc-12
i386 buildonly-randconfig-005-20260624 gcc-12
i386 buildonly-randconfig-006 gcc-12
i386 buildonly-randconfig-006-20260624 gcc-12
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260624 clang-22
i386 randconfig-002 clang-22
i386 randconfig-002-20260624 clang-22
i386 randconfig-003 clang-22
i386 randconfig-003-20260624 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260624 clang-22
i386 randconfig-005 clang-22
i386 randconfig-005-20260624 clang-22
i386 randconfig-006 clang-22
i386 randconfig-006-20260624 clang-22
i386 randconfig-007 clang-22
i386 randconfig-007-20260624 clang-22
i386 randconfig-011-20260624 clang-22
i386 randconfig-012-20260624 clang-22
i386 randconfig-013-20260624 clang-22
i386 randconfig-014-20260624 clang-22
i386 randconfig-015-20260624 clang-22
i386 randconfig-016-20260624 clang-22
i386 randconfig-017-20260624 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260624 gcc-11.5.0
loongarch randconfig-001-20260624 gcc-9.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260624 gcc-11.5.0
loongarch randconfig-002-20260624 gcc-9.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
m68k stmark2_defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260624 gcc-11.5.0
nios2 randconfig-001-20260624 gcc-9.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260624 gcc-11.5.0
nios2 randconfig-002-20260624 gcc-9.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260624 gcc-16.1.0
parisc randconfig-002-20260624 gcc-16.1.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc asp8347_defconfig clang-23
powerpc fsp2_defconfig gcc-16.1.0
powerpc randconfig-001-20260624 gcc-16.1.0
powerpc randconfig-002-20260624 gcc-16.1.0
powerpc64 randconfig-001-20260624 gcc-16.1.0
powerpc64 randconfig-002-20260624 gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 clang-18
riscv randconfig-001-20260624 clang-18
riscv randconfig-002 clang-18
riscv randconfig-002-20260624 clang-18
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-18
s390 randconfig-001-20260624 clang-18
s390 randconfig-002 clang-18
s390 randconfig-002-20260624 clang-18
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 clang-18
sh randconfig-001-20260624 clang-18
sh randconfig-002 clang-18
sh randconfig-002-20260624 clang-18
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260624 gcc-14.3.0
sparc randconfig-002-20260624 gcc-14.3.0
sparc sparc32_defconfig gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260624 gcc-14.3.0
sparc64 randconfig-002-20260624 gcc-14.3.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260624 gcc-14.3.0
um randconfig-002-20260624 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260624 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260624 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260624 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260624 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260624 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260624 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260624 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260624 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260624 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260624 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260624 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260624 clang-22
x86_64 randconfig-011-20260624 gcc-14
x86_64 randconfig-012-20260624 gcc-14
x86_64 randconfig-013-20260624 gcc-14
x86_64 randconfig-014-20260624 gcc-14
x86_64 randconfig-015-20260624 gcc-14
x86_64 randconfig-016-20260624 gcc-14
x86_64 randconfig-071-20260624 gcc-14
x86_64 randconfig-072-20260624 gcc-14
x86_64 randconfig-073-20260624 gcc-14
x86_64 randconfig-074-20260624 gcc-14
x86_64 randconfig-075-20260624 gcc-14
x86_64 randconfig-076-20260624 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001-20260624 gcc-14.3.0
xtensa randconfig-002-20260624 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Drop unused irq_data argument from msm_gpio_update_dual_edge_pos()
From: Konrad Dybcio @ 2026-06-24 7:43 UTC (permalink / raw)
To: Hans de Goede, Bjorn Andersson, Linus Walleij; +Cc: linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-2-johannes.goede@oss.qualcomm.com>
On 6/23/26 2:27 PM, Hans de Goede wrote:
> The "struct irq_data *d" argument to msm_gpio_update_dual_edge_pos() is
> unused, drop it.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
From: Konrad Dybcio @ 2026-06-24 7:41 UTC (permalink / raw)
To: Hans de Goede, Bjorn Andersson, Linus Walleij; +Cc: linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-1-johannes.goede@oss.qualcomm.com>
On 6/23/26 2:27 PM, Hans de Goede wrote:
> Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(),
> this is unnecessary because gpiochip_allocate_mask() already does this.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-06-24 7:25 UTC (permalink / raw)
To: Robin Murphy
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel, linux-rockchip, Heiko Stuebner, Marek Szyprowski,
Viacheslav Bocharov, Linus Walleij, Bartosz Golaszewski
In-Reply-To: <112d2563-e650-4881-bba0-335f6a3fcb8a@arm.com>
On Tue, 23 Jun 2026 17:16:44 +0200, Robin Murphy <robin.murphy@arm.com> said:
> On 11/06/2026 9:26 am, Marek Szyprowski wrote:
>> Hi Viachesla,
>>
>> On 10.06.2026 17:32, Viacheslav Bocharov wrote:
>>> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
>>> the underlying chip's can_sleep, but under that lock it calls config and
>>> direction ops that reach sleeping pinctrl paths. On a controller with
>>> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
>>> runs from atomic context:
>>>
...
>>
>> I've checked this patchset with these two reverted and no warning was reported.
>
> If it hadn't already been fixed (...)
>
About that - Viacheslav, do you still plan to submit v2 of this?
Bart
^ permalink raw reply
* [PATCH] gpio: pca9570: Use I2C match data
From: Pengpeng Hou @ 2026-06-24 5:37 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, linux-kernel, Pengpeng Hou
The driver stores chip metadata in both the OF match table and the I2C
id table, but probe currently reads it with device_get_match_data().
That helper only returns firmware-node match data, so an I2C-id/modalias
match can leave chip_data NULL before the driver dereferences it to read
ngpio.
Use i2c_get_match_data() so the I2C id table driver_data is consumed
when firmware match data is not present.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/gpio/gpio-pca9570.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pca9570.c b/drivers/gpio/gpio-pca9570.c
index 4a368803fb03..f0c2fea0f6fe 100644
--- a/drivers/gpio/gpio-pca9570.c
+++ b/drivers/gpio/gpio-pca9570.c
@@ -133,7 +133,7 @@ static int pca9570_probe(struct i2c_client *client)
gpio->chip.get = pca9570_get;
gpio->chip.set = pca9570_set;
gpio->chip.base = -1;
- gpio->chip_data = device_get_match_data(&client->dev);
+ gpio->chip_data = i2c_get_match_data(client);
gpio->chip.ngpio = gpio->chip_data->ngpio;
gpio->chip.can_sleep = true;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:44AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
From: Hans de Goede @ 2026-06-23 17:33 UTC (permalink / raw)
To: Mukesh Ojha; +Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio
In-Reply-To: <20260623160457.j66dlzxfkvn3jxuj@hu-mojha-hyd.qualcomm.com>
Hi,
Thank you for the reviews.
On 23-Jun-26 18:04, Mukesh Ojha wrote:
> On Tue, Jun 23, 2026 at 02:27:31PM +0200, Hans de Goede wrote:
>> Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(),
>> this is unnecessary because gpiochip_allocate_mask() already does this.
>>
>> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
>> ---
>> drivers/pinctrl/qcom/pinctrl-msm.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
>> index c2938494c6bb..419342ab45e1 100644
>> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
>> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
>> @@ -1047,8 +1047,6 @@ static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc,
>> const struct msm_pingroup *g;
>> int i;
>>
>> - bitmap_fill(valid_mask, ngpios);
>> -
>> for (i = 0; i < ngpios; i++) {
>> g = &pctrl->soc->groups[i];
>>
>> --
>> 2.54.0
>>
>
> Looks like you missed to add kernel mailing list to the series.
You mean lkml ? Generally speaking I don't add that to series which
are subsytem specific and not really interesting for a wider audience.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
From: Mukesh Ojha @ 2026-06-23 16:04 UTC (permalink / raw)
To: Hans de Goede; +Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-1-johannes.goede@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 02:27:31PM +0200, Hans de Goede wrote:
> Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(),
> this is unnecessary because gpiochip_allocate_mask() already does this.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index c2938494c6bb..419342ab45e1 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -1047,8 +1047,6 @@ static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc,
> const struct msm_pingroup *g;
> int i;
>
> - bitmap_fill(valid_mask, ngpios);
> -
> for (i = 0; i < ngpios; i++) {
> g = &pctrl->soc->groups[i];
>
> --
> 2.54.0
>
Looks like you missed to add kernel mailing list to the series.
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Drop unused irq_data argument from msm_gpio_update_dual_edge_pos()
From: Mukesh Ojha @ 2026-06-23 15:52 UTC (permalink / raw)
To: Hans de Goede; +Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-2-johannes.goede@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 02:27:32PM +0200, Hans de Goede wrote:
> The "struct irq_data *d" argument to msm_gpio_update_dual_edge_pos() is
> unused, drop it.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 419342ab45e1..f780bab51d9c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -810,8 +810,7 @@ static const struct gpio_chip msm_gpio_template = {
> * Algorithm comes from Google's msmgpio driver.
> */
> static void msm_gpio_update_dual_edge_pos(struct msm_pinctrl *pctrl,
> - const struct msm_pingroup *g,
> - struct irq_data *d)
> + const struct msm_pingroup *g)
> {
> int loop_limit = 100;
> unsigned val, val2, intstat;
> @@ -1015,7 +1014,7 @@ static void msm_gpio_irq_ack(struct irq_data *d)
> msm_ack_intr_status(pctrl, g);
>
> if (test_bit(d->hwirq, pctrl->dual_edge_irqs))
> - msm_gpio_update_dual_edge_pos(pctrl, g, d);
> + msm_gpio_update_dual_edge_pos(pctrl, g);
>
> raw_spin_unlock_irqrestore(&pctrl->lock, flags);
> }
> @@ -1190,7 +1189,7 @@ static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type)
> msm_ack_intr_status(pctrl, g);
>
> if (test_bit(d->hwirq, pctrl->dual_edge_irqs))
> - msm_gpio_update_dual_edge_pos(pctrl, g, d);
> + msm_gpio_update_dual_edge_pos(pctrl, g);
>
> raw_spin_unlock_irqrestore(&pctrl->lock, flags);
>
> --
> 2.54.0
>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
From: Mukesh Ojha @ 2026-06-23 15:44 UTC (permalink / raw)
To: Hans de Goede; +Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-1-johannes.goede@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 02:27:31PM +0200, Hans de Goede wrote:
> Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(),
> this is unnecessary because gpiochip_allocate_mask() already does this.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index c2938494c6bb..419342ab45e1 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -1047,8 +1047,6 @@ static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc,
> const struct msm_pingroup *g;
> int i;
>
> - bitmap_fill(valid_mask, ngpios);
> -
> for (i = 0; i < ngpios; i++) {
> g = &pctrl->soc->groups[i];
>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Robin Murphy @ 2026-06-23 15:16 UTC (permalink / raw)
To: Marek Szyprowski, Viacheslav Bocharov, Linus Walleij,
Bartosz Golaszewski
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel, linux-rockchip, Heiko Stuebner
In-Reply-To: <184d315b-a0a1-4792-8a40-1b4967025916@samsung.com>
On 11/06/2026 9:26 am, Marek Szyprowski wrote:
> Hi Viachesla,
>
> On 10.06.2026 17:32, Viacheslav Bocharov wrote:
>> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
>> the underlying chip's can_sleep, but under that lock it calls config and
>> direction ops that reach sleeping pinctrl paths. On a controller with
>> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
>> runs from atomic context:
>>
>> BUG: sleeping function called from invalid context
>> ... pinctrl_gpio_set_config <- gpiochip_generic_config
>> <- gpio_shared_proxy_set_config (voting spinlock held)
>> <- ... <- mmc_pwrseq_simple_probe
>>
>> This was reported on Khadas VIM3 and worked around for Amlogic by
>> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
>> sleeping"), which marked the whole meson controller sleeping. That
>> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
>> no longer detects devices, because its IRQ-disabled read slot calls the
>> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>>
>> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
>> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>>
>> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
>> gating on gpiod_cansleep() change behaviour. No current device needs
>> atomic (non-cansleep) value access on a shared GPIO -- every report
>> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
>> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
>> which is what the proxy exists to vote on. An alternative that keeps
>> atomic value access (split locking) is possible but adds a second lock
>> and new race windows. I went with the simpler, verified approach and
>> would appreciate guidance on whether the atomic value path must be
>> preserved.
>>
>> The two are a unit: patch 2 must not be applied without patch 1,
>> otherwise the original VIM3 splat returns on boards that share a meson
>> GPIO -- please keep the order. I have not Cc'd stable; I will request
>> stable backports separately once both patches have landed.
>>
>> Viacheslav Bocharov (2):
>> gpio: shared-proxy: always serialize with a sleeping mutex
>> pinctrl: meson: restore non-sleeping GPIO access
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> This probably also affects the similar changes in Rockchip GPIO driver done
> by the following commits:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction")
>
> I've checked this patchset with these two reverted and no warning was reported.
If it hadn't already been fixed, then indeed I guess this might make
20cf2aed89ac redundant. However, 7ca497be0016 is still an objective
improvement either way, since that driver never needed to call pinctrl
at all (it was seemingly just an artefact of how the GPIO code was
originally implemented within the pinctrl driver itself).
Thanks,
Robin.
^ 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