* Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Muhammad Usama Anjum @ 2025-11-25 10:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: usama.anjum, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <CAJZ5v0gtGjE-rSwM4Kom4cDEhp3eSOkLCmbLwrt_9u9a7VP6zQ@mail.gmail.com>
On 11/24/25 11:50 PM, Rafael J. Wysocki wrote:
> On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
>>
>> Input (Serio) drivers call input_handle_event(). Although the serio
>> drivers have duplicate events, they have separate code path and call
>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>> sent to the userspace if hibernation is in progress.
>
> Your change affects suspend too.
>
> Also, what's the goal you want to achieve?
Two goals:
* Don't send event to userspace
* Set pm_wakeup for hibernation cancellation for non-acpi devices (This api
call should be tested on non-acpi devices such as arm board to see if it
helps. I don't have an arm board in hand)
>
>> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
>> doesn't have wakeup source registered, this call doesn't do anything.
>> But there may be other input drivers which will require this.
>>
>> Without this, the event is sent to the userspace and it suspends the
>> device after hibernation cancellation.
>
> I think that's because user space handles it this way, isn't it?
Yes, it depends on how userspace handles such events. There are different settings
configured for systemd-logind when power event is received. The purpose is to consume
this event to cancel the hibernation without letting userspace know about it.
Thinking more about it, I wasn't sure if all of such events are compulsory to be
delivered to userspace. But then I found an example: In acpi_button_notify(), all
such events are not sent to userspace if button is suspended. So it seems okay to
not send this as well and just consume in the kernel.
>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>> ---
>> Changes since RFC:
>> - Use pm_sleep_transition_in_progress()
>> - Update description
>> ---
>> drivers/input/input.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index a500e1e276c21..7939bd9e47668 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -26,6 +26,7 @@
>> #include <linux/kstrtox.h>
>> #include <linux/mutex.h>
>> #include <linux/rcupdate.h>
>> +#include <linux/suspend.h>
>> #include "input-compat.h"
>> #include "input-core-private.h"
>> #include "input-poller.h"
>> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>>
>> lockdep_assert_held(&dev->event_lock);
>>
>> + if (code == KEY_POWER && pm_sleep_transition_in_progress()) {
>> + pm_wakeup_dev_event(&dev->dev, 0, true);
>> + return;
>> + }
>> +
>> disposition = input_get_disposition(dev, type, code, &value);
>> if (disposition != INPUT_IGNORE_EVENT) {
>> if (type != EV_SYN)
>> --
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: H. Nikolaus Schaller @ 2025-11-25 10:25 UTC (permalink / raw)
To: Romain Gantois
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <3021060.e9J7NaK4W3@fw-rgant>
Hi,
> Am 25.11.2025 um 09:41 schrieb Romain Gantois <romain.gantois@bootlin.com>:
>
>
> This is planned support for a voltage regulator chip.
Well, but one which is not by itself programmable. So IMHO, it does not support that chip,
but the circuit it is used in.
>
> > Are you looking for a virtual "glue" driver to logically combine several low
> > level functions?
> >
>
> I'm looking for a clean userspace abstraction for this component, the low-
> level functions in this case are those of a voltage regulator.
As far as I understood it has
- constant voltage
- current can be limited
- it can be turned on/off
That means it is a fixed-regulator (for constant voltage and turn on/off)
and a mechanism to program the current limit (iio-dac). Both have clean
userspace abstraction.
What am I missing?
> > What I still wonder: does your hardware warrant an upstream driver for a
> > non-programable chip if a different solution (with help of user-space)
> > already exist?
> >
>
> A different solution does not currently exist (although a userspace-based
> solution could be designed). I just think that a kernel-based solution is more
> desirable here.
I agree, but that is a common discussion :) For example, years ago I had a long
discussion if there should be touchscreen pre-calibration in kernel, which is
desirable to get it almost right after boot, or if it is user-space... In the
end it was rejected.
>
> > Another question: is your scheme generic enough so that it can be expected
> > that other devices are using it in the same way?
> >
>
> Yes, the LTM8054 has a fairly common design as far as buck-boost chips go.
> Things like feedback dividers on the output voltage pin are standard practice.
Yes, I know - but how is this related to the kernel or a driver? To my knowledge
feedback dividers are never relevant for kernel drivers for buck regulators,
especially if they are fixed and can not be programmed. They end up in a specification
of regulator-min-microvolt and regulator-max-microvolt.
So I still wonder why they must be made available to the kernel and user-space.
If you look for example into the schematics of a PocketBeagle 2
(https://docs.beagleboard.org/pocketbeagle-2.pdf).
Figure 3.23 on page 26 shows a 3.3V step-down converter with enable and feedback
resistors (560k/124k).
Still, this regulator is represented not by a dedicated TLV62595 driver but:
https://elixir.bootlin.com/linux/v6.18-rc7/source/arch/arm64/boot/dts/ti/k3-am62-pocketbeagle2.dts#L91
Well, it does not have a controllable current limit, just a builtin one.
(And a gpio-control could be added by using a regulator-gpio driver).
> And since the driver doesn't rely on a particular way of integrating the
> LTM8054 with other components, it can be reused wherever the same regulator
> chip is used.
That are my questions:
- what is so different with an LTM8054 to other buck regulators that it needs a dedicated driver
- is the feature to control current limit by a DAC to the LTM8054 or is it the DAC (in software perspective)
- does it need a conversion factor from mA to binary value? Why is this needed in kernel?
- are there similar designs planned for this chip or already in use which run Linux?
> > Or could the power controller framework (/sys/class/power_supply) fit
> > better?
> >
>
> I don't think the power supply abstraction is relevant here. The LTM8054 is a
> voltage regulator, it doesn't have charge, capacity, temperature monitoring,
> power limitation, or other power supply class features.
By current limitation you also have power limitation. Yes, it does not
need to provide charge, capacity, temperature but IMHO they are not all mandatory.
It is just a suggestion to look around if there are different abstractions
that already exist and can be used.
>
> > There is an API to ask chargers etc. for battery voltage and current limits
> > or even write them.
> >
> > There is also "generic-adc-battery" which allows to hook up with arbitrary
> > iio-adcs for measurements - although you need a DAC in your setup. Maybe an
> > extension here is a better strategy than a dedicated ltm8054 driver?
>
>
> What if the LTM8054 is not used to supply a battery?
The question remains if you want to solve something for a single board which
happens to have an LTM8054 or if you are solving a more general design pattern.
In summary my view is that the LTM8054 is just a "fixed-regulator" which
gets an additional current-limiter feature by adding a DAC chip (which needs a
driver of course). So software control is required not by the LTM8054 but by
adding a DAC chip.
Another suggestion: what extending the "regulator-fixed", "regulator-gpio",
"regulator-fixed-clock" pattern by some "regulator-gpio-iio-dac-current-limiter"
driver to make it independent of your specific chip?
By the way, are you aware of this feature of the regulator-gpio driver?
https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/regulator/gpio-regulator.c#L97
Just to note: I am neither maintainer nor doing any decisions on this, just asking
questions for curiosity and from experience and giving hints for alternative approaches,
where I hope they help to find the really best solution.
Best regards,
Nikolaus
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Muhammad Usama Anjum @ 2025-11-25 11:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: usama.anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <2025112433-emphasize-helpful-b748@gregkh>
Hi Greg,
Thank you for the review.
On 11/24/25 10:03 PM, Greg Kroah-Hartman wrote:
> On Fri, Nov 07, 2025 at 11:44:29PM +0500, Muhammad Usama Anjum wrote:
>> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
>> called when power button is pressed. The system is worken up from s2idle
>> in this case by setting hard parameter to pm_wakeup_dev_event().
>>
>> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
>> is in progress. Set the hard parameter such that pm_system_wakeup()
>> gets called which increments pm_abort_suspend counter. The explicit call
>> to acpi_pm_wakeup_event() is necessary as ACPI button device has the
>> wakeup source. Hence call to input_report_key() with input device
>> doesn't call pm_system_wakeup() as it doesn't have wakeup source
>> registered.
>>
>> Hence hibernation would be cancelled as in hibernation path, this counter
>> is checked if it should be aborted.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>
My thinking is that people don't press power button after triggering
hibernation. They will only press power button if they want to cancel the
hibernation or resume from hibernation a bit later when hibernation completes.
> This could be dangerous, as this is not what happens today, are you sure
> that people aren't just used to pressing the button multiple times until
> the system is hibernated? If so, that would now break with this change
> as it's hard to determine what is going on.
Yes, its possible. Previously the device wouldn't cancel hibernation on power
button press; while now it'll cancel.
So should we put this cancellation under some config option to avoid breaking
the default behavior?
>
> And why does hibernate take so long? Why not fix that up instead?
Hibernation is inherently slow: it must freeze devices, copy and
compress/encrypt memory, then resume storage devices to write the image to
disk.
While I've thought about increasing the speed, I've no concrete ideas yet.
The main problem is that its sequential in nature.
>
> thanks,
>
> greg k-h
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Greg Kroah-Hartman @ 2025-11-25 11:47 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input, kernel, superm1
In-Reply-To: <e1e97842-0ad3-4270-b0d1-3cc7150988cd@collabora.com>
On Tue, Nov 25, 2025 at 04:12:54PM +0500, Muhammad Usama Anjum wrote:
> Hi Greg,
>
> Thank you for the review.
>
> On 11/24/25 10:03 PM, Greg Kroah-Hartman wrote:
> > On Fri, Nov 07, 2025 at 11:44:29PM +0500, Muhammad Usama Anjum wrote:
> >> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
> >> called when power button is pressed. The system is worken up from s2idle
> >> in this case by setting hard parameter to pm_wakeup_dev_event().
> >>
> >> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
> >> is in progress. Set the hard parameter such that pm_system_wakeup()
> >> gets called which increments pm_abort_suspend counter. The explicit call
> >> to acpi_pm_wakeup_event() is necessary as ACPI button device has the
> >> wakeup source. Hence call to input_report_key() with input device
> >> doesn't call pm_system_wakeup() as it doesn't have wakeup source
> >> registered.
> >>
> >> Hence hibernation would be cancelled as in hibernation path, this counter
> >> is checked if it should be aborted.
> >>
> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> >
> My thinking is that people don't press power button after triggering
> hibernation. They will only press power button if they want to cancel the
> hibernation or resume from hibernation a bit later when hibernation completes.
> > This could be dangerous, as this is not what happens today, are you sure
> > that people aren't just used to pressing the button multiple times until
> > the system is hibernated? If so, that would now break with this change
> > as it's hard to determine what is going on.
> Yes, its possible. Previously the device wouldn't cancel hibernation on power
> button press; while now it'll cancel.
>
> So should we put this cancellation under some config option to avoid breaking
> the default behavior?
Do not add another config option, that way lies madness. As proof, what
would your distro select for this, in order to preserve old behavior? :)
> > And why does hibernate take so long? Why not fix that up instead?
> Hibernation is inherently slow: it must freeze devices, copy and
> compress/encrypt memory, then resume storage devices to write the image to
> disk.
>
> While I've thought about increasing the speed, I've no concrete ideas yet.
> The main problem is that its sequential in nature.
Then fix that?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Rafael J. Wysocki @ 2025-11-25 12:25 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <6f1f3210-47c6-4c00-8fb9-35f48bae2581@collabora.com>
On Tue, Nov 25, 2025 at 11:23 AM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> On 11/24/25 11:50 PM, Rafael J. Wysocki wrote:
> > On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> > <usama.anjum@collabora.com> wrote:
> >>
> >> Input (Serio) drivers call input_handle_event(). Although the serio
> >> drivers have duplicate events, they have separate code path and call
> >> input_handle_event(). Ignore the KEY_POWER such that this event isn't
> >> sent to the userspace if hibernation is in progress.
> >
> > Your change affects suspend too.
> >
> > Also, what's the goal you want to achieve?
> Two goals:
> * Don't send event to userspace
> * Set pm_wakeup for hibernation cancellation for non-acpi devices (This api
> call should be tested on non-acpi devices such as arm board to see if it
> helps. I don't have an arm board in hand)
>
> >
> >> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
> >> doesn't have wakeup source registered, this call doesn't do anything.
> >> But there may be other input drivers which will require this.
> >>
> >> Without this, the event is sent to the userspace and it suspends the
> >> device after hibernation cancellation.
> >
> > I think that's because user space handles it this way, isn't it?
>
> Yes, it depends on how userspace handles such events. There are different settings
> configured for systemd-logind when power event is received. The purpose is to consume
> this event to cancel the hibernation without letting userspace know about it.
>
> Thinking more about it, I wasn't sure if all of such events are compulsory to be
> delivered to userspace. But then I found an example: In acpi_button_notify(), all
> such events are not sent to userspace if button is suspended. So it seems okay to
> not send this as well and just consume in the kernel.
You want the given key (and it doesn't matter whether or not this is
KEY_POWER or something else) to play two roles. One of them is to
send a specific key code to user space and let it handle the keypress
as it wants. This is how it works most of the time. The second one
is to wake up the system from sleep (and I'm not sure why you want to
limit this to hibernation) in which case the key code will not be sent
to user space.
For this to work, you need to switch between the two modes quite
precisely and checking things like pm_sleep_transition_in_progress()
(which is only used for debug and its raciness is not relevant there)
is not sufficient for this purpose. That's what the "suspended" flag
in the ACPI button driver is for.
^ permalink raw reply
* Re: [PATCH 4/4] PM: sleep: clear pm_abort_suspend at suspend
From: Rafael J. Wysocki @ 2025-11-25 12:59 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <b71b3e35-fc76-4397-9d60-20778685e37c@collabora.com>
On Tue, Nov 25, 2025 at 10:54 AM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> Hi Rafael,
>
> Thank you for reviewing.
>
> On 11/24/25 11:54 PM, Rafael J. Wysocki wrote:
> > On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> > <usama.anjum@collabora.com> wrote:
> >>
> >> Clear pm_abort_suspend counter in case a wakeup is detected during
> >> hibernation process. If this counter isn't reset, it'll affect the
> >> next hibernation cycle and next time hibernation will not happen as
> >> pm_abort_suspend is still positive.
> >>
> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> >> ---
> >> drivers/base/power/main.c | 2 ++
> >> kernel/cpu.c | 1 +
> >> kernel/power/hibernate.c | 5 ++++-
> >> kernel/power/process.c | 1 +
> >> 4 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> index 5760abb25b591..84e76f8df1e02 100644
> >> --- a/drivers/base/power/main.c
> >> +++ b/drivers/base/power/main.c
> >> @@ -1642,6 +1642,7 @@ static void device_suspend_late(struct device *dev, pm_message_t state, bool asy
> >> goto Complete;
> >>
> >> if (pm_wakeup_pending()) {
> >> + pm_wakeup_clear(0);
> >> WRITE_ONCE(async_error, -EBUSY);
> >> goto Complete;
> >> }
> >> @@ -1887,6 +1888,7 @@ static void device_suspend(struct device *dev, pm_message_t state, bool async)
> >>
> >> if (pm_wakeup_pending()) {
> >> dev->power.direct_complete = false;
> >> + pm_wakeup_clear(0);
> >> WRITE_ONCE(async_error, -EBUSY);
> >> goto Complete;
> >> }
> >> diff --git a/kernel/cpu.c b/kernel/cpu.c
> >> index db9f6c539b28c..74c9f6b4947dd 100644
> >> --- a/kernel/cpu.c
> >> +++ b/kernel/cpu.c
> >> @@ -1921,6 +1921,7 @@ int freeze_secondary_cpus(int primary)
> >>
> >> if (pm_wakeup_pending()) {
> >> pr_info("Wakeup pending. Abort CPU freeze\n");
> >> + pm_wakeup_clear(0);
> >> error = -EBUSY;
> >> break;
> >> }
> >> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> >> index e15907f28c4cd..1f6b60df45d34 100644
> >> --- a/kernel/power/hibernate.c
> >> +++ b/kernel/power/hibernate.c
> >> @@ -349,8 +349,10 @@ static int create_image(int platform_mode)
> >> goto Enable_irqs;
> >> }
> >>
> >> - if (hibernation_test(TEST_CORE) || pm_wakeup_pending())
> >> + if (hibernation_test(TEST_CORE) || pm_wakeup_pending()) {
> >> + pm_wakeup_clear(0);
> >> goto Power_up;
> >> + }
> >>
> >> in_suspend = 1;
> >> save_processor_state();
> >> @@ -660,6 +662,7 @@ int hibernation_platform_enter(void)
> >> goto Enable_irqs;
> >>
> >> if (pm_wakeup_pending()) {
> >> + pm_wakeup_clear(0);
> >> error = -EAGAIN;
> >> goto Power_up;
> >> }
> >> diff --git a/kernel/power/process.c b/kernel/power/process.c
> >> index dc0dfc349f22b..e935b27a04ae0 100644
> >> --- a/kernel/power/process.c
> >> +++ b/kernel/power/process.c
> >> @@ -67,6 +67,7 @@ static int try_to_freeze_tasks(bool user_only)
> >> break;
> >>
> >> if (pm_wakeup_pending()) {
> >> + pm_wakeup_clear(0);
> >> wakeup = true;
> >> break;
> >> }
> >> --
> >
> > I don't think pm_wakeup_clear() needs to be called in so many places.
> >
> > Any why isn't it sufficient to call it in freeze_processes()? For
> > suspend, it is sufficient, so what's different about hibernation in
> > that respect?
>
> It seems this patch was written by me when [1] was added which removed the
> unconditional call pm_wakeup_clear(0) from freeze_processes(). It was later
> reverted [2].
OK, I see.
> I've removed this patch and tested again to find out:
> - try_to_freeze_tasks() gets called from freeze_process() after
> unconditional clearing of pm_wakeup. So pm_wakeup doesn't get cleared
> until next hibernation or any other similar operation. So for hibernation
> cancellation this patch isn't required. I'll drop it.
>
> But shouldn't this wakeup event be consumed without waiting for next hibernation
> (or similar operation to happen)?
I'm not sure what you mean.
Consuming an event is not related to calling pm_wakeup_clear().
pm_wakeup_clear() is related to wakeup IRQ handling, see pm_system_irq_wakeup().
This takes place after IRQs have been suspended (that's what the
"noirq" suspend phase is about).
^ permalink raw reply
* Re: [PATCH v4 2/3] Input: twl4030 - add TWL603x power button
From: Andreas Kemnade @ 2025-11-25 13:01 UTC (permalink / raw)
To: akemnade
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Tony Lindgren, Kevin Hilman, devicetree,
linux-kernel, linux-input, linux-omap
In-Reply-To: <20251106-twl6030-button-v4-2-fdf1aa6e1e9a@kernel.org>
On Thu, 06 Nov 2025 10:00:26 +0100
akemnade@kernel.org wrote:
> From: Andreas Kemnade <andreas@kemnade.info>
>
> Like the TWL4030, these PMICs also have a power button feature, so extend
> the TWL4030 power button driver. As the irqchip of the TWL6030 mfd driver
> does not provide mask, unmask finctions, do it manually.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
a friendly ping
anything still to do here?
Regards,
Andreas
> drivers/input/misc/twl4030-pwrbutton.c | 58 +++++++++++++++++++++++++++++++---
> 1 file changed, 54 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c b/drivers/input/misc/twl4030-pwrbutton.c
> index f85cc289c053..8673b1b441bf 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -20,6 +20,7 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> +#include <linux/bits.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/kernel.h>
> @@ -30,17 +31,31 @@
> #include <linux/platform_device.h>
> #include <linux/mfd/twl.h>
>
> -#define PWR_PWRON_IRQ (1 << 0)
> +#define PWR_PWRON_IRQ BIT(0)
>
> -#define STS_HW_CONDITIONS 0xf
> +struct twl_pwrbutton_chipdata {
> + u8 status_reg;
> + bool need_manual_irq;
> +};
> +
> +static const struct twl_pwrbutton_chipdata twl4030_chipdata = {
> + .status_reg = 0xf,
> + .need_manual_irq = false,
> +};
> +
> +static const struct twl_pwrbutton_chipdata twl6030_chipdata = {
> + .status_reg = 0x2,
> + .need_manual_irq = true,
> +};
>
> static irqreturn_t powerbutton_irq(int irq, void *_pwr)
> {
> struct input_dev *pwr = _pwr;
> + const struct twl_pwrbutton_chipdata *pdata = dev_get_drvdata(pwr->dev.parent);
> int err;
> u8 value;
>
> - err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &value, STS_HW_CONDITIONS);
> + err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &value, pdata->status_reg);
> if (!err) {
> pm_wakeup_event(pwr->dev.parent, 0);
> input_report_key(pwr, KEY_POWER, value & PWR_PWRON_IRQ);
> @@ -55,10 +70,17 @@ static irqreturn_t powerbutton_irq(int irq, void *_pwr)
>
> static int twl4030_pwrbutton_probe(struct platform_device *pdev)
> {
> + const struct twl_pwrbutton_chipdata *pdata;
> struct input_dev *pwr;
> int irq = platform_get_irq(pdev, 0);
> int err;
>
> + pdata = device_get_match_data(&pdev->dev);
> + if (!pdata)
> + return -EINVAL;
> +
> + platform_set_drvdata(pdev, (void *)pdata);
> +
> pwr = devm_input_allocate_device(&pdev->dev);
> if (!pwr) {
> dev_err(&pdev->dev, "Can't allocate power button\n");
> @@ -85,14 +107,41 @@ static int twl4030_pwrbutton_probe(struct platform_device *pdev)
> return err;
> }
>
> + if (pdata->need_manual_irq) {
> + err = twl6030_interrupt_unmask(0x01, REG_INT_MSK_LINE_A);
> + if (err < 0)
> + return err;
> +
> + err = twl6030_interrupt_unmask(0x01, REG_INT_MSK_STS_A);
> + if (err < 0)
> + return err;
> + }
> +
> device_init_wakeup(&pdev->dev, true);
>
> return 0;
> }
>
> +static void twl4030_pwrbutton_remove(struct platform_device *pdev)
> +{
> + const struct twl_pwrbutton_chipdata *pdata = platform_get_drvdata(pdev);
> +
> + if (pdata->need_manual_irq) {
> + twl6030_interrupt_mask(0x01, REG_INT_MSK_LINE_A);
> + twl6030_interrupt_mask(0x01, REG_INT_MSK_STS_A);
> + }
> +}
> +
> #ifdef CONFIG_OF
> static const struct of_device_id twl4030_pwrbutton_dt_match_table[] = {
> - { .compatible = "ti,twl4030-pwrbutton" },
> + {
> + .compatible = "ti,twl4030-pwrbutton",
> + .data = &twl4030_chipdata,
> + },
> + {
> + .compatible = "ti,twl6030-pwrbutton",
> + .data = &twl6030_chipdata,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
> @@ -100,6 +149,7 @@ MODULE_DEVICE_TABLE(of, twl4030_pwrbutton_dt_match_table);
>
> static struct platform_driver twl4030_pwrbutton_driver = {
> .probe = twl4030_pwrbutton_probe,
> + .remove = twl4030_pwrbutton_remove,
> .driver = {
> .name = "twl4030_pwrbutton",
> .of_match_table = of_match_ptr(twl4030_pwrbutton_dt_match_table),
>
^ permalink raw reply
* Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Muhammad Usama Anjum @ 2025-11-25 16:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: usama.anjum, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <CAJZ5v0iDUPB9s2fPJxqVqPGj5wbw54tR4thmDD2V-r4+Q2prwg@mail.gmail.com>
On 11/25/25 5:25 PM, Rafael J. Wysocki wrote:
> On Tue, Nov 25, 2025 at 11:23 AM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
>>
>> On 11/24/25 11:50 PM, Rafael J. Wysocki wrote:
>>> On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
>>> <usama.anjum@collabora.com> wrote:
>>>>
>>>> Input (Serio) drivers call input_handle_event(). Although the serio
>>>> drivers have duplicate events, they have separate code path and call
>>>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>>>> sent to the userspace if hibernation is in progress.
>>>
>>> Your change affects suspend too.
>>>
>>> Also, what's the goal you want to achieve?
>> Two goals:
>> * Don't send event to userspace
>> * Set pm_wakeup for hibernation cancellation for non-acpi devices (This api
>> call should be tested on non-acpi devices such as arm board to see if it
>> helps. I don't have an arm board in hand)
>>
>>>
>>>> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
>>>> doesn't have wakeup source registered, this call doesn't do anything.
>>>> But there may be other input drivers which will require this.
>>>>
>>>> Without this, the event is sent to the userspace and it suspends the
>>>> device after hibernation cancellation.
>>>
>>> I think that's because user space handles it this way, isn't it?
>>
>> Yes, it depends on how userspace handles such events. There are different settings
>> configured for systemd-logind when power event is received. The purpose is to consume
>> this event to cancel the hibernation without letting userspace know about it.
>>
>> Thinking more about it, I wasn't sure if all of such events are compulsory to be
>> delivered to userspace. But then I found an example: In acpi_button_notify(), all
>> such events are not sent to userspace if button is suspended. So it seems okay to
>> not send this as well and just consume in the kernel.
>
> You want the given key (and it doesn't matter whether or not this is
> KEY_POWER or something else) to play two roles. One of them is to
> send a specific key code to user space and let it handle the keypress
> as it wants. This is how it works most of the time. The second one
> is to wake up the system from sleep (and I'm not sure why you want to
> limit this to hibernation) in which case the key code will not be sent
> to user space.
>
> For this to work, you need to switch between the two modes quite
> precisely and checking things like pm_sleep_transition_in_progress()
> (which is only used for debug and its raciness is not relevant there)
> is not sufficient for this purpose. That's what the "suspended" flag
> in the ACPI button driver is for.
I see. I'll add a suspended flag just like the acpi button and use it here.
Thank you so much for explaining.
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Guenter Roeck @ 2025-11-25 16:37 UTC (permalink / raw)
To: H. Nikolaus Schaller, Romain Gantois
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Thomas Petazzoni, linux-kernel, devicetree,
linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi, Peter Rosin,
Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich, Kevin Tsai,
Linus Walleij, Dmitry Torokhov, Eugen Hristev, Vinod Koul,
Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <0E900830-E248-4F0F-A048-075EAF1D2440@goldelico.com>
On 11/25/25 02:25, H. Nikolaus Schaller wrote:
...
> Another suggestion: what extending the "regulator-fixed", "regulator-gpio",
> "regulator-fixed-clock" pattern by some "regulator-gpio-iio-dac-current-limiter"
> driver to make it independent of your specific chip?
>
The name is terrible ;-), but that is what I would have suggested as well.
I don't see anything chip specific in this code. If there is a need for
a regulator driver which uses gpio to enable it and a DAC for current limiting,
it should be made generic.
> By the way, are you aware of this feature of the regulator-gpio driver?
>
> https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/regulator/gpio-regulator.c#L97
>
> Just to note: I am neither maintainer nor doing any decisions on this, just asking
> questions for curiosity and from experience and giving hints for alternative approaches,
> where I hope they help to find the really best solution.
>
Same here.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Muhammad Usama Anjum @ 2025-11-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: usama.anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <2025112506-acting-tipoff-3a49@gregkh>
On 11/25/25 4:47 PM, Greg Kroah-Hartman wrote:
> On Tue, Nov 25, 2025 at 04:12:54PM +0500, Muhammad Usama Anjum wrote:
>> Hi Greg,
>>
>> Thank you for the review.
>>
>> On 11/24/25 10:03 PM, Greg Kroah-Hartman wrote:
>>> On Fri, Nov 07, 2025 at 11:44:29PM +0500, Muhammad Usama Anjum wrote:
>>>> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
>>>> called when power button is pressed. The system is worken up from s2idle
>>>> in this case by setting hard parameter to pm_wakeup_dev_event().
>>>>
>>>> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
>>>> is in progress. Set the hard parameter such that pm_system_wakeup()
>>>> gets called which increments pm_abort_suspend counter. The explicit call
>>>> to acpi_pm_wakeup_event() is necessary as ACPI button device has the
>>>> wakeup source. Hence call to input_report_key() with input device
>>>> doesn't call pm_system_wakeup() as it doesn't have wakeup source
>>>> registered.
>>>>
>>>> Hence hibernation would be cancelled as in hibernation path, this counter
>>>> is checked if it should be aborted.
>>>>
>>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>>>
>> My thinking is that people don't press power button after triggering
>> hibernation. They will only press power button if they want to cancel the
>> hibernation or resume from hibernation a bit later when hibernation completes.
>>> This could be dangerous, as this is not what happens today, are you sure
>>> that people aren't just used to pressing the button multiple times until
>>> the system is hibernated? If so, that would now break with this change
>>> as it's hard to determine what is going on.
>> Yes, its possible. Previously the device wouldn't cancel hibernation on power
>> button press; while now it'll cancel.
>>
>> So should we put this cancellation under some config option to avoid breaking
>> the default behavior?
>
> Do not add another config option, that way lies madness. As proof, what
> would your distro select for this, in order to preserve old behavior? :)
I think, the new behavior would be desirable by most distros. They don't care
about the old behavior. But its just my thinking. What do you think is the way forward?
Even if there are users which used to pressing power button during hibernation,
will not press it after a few tries if they really want the hibernation to complete.
>
>>> And why does hibernate take so long? Why not fix that up instead?
>> Hibernation is inherently slow: it must freeze devices, copy and
>> compress/encrypt memory, then resume storage devices to write the image to
>> disk.
>>
>> While I've thought about increasing the speed, I've no concrete ideas yet.
>> The main problem is that its sequential in nature.
>
> Then fix that?
That's in the plan. But who knows when we get time to attempt that.
First I need a board/machine with serial console access to view all logs in real
time. :)
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH 1/4] PM: hibernate: export pm_sleep_transition_in_progress()
From: Muhammad Usama Anjum @ 2025-11-25 16:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: usama.anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <2025112423-rocking-deafness-88c0@gregkh>
On 11/24/25 10:01 PM, Greg Kroah-Hartman wrote:
> On Fri, Nov 07, 2025 at 11:44:28PM +0500, Muhammad Usama Anjum wrote:
>> Export pm_sleep_transition_in_progress() to be used by other
>> modules.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>> ---
>> kernel/power/main.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/power/main.c b/kernel/power/main.c
>> index 33a47ed15994f..ff3354b5be150 100644
>> --- a/kernel/power/main.c
>> +++ b/kernel/power/main.c
>> @@ -570,6 +570,7 @@ bool pm_sleep_transition_in_progress(void)
>> {
>> return pm_suspend_in_progress() || hibernation_in_progress();
>> }
>> +EXPORT_SYMBOL_GPL(pm_sleep_transition_in_progress);
>
> The problem is, you can not rely on the result of this call as it could
> change right after you call it, right?
>
> So who needs to call this and why? What new workflow requires this?
Yeah, Rafael just mentioned as well that this API isn't dependable. I need
to use better flag for detecting if driver is suspended. I'm testing if
suspended flag in ACPI button driver is enough and similar flag can be added
in input driver.
>
> thanks,
>
> greg k-h
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v3] HID: memory leak in dualshock4_get_calibration_data
From: Eslam Khafagy @ 2025-11-25 18:19 UTC (permalink / raw)
To: Max Staudt, Jiri Slaby, roderick.colenbrander, jikos, bentiss
Cc: linux-input, linux-kernel, syzbot+4f5f81e1456a1f645bf8, stable
In-Reply-To: <44eb6401-e021-4c69-96af-0554f4f31e57@enpas.org>
On 11/24/25 16:06, Max Staudt wrote:
> On 11/24/25 3:32 PM, Jiri Slaby wrote:
>> Isn't this fixed already by:
>> commit 8513c154f8ad7097653dd9bf43d6155e5aad4ab3
>> Author: Abdun Nihaal <nihaal@cse.iitm.ac.in>
>> Date: Mon Nov 10 22:45:50 2025 +0530
>>
>> HID: playstation: Fix memory leak in
>> dualshock4_get_calibration_data()
>> ?
>
> As far as I can see, that patch does indeed fix the same issue, and it
> is already upstream.
>
> Thanks for the hint - Abdun's patch has been upstreamed quite
> recently, hence I guess Eslam missed it by accident. But maybe I'm
> wrong and Eslam can chime in himself?
Thank's Max & Jiri,
sorry i was sick the past couple of days i missed your replies.
yes. that patch fixes it. I guess i missed it because it wasn't merged
yet when i submitted v1.
So please ignore this patch.
>
>
>> Anyway, this is a typical use-case for __free(). Why not to use that?
>
> Wow, there's been a lot of interesting stuff happening around
> cleanup.h. I've been out of the kernel for too long, this looks like
> fun. Thanks for pointing it out :)
>
>
> Max
Lastly, One question to max,
at the beginning of the function dualshock4_get_calibration_data
buf = kzalloc(DS4_FEATURE_REPORT_CALIBRATION_SIZE, GFP_KERNEL); if
(!buf) { ret = -ENOMEM; goto transfer_failed; }
if the allocation fails. can't we just return here . or do we need to go
the the end of the function and do sanity checks at the end?
^ permalink raw reply
* Notice of code provenance, change
From: Christopher Snowhill @ 2025-11-25 22:20 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, Vicki Pfau, Pavel Rojtberg, Antheas Kapenekakis,
Nilton Perim Neto, Mario Limonciello, Pierre-Loup A. Griffais
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
In 2011, I authored and committed
b514d4f7c6506b696d7de6a4426d0886753e43c9, under my preferred name at the
time, "Chris Moeller", which is my stepdad's surname. I had been using
it until 1999 or so for school, but in 1999, I had to get my state ID
card, which was under my legal name, which I am sending this email from.
There are a number of reasons I won't get into in this message as to why
I never had it legally changed, or why I ended up switching to my legal
name at some point. Maybe a matter of pride or whatever.
I also accidentally typoed the email domain as "gmail.c", and then years
later, I discovered that several list messages were misdirected at that
incorrect address. Whoops.
Anyway, even if it is too late to change the commit history, I am now
signing off that commit again:
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Signed-off-by: Christopher Snowhill <chris@kode54.net>
I'm also including my other primary email address here, in case it is
useful to anyone on the project. I still have the hardware somewhere,
but I'm not really equipped to perform tests or maintenance with it, and
I haven't acquired any newer Xbox hardware in the same class since. I
now have an Xbox Series X|S wireless controller, but that's an entirely
different class of hardware, covered by other drivers.
I already tried to draft an email once, and my client ate it, because it
didn't save the draft, and I hadn't properly configured oama for OAuth2
sending yet. Let's see if I get an error this time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Greg Kroah-Hartman @ 2025-11-26 7:38 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input, kernel, superm1
In-Reply-To: <cef1d96b-b642-4e69-8c1b-2e0bf7528edf@collabora.com>
On Tue, Nov 25, 2025 at 09:41:22PM +0500, Muhammad Usama Anjum wrote:
> >> While I've thought about increasing the speed, I've no concrete ideas yet.
> >> The main problem is that its sequential in nature.
> >
> > Then fix that?
> That's in the plan. But who knows when we get time to attempt that.
Take the time to fix this properly first, don't paper over the issue by
changing user/system interactions that will not be needed in the future
when the real problem is resolved.
> First I need a board/machine with serial console access to view all logs in real
> time. :)
usb debug cables might be your solution.
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Mario Limonciello @ 2025-11-26 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input, kernel, Askar Safin
In-Reply-To: <2025112612-backup-driving-e6e6@gregkh>
>> First I need a board/machine with serial console access to view all logs in real
>> time. :)
>
> usb debug cables might be your solution.
>
Just a word of warning before you go too far down this path to get a
console working from XHCI debug.
This is probably a Hal changing a light bulb problem [1]. Last time I
tried XHCI debug cables on some modern AMD systems I ran into a problem
that the BAR is too big for early_ioremap(). Looking through LKML it's
come up a few times in the past too [2] [3].
Link: https://youtu.be/5W4NFcamRhM?si=qOFrCTzvK6-H-4AX [1]
Link: https://lore.kernel.org/linux-usb/ZCOq3PUBCtHkwdnw@mail-itl/ [2]
Link:
https://lore.kernel.org/linux-usb/CAAcb1K_bezseTM8DrOrzVUi_W+nZoE2N0CO4k3AQWPw7=7pyjw@mail.gmail.com/
[3]
The other obvious idea is to use netconsole, but you need a PCIe
Ethernet controller, but I think you'll have more success in development
using KVM as these are generic architectural problems.
To help you get started with this I may point out something that was
shared to me for another hibernate bug [4].
Link:
https://lore.kernel.org/linux-pm/20251105180506.137448-1-safinaskar@gmail.com/
[4]
Askar Safin (CC'ed) produced a script that does a very minimal kernel
build, sets up a VM with the right sizes of disks/swap/etc. It's
trivial to make kernel changes and re-run the script, and you can also
attach a debugger to the KVM instance. Maybe you can adapt something
like that. You can wrap it with 'time' calls to actually measure
performance for any ideas and prove them out too.
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Muhammad Usama Anjum @ 2025-11-26 13:26 UTC (permalink / raw)
To: Mario Limonciello, Greg Kroah-Hartman
Cc: usama.anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, Askar Safin
In-Reply-To: <92de74fb-fc75-4260-bb1d-2d6dd522183f@kernel.org>
On 11/26/25 5:55 PM, Mario Limonciello wrote:
>>> First I need a board/machine with serial console access to view all logs in real
>>> time. :)
>>
>> usb debug cables might be your solution.
>>
> Just a word of warning before you go too far down this path to get a console working from XHCI debug.
>
> This is probably a Hal changing a light bulb problem [1]. Last time I tried XHCI debug cables on some modern AMD systems I ran into a problem that the BAR is too big for early_ioremap(). Looking through LKML it's come up a few times in the past too [2] [3].
>
> Link: https://youtu.be/5W4NFcamRhM?si=qOFrCTzvK6-H-4AX [1]
> Link: https://lore.kernel.org/linux-usb/ZCOq3PUBCtHkwdnw@mail-itl/ [2]
> Link: https://lore.kernel.org/linux-usb/CAAcb1K_bezseTM8DrOrzVUi_W+nZoE2N0CO4k3AQWPw7=7pyjw@mail.gmail.com/ [3]
>
> The other obvious idea is to use netconsole, but you need a PCIe Ethernet controller, but I think you'll have more success in development using KVM as these are generic architectural problems.
>
> To help you get started with this I may point out something that was shared to me for another hibernate bug [4].
>
> Link: https://lore.kernel.org/linux-pm/20251105180506.137448-1-safinaskar@gmail.com/ [4]
>
> Askar Safin (CC'ed) produced a script that does a very minimal kernel build, sets up a VM with the right sizes of disks/swap/etc. It's trivial to make kernel changes and re-run the script, and you can also attach a debugger to the KVM instance. Maybe you can adapt something like that. You can wrap it with 'time' calls to actually measure performance for any ideas and prove them out too.
I was just going to try it. Thank you so much for double confirming. I'll
test and see.
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Antheas Kapenekakis @ 2025-11-26 13:37 UTC (permalink / raw)
To: platform-driver-x86, linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires, Corentin Chary,
Luke D . Jones, Hans de Goede, Ilpo Järvinen, Denis Benato
In-Reply-To: <20251122110032.4274-1-lkml@antheas.dev>
On Sat, 22 Nov 2025 at 12:01, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> This is a two part series which does the following:
> - Clean-up init sequence
> - Unify backlight handling to happen under asus-wmi so that all Aura
> devices have synced brightness controls and the backlight button works
> properly when it is on a USB laptop keyboard instead of one w/ WMI.
>
> For more context, see cover letter of V1. Since V5, I removed some patches
> to make this easier to merge.
Slight bump on this. It addresses both of the remarks Denis made in
the previous version.
I begrudgingly argued a bit for those because I did not want to resend
the series and they were not functional changes, so sorry about that.
But they are fixed in this version incl. with the conflict with the
armoury patchset. Denis, you omitted a rby on "platform/x86: asus-wmi:
Add support for multiple kbd led handlers" even though I addressed
your comment, so you may want to add that.
As for "HID: asus: early return for ROG devices" changing the name of
the devices of this driver, I will veto backporting it if it happens,
so inputplumber will have the two full months to remove the name
match. This is not a breaking change in the sense that software cannot
be made to work on both previous and latter versions and there is no
other software to my knowledge relying on name matches for Asus
keyboards. Moreover, an early exit is needed to prevent ejecting HID
endpoints without an ->input parameter so it is a needed fix anyway.
Postponing it will prevent Xbox Ally users from having RGB control
through userspace on a stock kernel but it is also not worth arguing
about
It is also fine for me for this series to merge for 6.20, but I'd
rather we handle it now since there will be some turbulence for asus
users due to armoury merging so it makes sense to have this transition
once.
Antheas
> ---
> V9: https://lore.kernel.org/all/20251120094617.11672-1-lkml@antheas.dev/
> V8: https://lore.kernel.org/all/20251101104712.8011-1-lkml@antheas.dev/
> V7: https://lore.kernel.org/all/20251018101759.4089-1-lkml@antheas.dev/
> V6: https://lore.kernel.org/all/20251013201535.6737-1-lkml@antheas.dev/
> V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
>
> Changes since V9:
> - No functional changes
> - Rebase to review-ilpo-next
> - Fix armoury series conflict by removing the file asus-wmi-leds-ids on
> "remove unused keyboard backlight quirk" + imports
> Dismiss Luke's review as this patch diverged
> - Reword paragraph in "Add support for multiple kbd led handlers" to be
> more verbose
> - Use kfree in fortify patch
> - Fix minor style quirks from --nonstict checkpatch run
>
> Changes since V8:
> - No functional changes
> - Move legacy init patch to second, modify first patch so that their
> diff is minimized
> - Split "prevent binding to all HID devices on ROG" into two patches:
> - moving backlight initialization into probe
> - early exit to skip ->init check and rename
> - Remove skipping vendor fixups for non-vendor devices. It is not possible
> to read usages before the report fixups are applied, so it did not work
> - In that patch, reword a comment to be single line and make is_vendor a bool
> - Dismiss Luke's tags from "Add support for multiple kbd led handlers" as it
> has drifted too far since he reviewed/tested it.
>
> Changes since V7:
> - Readd legacy init quirk for Dennis
> - Remove HID_QUIRK_INPUT_PER_APP as a courtesy to asusctl
> - Fix warning due to enum_backlight receiving negative values
>
> Changes since V6:
> - Split initialization refactor into three patches, update commit text
> to be clearer in what it does
> - Replace spinlock accesses with guard and scoped guard in all patches
> - Add missing includes mentioned by Ilpo
> - Reflow, tweak comment in prevent binding to all HID devices on ROG
> - Replace asus_ref.asus with local reference in all patches
> - Add missing kernel doc comments
> - Other minor nits from Ilpo
> - User reported warning due to scheduling work while holding a spinlock.
> Restructure patch for multiple handlers to limit when spinlock is held to
> variable access only. In parallel, setup a workqueue to handle registration
> of led device and setting brightness. This is required as registering the
> led device triggers kbd_led_get which needs to hold the spinlock to
> protect the led_wk value. The workqueue is also required for the hid
> event passthrough to avoid scheduling work while holding the spinlock.
> Apply the workqueue to wmi brightness buttons as well, as that was
> omitted before this series and WMI access was performed.
> - On "HID: asus: prevent binding to all HID devices on ROG", rename
> quirk HANDLE_GENERIC to SKIP_REPORT_FIXUP and only skip report fixup.
> This allows other quirks to apply (applies quirk that fixes keyboard
> being named as a pointer device).
>
> Changes since V5:
> - It's been a long time
> - Remove addition of RGB as that had some comments I need to work on
> - Remove folio patch (already merged)
> - Remove legacy fix patch 11 from V4. There is a small chance that
> without this patch, some old NKEY keyboards might not respond to
> RGB commands according to Luke, but the kernel driver does not do
> RGB currently. The 0x5d init is done by Armoury crate software in
> Windows. If an issue is found, we can re-add it or just remove patches
> 1/2 before merging. However, init could use the cleanup.
>
> Changes since V4:
> - Fix KConfig (reported by kernel robot)
> - Fix Ilpo's nits, if I missed anything lmk
>
> Changes since V3:
> - Add initializer for 0x5d for old NKEY keyboards until it is verified
> that it is not needed for their media keys to function.
> - Cover init in asus-wmi with spinlock as per Hans
> - If asus-wmi registers WMI handler with brightness, init the brightness
> in USB Asus keyboards, per Hans.
> - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> - Fix oops when unregistering asus-wmi by moving unregister outside of
> the spin lock (but after the asus reference is set to null)
>
> Changes since V2:
> - Check lazy init succeds in asus-wmi before setting register variable
> - make explicit check in asus_hid_register_listener for listener existing
> to avoid re-init
> - rename asus_brt to asus_hid in most places and harmonize everything
> - switch to a spinlock instead of a mutex to avoid kernel ooops
> - fixup hid device quirks to avoid multiple RGB devices while still exposing
> all input vendor devices. This includes moving rgb init to probe
> instead of the input_configured callbacks.
> - Remove fan key (during retest it appears to be 0xae that is already
> supported by hid-asus)
> - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> - removes fds from userspace and breaks backlight functionality. All
> - current mainline drivers do not support backlight hotplugging, so most
> userspace software (e.g., KDE, UPower) is built with that assumption.
> For the Ally, since it disconnects its controller during sleep, this
> caused the backlight slider to not work in KDE.
>
> Changes since V1:
> - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> - Fix ifdef else having an invalid signature (reported by kernel robot)
> - Restore input arguments to init and keyboard function so they can
> be re-used for RGB controls.
> - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> keyboard rename into it.
> - Unregister brightness listener before removing work queue to avoid
> a race condition causing corruption
> - Remove spurious mutex unlock in asus_brt_event
> - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> relocking the mutex and causing a deadlock when unregistering leds
> - Add extra check during unregistering to avoid calling unregister when
> no led device is registered.
> - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> the driver to create 4 RGB handlers per device. I also suspect some
> extra events sneak through (KDE had the @@@@@@).
>
> Antheas Kapenekakis (11):
> HID: asus: simplify RGB init sequence
> HID: asus: initialize additional endpoints only for legacy devices
> HID: asus: use same report_id in response
> HID: asus: fortify keyboard handshake
> HID: asus: move vendor initialization to probe
> HID: asus: early return for ROG devices
> platform/x86: asus-wmi: Add support for multiple kbd led handlers
> HID: asus: listen to the asus-wmi brightness device instead of
> creating one
> platform/x86: asus-wmi: remove unused keyboard backlight quirk
> platform/x86: asus-wmi: add keyboard brightness event handler
> HID: asus: add support for the asus-wmi brightness handler
>
> drivers/hid/hid-asus.c | 205 ++++++++--------
> drivers/platform/x86/asus-wmi.c | 223 +++++++++++++++---
> .../platform_data/x86/asus-wmi-leds-ids.h | 50 ----
> include/linux/platform_data/x86/asus-wmi.h | 28 +++
> 4 files changed, 322 insertions(+), 184 deletions(-)
> delete mode 100644 include/linux/platform_data/x86/asus-wmi-leds-ids.h
>
>
> base-commit: 2643187ccb8628144246ee9d44da5e3ac428f9c3
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Muhammad Usama Anjum @ 2025-11-26 13:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: usama.anjum, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <2025112612-backup-driving-e6e6@gregkh>
On 11/26/25 12:38 PM, Greg Kroah-Hartman wrote:
> On Tue, Nov 25, 2025 at 09:41:22PM +0500, Muhammad Usama Anjum wrote:
>>>> While I've thought about increasing the speed, I've no concrete ideas yet.
>>>> The main problem is that its sequential in nature.
>>>
>>> Then fix that?
>> That's in the plan. But who knows when we get time to attempt that.
>
> Take the time to fix this properly first, don't paper over the issue by
> changing user/system interactions that will not be needed in the future
> when the real problem is resolved.
You're absolutely right, and I share the same philosophy.
However, I think the hibernation cancellation feature has standalone value
regardless of how much we optimize hibernation time. Even if we achieve
significant improvements (5-30% or more), there will still be scenarios where
users want to abort an in-progress hibernation.
I'm focusing on making this series more concise for next revision.
>
>> First I need a board/machine with serial console access to view all logs in real
>> time. :)
>
> usb debug cables might be your solution.
>
> good luck!
>
> greg k-h
--
---
Thanks,
Usama
^ permalink raw reply
* [PATCH] Input: misc: pwm-vibra: fix resource leaks on start failure
From: Haotian Zhang @ 2025-11-26 14:56 UTC (permalink / raw)
To: sebastian.reichel, dmitry.torokhov
Cc: linux-input, linux-kernel, Haotian Zhang
The pwm_vibrator_start() function returns immediately if
pwm_apply_might_sleep() fails, neglecting to disable the
regulator or reset the enable GPIO. This results in a
potential resource leak.
Introduce a local flag to track regulator enablement
and implement an error handling path. Deassert the enable
GPIO and disable the regulator upon failure.
Fixes: 3e5b08518f6a ("Input: add a driver for PWM controllable vibrators")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
---
drivers/input/misc/pwm-vibra.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index 3e5ed685ed8f..d323a12596c3 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -40,6 +40,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
struct device *pdev = vibrator->input->dev.parent;
struct pwm_state state;
int err;
+ bool new_vcc_on = false;
if (!vibrator->vcc_on) {
err = regulator_enable(vibrator->vcc);
@@ -48,6 +49,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
return err;
}
vibrator->vcc_on = true;
+ new_vcc_on = true;
}
gpiod_set_value_cansleep(vibrator->enable_gpio, 1);
@@ -59,7 +61,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
err = pwm_apply_might_sleep(vibrator->pwm, &state);
if (err) {
dev_err(pdev, "failed to apply pwm state: %d\n", err);
- return err;
+ goto err_gpio;
}
if (vibrator->pwm_dir) {
@@ -71,11 +73,19 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
if (err) {
dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
pwm_disable(vibrator->pwm);
- return err;
+ goto err_gpio;
}
}
return 0;
+
+err_gpio:
+ gpiod_set_value_cansleep(vibrator->enable_gpio, 0);
+ if (new_vcc_on) {
+ regulator_disable(vibrator->vcc);
+ vibrator->vcc_on = false;
+ }
+ return err;
}
static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
--
2.50.1.windows.1
^ permalink raw reply related
* Re: [PATCH] HID: logitech-dj: Add support for G Pro X Superlight 2 receiver
From: Jiri Kosina @ 2025-11-26 15:14 UTC (permalink / raw)
To: Nathan Rossi
Cc: Benjamin Tissoires, linux-input, linux-kernel, Filipe Laíns
In-Reply-To: <20251108141300.3402380-1-nathan@nathanrossi.com>
On Sat, 8 Nov 2025, Nathan Rossi wrote:
> The Logitech G Pro X Superlight 2 has a lightspeed receiver with a
> product id of 0xc54d, this receiver behaves like the receiver used in
> the original Logitech G Pro X Superlight (id 0xc547) including the 13
> byte mouse reports.
>
> This change adds a definition for this receiver id, and a mapping for
> the recvr_type_gaming_hidpp_ls_1_3 type. With this change in place the
> receiver now reports the battery status of the connected mouse over
> wireless as well as exposing the HID interface needed for userspace to
> perform additional configuration with libratbag/Piper.
>
> Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: logitech-dj: Remove duplicate error logging
From: Jiri Kosina @ 2025-11-26 15:17 UTC (permalink / raw)
To: Hans de Goede; +Cc: Filipe Laíns, Benjamin Tissoires, linux-input, stable
In-Reply-To: <20251108210319.7125-1-johannes.goede@oss.qualcomm.com>
On Sat, 8 Nov 2025, Hans de Goede wrote:
> logi_dj_recv_query_paired_devices() and logi_dj_recv_switch_to_dj_mode()
> both have 2 callers which all log an error if the function fails. Move
> the error logging to inside these 2 functions to remove the duplicated
> error logging in the callers.
>
> While at it also move the logi_dj_recv_send_report() call error handling
> in logi_dj_recv_switch_to_dj_mode() to directly after the call. That call
> only fails if the report cannot be found and in that case it does nothing,
> so the msleep() is not necessary on failures.
>
> Fixes: 6f20d3261265 ("HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Both applied to hid.git#for-6.18/upstream-fixes, thanks Hans.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Ilpo Järvinen @ 2025-11-26 15:23 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
In-Reply-To: <CAGwozwGwkBH_03JvPQrevQiszwDZ5R4uDBnzWVeVXLo8xRmeug@mail.gmail.com>
On Wed, 26 Nov 2025, Antheas Kapenekakis wrote:
> On Sat, 22 Nov 2025 at 12:01, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> >
> > This is a two part series which does the following:
> > - Clean-up init sequence
> > - Unify backlight handling to happen under asus-wmi so that all Aura
> > devices have synced brightness controls and the backlight button works
> > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> >
> > For more context, see cover letter of V1. Since V5, I removed some patches
> > to make this easier to merge.
>
> Slight bump on this. It addresses both of the remarks Denis made in
> the previous version.
>
> I begrudgingly argued a bit for those because I did not want to resend
> the series and they were not functional changes, so sorry about that.
> But they are fixed in this version incl. with the conflict with the
> armoury patchset. Denis, you omitted a rby on "platform/x86: asus-wmi:
> Add support for multiple kbd led handlers" even though I addressed
> your comment, so you may want to add that.
FYI, there's no direct relation that mandates a person to give a rev-by
even if all his/her comments were addressed.
But generally yes, it would be useful to hear whether Denis is fine with
v10, especially those patches that had contention earlier but you've
modified post-v8.
> As for "HID: asus: early return for ROG devices" changing the name of
> the devices of this driver, I will veto backporting it if it happens,
> so inputplumber will have the two full months to remove the name
> match. This is not a breaking change in the sense that software cannot
> be made to work on both previous and latter versions and there is no
> other software to my knowledge relying on name matches for Asus
> keyboards.
Did Hans give some opinion about this rename earlier, at least I don't
remember nor could find from lore archives?
--
i.
> Moreover, an early exit is needed to prevent ejecting HID
> endpoints without an ->input parameter so it is a needed fix anyway.
> Postponing it will prevent Xbox Ally users from having RGB control
> through userspace on a stock kernel but it is also not worth arguing
> about
>
> It is also fine for me for this series to merge for 6.20, but I'd
> rather we handle it now since there will be some turbulence for asus
> users due to armoury merging so it makes sense to have this transition
> once.
>
> > ---
> > V9: https://lore.kernel.org/all/20251120094617.11672-1-lkml@antheas.dev/
> > V8: https://lore.kernel.org/all/20251101104712.8011-1-lkml@antheas.dev/
> > V7: https://lore.kernel.org/all/20251018101759.4089-1-lkml@antheas.dev/
> > V6: https://lore.kernel.org/all/20251013201535.6737-1-lkml@antheas.dev/
> > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> >
> > Changes since V9:
> > - No functional changes
> > - Rebase to review-ilpo-next
> > - Fix armoury series conflict by removing the file asus-wmi-leds-ids on
> > "remove unused keyboard backlight quirk" + imports
> > Dismiss Luke's review as this patch diverged
> > - Reword paragraph in "Add support for multiple kbd led handlers" to be
> > more verbose
> > - Use kfree in fortify patch
> > - Fix minor style quirks from --nonstict checkpatch run
> >
> > Changes since V8:
> > - No functional changes
> > - Move legacy init patch to second, modify first patch so that their
> > diff is minimized
> > - Split "prevent binding to all HID devices on ROG" into two patches:
> > - moving backlight initialization into probe
> > - early exit to skip ->init check and rename
> > - Remove skipping vendor fixups for non-vendor devices. It is not possible
> > to read usages before the report fixups are applied, so it did not work
> > - In that patch, reword a comment to be single line and make is_vendor a bool
> > - Dismiss Luke's tags from "Add support for multiple kbd led handlers" as it
> > has drifted too far since he reviewed/tested it.
> >
> > Changes since V7:
> > - Readd legacy init quirk for Dennis
> > - Remove HID_QUIRK_INPUT_PER_APP as a courtesy to asusctl
> > - Fix warning due to enum_backlight receiving negative values
> >
> > Changes since V6:
> > - Split initialization refactor into three patches, update commit text
> > to be clearer in what it does
> > - Replace spinlock accesses with guard and scoped guard in all patches
> > - Add missing includes mentioned by Ilpo
> > - Reflow, tweak comment in prevent binding to all HID devices on ROG
> > - Replace asus_ref.asus with local reference in all patches
> > - Add missing kernel doc comments
> > - Other minor nits from Ilpo
> > - User reported warning due to scheduling work while holding a spinlock.
> > Restructure patch for multiple handlers to limit when spinlock is held to
> > variable access only. In parallel, setup a workqueue to handle registration
> > of led device and setting brightness. This is required as registering the
> > led device triggers kbd_led_get which needs to hold the spinlock to
> > protect the led_wk value. The workqueue is also required for the hid
> > event passthrough to avoid scheduling work while holding the spinlock.
> > Apply the workqueue to wmi brightness buttons as well, as that was
> > omitted before this series and WMI access was performed.
> > - On "HID: asus: prevent binding to all HID devices on ROG", rename
> > quirk HANDLE_GENERIC to SKIP_REPORT_FIXUP and only skip report fixup.
> > This allows other quirks to apply (applies quirk that fixes keyboard
> > being named as a pointer device).
> >
> > Changes since V5:
> > - It's been a long time
> > - Remove addition of RGB as that had some comments I need to work on
> > - Remove folio patch (already merged)
> > - Remove legacy fix patch 11 from V4. There is a small chance that
> > without this patch, some old NKEY keyboards might not respond to
> > RGB commands according to Luke, but the kernel driver does not do
> > RGB currently. The 0x5d init is done by Armoury crate software in
> > Windows. If an issue is found, we can re-add it or just remove patches
> > 1/2 before merging. However, init could use the cleanup.
> >
> > Changes since V4:
> > - Fix KConfig (reported by kernel robot)
> > - Fix Ilpo's nits, if I missed anything lmk
> >
> > Changes since V3:
> > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > that it is not needed for their media keys to function.
> > - Cover init in asus-wmi with spinlock as per Hans
> > - If asus-wmi registers WMI handler with brightness, init the brightness
> > in USB Asus keyboards, per Hans.
> > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > the spin lock (but after the asus reference is set to null)
> >
> > Changes since V2:
> > - Check lazy init succeds in asus-wmi before setting register variable
> > - make explicit check in asus_hid_register_listener for listener existing
> > to avoid re-init
> > - rename asus_brt to asus_hid in most places and harmonize everything
> > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > all input vendor devices. This includes moving rgb init to probe
> > instead of the input_configured callbacks.
> > - Remove fan key (during retest it appears to be 0xae that is already
> > supported by hid-asus)
> > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > - removes fds from userspace and breaks backlight functionality. All
> > - current mainline drivers do not support backlight hotplugging, so most
> > userspace software (e.g., KDE, UPower) is built with that assumption.
> > For the Ally, since it disconnects its controller during sleep, this
> > caused the backlight slider to not work in KDE.
> >
> > Changes since V1:
> > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > - Restore input arguments to init and keyboard function so they can
> > be re-used for RGB controls.
> > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > keyboard rename into it.
> > - Unregister brightness listener before removing work queue to avoid
> > a race condition causing corruption
> > - Remove spurious mutex unlock in asus_brt_event
> > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > relocking the mutex and causing a deadlock when unregistering leds
> > - Add extra check during unregistering to avoid calling unregister when
> > no led device is registered.
> > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > the driver to create 4 RGB handlers per device. I also suspect some
> > extra events sneak through (KDE had the @@@@@@).
> >
> > Antheas Kapenekakis (11):
> > HID: asus: simplify RGB init sequence
> > HID: asus: initialize additional endpoints only for legacy devices
> > HID: asus: use same report_id in response
> > HID: asus: fortify keyboard handshake
> > HID: asus: move vendor initialization to probe
> > HID: asus: early return for ROG devices
> > platform/x86: asus-wmi: Add support for multiple kbd led handlers
> > HID: asus: listen to the asus-wmi brightness device instead of
> > creating one
> > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > platform/x86: asus-wmi: add keyboard brightness event handler
> > HID: asus: add support for the asus-wmi brightness handler
> >
> > drivers/hid/hid-asus.c | 205 ++++++++--------
> > drivers/platform/x86/asus-wmi.c | 223 +++++++++++++++---
> > .../platform_data/x86/asus-wmi-leds-ids.h | 50 ----
> > include/linux/platform_data/x86/asus-wmi.h | 28 +++
> > 4 files changed, 322 insertions(+), 184 deletions(-)
> > delete mode 100644 include/linux/platform_data/x86/asus-wmi-leds-ids.h
> >
> >
> > base-commit: 2643187ccb8628144246ee9d44da5e3ac428f9c3
> > --
> > 2.52.0
> >
> >
>
^ permalink raw reply
* Re: [PATCH] HID: playstation: Add missing check for input_ff_create_memless
From: Jiri Kosina @ 2025-11-26 15:23 UTC (permalink / raw)
To: Haotian Zhang; +Cc: roderick.colenbrander, bentiss, linux-input, linux-kernel
In-Reply-To: <20251117082808.1492-1-vulab@iscas.ac.cn>
On Mon, 17 Nov 2025, Haotian Zhang wrote:
> The ps_gamepad_create() function calls input_ff_create_memless()
> without verifying its return value, which can lead to incorrect
> behavior or potential crashes when FF effects are triggered.
>
> Add a check for the return value of input_ff_create_memless().
>
> Fixes: 51151098d7ab ("HID: playstation: add DualSense classic rumble support.")
> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
> ---
> drivers/hid/hid-playstation.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
> index 63f6eb9030d1..aea8d6cf46a2 100644
> --- a/drivers/hid/hid-playstation.c
> +++ b/drivers/hid/hid-playstation.c
> @@ -769,7 +769,9 @@ ps_gamepad_create(struct hid_device *hdev,
> #if IS_ENABLED(CONFIG_PLAYSTATION_FF)
> if (play_effect) {
> input_set_capability(gamepad, EV_FF, FF_RUMBLE);
> - input_ff_create_memless(gamepad, NULL, play_effect);
> + ret = input_ff_create_memless(gamepad, NULL, play_effect);
> + if (ret)
> + return ERR_PTR(ret);
I am not deeply versed in this particular driver's code, but don't you
leak input_dev allocated by ps_allocate_input_dev() here?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: add quirks for Lenovo Yoga Book 9i
From: Jiri Kosina @ 2025-11-26 15:26 UTC (permalink / raw)
To: Brian Howard
Cc: Andrei Shumailov, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20251118020723.6600-1-blhoward2@gmail.com>
On Mon, 17 Nov 2025, Brian Howard wrote:
> Add required quirks for Lenovo Yoga Book 9i Gen 8 to Gen 10 models,
> including a new quirk providing for custom input device naming and
> dropping erroneous InRange reports.
>
> The Lenovo Yoga Book 9i is a dual-screen laptop, with a single composite
> USB device providing both touch and tablet interfaces for both screens.
> All inputs report through a single device, differentiated solely by report
> numbers. As there is no way for udev to differentiate the inputs based on
> USB vendor/product ID or interface numbers, custom naming is required to
> match against for downstream configuration. A firmware bug also results
> in an erroneous InRange message report (with everything other than X/Y
> as 0) being received after the stylus leaves proximity, blocking later
> touch events.
>
> Signed-off-by: Brian Howard <blhoward2@gmail.com>
> Tested-by: Brian Howard <blhoward2@gmail.com>
> Reported-by: Andrei Shumailov <gentoo1993@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220386
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-multitouch.c | 73 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 0723b4b1c9ec..e896a6310bb2 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -833,6 +833,7 @@
> #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5
> #define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe
> #define USB_DEVICE_ID_LENOVO_X12_TAB2 0x61ae
> +#define USB_DEVICE_ID_LENOVO_YOGABOOK9I 0x6161
> #define USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E 0x600e
> #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d
> #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 179dc316b4b5..a828aac59cb2 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -76,6 +76,7 @@ MODULE_LICENSE("GPL");
> #define MT_QUIRK_DISABLE_WAKEUP BIT(21)
> #define MT_QUIRK_ORIENTATION_INVERT BIT(22)
> #define MT_QUIRK_APPLE_TOUCHBAR BIT(23)
> +#define MT_QUIRK_YOGABOOK9I BIT(24)
>
> #define MT_INPUTMODE_TOUCHSCREEN 0x02
> #define MT_INPUTMODE_TOUCHPAD 0x03
> @@ -229,6 +230,7 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app);
> #define MT_CLS_RAZER_BLADE_STEALTH 0x0112
> #define MT_CLS_SMART_TECH 0x0113
> #define MT_CLS_APPLE_TOUCHBAR 0x0114
> +#define MT_CLS_YOGABOOK9I 0x0115
> #define MT_CLS_SIS 0x0457
>
> #define MT_DEFAULT_MAXCONTACT 10
> @@ -424,6 +426,14 @@ static const struct mt_class mt_classes[] = {
> .quirks = MT_QUIRK_NOT_SEEN_MEANS_UP |
> MT_QUIRK_ALWAYS_VALID |
> MT_QUIRK_CONTACT_CNT_ACCURATE,
> + },
> + { .name = MT_CLS_YOGABOOK9I,
> + .quirks = MT_QUIRK_ALWAYS_VALID |
> + MT_QUIRK_FORCE_MULTI_INPUT |
> + MT_QUIRK_SEPARATE_APP_REPORT |
> + MT_QUIRK_HOVERING |
> + MT_QUIRK_YOGABOOK9I,
> + .export_all_inputs = true
> },
> { }
> };
> @@ -1557,6 +1567,7 @@ static void mt_report(struct hid_device *hid, struct hid_report *report)
> struct mt_device *td = hid_get_drvdata(hid);
> struct hid_field *field = report->field[0];
> struct mt_report_data *rdata;
> + int f, i;
>
> if (!(hid->claimed & HID_CLAIMED_INPUT))
> return;
> @@ -1565,6 +1576,38 @@ static void mt_report(struct hid_device *hid, struct hid_report *report)
> if (rdata && rdata->is_mt_collection)
> return mt_touch_report(hid, rdata);
>
> + /* Lenovo Yoga Book 9i requires consuming and dropping certain bogus reports */
> + if (rdata && rdata->application &&
> + (rdata->application->quirks & MT_QUIRK_YOGABOOK9I)) {
> +
> + bool all_zero_report = true;
Minor nit: why do you declare this variable in this scope, but the f and i
iterators in the global function scope?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling
From: Antheas Kapenekakis @ 2025-11-26 15:28 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: platform-driver-x86, linux-input, LKML, Jiri Kosina,
Benjamin Tissoires, Corentin Chary, Luke D . Jones, Hans de Goede,
Denis Benato
In-Reply-To: <b91fa2c8-e342-9e46-f401-8c3d0590cd38@linux.intel.com>
On Wed, 26 Nov 2025 at 16:24, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Wed, 26 Nov 2025, Antheas Kapenekakis wrote:
>
> > On Sat, 22 Nov 2025 at 12:01, Antheas Kapenekakis <lkml@antheas.dev> wrote:
> > >
> > > This is a two part series which does the following:
> > > - Clean-up init sequence
> > > - Unify backlight handling to happen under asus-wmi so that all Aura
> > > devices have synced brightness controls and the backlight button works
> > > properly when it is on a USB laptop keyboard instead of one w/ WMI.
> > >
> > > For more context, see cover letter of V1. Since V5, I removed some patches
> > > to make this easier to merge.
> >
> > Slight bump on this. It addresses both of the remarks Denis made in
> > the previous version.
> >
> > I begrudgingly argued a bit for those because I did not want to resend
> > the series and they were not functional changes, so sorry about that.
> > But they are fixed in this version incl. with the conflict with the
> > armoury patchset. Denis, you omitted a rby on "platform/x86: asus-wmi:
> > Add support for multiple kbd led handlers" even though I addressed
> > your comment, so you may want to add that.
>
> FYI, there's no direct relation that mandates a person to give a rev-by
> even if all his/her comments were addressed.
True, this is just a reminder because I did not hear from him and
since he added a rev-by on the kfree patch. There's no obligation from
my side.
> But generally yes, it would be useful to hear whether Denis is fine with
> v10, especially those patches that had contention earlier but you've
> modified post-v8.
>
> > As for "HID: asus: early return for ROG devices" changing the name of
> > the devices of this driver, I will veto backporting it if it happens,
> > so inputplumber will have the two full months to remove the name
> > match. This is not a breaking change in the sense that software cannot
> > be made to work on both previous and latter versions and there is no
> > other software to my knowledge relying on name matches for Asus
> > keyboards.
>
> Did Hans give some opinion about this rename earlier, at least I don't
> remember nor could find from lore archives?
Hans jumped in on the ayaneo controller patch. I don't think I saw
activity on this series
Antheas
> --
> i.
>
> > Moreover, an early exit is needed to prevent ejecting HID
> > endpoints without an ->input parameter so it is a needed fix anyway.
> > Postponing it will prevent Xbox Ally users from having RGB control
> > through userspace on a stock kernel but it is also not worth arguing
> > about
> >
> > It is also fine for me for this series to merge for 6.20, but I'd
> > rather we handle it now since there will be some turbulence for asus
> > users due to armoury merging so it makes sense to have this transition
> > once.
> >
> > > ---
> > > V9: https://lore.kernel.org/all/20251120094617.11672-1-lkml@antheas.dev/
> > > V8: https://lore.kernel.org/all/20251101104712.8011-1-lkml@antheas.dev/
> > > V7: https://lore.kernel.org/all/20251018101759.4089-1-lkml@antheas.dev/
> > > V6: https://lore.kernel.org/all/20251013201535.6737-1-lkml@antheas.dev/
> > > V5: https://lore.kernel.org/all/20250325184601.10990-1-lkml@antheas.dev/
> > > V4: https://lore.kernel.org/lkml/20250324210151.6042-1-lkml@antheas.dev/
> > > V3: https://lore.kernel.org/lkml/20250322102804.418000-1-lkml@antheas.dev/
> > > V2: https://lore.kernel.org/all/20250320220924.5023-1-lkml@antheas.dev/
> > > V1: https://lore.kernel.org/all/20250319191320.10092-1-lkml@antheas.dev/
> > >
> > > Changes since V9:
> > > - No functional changes
> > > - Rebase to review-ilpo-next
> > > - Fix armoury series conflict by removing the file asus-wmi-leds-ids on
> > > "remove unused keyboard backlight quirk" + imports
> > > Dismiss Luke's review as this patch diverged
> > > - Reword paragraph in "Add support for multiple kbd led handlers" to be
> > > more verbose
> > > - Use kfree in fortify patch
> > > - Fix minor style quirks from --nonstict checkpatch run
> > >
> > > Changes since V8:
> > > - No functional changes
> > > - Move legacy init patch to second, modify first patch so that their
> > > diff is minimized
> > > - Split "prevent binding to all HID devices on ROG" into two patches:
> > > - moving backlight initialization into probe
> > > - early exit to skip ->init check and rename
> > > - Remove skipping vendor fixups for non-vendor devices. It is not possible
> > > to read usages before the report fixups are applied, so it did not work
> > > - In that patch, reword a comment to be single line and make is_vendor a bool
> > > - Dismiss Luke's tags from "Add support for multiple kbd led handlers" as it
> > > has drifted too far since he reviewed/tested it.
> > >
> > > Changes since V7:
> > > - Readd legacy init quirk for Dennis
> > > - Remove HID_QUIRK_INPUT_PER_APP as a courtesy to asusctl
> > > - Fix warning due to enum_backlight receiving negative values
> > >
> > > Changes since V6:
> > > - Split initialization refactor into three patches, update commit text
> > > to be clearer in what it does
> > > - Replace spinlock accesses with guard and scoped guard in all patches
> > > - Add missing includes mentioned by Ilpo
> > > - Reflow, tweak comment in prevent binding to all HID devices on ROG
> > > - Replace asus_ref.asus with local reference in all patches
> > > - Add missing kernel doc comments
> > > - Other minor nits from Ilpo
> > > - User reported warning due to scheduling work while holding a spinlock.
> > > Restructure patch for multiple handlers to limit when spinlock is held to
> > > variable access only. In parallel, setup a workqueue to handle registration
> > > of led device and setting brightness. This is required as registering the
> > > led device triggers kbd_led_get which needs to hold the spinlock to
> > > protect the led_wk value. The workqueue is also required for the hid
> > > event passthrough to avoid scheduling work while holding the spinlock.
> > > Apply the workqueue to wmi brightness buttons as well, as that was
> > > omitted before this series and WMI access was performed.
> > > - On "HID: asus: prevent binding to all HID devices on ROG", rename
> > > quirk HANDLE_GENERIC to SKIP_REPORT_FIXUP and only skip report fixup.
> > > This allows other quirks to apply (applies quirk that fixes keyboard
> > > being named as a pointer device).
> > >
> > > Changes since V5:
> > > - It's been a long time
> > > - Remove addition of RGB as that had some comments I need to work on
> > > - Remove folio patch (already merged)
> > > - Remove legacy fix patch 11 from V4. There is a small chance that
> > > without this patch, some old NKEY keyboards might not respond to
> > > RGB commands according to Luke, but the kernel driver does not do
> > > RGB currently. The 0x5d init is done by Armoury crate software in
> > > Windows. If an issue is found, we can re-add it or just remove patches
> > > 1/2 before merging. However, init could use the cleanup.
> > >
> > > Changes since V4:
> > > - Fix KConfig (reported by kernel robot)
> > > - Fix Ilpo's nits, if I missed anything lmk
> > >
> > > Changes since V3:
> > > - Add initializer for 0x5d for old NKEY keyboards until it is verified
> > > that it is not needed for their media keys to function.
> > > - Cover init in asus-wmi with spinlock as per Hans
> > > - If asus-wmi registers WMI handler with brightness, init the brightness
> > > in USB Asus keyboards, per Hans.
> > > - Change hid handler name to asus-UNIQ:rgb:peripheral to match led class
> > > - Fix oops when unregistering asus-wmi by moving unregister outside of
> > > the spin lock (but after the asus reference is set to null)
> > >
> > > Changes since V2:
> > > - Check lazy init succeds in asus-wmi before setting register variable
> > > - make explicit check in asus_hid_register_listener for listener existing
> > > to avoid re-init
> > > - rename asus_brt to asus_hid in most places and harmonize everything
> > > - switch to a spinlock instead of a mutex to avoid kernel ooops
> > > - fixup hid device quirks to avoid multiple RGB devices while still exposing
> > > all input vendor devices. This includes moving rgb init to probe
> > > instead of the input_configured callbacks.
> > > - Remove fan key (during retest it appears to be 0xae that is already
> > > supported by hid-asus)
> > > - Never unregister asus::kbd_backlight while asus-wmi is active, as that
> > > - removes fds from userspace and breaks backlight functionality. All
> > > - current mainline drivers do not support backlight hotplugging, so most
> > > userspace software (e.g., KDE, UPower) is built with that assumption.
> > > For the Ally, since it disconnects its controller during sleep, this
> > > caused the backlight slider to not work in KDE.
> > >
> > > Changes since V1:
> > > - Add basic RGB support on hid-asus, (Z13/Ally) tested in KDE/Z13
> > > - Fix ifdef else having an invalid signature (reported by kernel robot)
> > > - Restore input arguments to init and keyboard function so they can
> > > be re-used for RGB controls.
> > > - Remove Z13 delay (it did not work to fix the touchpad) and replace it
> > > with a HID_GROUP_GENERIC quirk to allow hid-multitouch to load. Squash
> > > keyboard rename into it.
> > > - Unregister brightness listener before removing work queue to avoid
> > > a race condition causing corruption
> > > - Remove spurious mutex unlock in asus_brt_event
> > > - Place mutex lock in kbd_led_set after LED_UNREGISTERING check to avoid
> > > relocking the mutex and causing a deadlock when unregistering leds
> > > - Add extra check during unregistering to avoid calling unregister when
> > > no led device is registered.
> > > - Temporarily HID_QUIRK_INPUT_PER_APP from the ROG endpoint as it causes
> > > the driver to create 4 RGB handlers per device. I also suspect some
> > > extra events sneak through (KDE had the @@@@@@).
> > >
> > > Antheas Kapenekakis (11):
> > > HID: asus: simplify RGB init sequence
> > > HID: asus: initialize additional endpoints only for legacy devices
> > > HID: asus: use same report_id in response
> > > HID: asus: fortify keyboard handshake
> > > HID: asus: move vendor initialization to probe
> > > HID: asus: early return for ROG devices
> > > platform/x86: asus-wmi: Add support for multiple kbd led handlers
> > > HID: asus: listen to the asus-wmi brightness device instead of
> > > creating one
> > > platform/x86: asus-wmi: remove unused keyboard backlight quirk
> > > platform/x86: asus-wmi: add keyboard brightness event handler
> > > HID: asus: add support for the asus-wmi brightness handler
> > >
> > > drivers/hid/hid-asus.c | 205 ++++++++--------
> > > drivers/platform/x86/asus-wmi.c | 223 +++++++++++++++---
> > > .../platform_data/x86/asus-wmi-leds-ids.h | 50 ----
> > > include/linux/platform_data/x86/asus-wmi.h | 28 +++
> > > 4 files changed, 322 insertions(+), 184 deletions(-)
> > > delete mode 100644 include/linux/platform_data/x86/asus-wmi-leds-ids.h
> > >
> > >
> > > base-commit: 2643187ccb8628144246ee9d44da5e3ac428f9c3
> > > --
> > > 2.52.0
> > >
> > >
> >
>
^ 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