* Re: [PATCH 1/2] HID: input: map HID_GD_Z to ABS_DISTANCE for stylus/pen
From: Jiri Kosina @ 2025-08-12 12:35 UTC (permalink / raw)
To: Ping Cheng; +Cc: linux-input, bentiss, Dmitry.Torokhov, stable, Ping Cheng
In-Reply-To: <20250710212859.7892-1-ping.cheng@wacom.com>
Both applied to hid.git#for-6.18/core, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: lg-g15 - Add support for Logitech G13.
From: Markus Elfring @ 2025-08-12 11:51 UTC (permalink / raw)
To: Leo L. Schwab, linux-input
Cc: LKML, Benjamin Tissoires, Hans de Goede, Jiri Kosina, Kate Hsuan
In-Reply-To: <20250812065327.515098-2-ewhac@ewhac.org>
…
> +++ b/drivers/hid/hid-ids.h
…
> +static int lg_g13_event(struct lg_g15_data *g15, u8 const *data)
> +{
…
> +#ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED
…
> + if (hw_brightness_changed) {
> + led_classdev_notify_brightness_hw_changed(
> + &g15->leds[0].cdev,
> + TEST_BIT(rep->keybits, 23) ? LED_FULL : LED_OFF);
> + }
> +#endif
…
> +static void lg_g13_init_input_dev(struct hid_device *hdev,
> + struct input_dev *input, const char *name,
> + struct input_dev *input_js, const char *name_js)
> +{
…
> + for (int i = 0; i < ARRAY_SIZE(g13_keys_for_bits); ++i) {
> + if (g13_keys_for_bits[i]) {
> + input_set_capability(input, EV_KEY, g13_keys_for_bits[i]);
> + }
> + }
…
> + for (int i = 0; i < ARRAY_SIZE(g13_keys_for_bits_js); ++i) {
> + if (g13_keys_for_bits_js[i]) {
> + input_set_capability(input_js, EV_KEY, g13_keys_for_bits_js[i]);
> + }
> + }
…
May curly brackets be omitted at selected source code places?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.17-rc1#n197
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2] HID: lg-g15 - Add support for Logitech G13.
From: Markus Elfring @ 2025-08-12 11:24 UTC (permalink / raw)
To: Leo L. Schwab, linux-input
Cc: LKML, Benjamin Tissoires, Hans de Goede, Jiri Kosina, Kate Hsuan
In-Reply-To: <20250812065327.515098-2-ewhac@ewhac.org>
…
> Supports input event generation for all keys and the thumbstick, and
> exposes all LEDs.
See also once more:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17-rc1#n94
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] HID: lg-g15 - Add support for Logitech G13.
From: Leo L. Schwab @ 2025-08-12 6:51 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-input, LKML, Benjamin Tissoires, Hans de Goede, Jiri Kosina,
Kate Hsuan, oe-kbuild-all
In-Reply-To: <92a3486e-f101-4ca4-a611-a5c1c6afa6ca@web.de>
On Mon, Aug 11, 2025 at 07:00:24PM +0200, Markus Elfring wrote:
> See also once more:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#n94
>
On Mon, Aug 11, 2025 at 07:10:46PM +0200, Markus Elfring wrote:
> Under which circumstances would you become interested to apply a statement
> like “guard(mutex)(&g15->mutex);”?
> https://elixir.bootlin.com/linux/v6.16/source/include/linux/mutex.h#L225
>
On Tue, Aug 12, 2025 at 08:00:09AM +0800, kernel test robot wrote:
> kernel test robot noticed the following build errors:
> [ ... ]
> drivers/hid/hid-lg-g15.c: In function 'lg_g13_event':
> >> drivers/hid/hid-lg-g15.c:703:68: error: 'struct led_classdev' has no member named 'brightness_hw_changed'
> 703 | (!!TEST_BIT(rep->keybits, 23)) ^ (g15->leds[0].cdev.brightness_hw_changed > 0);
> | ^
>
Thank you. Updated patch forthcoming which will hopefully address
these concerns.
Schwab
^ permalink raw reply
* [PATCH v2] HID: lg-g15 - Add support for Logitech G13.
From: Leo L. Schwab @ 2025-08-12 6:53 UTC (permalink / raw)
To: Hans de Goede
Cc: Kate Hsuan, Leo L. Schwab, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
The Logitech G13 is a gaming keypad with general-purpose macro keys,
four LED-backlit macro preset keys, five "menu" keys, backlight toggle
key, an analog thumbstick, RGB LED backlight, and a monochrome LCD
display.
Supports input event generation for all keys and the thumbstick, and
exposes all LEDs.
Signed-off-by: Leo L. Schwab <ewhac@ewhac.org>
---
Changes in v2:
- Add `#ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED` bracket around new
code segment dependent on that feature (fixes test robot build
error).
- Use `guard(mutex)` construct in new code (existing code left
unmodified).
- Commit message revised.
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-lg-g15.c | 440 +++++++++++++++++++++++++++++++++++++--
2 files changed, 420 insertions(+), 21 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 33cc5820f2be..7ed1e402b80a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -870,6 +870,7 @@
#define USB_DEVICE_ID_LOGITECH_DUAL_ACTION 0xc216
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2 0xc218
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2_2 0xc219
+#define USB_DEVICE_ID_LOGITECH_G13 0xc21c
#define USB_DEVICE_ID_LOGITECH_G15_LCD 0xc222
#define USB_DEVICE_ID_LOGITECH_G11 0xc225
#define USB_DEVICE_ID_LOGITECH_G15_V2_LCD 0xc227
diff --git a/drivers/hid/hid-lg-g15.c b/drivers/hid/hid-lg-g15.c
index f8605656257b..1749d0b43967 100644
--- a/drivers/hid/hid-lg-g15.c
+++ b/drivers/hid/hid-lg-g15.c
@@ -26,7 +26,11 @@
#define LG_G510_FEATURE_BACKLIGHT_RGB 0x05
#define LG_G510_FEATURE_POWER_ON_RGB 0x06
+#define LG_G13_FEATURE_M_KEYS_LEDS 0x05
+#define LG_G13_FEATURE_BACKLIGHT_RGB 0x07
+
enum lg_g15_model {
+ LG_G13,
LG_G15,
LG_G15_V2,
LG_G510,
@@ -45,6 +49,12 @@ enum lg_g15_led_type {
LG_G15_LED_MAX
};
+struct g13_input_report {
+ u8 report_id; // 1
+ u8 joy_x, joy_y;
+ u8 keybits[5];
+};
+
struct lg_g15_led {
union {
struct led_classdev cdev;
@@ -63,12 +73,174 @@ struct lg_g15_data {
struct mutex mutex;
struct work_struct work;
struct input_dev *input;
+ struct input_dev *input_js; // joystick device for G13
struct hid_device *hdev;
enum lg_g15_model model;
struct lg_g15_led leds[LG_G15_LED_MAX];
bool game_mode_enabled;
};
+/********* G13 LED functions ***********/
+/*
+ * G13 retains no state across power cycles, and always powers up with the backlight on,
+ * color #5AFF6E, all macro key LEDs off.
+ */
+static int lg_g13_get_leds_state(struct lg_g15_data *g15)
+{
+ u8 * const tbuf = g15->transfer_buf;
+ int ret, high;
+
+ /* RGB backlight. */
+ ret = hid_hw_raw_request(g15->hdev, LG_G13_FEATURE_BACKLIGHT_RGB,
+ tbuf, 5,
+ HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
+ if (ret != 5) {
+ hid_err(g15->hdev, "Error getting backlight brightness: %d\n", ret);
+ return (ret < 0) ? ret : -EIO;
+ }
+
+ /* Normalize RGB intensities against highest component. */
+ high = max3(tbuf[1], tbuf[2], tbuf[3]);
+ if (high) {
+ g15->leds[LG_G15_KBD_BRIGHTNESS].red =
+ DIV_ROUND_CLOSEST(tbuf[1] * 255, high);
+ g15->leds[LG_G15_KBD_BRIGHTNESS].green =
+ DIV_ROUND_CLOSEST(tbuf[2] * 255, high);
+ g15->leds[LG_G15_KBD_BRIGHTNESS].blue =
+ DIV_ROUND_CLOSEST(tbuf[3] * 255, high);
+ g15->leds[LG_G15_KBD_BRIGHTNESS].brightness = high;
+ } else {
+ g15->leds[LG_G15_KBD_BRIGHTNESS].red = 255;
+ g15->leds[LG_G15_KBD_BRIGHTNESS].green = 255;
+ g15->leds[LG_G15_KBD_BRIGHTNESS].blue = 255;
+ g15->leds[LG_G15_KBD_BRIGHTNESS].brightness = 0;
+ }
+
+ /* Macro LEDs. */
+ ret = hid_hw_raw_request(g15->hdev, LG_G13_FEATURE_M_KEYS_LEDS,
+ tbuf, 5,
+ HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
+ if (ret != 5) {
+ hid_err(g15->hdev, "Error getting macro LED brightness: %d\n", ret);
+ return (ret < 0) ? ret : -EIO;
+ }
+
+ for (int i = LG_G15_MACRO_PRESET1; i < LG_G15_LED_MAX; ++i)
+ g15->leds[i].brightness = tbuf[1] & (1 << (i - LG_G15_MACRO_PRESET1));
+
+ return 0;
+}
+
+/* Must be called with g15->mutex locked */
+static int lg_g13_kbd_led_write(struct lg_g15_data *g15,
+ struct lg_g15_led *g15_led,
+ enum led_brightness brightness)
+{
+ struct mc_subled const * const subleds = g15_led->mcdev.subled_info;
+ u8 * const tbuf = g15->transfer_buf;
+ int ret;
+
+ led_mc_calc_color_components(&g15_led->mcdev, brightness);
+
+ tbuf[0] = 5;
+ tbuf[1] = subleds[0].brightness;
+ tbuf[2] = subleds[1].brightness;
+ tbuf[3] = subleds[2].brightness;
+ tbuf[4] = 0;
+
+ ret = hid_hw_raw_request(g15->hdev, LG_G13_FEATURE_BACKLIGHT_RGB,
+ tbuf, 5,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ if (ret == 5) {
+ g15_led->brightness = brightness;
+ ret = 0;
+ } else {
+ hid_err(g15->hdev, "Error setting backlight brightness: %d\n", ret);
+ ret = (ret < 0) ? ret : -EIO;
+ }
+
+ return ret;
+}
+
+static int lg_g13_kbd_led_set(struct led_classdev *led_cdev, enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc = lcdev_to_mccdev(led_cdev);
+ struct lg_g15_led *g15_led =
+ container_of(mc, struct lg_g15_led, mcdev);
+ struct lg_g15_data *g15 = dev_get_drvdata(led_cdev->dev->parent);
+
+ /* Ignore LED off on unregister / keyboard unplug */
+ if (led_cdev->flags & LED_UNREGISTERING)
+ return 0;
+
+ guard(mutex)(&g15->mutex);
+ return lg_g13_kbd_led_write(g15, g15_led, brightness);
+}
+
+static enum led_brightness lg_g13_kbd_led_get(struct led_classdev *led_cdev)
+{
+ struct led_classdev_mc const * const mc = lcdev_to_mccdev(led_cdev);
+ struct lg_g15_led const *g15_led =
+ container_of(mc, struct lg_g15_led, mcdev);
+
+ return g15_led->brightness;
+}
+
+static int lg_g13_mkey_led_set(struct led_classdev *led_cdev, enum led_brightness brightness)
+{
+ struct lg_g15_led *g15_led =
+ container_of(led_cdev, struct lg_g15_led, cdev);
+ struct lg_g15_data *g15 = dev_get_drvdata(led_cdev->dev->parent);
+ int i, ret;
+ u8 * const tbuf = g15->transfer_buf;
+ u8 val, mask = 0;
+
+ /* Ignore LED off on unregister / keyboard unplug */
+ if (led_cdev->flags & LED_UNREGISTERING)
+ return 0;
+
+ guard(mutex)(&g15->mutex);
+
+ for (i = LG_G15_MACRO_PRESET1; i < LG_G15_LED_MAX; ++i) {
+ if (i == g15_led->led)
+ val = brightness;
+ else
+ val = g15->leds[i].brightness;
+
+ if (val)
+ mask |= 1 << (i - LG_G15_MACRO_PRESET1);
+ }
+
+ tbuf[0] = 5;
+ tbuf[1] = mask;
+ tbuf[2] =
+ tbuf[3] =
+ tbuf[4] = 0;
+
+ ret = hid_hw_raw_request(g15->hdev, LG_G13_FEATURE_M_KEYS_LEDS,
+ tbuf, 5,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ if (ret != 5) {
+ hid_err(g15->hdev, "Error setting LED brightness: %d\n", ret);
+ return (ret < 0) ? ret : -EIO;
+ }
+
+ g15_led->brightness = brightness;
+ return 0;
+}
+
+static enum led_brightness lg_g13_mkey_led_get(struct led_classdev *led_cdev)
+{
+ /*
+ * G13 doesn't change macro key LEDs behind our back, so they're
+ * whatever we last set them to.
+ */
+ struct lg_g15_led *g15_led =
+ container_of(led_cdev, struct lg_g15_led, cdev);
+
+ return g15_led->brightness;
+}
+
/******** G15 and G15 v2 LED functions ********/
static int lg_g15_update_led_brightness(struct lg_g15_data *g15)
@@ -390,6 +562,8 @@ static int lg_g15_get_initial_led_brightness(struct lg_g15_data *g15)
int ret;
switch (g15->model) {
+ case LG_G13:
+ return lg_g13_get_leds_state(g15);
case LG_G15:
case LG_G15_V2:
return lg_g15_update_led_brightness(g15);
@@ -417,6 +591,117 @@ static int lg_g15_get_initial_led_brightness(struct lg_g15_data *g15)
/******** Input functions ********/
+/**
+ * g13_input_report.keybits[] is not 32-bit aligned, so we can't use the bitops macros.
+ *
+ * @ary: Pointer to array of u8s
+ * @b: Bit index into ary, LSB first. Not range checked.
+ */
+#define TEST_BIT(ary, b) ((1 << ((b) & 7)) & (ary)[(b) >> 3])
+
+/* Table mapping keybits[] bit positions to event codes. */
+/* Note: Indices are discontinuous to aid readability. */
+static const u16 g13_keys_for_bits[] = {
+ /* Main keypad - keys G1 - G22 */
+ [0] = KEY_MACRO1,
+ [1] = KEY_MACRO2,
+ [2] = KEY_MACRO3,
+ [3] = KEY_MACRO4,
+ [4] = KEY_MACRO5,
+ [5] = KEY_MACRO6,
+ [6] = KEY_MACRO7,
+ [7] = KEY_MACRO8,
+ [8] = KEY_MACRO9,
+ [9] = KEY_MACRO10,
+ [10] = KEY_MACRO11,
+ [11] = KEY_MACRO12,
+ [12] = KEY_MACRO13,
+ [13] = KEY_MACRO14,
+ [14] = KEY_MACRO15,
+ [15] = KEY_MACRO16,
+ [16] = KEY_MACRO17,
+ [17] = KEY_MACRO18,
+ [18] = KEY_MACRO19,
+ [19] = KEY_MACRO20,
+ [20] = KEY_MACRO21,
+ [21] = KEY_MACRO22,
+
+ /* LCD menu buttons. */
+ [24] = KEY_KBD_LCD_MENU5, // "Next page" button
+ [25] = KEY_KBD_LCD_MENU1, // Left-most
+ [26] = KEY_KBD_LCD_MENU2,
+ [27] = KEY_KBD_LCD_MENU3,
+ [28] = KEY_KBD_LCD_MENU4, // Right-most
+
+ /* Macro preset and record buttons; have red LEDs under them. */
+ [29] = KEY_MACRO_PRESET1,
+ [30] = KEY_MACRO_PRESET2,
+ [31] = KEY_MACRO_PRESET3,
+ [32] = KEY_MACRO_RECORD_START,
+
+ /* 33-35 handled by joystick device. */
+
+ /* Backlight toggle. */
+ [37] = KEY_LIGHTS_TOGGLE,
+};
+
+static const u16 g13_keys_for_bits_js[] = {
+ /* Joystick buttons */
+ /* These keybits are at bit indices 33, 34, and 35. */
+ BTN_BASE, // Left side
+ BTN_BASE2, // Bottom side
+ BTN_THUMB, // Stick depress
+};
+
+static int lg_g13_event(struct lg_g15_data *g15, u8 const *data)
+{
+ struct g13_input_report const * const rep = (struct g13_input_report *) data;
+ int i, val;
+ bool hw_brightness_changed;
+
+ /*
+ * Main macropad and menu keys.
+ * Emit key events defined for each bit position.
+ */
+ for (i = 0; i < ARRAY_SIZE(g13_keys_for_bits); ++i) {
+ if (g13_keys_for_bits[i]) {
+ val = TEST_BIT(rep->keybits, i);
+ input_report_key(g15->input, g13_keys_for_bits[i], val);
+ }
+ }
+ input_sync(g15->input);
+
+ /*
+ * Joystick.
+ * Emit button and deflection events.
+ */
+ for (i = 0; i < ARRAY_SIZE(g13_keys_for_bits_js); ++i) {
+ if (g13_keys_for_bits_js[i]) {
+ val = TEST_BIT(rep->keybits, i + 33);
+ input_report_key(g15->input_js, g13_keys_for_bits_js[i], val);
+ }
+ }
+ input_report_abs(g15->input_js, ABS_X, rep->joy_x);
+ input_report_abs(g15->input_js, ABS_Y, rep->joy_y);
+ input_sync(g15->input_js);
+
+#ifdef CONFIG_LEDS_BRIGHTNESS_HW_CHANGED
+ /*
+ * Bit 23 of keybits[] reports the current backlight on/off state. If
+ * it has changed from the last cached value, apply an update.
+ */
+ hw_brightness_changed =
+ (!!TEST_BIT(rep->keybits, 23)) ^ (g15->leds[0].cdev.brightness_hw_changed > 0);
+ if (hw_brightness_changed) {
+ led_classdev_notify_brightness_hw_changed(
+ &g15->leds[0].cdev,
+ TEST_BIT(rep->keybits, 23) ? LED_FULL : LED_OFF);
+ }
+#endif
+
+ return 0;
+}
+
/* On the G15 Mark I Logitech has been quite creative with which bit is what */
static void lg_g15_handle_lcd_menu_keys(struct lg_g15_data *g15, u8 *data)
{
@@ -572,6 +857,10 @@ static int lg_g15_raw_event(struct hid_device *hdev, struct hid_report *report,
return 0;
switch (g15->model) {
+ case LG_G13:
+ if (data[0] == 0x01 && size == sizeof(struct g13_input_report))
+ return lg_g13_event(g15, data);
+ break;
case LG_G15:
if (data[0] == 0x02 && size == 9)
return lg_g15_event(g15, data);
@@ -616,13 +905,22 @@ static void lg_g15_setup_led_rgb(struct lg_g15_data *g15, int index)
{
int i;
struct mc_subled *subled_info;
-
- g15->leds[index].mcdev.led_cdev.brightness_set_blocking =
- lg_g510_kbd_led_set;
- g15->leds[index].mcdev.led_cdev.brightness_get =
- lg_g510_kbd_led_get;
- g15->leds[index].mcdev.led_cdev.max_brightness = 255;
- g15->leds[index].mcdev.num_colors = 3;
+ struct lg_g15_led * const gled = &g15->leds[index];
+
+ if (g15->model == LG_G13) {
+ gled->mcdev.led_cdev.brightness_set_blocking =
+ lg_g13_kbd_led_set;
+ gled->mcdev.led_cdev.brightness_get =
+ lg_g13_kbd_led_get;
+ gled->mcdev.led_cdev.flags = LED_BRIGHT_HW_CHANGED;
+ } else {
+ gled->mcdev.led_cdev.brightness_set_blocking =
+ lg_g510_kbd_led_set;
+ gled->mcdev.led_cdev.brightness_get =
+ lg_g510_kbd_led_get;
+ }
+ gled->mcdev.led_cdev.max_brightness = 255;
+ gled->mcdev.num_colors = 3;
subled_info = devm_kcalloc(&g15->hdev->dev, 3, sizeof(*subled_info), GFP_KERNEL);
if (!subled_info)
@@ -632,20 +930,20 @@ static void lg_g15_setup_led_rgb(struct lg_g15_data *g15, int index)
switch (i + 1) {
case LED_COLOR_ID_RED:
subled_info[i].color_index = LED_COLOR_ID_RED;
- subled_info[i].intensity = g15->leds[index].red;
+ subled_info[i].intensity = gled->red;
break;
case LED_COLOR_ID_GREEN:
subled_info[i].color_index = LED_COLOR_ID_GREEN;
- subled_info[i].intensity = g15->leds[index].green;
+ subled_info[i].intensity = gled->green;
break;
case LED_COLOR_ID_BLUE:
subled_info[i].color_index = LED_COLOR_ID_BLUE;
- subled_info[i].intensity = g15->leds[index].blue;
+ subled_info[i].intensity = gled->blue;
break;
}
subled_info[i].channel = i;
}
- g15->leds[index].mcdev.subled_info = subled_info;
+ gled->mcdev.subled_info = subled_info;
}
static int lg_g15_register_led(struct lg_g15_data *g15, int i, const char *name)
@@ -656,6 +954,23 @@ static int lg_g15_register_led(struct lg_g15_data *g15, int i, const char *name)
g15->leds[i].cdev.name = name;
switch (g15->model) {
+ case LG_G13:
+ if (i < LG_G15_BRIGHTNESS_MAX) {
+ /* RGB backlight. */
+ lg_g15_setup_led_rgb(g15, i);
+ ret = devm_led_classdev_multicolor_register_ext(&g15->hdev->dev,
+ &g15->leds[i].mcdev,
+ NULL);
+ } else {
+ /* Macro keys */
+ g15->leds[i].cdev.brightness_set_blocking = lg_g13_mkey_led_set;
+ g15->leds[i].cdev.brightness_get = lg_g13_mkey_led_get;
+ g15->leds[i].cdev.max_brightness = 1;
+
+ ret = devm_led_classdev_register(&g15->hdev->dev,
+ &g15->leds[i].cdev);
+ }
+ break;
case LG_G15:
case LG_G15_V2:
g15->leds[i].cdev.brightness_get = lg_g15_led_get;
@@ -702,27 +1017,60 @@ static int lg_g15_register_led(struct lg_g15_data *g15, int i, const char *name)
}
/* Common input device init code shared between keyboards and Z-10 speaker handling */
-static void lg_g15_init_input_dev(struct hid_device *hdev, struct input_dev *input,
- const char *name)
+static void lg_g15_init_input_dev_core(struct hid_device *hdev,
+ struct input_dev *input,
+ char const *name)
{
- int i;
-
- input->name = name;
- input->phys = hdev->phys;
- input->uniq = hdev->uniq;
+ input->name = name;
+ input->phys = hdev->phys;
+ input->uniq = hdev->uniq;
input->id.bustype = hdev->bus;
input->id.vendor = hdev->vendor;
input->id.product = hdev->product;
input->id.version = hdev->version;
input->dev.parent = &hdev->dev;
- input->open = lg_g15_input_open;
- input->close = lg_g15_input_close;
+ input->open = lg_g15_input_open;
+ input->close = lg_g15_input_close;
+}
+
+static void lg_g15_init_input_dev(struct hid_device *hdev, struct input_dev *input,
+ const char *name)
+{
+ int i;
+
+ lg_g15_init_input_dev_core(hdev, input, name);
/* Keys below the LCD, intended for controlling a menu on the LCD */
for (i = 0; i < 5; i++)
input_set_capability(input, EV_KEY, KEY_KBD_LCD_MENU1 + i);
}
+static void lg_g13_init_input_dev(struct hid_device *hdev,
+ struct input_dev *input, const char *name,
+ struct input_dev *input_js, const char *name_js)
+{
+ /* Macropad. */
+ lg_g15_init_input_dev_core(hdev, input, name);
+ for (int i = 0; i < ARRAY_SIZE(g13_keys_for_bits); ++i) {
+ if (g13_keys_for_bits[i]) {
+ input_set_capability(input, EV_KEY, g13_keys_for_bits[i]);
+ }
+ }
+
+ /* OBTW, we're a joystick, too... */
+ lg_g15_init_input_dev_core(hdev, input_js, name_js);
+ for (int i = 0; i < ARRAY_SIZE(g13_keys_for_bits_js); ++i) {
+ if (g13_keys_for_bits_js[i]) {
+ input_set_capability(input_js, EV_KEY, g13_keys_for_bits_js[i]);
+ }
+ }
+
+ input_set_capability(input_js, EV_ABS, ABS_X);
+ input_set_abs_params(input_js, ABS_X, 0, 255, 0, 0);
+ input_set_capability(input_js, EV_ABS, ABS_Y);
+ input_set_abs_params(input_js, ABS_Y, 0, 255, 0, 0);
+}
+
static int lg_g15_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
static const char * const led_names[] = {
@@ -739,7 +1087,7 @@ static int lg_g15_probe(struct hid_device *hdev, const struct hid_device_id *id)
unsigned int connect_mask = 0;
bool has_ff000000 = false;
struct lg_g15_data *g15;
- struct input_dev *input;
+ struct input_dev *input, *input_js;
struct hid_report *rep;
int ret, i, gkeys = 0;
@@ -778,6 +1126,21 @@ static int lg_g15_probe(struct hid_device *hdev, const struct hid_device_id *id)
hid_set_drvdata(hdev, (void *)g15);
switch (g15->model) {
+ case LG_G13:
+ /*
+ * Some usermode libraries tend to ignore devices that don't
+ * "look like" a joystick. Create additional input device
+ * dedicated as joystick.
+ */
+ input_js = devm_input_allocate_device(&hdev->dev);
+ if (!input_js)
+ return -ENOMEM;
+ g15->input_js = input_js;
+ input_set_drvdata(input_js, hdev);
+
+ connect_mask = HID_CONNECT_HIDRAW;
+ gkeys = 25;
+ break;
case LG_G15:
INIT_WORK(&g15->work, lg_g15_leds_changed_work);
/*
@@ -859,6 +1222,34 @@ static int lg_g15_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto error_hw_stop;
return 0; /* All done */
+ } else if (g15->model == LG_G13) {
+ static char const * const g13_led_names[] = {
+ /* Backlight is shared between LCD and keys. */
+ "g13:rgb:kbd_backlight",
+ NULL, // Keep in sync with led_type enum
+ "g13:red:macro_preset_1",
+ "g13:red:macro_preset_2",
+ "g13:red:macro_preset_3",
+ "g13:red:macro_record",
+ };
+ lg_g13_init_input_dev(hdev,
+ input, "Logitech G13 Gaming Keypad",
+ input_js, "Logitech G13 Thumbstick");
+ ret = input_register_device(input);
+ if (ret)
+ goto error_hw_stop;
+ ret = input_register_device(input_js);
+ if (ret)
+ goto error_hw_stop;
+
+ for (i = 0; i < ARRAY_SIZE(g13_led_names); ++i) {
+ if (g13_led_names[i]) {
+ ret = lg_g15_register_led(g15, i, g13_led_names[i]);
+ if (ret)
+ goto error_hw_stop;
+ }
+ }
+ return 0;
}
/* Setup and register input device */
@@ -903,6 +1294,13 @@ static int lg_g15_probe(struct hid_device *hdev, const struct hid_device_id *id)
}
static const struct hid_device_id lg_g15_devices[] = {
+ /*
+ * The G13 is a macropad-only device with an LCD, LED backlighing,
+ * and joystick.
+ */
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_G13),
+ .driver_data = LG_G13 },
/* The G11 is a G15 without the LCD, treat it as a G15 */
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_G11),
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional
From: Matti Vaittinen @ 2025-08-12 5:11 UTC (permalink / raw)
To: Andy Shevchenko, Dmitry Torokhov
Cc: Arnd Bergmann, Bartosz Golaszewski, Linus Walleij, linux-gpio,
Lee Jones, Arnd Bergmann, Gatien Chevallier, Fabrice Gasnier,
Bartosz Golaszewski, Thomas Gleixner, Charles Keepax,
Krzysztof Kozlowski, Christophe JAILLET, linux-input,
linux-kernel
In-Reply-To: <aJpOEq_5jqGTUr4x@smile.fi.intel.com>
On 11/08/2025 23:09, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 12:21:51PM -0700, Dmitry Torokhov wrote:
>> On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
>>> On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
>>>> On 08/08/2025 18:17, Arnd Bergmann wrote:
>
> ...
>
>>>> As such, this patch seems Ok to me, you can treat this as an ack :) This,
>>>> however made me ponder following - is this the tight way to handle the
>>>> power-button IRQ? I don't see any other MFD devices doing this in same way,
>>>> although I am pretty sure there are other PMICs with similar power-button
>>>> IRQ...
>>>>
>>>> I see for example the "drivers/mfd/rt5120.c" to invoke
>>>> "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
>>>> however, feels like code duplication to me. I'd rather kept using the
>>>> gpio-keys, but seeing:
>>>>
>>>> git grep KEY_POWER drivers/mfd/
>>>> drivers/mfd/rohm-bd71828.c: .code = KEY_POWER,
>>>> drivers/mfd/rohm-bd718x7.c: .code = KEY_POWER,
>>>>
>>>> makes me wonder if there is more widely used (better) way?
>>>
>>> FWIW, on Intel platforms that use power button by PMIC we add a special driver
>>> for each of such cases.
>>
>> If we can make gpio-keys work for various power buttons that would be
>> great IMO. The MFD drivers in question already are using device tree,
>> but they do not define/expect nodes for the power buttons. If the nodes
>> were there then I think gpio-keys would work out of the box?
>
> Looking at the, e.g., https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/x86/intel/mrfld_pwrbtn.c,
> I am not sure it's as simply as it sounds. Basically it's an IRQ, which
> requires IRQ handling and proper acking/masking/etc.
In some (many?) cases the interrupts (acking/masking) are handled by an
irqchip code. When this is the case, the gpio-keys (or any other
power-button code) does not need to care about IRQ-specifics. (I don't
know about the Intel driver though.)
Problem with many of the bd718* (and probably some other MFD drivers)
is, that the interrupts are really relevant only for the drivers
specific to this one device (like PMIC in ROHM case). When this is the
case, the device is not really (from the HW perspective) an
interrupt-controller, which means it shouldn't probably be marked as one
in the device-tree either. It will then also mean that there can't be
meaningful interrupt specification for the button IRQ in the
device-tree, right?
Additionally, we have devices where most of the interrupts are internal
to the PMIC, but then the PMIC also has some pins usable as GPIO, which
can be used as interrupt sources. Eg, someone can connect another device
to these pins - which makes the PMIC an interrupt-controller. For these
PMICs the power-button IRQ can be provided via device-tree node (but the
IRQ spec may become a bit hairy, since most of the IRQs are meant to be
internal).
Hence, for me, providing the IRQ number in platform data seems still to
be the right thing to do :)
TLDR; I agree with Dmitry. It's nice to have an easily re-usable
power-button handler, which requires no IC-specific code. Gpio-keys
works for simple IRQ based power-buttons where IRQ controller takes care
of the acks/masks. I just wanted to know if it is for some reason
discouraged, or if I've used it in a wrong way (because the grep
resulted so few results).
Yours,
-- Matti
^ permalink raw reply
* Re: [PATCH 2/8] mfd: dt-bindings: ti,twl6040: convert to DT schema
From: Rob Herring (Arm) @ 2025-08-12 1:24 UTC (permalink / raw)
To: Jihed Chaibi
Cc: tiwai, devicetree, linux-usb, gregkh, ukleinek, krzk+dt,
dmitry.torokhov, broonie, linux-pwm, lee, linux-sound, lgirdwood,
peter.ujfalusi, linux-kernel, linux-input, shuah, conor+dt
In-Reply-To: <20250811224739.53869-3-jihed.chaibi.dev@gmail.com>
On Tue, 12 Aug 2025 00:47:33 +0200, Jihed Chaibi wrote:
> Convert the legacy TXT binding for the TWL6040 MFD
> to the modern YAML DT schema format. This adds formal validation
> and improves documentation.
>
> Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
> ---
> .../devicetree/bindings/mfd/ti,twl6040.yaml | 155 ++++++++++++++++++
> .../devicetree/bindings/mfd/twl6040.txt | 67 --------
> 2 files changed, 155 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/twl6040.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/ti,twl6040.example.dtb: twl@4b (ti,twl6040): 'twl6040,audpwron-gpio' does not match any of the regexes: '^#.*', '^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*', '^(keypad|m25p|max8952|max8997|max8998|mpmc),.*', '^(pciclass|pinctrl-single|#pinctrl-single|PowerPC),.*', '^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*', '^(simple-audio-card|st-plgpio|st-spics|ts),.*', '^100ask,.*', '^70mai,.*', '^8dev,.*', '^GEFanuc,.*', '^IBM,.*', '^ORCL,.*', '^SUNW,.*', '^[a-zA-Z0-9#_][a-zA-Z0-9+\\-._@]{0,63}$', '^[a-zA-Z0-9+\\-._]*@[0-9a-zA-Z,]*$', '^abb,.*', '^abilis,.*', '^abracon,.*', '^abt,.*', '^acbel,.*', '^acelink,.*', '^acer,.*', '^acme,.*', '^actions,.*', '^active-semi,.*', '^ad,.*', '^adafruit,.*', '^adapteva,.*', '^adaptrum,.*', '^adh,.*', '^adi,.*', '^adieng,.*', '^admatec,.*', '^advantech,.*', '^aeroflexgaisler,.*', '^aesop,.*', '^airoha,.*', '^al,.*', '^alcatel,.*', '^aldec,.*', '^alfa-network,.*', '^allegro,.*', '^allegromicro,.*', '^alliedvision,.*', '^allo,.*', '^allwinner,.*', '^alphascale,.*', '^alps,.*', '^alt,.*', '^altr,.*', '^amarula,.*', '^amazon,.*', '^amcc,.*', '^amd,.*', '^amediatech,.*', '^amlogic,.*', '^ampere,.*', '^amphenol,.*', '^ampire,.*', '^ams,.*', '^amstaos,.*', '^analogix,.*', '^anbernic,.*', '^andestech,.*', '^anvo,.*', '^aoly,.*', '^aosong,.*', '^apm,.*', '^apple,.*', '^aptina,.*', '^arasan,.*', '^archermind,.*', '^arcom,.*', '^arctic,.*', '^arcx,.*', '^argon40,.*', '^ariaboard,.*', '^aries,.*', '^arm,.*', '^armadeus,.*', '^armsom,.*', '^arrow,.*', '^artesyn,.*', '^asahi-kasei,.*', '^asc,.*', '^asix,.*', '^aspeed,.*', '^asrock,.*', '^asteralabs,.*', '^asus,.*', '^atheros,.*', '^atlas,.*', '^atmel,.*', '^auo,.*', '^auvidea,.*', '^avago,.*', '^avia,.*', '^avic,.*', '^avnet,.*', '^awinic,.*', '^axentia,.*', '^axiado,.*', '^axis,.*', '^azoteq,.*', '^azw,.*', '^baikal,.*', '^bananapi,.*', '^beacon,.*', '^beagle,.*', '^belling,.*', '^bhf,.*', '^bigtreetech,.*', '^bitmain,.*', '^blaize,.*', '^blutek,.*', '^boe,.*', '^bosch,.*', '^boundary,.*', '^brcm,.*', '^broadmobi,.*', '^bsh,.*', '^bticino,.*', '^buffalo,.*', '^bur,.*', '^bytedance,.*', '^calamp,.*', '^calao,.*', '^calaosystems,.*', '^calxeda,.*', '^cameo,.*', '^canaan,.*', '^caninos,.*', '^capella,.*', '^cascoda,.*', '^catalyst,.*', '^cavium,.*', '^cct,.*', '^cdns,.*', '^cdtech,.*', '^cellwise,.*', '^ceva,.*', '^chargebyte,.*', '^checkpoint,.*', '^chefree,.*', '^chipidea,.*', '^chipone,.*', '^chipspark,.*', '^chongzhou,.*', '^chrontel,.*', '^chrp,.*', '^chunghwa,.*', '^chuwi,.*', '^ciaa,.*', '^cirrus,.*', '^cisco,.*', '^cix,.*', '^clockwork,.*', '^cloos,.*', '^cloudengines,.*', '^cnm,.*', '^cnxt,.*', '^colorfly,.*', '^compulab,.*', '^comvetia,.*', '^congatec,.*', '^coolpi,.*', '^coreriver,.*', '^corpro,.*', '^cortina,.*', '^cosmic,.*', '^crane,.*', '^creative,.*', '^crystalfontz,.*', '^csky,.*', '^csot,.*', '^csq,.*', '^ctera,.*', '^ctu,.*', '^cubietech,.*', '^cudy,.*', '^cui,.*', '^cypress,.*', '^cyx,.*', '^cznic,.*', '^dallas,.*', '^dataimage,.*', '^davicom,.*', '^deepcomputing,.*', '^dell,.*', '^delta,.*', '^densitron,.*', '^denx,.*', '^devantech,.*', '^dfi,.*', '^dfrobot,.*', '^dh,.*', '^difrnce,.*', '^digi,.*', '^digilent,.*', '^dimonoff,.*', '^diodes,.*', '^dioo,.*', '^djn,.*', '^dlc,.*', '^dlg,.*', '^dlink,.*', '^dmo,.*', '^domintech,.*', '^dongwoon,.*', '^dptechnics,.*', '^dragino,.*', '^dream,.*', '^ds,.*', '^dserve,.*', '^dynaimage,.*', '^ea,.*', '^ebang,.*', '^ebbg,.*', '^ebs-systart,.*', '^ebv,.*', '^eckelmann,.*', '^econet,.*', '^edgeble,.*', '^edimax,.*', '^edt,.*', '^ees,.*', '^eeti,.*', '^einfochips,.*', '^eink,.*', '^elan,.*', '^element14,.*', '^elgin,.*', '^elida,.*', '^elimo,.*', '^elpida,.*', '^embedfire,.*', '^embest,.*', '^emcraft,.*', '^emlid,.*', '^emmicro,.*', '^empire-electronix,.*', '^emtrion,.*', '^enclustra,.*', '^endless,.*', '^ene,.*', '^energymicro,.*', '^engicam,.*', '^engleder,.*', '^epcos,.*', '^epfl,.*', '^epson,.*', '^esp,.*', '^est,.*', '^ettus,.*', '^eukrea,.*', '^everest,.*', '^everspin,.*', '^evervision,.*', '^exar,.*', '^excito,.*', '^exegin,.*', '^ezchip,.*', '^facebook,.*', '^fairchild,.*', '^fairphone,.*', '^faraday,.*', '^fascontek,.*', '^fastrax,.*', '^fcs,.*', '^feixin,.*', '^feiyang,.*', '^fii,.*', '^firefly,.*', '^focaltech,.*', '^forlinx,.*', '^freebox,.*', '^freecom,.*', '^frida,.*', '^friendlyarm,.*', '^fsl,.*', '^fujitsu,.*', '^fxtec,.*', '^galaxycore,.*', '^gameforce,.*', '^gardena,.*', '^gateway,.*', '^gateworks,.*', '^gcw,.*', '^ge,.*', '^geekbuying,.*', '^gef,.*', '^gehc,.*', '^gemei,.*', '^gemtek,.*', '^genesys,.*', '^genexis,.*', '^geniatech,.*', '^giantec,.*', '^giantplus,.*', '^glinet,.*', '^globalscale,.*', '^globaltop,.*', '^gmt,.*', '^gocontroll,.*', '^goldelico,.*', '^goodix,.*', '^google,.*', '^goramo,.*', '^gplus,.*', '^grinn,.*', '^grmn,.*', '^gumstix,.*', '^gw,.*', '^hannstar,.*', '^haochuangyi,.*', '^haoyu,.*', '^hardkernel,.*', '^hechuang,.*', '^hideep,.*', '^himax,.*', '^hirschmann,.*', '^hisi,.*', '^hisilicon,.*', '^hit,.*', '^hitex,.*', '^holt,.*', '^holtek,.*', '^honestar,.*', '^honeywell,.*', '^hoperf,.*', '^hoperun,.*', '^hp,.*', '^hpe,.*', '^hsg,.*', '^htc,.*', '^huawei,.*', '^hugsun,.*', '^huiling,.*', '^hwacom,.*', '^hxt,.*', '^hycon,.*', '^hydis,.*', '^hynitron,.*', '^hynix,.*', '^hyundai,.*', '^i2se,.*', '^ibm,.*', '^icplus,.*', '^idt,.*', '^iei,.*', '^ifi,.*', '^ilitek,.*', '^imagis,.*', '^img,.*', '^imi,.*', '^inanbo,.*', '^incircuit,.*', '^indiedroid,.*', '^inet-tek,.*', '^infineon,.*', '^inforce,.*', '^ingenic,.*', '^ingrasys,.*', '^injoinic,.*', '^innocomm,.*', '^innolux,.*', '^inside-secure,.*', '^insignal,.*', '^inspur,.*', '^intel,.*', '^intercontrol,.*', '^invensense,.*', '^inventec,.*', '^inversepath,.*', '^iom,.*', '^irondevice,.*', '^isee,.*', '^isil,.*', '^issi,.*', '^ite,.*', '^itead,.*', '^itian,.*', '^ivo,.*', '^iwave,.*', '^jadard,.*', '^jasonic,.*', '^jdi,.*', '^jedec,.*', '^jenson,.*', '^jesurun,.*', '^jethome,.*', '^jianda,.*', '^jide,.*', '^joz,.*', '^jty,.*', '^kam,.*', '^karo,.*', '^keithkoep,.*', '^keymile,.*', '^khadas,.*', '^kiebackpeter,.*', '^kinetic,.*', '^kingdisplay,.*', '^kingnovel,.*', '^kionix,.*', '^kobo,.*', '^kobol,.*', '^koe,.*', '^kontron,.*', '^kosagi,.*', '^kvg,.*', '^kyo,.*', '^lacie,.*', '^laird,.*', '^lamobo,.*', '^lantiq,.*', '^lattice,.*', '^lckfb,.*', '^lctech,.*', '^leadtek,.*', '^leez,.*', '^lego,.*', '^lemaker,.*', '^lenovo,.*', '^lg,.*', '^lgphilips,.*', '^libretech,.*', '^licheepi,.*', '^linaro,.*', '^lincolntech,.*', '^lineartechnology,.*', '^linksprite,.*', '^linksys,.*', '^linutronix,.*', '^linux,.*', '^linx,.*', '^liontron,.*', '^liteon,.*', '^litex,.*', '^lltc,.*', '^logicpd,.*', '^logictechno,.*', '^longcheer,.*', '^lontium,.*', '^loongmasses,.*', '^loongson,.*', '^lsi,.*', '^luckfox,.*', '^lunzn,.*', '^luxul,.*', '^lwn,.*', '^lxa,.*', '^m5stack,.*', '^macnica,.*', '^mantix,.*', '^mapleboard,.*', '^marantec,.*', '^marvell,.*', '^maxbotix,.*', '^maxim,.*', '^maxlinear,.*', '^mbvl,.*', '^mcube,.*', '^meas,.*', '^mecer,.*', '^mediatek,.*', '^megachips,.*', '^mele,.*', '^melexis,.*', '^melfas,.*', '^mellanox,.*', '^memsensing,.*', '^memsic,.*', '^menlo,.*', '^mentor,.*', '^meraki,.*', '^merrii,.*', '^methode,.*', '^micrel,.*', '^microchip,.*', '^microcrystal,.*', '^micron,.*', '^microsoft,.*', '^microsys,.*', '^microtips,.*', '^mikroe,.*', '^mikrotik,.*', '^milkv,.*', '^miniand,.*', '^minix,.*', '^mips,.*', '^miramems,.*', '^mitsubishi,.*', '^mitsumi,.*', '^mixel,.*', '^miyoo,.*', '^mntre,.*', '^mobileye,.*', '^modtronix,.*', '^moortec,.*', '^mosaixtech,.*', '^motorcomm,.*', '^motorola,.*', '^moxa,.*', '^mpl,.*', '^mps,.*', '^mqmaker,.*', '^mrvl,.*', '^mscc,.*', '^msi,.*', '^mstar,.*', '^mti,.*', '^multi-inno,.*', '^mundoreader,.*', '^murata,.*', '^mxic,.*', '^mxicy,.*', '^myir,.*', '^national,.*', '^neardi,.*', '^nec,.*', '^neofidelity,.*', '^neonode,.*', '^netcube,.*', '^netgear,.*', '^netlogic,.*', '^netron-dy,.*', '^netronix,.*', '^netxeon,.*', '^neweast,.*', '^newhaven,.*', '^newvision,.*', '^nexbox,.*', '^nextthing,.*', '^ni,.*', '^nicera,.*', '^nintendo,.*', '^nlt,.*', '^nokia,.*', '^nordic,.*', '^nothing,.*', '^novatek,.*', '^novtech,.*', '^numonyx,.*', '^nutsboard,.*', '^nuvoton,.*', '^nvd,.*', '^nvidia,.*', '^nxp,.*', '^oceanic,.*', '^ocs,.*', '^oct,.*', '^okaya,.*', '^oki,.*', '^olimex,.*', '^olpc,.*', '^oneplus,.*', '^onie,.*', '^onion,.*', '^onnn,.*', '^ontat,.*', '^opalkelly,.*', '^openailab,.*', '^opencores,.*', '^openembed,.*', '^openpandora,.*', '^openrisc,.*', '^openwrt,.*', '^option,.*', '^oranth,.*', '^orisetech,.*', '^ortustech,.*', '^osddisplays,.*', '^osmc,.*', '^ouya,.*', '^overkiz,.*', '^ovti,.*', '^oxsemi,.*', '^ozzmaker,.*', '^panasonic,.*', '^parade,.*', '^parallax,.*', '^pda,.*', '^pegatron,.*', '^pericom,.*', '^pervasive,.*', '^phicomm,.*', '^phytec,.*', '^picochip,.*', '^pinctrl-[0-9]+$', '^pine64,.*', '^pineriver,.*', '^pixcir,.*', '^plantower,.*', '^plathome,.*', '^plda,.*', '^plx,.*', '^ply,.*', '^pni,.*', '^pocketbook,.*', '^polaroid,.*', '^polyhex,.*', '^pool[0-3],.*', '^portwell,.*', '^poslab,.*', '^pov,.*', '^powertip,.*', '^powervr,.*', '^powkiddy,.*', '^pri,.*', '^primeview,.*', '^primux,.*', '^probox2,.*', '^prt,.*', '^pulsedlight,.*', '^purism,.*', '^puya,.*', '^qca,.*', '^qcom,.*', '^qemu,.*', '^qi,.*', '^qiaodian,.*', '^qihua,.*', '^qishenglong,.*', '^qnap,.*', '^quanta,.*', '^radxa,.*', '^raidsonic,.*', '^ralink,.*', '^ramtron,.*', '^raspberrypi,.*', '^raydium,.*', '^rda,.*', '^realtek,.*', '^relfor,.*', '^remarkable,.*', '^renesas,.*', '^rervision,.*', '^retronix,.*', '^revotics,.*', '^rex,.*', '^richtek,.*', '^ricoh,.*', '^rikomagic,.*', '^riot,.*', '^riscv,.*', '^rockchip,.*', '^rocktech,.*', '^rohm,.*', '^ronbo,.*', '^roofull,.*', '^roseapplepi,.*', '^rve,.*', '^saef,.*', '^sakurapi,.*', '^samsung,.*', '^samtec,.*', '^sancloud,.*', '^sandisk,.*', '^satoz,.*', '^sbs,.*', '^schindler,.*', '^schneider,.*', '^sciosense,.*', '^seagate,.*', '^seeed,.*', '^seirobotics,.*', '^semtech,.*', '^senseair,.*', '^sensirion,.*', '^sensortek,.*', '^sercomm,.*', '^sff,.*', '^sgd,.*', '^sgmicro,.*', '^sgx,.*', '^sharp,.*', '^shift,.*', '^shimafuji,.*', '^shineworld,.*', '^shiratech,.*', '^si-en,.*', '^si-linux,.*', '^siemens,.*', '^sifive,.*', '^siflower,.*', '^sigma,.*', '^sii,.*', '^sil,.*', '^silabs,.*', '^silan,.*', '^silead,.*', '^silergy,.*', '^silex-insight,.*', '^siliconfile,.*', '^siliconmitus,.*', '^silvaco,.*', '^simtek,.*', '^sinlinx,.*', '^sinovoip,.*', '^sinowealth,.*', '^sipeed,.*', '^sirf,.*', '^sis,.*', '^sitronix,.*', '^skov,.*', '^skyworks,.*', '^smartfiber,.*', '^smartlabs,.*', '^smartrg,.*', '^smi,.*', '^smsc,.*', '^snps,.*', '^sochip,.*', '^socionext,.*', '^solidrun,.*', '^solomon,.*', '^sony,.*', '^sophgo,.*', '^sourceparts,.*', '^spacemit,.*', '^spansion,.*', '^sparkfun,.*', '^spinalhdl,.*', '^sprd,.*', '^square,.*', '^ssi,.*', '^sst,.*', '^sstar,.*', '^st,.*', '^st-ericsson,.*', '^starfive,.*', '^starry,.*', '^startek,.*', '^starterkit,.*', '^ste,.*', '^stericsson,.*', '^storlink,.*', '^storm,.*', '^storopack,.*', '^summit,.*', '^sunchip,.*', '^sundance,.*', '^sunplus,.*', '^supermicro,.*', '^swir,.*', '^syna,.*', '^synology,.*', '^synopsys,.*', '^tbs,.*', '^tbs-biometrics,.*', '^tcg,.*', '^tcl,.*', '^tcs,.*', '^tcu,.*', '^tdo,.*', '^team-source-display,.*', '^technexion,.*', '^technologic,.*', '^techstar,.*', '^techwell,.*', '^teejet,.*', '^teltonika,.*', '^tempo,.*', '^terasic,.*', '^tesla,.*', '^test,.*', '^tfc,.*', '^thead,.*', '^thine,.*', '^thingyjp,.*', '^thundercomm,.*', '^thwc,.*', '^ti,.*', '^tianma,.*', '^tlm,.*', '^tmt,.*', '^topeet,.*', '^topic,.*', '^topland,.*', '^toppoly,.*', '^topwise,.*', '^toradex,.*', '^toshiba,.*', '^toumaz,.*', '^tpk,.*', '^tplink,.*', '^tpo,.*', '^tq,.*', '^transpeed,.*', '^traverse,.*', '^tronfy,.*', '^tronsmart,.*', '^truly,.*', '^tsd,.*', '^turing,.*', '^tyan,.*', '^tyhx,.*', '^u-blox,.*', '^u-boot,.*', '^ubnt,.*', '^ucrobotics,.*', '^udoo,.*', '^ufispace,.*', '^ugoos,.*', '^ultratronik,.*', '^uni-t,.*', '^uniwest,.*', '^upisemi,.*', '^urt,.*', '^usi,.*', '^usr,.*', '^utoo,.*', '^v3,.*', '^vaisala,.*', '^vamrs,.*', '^variscite,.*', '^vdl,.*', '^vertexcom,.*', '^via,.*', '^vialab,.*', '^vicor,.*', '^videostrong,.*', '^virtio,.*', '^virtual,.*', '^vishay,.*', '^visionox,.*', '^vitesse,.*', '^vivante,.*', '^vivax,.*', '^vocore,.*', '^voipac,.*', '^voltafield,.*', '^vot,.*', '^vscom,.*', '^vxt,.*', '^wacom,.*', '^wanchanglong,.*', '^wand,.*', '^waveshare,.*', '^wd,.*', '^we,.*', '^welltech,.*', '^wetek,.*', '^wexler,.*', '^whwave,.*', '^wi2wi,.*', '^widora,.*', '^wiligear,.*', '^willsemi,.*', '^winbond,.*', '^wingtech,.*', '^winlink,.*', '^winsen,.*', '^winstar,.*', '^wirelesstag,.*', '^wits,.*', '^wlf,.*', '^wm,.*', '^wobo,.*', '^wolfvision,.*', '^x-powers,.*', '^xen,.*', '^xes,.*', '^xiaomi,.*', '^xillybus,.*', '^xingbangda,.*', '^xinpeng,.*', '^xiphera,.*', '^xlnx,.*', '^xnano,.*', '^xunlong,.*', '^xylon,.*', '^yadro,.*', '^yamaha,.*', '^yes-optoelectronics,.*', '^yic,.*', '^yiming,.*', '^ylm,.*', '^yna,.*', '^yones-toptech,.*', '^ys,.*', '^ysoft,.*', '^yuridenki,.*', '^yuzukihd,.*', '^zarlink,.*', '^zealz,.*', '^zeitec,.*', '^zidoo,.*', '^zii,.*', '^zinitix,.*', '^zkmagic,.*', '^zte,.*', '^zyxel,.*'
from schema $id: http://devicetree.org/schemas/vendor-prefixes.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250811224739.53869-3-jihed.chaibi.dev@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 1/2] HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length
From: Xu, Even @ 2025-08-12 0:55 UTC (permalink / raw)
To: Jiri Kosina, Aaron, Ma
Cc: Sun, Xinpeng, bentiss@kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <qosrs9q2-6qrr-46r7-7nnp-s1nr1o265885@xreary.bet>
Thanks!
Best Regards,
Even Xu
> -----Original Message-----
> From: Jiri Kosina <jikos@kernel.org>
> Sent: Monday, August 11, 2025 7:39 PM
> To: Aaron, Ma <aaron.ma@canonical.com>
> Cc: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <xinpeng.sun@intel.com>;
> bentiss@kernel.org; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB
> length
>
> Both patches now applied to hid.git#for-6.17/upstream-fixes, thanks.
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: lg-g15 - Add support for Logitech G13.
From: kernel test robot @ 2025-08-12 0:00 UTC (permalink / raw)
To: Leo L. Schwab, Hans de Goede
Cc: oe-kbuild-all, Kate Hsuan, Leo L. Schwab, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20250810225617.1006272-2-ewhac@ewhac.org>
Hi Leo,
kernel test robot noticed the following build errors:
[auto build test ERROR on hid/for-next]
[also build test ERROR on linus/master v6.17-rc1 next-20250808]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Leo-L-Schwab/HID-lg-g15-Add-support-for-Logitech-G13/20250811-070633
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20250810225617.1006272-2-ewhac%40ewhac.org
patch subject: [PATCH] HID: lg-g15 - Add support for Logitech G13.
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20250812/202508120615.TGJUom52-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250812/202508120615.TGJUom52-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508120615.TGJUom52-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/hid/hid-lg-g15.c: In function 'lg_g13_event':
>> drivers/hid/hid-lg-g15.c:703:68: error: 'struct led_classdev' has no member named 'brightness_hw_changed'
703 | (!!TEST_BIT(rep->keybits, 23)) ^ (g15->leds[0].cdev.brightness_hw_changed > 0);
| ^
vim +703 drivers/hid/hid-lg-g15.c
665
666 static int lg_g13_event(struct lg_g15_data *g15, u8 const *data)
667 {
668 struct g13_input_report const * const rep = (struct g13_input_report *) data;
669 int i, val;
670 bool hw_brightness_changed;
671
672 /*
673 * Main macropad and menu keys.
674 * Emit key events defined for each bit position.
675 */
676 for (i = 0; i < ARRAY_SIZE(g13_keys_for_bits); ++i) {
677 if (g13_keys_for_bits[i]) {
678 val = TEST_BIT(rep->keybits, i);
679 input_report_key(g15->input, g13_keys_for_bits[i], val);
680 }
681 }
682 input_sync(g15->input);
683
684 /*
685 * Joystick.
686 * Emit button and deflection events.
687 */
688 for (i = 0; i < ARRAY_SIZE(g13_keys_for_bits_js); ++i) {
689 if (g13_keys_for_bits_js[i]) {
690 val = TEST_BIT(rep->keybits, i + 33);
691 input_report_key(g15->input_js, g13_keys_for_bits_js[i], val);
692 }
693 }
694 input_report_abs(g15->input_js, ABS_X, rep->joy_x);
695 input_report_abs(g15->input_js, ABS_Y, rep->joy_y);
696 input_sync(g15->input_js);
697
698 /*
699 * Bit 23 of keybits[] reports the current backlight on/off state. If
700 * it has changed from the last cached value, apply an update.
701 */
702 hw_brightness_changed =
> 703 (!!TEST_BIT(rep->keybits, 23)) ^ (g15->leds[0].cdev.brightness_hw_changed > 0);
704 if (hw_brightness_changed) {
705 led_classdev_notify_brightness_hw_changed(
706 &g15->leds[0].cdev,
707 TEST_BIT(rep->keybits, 23) ? LED_FULL : LED_OFF);
708 }
709
710 return 0;
711 }
712
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/6] Input: Add ABS_CLUTCH, HANDBRAKE, and SHIFTER
From: Vicki Pfau @ 2025-08-11 23:00 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <vh75qh4qit5dgq6jfwgdtpuwrjy6znifzmtwt5r6yuu5r5wxqn@5bwy7ygwvybe>
On 8/11/25 3:56 PM, Dmitry Torokhov wrote:
> On Thu, Aug 07, 2025 at 09:30:10PM -0700, Vicki Pfau wrote:
>> Add new absolute axes for racing game controllers
>>
>> Signed-off-by: Vicki Pfau <vi@endrift.com>
>> ---
>> drivers/hid/hid-debug.c | 16 +++++++++-------
>> include/uapi/linux/input-event-codes.h | 3 +++
>> 2 files changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
>> index 264eefaed08fb..534df8e4082da 100644
>> --- a/drivers/hid/hid-debug.c
>> +++ b/drivers/hid/hid-debug.c
>> @@ -3505,13 +3505,15 @@ static const char *absolutes[ABS_CNT] = {
>> [ABS_RY] = "Ry", [ABS_RZ] = "Rz",
>> [ABS_THROTTLE] = "Throttle", [ABS_RUDDER] = "Rudder",
>> [ABS_WHEEL] = "Wheel", [ABS_GAS] = "Gas",
>> - [ABS_BRAKE] = "Brake", [ABS_HAT0X] = "Hat0X",
>> - [ABS_HAT0Y] = "Hat0Y", [ABS_HAT1X] = "Hat1X",
>> - [ABS_HAT1Y] = "Hat1Y", [ABS_HAT2X] = "Hat2X",
>> - [ABS_HAT2Y] = "Hat2Y", [ABS_HAT3X] = "Hat3X",
>> - [ABS_HAT3Y] = "Hat 3Y", [ABS_PRESSURE] = "Pressure",
>> - [ABS_DISTANCE] = "Distance", [ABS_TILT_X] = "XTilt",
>> - [ABS_TILT_Y] = "YTilt", [ABS_TOOL_WIDTH] = "ToolWidth",
>> + [ABS_BRAKE] = "Brake", [ABS_CLUTCH] = "Clutch",
>> + [ABS_HANDBRAKE] = "Handbrake", [ABS_SHIFTER] = "Shifter",
>> + [ABS_HAT0X] = "Hat0X", [ABS_HAT0Y] = "Hat0Y",
>> + [ABS_HAT1X] = "Hat1X", [ABS_HAT1Y] = "Hat1Y",
>> + [ABS_HAT2X] = "Hat2X", [ABS_HAT2Y] = "Hat2Y",
>> + [ABS_HAT3X] = "Hat3X", [ABS_HAT3Y] = "Hat3Y",
>> + [ABS_PRESSURE] = "Pressure", [ABS_DISTANCE] = "Distance",
>> + [ABS_TILT_X] = "XTilt", [ABS_TILT_Y] = "YTilt",
>> + [ABS_TOOL_WIDTH] = "ToolWidth",
>> [ABS_VOLUME] = "Volume", [ABS_PROFILE] = "Profile",
>> [ABS_MISC] = "Misc",
>> [ABS_MT_SLOT] = "MTSlot",
>> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
>> index 08cb157ab5936..195139e895ffb 100644
>> --- a/include/uapi/linux/input-event-codes.h
>> +++ b/include/uapi/linux/input-event-codes.h
>> @@ -859,6 +859,9 @@
>> #define ABS_WHEEL 0x08
>> #define ABS_GAS 0x09
>> #define ABS_BRAKE 0x0a
>> +#define ABS_CLUTCH 0x0b
>> +#define ABS_HANDBRAKE 0x0c
>> +#define ABS_SHIFTER 0x0d
>
> We have BTN_GEAR_UP and BTN_GEAR_DOWN, can they be used?
The controller reports absolute values, not relative. If it were relative, BTN_GEAR_UP and BTN_GEAR_DOWN might make sense.
That said, I've been rethinking how to do mapping on both the wheel and flight stick, so I'm probably going go back to the drawing board on those. Feedback would still be nice, but I think the only one of these that might be mergeable as is is patch 1 (patch 2 was made against 6.16 by accident and does not apply to master). The shifter on Windows presents as individual buttons, one per gear, which is weird...but it's what games expect. Likewise, the dial presents as two buttons for the two relative values. I thought these methods were nonsensical (and I still do), but for compatibility reasons it might be better.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 3/6] Input: Add ABS_CLUTCH, HANDBRAKE, and SHIFTER
From: Dmitry Torokhov @ 2025-08-11 22:56 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20250808043017.1953101-4-vi@endrift.com>
On Thu, Aug 07, 2025 at 09:30:10PM -0700, Vicki Pfau wrote:
> Add new absolute axes for racing game controllers
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
> ---
> drivers/hid/hid-debug.c | 16 +++++++++-------
> include/uapi/linux/input-event-codes.h | 3 +++
> 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index 264eefaed08fb..534df8e4082da 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -3505,13 +3505,15 @@ static const char *absolutes[ABS_CNT] = {
> [ABS_RY] = "Ry", [ABS_RZ] = "Rz",
> [ABS_THROTTLE] = "Throttle", [ABS_RUDDER] = "Rudder",
> [ABS_WHEEL] = "Wheel", [ABS_GAS] = "Gas",
> - [ABS_BRAKE] = "Brake", [ABS_HAT0X] = "Hat0X",
> - [ABS_HAT0Y] = "Hat0Y", [ABS_HAT1X] = "Hat1X",
> - [ABS_HAT1Y] = "Hat1Y", [ABS_HAT2X] = "Hat2X",
> - [ABS_HAT2Y] = "Hat2Y", [ABS_HAT3X] = "Hat3X",
> - [ABS_HAT3Y] = "Hat 3Y", [ABS_PRESSURE] = "Pressure",
> - [ABS_DISTANCE] = "Distance", [ABS_TILT_X] = "XTilt",
> - [ABS_TILT_Y] = "YTilt", [ABS_TOOL_WIDTH] = "ToolWidth",
> + [ABS_BRAKE] = "Brake", [ABS_CLUTCH] = "Clutch",
> + [ABS_HANDBRAKE] = "Handbrake", [ABS_SHIFTER] = "Shifter",
> + [ABS_HAT0X] = "Hat0X", [ABS_HAT0Y] = "Hat0Y",
> + [ABS_HAT1X] = "Hat1X", [ABS_HAT1Y] = "Hat1Y",
> + [ABS_HAT2X] = "Hat2X", [ABS_HAT2Y] = "Hat2Y",
> + [ABS_HAT3X] = "Hat3X", [ABS_HAT3Y] = "Hat3Y",
> + [ABS_PRESSURE] = "Pressure", [ABS_DISTANCE] = "Distance",
> + [ABS_TILT_X] = "XTilt", [ABS_TILT_Y] = "YTilt",
> + [ABS_TOOL_WIDTH] = "ToolWidth",
> [ABS_VOLUME] = "Volume", [ABS_PROFILE] = "Profile",
> [ABS_MISC] = "Misc",
> [ABS_MT_SLOT] = "MTSlot",
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 08cb157ab5936..195139e895ffb 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -859,6 +859,9 @@
> #define ABS_WHEEL 0x08
> #define ABS_GAS 0x09
> #define ABS_BRAKE 0x0a
> +#define ABS_CLUTCH 0x0b
> +#define ABS_HANDBRAKE 0x0c
> +#define ABS_SHIFTER 0x0d
We have BTN_GEAR_UP and BTN_GEAR_DOWN, can they be used?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 8/8] usb: dt-bindings: ti,twlxxxx-usb: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL4030/6030 USB module
to the modern YAML DT schema format. This adds formal validation
and improves documentation using a conditional schema.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../bindings/usb/ti,twlxxxx-usb.yaml | 121 ++++++++++++++++++
.../devicetree/bindings/usb/twlxxxx-usb.txt | 43 -------
2 files changed, 121 insertions(+), 43 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/ti,twlxxxx-usb.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/ti,twlxxxx-usb.yaml b/Documentation/devicetree/bindings/usb/ti,twlxxxx-usb.yaml
new file mode 100644
index 000000000..029865ad2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,twlxxxx-usb.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,twlxxxx-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030/6030 USB PHY and Comparator
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ Bindings for the USB PHY and comparator module found within the
+ TWL4030 and TWL6030 family of companion chips.
+
+ TWL6030: USB COMPARATOR
+ TWL4030: USB COMPARATOR & PHY
+
+ If a sibling node is compatible with "ti,twl4030-bci", the driver for
+ that node will query this device for USB power status.
+
+properties:
+ compatible:
+ enum:
+ - ti,twl4030-usb
+ - ti,twl6030-usb
+
+ interrupts:
+ description: |
+ Interrupts for ID and VBUS events.
+ For "ti,twl6030-usb", two interrupts must be specified:
+ - The first is the OTG interrupt for ID events (host mode).
+ - The second is the USB interrupt for VBUS events (device mode).
+ For "ti,twl4030-usb", one or two interrupts can be specified:
+ - The first is the OTG interrupt for both ID and VBUS events.
+ - The second is optional.
+ minItems: 1
+ maxItems: 2
+
+ usb-supply:
+ description:
+ Phandle to the VUSB regulator. For TWL6030, this should be the 'vusb'
+ regulator. For TWL6032 subclass, it should be the 'ldousb' regulator.
+
+ usb1v5-supply:
+ description: Phandle to the VUSB1V5 regulator (for TWL4030).
+
+ usb1v8-supply:
+ description: Phandle to the VUSB1V8 regulator (for TWL4030).
+
+ usb3v1-supply:
+ description: Phandle to the USB3V1 regulator (for TWL4030).
+
+ usb_mode:
+ description: |
+ The mode used by the PHY (TWL4030 ONLY) to connect to the controller:
+ 1: ULPI mode
+ 2: CEA2011_3PIN mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6030-usb
+then:
+ required:
+ - usb-supply
+ properties:
+ interrupts:
+ minItems: 2
+else:
+ required:
+ - usb1v5-supply
+ - usb1v8-supply
+ - usb3v1-supply
+ - usb_mode
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl@48 {
+ reg = <0x48>;
+
+ usb_phy: usb-phy {
+ compatible = "ti,twl4030-usb";
+ interrupts = <10 4>; // Single interrupt: OTG (ID and VBUS events)
+ interrupt-parent = <&gic>;
+ usb1v5-supply = <®_vusb1v5>;
+ usb1v8-supply = <®_vusb1v8>;
+ usb3v1-supply = <®_vusb3v1>;
+ usb_mode = <1>;
+ };
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl@48 {
+ reg = <0x48>;
+
+ usb_comp: usb-phy {
+ compatible = "ti,twl6030-usb";
+ interrupts = <4 4>, <10 4>; // Two interrupts: OTG (ID events), USB (VBUS events)
+ interrupt-parent = <&gic>;
+ usb-supply = <®_vusb>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
deleted file mode 100644
index 17327a296..000000000
--- a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-USB COMPARATOR OF TWL CHIPS
-
-TWL6030 USB COMPARATOR
- - compatible : Should be "ti,twl6030-usb"
- - interrupts : Two interrupt numbers to the cpu should be specified. First
- interrupt number is the otg interrupt number that raises ID interrupts when
- the controller has to act as host and the second interrupt number is the
- usb interrupt number that raises VBUS interrupts when the controller has to
- act as device
- - usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6032 subclass.
-
-twl6030-usb {
- compatible = "ti,twl6030-usb";
- interrupts = < 4 10 >;
-};
-
-Board specific device node entry
-&twl6030-usb {
- usb-supply = <&vusb>;
-};
-
-TWL4030 USB PHY AND COMPARATOR
- - compatible : Should be "ti,twl4030-usb"
- - interrupts : The interrupt numbers to the cpu should be specified. First
- interrupt number is the otg interrupt number that raises ID interrupts
- and VBUS interrupts. The second interrupt number is optional.
- - <supply-name>-supply : phandle to the regulator device tree node.
- <supply-name> should be vusb1v5, vusb1v8 and vusb3v1
- - usb_mode : The mode used by the phy to connect to the controller. "1"
- specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.
-
-If a sibling node is compatible "ti,twl4030-bci", then it will find
-this device and query it for USB power status.
-
-twl4030-usb {
- compatible = "ti,twl4030-usb";
- interrupts = < 10 4 >;
- usb1v5-supply = <&vusb1v5>;
- usb1v8-supply = <&vusb1v8>;
- usb3v1-supply = <&vusb3v1>;
- usb_mode = <1>;
-};
--
2.39.5
^ permalink raw reply related
* [PATCH 7/8] sound: dt-bindings: ti,omap-twl4030: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the OMAP TWL4030 sound card
to the modern YAML DT schema format. This adds formal validation
and improves documentation.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../bindings/sound/omap-twl4030.txt | 62 -----------
.../bindings/sound/ti,omap-twl4030.yaml | 101 ++++++++++++++++++
2 files changed, 101 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/omap-twl4030.txt
create mode 100644 Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
deleted file mode 100644
index f6a715e4e..000000000
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Texas Instruments SoC with twl4030 based audio setups
-
-Required properties:
-- compatible: "ti,omap-twl4030"
-- ti,model: Name of the sound card (for example "omap3beagle")
-- ti,mcbsp: phandle for the McBSP node
-
-Optional properties:
-- ti,codec: phandle for the twl4030 audio node
-- ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
-- ti, jack-det-gpio: Jack detect GPIO
-- ti,audio-routing: List of connections between audio components.
- Each entry is a pair of strings, the first being the connection's sink,
- the second being the connection's source.
- If the routing is not provided all possible connection will be available
-
-Available audio endpoints for the audio-routing table:
-
-Board connectors:
- * Headset Stereophone
- * Earpiece Spk
- * Handsfree Spk
- * Ext Spk
- * Main Mic
- * Sub Mic
- * Headset Mic
- * Carkit Mic
- * Digital0 Mic
- * Digital1 Mic
- * Line In
-
-twl4030 pins:
- * HSOL
- * HSOR
- * EARPIECE
- * HFL
- * HFR
- * PREDRIVEL
- * PREDRIVER
- * CARKITL
- * CARKITR
- * MAINMIC
- * SUBMIC
- * HSMIC
- * DIGIMIC0
- * DIGIMIC1
- * CARKITMIC
- * AUXL
- * AUXR
-
- * Headset Mic Bias
- * Mic Bias 1 /* Used for Main Mic or Digimic0 */
- * Mic Bias 2 /* Used for Sub Mic or Digimic1 */
-
-Example:
-
-sound {
- compatible = "ti,omap-twl4030";
- ti,model = "omap3beagle";
-
- ti,mcbsp = <&mcbsp2>;
-};
diff --git a/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml b/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
new file mode 100644
index 000000000..3124320d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,omap-twl4030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments SoC with twl4030 based audio setups
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description:
+ Bindings for audio setups on TI OMAP SoCs using TWL4030-family audio codec connected via a McBSP port.
+
+properties:
+ compatible:
+ const: ti,omap-twl4030
+
+ ti,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Name of the sound card (for example "omap3beagle").
+
+ ti,mcbsp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle for the McBSP node.
+
+ ti,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle for the twl4030 audio node.
+
+ ti,mcbsp-voice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the McBSP node connected to the voice port.
+
+ ti,jack-det-gpio:
+ description: GPIO specifier for jack detection.
+ maxItems: 1
+
+ ti,audio-routing:
+ description: |
+ A list of audio routing connections. Each entry is a pair of strings,
+ with the first being the connection's sink and the second being the
+ source. If not provided, all possible connections are available.
+
+ Available TWL4030 Pins: "HFL", "HFR",
+ "PREDRIVEL", "PREDRIVER", "CARKITL", "CARKITR", "MAINMIC", "SUBMIC",
+ "HSMIC", "DIGIMIC0", "DIGIMIC1", "CARKITMIC", "AUXL", "AUXR",
+ "Headset Mic Bias", "Mic Bias 1", "Mic Bias 2"
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ items:
+ enum:
+ # Board Connectors
+ - Headset Stereophone
+ - Earpiece Spk
+ - Handsfree Spk
+ - Ext Spk
+ - Main Mic
+ - Sub Mic
+ - Headset Mic
+ - Carkit Mic
+ - Digital0 Mic
+ - Digital1 Mic
+ - Line In
+
+ # CODEC Pins
+ - HSOL
+ - HSOR
+ - EARPIECE
+ - HFL
+ - HFR
+ - PREDRIVEL
+ - PREDRIVER
+ - CARKITL
+ - CARKITR
+ - MAINMIC
+ - SUBMIC
+ - HSMIC
+ - DIGIMIC0
+ - DIGIMIC1
+ - CARKITMIC
+ - AUXL
+ - AUXR
+
+ # Headset Mic Bias
+ - Mic Bias 1 # Used for Main Mic or Digimic0
+ - Mic Bias 2 # Used for Sub Mic or Digimic1
+
+required:
+ - compatible
+ - ti,model
+ - ti,mcbsp
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "ti,omap-twl4030";
+ ti,model = "omap3beagle";
+ ti,mcbsp = <&mcbsp2>;
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH 6/8] pwm: dt-bindings: ti,twl-pwmled: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL-family PWMLED controller
to the modern YAML DT schema format. This adds formal validation
and improves documentation by inheriting from the base pwm schema.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../devicetree/bindings/pwm/ti,twl-pwmled.txt | 17 -------
.../bindings/pwm/ti,twl-pwmled.yaml | 46 +++++++++++++++++++
2 files changed, 46 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.yaml
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
deleted file mode 100644
index 31ca1b032..000000000
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Texas Instruments TWL series PWM drivers connected to LED terminals
-
-Supported PWMs:
-On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
-On TWL6030 series: LED PWM (mainly used as charging indicator LED)
-
-Required properties:
-- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-twl_pwmled: pwmled {
- compatible = "ti,twl6030-pwmled";
- #pwm-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.yaml b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.yaml
new file mode 100644
index 000000000..411cc4c8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/ti,twl-pwmled.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030/TWL6030 family PWM LED controller
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ Bindings for the following PWM controllers :
+ TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
+ TWL6030 series: LED PWM (mainly used as charging indicator LED)
+
+allOf:
+ - $ref: /schemas/pwm/pwm.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,twl4030-pwmled
+ - ti,twl6030-pwmled
+
+ '#pwm-cells':
+ const: 2
+
+required:
+ - compatible
+ - '#pwm-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm {
+ compatible = "ti,twl4030-pwmled";
+ #pwm-cells = <2>;
+ };
+
+ - |
+ pwm {
+ compatible = "ti,twl6030-pwmled";
+ #pwm-cells = <2>;
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH 5/8] pwm: dt-bindings: ti,twl-pwm: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL-family PWM controller
to the modern YAML DT schema format. This adds formal validation
and improves documentation by inheriting from the base pwm schema.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../devicetree/bindings/pwm/ti,twl-pwm.txt | 17 -------
.../devicetree/bindings/pwm/ti,twl-pwm.yaml | 46 +++++++++++++++++++
2 files changed, 46 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
deleted file mode 100644
index d97ca1964..000000000
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Texas Instruments TWL series PWM drivers
-
-Supported PWMs:
-On TWL4030 series: PWM1 and PWM2
-On TWL6030 series: PWM0 and PWM1
-
-Required properties:
-- compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-twl_pwm: pwm {
- compatible = "ti,twl6030-pwm";
- #pwm-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.yaml b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.yaml
new file mode 100644
index 000000000..5bbbdc13a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/ti,twl-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030/TWL6030 family PWM controller
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ Bindings for the following PWM controllers :
+ TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
+ TWL6030 series: LED PWM (mainly used as charging indicator LED)
+
+allOf:
+ - $ref: /schemas/pwm/pwm.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,twl4030-pwm
+ - ti,twl6030-pwm
+
+ '#pwm-cells':
+ const: 2
+
+required:
+ - compatible
+ - '#pwm-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm {
+ compatible = "ti,twl4030-pwm";
+ #pwm-cells = <2>;
+ };
+
+ - |
+ pwm {
+ compatible = "ti,twl6030-pwm";
+ #pwm-cells = <2>;
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH 4/8] mfd: dt-bindings: ti,twl4030-power: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL4030 power module
to the modern YAML DT schema format. This adds formal validation
and improves documentation.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../bindings/mfd/ti,twl4030-power.yaml | 69 +++++++++++++++++++
.../devicetree/bindings/mfd/twl4030-power.txt | 48 -------------
2 files changed, 69 insertions(+), 48 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl4030-power.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/twl4030-power.txt
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl4030-power.yaml b/Documentation/devicetree/bindings/mfd/ti,twl4030-power.yaml
new file mode 100644
index 000000000..c95b3f705
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,twl4030-power.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,twl4030-power.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030-family Power Management Module
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ The power management module inside the TWL family provides several facilities
+ to control the power resources, including power scripts. For now, the
+ binding only supports the complete shutdown of the system after poweroff.
+
+properties:
+ compatible:
+ description: |
+ The compatible string determines the specific power configuration.
+ "ti,twl4030-power": Standard power control.
+ "ti,twl4030-power-reset": Recommended for OMAP3530 and similar SoCs
+ that require a special configuration for warm reset to work correctly.
+ "ti,twl4030-power-idle": Loads the TI-recommended configuration for
+ idle modes into the PMIC.
+ "ti,twl4030-power-idle-osc-off": Uses the recommended idle configuration
+ but also shuts down the external oscillator. This may not work on all
+ boards depending on the oscillator wiring.
+
+ enum:
+ - ti,twl4030-power
+ - ti,twl4030-power-reset
+ - ti,twl4030-power-idle
+ - ti,twl4030-power-idle-osc-off
+
+ ti,system-power-controller:
+ type: boolean
+ description:
+ Indicates that the TWL4030 is the power supply master of the system,
+ allowing it to initiate system power-off.
+
+ ti,use_poweroff:
+ type: boolean
+ description: Deprecated name for ti,system-power-controller.
+ deprecated: true
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ clock-frequency = <2600000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_power: power {
+ compatible = "ti,twl4030-power";
+ ti,use_poweroff;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
deleted file mode 100644
index 3d1996331..000000000
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Texas Instruments TWL family (twl4030) reset and power management module
-
-The power management module inside the TWL family provides several facilities
-to control the power resources, including power scripts. For now, the
-binding only supports the complete shutdown of the system after poweroff.
-
-Required properties:
-- compatible : must be one of the following
- "ti,twl4030-power"
- "ti,twl4030-power-reset"
- "ti,twl4030-power-idle"
- "ti,twl4030-power-idle-osc-off"
-
-The use of ti,twl4030-power-reset is recommended at least on
-3530 that needs a special configuration for warm reset to work.
-
-When using ti,twl4030-power-idle, the TI recommended configuration
-for idle modes is loaded to the tlw4030 PMIC.
-
-When using ti,twl4030-power-idle-osc-off, the TI recommended
-configuration is used with the external oscillator being shut
-down during off-idle. Note that this does not work on all boards
-depending on how the external oscillator is wired.
-
-Optional properties:
-
-- ti,system-power-controller: This indicates that TWL4030 is the
- power supply master of the system. With this flag, the chip will
- initiate an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
- system poweroffs.
-
-- ti,use_poweroff: Deprecated name for ti,system-power-controller
-
-Example:
-&i2c1 {
- clock-frequency = <2600000>;
-
- twl: twl@48 {
- reg = <0x48>;
- interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
-
- twl_power: power {
- compatible = "ti,twl4030-power";
- ti,use_poweroff;
- };
- };
-};
--
2.39.5
^ permalink raw reply related
* [PATCH 3/8] input: dt-bindings: ti,twl4030-keypad: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL4030 keypad module
to the modern YAML DT schema format. This adds formal validation
and improves documentation by inheriting from the matrix-keymap schema.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../bindings/input/ti,twl4030-keypad.yaml | 44 +++++++++++++++++++
.../bindings/input/twl4030-keypad.txt | 27 ------------
2 files changed, 44 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,twl4030-keypad.yaml
delete mode 100644 Documentation/devicetree/bindings/input/twl4030-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/ti,twl4030-keypad.yaml b/Documentation/devicetree/bindings/input/ti,twl4030-keypad.yaml
new file mode 100644
index 000000000..a7c4916b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,twl4030-keypad.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,twl4030-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030-family Keypad Controller
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ TWL4030's Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+
+properties:
+ compatible:
+ const: ti,twl4030-keypad
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - keypad,num-rows
+ - keypad,num-columns
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ keypad {
+ compatible = "ti,twl4030-keypad";
+ interrupts = <1>;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ };
diff --git a/Documentation/devicetree/bindings/input/twl4030-keypad.txt b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
deleted file mode 100644
index e4be2f76a..000000000
--- a/Documentation/devicetree/bindings/input/twl4030-keypad.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* TWL4030's Keypad Controller device tree bindings
-
-TWL4030's Keypad controller is used to interface a SoC with a matrix-type
-keypad device. The keypad controller supports multiple row and column lines.
-A key can be placed at each intersection of a unique row and a unique column.
-The keypad controller can sense a key-press and key-release and report the
-event using a interrupt to the cpu.
-
-This binding is based on the matrix-keymap binding with the following
-changes:
-
- * keypad,num-rows and keypad,num-columns are required.
-
-Required SoC Specific Properties:
-- compatible: should be one of the following
- - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad
- controller.
-- interrupt: should be one of the following
- - <1>: For controllers compatible with twl4030 keypad controller.
-
-Example:
- twl_keypad: keypad {
- compatible = "ti,twl4030-keypad";
- interrupts = <1>;
- keypad,num-rows = <8>;
- keypad,num-columns = <8>;
- };
--
2.39.5
^ permalink raw reply related
* [PATCH 2/8] mfd: dt-bindings: ti,twl6040: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL6040 MFD
to the modern YAML DT schema format. This adds formal validation
and improves documentation.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../devicetree/bindings/mfd/ti,twl6040.yaml | 155 ++++++++++++++++++
.../devicetree/bindings/mfd/twl6040.txt | 67 --------
2 files changed, 155 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/twl6040.txt
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml b/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
new file mode 100644
index 000000000..305dc1676
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,twl6040.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL6040/TWL6041 Audio Codec
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
+ vibra and GPO functionality on OMAP4+ platforms.
+ They are connected to the host processor via i2c for commands, McPDM for audio
+ data and commands.
+
+properties:
+ compatible:
+ enum:
+ - ti,twl6040
+ - ti,twl6041
+
+ reg:
+ const: 0x4b
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 1
+
+ '#clock-cells':
+ description: TWL6040 is a provider of PDMCLK which is used by McPDM.
+ const: 0
+
+ twl6040,audpwron-gpio:
+ description: The GPIO specifier for the audio power-on line.
+ maxItems: 1
+
+ vio-supply:
+ description: Regulator for the VIO supply.
+
+ v2v1-supply:
+ description: Regulator for the V2V1 supply.
+
+ enable-active-high:
+ type: boolean
+ description: If present, powers on the device during boot.
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [clk32k, mclk]
+
+ # Vibra functionality :
+
+ vddvibl-supply:
+ description: Regulator for the left vibra motor supply.
+
+ vddvibr-supply:
+ description: Regulator for the right vibra motor supply.
+
+ vibra:
+ type: object
+ description: Node for vibra motor configuration parameters.
+ properties:
+ ti,vibldrv-res:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Resistance parameter for the left driver.
+
+ ti,vibrdrv-res:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Resistance parameter for the right driver.
+
+ ti,viblmotor-res:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Resistance parameter for the left motor.
+
+ ti,vibrmotor-res:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Resistance parameter for the right motor.
+
+ vddvibl_uV:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Optional override for the VDDVIBL default voltage in microvolts.
+
+ vddvibr_uV:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Optional override for the VDDVIBR default voltage in microvolts.
+ required:
+ - ti,vibldrv-res
+ - ti,vibrdrv-res
+ - ti,viblmotor-res
+ - ti,vibrmotor-res
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - gpio-controller
+ - '#gpio-cells'
+ - '#clock-cells'
+ - twl6040,audpwron-gpio
+ - vio-supply
+ - v2v1-supply
+ - vddvibl-supply
+ - vddvibr-supply
+ - vibra
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl6040: twl@4b {
+ compatible = "ti,twl6040";
+ reg = <0x4b>;
+
+ interrupts = <0 119 4>;
+ interrupt-parent = <&gic>;
+
+ gpio-controller;
+ #gpio-cells = <1>;
+ #clock-cells = <0>;
+ twl6040,audpwron-gpio = <&gpio4 31 0>;
+
+ vio-supply = <&v1v8>;
+ v2v1-supply = <&v2v1>;
+ enable-active-high;
+
+ /* regulators for vibra motor */
+ vddvibl-supply = <&vbat>;
+ vddvibr-supply = <&vbat>;
+
+ vibra {
+ /* Vibra driver, motor resistance parameters */
+ ti,vibldrv-res = <8>;
+ ti,vibrdrv-res = <3>;
+ ti,viblmotor-res = <10>;
+ ti,vibrmotor-res = <10>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt
deleted file mode 100644
index dfd8683ed..000000000
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-Texas Instruments TWL6040 family
-
-The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
-vibra and GPO functionality on OMAP4+ platforms.
-They are connected to the host processor via i2c for commands, McPDM for audio
-data and commands.
-
-Required properties:
-- compatible : "ti,twl6040" for twl6040, "ti,twl6041" for twl6041
-- reg: must be 0x4b for i2c address
-- interrupts: twl6040 has one interrupt line connecteded to the main SoC
-- gpio-controller:
-- #gpio-cells = <1>: twl6040 provides GPO lines.
-- #clock-cells = <0>; twl6040 is a provider of pdmclk which is used by McPDM
-- twl6040,audpwron-gpio: Power on GPIO line for the twl6040
-
-- vio-supply: Regulator for the twl6040 VIO supply
-- v2v1-supply: Regulator for the twl6040 V2V1 supply
-
-Optional properties, nodes:
-- enable-active-high: To power on the twl6040 during boot.
-- clocks: phandle to the clk32k and/or to mclk clock provider
-- clock-names: Must be "clk32k" for the 32K clock and "mclk" for the MCLK.
-
-Vibra functionality
-Required properties:
-- vddvibl-supply: Regulator for the left vibra motor
-- vddvibr-supply: Regulator for the right vibra motor
-- vibra { }: Configuration section for vibra parameters containing the following
- properties:
-- ti,vibldrv-res: Resistance parameter for left driver
-- ti,vibrdrv-res: Resistance parameter for right driver
-- ti,viblmotor-res: Resistance parameter for left motor
-- ti,viblmotor-res: Resistance parameter for right motor
-
-Optional properties within vibra { } section:
-- vddvibl_uV: If the vddvibl default voltage need to be changed
-- vddvibr_uV: If the vddvibr default voltage need to be changed
-
-Example:
-&i2c1 {
- twl6040: twl@4b {
- compatible = "ti,twl6040";
-
- interrupts = <0 119 4>;
- interrupt-parent = <&gic>;
- twl6040,audpwron-gpio = <&gpio4 31 0>;
-
- vio-supply = <&v1v8>;
- v2v1-supply = <&v2v1>;
- enable-active-high;
-
- /* regulators for vibra motor */
- vddvibl-supply = <&vbat>;
- vddvibr-supply = <&vbat>;
-
- vibra {
- /* Vibra driver, motor resistance parameters */
- ti,vibldrv-res = <8>;
- ti,vibrdrv-res = <3>;
- ti,viblmotor-res = <10>;
- ti,vibrmotor-res = <10>;
- };
- };
-};
-
-/include/ "twl6040.dtsi"
--
2.39.5
^ permalink raw reply related
* [PATCH 1/8] mfd: dt-bindings: ti,twl4030-audio: convert to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
In-Reply-To: <20250811224739.53869-1-jihed.chaibi.dev@gmail.com>
Convert the legacy TXT binding for the TWL4030 audio module
to the modern YAML DT schema format. This adds formal validation
and improves documentation.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
.../bindings/mfd/ti,twl4030-audio.yaml | 91 +++++++++++++++++++
.../devicetree/bindings/mfd/twl4030-audio.txt | 46 ----------
2 files changed, 91 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl4030-audio.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/twl4030-audio.txt
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl4030-audio.yaml b/Documentation/devicetree/bindings/mfd/ti,twl4030-audio.yaml
new file mode 100644
index 000000000..16ddcf007
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,twl4030-audio.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,twl4030-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030-family Audio Module
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description: |
+ The audio module within the TWL4030-family of companion chips consists
+ of an audio codec and a vibra driver. This binding describes the parent
+ node for these functions.
+
+properties:
+ compatible:
+ const: ti,twl4030-audio
+
+ codec:
+ type: object
+ description: Node containing properties for the audio codec functionality.
+ properties:
+ ti,digimic_delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay in milliseconds after enabling digital microphones to reduce
+ artifacts.
+
+ ti,ramp_delay_value:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Headset ramp delay configuration to reduce pop noise.
+
+ ti,hs_extmute:
+ type: boolean
+ description:
+ Enable the use of an external mute for headset pop reduction.
+
+ ti,hs_extmute_gpio:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ The GPIO specifier for the external mute control.
+ maxItems: 1
+
+ ti,offset_cncl_path:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset cancellation path selection. Refer to the Technical
+ Reference Manual for valid values.
+
+ # The 'codec' node itself is optional, but if it exists, it can be empty.
+ # We don't require any of its sub-properties.
+
+ ti,enable-vibra:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Set to 1 to enable the vibra functionality, if missing
+ or it is 0, the vibra functionality is disabled.
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ i2c {
+
+ clock-frequency = <2600000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_audio: audio {
+ compatible = "ti,twl4030-audio";
+
+ ti,enable-vibra = <1>;
+
+ codec {
+ ti,ramp_delay_value = <3>;
+ };
+
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
deleted file mode 100644
index 414d2ae0a..000000000
--- a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Texas Instruments TWL family (twl4030) audio module
-
-The audio module inside the TWL family consist of an audio codec and a vibra
-driver.
-
-Required properties:
-- compatible : must be "ti,twl4030-audio"
-
-Optional properties, nodes:
-
-Audio functionality:
-- codec { }: Need to be present if the audio functionality is used. Within this
- section the following options can be used:
-- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts
- from the start of the recorded sample (in ms)
--ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise
--ti,hs_extmute: Use external mute for HS pop reduction
--ti,hs_extmute_gpio: Use external GPIO to control the external mute
--ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
- valid values.
-
-Vibra functionality
-- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
- missing or it is 0, the vibra functionality is disabled.
-
-Example:
-&i2c1 {
- clock-frequency = <2600000>;
-
- twl: twl@48 {
- reg = <0x48>;
- interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
-
- twl_audio: audio {
- compatible = "ti,twl4030-audio";
-
- ti,enable-vibra = <1>;
-
- codec {
- ti,ramp_delay_value = <3>;
- };
-
- };
- };
-};
--
2.39.5
^ permalink raw reply related
* [PATCH 0/8] dt-bindings: Convert TWL4030/6040 family binding to DT schema
From: Jihed Chaibi @ 2025-08-11 22:47 UTC (permalink / raw)
To: linux-kernel
Cc: peter.ujfalusi, dmitry.torokhov, robh, krzk+dt, lgirdwood, tiwai,
conor+dt, lee, ukleinek, broonie, gregkh, linux-input, devicetree,
linux-pwm, linux-sound, linux-usb, shuah, jihed.chaibi.dev
Hello,
This series modernizes the Device Tree bindings for the Texas
Instruments TWL4030/TWL6040 family by converting all remaining
legacy TXT bindings to the structured YAML DT schema format.
This improves the bindings by adding formal type checking, clear property
definitions, and machine-readable examples, which allows for automated
validation and better documentation for developers.
The following eight patches are included in this series, covering the
audio, keypad, power, PWM, and USB sub-modules.
Thank you,
Jihed Chaibi (8):
mfd: dt-bindings: ti,twl4030-audio: convert to DT schema
mfd: dt-bindings: ti,twl6040: convert to DT schema
input: dt-bindings: ti,twl4030-keypad: convert to DT schema
mfd: dt-bindings: ti,twl4030-power: convert to DT schema
pwm: dt-bindings: ti,twl-pwm: convert to DT schema
pwm: dt-bindings: ti,twl-pwmled: convert to DT schema
sound: dt-bindings: ti,omap-twl4030: convert to DT schema
usb: dt-bindings: ti,twlxxxx-usb: convert to DT schema
.../bindings/input/ti,twl4030-keypad.yaml | 44 +++++
.../bindings/input/twl4030-keypad.txt | 27 ---
.../bindings/mfd/ti,twl4030-audio.yaml | 91 ++++++++++
.../bindings/mfd/ti,twl4030-power.yaml | 69 ++++++++
.../devicetree/bindings/mfd/ti,twl6040.yaml | 155 ++++++++++++++++++
.../devicetree/bindings/mfd/twl4030-audio.txt | 46 ------
.../devicetree/bindings/mfd/twl4030-power.txt | 48 ------
.../devicetree/bindings/mfd/twl6040.txt | 67 --------
.../devicetree/bindings/pwm/ti,twl-pwm.txt | 17 --
.../devicetree/bindings/pwm/ti,twl-pwm.yaml | 46 ++++++
.../devicetree/bindings/pwm/ti,twl-pwmled.txt | 17 --
.../bindings/pwm/ti,twl-pwmled.yaml | 46 ++++++
.../bindings/sound/omap-twl4030.txt | 62 -------
.../bindings/sound/ti,omap-twl4030.yaml | 101 ++++++++++++
.../bindings/usb/ti,twlxxxx-usb.yaml | 121 ++++++++++++++
.../devicetree/bindings/usb/twlxxxx-usb.txt | 43 -----
16 files changed, 673 insertions(+), 327 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,twl4030-keypad.yaml
delete mode 100644 Documentation/devicetree/bindings/input/twl4030-keypad.txt
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl4030-audio.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl4030-power.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/twl4030-audio.txt
delete mode 100644 Documentation/devicetree/bindings/mfd/twl4030-power.txt
delete mode 100644 Documentation/devicetree/bindings/mfd/twl6040.txt
delete mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/omap-twl4030.txt
create mode 100644 Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
create mode 100644 Documentation/devicetree/bindings/usb/ti,twlxxxx-usb.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
--
2.39.5
^ permalink raw reply
* Re: [PATCH v2] platform/x86: Add WMI driver for Redmibook keyboard.
From: foxidokun @ 2025-08-11 21:23 UTC (permalink / raw)
To: dmitry.torokhov
Cc: foxido, hansg, ilpo.jarvinen, linux-input, linux-kernel,
nikita.nikita.krasnov, platform-driver-x86, w_armin
In-Reply-To: <5e32uo4suh3mtib4tohtekwvycxgfzqcem3wwc6k6wwdxyjhpc@bt57y7vyvpmz>
> > + /* For linearizability */
> > + guard(mutex)(&data->key_lock);
>
> What is the exact purpose of this mutex? What does it protect?
It protects key sequence, so there wouldn't be race between two press & release combinations resuulting into press - press - release - release order.
--
Gladyshev Ilya
^ permalink raw reply
* Re: [PATCH v3] gpiolib: acpi: Program debounce when finding GPIO
From: Mario Limonciello @ 2025-08-11 21:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Hans de Goede, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, open list:GPIO ACPI SUPPORT,
open list:GPIO ACPI SUPPORT,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <aJpVw39tBNkEtkgZ@smile.fi.intel.com>
On 8/11/25 3:42 PM, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 11:43:56AM -0500, Mario Limonciello (AMD) wrote:
>> When soc-button-array looks up the GPIO to use it calls acpi_find_gpio()
>> which will parse _CRS.
>>
>> acpi_find_gpio.cold (drivers/gpio/gpiolib-acpi-core.c:953)
>> gpiod_find_and_request (drivers/gpio/gpiolib.c:4598 drivers/gpio/gpiolib.c:4625)
>> gpiod_get_index (drivers/gpio/gpiolib.c:4877)
>>
>> The GPIO is setup basically, but the debounce information is discarded.
>> The platform will assert what debounce should be in _CRS, so program it
>> at the time it's available.
>>
>> As this is considered non fatal if it fails, introduce a helper for
>> programming debounce and show a warning when failing to program.
>
> I think I already commented on this previously. Let me do that below anyway.
>
> ...
>
>
>> +static void acpi_set_debounce_timeout(struct gpio_desc *desc, unsigned int timeout)
>> +{
>> + int ret;
>> +
>> + /* ACPI uses hundredths of milliseconds units */
>> + ret = gpio_set_debounce_timeout(desc, timeout * 10);
>> + if (ret)
>> + dev_warn(&desc->gdev->dev,
>> + "Failed to set debounce-timeout: %d\n", ret);
>> +}
>
> I would make it still return the code to the caller. See below why.
>
>
> ...
>
>> - /* ACPI uses hundredths of milliseconds units */
>> - ret = gpio_set_debounce_timeout(desc, info.debounce * 10);
>> - if (ret)
>> - return ret;
>> + acpi_set_debounce_timeout(desc, info.debounce);
>
> The commit message fails to explain why we do relax the condition here. This is
> about GpioInt() resource and so far I haven't heard about misused debounce
> values there. If we drop the fatality, it has to be a separate patch explaining
> why. But only if we have practical use cases. AS long as there no failed
> platforms, I can't agree on this piece of change.
>
Thanks for the feedback. I thought that I got your feedback the first
time when I originally squashed, but I must have failed.
In that case I don't think we really need a helper at all. I'll change
it for v4 to just add the extra call without the use of a helper.
^ permalink raw reply
* Re: [PATCH v3] gpiolib: acpi: Program debounce when finding GPIO
From: Andy Shevchenko @ 2025-08-11 20:42 UTC (permalink / raw)
To: Mario Limonciello (AMD)
Cc: Hans de Goede, Mika Westerberg, Linus Walleij,
Bartosz Golaszewski, open list:GPIO ACPI SUPPORT,
open list:GPIO ACPI SUPPORT,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <20250811164356.613840-1-superm1@kernel.org>
On Mon, Aug 11, 2025 at 11:43:56AM -0500, Mario Limonciello (AMD) wrote:
> When soc-button-array looks up the GPIO to use it calls acpi_find_gpio()
> which will parse _CRS.
>
> acpi_find_gpio.cold (drivers/gpio/gpiolib-acpi-core.c:953)
> gpiod_find_and_request (drivers/gpio/gpiolib.c:4598 drivers/gpio/gpiolib.c:4625)
> gpiod_get_index (drivers/gpio/gpiolib.c:4877)
>
> The GPIO is setup basically, but the debounce information is discarded.
> The platform will assert what debounce should be in _CRS, so program it
> at the time it's available.
>
> As this is considered non fatal if it fails, introduce a helper for
> programming debounce and show a warning when failing to program.
I think I already commented on this previously. Let me do that below anyway.
...
> +static void acpi_set_debounce_timeout(struct gpio_desc *desc, unsigned int timeout)
> +{
> + int ret;
> +
> + /* ACPI uses hundredths of milliseconds units */
> + ret = gpio_set_debounce_timeout(desc, timeout * 10);
> + if (ret)
> + dev_warn(&desc->gdev->dev,
> + "Failed to set debounce-timeout: %d\n", ret);
> +}
I would make it still return the code to the caller. See below why.
...
> - /* ACPI uses hundredths of milliseconds units */
> - ret = gpio_set_debounce_timeout(desc, info.debounce * 10);
> - if (ret)
> - return ret;
> + acpi_set_debounce_timeout(desc, info.debounce);
The commit message fails to explain why we do relax the condition here. This is
about GpioInt() resource and so far I haven't heard about misused debounce
values there. If we drop the fatality, it has to be a separate patch explaining
why. But only if we have practical use cases. AS long as there no failed
platforms, I can't agree on this piece of change.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional
From: Andy Shevchenko @ 2025-08-11 20:09 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Matti Vaittinen, Arnd Bergmann, Bartosz Golaszewski,
Linus Walleij, linux-gpio, Lee Jones, Arnd Bergmann,
Gatien Chevallier, Fabrice Gasnier, Bartosz Golaszewski,
Thomas Gleixner, Charles Keepax, Krzysztof Kozlowski,
Christophe JAILLET, linux-input, linux-kernel
In-Reply-To: <mrqxggv7vhclnranoc3uacfyzccod6dmc54kip4f7wjdpngjzz@falnsjwnfcjc>
On Mon, Aug 11, 2025 at 12:21:51PM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
> > On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
> > > On 08/08/2025 18:17, Arnd Bergmann wrote:
...
> > > As such, this patch seems Ok to me, you can treat this as an ack :) This,
> > > however made me ponder following - is this the tight way to handle the
> > > power-button IRQ? I don't see any other MFD devices doing this in same way,
> > > although I am pretty sure there are other PMICs with similar power-button
> > > IRQ...
> > >
> > > I see for example the "drivers/mfd/rt5120.c" to invoke
> > > "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
> > > however, feels like code duplication to me. I'd rather kept using the
> > > gpio-keys, but seeing:
> > >
> > > git grep KEY_POWER drivers/mfd/
> > > drivers/mfd/rohm-bd71828.c: .code = KEY_POWER,
> > > drivers/mfd/rohm-bd718x7.c: .code = KEY_POWER,
> > >
> > > makes me wonder if there is more widely used (better) way?
> >
> > FWIW, on Intel platforms that use power button by PMIC we add a special driver
> > for each of such cases.
>
> If we can make gpio-keys work for various power buttons that would be
> great IMO. The MFD drivers in question already are using device tree,
> but they do not define/expect nodes for the power buttons. If the nodes
> were there then I think gpio-keys would work out of the box?
Looking at the, e.g., https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/x86/intel/mrfld_pwrbtn.c,
I am not sure it's as simply as it sounds. Basically it's an IRQ, which
requires IRQ handling and proper acking/masking/etc.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 09/21] input: gpio-keys: make legacy gpiolib optional
From: Dmitry Torokhov @ 2025-08-11 19:21 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Matti Vaittinen, Arnd Bergmann, Bartosz Golaszewski,
Linus Walleij, linux-gpio, Lee Jones, Arnd Bergmann,
Gatien Chevallier, Fabrice Gasnier, Bartosz Golaszewski,
Thomas Gleixner, Charles Keepax, Krzysztof Kozlowski,
Christophe JAILLET, linux-input, linux-kernel
In-Reply-To: <aJnng9z9pUTFI49x@smile.fi.intel.com>
On Mon, Aug 11, 2025 at 03:52:19PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 11, 2025 at 01:34:43PM +0300, Matti Vaittinen wrote:
> > On 08/08/2025 18:17, Arnd Bergmann wrote:
>
> ...
>
> > As such, this patch seems Ok to me, you can treat this as an ack :) This,
> > however made me ponder following - is this the tight way to handle the
> > power-button IRQ? I don't see any other MFD devices doing this in same way,
> > although I am pretty sure there are other PMICs with similar power-button
> > IRQ...
> >
> > I see for example the "drivers/mfd/rt5120.c" to invoke
> > "drivers/input/misc/rt5120-pwrkey.c" instead of using the gpio-keys. This,
> > however, feels like code duplication to me. I'd rather kept using the
> > gpio-keys, but seeing:
> >
> > git grep KEY_POWER drivers/mfd/
> > drivers/mfd/rohm-bd71828.c: .code = KEY_POWER,
> > drivers/mfd/rohm-bd718x7.c: .code = KEY_POWER,
> >
> > makes me wonder if there is more widely used (better) way?
>
> FWIW, on Intel platforms that use power button by PMIC we add a special driver
> for each of such cases.
If we can make gpio-keys work for various power buttons that would be
great IMO. The MFD drivers in question already are using device tree,
but they do not define/expect nodes for the power buttons. If the nodes
were there then I think gpio-keys would work out of the box?
Thanks.
--
Dmitry
^ 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