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: 172d9319 ("i2c: enable async suspend/resume on i2c client devices")
Reported-and-tested-by: NHugh Dickins <hughd@google.com>
Tested-by: NJarkko 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.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This driver works just fine with the BT404 version of the touchscreen
as well. Tested on the Samsung GT-I8160 (Codina) mobile phone.

Add all the new variants from the binding document so people can
easily test them, we believe most of them work more or less.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220214234033.1052681-1-linus.walleij@linaro.orgSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Buttonpads are expected to map the INPUT_PROP_BUTTONPAD property bit
and the BTN_LEFT key bit.

As explained in the specification, where a device has a button type
value of 0 (click-pad) or 1 (pressure-pad) there should not be
discrete buttons:
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report

However, some drivers map the BTN_RIGHT and/or BTN_MIDDLE key bits even
though the device is a buttonpad and therefore does not have those
buttons.

This behavior has forced userspace applications like libinput to
implement different workarounds and quirks to detect buttonpads and
offer to the user the right set of features and configuration options.
For more information:
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/726

In order to avoid this issue clear the BTN_RIGHT and BTN_MIDDLE key
bits when the input device is register if the INPUT_PROP_BUTTONPAD
property bit is set.

Notice that this change will not affect udev because it does not check
for buttons. See systemd/src/udev/udev-builtin-input_id.c.

List of known affected hardware:

 - Chuwi AeroBook Plus
 - Chuwi Gemibook
 - Framework Laptop
 - GPD Win Max
 - Huawei MateBook 2020
 - Prestigio Smartbook 141 C2
 - Purism Librem 14v1
 - StarLite Mk II   - AMI firmware
 - StarLite Mk II   - Coreboot firmware
 - StarLite Mk III  - AMI firmware
 - StarLite Mk III  - Coreboot firmware
 - StarLabTop Mk IV - AMI firmware
 - StarLabTop Mk IV - Coreboot firmware
 - StarBook Mk V
Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/20220208174806.17183-1-jose.exposito89@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Prepare input updates for 5.17 merge window.

change 'postion' to 'position'
Signed-off-by: NQinghua Jin <qhjin.dev@gmail.com>
Link: https://lore.kernel.org/r/20220106084215.355295-1-qhjin.dev@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Zinitix BT532 is another touch controller that seem to implement the
same interface as an already supported BT541. Add it to the driver.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NNikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-5-nikita@trvn.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The supply names of the Zinitix touchscreen were a bit confused, the new
bindings rectifies this.

To deal with old and new devicetrees, first check if we have "vddo" and in
case that exists assume the old supply names. Else go and look for the new
ones.

We cannot just get the regulators since we would get an OK and a dummy
regulator: we need to check explicitly for the old supply name.

Use struct device *dev as a local variable instead of the I2C client since
the device is what we are actually obtaining the resources from.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
[Slightly changed the legacy regulator detection]
Signed-off-by: NNikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-4-nikita@trvn.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This converts the Zinitix BT4xx and BT5xx touchscreen bindings to YAML,
fix them up a bit and extends them.

We list all the existing BT4xx and BT5xx components with compatible
strings.  These are all similar, use the same bindings and work in
similar ways.

We rename the supplies from the erroneous vdd/vddo to the actual supply
names vcca/vdd as specified on the actual component. It is long
established that supplies shall be named after the supply pin names of a
component.  The confusion probably stems from that in a certain product
the rails to the component were named vdd/vddo. Drop some notes on how OS
implementations should avoid confusion by first looking for vddo, and if
that exists assume the legacy binding pair and otherwise use vcca/vdd.

Add reset-gpios as sometimes manufacturers pulls a GPIO line to the reset
line on the chip.

Add optional touchscreen-fuzz-x and touchscreen-fuzz-y properties.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
[Fixed dt_schema_check]
Signed-off-by: NNikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-3-nikita@trvn.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Since irq request is the last thing in the driver probe, it happens
later than the input device registration. This means that there is a
small time window where if the open method is called the driver will
attempt to enable not yet available irq.

Fix that by moving the irq request before the input device registration.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Fixes: 26822652 ("Input: add zinitix touchscreen driver")
Signed-off-by: NNikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The power button on Cherry Trail systems with an AXP288 PMIC is connected
to both the power button pin of the PMIC as well as to a power button GPIO
on the Cherry Trail SoC itself. This leads to double power button event
reporting which is a problem.

Since reporting power button presses through the PMIC is not supported on
all PMICs used on Cherry Trail systems, we want to keep the GPIO
power button events, so the axp20x-pek code checks for the presence of
a GPIO power button and in that case does not register its input-device.

On most systems the GPIO power button also can wake-up the system from
suspend, so the axp20x-pek driver would also not register its interrupt
handler. But on some systems there was a bug causing wakeup by the GPIO
power button handler to not work.

Commit 9747070c ("Input: axp20x-pek - always register interrupt
handlers") was added as a work around for this registering the axp20x-pek
interrupts, but not the input-device on Cherry Trail systems.

In the mean time the root-cause of the GPIO power button wakeup events
not working has been found and fixed by the "pinctrl: cherryview: Do not
allow the same interrupt line to be used by 2 pins" patch,
so this is no longer necessary.

This reverts the workaround going back to only registering the
interrupt handlers on systems where we also register the input-device.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20220106111647.66520-1-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

bitmap_parselist() already clears the 'bits' bitmap, so there is no need
to clear it when it is allocated. This just wastes some cycles.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/d6ee621b9dd75b92f8831db365cee58dc2025322.1640813136.git.christophe.jaillet@wanadoo.frSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The spaceball.c module was not properly parsing the movement reports
coming from the device.  The code read axis data as signed 16-bit
little-endian values starting at offset 2.

In fact, axis data in Spaceball movement reports are signed 16-bit
big-endian values starting at offset 3.  This was determined first by
visually inspecting the data packets, and later verified by consulting:
http://spacemice.org/pdf/SpaceBall_2003-3003_Protocol.pdf

If this ever worked properly, it was in the time before Git...
Signed-off-by: NLeo L. Schwab <ewhac@ewhac.org>
Link: https://lore.kernel.org/r/20211221101630.1146385-1-ewhac@ewhac.org
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Syzbot has reported warning in __flush_work(). This warning is caused by
work->func == NULL, which means missing work initialization.

This may happen, since input_dev->close() calls
cancel_work_sync(&dev->work), but dev->work initalization happens _after_
input_register_device() call.

So this patch moves dev->work initialization before registering input
device

Fixes: 5a6eb676 ("Input: appletouch - improve powersaving for Geyser3 devices")
Reported-and-tested-by: syzbot+b88c5eae27386b252bbd@syzkaller.appspotmail.com
Signed-off-by: NPavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/20211230141151.17300-1-paskripkin@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The eKTH3900/eKTH5312 series do not support the firmware update rules of
Remark ID. Exclude these two series from checking it when updating the
firmware in touch controllers.
Signed-off-by: NJohnny Chuang <johnny.chuang.emc@gmail.com>
Link: https://lore.kernel.org/r/1639619603-20616-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The double `the' in a comment is repeated, thus it should be removed.
Signed-off-by: NXiang wangx <wangxiang@cdjrlc.com>
Link: https://lore.kernel.org/r/20211216082735.11948-1-wangxiang@cdjrlc.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Variable penup is assigned a value but penup is never read later, it
is redundant and can be removed.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211205000525.153999-1-colin.i.king@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The open delay time has to be applied only on the first sample of the
X/Y coordinates because on the following samples the ADC channel is not
changed. Removing this time from the samples after the first one,
"ti,coordinate-readouts" greater than 1, decreases the total acquisition
time, allowing to increase the number of acquired coordinates in the time
unit.
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20211212125358.14416-4-dariobin@libero.itSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Z2 step configuration doesn't erase the SEL_INP_SWC_3_0 bit-field
before setting the ADC channel. This way its value could be corrupted by
the ADC channel selected for the Z1 coordinate.

Fixes: 8c896308 ("input: ti_am335x_adc: use only FIFO0 and clean up a little")
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20211212125358.14416-3-dariobin@libero.itSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

As reported by the STEPCONFIG[1-16] registered field descriptions of the
TI reference manual, for the ADC "in single ended, SEL_INM_SWC_3_0 must
be 1xxx".

Unlike the Y and Z coordinates, this bit has not been set for the step
configuration registers used to sample the X coordinate.

Fixes: 1b8be32e ("Input: add support for TI Touchscreen controller")
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20211212125358.14416-2-dariobin@libero.itSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some Silead touchscreens have support for an active (battery powered)
pen, add support for this.

So far pen-support has only been seen on X86/ACPI (non devicetree) devs,
IOW it is not used in actual devicetree files. The devicetree-bindings
maintainers have requested properties like these to not be added to the
devicetree-bindings, so the new properties are deliberately not added
to the existing silead devicetree-bindings documentation.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211122220637.11386-3-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unfortunately, at the time of writing this commit message, we have been
unable to get permission from Silead, or from device OEMs, to distribute
the necessary Silead firmware files in linux-firmware.

On a whole bunch of devices the UEFI BIOS code contains a touchscreen
driver, which contains an embedded copy of the firmware. The fw-loader
code has a "platform" fallback mechanism, which together with info on the
firmware from drivers/platform/x86/touchscreen_dmi.c will use the firmware
from the UEFI driver when the firmware is missing from /lib/firmware. This
makes the touchscreen work OOTB without users needing to manually download
the firmware.

The firmware bundled with the original Windows/Android is usually newer
then the firmware in the UEFI driver and it is better calibrated. This
better calibration can lead to significant differences in the reported
min/max coordinates.

Add support for a new (optional) "silead,efi-fw-min-max" property which
provides a set of alternative min/max values to use for the x/y axis when
the EFI embedded firmware is used.

The new property is only used on (x86) devices which do not use devicetree,
IOW it is not used in actual devicetree files. The devicetree-bindings
maintainers have requested properties like these to not be added to the
devicetree-bindings, so the new property is deliberately not added to the
existing silead devicetree-bindings documentation.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211122220637.11386-2-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

2 small fixes for pen support

1. Set the id.vendor field for the pen input_dev
2. Fix a typo in a comment
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211212124242.81019-5-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

goodix_get_gpio_config() errors are fatal (abort probe()) so log them
at KERN_ERR level rather then as debug messages.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211212124242.81019-4-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The "id_buf" buffer is stored in "data->raw_info_block" and freed by
"mxt_free_object_table" in case of error.

Return instead of jumping to avoid a double free.

Addresses-Coverity-ID: 1474582 ("Double free")
Fixes: 068bdb67 ("Input: atmel_mxt_ts - fix the firmware update")
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/20211212194257.68879-1-jose.exposito89@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Addresses-Coverity-ID: 1493934 ("Resource leak")
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/20211208173321.26659-1-jose.exposito89@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some Goodix touchscreens have support for a (Goodix) active pen, add
support for this. The info on how to detect when a pen is down and to
detect when the stylus buttons are pressed was lifted from the out
of tree Goodix driver with pen support written by Adya:
https://gitlab.com/AdyaAdya/goodix-touchscreen-linux-driver/

Since there is no way to tell if pen support is present, the registering
of the pen input_dev is delayed till the first pen event is detected.

This has been tested on a Trekstor Surftab duo W1, a Chuwi Hi13 and
a Cyberbook T116 tablet.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=202161
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204513Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211207100754.31155-3-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Sync up with the mainline to get the latest APIs and DT bindings.

Add d->model mapping for the "9111" model, this fixes uses using
a wrong config_len of 240 bytes while the "9111" model uses
only 186 bytes of config.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211206164747.197309-2-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When converting a rumble into a periodic effect, for compatibility,
the magnitude is effectively calculated using:

magnitude = max(strong_rubble / 3 + weak_rubble / 6, 0x7fff);

The rumble magnitudes are both u16 and the resulting magnitude is
s16. The max is presumably an attempt to limit the result of the
calculation to the maximum possible magnitude for the s16 result,
and thus should be a min.

However in the case of strong = weak = 0xffff, the result of the first
part of the calculation is 0x7fff, meaning that the min would be
redundant anyway, so simply remove the current max.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20211130135039.13726-1-ckeepax@opensource.cirrus.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Don't populate a couple of arrays on the stack but instead make them
static const. Also makes the object code smaller by a few hundred
bytes.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211129231749.619469-1-colin.i.king@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unless the controller is not responding at boot or after suspend/resume,
the driver never resets the controller on x86/ACPI platforms. The driver
still requesting the reset pin at probe() though in case it needs it.

Until now the driver has always requested the reset pin with GPIOD_IN
as type. The idea being to put the pin in high-impedance mode to save
power until the driver actually wants to issue a reset.

But this means that just requesting the pin can cause issues, since
requesting it in another mode then GPIOD_ASIS may cause the pinctrl
driver to touch the pin settings. We have already had issues before
due to a bug in the pinctrl-cherryview.c driver which has been fixed in
commit 921daeec ("pinctrl: cherryview: Preserve
CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs").

And now it turns out that requesting the reset-pin as GPIOD_IN also stops
the touchscreen from working on the GPD P2 max mini-laptop. The behavior
of putting the pin in high-impedance mode relies on there being some
external pull-up to keep it high and there seems to be no pull-up on the
GPD P2 max, causing things to break.

This commit fixes this by requesting the reset pin as is when using
the x86/ACPI code paths to lookup the GPIOs; and by not dropping it
back into input-mode in case the driver does end up issuing a reset
for error-recovery.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209061
Fixes: a7d4b171 ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices")
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211206091116.44466-2-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The ASUS UM325UA suffers from the same issue as the ASUS UX425UA, which
is a very similar laptop. The i8042 device is not usable immediately
after boot and fails to initialize, requiring a deferred retry.

Enable the deferred probe quirk for the UM325UA.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256Signed-off-by: NSamuel Čavoj <samuel@cavoj.net>
Link: https://lore.kernel.org/r/20211204015615.232948-1-samuel@cavoj.netSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Improve the query device fields to be more verbose.
Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20211118123545.102872-1-alistair@alistair23.meSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:

[    6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[    6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118

[    6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[    6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[    6.512436] Workqueue: events_long serio_handle_event
[    6.512453] Call Trace:
[    6.512462]  show_stack+0x52/0x58
[    6.512474]  dump_stack+0xa1/0xd3
[    6.512487]  print_address_description.constprop.0+0x1d/0x140
[    6.512502]  ? __ps2_command+0x372/0x7e0
[    6.512516]  __kasan_report.cold+0x7d/0x112
[    6.512527]  ? _raw_write_lock_irq+0x20/0xd0
[    6.512539]  ? __ps2_command+0x372/0x7e0
[    6.512552]  kasan_report+0x3c/0x50
[    6.512564]  __asan_load1+0x6a/0x70
[    6.512575]  __ps2_command+0x372/0x7e0
[    6.512589]  ? ps2_drain+0x240/0x240
[    6.512601]  ? dev_printk_emit+0xa2/0xd3
[    6.512612]  ? dev_vprintk_emit+0xc5/0xc5
[    6.512621]  ? __kasan_check_write+0x14/0x20
[    6.512634]  ? mutex_lock+0x8f/0xe0
[    6.512643]  ? __mutex_lock_slowpath+0x20/0x20
[    6.512655]  ps2_command+0x52/0x90
[    6.512670]  elantech_ps2_command+0x4f/0xc0 [psmouse]
[    6.512734]  elantech_change_report_id+0x1e6/0x256 [psmouse]
[    6.512799]  ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[    6.512863]  ? ps2_command+0x7f/0x90
[    6.512877]  elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[    6.512943]  ? elantech_setup_ps2+0x460/0x460 [psmouse]
[    6.513005]  ? psmouse_reset+0x69/0xb0 [psmouse]
[    6.513064]  ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[    6.513122]  ? phys_pmd_init+0x30e/0x521
[    6.513137]  elantech_init+0x8a/0x200 [psmouse]
[    6.513200]  ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[    6.513249]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513296]  ? synaptics_send_cmd+0x60/0x60 [psmouse]
[    6.513342]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513388]  ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[    6.513432]  psmouse_extensions+0x65d/0x6e0 [psmouse]
[    6.513476]  ? psmouse_try_protocol+0x170/0x170 [psmouse]
[    6.513519]  ? mutex_unlock+0x22/0x40
[    6.513526]  ? ps2_command+0x7f/0x90
[    6.513536]  ? psmouse_probe+0xa3/0xf0 [psmouse]
[    6.513580]  psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[    6.513624]  psmouse_connect+0x272/0x530 [psmouse]
[    6.513669]  serio_driver_probe+0x55/0x70
[    6.513679]  really_probe+0x190/0x720
[    6.513689]  driver_probe_device+0x160/0x1f0
[    6.513697]  device_driver_attach+0x119/0x130
[    6.513705]  ? device_driver_attach+0x130/0x130
[    6.513713]  __driver_attach+0xe7/0x1a0
[    6.513720]  ? device_driver_attach+0x130/0x130
[    6.513728]  bus_for_each_dev+0xfb/0x150
[    6.513738]  ? subsys_dev_iter_exit+0x10/0x10
[    6.513748]  ? _raw_write_unlock_bh+0x30/0x30
[    6.513757]  driver_attach+0x2d/0x40
[    6.513764]  serio_handle_event+0x199/0x3d0
[    6.513775]  process_one_work+0x471/0x740
[    6.513785]  worker_thread+0x2d2/0x790
[    6.513794]  ? process_one_work+0x740/0x740
[    6.513802]  kthread+0x1b4/0x1e0
[    6.513809]  ? set_kthread_struct+0x80/0x80
[    6.513816]  ret_from_fork+0x22/0x30

[    6.513832] The buggy address belongs to the page:
[    6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[    6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[    6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[    6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[    6.513872] page dumped because: kasan: bad access detected

[    6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame:
[    6.513887]  elantech_change_report_id+0x0/0x256 [psmouse]

[    6.513941] this frame has 1 object:
[    6.513947]  [32, 34) 'param'

[    6.513956] Memory state around the buggy address:
[    6.513962]  ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00
[    6.513969]  ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00
[    6.513982]                                            ^
[    6.513988]  ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    6.513995]  ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00
[    6.514000] ==================================================================

Define param[] in elantech_change_report_id() as an array of 3 bytes to
prevent the out-of-bounds access in the stack.

Fixes: e4c90627 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
BugLink: https://bugs.launchpad.net/bugs/1945590Signed-off-by: NAndrea Righi <andrea.righi@canonical.com>
Reviewed-by: NWolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use the FIELD_PREP() helper, instead of open-coding the same operation.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/f8831b88346b36fc6e01e0910d0db6c94287d2b4.1637593297.git.geert+renesas@glider.beSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some automated builds report a stack frame size in excess of 2 kB for
iqs626_probe(); the culprit appears to be the call to iqs626_parse_prop().

To solve this problem, specify noinline_for_stack for all of the
iqs626_parse_*() helper functions which are called inside a for loop
within iqs626_parse_prop().

As a result, a build with '-Wframe-larger-than' as low as 512 is free of
any such warnings.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NJeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20211129004104.453930-1-jeff@labundy.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We've got a bug report about the non-working keyboard on ASUS ZenBook
UX425UA.  It seems that the PS/2 device isn't ready immediately at
boot but takes some seconds to get ready.  Until now, the only
workaround is to defer the probe, but it's available only when the
driver is a module.  However, many distros, including openSUSE as in
the original report, build the PS/2 input drivers into kernel, hence
it won't work easily.

This patch adds the support for the deferred probe for i8042 stuff as
a workaround of the problem above.  When the deferred probe mode is
enabled and the device couldn't be probed, it'll be repeated with the
standard deferred probe mechanism.

The deferred probe mode is enabled either via the new option
i8042.probe_defer or via the quirk table entry.  As of this patch, the
quirk table contains only ASUS ZenBook UX425UA.

The deferred probe part is based on Fabio's initial work.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Tested-by: NSamuel Čavoj <samuel@cavoj.net>
Link: https://lore.kernel.org/r/20211117063757.11380-1-tiwai@suse.deSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Prepare input updates for 5.16 merge window.

USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.

Fixes: 48735862 ("Input: iforce - use DMA-safe buffer when getting IDs from USB")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Cc: stable@vger.kernel.org      # 5.3
Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.orgSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

To make the code easier to read use macros for the bit masks.
Signed-off-by: NAlistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20211009113707.17568-2-alistair@alistair23.meSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>