* 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
* Re: [PATCH v13 2/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2026-01-30 7:53 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Andi Shyti,
Conor Dooley, Jiri Kosina, devicetree, linux-input,
Dmitry Torokhov, Bartosz Golaszewski, Ethan Twardy, linux-i2c,
linux-kernel, Leo Huang, Arun D Patil, Willie Thai, Ting-Kai Chen
In-Reply-To: <20260129183650.GA1419235@LNDCL34533.neenah.na.plexus.com>
On Thu, Jan 29, 2026 at 12:36:50PM -0600, Danny Kaehn wrote:
> On Tue, Jan 27, 2026 at 10:06:27PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 27, 2026 at 08:47:49AM -0600, Danny Kaehn wrote:
...
> > I'm wondering if we can avoid this (additional) check and use the result of one
> > of the branches.
>
> Meaning something like using the result of acpi_get_local_address() to
> determine whether the node is ACPI vs. not? That is what it used to do,
> before I needed to switch to different schemas for DT vs. ACPI. Now, it
> doesn't really make sense to use the child node types to determine
> whether the GPIO node is shared, but still possible if we store a bool
> result from the *_for_each_child_node() loop, but needs more complex
> logic to store that based on each child's type (and the loop is fully
> unnecessary for the non-ACPI case anyways).
>
> Following the discussion on the DT binding thread, do you still want
> ACPI to follow this different schema with the separate GPIO child node,
> or would you prefer to unify them?
Wouldn't it be a bit messy if we combine main Device object with the GPIO
and leave I²C as a separate node? Besides that it seems already established
practice to have GPIO + I²C controllers separated based on _ADR (see Intel
Galileo case, drivers/mfd/intel_quark_i2c_gpio.c). Even if we can combine
I prefer to use the existing schema to have less animals in the zoo, for
the consistency's sake.
...
> > > + device_for_each_child_node(&hdev->dev, child) {
> >
> > If we are still use the above check it will be dev_fwnode() duplication call,
> > so perhaps a temporary variable to collect the device's fwnode and use it
> > there, below (see below), and here as for
> >
> > fwnode_for_each_child_node()
>
>
> Makes sense, will update. I initially assumed we wanted to use the
> "device_*" API wherever possible.
Yes, but use a common sense. If we have fwnode already available, why should we
still use device_*()?
> > > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > + if (ret)
> > > + continue;
> > > +
> > > + switch (addr) {
> > > + case CP2112_I2C_ADR:
> > > + device_set_node(&dev->adap.dev, child);
> > > + break;
> > > + case CP2112_GPIO_ADR:
> > > + dev->gc.fwnode = child;
> > > + break;
> > > + }
> > > + }
> > > + } else {
> >
> > I would still check if this is a proper (OF) node, in case we stick with the
> > ACPI check above. Because we might have swnode and if it triggers, it will be
> > really something unexpected.
> >
> > } else if (is_of_node(fwnode)) {
>
> Wouldn't it be valid to use software nodes to describe the
> CP2112's functions? Is there any reason to intentionally prevent that?
swnode:s are for quirks. I hope in this case we won't see them IRL.
In any case, let's enable them when we will have the case.
> > > + child = device_get_named_child_node(&hdev->dev, "i2c");
> > > + device_set_node(&dev->adap.dev, child);
> > > + fwnode_handle_put(child);
> > > + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [syzbot] [input?] [usb?] WARNING in asus_remove
From: syzbot @ 2026-01-30 7:04 UTC (permalink / raw)
To: bentiss, chandna.sahil, jikos, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
In-Reply-To: <aXxOhV79TnuYaw0-@chandna.localdomain>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+13f8286fa2de04a7cd48@syzkaller.appspotmail.com
Tested-by: syzbot+13f8286fa2de04a7cd48@syzkaller.appspotmail.com
Tested on:
commit: 33a647c6 Add linux-next specific files for 20260129
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=140cf6ef980000
kernel config: https://syzkaller.appspot.com/x/.config?x=aef5831c38e37e48
dashboard link: https://syzkaller.appspot.com/bug?extid=13f8286fa2de04a7cd48
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=13ec1644580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* [PATCH v2] HID: sony: add dongle device IDs for CRKD Gibson SG
From: Rosalie Wanders @ 2026-01-30 6:57 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Rosalie Wanders, linux-input, linux-kernel
This patch adds the dongle device IDs for the CRKD Gibson SG
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-sony.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 43f86061cab2..91253b57c499 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -365,7 +365,9 @@
#define USB_VENDOR_ID_CRKD 0x3651
#define USB_DEVICE_ID_CRKD_PS4_GIBSON_SG 0x1500
-#define USB_DEVICE_ID_CRKD_PS5_GIBSON_SG 0x1600
+#define USB_DEVICE_ID_CRKD_PS4_GIBSON_SG_DONGLE 0x5500
+#define USB_DEVICE_ID_CRKD_PS5_GIBSON_SG 0x1600
+#define USB_DEVICE_ID_CRKD_PS5_GIBSON_SG_DONGLE 0x5600
#define USB_VENDOR_ID_CVTOUCH 0x1ff7
#define USB_DEVICE_ID_CVTOUCH_SCREEN 0x0013
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index d0270ffec4f4..836ce74764a8 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -2383,6 +2383,8 @@ static const struct hid_device_id sony_devices[] = {
.driver_data = RB4_GUITAR_PS4_USB },
{ HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS4_GIBSON_SG),
.driver_data = RB4_GUITAR_PS4_USB },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS4_GIBSON_SG_DONGLE),
+ .driver_data = RB4_GUITAR_PS4_USB },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_PDP, USB_DEVICE_ID_PDP_PS4_JAGUAR),
.driver_data = RB4_GUITAR_PS4_BT },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_PS4_STRATOCASTER),
@@ -2392,6 +2394,8 @@ static const struct hid_device_id sony_devices[] = {
.driver_data = RB4_GUITAR_PS5 },
{ HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS5_GIBSON_SG),
.driver_data = RB4_GUITAR_PS5 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CRKD, USB_DEVICE_ID_CRKD_PS5_GIBSON_SG_DONGLE),
+ .driver_data = RB4_GUITAR_PS5 },
{ }
};
MODULE_DEVICE_TABLE(hid, sony_devices);
--
2.52.0
^ permalink raw reply related
* [PATCH] HID: winwing: Enable rumble effects
From: Ivan Gorinov @ 2026-01-30 6:20 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel
Enable rumble motor control on TGRIP-15E and TGRIP-15EX throttle grips
by sending haptic feedback commands (EV_FF events) to the input device.
Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
---
drivers/hid/hid-winwing.c | 193 +++++++++++++++++++++++++++++++++++---
1 file changed, 179 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-winwing.c b/drivers/hid/hid-winwing.c
index ab65dc12d1e0..031590ffd383 100644
--- a/drivers/hid/hid-winwing.c
+++ b/drivers/hid/hid-winwing.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/workqueue.h>
#define MAX_REPORT 16
@@ -35,10 +36,14 @@ static const struct winwing_led_info led_info[3] = {
struct winwing_drv_data {
struct hid_device *hdev;
- __u8 *report_buf;
- struct mutex lock;
- int map_more_buttons;
- unsigned int num_leds;
+ struct mutex lights_lock;
+ __u8 *report_lights;
+ __u8 *report_rumble;
+ struct work_struct rumble_work;
+ struct ff_rumble_effect rumble;
+ int rumble_left;
+ int rumble_right;
+ int has_grip15;
struct winwing_led leds[];
};
@@ -47,10 +52,10 @@ static int winwing_led_write(struct led_classdev *cdev,
{
struct winwing_led *led = (struct winwing_led *) cdev;
struct winwing_drv_data *data = hid_get_drvdata(led->hdev);
- __u8 *buf = data->report_buf;
+ __u8 *buf = data->report_lights;
int ret;
- mutex_lock(&data->lock);
+ mutex_lock(&data->lights_lock);
buf[0] = 0x02;
buf[1] = 0x60;
@@ -69,7 +74,7 @@ static int winwing_led_write(struct led_classdev *cdev,
ret = hid_hw_output_report(led->hdev, buf, 14);
- mutex_unlock(&data->lock);
+ mutex_unlock(&data->lights_lock);
return ret;
}
@@ -87,9 +92,9 @@ static int winwing_init_led(struct hid_device *hdev,
if (!data)
return -EINVAL;
- data->report_buf = devm_kmalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
+ data->report_lights = devm_kzalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
- if (!data->report_buf)
+ if (!data->report_lights)
return -ENOMEM;
for (i = 0; i < 3; i += 1) {
@@ -117,7 +122,7 @@ static int winwing_init_led(struct hid_device *hdev,
return ret;
}
-static int winwing_map_button(int button, int map_more_buttons)
+static int winwing_map_button(int button, int has_grip15)
{
if (button < 1)
return KEY_RESERVED;
@@ -141,7 +146,7 @@ static int winwing_map_button(int button, int map_more_buttons)
return (button - 65) + BTN_TRIGGER_HAPPY17;
}
- if (!map_more_buttons) {
+ if (!has_grip15) {
/*
* Not mapping numbers [33 .. 64] which
* are not assigned to any real buttons
@@ -194,13 +199,150 @@ static int winwing_input_mapping(struct hid_device *hdev,
/* Button numbers start with 1 */
button = usage->hid & HID_USAGE;
- code = winwing_map_button(button, data->map_more_buttons);
+ code = winwing_map_button(button, data->has_grip15);
hid_map_usage(hi, usage, bit, max, EV_KEY, code);
return 1;
}
+/*
+ * If x ≤ 0, return 0;
+ * if x is in [1 .. 65535], return a value in [1 .. 255]
+ */
+static inline int convert_magnitude(int x)
+{
+ if (x < 1)
+ return 0;
+
+ return ((x * 255) >> 16) + 1;
+}
+
+static int winwing_haptic_rumble(struct winwing_drv_data *data)
+{
+ __u8 *buf;
+ __u8 m;
+
+ if (!data)
+ return -EINVAL;
+
+ buf = data->report_rumble;
+
+ if (!buf)
+ return -EINVAL;
+
+ if (!data->hdev) {
+ hid_err(data->hdev, "data->hdev == NULL\n");
+ return -EINVAL;
+ }
+
+ if (!data->hdev->ll_driver) {
+ hid_err(data->hdev, "data->hdev->ll_driver == NULL\n");
+ return -EINVAL;
+ }
+
+ m = convert_magnitude(data->rumble.strong_magnitude);
+ if (m != data->rumble_left) {
+ int ret;
+
+ buf[0] = 0x02;
+ buf[1] = 0x01;
+ buf[2] = 0xbf;
+ buf[3] = 0x00;
+ buf[4] = 0x00;
+ buf[5] = 0x03;
+ buf[6] = 0x49;
+ buf[7] = 0x00;
+ buf[8] = m;
+ buf[9] = 0x00;
+ buf[10] = 0;
+ buf[11] = 0;
+ buf[12] = 0;
+ buf[13] = 0;
+
+ ret = hid_hw_output_report(data->hdev, buf, 14);
+ if (ret < 0) {
+ hid_err(data->hdev, "error %d (%*ph)\n", ret, 14, buf);
+ return ret;
+ }
+ data->rumble_left = m;
+ }
+
+ m = convert_magnitude(data->rumble.weak_magnitude);
+ if (m != data->rumble_right) {
+ int ret;
+
+ buf[0] = 0x02;
+ buf[1] = 0x03;
+ buf[2] = 0xbf;
+ buf[3] = 0x00;
+ buf[4] = 0x00;
+ buf[5] = 0x03;
+ buf[6] = 0x49;
+ buf[7] = 0x00;
+ buf[8] = m;
+ buf[9] = 0x00;
+ buf[10] = 0;
+ buf[11] = 0;
+ buf[12] = 0;
+ buf[13] = 0;
+
+ ret = hid_hw_output_report(data->hdev, buf, 14);
+ if (ret < 0) {
+ hid_err(data->hdev, "error %d (%*ph)\n", ret, 14, buf);
+ return ret;
+ }
+ data->rumble_right = m;
+ }
+
+ return 0;
+}
+
+
+static void winwing_haptic_rumble_cb(struct work_struct *work)
+{
+ struct winwing_drv_data *data;
+
+ data = container_of(work, struct winwing_drv_data, rumble_work);
+
+ if (data)
+ winwing_haptic_rumble(data);
+}
+
+static int winwing_play_effect(struct input_dev *dev, void *context,
+ struct ff_effect *effect)
+{
+ struct winwing_drv_data *data = (struct winwing_drv_data *) context;
+
+ if (effect->type != FF_RUMBLE)
+ return 0;
+
+ if (!data)
+ return -EINVAL;
+
+ data->rumble = effect->u.rumble;
+
+ return schedule_work(&data->rumble_work);
+}
+
+static int winwing_init_ff(struct hid_device *hdev, struct hid_input *hidinput)
+{
+ struct winwing_drv_data *data;
+
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+ data->report_rumble = devm_kzalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
+ data->rumble_left = -1;
+ data->rumble_right = -1;
+
+ input_set_capability(hidinput->input, EV_FF, FF_RUMBLE);
+
+ if (!data)
+ return -EINVAL;
+
+ return input_ff_create_memless(hidinput->input, data,
+ winwing_play_effect);
+}
+
static int winwing_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -219,10 +361,12 @@ static int winwing_probe(struct hid_device *hdev,
if (!data)
return -ENOMEM;
- data->map_more_buttons = id->driver_data;
-
+ data->hdev = hdev;
+ data->has_grip15 = id->driver_data;
hid_set_drvdata(hdev, data);
+ INIT_WORK(&data->rumble_work, winwing_haptic_rumble_cb);
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "hw start failed\n");
@@ -232,19 +376,39 @@ static int winwing_probe(struct hid_device *hdev,
return 0;
}
+static void winwing_remove(struct hid_device *hdev)
+{
+ struct winwing_drv_data *data;
+
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+
+ if (data)
+ cancel_work_sync(&data->rumble_work);
+
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+}
+
static int winwing_input_configured(struct hid_device *hdev,
struct hid_input *hidinput)
{
+ struct winwing_drv_data *data;
int ret;
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+
ret = winwing_init_led(hdev, hidinput->input);
if (ret)
hid_err(hdev, "led init failed\n");
+ if (data->has_grip15)
+ winwing_init_ff(hdev, hidinput);
+
return ret;
}
+/* Set driver_data to 1 for grips with rumble motor and more than 32 buttons */
static const struct hid_device_id winwing_devices[] = {
{ HID_USB_DEVICE(0x4098, 0xbd65), .driver_data = 1 }, /* TGRIP-15E */
{ HID_USB_DEVICE(0x4098, 0xbd64), .driver_data = 1 }, /* TGRIP-15EX */
@@ -261,6 +425,7 @@ static struct hid_driver winwing_driver = {
.input_configured = winwing_input_configured,
.input_mapping = winwing_input_mapping,
.probe = winwing_probe,
+ .remove = winwing_remove,
};
module_hid_driver(winwing_driver);
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] [input?] [usb?] WARNING in asus_remove
From: Sahil Chandna @ 2026-01-30 6:24 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
In-Reply-To: <697baa8f.a70a0220.9914.001f.GAE@google.com>
#syz test
--- 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);
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox