* 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 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] 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
* [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
* [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
* 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
* 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 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: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
* [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
* [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
* 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 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
* [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
* [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
* 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
* [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 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
* Re: [PATCH 0/2] iio: orientation: hid-sensor-rotation: fix quaternion alignment
From: Andy Shevchenko @ 2026-02-16 7:44 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-0-47f01288c803@baylibre.com>
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() ?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: kernel test robot @ 2026-02-16 4:57 UTC (permalink / raw)
To: Svyatoslav Ryhel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Lee Jones, Pavel Machek, Sebastian Reichel,
Ion Agorria, Michał Mirosław
Cc: llvm, oe-kbuild-all, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260214180959.30714-3-clamor95@gmail.com>
Hi Svyatoslav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20260213]
[also build test WARNING on linus/master v6.19]
[cannot apply to dtor-input/next dtor-input/for-linus sre-power-supply/for-next robh/for-next v6.19 v6.19-rc8 v6.19-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Svyatoslav-Ryhel/dt-bindings-embedded-controller-document-ASUS-Transformer-EC/20260215-021406
base: next-20260213
patch link: https://lore.kernel.org/r/20260214180959.30714-3-clamor95%40gmail.com
patch subject: [PATCH v3 2/7] mfd: Add driver for ASUS Transformer embedded controller
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260216/202602161252.Kq5BRohK-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260216/202602161252.Kq5BRohK-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602161252.Kq5BRohK-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/asus-transformer-ec.c:234:40: warning: field width should have type 'int', but argument has type '__size_t' (aka 'unsigned long') [-Wformat]
234 | dev_dbg(&priv->self->dev, "EC read: %*ph, ret = %d%s\n",
| ~~^
235 | sizeof(priv->ec_data), priv->ec_data,
| ~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:165:31: note: expanded from macro 'dev_dbg'
165 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~ ~~~~~~~~~~~
include/linux/dev_printk.h:19:22: note: expanded from macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
include/linux/dynamic_debug.h:285:12: note: expanded from macro 'dynamic_dev_dbg'
285 | dev, fmt, ##__VA_ARGS__)
| ^~~ ~~~~~~~~~~~
include/linux/dynamic_debug.h:261:59: note: expanded from macro '_dynamic_func_call'
261 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/dynamic_debug.h:259:65: note: expanded from macro '_dynamic_func_call_cls'
259 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/dynamic_debug.h:231:15: note: expanded from macro '__dynamic_func_call_cls'
231 | func(&id, ##__VA_ARGS__); \
| ^~~~~~~~~~~
1 warning generated.
vim +234 drivers/mfd/asus-transformer-ec.c
227
228 static int asus_ec_read(struct asus_ec_data *priv, bool in_irq)
229 {
230 int ret = i2c_smbus_read_i2c_block_data(priv->self, ASUSEC_READ_BUF,
231 sizeof(priv->ec_data),
232 priv->ec_data);
233
> 234 dev_dbg(&priv->self->dev, "EC read: %*ph, ret = %d%s\n",
235 sizeof(priv->ec_data), priv->ec_data,
236 ret, in_irq ? "; in irq" : "");
237
238 return ret;
239 }
240
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] HID: wiimote: change wiimote_cmd_map_mp() to return void
From: Ethan Tidmore @ 2026-02-16 3:20 UTC (permalink / raw)
To: david; +Cc: jikos, bentiss, linux-input, linux-kernel, Ethan Tidmore
The function wiimote_cmd_map_mp() returns bool but no variable is ever
assigned to its return value. Also, by it returning bool it causes a
signedness warning from Smatch because wiimote_cmd_write() can return
-EIO.
Detected by Smatch:
drivers/hid/hid-wiimote-core.c:510 wiimote_cmd_map_mp() warn:
signedness bug returning '(-512)'
Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
---
drivers/hid/hid-wiimote-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-wiimote-core.c b/drivers/hid/hid-wiimote-core.c
index 5b5fc460a4c5..c4d11ff3c898 100644
--- a/drivers/hid/hid-wiimote-core.c
+++ b/drivers/hid/hid-wiimote-core.c
@@ -487,7 +487,7 @@ static int wiimote_cmd_init_mp(struct wiimote_data *wdata)
}
/* requires the cmd-mutex to be held */
-static bool wiimote_cmd_map_mp(struct wiimote_data *wdata, __u8 exttype)
+static void wiimote_cmd_map_mp(struct wiimote_data *wdata, __u8 exttype)
{
__u8 wmem;
@@ -507,7 +507,7 @@ static bool wiimote_cmd_map_mp(struct wiimote_data *wdata, __u8 exttype)
break;
}
- return wiimote_cmd_write(wdata, 0xa600fe, &wmem, sizeof(wmem));
+ wiimote_cmd_write(wdata, 0xa600fe, &wmem, sizeof(wmem));
}
/* requires the cmd-mutex to be held */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: kernel test robot @ 2026-02-15 20:28 UTC (permalink / raw)
To: Svyatoslav Ryhel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Lee Jones, Pavel Machek, Sebastian Reichel,
Ion Agorria, Michał Mirosław
Cc: llvm, oe-kbuild-all, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260214180959.30714-3-clamor95@gmail.com>
Hi Svyatoslav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20260213]
[also build test WARNING on linus/master v6.19]
[cannot apply to dtor-input/next dtor-input/for-linus sre-power-supply/for-next robh/for-next v6.19 v6.19-rc8 v6.19-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Svyatoslav-Ryhel/dt-bindings-embedded-controller-document-ASUS-Transformer-EC/20260215-021406
base: next-20260213
patch link: https://lore.kernel.org/r/20260214180959.30714-3-clamor95%40gmail.com
patch subject: [PATCH v3 2/7] mfd: Add driver for ASUS Transformer embedded controller
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260216/202602160408.CZnIzWhv-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260216/202602160408.CZnIzWhv-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602160408.CZnIzWhv-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/asus-transformer-ec.c:234:40: warning: field width should have type 'int', but argument has type 'unsigned long' [-Wformat]
dev_dbg(&priv->self->dev, "EC read: %*ph, ret = %d%s\n",
~~^
include/linux/dev_printk.h:165:31: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~ ~~~~~~~~~~~
include/linux/dev_printk.h:19:22: note: expanded from macro 'dev_fmt'
#define dev_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:285:12: note: expanded from macro 'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
^~~ ~~~~~~~~~~~
include/linux/dynamic_debug.h:261:59: note: expanded from macro '_dynamic_func_call'
_dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~
include/linux/dynamic_debug.h:259:65: note: expanded from macro '_dynamic_func_call_cls'
__dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~
include/linux/dynamic_debug.h:231:15: note: expanded from macro '__dynamic_func_call_cls'
func(&id, ##__VA_ARGS__); \
^~~~~~~~~~~
1 warning generated.
vim +234 drivers/mfd/asus-transformer-ec.c
227
228 static int asus_ec_read(struct asus_ec_data *priv, bool in_irq)
229 {
230 int ret = i2c_smbus_read_i2c_block_data(priv->self, ASUSEC_READ_BUF,
231 sizeof(priv->ec_data),
232 priv->ec_data);
233
> 234 dev_dbg(&priv->self->dev, "EC read: %*ph, ret = %d%s\n",
235 sizeof(priv->ec_data), priv->ec_data,
236 ret, in_irq ? "; in irq" : "");
237
238 return ret;
239 }
240
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [git pull] Input updates for v6.20-rc0
From: pr-tracker-bot @ 2026-02-15 16:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <aZE_tkCsDuCAH3Ux@google.com>
The pull request you sent on Sat, 14 Feb 2026 19:39:37 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v7.0-rc0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/348e77b8145676184fb49063d5543e054fd74909
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH v2 5/5] input: drv260x: Handle calibration timeout
From: Yauhen Kharuzhy @ 2026-02-15 14:14 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: linux-kernel, Hans de Goede
In-Reply-To: <20260215141435.727872-1-jekhor@gmail.com>
If something goes wrong during calibration (for instance, if the 'enable'
GPIO was not properly defined), the GO bit may not be cleared after some
time, causing the driver to get stuck.
To prevent this, add a timeout check to the waiting loop and return an
error if it times out.
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
drivers/input/misc/drv260x.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 71fbdabc6589..7ab891210fad 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -166,6 +166,12 @@
#define DRV260X_AUTOCAL_TIME_500MS (2 << 4)
#define DRV260X_AUTOCAL_TIME_1000MS (3 << 4)
+/*
+ * Timeout for waiting for the GO status bit, in seconds. Should be reasonably
+ * large to wait for a auto-calibration cycle completion.
+ */
+#define DRV260X_GO_TIMEOUT_S 5
+
/**
* struct drv260x_data -
* @input_dev: Pointer to the input device
@@ -309,6 +315,7 @@ static int drv260x_init(struct drv260x_data *haptics)
{
int error;
unsigned int cal_buf;
+ unsigned long timeout;
error = regmap_write(haptics->regmap,
DRV260X_RATED_VOLT, haptics->rated_voltage);
@@ -398,6 +405,7 @@ static int drv260x_init(struct drv260x_data *haptics)
return error;
}
+ timeout = jiffies + DRV260X_GO_TIMEOUT_S * HZ;
do {
usleep_range(15000, 15500);
error = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
@@ -407,6 +415,11 @@ static int drv260x_init(struct drv260x_data *haptics)
error);
return error;
}
+ if (time_after(jiffies, timeout)) {
+ dev_err(&haptics->client->dev,
+ "Calibration timeout. The device cannot be used.\n");
+ return -ETIMEDOUT;
+ }
} while (cal_buf == DRV260X_GO_BIT);
return 0;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 4/5] input: drv260x: Fix unbalanced regulator_disable() call
From: Yauhen Kharuzhy @ 2026-02-15 14:14 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: linux-kernel, Hans de Goede
In-Reply-To: <20260215141435.727872-1-jekhor@gmail.com>
The driver acquires the 'vbat' regulator during probing but never enables
it. Consequently, in the suspend method, the driver disables the regulator
without enabling it first, causing an 'Unbalanced regulator_disable()'
error.
Enable the regulator in the probe() method and add the remove() method with
regulator disabling to fix this.
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
drivers/input/misc/drv260x.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index c4dd410c303e..71fbdabc6589 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -520,19 +520,37 @@ static int drv260x_probe(struct i2c_client *client)
return error;
}
+ error = regulator_enable(haptics->regulator);
+ if (error) {
+ dev_err(dev, "Failed to enable regulator\n");
+ return error;
+ }
+
error = drv260x_init(haptics);
if (error) {
dev_err(dev, "Device init failed: %d\n", error);
- return error;
+ goto err_regulator_disable;
}
error = input_register_device(haptics->input_dev);
if (error) {
dev_err(dev, "couldn't register input device: %d\n", error);
- return error;
+ goto err_regulator_disable;
}
return 0;
+
+err_regulator_disable:
+ regulator_disable(haptics->regulator);
+
+ return error;
+}
+
+static void drv260x_remove(struct i2c_client *client)
+{
+ struct drv260x_data *haptics = i2c_get_clientdata(client);
+
+ regulator_disable(haptics->regulator);
}
static int drv260x_suspend(struct device *dev)
@@ -626,6 +644,7 @@ MODULE_DEVICE_TABLE(of, drv260x_of_match);
static struct i2c_driver drv260x_driver = {
.probe = drv260x_probe,
+ .remove = drv260x_remove,
.driver = {
.name = "drv260x-haptics",
.of_match_table = drv260x_of_match,
--
2.51.0
^ permalink raw reply related
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