* [PATCH 8/9] rtc: mt6397: add compatible for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-02-23 17:12 UTC (permalink / raw)
To: linux-mediatek
Cc: Val Packett, Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Eddie Huang, Alexandre Belloni, Louis-Alexis Eyraud,
Julien Massot, Gary Bisson, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-rtc
In-Reply-To: <cover.1771865014.git.l.scorcia@gmail.com>
From: Val Packett <val@packett.cool>
Add a compatible, using the same data as the MT6397.
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/rtc/rtc-mt6397.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 692c00ff544b..6b67d917f8d5 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -334,6 +334,7 @@ static const struct of_device_id mt6397_rtc_of_match[] = {
{ .compatible = "mediatek,mt6323-rtc", .data = &mt6397_rtc_data },
{ .compatible = "mediatek,mt6357-rtc", .data = &mt6358_rtc_data },
{ .compatible = "mediatek,mt6358-rtc", .data = &mt6358_rtc_data },
+ { .compatible = "mediatek,mt6392-rtc", .data = &mt6397_rtc_data },
{ .compatible = "mediatek,mt6397-rtc", .data = &mt6397_rtc_data },
{ }
};
--
2.43.0
^ permalink raw reply related
* [PATCH 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-02-23 17:12 UTC (permalink / raw)
To: linux-mediatek
Cc: Val Packett, Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Eddie Huang, Alexandre Belloni, Julien Massot,
Louis-Alexis Eyraud, Gary Bisson, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-rtc
In-Reply-To: <cover.1771865014.git.l.scorcia@gmail.com>
From: Val Packett <val@packett.cool>
Add the dts to be included by all boards using the MT6392 PMIC.
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 | 133 +++++++++++++++++++++++
1 file changed, 133 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
new file mode 100644
index 000000000000..d0d86ae0f073
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Copyright (c) 2024 Val Packett <val@packett.cool>
+ */
+
+#include <dt-bindings/input/input.h>
+
+&pwrap {
+ pmic: pmic {
+ compatible = "mediatek,mt6392";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ compatible = "mediatek,mt6392-regulator";
+
+ mt6392_vproc_reg: buck_vproc {
+ regulator-name = "vproc";
+ };
+
+ mt6392_vsys_reg: buck_vsys {
+ regulator-name = "vsys";
+ };
+
+ mt6392_vcore_reg: buck_vcore {
+ regulator-name = "vcore";
+ };
+
+ mt6392_vxo22_reg: ldo_vxo22 {
+ regulator-name = "vxo22";
+ };
+
+ mt6392_vaud22_reg: ldo_vaud22 {
+ regulator-name = "vaud22";
+ };
+
+ mt6392_vcama_reg: ldo_vcama {
+ regulator-name = "vcama";
+ };
+
+ mt6392_vaud28_reg: ldo_vaud28 {
+ regulator-name = "vaud28";
+ };
+
+ mt6392_vadc18_reg: ldo_vadc18 {
+ regulator-name = "vadc18";
+ };
+
+ mt6392_vcn35_reg: ldo_vcn35 {
+ regulator-name = "vcn35";
+ };
+
+ mt6392_vio28_reg: ldo_vio28 {
+ regulator-name = "vio28";
+ };
+
+ mt6392_vusb_reg: ldo_vusb {
+ regulator-name = "vusb";
+ };
+
+ mt6392_vmc_reg: ldo_vmc {
+ regulator-name = "vmc";
+ };
+
+ mt6392_vmch_reg: ldo_vmch {
+ regulator-name = "vmch";
+ };
+
+ mt6392_vemc3v3_reg: ldo_vemc3v3 {
+ regulator-name = "vemc3v3";
+ };
+
+ mt6392_vgp1_reg: ldo_vgp1 {
+ regulator-name = "vgp1";
+ };
+
+ mt6392_vgp2_reg: ldo_vgp2 {
+ regulator-name = "vgp2";
+ };
+
+ mt6392_vcn18_reg: ldo_vcn18 {
+ regulator-name = "vcn18";
+ };
+
+ mt6392_vcamaf_reg: ldo_vcamaf {
+ regulator-name = "vcamaf";
+ };
+
+ mt6392_vm_reg: ldo_vm {
+ regulator-name = "vm";
+ };
+
+ mt6392_vio18_reg: ldo_vio18 {
+ regulator-name = "vio18";
+ };
+
+ mt6392_vcamd_reg: ldo_vcamd {
+ regulator-name = "vcamd";
+ };
+
+ mt6392_vcamio_reg: ldo_vcamio {
+ regulator-name = "vcamio";
+ };
+
+ mt6392_vm25_reg: ldo_vm25 {
+ regulator-name = "vm25";
+ };
+
+ mt6392_vefuse_reg: ldo_vefuse {
+ regulator-name = "vefuse";
+ };
+ };
+
+ rtc {
+ compatible = "mediatek,mt6392-rtc";
+ };
+
+ keys {
+ compatible = "mediatek,mt6392-keys";
+
+ key-power {
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
+ key-home {
+ linux,keycodes = <KEY_HOME>;
+ wakeup-source;
+ };
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Andy Shevchenko @ 2026-02-23 17:38 UTC (permalink / raw)
To: Shawn Lin
Cc: Andy Shevchenko, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Jan Dabros, linux-i2c, Daniel Mack,
Haojian Zhuang, linux-spi, Jonathan Derrick, linux-pci,
linux-gpio, Mauro Carvalho Chehab, linux-media, linux-mmc
In-Reply-To: <cb878741-7b61-b72c-5a72-6ed6d5091b1f@rock-chips.com>
On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote:
> 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
> > On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
> > >
> > > This patch series addresses a long-standing design issue in the PCI/MSI
> > > subsystem where the implicit, automatic management of IRQ vectors by
> > > the devres framework conflicts with explicit driver cleanup, creating
> > > ambiguity and potential resource management bugs.
> > >
> > > ==== The Problem: Implicit vs. Explicit Management ====
> > > Historically, `pcim_enable_device()` not only manages standard PCI resources
> > > (BARs) via devres but also implicitly triggers automatic IRQ vector management
> > > by setting a flag that registers `pcim_msi_release()` as a cleanup action.
> > >
> > > This creates an ambiguous ownership model. Many drivers follow a pattern of:
> > > 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
> > > 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
> > >
> > > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > > attempt to free the IRQ vectors a second time upon device release, leading to
> > > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > > while 35 other drivers correctly rely solely on the implicit cleanup.
> >
> > Is this confirmed? What I read from the cover letter, this series was
> > only compile-tested, so how can you prove the problem exists in the
> > first place?
>
> Yes, it's confirmed. My debug of a double free issue of a out-of-tree
> PCIe wifi driver which uses
> pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
> it. And we did have a TODO to cleanup this hybrid usage, targeted in
> this cycle[1] suggested by Philipp:
Okay, fair enough. I think this bit was missing in the cover letter.
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi
> > > ==== The Solution: Making Management Explicit ====
> > > This series enforces a clear, predictable model:
> > > 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
> > > pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
> > > vectors should use these functions, which set the is_msi_managed flag and
> > > ensure automatic cleanup.
> > > 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
> > > pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
> > > make an explicit call to pcim_alloc_irq_vectors().
> > > 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
> > > to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
> > > pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
> > > are now solely the driver's responsibility to free with pci_free_irq_vectors().
> > >
> > > With these changes, we clear ownership model: Explicit resource management eliminates
> > > ambiguity and follows the "principle of least surprise." New drivers choose one model and
> > > be consistent.
> > > - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
> > > - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
> >
> > Have you checked previous attempts? Why is your series better than those?
>
> There seems not previous attempts.
Maybe we are looking to the different projects...
https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors
> > > ==== Testing And Review ====
> > > 1. This series is only compiled test with allmodconfig.
> > > 2. Given the substantial size of this patch series, I have structured the mailing
> > > to facilitate efficient review. The cover letter, the first patch and the last one will be sent
> > > to all relevant mailing lists and key maintainers to ensure broad visibility and
> > > initial feedback on the overall approach. The remaining subsystem-specific patches
> > > will be sent only to the respective subsystem maintainers and their associated
> > > mailing lists, reducing noise.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 7/9] input: keyboard: mtk-pmic-keys: add MT6392 support
From: Dmitry Torokhov @ 2026-02-23 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Eddie Huang, Alexandre Belloni, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-rtc
In-Reply-To: <2c96591313084d240ac94b9d42d91d984fa9bce7.1771865015.git.l.scorcia@gmail.com>
On Mon, Feb 23, 2026 at 05:12:46PM +0000, Luca Leonardo Scorcia wrote:
> From: Val Packett <val@packett.cool>
>
> Add support for the MT6392 PMIC to the keys driver.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please feel free to merge with the rest of the series.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Rob Herring @ 2026-02-23 17:57 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260213171431.2228814-2-hugo@hugovil.com>
On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add DT bindings for GPIO charlieplex keypad.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> new file mode 100644
> index 0000000000000..1672491a75a85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO charlieplex keypad
> +
> +maintainers:
> + - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> +
> +description:
> + The charlieplex keypad supports N^2)-N different key combinations (where N is
> + the number of lines). Key presses and releases are detected by configuring
> + only one line as output at a time, and reading other line states. This process
> + is repeated for each line.
> + This mechanism doesn't allow to detect simultaneous key presses.
> +
> +allOf:
> + - $ref: input.yaml#
> + - $ref: /schemas/input/matrix-keymap.yaml#
> +
> +properties:
> + compatible:
> + const: gpio-charlieplex-keypad
> +
> + autorepeat: true
> +
> + line-scan-delay-us:
> + description:
> + Delay, measured in microseconds, that is needed
> + before we can scan keypad after activating one line.
> + default: 0
Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
If so, move it to matrix-keymap.yaml to re-use it here.
If not, there's a bunch of other scan delay properties just from
grepping "delay" in the input bindings. Surely we can define something
common.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-02-23 18:47 UTC (permalink / raw)
To: Rob Herring
Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260223175706.GA4168417-robh@kernel.org>
Hi Rob,
On Mon, 23 Feb 2026 11:57:06 -0600
Rob Herring <robh@kernel.org> wrote:
> On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add DT bindings for GPIO charlieplex keypad.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++
> > 1 file changed, 82 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > new file mode 100644
> > index 0000000000000..1672491a75a85
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > @@ -0,0 +1,82 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO charlieplex keypad
> > +
> > +maintainers:
> > + - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > +
> > +description:
> > + The charlieplex keypad supports N^2)-N different key combinations (where N is
> > + the number of lines). Key presses and releases are detected by configuring
> > + only one line as output at a time, and reading other line states. This process
> > + is repeated for each line.
> > + This mechanism doesn't allow to detect simultaneous key presses.
> > +
> > +allOf:
> > + - $ref: input.yaml#
> > + - $ref: /schemas/input/matrix-keymap.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: gpio-charlieplex-keypad
> > +
> > + autorepeat: true
> > +
> > + line-scan-delay-us:
> > + description:
> > + Delay, measured in microseconds, that is needed
> > + before we can scan keypad after activating one line.
> > + default: 0
>
> Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> If so, move it to matrix-keymap.yaml to re-use it here.
It is used in a similar fashion, but for charlieplex keyboard, there is
no concept of "rows" and "columns". There are only
lines, which are all equivalent in functionality.
> If not, there's a bunch of other scan delay properties just from
> grepping "delay" in the input bindings. Surely we can define something
> common.
Most of those delays refer to something quite different than what
"col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
that we wait when activating a GPIO before we can safely/reliably read
other GPIOs connected thru its circuitry).
Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
combined into a common "line-scan-delay-us" ("line" is more generic
than column), and defined in matrix-keymap.yaml.
Then would it be ok to remove "col-scan-delay-us" from
gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ?
Hugo.
--
Hugo Villeneuve <hugo@hugovil.com>
^ permalink raw reply
* [PATCH 6/9] regulator: mt6392: Add support for MT6392 regulator
From: Luca Leonardo Scorcia @ 2026-02-23 17:12 UTC (permalink / raw)
To: linux-mediatek
Cc: Fabien Parent, Val Packett, Luca Leonardo Scorcia,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Eddie Huang, Alexandre Belloni, Louis-Alexis Eyraud,
Julien Massot, Gary Bisson, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-rtc
In-Reply-To: <cover.1771865014.git.l.scorcia@gmail.com>
From: Fabien Parent <parent.f@gmail.com>
The MT6392 is a regulator found on boards based on the MediaTek
MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
connects as a slave to a SoC using SPI, wrapped inside PWRAP.
Signed-off-by: Fabien Parent <parent.f@gmail.com>
Co-developed-by: Val Packett <val@packett.cool>
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6392-regulator.c | 491 +++++++++++++++++++++
include/linux/regulator/mt6392-regulator.h | 40 ++
4 files changed, 541 insertions(+)
create mode 100644 drivers/regulator/mt6392-regulator.c
create mode 100644 include/linux/regulator/mt6392-regulator.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d2335276cce5..66876d730807 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -991,6 +991,15 @@ config REGULATOR_MT6380
This driver supports the control of different power rails of device
through regulator interface.
+config REGULATOR_MT6392
+ tristate "MediaTek MT6392 PMIC"
+ depends on MFD_MT6397
+ help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6392 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
config REGULATOR_MT6397
tristate "MediaTek MT6397 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1beba1493241..db5145cfcf36 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
obj-$(CONFIG_REGULATOR_MT6363) += mt6363-regulator.o
obj-$(CONFIG_REGULATOR_MT6370) += mt6370-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
+obj-$(CONFIG_REGULATOR_MT6392) += mt6392-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
diff --git a/drivers/regulator/mt6392-regulator.c b/drivers/regulator/mt6392-regulator.c
new file mode 100644
index 000000000000..1ac5cdf4eb7f
--- /dev/null
+++ b/drivers/regulator/mt6392-regulator.c
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+// Copyright (c) 2020 BayLibre, SAS.
+// Author: Chen Zhong <chen.zhong@mediatek.com>
+// Author: Fabien Parent <fparent@baylibre.com>
+//
+// Based on mt6397-regulator.c
+
+#include <linux/module.h>
+#include <linux/linear_range.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6392/registers.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6392-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6392_BUCK_MODE_AUTO 0
+#define MT6392_BUCK_MODE_FORCE_PWM 1
+#define MT6392_LDO_MODE_NORMAL 0
+#define MT6392_LDO_MODE_LP 1
+
+/*
+ * MT6392 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6392_regulator_info {
+ struct regulator_desc desc;
+ u32 qi;
+ u32 vselon_reg;
+ u32 vselctrl_reg;
+ u32 vselctrl_mask;
+ u32 modeset_reg;
+ u32 modeset_mask;
+};
+
+#define MT6392_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \
+ vosel, vosel_mask, voselon, vosel_ctrl, \
+ _modeset_reg, _modeset_mask, rampdelay) \
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6392_volt_range_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = (max - min)/step + 1, \
+ .linear_ranges = volt_ranges, \
+ .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+ .vsel_reg = vosel, \
+ .vsel_mask = vosel_mask, \
+ .enable_reg = enreg, \
+ .enable_mask = BIT(0), \
+ .ramp_delay = rampdelay, \
+ }, \
+ .qi = BIT(13), \
+ .vselon_reg = voselon, \
+ .vselctrl_reg = vosel_ctrl, \
+ .vselctrl_mask = BIT(1), \
+ .modeset_reg = _modeset_reg, \
+ .modeset_mask = _modeset_mask, \
+}
+
+#define MT6392_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \
+ vosel_mask, _modeset_reg, _modeset_mask, entime) \
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6392_volt_table_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = ARRAY_SIZE(ldo_volt_table), \
+ .volt_table = ldo_volt_table, \
+ .vsel_reg = vosel, \
+ .vsel_mask = vosel_mask, \
+ .enable_reg = enreg, \
+ .enable_mask = BIT(enbit), \
+ .enable_time = entime, \
+ }, \
+ .qi = BIT(15), \
+ .modeset_reg = _modeset_reg, \
+ .modeset_mask = _modeset_mask, \
+}
+
+#define MT6392_LDO_LINEAR(match, vreg, min, max, step, volt_ranges, \
+ enreg, enbit, vosel, vosel_mask, _modeset_reg, \
+ _modeset_mask, entime) \
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6392_volt_ldo_range_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = (max - min)/step + 1, \
+ .linear_ranges = volt_ranges, \
+ .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+ .vsel_reg = vosel, \
+ .vsel_mask = vosel_mask, \
+ .enable_reg = enreg, \
+ .enable_mask = BIT(enbit), \
+ .enable_time = entime, \
+ }, \
+ .qi = BIT(15), \
+ .modeset_reg = _modeset_reg, \
+ .modeset_mask = _modeset_mask, \
+}
+
+#define MT6392_REG_FIXED(match, vreg, enreg, enbit, volt, \
+ _modeset_reg, _modeset_mask, entime) \
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6392_volt_fixed_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = 1, \
+ .enable_reg = enreg, \
+ .enable_mask = BIT(enbit), \
+ .enable_time = entime, \
+ .min_uV = volt, \
+ }, \
+ .qi = BIT(15), \
+ .modeset_reg = _modeset_reg, \
+ .modeset_mask = _modeset_mask, \
+}
+
+#define MT6392_REG_FIXED_NO_MODE(match, vreg, enreg, enbit, volt, \
+ entime) \
+[MT6392_ID_##vreg] = { \
+ .desc = { \
+ .name = #vreg, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6392_volt_fixed_no_mode_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6392_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = 1, \
+ .enable_reg = enreg, \
+ .enable_mask = BIT(enbit), \
+ .enable_time = entime, \
+ .min_uV = volt, \
+ }, \
+ .qi = BIT(15), \
+}
+
+static const struct linear_range buck_volt_range1[] = {
+ REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
+};
+
+static const struct linear_range buck_volt_range2[] = {
+ REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
+};
+
+static const u32 ldo_volt_table1[] = {
+ 1800000, 1900000, 2000000, 2200000,
+};
+
+static const struct linear_range ldo_volt_range2[] = {
+ REGULATOR_LINEAR_RANGE(3300000, 0, 3, 100000),
+};
+
+static const u32 ldo_volt_table3[] = {
+ 1800000, 3300000,
+};
+
+static const u32 ldo_volt_table4[] = {
+ 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table5[] = {
+ 1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table6[] = {
+ 1240000, 1390000,
+};
+
+static const u32 ldo_volt_table7[] = {
+ 1200000, 1300000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table8[] = {
+ 1800000, 2000000,
+};
+
+static int mt6392_buck_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ int ret, val = 0;
+ struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
+
+ switch (mode) {
+ case REGULATOR_MODE_FAST:
+ val = MT6392_BUCK_MODE_FORCE_PWM;
+ break;
+ case REGULATOR_MODE_NORMAL:
+ val = MT6392_BUCK_MODE_AUTO;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ val <<= ffs(info->modeset_mask) - 1;
+
+ ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
+ info->modeset_mask, val);
+
+ return ret;
+}
+
+static unsigned int mt6392_buck_get_mode(struct regulator_dev *rdev)
+{
+ unsigned int val;
+ unsigned int mode;
+ int ret;
+ struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
+
+ ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+ if (ret < 0)
+ return ret;
+
+ val &= info->modeset_mask;
+ val >>= ffs(info->modeset_mask) - 1;
+
+ if (val & 0x1)
+ mode = REGULATOR_MODE_FAST;
+ else
+ mode = REGULATOR_MODE_NORMAL;
+
+ return mode;
+}
+
+static int mt6392_ldo_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ int ret, val = 0;
+ struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
+
+ switch (mode) {
+ case REGULATOR_MODE_STANDBY:
+ val = MT6392_LDO_MODE_LP;
+ break;
+ case REGULATOR_MODE_NORMAL:
+ val = MT6392_LDO_MODE_NORMAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ val <<= ffs(info->modeset_mask) - 1;
+
+ ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
+ info->modeset_mask, val);
+
+ return ret;
+}
+
+static unsigned int mt6392_ldo_get_mode(struct regulator_dev *rdev)
+{
+ unsigned int val;
+ unsigned int mode;
+ int ret;
+ struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
+
+ ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+ if (ret < 0)
+ return ret;
+
+ val &= info->modeset_mask;
+ val >>= ffs(info->modeset_mask) - 1;
+
+ if (val & 0x1)
+ mode = REGULATOR_MODE_STANDBY;
+ else
+ mode = REGULATOR_MODE_NORMAL;
+
+ return mode;
+}
+
+static const struct regulator_ops mt6392_volt_range_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6392_buck_set_mode,
+ .get_mode = mt6392_buck_get_mode,
+};
+
+static const struct regulator_ops mt6392_volt_table_ops = {
+ .list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_iterate,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6392_ldo_set_mode,
+ .get_mode = mt6392_ldo_get_mode,
+};
+
+static const struct regulator_ops mt6392_volt_ldo_range_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6392_ldo_set_mode,
+ .get_mode = mt6392_ldo_get_mode,
+};
+
+static const struct regulator_ops mt6392_volt_fixed_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6392_ldo_set_mode,
+ .get_mode = mt6392_ldo_get_mode,
+};
+
+static const struct regulator_ops mt6392_volt_fixed_no_mode_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+/* The array is indexed by id(MT6392_ID_XXX) */
+static struct mt6392_regulator_info mt6392_regulators[] = {
+ MT6392_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
+ buck_volt_range1, MT6392_VPROC_CON7, MT6392_VPROC_CON9, 0x7f,
+ MT6392_VPROC_CON10, MT6392_VPROC_CON5, MT6392_VPROC_CON2,
+ 0x100, 12500),
+ MT6392_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500,
+ buck_volt_range2, MT6392_VSYS_CON7, MT6392_VSYS_CON9, 0x7f,
+ MT6392_VSYS_CON10, MT6392_VSYS_CON5, MT6392_VSYS_CON2, 0x100,
+ 25000),
+ MT6392_BUCK("buck_vcore", VCORE, 700000, 1493750, 6250,
+ buck_volt_range1, MT6392_VCORE_CON7, MT6392_VCORE_CON9, 0x7f,
+ MT6392_VCORE_CON10, MT6392_VCORE_CON5, MT6392_VCORE_CON2,
+ 0x100, 12500),
+ MT6392_REG_FIXED("ldo_vxo22", VXO22, MT6392_ANALDO_CON1, 10, 2200000,
+ MT6392_ANALDO_CON1, 0x2, 110),
+ MT6392_LDO("ldo_vaud22", VAUD22, ldo_volt_table1,
+ MT6392_ANALDO_CON2, 14, MT6392_ANALDO_CON8, 0x60,
+ MT6392_ANALDO_CON2, 0x2, 264),
+ MT6392_REG_FIXED_NO_MODE("ldo_vcama", VCAMA, MT6392_ANALDO_CON4, 15,
+ 2800000, 264),
+ MT6392_REG_FIXED("ldo_vaud28", VAUD28, MT6392_ANALDO_CON23, 14, 2800000,
+ MT6392_ANALDO_CON23, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vadc18", VADC18, MT6392_ANALDO_CON25, 14, 1800000,
+ MT6392_ANALDO_CON25, 0x2, 264),
+ MT6392_LDO_LINEAR("ldo_vcn35", VCN35, 3300000, 3600000, 100000,
+ ldo_volt_range2, MT6392_ANALDO_CON21, 12, MT6392_ANALDO_CON16,
+ 0xC, MT6392_ANALDO_CON21, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vio28", VIO28, MT6392_DIGLDO_CON0, 14, 2800000,
+ MT6392_DIGLDO_CON0, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vusb", VUSB, MT6392_DIGLDO_CON2, 14, 3300000,
+ MT6392_DIGLDO_CON2, 0x2, 264),
+ MT6392_LDO("ldo_vmc", VMC, ldo_volt_table3,
+ MT6392_DIGLDO_CON3, 12, MT6392_DIGLDO_CON24, 0x10,
+ MT6392_DIGLDO_CON3, 0x2, 264),
+ MT6392_LDO("ldo_vmch", VMCH, ldo_volt_table4,
+ MT6392_DIGLDO_CON5, 14, MT6392_DIGLDO_CON26, 0x80,
+ MT6392_DIGLDO_CON5, 0x2, 264),
+ MT6392_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4,
+ MT6392_DIGLDO_CON6, 14, MT6392_DIGLDO_CON27, 0x80,
+ MT6392_DIGLDO_CON6, 0x2, 264),
+ MT6392_LDO("ldo_vgp1", VGP1, ldo_volt_table5,
+ MT6392_DIGLDO_CON7, 15, MT6392_DIGLDO_CON28, 0xE0,
+ MT6392_DIGLDO_CON7, 0x2, 264),
+ MT6392_LDO("ldo_vgp2", VGP2, ldo_volt_table5,
+ MT6392_DIGLDO_CON8, 15, MT6392_DIGLDO_CON29, 0xE0,
+ MT6392_DIGLDO_CON8, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vcn18", VCN18, MT6392_DIGLDO_CON11, 14, 1800000,
+ MT6392_DIGLDO_CON11, 0x2, 264),
+ MT6392_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5,
+ MT6392_DIGLDO_CON31, 15, MT6392_DIGLDO_CON32, 0xE0,
+ MT6392_DIGLDO_CON31, 0x2, 264),
+ MT6392_LDO("ldo_vm", VM, ldo_volt_table6,
+ MT6392_DIGLDO_CON47, 14, MT6392_DIGLDO_CON48, 0x30,
+ MT6392_DIGLDO_CON47, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vio18", VIO18, MT6392_DIGLDO_CON49, 14, 1800000,
+ MT6392_DIGLDO_CON49, 0x2, 264),
+ MT6392_LDO("ldo_vcamd", VCAMD, ldo_volt_table7,
+ MT6392_DIGLDO_CON51, 14, MT6392_DIGLDO_CON52, 0x60,
+ MT6392_DIGLDO_CON51, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vcamio", VCAMIO, MT6392_DIGLDO_CON53, 14, 1800000,
+ MT6392_DIGLDO_CON53, 0x2, 264),
+ MT6392_REG_FIXED("ldo_vm25", VM25, MT6392_DIGLDO_CON55, 14, 2500000,
+ MT6392_DIGLDO_CON55, 0x2, 264),
+ MT6392_LDO("ldo_vefuse", VEFUSE, ldo_volt_table8,
+ MT6392_DIGLDO_CON57, 14, MT6392_DIGLDO_CON58, 0x10,
+ MT6392_DIGLDO_CON57, 0x2, 264),
+};
+
+static int mt6392_set_buck_vosel_reg(struct platform_device *pdev)
+{
+ struct mt6397_chip *mt6392 = dev_get_drvdata(pdev->dev.parent);
+ int i;
+ u32 regval;
+
+ for (i = 0; i < MT6392_MAX_REGULATOR; i++) {
+ if (mt6392_regulators[i].vselctrl_reg) {
+ if (regmap_read(mt6392->regmap,
+ mt6392_regulators[i].vselctrl_reg,
+ ®val) < 0) {
+ dev_err(&pdev->dev,
+ "Failed to read buck ctrl\n");
+ return -EIO;
+ }
+
+ if (regval & mt6392_regulators[i].vselctrl_mask) {
+ mt6392_regulators[i].desc.vsel_reg =
+ mt6392_regulators[i].vselon_reg;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int mt6392_regulator_probe(struct platform_device *pdev)
+{
+ struct mt6397_chip *mt6392 = dev_get_drvdata(pdev->dev.parent);
+ struct regulator_config config = {};
+ struct regulator_dev *rdev;
+ int i;
+
+ /* Query buck controller to select activated voltage register part */
+ if (mt6392_set_buck_vosel_reg(pdev))
+ return -EIO;
+
+ for (i = 0; i < MT6392_MAX_REGULATOR; i++) {
+ config.dev = &pdev->dev;
+ config.driver_data = &mt6392_regulators[i];
+ config.regmap = mt6392->regmap;
+
+ rdev = devm_regulator_register(&pdev->dev,
+ &mt6392_regulators[i].desc,
+ &config);
+ if (IS_ERR(rdev)) {
+ dev_err(&pdev->dev, "failed to register %s\n",
+ mt6392_regulators[i].desc.name);
+ return PTR_ERR(rdev);
+ }
+ }
+
+ return 0;
+}
+
+static const struct platform_device_id mt6392_platform_ids[] = {
+ {"mt6392-regulator", 0},
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6392_platform_ids);
+
+static struct platform_driver mt6392_regulator_driver = {
+ .driver = {
+ .name = "mt6392-regulator",
+ },
+ .probe = mt6392_regulator_probe,
+ .id_table = mt6392_platform_ids,
+};
+
+module_platform_driver(mt6392_regulator_driver);
+
+MODULE_AUTHOR("Chen Zhong <chen.zhong@mediatek.com>");
+MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6392 PMIC");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regulator/mt6392-regulator.h b/include/linux/regulator/mt6392-regulator.h
new file mode 100644
index 000000000000..dfcbcacb5ad4
--- /dev/null
+++ b/include/linux/regulator/mt6392-regulator.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong@mediatek.com>
+ */
+
+#ifndef __LINUX_REGULATOR_MT6392_H
+#define __LINUX_REGULATOR_MT6392_H
+
+enum {
+ MT6392_ID_VPROC = 0,
+ MT6392_ID_VSYS,
+ MT6392_ID_VCORE,
+ MT6392_ID_VXO22,
+ MT6392_ID_VAUD22,
+ MT6392_ID_VCAMA,
+ MT6392_ID_VAUD28,
+ MT6392_ID_VADC18,
+ MT6392_ID_VCN35,
+ MT6392_ID_VIO28,
+ MT6392_ID_VUSB = 10,
+ MT6392_ID_VMC,
+ MT6392_ID_VMCH,
+ MT6392_ID_VEMC3V3,
+ MT6392_ID_VGP1,
+ MT6392_ID_VGP2,
+ MT6392_ID_VCN18,
+ MT6392_ID_VCAMAF,
+ MT6392_ID_VM,
+ MT6392_ID_VIO18,
+ MT6392_ID_VCAMD,
+ MT6392_ID_VCAMIO,
+ MT6392_ID_VM25,
+ MT6392_ID_VEFUSE,
+ MT6392_ID_RG_MAX,
+};
+
+#define MT6392_MAX_REGULATOR MT6392_ID_RG_MAX
+
+#endif /* __LINUX_REGULATOR_MT6392_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
pci device drivers which rely on the devres machinery to help cleanup the IRQ
vectors.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++
include/linux/pci.h | 22 ++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c
index c18559b..2362fca 100644
--- a/drivers/pci/msi/api.c
+++ b/drivers/pci/msi/api.c
@@ -297,6 +297,32 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);
/**
+ * pcim_alloc_irq_vectors() - devres managed pci_alloc_irq_vectors()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags)
+{
+ return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, NULL);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors);
+
+/**
+ * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()
+ * Interrupt vectors are automatically freed by the devres machinery
+ */
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *affd)
+{
+ dev->is_msi_managed = true;
+ return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, affd);
+}
+EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);
+
+/**
* pci_irq_vector() - Get Linux IRQ number of a device interrupt vector
* @dev: the PCI device to operate on
* @nr: device-relative interrupt vector index (0-based); has different
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d5ec0f8..ae58f70 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1764,6 +1764,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
unsigned int max_vecs, unsigned int flags,
struct irq_affinity *affd);
+int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags);
+int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *affd);
+
bool pci_msix_can_alloc_dyn(struct pci_dev *dev);
struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
const struct irq_affinity_desc *affdesc);
@@ -1806,6 +1812,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
flags, NULL);
}
+static inline int
+pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags,
+ struct irq_affinity *aff_desc)
+{
+ return pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, aff_desc);
+}
+static inline int
+pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
+ unsigned int max_vecs, unsigned int flags)
+{
+ return pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,
+ flags, NULL);
+}
+
static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)
{ return false; }
static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,
--
2.7.4
^ permalink raw reply related
* [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
From: Bart Van Assche @ 2026-02-23 21:49 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Bart Van Assche, Dmitry Torokhov, Nick Dyer, linux-input
In-Reply-To: <20260223214950.2153735-1-bvanassche@acm.org>
Lock f54->data_mutex before the first 'goto error' statement since
jumping to the 'error' label causes that mutex to be unlocked.
This bug has been detected by the Clang thread-safety checker.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>
Cc: linux-input@vger.kernel.org
Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/input/rmi4/rmi_f54.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index ac4041a69fcd..fd57ebb1cb50 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
int i;
report_size = rmi_f54_get_report_size(f54);
+
+ mutex_lock(&f54->data_mutex);
+
if (report_size == 0) {
dev_err(&fn->dev, "Bad report size, report type=%d\n",
f54->report_type);
@@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
goto error; /* retry won't help */
}
- mutex_lock(&f54->data_mutex);
-
/*
* Need to check if command has completed.
* If not try again later.
^ permalink raw reply related
* [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
From: Bart Van Assche @ 2026-02-23 21:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Dmitry Torokhov, Nick Dyer, linux-input
In-Reply-To: <20260223215118.2154194-1-bvanassche@acm.org>
Lock f54->data_mutex before the first 'goto error' statement since
jumping to the 'error' label causes that mutex to be unlocked.
This bug has been detected by the Clang thread-safety checker.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>
Cc: linux-input@vger.kernel.org
Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/input/rmi4/rmi_f54.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index ac4041a69fcd..fd57ebb1cb50 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
int i;
report_size = rmi_f54_get_report_size(f54);
+
+ mutex_lock(&f54->data_mutex);
+
if (report_size == 0) {
dev_err(&fn->dev, "Bad report size, report type=%d\n",
f54->report_type);
@@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
goto error; /* retry won't help */
}
- mutex_lock(&f54->data_mutex);
-
/*
* Need to check if command has completed.
* If not try again later.
^ permalink raw reply related
* Re: [PATCH] Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table
From: Dmitry Torokhov @ 2026-02-23 21:54 UTC (permalink / raw)
To: Werner Sembach; +Cc: Christoffer Sandberg, linux-input, linux-kernel
In-Reply-To: <20260223142054.50310-1-wse@tuxedocomputers.com>
On Mon, Feb 23, 2026 at 03:20:45PM +0100, Werner Sembach wrote:
> From: Christoffer Sandberg <cs@tuxedo.de>
>
> The device occasionally wakes up from suspend with missing input on the
> internal keyboard and the following suspend attempt results in an instant
> wake-up. The quirks fix both issues for this device.
>
> Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: (subset) [PATCH v6 0/6] Input: imx6ul_tsc - set glitch threshold by dts property
From: Frank Li @ 2026-02-23 21:57 UTC (permalink / raw)
To: linux-kernel, Dario Binacchi
Cc: Frank Li, linux-amarula, Conor Dooley, Dmitry Torokhov,
Fabio Estevam, Haibo Chen, Javier Carrasco, Jeff LaBundy,
Krzysztof Kozlowski, Michael Trimarchi, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, Shawn Guo, devicetree, imx,
linux-arm-kernel, linux-input
In-Reply-To: <20250923143746.2857292-1-dario.binacchi@amarulasolutions.com>
On Tue, 23 Sep 2025 16:37:31 +0200, Dario Binacchi wrote:
> The series allows setting the glitch threshold for the detected signal
> from a DTS property instead of a hardcoded value.
> In addition, I applied a patch that replaces opencoded masking and
> shifting, with BIT(), GENMASK(), FIELD_GET() and FIELD_PREP() macros.
>
> I didn’t remove patches:
> - 2/6 Input: imx6ul_tsc - use BIT, FIELD_{GET,PREP} and GENMASK macros
> - 1/6 Input: imx6ul_tsc - fix typo in register name
> even though they were accepted, to avoid generating conflicts detected
> by the kernel test robot.
>
> [...]
Applied, thanks!
[5/6] ARM: dts: imx6ull-engicam-microgea-bmm: set touchscreen glitch threshold
commit: a96f415ab504484f10673be0d0d9c0e502ca9290
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
From: Dmitry Torokhov @ 2026-02-23 21:58 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Nick Dyer, linux-input
In-Reply-To: <20260223215118.2154194-16-bvanassche@acm.org>
Hi Bart,
On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
> Lock f54->data_mutex before the first 'goto error' statement since
> jumping to the 'error' label causes that mutex to be unlocked.
>
> This bug has been detected by the Clang thread-safety checker.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Nick Dyer <nick@shmanahar.org>
> Cc: linux-input@vger.kernel.org
> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> drivers/input/rmi4/rmi_f54.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index ac4041a69fcd..fd57ebb1cb50 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
> int i;
>
> report_size = rmi_f54_get_report_size(f54);
> +
> + mutex_lock(&f54->data_mutex);
> +
Thank you for the patch. Do you mind if I move mutex_lock() above the
call to rmi_f54_get_report_size()? It does not extend critical section
by much, and I think logically makes more sense.
> if (report_size == 0) {
> dev_err(&fn->dev, "Bad report size, report type=%d\n",
> f54->report_type);
> @@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
> goto error; /* retry won't help */
> }
>
> - mutex_lock(&f54->data_mutex);
> -
> /*
> * Need to check if command has completed.
> * If not try again later.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: input: mtk-pmic-keys: add MT6392 binding definition
From: Dmitry Torokhov @ 2026-02-23 22:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Eddie Huang, Alexandre Belloni, Julien Massot,
Louis-Alexis Eyraud, Gary Bisson, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-rtc
In-Reply-To: <056cbc09fcbb4a2845cece69209a2a564d993ac5.1771865015.git.l.scorcia@gmail.com>
On Mon, Feb 23, 2026 at 05:12:42PM +0000, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the binding documentation of the mtk-pmic-keys for the MT6392 PMICs.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please merge with the rest of the series.
> ---
> Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
> index b95435bd6a9b..2d3c4161a7f8 100644
> --- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
> +++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
> @@ -30,6 +30,7 @@ properties:
> - mediatek,mt6357-keys
> - mediatek,mt6358-keys
> - mediatek,mt6359-keys
> + - mediatek,mt6392-keys
> - mediatek,mt6397-keys
>
> power-off-time-sec: true
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
From: Bart Van Assche @ 2026-02-23 22:00 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Dmitry Torokhov, Nick Dyer, linux-input
In-Reply-To: <20260223220102.2158611-1-bart.vanassche@linux.dev>
From: Bart Van Assche <bvanassche@acm.org>
Lock f54->data_mutex before the first 'goto error' statement since
jumping to the 'error' label causes that mutex to be unlocked.
This bug has been detected by the Clang thread-safety checker.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Nick Dyer <nick@shmanahar.org>
Cc: linux-input@vger.kernel.org
Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/input/rmi4/rmi_f54.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index ac4041a69fcd..fd57ebb1cb50 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
int i;
report_size = rmi_f54_get_report_size(f54);
+
+ mutex_lock(&f54->data_mutex);
+
if (report_size == 0) {
dev_err(&fn->dev, "Bad report size, report type=%d\n",
f54->report_type);
@@ -546,8 +549,6 @@ static void rmi_f54_work(struct work_struct *work)
goto error; /* retry won't help */
}
- mutex_lock(&f54->data_mutex);
-
/*
* Need to check if command has completed.
* If not try again later.
^ permalink raw reply related
* Re: [PATCH v3 5/9] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Dmitry Torokhov @ 2026-02-23 22:02 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Svyatoslav Ryhel, Pavel Machek, Conor Dooley, devicetree,
David Lechner, linux-input, Krzysztof Kozlowski, Lee Jones,
Mark Brown, Tony Lindgren, linux-kernel, Liam Girdwood,
linux-leds
In-Reply-To: <177186521369.3975744.16898258990517269078.robh@kernel.org>
On Mon, Feb 23, 2026 at 10:46:54AM -0600, Rob Herring (Arm) wrote:
>
> On Mon, 23 Feb 2026 08:38:54 +0200, Svyatoslav Ryhel wrote:
> > Convert power button devicetree bindings for the Motorola CPCAP MFD from
> > TXT to YAML format. This patch does not change any functionality; the
> > bindings remain the same.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > 2 files changed, 32 insertions(+), 20 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> >
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please merge with the rest of the series.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 15/62] Input: synaptics-rmi4 - fix a locking bug in an error path
From: Bart Van Assche @ 2026-02-23 22:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
linux-kernel, Marco Elver, Christoph Hellwig, Steven Rostedt,
Nick Desaulniers, Nathan Chancellor, Kees Cook, Jann Horn,
Nick Dyer, linux-input
In-Reply-To: <aZzNSRIJdboXTV2-@google.com>
On 2/23/26 1:58 PM, Dmitry Torokhov wrote:
> Hi Bart,
>
> On Mon, Feb 23, 2026 at 01:50:30PM -0800, Bart Van Assche wrote:
>> Lock f54->data_mutex before the first 'goto error' statement since
>> jumping to the 'error' label causes that mutex to be unlocked.
>>
>> This bug has been detected by the Clang thread-safety checker.
>>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Cc: Nick Dyer <nick@shmanahar.org>
>> Cc: linux-input@vger.kernel.org
>> Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>> drivers/input/rmi4/rmi_f54.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
>> index ac4041a69fcd..fd57ebb1cb50 100644
>> --- a/drivers/input/rmi4/rmi_f54.c
>> +++ b/drivers/input/rmi4/rmi_f54.c
>> @@ -539,6 +539,9 @@ static void rmi_f54_work(struct work_struct *work)
>> int i;
>>
>> report_size = rmi_f54_get_report_size(f54);
>> +
>> + mutex_lock(&f54->data_mutex);
>> +
>
> Thank you for the patch. Do you mind if I move mutex_lock() above the
> call to rmi_f54_get_report_size()? It does not extend critical section
> by much, and I think logically makes more sense.
That sounds good to me. Please keep in mind that I'm not familiar with
the rmi4 driver.
Thanks,
Bart.
^ permalink raw reply
* [PATCH 37/37] PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
The function pcim_enable_device() sets the is_managed flag, which
causes the device's IRQ vectors to be automatically managed and released
by the devres framework. If a driver subsequently calls
pci_free_irq_vectors() manually, it can lead to a double-free of the
interrupt resources.
Analysis reveals most PCI drivers call pci_free_irq_vectors()
while also using pcim_enable_device(), making them susceptible to this
double-free issue. In contrast, 35 drivers follow the pattern of
relying on devres to handle the cleanup.
To address this inconsistency and enforce explicit, driver-managed
control of IRQ vectors, this patch removes the pci_is_managed() check
from pcim_setup_msi_release() and let devres help cleanup if is_msi_managed
is true. This change ensures that interrupt vectors are not automatically
freed by the devres machinery when pcim_enable_device() is used, placing
the responsibility for their release squarely on the driver logic via
pci_free_irq_vectors(). If the driver need devres to help cleanup, newly added
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() helpers could be used.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/pci/msi/msi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 81d24a2..0727a0a 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -70,7 +70,6 @@ static void pcim_msi_release(void *pcidev)
{
struct pci_dev *dev = pcidev;
- dev->is_msi_managed = false;
pci_free_irq_vectors(dev);
}
@@ -92,14 +91,13 @@ static int pcim_setup_msi_release(struct pci_dev *dev)
{
int ret;
- if (!pci_is_managed(dev) || dev->is_msi_managed)
+ if (!dev->is_msi_managed)
return 0;
ret = devm_add_action(&dev->dev, pcim_msi_release, dev);
if (ret)
return ret;
- dev->is_msi_managed = true;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [syzbot] [input?] possible deadlock in input_repeat_key
From: syzbot @ 2026-02-23 22:46 UTC (permalink / raw)
To: amir73il, jack, linux-fsdevel, linux-input, linux-kernel,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: a95f71ad3e2e Merge tag 'for-linus' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17db0152580000
kernel config: https://syzkaller.appspot.com/x/.config?x=665cbf0979cda6c5
dashboard link: https://syzkaller.appspot.com/bug?extid=422e601066bf071a9f8e
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3abe9dfc8715/disk-a95f71ad.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0a4dab480d10/vmlinux-a95f71ad.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d2eecb72d9bd/bzImage-a95f71ad.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+422e601066bf071a9f8e@syzkaller.appspotmail.com
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
syzkaller #0 Tainted: G L
-----------------------------------------------------
syz.0.6889/23959 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffff88805533cf30 (&new->fa_lock){....}-{3:3}, at: kill_fasync_rcu fs/fcntl.c:1135 [inline]
ffff88805533cf30 (&new->fa_lock){....}-{3:3}, at: kill_fasync+0x199/0x4d0 fs/fcntl.c:1159
and this task is already holding:
ffff88802bb32230 (&dev->event_lock#2){..-.}-{3:3}, at: class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
ffff88802bb32230 (&dev->event_lock#2){..-.}-{3:3}, at: input_inject_event+0xa5/0x340 drivers/input/input.c:419
which would create a new lock dependency:
(&dev->event_lock#2){..-.}-{3:3} -> (&new->fa_lock){....}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(&dev->event_lock#2){..-.}-{3:3}
... which became SOFTIRQ-irq-safe at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_repeat_key+0x33/0x680 drivers/input/input.c:2220
call_timer_fn+0x192/0x640 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2373 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2385
run_timer_base kernel/time/timer.c:2394 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2404
handle_softirqs+0x22a/0x870 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x5f/0x150 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
rcu_is_watching+0x70/0xb0 kernel/rcu/tree.c:754
rcu_read_lock_held_common kernel/rcu/update.c:109 [inline]
rcu_read_lock_held+0x15/0x50 kernel/rcu/update.c:349
mas_root lib/maple_tree.c:780 [inline]
mas_start+0x1e9/0x560 lib/maple_tree.c:1200
mas_state_walk lib/maple_tree.c:3291 [inline]
mas_walk+0x8b/0x2e0 lib/maple_tree.c:4599
lock_vma_under_rcu+0x1bd/0x500 mm/mmap_lock.c:304
do_user_addr_fault+0x2d8/0x1340 arch/x86/mm/fault.c:1325
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
to a SOFTIRQ-irq-unsafe lock:
(tasklist_lock){.+.+}-{3:3}
... which became SOFTIRQ-irq-unsafe at:
...
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x36/0x50 kernel/locking/spinlock.c:228
__do_wait+0xde/0x740 kernel/exit.c:1672
do_wait+0x1e7/0x540 kernel/exit.c:1716
kernel_wait+0xd6/0x1c0 kernel/exit.c:1892
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xbe/0x230 kernel/umh.c:163
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&dev->event_lock#2 --> &new->fa_lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock#2);
lock(&new->fa_lock);
<Interrupt>
lock(&dev->event_lock#2);
*** DEADLOCK ***
6 locks held by syz.0.6889/23959:
#0: ffff88802bc7c118 (&evdev->mutex){+.+.}-{4:4}, at: evdev_write+0x1ae/0x4c0 drivers/input/evdev.c:511
#1: ffff88802bb32230 (&dev->event_lock#2){..-.}-{3:3}, at: class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
#1: ffff88802bb32230 (&dev->event_lock#2){..-.}-{3:3}, at: input_inject_event+0xa5/0x340 drivers/input/input.c:419
#2: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#2: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#2: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: class_rcu_constructor include/linux/rcupdate.h:1193 [inline]
#2: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: input_inject_event+0xb6/0x340 drivers/input/input.c:420
#3: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#3: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#3: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: class_rcu_constructor include/linux/rcupdate.h:1193 [inline]
#3: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: input_pass_values+0x8d/0x890 drivers/input/input.c:119
#4: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#4: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#4: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: mousedev_notify_readers+0x2c/0xc00 drivers/input/mousedev.c:269
#5: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#5: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#5: ffffffff8e7602e0 (rcu_read_lock){....}-{1:3}, at: kill_fasync+0x53/0x4d0 fs/fcntl.c:1158
the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
-> (&dev->event_lock#2){..-.}-{3:3} {
IN-SOFTIRQ-W at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_repeat_key+0x33/0x680 drivers/input/input.c:2220
call_timer_fn+0x192/0x640 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2373 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2385
run_timer_base kernel/time/timer.c:2394 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2404
handle_softirqs+0x22a/0x870 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x5f/0x150 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
rcu_is_watching+0x70/0xb0 kernel/rcu/tree.c:754
rcu_read_lock_held_common kernel/rcu/update.c:109 [inline]
rcu_read_lock_held+0x15/0x50 kernel/rcu/update.c:349
mas_root lib/maple_tree.c:780 [inline]
mas_start+0x1e9/0x560 lib/maple_tree.c:1200
mas_state_walk lib/maple_tree.c:3291 [inline]
mas_walk+0x8b/0x2e0 lib/maple_tree.c:4599
lock_vma_under_rcu+0x1bd/0x500 mm/mmap_lock.c:304
do_user_addr_fault+0x2d8/0x1340 arch/x86/mm/fault.c:1325
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
INITIAL USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:162
class_spinlock_irqsave_constructor include/linux/spinlock.h:618 [inline]
input_inject_event+0xa5/0x340 drivers/input/input.c:419
kbd_led_trigger_activate+0xbc/0x100 drivers/tty/vt/keyboard.c:1021
led_trigger_set+0x535/0x960 drivers/leds/led-triggers.c:220
led_match_default_trigger drivers/leds/led-triggers.c:277 [inline]
led_trigger_set_default+0x260/0x2a0 drivers/leds/led-triggers.c:300
led_classdev_register_ext+0x787/0x9c0 drivers/leds/led-class.c:578
led_classdev_register include/linux/leds.h:274 [inline]
input_leds_connect+0x517/0x790 drivers/input/input-leds.c:145
input_attach_handler drivers/input/input.c:994 [inline]
input_register_device+0xd00/0x1160 drivers/input/input.c:2378
atkbd_connect+0x731/0xa50 drivers/input/keyboard/atkbd.c:1340
serio_connect_driver drivers/input/serio/serio.c:44 [inline]
serio_driver_probe+0x82/0xd0 drivers/input/serio/serio.c:748
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x267/0xaf0 drivers/base/dd.c:661
__driver_probe_device+0x18c/0x320 drivers/base/dd.c:803
driver_probe_device+0x4f/0x240 drivers/base/dd.c:833
__driver_attach+0x3e7/0x710 drivers/base/dd.c:1227
bus_for_each_dev+0x23b/0x2c0 drivers/base/bus.c:383
serio_attach_driver drivers/input/serio/serio.c:777 [inline]
serio_handle_event+0x20a/0xdd0 drivers/input/serio/serio.c:214
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff9a6053c0>] input_allocate_device.__key.7+0x0/0x20
the dependencies between the lock to be acquired
and SOFTIRQ-irq-unsafe lock:
-> (tasklist_lock){.+.+}-{3:3} {
HARDIRQ-ON-R at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x36/0x50 kernel/locking/spinlock.c:228
__do_wait+0xde/0x740 kernel/exit.c:1672
do_wait+0x1e7/0x540 kernel/exit.c:1716
kernel_wait+0xd6/0x1c0 kernel/exit.c:1892
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xbe/0x230 kernel/umh.c:163
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
SOFTIRQ-ON-R at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x36/0x50 kernel/locking/spinlock.c:228
__do_wait+0xde/0x740 kernel/exit.c:1672
do_wait+0x1e7/0x540 kernel/exit.c:1716
kernel_wait+0xd6/0x1c0 kernel/exit.c:1892
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xbe/0x230 kernel/umh.c:163
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INITIAL USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x3d/0x50 kernel/locking/spinlock.c:326
copy_process+0x247a/0x3cf0 kernel/fork.c:2369
kernel_clone+0x248/0x8e0 kernel/fork.c:2654
user_mode_thread+0x110/0x180 kernel/fork.c:2730
rest_init+0x23/0x300 init/main.c:725
start_kernel+0x385/0x3d0 init/main.c:1210
x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0x143/0x1c0 arch/x86/kernel/head64.c:291
common_startup_64+0x13e/0x147
INITIAL READ USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x36/0x50 kernel/locking/spinlock.c:228
__do_wait+0xde/0x740 kernel/exit.c:1672
do_wait+0x1e7/0x540 kernel/exit.c:1716
kernel_wait+0xd6/0x1c0 kernel/exit.c:1892
call_usermodehelper_exec_sync kernel/umh.c:136 [inline]
call_usermodehelper_exec_work+0xbe/0x230 kernel/umh.c:163
process_one_work kernel/workqueue.c:3275 [inline]
process_scheduled_works+0xb02/0x1830 kernel/workqueue.c:3358
worker_thread+0xa50/0xfc0 kernel/workqueue.c:3439
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
}
... key at: [<ffffffff8e40c058>] tasklist_lock+0x18/0x40
... acquired at:
__raw_read_lock include/linux/rwlock_api_smp.h:161 [inline]
_raw_read_lock+0x36/0x50 kernel/locking/spinlock.c:228
send_sigio+0x101/0x370 fs/fcntl.c:932
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync+0x24d/0x4d0 fs/fcntl.c:1159
sock_wake_async+0x137/0x160 net/socket.c:-1
sk_wake_async_rcu include/net/sock.h:2579 [inline]
sock_def_readable+0x3c1/0x580 net/core/sock.c:3613
unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2480
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0xa68/0xad0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&f_owner->lock){....}-{3:3} {
INITIAL USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x3d/0x50 kernel/locking/spinlock.c:326
__f_setown+0x67/0x370 fs/fcntl.c:136
fcntl_dirnotify+0x3f9/0x6a0 fs/notify/dnotify/dnotify.c:369
do_fcntl+0x77e/0x1a20 fs/fcntl.c:538
__do_sys_fcntl fs/fcntl.c:602 [inline]
__se_sys_fcntl+0xc8/0x150 fs/fcntl.c:587
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x48/0x60 kernel/locking/spinlock.c:236
send_sigio+0x38/0x370 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync+0x24d/0x4d0 fs/fcntl.c:1159
sock_wake_async+0x137/0x160 net/socket.c:-1
sk_wake_async_rcu include/net/sock.h:2579 [inline]
sock_def_readable+0x3c1/0x580 net/core/sock.c:3613
unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2480
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0xa68/0xad0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff9a2e6160>] file_f_owner_allocate.__key+0x0/0x20
... acquired at:
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x48/0x60 kernel/locking/spinlock.c:236
send_sigio+0x38/0x370 fs/fcntl.c:918
kill_fasync_rcu fs/fcntl.c:1144 [inline]
kill_fasync+0x24d/0x4d0 fs/fcntl.c:1159
sock_wake_async+0x137/0x160 net/socket.c:-1
sk_wake_async_rcu include/net/sock.h:2579 [inline]
sock_def_readable+0x3c1/0x580 net/core/sock.c:3613
unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2480
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0xa68/0xad0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> (&new->fa_lock){....}-{3:3} {
INITIAL USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_write_lock_irq include/linux/rwlock_api_smp.h:211 [inline]
_raw_write_lock_irq+0x3d/0x50 kernel/locking/spinlock.c:326
fasync_remove_entry+0xf1/0x1c0 fs/fcntl.c:1012
sock_fasync+0x85/0xf0 net/socket.c:1480
__fput+0x8a5/0xa70 fs/file_table.c:466
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
INITIAL READ USE at:
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x48/0x60 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync+0x199/0x4d0 fs/fcntl.c:1159
sock_wake_async+0x137/0x160 net/socket.c:-1
sk_wake_async_rcu include/net/sock.h:2579 [inline]
sock_def_readable+0x3c1/0x580 net/core/sock.c:3613
unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2480
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0xa68/0xad0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
}
... key at: [<ffffffff9a2e6180>] fasync_insert_entry.__key+0x0/0x20
... acquired at:
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x48/0x60 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync+0x199/0x4d0 fs/fcntl.c:1159
mousedev_notify_readers+0x6f1/0xc00 drivers/input/mousedev.c:309
mousedev_event+0x602/0x1320 drivers/input/mousedev.c:394
input_handle_events_default+0xd4/0x1a0 drivers/input/input.c:2541
input_pass_values+0x288/0x890 drivers/input/input.c:128
input_event_dispose+0x330/0x6b0 drivers/input/input.c:342
input_inject_event+0x1dd/0x340 drivers/input/input.c:424
evdev_write+0x325/0x4c0 drivers/input/evdev.c:528
vfs_write+0x29a/0xb90 fs/read_write.c:686
ksys_write+0x150/0x270 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
stack backtrace:
CPU: 1 UID: 0 PID: 23959 Comm: syz.0.6889 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_bad_irq_dependency kernel/locking/lockdep.c:2616 [inline]
check_irq_usage kernel/locking/lockdep.c:2857 [inline]
check_prev_add kernel/locking/lockdep.c:3169 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x2a94/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:172 [inline]
_raw_read_lock_irqsave+0x48/0x60 kernel/locking/spinlock.c:236
kill_fasync_rcu fs/fcntl.c:1135 [inline]
kill_fasync+0x199/0x4d0 fs/fcntl.c:1159
mousedev_notify_readers+0x6f1/0xc00 drivers/input/mousedev.c:309
mousedev_event+0x602/0x1320 drivers/input/mousedev.c:394
input_handle_events_default+0xd4/0x1a0 drivers/input/input.c:2541
input_pass_values+0x288/0x890 drivers/input/input.c:128
input_event_dispose+0x330/0x6b0 drivers/input/input.c:342
input_inject_event+0x1dd/0x340 drivers/input/input.c:424
evdev_write+0x325/0x4c0 drivers/input/evdev.c:528
vfs_write+0x29a/0xb90 fs/read_write.c:686
ksys_write+0x150/0x270 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1f91b9c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f1f92b1f028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f1f91e15fa0 RCX: 00007f1f91b9c629
RDX: 0000000000000918 RSI: 0000200000000040 RDI: 0000000000000004
RBP: 00007f1f91c32b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f1f91e16038 R14: 00007f1f91e15fa0 R15: 00007f1f91f3fa48
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: add GPIO charlieplex keypad
From: Rob Herring @ 2026-02-23 23:23 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: hvilleneuve, dmitry.torokhov, krzk+dt, conor+dt, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260223134738.00988a3d87165cb130292c89@hugovil.com>
On Mon, Feb 23, 2026 at 12:47 PM Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> Hi Rob,
>
> On Mon, 23 Feb 2026 11:57:06 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > On Fri, Feb 13, 2026 at 12:14:25PM -0500, Hugo Villeneuve wrote:
> > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > >
> > > Add DT bindings for GPIO charlieplex keypad.
> > >
> > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > ---
> > > .../input/gpio-charlieplex-keypad.yaml | 82 +++++++++++++++++++
> > > 1 file changed, 82 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > new file mode 100644
> > > index 0000000000000..1672491a75a85
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > > @@ -0,0 +1,82 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +
> > > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: GPIO charlieplex keypad
> > > +
> > > +maintainers:
> > > + - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > +
> > > +description:
> > > + The charlieplex keypad supports N^2)-N different key combinations (where N is
> > > + the number of lines). Key presses and releases are detected by configuring
> > > + only one line as output at a time, and reading other line states. This process
> > > + is repeated for each line.
> > > + This mechanism doesn't allow to detect simultaneous key presses.
> > > +
> > > +allOf:
> > > + - $ref: input.yaml#
> > > + - $ref: /schemas/input/matrix-keymap.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + const: gpio-charlieplex-keypad
> > > +
> > > + autorepeat: true
> > > +
> > > + line-scan-delay-us:
> > > + description:
> > > + Delay, measured in microseconds, that is needed
> > > + before we can scan keypad after activating one line.
> > > + default: 0
> >
> > Isn't this the same as "col-scan-delay-us" in gpio-matrix-keypad.yaml?
> > If so, move it to matrix-keymap.yaml to re-use it here.
>
> It is used in a similar fashion, but for charlieplex keyboard, there is
> no concept of "rows" and "columns". There are only
> lines, which are all equivalent in functionality.
>
> > If not, there's a bunch of other scan delay properties just from
> > grepping "delay" in the input bindings. Surely we can define something
> > common.
>
> Most of those delays refer to something quite different than what
> "col-scan-delay-us" or "line-scan-delay-us" are used for (it is a delay
> that we wait when activating a GPIO before we can safely/reliably read
> other GPIOs connected thru its circuitry).
>
> Maybe "col-scan-delay-us" and "line-scan-delay-us" could be
> combined into a common "line-scan-delay-us" ("line" is more generic
> than column), and defined in matrix-keymap.yaml.
What about "scan-delay-us"? I would assume all the scan delay
properties are just the delay after changing the outputs to reading
the inputs.
> Then would it be ok to remove "col-scan-delay-us" from
> gpio-matrix-keypad.yaml and use "line-scan-delay-us" (ABI change) ?
No!
Rob
^ permalink raw reply
* Re: [PATCH v7 0/3] TrackPoint doubletap enablement and user control
From: Vishnu Sankar @ 2026-02-23 23:28 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar
In-Reply-To: <20260209063355.491189-1-vishnuocv@gmail.com>
Hi,
Gentle ping on this series.
This is v7 addressing all previous review comments.
Please let me know if any further changes are needed.
Thanks,
Vishnu
On Mon, Feb 9, 2026 at 3:34 PM Vishnu Sankar <vishnuocv@gmail.com> wrote:
>
> This patch series adds support for TrackPoint doubletap with a clear and
> simple separation of responsibilities between drivers:
>
> 1. Firmware enablement (trackpoint.c):
> Automatically enables doubletap on capable hardware during device
> detection.
>
> 2. User control (thinkpad_acpi.c):
> Provides a sysfs interface to enable or disable delivery of doubletap
> events to userspace.
>
> The approach follows the KISS principle:
> - The TrackPoint driver enables hardware functionality by default.
> - The thinkpad_acpi driver controls whether ACPI doubletap events are
> delivered, using existing hotkey filtering infrastructure.
> - No cross-driver APIs or dual filtering paths are introduced.
>
> Changes in v7:
> - Removed unwanted comments and logs
>
> Changes in v6:
> - Documentation: fix formatting of the doubletap_enable sysfs attribute
> description (separate "Values" list)
>
> Changes in v5:
> - Rename sysfs attribute from doubletap_filter to doubletap_enable to
> reflect actual behavior.
> - Fix inverted logic so events are delivered only when doubletap is
> enabled.
> - Suppress ACPI hotkey delivery instead of injecting or filtering input
> events.
> - Register the sysfs attribute via hotkey_attributes[] instead of
> device_create_file().
> - Drop unnecessary helper wrappers and debug logging.
> - Update Documentation to reflect the new naming and semantics.
>
> Changes in v4:
> - Complete redesign based on reviewer feedback.
> - trackpoint.c: Simplified to only enable doubletap by default.
> - trackpoint.c: Removed all sysfs attributes and global variables.
> - trackpoint.c: Uses firmware ID detection with deny list.
> - thinkpad_acpi.c: Added sysfs interface for kernel-level event control.
> - thinkpad_acpi.c: No cross-driver dependencies.
> - Documentation: Updated to reflect simplified sysfs approach.
>
> Changes in v3:
> - No changes.
>
> Changes in v2:
> - Improved commit messages.
> - Removed unnecessary comments and debug messages.
> - Switched to strstarts() usage.
> - Simplified firmware capability detection logic.
>
> This version addresses the remaining review feedback by correcting the
> naming and logic inversion, aligning sysfs semantics with behavior, and
> fully integrating with existing thinkpad_acpi hotkey handling.
>
> Vishnu Sankar (3):
> input: trackpoint - Enable doubletap by default on capable devices
> platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint
> double-tap
> Documentation: thinkpad-acpi - Document doubletap_enable attribute
>
> .../admin-guide/laptops/thinkpad-acpi.rst | 21 +++++++++
> drivers/input/mouse/trackpoint.c | 45 +++++++++++++++++++
> drivers/input/mouse/trackpoint.h | 5 +++
> drivers/platform/x86/lenovo/thinkpad_acpi.c | 42 ++++++++++++++---
> 4 files changed, 106 insertions(+), 7 deletions(-)
>
> --
> 2.51.0
>
--
Regards,
Vishnu Sankar
^ permalink raw reply
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Jakub Kicinski @ 2026-02-24 0:04 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, Philipp Stanner, netdev,
nic_swsd, linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <1771860581-82092-2-git-send-email-shawn.lin@rock-chips.com>
On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> pci device drivers which rely on the devres machinery to help cleanup the IRQ
> vectors.
If you can please add this API with just a few users, and then convert
remaining users via the subsystem trees in the next cycle.
There's no need to risk wasting maintainer time on conflicts with
conversions like this.
^ permalink raw reply
* Re: [PATCH] ARM: dts: qcom: msm8960: expressatt: Add coreriver,tc360-touchkey
From: Rudraksha Gupta @ 2026-02-24 1:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel, beomho.seo, jcsing.lee, linux-input,
nick.reitemeyer
In-Reply-To: <aZvPUn2RxUHDahfO@google.com>
On 2/22/26 19:54, Dmitry Torokhov wrote:
> Hi Rudraksha,
>
> On Thu, Feb 19, 2026 at 08:33:43PM -0800, Rudraksha Gupta wrote:
>> Hello all,
>>
>>
>> Top posting for once (context below).
>>
>> Not too sure what the next steps are to get the tm2 touchkey in. Should I
>> resend the patch, contact someone else that can help provide guidance, or
>> something else?
>>
>>
>> Adding Dmitry Torokhov (official maintainer) and Nick Reitemeyer (person who
>> introduced this variant).
> Sorry, I am not sure what the question is... It seems that you made the
> driver work without any additional changes?
I believe this patch is blocked on Konrad's comment:
> This driver mentions a register called CYPRESS_MODULE_VER - maybe
it could help confirm the model?
This was in response to me saying that the "coreriver,tc360-touchkey"
tm2 variant works as is on my device, but I can't tell for sure if this
is actually the variant that is on my device. There isn't really any
documentation for how this peripheral works and I was primarily relying
on others in this thread to provide details to confirm that this is the
actual variant being used.
If I'm mistaken that this is a blocker, please let me know.
Thanks,
Rudraksha
^ permalink raw reply
* [PATCH v5 00/16] HID: Add Legion Go and Go S Drivers
From: Derek J. Clark @ 2026-02-24 1:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Richard Hughes, Mario Limonciello, Zhixin Zhang, Mia Shao,
Mark Pearson, Pierre-Loup A . Griffais, Derek J . Clark,
linux-input, linux-doc, linux-kernel
This series adds configuration driver support for the Legion Go S,
Legion Go, and Legion Go 2 built-in controller HID interfaces. This
allows for configuring hardware specific attributes such as the auso
sleep timeout, rumble intensity, etc. non-configuration reports are
forwarded to the HID subsystem to ensure no loss of functionality in
userspace. Basic gamepad functionality is provided through xpad, while
advanced features are currently only implemented in userspace daemons
such as InputPlumber[1]. I plan to move this functionality into the
kernel in a later patch series.
Three new device.h macros are added that solve a fairly specific
problem. Many of the attributes need to have the same name as other
attributes when they are in separate attribute subdirectories. The
previous version of this series, along with the upcoming his-asus-ally
driver[2] use this macro to simplify the sysfs by removing redundancy.
An upcoming out of tree driver for the Zotac Zone [3] also found this
macro to be useful. This greatly reduces the path length and term
redundancy of file paths in the sysfs, while also allowing for cleaner
subdirectories that are grouped by functionality. Rather than carry the
same macro in four drivers, it seems beneficial to me that we include the
macro with the other device macros.
A new HID uevent property is also added, HID_FIRMWARE_VERSION, so as to
permit fwupd to read the firmware version of the Go S HID interface without
detaching the kernel driver.
Finally, there are some checkpatch warnings that will need to be supressed:
WARNING: ENOSYS means 'invalid syscall nr' and nothing else
1292: FILE: drivers/hid/lenovo-legos-hid/lenovo-legos-hid-config.c:1085:
+ case -ENOSYS: /* during rmmod -ENOSYS is expected */
This error handling case was added as it is experienced in the real world
when the driver is rmmod. The LED subsystem produces this error code in
its legacy code and this is not a new novel use of -ENOSYS, we are simply
catching the case to avoid spurious errors in dmesg when the drivers are
removed.
[1]: https://github.com/ShadowBlip/InputPlumber/tree/main/src/drivers/lego
[2]: https://lore.kernel.org/all/20240806081212.56860-1-luke@ljones.dev/
[3]: https://github.com/flukejones/linux/tree/wip/zotac-zone-6.15/drivers/hid/zotac-zone-hid
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
---
Change Log
v5:
- Make all RO attributes cache the data during probe using delayed
work for both drivers. All RW attributes are read in realtime to
ensure they match the device current state in the event of firmware
reset or a userspace application.
- Fix endianness of version strings and print as hex for Go driver.
- Remove reset__esume function. It was not being hit as the MCU of
both devices disconnects of suspend, forcing a reinit of the driver.
Udev or userpsace will need to set the OS Mode upon resume.
v4: https://lore.kernel.org/linux-input/20260220070533.4083667-1-derekjohn.clark@gmail.com/
- Use dmabuf allocated per request for both drivers instead of a devm
preallocated buffer that is reused. This solves a bug where some
attributes couldn't be restored without manual writing after resume.
- Reduce the number of quirks and flags in the Go S init to only those
necessary. Previously they were duplicated from the Go driver but
everything except HID_CONNECT_HIDRAW was found to be unnessary
during operational testing.
- Clean up formatting for debug prints in Go S driver.
- Fix bugs in RGB driver for Go that caused the effect to switch to
solid when the speed or brightness was changed.
- Remove extraneous setting of os_mode member of drvdata when setting
os_mode. It will be read from the hardware in _show.
v3: https://lore.kernel.org/linux-input/20260124014907.991265-1-derekjohn.clark@gmail.com/
- Fix Documentation formatting by removing extra + characters.
- Fix bugs in hid-lenovo-go-s IMU & TP RO attributes being tied to the
wrong _show function.
- Rename enume os_mode_index to os_mode_types_index to fix collision
with os_mode_index attribute.
- Remove accidental rename for enabled->enable attributes in patch 4
- Add SOB for Mario in patch 10 as Co-Developer.
v2: https://lore.kernel.org/linux-input/20251229031753.581664-1-derekjohn.clark@gmail.com/
- Break up adding the Go S driver into feature specific patches.
- Rename Go S driver from lenovo-legos-hid to hid-lenovo-go-s and move
it out of a subdirectory.
- Drop the arbitrary uevent properties patch.
- Add Go series driver.
- Move DEVICE_ATTR_NAMED macros to device.h.
v1: https://lore.kernel.org/linux-input/20250703004943.515919-1-derekjohn.clark@gmail.com/
Derek J. Clark (15):
include: device.h: Add named device attributes
HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
HID: hid-lenovo-go: Add Feature Status Attributes
HID: hid-lenovo-go: Add Rumble and Haptic Settings
HID: hid-lenovo-go: Add FPS Mode DPI settings
HID: hid-lenovo-go: Add RGB LED control interface
HID: hid-lenovo-go: Add Calibration Settings
HID: hid-lenovo-go: Add OS Mode Toggle
HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver
HID: hid-lenovo-go-s: Add MCU ID Attribute
HID: hid-lenovo-go-s: Add Feature Status Attributes
HID: hid-lenovo-go-s: Add Touchpad Mode Attributes
HID: hid-lenovo-go-s: Add RGB LED control interface
HID: hid-lenovo-go-s: Add IMU and Touchpad RO Attributes
HID: Add documentation for Lenovo Legion Go drivers
Mario Limonciello (1):
HID: Include firmware version in the uevent
.../ABI/testing/sysfs-driver-hid-lenovo-go | 724 +++++
.../ABI/testing/sysfs-driver-hid-lenovo-go-s | 304 ++
MAINTAINERS | 11 +
drivers/hid/Kconfig | 24 +
drivers/hid/Makefile | 2 +
drivers/hid/hid-core.c | 5 +
drivers/hid/hid-ids.h | 7 +
drivers/hid/hid-lenovo-go-s.c | 1509 ++++++++++
drivers/hid/hid-lenovo-go.c | 2497 +++++++++++++++++
include/linux/device.h | 46 +
include/linux/hid.h | 1 +
11 files changed, 5130 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s
create mode 100644 drivers/hid/hid-lenovo-go-s.c
create mode 100644 drivers/hid/hid-lenovo-go.c
--
2.52.0
^ permalink raw reply
* [PATCH v5 01/16] include: device.h: Add named device attributes
From: Derek J. Clark @ 2026-02-24 1:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Richard Hughes, Mario Limonciello, Zhixin Zhang, Mia Shao,
Mark Pearson, Pierre-Loup A . Griffais, Derek J . Clark,
linux-input, linux-doc, linux-kernel
In-Reply-To: <20260224013217.1363996-1-derekjohn.clark@gmail.com>
Adds DEVICE_ATTR_[RW|RO|WO]_NAMED macros for adding attributes that
reuse the same sysfs name in a driver under separate subdirectories.
When dealing with some devices it can be useful to be able to reuse
the same name for similar attributes under a different subdirectory.
For example, a single logical HID endpoint may provide a configuration
interface for multiple physical devices. In such a case it is useful to
provide symmetrical attribute names under different subdirectories on
the configuration device. The Lenovo Legion Go is one such device,
providing configuration to a detachable left controller, detachable
right controller, the wireless transmission dongle, and the MCU. It is
therefore beneficial to treat each of these as individual devices in
the driver, providing a subdirectory for each physical device in the
sysfs. As some attributes are reused by each physical device, it
provides a much cleaner interface if the same driver can reuse the same
attribute name in sysfs while uniquely distinguishing the store/show
functions in the driver, rather than repeat string portions.
Example new WO attrs:
ATTRS{left_handle/reset}=="(not readable)"
ATTRS{right_handle/reset}=="(not readable)"
ATTRS{tx_dongle/reset}=="(not readable)"
vs old WO attrs in a subdir:
ATTRS{left_handle/left_handle_reset}=="(not readable)"
ATTRS{right_handle/right_handle_reset}=="(not readable)"
ATTRS{tx_dongle/tx_dongle_reset}=="(not readable)"
or old WO attrs with no subdir:
ATTRS{left_handle_reset}=="(not readable)"
ATTRS{right_handle_reset}=="(not readable)"
ATTRS{tx_dongle_reset}=="(not readable)"
While the third option is usable, it doesn't logically break up the
physical devices and creates a device directory with over 80 attributes
once all attrs are defined.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
---
v4:
- Use dmabuf per request instead of devm allocated static buffer.
Resolves bug with side effects during suspend.
---
include/linux/device.h | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 0be95294b6e61..381463baed6d3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -189,6 +189,22 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
#define DEVICE_ATTR_ADMIN_RW(_name) \
struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
+/**
+ * DEVICE_ATTR_RW_NAMED - Define a read-write device attribute with a sysfs name
+ * that differs from the function name.
+ * @_name: Attribute function preface
+ * @_attrname: Attribute name as it wil be exposed in the sysfs.
+ *
+ * Like DEVICE_ATTR_RW(), but allows for reusing names under separate paths in
+ * the same driver.
+ */
+#define DEVICE_ATTR_RW_NAMED(_name, _attrname) \
+ struct device_attribute dev_attr_##_name = { \
+ .attr = { .name = _attrname, .mode = 0644 }, \
+ .show = _name##_show, \
+ .store = _name##_store, \
+ }
+
/**
* DEVICE_ATTR_RO - Define a readable device attribute.
* @_name: Attribute name.
@@ -207,6 +223,21 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
#define DEVICE_ATTR_ADMIN_RO(_name) \
struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
+/**
+ * DEVICE_ATTR_RO_NAMED - Define a read-only device attribute with a sysfs name
+ * that differs from the function name.
+ * @_name: Attribute function preface
+ * @_attrname: Attribute name as it wil be exposed in the sysfs.
+ *
+ * Like DEVICE_ATTR_RO(), but allows for reusing names under separate paths in
+ * the same driver.
+ */
+#define DEVICE_ATTR_RO_NAMED(_name, _attrname) \
+ struct device_attribute dev_attr_##_name = { \
+ .attr = { .name = _attrname, .mode = 0444 }, \
+ .show = _name##_show, \
+ }
+
/**
* DEVICE_ATTR_WO - Define an admin-only writable device attribute.
* @_name: Attribute name.
@@ -216,6 +247,21 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
#define DEVICE_ATTR_WO(_name) \
struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
+/**
+ * DEVICE_ATTR_WO_NAMED - Define a read-only device attribute with a sysfs name
+ * that differs from the function name.
+ * @_name: Attribute function preface
+ * @_attrname: Attribute name as it wil be exposed in the sysfs.
+ *
+ * Like DEVICE_ATTR_WO(), but allows for reusing names under separate paths in
+ * the same driver.
+ */
+#define DEVICE_ATTR_WO_NAMED(_name, _attrname) \
+ struct device_attribute dev_attr_##_name = { \
+ .attr = { .name = _attrname, .mode = 0200 }, \
+ .store = _name##_store, \
+ }
+
/**
* DEVICE_ULONG_ATTR - Define a device attribute backed by an unsigned long.
* @_name: Attribute name.
--
2.52.0
^ permalink raw reply related
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