* [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
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-10 9:37 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-sexy-grumpy-sambar-44edd2@quoll>
вт, 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.
> 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.
> > +
> > + 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.
> 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 9:25 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: <20260209104407.116426-2-clamor95@gmail.com>
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.
> @@ -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.
> +
> + 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.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-10 9:22 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: <20260209104407.116426-4-clamor95@gmail.com>
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).
> @@ -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
> + - 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.
Missing blank line.
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + request-gpio:
gpio is deprecated. gpios, look at any other binding.
> + 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?
> +
> + 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.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Krzysztof Kozlowski @ 2026-02-10 8:32 UTC (permalink / raw)
To: Rakesh Kota
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
In-Reply-To: <20260210082612.3xakor2yo4h3dbra@hu-kotarake-hyd.qualcomm.com>
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.
> > 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 v2 1/3] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rakesh Kota @ 2026-02-10 8:26 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: <b0ade3b3-f2b3-4dbe-9e21-920bbda1d077@kernel.org>
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, 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/
Best regards
Rakesh Kota
> >
> > Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> > ---
>
> Where is the changelog? Nothing in cover letter explained what was
> happening with this patch, nothing is here.
>
> > .../devicetree/bindings/power/reset/qcom,pon.yaml | 16 ++++++++++------
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..14b85b0d97da12c756cfe2ce33853501ba4ca46c 100644
> > --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > @@ -17,12 +17,16 @@ description: |
> >
> > properties:
> > compatible:
> > - enum:
> > - - qcom,pm8916-pon
> > - - qcom,pm8941-pon
> > - - qcom,pms405-pon
> > - - qcom,pm8998-pon
> > - - qcom,pmk8350-pon
> > + oneOf:
> > + - enum:
> > + - qcom,pm8916-pon
> > + - qcom,pm8941-pon
> > + - qcom,pms405-pon
> > + - qcom,pm8998-pon
>
> Move this one up to to fix sorting while at it.
>
> > + - qcom,pmk8350-pon
>
> And this above pms.
>
> > + - items:
> > + - const: qcom,pmm8654au-pon
> > + - const: qcom,pmk8350-pon
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: input: qcom,pm8941-pwrkey: Document PMM8654AU
From: Dmitry Torokhov @ 2026-02-10 6:20 UTC (permalink / raw)
To: Rakesh Kota
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Courtney Cavin, Bjorn Andersson, Konrad Dybcio,
linux-pm, devicetree, linux-kernel, linux-arm-msm, linux-input
In-Reply-To: <20260209-add_pwrkey_and_resin-v2-2-f944d87b9a93@oss.qualcomm.com>
On Mon, Feb 09, 2026 at 06:53:37PM +0530, Rakesh Kota wrote:
> Add compatible strings for PMM8654AU power key and resin support.
> These blocks are compatible with PMK8350, so use that as the
> fallback.
>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Applied, thank you.
--
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