* [PATCH 0/3] ARM: dts: imx: clean imx25 tsadc related CHECK_DTBS warnings
From: Frank Li @ 2026-02-11 21:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lee Jones
Cc: linux-input, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li
Clean imx25 tsadc related warnings.
- convert txt to yaml.
- rename nodename to touchscreen.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (3):
dt-bindings: input: touchscreen: convert fsl-mx25-tcq.txt to yaml
dt-bindings: mfd: convert fsl-imx25-tsadc.txt to yaml format
ARM: dts: imx25: rename node name tcq to touchscreen
.../bindings/input/touchscreen/fsl,imx25-tcq.yaml | 69 +++++++++++++++
.../bindings/input/touchscreen/fsl-mx25-tcq.txt | 34 --------
.../devicetree/bindings/mfd/fsl,imx25-tsadc.yaml | 97 ++++++++++++++++++++++
.../devicetree/bindings/mfd/fsl-imx25-tsadc.txt | 47 -----------
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 2 +-
5 files changed, 167 insertions(+), 82 deletions(-)
---
base-commit: 80a957b5f15ec855849f15cd1cbe1a655c09701f
change-id: 20260211-yaml_mfd-8101eef273c7
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 08/11] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: Rob Herring @ 2026-02-11 21:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
Tony Lindgren, linux-iio, devicetree, linux-kernel, linux-input,
linux-leds
In-Reply-To: <20260206172845.145407-9-clamor95@gmail.com>
On Fri, Feb 06, 2026 at 07:28:42PM +0200, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../bindings/mfd/motorola,cpcap.yaml | 411 ++++++++++++++++++
> .../bindings/mfd/motorola-cpcap.txt | 78 ----
> 2 files changed, 411 insertions(+), 78 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> delete mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 000000000000..7e350721d9f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,411 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC MFD
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap
> + - st,6556002
This does not match the only user in the kernel .dts files as
"st,6556002" should be a fallback.
Rob
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: cpcap-regulator: document Mot regulator
From: Rob Herring (Arm) @ 2026-02-11 21:13 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, David Lechner, Lee Jones, Mark Brown, linux-kernel,
linux-leds, Dmitry Torokhov, Tony Lindgren, Nuno Sá,
devicetree, Dixit Parmar, Krzysztof Kozlowski, Andy Shevchenko,
Conor Dooley, Jonathan Cameron, Pavel Machek, linux-iio,
Liam Girdwood
In-Reply-To: <20260206172845.145407-3-clamor95@gmail.com>
On Fri, 06 Feb 2026 19:28:36 +0200, Svyatoslav Ryhel wrote:
> Document regulator composition used by the CPCAP of Tegra20 Mot board,
> that is a base for Atrix 4G and Droid X2.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/regulator/motorola,cpcap-regulator.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 2/2] Input: cros_ec_keyb - add function key support
From: Fabio Baltieri @ 2026-02-11 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Benson Leung, Guenter Roeck
Cc: Fabio Baltieri, Tzung-Bi Shih, Simon Glass, linux-input,
chrome-platform, linux-kernel
In-Reply-To: <20260211173421.1206478-1-fabiobaltieri@chromium.org>
Add support for handling an Fn button and sending separate keycodes for
a subset of keys in the matrix defined in the upper half of the keymap.
Signed-off-by: Fabio Baltieri <fabiobaltieri@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
drivers/input/keyboard/cros_ec_keyb.c | 191 +++++++++++++++++++++++---
1 file changed, 175 insertions(+), 16 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
index 1c6b0461dc35..67022f92533d 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -29,6 +29,12 @@
#include <linux/unaligned.h>
+/*
+ * Maximum size of the normal key matrix, this is limited by the host command
+ * key_matrix field defined in ec_response_get_next_data_v3
+ */
+#define CROS_EC_KEYBOARD_COLS_MAX 18
+
/**
* struct cros_ec_keyb - Structure representing EC keyboard device
*
@@ -44,6 +50,9 @@
* @bs_idev: The input device for non-matrix buttons and switches (or NULL).
* @notifier: interrupt event notifier for transport devices
* @vdata: vivaldi function row data
+ * @has_fn_map: whether the driver uses an fn function-map layer
+ * @fn_key_pressed: tracks the function key status
+ * @fn_event_pending: tracks where any function key fired
*/
struct cros_ec_keyb {
unsigned int rows;
@@ -61,6 +70,10 @@ struct cros_ec_keyb {
struct notifier_block notifier;
struct vivaldi_data vdata;
+
+ bool has_fn_map;
+ bool fn_key_pressed;
+ bool fn_event_pending;
};
/**
@@ -166,16 +179,103 @@ static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t *buf)
return false;
}
+/*
+ * Process a function key state change, send an event report if appropriate.
+ */
+static void cros_ec_keyb_process_fn_key(struct cros_ec_keyb *ckdev,
+ int row, int col, bool state)
+{
+ struct input_dev *idev = ckdev->idev;
+ int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
+
+ ckdev->fn_key_pressed = state;
+
+ if (state) {
+ ckdev->fn_event_pending = false;
+ } else if (!ckdev->fn_event_pending) {
+ /*
+ * Send the original code if nothing else has been pressed
+ * together with Fn.
+ */
+ input_event(idev, EV_MSC, MSC_SCAN, pos);
+ input_report_key(idev, KEY_FN, true);
+ input_sync(idev);
+
+ input_event(idev, EV_MSC, MSC_SCAN, pos);
+ input_report_key(idev, KEY_FN, false);
+ }
+}
+
+/*
+ * Return the Fn code for a normal key row, col combination, optionally set a
+ * position code too.
+ */
+static unsigned int cros_ec_keyb_fn_code(struct cros_ec_keyb *ckdev,
+ int row, int col, int *pos)
+{
+ struct input_dev *idev = ckdev->idev;
+ const unsigned short *keycodes = idev->keycode;
+ int fn_pos = MATRIX_SCAN_CODE(row + ckdev->rows, col, ckdev->row_shift);
+
+ if (pos)
+ *pos = fn_pos;
+
+ return keycodes[fn_pos];
+}
+
+/*
+ * Process the new state for a single key.
+ */
+static void cros_ec_keyb_process_one(struct cros_ec_keyb *ckdev,
+ int row, int col, bool state)
+{
+ struct input_dev *idev = ckdev->idev;
+ const unsigned short *keycodes = idev->keycode;
+ int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
+ unsigned int code = keycodes[pos];
+
+ dev_dbg(ckdev->dev, "changed: [r%d c%d]: byte %02x\n", row, col, state);
+
+ if (ckdev->has_fn_map) {
+ int fn_pos;
+ unsigned int fn_code = cros_ec_keyb_fn_code(ckdev, row, col, &fn_pos);
+
+ if (code == KEY_FN)
+ return cros_ec_keyb_process_fn_key(ckdev, row, col, state);
+
+ if (!state) {
+ if (test_bit(fn_code, idev->key)) {
+ code = fn_code;
+ pos = fn_pos;
+ } else if (test_bit(code, idev->key)) {
+ /* nothing to do */
+ } else {
+ /* Discard, key press code was not sent */
+ return;
+ }
+ } else if (ckdev->fn_key_pressed) {
+ ckdev->fn_event_pending = true;
+
+ if (!fn_code)
+ return;
+
+ code = fn_code;
+ pos = fn_pos;
+ }
+ }
+
+ input_event(idev, EV_MSC, MSC_SCAN, pos);
+ input_report_key(idev, code, state);
+}
/*
* Compares the new keyboard state to the old one and produces key
- * press/release events accordingly. The keyboard state is 13 bytes (one byte
- * per column)
+ * press/release events accordingly. The keyboard state is one byte
+ * per column.
*/
static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
uint8_t *kb_state, int len)
{
- struct input_dev *idev = ckdev->idev;
int col, row;
int new_state;
int old_state;
@@ -192,20 +292,13 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
for (col = 0; col < ckdev->cols; col++) {
for (row = 0; row < ckdev->rows; row++) {
- int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
- const unsigned short *keycodes = idev->keycode;
-
new_state = kb_state[col] & (1 << row);
old_state = ckdev->old_kb_state[col] & (1 << row);
- if (new_state != old_state) {
- dev_dbg(ckdev->dev,
- "changed: [r%d c%d]: byte %02x\n",
- row, col, new_state);
-
- input_event(idev, EV_MSC, MSC_SCAN, pos);
- input_report_key(idev, keycodes[pos],
- new_state);
- }
+
+ if (new_state == old_state)
+ continue;
+
+ cros_ec_keyb_process_one(ckdev, row, col, new_state);
}
ckdev->old_kb_state[col] = kb_state[col];
}
@@ -582,6 +675,63 @@ static void cros_ec_keyb_parse_vivaldi_physmap(struct cros_ec_keyb *ckdev)
ckdev->vdata.num_function_row_keys = n_physmap;
}
+/* Returns true if there is a KEY_FN code defined in the normal keymap */
+static bool cros_ec_keyb_has_fn_key(struct cros_ec_keyb *ckdev)
+{
+ struct input_dev *idev = ckdev->idev;
+ const unsigned short *keycodes = idev->keycode;
+
+ for (int row = 0; row < ckdev->rows; row++) {
+ for (int col = 0; col < ckdev->cols; col++) {
+ int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
+
+ if (keycodes[pos] == KEY_FN)
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/*
+ * Returns true if there is a KEY_FN defined and at least one key in the fn
+ * layer keymap
+ */
+static bool cros_ec_keyb_has_fn_map(struct cros_ec_keyb *ckdev)
+{
+ if (!cros_ec_keyb_has_fn_key(ckdev))
+ return false;
+
+ for (int row = 0; row < ckdev->rows; row++) {
+ for (int col = 0; col < ckdev->cols; col++) {
+ if (cros_ec_keyb_fn_code(ckdev, row, col, NULL) != 0)
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/*
+ * Custom handler for the set keycode ioctl, calls the default handler and
+ * recomputes has_fn_map.
+ */
+static int cros_ec_keyb_setkeycode(struct input_dev *idev,
+ const struct input_keymap_entry *ke,
+ unsigned int *old_keycode)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(idev);
+ int ret;
+
+ ret = input_default_setkeycode(idev, ke, old_keycode);
+ if (ret)
+ return ret;
+
+ ckdev->has_fn_map = cros_ec_keyb_has_fn_map(ckdev);
+
+ return 0;
+}
+
/**
* cros_ec_keyb_register_matrix - Register matrix keys
*
@@ -603,6 +753,12 @@ static int cros_ec_keyb_register_matrix(struct cros_ec_keyb *ckdev)
if (err)
return err;
+ if (ckdev->cols > CROS_EC_KEYBOARD_COLS_MAX) {
+ dev_err(dev, "keypad,num-columns too large: %d (max: %d)\n",
+ ckdev->cols, CROS_EC_KEYBOARD_COLS_MAX);
+ return -EINVAL;
+ }
+
ckdev->valid_keys = devm_kzalloc(dev, ckdev->cols, GFP_KERNEL);
if (!ckdev->valid_keys)
return -ENOMEM;
@@ -631,11 +787,12 @@ static int cros_ec_keyb_register_matrix(struct cros_ec_keyb *ckdev)
idev->id.version = 1;
idev->id.product = 0;
idev->dev.parent = dev;
+ idev->setkeycode = cros_ec_keyb_setkeycode;
ckdev->ghost_filter = device_property_read_bool(dev,
"google,needs-ghost-filter");
- err = matrix_keypad_build_keymap(NULL, NULL, ckdev->rows, ckdev->cols,
+ err = matrix_keypad_build_keymap(NULL, NULL, ckdev->rows * 2, ckdev->cols,
NULL, idev);
if (err) {
dev_err(dev, "cannot build key matrix\n");
@@ -650,6 +807,8 @@ static int cros_ec_keyb_register_matrix(struct cros_ec_keyb *ckdev)
cros_ec_keyb_compute_valid_keys(ckdev);
cros_ec_keyb_parse_vivaldi_physmap(ckdev);
+ ckdev->has_fn_map = cros_ec_keyb_has_fn_map(ckdev);
+
err = input_register_device(ckdev->idev);
if (err) {
dev_err(dev, "cannot register input device\n");
--
2.53.0.239.g8d8fc8a987-goog
^ permalink raw reply related
* [PATCH v7 0/2] Input: cros_ec_keyb - add function key support
From: Fabio Baltieri @ 2026-02-11 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Benson Leung, Guenter Roeck
Cc: Fabio Baltieri, Tzung-Bi Shih, Simon Glass, linux-input,
chrome-platform, linux-kernel
Changes from v6:
- Fixed a bug where normal key were sending the wrong MSC scancode
- Added setkeycode handling so fn functionality is recomputed in
runtime when the keymap is changed
Changes from v5:
- minor renames/cosmetic changes
- dropped the *_key_status array, tracking using the idev->key bitmask
Changes from v4:
- just a comment tweak
Changes from v3:
- implemented fn layer runtime detection
- tweaked cros_ec_keyb_fn_code to return back the correct position
code
Changes from v2:
- renamed the dt property to use-fn-map, dropped the example
- added few function comments
- added a helper for obtaining the fn code
- reordered, dt patch first
Changes from v1:
- change struct to short types
- refactored the fn key handling in its own function
- changed props to use the google, prefix
- reworked the properties to use an overlay map rather than a
dedicated one
Fabio Baltieri (2):
Input: export input_default_setkeycode
Input: cros_ec_keyb - add function key support
drivers/input/input.c | 9 +-
drivers/input/keyboard/cros_ec_keyb.c | 191 +++++++++++++++++++++++---
include/linux/input.h | 4 +
3 files changed, 185 insertions(+), 19 deletions(-)
--
2.53.0.239.g8d8fc8a987-goog
^ permalink raw reply
* [PATCH v7 1/2] Input: export input_default_setkeycode
From: Fabio Baltieri @ 2026-02-11 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Benson Leung, Guenter Roeck
Cc: Fabio Baltieri, Tzung-Bi Shih, Simon Glass, linux-input,
chrome-platform, linux-kernel
In-Reply-To: <20260211173421.1206478-1-fabiobaltieri@chromium.org>
Export input_default_setkeycode so that a driver can set a custom
setkeycode handler to do take some driver specific action but still call
the default handler at some point.
Signed-off-by: Fabio Baltieri <fabiobaltieri@chromium.org>
---
drivers/input/input.c | 9 ++++++---
include/linux/input.h | 4 ++++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index a500e1e276c2..d3a1878f25db 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -800,14 +800,16 @@ static int input_default_getkeycode(struct input_dev *dev,
return 0;
}
-static int input_default_setkeycode(struct input_dev *dev,
- const struct input_keymap_entry *ke,
- unsigned int *old_keycode)
+int input_default_setkeycode(struct input_dev *dev,
+ const struct input_keymap_entry *ke,
+ unsigned int *old_keycode)
{
unsigned int index;
int error;
int i;
+ lockdep_assert_held(&dev->event_lock);
+
if (!dev->keycodesize)
return -EINVAL;
@@ -861,6 +863,7 @@ static int input_default_setkeycode(struct input_dev *dev,
__set_bit(ke->keycode, dev->keybit);
return 0;
}
+EXPORT_SYMBOL(input_default_setkeycode);
/**
* input_get_keycode - retrieve keycode currently mapped to a given scancode
diff --git a/include/linux/input.h b/include/linux/input.h
index 7d7cb0593a63..06ca62328db1 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -517,6 +517,10 @@ INPUT_GENERATE_ABS_ACCESSORS(res, resolution)
int input_scancode_to_scalar(const struct input_keymap_entry *ke,
unsigned int *scancode);
+int input_default_setkeycode(struct input_dev *dev,
+ const struct input_keymap_entry *ke,
+ unsigned int *old_keycode);
+
int input_get_keycode(struct input_dev *dev, struct input_keymap_entry *ke);
int input_set_keycode(struct input_dev *dev,
const struct input_keymap_entry *ke);
--
2.53.0.239.g8d8fc8a987-goog
^ permalink raw reply related
* [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement
From: Lee Jones @ 2026-02-11 16:40 UTC (permalink / raw)
To: lee, David Rheinsberg, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
Cc: stable
Since the report ID is located within the data buffer, overwriting it
would mean that any subsequent matching could cause a disparity in
assumed allocated buffer size. This in turn could trivially result in
an out-of-bounds condition. To mitigate this issue, let's refuse to
overwrite a given report's data area if the ID in get_report_reply
doesn't match.
Cc: stable@vger.kernel.org
Fixes: fcfcf0deb89ec ("HID: uhid: implement feature requests")
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/uhid.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 21a70420151e..a0ee4e86656f 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -262,6 +262,10 @@ static int uhid_hid_get_report(struct hid_device *hid, unsigned char rnum,
req = &uhid->report_buf.u.get_report_reply;
if (req->err) {
ret = -EIO;
+ } else if (rnum != req->data[0]) {
+ hid_err(hid, "Report ID mismatch - refusing to overwrite the data buffer\n");
+ ret = -EINVAL;
+ goto unlock;
} else {
ret = min3(count, (size_t)req->size, (size_t)UHID_DATA_MAX);
memcpy(buf, req->data, ret);
--
2.53.0.273.g2a3d683680-goog
^ permalink raw reply related
* [PATCH] HID: hid-mcp-2200.c: fix typos in comments
From: Hans Anda @ 2026-02-11 14:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Johannes, Hans Anda
Fix typos in comments
drivers/hid/hid-mcp2200.c: "Commands" -> "Command", "Altternative" -> "Alternative"
Signed-off-by: Hans Anda <hansa@airmail.cc>
---
drivers/hid/hid-mcp2200.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
index dafdd5b4a079..7e2f5e37a85a 100644
--- a/drivers/hid/hid-mcp2200.c
+++ b/drivers/hid/hid-mcp2200.c
@@ -17,7 +17,7 @@
#include <linux/mutex.h>
#include "hid-ids.h"
-/* Commands codes in a raw output report */
+/* Command codes in a raw output report */
#define SET_CLEAR_OUTPUTS 0x08
#define CONFIGURE 0x10
#define READ_EE 0x20
@@ -30,7 +30,7 @@ enum MCP_IO_DIR {
MCP2200_DIR_IN = 0x01,
};
-/* Altternative pin assignments */
+/* Alternative pin assignments */
#define TXLED 2
#define RXLED 3
#define USBCFG 6
--
2.52.0
^ permalink raw reply related
* [PATCH] HID: hid-mcp-2200.c: fix typos in comments
From: Hans Anda @ 2026-02-11 10:49 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Johannes, Hans Anda
Signed-off-by: Hans Anda <hansa@airmail.cc>
---
drivers/hid/hid-mcp2200.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-mcp2200.c b/drivers/hid/hid-mcp2200.c
index dafdd5b4a079..7e2f5e37a85a 100644
--- a/drivers/hid/hid-mcp2200.c
+++ b/drivers/hid/hid-mcp2200.c
@@ -17,7 +17,7 @@
#include <linux/mutex.h>
#include "hid-ids.h"
-/* Commands codes in a raw output report */
+/* Command codes in a raw output report */
#define SET_CLEAR_OUTPUTS 0x08
#define CONFIGURE 0x10
#define READ_EE 0x20
@@ -30,7 +30,7 @@ enum MCP_IO_DIR {
MCP2200_DIR_IN = 0x01,
};
-/* Altternative pin assignments */
+/* Alternative pin assignments */
#define TXLED 2
#define RXLED 3
#define USBCFG 6
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-11 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <9dcc308d-f87d-4706-90ae-df3669aea224@kernel.org>
вт, 10 лют. 2026 р. о 14:48 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 10/02/2026 12:54, Krzysztof Kozlowski wrote:
> > On 10/02/2026 12:40, Svyatoslav Ryhel wrote:
> >>>>
> >>>> So you propose introduce a compatible for every single ec used in
> >>>> transformers instead of simply disable unpopulated functions? And how
> >>>> then battery and charger can reach monitored cell if they have no
> >>>> dedicated node?
> >>>
> >>> Just like for other bindings for nodes without resources, fold into
> >>> parent. This is already explained in writing bindings, so you could have
> >>> just read that. I will pass with answering more questions till you read
> >>> that doc.
> >>>
> >>
> >> Unfolding asus,ec-pad and asus,ec-dock will result in this list:
> >>
> >> asus,tf101-dock-ec
> >> asus,tf101g-dock-ec
> >> asus,sl101-pad-ec
> >> asus,tf201-pad-ec
> >> asus,tf201-dock-ec
> >> asus,tf300t-pad-ec
> >> asus,tf300t-dock-ec
> >> asus,tf300tg-pad-ec
> >> asus,tf300tg-dock-ec
> >> asus,tf300tl-pad-ec
> >> asus,tf300tl-dock-ec
> >> asus,tf600t-pad-ec
> >> asus,tf700t-pad-ec
> >> asus,tf700t-dock-ec
> >> asus,tf701t-pad-ec
> >> asus,p1801-t-pad-ec
> >>
> >> with minor variations in populated cells. Is this acceptible?
> >
> >
> > Yes, this looks correct.
>
> Update: with fallback-expressed compatibility when same interface and/or
> superset of features.
>
I am removing separate DockRAM and merging it into this schema hence,
it should look like this
reg:
description:
The ASUS Transformer EC has a main I2C address and an associated
DockRAM device, which provides power-related functions for the
embedded controller. Both addresses are required for operation.
minItems: 2
reg-names:
items:
- const: ec
- const: dockram
How should I organize amount of regs? Would this example be acceptable
with minItems: 2 since EC requires both to work or should I set is as
items list or minItems: 2 maxItems: 2? Thank you.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rakesh Kota @ 2026-02-11 10:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Dmitry Torokhov, Courtney Cavin, Bjorn Andersson,
Konrad Dybcio, linux-pm, devicetree, linux-kernel, linux-arm-msm,
linux-input, Rakesh Kota
In-Reply-To: <b9c7aa89-b260-42aa-a85d-9e596e78e419@kernel.org>
On Tue, Feb 10, 2026 at 09:32:18AM +0100, Krzysztof Kozlowski wrote:
> On 10/02/2026 09:26, Rakesh Kota wrote:
> > On Mon, Feb 09, 2026 at 02:49:24PM +0100, Krzysztof Kozlowski wrote:
> >> On 09/02/2026 14:23, Rakesh Kota wrote:
> >>> Add the compatible string "qcom,pmm8654au-pon" for the PMM8654AU PMIC.
> >>> The PON peripheral on PMM8654AU is compatible with PMK8350, so it is
> >>> documented as a fallback to "qcom,pmk8350-pon".
> >>
> >> Drop everything after ,. Do not explain WHAT you did. We see it.
> >>
> >>>
> >>> While PMM8654AU supports additional registers compared to the baseline,
> >>
> >> full stop.
> >>
> >>> there is currently no active use case for these features. This specific
> >>> compatible string reserves the identifier for future hardware-specific
> >>> handling if required.
> >>
> >> All the rest is irrelevant or even wrong. We do not reserve identifiers.
> >> If you want to reserve something, then I need to reject the patch.
> >>
> > Hi Konrad Dybcio,
> >
> > It appears that Krzysztof Kozlowski has concerns regarding the
> > compatible string reservation for future use cases, noting that
> > identifiers should not be reserved in this manner.
>
> So do not reserve identifiers but submit bindings reflecting REAL
> hardware being used.
>
Yes, there is a real hardware difference between the PMK8350 and
PMM865AU PON peripherals. The PMM865AU PON is leveraged from the PMK8350
PON and includes extra features, but those features do not have any
active use cases for now.
If you are okay with the new compatible string, I will send V3 and fix
the commit message suggestions.
> > > So, could you please help ACK my first patch-set instead?
> > https://lore.kernel.org/all/20260122-add_pwrkey_and_resin-v1-1-a9fe87537816@oss.qualcomm.com/
> >
>
> First patchset is wrong. You already received comments on that.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1] input: xpad: Add support for BETOP BTP-KP50B/C, controller's wireless mode
From: Shengyu Qu @ 2026-02-11 6:53 UTC (permalink / raw)
To: liushuyu, Antheas Kapenekakis
Cc: wiagn233, dmitry.torokhov, vi, niltonperimneto, linux-input,
linux-kernel
In-Reply-To: <c584ce4f-6daa-448e-ab53-a144068216a7@aosc.io>
[-- Attachment #1.1.1: Type: text/plain, Size: 961 bytes --]
Hi,
Seems your patch is not working. Tested on both KP50B and KP50C. Log
attached.
Best regards,
Shengyu
在 2026/2/10 13:53, liushuyu 写道:
> Hi there,
>> Hi,
>> if I recall, this logic abuses some HID descriptor logic to cycle the
>> mode depending on the OS. The arch wiki has a potential fix for
>> certain controllers.
>>
>> This makes you end up in Android mode since linux kernel. Nintendo
>> uses a BSD-based kernel, and the Windows NT kernel is different. So by
>> breaking the protocol in different ways they get it to cycle.
>>
>> Antheas
>
> I sent a patch to the linux-input list a few months ago to work around
> this issue with the BETOP/Beitong controllers:
> https://lore.kernel.org/linux-input/20260102030154.197749-3-liushuyu@aosc.io/.
> It would be appreciated if anyone in the thread could verify if my
> previous workaround works for their BETOP/Beitong controllers as well.
>
> Thanks,
> Zixing
>
[-- Attachment #1.1.2: dmesg-xpad.txt --]
[-- Type: text/plain, Size: 5771 bytes --]
[12892.612050] usb 1-5: new high-speed USB device number 25 using xhci_hcd
[12892.736452] usb 1-5: New USB device found, idVendor=1a86, idProduct=8091, bcdDevice=13.10
[12892.736457] usb 1-5: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[12892.736458] usb 1-5: Product: USB HUB
[12892.737405] hub 1-5:1.0: USB hub found
[12892.737424] hub 1-5:1.0: 4 ports detected
[12893.017043] usb 1-5.1: new full-speed USB device number 26 using xhci_hcd
[12893.027334] usb 1-6: USB disconnect, device number 24
[12893.102809] usb 1-5.1: New USB device found, idVendor=20bc, idProduct=5133, bcdDevice= 1.00
[12893.102820] usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12893.102823] usb 1-5.1: Product: BTP-KP50B XINPUT WIRED
[12893.102826] usb 1-5.1: Manufacturer: BEITONG
[12893.112766] input: Beitong KP50B Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/input/input57
[12893.113861] input: BEITONG BTP-KP50B XINPUT WIRED Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.0017/input/input58
[12893.204328] input: BEITONG BTP-KP50B XINPUT WIRED as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.0017/input/input59
[12893.204487] hid-generic 0003:20BC:5133.0017: input,hiddev96,hidraw0: USB HID v1.11 Keyboard [BEITONG BTP-KP50B XINPUT WIRED] on usb-0000:00:14.0-5.1/input1
[12893.280105] usb 1-5.2: new full-speed USB device number 27 using xhci_hcd
[12893.367430] usb 1-5.2: New USB device found, idVendor=0517, idProduct=5350, bcdDevice= 0.00
[12893.367441] usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12893.367445] usb 1-5.2: Product: BTPRO Screen
[12893.367447] usb 1-5.2: Manufacturer: Xingzj
[12893.373731] hid-generic 0003:0517:5350.0018: hiddev99,hidraw7: USB HID v1.10 Device [Xingzj BTPRO Screen] on usb-0000:00:14.0-5.2/input0
[12893.479187] usb 1-6: new full-speed USB device number 28 using xhci_hcd
[12893.603837] usb 1-6: New USB device found, idVendor=20dd, idProduct=5134, bcdDevice= 1.00
[12893.603848] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12893.603851] usb 1-6: Product: KP50B DONGLE
[12893.603854] usb 1-6: Manufacturer: BEITONG
[12893.606407] hid-generic 0003:20DD:5134.0019: hiddev100,hidraw8: USB HID v1.11 Device [BEITONG KP50B DONGLE] on usb-0000:00:14.0-6/input0
[12894.170005] usb 1-5.1: USB disconnect, device number 26
[12894.496092] usb 1-5.1: new full-speed USB device number 29 using xhci_hcd
[12894.582050] usb 1-5.1: New USB device found, idVendor=20bc, idProduct=5133, bcdDevice= 1.00
[12894.582060] usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12894.582063] usb 1-5.1: Product: BTP-KP50B XINPUT WIRED
[12894.582066] usb 1-5.1: Manufacturer: BEITONG
[12894.592454] input: Beitong KP50B Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/input/input60
[12894.593621] input: BEITONG BTP-KP50B XINPUT WIRED Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.001A/input/input61
[12894.685250] input: BEITONG BTP-KP50B XINPUT WIRED as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.001A/input/input62
[12894.685408] hid-generic 0003:20BC:5133.001A: input,hiddev96,hidraw0: USB HID v1.11 Keyboard [BEITONG BTP-KP50B XINPUT WIRED] on usb-0000:00:14.0-5.1/input1
[12895.706017] usb 1-5.1: USB disconnect, device number 29
[12896.032019] usb 1-5.1: new full-speed USB device number 30 using xhci_hcd
[12896.118721] usb 1-5.1: New USB device found, idVendor=20bc, idProduct=5133, bcdDevice= 1.00
[12896.118732] usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12896.118736] usb 1-5.1: Product: BTP-KP50B XINPUT WIRED
[12896.118739] usb 1-5.1: Manufacturer: BEITONG
[12896.129259] input: Beitong KP50B Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/input/input63
[12896.130423] input: BEITONG BTP-KP50B XINPUT WIRED Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.001B/input/input64
[12896.214259] input: BEITONG BTP-KP50B XINPUT WIRED as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.1/0003:20BC:5133.001B/input/input65
[12896.214487] hid-generic 0003:20BC:5133.001B: input,hiddev96,hidraw0: USB HID v1.11 Keyboard [BEITONG BTP-KP50B XINPUT WIRED] on usb-0000:00:14.0-5.1/input1
[12897.242015] usb 1-5.1: USB disconnect, device number 30
[12897.530076] usb 1-5.1: new full-speed USB device number 31 using xhci_hcd
[12897.615068] usb 1-5.1: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[12897.615080] usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12897.615087] usb 1-5.1: Product: BTP-KP50B NS WIRED
[12897.615091] usb 1-5.1: Manufacturer: BEITONG
[12897.621902] nintendo 0003:057E:2009.001C: hidraw0: USB HID v81.11 Joystick [BEITONG BTP-KP50B NS WIRED] on usb-0000:00:14.0-5.1/input0
[12899.736001] nintendo 0003:057E:2009.001C: Failed to set baudrate (ret=-110), continuing anyway
[12899.947146] nintendo 0003:057E:2009.001C: controller MAC = 80:E4:FE:1C:52:61
[12899.952085] nintendo 0003:057E:2009.001C: using factory cal for left stick
[12899.954131] nintendo 0003:057E:2009.001C: using factory cal for right stick
[12899.960080] nintendo 0003:057E:2009.001C: using factory cal for IMU
[12899.962142] nintendo 0003:057E:2009.001C: inaccurate IMU divisors (6)
[12899.968081] nintendo 0003:057E:2009.001C: assigned player 1 led pattern
[12899.972241] input: BEITONG BTP-KP50B NS WIRED as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/0003:057E:2009.001C/input/input66
[12899.972446] input: BEITONG BTP-KP50B NS WIRED (IMU) as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/0003:057E:2009.001C/input/input67
[-- Attachment #1.1.3: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6977 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* [PATCH RESEND] HID: winwing: Enable rumble effects
From: Ivan Gorinov @ 2026-02-11 5:31 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel
Enable rumble motor control on TGRIP-15E and TGRIP-15EX throttle grips
by sending haptic feedback commands (EV_FF events) to the input device.
Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
---
drivers/hid/hid-winwing.c | 193 +++++++++++++++++++++++++++++++++++---
1 file changed, 179 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-winwing.c b/drivers/hid/hid-winwing.c
index ab65dc12d1e0..031590ffd383 100644
--- a/drivers/hid/hid-winwing.c
+++ b/drivers/hid/hid-winwing.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/workqueue.h>
#define MAX_REPORT 16
@@ -35,10 +36,14 @@ static const struct winwing_led_info led_info[3] = {
struct winwing_drv_data {
struct hid_device *hdev;
- __u8 *report_buf;
- struct mutex lock;
- int map_more_buttons;
- unsigned int num_leds;
+ struct mutex lights_lock;
+ __u8 *report_lights;
+ __u8 *report_rumble;
+ struct work_struct rumble_work;
+ struct ff_rumble_effect rumble;
+ int rumble_left;
+ int rumble_right;
+ int has_grip15;
struct winwing_led leds[];
};
@@ -47,10 +52,10 @@ static int winwing_led_write(struct led_classdev *cdev,
{
struct winwing_led *led = (struct winwing_led *) cdev;
struct winwing_drv_data *data = hid_get_drvdata(led->hdev);
- __u8 *buf = data->report_buf;
+ __u8 *buf = data->report_lights;
int ret;
- mutex_lock(&data->lock);
+ mutex_lock(&data->lights_lock);
buf[0] = 0x02;
buf[1] = 0x60;
@@ -69,7 +74,7 @@ static int winwing_led_write(struct led_classdev *cdev,
ret = hid_hw_output_report(led->hdev, buf, 14);
- mutex_unlock(&data->lock);
+ mutex_unlock(&data->lights_lock);
return ret;
}
@@ -87,9 +92,9 @@ static int winwing_init_led(struct hid_device *hdev,
if (!data)
return -EINVAL;
- data->report_buf = devm_kmalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
+ data->report_lights = devm_kzalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
- if (!data->report_buf)
+ if (!data->report_lights)
return -ENOMEM;
for (i = 0; i < 3; i += 1) {
@@ -117,7 +122,7 @@ static int winwing_init_led(struct hid_device *hdev,
return ret;
}
-static int winwing_map_button(int button, int map_more_buttons)
+static int winwing_map_button(int button, int has_grip15)
{
if (button < 1)
return KEY_RESERVED;
@@ -141,7 +146,7 @@ static int winwing_map_button(int button, int map_more_buttons)
return (button - 65) + BTN_TRIGGER_HAPPY17;
}
- if (!map_more_buttons) {
+ if (!has_grip15) {
/*
* Not mapping numbers [33 .. 64] which
* are not assigned to any real buttons
@@ -194,13 +199,150 @@ static int winwing_input_mapping(struct hid_device *hdev,
/* Button numbers start with 1 */
button = usage->hid & HID_USAGE;
- code = winwing_map_button(button, data->map_more_buttons);
+ code = winwing_map_button(button, data->has_grip15);
hid_map_usage(hi, usage, bit, max, EV_KEY, code);
return 1;
}
+/*
+ * If x ≤ 0, return 0;
+ * if x is in [1 .. 65535], return a value in [1 .. 255]
+ */
+static inline int convert_magnitude(int x)
+{
+ if (x < 1)
+ return 0;
+
+ return ((x * 255) >> 16) + 1;
+}
+
+static int winwing_haptic_rumble(struct winwing_drv_data *data)
+{
+ __u8 *buf;
+ __u8 m;
+
+ if (!data)
+ return -EINVAL;
+
+ buf = data->report_rumble;
+
+ if (!buf)
+ return -EINVAL;
+
+ if (!data->hdev) {
+ hid_err(data->hdev, "data->hdev == NULL\n");
+ return -EINVAL;
+ }
+
+ if (!data->hdev->ll_driver) {
+ hid_err(data->hdev, "data->hdev->ll_driver == NULL\n");
+ return -EINVAL;
+ }
+
+ m = convert_magnitude(data->rumble.strong_magnitude);
+ if (m != data->rumble_left) {
+ int ret;
+
+ buf[0] = 0x02;
+ buf[1] = 0x01;
+ buf[2] = 0xbf;
+ buf[3] = 0x00;
+ buf[4] = 0x00;
+ buf[5] = 0x03;
+ buf[6] = 0x49;
+ buf[7] = 0x00;
+ buf[8] = m;
+ buf[9] = 0x00;
+ buf[10] = 0;
+ buf[11] = 0;
+ buf[12] = 0;
+ buf[13] = 0;
+
+ ret = hid_hw_output_report(data->hdev, buf, 14);
+ if (ret < 0) {
+ hid_err(data->hdev, "error %d (%*ph)\n", ret, 14, buf);
+ return ret;
+ }
+ data->rumble_left = m;
+ }
+
+ m = convert_magnitude(data->rumble.weak_magnitude);
+ if (m != data->rumble_right) {
+ int ret;
+
+ buf[0] = 0x02;
+ buf[1] = 0x03;
+ buf[2] = 0xbf;
+ buf[3] = 0x00;
+ buf[4] = 0x00;
+ buf[5] = 0x03;
+ buf[6] = 0x49;
+ buf[7] = 0x00;
+ buf[8] = m;
+ buf[9] = 0x00;
+ buf[10] = 0;
+ buf[11] = 0;
+ buf[12] = 0;
+ buf[13] = 0;
+
+ ret = hid_hw_output_report(data->hdev, buf, 14);
+ if (ret < 0) {
+ hid_err(data->hdev, "error %d (%*ph)\n", ret, 14, buf);
+ return ret;
+ }
+ data->rumble_right = m;
+ }
+
+ return 0;
+}
+
+
+static void winwing_haptic_rumble_cb(struct work_struct *work)
+{
+ struct winwing_drv_data *data;
+
+ data = container_of(work, struct winwing_drv_data, rumble_work);
+
+ if (data)
+ winwing_haptic_rumble(data);
+}
+
+static int winwing_play_effect(struct input_dev *dev, void *context,
+ struct ff_effect *effect)
+{
+ struct winwing_drv_data *data = (struct winwing_drv_data *) context;
+
+ if (effect->type != FF_RUMBLE)
+ return 0;
+
+ if (!data)
+ return -EINVAL;
+
+ data->rumble = effect->u.rumble;
+
+ return schedule_work(&data->rumble_work);
+}
+
+static int winwing_init_ff(struct hid_device *hdev, struct hid_input *hidinput)
+{
+ struct winwing_drv_data *data;
+
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+ data->report_rumble = devm_kzalloc(&hdev->dev, MAX_REPORT, GFP_KERNEL);
+ data->rumble_left = -1;
+ data->rumble_right = -1;
+
+ input_set_capability(hidinput->input, EV_FF, FF_RUMBLE);
+
+ if (!data)
+ return -EINVAL;
+
+ return input_ff_create_memless(hidinput->input, data,
+ winwing_play_effect);
+}
+
static int winwing_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -219,10 +361,12 @@ static int winwing_probe(struct hid_device *hdev,
if (!data)
return -ENOMEM;
- data->map_more_buttons = id->driver_data;
-
+ data->hdev = hdev;
+ data->has_grip15 = id->driver_data;
hid_set_drvdata(hdev, data);
+ INIT_WORK(&data->rumble_work, winwing_haptic_rumble_cb);
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "hw start failed\n");
@@ -232,19 +376,39 @@ static int winwing_probe(struct hid_device *hdev,
return 0;
}
+static void winwing_remove(struct hid_device *hdev)
+{
+ struct winwing_drv_data *data;
+
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+
+ if (data)
+ cancel_work_sync(&data->rumble_work);
+
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+}
+
static int winwing_input_configured(struct hid_device *hdev,
struct hid_input *hidinput)
{
+ struct winwing_drv_data *data;
int ret;
+ data = (struct winwing_drv_data *) hid_get_drvdata(hdev);
+
ret = winwing_init_led(hdev, hidinput->input);
if (ret)
hid_err(hdev, "led init failed\n");
+ if (data->has_grip15)
+ winwing_init_ff(hdev, hidinput);
+
return ret;
}
+/* Set driver_data to 1 for grips with rumble motor and more than 32 buttons */
static const struct hid_device_id winwing_devices[] = {
{ HID_USB_DEVICE(0x4098, 0xbd65), .driver_data = 1 }, /* TGRIP-15E */
{ HID_USB_DEVICE(0x4098, 0xbd64), .driver_data = 1 }, /* TGRIP-15EX */
@@ -261,6 +425,7 @@ static struct hid_driver winwing_driver = {
.input_configured = winwing_input_configured,
.input_mapping = winwing_input_mapping,
.probe = winwing_probe,
+ .remove = winwing_remove,
};
module_hid_driver(winwing_driver);
--
2.43.0
^ permalink raw reply related
* [PATCH] Input: xpad: Add support for "Nova 2 Lite" from GameSir
From: Qbeliw Tanaka @ 2026-02-11 1:17 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, q.tanaka
[-- Attachment #1: Type: Text/Plain, Size: 139 bytes --]
Hi.
This patch adds support for the gamepad "Nova 2 Lite" from GameSir. It is compatible with the Xbox 360 gamepad.
Thanks bedforehand.
[-- Attachment #2: 0001-patch-v1-joydev-xpad-Add-support-for-Nova-2-Lite-fro.patch --]
[-- Type: Text/X-Patch, Size: 1158 bytes --]
From 124e8e9057fcfb2439c195fe17f498da22802a18 Mon Sep 17 00:00:00 2001
From: Qbeliw Tanaka <q.tanaka@gmx.com>
Date: Tue, 10 Feb 2026 21:51:12 +0900
Subject: [PATCH] Input: xpad: Add support for "Nova 2 Lite" from
GameSir
This patch adds support for the gamepad "Nova 2 Lite" from GameSir. It is compatible with the Xbox 360 gamepad.
Signed-off-by: Qbeliw Tanaka <q.tanaka@gmx.com>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 363d50949..8d96349c3 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -421,6 +421,7 @@ static const struct xpad_device {
{ 0x3285, 0x0662, "Nacon Revolution5 Pro", 0, XTYPE_XBOX360 },
{ 0x3285, 0x0663, "Nacon Evol-X", 0, XTYPE_XBOXONE },
{ 0x3537, 0x1004, "GameSir T4 Kaleid", 0, XTYPE_XBOX360 },
+ { 0x3537, 0x100f, "GameSir Nova 2 Lite", 0, XTYPE_XBOX360 },
{ 0x3537, 0x1010, "GameSir G7 SE", 0, XTYPE_XBOXONE },
{ 0x3651, 0x1000, "CRKD SG", 0, XTYPE_XBOX360 },
{ 0x366c, 0x0005, "ByoWave Proteus Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE, FLAG_DELAY_INIT },
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 12:48 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <ec3b39d6-51ec-429d-b083-e5af2b4a9c65@kernel.org>
On 10/02/2026 12:54, Krzysztof Kozlowski wrote:
> On 10/02/2026 12:40, Svyatoslav Ryhel wrote:
>>>>
>>>> So you propose introduce a compatible for every single ec used in
>>>> transformers instead of simply disable unpopulated functions? And how
>>>> then battery and charger can reach monitored cell if they have no
>>>> dedicated node?
>>>
>>> Just like for other bindings for nodes without resources, fold into
>>> parent. This is already explained in writing bindings, so you could have
>>> just read that. I will pass with answering more questions till you read
>>> that doc.
>>>
>>
>> Unfolding asus,ec-pad and asus,ec-dock will result in this list:
>>
>> asus,tf101-dock-ec
>> asus,tf101g-dock-ec
>> asus,sl101-pad-ec
>> asus,tf201-pad-ec
>> asus,tf201-dock-ec
>> asus,tf300t-pad-ec
>> asus,tf300t-dock-ec
>> asus,tf300tg-pad-ec
>> asus,tf300tg-dock-ec
>> asus,tf300tl-pad-ec
>> asus,tf300tl-dock-ec
>> asus,tf600t-pad-ec
>> asus,tf700t-pad-ec
>> asus,tf700t-dock-ec
>> asus,tf701t-pad-ec
>> asus,p1801-t-pad-ec
>>
>> with minor variations in populated cells. Is this acceptible?
>
>
> Yes, this looks correct.
Update: with fallback-expressed compatibility when same interface and/or
superset of features.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 11:54 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n0u_0ZukcKXt0QpiyCMhWsg2VE-dE19wDCbRQvBvVOf+A@mail.gmail.com>
On 10/02/2026 12:40, Svyatoslav Ryhel wrote:
>>>
>>> So you propose introduce a compatible for every single ec used in
>>> transformers instead of simply disable unpopulated functions? And how
>>> then battery and charger can reach monitored cell if they have no
>>> dedicated node?
>>
>> Just like for other bindings for nodes without resources, fold into
>> parent. This is already explained in writing bindings, so you could have
>> just read that. I will pass with answering more questions till you read
>> that doc.
>>
>
> Unfolding asus,ec-pad and asus,ec-dock will result in this list:
>
> asus,tf101-dock-ec
> asus,tf101g-dock-ec
> asus,sl101-pad-ec
> asus,tf201-pad-ec
> asus,tf201-dock-ec
> asus,tf300t-pad-ec
> asus,tf300t-dock-ec
> asus,tf300tg-pad-ec
> asus,tf300tg-dock-ec
> asus,tf300tl-pad-ec
> asus,tf300tl-dock-ec
> asus,tf600t-pad-ec
> asus,tf700t-pad-ec
> asus,tf700t-dock-ec
> asus,tf701t-pad-ec
> asus,p1801-t-pad-ec
>
> with minor variations in populated cells. Is this acceptible?
Yes, this looks correct.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-10 11:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <dc7acd1e-91e8-492c-8665-cb680c6164fd@kernel.org>
вт, 10 лют. 2026 р. о 13:24 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 10/02/2026 12:14, Svyatoslav Ryhel wrote:
> > вт, 10 лют. 2026 р. о 13:04 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >>
> >> On 10/02/2026 11:59, Svyatoslav Ryhel wrote:
> >>>>>>> + asus,clear-factory-mode:
> >>>>>>> + type: boolean
> >>>>>>> + description: clear Factory Mode bit in EC control register
> >>>>>>
> >>>>>> Why would this be a static/fixed property over lifecycle of all devices?
> >>>>>>
> >>>>>
> >>>>> Specify pls.
> >>>>
> >>>> Provide rationale why we need to clear it every time, not once. Or any
> >>>> other rationale why we would accept that property.
> >>>>
> >>>
> >>> Cause it is done by original Asus code and Asus did not provide
> >>> schematic or any data apart from downstream source regarding this EC.
> >>
> >> So that's a no. downstream code which is poor quality, not following DT
> >> rules at all, is never an argument for a DT property.
> >>
> >
> > This property indicates that this controller on every reset restores
>
> Implied by compatible then and you can drop the property.
>
> > factory bit hence it must be cleared. Bit is write only and cannot be
> > detected. EC remains in factory mode which blocks its functions.
> >
> >>>
> >>>>>
> >>>>>>> +
> >>>>>>> + battery:
> >>>>>>> + type: object
> >>>>>>> + $ref: /schemas/power/supply/power-supply.yaml
> >>>>>>> + unevaluatedProperties: false
> >>>>>>> +
> >>>>>>> + properties:
> >>>>>>> + compatible:
> >>>>>>> + const: asus,ec-battery
> >>>>>>> +
> >>>>>>> + required:
> >>>>>>> + - compatible
> >>>>>>> +
> >>>>>>> + charger:
> >>>>>>> + type: object
> >>>>>>> + $ref: /schemas/power/supply/power-supply.yaml
> >>>>>>> + additionalProperties: false
> >>>>>>> +
> >>>>>>> + properties:
> >>>>>>> + compatible:
> >>>>>>> + const: asus,ec-charger
> >>>>>>> +
> >>>>>>> + monitored-battery: true
> >>>>>>> +
> >>>>>>> + required:
> >>>>>>> + - compatible
> >>>>>>> +
> >>>>>>> + keyboard-ext:
> >>>>>>> + type: object
> >>>>>>> + description: top row of multimedia keys
> >>>>>>> + additionalProperties: false
> >>>>>>> +
> >>>>>>> + properties:
> >>>>>>> + compatible:
> >>>>>>> + const: asus,ec-keys
> >>>>>>> +
> >>>>>>> + required:
> >>>>>>> + - compatible
> >>>>>>> +
> >>>>>>> + led:
> >>>>>>> + type: object
> >>>>>>> + additionalProperties: false
> >>>>>>> +
> >>>>>>> + properties:
> >>>>>>> + compatible:
> >>>>>>> + const: asus,ec-led
> >>>>>>> +
> >>>>>>> + required:
> >>>>>>> + - compatible
> >>>>>>> +
> >>>>>>> + serio:
> >>>>>>
> >>>>>> All of these children are pointless - no resources. Drop all of them,
> >>>>>> it's btw explicitly documented rule in writing bindings.
> >>>>>>
> >>>>>
> >>>>> They are all needed to be able to disable them individually from the
> >>>>> device tree if needed.
> >>>>
> >>>> They should not be disabled from DT, so they are not valid here. The
> >>>> given EC for given device is fixed/static. Does not change.
> >>>>
> >>>
> >>> Have you considered a possibility that function may be
> >>> disabled/unrouted within the controller. By the vendor.
> >>
> >> And then it is implied by the compatible, so no need for any of that.
> >> Otherwise, if it is not specific per device, then specifying it for DTS
> >> for all devices would make no sense.
> >>
> >
> > So you propose introduce a compatible for every single ec used in
> > transformers instead of simply disable unpopulated functions? And how
> > then battery and charger can reach monitored cell if they have no
> > dedicated node?
>
> Just like for other bindings for nodes without resources, fold into
> parent. This is already explained in writing bindings, so you could have
> just read that. I will pass with answering more questions till you read
> that doc.
>
Unfolding asus,ec-pad and asus,ec-dock will result in this list:
asus,tf101-dock-ec
asus,tf101g-dock-ec
asus,sl101-pad-ec
asus,tf201-pad-ec
asus,tf201-dock-ec
asus,tf300t-pad-ec
asus,tf300t-dock-ec
asus,tf300tg-pad-ec
asus,tf300tg-dock-ec
asus,tf300tl-pad-ec
asus,tf300tl-dock-ec
asus,tf600t-pad-ec
asus,tf700t-pad-ec
asus,tf700t-dock-ec
asus,tf701t-pad-ec
asus,p1801-t-pad-ec
with minor variations in populated cells. Is this acceptible?
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 11:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n0O_uSAPYFtg8s+Ni0buyGJys6d0jEMob6SNWx-aeKUEw@mail.gmail.com>
On 10/02/2026 12:14, Svyatoslav Ryhel wrote:
> вт, 10 лют. 2026 р. о 13:04 Krzysztof Kozlowski <krzk@kernel.org> пише:
>>
>> On 10/02/2026 11:59, Svyatoslav Ryhel wrote:
>>>>>>> + asus,clear-factory-mode:
>>>>>>> + type: boolean
>>>>>>> + description: clear Factory Mode bit in EC control register
>>>>>>
>>>>>> Why would this be a static/fixed property over lifecycle of all devices?
>>>>>>
>>>>>
>>>>> Specify pls.
>>>>
>>>> Provide rationale why we need to clear it every time, not once. Or any
>>>> other rationale why we would accept that property.
>>>>
>>>
>>> Cause it is done by original Asus code and Asus did not provide
>>> schematic or any data apart from downstream source regarding this EC.
>>
>> So that's a no. downstream code which is poor quality, not following DT
>> rules at all, is never an argument for a DT property.
>>
>
> This property indicates that this controller on every reset restores
Implied by compatible then and you can drop the property.
> factory bit hence it must be cleared. Bit is write only and cannot be
> detected. EC remains in factory mode which blocks its functions.
>
>>>
>>>>>
>>>>>>> +
>>>>>>> + battery:
>>>>>>> + type: object
>>>>>>> + $ref: /schemas/power/supply/power-supply.yaml
>>>>>>> + unevaluatedProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + const: asus,ec-battery
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - compatible
>>>>>>> +
>>>>>>> + charger:
>>>>>>> + type: object
>>>>>>> + $ref: /schemas/power/supply/power-supply.yaml
>>>>>>> + additionalProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + const: asus,ec-charger
>>>>>>> +
>>>>>>> + monitored-battery: true
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - compatible
>>>>>>> +
>>>>>>> + keyboard-ext:
>>>>>>> + type: object
>>>>>>> + description: top row of multimedia keys
>>>>>>> + additionalProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + const: asus,ec-keys
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - compatible
>>>>>>> +
>>>>>>> + led:
>>>>>>> + type: object
>>>>>>> + additionalProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + const: asus,ec-led
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - compatible
>>>>>>> +
>>>>>>> + serio:
>>>>>>
>>>>>> All of these children are pointless - no resources. Drop all of them,
>>>>>> it's btw explicitly documented rule in writing bindings.
>>>>>>
>>>>>
>>>>> They are all needed to be able to disable them individually from the
>>>>> device tree if needed.
>>>>
>>>> They should not be disabled from DT, so they are not valid here. The
>>>> given EC for given device is fixed/static. Does not change.
>>>>
>>>
>>> Have you considered a possibility that function may be
>>> disabled/unrouted within the controller. By the vendor.
>>
>> And then it is implied by the compatible, so no need for any of that.
>> Otherwise, if it is not specific per device, then specifying it for DTS
>> for all devices would make no sense.
>>
>
> So you propose introduce a compatible for every single ec used in
> transformers instead of simply disable unpopulated functions? And how
> then battery and charger can reach monitored cell if they have no
> dedicated node?
Just like for other bindings for nodes without resources, fold into
parent. This is already explained in writing bindings, so you could have
just read that. I will pass with answering more questions till you read
that doc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-10 11:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <cb91898e-10f1-4d64-bace-41bbed08179b@kernel.org>
вт, 10 лют. 2026 р. о 13:04 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 10/02/2026 11:59, Svyatoslav Ryhel wrote:
> >>>>> + asus,clear-factory-mode:
> >>>>> + type: boolean
> >>>>> + description: clear Factory Mode bit in EC control register
> >>>>
> >>>> Why would this be a static/fixed property over lifecycle of all devices?
> >>>>
> >>>
> >>> Specify pls.
> >>
> >> Provide rationale why we need to clear it every time, not once. Or any
> >> other rationale why we would accept that property.
> >>
> >
> > Cause it is done by original Asus code and Asus did not provide
> > schematic or any data apart from downstream source regarding this EC.
>
> So that's a no. downstream code which is poor quality, not following DT
> rules at all, is never an argument for a DT property.
>
This property indicates that this controller on every reset restores
factory bit hence it must be cleared. Bit is write only and cannot be
detected. EC remains in factory mode which blocks its functions.
> >
> >>>
> >>>>> +
> >>>>> + battery:
> >>>>> + type: object
> >>>>> + $ref: /schemas/power/supply/power-supply.yaml
> >>>>> + unevaluatedProperties: false
> >>>>> +
> >>>>> + properties:
> >>>>> + compatible:
> >>>>> + const: asus,ec-battery
> >>>>> +
> >>>>> + required:
> >>>>> + - compatible
> >>>>> +
> >>>>> + charger:
> >>>>> + type: object
> >>>>> + $ref: /schemas/power/supply/power-supply.yaml
> >>>>> + additionalProperties: false
> >>>>> +
> >>>>> + properties:
> >>>>> + compatible:
> >>>>> + const: asus,ec-charger
> >>>>> +
> >>>>> + monitored-battery: true
> >>>>> +
> >>>>> + required:
> >>>>> + - compatible
> >>>>> +
> >>>>> + keyboard-ext:
> >>>>> + type: object
> >>>>> + description: top row of multimedia keys
> >>>>> + additionalProperties: false
> >>>>> +
> >>>>> + properties:
> >>>>> + compatible:
> >>>>> + const: asus,ec-keys
> >>>>> +
> >>>>> + required:
> >>>>> + - compatible
> >>>>> +
> >>>>> + led:
> >>>>> + type: object
> >>>>> + additionalProperties: false
> >>>>> +
> >>>>> + properties:
> >>>>> + compatible:
> >>>>> + const: asus,ec-led
> >>>>> +
> >>>>> + required:
> >>>>> + - compatible
> >>>>> +
> >>>>> + serio:
> >>>>
> >>>> All of these children are pointless - no resources. Drop all of them,
> >>>> it's btw explicitly documented rule in writing bindings.
> >>>>
> >>>
> >>> They are all needed to be able to disable them individually from the
> >>> device tree if needed.
> >>
> >> They should not be disabled from DT, so they are not valid here. The
> >> given EC for given device is fixed/static. Does not change.
> >>
> >
> > Have you considered a possibility that function may be
> > disabled/unrouted within the controller. By the vendor.
>
> And then it is implied by the compatible, so no need for any of that.
> Otherwise, if it is not specific per device, then specifying it for DTS
> for all devices would make no sense.
>
So you propose introduce a compatible for every single ec used in
transformers instead of simply disable unpopulated functions? And how
then battery and charger can reach monitored cell if they have no
dedicated node?
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/9] dt-bindings: misc: document ASUS Transformers EC DockRAM
From: Svyatoslav Ryhel @ 2026-02-10 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <e73d6634-7f31-4dcf-87dd-c8192e7e66c1@kernel.org>
вт, 10 лют. 2026 р. о 12:50 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 10/02/2026 10:42, Svyatoslav Ryhel wrote:
> > вт, 10 лют. 2026 р. о 11:25 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >>
> >> On Mon, Feb 09, 2026 at 12:43:59PM +0200, Svyatoslav Ryhel wrote:
> >>> Documenting an I2C device used in conjunction with the EC on ASUS
> >>> Transformers. The main function of DockRAM (the name used by downstream
> >>> ASUS sources) is to provide power-related functions, such as battery and
> >>> charger communication. The device is exposed as an individual entity
> >>> because multiple embedded controllers can utilize the same DockRAM
> >>> instance.
> >>>
> >>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >>> ---
> >>> .../bindings/misc/asus,dockram.yaml | 40 +++++++++++++++++++
> >>> 1 file changed, 40 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/misc/asus,dockram.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/misc/asus,dockram.yaml b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
> >>> new file mode 100644
> >>> index 000000000000..0cfde619ba01
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
> >>
> >> Not a misc device. Find appropriate place, e.g. for EC or docking or
> >> laptop devices or power-related.
> >>
> >
> > Why not misc? be more specific pls where you want it to be.
>
> Because there is no such device as "misc". Otherwise explain me what
> sort of device is "misc".
>
> I already wrote where I want it to be placed. You keep bouncing
> questions pointlessly, even when given exact request.
>
Among your list only EC exists. There are no docking or laptop devices
or power-related. Hence asking.
>
> >
> >>> @@ -0,0 +1,40 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/misc/asus,dockram.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Asus Transformer EC DockRAM
> >>> +
> >>> +maintainers:
> >>> + - Svyatoslav Ryhel <clamor95@gmail.com>
> >>> +
> >>> +description:
> >>> + Dedicated i2c device used to provide power related functions of the
> >>> + embedded controller used in ASUS Transformer device family.
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + const: asus,dockram
> >>
> >> Way too generic compatible. You are not documenting here all ASUS
> >> laptops/devices dockram. For example this implies dockram is also on
> >> ASUS Vivobook... or on any other asus device.
> >>
> >
> > Asus were not so generous to provide more specific data, they call
> > this device dockram in their sources.
>
>
>
> >
> >>> +
> >>> + reg:
> >>> + maxItems: 1
> >>> +
> >>> +required:
> >>> + - compatible
> >>> + - reg
> >>> +
> >>
> >> Device looks weirdly empty. Probably you have it only to instantiate I2C
> >> handle, so what you really wanted is i2c-parent. This is not a real
> >> device.
> >>
> >
> > WDYM? it is a real physical i2c device located on a i2c bus and probed
> > by i2c driver just fine. Maybe you will deny RTC being a real device
>
> Driver does not matter here.
>
It seems that you see a "forbidden" word and tear it out of context.
> > like it was done for example for max77663 which now causes a massive
> > issues since it can occupy different i2c addresses?
>
> Then describe what is the device here. So far it looks exactly like
> "ec-dock" for which you already have a binding.
>
Wrong, it has nothing to do with "ec-dock" specifically. It is has a
pretty discrete description. It used to provide power related
functions of the embedded controller used in ASUS Transformer device
family. To access to battery stats, charger status, leds control. Can
be used by multiple controllers at once (like on TF701T or TF600T)
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 11:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n1foyy9g7MAurSAyLCUHTzrPPu0ceqy9YpcDA9uzgjGng@mail.gmail.com>
On 10/02/2026 11:59, Svyatoslav Ryhel wrote:
>>>>> + asus,clear-factory-mode:
>>>>> + type: boolean
>>>>> + description: clear Factory Mode bit in EC control register
>>>>
>>>> Why would this be a static/fixed property over lifecycle of all devices?
>>>>
>>>
>>> Specify pls.
>>
>> Provide rationale why we need to clear it every time, not once. Or any
>> other rationale why we would accept that property.
>>
>
> Cause it is done by original Asus code and Asus did not provide
> schematic or any data apart from downstream source regarding this EC.
So that's a no. downstream code which is poor quality, not following DT
rules at all, is never an argument for a DT property.
>
>>>
>>>>> +
>>>>> + battery:
>>>>> + type: object
>>>>> + $ref: /schemas/power/supply/power-supply.yaml
>>>>> + unevaluatedProperties: false
>>>>> +
>>>>> + properties:
>>>>> + compatible:
>>>>> + const: asus,ec-battery
>>>>> +
>>>>> + required:
>>>>> + - compatible
>>>>> +
>>>>> + charger:
>>>>> + type: object
>>>>> + $ref: /schemas/power/supply/power-supply.yaml
>>>>> + additionalProperties: false
>>>>> +
>>>>> + properties:
>>>>> + compatible:
>>>>> + const: asus,ec-charger
>>>>> +
>>>>> + monitored-battery: true
>>>>> +
>>>>> + required:
>>>>> + - compatible
>>>>> +
>>>>> + keyboard-ext:
>>>>> + type: object
>>>>> + description: top row of multimedia keys
>>>>> + additionalProperties: false
>>>>> +
>>>>> + properties:
>>>>> + compatible:
>>>>> + const: asus,ec-keys
>>>>> +
>>>>> + required:
>>>>> + - compatible
>>>>> +
>>>>> + led:
>>>>> + type: object
>>>>> + additionalProperties: false
>>>>> +
>>>>> + properties:
>>>>> + compatible:
>>>>> + const: asus,ec-led
>>>>> +
>>>>> + required:
>>>>> + - compatible
>>>>> +
>>>>> + serio:
>>>>
>>>> All of these children are pointless - no resources. Drop all of them,
>>>> it's btw explicitly documented rule in writing bindings.
>>>>
>>>
>>> They are all needed to be able to disable them individually from the
>>> device tree if needed.
>>
>> They should not be disabled from DT, so they are not valid here. The
>> given EC for given device is fixed/static. Does not change.
>>
>
> Have you considered a possibility that function may be
> disabled/unrouted within the controller. By the vendor.
And then it is implied by the compatible, so no need for any of that.
Otherwise, if it is not specific per device, then specifying it for DTS
for all devices would make no sense.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-10 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <d1973810-d3f5-4ed7-ba0f-6bf93c1c7f3d@kernel.org>
вт, 10 лют. 2026 р. о 12:48 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 10/02/2026 10:37, Svyatoslav Ryhel wrote:
> > вт, 10 лют. 2026 р. о 11:22 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >>
> >> On Mon, Feb 09, 2026 at 12:44:01PM +0200, Svyatoslav Ryhel wrote:
> >>> Document embedded controller used in ASUS Transformer device series.
> >>>
> >>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >>> ---
> >>> .../devicetree/bindings/mfd/asus,ec.yaml | 152 ++++++++++++++++++
> >>> 1 file changed, 152 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/mfd/asus,ec.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mfd/asus,ec.yaml b/Documentation/devicetree/bindings/mfd/asus,ec.yaml
> >>> new file mode 100644
> >>> index 000000000000..1d1a62761b71
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mfd/asus,ec.yaml
> >>
> >> EC do not go to MFD, but to dedicated directory (there is such).
> >>
> >
> > Noted
> >
> >>> @@ -0,0 +1,152 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/mfd/asus,ec.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: ASUS Transformer's Embedded Controller
> >>> +
> >>> +description:
> >>> + Several Nuvoton based Embedded Controller attached to an I2C bus,
> >>> + running a custom ASUS firmware, specific to the Asus Transformer
> >>> + device series.
> >>> +
> >>> +maintainers:
> >>> + - Svyatoslav Ryhel <clamor95@gmail.com>
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + oneOf:
> >>
> >> Drop oneOf
> >>
> >
> > Noted
> >
> >>> + - enum:
> >>> + - asus,ec-pad # Pad part of Asus Transformer
> >>> + - asus,ec-dock # Dock part of Asus Transformer
> >>
> >>
> >> Compatibles are way too generic. "ec" basically means you document all
> >> Asus EC, which is for sure not true. You need specific compatible for
> >> this specific model.
> >>
> >
> > Asus were not so generous to provide more specific data, they call
> > there controllers asusdec and asusped in their sources.
>
> Look how other ECs are called. Your device is not "", but e.g.
> "Transformer".
>
> >
> >> Missing blank line.
> >>
> >
> > noted
> >
> >>> + reg:
> >>> + maxItems: 1
> >>> +
> >>> + interrupts:
> >>> + maxItems: 1
> >>> +
> >>> + request-gpio:
> >>
> >> gpio is deprecated. gpios, look at any other binding.
> >>
> >
> > noted
> >
> >>> + maxItems: 1
> >>> +
> >>> + asus,dockram:
> >>> + $ref: /schemas/types.yaml#/definitions/phandle
> >>> + description: I2C device used to access power related functions.
> >>> +
> >>> + asus,clear-factory-mode:
> >>> + type: boolean
> >>> + description: clear Factory Mode bit in EC control register
> >>
> >> Why would this be a static/fixed property over lifecycle of all devices?
> >>
> >
> > Specify pls.
>
> Provide rationale why we need to clear it every time, not once. Or any
> other rationale why we would accept that property.
>
Cause it is done by original Asus code and Asus did not provide
schematic or any data apart from downstream source regarding this EC.
> >
> >>> +
> >>> + battery:
> >>> + type: object
> >>> + $ref: /schemas/power/supply/power-supply.yaml
> >>> + unevaluatedProperties: false
> >>> +
> >>> + properties:
> >>> + compatible:
> >>> + const: asus,ec-battery
> >>> +
> >>> + required:
> >>> + - compatible
> >>> +
> >>> + charger:
> >>> + type: object
> >>> + $ref: /schemas/power/supply/power-supply.yaml
> >>> + additionalProperties: false
> >>> +
> >>> + properties:
> >>> + compatible:
> >>> + const: asus,ec-charger
> >>> +
> >>> + monitored-battery: true
> >>> +
> >>> + required:
> >>> + - compatible
> >>> +
> >>> + keyboard-ext:
> >>> + type: object
> >>> + description: top row of multimedia keys
> >>> + additionalProperties: false
> >>> +
> >>> + properties:
> >>> + compatible:
> >>> + const: asus,ec-keys
> >>> +
> >>> + required:
> >>> + - compatible
> >>> +
> >>> + led:
> >>> + type: object
> >>> + additionalProperties: false
> >>> +
> >>> + properties:
> >>> + compatible:
> >>> + const: asus,ec-led
> >>> +
> >>> + required:
> >>> + - compatible
> >>> +
> >>> + serio:
> >>
> >> All of these children are pointless - no resources. Drop all of them,
> >> it's btw explicitly documented rule in writing bindings.
> >>
> >
> > They are all needed to be able to disable them individually from the
> > device tree if needed.
>
> They should not be disabled from DT, so they are not valid here. The
> given EC for given device is fixed/static. Does not change.
>
Have you considered a possibility that function may be
disabled/unrouted within the controller. By the vendor.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/9] dt-bindings: misc: document ASUS Transformers EC DockRAM
From: Krzysztof Kozlowski @ 2026-02-10 10:50 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n3Pzvzt+LmOH_peCtpx8DP2-GiRv--6-ppQUaa51AXRFw@mail.gmail.com>
On 10/02/2026 10:42, Svyatoslav Ryhel wrote:
> вт, 10 лют. 2026 р. о 11:25 Krzysztof Kozlowski <krzk@kernel.org> пише:
>>
>> On Mon, Feb 09, 2026 at 12:43:59PM +0200, Svyatoslav Ryhel wrote:
>>> Documenting an I2C device used in conjunction with the EC on ASUS
>>> Transformers. The main function of DockRAM (the name used by downstream
>>> ASUS sources) is to provide power-related functions, such as battery and
>>> charger communication. The device is exposed as an individual entity
>>> because multiple embedded controllers can utilize the same DockRAM
>>> instance.
>>>
>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>> ---
>>> .../bindings/misc/asus,dockram.yaml | 40 +++++++++++++++++++
>>> 1 file changed, 40 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/misc/asus,dockram.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/asus,dockram.yaml b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
>>> new file mode 100644
>>> index 000000000000..0cfde619ba01
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
>>
>> Not a misc device. Find appropriate place, e.g. for EC or docking or
>> laptop devices or power-related.
>>
>
> Why not misc? be more specific pls where you want it to be.
Because there is no such device as "misc". Otherwise explain me what
sort of device is "misc".
I already wrote where I want it to be placed. You keep bouncing
questions pointlessly, even when given exact request.
>
>>> @@ -0,0 +1,40 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/misc/asus,dockram.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Asus Transformer EC DockRAM
>>> +
>>> +maintainers:
>>> + - Svyatoslav Ryhel <clamor95@gmail.com>
>>> +
>>> +description:
>>> + Dedicated i2c device used to provide power related functions of the
>>> + embedded controller used in ASUS Transformer device family.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: asus,dockram
>>
>> Way too generic compatible. You are not documenting here all ASUS
>> laptops/devices dockram. For example this implies dockram is also on
>> ASUS Vivobook... or on any other asus device.
>>
>
> Asus were not so generous to provide more specific data, they call
> this device dockram in their sources.
>
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> +
>>
>> Device looks weirdly empty. Probably you have it only to instantiate I2C
>> handle, so what you really wanted is i2c-parent. This is not a real
>> device.
>>
>
> WDYM? it is a real physical i2c device located on a i2c bus and probed
> by i2c driver just fine. Maybe you will deny RTC being a real device
Driver does not matter here.
> like it was done for example for max77663 which now causes a massive
> issues since it can occupy different i2c addresses?
Then describe what is the device here. So far it looks exactly like
"ec-dock" for which you already have a binding.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 10:48 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n3fizf=r58Fr4YQ6pnjHq5p-7yFz95obss6w6x0bfgnDg@mail.gmail.com>
On 10/02/2026 10:37, Svyatoslav Ryhel wrote:
> вт, 10 лют. 2026 р. о 11:22 Krzysztof Kozlowski <krzk@kernel.org> пише:
>>
>> On Mon, Feb 09, 2026 at 12:44:01PM +0200, Svyatoslav Ryhel wrote:
>>> Document embedded controller used in ASUS Transformer device series.
>>>
>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>> ---
>>> .../devicetree/bindings/mfd/asus,ec.yaml | 152 ++++++++++++++++++
>>> 1 file changed, 152 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/mfd/asus,ec.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/asus,ec.yaml b/Documentation/devicetree/bindings/mfd/asus,ec.yaml
>>> new file mode 100644
>>> index 000000000000..1d1a62761b71
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/asus,ec.yaml
>>
>> EC do not go to MFD, but to dedicated directory (there is such).
>>
>
> Noted
>
>>> @@ -0,0 +1,152 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/mfd/asus,ec.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: ASUS Transformer's Embedded Controller
>>> +
>>> +description:
>>> + Several Nuvoton based Embedded Controller attached to an I2C bus,
>>> + running a custom ASUS firmware, specific to the Asus Transformer
>>> + device series.
>>> +
>>> +maintainers:
>>> + - Svyatoslav Ryhel <clamor95@gmail.com>
>>> +
>>> +properties:
>>> + compatible:
>>> + oneOf:
>>
>> Drop oneOf
>>
>
> Noted
>
>>> + - enum:
>>> + - asus,ec-pad # Pad part of Asus Transformer
>>> + - asus,ec-dock # Dock part of Asus Transformer
>>
>>
>> Compatibles are way too generic. "ec" basically means you document all
>> Asus EC, which is for sure not true. You need specific compatible for
>> this specific model.
>>
>
> Asus were not so generous to provide more specific data, they call
> there controllers asusdec and asusped in their sources.
Look how other ECs are called. Your device is not "", but e.g.
"Transformer".
>
>> Missing blank line.
>>
>
> noted
>
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + interrupts:
>>> + maxItems: 1
>>> +
>>> + request-gpio:
>>
>> gpio is deprecated. gpios, look at any other binding.
>>
>
> noted
>
>>> + maxItems: 1
>>> +
>>> + asus,dockram:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: I2C device used to access power related functions.
>>> +
>>> + asus,clear-factory-mode:
>>> + type: boolean
>>> + description: clear Factory Mode bit in EC control register
>>
>> Why would this be a static/fixed property over lifecycle of all devices?
>>
>
> Specify pls.
Provide rationale why we need to clear it every time, not once. Or any
other rationale why we would accept that property.
>
>>> +
>>> + battery:
>>> + type: object
>>> + $ref: /schemas/power/supply/power-supply.yaml
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + compatible:
>>> + const: asus,ec-battery
>>> +
>>> + required:
>>> + - compatible
>>> +
>>> + charger:
>>> + type: object
>>> + $ref: /schemas/power/supply/power-supply.yaml
>>> + additionalProperties: false
>>> +
>>> + properties:
>>> + compatible:
>>> + const: asus,ec-charger
>>> +
>>> + monitored-battery: true
>>> +
>>> + required:
>>> + - compatible
>>> +
>>> + keyboard-ext:
>>> + type: object
>>> + description: top row of multimedia keys
>>> + additionalProperties: false
>>> +
>>> + properties:
>>> + compatible:
>>> + const: asus,ec-keys
>>> +
>>> + required:
>>> + - compatible
>>> +
>>> + led:
>>> + type: object
>>> + additionalProperties: false
>>> +
>>> + properties:
>>> + compatible:
>>> + const: asus,ec-led
>>> +
>>> + required:
>>> + - compatible
>>> +
>>> + serio:
>>
>> All of these children are pointless - no resources. Drop all of them,
>> it's btw explicitly documented rule in writing bindings.
>>
>
> They are all needed to be able to disable them individually from the
> device tree if needed.
They should not be disabled from DT, so they are not valid here. The
given EC for given device is fixed/static. Does not change.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/9] dt-bindings: misc: document ASUS Transformers EC DockRAM
From: Svyatoslav Ryhel @ 2026-02-10 9:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <20260210-hidden-swinging-galago-fdcfa3@quoll>
вт, 10 лют. 2026 р. о 11:25 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Mon, Feb 09, 2026 at 12:43:59PM +0200, Svyatoslav Ryhel wrote:
> > Documenting an I2C device used in conjunction with the EC on ASUS
> > Transformers. The main function of DockRAM (the name used by downstream
> > ASUS sources) is to provide power-related functions, such as battery and
> > charger communication. The device is exposed as an individual entity
> > because multiple embedded controllers can utilize the same DockRAM
> > instance.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/misc/asus,dockram.yaml | 40 +++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/asus,dockram.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/misc/asus,dockram.yaml b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
> > new file mode 100644
> > index 000000000000..0cfde619ba01
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/asus,dockram.yaml
>
> Not a misc device. Find appropriate place, e.g. for EC or docking or
> laptop devices or power-related.
>
Why not misc? be more specific pls where you want it to be.
> > @@ -0,0 +1,40 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/misc/asus,dockram.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Asus Transformer EC DockRAM
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + Dedicated i2c device used to provide power related functions of the
> > + embedded controller used in ASUS Transformer device family.
> > +
> > +properties:
> > + compatible:
> > + const: asus,dockram
>
> Way too generic compatible. You are not documenting here all ASUS
> laptops/devices dockram. For example this implies dockram is also on
> ASUS Vivobook... or on any other asus device.
>
Asus were not so generous to provide more specific data, they call
this device dockram in their sources.
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
>
> Device looks weirdly empty. Probably you have it only to instantiate I2C
> handle, so what you really wanted is i2c-parent. This is not a real
> device.
>
WDYM? it is a real physical i2c device located on a i2c bus and probed
by i2c driver just fine. Maybe you will deny RTC being a real device
like it was done for example for max77663 which now causes a massive
issues since it can occupy different i2c addresses?
> Best regards,
> Krzysztof
>
^ 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