* Re: [PATCH v2 01/11] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Svyatoslav Ryhel @ 2026-02-09 7:13 UTC (permalink / raw)
To: Rob Herring, David Lechner
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: <CAL_Jsq+JzAnvW3zSC7Y=dpWTKMUwFfTOuAnMS21d+F_W=5ONeg@mail.gmail.com>
9 лютого 2026 р. 00:37:41 GMT+02:00, Rob Herring <robh@kernel.org> пише:
>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.
>
Amazing! Thank you both for your suggestions.
>Rob
^ permalink raw reply
* Re: [PATCH] Input: cyapa - fix missing input->mutex when calling input_device_enabled()
From: Ziyi Guo @ 2026-02-09 6:58 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <aYHEzf5nYpA1H5Cj@google.com>
On Tue, Feb 3, 2026 at 3:52 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> The driver requires much more through conversion to handle potential
> races with opening and closing the input device.
>
> Thanks.
>
> --
> Dmitry
Hi Dmitry,
Thank you for your time and comments.
How about we go with an alternative approach, add a bool input_opened
field to struct cyapa, set it in cyapa_open() and clear it in
cyapa_close(), then replace input_device_enabled(input) with
cyapa->input_opened.
I guess this work because
- The input core calls dev->open() exactly when input_device_enabled()
transitions to true (first user open, uninhibit with users), and
dev->close()
exactly when it transitions to false (last user close, inhibit with
users). So the flag mirrors input_device_enabled().
- cyapa_open() and cyapa_close() both hold state_sync_lock when
setting the flag. All callers of cyapa_enable_irq_for_cmd(),
cyapa_disable_irq_for_cmd(), and cyapa_reinitialize() that can
reach the flag also hold state_sync_lock, so the check and the
subsequent action (power mode change, IRQ enable/disable) are atomic,
no TOCTOU window.
Thank you again!
^ permalink raw reply
* [PATCH v7 3/3] Documentation: thinkpad-acpi - Document doubletap_enable attribute
From: Vishnu Sankar @ 2026-02-09 6:33 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260209063355.491189-1-vishnuocv@gmail.com>
Document the doubletap_enable sysfs attribute for ThinkPad ACPI driver.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
---
Changes in v6:
- Fix formatting of doubletap_enable sysfs documentation (separate Values list)
---
.../admin-guide/laptops/thinkpad-acpi.rst | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index 4ab0fef7d440..9a660724648b 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1521,6 +1521,27 @@ Currently 2 antenna types are supported as mentioned below:
The property is read-only. If the platform doesn't have support the sysfs
class is not created.
+doubletap_enable
+----------------
+
+sysfs: doubletap_enable
+
+Controls whether TrackPoint doubletap events are filtered out. Doubletap is a
+feature where quickly tapping the TrackPoint twice triggers a special function key event.
+
+The available commands are::
+
+ cat /sys/devices/platform/thinkpad_acpi/doubletap_enable
+ echo 1 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
+ echo 0 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
+
+Values:
+
+ * 1 - doubletap events are processed (default)
+ * 0 - doubletap events are filtered out (ignored)
+
+ This setting can also be toggled via the Fn+doubletap hotkey.
+
Auxmac
------
--
2.51.0
^ permalink raw reply related
* [PATCH v7 2/3] platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint double-tap
From: Vishnu Sankar @ 2026-02-09 6:33 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260209063355.491189-1-vishnuocv@gmail.com>
Add a sysfs attribute to enable or disable TrackPoint double-tap hotkey
events at the kernel level.
The TrackPoint firmware enables double-tap support automatically. This
interface allows userspace to control whether double-tap events are
forwarded to userspace.
The attribute is available at:
/sys/devices/platform/thinkpad_acpi/doubletap_enable
0 - Disable double-tap hotkey events
1 - Enable double-tap hotkey events (default)
Filtering is implemented by suppressing ACPI hotkey delivery without
injecting synthetic input events.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
---
Changes in v2:
- Updated commit message to clarify dependency on trackpoint driver
- Now handling sysfs read/write of trackpoint driver using file read/write
- Removed sysfs attribute creation of trackpoint double tap here
- Reversed the logic and return false right away
- Dropped unnecessary debug messages
- Using dev_dbg() instead of pr_xxxx()
Changes in v3:
- No changes
Changes in v4:
- Simplified approach: single sysfs attribute for user control
- Clear naming: doubletap_filter instead of doubletap_enabled
- Intuitive behavior: 0=process events, 1=filter events
- No cross-driver dependencies or complex interactions
- Minimal code changes using existing thinkpad_acpi infrastructure
Changes in v5:
- Rename doubletap_filter to doubletap_enable to match actual behavior
- Fix inverted logic so events are emitted only when doubletap is enabled
- Register sysfs attribute via hotkey_attributes[] (no device_create_file)
---
---
drivers/platform/x86/lenovo/thinkpad_acpi.c | 42 +++++++++++++++++----
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index cc19fe520ea9..ca01323c990a 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -373,7 +373,7 @@ static struct {
u32 hotkey_poll_active:1;
u32 has_adaptive_kbd:1;
u32 kbd_lang:1;
- u32 trackpoint_doubletap:1;
+ u32 trackpoint_doubletap_enable:1;
struct quirk_entry *quirks;
} tp_features;
@@ -3018,6 +3018,31 @@ static const struct attribute_group adaptive_kbd_attr_group = {
.attrs = adaptive_kbd_attributes,
};
+/* sysfs doubletap enable --------------------------------------------- */
+static ssize_t doubletap_enable_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%d\n", tp_features.trackpoint_doubletap_enable);
+}
+
+static ssize_t doubletap_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ bool enable;
+ int err;
+
+ err = kstrtobool(buf, &enable);
+ if (err)
+ return err;
+
+ tp_features.trackpoint_doubletap_enable = enable;
+ return count;
+}
+
+static DEVICE_ATTR_RW(doubletap_enable);
+
/* --------------------------------------------------------------------- */
static struct attribute *hotkey_attributes[] = {
@@ -3032,6 +3057,7 @@ static struct attribute *hotkey_attributes[] = {
&dev_attr_hotkey_recommended_mask.attr,
&dev_attr_hotkey_tablet_mode.attr,
&dev_attr_hotkey_radio_sw.attr,
+ &dev_attr_doubletap_enable.attr,
#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
&dev_attr_hotkey_source_mask.attr,
&dev_attr_hotkey_poll_freq.attr,
@@ -3557,8 +3583,8 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
hotkey_poll_setup_safe(true);
- /* Enable doubletap by default */
- tp_features.trackpoint_doubletap = 1;
+ /* Enable TrackPoint doubletap event reporting by default. */
+ tp_features.trackpoint_doubletap_enable = 1;
return 0;
}
@@ -3863,9 +3889,9 @@ static bool hotkey_notify_8xxx(const u32 hkey, bool *send_acpi_ev)
{
switch (hkey) {
case TP_HKEY_EV_TRACK_DOUBLETAP:
- if (tp_features.trackpoint_doubletap)
- tpacpi_input_send_key(hkey, send_acpi_ev);
-
+ /* Only send event if doubletap is enabled */
+ if (!tp_features.trackpoint_doubletap_enable)
+ *send_acpi_ev = false;
return true;
default:
return false;
@@ -11285,7 +11311,9 @@ static bool tpacpi_driver_event(const unsigned int hkey_event)
mutex_unlock(&tpacpi_inputdev_send_mutex);
return true;
case TP_HKEY_EV_DOUBLETAP_TOGGLE:
- tp_features.trackpoint_doubletap = !tp_features.trackpoint_doubletap;
+ /* Toggle kernel-level doubletap event filtering */
+ tp_features.trackpoint_doubletap_enable =
+ !tp_features.trackpoint_doubletap_enable;
return true;
case TP_HKEY_EV_PROFILE_TOGGLE:
case TP_HKEY_EV_PROFILE_TOGGLE2:
--
2.51.0
^ permalink raw reply related
* [PATCH v7 1/3] input: trackpoint - Enable doubletap by default on capable devices
From: Vishnu Sankar @ 2026-02-09 6:33 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260209063355.491189-1-vishnuocv@gmail.com>
Enable doubletap functionality by default on TrackPoint devices that
support it. The feature is detected using firmware ID pattern matching
(PNP: LEN03xxx) with a deny list of incompatible devices.
This provides immediate doubletap functionality without requiring
userspace configuration. The hardware is enabled during device
detection, while event filtering continues to be handled by the
thinkpad_acpi driver as before.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Changes in v7:
- Removed unwanted comments
- Removed psmouse_info ()
Changes in v6:
- No Changes
Changes in v5:
- Renamed function to trackpoint_is_dt_capable()
- Simplified string comparison without sscanf()
- Removed wrapper function as suggested
- Fixed missing period in comment
Changes in v4:
- Simplified approach: removed all sysfs attributes and user interface
- Enable doubletap by default during device detection
- Removed global variables and complex attribute infrastructure
- Uses minimal firmware ID detection with deny list
- Follows KISS principle as suggested by reviewers
Changes in v3:
- No changes
Changes in v2:
- Improve commit messages
- Sysfs attributes moved to trackpoint.c
- Removed unnecessary comments
- Removed unnecessary debug messages
- Using strstarts() instead of strcmp()
- is_trackpoint_dt_capable() modified
- Removed _BIT suffix and used BIT() define
- Reverse the trackpoint_doubletap_status() logic to return error first
- Removed export functions as a result of the design change
- Changed trackpoint_dev->psmouse to parent_psmouse
- The path of trackpoint.h is not changed
---
drivers/input/mouse/trackpoint.c | 45 ++++++++++++++++++++++++++++++++
drivers/input/mouse/trackpoint.h | 5 ++++
2 files changed, 50 insertions(+)
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index 5f6643b69a2c..e12d76350252 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -393,6 +393,45 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
return 0;
}
+/* List of known incapable device PNP IDs */
+static const char * const dt_incompatible_devices[] = {
+ "LEN0304",
+ "LEN0306",
+ "LEN0317",
+ "LEN031A",
+ "LEN031B",
+ "LEN031C",
+ "LEN031D",
+};
+
+/*
+ * Checks if it's a doubletap capable device.
+ * The PNP ID format is "PNP: LEN030d PNP0f13".
+ */
+static bool trackpoint_is_dt_capable(const char *pnp_id)
+{
+ size_t i;
+
+ if (!pnp_id)
+ return false;
+
+ /* Must start with "PNP: LEN03" */
+ if (!strstarts(pnp_id, "PNP: LEN03"))
+ return false;
+
+ /* Ensure enough length before comparing */
+ if (strlen(pnp_id) < 12)
+ return false;
+
+ /* Check deny-list */
+ for (i = 0; i < ARRAY_SIZE(dt_incompatible_devices); i++) {
+ if (!strncmp(pnp_id + 5,
+ dt_incompatible_devices[i], 7))
+ return false;
+ }
+ return true;
+}
+
int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
{
struct ps2dev *ps2dev = &psmouse->ps2dev;
@@ -470,6 +509,12 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
psmouse->vendor, firmware_id,
(button_info & 0xf0) >> 4, button_info & 0x0f);
+ if (trackpoint_is_dt_capable(ps2dev->serio->firmware_id)) {
+ error = trackpoint_write(ps2dev, TP_DOUBLETAP, TP_DOUBLETAP_ENABLE);
+ if (error)
+ psmouse_warn(psmouse, "Failed to enable doubletap: %d\n", error);
+ }
+
return 0;
}
diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
index eb5412904fe0..3e03cdb39449 100644
--- a/drivers/input/mouse/trackpoint.h
+++ b/drivers/input/mouse/trackpoint.h
@@ -69,6 +69,8 @@
/* (how hard it is to drag */
/* with Z-axis pressed) */
+#define TP_DOUBLETAP 0x58 /* TrackPoint doubletap register */
+
#define TP_MINDRAG 0x59 /* Minimum amount of force needed */
/* to trigger dragging */
@@ -110,6 +112,9 @@
external device will be forced to 1 */
#define TP_MASK_EXT_TAG 0x04
+/* Doubletap register values */
+#define TP_DOUBLETAP_ENABLE 0xFF /* Enable value */
+#define TP_DOUBLETAP_DISABLE 0xFE /* Disable value */
/* Power on Self Test Results */
#define TP_POR_SUCCESS 0x3B
--
2.51.0
^ permalink raw reply related
* [PATCH v7 0/3] TrackPoint doubletap enablement and user control
From: Vishnu Sankar @ 2026-02-09 6:33 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
This patch series adds support for TrackPoint doubletap with a clear and
simple separation of responsibilities between drivers:
1. Firmware enablement (trackpoint.c):
Automatically enables doubletap on capable hardware during device
detection.
2. User control (thinkpad_acpi.c):
Provides a sysfs interface to enable or disable delivery of doubletap
events to userspace.
The approach follows the KISS principle:
- The TrackPoint driver enables hardware functionality by default.
- The thinkpad_acpi driver controls whether ACPI doubletap events are
delivered, using existing hotkey filtering infrastructure.
- No cross-driver APIs or dual filtering paths are introduced.
Changes in v7:
- Removed unwanted comments and logs
Changes in v6:
- Documentation: fix formatting of the doubletap_enable sysfs attribute
description (separate "Values" list)
Changes in v5:
- Rename sysfs attribute from doubletap_filter to doubletap_enable to
reflect actual behavior.
- Fix inverted logic so events are delivered only when doubletap is
enabled.
- Suppress ACPI hotkey delivery instead of injecting or filtering input
events.
- Register the sysfs attribute via hotkey_attributes[] instead of
device_create_file().
- Drop unnecessary helper wrappers and debug logging.
- Update Documentation to reflect the new naming and semantics.
Changes in v4:
- Complete redesign based on reviewer feedback.
- trackpoint.c: Simplified to only enable doubletap by default.
- trackpoint.c: Removed all sysfs attributes and global variables.
- trackpoint.c: Uses firmware ID detection with deny list.
- thinkpad_acpi.c: Added sysfs interface for kernel-level event control.
- thinkpad_acpi.c: No cross-driver dependencies.
- Documentation: Updated to reflect simplified sysfs approach.
Changes in v3:
- No changes.
Changes in v2:
- Improved commit messages.
- Removed unnecessary comments and debug messages.
- Switched to strstarts() usage.
- Simplified firmware capability detection logic.
This version addresses the remaining review feedback by correcting the
naming and logic inversion, aligning sysfs semantics with behavior, and
fully integrating with existing thinkpad_acpi hotkey handling.
Vishnu Sankar (3):
input: trackpoint - Enable doubletap by default on capable devices
platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint
double-tap
Documentation: thinkpad-acpi - Document doubletap_enable attribute
.../admin-guide/laptops/thinkpad-acpi.rst | 21 +++++++++
drivers/input/mouse/trackpoint.c | 45 +++++++++++++++++++
drivers/input/mouse/trackpoint.h | 5 +++
drivers/platform/x86/lenovo/thinkpad_acpi.c | 42 ++++++++++++++---
4 files changed, 106 insertions(+), 7 deletions(-)
--
2.51.0
^ permalink raw reply
* 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
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