* [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-05-10 5:20 UTC (permalink / raw)
To: linux-arm-kernel, linux-input, linux-serial
Cc: Ethan Nelson-Moore, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Linus Walleij, Kees Cook,
Nathan Chancellor, Sebastian Andrzej Siewior, Steven Rostedt,
Thomas Weissschuh, Peter Zijlstra
To improve future maintainability, change the interrupt handling for
mach-footbridge to use sparse IRQs.
Since the number of possible interrupts is already fixed and relatively
small, just make it use all legacy interrupts preallocated using the
.nr_irqs field in the machine descriptor, rather than actually
allocating domains on the fly.
Many files had to be adjusted to include <mach/irqs.h>
explicitly because it is no longer implicitly included with sparse
IRQs.
Description adapted from commit c78a41fc04f0 ("ARM: s3c24xx: convert
to sparse-irq").
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
This commit depends on my previous submission "ARM: <asm/floppy.h>: fix
build with sparse IRQs".
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/irq.h | 4 +++-
| 2 +-
| 2 +-
| 2 +-
| 2 ++
| 4 +---
| 2 +-
| 2 +-
| 2 +-
| 2 ++
| 2 +-
drivers/char/nwbutton.c | 2 +-
drivers/input/serio/i8042-io.h | 6 +++---
drivers/tty/serial/21285.c | 2 +-
15 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 09b2767fee0f..1155c78bb6aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -153,7 +153,7 @@ config ARM
select PCI_SYSCALL if PCI
select PERF_USE_VMALLOC
select RTC_LIB
- select SPARSE_IRQ if !ARCH_FOOTBRIDGE
+ select SPARSE_IRQ
select SYS_SUPPORTS_APM_EMULATION
select THREAD_INFO_IN_TASK
select TIMER_OF if OF
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index 26c1d2ced4ce..08589b88c3b9 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -10,7 +10,9 @@
#define NR_IRQS NR_IRQS_LEGACY
#endif
-#ifndef irq_canonicalize
+#ifdef CONFIG_ARCH_FOOTBRIDGE
+#define irq_canonicalize(i) (((i) == 2) ? 9 : i)
+#else
#define irq_canonicalize(i) (i)
#endif
--git a/arch/arm/mach-footbridge/dc21285-timer.c b/arch/arm/mach-footbridge/dc21285-timer.c
index 2908c9ef3c9b..7d7ad1c1ef3f 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -12,7 +12,7 @@
#include <linux/irq.h>
#include <linux/sched_clock.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/hardware/dec21285.h>
#include <asm/mach/time.h>
--git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index e1b336624883..ffdecfadc9e2 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -17,7 +17,7 @@
#include <linux/io.h>
#include <linux/spinlock.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/mach/pci.h>
#include <asm/hardware/dec21285.h>
--git a/arch/arm/mach-footbridge/ebsa285-pci.c b/arch/arm/mach-footbridge/ebsa285-pci.c
index c3f280d08fa7..d2168660dd01 100644
--- a/arch/arm/mach-footbridge/ebsa285-pci.c
+++ b/arch/arm/mach-footbridge/ebsa285-pci.c
@@ -10,7 +10,7 @@
#include <linux/pci.h>
#include <linux/init.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/mach/pci.h>
#include <asm/mach-types.h>
--git a/arch/arm/mach-footbridge/ebsa285.c b/arch/arm/mach-footbridge/ebsa285.c
index 1cb7d674bc81..a820f7467468 100644
--- a/arch/arm/mach-footbridge/ebsa285.c
+++ b/arch/arm/mach-footbridge/ebsa285.c
@@ -10,6 +10,7 @@
#include <linux/slab.h>
#include <linux/leds.h>
+#include <mach/irqs.h>
#include <asm/hardware/dec21285.h>
#include <asm/mach-types.h>
@@ -117,6 +118,7 @@ MACHINE_START(EBSA285, "EBSA285")
.video_end = 0x000bffff,
.map_io = footbridge_map_io,
.init_early = footbridge_sched_clock,
+ .nr_irqs = FOOTBRIDGE_NR_IRQS,
.init_irq = footbridge_init_irq,
.init_time = footbridge_timer_init,
.restart = footbridge_restart,
--git a/arch/arm/mach-footbridge/include/mach/irqs.h b/arch/arm/mach-footbridge/include/mach/irqs.h
index a5f41846ab9c..10f1fbc24012 100644
--- a/arch/arm/mach-footbridge/include/mach/irqs.h
+++ b/arch/arm/mach-footbridge/include/mach/irqs.h
@@ -11,7 +11,7 @@
*/
#include <asm/mach-types.h>
-#define NR_IRQS 36
+#define FOOTBRIDGE_NR_IRQS 36
#define NR_DC21285_IRQS 16
#define _ISA_IRQ(x) (0 + (x))
@@ -93,5 +93,3 @@
#define I8042_KBD_IRQ IRQ_ISA_KEYBOARD
#define I8042_AUX_IRQ (machine_is_netwinder() ? IRQ_NETWINDER_PS2MOUSE : IRQ_ISA_PS2MOUSE)
#define IRQ_FLOPPYDISK IRQ_ISA_FLOPPY
-
-#define irq_canonicalize(_i) (((_i) == IRQ_ISA_CASCADE) ? IRQ_ISA_2 : _i)
--git a/arch/arm/mach-footbridge/isa-irq.c b/arch/arm/mach-footbridge/isa-irq.c
index 842ddb4121ef..e4e71bdf1dc7 100644
--- a/arch/arm/mach-footbridge/isa-irq.c
+++ b/arch/arm/mach-footbridge/isa-irq.c
@@ -21,8 +21,8 @@
#include <asm/mach/irq.h>
#include <mach/hardware.h>
+#include <mach/irqs.h>
#include <asm/hardware/dec21285.h>
-#include <asm/irq.h>
#include <asm/mach-types.h>
#include "common.h"
--git a/arch/arm/mach-footbridge/isa-timer.c b/arch/arm/mach-footbridge/isa-timer.c
index 723e3eae995d..07dee61b0b03 100644
--- a/arch/arm/mach-footbridge/isa-timer.c
+++ b/arch/arm/mach-footbridge/isa-timer.c
@@ -13,7 +13,7 @@
#include <linux/spinlock.h>
#include <linux/timex.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/mach/time.h>
#include "common.h"
--git a/arch/arm/mach-footbridge/isa.c b/arch/arm/mach-footbridge/isa.c
index 84caccddce44..1e7b0f5fb111 100644
--- a/arch/arm/mach-footbridge/isa.c
+++ b/arch/arm/mach-footbridge/isa.c
@@ -7,7 +7,7 @@
#include <linux/init.h>
#include <linux/serial_8250.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/hardware/dec21285.h>
#include "common.h"
--git a/arch/arm/mach-footbridge/netwinder-hw.c b/arch/arm/mach-footbridge/netwinder-hw.c
index c024eefd4978..ab17ba916d47 100644
--- a/arch/arm/mach-footbridge/netwinder-hw.c
+++ b/arch/arm/mach-footbridge/netwinder-hw.c
@@ -16,6 +16,7 @@
#include <linux/slab.h>
#include <linux/leds.h>
+#include <mach/irqs.h>
#include <asm/hardware/dec21285.h>
#include <asm/mach-types.h>
#include <asm/setup.h>
@@ -766,6 +767,7 @@ MACHINE_START(NETWINDER, "Rebel-NetWinder")
.reserve_lp2 = 1,
.fixup = fixup_netwinder,
.map_io = footbridge_map_io,
+ .nr_irqs = FOOTBRIDGE_NR_IRQS,
.init_irq = footbridge_init_irq,
.init_time = isa_timer_init,
.restart = netwinder_restart,
--git a/arch/arm/mach-footbridge/netwinder-pci.c b/arch/arm/mach-footbridge/netwinder-pci.c
index e8304392074b..bfd5c0606c71 100644
--- a/arch/arm/mach-footbridge/netwinder-pci.c
+++ b/arch/arm/mach-footbridge/netwinder-pci.c
@@ -10,7 +10,7 @@
#include <linux/pci.h>
#include <linux/init.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/mach/pci.h>
#include <asm/mach-types.h>
diff --git a/drivers/char/nwbutton.c b/drivers/char/nwbutton.c
index 92cee5717237..99819b184aac 100644
--- a/drivers/char/nwbutton.c
+++ b/drivers/char/nwbutton.c
@@ -18,7 +18,7 @@
#include <linux/init.h>
#include <linux/uaccess.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#include <asm/mach-types.h>
#define __NWBUTTON_C /* Tell the header file who we are */
diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
index a8f4b2d70e59..cea72bd888af 100644
--- a/drivers/input/serio/i8042-io.h
+++ b/drivers/input/serio/i8042-io.h
@@ -15,9 +15,9 @@
* IRQs.
*/
-#if defined(__arm__)
-/* defined in include/asm-arm/arch-xxx/irqs.h */
-#include <asm/irq.h>
+#ifdef CONFIG_ARCH_FOOTBRIDGE
+/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
+#include <mach/irqs.h>
#elif defined(CONFIG_PPC)
extern int of_i8042_kbd_irq;
extern int of_i8042_aux_irq;
diff --git a/drivers/tty/serial/21285.c b/drivers/tty/serial/21285.c
index 4de0c975ebdc..f0c63875912e 100644
--- a/drivers/tty/serial/21285.c
+++ b/drivers/tty/serial/21285.c
@@ -15,11 +15,11 @@
#include <linux/serial.h>
#include <linux/io.h>
-#include <asm/irq.h>
#include <asm/mach-types.h>
#include <asm/system_info.h>
#include <asm/hardware/dec21285.h>
#include <mach/hardware.h>
+#include <mach/irqs.h>
#define BAUD_BASE (mem_fclk_21285/64)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
From: dev exalt @ 2026-05-10 6:36 UTC (permalink / raw)
To: Bastien Nocera
Cc: jikos, bentiss, lains, linux-input, linux-kernel, sari.kreitem,
hbarnor
In-Reply-To: <CAJaUH_-0vDrXTr==n=eKJH+BmhDRjzpd6s9by2yTMJH9VuD+gA@mail.gmail.com>
Hi Bastien,
Just following up on this thread in case you had a chance to review
our latest response.
Would you be OK with us proceeding with the implementation and
preparing a v2 patch based on it?
Thanks,
Baraa
On Thu, Mar 19, 2026 at 12:05 PM dev exalt <exalt.dev.team@gmail.com> wrote:
>
> Hi Bastien,
>
> Thanks for the review. Please see our responses inline below.
>
> On Mon, Mar 9, 2026 at 11:53 AM Bastien Nocera <hadess@hadess.net> wrote:
> >
> > Hey,
> >
> > Sorry for not looking at this earlier, it slipped through the cracks as
> > it arrived on the mailing-list as I was away.
> >
> > On Mon, 2025-12-15 at 14:53 +0200, DevExalt wrote:
> > > From: "Baraa Atta (Dev Exalt)" <exalt.dev.team@gmail.com>
> > >
> > > Add support in the Logitech HID++ driver for the HID++ Multi-Platform
> > > feature (0x4531), which enables HID++ devices to adjust their
> > > behavior
> > > based on the host operating system (Linux, ChromeOS, Android).
> >
> > Can you please explain what the feature actually does ? (the Logitech
> > docs say "Set the right keyboard layout for your computer operating
> > system" and mention that some multimedia keys are inoperable unless a
> > compatible OS is set).
>
> The HID++ Multi-Platform feature (0x4531) allows a device to select a
> platform profile that determines how the device firmware behaves for a
> specific operating system.
>
> In practice, this affects how certain keys and functions are exposed
> to the host. Depending on the selected platform, the device may emit
> different HID usages or key combinations for the same physical key.
>
> For example, on the Logitech MX Keys S keyboard a specific key
> produces different events depending on the configured platform. When
> the platform is set to Linux the key generates the combination Shift +
> Ctrl + Alt + Meta + Space, while when the platform is set to Chrome
> the same key generates a dedicated Emoji key event (HID usage code
> 585).
>
> The exact behavioral differences are device-specific and defined by
> the device firmware.
>
> >
> > >
> > > This patch:
> > > * Adds device IDs for MX Keys S (046d:b378) and Casa Keys
> > > (046d:b371).
> > > * Introduces the module parameter "hidpp_platform" to allow
> > > selecting a
> > > target platform.
> > > * Detects whether a device implements feature 0x4531.
> > > * Validates that the requested platform is supported by the device.
> > > * Applies the platform index when valid, otherwise leaves the device
> > > unchanged.
> > > * Keeps default behavior when "hidpp_platform" is unset or invalid.
> >
> > Can you explain the benefits of setting this module parameter, compared
> > to using the keyboard shortcuts to switch to a specific OS
> > configuration?
>
> The distribution can configure the parameter and have the OS configure
> the device automatically without user interaction. Devices will just
> work as expected out of the box. Users can still override it using the
> keyboard shortcut.
>
> >
> > What happens when 2 Logitech devices with different supported OSes are
> > used?
>
> If a device does not support the platform specified through the module
> parameter, the driver does not modify that device and its default
> platform configuration remains unchanged.
>
> During initialization, the driver queries the device for the list of
> supported platform descriptors exposed by the HID++ Multi-Platform
> feature (0x4531). The requested platform is only applied if the device
> advertises support for a compatible descriptor.
>
> For example, if two devices are connected and the module parameter is
> set to linux, a device that supports the Linux platform descriptor
> will have its platform updated accordingly, causing its firmware
> behavior to switch to the Linux profile. A device that does not
> advertise support for the Linux platform will not be modified and will
> continue operating on its default configuration.
>
> >
> > > Supported values for hidpp_platform:
> > > Android, Linux, Chrome
> >
> > Any reason why there aren't more supported OSes?
> >
> > The Logitech docs[1] lists:
> > WebOS iOS MacOS Android Chrome Linux WinEmb Windows Tizen
> > as possible values.
> >
> > [1]:
> > https://drive.google.com/file/d/1KyiBA5m_5V1s6jQ9eQrgRJN0SbbbI9_I/view
> >
> > I recently got a K980 which has this functionality, it only documents
> > Windows, macOS and Chrome, but Solaar also lists Linux as an option.
> >
> > So my questions would be:
> > - why not support the whole range of possible OSes in this option?
>
> Our initial focus during development was primarily on Android, and we
> subsequently added Linux and Chrome. However, if it is preferred for
> completeness, we are happy to add the rest of supported OS platforms
> listed in the documentation.
>
> > - why is it a module option instead of, say, a sysfs attribute that
> > could be changed per device?
> > - why not implement this in user-space through a udev callout?
>
> The module parameter was initially chosen to provide a simple,
> system-wide default that distributions can configure at boot. This
> ensures the devices work out of the box without relying on user
> interaction.
>
> Following your question, we can also add a per-device sysfs attribute
> alongside the module parameter. This hybrid approach accommodates
> compatibility with all systems, since udev is not supported by all
> distributions.
>
> >
> > Cheers
> >
> > >
> > > TEST=Pair MX Keys S and Casa Keys over Bluetooth and verify:
> > > * Feature 0x4531 is detected.
> > > * Valid platform values are accepted and applied.
> > > * Invalid platform values result in no update.
> > > * Devices without 0x4531 retain default behavior.
> > > * Platform-specific key behavior is observed once applied.
> > >
> > > Signed-off-by: Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
> > > ---
> > > drivers/hid/hid-ids.h | 2 +
> > > drivers/hid/hid-logitech-hidpp.c | 280
> > > +++++++++++++++++++++++++++++++
> > > drivers/hid/hid-quirks.c | 2 +
> > > 3 files changed, 284 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > index d31711f1aaec..12de1194d7fa 100644
> > > --- a/drivers/hid/hid-ids.h
> > > +++ b/drivers/hid/hid-ids.h
> > > @@ -866,6 +866,8 @@
> > > #define USB_DEVICE_ID_LOGITECH_T651 0xb00c
> > > #define USB_DEVICE_ID_LOGITECH_DINOVO_EDGE_KBD 0xb309
> > > #define USB_DEVICE_ID_LOGITECH_CASA_TOUCHPAD 0xbb00
> > > +#define USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD 0xb371
> > > +#define USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD 0xb378
> > > #define USB_DEVICE_ID_LOGITECH_C007 0xc007
> > > #define USB_DEVICE_ID_LOGITECH_C077 0xc077
> > > #define USB_DEVICE_ID_LOGITECH_RECEIVER 0xc101
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> > > logitech-hidpp.c
> > > index d5011a5d0890..e94daed31981 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -4373,6 +4373,280 @@ static bool hidpp_application_equals(struct
> > > hid_device *hdev,
> > > return report && report->application == application;
> > > }
> > >
> > > +/* -----------------------------------------------------------------
> > > --------- */
> > > +/* 0x4531: Multi-Platform
> > > Support */
> > > +/* -----------------------------------------------------------------
> > > --------- */
> > > +
> > > +/*
> > > + * Some Logitech devices expose the HID++ feature 0x4531 (Multi-
> > > Platform) allowing
> > > + * the host to specify which operating system platform to use on the
> > > device. Changing device's
> > > + * platform may alter the behavior of the device to match the
> > > specified platform.
> > > + */
> > > +
> > > +static char *hidpp_platform;
> > > +module_param(hidpp_platform, charp, 0644);
> > > +MODULE_PARM_DESC(hidpp_platform, "Select host platform type for
> > > Logitech HID++ Multi-Platform feature "
> > > + "0x4531, valid values: (linux|chrome|android). If
> > > unset, no "
> > > + "change is applied.");
> > > +
> > > +#define HIDPP_MULTIPLATFORM_FEAT_ID 0x4531
> > > +#define HIDPP_MULTIPLATFORM_GET_FEATURE_INFO 0x0F
> > > +#define HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR 0x1F
> > > +#define HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM 0x3F
> > > +
> > > +#define
> > > HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX BIT(10)
> > > +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME BIT(11)
> > > +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID BIT(12)
> > > +
> > > +struct hidpp_platform_desc {
> > > + u8 plat_idx;
> > > + u8 desc_idx;
> > > + u16 plat_mask;
> > > +};
> > > +
> > > +/**
> > > + * hidpp_multiplatform_mask_from_str() - Convert platform name to an
> > > HID++ platform mask
> > > + * @pname: Platform name string
> > > + *
> > > + * Converts a platform name string to its corresponding HID++
> > > platform mask based on
> > > + * the Multi-Platform feature specification.
> > > + *
> > > + * Return: Platform mask corresponding to @pname on success,
> > > + * or 0 if @pname is NULL or unsupported.
> > > + */
> > > +static u16 hidpp_multiplatform_mask_from_str(const char *pname)
> > > +{
> > > + if (!pname)
> > > + return 0;
> > > +
> > > + if (!strcasecmp(pname, "linux"))
> > > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX;
> > > + if (!strcasecmp(pname, "chrome"))
> > > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME;
> > > + if (!strcasecmp(pname, "android"))
> > > + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * hidpp_multiplatform_get_num_pdesc() - Retrieve number of platform
> > > descriptors
> > > + * @hidpp: Pointer to the hidpp_device instance
> > > + * @feat_index: Feature index of the Multi-Platform feature
> > > + * @num_desc: Pointer to store the number of platform descriptors
> > > + *
> > > + * Retrieves the number of platform descriptors supported by the
> > > device through
> > > + * the Multi-Platform feature and stores it in @num_desc.
> > > + *
> > > + * Return: 0 on success, or non-zero on failure.
> > > + */
> > > +static int hidpp_multiplatform_get_num_pdesc(struct hidpp_device
> > > *hidpp,
> > > + u8 feat_index, u8
> > > *num_desc)
> > > +{
> > > + int ret;
> > > + struct hidpp_report response;
> > > + struct hid_device *hdev = hidpp->hid_dev;
> > > +
> > > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > > +
> > > HIDPP_MULTIPLATFORM_GET_FEATURE_INFO,
> > > + NULL, 0, &response);
> > > + if (ret) {
> > > + hid_warn(hdev, "Multiplatform: GET_FEATURE_INFO
> > > failed (err=%d)", ret);
> > > + return ret;
> > > + }
> > > +
> > > + *num_desc = response.fap.params[3];
> > > + hid_dbg(hdev, "Multiplatform: Device supports %d platform
> > > descriptors", *num_desc);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * hidpp_multiplatform_get_platform_desc() - Retrieve a platform
> > > descriptor entry
> > > + * @hidpp: Pointer to the hidpp_device instance
> > > + * @feat_index: Feature index of the Multi-Platform feature
> > > + * @platform_idx: Index of the platform descriptor to retrieve
> > > + * @pdesc: Pointer to store the retrieved platform descriptor
> > > + *
> > > + * Retrieves a single platform descriptor identified by
> > > @platform_idx from the
> > > + * device and stores the parsed descriptor fields in @pdesc.
> > > + *
> > > + * Return: 0 on success, or non-zero on failure.
> > > + */
> > > +static int hidpp_multiplatform_get_platform_desc(struct hidpp_device
> > > *hidpp, u8 feat_index,
> > > + u8 platform_idx,
> > > struct hidpp_platform_desc *pdesc)
> > > +{
> > > + int ret;
> > > + struct hidpp_report response;
> > > + u8 params[1] = { platform_idx };
> > > + struct hid_device *hdev = hidpp->hid_dev;
> > > +
> > > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > > +
> > > HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR,
> > > + params, sizeof(params),
> > > &response);
> > > +
> > > + if (ret) {
> > > + hid_warn(hdev,
> > > + "Multiplatform: GET_PLATFORM_DESCRIPTOR
> > > failed for index %d (err=%d)",
> > > + platform_idx, ret);
> > > + return ret;
> > > + }
> > > +
> > > + pdesc->plat_idx = response.fap.params[0];
> > > + pdesc->desc_idx = response.fap.params[1];
> > > + pdesc->plat_mask =
> > > get_unaligned_be16(&response.fap.params[2]);
> > > +
> > > + hid_dbg(hdev,
> > > + "Multiplatform: descriptor %d: plat_idx=%d,
> > > desc_idx=%d, plat_mask=0x%04x",
> > > + platform_idx, pdesc->plat_idx, pdesc->desc_idx,
> > > pdesc->plat_mask);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * hidpp_multiplatform_get_platform_index() - Find platform index
> > > for a mask
> > > + * @hidpp: Pointer to the hidpp_device instance
> > > + * @feat_index: Feature index of the Multi-Platform feature
> > > + * @plat_mask: Platform mask to search for
> > > + * @plat_index: Pointer to store the matched platform index
> > > + *
> > > + * Iterates through all platform descriptors exposed by the device
> > > via the
> > > + * Multi-Platform feature, retrieving each descriptor and comparing
> > > its
> > > + * platform mask to @plat_mask. A descriptor matches if its mask
> > > overlaps with
> > > + * the requested @plat_mask (i.e. (pdesc.plat_mask & plat_mask) is
> > > non-zero).
> > > + *
> > > + * When a matching descriptor is found, its platform index
> > > (plat_idx) is
> > > + * written to @plat_index and the function returns success.
> > > + *
> > > + * If no descriptor matches, -ENOENT is returned.
> > > + *
> > > + * Return: 0 on success; -ENOENT if no matching descriptor exists;
> > > + * or non-zero on failure.
> > > + */
> > > +static int hidpp_multiplatform_get_platform_index(struct
> > > hidpp_device *hidpp,
> > > + u8 feat_index, u16
> > > plat_mask,
> > > + u8 *plat_index)
> > > +{
> > > + int i;
> > > + int ret;
> > > + u8 num_desc;
> > > + struct hidpp_platform_desc pdesc;
> > > + struct hid_device *hdev = hidpp->hid_dev;
> > > +
> > > + ret = hidpp_multiplatform_get_num_pdesc(hidpp, feat_index,
> > > &num_desc);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + for (i = 0; i < num_desc; i++) {
> > > + ret = hidpp_multiplatform_get_platform_desc(hidpp,
> > > feat_index, i, &pdesc);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (pdesc.plat_mask & plat_mask) {
> > > + *plat_index = pdesc.plat_idx;
> > > + hid_dbg(hdev,
> > > + "Multiplatform: Selected platform
> > > index %d for platform '%s'",
> > > + *plat_index, hidpp_platform);
> > > + return 0;
> > > + }
> > > + }
> > > +
> > > + hid_dbg(hdev,
> > > + "Multiplatform: No matching platform descriptor
> > > found for platform '%s'",
> > > + hidpp_platform);
> > > + return -ENOENT;
> > > +}
> > > +
> > > +/**
> > > + * hidpp_multiplatform_update_device_platform() - Update the device
> > > platform
> > > + * @hidpp: Pointer to the hidpp_device instance
> > > + * @feat_index: Feature index of the Multi-Platform feature
> > > + * @plat_index: Platform index to set on the device
> > > + *
> > > + * Sends the HID++ Multi-Platform 'SET_CURRENT_PLATFORM' command to
> > > the device to
> > > + * update its platform index to @plat_index.
> > > + *
> > > + * Return: 0 on success, or non-zero on failure.
> > > + */
> > > +static int hidpp_multiplatform_update_device_platform(struct
> > > hidpp_device *hidpp,
> > > + u8 feat_index,
> > > u8 plat_index)
> > > +{
> > > + int ret;
> > > + struct hidpp_report response;
> > > + /* Byte 0 (hostIndex): 0xFF selects the current host. */
> > > + u8 params[2] = { 0xFF, plat_index };
> > > +
> > > + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> > > +
> > > HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM,
> > > + params, sizeof(params),
> > > &response);
> > > +
> > > + if (ret)
> > > + hid_warn(hidpp->hid_dev,
> > > + "Multiplatform: SET_CURRENT_PLATFORM failed
> > > for index %d (err=%d)",
> > > + plat_index, ret);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/**
> > > + * hidpp_multiplatform_init() - Apply the HID++ Multi-Platform
> > > (0x4531) feature
> > > + * @hidpp: Pointer to the hidpp_device instance
> > > + *
> > > + * Initializes the Multi-Platform feature by selecting the device
> > > platform
> > > + * corresponding to the module parameter @hidpp_platform, if
> > > provided.
> > > + *
> > > + * The function performs the following steps:
> > > + * 1. Convert the @hidpp_platform string into a platform mask.
> > > + * 2. Check whether the device supports the Multi-Platform feature
> > > (0x4531).
> > > + * 3. Look up the device's platform index whose mask matches the
> > > host
> > > + * platform mask.
> > > + * 4. Apply that platform index to the device via
> > > 'SET_CURRENT_PLATFORM'.
> > > + *
> > > + * If the module parameter is unset or invalid, or the device does
> > > not support
> > > + * the feature, or no matching platform descriptor is found, the
> > > function exits
> > > + * silently without modifying the device state.
> > > + *
> > > + * On success, the device's platform configuration is updated.
> > > + */
> > > +static void hidpp_multiplatform_init(struct hidpp_device *hidpp)
> > > +{
> > > + int ret;
> > > + u8 feat_index;
> > > + u8 plat_index;
> > > + u16 host_plat_mask;
> > > + struct hid_device *hdev = hidpp->hid_dev;
> > > +
> > > + if (!hidpp_platform)
> > > + return;
> > > +
> > > + host_plat_mask =
> > > hidpp_multiplatform_mask_from_str(hidpp_platform);
> > > + if (!host_plat_mask) {
> > > + hid_warn(hdev,
> > > + "Multiplatform: Invalid or unsupported
> > > platform name '%s'",
> > > + hidpp_platform);
> > > + return;
> > > + }
> > > +
> > > + ret = hidpp_root_get_feature(hidpp,
> > > HIDPP_MULTIPLATFORM_FEAT_ID, &feat_index);
> > > + if (ret) {
> > > + hid_warn(hdev,
> > > + "Multiplatform: Failed to get the HID++
> > > multiplatform feature 0x4531");
> > > + return;
> > > + }
> > > +
> > > + ret = hidpp_multiplatform_get_platform_index(hidpp,
> > > feat_index, host_plat_mask,
> > > + &plat_index);
> > > + if (ret)
> > > + return;
> > > +
> > > + ret = hidpp_multiplatform_update_device_platform(hidpp,
> > > feat_index, plat_index);
> > > + if (ret)
> > > + return;
> > > +
> > > + hid_info(hdev,
> > > + "Multiplatform: Device platform successfully set to
> > > '%s'", hidpp_platform);
> > > +}
> > > +
> > > static int hidpp_probe(struct hid_device *hdev, const struct
> > > hid_device_id *id)
> > > {
> > > struct hidpp_device *hidpp;
> > > @@ -4467,6 +4741,8 @@ static int hidpp_probe(struct hid_device *hdev,
> > > const struct hid_device_id *id)
> > > if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT)
> > > connect_mask &= ~HID_CONNECT_HIDINPUT;
> > >
> > > + hidpp_multiplatform_init(hidpp);
> > > +
> > > /* Now export the actual inputs and hidraw nodes to the
> > > world */
> > > hid_device_io_stop(hdev);
> > > ret = hid_connect(hdev, connect_mask);
> > > @@ -4664,6 +4940,10 @@ static const struct hid_device_id
> > > hidpp_devices[] = {
> > > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
> > > { /* MX Anywhere 3SB mouse over Bluetooth */
> > > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
> > > + { /* Casa Keys keyboard over Bluetooth */
> > > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > > USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> > > + { /* MX Keys S keyboard over Bluetooth */
> > > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > > USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> > > {}
> > > };
> > >
> > > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> > > index c89a015686c0..99ca04b61bda 100644
> > > --- a/drivers/hid/hid-quirks.c
> > > +++ b/drivers/hid/hid-quirks.c
> > > @@ -520,6 +520,8 @@ static const struct hid_device_id
> > > hid_have_special_driver[] = {
> > > #endif
> > > #if IS_ENABLED(CONFIG_HID_LOGITECH_HIDPP)
> > > { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> > > USB_DEVICE_ID_LOGITECH_G920_WHEEL) },
> > > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > > USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> > > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> > > USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> > > #endif
> > > #if IS_ENABLED(CONFIG_HID_MAGICMOUSE)
> > > { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
> > > USB_DEVICE_ID_APPLE_MAGICMOUSE) },
>
> Thanks,
>
> Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 3/9] iio: hid-sensors: introduce device managed API
From: Andy Shevchenko @ 2026-05-10 6:36 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260509101040.791404-4-sanjayembedded@gmail.com>
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?
> +{
> + 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);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 4/9] iio: gyro: hid-sensor-gyro-3d: cleanup codestyle warning
From: Andy Shevchenko @ 2026-05-10 6:38 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260509101040.791404-5-sanjayembedded@gmail.com>
On Sat, May 09, 2026 at 03:40:35PM +0530, Sanjay Chitroda wrote:
> Reported by checkpatch:
> FILE: drivers/iio/gyro/hid-sensor-gyro-3d.c
>
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> + unsigned usage_id,
Use the type that is in the respective prototypes.
Also note, there was a patch doing exactly that. Find it in the mailing lists
and ask author if you can take it or what the status of affairs is.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 7/9] iio: humidity: hid-sensor-humidity: use common device for devres
From: Andy Shevchenko @ 2026-05-10 6:42 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260509101040.791404-8-sanjayembedded@gmail.com>
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.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v5 0/6] mfd: cpcap: convert documentation to schema and add Mot board support
From: Svyatoslav Ryhel @ 2026-05-10 11:07 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
The initial goal was only to add support for the CPCAP used in the Mot
Tegra20 board; however, since the documentation was already partially
converted, I decided to complete the conversion to schema too.
The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
from TXT to YAML while preserving the original structure. Mot board
compatibility was added to the regulator and core schema. Since these
were one-line patches, they were not separated into dedicated commits;
however, the commit message notes this for both cases.
Finally, the CPCAP MFD was slightly refactored to improve support for
multiple subcell compositions.
---
Changes in v2:
- fixed code style
- rtc conversion was picked, so patch dropped
- added audio ports description into mfd schema
- splitted schema conversion and compatible addition
- minor style improvements and typo fixes
Changes in v3:
- added regulator node names list into pattern
- filled spi_device_id with driver data
- ADC patches were picked, so changes dropped
Changes in v4:
- dropped regulator patches (applied)
Changes in v5:
- switched to MFD_CELL_* macros
- switched to use determinator of model
- switched to spi_get_device_match_data
---
Svyatoslav Ryhel (6):
dt-bindings: leds: leds-cpcap: convert to DT schema
dt-bindings: input: cpcap-pwrbutton: convert to DT schema
dt-bindings: mfd: motorola-cpcap: convert to DT schema
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
mfd: motorola-cpcap: diverge configuration per-board
mfd: motorola-cpcap: add support for Mot CPCAP composition
.../bindings/input/cpcap-pwrbutton.txt | 20 -
.../input/motorola,cpcap-pwrbutton.yaml | 32 ++
.../devicetree/bindings/leds/leds-cpcap.txt | 29 --
.../bindings/leds/motorola,cpcap-leds.yaml | 42 ++
.../bindings/mfd/motorola,cpcap.yaml | 419 ++++++++++++++++++
.../bindings/mfd/motorola-cpcap.txt | 78 ----
drivers/mfd/motorola-cpcap.c | 172 ++++---
include/linux/mfd/motorola-cpcap.h | 7 +
8 files changed, 611 insertions(+), 188 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
--
2.51.0
^ permalink raw reply
* [PATCH v5 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Svyatoslav Ryhel @ 2026-05-10 11:07 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>
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
diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
deleted file mode 100644
index ebf7cdc7f70c..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Motorola CPCAP PMIC LEDs
-------------------------
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-Requires node properties:
-- compatible: should be one of
- * "motorola,cpcap-led-mdl" (Main Display Lighting)
- * "motorola,cpcap-led-kl" (Keyboard Lighting)
- * "motorola,cpcap-led-adl" (Aux Display Lighting)
- * "motorola,cpcap-led-red" (Red Triode)
- * "motorola,cpcap-led-green" (Green Triode)
- * "motorola,cpcap-led-blue" (Blue Triode)
- * "motorola,cpcap-led-cf" (Camera Flash)
- * "motorola,cpcap-led-bt" (Bluetooth)
- * "motorola,cpcap-led-cp" (Camera Privacy LED)
-- label: see Documentation/devicetree/bindings/leds/common.txt
-- vdd-supply: A phandle to the regulator powering the LED
-
-Example:
-
-&cpcap {
- cpcap_led_red: red-led {
- compatible = "motorola,cpcap-led-red";
- label = "cpcap:red";
- vdd-supply = <&sw5>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
new file mode 100644
index 000000000000..c8e7b88a05cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC LEDs
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. LEDs are
+ represented as sub-nodes of the PMIC node on the device tree.
+
+allOf:
+ - $ref: /schemas/leds/common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - motorola,cpcap-led-adl # Display Lighting
+ - motorola,cpcap-led-blue # Blue Triode
+ - motorola,cpcap-led-bt # Bluetooth
+ - motorola,cpcap-led-cf # Camera Flash
+ - motorola,cpcap-led-cp # Camera Privacy LED
+ - motorola,cpcap-led-green # Green Triode
+ - motorola,cpcap-led-kl # Keyboard Lighting
+ - motorola,cpcap-led-mdl # Main Display Lighting
+ - motorola,cpcap-led-red # Red Triode
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - label
+ - vdd-supply
+
+unevaluatedProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
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>
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
diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
deleted file mode 100644
index 0dd0076daf71..000000000000
--- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Motorola CPCAP on key
-
-This module is part of the CPCAP. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "motorola,cpcap-pwrbutton"
-- interrupts: irq specifier for CPCAP's ON IRQ
-
-Example:
-
-&cpcap {
- cpcap_pwrbutton: pwrbutton {
- compatible = "motorola,cpcap-pwrbutton";
- interrupts = <23 IRQ_TYPE_NONE>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
new file mode 100644
index 000000000000..77a3e5a47d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC power key
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ This module is part of the Motorola CPCAP MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
+ power key is represented as a sub-node of the PMIC node on the device
+ tree.
+
+properties:
+ compatible:
+ const: motorola,cpcap-pwrbutton
+
+ interrupts:
+ items:
+ - description: CPCAP's ON interrupt
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+...
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
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>
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
+
+ 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 related
* [PATCH v5 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
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 compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/mfd/motorola,cpcap.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
index 7f257f3a1a5a..542d149d2b39 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
+
+ - items:
+ - const: motorola,cpcap
+ - const: st,6556002
reg:
maxItems: 1
--
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
* [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 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
* 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
* 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
* [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 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
* 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 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: (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 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
* [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
* [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
* 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
* 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
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