* Re: [PATCH v5 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-05-11 21:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, dmitry.torokhov, linux-input, conor+dt, devicetree, krzk+dt
In-Reply-To: <20260510110804.33045-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The schema prevents the use of the generic `motorola,cpcap` fallback for the new compatible strings, which will break device probing.
--
commit 43b55cbad252ef116a236dfd195512e35a6f5c82
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> index 7f257f3a1a5a2..542d149d2b39c 100644
> --- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -14,9 +14,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: motorola,cpcap
> - - const: st,6556002
> + oneOf:
> + - enum:
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
Will this prevent the use of motorola,cpcap as a fallback for the new
compatible strings? It looks like this branch of the schema requires devices
to provide only a single compatible string.
Looking at the OMAP4 board code for Mapphone devices, it explicitly matches
against the generic motorola,cpcap string:
arch/arm/mach-omap2/pmic-cpcap.c:cpcap_init() {
...
if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
return -ENODEV;
...
}
By forbidding motorola,cpcap as a fallback in the bindings, will device trees
updated to pass schema validation (by using only the new specific compatibles)
fail to find the node at runtime in the board code?
If the node is not found, does this prevent the initialization of the CPCAP
PMIC voltage regulators on OMAP4 devices, breaking power management and
voltage scaling?
Could the schema permit motorola,cpcap as a fallback for the new compatible
strings, perhaps by using an items list with the new strings as the first
item and motorola,cpcap as the const fallback?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510110804.33045-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 3/4] HID: hid-msi-claw: Add RGB control interface
From: sashiko-bot @ 2026-05-11 21:22 UTC (permalink / raw)
To: Derek J. Clark; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260510043510.442807-4-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] `speed_show()` incorrectly casts the LED class device pointer to a `hid_device`, leading to an out-of-bounds memory read and kernel crash.
- [High] Deadlock and missing return in `cfg_setup_fn` when handling initialization errors.
- [High] Sysfs attributes re-arm the cancelled delayed work after device teardown, leading to a Use-After-Free.
- [High] Racy nullification of `brightness_set` causes a TOCTOU NULL pointer dereference.
- [Medium] Communication failure in `claw_read_rgb_config` leaves the profile parser in a corrupted state.
--
commit 9663adbabcba6be0b443e7073133d650a790c871
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi-claw: Add RGB control interface
Adds RGB control interface for MSI Claw devices with 9 total zones and
supports up to 8 sequential frames of RGB zone data.
> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
> index 60694d075d56f..f4fe74a784c29 100644
> --- a/drivers/hid/hid-msi-claw.c
> +++ b/drivers/hid/hid-msi-claw.c
[ ... ]
> @@ -743,6 +836,389 @@ static const struct attribute_group claw_gamepad_attr_group = {
> .is_visible = claw_gamepad_attr_is_visible,
> };
>
> +/* Read RGB config from device */
> +static int claw_read_rgb_config(struct hid_device *hdev)
> +{
> + u8 data[4] = { 0x01, 0x00, 0x00, CLAW_RGB_FRAME_OFFSET };
> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
> + u16 read_addr = drvdata->rgb_addr;
> + size_t len = ARRAY_SIZE(data);
> + int ret, i;
> +
> + if (!drvdata->rgb_addr)
> + return -ENODEV;
> +
> + /* Loop through all 8 pages of RGB data */
> + for (i = 0; i < 8; i++) {
> + drvdata->profile_pending = CLAW_RGB_PENDING;
> + data[1] = (read_addr >> 8) & 0xff;
> + data[2] = read_addr & 0x00ff;
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
> + if (ret)
> + return ret;
If mcu_property_out() fails here, does drvdata->profile_pending remain set
to CLAW_RGB_PENDING? If a subsequent unrelated profile event or stray ACK
arrives, could claw_profile_event() incorrectly parse its payload as an RGB
frame?
[ ... ]
> +static ssize_t speed_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct hid_device *hdev = to_hid_device(dev);
> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
Since the rgb_attr_group attributes are attached to the LED class device
rather than the HID device, does to_hid_device(dev) result in an invalid
pointer dereference here? Other sysfs functions in this patch seem to
correctly use dev_get_drvdata(dev) to retrieve the led_classdev.
[ ... ]
> @@ -758,6 +1234,13 @@ static void cfg_setup_fn(struct work_struct *work)
> claw_remove(drvdata->hdev);
> }
>
> + ret = claw_read_rgb_config(drvdata->hdev);
> + if (ret) {
> + dev_err(drvdata->led_mc.led_cdev.dev,
> + "Failed to setup device, can't read RGB config: %d\n", ret);
> + claw_remove(drvdata->hdev);
> + }
If claw_remove() is called from within the cfg_setup worker thread, and
claw_remove() calls cancel_delayed_work_sync(&drvdata->cfg_setup), won't
this deadlock waiting for itself to complete?
Also, since there is no return statement after claw_remove() is called in
these error blocks, will this proceed to execute the rest of the function on
a stopped device?
[ ... ]
> @@ -881,6 +1405,9 @@ static void claw_remove(struct hid_device *hdev)
>
> if (drvdata->endpoint == CLAW_XINPUT_CFG_INTF_IN ||
> drvdata->endpoint == CLAW_DINPUT_CFG_INTF_IN) {
> + /* Block writes to brightness/multi_intensity during teardown */
> + drvdata->led_mc.led_cdev.brightness_set = NULL;
Is it safe to dynamically nullify the brightness_set callback here? If a
concurrent brightness update in the LED core checks the pointer, sees it as
valid, and then this nullification happens before the actual function call,
could it result in a NULL pointer dereference?
> + cancel_delayed_work_sync(&drvdata->rgb_queue);
Since the LED class device is registered with devres
(devm_led_classdev_multicolor_register), the sysfs attributes like effect,
speed, and enabled remain accessible until after claw_remove() completes.
If userspace writes to any of those attributes in this window, could
mod_delayed_work() re-arm rgb_queue, leading to a use-after-free when
drvdata is subsequently freed?
> sysfs_remove_group(&hdev->dev.kobj, &claw_gamepad_attr_group);
> cancel_delayed_work_sync(&drvdata->cfg_setup);
> cancel_delayed_work_sync(&drvdata->cfg_resume);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510043510.442807-1-derekjohn.clark@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v5 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-05-11 21:19 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, linux-input, robh, krzk+dt, devicetree, dmitry.torokhov
In-Reply-To: <20260510110804.33045-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The YAML schema enforces a `ports` wrapper node for `audio-codec`, breaking validation for existing device trees.
- [Medium] The power button subnode name `key-power` conflicts with existing device trees, causing validation failures.
- [Medium] The `spi-cs-high` property was dropped from the `required` list during YAML conversion.
- [Low] The schema uses `additionalProperties: false` alongside a `$ref` in `allOf`, which is a dt-schema anti-pattern.
--
commit f0e021d94a5e3dc2af4a93b58f8cc3b052099a76
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..7f257f3a1a5a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,414 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC MFD
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: port connected to the Stereo HiFi DAC
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: port connected to the Voice DAC
Will this cause validation failures for existing device trees?
The new YAML schema defines additionalProperties: false on the
audio-codec node and expects OF graph ports to be nested strictly
inside a ports child node. The original TXT binding example and existing
device trees place port@0 directly under the audio-codec node without
a ports wrapper.
[ ... ]
> + battery:
> + $ref: /schemas/power/supply/cpcap-battery.yaml#
> +
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
Is this node name conflict expected?
The schema strictly defines the power button child node as key-power,
but existing upstream device trees name this node button. Since button
is not explicitly defined in the YAML properties, will it be rejected by
dtbs_check?
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
> + - "#address-cells"
> + - "#size-cells"
Was spi-cs-high intentionally omitted from the required list?
The original TXT binding explicitly listed it under required properties,
and the hardware requires an active-high SPI chip select to function
correctly.
> +
> +additionalProperties: false
Should this be unevaluatedProperties: false instead?
In JSON schema, additionalProperties: false ignores properties inherited
from $ref inclusions inside allOf. This rejects standard SPI properties
unless they are manually duplicated in the local properties block.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510110804.33045-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2] HID: pidff: Fix integer overflow in pidff_rescale
From: sashiko-bot @ 2026-05-11 20:56 UTC (permalink / raw)
To: Tomasz Pakuła; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260510122352.1161826-1-tomasz.pakula.oficjalny@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The subtraction `field->logical_maximum - field->logical_minimum` is evaluated in 32-bit arithmetic, allowing it to overflow before being promoted to `s64`.
- [High] The adjacent function `pidff_rescale_signed()` suffers from the exact same integer overflow vulnerability but was completely missed by the patch.
- [High] This problem wasn't introduced by this patch, but missing bounds check on `unit_exponent` in `pidff_rescale_time()` allows a kernel stall via a malicious HID descriptor.
--
commit d365813aa395ac1ce1eeffd147aa3beb65aba60b
Author: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
HID: pidff: Fix integer overflow in pidff_rescale
This commit attempts to fix an integer overflow in pidff_rescale by using a
64-bit signed integer for calculations. It addresses an issue where rescaling
values close to the maximum could temporarily exceed the 32-bit signed
integer range.
Closes: https://github.com/JacKeTUs/universal-pidff/issues/116
> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
> index aee8a44433059..c45f182d04480 100644
> --- a/drivers/hid/usbhid/hid-pidff.c
> +++ b/drivers/hid/usbhid/hid-pidff.c
[ ... ]
> @@ -326,8 +327,10 @@ static s32 pidff_clamp(s32 i, struct hid_field *field)
> */
> static int pidff_rescale(int i, int max, struct hid_field *field)
> {
> - return i * (field->logical_maximum - field->logical_minimum) / max +
> - field->logical_minimum;
> + /* 64 bits needed for big values during rescale */
> + s64 result = field->logical_maximum - field->logical_minimum;
Since both logical_maximum and logical_minimum are 32-bit signed integers,
does the subtraction field->logical_maximum - field->logical_minimum evaluate
in 32-bit arithmetic and potentially overflow before being promoted to s64?
If an untrusted USB device provides a descriptor with extreme limits,
this difference could exceed the capacity of a 32-bit signed integer and wrap
around to a negative value. Should at least one operand be explicitly cast
to s64 before the subtraction?
> +
> + return div_s64(result * i, max) + field->logical_minimum;
> }
>
> /*
This isn't a regression introduced by this patch, but looking at the
adjacent pidff_rescale_signed() function:
drivers/hid/usbhid/hid-pidff.c:pidff_rescale_signed() {
...
if (i > 0)
return i * field->logical_maximum / S16_MAX;
...
}
Does the multiplication i * field->logical_maximum suffer from a similar
overflow?
Since both operands fit into an int, they evaluate in 32-bit signed
arithmetic. If a device advertises a logical_maximum greater than 65535,
could this multiplication silently overflow yielding a wrapped-around
negative value before the division takes place?
Also not introduced by this patch, but looking at pidff_rescale_time():
drivers/hid/usbhid/hid-pidff.c:pidff_rescale_time() {
...
int exponent = field->unit_exponent;
pr_debug("time field exponent: %d\n", exponent);
for (; exponent < FF_TIME_EXPONENT; exponent++)
scaled_time *= 10;
for (; exponent > FF_TIME_EXPONENT; exponent--)
scaled_time /= 10;
...
}
Are there any bounds checks on field->unit_exponent before it is used
in these loops?
The field->unit_exponent is parsed from untrusted USB device descriptors.
If a USB device provides a large 32-bit exponent value, could
this execute up to 2.14 billion iterations doing multiplications or
divisions without any early break checks?
Could this trigger a kernel stall or soft lockup when a user uploads a
force-feedback effect?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510122352.1161826-1-tomasz.pakula.oficjalny@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/4] HID: hid-msi-claw: Add M-key mapping attributes
From: sashiko-bot @ 2026-05-11 20:51 UTC (permalink / raw)
To: Derek J. Clark; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260510043510.442807-3-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Data race on `drvdata->profile_pending` and lack of transaction atomicity during concurrent sysfs accesses.
--
commit b9bc6d29326e3dd3ed065aca7059668a1b674bc8
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi-claw: Add M-key mapping attributes
Adds sysfs attributes to remap the M1 and M2 rear buttons to up to 5 events
(gamepad, keyboard, or mouse) when in macro mode.
> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
> index 7a3cd940ec49e..60694d075d56f 100644
> --- a/drivers/hid/hid-msi-claw.c
> +++ b/drivers/hid/hid-msi-claw.c
[ ... ]
> +static int claw_buttons_store(struct device *dev, const char *buf, u8 mkey_idx)
> +{
[ ... ]
> +set_buttons:
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_WRITE_PROFILE_DATA, data, len, 8);
> + if (ret < 0)
> + goto err_free;
> +
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_SYNC_TO_ROM, NULL, 0, 0);
Is it possible for concurrent writers to interleave these commands?
Looking at mcu_property_out(), it takes the cfg_mutex internally, but there
is no lock held across both calls here. If a second writer executes its
WRITE_PROFILE_DATA before the first writer executes SYNC_TO_ROM, could the MCU
be left in an inconsistent state?
[ ... ]
> +static int claw_buttons_show(struct device *dev, char *buf, enum claw_key_index m_key)
> +{
[ ... ]
> + codes = (m_key == CLAW_KEY_M1) ? drvdata->m1_codes : drvdata->m2_codes;
> + drvdata->profile_pending = (m_key == CLAW_KEY_M1) ? CLAW_M1_PENDING : CLAW_M2_PENDING;
> +
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
Can concurrent reads of button_m1 and button_m2 race and corrupt the
profile_pending state?
If Thread A and Thread B access the sysfs attributes simultaneously,
profile_pending is updated locklessly here before mcu_property_out() takes
the cfg_mutex.
Could Thread B overwrite profile_pending to CLAW_M2_PENDING before Thread A's
command executes? If so, when the hardware replies to Thread A's M1 command,
claw_profile_event() might route Thread A's data into Thread B's m2_codes
buffer and clear the state to CLAW_NO_PENDING.
This would cause Thread B's subsequent reply to be dropped and trigger the
"Got profile event without changes pending" warning.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510043510.442807-1-derekjohn.clark@gmail.com?part=2
^ permalink raw reply
* [PATCH] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: Christian Fressl @ 2026-05-11 20:31 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Christian Fressl
Apple Magic Trackpad 2 devices support persistent haptic feedback
configuration through feature reports 0x22 and 0x23. Add an opt-in
module parameter to select either the verified silent-low profile or to
disable haptic feedback.
The default remains unchanged. The report payload format is
reverse-engineered, so keep the existing payload bytes fixed and vary
only the known 24-bit feedback value.
The USB-C Trackpad exposes multiple HID interfaces. Use the one-shot
actuator output report 0x53 only to identify the interface that accepts
the persistent configuration reports; do not use it for the persistent
setting itself.
Tested on Apple Magic Trackpad USB-C 05ac:0324 with Ubuntu
6.17.0-23-generic. Compile-tested against HID for-next.
Protocol information was derived from public reverse-engineering notes,
then independently tested with local hardware.
Link: https://github.com/mwyborski/Linux-Magic-Trackpad-2-Driver/issues/28#issuecomment-451625504
Signed-off-by: Christian Fressl <christian@fressl.at>
---
drivers/hid/hid-magicmouse.c | 101 ++++++++++++++++++++++++++++++++++-
1 file changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index e70bd3dc07ab..31002cb1f108 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -51,6 +51,10 @@ static bool report_undeciphered;
module_param(report_undeciphered, bool, 0644);
MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state field using a MSC_RAW event");
+static unsigned int haptic_click;
+module_param(haptic_click, uint, 0644);
+MODULE_PARM_DESC(haptic_click, "Haptic click feedback: 0=unchanged, 1=silent-low, 2=off");
+
#define TRACKPAD2_2021_BT_VERSION 0x110
#define TRACKPAD_2024_BT_VERSION 0x314
@@ -62,6 +66,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state fie
#define DOUBLE_REPORT_ID 0xf7
#define USB_BATTERY_TIMEOUT_SEC 60
+#define TRACKPAD2_HAPTIC_CLICK_REPORT_ID 0x22
+#define TRACKPAD2_HAPTIC_RELEASE_REPORT_ID 0x23
+#define TRACKPAD2_HAPTIC_ACTUATOR_REPORT_ID 0x53
+#define TRACKPAD2_HAPTIC_REPORT_LEN 14
+#define TRACKPAD2_HAPTIC_CLICK_UNCHANGED 0
+#define TRACKPAD2_HAPTIC_CLICK_SILENT_LOW 1
+#define TRACKPAD2_HAPTIC_CLICK_OFF 2
+#define TRACKPAD2_HAPTIC_SILENT_CLICK 0x000015
+#define TRACKPAD2_HAPTIC_SILENT_RELEASE 0x000010
+#define TRACKPAD2_HAPTIC_OFF 0x000000
+
/* These definitions are not precise, but they're close enough. (Bits
* 0x03 seem to indicate the aspect ratio of the touch, bits 0x70 seem
* to be some kind of bit mask -- 0x20 may be a near-field reading,
@@ -812,6 +827,81 @@ static bool is_usb_magictrackpad2(__u32 vendor, __u32 product)
product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2_USBC;
}
+static bool magicmouse_is_haptic_interface(struct hid_device *hdev)
+{
+ struct hid_report_enum *report_enum;
+
+ report_enum = &hdev->report_enum[HID_OUTPUT_REPORT];
+
+ /*
+ * The persistent haptic configuration reports are accepted as feature
+ * reports, but are not advertised in the feature report descriptor.
+ * Report 0x53 is the one-shot actuator output report and identifies
+ * the HID interface that accepts the persistent reports.
+ */
+ return report_enum->report_id_hash[TRACKPAD2_HAPTIC_ACTUATOR_REPORT_ID];
+}
+
+static int magicmouse_send_haptic_report(struct hid_device *hdev, u8 report_id,
+ u32 feedback)
+{
+ static const u8 report_template[TRACKPAD2_HAPTIC_REPORT_LEN] = {
+ 0x00, 0x01, 0x00, 0x78, 0x02, 0x00, 0x24,
+ 0x30, 0x06, 0x01, 0x00, 0x18, 0x48, 0x13,
+ };
+ u8 *buf;
+ int ret;
+
+ buf = kmemdup(report_template, sizeof(report_template), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = report_id;
+ buf[2] = feedback & 0xff;
+ buf[5] = (feedback >> 8) & 0xff;
+ buf[10] = (feedback >> 16) & 0xff;
+
+ ret = hid_hw_raw_request(hdev, buf[0], buf, TRACKPAD2_HAPTIC_REPORT_LEN,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ kfree(buf);
+
+ return ret;
+}
+
+static int magicmouse_apply_haptic_click(struct hid_device *hdev)
+{
+ u32 click_feedback;
+ u32 release_feedback;
+ int ret;
+
+ if (haptic_click == TRACKPAD2_HAPTIC_CLICK_UNCHANGED)
+ return 0;
+
+ switch (haptic_click) {
+ case TRACKPAD2_HAPTIC_CLICK_SILENT_LOW:
+ click_feedback = TRACKPAD2_HAPTIC_SILENT_CLICK;
+ release_feedback = TRACKPAD2_HAPTIC_SILENT_RELEASE;
+ break;
+ case TRACKPAD2_HAPTIC_CLICK_OFF:
+ click_feedback = TRACKPAD2_HAPTIC_OFF;
+ release_feedback = TRACKPAD2_HAPTIC_OFF;
+ break;
+ default:
+ hid_warn(hdev, "invalid haptic_click value %u\n", haptic_click);
+ return -EINVAL;
+ }
+
+ ret = magicmouse_send_haptic_report(hdev,
+ TRACKPAD2_HAPTIC_CLICK_REPORT_ID,
+ click_feedback);
+ if (ret < 0)
+ return ret;
+
+ return magicmouse_send_haptic_report(hdev,
+ TRACKPAD2_HAPTIC_RELEASE_REPORT_ID,
+ release_feedback);
+}
+
static int magicmouse_fetch_battery(struct hid_device *hdev)
{
#ifdef CONFIG_HID_BATTERY_STRENGTH
@@ -894,8 +984,17 @@ static int magicmouse_probe(struct hid_device *hdev,
if (is_usb_magicmouse2(id->vendor, id->product) ||
(is_usb_magictrackpad2(id->vendor, id->product) &&
- hdev->type != HID_TYPE_USBMOUSE))
+ hdev->type != HID_TYPE_USBMOUSE)) {
+ if (is_usb_magictrackpad2(id->vendor, id->product) &&
+ magicmouse_is_haptic_interface(hdev)) {
+ ret = magicmouse_apply_haptic_click(hdev);
+ if (ret < 0)
+ hid_warn(hdev,
+ "unable to apply haptic click setting (%d)\n",
+ ret);
+ }
return 0;
+ }
if (!msc->input) {
hid_err(hdev, "magicmouse input not registered\n");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input: ads7846 - consolidate coordinate filtering logic
From: Kris Bahnsen @ 2026-05-11 20:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Aaro Koskinen, Mark Featherston, Marek Vasut,
linux-kernel
In-Reply-To: <afzo03UP-shPfNMe@google.com>
Dmitry,
On 5/7/26 12:35 PM, Dmitry Torokhov wrote:
> Hi Kris,
>
> On Thu, May 07, 2026 at 10:48:57AM -0700, Kris Bahnsen wrote:
>> On 5/4/26 9:54 PM, Dmitry Torokhov wrote:
>>> The ads7846 driver has two separate filtering functions,
>>> ads7846_filter() and ads7846_filter_one(), for the full-duplex and
>>> half-duplex SPI paths, respectively.
>>>
>>> They can be consolidated by extracting the core filtering logic for a
>>> single command into a helper function, ads7846_filter_cmd(), which
>>> iterates from l->skip to l->count. The half-duplex setup function is
>>> updated to set l->skip = l->count - 1 so that the helper only processes
>>> the last sample, preserving the original half-duplex behavior.
>>>
>>> Assisted-by: Gemini:gemini-3.1-pro
>>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>> ---
>>>
>>> Not tested so will appreciate if someone could give it a spin.
>>
>> Forgive my ignorance, but I am unsure of the base commit this applies
>> to and I'm unable to apply it to current HEAD of linux, linux-next,
>> or your input tree.
>>
>> I also am not easily able to test this if it doesn't cleanly apply
>> to the latest LTS, but will do what I can once I know what other
>> patches I would need to pull in to our tree.
>
> I think if you pull 'next' branch of my tree, then the following patches
> seem to apply cleanly on 7.0:
>
> c68bc840f06c ("Input: ads7846 - restore half-duplex support")
> 011bdf9f3a9d ("Input: ads7846 - consolidate coordinate filtering logic")
Please confirm that the referenced commits are pushed and that I
am using the correct remote URLs. I am unable to find the referenced
commits still:
$ git remote -v
input git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git (fetch)
input git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git (push)
next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)
[...]
$ git fetch next
$ git fetch input
$ git show c68bc840f06c
fatal: ambiguous argument 'c68bc840f06c': unknown revision or path not in the working tree.
$ git show 011bdf9f3a9d
fatal: ambiguous argument '011bdf9f3a9d': unknown revision or path not in the working tree.
Apologies in advance if I am missing something obvious.
> I hope they also build ;)
>
> c68bc840f06c should appear in linux-next soon too.
>
> Thanks.
>
--
Kris Bahnsen
Software Engineer
embeddedTS
^ permalink raw reply
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Linus Walleij @ 2026-05-11 20:12 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Val Packett, Julien Massot, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 11:37 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This patch 4/9 applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
From: Mark Pearson @ 2026-05-11 17:52 UTC (permalink / raw)
To: Kean, Derek J . Clark
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260511132854.1351379-1-rh_king@163.com>
On Mon, May 11, 2026, at 9:28 AM, Kean wrote:
> In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
> little-endian value via *(__le32 *)data but only guards the access
> with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
> the code reads one byte beyond the end of the buffer.
>
> Change the size check to >= 4 to match the actual access width.
>
> Signed-off-by: Kean <rh_king@163.com>
> ---
> drivers/hid/hid-lenovo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
> index a6b73e03c16b..4686ecb6cfa8 100644
> --- a/drivers/hid/hid-lenovo.c
> +++ b/drivers/hid/hid-lenovo.c
> @@ -793,7 +793,7 @@ static int lenovo_raw_event(struct hid_device *hdev,
> */
> if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
> || hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
> - && size >= 3 && report->id == 0x03))
> + && size >= 4 && report->id == 0x03))
> return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));
>
> return 0;
> --
> 2.53.0
Looks good to me. Thanks!
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Mark
^ permalink raw reply
* Re: [PATCH v3 7/9] iio: humidity: hid-sensor-humidity: use common device for devres
From: Jonathan Cameron @ 2026-05-11 16:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, jikos, srinivas.pandruvada, dlechner, nuno.sa,
andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <agAo6fXUaoTwl326@ashevche-desk.local>
On Sun, 10 May 2026 09:42:49 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sat, May 09, 2026 at 03:40:38PM +0530, Sanjay Chitroda wrote:
>
> > kmemdup() is used for memory that is logically tied to the HID
> > platform device, even though the driver binds into the IIO framework.
> >
> > Using &indio_dev->dev for devres allocations works functionally, but it
> > results in two separate devres ownership trees—one for the HID
> > platform device (pdev) and another for the IIO device (indio_dev).
> >
> > The devres framework is intended to have a single, well-defined parent
> > device. Since the memory originates from HID sensor probing and is not
> > IIO-specific, &pdev->dev is the correct and logical owner.
> >
> > Switch to using the platform device for devm_kmemdup() so that all
> > resources are released deterministically and consistently.
>
> This patch sounds like a required fix and has to be placed in the beginning of
> the series along with the Fixes tag.
Hmm. I always find these hard to prove...
Ultimately for a device for which no driver is ever bound I believe
the call to devres_release_all() in device_release() catches these.
That should I think happen when the last reference to the iio_dev->dev
is dropped (for the device we care about in the 'buggy' code).
Now that may well be at a different time to when it would happen on
the underlying bus device unbind. However here we are talking about
an allocation so as long as we release it at somepoint and that's late
enough (which it will be either way) then it's not a bug - it just makes
the code harder to reason about.
Jonathan
p.s. I remember testing the releases on some other drivers years ago
to figure out if they had an actual bug based on the pattern we have
here. It 'works' but yuk.
^ permalink raw reply
* Re: [PATCH v3 3/9] iio: hid-sensors: introduce device managed API
From: Jonathan Cameron @ 2026-05-11 16:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, jikos, srinivas.pandruvada, dlechner, nuno.sa,
andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <agAngXqFb5L2--AN@ashevche-desk.local>
On Sun, 10 May 2026 09:36:49 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sat, May 09, 2026 at 03:40:34PM +0530, Sanjay Chitroda wrote:
>
> > hid_sensor_setup_trigger() is common API used for the HID IIO drivers,
> > prepare devm API devm_hid_sensor_setup_trigger() to acquire resource
> > during setup and release using device managed framework during drivers
> > fail, unbind or remove path.
> >
> > Register action with devm_add_action_or_reset() to release resource with
> > devres framework.
>
> ...
>
> > +int devm_hid_sensor_setup_trigger(struct device *dev, struct iio_dev *indio_dev,
> > + const char *name, struct hid_sensor_common *attrb)
>
> At this point don't we have indio_dev->dev.parent == dev?
yes probably but I'd rather we didn't use that. For devm calls it's nicer to have the
owner device explicit.
>
> > +{
> > + int ret;
> > +
> > + ret = hid_sensor_setup_trigger(indio_dev, name, attrb);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_add_action_or_reset(dev, hid_sensor_remove_trigger_action, attrb);
> > +}
>
^ permalink raw reply
* Re: [PATCH v3 0/4] ROCK 4D audio enablement
From: Nicolas Frattaroli @ 2026-05-11 16:21 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Krzysztof Kozlowski, Cristian Ciocaltea
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
Hi Alexandre, and other maintainers,
On Wednesday, 8 April 2026 19:49:38 Central European Summer Time Nicolas Frattaroli wrote:
> The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
> no mic) and a headset (i.e., with mic). After some searching, it appears
> that the closest we can get to modelling this is by sending a particular
> switch input event.
>
> So this series modifies the adc-keys bindings, extends the adc-keys
> driver to allow sending other input types as well, and then adds the
> analog audio nodes to ROCK 4D's device tree.
>
> It should be noted that analog capture from the TRRS jack currently
> results in completely digitally silent audio for me, i.e. no data other
> than 0xFF. There's a few reasons why this could happen, chief among them
> that my SAI driver is broken or that the ES8328 codec driver is once
> again broken. The DAPM routes when graphed out look fine though. So the
> DTS part is correct, and I can fix the broken capture in a separate
> follow-up patch that doesn't have to include DT people.
>
> Another possibility is that my phone headset, despite being 4 rings and
> having a little pin hole at the back of the volume doodad, does not
> actually have a microphone, but in that case I'd still expect some noise
> in the PCM. Maybe it's just shy.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> Changes in v3:
> - bindings: use unevaluatedProperties instead of explicitly mentioning
> linux,input-type.
> - Link to v2: https://lore.kernel.org/r/20251215-rock4d-audio-v2-0-82a61de39b4c@collabora.com
>
> Changes in v2:
> - Drop HDMI audio patch, as it was already merged.
> - adc-keys: rename "keycode" to "code".
> - adc-keys: make the keycode (now "code") local a u32 instead of an int
> - adc-keys: only allow EV_KEY and EV_SW for now. Rename patch
> accordingly.
> - adc-keys: Add another patch to rework probe function error logging.
> - Link to v1: https://lore.kernel.org/r/20250630-rock4d-audio-v1-0-0b3c8e8fda9c@collabora.com
>
> ---
> Nicolas Frattaroli (4):
> dt-bindings: input: adc-keys: allow all input properties
> Input: adc-keys - support EV_SW as well, not just EV_KEY.
> Input: adc-keys - Use dev_err_probe in probe function
> arm64: dts: rockchip: add analog audio to ROCK 4D
>
> .../devicetree/bindings/input/adc-keys.yaml | 17 ++--
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 ++++++++++++++++++++++
> drivers/input/keyboard/adc-keys.c | 88 ++++++++++-----------
> 3 files changed, 147 insertions(+), 48 deletions(-)
> ---
> base-commit: 8de395f35e79d9168a78504fed495578ec7bac52
> change-id: 20250627-rock4d-audio-cfc07f168a08
>
> Best regards,
> --
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
>
What's the path forward here? All the patches are reviewed, but it
has been almost a month without them being applied now.
Which tree(s) would this be applied to, and who should I poke?
Thanks :)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* [PATCH v1 5/8] hid: Pen battery quirk for Surface Pro 12in
From: Harrison Vanderbyl @ 2026-05-11 14:40 UTC (permalink / raw)
To: linux-arm-msm, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <cover.1778498477.git.harrison.vanderbyl@gmail.com>
The pen setup for this device uses bluetooth for
communicating battery levels and status instead of
reporting it over i2c.
Without this quirk, the device either reports an
extra, broken phantom battery, or hangs.
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0cf63742315b..d16f55479786 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -459,6 +459,7 @@
#define USB_DEVICE_ID_HP_X2 0x074d
#define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
#define I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM 0x2F81
+#define I2C_DEVICE_ID_SURFACE_PRO_12IN 0x4376
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d73cfa2e73d3..61ecd840d0bd 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -395,6 +395,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_AVOID_QUERY },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM),
HID_BATTERY_QUIRK_AVOID_QUERY },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_PRO_12IN),
+ HID_BATTERY_QUIRK_IGNORE },
/*
* Elan HID touchscreens seem to all report a non present battery,
* set HID_BATTERY_QUIRK_IGNORE for all Elan I2C and USB HID devices.
--
2.53.0
^ permalink raw reply related
* [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
From: Kean @ 2026-05-11 13:28 UTC (permalink / raw)
To: derekjohn.clark, mpearson-lenovo
Cc: jikos, bentiss, linux-input, linux-kernel, Kean
In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
little-endian value via *(__le32 *)data but only guards the access
with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
the code reads one byte beyond the end of the buffer.
Change the size check to >= 4 to match the actual access width.
Signed-off-by: Kean <rh_king@163.com>
---
drivers/hid/hid-lenovo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..4686ecb6cfa8 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -793,7 +793,7 @@ static int lenovo_raw_event(struct hid_device *hdev,
*/
if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
|| hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
- && size >= 3 && report->id == 0x03))
+ && size >= 4 && report->id == 0x03))
return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC 4/4] arm64: dts: qcom: milos-fairphone-fp6: add supply for Hall Effect sensor
From: Konrad Dybcio @ 2026-05-11 11:46 UTC (permalink / raw)
To: Griffin Kroah-Hartman, Dmitry Torokhov, Liam Girdwood, Mark Brown,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luca Weiss
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20260508-gpiokeys-vdd-supply-v1-4-0bb32e8e6428@fairphone.com>
On 5/8/26 2:53 PM, Griffin Kroah-Hartman wrote:
> Add vdd-supply for the Hall Effect sensor in gpio-keys so that power for
> the sensor will be enabled when it's in use.
>
> With this, we can drop the regulator-always-on for vreg_l10b.
>
> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
> ---
Modulo whatever the supply name ends up being:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Thanks for shaving this yak!
Konrad
^ permalink raw reply
* Re: (subset) [PATCH 0/9] MT6365 PMIC support cleanup
From: AngeloGioacchino Del Regno @ 2026-05-11 9:36 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Louis-Alexis Eyraud
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:13 +0200, Louis-Alexis Eyraud wrote:
> Several Mediatek and Radxa boards, based on MT8370, MT8390 or MT8395
> SoC, integrate the MT6365 PMIC, that is a MT6359P variant:
> - Mediatek Genio 1200-EVK
> - Mediatek Genio 700-EVK
> - Mediatek Genio 510-EVK
> - Radxa NIO-12L
> It is compatible with the MT6359 PMIC.
>
> [...]
Applied to v7.1-next/dts64, thanks!
[6/9] arm64: dts: mediatek: add MT6365 PMIC include
commit: dd85b476c5bb164e5978e42867e1f4deb23b23fd
[7/9] arm64: dts: mediatek: mt8390-genio-common: use MT6365 PMIC definitions
commit: 38c2adaccd3618882e3c5b8ec76ef77a1ecb8de9
[8/9] arm64: dts: mediatek: mt8395-genio-common: use MT6365 PMIC definitions
commit: c264c7958a36ceedebedf8a437fa719906e4e1af
[9/9] arm64: dts: mediatek: mt8395-radxa-nio-12l: use MT6365 PMIC definitions
commit: 4d2b8fcd8bbd7f00335a52b86189d85686fdc707
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-3-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> Add compatible string for the pmic keys block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> MT6365 PMIC is compatible with MT6359, so add the compatible strings
> for the main and sub devices (regulator, rtc, audio codec).
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-4-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> Add compatible string for the AuxADC block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* [PATCH] Input: tsc2007 - fix resistance calculation when A/D value is saturated
From: Yuki Horii @ 2026-05-11 5:40 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: andreas, clamor95, linux-input, yuuki198708, Yuki Horii
The A/D conversion sequence starts with reading the Y position
immediately after the A/D converter is powered on. This makes
the Y position measurement more susceptible to instability due
to noise and mechanical bounce compared to the X position, and
may result in a saturated value (MAX_12BIT = 0xFFF).
While the Y position is not used in equation #1 of the datasheet
for touch resistance calculation, it is required for equation #2.
A saturated Y A/D value, like a saturated X A/D value, indicates
that the touch resistance calculation is invalid.
Only the saturation of the X A/D value was checked, while the
saturation of the Y A/D value was not. Additionally, modifying
tc->x directly had an unintended side effect of corrupting the
caller's data.
The function now returns 0 when either X or Y A/D value is
saturated to indicate that the touch resistance calculation
is invalid.
Signed-off-by: Yuki Horii <horiiyuk@ishida.co.jp>
---
drivers/input/touchscreen/tsc2007_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c
index 524f14eb3da2..ce82163da4ff 100644
--- a/drivers/input/touchscreen/tsc2007_core.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -71,9 +71,9 @@ u32 tsc2007_calculate_resistance(struct tsc2007 *tsc, struct ts_event *tc)
{
u64 rt = 0;
- /* range filtering */
- if (tc->x == MAX_12BIT)
- tc->x = 0;
+ /* invalidate touch resistance if X or Y coordinate is saturated */
+ if (tc->x == MAX_12BIT || tc->y == MAX_12BIT)
+ return 0;
if (likely(tc->x && tc->z1)) {
/* compute touch resistance using equation #1 */
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v5 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: Rob Herring (Arm) @ 2026-05-10 12:44 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, linux-kernel, devicetree, linux-leds, Tony Lindgren,
Lee Jones, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Pavel Machek, Dmitry Torokhov
In-Reply-To: <20260510110804.33045-3-clamor95@gmail.com>
On Sun, 10 May 2026 14:08:00 +0300, 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.
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> .../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/20260510110804.33045-3-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 v5 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Rob Herring (Arm) @ 2026-05-10 12:44 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, Conor Dooley, Krzysztof Kozlowski, Pavel Machek,
Lee Jones, Tony Lindgren, Dmitry Torokhov, David Lechner,
linux-kernel, linux-leds, linux-input
In-Reply-To: <20260510110804.33045-2-clamor95@gmail.com>
On Sun, 10 May 2026 14:07:59 +0300, 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/20260510110804.33045-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
* [PATCH v2] HID: pidff: Fix integer overflow in pidff_rescale
From: Tomasz Pakuła @ 2026-05-10 12:23 UTC (permalink / raw)
To: jikos, bentiss; +Cc: oleg, linux-input, linux-kernel, tomasz.pakula.oficjalny
Rescaling values close to the max (U16_MAX) temporarily creates values
that exceed the s32 range. This caused value overflow in case when, for
example, a periodic effect phase was higer than 180 degrees. In turn,
rescale function could return values outised of the logical range of the
HID field.
Fix by using 64 bit signed integer to store the value during calculation
but still return only 32 bit integer.
Closes: https://github.com/JacKeTUs/universal-pidff/issues/116
Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
Cc: <stable@vger.kernel.org>
Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
---
For inclusion in 7.1 RC period.
v2: use div_s64() instead of plain division
drivers/hid/usbhid/hid-pidff.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index aee8a4443305..c45f182d0448 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -11,6 +11,7 @@
#include "hid-pidff.h"
#include <linux/hid.h>
#include <linux/input.h>
+#include <linux/math64.h>
#include <linux/minmax.h>
#include <linux/slab.h>
#include <linux/stringify.h>
@@ -326,8 +327,10 @@ static s32 pidff_clamp(s32 i, struct hid_field *field)
*/
static int pidff_rescale(int i, int max, struct hid_field *field)
{
- return i * (field->logical_maximum - field->logical_minimum) / max +
- field->logical_minimum;
+ /* 64 bits needed for big values during rescale */
+ s64 result = field->logical_maximum - field->logical_minimum;
+
+ return div_s64(result * i, max) + field->logical_minimum;
}
/*
--
2.54.0
^ permalink raw reply related
* [PATCH v5 6/6] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: Svyatoslav Ryhel @ 2026-05-10 11:08 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260510110804.33045-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 | 30 ++++++++++++++++++++++++++++++
include/linux/mfd/motorola-cpcap.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index f5a7fdd89dd5..bd9fb0d61ba6 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -270,6 +270,28 @@ static const struct mfd_cell cpcap_mapphone_mfd_devices[] = {
MFD_CELL_NAME("cpcap-codec"),
};
+/*
+ * 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[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,mot-cpcap-adc"),
+ MFD_CELL_OF("cpcap_battery", NULL, NULL, 0, 0,
+ "motorola,cpcap-battery"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0,
+ "motorola,mot-cpcap-regulator"),
+ MFD_CELL_OF("cpcap-rtc", NULL, NULL, 0, 0, "motorola,cpcap-rtc"),
+ MFD_CELL_OF("cpcap-pwrbutton", NULL, NULL, 0, 0,
+ "motorola,cpcap-pwrbutton"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 0, "motorola,cpcap-led-red"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 1, "motorola,cpcap-led-green"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 2, "motorola,cpcap-led-blue"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 3, "motorola,cpcap-led-adl"),
+ MFD_CELL_NAME("cpcap-codec"),
+};
+
static int cpcap_probe(struct spi_device *spi)
{
struct cpcap_ddata *cpcap;
@@ -294,6 +316,10 @@ static int cpcap_probe(struct spi_device *spi)
cells = cpcap_mapphone_mfd_devices;
num_cells = ARRAY_SIZE(cpcap_mapphone_mfd_devices);
break;
+ case CPCAP_MOT:
+ cells = cpcap_mot_mfd_devices;
+ num_cells = ARRAY_SIZE(cpcap_mot_mfd_devices);
+ break;
default:
return dev_err_probe(&spi->dev, -EINVAL,
"Unknown device %d\n", cpcap->variant);
@@ -343,6 +369,9 @@ static const struct of_device_id cpcap_of_match[] = {
}, {
.compatible = "motorola,mapphone-cpcap",
.data = (void *)CPCAP_MAPPHONE
+ }, {
+ .compatible = "motorola,mot-cpcap",
+ .data = (void *)CPCAP_MOT
},
{ /* sentinel */ }
};
@@ -351,6 +380,7 @@ MODULE_DEVICE_TABLE(of, cpcap_of_match);
static const struct spi_device_id cpcap_spi_ids[] = {
{ "cpcap", CPCAP_DEFAULT },
{ "mapphone-cpcap", CPCAP_MAPPHONE },
+ { "mot-cpcap", CPCAP_MOT },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
index 1a85b06272c8..bb23363eeccd 100644
--- a/include/linux/mfd/motorola-cpcap.h
+++ b/include/linux/mfd/motorola-cpcap.h
@@ -28,6 +28,7 @@
enum cpcap_variant {
CPCAP_DEFAULT = 1,
CPCAP_MAPPHONE,
+ CPCAP_MOT,
CPCAP_MAX
};
--
2.51.0
^ permalink raw reply related
* [PATCH v5 5/6] mfd: motorola-cpcap: diverge configuration per-board
From: Svyatoslav Ryhel @ 2026-05-10 11:08 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Svyatoslav Ryhel, David Lechner,
Tony Lindgren
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260510110804.33045-1-clamor95@gmail.com>
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.
Removed st,6556002 as it is no longer applicable to all cases and
duplicates motorola,cpcap, which is used as the default composition.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/motorola-cpcap.c | 142 ++++++++++++++++-------------
include/linux/mfd/motorola-cpcap.h | 6 ++
2 files changed, 87 insertions(+), 61 deletions(-)
diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index d8243b956f87..f5a7fdd89dd5 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/sysfs.h>
@@ -30,6 +31,7 @@ struct cpcap_ddata {
struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
const struct regmap_config *regmap_conf;
struct regmap *regmap;
+ enum cpcap_variant variant;
};
static int cpcap_sense_irq(struct regmap *regmap, int irq)
@@ -195,20 +197,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
return 0;
}
-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", },
- {},
-};
-MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
-
static const struct regmap_config cpcap_regmap_config = {
.reg_bits = 16,
.reg_stride = 4,
@@ -241,62 +229,76 @@ static int cpcap_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
-static const struct mfd_cell cpcap_mfd_devices[] = {
- {
- .name = "cpcap_adc",
- .of_compatible = "motorola,mapphone-cpcap-adc",
- }, {
- .name = "cpcap_battery",
- .of_compatible = "motorola,cpcap-battery",
- }, {
- .name = "cpcap-charger",
- .of_compatible = "motorola,mapphone-cpcap-charger",
- }, {
- .name = "cpcap-regulator",
- .of_compatible = "motorola,mapphone-cpcap-regulator",
- }, {
- .name = "cpcap-rtc",
- .of_compatible = "motorola,cpcap-rtc",
- }, {
- .name = "cpcap-pwrbutton",
- .of_compatible = "motorola,cpcap-pwrbutton",
- }, {
- .name = "cpcap-usb-phy",
- .of_compatible = "motorola,mapphone-cpcap-usb-phy",
- }, {
- .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-led",
- .id = 4,
- .of_compatible = "motorola,cpcap-led-cp",
- }, {
- .name = "cpcap-codec",
- }
+static const struct mfd_cell cpcap_default_mfd_devices[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
+ MFD_CELL_OF("cpcap_battery", NULL, NULL, 0, 0,
+ "motorola,cpcap-battery"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0,
+ "motorola,cpcap-regulator"),
+ MFD_CELL_OF("cpcap-rtc", NULL, NULL, 0, 0, "motorola,cpcap-rtc"),
+ MFD_CELL_OF("cpcap-pwrbutton", NULL, NULL, 0, 0,
+ "motorola,cpcap-pwrbutton"),
+ MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0,
+ "motorola,cpcap-usb-phy"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 0, "motorola,cpcap-led-red"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 1, "motorola,cpcap-led-green"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 2, "motorola,cpcap-led-blue"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 3, "motorola,cpcap-led-adl"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
+ MFD_CELL_NAME("cpcap-codec"),
+};
+
+static const struct mfd_cell cpcap_mapphone_mfd_devices[] = {
+ MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0,
+ "motorola,mapphone-cpcap-adc"),
+ MFD_CELL_OF("cpcap_battery", NULL, NULL, 0, 0,
+ "motorola,cpcap-battery"),
+ MFD_CELL_OF("cpcap-charger", NULL, NULL, 0, 0,
+ "motorola,mapphone-cpcap-charger"),
+ MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0,
+ "motorola,mapphone-cpcap-regulator"),
+ MFD_CELL_OF("cpcap-rtc", NULL, NULL, 0, 0, "motorola,cpcap-rtc"),
+ MFD_CELL_OF("cpcap-pwrbutton", NULL, NULL, 0, 0,
+ "motorola,cpcap-pwrbutton"),
+ MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0,
+ "motorola,mapphone-cpcap-usb-phy"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 0, "motorola,cpcap-led-red"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 1, "motorola,cpcap-led-green"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 2, "motorola,cpcap-led-blue"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 3, "motorola,cpcap-led-adl"),
+ MFD_CELL_OF("cpcap-led", NULL, NULL, 0, 4, "motorola,cpcap-led-cp"),
+ MFD_CELL_NAME("cpcap-codec"),
};
static int cpcap_probe(struct spi_device *spi)
{
struct cpcap_ddata *cpcap;
+ const struct mfd_cell *cells;
+ unsigned int num_cells;
int ret;
cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
if (!cpcap)
return -ENOMEM;
+ cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);
+ if (!cpcap->variant)
+ return -ENODEV;
+
+ switch (cpcap->variant) {
+ case CPCAP_DEFAULT:
+ cells = cpcap_default_mfd_devices;
+ num_cells = ARRAY_SIZE(cpcap_default_mfd_devices);
+ break;
+ case CPCAP_MAPPHONE:
+ cells = cpcap_mapphone_mfd_devices;
+ num_cells = ARRAY_SIZE(cpcap_mapphone_mfd_devices);
+ break;
+ default:
+ return dev_err_probe(&spi->dev, -EINVAL,
+ "Unknown device %d\n", cpcap->variant);
+ }
+
cpcap->spi = spi;
spi_set_drvdata(spi, cpcap);
@@ -331,10 +333,28 @@ static int cpcap_probe(struct spi_device *spi)
spi->dev.coherent_dma_mask = 0;
spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
- return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
- ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, NULL);
+ return devm_mfd_add_devices(&spi->dev, 0, cells, num_cells, NULL, 0, NULL);
}
+static const struct of_device_id cpcap_of_match[] = {
+ {
+ .compatible = "motorola,cpcap",
+ .data = (void *)CPCAP_DEFAULT
+ }, {
+ .compatible = "motorola,mapphone-cpcap",
+ .data = (void *)CPCAP_MAPPHONE
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cpcap_of_match);
+
+static const struct spi_device_id cpcap_spi_ids[] = {
+ { "cpcap", CPCAP_DEFAULT },
+ { "mapphone-cpcap", CPCAP_MAPPHONE },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
+
static struct spi_driver cpcap_driver = {
.driver = {
.name = "cpcap-core",
diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
index 981e5777deb7..1a85b06272c8 100644
--- a/include/linux/mfd/motorola-cpcap.h
+++ b/include/linux/mfd/motorola-cpcap.h
@@ -25,6 +25,12 @@
#define CPCAP_REVISION_2_0 0x10
#define CPCAP_REVISION_2_1 0x11
+enum cpcap_variant {
+ CPCAP_DEFAULT = 1,
+ CPCAP_MAPPHONE,
+ CPCAP_MAX
+};
+
/* CPCAP registers */
#define CPCAP_REG_INT1 0x0000 /* Interrupt 1 */
#define CPCAP_REG_INT2 0x0004 /* Interrupt 2 */
--
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