* Re: [PATCH v2 1/6] Input: cyttsp5 - fix array length
From: Dmitry Torokhov @ 2023-05-02 0:15 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-2-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:05PM +0200, Maximilian Weigand wrote:
> The cmd array should be initialized with the proper command size and not
> with the actual command value that is sent to the touchscreen.
>
> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
> Reviewed-by: Alistair Francis <alistair@alistair23.me>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/6] Input: cyttsp5 - remove unused code
From: Dmitry Torokhov @ 2023-05-02 0:15 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-3-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:06PM +0200, Maximilian Weigand wrote:
> The removed lines are remnants of the vendor driver and are not used in
> the upstream driver.
>
> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
> Reviewed-by: Alistair Francis <alistair@alistair23.me>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 6/6] Input: cyttsp5 - implement proper sleep and wakeup procedures
From: Dmitry Torokhov @ 2023-05-02 0:22 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-7-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:10PM +0200, Maximilian Weigand wrote:
> struct cyttsp5 {
> struct device *dev;
> struct completion cmd_done;
> + struct completion cmd_command_done;
Why do we need separate comletion? Do you observe some additional
traffic from the controller when powering it off and on?
> +static int __maybe_unused cyttsp5_suspend(struct device *dev)
> +{
> + struct cyttsp5 *ts = dev_get_drvdata(dev);
> +
> + if (!ts->is_wakeup_source)
I believe the idiomatic way to check this is to call
device_may_wakeup().
> + cyttsp5_enter_sleep(ts);
> + return 0;
> +}
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: input: cypress,tt21000 - fix interrupt type in dts example
From: Dmitry Torokhov @ 2023-05-02 0:24 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-4-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:07PM +0200, Maximilian Weigand wrote:
> Triggering the interrupt of the IRQ_TYPE_LEVEL_LOW type can lead to
> probing issues with the device for the current driver (encountered on
> the Pine64 PineNote). Basically the interrupt would be triggered before
> certain commands were sent to the device, leading to a race between the
> device responding fast enough and the irq handler fetching a data frame
> from it. Actually all devices currently using the driver already use a
> falling edge trigger.
I'd prefer we adjusted the driver to handle level interrupts properly.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/6] dt-bindings: input: cypress,tt21000 - add wakeup-source entry to documentation
From: Dmitry Torokhov @ 2023-05-02 0:28 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-6-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:09PM +0200, Maximilian Weigand wrote:
> The touchscreen can be used to wake up systems from sleep and therefore
> the wakeup-source entry should be included in the documentation.
>
> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
> Reviewed-by: Alistair Francis <alistair@alistair23.me>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/5] Improvements for drv260x driver and add to Huawei Watch
From: Dmitry Torokhov @ 2023-05-02 0:29 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Dan Murphy, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Raffaele Tranquillini, Yassine Oudjana, linux-input, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
On Sun, Apr 30, 2023 at 08:20:52PM +0200, Luca Weiss wrote:
> Clean up some issues with the driver I've noticed while working on it,
> then fix the magnitude handling which previously resulted the driver
> discarding the upper 8 bits of the magnitude value, and finally we can
> add the drv260x to the APQ8026 Huawei Watch.
>
> While the "fix magnitude handling" commit technically changes behavior
> and could change behavior of existing user space applications that deal
> with this quirky behavior, it's definitely not correct and results in
> very unexpected behavior if the user space doesn't look out for it
> (meaning only use 0x00-0xFF magnitude, and also know that the magnitude
> was interpreted as signed value, see more details in the commit message
> there).
>
> There's currently only one other upstream user of the driver,
> qcom/msm8996-xiaomi-gemini where I've added the dts authors to this
> patch series (Raffaele & Yassine) and some tests on that device would be
> nice since it's operating in LRA mode, mine does in ERM mode.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> Luca Weiss (5):
> Input: drv260x - fix typo in register value define
> Input: drv260x - sleep between polling GO bit
> Input: drv260x - remove unused .reg_defaults
> Input: drv260x - fix magnitude handling
> ARM: dts: qcom: apq8026-huawei-sturgeon: Add vibrator
Applied patches 1-4.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [git pull] Input updates for v6.4-rc0
From: pr-tracker-bot @ 2023-05-02 0:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <ZFBKHyTky9YhQv+s@google.com>
The pull request you sent on Mon, 1 May 2023 16:24:15 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.4-rc0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/865fdb08197e657c59e74a35fa32362b12397f58
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] Input: cyttsp4_core - change del_timer_sync() to timer_shutdown_sync()
From: Dmitry Torokhov @ 2023-05-02 0:38 UTC (permalink / raw)
To: Duoming Zhou; +Cc: linux-input, linux-kernel, linus.walleij
In-Reply-To: <20230421082919.8471-1-duoming@zju.edu.cn>
On Fri, Apr 21, 2023 at 04:29:19PM +0800, Duoming Zhou wrote:
> The watchdog_timer can schedule tx_timeout_task and watchdog_work
> can also arm watchdog_timer. The process is shown below:
>
> ----------- timer schedules work ------------
> cyttsp4_watchdog_timer() //timer handler
> schedule_work(&cd->watchdog_work)
>
> ----------- work arms timer ------------
> cyttsp4_watchdog_work() //workqueue callback function
> cyttsp4_start_wd_timer()
> mod_timer(&cd->watchdog_timer, ...)
>
> Although del_timer_sync() and cancel_work_sync() are called in
> cyttsp4_remove(), the timer and workqueue could still be rearmed.
> As a result, the possible use after free bugs could happen. The
> process is shown below:
>
> (cleanup routine) | (timer and workqueue routine)
> cyttsp4_remove() | cyttsp4_watchdog_timer() //timer
> cyttsp4_stop_wd_timer() | schedule_work()
> del_timer_sync() |
> | cyttsp4_watchdog_work() //worker
> | cyttsp4_start_wd_timer()
> | mod_timer()
> cancel_work_sync() |
> | cyttsp4_watchdog_timer() //timer
> | schedule_work()
> del_timer_sync() |
> kfree(cd) //FREE |
> | cyttsp4_watchdog_work() // reschedule!
> | cd-> //USE
>
> This patch changes del_timer_sync() to timer_shutdown_sync(),
> which could prevent rearming of the timer from the workqueue.
>
> Fixes: 17fb1563d69b ("Input: cyttsp4 - add core driver for Cypress TMA4XX touchscreen devices")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] i8042: add missing include
From: Dmitry Torokhov @ 2023-05-02 0:39 UTC (permalink / raw)
To: Michał Mirosław; +Cc: linux-input
In-Reply-To: <49fd4d400d1ab62095e5ed75a6637f883c0d071b.1682795105.git.mirq-linux@rere.qmqm.pl>
On Sat, Apr 29, 2023 at 09:06:49PM +0200, Michał Mirosław wrote:
> <linux/i8042.h> include uses ENODEV when included with
> !IS_ENABLED(CONFIG_SERIO_I8042) and so need to include it.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4: Use %pe for error codes.
From: Dmitry Torokhov @ 2023-05-02 0:40 UTC (permalink / raw)
To: Michał Mirosław; +Cc: linux-input
In-Reply-To: <1ec25bf991f576a98bd8fdc58264a92ee268eba9.1682793592.git.mirq-linux@rere.qmqm.pl>
On Sat, Apr 29, 2023 at 08:41:19PM +0200, Michał Mirosław wrote:
> Make the error messages a bit easier to understand by showing
> error names where that's enabled.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> drivers/input/rmi4/rmi_driver.c | 66 +++++++++++++++++----------------
> 1 file changed, 34 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index 258d5fe3d395..82d85c02a873 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -69,8 +69,8 @@ static int reset_one_function(struct rmi_function *fn)
> if (fh->reset) {
> retval = fh->reset(fn);
> if (retval < 0)
> - dev_err(&fn->dev, "Reset failed with code %d.\n",
> - retval);
> + dev_err(&fn->dev, "Reset failed: %pe\n",
> + ERR_PTR(retval));
If this is desired we should have a format option for
non-err-ptr-encoded errors.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Dmitry Torokhov @ 2023-05-02 0:47 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Rob Herring,
Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-3-e87eeb94da51@z3ntu.xyz>
On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
> Some pwm vibrators have a dedicated enable GPIO that needs to be set
> high so that the vibrator works. Add support for that optionally.
So this is not simply a power supply in your case controlled by a GPIO?
We truly can have both GPIO and a separate regulator?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: avoid calling input_set_abs_val() in the event handling core
From: Dmitry Torokhov @ 2023-05-02 1:01 UTC (permalink / raw)
To: linux-input; +Cc: Teng Qi, linux-kernel
input_abs_set_val() can nominally call input_alloc_absinfo() which may
allocate memory with GFP_KERNEL flag. This does not happen when
input_abs_set_val() is called by the input core to set current MT slot when
handling a new input event, but it trips certain static analyzers.
Rearrange the code to access the relevant structures directly.
Reported-by: Teng Qi <starmiku1207184332@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/input.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 37e876d45eb9..f791d14ecf23 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -190,6 +190,7 @@ static int input_handle_abs_event(struct input_dev *dev,
unsigned int code, int *pval)
{
struct input_mt *mt = dev->mt;
+ bool is_new_slot = false;
bool is_mt_event;
int *pold;
@@ -210,6 +211,7 @@ static int input_handle_abs_event(struct input_dev *dev,
pold = &dev->absinfo[code].value;
} else if (mt) {
pold = &mt->slots[mt->slot].abs[code - ABS_MT_FIRST];
+ is_new_slot = mt->slot != dev->absinfo[ABS_MT_SLOT].value;
} else {
/*
* Bypass filtering for multi-touch events when
@@ -228,8 +230,8 @@ static int input_handle_abs_event(struct input_dev *dev,
}
/* Flush pending "slot" event */
- if (is_mt_event && mt && mt->slot != input_abs_get_val(dev, ABS_MT_SLOT)) {
- input_abs_set_val(dev, ABS_MT_SLOT, mt->slot);
+ if (is_new_slot) {
+ dev->absinfo[ABS_MT_SLOT].value = mt->slot;
return INPUT_PASS_TO_HANDLERS | INPUT_SLOT;
}
--
2.40.1.495.gc816e09b53d-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] drivers: input: input: Fix possible sleep-in-atomic bug in input_alloc_absinfo()
From: Dmitry Torokhov @ 2023-05-02 1:03 UTC (permalink / raw)
To: starmiku1207184332; +Cc: rydberg, linux-input, linux-kernel
In-Reply-To: <20230425074951.1042694-1-starmiku1207184332@gmail.com>
Hi Teng Qi,
On Tue, Apr 25, 2023 at 07:49:51AM +0000, starmiku1207184332@gmail.com wrote:
> From: Teng Qi <starmiku1207184332@gmail.com>
>
> input_alloc_absinfo() may cause the kernel to sleep by calling kcalloc() with
> the GFP_KERNEL flag. It may be called by input_event() holding spinlock through
> the following call path:
>
> input_event(), 433
> input_handle_event(), 399
> input_get_disposition(), 294
> input_handle_abs_event(), 232
> input_abs_set_val(), Clang suggests it calls input_alloc_absinfo()
> unconditionally
> input_alloc_absinfo(), 483
> kcalloc(..., GFP_KERNEL)
>
> This call path can potentially trigger a sleep-in-atomic bug. To prevent this
> potential bug, we modify input_alloc_absinfo() to use the GFP_ATOMIC flag
> instead of the GFP_KERNEL flag.
This can not happen in practice, and changing the allocation type to
GFP_ATOMIC hurts the other code. We can avoid the issue by not using the
helper and have input core access the slot info directly. I CCed you on
a patch doing so.
> The possible bug is detected by a static code analysis tool.
>
> Signed-off-by: Teng Qi <starmiku1207184332@gmail.com>
> ---
> drivers/input/input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 37e876d45eb9..eefc4c85a693 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -480,7 +480,7 @@ void input_alloc_absinfo(struct input_dev *dev)
> if (dev->absinfo)
> return;
>
> - dev->absinfo = kcalloc(ABS_CNT, sizeof(*dev->absinfo), GFP_KERNEL);
> + dev->absinfo = kcalloc(ABS_CNT, sizeof(*dev->absinfo), GFP_ATOMIC);
> if (!dev->absinfo) {
> dev_err(dev->dev.parent ?: &dev->dev,
> "%s: unable to allocate memory\n", __func__);
> --
> 2.25.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Call input_set_timestamp for events injected using uinput
From: Dmitry Torokhov @ 2023-05-02 1:05 UTC (permalink / raw)
To: Biswarup Pal, Peter Hutterer; +Cc: kernel-team, linux-input, linux-kernel
In-Reply-To: <20230427000152.1407471-1-biswarupp@google.com>
On Thu, Apr 27, 2023 at 12:01:51AM +0000, Biswarup Pal wrote:
> Currently, uinput doesn't use the input_set_timestamp API, so any
> event injected using uinput is not accurately timestamped in terms of
> measuring when the actual event happened. Hence, call the
> input_set_timestamp API from uinput in order to provide a more
> accurate sense of time for the event. Propagate only the timestamps
> which are a) positive, b) within a pre-defined offset (10 secs) from
> the current time, and c) not in the future.
This makes sense to me. Peter, do you see any issues?
Thanks!
>
> Signed-off-by: Biswarup Pal <biswarupp@google.com>
> ---
> drivers/input/misc/uinput.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index f2593133e524..d98212d55108 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -33,6 +33,7 @@
> #define UINPUT_NAME "uinput"
> #define UINPUT_BUFFER_SIZE 16
> #define UINPUT_NUM_REQUESTS 16
> +#define UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS 10
>
> enum uinput_state { UIST_NEW_DEVICE, UIST_SETUP_COMPLETE, UIST_CREATED };
>
> @@ -569,11 +570,40 @@ static int uinput_setup_device_legacy(struct uinput_device *udev,
> return retval;
> }
>
> +/*
> + * Returns true if the given timestamp is valid (i.e., if all the following
> + * conditions are satisfied), false otherwise.
> + * 1) given timestamp is positive
> + * 2) it's within the allowed offset before the current time
> + * 3) it's not in the future
> + */
> +static bool is_valid_timestamp(const ktime_t timestamp)
> +{
> + ktime_t zero_time;
> + ktime_t current_time;
> + ktime_t min_time;
> + ktime_t offset;
> +
> + zero_time = ktime_set(0, 0);
> + if (ktime_compare(zero_time, timestamp) >= 0)
> + return false;
> +
> + current_time = ktime_get();
> + offset = ktime_set(UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS, 0);
> + min_time = ktime_sub(current_time, offset);
> +
> + if (ktime_after(min_time, timestamp) || ktime_after(timestamp, current_time))
> + return false;
> +
> + return true;
> +}
> +
> static ssize_t uinput_inject_events(struct uinput_device *udev,
> const char __user *buffer, size_t count)
> {
> struct input_event ev;
> size_t bytes = 0;
> + ktime_t timestamp;
>
> if (count != 0 && count < input_event_size())
> return -EINVAL;
> @@ -588,6 +618,10 @@ static ssize_t uinput_inject_events(struct uinput_device *udev,
> if (input_event_from_user(buffer + bytes, &ev))
> return -EFAULT;
>
> + timestamp = ktime_set(ev.input_event_sec, ev.input_event_usec * NSEC_PER_USEC);
> + if (is_valid_timestamp(timestamp))
> + input_set_timestamp(udev->dev, timestamp);
> +
> input_event(udev->dev, ev.type, ev.code, ev.value);
> bytes += input_event_size();
> cond_resched();
> --
> 2.40.1.495.gc816e09b53d-goog
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Call input_set_timestamp for events injected using uinput
From: Peter Hutterer @ 2023-05-02 2:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Biswarup Pal, kernel-team, linux-input, linux-kernel
In-Reply-To: <ZFBh948No3IAV2hf@google.com>
Thanks for the CC, I would've missed that.
On Mon, May 01, 2023 at 06:05:59PM -0700, Dmitry Torokhov wrote:
> On Thu, Apr 27, 2023 at 12:01:51AM +0000, Biswarup Pal wrote:
> > Currently, uinput doesn't use the input_set_timestamp API, so any
> > event injected using uinput is not accurately timestamped in terms of
> > measuring when the actual event happened. Hence, call the
> > input_set_timestamp API from uinput in order to provide a more
> > accurate sense of time for the event. Propagate only the timestamps
> > which are a) positive, b) within a pre-defined offset (10 secs) from
> > the current time, and c) not in the future.
>
> This makes sense to me. Peter, do you see any issues?
nope, this looks good and has my
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
afaict any code that has compiler warnings enabled should have this on
zero anyway. It'd be really nice to pass a timestamp down to uinput but
that's obviously a lot more involved.
Cheers,
Peter
>
> Thanks!
>
> >
> > Signed-off-by: Biswarup Pal <biswarupp@google.com>
> > ---
> > drivers/input/misc/uinput.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> > index f2593133e524..d98212d55108 100644
> > --- a/drivers/input/misc/uinput.c
> > +++ b/drivers/input/misc/uinput.c
> > @@ -33,6 +33,7 @@
> > #define UINPUT_NAME "uinput"
> > #define UINPUT_BUFFER_SIZE 16
> > #define UINPUT_NUM_REQUESTS 16
> > +#define UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS 10
> >
> > enum uinput_state { UIST_NEW_DEVICE, UIST_SETUP_COMPLETE, UIST_CREATED };
> >
> > @@ -569,11 +570,40 @@ static int uinput_setup_device_legacy(struct uinput_device *udev,
> > return retval;
> > }
> >
> > +/*
> > + * Returns true if the given timestamp is valid (i.e., if all the following
> > + * conditions are satisfied), false otherwise.
> > + * 1) given timestamp is positive
> > + * 2) it's within the allowed offset before the current time
> > + * 3) it's not in the future
> > + */
> > +static bool is_valid_timestamp(const ktime_t timestamp)
> > +{
> > + ktime_t zero_time;
> > + ktime_t current_time;
> > + ktime_t min_time;
> > + ktime_t offset;
> > +
> > + zero_time = ktime_set(0, 0);
> > + if (ktime_compare(zero_time, timestamp) >= 0)
> > + return false;
> > +
> > + current_time = ktime_get();
> > + offset = ktime_set(UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS, 0);
> > + min_time = ktime_sub(current_time, offset);
> > +
> > + if (ktime_after(min_time, timestamp) || ktime_after(timestamp, current_time))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > static ssize_t uinput_inject_events(struct uinput_device *udev,
> > const char __user *buffer, size_t count)
> > {
> > struct input_event ev;
> > size_t bytes = 0;
> > + ktime_t timestamp;
> >
> > if (count != 0 && count < input_event_size())
> > return -EINVAL;
> > @@ -588,6 +618,10 @@ static ssize_t uinput_inject_events(struct uinput_device *udev,
> > if (input_event_from_user(buffer + bytes, &ev))
> > return -EFAULT;
> >
> > + timestamp = ktime_set(ev.input_event_sec, ev.input_event_usec * NSEC_PER_USEC);
> > + if (is_valid_timestamp(timestamp))
> > + input_set_timestamp(udev->dev, timestamp);
> > +
> > input_event(udev->dev, ev.type, ev.code, ev.value);
> > bytes += input_event_size();
> > cond_resched();
> > --
> > 2.40.1.495.gc816e09b53d-goog
> >
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: synaptics - disable intertouch for Lenovo L440
From: Dmitry Torokhov @ 2023-05-02 3:11 UTC (permalink / raw)
To: Jonathan Denose
Cc: Andrew Duggan, Lyude Paul, Andrew Duggan, amandhoot12@gmail.com,
jdenose@google.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, markpearson@lenovo.com,
wsa+renesas@sang-engineering.com, benjamin.tissoires
In-Reply-To: <CALNJtpWOPRB3-0Jw+GJt_D-vjEhbhDRw-Kb3boC0dOU+525fFQ@mail.gmail.com>
On Mon, Apr 24, 2023 at 02:11:28PM -0500, Jonathan Denose wrote:
> Hi Andrew,
>
> Thanks for your reply. As an update, I was able to try the patch here:
> https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/ and it
> resolves the suspend/resume issue on this device. I'm not sure what
> the status of the linked patch is, to me it doesn't look like it was
> merged anywhere.
This patch shoudl have been superseded by:
commit 7b1f781f2d2460693f43d5f764198df558e3494b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Tue Feb 15 13:32:26 2022 -0800
Input: psmouse - set up dependency between PS/2 and SMBus companions
When we switch from emulated PS/2 to native (RMI4 or Elan) protocols, we
create SMBus companion devices that are attached to I2C/SMBus controllers.
However, when suspending and resuming, we also need to make sure that we
take into account the PS/2 device they are associated with, so that PS/2
device is suspended after the companion and resumed before it, otherwise
companions will not work properly. Before I2C devices were marked for
asynchronous suspend/resume, this ordering happened naturally, but now we
need to enforce it by establishing device links, with PS/2 devices being
suppliers and SMBus companions being consumers.
Fixes: 172d931910e1 ("i2c: enable async suspend/resume on i2c client devices")
Reported-and-tested-by: Hugh Dickins <hughd@google.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com
Link: https://lore.kernel.org/r/YgwQN8ynO88CPMju@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Which should have ensured that PS/2 device is resumed first, before
trying to resume RMI interface. I wonder why it is not working for you.
Can you enable logging and see if the order of resume is correct or not.
If it is still wrong we need to figure out why setting the link between
the devices does not have the desired effect.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2] Input: xpad - Move Xbox 360 magic packet sending
From: Vicki Pfau @ 2023-05-02 3:12 UTC (permalink / raw)
To: Dmitry Torokhov, Dongliang Mu, linux-input
Cc: Dan Carpenter, Vicki Pfau, syzbot+a3f758b8d8cb7e49afec
This moves the sending of the magic packet introduced in db7220c48d8d from
xpad_probe to xpad_start_input to ensure that xpad->dev->dev exists in the
event that an error occurs. This should also fix issues with suspend that may
occur with some controllers.
Fixes: db7220c48d8d ("Input: xpad - fix support for some third-party controllers")
Reported-by: syzbot+a3f758b8d8cb7e49afec@syzkaller.appspotmail.com
Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
Link: https://groups.google.com/g/syzkaller-bugs/c/iMhTgpGuIbM
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/input/joystick/xpad.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 50ecff681b89..40abea92c393 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1720,6 +1720,27 @@ static int xpad_start_input(struct usb_xpad *xpad)
return error;
}
}
+ if (xpad->xtype == XTYPE_XBOX360) {
+ /*
+ * Some third-party controllers Xbox 360-style controllers
+ * require this message to finish initialization.
+ */
+ u8 dummy[20];
+
+ error = usb_control_msg_recv(xpad->udev, 0,
+ /* bRequest */ 0x01,
+ /* bmRequestType */
+ USB_TYPE_VENDOR | USB_DIR_IN |
+ USB_RECIP_INTERFACE,
+ /* wValue */ 0x100,
+ /* wIndex */ 0x00,
+ dummy, sizeof(dummy),
+ 25, GFP_KERNEL);
+ if (error)
+ dev_warn(&xpad->dev->dev,
+ "unable to receive magic message: %d\n",
+ error);
+ }
return 0;
}
--
2.40.1
^ permalink raw reply related
* Re: [PATCH] Call input_set_timestamp for events injected using uinput
From: Dmitry Torokhov @ 2023-05-02 3:21 UTC (permalink / raw)
To: Peter Hutterer; +Cc: Biswarup Pal, kernel-team, linux-input, linux-kernel
In-Reply-To: <20230502021305.GA798180@quokka>
On Tue, May 02, 2023 at 12:13:05PM +1000, Peter Hutterer wrote:
> Thanks for the CC, I would've missed that.
>
> On Mon, May 01, 2023 at 06:05:59PM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 27, 2023 at 12:01:51AM +0000, Biswarup Pal wrote:
> > > Currently, uinput doesn't use the input_set_timestamp API, so any
> > > event injected using uinput is not accurately timestamped in terms of
> > > measuring when the actual event happened. Hence, call the
> > > input_set_timestamp API from uinput in order to provide a more
> > > accurate sense of time for the event. Propagate only the timestamps
> > > which are a) positive, b) within a pre-defined offset (10 secs) from
> > > the current time, and c) not in the future.
> >
> > This makes sense to me. Peter, do you see any issues?
>
> nope, this looks good and has my
> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Great, applied.
>
> afaict any code that has compiler warnings enabled should have this on
> zero anyway. It'd be really nice to pass a timestamp down to uinput but
> that's obviously a lot more involved.
>
> Cheers,
> Peter
>
> >
> > Thanks!
> >
> > >
> > > Signed-off-by: Biswarup Pal <biswarupp@google.com>
> > > ---
> > > drivers/input/misc/uinput.c | 34 ++++++++++++++++++++++++++++++++++
> > > 1 file changed, 34 insertions(+)
> > >
> > > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> > > index f2593133e524..d98212d55108 100644
> > > --- a/drivers/input/misc/uinput.c
> > > +++ b/drivers/input/misc/uinput.c
> > > @@ -33,6 +33,7 @@
> > > #define UINPUT_NAME "uinput"
> > > #define UINPUT_BUFFER_SIZE 16
> > > #define UINPUT_NUM_REQUESTS 16
> > > +#define UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS 10
> > >
> > > enum uinput_state { UIST_NEW_DEVICE, UIST_SETUP_COMPLETE, UIST_CREATED };
> > >
> > > @@ -569,11 +570,40 @@ static int uinput_setup_device_legacy(struct uinput_device *udev,
> > > return retval;
> > > }
> > >
> > > +/*
> > > + * Returns true if the given timestamp is valid (i.e., if all the following
> > > + * conditions are satisfied), false otherwise.
> > > + * 1) given timestamp is positive
> > > + * 2) it's within the allowed offset before the current time
> > > + * 3) it's not in the future
> > > + */
> > > +static bool is_valid_timestamp(const ktime_t timestamp)
> > > +{
> > > + ktime_t zero_time;
> > > + ktime_t current_time;
> > > + ktime_t min_time;
> > > + ktime_t offset;
> > > +
> > > + zero_time = ktime_set(0, 0);
> > > + if (ktime_compare(zero_time, timestamp) >= 0)
> > > + return false;
> > > +
> > > + current_time = ktime_get();
> > > + offset = ktime_set(UINPUT_TIMESTAMP_ALLOWED_OFFSET_SECS, 0);
> > > + min_time = ktime_sub(current_time, offset);
> > > +
> > > + if (ktime_after(min_time, timestamp) || ktime_after(timestamp, current_time))
> > > + return false;
> > > +
> > > + return true;
> > > +}
> > > +
> > > static ssize_t uinput_inject_events(struct uinput_device *udev,
> > > const char __user *buffer, size_t count)
> > > {
> > > struct input_event ev;
> > > size_t bytes = 0;
> > > + ktime_t timestamp;
> > >
> > > if (count != 0 && count < input_event_size())
> > > return -EINVAL;
> > > @@ -588,6 +618,10 @@ static ssize_t uinput_inject_events(struct uinput_device *udev,
> > > if (input_event_from_user(buffer + bytes, &ev))
> > > return -EFAULT;
> > >
> > > + timestamp = ktime_set(ev.input_event_sec, ev.input_event_usec * NSEC_PER_USEC);
> > > + if (is_valid_timestamp(timestamp))
> > > + input_set_timestamp(udev->dev, timestamp);
> > > +
> > > input_event(udev->dev, ev.type, ev.code, ev.value);
> > > bytes += input_event_size();
> > > cond_resched();
> > > --
> > > 2.40.1.495.gc816e09b53d-goog
> > >
> >
> > --
> > Dmitry
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/2] Input: atmel_mxt_ts - support capacitive keys
From: Dmitry Torokhov @ 2023-05-02 3:23 UTC (permalink / raw)
To: André Apitzsch
Cc: Nick Dyer, Rob Herring, Krzysztof Kozlowski, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Linus Walleij, linux-input,
devicetree, linux-arm-kernel, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20230407-atmel_keys-v2-0-92446a4343cb@apitzsch.eu>
On Fri, Apr 07, 2023 at 02:44:23PM +0200, André Apitzsch wrote:
> Add support for touch keys found in some Atmel touch controller
> configurations.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> ---
> Changes in v2:
> * Added A-b, R-b tags
Applied the lot, thank you.
>
> ---
> André Apitzsch (2):
> dt-bindings: input: atmel,maxtouch: add linux,keycodes
> Input: atmel_mxt_ts - support capacitive keys
>
> .../devicetree/bindings/input/atmel,maxtouch.yaml | 7 ++
> drivers/input/touchscreen/atmel_mxt_ts.c | 85 ++++++++++++++++++++++
> 2 files changed, 92 insertions(+)
> ---
> base-commit: f2afccfefe7be1f7346564fe619277110d341f9b
> change-id: 20230407-atmel_keys-7a49c6b677b2
>
> Best regards,
> --
> André Apitzsch <git@apitzsch.eu>
>
--
Dmitry
^ permalink raw reply
* [PATCH v2 1/2] HID: lg4ff: explicitly include linux/leds.h
From: Thomas Weißschuh @ 2023-05-02 4:28 UTC (permalink / raw)
To: Sebastian Reichel, Jiri Kosina, Benjamin Tissoires
Cc: linux-pm, linux-kernel, linux-input, kernel test robot,
Thomas Weißschuh
In-Reply-To: <20230212-include-power_supply-leds-v2-0-e9910a3f5837@weissschuh.net>
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202304301551.baBXvI9d-lkp@intel.com/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
drivers/hid/hid-lg4ff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index e3fcf1353fb3..d55d04c140b9 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -15,6 +15,7 @@
#include <linux/input.h>
#include <linux/usb.h>
#include <linux/hid.h>
+#include <linux/leds.h>
#include "usbhid/usbhid.h"
#include "hid-lg.h"
--
2.40.1
^ permalink raw reply related
* [PATCH v2 0/2] power: supply: remove unneeded include of linux/leds.h
From: Thomas Weißschuh @ 2023-05-02 4:28 UTC (permalink / raw)
To: Sebastian Reichel, Jiri Kosina, Benjamin Tissoires
Cc: linux-pm, linux-kernel, linux-input, kernel test robot,
Thomas Weißschuh
Currently power_supply.h includes leds.h to get access to
struct led_trigger.
This propagates the inclusion unnecessarily to all users of
power_supply.h.
Replace this inclusion by a single forward declaration.
---
Changes in v2:
- Add an explicit include to drivers/hid/hid-lg4ff.c
- Link to v1: https://lore.kernel.org/r/20230212-include-power_supply-leds-v1-1-7adbf7424002@weissschuh.net
---
Thomas Weißschuh (2):
HID: lg4ff: explicitly include linux/leds.h
power: supply: remove unneeded include of linux/leds.h
drivers/hid/hid-lg4ff.c | 1 +
include/linux/power_supply.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
---
base-commit: 865fdb08197e657c59e74a35fa32362b12397f58
change-id: 20230212-include-power_supply-leds-fe1d71c7b7b2
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
^ permalink raw reply
* [PATCH v2 2/2] power: supply: remove unneeded include of linux/leds.h
From: Thomas Weißschuh @ 2023-05-02 4:28 UTC (permalink / raw)
To: Sebastian Reichel, Jiri Kosina, Benjamin Tissoires
Cc: linux-pm, linux-kernel, linux-input, Thomas Weißschuh
In-Reply-To: <20230212-include-power_supply-leds-v2-0-e9910a3f5837@weissschuh.net>
Instead of including the full linux/leds.h header file a single
forward-declaration is enough.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
include/linux/power_supply.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index a427f13c757f..dc5e17e8c919 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -14,10 +14,11 @@
#include <linux/device.h>
#include <linux/workqueue.h>
-#include <linux/leds.h>
#include <linux/spinlock.h>
#include <linux/notifier.h>
+struct led_trigger;
+
/*
* All voltages, currents, charges, energies, time and temperatures in uV,
* µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
--
2.40.1
^ permalink raw reply related
* Re: [PATCH] Input: avoid calling input_set_abs_val() in the event handling core
From: Peter Hutterer @ 2023-05-02 6:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Teng Qi, linux-kernel
In-Reply-To: <ZFBg379uuHjf+YEM@google.com>
On Mon, May 01, 2023 at 06:01:19PM -0700, Dmitry Torokhov wrote:
> input_abs_set_val() can nominally call input_alloc_absinfo() which may
> allocate memory with GFP_KERNEL flag. This does not happen when
> input_abs_set_val() is called by the input core to set current MT slot when
> handling a new input event, but it trips certain static analyzers.
>
> Rearrange the code to access the relevant structures directly.
>
> Reported-by: Teng Qi <starmiku1207184332@gmail.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If git grep is to be believed, this is the only use of
input_abs_set_val. Maybe removing that function is an option?
Are there external drivers that rely on this (instead of sending an
event)?
Cheers,
Peter
> ---
> drivers/input/input.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 37e876d45eb9..f791d14ecf23 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -190,6 +190,7 @@ static int input_handle_abs_event(struct input_dev *dev,
> unsigned int code, int *pval)
> {
> struct input_mt *mt = dev->mt;
> + bool is_new_slot = false;
> bool is_mt_event;
> int *pold;
>
> @@ -210,6 +211,7 @@ static int input_handle_abs_event(struct input_dev *dev,
> pold = &dev->absinfo[code].value;
> } else if (mt) {
> pold = &mt->slots[mt->slot].abs[code - ABS_MT_FIRST];
> + is_new_slot = mt->slot != dev->absinfo[ABS_MT_SLOT].value;
> } else {
> /*
> * Bypass filtering for multi-touch events when
> @@ -228,8 +230,8 @@ static int input_handle_abs_event(struct input_dev *dev,
> }
>
> /* Flush pending "slot" event */
> - if (is_mt_event && mt && mt->slot != input_abs_get_val(dev, ABS_MT_SLOT)) {
> - input_abs_set_val(dev, ABS_MT_SLOT, mt->slot);
> + if (is_new_slot) {
> + dev->absinfo[ABS_MT_SLOT].value = mt->slot;
> return INPUT_PASS_TO_HANDLERS | INPUT_SLOT;
> }
>
> --
> 2.40.1.495.gc816e09b53d-goog
>
>
> --
> Dmitry
^ permalink raw reply
* [PATCH] HID: uclogic: Modular KUnit tests should not depend on KUNIT=y
From: Geert Uytterhoeven @ 2023-05-02 10:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Daniel Latypov,
José Expósito, Brendan Higgins, David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
While KUnit tests that cannot be built as a loadable module must depend
on "KUNIT=y", this is not true for modular tests, where it adds an
unnecessary limitation.
Fix this by relaxing the dependency to "KUNIT".
Fixes: 08809e482a1c44d9 ("HID: uclogic: KUnit best practices and naming conventions")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/hid/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4ce012f83253ec9f..b977450cac75265d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1285,7 +1285,7 @@ config HID_MCP2221
config HID_KUNIT_TEST
tristate "KUnit tests for HID" if !KUNIT_ALL_TESTS
- depends on KUNIT=y
+ depends on KUNIT
depends on HID_BATTERY_STRENGTH
depends on HID_UCLOGIC
default KUNIT_ALL_TESTS
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Input: tests - miscellaneous fixes
From: Geert Uytterhoeven @ 2023-05-02 10:17 UTC (permalink / raw)
To: Dmitry Torokhov, Javier Martinez Canillas, Brendan Higgins,
David Gow
Cc: linux-input, linux-kselftest, kunit-dev, linux-kernel,
Geert Uytterhoeven
Hi all,
This patch series fixes a crash in the new input selftest, and makes the
test available when the KUnit framework is modular.
Unfortunately test 3 still fails for me (tested on Koelsch (R-Car M2-W)
and ARAnyM):
KTAP version 1
# Subtest: input_core
1..3
input: Test input device as /devices/virtual/input/input1
ok 1 input_test_polling
input: Test input device as /devices/virtual/input/input2
ok 2 input_test_timestamp
input: Test input device as /devices/virtual/input/input3
# input_test_match_device_id: ASSERTION FAILED at # drivers/input/tests/input_test.c:99
Expected input_match_device_id(input_dev, &id) to be true, but is false
not ok 3 input_test_match_device_id
# input_core: pass:2 fail:1 skip:0 total:3
# Totals: pass:2 fail:1 skip:0 total:3
not ok 1 input_core
Thanks!
Geert Uytterhoeven (2):
Input: tests - fix use-after-free and refcount underflow in
input_test_exit()
Input: tests - modular KUnit tests should not depend on KUNIT=y
drivers/input/Kconfig | 2 +-
drivers/input/tests/input_test.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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