* Re: [PATCH 2/2] iio: orientation: hid-sensor-rotation: fix quaternion alignment
From: Andy Shevchenko @ 2026-02-16 7:45 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada, linux-iio, linux-kernel, Jonathan Cameron,
linux-input, Lixu Zhang
In-Reply-To: <20260214-iio-fix-repeat-alignment-v1-2-47f01288c803@baylibre.com>
On Sat, Feb 14, 2026 at 03:00:21PM -0600, David Lechner wrote:
> Restore the alignment of sampled_vals to 16 bytes by using
> IIO_DECLARE_REPEATED_ELEMENT(). This field contains a quaternion value
> which scan_type.repeat = 4 and storagebits = 32. So the alignment must
> be 16 bytes to match the assumptions of iio_storage_bytes_for_si() and
> also to not break userspace.
...
> struct {
> - s32 sampled_vals[4];
> + IIO_DECLARE_REPEATED_ELEMENT(s32, sampled_vals, 4);
This becomes
IIO_DECLARE_QUATERNION(s32, sampled_vals);
> aligned_s64 timestamp;
> } scan;
In the similar way we can address drivers/iio/imu/bno055/bno055.c.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] i2c: core-smbus: validate block size in __i2c_smbus_xfer() for native SMBus path
From: Rostislav Nesin @ 2026-02-16 8:54 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rostislav Nesin, Michael Zaidman, Jiri Kosina, Benjamin Tissoires,
linux-i2c, linux-input, linux-kernel, lvc-project,
syzbot+64ca69977b37604cd6d9
In the native SMBus path, data->block[0] specifies the data length
for block transfers. When the adapter provides a native smbus_xfer,
__i2c_smbus_xfer() calls it without any prior validation of
data->block[0], so every native SMBus adapter (e.g. hid-ft260,
hid-mcp2221) is exposed to out-of-bounds access if userspace passes
block[0] > 32.
This triggered the following out-of-bounds access reported by syzbot
in the hid-ft260 driver:
BUG: KASAN: stack-out-of-bounds in ft260_smbus_write+0x19b/0x2f0
drivers/hid/hid-ft260.c:486
Read of size 42 at addr ffffc90003427d81 by task syz.2.65/6119
CPU: 0 UID: 0 PID: 6119 Comm: syz.2.65 Not tainted syzkaller #0
PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 10/25/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:194 [inline]
kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:200
__asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
ft260_smbus_xfer+0x22c/0x640 drivers/hid/hid-ft260.c:736
__i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:591 [inline]
__i2c_smbus_xfer+0x4f0/0xf60 drivers/i2c/i2c-core-smbus.c:554
i2c_smbus_xfer drivers/i2c/i2c-core-smbus.c:546 [inline]
i2c_smbus_xfer+0x200/0x3c0 drivers/i2c/i2c-core-smbus.c:536
i2cdev_ioctl_smbus+0x237/0x990 drivers/i2c/i2c-dev.c:389
i2cdev_ioctl+0x361/0x840 drivers/i2c/i2c-dev.c:478
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Add validation for data->block[0] > I2C_SMBUS_BLOCK_MAX for
I2C_SMBUS_BLOCK_DATA, I2C_SMBUS_I2C_BLOCK_DATA and
I2C_SMBUS_BLOCK_PROC_CALL cases to avoid out-of-bounds access.
For I2C_SMBUS_BLOCK_DATA validate only on WRITE: on READ the length
comes from the device (Count byte, see smbus-protocol.rst). For
I2C_SMBUS_I2C_BLOCK_DATA and I2C_SMBUS_BLOCK_PROC_CALL the write phase
uses block[0] from the caller, so validate in both cases.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Reported-by: syzbot+64ca69977b37604cd6d9@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Rostislav Nesin <ssp.nesin@crpt.ru>
---
drivers/i2c/i2c-core-smbus.c | 34 ++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -575,6 +575,40 @@ s32 __i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
flags &= I2C_M_TEN | I2C_CLIENT_PEC | I2C_CLIENT_SCCB;
+ if (data) {
+ switch (protocol) {
+ case I2C_SMBUS_BLOCK_DATA:
+ if (read_write == I2C_SMBUS_WRITE &&
+ data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev,
+ "Invalid block write size %d\n",
+ data->block[0]);
+ return -EINVAL;
+ }
+ break;
+ case I2C_SMBUS_I2C_BLOCK_DATA:
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev,
+ "Invalid block %s size %d\n",
+ read_write == I2C_SMBUS_READ ?
+ "read" : "write",
+ data->block[0]);
+ return -EINVAL;
+ }
+ break;
+ case I2C_SMBUS_BLOCK_PROC_CALL:
+ if (data->block[0] > I2C_SMBUS_BLOCK_MAX) {
+ dev_err(&adapter->dev,
+ "Invalid block write size %d\n",
+ data->block[0]);
+ return -EINVAL;
+ }
+ break;
+ default:
+ break;
+ }
+ }
+
xfer_func = adapter->algo->smbus_xfer;
if (i2c_in_atomic_xfer_mode()) {
if (adapter->algo->smbus_xfer_atomic)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2] HID: asus: synchronize fn_lock_sync_work initialization and teardown
From: Sahil Chandna @ 2026-02-16 12:10 UTC (permalink / raw)
To: jikos, bentiss, connorbelli2003, linux-input, linux-kernel, stern
In-Reply-To: <20260204182029.278659-1-chandna.sahil@gmail.com>
On Wed, Feb 04, 2026 at 11:50:29PM +0530, Sahil Chandna wrote:
>Syzbot reported a workqueue warning where cancel_work_sync() was
>called on an uninitialized work_struct. Fix this by adding a mutex lock and
>initializing fn_lock_sync_work before marking fn_lock as enabled.
>This ensures cancel_work_sync() is only called for an initialized work.
>
>Fixes: f631011e36b8 ("HID: hid-asus: Implement fn lock for Asus ProArt P16")
>Reported-by: syzbot+13f8286fa2de04a7cd48@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=13f8286fa2de04a7cd48
>Suggested-by: Alan Stern <stern@rowland.harvard.edu>
>Signed-off-by: Sahil Chandna <chandna.sahil@gmail.com>
>---
>link to v1: https://lore.kernel.org/all/20260130155204.96831-1-chandna.sahil@gmail.com/
>changes since v1:
>- Add mutex locking between init_work and cancel_work.
>
>Testing:
>- Reproduced bug on local setup and original syz reproducer.
>- Tested with fix and original C reproducer, issue is not reproduced
>locally.
>---
> drivers/hid/hid-asus.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>index 1b9793f7c07e..2d6b6e363bde 100644
>--- a/drivers/hid/hid-asus.c
>+++ b/drivers/hid/hid-asus.c
>@@ -147,6 +147,7 @@ struct asus_drvdata {
> unsigned long battery_next_query;
> struct work_struct fn_lock_sync_work;
> bool fn_lock;
>+ struct mutex lock;
> };
>
> static int asus_report_battery(struct asus_drvdata *, u8 *, int);
>@@ -960,8 +961,10 @@ static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
> }
>
> if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
>- drvdata->fn_lock = true;
>+ mutex_lock(&drvdata->lock);
> INIT_WORK(&drvdata->fn_lock_sync_work, asus_sync_fn_lock);
>+ drvdata->fn_lock = true;
>+ mutex_unlock(&drvdata->lock);
> asus_kbd_set_fn_lock(hdev, true);
> }
>
>@@ -1258,6 +1261,7 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>
> drvdata->hdev = hdev;
>+ mutex_init(&drvdata->lock);
>
> if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
> ret = asus_battery_probe(hdev);
>@@ -1343,8 +1347,10 @@ static void asus_remove(struct hid_device *hdev)
> cancel_work_sync(&drvdata->kbd_backlight->work);
> }
>
>- if (drvdata->quirks & QUIRK_HID_FN_LOCK)
>+ mutex_lock(&drvdata->lock);
>+ if ((drvdata->quirks & QUIRK_HID_FN_LOCK) && drvdata->fn_lock)
> cancel_work_sync(&drvdata->fn_lock_sync_work);
>+ mutex_unlock(&drvdata->lock);
>
> hid_hw_stop(hdev);
> }
>--
>2.50.1
>
Hi,
just checking if there is any feedback regarding this patch.
regards,
Sahil
^ permalink raw reply
* [PATCHv2 0/2] hid: hid-pl.c update
From: Oliver Neukum @ 2026-02-16 13:43 UTC (permalink / raw)
To: jikos, bentiss, linux-input
This seems to have fallen through the cracks. The first
patch eliminates a failure to properly handle errors
in probe. We have to give up in the error case or
a pointer will remain uninitialized and wil eventually be followed.
Secondly we fix a debug macro by going to dynamic debugging.
V2: resend the full series
^ permalink raw reply
* [PATCHv2 1/2] hid: hid-pl: handle probe errors
From: Oliver Neukum @ 2026-02-16 13:44 UTC (permalink / raw)
To: jikos, bentiss, linux-input; +Cc: Oliver Neukum, stable
In-Reply-To: <20260216134958.260648-1-oneukum@suse.com>
Errors in init must be reported back or we'll
follow a NULL pointer the first time FF is used,
because plff_init() initializes the private member.
V2: resend full series
Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2in1 Adapter")
Cc: <stable@vger.kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/hid/hid-pl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
index 3c8827081dea..dc11d5322fc0 100644
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -194,9 +194,14 @@ static int pl_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto err;
}
- plff_init(hdev);
+ ret = plff_init(hdev);
+ if (ret)
+ goto stop;
return 0;
+
+stop:
+ hid_hw_stop(hdev);
err:
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] hid: hid-pl: eliminate private debug macro
From: Oliver Neukum @ 2026-02-16 13:44 UTC (permalink / raw)
To: jikos, bentiss, linux-input; +Cc: Oliver Neukum
In-Reply-To: <20260216134958.260648-1-oneukum@suse.com>
Use proper dynamic debugging.
V2: resend full series
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/hid/hid-pl.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
index dc11d5322fc0..4b6b33597d11 100644
--- a/drivers/hid/hid-pl.c
+++ b/drivers/hid/hid-pl.c
@@ -24,10 +24,6 @@
*/
-/* #define DEBUG */
-
-#define debug(format, arg...) pr_debug("hid-plff: " format "\n" , ## arg)
-
#include <linux/input.h>
#include <linux/slab.h>
#include <linux/module.h>
@@ -53,14 +49,14 @@ static int hid_plff_play(struct input_dev *dev, void *data,
left = effect->u.rumble.strong_magnitude;
right = effect->u.rumble.weak_magnitude;
- debug("called with 0x%04x 0x%04x", left, right);
+ dev_dbg(&dev->dev, "called with 0x%04x 0x%04x", left, right);
left = left * plff->maxval / 0xffff;
right = right * plff->maxval / 0xffff;
*plff->strong = left;
*plff->weak = right;
- debug("running with 0x%02x 0x%02x", left, right);
+ dev_dbg(&dev->dev,"running with 0x%02x 0x%02x", left, right);
hid_hw_request(hid, plff->report, HID_REQ_SET_REPORT);
return 0;
@@ -119,7 +115,7 @@ static int plff_init(struct hid_device *hid)
report->field[0]->value[1] = 0x00;
strong = &report->field[0]->value[2];
weak = &report->field[0]->value[3];
- debug("detected single-field device");
+ dev_dbg(&hid->dev, "detected single-field device");
} else if (report->field[0]->maxusage == 1 &&
report->field[0]->usage[0].hid ==
(HID_UP_LED | 0x43) &&
@@ -134,7 +130,7 @@ static int plff_init(struct hid_device *hid)
weak = &report->field[3]->value[0];
if (hid->vendor == USB_VENDOR_ID_JESS2)
maxval = 0xff;
- debug("detected 4-field device");
+ dev_dbg(&hid->dev, "detected 4-field device");
} else {
hid_err(hid, "not enough fields or values\n");
return -ENODEV;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/2] iio: orientation: hid-sensor-rotation: fix quaternion alignment
From: David Lechner @ 2026-02-16 15:25 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada, linux-iio, linux-kernel, Jonathan Cameron,
linux-input, Lixu Zhang
In-Reply-To: <aZLKy4l6OlPgIkZx@smile.fi.intel.com>
On 2/16/26 1:44 AM, Andy Shevchenko wrote:
> On Sat, Feb 14, 2026 at 03:00:19PM -0600, David Lechner wrote:
>> The main point of this series is to fix a regression reported in
>> hid-sensor-rotation where the alignment of the quaternion field in the
>> data was inadvertently changed from 16 bytes to 8 bytes. This is an
>> unusually case (one of only 2 in the kernel) where the .repeat field of
>> struct iio_scan_type is used and we have such a requirement. (The other
>> case uses u16 instead of u32, so it wasn't affected.)
>>
>> To make the reason for the alignment more explicit to future readers,
>> we introduce a new macro, IIO_DECLARE_REPEATED_ELEMENT, to declare the
>> array with proper allignment. This is meant to follow the pattern of
>> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.
>
> In both cases it's quaternion, maybe be more explicit and define
> IIO_DECLARE_QUATERNION() ?
>
It is really the fact that the scan_type has .repeat > 1 that requires
this, so I was trying to make a name that shows that link.
But right now, quaternion is the only thing that has .repeat > 1, so
I guess it would be OK either way. We'll see if Jonathan has an
opinion on the naming.
^ permalink raw reply
* [PATCH 1/2] hid: asus: add xg mobile 2023 external hardware support
From: Denis Benato @ 2026-02-16 17:55 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Ilpo Järvinen, Denis Benato
XG mobile stations have the 0x5a endpoint and has to be initialized:
add them to hid-asus.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 3 +++
drivers/hid/hid-ids.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 1b9793f7c07e..52efbf75a994 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1483,6 +1483,9 @@ static const struct hid_device_id asus_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_ALLY_XPAD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+ USB_DEVICE_ID_ASUSTEK_XGM_2023),
+ },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_CLAYMORE_II_KEYBOARD),
QUIRK_ROG_CLAYMORE_II_KEYBOARD },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3e299a30dcde..4ab7640b119a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -229,6 +229,7 @@
#define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X 0x1b4c
#define USB_DEVICE_ID_ASUSTEK_ROG_CLAYMORE_II_KEYBOARD 0x196b
#define USB_DEVICE_ID_ASUSTEK_FX503VD_KEYBOARD 0x1869
+#define USB_DEVICE_ID_ASUSTEK_XGM_2023 0x1a9a
#define USB_VENDOR_ID_ATEN 0x0557
#define USB_DEVICE_ID_ATEN_UC100KM 0x2004
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] hid: asus: always fully initialize devices
From: Denis Benato @ 2026-02-16 17:55 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Ilpo Järvinen, Denis Benato
In-Reply-To: <20260216175539.12415-1-denis.benato@linux.dev>
ASUS has more devices other than laptop keyboards which needs
to be initializated: the init sequence is the same as keyboards.
ID1 and ID2 are USB report IDs that are correctly enumerated:
send init commands to all devices that supports those reports IDs.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 46 ++++++++++++++++++++++++++++++++----------
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 52efbf75a994..0a85b1ecdda6 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -102,7 +102,6 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define QUIRK_ROG_CLAYMORE_II_KEYBOARD BIT(12)
#define QUIRK_ROG_ALLY_XPAD BIT(13)
#define QUIRK_HID_FN_LOCK BIT(14)
-#define QUIRK_ROG_NKEY_ID1ID2_INIT BIT(15)
#define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
QUIRK_NO_INIT_REPORTS | \
@@ -209,6 +208,12 @@ static const struct asus_touchpad_info medion_e1239t_tp = {
.report_size = 32 /* 2 byte header + 5 * 5 + 5 byte footer */,
};
+static const u8 asus_report_id_init[] = {
+ FEATURE_KBD_REPORT_ID,
+ FEATURE_KBD_LED_REPORT_ID1,
+ FEATURE_KBD_LED_REPORT_ID2
+};
+
static void asus_report_contact_down(struct asus_drvdata *drvdat,
int toolType, u8 *data)
{
@@ -715,6 +720,21 @@ static void validate_mcu_fw_version(struct hid_device *hdev, int idProduct)
}
}
+static bool asus_has_report_id(struct hid_device *hdev, u16 report_id)
+{
+ int t, f, u, err = 0;
+ struct hid_report *report;
+
+ for (t = HID_INPUT_REPORT; t <= HID_FEATURE_REPORT; t++) {
+ list_for_each_entry(report, &hdev->report_enum[t].report_list, list) {
+ if (report->id == report_id)
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int asus_kbd_register_leds(struct hid_device *hdev)
{
struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
@@ -723,9 +743,9 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
unsigned char kbd_func;
int ret;
- ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
- if (ret < 0)
- return ret;
+ /* Laptops keyboard backlight is always at 0x5a */
+ if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID))
+ return -ENODEV;
/* Get keyboard functions */
ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
@@ -736,11 +756,6 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
return -ENODEV;
- if (drvdata->quirks & QUIRK_ROG_NKEY_ID1ID2_INIT) {
- asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
- asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
- }
-
if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
ret = asus_kbd_disable_oobe(hdev);
if (ret < 0)
@@ -1287,6 +1302,15 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
+ for (int r = 0; r < ARRAY_SIZE(asus_report_id_init); r++) {
+ if (asus_has_report_id(hdev, asus_report_id_init[r])) {
+ ret = asus_kbd_init(hdev, asus_report_id_init[r]);
+ if (ret < 0)
+ hid_warn(hdev, "Failed to initialize 0x%x: %d.\n",
+ asus_report_id_init[r], ret);
+ }
+ }
+
if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
asus_kbd_register_leds(hdev))
hid_warn(hdev, "Failed to initialize backlight.\n");
@@ -1470,10 +1494,10 @@ static const struct hid_device_id asus_devices[] = {
QUIRK_USE_KBD_BACKLIGHT },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD),
- QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_NKEY_ID1ID2_INIT },
+ QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
- QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK | QUIRK_ROG_NKEY_ID1ID2_INIT },
+ QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Conor Dooley @ 2026-02-16 18:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260214180959.30714-2-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]
On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> Document embedded controller used in ASUS Transformer device series.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>
> diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> new file mode 100644
> index 000000000000..670c4c2d339d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASUS Transformer's Embedded Controller
> +
> +description:
> + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> + running a custom ASUS firmware, specific to the ASUS Transformer
> + device series.
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/power/supply/power-supply.yaml
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - asus,p1801-t-ec-pad
> + - asus,sl101-ec-dock
> + - asus,tf600t-ec-pad
> + - asus,tf701t-ec-pad
> +
> + - items:
> + - enum:
> + - asus,tf101-ec-dock
> + - asus,tf101g-ec-dock
> + - asus,tf201-ec-dock
> + - asus,tf300t-ec-dock
> + - asus,tf300tg-ec-dock
> + - asus,tf300tl-ec-dock
> + - asus,tf700t-ec-dock
> + - const: asus,transformer-ec-dock
> +
> + - items:
> + - enum:
> + - asus,tf201-ec-pad
> + - asus,tf300t-ec-pad
> + - asus,tf300tg-ec-pad
> + - asus,tf300tl-ec-pad
> + - asus,tf700t-ec-pad
> + - const: asus,transformer-ec-pad
Can you explain somewhere here what the "dock" and "pad" devices are and
how they differ? For example, I am currently wondering why tf700t has both
"dock" and "pad".
Also, why are some of the compatibles permitted standalone? That should
be mentioned in your commit message too. Also, other than the sl101, the
standalone ones seem to have the same match data in the mfd driver. Why
are fallbacks not made use of there?
Since this transformer series seems to have multiple programming models
for "ec-pad" devices, it calls into question your use of the generic
fallback compatibles is appropriate and makes it seem like you should be
using device compatibles as a fallback.
The rest looks okay other than the filename, which doesn't match any of
the compatibles that you've got here.
Cheers,
Conor.
> +
> + 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
> +
> + interrupts:
> + maxItems: 1
> +
> + request-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - request-gpios
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + embedded-controller@19 {
> + compatible = "asus,tf201-ec-dock", "asus,transformer-ec-dock";
> + reg = <0x19>, <0x1b>;
> + reg-names = "ec", "dockram";
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
> +
> + request-gpios = <&gpio 134 GPIO_ACTIVE_LOW>;
> +
> + monitored-battery = <&dock_battery>;
> + };
> + };
> +...
> --
> 2.51.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-16 18:22 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260216-sprung-scallop-de7b64bf528c@spud>
пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>
> On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > Document embedded controller used in ASUS Transformer device series.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > 1 file changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > new file mode 100644
> > index 000000000000..670c4c2d339d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > @@ -0,0 +1,98 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ASUS Transformer's Embedded Controller
> > +
> > +description:
> > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > + running a custom ASUS firmware, specific to the ASUS Transformer
> > + device series.
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +allOf:
> > + - $ref: /schemas/power/supply/power-supply.yaml
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - asus,p1801-t-ec-pad
> > + - asus,sl101-ec-dock
> > + - asus,tf600t-ec-pad
> > + - asus,tf701t-ec-pad
> > +
> > + - items:
> > + - enum:
> > + - asus,tf101-ec-dock
> > + - asus,tf101g-ec-dock
> > + - asus,tf201-ec-dock
> > + - asus,tf300t-ec-dock
> > + - asus,tf300tg-ec-dock
> > + - asus,tf300tl-ec-dock
> > + - asus,tf700t-ec-dock
> > + - const: asus,transformer-ec-dock
> > +
> > + - items:
> > + - enum:
> > + - asus,tf201-ec-pad
> > + - asus,tf300t-ec-pad
> > + - asus,tf300tg-ec-pad
> > + - asus,tf300tl-ec-pad
> > + - asus,tf700t-ec-pad
> > + - const: asus,transformer-ec-pad
>
> Can you explain somewhere here what the "dock" and "pad" devices are and
> how they differ? For example, I am currently wondering why tf700t has both
> "dock" and "pad".
"pad" is used for the controller in the tablet itself in the pad
"dock" is used for the controller in the mobile dock keyboard.
Seems quite obvious.
> Also, why are some of the compatibles permitted standalone? That should
> be mentioned in your commit message too. Also, other than the sl101, the
> standalone ones seem to have the same match data in the mfd driver. Why
> are fallbacks not made use of there?
>
Because standalone compatibles describe a unique hw configuration
which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
Different generations, different form-factors.
> Since this transformer series seems to have multiple programming models
> for "ec-pad" devices, it calls into question your use of the generic
> fallback compatibles is appropriate and makes it seem like you should be
> using device compatibles as a fallback.
That is redundant.
>
> The rest looks okay other than the filename, which doesn't match any of
> the compatibles that you've got here.
>
How should I call it then?
> Cheers,
> Conor.
>
> > +
> > + 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
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + request-gpios:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - interrupts
> > + - request-gpios
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + embedded-controller@19 {
> > + compatible = "asus,tf201-ec-dock", "asus,transformer-ec-dock";
> > + reg = <0x19>, <0x1b>;
> > + reg-names = "ec", "dockram";
> > +
> > + interrupt-parent = <&gpio>;
> > + interrupts = <151 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + request-gpios = <&gpio 134 GPIO_ACTIVE_LOW>;
> > +
> > + monitored-battery = <&dock_battery>;
> > + };
> > + };
> > +...
> > --
> > 2.51.0
> >
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Conor Dooley @ 2026-02-16 18:50 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <CAPVz0n06+uLCSfY_bYS9v7KJ-hXotye7ej-rze6-Q8_JAF7XVA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5221 bytes --]
On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> >
> > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > Document embedded controller used in ASUS Transformer device series.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > 1 file changed, 98 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > new file mode 100644
> > > index 000000000000..670c4c2d339d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > @@ -0,0 +1,98 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: ASUS Transformer's Embedded Controller
> > > +
> > > +description:
> > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > + device series.
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +allOf:
> > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - enum:
> > > + - asus,p1801-t-ec-pad
> > > + - asus,sl101-ec-dock
> > > + - asus,tf600t-ec-pad
> > > + - asus,tf701t-ec-pad
> > > +
> > > + - items:
> > > + - enum:
> > > + - asus,tf101-ec-dock
> > > + - asus,tf101g-ec-dock
> > > + - asus,tf201-ec-dock
> > > + - asus,tf300t-ec-dock
> > > + - asus,tf300tg-ec-dock
> > > + - asus,tf300tl-ec-dock
> > > + - asus,tf700t-ec-dock
> > > + - const: asus,transformer-ec-dock
> > > +
> > > + - items:
> > > + - enum:
> > > + - asus,tf201-ec-pad
> > > + - asus,tf300t-ec-pad
> > > + - asus,tf300tg-ec-pad
> > > + - asus,tf300tl-ec-pad
> > > + - asus,tf700t-ec-pad
> > > + - const: asus,transformer-ec-pad
> >
> > Can you explain somewhere here what the "dock" and "pad" devices are and
> > how they differ? For example, I am currently wondering why tf700t has both
> > "dock" and "pad".
>
> "pad" is used for the controller in the tablet itself in the pad
> "dock" is used for the controller in the mobile dock keyboard.
> Seems quite obvious.
To someone intimately familiar with the devices maybe. Not to the people
you have to justify your patches to. Your response implies that this is
some sort of thing that's like a surface, but please put an explicit
explanation into the binding somewhere as to what each compatible is
for.
> > Also, why are some of the compatibles permitted standalone? That should
> > be mentioned in your commit message too. Also, other than the sl101, the
> > standalone ones seem to have the same match data in the mfd driver. Why
> > are fallbacks not made use of there?
> >
>
> Because standalone compatibles describe a unique hw configuration
> which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> Different generations, different form-factors.
I don't see any reasons here that eliminate fallback compatibles.
+ { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
+ { }
Three of them use the same match data, so you need to explain why you've
made these three standalone when all the others that share a programming
model got a generic fallback. Fallback usage is based on programming
model, not based on whether the devices are a physically different, so
your explanation must reflect this.
> > Since this transformer series seems to have multiple programming models
> > for "ec-pad" devices, it calls into question your use of the generic
> > fallback compatibles is appropriate and makes it seem like you should be
> > using device compatibles as a fallback.
>
> That is redundant.
I don't understand how that is a response to what I said.
> > The rest looks okay other than the filename, which doesn't match any of
> > the compatibles that you've got here.
> >
>
> How should I call it then?
Make it match a compatible, just like any other binding.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-16 19:14 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260216-plunder-defense-de11cf56dd3d@spud>
пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>
> On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> > >
> > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > > Document embedded controller used in ASUS Transformer device series.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > > 1 file changed, 98 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > new file mode 100644
> > > > index 000000000000..670c4c2d339d
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > @@ -0,0 +1,98 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: ASUS Transformer's Embedded Controller
> > > > +
> > > > +description:
> > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > > + device series.
> > > > +
> > > > +maintainers:
> > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - enum:
> > > > + - asus,p1801-t-ec-pad
> > > > + - asus,sl101-ec-dock
> > > > + - asus,tf600t-ec-pad
> > > > + - asus,tf701t-ec-pad
> > > > +
> > > > + - items:
> > > > + - enum:
> > > > + - asus,tf101-ec-dock
> > > > + - asus,tf101g-ec-dock
> > > > + - asus,tf201-ec-dock
> > > > + - asus,tf300t-ec-dock
> > > > + - asus,tf300tg-ec-dock
> > > > + - asus,tf300tl-ec-dock
> > > > + - asus,tf700t-ec-dock
> > > > + - const: asus,transformer-ec-dock
> > > > +
> > > > + - items:
> > > > + - enum:
> > > > + - asus,tf201-ec-pad
> > > > + - asus,tf300t-ec-pad
> > > > + - asus,tf300tg-ec-pad
> > > > + - asus,tf300tl-ec-pad
> > > > + - asus,tf700t-ec-pad
> > > > + - const: asus,transformer-ec-pad
> > >
> > > Can you explain somewhere here what the "dock" and "pad" devices are and
> > > how they differ? For example, I am currently wondering why tf700t has both
> > > "dock" and "pad".
> >
> > "pad" is used for the controller in the tablet itself in the pad
> > "dock" is used for the controller in the mobile dock keyboard.
> > Seems quite obvious.
>
> To someone intimately familiar with the devices maybe. Not to the people
> you have to justify your patches to. Your response implies that this is
> some sort of thing that's like a surface, but please put an explicit
> explanation into the binding somewhere as to what each compatible is
> for.
Ok, fair.
>
> > > Also, why are some of the compatibles permitted standalone? That should
> > > be mentioned in your commit message too. Also, other than the sl101, the
> > > standalone ones seem to have the same match data in the mfd driver. Why
> > > are fallbacks not made use of there?
> > >
> >
> > Because standalone compatibles describe a unique hw configuration
> > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> > Different generations, different form-factors.
>
> I don't see any reasons here that eliminate fallback compatibles.
> + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
> + { }
> Three of them use the same match data, so you need to explain why you've
> made these three standalone when all the others that share a programming
> model got a generic fallback. Fallback usage is based on programming
> model, not based on whether the devices are a physically different, so
> your explanation must reflect this.
>
> > > Since this transformer series seems to have multiple programming models
> > > for "ec-pad" devices, it calls into question your use of the generic
> > > fallback compatibles is appropriate and makes it seem like you should be
> > > using device compatibles as a fallback.
> >
> > That is redundant.
>
> I don't understand how that is a response to what I said.
>
in other words you propose this:
properties:
compatible:
oneOf:
- items:
- enum:
- asus,sl101-ec-dock
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf300t-ec-dock
- asus,tf300tg-ec-dock
- asus,tf300tl-ec-dock
- asus,tf700t-ec-dock
- const: asus,transformer-ec-dock
- items:
- enum:
- asus,p1801-t-ec-pad
- asus,tf201-ec-pad
- asus,tf300t-ec-pad
- asus,tf300tg-ec-pad
- asus,tf300tl-ec-pad
- asus,tf700t-ec-pad
- asus,tf600t-ec-pad
- asus,tf701t-ec-pad
- const: asus,transformer-ec-pad
And in the driver add match to every single entry of enums?
> > > The rest looks okay other than the filename, which doesn't match any of
> > > the compatibles that you've got here.
> > >
> >
> > How should I call it then?
>
> Make it match a compatible, just like any other binding.
^ permalink raw reply
* [PATCH] HID: appletb-kbd: add .resume method in PM
From: Aditya Garg @ 2026-02-16 21:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, stable
Upon resuming from suspend, the Touch Bar driver was missing a resume
method in order to restore the original mode the Touch Bar was on before
suspending. It is the same as the reset_resume method.
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
drivers/hid/hid-appletb-kbd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-appletb-kbd.c b/drivers/hid/hid-appletb-kbd.c
index b00687e67..0b10cff46 100644
--- a/drivers/hid/hid-appletb-kbd.c
+++ b/drivers/hid/hid-appletb-kbd.c
@@ -477,7 +477,7 @@ static int appletb_kbd_suspend(struct hid_device *hdev, pm_message_t msg)
return 0;
}
-static int appletb_kbd_reset_resume(struct hid_device *hdev)
+static int appletb_kbd_resume(struct hid_device *hdev)
{
struct appletb_kbd *kbd = hid_get_drvdata(hdev);
@@ -503,7 +503,8 @@ static struct hid_driver appletb_kbd_hid_driver = {
.input_configured = appletb_kbd_input_configured,
#ifdef CONFIG_PM
.suspend = appletb_kbd_suspend,
- .reset_resume = appletb_kbd_reset_resume,
+ .resume = appletb_kbd_resume,
+ .reset_resume = appletb_kbd_resume,
#endif
.driver.dev_groups = appletb_kbd_groups,
};
--
2.52.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.19-6.12] HID: i2c-hid: Add FocalTech FT8112
From: Sasha Levin @ 2026-02-17 1:01 UTC (permalink / raw)
To: patches, stable
Cc: Daniel Peng, Jiri Kosina, Douglas Anderson, Dmitry Torokhov,
Sasha Levin, jikos, bentiss, linux-input, linux-kernel
In-Reply-To: <20260217010118.3503621-1-sashal@kernel.org>
From: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
[ Upstream commit 3d9586f1f90c9101b1abf5b0e9d70ca45f5f16db ]
Information for touchscreen model HKO/RB116AS01-2 as below:
- HID :FTSC1000
- slave address:0X38
- Interface:HID over I2C
- Touch control lC:FT8112
- I2C ID: PNP0C50
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Acked-by: Jiri Kosina <jkosina@suse.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20251117094041.300083-2-Daniel_Peng@pegatron.corp-partner.google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The ili2901 entry was added in December 2023. For older stable trees
that don't have that entry, the patch would need minor context
adjustment but the change itself is straightforward. Even without the
ili2901 entry as context, the addition inserts cleanly in the match
table.
## Verification
- **git log** confirmed `i2c-hid-of-elan.c` was first added in commit
`bd3cba00dcc63` (May 2022), present in 6.1.y+ stable trees
- **git log** confirmed the file has had similar device additions
(ili9882t, ili2901, ekth6a12nay) following the same pattern
- The code diff shows the new entry follows the exact struct pattern of
existing entries
- The commit has `Reviewed-by: Douglas Anderson` and `Acked-by: Jiri
Kosina` (verified in commit message)
- The compatible string `"focaltech,ft8112"` is a new vendor, but the
driver architecture supports multiple vendors (it already has elan and
ilitek)
- The `elan_i2c_hid_chip_data` struct is used identically for all
devices in this driver
- The `ili2901` context entry was added in Dec 2023 (commit
`03ddb7de012c6`), so the patch may need minor context adjustment for
6.1.y but the logical change is trivial
## Conclusion
This is a textbook device ID / compatible string addition to an existing
driver. It enables a FocalTech FT8112 touchscreen that would otherwise
be completely non-functional. The change is:
- Small (~10 lines), isolated, and low-risk
- Following an established pattern in the driver
- Reviewed and acked by maintainers
- Critical for users with this hardware (no touchscreen = unusable
device)
This is exactly the type of commit that the stable kernel exception for
device IDs was designed for.
**YES**
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
index 0215f217f6d86..b81fcc6ff49ee 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
@@ -168,6 +168,13 @@ static const struct elan_i2c_hid_chip_data elan_ekth6a12nay_chip_data = {
.power_after_backlight = true,
};
+static const struct elan_i2c_hid_chip_data focaltech_ft8112_chip_data = {
+ .post_power_delay_ms = 10,
+ .post_gpio_reset_on_delay_ms = 150,
+ .hid_descriptor_address = 0x0001,
+ .main_supply_name = "vcc33",
+};
+
static const struct elan_i2c_hid_chip_data ilitek_ili9882t_chip_data = {
.post_power_delay_ms = 1,
.post_gpio_reset_on_delay_ms = 200,
@@ -191,6 +198,7 @@ static const struct elan_i2c_hid_chip_data ilitek_ili2901_chip_data = {
static const struct of_device_id elan_i2c_hid_of_match[] = {
{ .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data },
{ .compatible = "elan,ekth6a12nay", .data = &elan_ekth6a12nay_chip_data },
+ { .compatible = "focaltech,ft8112", .data = &focaltech_ft8112_chip_data },
{ .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data },
{ .compatible = "ilitek,ili2901", .data = &ilitek_ili2901_chip_data },
{ }
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] touchscreen-dmi quirk for SUPI S10
From: Yajat Kumar @ 2026-02-17 5:07 UTC (permalink / raw)
To: hansg, dmitry.torokhov, linux-input, linux-kernel; +Cc: Yajat Kumar
In-Reply-To: <0840e4ec-0b61-4e0d-9d67-d0eb2ab2d6a1@kernel.org>
Hi Hans,
Sorry for the threading issue — Gmail broke my previous reply. Reposting confirmation below.
I’ve tested the attached patch on the SUPI S10.
The touchscreen uses ACPI HID GDIX1001, so no change is needed there.
With the patch applied, the Y axis is no longer inverted and touch
input now matches the display orientation correctly.
You can add:
Tested-by: Yajat Kumar <yajatapps3@gmail.com>
Thanks for the quick fix and explanation.
Regards,
Yajat Kumar
^ permalink raw reply
* Re: [PATCH 0/2] iio: orientation: hid-sensor-rotation: fix quaternion alignment
From: Andy Shevchenko @ 2026-02-17 8:10 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada, linux-iio, linux-kernel, Jonathan Cameron,
linux-input, Lixu Zhang
In-Reply-To: <bcfc711c-a02a-4470-a2a6-de43c71e7c2e@baylibre.com>
On Mon, Feb 16, 2026 at 09:25:58AM -0600, David Lechner wrote:
> On 2/16/26 1:44 AM, Andy Shevchenko wrote:
> > On Sat, Feb 14, 2026 at 03:00:19PM -0600, David Lechner wrote:
> >> The main point of this series is to fix a regression reported in
> >> hid-sensor-rotation where the alignment of the quaternion field in the
> >> data was inadvertently changed from 16 bytes to 8 bytes. This is an
> >> unusually case (one of only 2 in the kernel) where the .repeat field of
> >> struct iio_scan_type is used and we have such a requirement. (The other
> >> case uses u16 instead of u32, so it wasn't affected.)
> >>
> >> To make the reason for the alignment more explicit to future readers,
> >> we introduce a new macro, IIO_DECLARE_REPEATED_ELEMENT, to declare the
> >> array with proper allignment. This is meant to follow the pattern of
> >> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.
> >
> > In both cases it's quaternion, maybe be more explicit and define
> > IIO_DECLARE_QUATERNION() ?
>
> It is really the fact that the scan_type has .repeat > 1 that requires
> this, so I was trying to make a name that shows that link.
>
> But right now, quaternion is the only thing that has .repeat > 1, so
> I guess it would be OK either way. We'll see if Jonathan has an
> opinion on the naming.
I think we should solve the problems when they appear. Naming explicitly
for quaternion makes it easier to get from the core reading without having
a variable name to repeat that. Magic 4 might not always be a quaternion.
Do we have "repeat" to be used in other cases, btw?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Conor Dooley @ 2026-02-17 11:05 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <CAPVz0n0-LbTUZBCaO=oN3PpPLpwAqzNo29r687pKY8NbEE9giA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6573 bytes --]
On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
> >
> > On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
> > > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
> > > >
> > > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
> > > > > Document embedded controller used in ASUS Transformer device series.
> > > > >
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
> > > > > 1 file changed, 98 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..670c4c2d339d
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
> > > > > @@ -0,0 +1,98 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: ASUS Transformer's Embedded Controller
> > > > > +
> > > > > +description:
> > > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
> > > > > + running a custom ASUS firmware, specific to the ASUS Transformer
> > > > > + device series.
> > > > > +
> > > > > +maintainers:
> > > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > +
> > > > > +allOf:
> > > > > + - $ref: /schemas/power/supply/power-supply.yaml
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + oneOf:
> > > > > + - enum:
> > > > > + - asus,p1801-t-ec-pad
> > > > > + - asus,sl101-ec-dock
> > > > > + - asus,tf600t-ec-pad
> > > > > + - asus,tf701t-ec-pad
> > > > > +
> > > > > + - items:
> > > > > + - enum:
> > > > > + - asus,tf101-ec-dock
> > > > > + - asus,tf101g-ec-dock
> > > > > + - asus,tf201-ec-dock
> > > > > + - asus,tf300t-ec-dock
> > > > > + - asus,tf300tg-ec-dock
> > > > > + - asus,tf300tl-ec-dock
> > > > > + - asus,tf700t-ec-dock
> > > > > + - const: asus,transformer-ec-dock
> > > > > +
> > > > > + - items:
> > > > > + - enum:
> > > > > + - asus,tf201-ec-pad
> > > > > + - asus,tf300t-ec-pad
> > > > > + - asus,tf300tg-ec-pad
> > > > > + - asus,tf300tl-ec-pad
> > > > > + - asus,tf700t-ec-pad
> > > > > + - const: asus,transformer-ec-pad
> > > > Also, why are some of the compatibles permitted standalone? That should
> > > > be mentioned in your commit message too. Also, other than the sl101, the
> > > > standalone ones seem to have the same match data in the mfd driver. Why
> > > > are fallbacks not made use of there?
> > > >
> > >
> > > Because standalone compatibles describe a unique hw configuration
> > > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
> > > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
> > > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
> > > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
> > > Different generations, different form-factors.
> >
> > I don't see any reasons here that eliminate fallback compatibles.
> > + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
> > + { }
> > Three of them use the same match data, so you need to explain why you've
> > made these three standalone when all the others that share a programming
> > model got a generic fallback. Fallback usage is based on programming
> > model, not based on whether the devices are a physically different, so
> > your explanation must reflect this.
> >
> > > > Since this transformer series seems to have multiple programming models
> > > > for "ec-pad" devices, it calls into question your use of the generic
> > > > fallback compatibles is appropriate and makes it seem like you should be
> > > > using device compatibles as a fallback.
> > >
> > > That is redundant.
> >
> > I don't understand how that is a response to what I said.
> >
>
> in other words you propose this:
>
> properties:
> compatible:
> oneOf:
> - items:
> - enum:
> - asus,sl101-ec-dock
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf300t-ec-dock
> - asus,tf300tg-ec-dock
> - asus,tf300tl-ec-dock
> - asus,tf700t-ec-dock
> - const: asus,transformer-ec-dock
>
> - items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,tf201-ec-pad
> - asus,tf300t-ec-pad
> - asus,tf300tg-ec-pad
> - asus,tf300tl-ec-pad
> - asus,tf700t-ec-pad
> - asus,tf600t-ec-pad
> - asus,tf701t-ec-pad
> - const: asus,transformer-ec-pad
>
> And in the driver add match to every single entry of enums?
No, I was talking about removing the generic compatibles entirely, since
they are not suitably generic to cover all devices at the point of
addition. So like:
items:
- enum:
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf300t-ec-dock
- asus,tf300tg-ec-dock
- asus,tf300tl-ec-dock
- const: asus,tf700t-ec-dock
and
items:
- enum:
- asus,p1801-t-ec-pad
- asus,tf600t-ec-pad
- const: asus,tf701t-ec-pad
I dunno about these particular devices, but if there's already two
programming models for these devices, what's to stop there being more
added if/when a new generation of produces arrives?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-17 11:23 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260217-vowed-botany-b1c47c7e40b8@spud>
17 лютого 2026 р. 13:05:09 GMT+02:00, Conor Dooley <conor@kernel.org> пише:
>On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
>> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>> >
>> > On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
>> > > пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>> > > >
>> > > > On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
>> > > > > Document embedded controller used in ASUS Transformer device series.
>> > > > >
>> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>> > > > > ---
>> > > > > .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
>> > > > > 1 file changed, 98 insertions(+)
>> > > > > create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > >
>> > > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > > new file mode 100644
>> > > > > index 000000000000..670c4c2d339d
>> > > > > --- /dev/null
>> > > > > +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>> > > > > @@ -0,0 +1,98 @@
>> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> > > > > +%YAML 1.2
>> > > > > +---
>> > > > > +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
>> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > > > > +
>> > > > > +title: ASUS Transformer's Embedded Controller
>> > > > > +
>> > > > > +description:
>> > > > > + Several Nuvoton based Embedded Controllers attached to an I2C bus,
>> > > > > + running a custom ASUS firmware, specific to the ASUS Transformer
>> > > > > + device series.
>> > > > > +
>> > > > > +maintainers:
>> > > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
>> > > > > +
>> > > > > +allOf:
>> > > > > + - $ref: /schemas/power/supply/power-supply.yaml
>> > > > > +
>> > > > > +properties:
>> > > > > + compatible:
>> > > > > + oneOf:
>> > > > > + - enum:
>> > > > > + - asus,p1801-t-ec-pad
>> > > > > + - asus,sl101-ec-dock
>> > > > > + - asus,tf600t-ec-pad
>> > > > > + - asus,tf701t-ec-pad
>> > > > > +
>> > > > > + - items:
>> > > > > + - enum:
>> > > > > + - asus,tf101-ec-dock
>> > > > > + - asus,tf101g-ec-dock
>> > > > > + - asus,tf201-ec-dock
>> > > > > + - asus,tf300t-ec-dock
>> > > > > + - asus,tf300tg-ec-dock
>> > > > > + - asus,tf300tl-ec-dock
>> > > > > + - asus,tf700t-ec-dock
>> > > > > + - const: asus,transformer-ec-dock
>> > > > > +
>> > > > > + - items:
>> > > > > + - enum:
>> > > > > + - asus,tf201-ec-pad
>> > > > > + - asus,tf300t-ec-pad
>> > > > > + - asus,tf300tg-ec-pad
>> > > > > + - asus,tf300tl-ec-pad
>> > > > > + - asus,tf700t-ec-pad
>> > > > > + - const: asus,transformer-ec-pad
>
>> > > > Also, why are some of the compatibles permitted standalone? That should
>> > > > be mentioned in your commit message too. Also, other than the sl101, the
>> > > > standalone ones seem to have the same match data in the mfd driver. Why
>> > > > are fallbacks not made use of there?
>> > > >
>> > >
>> > > Because standalone compatibles describe a unique hw configuration
>> > > which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
>> > > is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
>> > > for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
>> > > in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
>> > > Different generations, different form-factors.
>> >
>> > I don't see any reasons here that eliminate fallback compatibles.
>> > + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
>> > + { }
>> > Three of them use the same match data, so you need to explain why you've
>> > made these three standalone when all the others that share a programming
>> > model got a generic fallback. Fallback usage is based on programming
>> > model, not based on whether the devices are a physically different, so
>> > your explanation must reflect this.
>> >
>> > > > Since this transformer series seems to have multiple programming models
>> > > > for "ec-pad" devices, it calls into question your use of the generic
>> > > > fallback compatibles is appropriate and makes it seem like you should be
>> > > > using device compatibles as a fallback.
>> > >
>> > > That is redundant.
>> >
>> > I don't understand how that is a response to what I said.
>> >
>>
>> in other words you propose this:
>>
>> properties:
>> compatible:
>> oneOf:
>> - items:
>> - enum:
>> - asus,sl101-ec-dock
>> - asus,tf101-ec-dock
>> - asus,tf101g-ec-dock
>> - asus,tf201-ec-dock
>> - asus,tf300t-ec-dock
>> - asus,tf300tg-ec-dock
>> - asus,tf300tl-ec-dock
>> - asus,tf700t-ec-dock
>> - const: asus,transformer-ec-dock
>>
>> - items:
>> - enum:
>> - asus,p1801-t-ec-pad
>> - asus,tf201-ec-pad
>> - asus,tf300t-ec-pad
>> - asus,tf300tg-ec-pad
>> - asus,tf300tl-ec-pad
>> - asus,tf700t-ec-pad
>> - asus,tf600t-ec-pad
>> - asus,tf701t-ec-pad
>> - const: asus,transformer-ec-pad
>>
>> And in the driver add match to every single entry of enums?
>
>No, I was talking about removing the generic compatibles entirely, since
>they are not suitably generic to cover all devices at the point of
>addition. So like:
>
Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work?
properties:
compatible:
- items:
- enum:
- asus,p1801-t-ec-pad
- asus,sl101-ec-dock
- asus,tf101-ec-dock
- asus,tf101g-ec-dock
- asus,tf201-ec-dock
- asus,tf201-ec-pad
- asus,tf300t-ec-dock
- asus,tf300t-ec-pad
- asus,tf300tg-ec-dock
- asus,tf300tg-ec-pad
- asus,tf300tl-ec-dock
- asus,tf300tl-ec-pad
- asus,tf700t-ec-dock
- asus,tf700t-ec-pad
- asus,tf600t-ec-pad
- asus,tf701t-ec-pad
- const: asus,transformer-ec
And them schema name will match the genetic compatible.
>items:
> - enum:
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf300t-ec-dock
> - asus,tf300tg-ec-dock
> - asus,tf300tl-ec-dock
> - const: asus,tf700t-ec-dock
>
>and
>
>items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,tf600t-ec-pad
> - const: asus,tf701t-ec-pad
>
>I dunno about these particular devices, but if there's already two
>programming models for these devices, what's to stop there being more
>added if/when a new generation of produces arrives?
There will be no new devices with this EC, last one was around 2013.
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-17 11:31 UTC (permalink / raw)
To: Conor Dooley, Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260217-vowed-botany-b1c47c7e40b8@spud>
On 17/02/2026 12:05, Conor Dooley wrote:
> On Mon, Feb 16, 2026 at 09:14:40PM +0200, Svyatoslav Ryhel wrote:
>> пн, 16 лют. 2026 р. о 20:50 Conor Dooley <conor@kernel.org> пише:
>>>
>>> On Mon, Feb 16, 2026 at 08:22:38PM +0200, Svyatoslav Ryhel wrote:
>>>> пн, 16 лют. 2026 р. о 20:04 Conor Dooley <conor@kernel.org> пише:
>>>>>
>>>>> On Sat, Feb 14, 2026 at 08:09:53PM +0200, Svyatoslav Ryhel wrote:
>>>>>> Document embedded controller used in ASUS Transformer device series.
>>>>>>
>>>>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>>>>> ---
>>>>>> .../asus,transformer-ec.yaml | 98 +++++++++++++++++++
>>>>>> 1 file changed, 98 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..670c4c2d339d
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/embedded-controller/asus,transformer-ec.yaml
>>>>>> @@ -0,0 +1,98 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/embedded-controller/asus,transformer-ec.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: ASUS Transformer's Embedded Controller
>>>>>> +
>>>>>> +description:
>>>>>> + Several Nuvoton based Embedded Controllers attached to an I2C bus,
>>>>>> + running a custom ASUS firmware, specific to the ASUS Transformer
>>>>>> + device series.
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Svyatoslav Ryhel <clamor95@gmail.com>
>>>>>> +
>>>>>> +allOf:
>>>>>> + - $ref: /schemas/power/supply/power-supply.yaml
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + oneOf:
>>>>>> + - enum:
>>>>>> + - asus,p1801-t-ec-pad
>>>>>> + - asus,sl101-ec-dock
>>>>>> + - asus,tf600t-ec-pad
>>>>>> + - asus,tf701t-ec-pad
>>>>>> +
>>>>>> + - items:
>>>>>> + - enum:
>>>>>> + - asus,tf101-ec-dock
>>>>>> + - asus,tf101g-ec-dock
>>>>>> + - asus,tf201-ec-dock
>>>>>> + - asus,tf300t-ec-dock
>>>>>> + - asus,tf300tg-ec-dock
>>>>>> + - asus,tf300tl-ec-dock
>>>>>> + - asus,tf700t-ec-dock
>>>>>> + - const: asus,transformer-ec-dock
>>>>>> +
>>>>>> + - items:
>>>>>> + - enum:
>>>>>> + - asus,tf201-ec-pad
>>>>>> + - asus,tf300t-ec-pad
>>>>>> + - asus,tf300tg-ec-pad
>>>>>> + - asus,tf300tl-ec-pad
>>>>>> + - asus,tf700t-ec-pad
>>>>>> + - const: asus,transformer-ec-pad
>
>>>>> Also, why are some of the compatibles permitted standalone? That should
>>>>> be mentioned in your commit message too. Also, other than the sl101, the
>>>>> standalone ones seem to have the same match data in the mfd driver. Why
>>>>> are fallbacks not made use of there?
>>>>>
>>>>
>>>> Because standalone compatibles describe a unique hw configuration
>>>> which cannot be grouped into something meaningful. asus,p1801-t-ec-pad
>>>> is for EC of Tegra30/Intel based p1801-t AIO, asus,sl101-ec-dock is
>>>> for EC of Tegra20 slider tablet, asus,tf600t-ec-pad is for altered EC
>>>> in Win8 Tegra30 tablet, asus,tf701t-ec-pad is for Tegra114 tablet.
>>>> Different generations, different form-factors.
>>>
>>> I don't see any reasons here that eliminate fallback compatibles.
>>> + { .compatible = "asus,p1801-t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { .compatible = "asus,tf600t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { .compatible = "asus,tf701t-ec-pad", .data = &asus_ec_pad_charger_data },
>>> + { }
>>> Three of them use the same match data, so you need to explain why you've
>>> made these three standalone when all the others that share a programming
>>> model got a generic fallback. Fallback usage is based on programming
>>> model, not based on whether the devices are a physically different, so
>>> your explanation must reflect this.
>>>
>>>>> Since this transformer series seems to have multiple programming models
>>>>> for "ec-pad" devices, it calls into question your use of the generic
>>>>> fallback compatibles is appropriate and makes it seem like you should be
>>>>> using device compatibles as a fallback.
>>>>
>>>> That is redundant.
>>>
>>> I don't understand how that is a response to what I said.
>>>
>>
>> in other words you propose this:
>>
>> properties:
>> compatible:
>> oneOf:
>> - items:
>> - enum:
>> - asus,sl101-ec-dock
>> - asus,tf101-ec-dock
>> - asus,tf101g-ec-dock
>> - asus,tf201-ec-dock
>> - asus,tf300t-ec-dock
>> - asus,tf300tg-ec-dock
>> - asus,tf300tl-ec-dock
>> - asus,tf700t-ec-dock
>> - const: asus,transformer-ec-dock
>>
>> - items:
>> - enum:
>> - asus,p1801-t-ec-pad
>> - asus,tf201-ec-pad
>> - asus,tf300t-ec-pad
>> - asus,tf300tg-ec-pad
>> - asus,tf300tl-ec-pad
>> - asus,tf700t-ec-pad
>> - asus,tf600t-ec-pad
>> - asus,tf701t-ec-pad
>> - const: asus,transformer-ec-pad
>>
>> And in the driver add match to every single entry of enums?
>
> No, I was talking about removing the generic compatibles entirely, since
> they are not suitably generic to cover all devices at the point of
> addition. So like:
Yep. Generic compatible has hardly a meaning if you already know it is
not generic enough - some devices are not compatible with it.
Each SoC/platform which pushed to these generic compatible, hit a wall
after some months/years. Apple is a nice example now.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Krzysztof Kozlowski @ 2026-02-17 11:32 UTC (permalink / raw)
To: Svyatoslav Ryhel, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <55C30023-4175-48F2-BCB0-12EC23C48F01@gmail.com>
On 17/02/2026 12:23, Svyatoslav Ryhel wrote:
>>> in other words you propose this:
>>>
>>> properties:
>>> compatible:
>>> oneOf:
>>> - items:
>>> - enum:
>>> - asus,sl101-ec-dock
>>> - asus,tf101-ec-dock
>>> - asus,tf101g-ec-dock
>>> - asus,tf201-ec-dock
>>> - asus,tf300t-ec-dock
>>> - asus,tf300tg-ec-dock
>>> - asus,tf300tl-ec-dock
>>> - asus,tf700t-ec-dock
>>> - const: asus,transformer-ec-dock
>>>
>>> - items:
>>> - enum:
>>> - asus,p1801-t-ec-pad
>>> - asus,tf201-ec-pad
>>> - asus,tf300t-ec-pad
>>> - asus,tf300tg-ec-pad
>>> - asus,tf300tl-ec-pad
>>> - asus,tf700t-ec-pad
>>> - asus,tf600t-ec-pad
>>> - asus,tf701t-ec-pad
>>> - const: asus,transformer-ec-pad
>>>
>>> And in the driver add match to every single entry of enums?
>>
>> No, I was talking about removing the generic compatibles entirely, since
>> they are not suitably generic to cover all devices at the point of
>> addition. So like:
>>
>
> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work?
Then what does the generic compatible express if it is not used by the SW.
Wrap your emails to mailing list style.
>
> properties:
> compatible:
> - items:
> - enum:
> - asus,p1801-t-ec-pad
> - asus,sl101-ec-dock
> - asus,tf101-ec-dock
> - asus,tf101g-ec-dock
> - asus,tf201-ec-dock
> - asus,tf201-ec-pad
> - asus,tf300t-ec-dock
> - asus,tf300t-ec-pad
> - asus,tf300tg-ec-dock
> - asus,tf300tg-ec-pad
> - asus,tf300tl-ec-dock
> - asus,tf300tl-ec-pad
> - asus,tf700t-ec-dock
> - asus,tf700t-ec-pad
> - asus,tf600t-ec-pad
> - asus,tf701t-ec-pad
> - const: asus,transformer-ec
>
> And them schema name will match the genetic compatible.
Then what does the generic compatible express?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Svyatoslav Ryhel @ 2026-02-17 11:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <1519143e-4fc3-490d-ab8d-e65edd2c4eec@kernel.org>
17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише:
>On 17/02/2026 12:23, Svyatoslav Ryhel wrote:
>>>> in other words you propose this:
>>>>
>>>> properties:
>>>> compatible:
>>>> oneOf:
>>>> - items:
>>>> - enum:
>>>> - asus,sl101-ec-dock
>>>> - asus,tf101-ec-dock
>>>> - asus,tf101g-ec-dock
>>>> - asus,tf201-ec-dock
>>>> - asus,tf300t-ec-dock
>>>> - asus,tf300tg-ec-dock
>>>> - asus,tf300tl-ec-dock
>>>> - asus,tf700t-ec-dock
>>>> - const: asus,transformer-ec-dock
>>>>
>>>> - items:
>>>> - enum:
>>>> - asus,p1801-t-ec-pad
>>>> - asus,tf201-ec-pad
>>>> - asus,tf300t-ec-pad
>>>> - asus,tf300tg-ec-pad
>>>> - asus,tf300tl-ec-pad
>>>> - asus,tf700t-ec-pad
>>>> - asus,tf600t-ec-pad
>>>> - asus,tf701t-ec-pad
>>>> - const: asus,transformer-ec-pad
>>>>
>>>> And in the driver add match to every single entry of enums?
>>>
>>> No, I was talking about removing the generic compatibles entirely, since
>>> they are not suitably generic to cover all devices at the point of
>>> addition. So like:
>>>
>>
>> Actually, they all can be grouped under asus,transformer-ec fallback if that is needed, both pad and dock EC have the same core functions just different set of cells. And then in the driver each compatible will get a dedicated matching data. Will this work?
>
>Then what does the generic compatible express if it is not used by the SW.
>
>Wrap your emails to mailing list style.
>
>>
>> properties:
>> compatible:
>> - items:
>> - enum:
>> - asus,p1801-t-ec-pad
>> - asus,sl101-ec-dock
>> - asus,tf101-ec-dock
>> - asus,tf101g-ec-dock
>> - asus,tf201-ec-dock
>> - asus,tf201-ec-pad
>> - asus,tf300t-ec-dock
>> - asus,tf300t-ec-pad
>> - asus,tf300tg-ec-dock
>> - asus,tf300tg-ec-pad
>> - asus,tf300tl-ec-dock
>> - asus,tf300tl-ec-pad
>> - asus,tf700t-ec-dock
>> - asus,tf700t-ec-pad
>> - asus,tf600t-ec-pad
>> - asus,tf701t-ec-pad
>> - const: asus,transformer-ec
>>
>> And them schema name will match the genetic compatible.
>
>Then what does the generic compatible express?
>
Then enum it is
>
>Best regards,
>Krzysztof
^ permalink raw reply
* [PATCH] HID: multitouch: new class MT_CLS_EGALAX_P80H84
From: Ian Ray @ 2026-02-17 11:51 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Sebastian Reichel
Cc: Ian Ray, linux-input, linux-kernel
Add class MT_CLS_EGALAX_P80H84 to describe eGalaxy P80H84 touchscreen.
The eGalaxy P80H84 touchscreen reports 'HID_GROUP_MULTITOUCH_WIN_8' and
this caused the generic 'MT_CLS_WIN_8' class to be detected.
The new class does _not_ export all inputs, since doing so results in a
visible mouse cursor when only the touchscreen is connected.
The visible mouse cursor was exposed by c23e2043d5f7 ("HID: multitouch:
do not filter mice nodes").
Before this change:
-- >8 --
kernel: input: eGalax Inc. eGalaxTouch P80H84 2537 v00_T3 k4.10.139 as /devices/platform/soc/2100000.bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:0EEF:C002.0001/input/input1
kernel: input: eGalax Inc. eGalaxTouch P80H84 2537 v00_T3 k4.10.139 UNKNOWN as /devices/platform/soc/2100000.bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:0EEF:C002.0001/input/input3
kernel: hid-multitouch 0003:0EEF:C002.0001: input,hidraw0: USB HID v1.11 Pointer [eGalax Inc. eGalaxTouch P80H84 2537 v00_T3 k4.10.139] on usb-ci_hdrc.0-1.4/input0
-- >8 --
After this change:
-- >8 --
kernel: input: eGalax Inc. eGalaxTouch P80H84 2537 v00_T3 k4.10.139 as /devices/platform/soc/2100000.bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:0EEF:C002.0001/input/input1
kernel: hid-multitouch 0003:0EEF:C002.0001: input,hidraw0: USB HID v1.11 Pointer [eGalax Inc. eGalaxTouch P80H84 2537 v00_T3 k4.10.139] on usb-ci_hdrc.0-1.4/input0
-- >8 --
Fixes: f9e82295eec1 ("HID: multitouch: add eGalaxTouch P80H84 support")
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
---
drivers/hid/hid-multitouch.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 7daa8f6d8187..8052b35bfd7d 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -233,6 +233,7 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app);
#define MT_CLS_SMART_TECH 0x0113
#define MT_CLS_APPLE_TOUCHBAR 0x0114
#define MT_CLS_YOGABOOK9I 0x0115
+#define MT_CLS_EGALAX_P80H84 0x0116
#define MT_CLS_SIS 0x0457
#define MT_DEFAULT_MAXCONTACT 10
@@ -438,6 +439,11 @@ static const struct mt_class mt_classes[] = {
MT_QUIRK_YOGABOOK9I,
.export_all_inputs = true
},
+ { .name = MT_CLS_EGALAX_P80H84,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_IGNORE_DUPLICATES |
+ MT_QUIRK_CONTACT_CNT_ACCURATE,
+ },
{ }
};
@@ -2215,8 +2221,9 @@ static const struct hid_device_id mt_devices[] = {
{ .driver_data = MT_CLS_EGALAX_SERIAL,
MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C000) },
- { .driver_data = MT_CLS_EGALAX,
- MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
+ { .driver_data = MT_CLS_EGALAX_P80H84,
+ HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_DWAV,
USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) },
/* Elan devices */
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Konrad Dybcio @ 2026-02-17 12:27 UTC (permalink / raw)
To: Dmitry Baryshkov, Rakesh Kota
Cc: Krzysztof Kozlowski, 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: <k2eu6lvokuh6pilmipztfqufffkmxa3zylsxz4lad45ow255no@fvocedpr3qwp>
On 2/13/26 7:17 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 10, 2026 at 01:56:12PM +0530, 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,
>
> I can't find PMM8654AU either on Qualcomm.com or in the catalog. Is it
> an actual name for the chip?
Right, I would like to see some clarity on that too.
I see there's a PMM8650AU and there's two variants of it, perhaps that's
one of them?
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Konrad Dybcio @ 2026-02-17 12:29 UTC (permalink / raw)
To: Rakesh Kota, 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
In-Reply-To: <20260211104153.r6xz7ya5emxa36cp@hu-kotarake-hyd.qualcomm.com>
On 2/11/26 11:41 AM, Rakesh Kota wrote:
> 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.
I believe the only issue here is the commit message indeed, you're not
reserving an identifier, but rather describing a new version/implementation
of a hardware block that (with the 8350 fallback) just happens not to need
any specific handling to make use of the 99.9% of its features
Konrad
^ 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