* Re: [PATCH] HID: playstation: Clamp num_touch_reports
From: Jiri Kosina @ 2026-05-12 15:55 UTC (permalink / raw)
To: T.J. Mercier
Cc: roderick.colenbrander, linux-input, Benjamin Tissoires, stable,
Xingyu Jin, Roderick Colenbrander, linux-kernel
In-Reply-To: <20260417154704.1186803-1-tjmercier@google.com>
On Fri, 17 Apr 2026, T.J. Mercier wrote:
> A device would never lie about the number of touch reports would it?
>
> If it does the loop in dualshock4_parse_report will read off the end of
> the touch_reports array, up to about 2 KiB for the maximum number of 256
> loop iteraions. The data that is read is emitted via evdev if the
> DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
> clamping the num_touch_reports value provided by the device to the
> maximum size of the touch_reports array.
>
> Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
> Cc: stable@vger.kernel.org
> Reported-by: Xingyu Jin <xingyuj@google.com>
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6] HID: magicmouse: add battery reporting for Magic Trackpad v1
From: Jiri Kosina @ 2026-05-12 15:53 UTC (permalink / raw)
To: Damiano Gragnaniello; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20260416143323.418078-1-damianogragnaniello@gmail.com>
On Thu, 16 Apr 2026, Damiano Gragnaniello wrote:
[ ... snip ... ]
>
> - /* If there is only one "firm" touch, set touch to its
> - * tracking ID.
> - */
[ ... snip ... ]
> - /* If some button was pressed before, keep it held
> - * down. Otherwise, if there's exactly one firm
> - * touch, use that to override the mouse's guess.
> - */
[ ... snip ... ]
> - /* If requested, emulate a scroll wheel by detecting small
> - * vertical touch motions.
> - */
> - if (emulate_scroll_wheel && (input->id.product !=
> - USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)) {
[ ... snip ... ]
> - /* Reset acceleration after half a second. */
[ ... snip ... ]
> - /* Generate the input events for this touch. */
[ ... snip ... ]
> - /* Expect four bytes of prefix, and N*9 bytes of touch data. */
[ ... snip ... ]
> - /* The following bits provide a device specific timestamp. They
> - * are unused here.
> - *
> - * ts = data[1] >> 6 | data[2] << 2 | data[3] << 10;
> - */
[ ... snip ... ]
> - /* Expect twelve bytes of prefix and N*9 bytes of touch data. */
[ ... snip ... ]
Why are you removing all those comments? (and quite some more).
I don't think your patch changes any of this.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Jiri Kosina @ 2026-05-12 15:49 UTC (permalink / raw)
To: Lee Jones; +Cc: Benjamin Tissoires, linux-input, linux-kernel, gnoack
In-Reply-To: <20260416131655.2279756-1-lee@kernel.org>
On Thu, 16 Apr 2026, Lee Jones wrote:
> It is currently possible for a malicious or misconfigured USB device to
> cause an out-of-bounds (OOB) read when submitting reports using
> DOUBLE_REPORT_ID by specifying a large report length and providing a
> smaller one.
>
> Let's prevent that by comparing the specified report length with the
> actual size of the data read in from userspace. If the actual data
> length ends up being smaller than specified, we'll politely warn the
> user and prevent any further processing.
>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v1 => v2: Add more size checks to protect against issues during recursion
Applied, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: fix OOB write in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:48 UTC (permalink / raw)
To: Florian Pradines; +Cc: gupt21, bentiss, linux-i2c, linux-input
In-Reply-To: <20260509094517.2691246-1-florian.pradines@gmail.com>
On Sat, 9 May 2026, Florian Pradines wrote:
> mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
> offset rxbuf_idx without checking that the copy fits within the
> destination buffer. A device responding with up to 60 bytes to a
> small I2C/SMBus read can overflow the buffer.
>
> Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
> mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
> before the memcpy.
>
> Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:47 UTC (permalink / raw)
To: Benoit Sevens
Cc: Rishi Gupta, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel
In-Reply-To: <20260415114752.1181079-1-bsevens@google.com>
On Wed, 15 Apr 2026, Benoit Sevens wrote:
> From: Benoît Sevens <bsevens@google.com>
>
> A heap buffer overflow can occur in the mcp2221_raw_event() function
> when handling I2C read responses. The driver failed to check if the
> total incoming data length fits within the originally allocated buffer
> `mcp->rxbuf`.
>
> Fix this by introducing `rxbuf_len` to `struct mcp2221` to keep track
> of the allocated buffer size. Initialize it in `mcp_i2c_smbus_read()`
> and `mcp_smbus_xfer()`, and ensure the copied data length combined with
> the current index does not exceed this length in `mcp2221_raw_event()`.
>
> Signed-off-by: Benoît Sevens <bsevens@google.com>
Unfortunately the patch seems to have been somehow mangled by your mail
client:
patching file drivers/hid/hid-mcp2221.c
Hunk #1 succeeded at 126 (offset 7 lines).
Hunk #2 FAILED at 324.
patch: **** malformed patch at line 173: u16 addr,
Fix for the same issue has later been submitted by Florian Pradines [1],
so I will be taking that one and adding you as Reported-by: or so, ok?
Thanks.
[1] https://lore.kernel.org/all/20260509094517.2691246-1-florian.pradines@gmail.com/
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Jiri Kosina @ 2026-05-12 15:43 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <20260415073142.1303505-1-vi@endrift.com>
On Wed, 15 Apr 2026, Vicki Pfau wrote:
> This series adds preliminary support for Switch 2 controllers using the
> same split-driver model as previous versions. This is a minor iteration on
> v3 (which was erroneously submitted as v2 again), fixing an issue where we
> checked for NULL instead of handling an ERR_PTR, as well as a few typo
> fixes.
>
> Vicki Pfau (3):
> HID: nintendo: Add preliminary Switch 2 controller driver
> HID: nintendo: Add rumble support for Switch 2 controllers
> HID: nintendo: Add unified report format support
Vicki,
are you planning v5 with Silvan's comment addressed, please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification
From: Jiri Kosina @ 2026-05-12 15:39 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, bentiss
In-Reply-To: <20260413125803.46792-1-carvsdriver@gmail.com>
On Mon, 13 Apr 2026, Dave Carey wrote:
> The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a
> HID_DG_TOUCHPAD application collection designed for the Windows inbox HID
> driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN
> collections provide the correct direct-touch interface. The presence of
> the touchpad collection causes hid-multitouch to misclassify the
> touchscreen nodes as indirect buttonpads, leaving them non-functional.
>
> Within the touchpad collection:
> - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic
> that sets INPUT_MT_POINTER on the touchscreen applications.
> - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via
> mt_allocate_application(), propagating to all touchscreen nodes.
> - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD,
> setting td->is_buttonpad = true for the entire device.
>
> Additionally, the firmware resets if any USB control request arrives while
> the CDC-ACM interface is initialising (~1.18 s after enumeration).
> The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature
> reports in the touchscreen collections trigger GET_REPORT calls at probe
> that hit this window. Surface Switch (0x57) and Button Switch (0x58)
> feature reports are sent by mt_set_modes() on every input-device open and
> close, repeatedly hitting this window throughout device lifetime.
>
> The firmware also leaves a persistent ghost contact in its contact buffer
> (contact ID 2, fixed coordinates, tip always asserted) on every enumeration.
> This ghost occupies a multitouch slot and prevents KWin from seeing a clean
> finger-lift, causing stuck touch state. The ghost is cleared when Input
> Mode is set via HID_REQ_SET_REPORT at probe.
Oh man, what a device.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] HID: pulsar: add driver for Pulsar gaming mice
From: Jiri Kosina @ 2026-05-12 15:37 UTC (permalink / raw)
To: Nikolas Koesling
Cc: Benjamin Tissoires, Lode Willems, linux-input, linux-kernel, Leo
In-Reply-To: <20260412075346.100567-1-nikolas@koesling.info>
On Sun, 12 Apr 2026, Nikolas Koesling wrote:
> Add a HID driver for Pulsar wireless gaming mice (X2 V2, X2H, X2A,
> Xlite V3). The driver exposes battery level, voltage, and charging
> status through the power supply framework. It supports wired, 1kHz,
> and 4kHz wireless dongle connections.
>
> The driver also supports Kysona M600 ATK, VXE R1 SE+ and
> VXE Dragonfly R1 Pro, which use the same protocol for reading
> battery status and availability.
>
> The protocol used by this driver is based on findings from
> python-pulsar-mouse-tool by Andrew Rabert (MIT License):
> https://github.com/andrewrabert/python-pulsar-mouse-tool
>
> ATK vendor and device IDs were provided by Leo <leo@managarm.org>.
> VXE and Kysona vendor and device IDS are from hid-kysona.c by
> Lode Willems <me@lodewillems.com>
>
> Tested-by: Leo <leo@managarm.org>
> Signed-off-by: Nikolas Koesling <nikolas@koesling.info>
> ---
> Changes in v2:
> - Add support for Kysona M600, ATK VXE R1 SE+, and VXE Dragonfly R1 Pro
> - Add device type enum to distinguish vendors and generate proper
> battery names per vendor/model
> - Add mutual exclusion with HID_KYSONA in Kconfig
> - Add ATK and VXE vendor/device IDs to hid-ids.h
> - Refactor model name generation: extract model_pulsar() and add
> model_atk() for vendor-specific battery naming
> - Fall back to hdev->name for battery model when device info read
> fails on non-Pulsar devices (downgrade error to debug log)
> - Remove POWER_SUPPLY_PROP_MANUFACTURER property
> - Pass device type via driver_data in hid_device_id table
>
> Changes in v3:
> - Increase size of battery model name to hid device name size
> ---
> MAINTAINERS | 6 +
> drivers/hid/Kconfig | 15 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-ids.h | 15 +
> drivers/hid/hid-pulsar.c | 754 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 791 insertions(+)
> create mode 100644 drivers/hid/hid-pulsar.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..207216632918 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11352,6 +11352,12 @@ L: linux-input@vger.kernel.org
> S: Supported
> F: drivers/hid/hid-playstation.c
>
> +HID PULSAR DRIVER
> +M: Nikolas Koesling <nikolas@koesling.info>
> +L: linux-input@vger.kernel.org
> +S: Maintained
> +F: drivers/hid/hid-pulsar.c
> +
> HID SENSOR HUB DRIVERS
> M: Jiri Kosina <jikos@kernel.org>
> M: Jonathan Cameron <jic23@kernel.org>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index c1d9f7c6a5f2..333d165554ee 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -511,12 +511,15 @@ config HID_KYE
> config HID_KYSONA
> tristate "Kysona devices"
> depends on USB_HID
> + depends on !HID_PULSAR
> help
> Support for Kysona mice.
>
> Say Y here if you have a Kysona M600 mouse
> and want to be able to read its battery capacity.
>
> + Note: The Kysona M600 is also supported by HID_PULSAR.
> +
I guess that we want to just ditch that driver altogether then?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: magicmouse: enable battery polling for 2024 Magic Trackpad
From: Jiri Kosina @ 2026-05-12 15:36 UTC (permalink / raw)
To: Dmitri Ollari; +Cc: linux-input
In-Reply-To: <20260411163806.35759-1-dmitri.ollari@protonmail.com>
On Sat, 11 Apr 2026, Dmitri Ollari wrote:
> The 2024 Magic Trackpad USB-C (PID 0x0324) does not report battery
> strength via HID descriptor fields over Bluetooth. Instead it requires
> an explicit HID_REQ_GET_REPORT request to retrieve the battery level.
>
> This patch makes the following changes:
>
> 1. Replace the battery_timer (timer_list) with battery_work (delayed_work)
> so that HID_REQ_GET_REPORT can be issued from a sleepable context.
> Timers run in atomic context and cannot block, which caused deadlocks
> on the Bluetooth transport path.
>
> 2. Extend the fetch guard and probe scheduling block to include the 2024
> Magic Trackpad USB-C when connected over Bluetooth (vendor 0x004C,
> product 0x0324 via BT_VENDOR_ID_APPLE).
>
> 3. Schedule battery_work immediately at probe (delay=0) instead of
> issuing a direct magicmouse_fetch_battery() call. The direct call
> bypassed the cold-start correction logic and could publish a stale
> value before the work handler had a chance to validate it.
>
> 4. Add a cold-start
> double-poll: the device may return a stale battery
> value (e.g. 4%) on the very first GET_REPORT after power-on. On the
> first successful poll battery_validated is set and a second poll is
> scheduled 3 seconds later to obtain the real value. Subsequent polls
> use the normal 60-second interval.
>
> 5. Remove the early-return guard that skipped polling when
> battery_capacity equalled battery_max. This prevented the second
> corrective poll from firing when the first stale response happened
> to equal 100.
>
> Signed-off-by: Dmitri Ollari <dmitri.ollari@protonmail.com>
Dmitri,
thanks for the patch.
It has however been badly line-wrapped and whitespace-damaged by your mail
client.
Can you please look into fixing it and resubmit?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sony: use input_dev from sc struct in sony_init_ff()
From: Jiri Kosina @ 2026-05-12 15:34 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260411155347.101760-2-rosalie@mailbox.org>
On Sat, 11 Apr 2026, Rosalie Wanders wrote:
> This commit makes sony_init_ff() use the input_dev from the sc struct,
> this simplifies the sony_init_ff() function.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: usbhid: replace strlcat with better alternatives
From: Jiri Kosina @ 2026-05-12 15:33 UTC (permalink / raw)
To: Mahad Ibrahim
Cc: Benjamin Tissoires, linux-usb, linux-input, linux-hardening,
linux-kernel-mentees, Shuah Khan, linux-kernel
In-Reply-To: <20260410192447.7059-1-mahad.ibrahim.dev@gmail.com>
On Fri, 10 Apr 2026, Mahad Ibrahim wrote:
> In preparation for the removal of the strlcat() API as per the KSPP,
> replace the string concatenation logic in hid-core, usbkbd, and
> usbmouse with struct seq_buf, which tracks the current write position
> and remaining space internally. The changes implemented include:
>
> - Replace device name and phys concatenation with seq_buf_puts().
> - Include Struct seq_buf and its initialization.
> - Include header file of seq_buf.
> - Replace strlen() with seq_buf_used() on the string buffer which was
> tracked by seq_buf to increase speed.
> - Add size_t len in files which did not have it.
> - Use of strscpy with length in place of strlcat.
>
> Testing: This driver was compiled as a module as well as in-built in
> QEMU with the QEMU basic mouse, and QEMU basic keyboard. The testing was
> done in the following steps.
> - Add Hardware Mouse in QEMU checking the usbhid module.
> - Verify dmesg string name of mouse.
> - Blacklist hidusb module from auto-loading, and removing the module via
> rmmod.
> - Load usbmouse module, and reattach QEMU mouse.
> - Verify dmesg string name of mouse.
> - Repeat same procedure on usbkbd module.
>
> This aligns the driver with KSPP security guidelines.
>
> Link: https://github.com/KSPP/linux/issues/370
>
> Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: Add DualSense Edge extra button support
From: Jiri Kosina @ 2026-05-12 15:30 UTC (permalink / raw)
To: Aaron Webster
Cc: Roderick Colenbrander, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260407044008.40222-1-awebster@gmail.com>
On Mon, 6 Apr 2026, Aaron Webster wrote:
> The DualSense Edge controller (product ID 0x0df2) has four additional
> buttons compared to the standard DualSense: two front function buttons
> (Fn1 and Fn2) and two rear paddles (left and right). These are reported
> in bits 4-7 of buttons[2] in the input report.
>
> Map them to BTN_TRIGGER_HAPPY1 through BTN_TRIGGER_HAPPY4 so that
> userspace applications can use these extra inputs. An is_edge flag
> gates the extra button handling based on the product ID.
>
> Signed-off-by: Aaron Webster <awebster@gmail.com>
> ---
> Tested with a DualSense Edge controller (Hardware: 1000208, Firmware:
> 1000087 type 3, Fw version: 20 131082 6, Sw series: 68, Update version:
> 0213, build date Jul 4 2025) on Debian 13 (trixie) with kernel
> 6.12.74+deb13+1-amd64 (x86_64) via Bluetooth.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: rakk: add support for Rakk Dasig X side buttons
From: Jiri Kosina @ 2026-05-12 15:29 UTC (permalink / raw)
To: Karl Cayme; +Cc: bentiss, linux-input, linux-kernel, linuxhid
In-Reply-To: <20260321124759.608492-1-kcayme@gmail.com>
On Sat, 21 Mar 2026, Karl Cayme wrote:
> The Rakk Dasig X gaming mouse has a faulty HID report descriptor that
> declares USAGE_MAXIMUM=3 (buttons 1-3) while actually sending 5 button
> bits (REPORT_COUNT=5). This causes the kernel to ignore side buttons
> (buttons 4 and 5).
>
> Fix by patching the descriptor to set USAGE_MAXIMUM=5 in the
> report_fixup callback.
>
> The mouse uses Telink vendor ID 0x248a with three product IDs for USB
> direct (0xfb01), wireless dongle (0xfa02), and Bluetooth (0x8266)
> connection modes. All three variants have the same bug at byte offset 17.
>
> Suggested-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
> Signed-off-by: Karl Cayme <kcayme@gmail.com>
> ---
> Hi,
>
> Thanks for the feedback. I updated the patch with your suggestion to
> check PIDs.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] HID: iota-ups: add driver for LattePanda IOTA UPS
From: Jiri Kosina @ 2026-05-12 15:27 UTC (permalink / raw)
To: Andrew Maney; +Cc: linux-input, benjamin.tissoires
In-Reply-To: <20260316072034.56694-1-andrewmaney05@gmail.com>
On Mon, 16 Mar 2026, Andrew Maney wrote:
> This driver exposes the DFRobot LattePanda IOTA UPS board as a standard
> power_supply device, allowing desktop environments and power management
> tools such as UPower and systemd-logind to display battery status,
> remaining capacity, and charging status without any special
> configuration. It also enables automatic suspend or shutdown on low
> battery and power profile configuration via any tool that supports the
> standard power_supply interface.
>
> The UPS presents itself as an Arduino Leonardo HID device running custom
> firmware (VID 0x2341, PID 0x8036). It reports status and capacity via
> HID reports 0x07 and 0x0C respectively.
>
> The charge limit (80% or 100%) is configured via a physical DIP switch
> on the UPS board and cannot be detected automatically. Userspace can
> inform the driver of the configured limit via
> charge_control_end_threshold.
>
> Known issue: the driver occasionally reports 0% capacity briefly on
> initial load before the first valid HID report is received. I am
> investigating the cause.
>
> Signed-off-by: Andrew Maney <andrewmaney05@gmail.com>
> ---
> iota-ups.c | 355 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 355 insertions(+)
> create mode 100644 iota-ups.c
>
> diff --git a/iota-ups.c b/iota-ups.c
> new file mode 100644
> index 0000000..df334b2
> --- /dev/null
> +++ b/iota-ups.c
You seem to have generated this patch in a strange way, so that it can't
be applied on top of the tree (i.e. in a standard 'patch -p1' way that
all the tools default to).
Could you please re-generate it properly and resend?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: Jiri Kosina @ 2026-05-12 15:24 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Benjamin Tissoires, René Rebe, linux-input, kernel-janitors,
linux-kernel, Lukas Bulwahn
In-Reply-To: <20260205081131.426899-1-lukas.bulwahn@redhat.com>
On Thu, 5 Feb 2026, Lukas Bulwahn wrote:
> From: Lukas Bulwahn <lukas.bulwahn@redhat.com>
>
> Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for
> appledisplay") intends to add a quirk for kernels built with Apple Cinema
> Display support, but it refers to the non-existing config option
> CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display
> support is named CONFIG_USB_APPLEDISPLAY.
>
> Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef
> directive.
>
> Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay")
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Applied, thanks Lukas.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [RFC] hid: hid-sjoy: race between init and usage
From: Jiri Kosina @ 2026-05-12 15:23 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, jussi.kivilinna, linux-input
In-Reply-To: <20260303094906.1214359-1-oneukum@suse.com>
On Tue, 3 Mar 2026, Oliver Neukum wrote:
> The driver uses an initial IO to set the device to a default
> state. That initialization is currently being done after the device
> node has been created. That means that the single buffer used
> for output can be altered while IO is in progress.
> Move the intialization before announcement to user space.
>
> Fixes: fac733f029251 ("HID: force feedback support for SmartJoy PLUS PS2/USB adapter")
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Jonathan Cameron @ 2026-05-12 14:48 UTC (permalink / raw)
To: Natália Salvino André
Cc: andy, dlechner, jikos, nuno.sa, srinivas.pandruvada, linux-iio,
linux-input, Zhang, Lixu
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
On Mon, 11 May 2026 22:16:16 -0300
Natália Salvino André <natalia.andre@ime.usp.br> wrote:
> This series refactors the HID sensor drivers to standardize the
> initialization of the iio_chan_spec scan_type structure.
> Direct initialization using compound literals was used.
>
> This change improves code readability and ensures that all fields
> of the scan_type structure are properly zero-initialized.
> Additionally, for the hid-sensor-accel-3d driver, the channel
> initialization loop was refactored to iterate directly over the
> scan indices, eliminating redundant logic.
Series looks good to me but I'll leave it on the list a while to
both let sashiko catch up and anyone else who wants to can have time
to look. Also ideally get some testing.
Lixu, if you don't mind, please can you give this a test on top
of the more radical refactor patches?
To me it looks safe enough but this is the sort of series that subtle
typos can hide in!
Thanks,
Jonathan
>
> Natália Salvino André (6):
> iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
> iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
> iio: light: HID: hid-sensor-als: Refactor channel initialization
> iio: light: HID: hid-sensor-prox: Refactor channel initialization
> iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
> initialization
> iio: pressure: HID: hid-sensor-press: Refactor channel initialization
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++----------
> drivers/iio/light/hid-sensor-als.c | 18 +++++--------
> drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
> drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
> 6 files changed, 42 insertions(+), 85 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Jonathan Cameron @ 2026-05-12 14:42 UTC (permalink / raw)
To: Natália Salvino André
Cc: andy, dlechner, jikos, nuno.sa, srinivas.pandruvada, linux-iio,
linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
On Mon, 11 May 2026 22:16:16 -0300
Natália Salvino André <natalia.andre@ime.usp.br> wrote:
> This series refactors the HID sensor drivers to standardize the
> initialization of the iio_chan_spec scan_type structure.
> Direct initialization using compound literals was used.
>
> This change improves code readability and ensures that all fields
> of the scan_type structure are properly zero-initialized.
> Additionally, for the hid-sensor-accel-3d driver, the channel
> initialization loop was refactored to iterate directly over the
> scan indices, eliminating redundant logic.
Hi Natália,
I'm a little confused. How is this v3? Where is the change log?
I'll review it as a fresh series.
thanks
Jonathan
>
> Natália Salvino André (6):
> iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
> iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
> iio: light: HID: hid-sensor-als: Refactor channel initialization
> iio: light: HID: hid-sensor-prox: Refactor channel initialization
> iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
> initialization
> iio: pressure: HID: hid-sensor-press: Refactor channel initialization
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++----------
> drivers/iio/light/hid-sensor-als.c | 18 +++++--------
> drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
> drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
> 6 files changed, 42 insertions(+), 85 deletions(-)
>
^ permalink raw reply
* [PATCH] HID: lenovo: Restore Fn-lock LED state on resume for tp10ubkbd devices
From: Kean @ 2026-05-12 14:22 UTC (permalink / raw)
To: derekjohn.clark, mpearson-lenovo
Cc: jikos, bentiss, linux-input, linux-kernel, Kean
The reset_resume callback only restores trackpoint settings for compact
USB keyboards (CUSBKBD, TPIIUSBKBD) but omits the tp10ubkbd device
family: X12_TAB, X12_TAB2, TP10UBKBD, X1_TAB, X1_TAB2, X1_TAB3.
If these devices lose power during suspend, the Fn-lock state reverts
to the hardware default but the driver's cached state and the keyboard
LED are not restored, causing the LED to show the wrong state after
resume.
Add the missing device cases to restore the Fn-lock LED on resume.
Tested:
This patch works on ThinkPad X12_TAB.
Signed-off-by: Kean <rh_king@163.com>
---
drivers/hid/hid-lenovo.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..4c9fb163b6d6 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -1424,6 +1424,8 @@ static int lenovo_probe(struct hid_device *hdev,
static int lenovo_reset_resume(struct hid_device *hdev)
{
+ struct lenovo_drvdata *data;
+
switch (hdev->product) {
case USB_DEVICE_ID_LENOVO_CUSBKBD:
case USB_DEVICE_ID_LENOVO_TPIIUSBKBD:
@@ -1431,6 +1433,17 @@ static int lenovo_reset_resume(struct hid_device *hdev)
lenovo_features_set_cptkbd(hdev);
break;
+ case USB_DEVICE_ID_LENOVO_X12_TAB:
+ case USB_DEVICE_ID_LENOVO_X12_TAB2:
+ case USB_DEVICE_ID_LENOVO_TP10UBKBD:
+ case USB_DEVICE_ID_LENOVO_X1_TAB:
+ case USB_DEVICE_ID_LENOVO_X1_TAB2:
+ case USB_DEVICE_ID_LENOVO_X1_TAB3:
+ data = hid_get_drvdata(hdev);
+ if (data)
+ lenovo_led_set_tp10ubkbd(hdev, TP10UBKBD_FN_LOCK_LED,
+ data->fn_lock ? LED_ON : LED_OFF);
+ break;
default:
break;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Lee Jones @ 2026-05-12 14:12 UTC (permalink / raw)
To: Günther Noack
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260430140148.GJ1806155@google.com>
On Thu, 30 Apr 2026, Lee Jones wrote:
> On Thu, 16 Apr 2026, Günther Noack wrote:
>
> > On Thu, Apr 16, 2026 at 02:16:54PM +0100, Lee Jones wrote:
> > > It is currently possible for a malicious or misconfigured USB device to
> > > cause an out-of-bounds (OOB) read when submitting reports using
> > > DOUBLE_REPORT_ID by specifying a large report length and providing a
> > > smaller one.
> > >
> > > Let's prevent that by comparing the specified report length with the
> > > actual size of the data read in from userspace. If the actual data
> > > length ends up being smaller than specified, we'll politely warn the
> > > user and prevent any further processing.
> > >
> > > Signed-off-by: Lee Jones <lee@kernel.org>
> > > ---
> > > v1 => v2: Add more size checks to protect against issues during recursion
> > >
> > > drivers/hid/hid-magicmouse.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > > index 91f621ceb924..e84e6b21d113 100644
> > > --- a/drivers/hid/hid-magicmouse.c
> > > +++ b/drivers/hid/hid-magicmouse.c
> > > @@ -390,6 +390,10 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > > struct input_dev *input = msc->input;
> > > int x = 0, y = 0, ii, clicks = 0, npoints;
> > >
> > > + /* Protect against zero sized recursive calls from DOUBLE_REPORT_ID */
> > > + if (size < 1)
> > > + return 0;
> > > +
> > > switch (data[0]) {
> > > case TRACKPAD_REPORT_ID:
> > > case TRACKPAD2_BT_REPORT_ID:
> > > @@ -490,6 +494,18 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > > /* Sometimes the trackpad sends two touch reports in one
> > > * packet.
> > > */
> > > +
> > > + /* Ensure that we have at least 2 elements (report type and size) */
> > > + if (size < 2)
> > > + return 0;
> > > +
> > > + if (size < data[1] + 2) {
> > > + hid_warn(hdev,
> > > + "received report length (%d) was smaller than specified (%d)",
> > > + size, data[1] + 2);
> > > + return 0;
> > > + }
> > > +
> > > magicmouse_raw_event(hdev, report, data + 2, data[1]);
> > > magicmouse_raw_event(hdev, report, data + 2 + data[1],
> > > size - 2 - data[1]);
> > > --
> > > 2.54.0.rc1.513.gad8abe7a5a-goog
> > >
> >
> > Thank you! This looks correct now.
> >
> > Reviewed-by: Günther Noack <gnoack@google.com>
>
> Contentless ping. =:-)
Biweekly ping on this please - if you'd prefer a [RESEND], let me know.
--
Lee Jones
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Alain Michaud @ 2026-05-12 13:22 UTC (permalink / raw)
To: jikos, bentiss
Cc: lains, hadess, ogay, linux-input, linux-kernel, Alain Michaud
Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
to the hidpp_devices matching table, enabling full HID++ support for
them.
The added keyboards are:
- Logitech Signature K650 & B2B
- Logitech Pebble Keys 2 K380S
- Logitech Casa Pop-Up Desk & B2B
- Logitech Wave Keys & B2B
- Logitech Signature Slim K950 & B2B
- Logitech MX Keys S & B2B
- Logitech Keys-To-Go 2
- Logitech Pop Icon Keys
- Logitech MX Keys Mini & B2B
- Logitech Signature Slim Solar+ K980 B2B
- Logitech Bluetooth Keyboard K250/K251
- Logitech Signature Comfort K880 & B2B
Signed-off-by: Alain Michaud <alainmichaud@google.com>
Reviewed-by: Olivier Gay <ogay@logitech.com>
---
drivers/hid/hid-logitech-hidpp.c | 38 ++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index b1330d23bd2d..b740dcd60b2f 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4685,6 +4685,44 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
{ /* MX Master 4 mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
+ { /* Logitech Signature K650 over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb36f) },
+ { /* Logitech Signature K650 B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb370) },
+ { /* Logitech Pebble Keys 2 K380S over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb377) },
+ { /* Logitech Casa Pop-Up Desk over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb371) },
+ { /* Logitech Casa Pop-Up Desk B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb374) },
+ { /* Logitech Wave Keys over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb383) },
+ { /* Logitech Wave Keys B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb384) },
+ { /* Logitech Signature Slim K950 over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb386) },
+ { /* Logitech Signature Slim K950 B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb388) },
+ { /* Logitech MX Keys S over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb378) },
+ { /* Logitech MX Keys S B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb380) },
+ { /* Logitech Keys-To-Go 2 over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb38c) },
+ { /* Logitech Pop Icon Keys over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb38f) },
+ { /* Logitech MX Keys Mini over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb369) },
+ { /* Logitech MX Keys Mini B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb36e) },
+ { /* Logitech Signature Slim Solar+ K980 B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb394) },
+ { /* Logitech Bluetooth Keyboard K250/K251 over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb397) },
+ { /* Logitech Signature Comfort K880 over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb39c) },
+ { /* Logitech Signature Comfort K880 B2B over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb39d) },
{}
};
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v5 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-05-12 13:00 UTC (permalink / raw)
To: Rob Herring
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <20260512125309.GA1476682-robh@kernel.org>
вт, 12 трав. 2026 р. о 15:53 Rob Herring <robh@kernel.org> пише:
>
> On Sun, May 10, 2026 at 02:08:01PM +0300, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> > ---
> > .../bindings/mfd/motorola,cpcap.yaml | 414 ++++++++++++++++++
> > .../bindings/mfd/motorola-cpcap.txt | 78 ----
> > 2 files changed, 414 insertions(+), 78 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> > delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> > new file mode 100644
> > index 000000000000..7f257f3a1a5a
> > --- /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:
> > + compatible:
> > + items:
> > + - const: motorola,cpcap
> > + - const: st,6556002
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
> > + const: 2
> > +
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
>
> There aren't any child nodes with an address. These 2 can be dropped.
>
I will adjust in v6 if there will be need in one.
> > +
> > + spi-max-frequency:
> > + maximum: 9600000
> > +
> > + spi-cs-high: true
> > + spi-cpol: true
> > + spi-cpha: true
> > +
> > + adc:
> > + $ref: /schemas/iio/adc/motorola,cpcap-adc.yaml#
> > +
> > + audio-codec:
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + interrupts:
> > + items:
> > + - description: headset detect interrupt
> > + - description: microphone bias 2 detect interrupt
> > +
> > + interrupt-names:
> > + items:
> > + - const: hs
> > + - const: mb2
> > +
> > + "#sound-dai-cells":
> > + const: 1
> > +
> > + VAUDIO-supply:
> > + description:
> > + Codec power supply, usually VAUDIO regulator of CPCAP.
> > +
> > + 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
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - interrupts
> > + - interrupt-names
> > + - "#sound-dai-cells"
> > +
> > + 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#
> > +
> > + phy:
> > + $ref: /schemas/phy/motorola,cpcap-usb-phy.yaml#
> > +
> > + regulator:
> > + $ref: /schemas/regulator/motorola,cpcap-regulator.yaml#
> > +
> > + rtc:
> > + $ref: /schemas/rtc/motorola,cpcap-rtc.yaml#
> > +
> > +patternProperties:
> > + "^led(-[a-z]+)?$":
> > + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - interrupt-controller
> > + - "#interrupt-cells"
> > + - spi-max-frequency
> > + - "#address-cells"
> > + - "#size-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/input/linux-event-codes.h>
> > +
> > + spi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpcap: pmic@0 {
> > + compatible = "motorola,cpcap", "st,6556002";
> > + reg = <0>; /* cs0 */
> > +
> > + interrupt-parent = <&gpio1>;
> > + interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> > +
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + spi-max-frequency = <3000000>;
> > + spi-cs-high;
> > +
> > + spi-cpol;
> > + spi-cpha;
> > +
> > + cpcap_adc: adc {
> > + compatible = "motorola,cpcap-adc";
> > +
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <8 IRQ_TYPE_NONE>;
> > + interrupt-names = "adcdone";
> > +
> > + #io-channel-cells = <1>;
> > + };
> > +
> > + cpcap_audio: audio-codec {
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <9 IRQ_TYPE_NONE>, <10 IRQ_TYPE_NONE>;
> > + interrupt-names = "hs", "mb2";
> > +
> > + VAUDIO-supply = <&vdd_audio>;
> > +
> > + #sound-dai-cells = <1>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + /* HiFi */
> > + port@0 {
> > + reg = <0>;
> > +
> > + cpcap_audio_codec0: endpoint {
> > + };
> > + };
> > +
> > + /* Voice */
> > + port@1 {
> > + reg = <1>;
> > +
> > + cpcap_audio_codec1: endpoint {
> > + };
> > + };
> > + };
> > + };
> > +
> > + cpcap_battery: battery {
> > + compatible = "motorola,cpcap-battery";
> > +
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <6 IRQ_TYPE_NONE>, <5 IRQ_TYPE_NONE>,
> > + <3 IRQ_TYPE_NONE>, <20 IRQ_TYPE_NONE>,
> > + <54 IRQ_TYPE_NONE>, <57 IRQ_TYPE_NONE>;
> > + interrupt-names = "eol", "lowbph", "lowbpl",
> > + "chrgcurr1", "battdetb", "cccal";
> > +
> > + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> > + <&cpcap_adc 5>, <&cpcap_adc 6>;
> > + io-channel-names = "battdetb", "battp",
> > + "chg_isense", "batti";
> > + power-supplies = <&cpcap_charger>;
> > + };
> > +
> > + cpcap_charger: charger {
> > + compatible = "motorola,mapphone-cpcap-charger";
> > +
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <13 IRQ_TYPE_NONE>, <12 IRQ_TYPE_NONE>,
> > + <29 IRQ_TYPE_NONE>, <28 IRQ_TYPE_NONE>,
> > + <22 IRQ_TYPE_NONE>, <21 IRQ_TYPE_NONE>,
> > + <20 IRQ_TYPE_NONE>, <19 IRQ_TYPE_NONE>,
> > + <54 IRQ_TYPE_NONE>;
> > + interrupt-names = "chrg_det", "rvrs_chrg", "chrg_se1b",
> > + "se0conn", "rvrs_mode", "chrgcurr2",
> > + "chrgcurr1", "vbusvld", "battdetb";
> > +
> > + mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>,
> > + <&gpio3 23 GPIO_ACTIVE_LOW>;
> > +
> > + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> > + <&cpcap_adc 2>, <&cpcap_adc 5>,
> > + <&cpcap_adc 6>;
> > + io-channel-names = "battdetb", "battp",
> > + "vbus", "chg_isense",
> > + "batti";
> > + };
> > +
> > + key-power {
> > + compatible = "motorola,cpcap-pwrbutton";
> > +
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <23 IRQ_TYPE_NONE>;
> > + };
> > +
> > + led-red {
> > + compatible = "motorola,cpcap-led-red";
> > + vdd-supply = <&vdd_led>;
> > + label = "status-led::red";
> > + };
> > +
> > + led-green {
> > + compatible = "motorola,cpcap-led-green";
> > + vdd-supply = <&vdd_led>;
> > + label = "status-led::green";
> > + };
> > +
> > + led-blue {
> > + compatible = "motorola,cpcap-led-blue";
> > + vdd-supply = <&vdd_led>;
> > + label = "status-led::blue";
> > + };
> > +
> > + cpcap_usb2_phy: phy {
> > + compatible = "motorola,cpcap-usb-phy";
> > +
> > + pinctrl-0 = <&usb_gpio_mux_sel1>, <&usb_gpio_mux_sel2>;
> > + pinctrl-1 = <&usb_ulpi_pins>;
> > + pinctrl-2 = <&usb_utmi_pins>;
> > + pinctrl-3 = <&uart3_pins>;
> > + pinctrl-names = "default", "ulpi", "utmi", "uart";
> > + #phy-cells = <0>;
> > +
> > + interrupts-extended =
> > + <&cpcap 15 IRQ_TYPE_NONE>, <&cpcap 14 IRQ_TYPE_NONE>,
> > + <&cpcap 28 IRQ_TYPE_NONE>, <&cpcap 19 IRQ_TYPE_NONE>,
> > + <&cpcap 18 IRQ_TYPE_NONE>, <&cpcap 17 IRQ_TYPE_NONE>,
> > + <&cpcap 16 IRQ_TYPE_NONE>, <&cpcap 49 IRQ_TYPE_NONE>,
> > + <&cpcap 48 IRQ_TYPE_NONE>;
> > + interrupt-names = "id_ground", "id_float", "se0conn",
> > + "vbusvld", "sessvld", "sessend",
> > + "se1", "dm", "dp";
> > +
> > + mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,
> > + <&gpio1 0 GPIO_ACTIVE_HIGH>;
> > +
> > + io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
> > + io-channel-names = "vbus", "id";
> > +
> > + vusb-supply = <&avdd_usb>;
> > + };
> > +
> > + regulator {
> > + compatible = "motorola,cpcap-regulator";
> > +
> > + regulators {
> > + vdd_cpu: SW1 {
> > + regulator-name = "vdd_cpu";
> > + regulator-min-microvolt = <750000>;
> > + regulator-max-microvolt = <1125000>;
> > + regulator-enable-ramp-delay = <1500>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_core: SW2 {
> > + regulator-name = "vdd_core";
> > + regulator-min-microvolt = <950000>;
> > + regulator-max-microvolt = <1300000>;
> > + regulator-enable-ramp-delay = <1500>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_1v8_vio: SW3 {
> > + regulator-name = "vdd_1v8_vio";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-enable-ramp-delay = <0>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_aon: SW4 {
> > + regulator-name = "vdd_aon";
> > + regulator-min-microvolt = <950000>;
> > + regulator-max-microvolt = <1300000>;
> > + regulator-enable-ramp-delay = <1500>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_led: SW5 {
> > + regulator-name = "vdd_led";
> > + regulator-min-microvolt = <5050000>;
> > + regulator-max-microvolt = <5050000>;
> > + regulator-enable-ramp-delay = <1500>;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_hvio: VHVIO {
> > + regulator-name = "vdd_hvio";
> > + regulator-min-microvolt = <2775000>;
> > + regulator-max-microvolt = <2775000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + };
> > +
> > + vcore_emmc: VSDIO {
> > + regulator-name = "vcore_emmc";
> > + regulator-min-microvolt = <1500000>;
> > + regulator-max-microvolt = <3000000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + avdd_dsi_csi: VCSI {
> > + regulator-name = "avdd_dsi_csi";
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-boot-on;
> > + };
> > +
> > + avdd_3v3_periph: VWLAN2 {
> > + regulator-name = "avdd_3v3_periph";
> > + regulator-min-microvolt = <2775000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-boot-on;
> > + };
> > +
> > + vddio_usd: VSIMCARD {
> > + regulator-name = "vddio_usd";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <2900000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_haptic: VVIB {
> > + regulator-name = "vdd_haptic";
> > + regulator-min-microvolt = <1300000>;
> > + regulator-max-microvolt = <3000000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + };
> > +
> > + avdd_usb: VUSB {
> > + regulator-name = "avdd_usb";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + vdd_audio: VAUDIO {
> > + regulator-name = "vdd_audio";
> > + regulator-min-microvolt = <2775000>;
> > + regulator-max-microvolt = <2775000>;
> > + regulator-enable-ramp-delay = <1000>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > + };
> > + };
> > +
> > + cpcap_rtc: rtc {
> > + compatible = "motorola,cpcap-rtc";
> > +
> > + interrupt-parent = <&cpcap>;
> > + interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
> > + };
> > + };
> > + };
> > +
> > +...
> > diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> > deleted file mode 100644
> > index 18c3fc26ca93..000000000000
> > --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> > +++ /dev/null
> > @@ -1,78 +0,0 @@
> > -Motorola CPCAP PMIC device tree binding
> > -
> > -Required properties:
> > -- compatible : One or both of "motorola,cpcap" or "ste,6556002"
> > -- reg : SPI chip select
> > -- interrupts : The interrupt line the device is connected to
> > -- interrupt-controller : Marks the device node as an interrupt controller
> > -- #interrupt-cells : The number of cells to describe an IRQ, should be 2
> > -- #address-cells : Child device offset number of cells, should be 1
> > -- #size-cells : Child device size number of cells, should be 0
> > -- spi-max-frequency : Typically set to 3000000
> > -- spi-cs-high : SPI chip select direction
> > -
> > -Optional subnodes:
> > -
> > -The sub-functions of CPCAP get their own node with their own compatible values,
> > -which are described in the following files:
> > -
> > -- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
> > -- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
> > -- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > -- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
> > -- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > -- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
> > -- Documentation/devicetree/bindings/leds/leds-cpcap.txt
> > -- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> > -
> > -The only exception is the audio codec. Instead of a compatible value its
> > -node must be named "audio-codec".
> > -
> > -Required properties for the audio-codec subnode:
> > -
> > -- #sound-dai-cells = <1>;
> > -- interrupts : should contain jack detection interrupts, with headset
> > - detect interrupt matching "hs" and microphone bias 2
> > - detect interrupt matching "mb2" in interrupt-names.
> > -- interrupt-names : Contains "hs", "mb2"
> > -
> > -The audio-codec provides two DAIs. The first one is connected to the
> > -Stereo HiFi DAC and the second one is connected to the Voice DAC.
> > -
> > -Example:
> > -
> > -&mcspi1 {
> > - cpcap: pmic@0 {
> > - compatible = "motorola,cpcap", "ste,6556002";
> > - reg = <0>; /* cs0 */
> > - interrupt-parent = <&gpio1>;
> > - interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> > - interrupt-controller;
> > - #interrupt-cells = <2>;
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - spi-max-frequency = <3000000>;
> > - spi-cs-high;
> > -
> > - audio-codec {
> > - #sound-dai-cells = <1>;
> > - interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
> > - interrupt-names = "hs", "mb2";
> > -
> > - /* HiFi */
> > - port@0 {
> > - endpoint {
> > - remote-endpoint = <&cpu_dai1>;
> > - };
> > - };
> > -
> > - /* Voice */
> > - port@1 {
> > - endpoint {
> > - remote-endpoint = <&cpu_dai2>;
> > - };
> > - };
> > - };
> > - };
> > -};
> > -
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v5 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Rob Herring @ 2026-05-12 12:53 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <20260510110804.33045-4-clamor95@gmail.com>
On Sun, May 10, 2026 at 02:08:01PM +0300, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> .../bindings/mfd/motorola,cpcap.yaml | 414 ++++++++++++++++++
> .../bindings/mfd/motorola-cpcap.txt | 78 ----
> 2 files changed, 414 insertions(+), 78 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 000000000000..7f257f3a1a5a
> --- /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:
> + compatible:
> + items:
> + - const: motorola,cpcap
> + - const: st,6556002
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
There aren't any child nodes with an address. These 2 can be dropped.
> +
> + spi-max-frequency:
> + maximum: 9600000
> +
> + spi-cs-high: true
> + spi-cpol: true
> + spi-cpha: true
> +
> + adc:
> + $ref: /schemas/iio/adc/motorola,cpcap-adc.yaml#
> +
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + interrupts:
> + items:
> + - description: headset detect interrupt
> + - description: microphone bias 2 detect interrupt
> +
> + interrupt-names:
> + items:
> + - const: hs
> + - const: mb2
> +
> + "#sound-dai-cells":
> + const: 1
> +
> + VAUDIO-supply:
> + description:
> + Codec power supply, usually VAUDIO regulator of CPCAP.
> +
> + 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
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - interrupts
> + - interrupt-names
> + - "#sound-dai-cells"
> +
> + 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#
> +
> + phy:
> + $ref: /schemas/phy/motorola,cpcap-usb-phy.yaml#
> +
> + regulator:
> + $ref: /schemas/regulator/motorola,cpcap-regulator.yaml#
> +
> + rtc:
> + $ref: /schemas/rtc/motorola,cpcap-rtc.yaml#
> +
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/input/linux-event-codes.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpcap: pmic@0 {
> + compatible = "motorola,cpcap", "st,6556002";
> + reg = <0>; /* cs0 */
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + spi-max-frequency = <3000000>;
> + spi-cs-high;
> +
> + spi-cpol;
> + spi-cpha;
> +
> + cpcap_adc: adc {
> + compatible = "motorola,cpcap-adc";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <8 IRQ_TYPE_NONE>;
> + interrupt-names = "adcdone";
> +
> + #io-channel-cells = <1>;
> + };
> +
> + cpcap_audio: audio-codec {
> + interrupt-parent = <&cpcap>;
> + interrupts = <9 IRQ_TYPE_NONE>, <10 IRQ_TYPE_NONE>;
> + interrupt-names = "hs", "mb2";
> +
> + VAUDIO-supply = <&vdd_audio>;
> +
> + #sound-dai-cells = <1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* HiFi */
> + port@0 {
> + reg = <0>;
> +
> + cpcap_audio_codec0: endpoint {
> + };
> + };
> +
> + /* Voice */
> + port@1 {
> + reg = <1>;
> +
> + cpcap_audio_codec1: endpoint {
> + };
> + };
> + };
> + };
> +
> + cpcap_battery: battery {
> + compatible = "motorola,cpcap-battery";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <6 IRQ_TYPE_NONE>, <5 IRQ_TYPE_NONE>,
> + <3 IRQ_TYPE_NONE>, <20 IRQ_TYPE_NONE>,
> + <54 IRQ_TYPE_NONE>, <57 IRQ_TYPE_NONE>;
> + interrupt-names = "eol", "lowbph", "lowbpl",
> + "chrgcurr1", "battdetb", "cccal";
> +
> + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> + <&cpcap_adc 5>, <&cpcap_adc 6>;
> + io-channel-names = "battdetb", "battp",
> + "chg_isense", "batti";
> + power-supplies = <&cpcap_charger>;
> + };
> +
> + cpcap_charger: charger {
> + compatible = "motorola,mapphone-cpcap-charger";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <13 IRQ_TYPE_NONE>, <12 IRQ_TYPE_NONE>,
> + <29 IRQ_TYPE_NONE>, <28 IRQ_TYPE_NONE>,
> + <22 IRQ_TYPE_NONE>, <21 IRQ_TYPE_NONE>,
> + <20 IRQ_TYPE_NONE>, <19 IRQ_TYPE_NONE>,
> + <54 IRQ_TYPE_NONE>;
> + interrupt-names = "chrg_det", "rvrs_chrg", "chrg_se1b",
> + "se0conn", "rvrs_mode", "chrgcurr2",
> + "chrgcurr1", "vbusvld", "battdetb";
> +
> + mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>,
> + <&gpio3 23 GPIO_ACTIVE_LOW>;
> +
> + io-channels = <&cpcap_adc 0>, <&cpcap_adc 1>,
> + <&cpcap_adc 2>, <&cpcap_adc 5>,
> + <&cpcap_adc 6>;
> + io-channel-names = "battdetb", "battp",
> + "vbus", "chg_isense",
> + "batti";
> + };
> +
> + key-power {
> + compatible = "motorola,cpcap-pwrbutton";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <23 IRQ_TYPE_NONE>;
> + };
> +
> + led-red {
> + compatible = "motorola,cpcap-led-red";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::red";
> + };
> +
> + led-green {
> + compatible = "motorola,cpcap-led-green";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::green";
> + };
> +
> + led-blue {
> + compatible = "motorola,cpcap-led-blue";
> + vdd-supply = <&vdd_led>;
> + label = "status-led::blue";
> + };
> +
> + cpcap_usb2_phy: phy {
> + compatible = "motorola,cpcap-usb-phy";
> +
> + pinctrl-0 = <&usb_gpio_mux_sel1>, <&usb_gpio_mux_sel2>;
> + pinctrl-1 = <&usb_ulpi_pins>;
> + pinctrl-2 = <&usb_utmi_pins>;
> + pinctrl-3 = <&uart3_pins>;
> + pinctrl-names = "default", "ulpi", "utmi", "uart";
> + #phy-cells = <0>;
> +
> + interrupts-extended =
> + <&cpcap 15 IRQ_TYPE_NONE>, <&cpcap 14 IRQ_TYPE_NONE>,
> + <&cpcap 28 IRQ_TYPE_NONE>, <&cpcap 19 IRQ_TYPE_NONE>,
> + <&cpcap 18 IRQ_TYPE_NONE>, <&cpcap 17 IRQ_TYPE_NONE>,
> + <&cpcap 16 IRQ_TYPE_NONE>, <&cpcap 49 IRQ_TYPE_NONE>,
> + <&cpcap 48 IRQ_TYPE_NONE>;
> + interrupt-names = "id_ground", "id_float", "se0conn",
> + "vbusvld", "sessvld", "sessend",
> + "se1", "dm", "dp";
> +
> + mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,
> + <&gpio1 0 GPIO_ACTIVE_HIGH>;
> +
> + io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
> + io-channel-names = "vbus", "id";
> +
> + vusb-supply = <&avdd_usb>;
> + };
> +
> + regulator {
> + compatible = "motorola,cpcap-regulator";
> +
> + regulators {
> + vdd_cpu: SW1 {
> + regulator-name = "vdd_cpu";
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1125000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_core: SW2 {
> + regulator-name = "vdd_core";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_1v8_vio: SW3 {
> + regulator-name = "vdd_1v8_vio";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <0>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_aon: SW4 {
> + regulator-name = "vdd_aon";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_led: SW5 {
> + regulator-name = "vdd_led";
> + regulator-min-microvolt = <5050000>;
> + regulator-max-microvolt = <5050000>;
> + regulator-enable-ramp-delay = <1500>;
> + regulator-boot-on;
> + };
> +
> + vdd_hvio: VHVIO {
> + regulator-name = "vdd_hvio";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <2775000>;
> + regulator-enable-ramp-delay = <1000>;
> + };
> +
> + vcore_emmc: VSDIO {
> + regulator-name = "vcore_emmc";
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + avdd_dsi_csi: VCSI {
> + regulator-name = "avdd_dsi_csi";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + avdd_3v3_periph: VWLAN2 {
> + regulator-name = "avdd_3v3_periph";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + vddio_usd: VSIMCARD {
> + regulator-name = "vddio_usd";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2900000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-boot-on;
> + };
> +
> + vdd_haptic: VVIB {
> + regulator-name = "vdd_haptic";
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-enable-ramp-delay = <1000>;
> + };
> +
> + avdd_usb: VUSB {
> + regulator-name = "avdd_usb";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vdd_audio: VAUDIO {
> + regulator-name = "vdd_audio";
> + regulator-min-microvolt = <2775000>;
> + regulator-max-microvolt = <2775000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> + cpcap_rtc: rtc {
> + compatible = "motorola,cpcap-rtc";
> +
> + interrupt-parent = <&cpcap>;
> + interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> deleted file mode 100644
> index 18c3fc26ca93..000000000000
> --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -Motorola CPCAP PMIC device tree binding
> -
> -Required properties:
> -- compatible : One or both of "motorola,cpcap" or "ste,6556002"
> -- reg : SPI chip select
> -- interrupts : The interrupt line the device is connected to
> -- interrupt-controller : Marks the device node as an interrupt controller
> -- #interrupt-cells : The number of cells to describe an IRQ, should be 2
> -- #address-cells : Child device offset number of cells, should be 1
> -- #size-cells : Child device size number of cells, should be 0
> -- spi-max-frequency : Typically set to 3000000
> -- spi-cs-high : SPI chip select direction
> -
> -Optional subnodes:
> -
> -The sub-functions of CPCAP get their own node with their own compatible values,
> -which are described in the following files:
> -
> -- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
> -- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
> -- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> -- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
> -- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> -- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
> -- Documentation/devicetree/bindings/leds/leds-cpcap.txt
> -- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
> -
> -The only exception is the audio codec. Instead of a compatible value its
> -node must be named "audio-codec".
> -
> -Required properties for the audio-codec subnode:
> -
> -- #sound-dai-cells = <1>;
> -- interrupts : should contain jack detection interrupts, with headset
> - detect interrupt matching "hs" and microphone bias 2
> - detect interrupt matching "mb2" in interrupt-names.
> -- interrupt-names : Contains "hs", "mb2"
> -
> -The audio-codec provides two DAIs. The first one is connected to the
> -Stereo HiFi DAC and the second one is connected to the Voice DAC.
> -
> -Example:
> -
> -&mcspi1 {
> - cpcap: pmic@0 {
> - compatible = "motorola,cpcap", "ste,6556002";
> - reg = <0>; /* cs0 */
> - interrupt-parent = <&gpio1>;
> - interrupts = <7 IRQ_TYPE_EDGE_RISING>;
> - interrupt-controller;
> - #interrupt-cells = <2>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - spi-max-frequency = <3000000>;
> - spi-cs-high;
> -
> - audio-codec {
> - #sound-dai-cells = <1>;
> - interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
> - interrupt-names = "hs", "mb2";
> -
> - /* HiFi */
> - port@0 {
> - endpoint {
> - remote-endpoint = <&cpu_dai1>;
> - };
> - };
> -
> - /* Voice */
> - port@1 {
> - endpoint {
> - remote-endpoint = <&cpu_dai2>;
> - };
> - };
> - };
> - };
> -};
> -
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v3 3/9] iio: hid-sensors: introduce device managed API
From: srinivas pandruvada @ 2026-05-12 12:47 UTC (permalink / raw)
To: Sanjay Chitroda, jikos, jic23, Zhang, Lixu
Cc: dlechner, nuno.sa, andy, sakari.ailus, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260509101040.791404-4-sanjayembedded@gmail.com>
On Sat, 2026-05-09 at 15:40 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> 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.
>
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Looks good but we have to test by unbinding ISH PCI device.
Thanks,
Srinivas
> ---
> Changes in v3:
> - Remove cast and update function based on review comment from Andy
> - v2 link ->
> https://lore.kernel.org/all/20260429175918.2541914-3-sanjayembedded@gmail.com/
> ---
> .../common/hid-sensors/hid-sensor-trigger.c | 18
> ++++++++++++++++++
> .../common/hid-sensors/hid-sensor-trigger.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 98fadc61a68a..fb6a4587ae03 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -301,6 +301,24 @@ int hid_sensor_setup_trigger(struct iio_dev
> *indio_dev, const char *name,
> }
> EXPORT_SYMBOL_NS(hid_sensor_setup_trigger, "IIO_HID");
>
> +static void hid_sensor_remove_trigger_action(void *attrb)
> +{
> + hid_sensor_remove_trigger(attrb);
> +}
> +
> +int devm_hid_sensor_setup_trigger(struct device *dev, struct iio_dev
> *indio_dev,
> + const char *name, struct
> hid_sensor_common *attrb)
> +{
> + 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);
> +}
> +EXPORT_SYMBOL_NS(devm_hid_sensor_setup_trigger, "IIO_HID");
> +
> static int __maybe_unused hid_sensor_suspend(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.h
> b/drivers/iio/common/hid-sensors/hid-sensor-trigger.h
> index afec46ecbe71..6fd7c39a240d 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.h
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.h
> @@ -17,6 +17,8 @@ extern const struct dev_pm_ops hid_sensor_pm_ops;
> int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char
> *name,
> struct hid_sensor_common *attrb);
> void hid_sensor_remove_trigger(struct hid_sensor_common *attrb);
> +int devm_hid_sensor_setup_trigger(struct device *dev, struct iio_dev
> *indio_dev,
> + const char *name, struct
> hid_sensor_common *attrb);
> int hid_sensor_power_state(struct hid_sensor_common *st, bool
> state);
>
> #endif
^ permalink raw reply
* Re: [PATCH v3 2/9] iio: hid-sensors: cleanup codestyle warning
From: srinivas pandruvada @ 2026-05-12 12:39 UTC (permalink / raw)
To: Sanjay Chitroda, jikos, jic23
Cc: dlechner, nuno.sa, andy, sakari.ailus, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260509101040.791404-3-sanjayembedded@gmail.com>
On Sat, 2026-05-09 at 15:40 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Reported by checkpatch:
> FILE: drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>
> WARNING: Missing a blank line after declarations
>
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 28d050b45c74..98fadc61a68a 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -313,7 +313,9 @@ static int __maybe_unused
> hid_sensor_resume(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct hid_sensor_common *attrb =
> iio_device_get_drvdata(indio_dev);
> +
> schedule_work(&attrb->work);
> +
> return 0;
> }
>
> @@ -321,6 +323,7 @@ static int __maybe_unused
> hid_sensor_runtime_resume(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct hid_sensor_common *attrb =
> iio_device_get_drvdata(indio_dev);
> +
> return _hid_sensor_power_state(attrb, true);
> }
>
^ 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