* [PATCH 0/2] asus vivobook tablet mode
From: Helge Bahmann @ 2026-07-21 14:28 UTC (permalink / raw)
To: Jiri Kosina, linux-input, Basavaraj Natikar; +Cc: Basavaraj Natikar
In-Reply-To: <ecadaac8-e222-420a-ac5b-4d529fb3317e@amd.com>
Hi Basavaraj,
Here the two patches implementing the split hid/input
driver for the tablet mode support. I mulled over what
exactly to use as report descriptor in the hid driver, and
there is no clean and easy solution -- I hope this is what
you had in mind? I could not figure a way how to do
a stand-alone input driver without doing any hid indirection,
as I simply could not find a way to bind to the physical
dev twice.
Please let me know in comments to the patches how you
would like to proceed.
Thanks!
Helge
^ permalink raw reply
* [PATCH 2/2] amd-sfh-tabletmode: interpret sfh tablet mode hid report
From: Helge Bahmann @ 2026-07-21 14:29 UTC (permalink / raw)
To: Jiri Kosina, linux-input, Basavaraj Natikar; +Cc: Basavaraj Natikar
In-Reply-To: <ecadaac8-e222-420a-ac5b-4d529fb3317e@amd.com>
Add a driver that hooks into the tablet mode hid reports
generated by the amd-sfh-hid driver. This enables tablet
mode switching on e.g. Asus Vivobook devices.
Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
---
drivers/input/misc/Kconfig | 11 ++++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/amd_sfh_tabletmode.c | 88 +++++++++++++++++++++++++
3 files changed, 100 insertions(+)
create mode 100644 drivers/input/misc/amd_sfh_tabletmode.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 94a753fcb64f..5a1dacd6f7b9 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -1003,4 +1003,15 @@ config INPUT_STPMIC1_ONKEY
To compile this driver as a module, choose M here: the
module will be called stpmic1_onkey.
+config INPUT_AMD_SFH_TABLETMODE
+ tristate "AMD sensor fusion hub tablet mode driver"
+ help
+ Say Y to enable support of the tablet mode switch driver for
+ convertible laptops based on the AMD sensor fusion hub. This
+ driver is known to work on Asus VivoBook but will likely
+ work on other laptops featuring the same chipset.
+
+ To compile this driver as a module, choose M here: the
+ module will be called amd_sfh_tabletmode.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415fc4e2918b..3f5abbe39f3a 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -96,3 +96,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK) += yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_AMD_SFH_TABLETMODE) += amd_sfh_tabletmode.o
diff --git a/drivers/input/misc/amd_sfh_tabletmode.c b/drivers/input/misc/amd_sfh_tabletmode.c
new file mode 100644
index 000000000000..ee1207372207
--- /dev/null
+++ b/drivers/input/misc/amd_sfh_tabletmode.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * AMD MP2 PCIe tablet mode hid input driver
+ * Copyright 2026 Helge Bahmann Advanced Micro Devices, Inc.
+ * Authors: Helge Bahmann <hcb@chaoticmind.net>
+ */
+
+#include <linux/hid.h>
+#include <linux/module.h>
+
+#define AMD_SFH_HID_VENDOR 0x1022
+#define AMD_SFH_HID_PRODUCT 0x0001
+
+static int amd_sfh_tabletmode_probe(struct hid_device *hdev,
+ const struct hid_device_id *id)
+{
+ int error = 0;
+
+ error = hid_parse(hdev);
+ if (error)
+ return error;
+
+ error = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (error)
+ return error;
+
+ return 0;
+}
+
+static void amd_sfh_tabletmode_remove(struct hid_device *hdev)
+{
+ hid_hw_stop(hdev);
+}
+
+static int amd_sfh_tabletmode_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ if ((usage->hid & HID_USAGE_PAGE) == HID_UP_CONSUMER && (usage->hid & HID_USAGE) == 0x02ff) {
+ input_set_capability(hi->input, EV_SW, SW_TABLET_MODE);
+ usage->type = EV_SW;
+ usage->code = SW_TABLET_MODE;
+ return 1;
+ }
+ return 0;
+}
+
+static int amd_sfh_tabletmode_event(struct hid_device *hid, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ input_report_switch(field->hidinput->input, SW_TABLET_MODE, value);
+
+ return 0;
+}
+
+static const struct hid_device_id amd_sfh_tabletmode_devices[] = {
+ { HID_DEVICE(BUS_AMD_SFH, HID_GROUP_GENERIC, AMD_SFH_HID_VENDOR, AMD_SFH_HID_PRODUCT) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, amd_sfh_tabletmode_devices);
+
+static struct hid_driver amd_sfh_tabletmode_driver = {
+ .name = "amd_sfh_tabletmode",
+ .id_table = amd_sfh_tabletmode_devices,
+ .probe = amd_sfh_tabletmode_probe,
+ .remove = amd_sfh_tabletmode_remove,
+ .input_mapping = amd_sfh_tabletmode_input_mapping,
+ .event = amd_sfh_tabletmode_event,
+};
+
+static int __init amd_sfh_tabletmode_init(void)
+{
+ int error;
+
+ error = hid_register_driver(&amd_sfh_tabletmode_driver);
+
+ return error;
+}
+module_init(amd_sfh_tabletmode_init);
+
+static void __exit amd_sfh_tabletmode_exit(void)
+{
+ hid_unregister_driver(&amd_sfh_tabletmode_driver);
+}
+module_exit(amd_sfh_tabletmode_exit);
+
+MODULE_DESCRIPTION("Input driver for tablet mode sensor on amd sfh.");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] amd-sfh-hid: tablet mode hid report and asus quirk
From: Helge Bahmann @ 2026-07-21 14:29 UTC (permalink / raw)
To: Jiri Kosina, linux-input, Basavaraj Natikar; +Cc: Basavaraj Natikar
In-Reply-To: <ecadaac8-e222-420a-ac5b-4d529fb3317e@amd.com>
Add an input driver that interprets the "operation mode" sensor offered
by the amd sfh as a hid driver to generate a custom hid report (tablet
mode switch).
Add a quirk to restore compatibility of the driver with the Asus
VivoBook (turn off the "disable interrupts flag). Expose the
intr_disable flag as a module parameter in case it turns out to be
needed on further laptop models.
Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
---
drivers/hid/amd-sfh-hid/amd_sfh_client.c | 19 ------------
drivers/hid/amd-sfh-hid/amd_sfh_hid.h | 1 +
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 9 ++++++
drivers/hid/amd-sfh-hid/amd_sfh_pcie.h | 3 ++
.../hid_descriptor/amd_sfh_hid_desc.c | 31 +++++++++++++++++++
.../hid_descriptor/amd_sfh_hid_desc.h | 9 ++++++
.../hid_descriptor/amd_sfh_hid_report_desc.h | 18 +++++++++++
7 files changed, 71 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
index 7017bfa59093..57ff708ca39b 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
@@ -254,19 +254,6 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
goto cleanup;
}
- if (cl_data->sensor_idx[i] == op_idx) {
- info.period = AMD_SFH_IDLE_LOOP;
- info.sensor_idx = cl_data->sensor_idx[i];
- info.dma_address = cl_data->sensor_dma_addr[i];
- mp2_ops->start(privdata, info);
- cl_data->sensor_sts[i] = amd_sfh_wait_for_response(privdata,
- cl_data->sensor_idx[i],
- SENSOR_ENABLED);
- if (cl_data->sensor_sts[i] == SENSOR_ENABLED)
- cl_data->is_any_sensor_enabled = true;
- continue;
- }
-
cl_data->sensor_sts[i] = SENSOR_DISABLED;
cl_data->sensor_requested_cnt[i] = 0;
cl_data->cur_hid_dev = i;
@@ -327,12 +314,6 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
for (i = 0; i < cl_data->num_hid_devices; i++) {
cl_data->cur_hid_dev = i;
- if (cl_data->sensor_idx[i] == op_idx) {
- dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
- cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
- cl_data->sensor_sts[i]);
- continue;
- }
if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
rc = amdtp_hid_probe(i, cl_data);
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
index 7452b0302953..c1b62e5df2ff 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
@@ -78,4 +78,5 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data);
int amd_sfh_get_report(struct hid_device *hid, int report_id, int report_type);
void amd_sfh_set_report(struct hid_device *hid, int report_id, int report_type);
void amdtp_hid_wakeup(struct hid_device *hid);
+
#endif
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 1d9f955573aa..cd9cff75f114 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -39,6 +39,8 @@ module_param_named(sensor_mask, sensor_mask_override, int, 0444);
MODULE_PARM_DESC(sensor_mask, "override the detected sensors mask");
static bool intr_disable = true;
+module_param_named(intr_disable, intr_disable, bool, 0444);
+MODULE_PARM_DESC(intr_disable, "override the interrupt disable sensor bit");
static int amd_sfh_wait_response_v2(struct amd_mp2_dev *mp2, u8 sid, u32 sensor_sts)
{
@@ -317,6 +319,13 @@ static const struct dmi_system_id dmi_sfh_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook x360 435 G7"),
},
},
+ {
+ .callback = mp2_disable_intr,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VivoBook_ASUSLaptop TP420UA_TM420UA"),
+ }
+ },
{}
};
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
index 2eb61f4e8434..5e968894ebe4 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
@@ -83,6 +83,9 @@ enum sensor_idx {
als_idx = 19
};
+#define AMD_SFH_OP_IDX_MODE_LAPTOP 1
+#define AMD_SFH_OP_IDX_MODE_TABLET 3
+
enum mem_use_type {
USE_DRAM,
USE_C2P_REG,
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
index ef1f9be8b893..7e807b92d296 100644
--- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.c
@@ -42,6 +42,11 @@ static int get_report_descriptor(int sensor_idx, u8 *rep_desc)
memcpy(rep_desc, gyro3_report_descriptor,
sizeof(gyro3_report_descriptor));
break;
+ case op_idx: /* op */
+ memset(rep_desc, 0, sizeof(tablet_mode_report_descriptor));
+ memcpy(rep_desc, tablet_mode_report_descriptor,
+ sizeof(tablet_mode_report_descriptor));
+ break;
case mag_idx: /* Magnetometer */
memset(rep_desc, 0, sizeof(comp3_report_descriptor));
memcpy(rep_desc, comp3_report_descriptor,
@@ -87,6 +92,16 @@ static u32 get_descr_sz(int sensor_idx, int descriptor_name)
return sizeof(struct gyro_feature_report);
}
break;
+ case op_idx:
+ switch (descriptor_name) {
+ case descr_size:
+ return sizeof(tablet_mode_report_descriptor);
+ case input_size:
+ return sizeof(struct tablet_mode_input_report);
+ case feature_size:
+ return sizeof(struct tablet_mode_feature_report);
+ }
+ break;
case mag_idx:
switch (descriptor_name) {
case descr_size:
@@ -139,6 +154,7 @@ static u8 get_feature_report(int sensor_idx, int report_id, u8 *feature_report)
{
struct accel3_feature_report acc_feature;
struct gyro_feature_report gyro_feature;
+ struct tablet_mode_feature_report tablet_mode_feature;
struct magno_feature_report magno_feature;
struct hpd_feature_report hpd_feature;
struct als_feature_report als_feature;
@@ -164,6 +180,11 @@ static u8 get_feature_report(int sensor_idx, int report_id, u8 *feature_report)
memcpy(feature_report, &gyro_feature, sizeof(gyro_feature));
report_size = sizeof(gyro_feature);
break;
+ case op_idx: /* op */
+ get_common_features(&tablet_mode_feature.common_property, report_id);
+ memcpy(feature_report, &tablet_mode_feature, sizeof(tablet_mode_feature));
+ report_size = sizeof(tablet_mode_feature);
+ break;
case mag_idx: /* Magnetometer */
get_common_features(&magno_feature.common_property, report_id);
magno_feature.magno_headingchange_sensitivity = HID_DEFAULT_SENSITIVITY;
@@ -212,6 +233,7 @@ static u8 get_input_report(u8 current_index, int sensor_idx, int report_id,
u8 supported_input = privdata->mp2_acs & GENMASK(3, 0);
struct magno_input_report magno_input;
struct accel3_input_report acc_input;
+ struct tablet_mode_input_report tablet_mode_input;
struct gyro_input_report gyro_input;
struct hpd_input_report hpd_input;
struct als_input_report als_input;
@@ -238,6 +260,15 @@ static u8 get_input_report(u8 current_index, int sensor_idx, int report_id,
memcpy(input_report, &gyro_input, sizeof(gyro_input));
report_size = sizeof(gyro_input);
break;
+ case op_idx: /* op */
+ tablet_mode_input.report_id = 0x11;
+ if (sensor_virt_addr[0] == 3)
+ tablet_mode_input.tablet_state = 1;
+ else
+ tablet_mode_input.tablet_state = 0;
+ memcpy(input_report, &tablet_mode_input, sizeof(tablet_mode_input));
+ report_size = sizeof(tablet_mode_input);
+ break;
case mag_idx: /* Magnetometer */
get_common_inputs(&magno_input.common_property, report_id);
magno_input.in_magno_x = (int)sensor_virt_addr[0] / AMD_SFH_FW_MULTIPLIER;
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
index 882434b1501f..ff82e47eb3ca 100644
--- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
@@ -114,4 +114,13 @@ struct hpd_input_report {
u8 human_presence;
} __packed;
+struct tablet_mode_feature_report {
+ struct common_feature_property common_property;
+} __packed;
+
+struct tablet_mode_input_report {
+ u8 report_id; /* Muss 0x11 (17) sein */
+ u8 tablet_state; /* Bit 0: Status, Bits 1-7: Padding */
+} __packed;
+
#endif
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
index 67ec2d6a417d..f95368534fc6 100644
--- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_desc.h
@@ -776,4 +776,22 @@ static const u8 hpd_report_descriptor[] = {
0X81, 0x02, /* HID Input (Data_Var_Abs) */
0xC0 /* HID end collection */
};
+
+/* tablet mode switch */
+static const u8 tablet_mode_report_descriptor[] = {
+0x05, 0x0C, /* HID usage consumer electronics */
+0x09, 0x01, /* HID usage */
+0xA1, 0x00, /* HID collection (Physical) */
+0x85, 0x11, /* HID report id */
+0x0A, 0xFF, 0x02, /* HID usage (unallocated -- (ab)used for tablet mode) */
+0x15, 0x00, /* HID logical Min_8(0) */
+0x25, 0x01, /* HID logical Max_8(1) */
+0x75, 0x01, /* HID report size(1) */
+0x95, 0x01, /* HID report count (1) */
+0X81, 0x02, /* HID input (Data_Var_Abs) */
+0x75, 0x01, /* HID report size (1) */
+0x95, 0x07, /* HID report count (7) */
+0x81, 0x03, /* HID input (Data_Var_Abs) */
+0xC0 /* HID end collection */
+};
#endif
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] dt-bindings: input: Convert TI Palmas Power Button to DT schema
From: Rob Herring (Arm) @ 2026-07-21 13:54 UTC (permalink / raw)
To: Eduard Bostina
Cc: devicetree, linux-kernel, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, simona.toaca, goledhruva, daniel.baluta,
linux-input, m-chawdhry
In-Reply-To: <20260719141701.3565277-1-egbostina@gmail.com>
On Sun, 19 Jul 2026 14:17:01 +0000, Eduard Bostina wrote:
> Convert the Texas Instruments Palmas power button bindings
> to DT schema.
>
> During the conversion, 'wakeup-source' was added.
> It was missing from the original text binding but is actively
> used by in-tree boards.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
> .../bindings/input/ti,palmas-pwrbutton.txt | 35 -----------
> .../bindings/input/ti,palmas-pwrbutton.yaml | 58 +++++++++++++++++++
> 2 files changed, 58 insertions(+), 35 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> create mode 100644 Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: Convert TI Keypad Controller to DT schema
From: Rob Herring (Arm) @ 2026-07-21 13:48 UTC (permalink / raw)
To: Eduard Bostina
Cc: Andreas Kemnade, Dmitry Torokhov, Krzysztof Kozlowski,
linux-kernel, Aaro Koskinen, Tony Lindgren, linux-omap,
daniel.baluta, goledhruva, m-chawdhry, Conor Dooley, devicetree,
linux-input, Kevin Hilman, simona.toaca, Roger Quadros
In-Reply-To: <20260719133730.3551691-2-egbostina@gmail.com>
On Sun, 19 Jul 2026 13:37:29 +0000, Eduard Bostina wrote:
> Convert the Texas Instruments Keypad Controller bindings
> to DT schema.
>
> During the conversion, the following updates were made:
> - Corrected the documented property 'linux,keypad-no-autorepeat'
> to 'linux,input-no-autorepeat'. The old text binding documented
> the property incorrectly. The standard input subsystem property is
> 'linux,input-no-autorepeat', which is actively used in device
> trees and parsed by the kernel.
> - Added the 'reg-names' property ("mpu"), which was omitted from
> the original text binding but is actively used in device trees.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
> .../devicetree/bindings/input/omap-keypad.txt | 28 ---------
> .../bindings/input/ti,omap4-keypad.yaml | 63 +++++++++++++++++++
> 2 files changed, 63 insertions(+), 28 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/omap-keypad.txt
> create mode 100644 Documentation/devicetree/bindings/input/ti,omap4-keypad.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema
From: Rob Herring (Arm) @ 2026-07-21 12:01 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Pavel Machek, Lee Jones, devicetree, Dmitry Torokhov,
Conor Dooley, Krzysztof Kozlowski, linux-input, linux-kernel,
linux-leds
In-Reply-To: <20260721095654.429346-2-clamor95@gmail.com>
On Tue, 21 Jul 2026 12:56:48 +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/20260721095654.429346-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 v3 3/4] dt-bindings: input: Convert TI TPS65217 power button to DT schema
From: sashiko-bot @ 2026-07-21 11:34 UTC (permalink / raw)
To: Eduard Bostina
Cc: conor+dt, linux-input, linux-leds, dri-devel, robh, devicetree,
lee, dmitry.torokhov
In-Reply-To: <20260721112133.70382-4-egbostina@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing NULL check on `dev_get_regmap` can lead to a kernel panic in the IRQ handler.
- [High] The driver incorrectly masks `platform_get_irq()` error codes with `-EINVAL`, breaking probe deferral.
--
--- Patch [3]: [PATCH v3 3/4] dt-bindings: input: Convert TI TPS65217 power button to DT schema ---
commit 7ffa82f06e0d099b257abd8ec45ed224af6ff3c6
Author: Eduard Bostina <egbostina@gmail.com>
dt-bindings: input: Convert TI TPS65217 power button to DT schema
Convert the Texas Instruments TPS65217 and TPS65218 Power Button
bindings to DT schema.
drivers/input/misc/tps65218-pwrbutton.c:tps6521x_pb_probe() {
...
pwr->regmap = dev_get_regmap(dev->parent, NULL);
...
}
[Severity: High]
This isn't a bug introduced by this patch, but does this code need to check
if pwr->regmap is NULL?
If dev_get_regmap() returns NULL due to an incomplete device tree, it seems
this could lead to a kernel panic during an interrupt when tps6521x_pb_irq()
dereferences it:
drivers/input/misc/tps65218-pwrbutton.c:tps6521x_pb_irq() {
...
error = regmap_read(pwr->regmap, tps_data->reg_status, ®);
...
}
drivers/input/misc/tps65218-pwrbutton.c:tps6521x_pb_probe() {
...
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return -EINVAL;
...
}
[Severity: High]
This is also a pre-existing issue, but does masking the return value of
platform_get_irq() break probe deferral?
If platform_get_irq() returns -EPROBE_DEFER, converting the error to -EINVAL
prevents the driver core from handling the deferral and retrying later.
> diff --git a/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
> new file mode 100644
> index 0000000000000..3526d8b045fd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721112133.70382-1-egbostina@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v3 4/4] dt-bindings: leds: backlight: Convert TPS65217 to DT schema
From: sashiko-bot @ 2026-07-21 11:29 UTC (permalink / raw)
To: Eduard Bostina
Cc: linux-leds, conor+dt, dri-devel, linux-input, devicetree, robh,
lee, dmitry.torokhov
In-Reply-To: <20260721112133.70382-5-egbostina@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch converts the TPS65217 backlight binding to a comprehensive PMIC schema but fails to delete the existing `regulator/tps65217.txt` binding, resulting in duplicate bindings.
- [Medium] The binding adds interrupt controller capabilities but omits `interrupt-controller` and `#interrupt-cells` from the `required` list.
--
--- Patch [4]: [PATCH v3 4/4] dt-bindings: leds: backlight: Convert TPS65217 to DT schema ---
commit 280c44c9d977e107c7e28a27785e5c9c3dbde99e
Author: Eduard Bostina <egbostina@gmail.com>
dt-bindings: leds: backlight: Convert TPS65217 to DT schema
This commit converts the Texas Instruments TPS65217 backlight binding to
DT schema, adding child nodes for regulators, charger, and pwrbutton,
as well as documenting interrupt and shutdown controller properties.
> diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> new file mode 100644
> index 0000000000000..4d2f4dbd2d52e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> @@ -0,0 +1,170 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/ti,tps65217.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TPS65217 family of regulators
[Severity: Medium]
This schema defines a comprehensive PMIC with regulators and chargers
rather than just a backlight, but it is placed in the leds/backlight
directory. Should this be moved to a more central MFD or regulator schema
location?
Additionally, it appears the existing regulator binding documentation at
Documentation/devicetree/bindings/regulator/tps65217.txt was not deleted
in this patch, leaving duplicate bindings for the ti,tps65217 compatible
string. Should that file be removed as part of this conversion so schema
validation is not split and inconsistent?
[ ... ]
> + pwrbutton:
> + $ref: /schemas/input/ti,tps65217-pwrbutton.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
[Severity: Medium]
Because this binding allows the device to act as an interrupt controller,
do interrupt-controller and #interrupt-cells need to be included in this
required list?
The device tree binding guidelines indicate that when hardware provides
these capabilities, the corresponding properties must be required so
incomplete device tree nodes don't silently pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721112133.70382-1-egbostina@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: Rename the TPS65217 regulator nodes
From: sashiko-bot @ 2026-07-21 11:26 UTC (permalink / raw)
To: Eduard Bostina
Cc: devicetree, dmitry.torokhov, dri-devel, linux-leds, robh,
linux-input, conor+dt, lee
In-Reply-To: <20260721112133.70382-3-egbostina@gmail.com>
> The TPS65217 regulator nodes are named regulator@0 to regulator@6 and
> rely on the deprecated 'regulator-compatible' property to be matched
> against the driver, which looks for "dcdc1" to "ldo4".
>
> Documentation/devicetree/bindings/regulator/tps65217.txt states the
> regulators must be named dcdc[1-3] and ldo[1-4].
>
> Rename the nodes accordingly and drop 'regulator-compatible' along with
> the unit addresses it made necessary.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721112133.70382-1-egbostina@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: ti: am335x-guardian: Drop unused isink-en property
From: sashiko-bot @ 2026-07-21 11:24 UTC (permalink / raw)
To: Eduard Bostina
Cc: conor+dt, devicetree, dmitry.torokhov, dri-devel, lee, linux-leds,
robh, linux-input
In-Reply-To: <20260721112133.70382-2-egbostina@gmail.com>
> The 'isink-en' property is not documented and not read by any driver,
> so remove it from the TPS65217 backlight node.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721112133.70382-1-egbostina@gmail.com?part=1
^ permalink raw reply
* [PATCH v3 4/4] dt-bindings: leds: backlight: Convert TPS65217 to DT schema
From: Eduard Bostina @ 2026-07-21 11:21 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Mark Jackson,
Pavel Machek, Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260721112133.70382-1-egbostina@gmail.com>
Convert the Texas Instruments TPS65217 bindings to DT schema.
During the conversion, the following updates were made:
- Documented the 'regulators', 'charger' and 'pwrbutton' child nodes,
which are used by the boards but were missing from the old txt
binding.
- Documented the 'interrupts', 'interrupt-controller', '#interrupt-cells'
and 'ti,pmic-shutdown-controller' properties, which are used by the
am335x boards and read by the driver.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
.../bindings/leds/backlight/ti,tps65217.yaml | 170 ++++++++++++++++++
.../leds/backlight/tps65217-backlight.txt | 27 ---
2 files changed, 170 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
new file mode 100644
index 000000000000..4d2f4dbd2d52
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,tps65217.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TPS65217 family of regulators
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+description:
+ The TPS65217 chip contains a boost converter and current sinks which can be
+ used to drive LEDs for use as backlights.
+
+properties:
+ compatible:
+ const: ti,tps65217
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ ti,pmic-shutdown-controller:
+ type: boolean
+ description:
+ Set the PMIC to shutdown on PWR_EN toggle.
+
+ backlight:
+ type: object
+ additionalProperties: false
+ description:
+ Node for specifying WLED1 and WLED2 lines in TPS65217.
+
+ properties:
+ isel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ Selection bit. Valid values:
+ 1 - ISEL1 (low-level)
+ 2 - ISEL2 (high-level)
+
+ fdim:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [100, 200, 500, 1000]
+ description:
+ PWM dimming frequency in Hz.
+
+ default-brightness:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 100
+
+ required:
+ - isel
+ - fdim
+ - default-brightness
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description:
+ List of child nodes that specify the regulator initialization data.
+ Not all regulators for the given device need to be present.
+
+ patternProperties:
+ "^(dcdc[1-3]|ldo[1-4])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ charger:
+ $ref: /schemas/power/supply/tps65217-charger.yaml#
+ unevaluatedProperties: false
+
+ pwrbutton:
+ $ref: /schemas/input/ti,tps65217-pwrbutton.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@24 {
+ compatible = "ti,tps65217";
+ reg = <0x24>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,pmic-shutdown-controller;
+
+ backlight {
+ isel = <1>; /* 1 - ISET1, 2 ISET2 */
+ fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
+ default-brightness = <50>;
+ };
+
+ charger {
+ compatible = "ti,tps65217-charger";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
+ };
+
+ pwrbutton {
+ compatible = "ti,tps65217-pwrbutton";
+ interrupts = <2>;
+ };
+
+ regulators {
+ dcdc1 {
+ regulator-name = "vdds_dpr";
+ regulator-always-on;
+ };
+
+ dcdc2 {
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1351500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "vio,vrtc,vdds";
+ regulator-always-on;
+ };
+
+ ldo2 {
+ regulator-name = "vdd_3v3aux";
+ regulator-always-on;
+ };
+
+ ldo3 {
+ regulator-name = "vdd_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo4 {
+ regulator-name = "vdd_3v3a";
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
deleted file mode 100644
index 5fb9279ac287..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-TPS65217 family of regulators
-
-The TPS65217 chip contains a boost converter and current sinks which can be
-used to drive LEDs for use as backlights.
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
-- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
-- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
-- default-brightness: valid values: 0-100
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
- tps: tps@24 {
- reg = <0x24>;
- compatible = "ti,tps65217";
- backlight {
- isel = <1>; /* 1 - ISET1, 2 ISET2 */
- fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
- default-brightness = <50>;
- };
- };
-
--
2.43.0
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: input: Convert TI TPS65217 power button to DT schema
From: Eduard Bostina @ 2026-07-21 11:21 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Mark Jackson,
Pavel Machek, Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry,
Krzysztof Kozlowski
In-Reply-To: <20260721112133.70382-1-egbostina@gmail.com>
Convert the Texas Instruments TPS65217 and TPS65218 Power Button
bindings to DT schema.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/input/ti,tps65217-pwrbutton.yaml | 42 +++++++++++++++++++
.../bindings/input/tps65218-pwrbutton.txt | 30 -------------
2 files changed, 42 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
diff --git a/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
new file mode 100644
index 000000000000..3526d8b045fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,tps65217-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TPS65217 and TPS65218 Power Button
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+description:
+ This module is part of the TPS65217/TPS65218 PMIC. It provides a simple
+ power button event via an interrupt.
+
+properties:
+ compatible:
+ enum:
+ - ti,tps65217-pwrbutton
+ - ti,tps65218-pwrbutton
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-button {
+ compatible = "ti,tps65218-pwrbutton";
+ interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
deleted file mode 100644
index 8682ab6d4a50..000000000000
--- a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Texas Instruments TPS65217 and TPS65218 power button
-
-This module is part of the TPS65217/TPS65218. For more details about the whole
-TPS65217 chip see Documentation/devicetree/bindings/regulator/tps65217.txt.
-
-This driver provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
-
-Required properties:
-- interrupts: should be one of the following
- - <2>: For controllers compatible with tps65217
- - <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
-
-Examples:
-
-&tps {
- tps65217-pwrbutton {
- compatible = "ti,tps65217-pwrbutton";
- interrupts = <2>;
- };
-};
-
-&tps {
- power-button {
- compatible = "ti,tps65218-pwrbutton";
- interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
- };
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/4] ARM: dts: Rename the TPS65217 regulator nodes
From: Eduard Bostina @ 2026-07-21 11:21 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Mark Jackson,
Pavel Machek, Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260721112133.70382-1-egbostina@gmail.com>
The TPS65217 regulator nodes are named regulator@0 to regulator@6 and
rely on the deprecated 'regulator-compatible' property to be matched
against the driver, which looks for "dcdc1" to "ldo4".
Documentation/devicetree/bindings/regulator/tps65217.txt states the
regulators must be named dcdc[1-3] and ldo[1-4].
Rename the nodes accordingly and drop 'regulator-compatible' along with
the unit addresses it made necessary.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
.../boot/dts/ti/omap/am335x-bone-common.dtsi | 14 ++++-----
.../arm/boot/dts/ti/omap/am335x-chilisom.dtsi | 14 ++++-----
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 14 ++++-----
arch/arm/boot/dts/ti/omap/am335x-nano.dts | 14 ++++-----
.../dts/ti/omap/am335x-osd335x-common.dtsi | 14 ++++-----
arch/arm/boot/dts/ti/omap/am335x-pepper.dts | 14 ++++-----
arch/arm/boot/dts/ti/omap/am335x-shc.dts | 31 +++++--------------
arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 14 ++++-----
arch/arm/boot/dts/tps65217.dtsi | 31 +++++--------------
9 files changed, 63 insertions(+), 97 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi b/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
index 1d83fc116b66..e5ca2bd65736 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
@@ -337,12 +337,12 @@ pwrbutton {
};
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
regulator-name = "vdds_dpr";
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -351,7 +351,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -360,22 +360,22 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
regulator-name = "vio,vrtc,vdds";
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
regulator-name = "vdd_3v3aux";
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
regulator-name = "vdd_1v8";
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
regulator-name = "vdd_3v3a";
regulator-always-on;
};
diff --git a/arch/arm/boot/dts/ti/omap/am335x-chilisom.dtsi b/arch/arm/boot/dts/ti/omap/am335x-chilisom.dtsi
index bd43da6356b6..9ee6d6d4a9c1 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am335x-chilisom.dtsi
@@ -70,12 +70,12 @@ tps: tps@24 {
&tps {
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
regulator-name = "vdds_dpr";
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -84,7 +84,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -93,25 +93,25 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
regulator-name = "vio,vrtc,vdds";
regulator-boot-on;
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
regulator-name = "vdd_3v3aux";
regulator-boot-on;
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
regulator-name = "vdd_1v8";
regulator-boot-on;
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
regulator-name = "vdd_3v3d";
regulator-boot-on;
regulator-always-on;
diff --git a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
index d595e79d6b05..fecfe12e1349 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
@@ -323,12 +323,12 @@ backlight {
};
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
regulator-name = "vdds_dpr";
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -337,7 +337,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -346,24 +346,24 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
regulator-name = "vio,vrtc,vdds";
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
regulator-name = "vdd_3v3aux";
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
regulator-name = "vdd_1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
regulator-name = "vdd_3v3a";
regulator-always-on;
};
diff --git a/arch/arm/boot/dts/ti/omap/am335x-nano.dts b/arch/arm/boot/dts/ti/omap/am335x-nano.dts
index d51cdd6e1ab4..c1143f0a3356 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-nano.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-nano.dts
@@ -431,7 +431,7 @@ &usb0 {
&tps {
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
/* +1.5V voltage with ±4% tolerance */
regulator-min-microvolt = <1450000>;
regulator-max-microvolt = <1550000>;
@@ -439,7 +439,7 @@ dcdc1_reg: regulator@0 {
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.1V with ±4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <915000>;
@@ -448,7 +448,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with ±4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <915000>;
@@ -457,7 +457,7 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
/* +1.8V voltage with ±4% tolerance */
regulator-min-microvolt = <1750000>;
regulator-max-microvolt = <1870000>;
@@ -465,7 +465,7 @@ ldo1_reg: regulator@3 {
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
/* +3.3V voltage with ±4% tolerance */
regulator-min-microvolt = <3175000>;
regulator-max-microvolt = <3430000>;
@@ -473,7 +473,7 @@ ldo2_reg: regulator@4 {
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
/* +1.8V voltage with ±4% tolerance */
regulator-min-microvolt = <1750000>;
regulator-max-microvolt = <1870000>;
@@ -481,7 +481,7 @@ ldo3_reg: regulator@5 {
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
/* +3.3V voltage with ±4% tolerance */
regulator-min-microvolt = <3175000>;
regulator-max-microvolt = <3430000>;
diff --git a/arch/arm/boot/dts/ti/omap/am335x-osd335x-common.dtsi b/arch/arm/boot/dts/ti/omap/am335x-osd335x-common.dtsi
index 93a3af83feac..021cf5cbbb96 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-osd335x-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am335x-osd335x-common.dtsi
@@ -69,12 +69,12 @@ pwrbutton {
};
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
regulator-name = "vdds_dpr";
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -83,7 +83,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -92,24 +92,24 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
regulator-name = "vio,vrtc,vdds";
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
regulator-name = "vdd_3v3aux";
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
regulator-name = "vdd_1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
regulator-name = "vdd_3v3a";
regulator-always-on;
};
diff --git a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
index 10d54e0ad15a..363638e74719 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
@@ -433,12 +433,12 @@ backlight {
};
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
/* VDD_1V8 system supply */
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_CORE voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -447,7 +447,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_MPU voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -456,26 +456,26 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
/* VRTC 1.8V always-on supply */
regulator-name = "vrtc,vdds";
regulator-always-on;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
/* 3.3V rail */
regulator-name = "vdd_3v3aux";
regulator-always-on;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
/* VDD_3V3A 3.3V rail */
regulator-name = "vdd_3v3a";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
/* VDD_3V3B 3.3V rail */
regulator-name = "vdd_3v3b";
regulator-always-on;
diff --git a/arch/arm/boot/dts/ti/omap/am335x-shc.dts b/arch/arm/boot/dts/ti/omap/am335x-shc.dts
index 597482822608..473058584691 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-shc.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-shc.dts
@@ -254,26 +254,19 @@ &tps {
ti,pmic-shutdown-controller;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- dcdc1_reg: regulator@0 {
- reg = <0>;
+ dcdc1_reg: dcdc1 {
regulator-name = "vdds_dpr";
- regulator-compatible = "dcdc1";
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1450000>;
regulator-boot-on;
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
- reg = <1>;
+ dcdc2_reg: dcdc2 {
/*
* VDD_MPU voltage limits 0.95V - 1.26V with
* +/-4% tolerance
*/
- regulator-compatible = "dcdc2";
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <1375000>;
@@ -282,51 +275,41 @@ dcdc2_reg: regulator@1 {
regulator-ramp-delay = <70000>;
};
- dcdc3_reg: regulator@2 {
- reg = <2>;
+ dcdc3_reg: dcdc3 {
/*
* VDD_CORE voltage limits 0.95V - 1.1V with
* +/-4% tolerance
*/
regulator-name = "vdd_core";
- regulator-compatible = "dcdc3";
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <1125000>;
regulator-boot-on;
regulator-always-on;
};
- ldo1_reg: regulator@3 {
- reg = <3>;
+ ldo1_reg: ldo1 {
regulator-name = "vio,vrtc,vdds";
- regulator-compatible = "ldo1";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo2_reg: regulator@4 {
- reg = <4>;
+ ldo2_reg: ldo2 {
regulator-name = "vdd_3v3aux";
- regulator-compatible = "ldo2";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
- ldo3_reg: regulator@5 {
- reg = <5>;
+ ldo3_reg: ldo3 {
regulator-name = "vdd_1v8";
- regulator-compatible = "ldo3";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo4_reg: regulator@6 {
- reg = <6>;
+ ldo4_reg: ldo4 {
regulator-name = "vdd_3v3a";
- regulator-compatible = "ldo4";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
diff --git a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
index c5259eb7d21c..0cc9289c752b 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
@@ -607,14 +607,14 @@ &tps {
interrupts = <7>; /* NNMI */
regulators {
- dcdc1_reg: regulator@0 {
+ dcdc1_reg: dcdc1 {
/* VDDS_DDR */
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
};
- dcdc2_reg: regulator@1 {
+ dcdc2_reg: dcdc2 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
@@ -623,7 +623,7 @@ dcdc2_reg: regulator@1 {
regulator-always-on;
};
- dcdc3_reg: regulator@2 {
+ dcdc3_reg: dcdc3 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
regulator-name = "vdd_core";
regulator-min-microvolt = <925000>;
@@ -632,28 +632,28 @@ dcdc3_reg: regulator@2 {
regulator-always-on;
};
- ldo1_reg: regulator@3 {
+ ldo1_reg: ldo1 {
/* VRTC / VIO / VDDS*/
regulator-always-on;
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- ldo2_reg: regulator@4 {
+ ldo2_reg: ldo2 {
/* VDD_3V3AUX */
regulator-always-on;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
- ldo3_reg: regulator@5 {
+ ldo3_reg: ldo3 {
/* VDD_1V8 */
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
- ldo4_reg: regulator@6 {
+ ldo4_reg: ldo4 {
/* VDD_3V3A */
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 0d463de5650f..e7db105b3657 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -27,42 +27,25 @@ pwrbutton {
};
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- dcdc1_reg: regulator@0 {
- reg = <0>;
- regulator-compatible = "dcdc1";
+ dcdc1_reg: dcdc1 {
};
- dcdc2_reg: regulator@1 {
- reg = <1>;
- regulator-compatible = "dcdc2";
+ dcdc2_reg: dcdc2 {
};
- dcdc3_reg: regulator@2 {
- reg = <2>;
- regulator-compatible = "dcdc3";
+ dcdc3_reg: dcdc3 {
};
- ldo1_reg: regulator@3 {
- reg = <3>;
- regulator-compatible = "ldo1";
+ ldo1_reg: ldo1 {
};
- ldo2_reg: regulator@4 {
- reg = <4>;
- regulator-compatible = "ldo2";
+ ldo2_reg: ldo2 {
};
- ldo3_reg: regulator@5 {
- reg = <5>;
- regulator-compatible = "ldo3";
+ ldo3_reg: ldo3 {
};
- ldo4_reg: regulator@6 {
- reg = <6>;
- regulator-compatible = "ldo4";
+ ldo4_reg: ldo4 {
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/4] ARM: dts: ti: am335x-guardian: Drop unused isink-en property
From: Eduard Bostina @ 2026-07-21 11:21 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Mark Jackson,
Pavel Machek, Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry,
Krzysztof Kozlowski
In-Reply-To: <20260721112133.70382-1-egbostina@gmail.com>
The 'isink-en' property is not documented and not read by any driver,
so remove it from the TPS65217 backlight node.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
index 6ce3a2d029ee..d595e79d6b05 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
@@ -320,9 +320,6 @@ backlight {
isel = <1>; /* 1 - ISET1, 2 ISET2 */
fdim = <500>; /* TPS65217_BL_FDIM_500HZ */
default-brightness = <50>;
- /* 1(on) - enable current sink, while initialization */
- /* 0(off) - disable current sink, while initialization */
- isink-en = <1>;
};
regulators {
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/4] dt-bindings: Convert TI TPS65217 to DT schema
From: Eduard Bostina @ 2026-07-21 11:21 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Mark Jackson,
Pavel Machek, Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
This series converts the Texas Instruments TPS65217 PMIC bindings to DT
schema.
Changes in v3:
- Added 'unevaluatedProperties' to the 'charger' and 'pwrbutton' nodes.
- Renamed the example node to 'pmic@24' and added the rest of the
properties and nodes to it.
- Dropped 'regulator-compatible' from the schema. The property is
deprecated, so the regulator nodes are now named after the strings the
driver matches on and the DTS is updated accordingly.
Link to v2:
https://lore.kernel.org/all/20260718215632.3295049-1-egbostina@gmail.com/
Eduard Bostina (4):
ARM: dts: ti: am335x-guardian: Drop unused isink-en property
ARM: dts: Rename the TPS65217 regulator nodes
dt-bindings: input: Convert TI TPS65217 power button to DT schema
dt-bindings: leds: backlight: Convert TPS65217 to DT schema
.../bindings/input/ti,tps65217-pwrbutton.yaml | 42 +++++
.../bindings/input/tps65218-pwrbutton.txt | 30 ----
.../bindings/leds/backlight/ti,tps65217.yaml | 170 ++++++++++++++++++
.../leds/backlight/tps65217-backlight.txt | 27 ---
.../boot/dts/ti/omap/am335x-bone-common.dtsi | 14 +-
.../arm/boot/dts/ti/omap/am335x-chilisom.dtsi | 14 +-
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 17 +-
arch/arm/boot/dts/ti/omap/am335x-nano.dts | 14 +-
.../dts/ti/omap/am335x-osd335x-common.dtsi | 14 +-
arch/arm/boot/dts/ti/omap/am335x-pepper.dts | 14 +-
arch/arm/boot/dts/ti/omap/am335x-shc.dts | 31 +---
arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 14 +-
arch/arm/boot/dts/tps65217.dtsi | 31 +---
13 files changed, 275 insertions(+), 157 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
--
2.43.0
^ permalink raw reply
* [BUG] HID/input - Input misses when rapidly pressing consumer control keys on Logitech Media Keyboard K200
From: Barath Kannan @ 2026-07-21 11:19 UTC (permalink / raw)
To: linux-input; +Cc: Barath Kannan, linux-kernel, dmitry.torokhov, bentiss, jikos
Description:
When consumer control buttons such as volume up/down, pause/play etc
of the Logitech Media Keyboard K200 are rapidly pressed, most of the
inputs don't register properly.
Environment used:
- linux kernel 7.20.rc-4-dirty
- qemu-system-x86_64 version 11.0.50. The arguments used were(This
passes the keyboard through to qemu):
-kernel "$BZIMAGE"
-machine "q35"
-cpu max
-vga std
-display gtk
-device qemu-xhci,id=xhci
-usb -device usb-host,bus=xhci.0,vendorid=0x046d,productid=0xc31d
-initrd "$INITRAMFS_CPIO"
-m 1G
-smp 4
-no-reboot
-virtfs "local,id=lkmpg,path=$PROJECT_ROOT,security_model=none,mount_tag=lkmpg"
-append "nokaslr"
(this is a slightly modified version of the qemu environment specified
at the start of the Linux Kernel Module Programming Guide)
- Qemu itself runs in a distrobox container running an Ubuntu 26.04 LTS
- My host is Fedora Kinoite 43 with kernel version
6.17.12-300.fc43.x86_64(where I first noticed the issue)
- The keyboard's vendorId : productId -> 046d:c31d
Steps for reproduction:
- Run hexdump -v on the appropriate /dev/input/event entry
- Press the volume up button on the keyboard, slowly
- Given enough time between key presses all presses cause a change in
output with corresponding press/release entries
- Rapidly press the volume up button on the keyboard
- Notice that output either:
1. Doesn't change at all.
2. or after some time, it sort of gets flushed and you see a bunch
of entries output all together.
Expected Behaviour:
Each button press/release should correspond to an event.
Some Notes and Logs:
- I concluded that this isn't likely to be a hardware issue as the
expected behaviour was shown on Windows 11.
- I noticed this issue first in kernel 6.12.12, and later I tested it
in 7.20.rc-4-dirty and discovered that the issue still persists.
- I hacked on the kernel in an attempt to figure out the problem
myself, adding pr_info statements dumping state in evdev_read,
input_event_dispose and hid_irq_in and saw the following(linked is my
raw dmesg output without my changes, output grepping my pr_info
statements and my .config. I have delimited the 3 sections by using a
bunch of '=' characters):
https://pastebin.com/59FsWsvq
It seems to me that there are a lot of unnecessary SYN_REPORT calls
with a disposition that triggers a flush of the device's inputs such
as:
[ 110.907511] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[ 110.907543] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10
[ 111.035339] hid_irq_in device: 1133:49949 status: 0
[ 111.035412] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[ 111.035431] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10
...but I couldn't get any further than that.
- Also, I noticed that the polling rate for consumer/system control is
set to 255 ms whereas the main keyboard is set to 10 ms(I got this
from the bInterval value while debugging).
Would appreciate guidance on this.
^ permalink raw reply
* Bug: HID/input - Input misses when rapidly pressing consumer control keys on Logitech Media Keyboard K200
From: Barath Rk @ 2026-07-21 10:42 UTC (permalink / raw)
To: linux-input, linux-kernel; +Cc: dmitry.torokhov, bentiss, jikos
Description:
When consumer control buttons such as volume up/down, pause/play etc
of the Logitech Media Keyboard K200 are rapidly pressed, most of the
inputs don't register properly.
Environment used:
- linux kernel 7.20.rc-4-dirty
- qemu-system-x86_64 version 11.0.50. The arguments used were(This
passes the keyboard through to qemu):
-kernel "$BZIMAGE"
-machine "q35"
-cpu max
-vga std
-display gtk
-device qemu-xhci,id=xhci
-usb -device usb-host,bus=xhci.0,vendorid=0x046d,productid=0xc31d
-initrd "$INITRAMFS_CPIO"
-m 1G
-smp 4
-no-reboot
-virtfs "local,id=lkmpg,path=$PROJECT_ROOT,security_model=none,mount_tag=lkmpg"
-append "nokaslr"
(this is a slightly modified version of the qemu environment specified
at the start of the Linux Kernel Module Programming Guide)
- Qemu itself runs in a distrobox container running an Ubuntu 26.04 LTS
- My host is Fedora Kinoite 43 with kernel version
6.17.12-300.fc43.x86_64(where I first noticed the issue)
- The keyboard's vendorId : productId -> 046d:c31d
Steps for reproduction:
- Run hexdump -v on the appropriate /dev/input/event entry
- Press the volume up button on the keyboard, slowly
- Given enough time between key presses all presses cause a change in
output with corresponding press/release entries
- Rapidly press the volume up button on the keyboard
- Notice that output either:
1. Doesn't change at all.
2. or after some time, it sort of gets flushed and you see a bunch
of entries output all together.
Expected Behaviour:
Each button press/release should correspond to an event.
Some Notes and Logs:
- I concluded that this isn't likely to be a hardware issue as the
expected behaviour was shown on Windows 11.
- I noticed this issue first in kernel 6.12.12, and later I tested it
in 7.20.rc-4-dirty and discovered that the issue still persists.
- I hacked on the kernel in an attempt to figure out the problem
myself, adding pr_info statements dumping state in evdev_read,
input_event_dispose and hid_irq_in and saw the following(linked is my
raw dmesg output without my changes, output grepping my pr_info
statements and my .config. I have delimited the 3 sections by using a
bunch of '=' characters):
https://pastebin.com/59FsWsvq
It seems to me that there are a lot of unnecessary SYN_REPORT calls
with a disposition that triggers a flush of the device's inputs such
as:
[ 110.907511] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[ 110.907543] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10
[ 111.035339] hid_irq_in device: 1133:49949 status: 0
[ 111.035412] input: input_event_dispose for device Logitech USB
Keyboard Consumer Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 11
[ 111.035431] input: input_event_dispose for device Logitech USB
Keyboard System Control of type: 0 code: 0 value: 0 dev->num_vals: 1
dev->max_vals: 10
...but I couldn't get any further than that.
- Also, I noticed that the polling rate for consumer/system control is
set to 255 ms whereas the main keyboard is set to 10 ms(I got this
from the bInterval value while debugging).
Would appreciate guidance on this.
^ permalink raw reply
* Re: [PATCH v3 7/9] platform/chrome: of_hw_prober: Add delay for hana trackpads
From: Andy Shevchenko @ 2026-07-21 10:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti,
linux-mediatek, devicetree, linux-arm-kernel, chrome-platform,
linux-input, linux-i2c, linux-kernel
In-Reply-To: <20260721075226.2347933-8-wenst@chromium.org>
On Tue, Jul 21, 2026 at 03:52:21PM +0800, Chen-Yu Tsai wrote:
> Up until now, the MT8173 elm/hana device tree has set the dedicated
> regulator supplying the trackpad as always-on, simply because the Elan
> driver was missing proper delays. As a result the delay for the
> Synaptics trackpad was also omitted, as it was not strictly required
> under such a model and delayed the availability of the trackpad to the
> user.
>
> The Elan driver recently gained proper delays after power-up, with
> adaptive skipping of the delay if the regulator was originally
> on. The I2C HID driver and I2C OF component prober library gained
> similar adaptive delay skipping. The device tree will be fixed to have
> the regulator not be always on, and proper post-power-on delay time
> added to the I2C HID device.
>
> Also add the post-power-on delay to the ChromeOS OF component prober,
> so that if the regulator is off at the time of probing, the prober knows
> to wait for the hardware to initialize.
...
> +++ b/drivers/platform/chrome/chromeos_of_hw_prober.c
> /*
> * ELAN trackpad needs 2 ms for H/W init and 100 ms for F/W init.
> * Synaptics trackpad needs 100 ms.
> - * However, the regulator is set to "always-on", presumably to
> - * avoid this delay. The ELAN driver is also missing delays.
> */
> - .post_power_on_delay_ms = 0,
> + .post_power_on_delay_ms = 110,
This and the other delay in the previous patches are all HW-related. What if
another touchpad gets connected? I mean that the delays for the certain HW
should not affect other possible devices connected to the platform.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 6/9] i2c: of-prober: Defer regulator_disable() on successful probe in simple helper
From: Andy Shevchenko @ 2026-07-21 10:24 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti,
linux-mediatek, devicetree, linux-arm-kernel, chrome-platform,
linux-input, linux-i2c, linux-kernel
In-Reply-To: <20260721075226.2347933-7-wenst@chromium.org>
On Tue, Jul 21, 2026 at 03:52:20PM +0800, Chen-Yu Tsai wrote:
> When a I2C component is found, it's device node is immediately enabled.
> This triggers device creation and driver binding. The prober will hold
> the regulator enable reference across this part. If the driver probes
> synchronously, then it happens within this window. On the other hand,
> if the driver probes asynchronously, there is high chance that it
> happens after the prober's cleanup function was called, in which case
> the regulator would have been disabled when the driver's probe function
> is called. This would then require the driver to wait 100 ms for the
> hardware to reinitialize, even if the probe function was just a split
> second late and the regulator was disabled a few milliseconds ago.
>
> Recently, some of the drivers for the component that are targeted by the
> I2C OF component prober gained the ability to skip waiting for hardware
> initialization if the regulator was left enabled. This happens when the
> PMIC has them on by default, or if the component prober left them on
> after probing the component.
>
> Wait a bit of time before dropping the enable refcount on our end so
> that the actual driver has the opportunity to catch and increase the
> refcount on their end. The 100 ms delay was arbitrarily chosen.
...
> + /*
> + * Wait a bit of time for async drivers to probe and increase the
> + * regulator enable count. This allows the drivers to check and
> + * skip waiting for re-initialization.
> + */
> + if (defer_disable) {
> + dev_dbg(dev, "Deferring regulator disable\n");
> + msleep(100);
How was this value chosen?
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 5/6] mfd: motorola-cpcap: diverge configuration per-board
From: sashiko-bot @ 2026-07-21 10:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-leds, lee, conor+dt, devicetree, robh, dmitry.torokhov,
linux-input
In-Reply-To: <20260721095654.429346-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Removal of the 'st,6556002' compatible string breaks device tree backward compatibility.
- [Medium] Casting const void * to enum triggers a -Wpointer-to-int-cast warning on 64-bit architectures.
- [Low] The commit message description violates MFD subsystem capitalization rules.
--
--- Patch [5]: [PATCH v7 5/6] mfd: motorola-cpcap: diverge configuration per-board ---
commit f5cc3529b5d7a3c2c11043bd5543be65ebce6656
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: diverge configuration per-board
This commit modifies the CPCAP driver to support board-specific subdevice
configurations. It splits the MFD cells into common, default, and
mapphone-specific arrays. It also removes the legacy st,6556002 compatible
string.
> mfd: motorola-cpcap: diverge configuration per-board
[Severity: Low]
This isn't a bug, but the MFD subsystem guidelines request that the
description after the subsystem prefix be capitalized. Should "diverge" be
"Diverge"?
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -194,20 +196,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", },
> - {},
> -};
[Severity: High]
Does removing the "st,6556002" compatible string break backwards
compatibility for systems booting with older device tree blobs?
Device tree bindings are generally considered a stable ABI, so newer kernels
are expected to still probe devices using older DTBs.
[ ... ]
> 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);
[Severity: Medium]
Can this direct cast from a pointer to an enum cause a -Wpointer-to-int-cast
build warning on 64-bit architectures?
spi_get_device_match_data() returns a const void *, which is 64-bit on
platforms like arm64. Casting it directly to a 32-bit enum might drop
the upper 32 bits. Should this be cast to a uintptr_t first?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721095654.429346-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v3 2/9] Input: elan_i2c - sort include statements
From: Andy Shevchenko @ 2026-07-21 10:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Benson Leung,
Tzung-Bi Shih, Dmitry Torokhov, Jiri Kosina, Andi Shyti,
linux-mediatek, devicetree, linux-arm-kernel, chrome-platform,
linux-input, linux-i2c, linux-kernel
In-Reply-To: <20260721075226.2347933-3-wenst@chromium.org>
On Tue, Jul 21, 2026 at 03:52:16PM +0800, Chen-Yu Tsai wrote:
> Sort the include statements before adding new ones in the next change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 6/6] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: sashiko-bot @ 2026-07-21 10:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: lee, conor+dt, devicetree, robh, linux-input, dmitry.torokhov,
linux-leds
In-Reply-To: <20260721095654.429346-7-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The commit message description is not capitalized, violating MFD subsystem guidelines.
--
--- Patch [6]: [PATCH v7 6/6] mfd: motorola-cpcap: add support for Mot CPCAP composition ---
commit 8d174ab85721459a22732636e016f27b79a8d93b
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: add support for Mot CPCAP composition
This commit adds an MFD subdevice composition used in Tegra20 based Mot
boards (Motorola Atrix 4G and Droid X2).
> mfd: motorola-cpcap: add support for Mot CPCAP composition
[Severity: Low]
This isn't a bug, but should the description after the subsystem prefix be
capitalized? The MFD subsystem guidelines mandate capitalizing the description
after the prefix (e.g., "mfd: motorola-cpcap: Add support...").
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721095654.429346-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v7 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-07-21 10:16 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, conor+dt, devicetree, linux-leds, lee, robh,
dmitry.torokhov
In-Reply-To: <20260721095654.429346-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The new compatible strings are defined as standalone enums without a generic fallback, causing drivers to fail to probe.
- [Low] The commit message description starts with a lowercase letter, violating MFD subsystem guidelines.
--
--- Patch [4]: [PATCH v7 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP ---
commit d9f93935d00aa3510052461fef588d4ce3014eed
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
[Severity: Low]
This isn't a bug, but should the description part of the commit message be
capitalized? The MFD subsystem guidelines typically expect a capitalized
description after the subsystem prefix.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> index 76705ea56805a..da7abe2ec9126 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
[Severity: Medium]
Since these new compatible strings are defined as standalone enums without a
generic fallback, will the core driver fail to probe these devices?
Looking at drivers/mfd/motorola-cpcap.c, cpcap_of_match[] lacks a match for
these specific strings:
static const struct of_device_id cpcap_of_match[] = {
{ .compatible = "motorola,cpcap", },
{ .compatible = "st,6556002", },
{},
};
Are there plans to update the driver's match table to recognize these new
standalone compatibles, or could a generic fallback like "motorola,cpcap" be
added to the bindings?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721095654.429346-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v7 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-07-21 10:15 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, robh, conor+dt, devicetree, linux-leds,
dmitry.torokhov, lee
In-Reply-To: <20260721095654.429346-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Medium] YAML schema omits `#address-cells` and `#size-cells` properties for the root node, causing validation failures for existing device trees.
- [Medium] Schema strictly expects the power button node to be named `key-power`, breaking validation for the legacy `button` node.
- [Medium] The `audio-codec` schema expects a `ports` wrapper, breaking validation for legacy direct `port@0` definitions.
- [Low] The `spi-cs-high` property was dropped from the schema's `required` list.
- [Low] Commit message description is not capitalized, violating MFD subsystem guidelines.
--
--- Patch [3]: [PATCH v7 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema ---
commit 4de37a9bd5e5179740a9f015e1900ab235da93ae
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> dt-bindings: mfd: motorola-cpcap: convert to DT schema
[Severity: Low]
This isn't a bug, but the MFD subsystem guidelines require the description
after the subsystem prefix to be capitalized. Should "convert" be "Convert"?
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,403 @@
> +# 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
[Severity: Medium]
Does omitting #address-cells and #size-cells from the properties block
break validation for existing device trees?
Because this schema sets additionalProperties: false, running make dtbs_check
against existing in-tree device trees (like
arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi, which uses
#address-cells = <1> and #size-cells = <0> on the pmic@0 node) will falsely
report validation errors.
[ ... ]
> + 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:
[Severity: Medium]
Will this strict ports wrapper requirement cause validation failures for
legacy device trees?
Existing device trees place port@0 directly inside the audio-codec node:
arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi:
cpcap_audio: audio-codec {
...
port@0 {
cpcap_audio_codec0: endpoint { ... };
};
};
With additionalProperties: false set on the audio-codec node, dtbs_check
will flag these direct ports as illegal properties.
[ ... ]
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
[Severity: Medium]
Does hardcoding the node name as key-power break validation for the legacy
button node?
Existing device trees use the button node name:
arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi:
power_button: button {
compatible = "motorola,cpcap-pwrbutton";
...
};
Since this schema enforces the exact name key-power, make dtbs_check
will flag the existing button node as an invalid property.
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
[Severity: Low]
Is it intentional to drop spi-cs-high from this list?
The legacy text binding explicitly documented spi-cs-high as a required
property, which reflects the hardware's active-high chip select requirement.
Omitting it here relaxes the constraint and might allow inaccurate device trees
to pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721095654.429346-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v7 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: sashiko-bot @ 2026-07-21 10:08 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, dmitry.torokhov, devicetree, lee, robh, conor+dt,
linux-leds
In-Reply-To: <20260721095654.429346-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The conversion to YAML format creates broken documentation cross-references between the child power button binding and the parent MFD binding.
--
--- Patch [2]: [PATCH v7 2/6] dt-bindings: input: cpcap-pwrbutton: convert to DT schema ---
commit 04f32d0760614b206c7745dbb0c714f9b7720ee6
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: input: cpcap-pwrbutton: convert to DT schema
This commit converts the device tree bindings for the Motorola CPCAP PMIC
power button from plain text to YAML format.
> 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 0000000000000..77a3e5a47d1ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> @@ -0,0 +1,32 @@
[ ... ]
> +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
[Severity: Low]
Are we referencing a file that doesn't exist yet? Since the parent MFD
binding hasn't been converted to YAML yet, the referenced file
motorola,cpcap.yaml doesn't seem to be in the tree.
Additionally, should the parent MFD binding
(Documentation/devicetree/bindings/mfd/motorola-cpcap.txt) be updated in
this patch? It appears it still explicitly lists cpcap-pwrbutton.txt in its
"Optional subnodes:" section, which is being deleted here.
> + power key is represented as a sub-node of the PMIC node on the device
> + tree.
> +
> +properties:
> + compatible:
> + const: motorola,cpcap-pwrbutton
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721095654.429346-1-clamor95@gmail.com?part=2
^ 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