* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Rob Herring @ 2026-02-08 22:37 UTC (permalink / raw)
To: David Lechner
Cc: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <51eddfc0-9f23-4a7f-8729-19775d834c0b@baylibre.com>
On Sat, Feb 7, 2026 at 11:32 AM David Lechner <dlechner@baylibre.com> wrote:
>
> On 2/7/26 11:25 AM, Svyatoslav Ryhel wrote:
> > сб, 7 лют. 2026 р. о 19:19 David Lechner <dlechner@baylibre.com> пише:
> >>
> >> On 2/7/26 3:20 AM, Svyatoslav Ryhel wrote:
> >>> сб, 7 лют. 2026 р. о 01:09 Rob Herring <robh@kernel.org> пише:
> >>>>
> >>>> On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
> >>>>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> >>>>> from TXT to YAML format. Main functionality preserved.
> >>>>>
> >>
> >> ...
> >>
> >>>>> +properties:
> >>>>> + compatible:
> >>>>> + enum:
> >>>>> + - motorola,cpcap-regulator
> >>>>> + - motorola,mapphone-cpcap-regulator
> >>>>> + - motorola,xoom-cpcap-regulator
> >>>>> +
> >>>>> + regulators:
> >>>>> + type: object
> >>>>> +
> >>>>> + patternProperties:
> >>>>> + "$[A-Z0-9]+^":
> >>>>
> >>>> I thought it was said on the last version to list the names. Considering
> >>>> you already have them below, better to put them in schema than prose.
> >>>> And pretty much all regulator bindings define the names.
> >>>>
> >>>
> >>> What exactly do you propose? All those names will not fit into a
> >>> single unbreakable line (more than 125 columns in length btw). Patch
> >>> checker will complain about this. Duplicate pattern properties for
> >>> every few names? Please be a bit more specific. Thank you!
> >>
> >> Making checkpatch happy is not a hard requirement. If you have to
> >> go over 125 characters for technical reasons, no one is going to
> >> complain.
> >>
> >> I already gave an example on the last version. It is just a regex
> >> expression. (And note that you didn't fix the $ and ^ either. ^
> >> means beginning of the line and $ means the end of the line. So
> >> the pattern currently won't match anything.)
> >>
> >> patternProperties:
> >> "^(SW1|SW2|SW3|SW4|SW5|...)$":
> >>
> >>
> >> And I hope it is obvious that you are meant to replace ... with the
> >> rest of the names separated by |.
> >>
> >
> > David, thank you for your suggestions and I did not want to offend you
> > nor Rob, or ignore. Using this large string IMHO feels a bit wrong. No
> > offence, I will use it if required. At the same time I was
> > experimenting with possible representation and come up with smth like
> > this:
> >
> > patternProperties:
> > "^SW[1-6]$":
> > type: object
> > $ref: /schemas/regulator/regulator.yaml#
> > unevaluatedProperties: false
> >
> > required:
> > - regulator-name
> > - regulator-enable-ramp-delay
> > - regulator-min-microvolt
> > - regulator-max-microvolt
> >
> > "^V(CAM|CSI|DAC|DIG|FUSE|HVIO|SDIO|PLL|RF1|RF2|RFREF)$":
> > type: object
> > $ref: /schemas/regulator/regulator.yaml#
> > unevaluatedProperties: false
> >
> > required:
> > - regulator-name
> > - regulator-enable-ramp-delay
> > - regulator-min-microvolt
> > - regulator-max-microvolt
> >
> > "^V(WLAN1|WLAN2|SIM|SIMCARD|VIB|USB|AUDIO)$":
> > type: object
> > $ref: /schemas/regulator/regulator.yaml#
> > unevaluatedProperties: false
> >
> > required:
> > - regulator-name
> > - regulator-enable-ramp-delay
> > - regulator-min-microvolt
> > - regulator-max-microvolt
> >
> > Will this be acceptable? It passes checks
>
> I think we would rather have the long match string instead of
> repeating the rest of it multiple times.
Yes.
105 chars:
"^(SW[1-6]|V(CAM|CSI|DAC|DIG|FUSE|HVIO|SDIO|PLL|RF[12]|RFREF|WLAN[12]|SIM|SIMCARD|VIB|USB|AUDIO))$":
There is the yamllint of 110 which does have to be followed.
Rob
^ permalink raw reply
* [PATCH v5] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Yedaya Katsman via B4 Relay @ 2026-02-08 21:24 UTC (permalink / raw)
To: Kamil Gołda, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm,
Yedaya Katsman
From: Yedaya Katsman <yedaya.ka@gmail.com>
Add device tree node for the Focaltech FT3518 touchscreen on
Xiaomi Mi A3 (laurel-sprout).
Enable qupv3_id_0 and i2c2 bus that the touchscreen is on.
Downstream references:
Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/trinket-pinctrl.dtsi
Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/laurel_sprout-qrd.dtsi
Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com>
Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com>
---
Adds support for the touchscreen in the Xiaomi Mi A3 (xiaomi-laurel)
smartphone, FocalTech FT3518
Original tree was here:
Link: https://gitlab.postmarketos.org/SzczurekYT/linux/-/commits/laurel
---
Changes in v5:
- Add pin config for ts vdd
- Reorder some properties
- Drop applied patches
- Link to v4: https://lore.kernel.org/r/20260120-touchscreen-patches-v4-0-30145da9d6d3@gmail.com
Changes in v4:
- Follow dts coding style for pinctrl nodes
- Don't refrence touchscreen "release" gpio config
- Link to v3: https://lore.kernel.org/r/20260118-touchscreen-patches-v3-0-1c6a729c5eb4@gmail.com
Changes in v3:
- Rename regulator node and reorder nodes
- Add gpio pin configuration for pmx_ts_* in sm6125, and reference in the
touchscreen configuration as pinctrl-*. Doesn't have configuration for
the gpio 83 pin since it isn't documented downstream.
- Link to v2: https://lore.kernel.org/r/20260114-touchscreen-patches-v2-0-4215f94c8aba@gmail.com
Changes in v2:
- Fixed name and email in signoffs
- Link to v1: https://lore.kernel.org/r/20260113-touchscreen-patches-v1-0-a10957f32dd8@gmail.com
---
.../boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts | 73 ++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
index 994fb0412fcbdf5466f87a325c48b697a37b514b..97f64cb5d570e018ef666612f3839c4e6759ac7b 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
@@ -82,6 +82,19 @@ key-volume-up {
};
};
+ ts_vdd_supply: regulator-ts-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "ts_vdd_supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+
+ enable-active-high;
+ gpio = <&tlmm 83 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&ts_vdd_en>;
+ pinctrl-names = "default";
+ };
+
thermal-zones {
rf-pa0-thermal {
thermal-sensors = <&pm6125_adc_tm 0>;
@@ -128,6 +141,27 @@ &hsusb_phy1 {
status = "okay";
};
+&i2c2 {
+ status = "okay";
+
+ touchscreen@38 {
+ compatible = "focaltech,ft3518";
+ reg = <0x38>;
+ interrupts-extended = <&tlmm 88 IRQ_TYPE_EDGE_FALLING>;
+
+ vcc-supply = <&ts_vdd_supply>;
+
+ pinctrl-0 = <&ts_int_active &ts_reset_active>;
+ pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>;
+ pinctrl-names = "default","sleep";
+
+ reset-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
+
+ touchscreen-size-x = <720>;
+ touchscreen-size-y = <1560>;
+ };
+};
+
&pm6125_adc {
pinctrl-names = "default";
pinctrl-0 = <&camera_flash_therm &emmc_ufs_therm>;
@@ -220,6 +254,10 @@ &pon_resin {
status = "okay";
};
+&qupv3_id_0 {
+ status = "okay";
+};
+
&rpm_requests {
regulators-0 {
compatible = "qcom,rpm-pm6125-regulators";
@@ -387,6 +425,41 @@ &sdhc_2 {
&tlmm {
gpio-reserved-ranges = <22 2>, <28 6>;
+
+ ts_vdd_en: ts-vdd-default-state {
+ pins = "gpio83";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ ts_reset_active: pmx-ts-reset-active-state {
+ pins = "gpio87";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ ts_reset_suspend: pmx-ts-reset-suspend-state {
+ pins = "gpio87";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ ts_int_active: pmx-ts-int-active-state {
+ pins = "gpio88";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ ts_int_suspend: pmx-ts-int-suspend-state {
+ pins = "gpio88";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
};
&ufs_mem_hc {
---
base-commit: 9845cf73f7db6094c0d8419d6adb848028f4a921
change-id: 20260113-touchscreen-patches-beb2526bd5fb
Best regards,
--
Yedaya Katsman <yedaya.ka@gmail.com>
^ permalink raw reply related
* [PATCH] Input: evdev: fix data race in evdev_read() and evdev_poll()
From: Osama Abdelkader @ 2026-02-08 19:45 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel
Cc: Osama Abdelkader, syzbot+1b327485934adf39955b
Protect all reads of client->packet_head with buffer_lock to fix a
KCSAN-reported data race. The race occurs between:
- evdev_pass_values() writing to packet_head (protected by buffer_lock)
- evdev_read() reading packet_head without lock protection
- evdev_poll() reading packet_head without lock protection
The fix ensures all accesses to packet_head are protected by buffer_lock,
matching the existing write-side protection pattern used in
evdev_pass_values() and evdev_fetch_next_event().
Changes:
- evdev_read(): Protect packet_head read in O_NONBLOCK check
- evdev_read(): Protect packet_head read in wait loop condition
- evdev_poll(): Protect packet_head read in poll check
KCSAN report:
BUG: KCSAN: data-race in evdev_pass_values / evdev_read
write to 0xffff888104842008 of 4 bytes by task 8439 on cpu 1:
__pass_event drivers/input/evdev.c:239 [inline]
evdev_pass_values+0x387/0x4e0 drivers/input/evdev.c:278
evdev_events+0x8e/0xd0 drivers/input/evdev.c:306
input_pass_values+0x123/0x390 drivers/input/input.c:128
input_event_dispose+0x248/0x320 drivers/input/input.c:342
input_handle_event+0x9e8/0xa20 drivers/input/input.c:370
input_inject_event+0xbc/0x120 drivers/input/input.c:424
evdev_write+0x224/0x2b0 drivers/input/evdev.c:528
vfs_write+0x269/0x9f0 fs/read_write.c:684
ksys_write+0xdc/0x1a0 fs/read_write.c:738
__do_sys_write fs/read_write.c:749 [inline]
__se_sys_write fs/read_write.c:746 [inline]
__x64_sys_write+0x40/0x50 fs/read_write.c:746
x64_sys_call+0x2847/0x3000 arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff888104842008 of 4 bytes by task 2991 on cpu 0:
evdev_read+0x157/0x5e0 drivers/input/evdev.c:572
vfs_read+0x1ab/0x7f0 fs/read_write.c:570
ksys_read+0xdc/0x1a0 fs/read_write.c:715
__do_sys_read fs/read_write.c:724 [inline]
__se_sys_read fs/read_write.c:722 [inline]
__x64_sys_read+0x40/0x50 fs/read_write.c:722
x64_sys_call+0x2889/0x3000 arch/x86/include/generated/asm/syscalls_64.h:1
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000002 -> 0x00000004
Reported-by: syzbot+1b327485934adf39955b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b327485934adf39955b
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
drivers/input/evdev.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 90ff6be85cf4..eebd59d190f5 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -569,9 +569,13 @@ static ssize_t evdev_read(struct file *file, char __user *buffer,
if (!evdev->exist || client->revoked)
return -ENODEV;
+ spin_lock_irq(&client->buffer_lock);
if (client->packet_head == client->tail &&
- (file->f_flags & O_NONBLOCK))
+ (file->f_flags & O_NONBLOCK)) {
+ spin_unlock_irq(&client->buffer_lock);
return -EAGAIN;
+ }
+ spin_unlock_irq(&client->buffer_lock);
/*
* count == 0 is special - no IO is done but we check
@@ -593,9 +597,12 @@ static ssize_t evdev_read(struct file *file, char __user *buffer,
break;
if (!(file->f_flags & O_NONBLOCK)) {
- error = wait_event_interruptible(client->wait,
+ spin_lock_irq(&client->buffer_lock);
+ error = wait_event_interruptible_lock_irq(client->wait,
client->packet_head != client->tail ||
- !evdev->exist || client->revoked);
+ !evdev->exist || client->revoked,
+ client->buffer_lock);
+ spin_unlock_irq(&client->buffer_lock);
if (error)
return error;
}
@@ -610,6 +617,7 @@ static __poll_t evdev_poll(struct file *file, poll_table *wait)
struct evdev_client *client = file->private_data;
struct evdev *evdev = client->evdev;
__poll_t mask;
+ bool have_data;
poll_wait(file, &client->wait, wait);
@@ -618,7 +626,11 @@ static __poll_t evdev_poll(struct file *file, poll_table *wait)
else
mask = EPOLLHUP | EPOLLERR;
- if (client->packet_head != client->tail)
+ spin_lock_irq(&client->buffer_lock);
+ have_data = client->packet_head != client->tail;
+ spin_unlock_irq(&client->buffer_lock);
+
+ if (have_data)
mask |= EPOLLIN | EPOLLRDNORM;
return mask;
--
2.43.0
^ permalink raw reply related
* [PATCH] usbhid: tolerate intermittent errors
From: Liam Mitchell @ 2026-02-08 17:10 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Alan Stern, linux-usb, linux-input, linux-kernel, Liam Mitchell
Modifies the usbhid error handling logic to better handle intermittent
errors like EPROTO, which should only need resubmission of URBs and not
full device reset.
Reduces initial retry delay from 13ms to 1ms. The faster the URB is
resubmitted, the lower the chance that user events will be missed.
Increases retry delay multiplier from 2 to 5, reaching max delay in a
similar number of retries.
Adds another check to the reset block, only resetting if retry_delay has
reached max, effectively only allowing reset after 4 errors.
---
The usbhid driver will reset a device after only two errors 1-1.5s apart.
The first error will be handled with a retry after 13ms.
Handling of the second error depends on the time since the first:
* <1000ms: retry after 26ms
* >1000ms & <1500ms: reset USB device, taking maybe hundreds of ms
* >1500ms: retry after 13ms
It doesn't take into account the type, count or timing of errors.
EPROTO errors can occur randomly, sometimes frequently and are often not
fixed by a device reset.
Retry delays or device resets only raise the chance that input events will
be missed and that users see symptoms like missed or sticky keyboard keys.
See following thread for more details:
https://lore.kernel.org/linux-input/CAOQ1CL6Q+4GNy=kgisLzs0UBXFT3b02PG8t-0rPuW-Wf6NhQ6g@mail.gmail.com/
The following patch is a minimal change to better tolerate intermittent errors.
Using existing variables, we reduce initial retry delays and only reset in
the 1000-1500ms window if 4+ errors have occurred.
This should reduce issues for users with intermittent errors and retain
the intended retry-backoff-reset for erroring devices that need a reset.
More comprehensive error handling could involve counting errors, time between
errors and/or switching on error type but would be more invasive.
Signed-off-by: Liam Mitchell <mitchell.liam@gmail.com>
---
drivers/hid/usbhid/hid-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index aac0051a2cf6..b6e956ca781b 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -160,12 +160,12 @@ static void hid_io_error(struct hid_device *hid)
/* When an error occurs, retry at increasing intervals */
if (usbhid->retry_delay == 0) {
- usbhid->retry_delay = 13; /* Then 26, 52, 104, 104, ... */
+ usbhid->retry_delay = 1; /* Then 5, 25, 125, 125, ... */
usbhid->stop_retry = jiffies + msecs_to_jiffies(1000);
} else if (usbhid->retry_delay < 100)
- usbhid->retry_delay *= 2;
+ usbhid->retry_delay *= 5;
- if (time_after(jiffies, usbhid->stop_retry)) {
+ if (time_after(jiffies, usbhid->stop_retry) && usbhid->retry_delay >= 100) {
/* Retries failed, so do a port reset unless we lack bandwidth*/
if (!test_bit(HID_NO_BANDWIDTH, &usbhid->iofl)
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20260208-usbhid-eproto-152c7abcb185
Best regards,
--
Liam Mitchell <mitchell.liam@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 10/11] mfd: motorola-cpcap: diverge configuration per-board
From: Svyatoslav Ryhel @ 2026-02-08 15:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <aYiHnUW93AB0ARJH@smile.fi.intel.com>
8 лютого 2026 р. 14:54:53 GMT+02:00, Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>On Fri, Feb 06, 2026 at 07:28:44PM +0200, Svyatoslav Ryhel wrote:
>> MFD have rigid subdevice structure which does not allow flexible dynamic
>> subdevice linking. Address this by diverging CPCAP subdevice composition
>> to take into account board specific configuration.
>>
>> Create a common default subdevice composition, rename existing subdevice
>> composition into cpcap_mapphone_mfd_devices since it targets mainly
>> Mapphone board.
>
>...
>
>> -static const struct of_device_id cpcap_of_match[] = {
>> - { .compatible = "motorola,cpcap", },
>> - { .compatible = "st,6556002", },
>> - {},
>> -};
>> -MODULE_DEVICE_TABLE(of, cpcap_of_match);
>> -
>> static const struct spi_device_id cpcap_spi_ids[] = {
>> { .name = "cpcap", },
>> { .name = "6556002", },
>> + { .name = "mapphone-cpcap", },
>> {},
>> };
>
>This also needs to be converted to use driver data.
>
I can do that, but is it needed? This id table, if I understand correctly, is here solely to silence warnings about missing spi id table. Driver itself does not use it in any way and will never use since all available devices that use this driver rely solely on the device tree, all possible future devices will be relying on device tree too due to obvious reasons.
And please, may you contain all your reviewing in one iteration. Then both of us will spend less time working on the patch. Thank you!
>> MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
>
^ permalink raw reply
* Re: [PATCH v2 11/11] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Andy Shevchenko @ 2026-02-08 14:48 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Andy Shevchenko, 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, linux-iio, devicetree,
linux-kernel, linux-input, linux-leds
In-Reply-To: <39B7F089-5B4A-47F7-B2EA-A526B290FA77@gmail.com>
On Sun, Feb 8, 2026 at 4:41 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> 8 лютого 2026 р. 14:56:18 GMT+02:00, Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> >On Fri, Feb 06, 2026 at 07:28:45PM +0200, Svyatoslav Ryhel wrote:
...
> >> { .name = "cpcap", },
> >> { .name = "6556002", },
> >> { .name = "mapphone-cpcap", },
> >> + { .name = "mot-cpcap", },
> >
> >Drop inner trailing comma.
> >
>
> That would be a stray change, wouldn't it?
Have you read below?
> >> {},
> >
> >Drop a comma at the terminator.
> >
>
> That would be a stray change as well, wouldn't it?
Have you read below?
> >> };
> >> MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> >
> >This can be done in the patch that adds driver data.
^^^
> Then lets move there.
Exactly!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 11/11] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Svyatoslav Ryhel @ 2026-02-08 14:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <aYiH8iwetvRfWxGI@smile.fi.intel.com>
8 лютого 2026 р. 14:56:18 GMT+02:00, Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>On Fri, Feb 06, 2026 at 07:28:45PM +0200, Svyatoslav Ryhel wrote:
>> Add a MFD subdevice composition used in Tegra20 based Mot board
>> (Motorola Atrix 4G and Droid X2).
>
>...
>
>> { .name = "cpcap", },
>> { .name = "6556002", },
>> { .name = "mapphone-cpcap", },
>> + { .name = "mot-cpcap", },
>
>Drop inner trailing comma.
>
That would be a stray change, wouldn't it?
>> {},
>
>Drop a comma at the terminator.
>
That would be a stray change as well, wouldn't it?
>> };
>> MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
>
>This can be done in the patch that adds driver data.
>
Then lets move there.
^ permalink raw reply
* [PATCH v1] Input: joydev: Don't expose DualSense motion sensors as jsX
From: Max Staudt @ 2026-02-08 12:48 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Max Staudt, stable
Without this, DualSense (PS5) gamepads are allocated a second jsX
device for their gyroscope/accelerometer, confusing programs such as
/lib/udev/js-set-enum-leds which look at jsX device numbers to
determine the player number. Ideally, we should have only one jsX
device per gamepad.
This follows the schema started by:
commit 20ac95d52a28 ("Input: joydev - blacklist ds3/ds4/udraw motion sensors")
Fixes: 402987c5d98a ("HID: playstation: add DualSense accelerometer and gyroscope support.")
Cc: stable@vger.kernel.org
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/input/joydev.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c
index ba2b17288bcd..f2fdbc814a8f 100644
--- a/drivers/input/joydev.c
+++ b/drivers/input/joydev.c
@@ -753,6 +753,8 @@ static void joydev_cleanup(struct joydev *joydev)
#define USB_DEVICE_ID_SONY_PS4_CONTROLLER 0x05c4
#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_2 0x09cc
#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE 0x0ba0
+#define USB_DEVICE_ID_SONY_PS5_CONTROLLER 0x0ce6
+#define USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 0x0df2
#define USB_VENDOR_ID_THQ 0x20d6
#define USB_DEVICE_ID_THQ_PS3_UDRAW 0xcb17
@@ -793,6 +795,8 @@ static const struct input_device_id joydev_blacklist[] = {
ACCEL_DEV(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER),
ACCEL_DEV(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
ACCEL_DEV(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
+ ACCEL_DEV(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
+ ACCEL_DEV(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2),
ACCEL_DEV(USB_VENDOR_ID_THQ, USB_DEVICE_ID_THQ_PS3_UDRAW),
ACCEL_DEV(USB_VENDOR_ID_NINTENDO, USB_DEVICE_ID_NINTENDO_PROCON),
ACCEL_DEV(USB_VENDOR_ID_NINTENDO, USB_DEVICE_ID_NINTENDO_CHRGGRIP),
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 11/11] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Andy Shevchenko @ 2026-02-08 12:56 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-12-clamor95@gmail.com>
On Fri, Feb 06, 2026 at 07:28:45PM +0200, Svyatoslav Ryhel wrote:
> Add a MFD subdevice composition used in Tegra20 based Mot board
> (Motorola Atrix 4G and Droid X2).
...
> { .name = "cpcap", },
> { .name = "6556002", },
> { .name = "mapphone-cpcap", },
> + { .name = "mot-cpcap", },
Drop inner trailing comma.
> {},
Drop a comma at the terminator.
> };
> MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
This can be done in the patch that adds driver data.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 10/11] mfd: motorola-cpcap: diverge configuration per-board
From: Andy Shevchenko @ 2026-02-08 12:54 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-11-clamor95@gmail.com>
On Fri, Feb 06, 2026 at 07:28:44PM +0200, Svyatoslav Ryhel wrote:
> MFD have rigid subdevice structure which does not allow flexible dynamic
> subdevice linking. Address this by diverging CPCAP subdevice composition
> to take into account board specific configuration.
>
> Create a common default subdevice composition, rename existing subdevice
> composition into cpcap_mapphone_mfd_devices since it targets mainly
> Mapphone board.
...
> -static const struct of_device_id cpcap_of_match[] = {
> - { .compatible = "motorola,cpcap", },
> - { .compatible = "st,6556002", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> -
> static const struct spi_device_id cpcap_spi_ids[] = {
> { .name = "cpcap", },
> { .name = "6556002", },
> + { .name = "mapphone-cpcap", },
> {},
> };
This also needs to be converted to use driver data.
> MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: David Lechner @ 2026-02-07 17:32 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <CAPVz0n2KwqPw88JVcPzhTQ2n+GKzahkrEThjjrqm0CSdjKTEOw@mail.gmail.com>
On 2/7/26 11:25 AM, Svyatoslav Ryhel wrote:
> сб, 7 лют. 2026 р. о 19:19 David Lechner <dlechner@baylibre.com> пише:
>>
>> On 2/7/26 3:20 AM, Svyatoslav Ryhel wrote:
>>> сб, 7 лют. 2026 р. о 01:09 Rob Herring <robh@kernel.org> пише:
>>>>
>>>> On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
>>>>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
>>>>> from TXT to YAML format. Main functionality preserved.
>>>>>
>>
>> ...
>>
>>>>> +properties:
>>>>> + compatible:
>>>>> + enum:
>>>>> + - motorola,cpcap-regulator
>>>>> + - motorola,mapphone-cpcap-regulator
>>>>> + - motorola,xoom-cpcap-regulator
>>>>> +
>>>>> + regulators:
>>>>> + type: object
>>>>> +
>>>>> + patternProperties:
>>>>> + "$[A-Z0-9]+^":
>>>>
>>>> I thought it was said on the last version to list the names. Considering
>>>> you already have them below, better to put them in schema than prose.
>>>> And pretty much all regulator bindings define the names.
>>>>
>>>
>>> What exactly do you propose? All those names will not fit into a
>>> single unbreakable line (more than 125 columns in length btw). Patch
>>> checker will complain about this. Duplicate pattern properties for
>>> every few names? Please be a bit more specific. Thank you!
>>
>> Making checkpatch happy is not a hard requirement. If you have to
>> go over 125 characters for technical reasons, no one is going to
>> complain.
>>
>> I already gave an example on the last version. It is just a regex
>> expression. (And note that you didn't fix the $ and ^ either. ^
>> means beginning of the line and $ means the end of the line. So
>> the pattern currently won't match anything.)
>>
>> patternProperties:
>> "^(SW1|SW2|SW3|SW4|SW5|...)$":
>>
>>
>> And I hope it is obvious that you are meant to replace ... with the
>> rest of the names separated by |.
>>
>
> David, thank you for your suggestions and I did not want to offend you
> nor Rob, or ignore. Using this large string IMHO feels a bit wrong. No
> offence, I will use it if required. At the same time I was
> experimenting with possible representation and come up with smth like
> this:
>
> patternProperties:
> "^SW[1-6]$":
> type: object
> $ref: /schemas/regulator/regulator.yaml#
> unevaluatedProperties: false
>
> required:
> - regulator-name
> - regulator-enable-ramp-delay
> - regulator-min-microvolt
> - regulator-max-microvolt
>
> "^V(CAM|CSI|DAC|DIG|FUSE|HVIO|SDIO|PLL|RF1|RF2|RFREF)$":
> type: object
> $ref: /schemas/regulator/regulator.yaml#
> unevaluatedProperties: false
>
> required:
> - regulator-name
> - regulator-enable-ramp-delay
> - regulator-min-microvolt
> - regulator-max-microvolt
>
> "^V(WLAN1|WLAN2|SIM|SIMCARD|VIB|USB|AUDIO)$":
> type: object
> $ref: /schemas/regulator/regulator.yaml#
> unevaluatedProperties: false
>
> required:
> - regulator-name
> - regulator-enable-ramp-delay
> - regulator-min-microvolt
> - regulator-max-microvolt
>
> Will this be acceptable? It passes checks
I think we would rather have the long match string instead of
repeating the rest of it multiple times.
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Svyatoslav Ryhel @ 2026-02-07 17:25 UTC (permalink / raw)
To: David Lechner
Cc: Rob Herring, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <db9115ca-2c8f-4b5e-89ce-f3b934071a59@baylibre.com>
сб, 7 лют. 2026 р. о 19:19 David Lechner <dlechner@baylibre.com> пише:
>
> On 2/7/26 3:20 AM, Svyatoslav Ryhel wrote:
> > сб, 7 лют. 2026 р. о 01:09 Rob Herring <robh@kernel.org> пише:
> >>
> >> On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
> >>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> >>> from TXT to YAML format. Main functionality preserved.
> >>>
>
> ...
>
> >>> +properties:
> >>> + compatible:
> >>> + enum:
> >>> + - motorola,cpcap-regulator
> >>> + - motorola,mapphone-cpcap-regulator
> >>> + - motorola,xoom-cpcap-regulator
> >>> +
> >>> + regulators:
> >>> + type: object
> >>> +
> >>> + patternProperties:
> >>> + "$[A-Z0-9]+^":
> >>
> >> I thought it was said on the last version to list the names. Considering
> >> you already have them below, better to put them in schema than prose.
> >> And pretty much all regulator bindings define the names.
> >>
> >
> > What exactly do you propose? All those names will not fit into a
> > single unbreakable line (more than 125 columns in length btw). Patch
> > checker will complain about this. Duplicate pattern properties for
> > every few names? Please be a bit more specific. Thank you!
>
> Making checkpatch happy is not a hard requirement. If you have to
> go over 125 characters for technical reasons, no one is going to
> complain.
>
> I already gave an example on the last version. It is just a regex
> expression. (And note that you didn't fix the $ and ^ either. ^
> means beginning of the line and $ means the end of the line. So
> the pattern currently won't match anything.)
>
> patternProperties:
> "^(SW1|SW2|SW3|SW4|SW5|...)$":
>
>
> And I hope it is obvious that you are meant to replace ... with the
> rest of the names separated by |.
>
David, thank you for your suggestions and I did not want to offend you
nor Rob, or ignore. Using this large string IMHO feels a bit wrong. No
offence, I will use it if required. At the same time I was
experimenting with possible representation and come up with smth like
this:
patternProperties:
"^SW[1-6]$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
- regulator-name
- regulator-enable-ramp-delay
- regulator-min-microvolt
- regulator-max-microvolt
"^V(CAM|CSI|DAC|DIG|FUSE|HVIO|SDIO|PLL|RF1|RF2|RFREF)$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
- regulator-name
- regulator-enable-ramp-delay
- regulator-min-microvolt
- regulator-max-microvolt
"^V(WLAN1|WLAN2|SIM|SIMCARD|VIB|USB|AUDIO)$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
- regulator-name
- regulator-enable-ramp-delay
- regulator-min-microvolt
- regulator-max-microvolt
Will this be acceptable? It passes checks
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: David Lechner @ 2026-02-07 17:19 UTC (permalink / raw)
To: Svyatoslav Ryhel, Rob Herring
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <CAPVz0n3EGCSLUX7jTLve0x0z4uW1yexViCwkSQLY2d_4r4qkjg@mail.gmail.com>
On 2/7/26 3:20 AM, Svyatoslav Ryhel wrote:
> сб, 7 лют. 2026 р. о 01:09 Rob Herring <robh@kernel.org> пише:
>>
>> On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
>>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
>>> from TXT to YAML format. Main functionality preserved.
>>>
...
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - motorola,cpcap-regulator
>>> + - motorola,mapphone-cpcap-regulator
>>> + - motorola,xoom-cpcap-regulator
>>> +
>>> + regulators:
>>> + type: object
>>> +
>>> + patternProperties:
>>> + "$[A-Z0-9]+^":
>>
>> I thought it was said on the last version to list the names. Considering
>> you already have them below, better to put them in schema than prose.
>> And pretty much all regulator bindings define the names.
>>
>
> What exactly do you propose? All those names will not fit into a
> single unbreakable line (more than 125 columns in length btw). Patch
> checker will complain about this. Duplicate pattern properties for
> every few names? Please be a bit more specific. Thank you!
Making checkpatch happy is not a hard requirement. If you have to
go over 125 characters for technical reasons, no one is going to
complain.
I already gave an example on the last version. It is just a regex
expression. (And note that you didn't fix the $ and ^ either. ^
means beginning of the line and $ means the end of the line. So
the pattern currently won't match anything.)
patternProperties:
"^(SW1|SW2|SW3|SW4|SW5|...)$":
And I hope it is obvious that you are meant to replace ... with the
rest of the names separated by |.
^ permalink raw reply
* [PATCH] bcm5974: recover from failed mode switch
From: Liam Mitchell @ 2026-02-07 17:16 UTC (permalink / raw)
To: Henrik Rydberg, Dmitry Torokhov; +Cc: linux-input, linux-kernel, Liam Mitchell
Mode switches sent before control response are ignored.
On receiving unknown 8-byte packets, assume that mode switch was ignored
and reset by switching to normal mode, waiting then switching back to
wellspring mode.
---
This patch addresses an issue where the bcm5974 driver switches modes
before the device is ready, resulting in an unresponsive trackpad and
"bcm5974: bad trackpad package, length: 8" repeated in logs.
Discussion of issue in the thread:
https://lore.kernel.org/linux-input/CAOQ1CL4+DP1TuLAGNsz5GdFBTHvnTg=5q=Dr2Z1OQc6RXydSYA@mail.gmail.com/
This fix is conservative, avoiding changing existing mode-switch
behavior because I cannot test all variations of hardware.
On receiving an unknown 8-byte packet, we assume the device is not in
wellspring mode and schedule an asynchronous mode reset.
Signed-off-by: Liam Mitchell <mitchell.liam@gmail.com>
---
drivers/input/mouse/bcm5974.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index dfdfb59cc8b5..85ddd65f2603 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -286,6 +286,8 @@ struct bcm5974 {
const struct tp_finger *index[MAX_FINGERS]; /* finger index data */
struct input_mt_pos pos[MAX_FINGERS]; /* position array */
int slots[MAX_FINGERS]; /* slot assignments */
+ struct work_struct mode_reset_work;
+ unsigned long last_mode_reset;
};
/* trackpad finger block data, le16-aligned */
@@ -696,6 +698,34 @@ static int bcm5974_wellspring_mode(struct bcm5974 *dev, bool on)
return retval;
}
+/*
+ * Mode switches sent before the control response are ignored.
+ * Fixing this state requires switching to normal mode and waiting
+ * 1ms before switching back to wellspring mode.
+ */
+static void bcm5974_mode_reset_work(struct work_struct *work)
+{
+ int error;
+ struct bcm5974 *dev = container_of(work, struct bcm5974, mode_reset_work);
+
+ mutex_lock(&dev->pm_mutex);
+ dev->last_mode_reset = jiffies;
+
+ error = bcm5974_wellspring_mode(dev, false);
+ if (error) {
+ dprintk(1, "bcm5974: reset to normal mode failed\n");
+ goto out;
+ }
+
+ msleep(1);
+
+ error = bcm5974_wellspring_mode(dev, true);
+ if (error)
+ dprintk(1, "bcm5974: mode switch after reset failed\n");
+ out:
+ mutex_unlock(&dev->pm_mutex);
+}
+
static void bcm5974_irq_button(struct urb *urb)
{
struct bcm5974 *dev = urb->context;
@@ -752,10 +782,18 @@ static void bcm5974_irq_trackpad(struct urb *urb)
if (dev->tp_urb->actual_length == 2)
goto exit;
- if (report_tp_state(dev, dev->tp_urb->actual_length))
+ if (report_tp_state(dev, dev->tp_urb->actual_length)) {
dprintk(1, "bcm5974: bad trackpad package, length: %d\n",
dev->tp_urb->actual_length);
+ /* HID packet means we aren't in wellspring mode */
+ /* If we haven't tried a reset in the last second, try now */
+ if (dev->tp_urb->actual_length == 8 &&
+ time_after(jiffies, dev->last_mode_reset + msecs_to_jiffies(1000))) {
+ schedule_work(&dev->mode_reset_work);
+ }
+ }
+
exit:
error = usb_submit_urb(dev->tp_urb, GFP_ATOMIC);
if (error)
@@ -906,6 +944,8 @@ static int bcm5974_probe(struct usb_interface *iface,
dev->intf = iface;
dev->input = input_dev;
dev->cfg = *cfg;
+ dev->last_mode_reset = 0;
+ INIT_WORK(&dev->mode_reset_work, bcm5974_mode_reset_work);
mutex_init(&dev->pm_mutex);
/* setup urbs */
@@ -998,6 +1038,7 @@ static void bcm5974_disconnect(struct usb_interface *iface)
{
struct bcm5974 *dev = usb_get_intfdata(iface);
+ cancel_work_sync(&dev->mode_reset_work);
usb_set_intfdata(iface, NULL);
input_unregister_device(dev->input);
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20260207-bcm5974-reset-85ccdfca9641
Best regards,
--
Liam Mitchell <mitchell.liam@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 05/11] iio: adc: cpcap-adc: add support for Mot ADC
From: Jonathan Cameron @ 2026-02-07 13:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-6-clamor95@gmail.com>
On Fri, 6 Feb 2026 19:28:39 +0200
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> Add support for ADC found in Motorola Mot board, used as a base for
> Atrix 4G and Droid X2 smartphones.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Applied to the testing branch of iio.git.
thanks,
Jonathan
> ---
> drivers/iio/adc/cpcap-adc.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
> index d9ee2ea116a7..f6f72efcc6ed 100644
> --- a/drivers/iio/adc/cpcap-adc.c
> +++ b/drivers/iio/adc/cpcap-adc.c
> @@ -934,6 +934,17 @@ static const struct cpcap_adc_ato mapphone_adc = {
> .atox_ps_factor_out = 0,
> };
>
> +static const struct cpcap_adc_ato mot_adc = {
> + .ato_in = 0x0300,
> + .atox_in = 0,
> + .adc_ps_factor_in = 0x0200,
> + .atox_ps_factor_in = 0,
> + .ato_out = 0x0780,
> + .atox_out = 0,
> + .adc_ps_factor_out = 0x0600,
> + .atox_ps_factor_out = 0,
> +};
> +
> static const struct of_device_id cpcap_adc_id_table[] = {
> {
> .compatible = "motorola,cpcap-adc",
> @@ -942,6 +953,10 @@ static const struct of_device_id cpcap_adc_id_table[] = {
> .compatible = "motorola,mapphone-cpcap-adc",
> .data = &mapphone_adc,
> },
> + {
> + .compatible = "motorola,mot-cpcap-adc",
> + .data = &mot_adc,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(of, cpcap_adc_id_table);
^ permalink raw reply
* Re: [PATCH v2 04/11] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: Jonathan Cameron @ 2026-02-07 13:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: 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, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-5-clamor95@gmail.com>
On Fri, 6 Feb 2026 19:28:38 +0200
Svyatoslav Ryhel <clamor95@gmail.com> 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.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Applied to the testing branch of iio.git.
Thanks,
Jonathan
> ---
> .../devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml b/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> index 9ceb6f18c854..1f77da7f8e06 100644
> --- a/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> @@ -19,6 +19,7 @@ properties:
> enum:
> - motorola,cpcap-adc
> - motorola,mapphone-cpcap-adc
> + - motorola,mot-cpcap-adc
>
> interrupts:
> maxItems: 1
^ permalink raw reply
* Re: [PATCH v1] input: xpad: Add support for BETOP BTP-KP50B/C controller's wireless mode
From: Antheas Kapenekakis @ 2026-02-07 12:00 UTC (permalink / raw)
To: Shengyu Qu
Cc: dmitry.torokhov, vi, niltonperimneto, linux-input, linux-kernel
In-Reply-To: <TY4PR01MB144320C2F5B24AEA833ECFB2E9867A@TY4PR01MB14432.jpnprd01.prod.outlook.com>
On Sat, 7 Feb 2026 at 05:57, Shengyu Qu <wiagn233@outlook.com> wrote:
>
> Update on commit info: seems these controllers support Xbox mode when
> using wired mode, however, their firmware has some weird enumeration
> logic that won't work with current xpad driver(It would enum as xbox
> first if no driver is loaded, then disconnect and re-enum as NS
> controller, finally something else), and by default wired mode would end
> with nintendo driver.
Hi,
if I recall, this logic abuses some HID descriptor logic to cycle the
mode depending on the OS. The arch wiki has a potential fix for
certain controllers.
This makes you end up in Android mode since linux kernel. Nintendo
uses a BSD-based kernel, and the Windows NT kernel is different. So by
breaking the protocol in different ways they get it to cycle.
Antheas
> 在 2026/2/5 22:15, Shengyu Qu 写道:
> > BETOP's BTP-KP50B and BTP-KP50C controller's wireless dongles are both
> > working as standard Xbox 360 controllers. Add USB device IDs for them to
> > xpad driver.
> >
> > Both controllers can't work as Xbox controllers when using wired mode and
> > have different USB IDs.
> >
> > Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> > ---
> > drivers/input/joystick/xpad.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> > index 363d50949386..260dd41ea6e5 100644
> > --- a/drivers/input/joystick/xpad.c
> > +++ b/drivers/input/joystick/xpad.c
> > @@ -360,6 +360,8 @@ static const struct xpad_device {
> > { 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
> > { 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
> > { 0x1ee9, 0x1590, "ZOTAC Gaming Zone", 0, XTYPE_XBOX360 },
> > + { 0x20bc, 0x5134, "BETOP BTP-KP50B Xinput Dongle", 0, XTYPE_XBOX360 },
> > + { 0x20bc, 0x514a, "BETOP BTP-KP50C Xinput Dongle", 0, XTYPE_XBOX360 },
> > { 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
> > { 0x20d6, 0x2009, "PowerA Enhanced Wired Controller for Xbox Series X|S", 0, XTYPE_XBOXONE },
> > { 0x20d6, 0x2064, "PowerA Wired Controller for Xbox", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
> > @@ -562,6 +564,7 @@ static const struct usb_device_id xpad_table[] = {
> > XPAD_XBOX360_VENDOR(0x1a86), /* Nanjing Qinheng Microelectronics (WCH) */
> > XPAD_XBOX360_VENDOR(0x1bad), /* Harmonix Rock Band guitar and drums */
> > XPAD_XBOX360_VENDOR(0x1ee9), /* ZOTAC Technology Limited */
> > + XPAD_XBOX360_VENDOR(0x20bc), /* BETOP wireless dongles */
> > XPAD_XBOX360_VENDOR(0x20d6), /* PowerA controllers */
> > XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA controllers */
> > XPAD_XBOX360_VENDOR(0x2345), /* Machenike Controllers */
>
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Svyatoslav Ryhel @ 2026-02-07 9:20 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206230922.GA254792-robh@kernel.org>
сб, 7 лют. 2026 р. о 01:09 Rob Herring <robh@kernel.org> пише:
>
> On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> > from TXT to YAML format. Main functionality preserved.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> > .../regulator/motorola,cpcap-regulator.yaml | 50 +++++++++++++++++++
> > 2 files changed, 50 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 {
> > - 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..50bc57f06b51
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > @@ -0,0 +1,50 @@
> > +# 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,xoom-cpcap-regulator
> > +
> > + regulators:
> > + type: object
> > +
> > + patternProperties:
> > + "$[A-Z0-9]+^":
>
> I thought it was said on the last version to list the names. Considering
> you already have them below, better to put them in schema than prose.
> And pretty much all regulator bindings define the names.
>
What exactly do you propose? All those names will not fit into a
single unbreakable line (more than 125 columns in length btw). Patch
checker will complain about this. Duplicate pattern properties for
every few names? Please be a bit more specific. Thank you!
> > + $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
> > +
> > + required:
> > + - regulator-name
> > + - regulator-enable-ramp-delay
> > + - regulator-min-microvolt
> > + - regulator-max-microvolt
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
> > +...
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v1] input: xpad: Add support for BETOP BTP-KP50B/C controller's wireless mode
From: Shengyu Qu @ 2026-02-07 4:57 UTC (permalink / raw)
To: dmitry.torokhov, vi, lkml, niltonperimneto, linux-input,
linux-kernel
Cc: wiagn233
In-Reply-To: <TY4PR01MB1443218CD6B7089D3DBF893989899A@TY4PR01MB14432.jpnprd01.prod.outlook.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2262 bytes --]
Update on commit info: seems these controllers support Xbox mode when
using wired mode, however, their firmware has some weird enumeration
logic that won't work with current xpad driver(It would enum as xbox
first if no driver is loaded, then disconnect and re-enum as NS
controller, finally something else), and by default wired mode would end
with nintendo driver.
在 2026/2/5 22:15, Shengyu Qu 写道:
> BETOP's BTP-KP50B and BTP-KP50C controller's wireless dongles are both
> working as standard Xbox 360 controllers. Add USB device IDs for them to
> xpad driver.
>
> Both controllers can't work as Xbox controllers when using wired mode and
> have different USB IDs.
>
> Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
> ---
> drivers/input/joystick/xpad.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 363d50949386..260dd41ea6e5 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -360,6 +360,8 @@ static const struct xpad_device {
> { 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
> { 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
> { 0x1ee9, 0x1590, "ZOTAC Gaming Zone", 0, XTYPE_XBOX360 },
> + { 0x20bc, 0x5134, "BETOP BTP-KP50B Xinput Dongle", 0, XTYPE_XBOX360 },
> + { 0x20bc, 0x514a, "BETOP BTP-KP50C Xinput Dongle", 0, XTYPE_XBOX360 },
> { 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
> { 0x20d6, 0x2009, "PowerA Enhanced Wired Controller for Xbox Series X|S", 0, XTYPE_XBOXONE },
> { 0x20d6, 0x2064, "PowerA Wired Controller for Xbox", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
> @@ -562,6 +564,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOX360_VENDOR(0x1a86), /* Nanjing Qinheng Microelectronics (WCH) */
> XPAD_XBOX360_VENDOR(0x1bad), /* Harmonix Rock Band guitar and drums */
> XPAD_XBOX360_VENDOR(0x1ee9), /* ZOTAC Technology Limited */
> + XPAD_XBOX360_VENDOR(0x20bc), /* BETOP wireless dongles */
> XPAD_XBOX360_VENDOR(0x20d6), /* PowerA controllers */
> XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA controllers */
> XPAD_XBOX360_VENDOR(0x2345), /* Machenike Controllers */
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Rob Herring @ 2026-02-06 23:09 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-2-clamor95@gmail.com>
On Fri, Feb 06, 2026 at 07:28:35PM +0200, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> .../regulator/motorola,cpcap-regulator.yaml | 50 +++++++++++++++++++
> 2 files changed, 50 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 {
> - 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..50bc57f06b51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> @@ -0,0 +1,50 @@
> +# 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,xoom-cpcap-regulator
> +
> + regulators:
> + type: object
> +
> + patternProperties:
> + "$[A-Z0-9]+^":
I thought it was said on the last version to list the names. Considering
you already have them below, better to put them in schema than prose.
And pretty much all regulator bindings define the names.
> + $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
> +
> + required:
> + - regulator-name
> + - regulator-enable-ramp-delay
> + - regulator-min-microvolt
> + - regulator-max-microvolt
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +...
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v2 07/11] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Rob Herring (Arm) @ 2026-02-06 22:58 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Andy Shevchenko, Jonathan Cameron, Dixit Parmar,
Lee Jones, Liam Girdwood, Tony Lindgren, Krzysztof Kozlowski,
Pavel Machek, linux-iio, Mark Brown, linux-input, devicetree,
linux-leds, linux-kernel, Conor Dooley, David Lechner,
Nuno Sá
In-Reply-To: <20260206172845.145407-8-clamor95@gmail.com>
On Fri, 06 Feb 2026 19:28:41 +0200, Svyatoslav Ryhel wrote:
> Convert power button devicetree bindings for the Motorola CPCAP MFD from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 20 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Documentation/devicetree/bindings/mfd/motorola-cpcap.txt: Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260206172845.145407-8-clamor95@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 06/11] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Rob Herring (Arm) @ 2026-02-06 22:58 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, Nuno Sá, Dmitry Torokhov, David Lechner,
Dixit Parmar, linux-iio, Conor Dooley, devicetree, linux-leds,
Krzysztof Kozlowski, Tony Lindgren, Andy Shevchenko, Pavel Machek,
Liam Girdwood, Lee Jones, Mark Brown, linux-input, linux-kernel
In-Reply-To: <20260206172845.145407-7-clamor95@gmail.com>
On Fri, 06 Feb 2026 19:28:40 +0200, 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>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> .../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
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/leds/leds-cpcap.txt
Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Documentation/devicetree/bindings/mfd/motorola-cpcap.txt: Documentation/devicetree/bindings/leds/leds-cpcap.txt
See https://patchwork.kernel.org/project/devicetree/patch/20260206172845.145407-7-clamor95@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Rob Herring (Arm) @ 2026-02-06 22:58 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Liam Girdwood, Dmitry Torokhov, devicetree, David Lechner,
Conor Dooley, linux-input, Andy Shevchenko, Lee Jones,
Nuno Sá, Tony Lindgren, Pavel Machek, linux-iio, linux-leds,
Dixit Parmar, Mark Brown, linux-kernel, Jonathan Cameron,
Krzysztof Kozlowski
In-Reply-To: <20260206172845.145407-2-clamor95@gmail.com>
On Fri, 06 Feb 2026 19:28:35 +0200, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> .../regulator/motorola,cpcap-regulator.yaml | 50 +++++++++++++++++++
> 2 files changed, 50 insertions(+), 35 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
Warning: Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Documentation/devicetree/bindings/mfd/motorola-cpcap.txt: Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
See https://patchwork.kernel.org/project/devicetree/patch/20260206172845.145407-2-clamor95@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] HID: ft260: fix block size validation in SMBus transfers
From: Michael Zaidman @ 2026-02-06 22:22 UTC (permalink / raw)
To: Rostislav Nesin
Cc: Jiri Kosina, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel, lvc-project, syzbot+64ca69977b37604cd6d9
In-Reply-To: <20260206043600.780298-1-ssp.nesin@crpt.ru>
[-- Attachment #1.1: Type: text/plain, Size: 5836 bytes --]
Hi Rostislav,
Thank you for the patch and for reporting this.
The bug is real: an unvalidated data->block[0] in the native SMBus
path can cause OOB access, and your analysis is correct.
However, I'd prefer to fix this in the I2C core rather than in
individual drivers. Here is why:
drivers/i2c/i2c-core-smbus.c already validates block size in the
emulated path (i2c_smbus_xfer_emulated): for I2C_SMBUS_BLOCK_DATA
write, I2C_SMBUS_I2C_BLOCK_DATA, and I2C_SMBUS_BLOCK_PROC_CALL it
rejects data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL. But when
the adapter provides a native smbus_xfer, __i2c_smbus_xfer() calls
it without any prior validation on data->block[0].
This means every native SMBus adapter is exposed. For example,
hid-mcp2221 has the exact same class of bug -- it uses data->block[0]
in the block paths without any upper-bound check. hid-cp2112 happens
to have a driver-level guard, but relying on each driver to do this
independently is fragile.
Fixing it once in __i2c_smbus_xfer() protects all native SMBus
adapters and aligns the native path with the emulated path's contract.
Also note that the correct bound is data->block[0] > I2C_SMBUS_BLOCK_MAX
(i.e. > 32), consistent with the UAPI definition of union i2c_smbus_data
and the emulated path checks. The + 1 in the submitted patch would allow
33, which is already out of spec per the SMBus standard.
Could you please respin the patch against drivers/i2c/i2c-core-smbus.c
instead? Something like in the attached .diff file, added in
__i2c_smbus_xfer() right
after flags &= ... and before xfer_func = adapter->algo->smbus_xfer
You can keep the same Reported-by, Closes, and Fixes tags. Once this
core patch is in, we won't need separate driver-level checks in
hid-ft260 (or hid-mcp2221).
Thanks,
Michael
On Fri, Feb 6, 2026 at 6:36 AM Rostislav Nesin <ssp.nesin@crpt.ru> wrote:
> In ft260_smbus_xfer(), data->block[0] specifies the data length for
> block transfers. Without proper validation, a caller can set block[0]
> to a value larger than I2C_SMBUS_BLOCK_MAX (32), causing out-of-bounds
> access in both ft260_smbus_write() and ft260_i2c_read(). This
> triggered the out-of-bounds access reported by syzbot.
>
> BUG: KASAN: stack-out-of-bounds in ft260_smbus_write+0x19b/0x2f0
> drivers/hid/hid-ft260.c:486
> Read of size 42 at addr ffffc90003427d81 by task syz.2.65/6119
>
> CPU: 0 UID: 0 PID: 6119 Comm: syz.2.65 Not tainted syzkaller #0
> PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 10/25/2025
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:378 [inline]
> print_report+0xcd/0x630 mm/kasan/report.c:482
> kasan_report+0xe0/0x110 mm/kasan/report.c:595
> check_region_inline mm/kasan/generic.c:194 [inline]
> kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200
> __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
> ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
> ft260_smbus_xfer+0x22c/0x640 drivers/hid/hid-ft260.c:736
> __i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:591 [inline]
> __i2c_smbus_xfer+0x4f0/0xf60 drivers/i2c/i2c-core-smbus.c:554
> i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:546 [inline]
> i2c_smbus_xfer+0x200/0x3c0 drivers/i2c/i2c-core-smbus.c:536
> i2cdev_ioctl_smbus+0x237/0x990 drivers/i2c/i2c-dev.c:389
> i2cdev_ioctl+0x361/0x840 drivers/i2c/i2c-dev.c:478
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl fs/ioctl.c:583 [inline]
> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> </TASK>
>
> Add validation for data->block[0] > I2C_SMBUS_BLOCK_MAX + 1 at the
> start of I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_I2C_BLOCK_DATA cases to
> protect both read and write paths.
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Reported-by: syzbot+64ca69977b37604cd6d9@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9
> Fixes: 6a82582d9fa4 ("HID: ft260: add usb hid to i2c host bridge driver")
> Signed-off-by: Rostislav Nesin <ssp.nesin@crpt.ru>
> ---
> drivers/hid/hid-ft260.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> index 79505c64dbfe..7bd858e40826 100644
> --- a/drivers/hid/hid-ft260.c
> +++ b/drivers/hid/hid-ft260.c
> @@ -659,6 +659,10 @@ static int ft260_smbus_xfer(struct i2c_adapter
> *adapter, u16 addr, u16 flags,
> }
> break;
> case I2C_SMBUS_BLOCK_DATA:
> + if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1) {
> + ret = -EINVAL;
> + goto smbus_exit;
> + }
> if (read_write == I2C_SMBUS_READ) {
> ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,
> FT260_FLAG_START);
> @@ -675,6 +679,10 @@ static int ft260_smbus_xfer(struct i2c_adapter
> *adapter, u16 addr, u16 flags,
> }
> break;
> case I2C_SMBUS_I2C_BLOCK_DATA:
> + if (data->block[0] > I2C_SMBUS_BLOCK_MAX + 1) {
> + ret = -EINVAL;
> + goto smbus_exit;
> + }
> if (read_write == I2C_SMBUS_READ) {
> ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,
> FT260_FLAG_START);
> --
> 2.34.1
>
[-- Attachment #1.2: Type: text/html, Size: 7026 bytes --]
[-- Attachment #2: i2c-core-smbus-validate-block-size.diff --]
[-- Type: application/octet-stream, Size: 1268 bytes --]
---
drivers/i2c/i2c-core-smbus.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -576,6 +576,35 @@ s32 __i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
flags &= I2C_M_TEN | I2C_CLIENT_PEC | I2C_CLIENT_SCCB;
+ /*
+ * Validate block transfer sizes so that adapters that implement
+ * native smbus_xfer see the same contract as the emulated path.
+ */
+ if (data) {
+ switch (protocol) {
+ case I2C_SMBUS_BLOCK_DATA:
+ case I2C_SMBUS_I2C_BLOCK_DATA:
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev,
+ "Invalid block size %d (max %d)\n",
+ data->block[0], I2C_SMBUS_BLOCK_MAX);
+ return -EINVAL;
+ }
+ break;
+ case I2C_SMBUS_BLOCK_PROC_CALL:
+ if (read_write == I2C_SMBUS_WRITE &&
+ data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev,
+ "Invalid block write size %d (max %d)\n",
+ data->block[0], I2C_SMBUS_BLOCK_MAX);
+ return -EINVAL;
+ }
+ break;
+ default:
+ break;
+ }
+ }
+
xfer_func = adapter->algo->smbus_xfer;
if (i2c_in_atomic_xfer_mode()) {
if (adapter->algo->smbus_xfer_atomic)
^ permalink raw reply
* [PATCH v2 11/11] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Svyatoslav Ryhel @ 2026-02-06 17:28 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,
Svyatoslav Ryhel, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds
In-Reply-To: <20260206172845.145407-1-clamor95@gmail.com>
Add a MFD subdevice composition used in Tegra20 based Mot board
(Motorola Atrix 4G and Droid X2).
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 50 ++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index bea11868e823..d64c83614f12 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -206,6 +206,7 @@ static const struct spi_device_id cpcap_spi_ids[] = {
{ .name = "cpcap", },
{ .name = "6556002", },
{ .name = "mapphone-cpcap", },
+ { .name = "mot-cpcap", },
{},
};
MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
@@ -343,6 +344,54 @@ static const struct cpcap_chip_data cpcap_mapphone_data = {
.num_devices = ARRAY_SIZE(cpcap_mapphone_mfd_devices),
};
+/*
+ * The Mot board features a USB-PHY and charger similar to the ones in
+ * Mapphone; however, because Mot is based on Tegra20, it is incompatible
+ * with the existing implementation, which is tightly interconnected with
+ * the OMAP USB PHY.
+ */
+static const struct mfd_cell cpcap_mot_mfd_devices[] = {
+ {
+ .name = "cpcap_adc",
+ .of_compatible = "motorola,mot-cpcap-adc",
+ }, {
+ .name = "cpcap_battery",
+ .of_compatible = "motorola,cpcap-battery",
+ }, {
+ .name = "cpcap-regulator",
+ .of_compatible = "motorola,mot-cpcap-regulator",
+ }, {
+ .name = "cpcap-rtc",
+ .of_compatible = "motorola,cpcap-rtc",
+ }, {
+ .name = "cpcap-pwrbutton",
+ .of_compatible = "motorola,cpcap-pwrbutton",
+ }, {
+ .name = "cpcap-led",
+ .id = 0,
+ .of_compatible = "motorola,cpcap-led-red",
+ }, {
+ .name = "cpcap-led",
+ .id = 1,
+ .of_compatible = "motorola,cpcap-led-green",
+ }, {
+ .name = "cpcap-led",
+ .id = 2,
+ .of_compatible = "motorola,cpcap-led-blue",
+ }, {
+ .name = "cpcap-led",
+ .id = 3,
+ .of_compatible = "motorola,cpcap-led-adl",
+ }, {
+ .name = "cpcap-codec",
+ },
+};
+
+static const struct cpcap_chip_data cpcap_mot_data = {
+ .mfd_devices = cpcap_mot_mfd_devices,
+ .num_devices = ARRAY_SIZE(cpcap_mot_mfd_devices),
+};
+
static int cpcap_probe(struct spi_device *spi)
{
struct cpcap_ddata *cpcap;
@@ -398,6 +447,7 @@ static const struct of_device_id cpcap_of_match[] = {
{ .compatible = "motorola,cpcap", .data = &cpcap_default_data },
{ .compatible = "st,6556002", .data = &cpcap_default_data },
{ .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
+ { .compatible = "motorola,mot-cpcap", .data = &cpcap_mot_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, cpcap_of_match);
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox