* [PATCH v1 0/9] mfd: Add support for Asus Transformer embedded controller
From: Svyatoslav Ryhel @ 2026-02-01 10:43 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Svyatoslav Ryhel, Michał Mirosław,
Ion Agorria
Cc: devicetree, linux-kernel, linux-input, linux-leds, linux-pm
Add support for embedded controller used in Asus Transformers for
managing power and input functions.
Michał Mirosław (7):
misc: Support Asus Transformer's EC access device
mfd: Add driver for Asus Transformer embedded controller
input: serio: Add driver for Asus Transformer dock keyboard and
touchpad
input: keyboard: Add driver for Asus Transformer dock multimedia keys
leds: Add driver for Asus Transformer LEDs
power: supply: Add driver for Asus Transformer battery
power: supply: Add charger driver for Asus Transformers
Svyatoslav Ryhel (2):
dt-bindings: misc: document ASUS Transformers EC Dockram
dt-bindings: mfd: document ASUS Transformer EC
.../devicetree/bindings/mfd/asus,ec.yaml | 153 ++++++
.../bindings/misc/asus,dockram.yaml | 40 ++
drivers/input/keyboard/Kconfig | 10 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/asus-ec-keys.c | 285 +++++++++++
drivers/input/serio/Kconfig | 15 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/asus-ec-kbc.c | 162 ++++++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-asus-ec.c | 106 ++++
drivers/mfd/Kconfig | 14 +
drivers/mfd/Makefile | 1 +
drivers/mfd/asus-ec.c | 460 ++++++++++++++++++
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile | 1 +
drivers/misc/asus-dockram.c | 327 +++++++++++++
drivers/power/supply/Kconfig | 22 +
drivers/power/supply/Makefile | 2 +
drivers/power/supply/asus-ec-battery.c | 282 +++++++++++
drivers/power/supply/asus-ec-charger.c | 205 ++++++++
include/linux/mfd/asus-ec.h | 113 +++++
22 files changed, 2221 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/asus,ec.yaml
create mode 100644 Documentation/devicetree/bindings/misc/asus,dockram.yaml
create mode 100644 drivers/input/keyboard/asus-ec-keys.c
create mode 100644 drivers/input/serio/asus-ec-kbc.c
create mode 100644 drivers/leds/leds-asus-ec.c
create mode 100644 drivers/mfd/asus-ec.c
create mode 100644 drivers/misc/asus-dockram.c
create mode 100644 drivers/power/supply/asus-ec-battery.c
create mode 100644 drivers/power/supply/asus-ec-charger.c
create mode 100644 include/linux/mfd/asus-ec.h
--
2.51.0
^ permalink raw reply
* Re: [PATCH v6 1/3] input: trackpoint - Enable doubletap by default on capable devices
From: Dmitry Torokhov @ 2026-02-01 8:09 UTC (permalink / raw)
To: Vishnu Sankar
Cc: mpearson-lenovo, hmh, hansg, corbet, derekjohn.clark,
ilpo.jarvinen, linux-input, linux-kernel, ibm-acpi-devel,
linux-doc, platform-driver-x86, vsankar
In-Reply-To: <20260127103907.20269-2-vishnuocv@gmail.com>
Hi Vishnu,
On Tue, Jan 27, 2026 at 07:39:05PM +0900, Vishnu Sankar wrote:
> @@ -470,6 +509,14 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> psmouse->vendor, firmware_id,
> (button_info & 0xf0) >> 4, button_info & 0x0f);
>
> + /* Enable doubletap by default on capable devices */
This is obvious from the code, please drop the comment.
> + if (trackpoint_is_dt_capable(ps2dev->serio->firmware_id)) {
> + if (trackpoint_write(ps2dev, TP_DOUBLETAP, TP_DOUBLETAP_ENABLE))
> + psmouse_warn(psmouse, "Failed to enable doubletap: %d\n", error);
> + else
> + psmouse_info(psmouse, "Doubletap enabled by default!\n");
Drop psmouse_info(), no need to make the driver too noisy.
Otherwise:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:09 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <fca2c04b-fe1c-4685-9c80-b0d7d37ced60@baylibre.com>
сб, 31 січ. 2026 р. о 22:07 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> > Audio codec bindings adjusted with common ports node for port@0 and
> > port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> > same.
> >
>
> ...
>
> > +examples:
>
> Ah, I guess this covers all of the missing examples. The other commit
> messages should say that was the plan so we know why the examples were
> omitted in the other patches.
>
Subdevices schema state that they are part of MFD and link to the main
MFD schema. MFD device description mandates to have a complete device
example so having examples for each subdevice is redundant.
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:07 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8bd89524-dfc3-43b0-b0f2-cdb1cd51e1ac@baylibre.com>
сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, 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
> >
> > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > deleted file mode 100644
> > index 0dd0076daf71..000000000000
> > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > +++ /dev/null
> > @@ -1,20 +0,0 @@
> > -Motorola CPCAP on key
> > -
> > -This module is part of the CPCAP. For more details about the whole
> > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > -
> > -This module provides a simple power button event via an Interrupt.
> > -
> > -Required properties:
> > -- compatible: should be one of the following
> > - - "motorola,cpcap-pwrbutton"
> > -- interrupts: irq specifier for CPCAP's ON IRQ
> > -
> > -Example:
> > -
> > -&cpcap {
> > - cpcap_pwrbutton: pwrbutton {
> > - compatible = "motorola,cpcap-pwrbutton";
> > - interrupts = <23 IRQ_TYPE_NONE>;
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > new file mode 100644
> > index 000000000000..643f6b2b1f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > @@ -0,0 +1,32 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC power key
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + power key is represented as a sub-node of the PMIC node on the device
> > + tree.
> > +
> > +properties:
> > + compatible:
> > + const: motorola,cpcap-pwrbutton
> > +
> > + interrupts:
> > + minItems: 1
>
> Should this be maxItems: 1?
>
> > + description: CPCAP's ON interrupt
>
> Or I suppose:
>
> items:
> - description: ...
>
Both options are perfectly fine for me, and I lean towards using
"items: desc" but I would like to hear what schema maintainers would
say, which layout is preferred in this case.
>
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
>
> example: ...
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8cedbb9c-9f72-43ae-a23e-705b3feb85fb@baylibre.com>
сб, 31 січ. 2026 р. о 21:55 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/31/26 1:46 PM, David Lechner wrote:
> > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> >> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> >> from TXT to YAML format. Main functionality preserved and added compatible
> >> for CPCAP regulator set found in the Mot board.
> >>
>
> ...
>
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - motorola,cpcap-regulator
> >> + - motorola,mapphone-cpcap-regulator
> >> + - motorola,mot-cpcap-regulator
>
> This is what caused me to get confused on the order of the later patches.
>
> motorola,mot-cpcap-regulator is a new compatible, so would be better as
> a separate patch.
>
Rob already cleared this up
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>
сб, 31 січ. 2026 р. о 21:46 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> > from TXT to YAML format. Main functionality preserved and added compatible
> > for CPCAP regulator set found in the Mot board.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> > .../regulator/motorola,cpcap-regulator.yaml | 51 +++++++++++++++++++
> > 2 files changed, 51 insertions(+), 35 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > deleted file mode 100644
> > index 36f5e2f5cc0f..000000000000
> > --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > +++ /dev/null
> > @@ -1,35 +0,0 @@
> > -Motorola CPCAP PMIC voltage regulators
> > -------------------------------------
> > -
> > -Requires node properties:
> > -- "compatible" value one of:
> > - "motorola,cpcap-regulator"
> > - "motorola,mapphone-cpcap-regulator"
> > - "motorola,xoom-cpcap-regulator"
> > -
> > -Required regulator properties:
> > -- "regulator-name"
> > -- "regulator-enable-ramp-delay"
> > -- "regulator-min-microvolt"
> > -- "regulator-max-microvolt"
> > -
> > -Optional regulator properties:
> > -- "regulator-boot-on"
> > -
> > -See Documentation/devicetree/bindings/regulator/regulator.txt
> > -for more details about the regulator properties.
> > -
> > -Example:
> > -
> > -cpcap_regulator: regulator {
> > - compatible = "motorola,cpcap-regulator";
> > -
> > - cpcap_regulators: regulators {
> > - sw5: SW5 {
>
> Old example is missing the required regulator-names property.
>
> > - regulator-min-microvolt = <5050000>;
> > - regulator-max-microvolt = <5050000>;
> > - regulator-enable-ramp-delay = <50000>;
> > - regulator-boot-on;
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > new file mode 100644
> > index 000000000000..b73d32a86904
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC regulators
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + regulator controller is represented as a sub-node of the PMIC node
> > + on the device tree.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - motorola,cpcap-regulator
> > + - motorola,mapphone-cpcap-regulator
> > + - motorola,mot-cpcap-regulator
> > + - motorola,xoom-cpcap-regulator
> > +
> > + regulators:
> > + type: object
> > +
> > + patternProperties:
> > + "$[A-Z0-9]+^":
>
> Why not put the valid names here? Or does the node name not actually matter?
> (in which case lower case could be allowed too.)
>
> "^(SW1|SW2|...)$":
>
> And $,^ are swapped.
>
This is an interesting suggestion, maybe schema maintainers can
suggest how to approach this? Node name and case matters, list of
possible names is in the description.
> > + $ref: /schemas/regulator/regulator.yaml#
> > + type: object
> > + description:
> > + Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> > + VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> > + VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> > +
>
> If these apply to the regulator-name property, it can be written instead as:
>
Regulator name does not matter, any name is acceptible.
> properties:
> regulator-name:
> enum:
> - SW1
> - SW2
> ...
>
>
> Not sure if it is strictly needed, but this would document the optional
> property:
>
> regulator-boot-on: true
>
this is covered by common regulator schema, along with other possible
regulator properties
> > + required:
> > + - regulator-name
> > + - regulator-enable-ramp-delay
> > + - regulator-min-microvolt
> > + - regulator-max-microvolt
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
>
> Example should go here.
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v2 2/3] Input: aw86938 - add driver for Awinic AW86938
From: Dmitry Torokhov @ 2026-02-01 1:49 UTC (permalink / raw)
To: Griffin Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Luca Weiss, linux-input, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <20260128-aw86938-driver-v2-2-b51ee086aaf5@fairphone.com>
Hi Griffin,
On Wed, Jan 28, 2026 at 04:51:14PM +0100, Griffin Kroah-Hartman wrote:
> @@ -717,9 +746,19 @@ static int aw86927_detect(struct aw86927_data *haptics)
>
> chip_id = be16_to_cpu(read_buf);
>
> - if (chip_id != AW86927_CHIPID) {
> - dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
> - return -ENODEV;
> + switch (haptics->model) {
> + case AW86927:
> + if (chip_id != AW86927_CHIPID) {
> + dev_err(haptics->dev, "Unexpected CHIPID value 0x%x\n", chip_id);
> + return -ENODEV;
> + }
If we are able to query chip ID why do we need to have separate
compatibles? I would define chip data structure with differences between
variants and assign and use it instead of having separate compatible.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v3] selftests: hid: tests: test_wacom_generic: add tests for display devices and opaque devices
From: Alex Tran @ 2026-01-31 23:57 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Shuah Khan
Cc: Ping Cheng, Jason Gerecke, Erin Skomra, linux-input,
linux-kselftest, linux-kernel, Alex Tran
Verify Wacom devices set INPUT_PROP_DIRECT on display devices and
INPUT_PROP_POINTER on opaque devices. Verify INPUT_PROP_POINTER
is not set on display devices and INPUT_PROP_DIRECT is not set
on opaque devices.
Moved test_prop_pointer into TestOpaqueTablet. Created a
DirectTabletTest mixin class for test_prop_direct that can be
inherited by display tablet test classes.Used DirectTabletTest
for TestDTH2452Tablet case.
Signed-off-by: Alex Tran <alex.t.tran@gmail.com>
---
Changes in v3:
- add assertion for prop tests where opposite is not set
Changes in v2:
- Removed the tests from the BaseTest class
- Removed disabling tests for certain subclasses
- Moved test_prop_pointer under TestOpaqueTablet
- Created DirectTabletTest mixin class
- Moved test_prop_direct under TestDTH2452Tablet
---
.../selftests/hid/tests/test_wacom_generic.py | 34 +++++++++++++---------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/hid/tests/test_wacom_generic.py b/tools/testing/selftests/hid/tests/test_wacom_generic.py
index 2d6d04f0ff80bea46dc6c61c2b3a43383be6ac50..3903f479b15bdf8937a9f1ae96791f6dee0f89b7 100644
--- a/tools/testing/selftests/hid/tests/test_wacom_generic.py
+++ b/tools/testing/selftests/hid/tests/test_wacom_generic.py
@@ -598,18 +598,6 @@ class BaseTest:
if unit_set:
assert required[usage].contains(field)
- def test_prop_direct(self):
- """
- Todo: Verify that INPUT_PROP_DIRECT is set on display devices.
- """
- pass
-
- def test_prop_pointer(self):
- """
- Todo: Verify that INPUT_PROP_POINTER is set on opaque devices.
- """
- pass
-
class PenTabletTest(BaseTest.TestTablet):
def assertName(self, uhdev):
@@ -677,6 +665,15 @@ class TestOpaqueTablet(PenTabletTest):
uhdev.event(130, 240, pressure=0), [], auto_syn=False, strict=True
)
+ def test_prop_pointer(self):
+ """
+ Verify that INPUT_PROP_POINTER is set and INPUT_PROP_DIRECT
+ is not set on opaque devices.
+ """
+ evdev = self.uhdev.get_evdev()
+ assert libevdev.INPUT_PROP_POINTER in evdev.properties
+ assert libevdev.INPUT_PROP_DIRECT not in evdev.properties
+
class TestOpaqueCTLTablet(TestOpaqueTablet):
def create_device(self):
@@ -862,7 +859,18 @@ class TestPTHX60_Pen(TestOpaqueCTLTablet):
)
-class TestDTH2452Tablet(test_multitouch.BaseTest.TestMultitouch, TouchTabletTest):
+class DirectTabletTest():
+ def test_prop_direct(self):
+ """
+ Verify that INPUT_PROP_DIRECT is set and INPUT_PROP_POINTER
+ is not set on display devices.
+ """
+ evdev = self.uhdev.get_evdev()
+ assert libevdev.INPUT_PROP_DIRECT in evdev.properties
+ assert libevdev.INPUT_PROP_POINTER not in evdev.properties
+
+
+class TestDTH2452Tablet(test_multitouch.BaseTest.TestMultitouch, TouchTabletTest, DirectTabletTest):
ContactIds = namedtuple("ContactIds", "contact_id, tracking_id, slot_num")
def create_device(self):
---
base-commit: 79b95d74470dd97d7d0908d5a3c0734a23e51aa4
change-id: 20260131-wacom_selftests_display_opaque_dev_tests-4519c400143b
Best regards,
--
Alex Tran <alex.t.tran@gmail.com>
^ permalink raw reply related
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: David Lechner @ 2026-01-31 20:07 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-9-clamor95@gmail.com>
On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> Audio codec bindings adjusted with common ports node for port@0 and
> port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> same.
>
...
> +examples:
Ah, I guess this covers all of the missing examples. The other commit
messages should say that was the plan so we know why the examples were
omitted in the other patches.
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: David Lechner @ 2026-01-31 20:02 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-8-clamor95@gmail.com>
On 1/25/26 7:42 AM, 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
>
> diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> deleted file mode 100644
> index 0dd0076daf71..000000000000
> --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Motorola CPCAP on key
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -This module provides a simple power button event via an Interrupt.
> -
> -Required properties:
> -- compatible: should be one of the following
> - - "motorola,cpcap-pwrbutton"
> -- interrupts: irq specifier for CPCAP's ON IRQ
> -
> -Example:
> -
> -&cpcap {
> - cpcap_pwrbutton: pwrbutton {
> - compatible = "motorola,cpcap-pwrbutton";
> - interrupts = <23 IRQ_TYPE_NONE>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> new file mode 100644
> index 000000000000..643f6b2b1f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC power key
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> + power key is represented as a sub-node of the PMIC node on the device
> + tree.
> +
> +properties:
> + compatible:
> + const: motorola,cpcap-pwrbutton
> +
> + interrupts:
> + minItems: 1
Should this be maxItems: 1?
> + description: CPCAP's ON interrupt
Or I suppose:
items:
- description: ...
> +
> +required:
> + - compatible
> + - interrupts
> +
> +additionalProperties: false
> +
example: ...
> +...
^ permalink raw reply
* Re: [PATCH v1 05/10] dt-bindings: leds: leds-cpcap: convert to schema
From: David Lechner @ 2026-01-31 19:59 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-6-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert leds 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>
> ---
> .../devicetree/bindings/leds/leds-cpcap.txt | 29 -------------
> .../bindings/leds/motorola,cpcap-leds.yaml | 42 +++++++++++++++++++
> 2 files changed, 42 insertions(+), 29 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
> create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> deleted file mode 100644
> index ebf7cdc7f70c..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Motorola CPCAP PMIC LEDs
> -------------------------
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -Requires node properties:
> -- compatible: should be one of
> - * "motorola,cpcap-led-mdl" (Main Display Lighting)
> - * "motorola,cpcap-led-kl" (Keyboard Lighting)
> - * "motorola,cpcap-led-adl" (Aux Display Lighting)
> - * "motorola,cpcap-led-red" (Red Triode)
> - * "motorola,cpcap-led-green" (Green Triode)
> - * "motorola,cpcap-led-blue" (Blue Triode)
> - * "motorola,cpcap-led-cf" (Camera Flash)
> - * "motorola,cpcap-led-bt" (Bluetooth)
> - * "motorola,cpcap-led-cp" (Camera Privacy LED)
> -- label: see Documentation/devicetree/bindings/leds/common.txt
> -- vdd-supply: A phandle to the regulator powering the LED
> -
> -Example:
> -
> -&cpcap {
> - cpcap_led_red: red-led {
> - compatible = "motorola,cpcap-led-red";
> - label = "cpcap:red";
> - vdd-supply = <&sw5>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> new file mode 100644
> index 000000000000..8dfc98a1ef99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC leds
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. Leds are
s/Leds/LEDs/
> + represented as sub-nodes of the PMIC node on the device tree.
> +
> +allOf:
> + - $ref: /schemas/leds/common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap-led-adl # Display Lighting
> + - motorola,cpcap-led-blue # Blue Triode
> + - motorola,cpcap-led-bt # Bluetooth
> + - motorola,cpcap-led-cf # Camera Flash
> + - motorola,cpcap-led-cp # Camera Privacy LED
> + - motorola,cpcap-led-green # Green Triode
> + - motorola,cpcap-led-kl # Keyboard Lighting
> + - motorola,cpcap-led-mdl # Main Display Lighting
> + - motorola,cpcap-led-red # Red Triode
> +
> + vdd-supply: true
> +
> +required:
> + - compatible
> + - label
> + - vdd-supply
> +
> +unevaluatedProperties: false
> +
Should keep the example here.
> +...
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:55 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>
On 1/31/26 1:46 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
>> from TXT to YAML format. Main functionality preserved and added compatible
>> for CPCAP regulator set found in the Mot board.
>>
...
>> +properties:
>> + compatible:
>> + enum:
>> + - motorola,cpcap-regulator
>> + - motorola,mapphone-cpcap-regulator
>> + - motorola,mot-cpcap-regulator
This is what caused me to get confused on the order of the later patches.
motorola,mot-cpcap-regulator is a new compatible, so would be better as
a separate patch.
^ permalink raw reply
* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:50 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <92858c73-1e11-4283-8ab6-1188e8bae0df@baylibre.com>
On 1/31/26 1:48 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Add compatible for ADC used in Mot board. Separate compatible is required
>> since ADC in the Mot board uses a unique set of configurations.
>>
> Logically, it makes more sense to readers to put the DT binding patch
> before the driver change in the series.
OK, I didn't read carefully enough that there are multiple devices
in this series. So you already did what I suggested. :-)
^ permalink raw reply
* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:48 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-4-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Add compatible for ADC used in Mot board. Separate compatible is required
> since ADC in the Mot board uses a unique set of configurations.
>
Logically, it makes more sense to readers to put the DT binding patch
before the driver change in the series.
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:46 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-2-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved and added compatible
> for CPCAP regulator set found in the Mot board.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> .../regulator/motorola,cpcap-regulator.yaml | 51 +++++++++++++++++++
> 2 files changed, 51 insertions(+), 35 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> deleted file mode 100644
> index 36f5e2f5cc0f..000000000000
> --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -Motorola CPCAP PMIC voltage regulators
> -------------------------------------
> -
> -Requires node properties:
> -- "compatible" value one of:
> - "motorola,cpcap-regulator"
> - "motorola,mapphone-cpcap-regulator"
> - "motorola,xoom-cpcap-regulator"
> -
> -Required regulator properties:
> -- "regulator-name"
> -- "regulator-enable-ramp-delay"
> -- "regulator-min-microvolt"
> -- "regulator-max-microvolt"
> -
> -Optional regulator properties:
> -- "regulator-boot-on"
> -
> -See Documentation/devicetree/bindings/regulator/regulator.txt
> -for more details about the regulator properties.
> -
> -Example:
> -
> -cpcap_regulator: regulator {
> - compatible = "motorola,cpcap-regulator";
> -
> - cpcap_regulators: regulators {
> - sw5: SW5 {
Old example is missing the required regulator-names property.
> - regulator-min-microvolt = <5050000>;
> - regulator-max-microvolt = <5050000>;
> - regulator-enable-ramp-delay = <50000>;
> - regulator-boot-on;
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> new file mode 100644
> index 000000000000..b73d32a86904
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC regulators
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> + regulator controller is represented as a sub-node of the PMIC node
> + on the device tree.
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap-regulator
> + - motorola,mapphone-cpcap-regulator
> + - motorola,mot-cpcap-regulator
> + - motorola,xoom-cpcap-regulator
> +
> + regulators:
> + type: object
> +
> + patternProperties:
> + "$[A-Z0-9]+^":
Why not put the valid names here? Or does the node name not actually matter?
(in which case lower case could be allowed too.)
"^(SW1|SW2|...)$":
And $,^ are swapped.
> + $ref: /schemas/regulator/regulator.yaml#
> + type: object
> + description:
> + Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> + VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> + VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> +
If these apply to the regulator-name property, it can be written instead as:
properties:
regulator-name:
enum:
- SW1
- SW2
...
Not sure if it is strictly needed, but this would document the optional
property:
regulator-boot-on: true
> + required:
> + - regulator-name
> + - regulator-enable-ramp-delay
> + - regulator-min-microvolt
> + - regulator-max-microvolt
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
Example should go here.
> +...
^ permalink raw reply
* RE: [linux-drivers-review] [PATCH] HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients
From: Lin, Ryan @ 2026-01-31 6:51 UTC (permalink / raw)
To: srinivas pandruvada, linux-kernel@vger.kernel.org,
linux-input@vger.kernel.org,
linux-drivers-review@eclists.intel.com, Zhang, Lixu,
Benjamin Tissoires, Jiri Kosina
In-Reply-To: <381d44f303b9dd51e0d5063a805868eb601145f2.camel@linux.intel.com>
> -----Original Message-----
> From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
> Sent: Saturday, January 31, 2026 9:32 AM
> To: Lin, Ryan <ryan.lin@intel.com>; linux-kernel@vger.kernel.org; linux-
> input@vger.kernel.org; linux-drivers-review@eclists.intel.com; Zhang, Lixu
> <lixu.zhang@intel.com>; Benjamin Tissoires <bentiss@kernel.org>; Jiri Kosina
> <jikos@kernel.org>
> Subject: Re: [linux-drivers-review] [PATCH] HID: intel-ish-hid: fix NULL-ptr-deref
> in ishtp_bus_remove_all_clients
>
> On Fri, 2026-01-30 at 13:25 +0800, Ryan Lin wrote:
> > During a warm reset flow, the cl->device pointer may be NULL if the
> > reset occurs while clients are still being enumerated. Accessing
> > cl->device->reference_count without a NULL check leads to a kernel
> > panic.
> >
> > This issue was identified during multi-unit warm reboot stress
> > clycles.
> > Add a defensive NULL check for cl->device to ensure stability under
> > such intensive testing conditions.
> >
> > KASAN: null-ptr-deref in range [0000000000000000-0000000000000007]
> > Workqueue: ish_fw_update_wq fw_reset_work_fn
> >
> > Call Trace:
> > ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp]
> > ishtp_reset_handler+0x85/0x1a0 [intel_ishtp]
> > fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc]
> >
> > Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer")
> > Signed-off-by: Ryan Lin <ryan.lin@intel.com>
>
> You need to use get_maintainer.pl to get all TO and CC list.
>
> You missed
> Jiri Kosina <jikos@kernel.org>
> Benjamin Tissoires <bentiss@kernel.org>
Thanks, Srinivas. I've looped Jiri and Benjamin in the v2 thread. Appreciate the heads-up.
Regards,
Ryan
>
>
> > ---
> > drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c
> > b/drivers/hid/intel-ish-hid/ishtp/bus.c
> > index c3915f3a060e..b890fbf97a75 100644
> > --- a/drivers/hid/intel-ish-hid/ishtp/bus.c
> > +++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
> > @@ -730,7 +730,7 @@ void ishtp_bus_remove_all_clients(struct
> > ishtp_device *ishtp_dev,
> > spin_lock_irqsave(&ishtp_dev->cl_list_lock, flags);
> > list_for_each_entry(cl, &ishtp_dev->cl_list, link) {
> > cl->state = ISHTP_CL_DISCONNECTED;
> > - if (warm_reset && cl->device->reference_count)
> > + if (warm_reset && cl->device && cl->device-
> > >reference_count)
> > continue;
> >
> > /*
^ permalink raw reply
* RE: [PATCH v2] HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients
From: Lin, Ryan @ 2026-01-31 6:46 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
srinivas.pandruvada@linux.intel.com, Zhang, Lixu,
jikos@kernel.org, bentiss@kernel.org
In-Reply-To: <20260130053456.4971-1-ryan.lin@intel.com>
Hi Jiri and Benjamin,
Looping you in for this v2. Apologies for the oversight in the To list.
Thanks,
Ryan
> -----Original Message-----
> From: Lin, Ryan <ryan.lin@intel.com>
> Sent: Friday, January 30, 2026 1:35 PM
> To: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org;
> srinivas.pandruvada@linux.intel.com; Zhang, Lixu <lixu.zhang@intel.com>
> Cc: Lin, Ryan <ryan.lin@intel.com>
> Subject: [PATCH v2] HID: intel-ish-hid: fix NULL-ptr-deref in
> ishtp_bus_remove_all_clients
>
> During a warm reset flow, the cl->device pointer may be NULL if the reset occurs
> while clients are still being enumerated. Accessing
> cl->device->reference_count without a NULL check leads to a kernel panic.
>
> This issue was identified during multi-unit warm reboot stress clycles.
> Add a defensive NULL check for cl->device to ensure stability under such
> intensive testing conditions.
>
> KASAN: null-ptr-deref in range [0000000000000000-0000000000000007]
> Workqueue: ish_fw_update_wq fw_reset_work_fn
>
> Call Trace:
> ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp]
> ishtp_reset_handler+0x85/0x1a0 [intel_ishtp]
> fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc]
>
> Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer")
> Signed-off-by: Ryan Lin <ryan.lin@intel.com>
> ---
> drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-
> hid/ishtp/bus.c
> index c3915f3a060e..b890fbf97a75 100644
> --- a/drivers/hid/intel-ish-hid/ishtp/bus.c
> +++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
> @@ -730,7 +730,7 @@ void ishtp_bus_remove_all_clients(struct ishtp_device
> *ishtp_dev,
> spin_lock_irqsave(&ishtp_dev->cl_list_lock, flags);
> list_for_each_entry(cl, &ishtp_dev->cl_list, link) {
> cl->state = ISHTP_CL_DISCONNECTED;
> - if (warm_reset && cl->device->reference_count)
> + if (warm_reset && cl->device && cl->device->reference_count)
> continue;
>
> /*
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH v2 2/3] Input: aw86938 - add driver for Awinic AW86938
From: kernel test robot @ 2026-01-31 3:44 UTC (permalink / raw)
To: Griffin Kroah-Hartman, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss
Cc: llvm, oe-kbuild-all, linux-input, devicetree, linux-kernel,
linux-arm-msm, Griffin Kroah-Hartman
In-Reply-To: <20260128-aw86938-driver-v2-2-b51ee086aaf5@fairphone.com>
Hi Griffin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 0364de6be161e2360cbb1f26d5aff5b343ef7bb0]
url: https://github.com/intel-lab-lkp/linux/commits/Griffin-Kroah-Hartman/dt-bindings-input-awinic-aw86927-Add-Awinic-AW86938/20260129-000753
base: 0364de6be161e2360cbb1f26d5aff5b343ef7bb0
patch link: https://lore.kernel.org/r/20260128-aw86938-driver-v2-2-b51ee086aaf5%40fairphone.com
patch subject: [PATCH v2 2/3] Input: aw86938 - add driver for Awinic AW86938
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260131/202601311117.t00gEixW-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260131/202601311117.t00gEixW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601311117.t00gEixW-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/misc/aw86927.c:778:19: warning: cast to smaller integer type 'enum aw86927_model' from 'const void *' [-Wvoid-pointer-to-enum-cast]
778 | haptics->model = (enum aw86927_model)device_get_match_data(&client->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +778 drivers/input/misc/aw86927.c
766
767 static int aw86927_probe(struct i2c_client *client)
768 {
769 struct aw86927_data *haptics;
770 int err;
771
772 haptics = devm_kzalloc(&client->dev, sizeof(struct aw86927_data), GFP_KERNEL);
773 if (!haptics)
774 return -ENOMEM;
775
776 haptics->dev = &client->dev;
777 haptics->client = client;
> 778 haptics->model = (enum aw86927_model)device_get_match_data(&client->dev);
779
780 i2c_set_clientdata(client, haptics);
781
782 haptics->regmap = devm_regmap_init_i2c(client, &aw86927_regmap_config);
783 if (IS_ERR(haptics->regmap))
784 return dev_err_probe(haptics->dev, PTR_ERR(haptics->regmap),
785 "Failed to allocate register map\n");
786
787 haptics->input_dev = devm_input_allocate_device(haptics->dev);
788 if (!haptics->input_dev)
789 return -ENOMEM;
790
791 haptics->reset_gpio = devm_gpiod_get(haptics->dev, "reset", GPIOD_OUT_HIGH);
792 if (IS_ERR(haptics->reset_gpio))
793 return dev_err_probe(haptics->dev, PTR_ERR(haptics->reset_gpio),
794 "Failed to get reset gpio\n");
795
796 /* Hardware reset */
797 aw86927_hw_reset(haptics);
798
799 /* Software reset */
800 err = regmap_write(haptics->regmap, AW86927_RSTCFG_REG, AW86927_RSTCFG_SOFTRST);
801 if (err)
802 return dev_err_probe(haptics->dev, err, "Failed Software reset\n");
803
804 /* Wait ~3ms until I2C is accessible */
805 usleep_range(3000, 3500);
806
807 err = aw86927_detect(haptics);
808 if (err)
809 return dev_err_probe(haptics->dev, err, "Failed to find chip\n");
810
811 /* IRQ config */
812 err = regmap_write(haptics->regmap, AW86927_SYSCTRL4_REG,
813 FIELD_PREP(AW86927_SYSCTRL4_INT_MODE_MASK,
814 AW86927_SYSCTRL4_INT_MODE_EDGE) |
815 FIELD_PREP(AW86927_SYSCTRL4_INT_EDGE_MODE_MASK,
816 AW86927_SYSCTRL4_INT_EDGE_MODE_POS));
817 if (err)
818 return dev_err_probe(haptics->dev, err, "Failed to configure interrupt modes\n");
819
820 err = regmap_write(haptics->regmap, AW86927_SYSINTM_REG,
821 AW86927_SYSINTM_BST_OVPM |
822 AW86927_SYSINTM_FF_AEM |
823 AW86927_SYSINTM_FF_AFM |
824 AW86927_SYSINTM_DONEM);
825 if (err)
826 return dev_err_probe(haptics->dev, err, "Failed to configure interrupt masks\n");
827
828 err = devm_request_threaded_irq(haptics->dev, client->irq, NULL,
829 aw86927_irq, IRQF_ONESHOT, NULL, haptics);
830 if (err)
831 return dev_err_probe(haptics->dev, err, "Failed to request threaded irq\n");
832
833 INIT_WORK(&haptics->play_work, aw86927_haptics_play_work);
834
835 haptics->input_dev->name = "aw86927-haptics";
836 haptics->input_dev->close = aw86927_close;
837
838 input_set_drvdata(haptics->input_dev, haptics);
839 input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
840
841 err = input_ff_create_memless(haptics->input_dev, NULL, aw86927_haptics_play);
842 if (err)
843 return dev_err_probe(haptics->dev, err, "Failed to create FF dev\n");
844
845 /* Set up registers */
846 err = aw86927_play_mode(haptics, AW86927_STANDBY_MODE);
847 if (err)
848 return dev_err_probe(haptics->dev, err,
849 "Failed to enter standby for Haptic init\n");
850
851 err = aw86927_haptic_init(haptics);
852 if (err)
853 return dev_err_probe(haptics->dev, err, "Haptic init failed\n");
854
855 /* RAM init, upload the waveform for playback */
856 err = aw86927_ram_init(haptics);
857 if (err)
858 return dev_err_probe(haptics->dev, err, "Failed to init aw86927 sram\n");
859
860 err = input_register_device(haptics->input_dev);
861 if (err)
862 return dev_err_probe(haptics->dev, err, "Failed to register input device\n");
863
864 return 0;
865 }
866
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [linux-drivers-review] [PATCH] HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients
From: srinivas pandruvada @ 2026-01-31 1:32 UTC (permalink / raw)
To: Ryan Lin, linux-kernel, linux-input, linux-drivers-review,
lixu.zhang, Benjamin Tissoires, Jiri Kosina
In-Reply-To: <20260130052544.4784-1-ryan.lin@intel.com>
On Fri, 2026-01-30 at 13:25 +0800, Ryan Lin wrote:
> During a warm reset flow, the cl->device pointer may be NULL if the
> reset occurs while clients are still being enumerated. Accessing
> cl->device->reference_count without a NULL check leads to a kernel
> panic.
>
> This issue was identified during multi-unit warm reboot stress
> clycles.
> Add a defensive NULL check for cl->device to ensure stability under
> such intensive testing conditions.
>
> KASAN: null-ptr-deref in range [0000000000000000-0000000000000007]
> Workqueue: ish_fw_update_wq fw_reset_work_fn
>
> Call Trace:
> ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp]
> ishtp_reset_handler+0x85/0x1a0 [intel_ishtp]
> fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc]
>
> Fixes: 3703f53b99e4a ("HID: intel_ish-hid: ISH Transport layer")
> Signed-off-by: Ryan Lin <ryan.lin@intel.com>
You need to use get_maintainer.pl to get all TO and CC list.
You missed
Jiri Kosina <jikos@kernel.org>
Benjamin Tissoires <bentiss@kernel.org>
> ---
> drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c
> b/drivers/hid/intel-ish-hid/ishtp/bus.c
> index c3915f3a060e..b890fbf97a75 100644
> --- a/drivers/hid/intel-ish-hid/ishtp/bus.c
> +++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
> @@ -730,7 +730,7 @@ void ishtp_bus_remove_all_clients(struct
> ishtp_device *ishtp_dev,
> spin_lock_irqsave(&ishtp_dev->cl_list_lock, flags);
> list_for_each_entry(cl, &ishtp_dev->cl_list, link) {
> cl->state = ISHTP_CL_DISCONNECTED;
> - if (warm_reset && cl->device->reference_count)
> + if (warm_reset && cl->device && cl->device-
> >reference_count)
> continue;
>
> /*
^ permalink raw reply
* Re: (subset) [PATCH v1 06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
From: Alexandre Belloni @ 2026-01-30 22:59 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, Svyatoslav Ryhel
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-7-clamor95@gmail.com>
On Sun, 25 Jan 2026 15:42:58 +0200, Svyatoslav Ryhel wrote:
> Convert RTC devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
>
Applied, thanks!
[06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
https://git.kernel.org/abelloni/c/96a77ec577d4
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v4 0/6] dt-bindings: goldfish: Convert to DT schema
From: Sebastian Reichel @ 2026-01-30 22:24 UTC (permalink / raw)
To: airlied, simona, maarten.lankhorst, mripard, tzimmermann, robh,
krzk+dt, conor+dt, dmitry.torokhov, sre, gregkh, jirislaby,
lgirdwood, broonie, Kuan-Wei Chiu
Cc: jserv, dri-devel, devicetree, linux-kernel, linux-input, linux-pm,
linux-serial, linux-sound, Yu-Chun Lin
In-Reply-To: <20260113092602.3197681-1-visitorckw@gmail.com>
On Tue, 13 Jan 2026 09:25:56 +0000, Kuan-Wei Chiu wrote:
> Convert the Android Goldfish emulator platform bindings from text
> format to DT schema.
>
> Most of these bindings are currently located in
> Documentation/devicetree/bindings/goldfish/. Move them to the
> appropriate subsystem directories (serial, input, power, sound, misc)
> to align with the kernel directory structure.
>
> [...]
Applied, thanks!
[4/6] dt-bindings: power: supply: google,goldfish-battery: Convert to DT schema
commit: 4c3f02f843999a590f4481791f59a2f9a7f34fe4
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [Poke?] Re: [PATCH v2 0/1] HID: switch2: Add preliminary Switch 2 controller driver
From: lyude @ 2026-01-30 22:14 UTC (permalink / raw)
To: Vicki Pfau, Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires,
linux-input
Cc: Luiz Augusto von Dentz, Bastien Nocera
In-Reply-To: <e66735b6e1b0ac4db3dfd2aaddadcc9ff052beb0.camel@redhat.com>
aaaaand whoops. Sorry! I had gotten asked for help getting attention on
this but I realized I just poked the wrong subsystem maintainer - I am
going for HID, not Input. You're off the hook Dmitry :P, sorry for the
misunderstanding.
Bentiss/Jiri, any chance this patch is on your radar?
On Fri, 2026-01-30 at 17:09 -0500, lyude@redhat.com wrote:
> Hey Dmitry! I'm sure you've got a lot on your plate, I just wanted to
> double check that you had this patch series on your radar since it's
> nearing 3 weeks (and V1 of this patch has been on the mailing list
> since early November with me being the only one responding to it).
>
> Is there anything you need from Vicki still, is there a chance you
> might know when you can take a look at this, etc.?
>
> Also, thank you for any help you can provide!
>
> On Thu, 2026-01-08 at 19:40 -0800, Vicki Pfau wrote:
> > This is effectively a resubmission of the previous patch with minor
> > fixes
> > for issues that came up during the first review. Bluetooth support
> > is
> > still
> > not included, but this will hopefully provide a solid foundation
> > for
> > bringing up Bluetooth support once BlueZ is capable of bringing up
> > the
> > controller. This will probably require a new plugin, but
> > investigation is
> > still ongoing.
> >
> > Vicki Pfau (1):
> > HID: switch2: Add preliminary Switch 2 controller driver
> >
> > MAINTAINERS | 7 +
> > drivers/hid/Kconfig | 18 +
> > drivers/hid/Makefile | 1 +
> > drivers/hid/hid-ids.h | 4 +
> > drivers/hid/hid-switch2.c | 975
> > +++++++++++++++++++++++++++
> > drivers/hid/hid-switch2.h | 242 +++++++
> > drivers/input/joystick/Kconfig | 8 +
> > drivers/input/joystick/Makefile | 1 +
> > drivers/input/joystick/switch2-usb.c | 353 ++++++++++
> > 9 files changed, 1609 insertions(+)
> > create mode 100644 drivers/hid/hid-switch2.c
> > create mode 100644 drivers/hid/hid-switch2.h
> > create mode 100644 drivers/input/joystick/switch2-usb.c
^ permalink raw reply
* [Poke?] Re: [PATCH v2 0/1] HID: switch2: Add preliminary Switch 2 controller driver
From: lyude @ 2026-01-30 22:09 UTC (permalink / raw)
To: Vicki Pfau, Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires,
linux-input
Cc: Luiz Augusto von Dentz, Bastien Nocera
In-Reply-To: <20260109034034.565630-1-vi@endrift.com>
Hey Dmitry! I'm sure you've got a lot on your plate, I just wanted to
double check that you had this patch series on your radar since it's
nearing 3 weeks (and V1 of this patch has been on the mailing list
since early November with me being the only one responding to it).
Is there anything you need from Vicki still, is there a chance you
might know when you can take a look at this, etc.?
Also, thank you for any help you can provide!
On Thu, 2026-01-08 at 19:40 -0800, Vicki Pfau wrote:
> This is effectively a resubmission of the previous patch with minor
> fixes
> for issues that came up during the first review. Bluetooth support is
> still
> not included, but this will hopefully provide a solid foundation for
> bringing up Bluetooth support once BlueZ is capable of bringing up
> the
> controller. This will probably require a new plugin, but
> investigation is
> still ongoing.
>
> Vicki Pfau (1):
> HID: switch2: Add preliminary Switch 2 controller driver
>
> MAINTAINERS | 7 +
> drivers/hid/Kconfig | 18 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-ids.h | 4 +
> drivers/hid/hid-switch2.c | 975
> +++++++++++++++++++++++++++
> drivers/hid/hid-switch2.h | 242 +++++++
> drivers/input/joystick/Kconfig | 8 +
> drivers/input/joystick/Makefile | 1 +
> drivers/input/joystick/switch2-usb.c | 353 ++++++++++
> 9 files changed, 1609 insertions(+)
> create mode 100644 drivers/hid/hid-switch2.c
> create mode 100644 drivers/hid/hid-switch2.h
> create mode 100644 drivers/input/joystick/switch2-usb.c
^ permalink raw reply
* [PATCH] HID: asus: Add check for cancelling fn_lock_sync_work
From: Sahil Chandna @ 2026-01-30 15:52 UTC (permalink / raw)
To: jikos, bentiss, connorbelli2003, linux-input, linux-kernel
Cc: Sahil Chandna, syzbot+13f8286fa2de04a7cd48
syzbot reported a workqueue warning where fn_lock_sync_work is cancelled
during device removal before the work has been initialized. This can
happen when the device is disconnected while initialization is still
in progress.
Fix this by initializing fn_lock_sync_work before marking fn_lock as
enabled, and by using fn_lock as a flag in the remove path. This
ensures cancel_work_sync() is only called for initialized work.
Fixes: f631011e36b8 ("HID: hid-asus: Implement fn lock for Asus ProArt P16")
Reported-by: syzbot+13f8286fa2de04a7cd48@syzkaller.appspotmail.com
Signed-off-by: Sahil Chandna <chandna.sahil@gmail.com>
---
drivers/hid/hid-asus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 1b9793f7c07e..bb85a36de14f 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -960,8 +960,8 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
}
if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
- drvdata->fn_lock = true;
INIT_WORK(&drvdata->fn_lock_sync_work, asus_sync_fn_lock);
+ drvdata->fn_lock = true;
asus_kbd_set_fn_lock(hdev, true);
}
@@ -1343,7 +1343,7 @@ static void asus_remove(struct hid_device *hdev)
cancel_work_sync(&drvdata->kbd_backlight->work);
}
- if (drvdata->quirks & QUIRK_HID_FN_LOCK)
+ if ((drvdata->quirks & QUIRK_HID_FN_LOCK) && drvdata->fn_lock)
cancel_work_sync(&drvdata->fn_lock_sync_work);
hid_hw_stop(hdev);
--
2.50.1
^ permalink raw reply related
* [PATCH] HID: asus: add missing code in asus_event
From: xiaopeitux @ 2026-01-30 8:28 UTC (permalink / raw)
To: jikos, bentiss, linux-input, linux-kernel; +Cc: Pei Xiao
From: Pei Xiao <xiaopei01@kylinos.cn>
In the commit f631011e36b8 ("HID: hid-asus: Implement fn lock for Asus
ProArt P16"), there was FN-related code for asus_event, but in the latest
linux-next branch, the FN code for asus_event is missing. So add it.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/hid/hid-asus.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 1b9793f7c07e..8e34063216c7 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -354,6 +354,8 @@ static int asus_wmi_send_event(struct asus_drvdata *drvdata, u8 code)
static int asus_event(struct hid_device *hdev, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
+ struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
+
if ((usage->hid & HID_USAGE_PAGE) == HID_USAGE_PAGE_VENDOR &&
(usage->hid & HID_USAGE) != 0x00 &&
(usage->hid & HID_USAGE) != 0xff && !usage->type) {
@@ -361,6 +363,12 @@ static int asus_event(struct hid_device *hdev, struct hid_field *field,
usage->hid & HID_USAGE);
}
+ if (drvdata->quirks & QUIRK_HID_FN_LOCK &&
+ usage->type == EV_KEY && usage->code == KEY_FN_ESC && value == 1) {
+ drvdata->fn_lock = !drvdata->fn_lock;
+ schedule_work(&drvdata->fn_lock_sync_work);
+ }
+
if (usage->type == EV_KEY && value) {
switch (usage->code) {
case KEY_KBDILLUMUP:
--
2.25.1
^ 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