* Re: [PATCH 3/3] HID: asus: avoid memory leak in asus_report_fixup()
From: Günther Noack @ 2026-02-17 19:51 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <aZSzASB_TC2RyQsR@plouf>
Hello!
On Tue, Feb 17, 2026 at 07:31:23PM +0100, Benjamin Tissoires wrote:
> On Feb 17 2026, Günther Noack wrote:
> > The asus_report_fixup() function was allocating a new buffer with kmemdup()
> > when growing the report descriptor but never freeing it. Switch to
> > devm_kzalloc() to ensure the memory is managed and freed automatically when
> > the device is removed.
>
> Actually this one is even worse: you can't use devm_kzalloc because
> hid-core.c will later call kfree(dev->rdesc) if dev->rdesc is different
> from the one provided by the low level driver. So we are going to have
> a double free.
The buffer returned by report_fixup() is duplicated first before
hid-core stores it in dev->rdesc. The pointer that report_fixup()
returns is not managed by the caller.
I elaborated in the response to the other patch in [1]. You can see
it in the source code in the position marked with (4).
[1] https://lore.kernel.org/all/aZTEnPEHcWEkoTJR@google.com/
> I really wonder if this was ever tested.
I only convinced myself by staring at the code, because I do not
happen to have the matching USB devices here. What it your usual
approach to verifying such changes? raw-gadget?
—Günther
^ permalink raw reply
* Re: [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup()
From: Günther Noack @ 2026-02-17 19:42 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <aZSxeusondD26uN3@plouf>
Hello Benjamin!
On Tue, Feb 17, 2026 at 07:22:20PM +0100, Benjamin Tissoires wrote:
> On Feb 17 2026, Günther Noack wrote:
> > The apple_report_fixup() function was allocating a new buffer with
> > kmemdup() but never freeing it. Since the caller of report_fixup() already
> > provides a writable buffer and allows returning a pointer within that
> > buffer, we can just modify the descriptor in-place and return the adjusted
> > pointer.
> >
> > Assisted-by: Gemini-CLI:Google Gemini 3
> > Signed-off-by: Günther Noack <gnoack@google.com>
> > ---
> > drivers/hid/hid-apple.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index 233e367cce1d..894adc23367b 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -686,9 +686,7 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> > hid_info(hdev,
> > "fixing up Magic Keyboard battery report descriptor\n");
> > *rsize = *rsize - 1;
> > - rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
> > - if (!rdesc)
> > - return NULL;
> > + rdesc = rdesc + 1;
>
> I might be wrong, but later we call free(dev->rdesc) on device removal.
> AFAICT, incrementing the pointer is undefined behavior.
>
> What we should do instead is probably a krealloc instead of a kmemdup.
>
> Same for all 3 patches.
Thanks for the review.
Let me try to address your three responses in one reply.
I am happy to accept it if I am wrong about this, but I don't
understand your reasoning. (This should go without saying, but maybe
is worth reiterating, I would not have sent this if I had not
convinced myself independently of LLM-assisted reasoning.)
Let me explain my reasoning based on the place where .report_fixup()
is called from, which is hid_open_report() in hid-core.c:
start = device->bpf_rdesc; /* (1) */
if (WARN_ON(!start))
return -ENODEV;
size = device->bpf_rsize;
if (device->driver->report_fixup) {
/*
* device->driver->report_fixup() needs to work
* on a copy of our report descriptor so it can
* change it.
*/
__u8 *buf = kmemdup(start, size, GFP_KERNEL); /* (2) */
if (buf == NULL)
return -ENOMEM;
start = device->driver->report_fixup(device, buf, &size); /* (3) */
/*
* The second kmemdup is required in case report_fixup() returns
* a static read-only memory, but we have no idea if that memory
* needs to be cleaned up or not at the end.
*/
start = kmemdup(start, size, GFP_KERNEL); /* (4) */
kfree(buf); /* (5) */
if (start == NULL)
return -ENOMEM;
}
device->rdesc = start;
device->rsize = size;
This function uses a slightly elaborate scheme to call .report_fixup:
(1) start is assigned to the original device->bpf_rdesc
(2) buf is assigned to a copy of the 'start' buffer (deallocated in (5)).
. It is done because buf is meant to be mutated by .report_fixup()
. (3) start = ...->report_fixup(..., buf, ...)
. (4) start = kmemdup(start, ...)
(5) deallocate buf
Importantly:
(a) The buffer buf passed to report_fixup() is a copy of the report
descriptor whose lifetime spans only from (2) to (5).
(b) The result of .report_fixup(), start, is immediately discarded in
(4) and reassigned to the start variable again.
From (b), we can see that the result of .report_fixup() does *not* get
deallocated by the caller, and thus, when the driver wants to return a
newly allocated array, is must also hold a reference to it so that it
can deallocate it later.
From (a), we can see that the report_fixup hook is free to manipulate
the contents of the buffer that it receives, but if we were to
*reallocate* it within report_fixup, as you are suggesting above, it
could become a double free:
* During realloc, the allocator would potentially have to move the
buffer to a place where there is enough space, freeing up the old
place and allocating a new place. [1]
* In (5), we would then pass the original (now deallocated) buf
pointer to kfree, leading to a double free.
If I were to describe the current interface of the hook
.report_fixup(dev, rdesc, rsize), it would be:
* report_fixup may modify rdesc[0] to rdesc[rsize-1]
* report_fixup may *not* deallocate rdesc
(ownership of rdesc stays with the caller)
* specifically, it may also not reallocate rdesc
(because that may imply a deallocation)
* report_fixup returns a pointer to a buffer for which it can
guarantee that it lives long enough for the kmemdup in (4), but
which will *not* be deallocated by the caller (see (b) above). The
three techniques I have found for that are:
* returning a subsection of the rdesc that it received
* returning a pointer into a statically allocated array
(e.g. motion_fixup() and ps3remote_fixup() in hid-sony.c)
* allocating it with a devm_*() function. My understanding was
that this ties it to the lifetime of the device. (e.g. the
QUIRK_G752_KEYBOARD case in hid-asus.c)
Honestly, I still think that this reasoning holds, but I am happy to
be convinced otherwise. Please let me know what you think.
—Günther
^ permalink raw reply
* Re: [PATCH 0/3] HID: Fix some memory leaks in drivers/hid
From: Benjamin Tissoires @ 2026-02-17 18:36 UTC (permalink / raw)
To: Günther Noack; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260217160125.1097578-1-gnoack@google.com>
On Feb 17 2026, Günther Noack wrote:
> Hello!
>
> These patches fix a few memory leaks in HID report descriptor fixups.
>
> FWIW, a good ad-hoc way to look for usages of allocation functions in
> these is:
>
> awk '/static.*report_fixup.*/,/^}/ { print FILENAME, $0 }' drivers/hid/hid-*.c \
> | grep -E '(malloc|kzalloc|kcalloc|kmemdup)'
>
> The devm_* variants are safe in this context, because they tie the
> allocated memory to the lifetime of the driver.
No. Look at hid_close_report() in drivers/hid/hid-core.c.
HID still hasn't fully migrated to devm, so as a rule of thumb, if you
change a kzalloc into a devm_kzalloc, you are getting into troubles
unless you fix the all the kfree path.
>
> For transparency, I generated these commits with Gemini-CLI,
> starting with this prompt:
>
> We are working in the Linux kernel. In the HID drivers in
> `drivers/hid/hid-*.c`, the `report_fixup` driver hook is a function
> that gets a byte buffer (with size) as input and that may modify that
> byte buffer, and optionally return a pointer to a new byte buffer and
> update the size. The returned value is *not* memory-managed by the
> caller though and will not be freed subsequently. When the
If the memory is *not* managed, why would gemini converts kzalloc into
devm variants without changing the kfree paths????
> `report_fixup` implementation allocates a new buffer and returns that,
> that will not get freed by the caller.
This is wrong. See hid_close_report(): if the new rdesc (after fixup)
differs from the one initially set, there is an explicit call to
kfree().
-> there is no memleak AFAICT, and your prompt is wrong.
Cheers,
Benjamin
> Validate this assessment and
> fix up all HID drivers where that mistake is made.
>
> (and then a little bit of additional nudging for the details).
>
> —Günther
>
>
> Günther Noack (3):
> HID: apple: avoid memory leak in apple_report_fixup()
> HID: magicmouse: avoid memory leak in magicmouse_report_fixup()
> HID: asus: avoid memory leak in asus_report_fixup()
>
> drivers/hid/hid-apple.c | 4 +---
> drivers/hid/hid-asus.c | 15 +++++++++++----
> drivers/hid/hid-magicmouse.c | 4 +---
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> --
> 2.53.0.335.g19a08e0c02-goog
>
^ permalink raw reply
* Re: [PATCH 3/3] HID: asus: avoid memory leak in asus_report_fixup()
From: Benjamin Tissoires @ 2026-02-17 18:31 UTC (permalink / raw)
To: Günther Noack; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260217160125.1097578-4-gnoack@google.com>
On Feb 17 2026, Günther Noack wrote:
> The asus_report_fixup() function was allocating a new buffer with kmemdup()
> when growing the report descriptor but never freeing it. Switch to
> devm_kzalloc() to ensure the memory is managed and freed automatically when
> the device is removed.
Actually this one is even worse: you can't use devm_kzalloc because
hid-core.c will later call kfree(dev->rdesc) if dev->rdesc is different
from the one provided by the low level driver. So we are going to have
a double free.
I really wonder if this was ever tested.
Cheers,
Benjamin
>
> Also fix a harmless out-of-bounds read by copying only the original
> descriptor size.
>
> Assisted-by: Gemini-CLI:Google Gemini 3
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-asus.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 8ffcd12038e8..7a08e964b9cc 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1399,14 +1399,21 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> */
> if (*rsize == rsize_orig &&
> rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
> - *rsize = rsize_orig + 1;
> - rdesc = kmemdup(rdesc, *rsize, GFP_KERNEL);
> - if (!rdesc)
> - return NULL;
> + __u8 *new_rdesc;
> +
> + new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
> + GFP_KERNEL);
> + if (!new_rdesc)
> + return rdesc;
>
> hid_info(hdev, "Fixing up %s keyb report descriptor\n",
> drvdata->quirks & QUIRK_T100CHI ?
> "T100CHI" : "T90CHI");
> +
> + memcpy(new_rdesc, rdesc, rsize_orig);
> + *rsize = rsize_orig + 1;
> + rdesc = new_rdesc;
> +
> memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
> rdesc[offs] = 0x19;
> rdesc[offs + 1] = 0x00;
> --
> 2.53.0.335.g19a08e0c02-goog
>
^ permalink raw reply
* Re: [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup()
From: Benjamin Tissoires @ 2026-02-17 18:22 UTC (permalink / raw)
To: Günther Noack; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260217160125.1097578-2-gnoack@google.com>
On Feb 17 2026, Günther Noack wrote:
> The apple_report_fixup() function was allocating a new buffer with
> kmemdup() but never freeing it. Since the caller of report_fixup() already
> provides a writable buffer and allows returning a pointer within that
> buffer, we can just modify the descriptor in-place and return the adjusted
> pointer.
>
> Assisted-by: Gemini-CLI:Google Gemini 3
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-apple.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index 233e367cce1d..894adc23367b 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -686,9 +686,7 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> hid_info(hdev,
> "fixing up Magic Keyboard battery report descriptor\n");
> *rsize = *rsize - 1;
> - rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
> - if (!rdesc)
> - return NULL;
> + rdesc = rdesc + 1;
I might be wrong, but later we call free(dev->rdesc) on device removal.
AFAICT, incrementing the pointer is undefined behavior.
What we should do instead is probably a krealloc instead of a kmemdup.
Same for all 3 patches.
Cheers,
Benjamin
>
> rdesc[0] = 0x05;
> rdesc[1] = 0x01;
> --
> 2.53.0.335.g19a08e0c02-goog
>
^ permalink raw reply
* Re: [PATCH] Input: libps2 - embed WARN_ON(1) macros into their enclosing if statements
From: Dmitry Torokhov @ 2026-02-17 18:07 UTC (permalink / raw)
To: Max Brener; +Cc: linux-input, linux-kernel
In-Reply-To: <20260214203725.6463-1-linmaxi@gmail.com>
On Sat, Feb 14, 2026 at 10:37:24PM +0200, Max Brener wrote:
> Make WARN_ON(1) statements embedded inside their respective 'if' expressions,
> to improve code clarity.
>
> Signed-off-by: Max Brener <linmaxi@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH 3/3] HID: asus: avoid memory leak in asus_report_fixup()
From: Günther Noack @ 2026-02-17 16:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input, linux-kernel, Günther Noack
In-Reply-To: <20260217160125.1097578-1-gnoack@google.com>
The asus_report_fixup() function was allocating a new buffer with kmemdup()
when growing the report descriptor but never freeing it. Switch to
devm_kzalloc() to ensure the memory is managed and freed automatically when
the device is removed.
Also fix a harmless out-of-bounds read by copying only the original
descriptor size.
Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-asus.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 8ffcd12038e8..7a08e964b9cc 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1399,14 +1399,21 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
*/
if (*rsize == rsize_orig &&
rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
- *rsize = rsize_orig + 1;
- rdesc = kmemdup(rdesc, *rsize, GFP_KERNEL);
- if (!rdesc)
- return NULL;
+ __u8 *new_rdesc;
+
+ new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
+ GFP_KERNEL);
+ if (!new_rdesc)
+ return rdesc;
hid_info(hdev, "Fixing up %s keyb report descriptor\n",
drvdata->quirks & QUIRK_T100CHI ?
"T100CHI" : "T90CHI");
+
+ memcpy(new_rdesc, rdesc, rsize_orig);
+ *rsize = rsize_orig + 1;
+ rdesc = new_rdesc;
+
memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
rdesc[offs] = 0x19;
rdesc[offs + 1] = 0x00;
--
2.53.0.335.g19a08e0c02-goog
^ permalink raw reply related
* [PATCH 2/3] HID: magicmouse: avoid memory leak in magicmouse_report_fixup()
From: Günther Noack @ 2026-02-17 16:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input, linux-kernel, Günther Noack
In-Reply-To: <20260217160125.1097578-1-gnoack@google.com>
The magicmouse_report_fixup() function was allocating a new buffer with
kmemdup() but never freeing it. Since the caller already provides a
writable buffer and allows returning a pointer within it, modify the
descriptor in-place and return the adjusted pointer.
Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-magicmouse.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index 91f621ceb924..17908d52c027 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -994,9 +994,7 @@ static const __u8 *magicmouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
hid_info(hdev,
"fixing up magicmouse battery report descriptor\n");
*rsize = *rsize - 1;
- rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
- if (!rdesc)
- return NULL;
+ rdesc = rdesc + 1;
rdesc[0] = 0x05;
rdesc[1] = 0x01;
--
2.53.0.335.g19a08e0c02-goog
^ permalink raw reply related
* [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup()
From: Günther Noack @ 2026-02-17 16:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input, linux-kernel, Günther Noack
In-Reply-To: <20260217160125.1097578-1-gnoack@google.com>
The apple_report_fixup() function was allocating a new buffer with
kmemdup() but never freeing it. Since the caller of report_fixup() already
provides a writable buffer and allows returning a pointer within that
buffer, we can just modify the descriptor in-place and return the adjusted
pointer.
Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-apple.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 233e367cce1d..894adc23367b 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -686,9 +686,7 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
hid_info(hdev,
"fixing up Magic Keyboard battery report descriptor\n");
*rsize = *rsize - 1;
- rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
- if (!rdesc)
- return NULL;
+ rdesc = rdesc + 1;
rdesc[0] = 0x05;
rdesc[1] = 0x01;
--
2.53.0.335.g19a08e0c02-goog
^ permalink raw reply related
* [PATCH 0/3] HID: Fix some memory leaks in drivers/hid
From: Günther Noack @ 2026-02-17 16:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input, linux-kernel, Günther Noack
Hello!
These patches fix a few memory leaks in HID report descriptor fixups.
FWIW, a good ad-hoc way to look for usages of allocation functions in
these is:
awk '/static.*report_fixup.*/,/^}/ { print FILENAME, $0 }' drivers/hid/hid-*.c \
| grep -E '(malloc|kzalloc|kcalloc|kmemdup)'
The devm_* variants are safe in this context, because they tie the
allocated memory to the lifetime of the driver.
For transparency, I generated these commits with Gemini-CLI,
starting with this prompt:
We are working in the Linux kernel. In the HID drivers in
`drivers/hid/hid-*.c`, the `report_fixup` driver hook is a function
that gets a byte buffer (with size) as input and that may modify that
byte buffer, and optionally return a pointer to a new byte buffer and
update the size. The returned value is *not* memory-managed by the
caller though and will not be freed subsequently. When the
`report_fixup` implementation allocates a new buffer and returns that,
that will not get freed by the caller. Validate this assessment and
fix up all HID drivers where that mistake is made.
(and then a little bit of additional nudging for the details).
—Günther
Günther Noack (3):
HID: apple: avoid memory leak in apple_report_fixup()
HID: magicmouse: avoid memory leak in magicmouse_report_fixup()
HID: asus: avoid memory leak in asus_report_fixup()
drivers/hid/hid-apple.c | 4 +---
drivers/hid/hid-asus.c | 15 +++++++++++----
drivers/hid/hid-magicmouse.c | 4 +---
3 files changed, 13 insertions(+), 10 deletions(-)
--
2.53.0.335.g19a08e0c02-goog
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Conor Dooley @ 2026-02-17 15:50 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Krzysztof Kozlowski, 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: <CAPVz0n0u7uhL8_FQFiuB7DrnL++ecbaEKEoV7N2PgTVRBVECkw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
On Tue, Feb 17, 2026 at 04:29:59PM +0200, Svyatoslav Ryhel wrote:
> вт, 17 лют. 2026 р. о 16:03 Conor Dooley <conor@kernel.org> пише:
> > On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote:
> > > 17 лютого 2026 р. 13:32:26 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише:
> > > >> 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
> >
> >
> > Why would you do that, instead of what I posted earlier in the thread?
> > If you send a flat enum with all devices listed, I'm gonna just be there
> > telling you to consolidate into one device-specific fallback compatible
> > per programming model.
>
> There is no one device-specific fallback compatible! Schema describes
> HARDWARE not drivers no? I will not use random device compatible from
> the list as a fallback compatible for a different random unrelated
> device, that is plain wrong.
Which is why I am not mentioning drivers at all, and instead talking about
programming models. Fallback compatibles represent similarities in
programming model, even if the laptop that these devices are contained
in are different, so whatever device compatible you pick might be random
(but going chronologically is usually my recommendation) but it won't be
unrelated.
> Discuss this with Krzysztof and come up with something meaningful please.
If you don't consider my reviews to be meaningful, you're welcome to
carry a Nacked-by: Conor Dooley <conor.dooley@microchip.com> with a link
to this discussion instead.
Thanks,
Conor.
[-- 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: Krzysztof Kozlowski @ 2026-02-17 14:44 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: <CAPVz0n0u7uhL8_FQFiuB7DrnL++ecbaEKEoV7N2PgTVRBVECkw@mail.gmail.com>
On 17/02/2026 15:29, Svyatoslav Ryhel wrote:
>>>>> 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
>>
>>
>> Why would you do that, instead of what I posted earlier in the thread?
>> If you send a flat enum with all devices listed, I'm gonna just be there
>> telling you to consolidate into one device-specific fallback compatible
>> per programming model.
>
> There is no one device-specific fallback compatible! Schema describes
> HARDWARE not drivers no? I will not use random device compatible from
You came with "asus,transformer-ec" as fallback which is same random
choice, so how one random device is okay, but other not? We asked to use
some meaningful device as fallback, to the best of current knowledge.
> the list as a fallback compatible for a different random unrelated
> device, that is plain wrong. Discuss this with Krzysztof and come up
> with something meaningful please.
It is not pleasant to review your patches. This happened in the past [1]
and recently is not getting better. In multiple threads. Receiving
half-baked responses to actual review questions means you do not value
our time. I think you somehow annoyed, offended or wasted time of all
three DT maintainers.
Well, sure, happens.
Just understand there might be a reason when your patches do not receive
attention or reviews.
[1]
https://lore.kernel.org/r/CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@mail.gmail.com/
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 14:29 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, 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-dig-husked-8a59b6a19aee@spud>
вт, 17 лют. 2026 р. о 16:03 Conor Dooley <conor@kernel.org> пише:
>
> On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote:
> >
> >
> > 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
>
>
> Why would you do that, instead of what I posted earlier in the thread?
> If you send a flat enum with all devices listed, I'm gonna just be there
> telling you to consolidate into one device-specific fallback compatible
> per programming model.
There is no one device-specific fallback compatible! Schema describes
HARDWARE not drivers no? I will not use random device compatible from
the list as a fallback compatible for a different random unrelated
device, that is plain wrong. Discuss this with Krzysztof and come up
with something meaningful please.
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: Conor Dooley @ 2026-02-17 14:03 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Krzysztof Kozlowski, 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: <81844CC9-5355-4B1D-AEBD-6DD67FB8C81B@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]
On Tue, Feb 17, 2026 at 01:34:01PM +0200, Svyatoslav Ryhel wrote:
>
>
> 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
Why would you do that, instead of what I posted earlier in the thread?
If you send a flat enum with all devices listed, I'm gonna just be there
telling you to consolidate into one device-specific fallback compatible
per programming model.
[-- 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: Conor Dooley @ 2026-02-17 14:01 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: <55C30023-4175-48F2-BCB0-12EC23C48F01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8575 bytes --]
On Tue, Feb 17, 2026 at 01:23:06PM +0200, Svyatoslav Ryhel wrote:
>
>
> 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.
And what is to stop the next device in 2027 or w/e having a different
programming model (so a third)? That's my point, I wasn't talking about
there being more devices with two programming models evidenced here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] touchscreen-dmi quirk for SUPI S10
From: Hans de Goede @ 2026-02-17 13:24 UTC (permalink / raw)
To: Yajat Kumar, dmitry.torokhov, linux-input, linux-kernel
In-Reply-To: <20260217050755.16078-1-yajatapps3@gmail.com>
Hi,
On 17-Feb-26 06:07, Yajat Kumar wrote:
> 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.
Thank you for testing. Now that its been confirmed
this works I've posted the patch upstream:
https://lore.kernel.org/platform-driver-x86/20260217132346.34535-1-johannes.goede@oss.qualcomm.com/
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: monaco-pmics: Add PON power key and reset inputs
From: Konrad Dybcio @ 2026-02-17 12:30 UTC (permalink / raw)
To: Rakesh Kota, Sebastian Reichel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Dmitry Torokhov, Courtney Cavin,
Bjorn Andersson, Konrad Dybcio
Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, linux-input
In-Reply-To: <20260209-add_pwrkey_and_resin-v2-3-f944d87b9a93@oss.qualcomm.com>
On 2/9/26 2:23 PM, Rakesh Kota wrote:
> Add the Power On (PON) peripheral with power key and reset input
> support for the PMM8654AU PMIC on Monaco platforms.
>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-pmics.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> index e990d7367719beaa9e0cea87d9c183ae18c3ebc8..182c2339bb11af40275050a36c4688227e89497a 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> @@ -13,6 +13,26 @@ pmm8620au_0: pmic@0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + pmm8654au_0_pon: pon@1200 {
> + compatible = "qcom,pmm8654au-pon", "qcom,pmk8350-pon";
> + reg = <0x1200>, <0x800>;
> + reg-names = "hlos", "pbs";
> +
> + pmm8654au_0_pon_pwrkey: pwrkey {
> + compatible = "qcom,pmm8654au-pwrkey", "qcom,pmk8350-pwrkey";
> + interrupts-extended = <&spmi_bus 0x0 0x12 0x7 IRQ_TYPE_EDGE_BOTH>;
> + linux,code = <KEY_POWER>;
> + debounce = <15625>;
> + };
> +
> + pmm8654au_0_pon_resin: resin {
> + compatible = "qcom,pmm8654au-resin", "qcom,pmk8350-resin";
> + interrupts-extended = <&spmi_bus 0x0 0x12 0x6 IRQ_TYPE_EDGE_BOTH>;
> + linux,code = <KEY_VOLUMEDOWN>;
> + debounce = <15625>;
FWIW we tend to disable RESIN by default, as it's not as ubiquitous as
the power key and only assign the keycode in board DT, since it may
commonly be reused for either of the volume keys (or something else
entirely)
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
* 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
* [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 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
* 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: 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: 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: 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
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