Merge for-linus branch to sync Elan touchscreen driver code.

This patch adds support for the Azoteq IQS269A capacitive touch
controller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/1588352982-5117-2-git-send-email-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds device tree bindings for the Azoteq IQS269A
capacitive touch controller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1588352982-5117-1-git-send-email-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Use devm_add_action_or_reset() to handle all cleanups of failure in
.probe and .remove, then .remove callback can be dropped.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1584082751-17047-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The address referenced by this driver is within the Qualcomm Clock
namespace so let's drop the msm-vibrator bindings so that a more generic
solution can be used instead.  No one is currently using driver so this
won't affect any users.
Signed-off-by: Brian Masney <masneyb@onstation.org>
Link: https://lore.kernel.org/r/20200513013140.69935-3-masneyb@onstation.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The address referenced in this binding is within the Qualcomm Clock
namespace so let's drop the msm-vibrator bindings so that a more
generic solution can be used instead.  No one is currently using these
bindings so this won't affect any users.
Signed-off-by: Brian Masney <masneyb@onstation.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200513013140.69935-2-masneyb@onstation.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

There is an non-touch case by non-calibration after update firmware.
Elan could know calibrate or not by calibration count.
The value of '0xffff' means we didn't calibrate after update firmware.
If calibrate success, it will plus one and change to '0x0000'.
Signed-off-by: Johnny Chuang <johnny.chuang@emc.com.tw>
Link: https://lore.kernel.org/r/1588754932-5902-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

input_mt_report_slot_state() ignores "tool" argument when the slot is
closed, which has caused a bit of confusion. Let's introduce
input_mt_report_slot_inactive() to report inactive slot state.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Link: https://lore.kernel.org/r/20200508055656.96389-2-jiada_wang@mentor.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Convert elants_i2c.txt DT binding to YAML and put into correct directory.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200423173253.711725-2-david@ixit.czSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Sync up with mainline to get device tree and other changes.

This adds a new driver for the Cypress CY8CTMA140 touchscreen.

This driver is inspired by out-of-tree code for the Samsung
GT-S7710 mobile phone.

I have tried to compare the structure and behaviour of this
touchscreen to the existing CYTTSP and CYTTSP4 generics and
it seems pretty different. It is also different in character
from the cy8ctmg110_ts.c. It appears to rather be vaguely
related to the Melfas MMS114 driver, yet distinctly
different.

Dmitry Torokhov rewrote the key scanning code during the
submission process so the driver is a joint work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200506123435.187432-2-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This adds device tree bindings for the Cypress CY8CTMA140 touchscreen.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200506123435.187432-1-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507185347.GA14499@embeddedorSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Probing the device takes a while, because we sleep for 300 ms after a
reset; allow asynchronous probing so this can happen in the background
while other devices are being probed.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20200227112819.16754-5-m.felsch@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

It is possible to bring the device into a deep sleep state. To exit this
state the reset or wakeup pin must be toggeled as documented in [1].
Because of the poor documentation I used the several downstream kernels
[2] and other applications notes [3] to indentify the related registers.

Furthermore I added the support to disable the device completely which
is obviously the most effective power-saving mechanism. This mechanism
needs the reset pin to ensure the power-up/down sequence.

We can't apply any of these power-saving mechanism if both pins are
missing (not connected) or if it is a wakeup device.

[1] https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x26.pdf
    https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x06.pdf
[2] https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/input/touchscreen/ft5x_ts.c
    https://github.com/Pablito2020/focaltech-touch-driver/blob/master/ft5336_driver.c
[3] https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x16_registers.pdfSigned-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20200227112819.16754-4-m.felsch@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We need to restore the parameters if we switch between the
factory/work mode and during the resume process if we switched off the
power-supply. Therefore refactor edt_ft5x06_work_mode() and move the
"restore the parameters" into a helper routine so we can reuse it later.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20200227112819.16754-3-m.felsch@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Since commit b6eba860 ("Input: edt-ft5x06 - add offset support for
ev-ft5726") offset-x and offset-y is supported. Devices using those
offset parameters don't support the offset parameter so we need to add
the NO_REGISTER check for edt_ft5x06_ts_get_defaults().

Fixes: b6eba860 ("Input: edt-ft5x06 - add offset support for ev-ft5726")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20200227112819.16754-2-m.felsch@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

On some X86 devices we do not register an input-device, because the
power-button is also handled by the soc_button_array (GPIO) input driver,
and we want to avoid reporting power-button presses to userspace twice.

Sofar when we did this we also did not register our interrupt handlers,
since those were only necessary to report input events.

But on at least 2 device models the Medion Akoya E1239T and the GPD win,
the GPIO pin used by the soc_button_array driver for the power-button
cannot wakeup the system from suspend. Why this does not work is not clear,
I've tried comparing the value of all relevant registers on the Cherry
Trail SoC, with those from models where this does work. I've checked:
PMC registers: FUNC_DIS, FUNC_DIS2, SOIX_WAKE_EN, D3_STS_0, D3_STS_1,
D3_STDBY_STS_0, D3_STDBY_STS_1; PMC ACPI I/O regs: PM1_STS_EN, GPE0a_EN
and they all have identical contents in the working and non working cases.
I suspect that the firmware either sets some unknown register to a value
causing this, or that it turns off a power-plane which is necessary for
GPIO wakeups to work during suspend.

What does work on the Medion Akoya E1239T is letting the AXP288 wakeup
the system on a power-button press (the GPD win has a different PMIC).

Move the registering of the power-button press/release interrupt-handler
from axp20x_pek_probe_input_device() to axp20x_pek_probe() so that the
PMIC will wakeup the system on a power-button press, even if we do not
register an input device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200426155757.297087-1-hdegoede@redhat.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The 'pengutronix' address is defunct for years. Use the proper contact
address.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20200502142639.18925-1-wsa@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Fix to return a negative error code from the input_register_device()
error handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Fix a use-after-free noticed by running with KASAN enabled. If
rmi_irq_fn() is run twice in a row, then rmi_f11_attention() (among
others) will end up reading from drvdata->attn_data.data, which was
freed and left dangling in rmi_irq_fn().

Commit 55edde9f ("Input: synaptics-rmi4 - prevent UAF reported by
KASAN") correctly identified and analyzed this bug. However the attempted
fix only NULLed out a local variable, missing the fact that
drvdata->attn_data is a struct, not a pointer.

NULL out the correct pointer in the driver data to prevent the attention
functions from copying from it.

Fixes: 55edde9f ("Input: synaptics-rmi4 - prevent UAF reported by KASAN")
Fixes: b908d3cd ("Input: synaptics-rmi4 - allow to add attention data")
Signed-off-by: Evan Green <evgreen@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeidSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version
"GDETC1WW (1.81 ) 06/27/2019", the keyboard, Synaptics TouchPad, and
TrackPoint either do not function or stop functioning a few minutes
after boot.  This problem has been noted before, perhaps only occurring
with BIOS 1.57 and later.[1][2][3][4][5]

Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago
and although the [BIOS changelog] notes "Fixed an issue of UEFI
touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be
insufficient.

Setting i8042.reset=1 or adding 33474HU to the reset list avoids the
issue on my system from either warm or cold boot.

[1]: https://bugs.launchpad.net/bugs/1210748
[2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425
[3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200
[4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115
[5]: https://forums.lenovo.com/topic/findpost/27/1337119
[BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txtSigned-off-by: Kevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.nameSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 18931506. From Kevin
Locke:

"... nomux only appeared to fix the issue because the controller
continued working after warm reboots. After more thorough testing from
both warm and cold start, I now believe the entry should be added to
i8042_dmi_reset_table rather than i8042_dmi_nomux_table as i8042.reset=1
alone is sufficient to avoid the issue from both states while
i8042.nomux is not."

Allow the firmware to specify the mapping between the scan code and the
linux keycode. This takes the form of a "linux,keymap" property which is
an array of u32 values, each value specifying mapping for a key.
Signed-off-by: Rajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20200427210259.91330-3-rajatja@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Certain keyboards have their top-row keys intended for actions such as
"Browser back", "Browser Refresh", "Fullscreen" etc as their primary mode,
thus they will send scan codes for those actions. Further, they don't
have a dedicated "Fn" key so don't have the capability to generate
function key codes (e.g. F1, F2 etc..).  However in this case, if
userspace still wants to "synthesize" those function keys using the top
row action keys, it needs to know the physical position of the top row
keys. (Essentially a mapping between usage codes and a physical location
in the top row).

This patch enhances the atkbd driver to receive such a mapping from the
firmware / device tree, and expose it to userspace in the form of a
function-row-physmap attribute. The attribute would be a space separated
ordered list of physical codes, for the keys in the function row, in
left-to-right order.

The attribute will only be present if the kernel knows about such mapping,
otherwise the attribute shall not be visible.
Signed-off-by: Rajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20200427210259.91330-2-rajatja@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Attach the firmware node to the serio i8042 kbd device so that device
properties can be passed from the firmware.
Signed-off-by: Rajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20200427210259.91330-1-rajatja@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

MMS345L is another first generation touch screen from Melfas,
which uses mostly the same registers as MMS152.

However, there is some garbage printed during initialization.
Apparently MMS345L does not have the MMS152_COMPAT_GROUP register
that is read+printed during initialization.

  TSP FW Rev: bootloader 0x6 / core 0x26 / config 0x26, Compat group: \x06

On earlier kernel versions the compat group was actually printed as
an ASCII control character, seems like it gets escaped now.

But we probably shouldn't print something from a random register.

Add a separate "melfas,mms345l" compatible that avoids reading
from the MMS152_COMPAT_GROUP register. This might also help in case
there is some other device-specific quirk in the future.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://lore.kernel.org/r/20200423102431.2715-1-stephan@gerhold.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The mms114 driver now supports MMS345L; document the
melfas,mms345l binding that is used for it.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andi Shyti <andi@etezian.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200423102431.2715-2-stephan@gerhold.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

According to the file name and Kconfig, a 'k' is missing in this driver
name. It should be "dlink-dir685-touchkeys".

Fixes: 131b3de7 ("Input: add D-Link DIR-685 touchkeys driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200412213937.5287-1-christophe.jaillet@wanadoo.frSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Sending [ 0x05, 0x20, 0x00, 0x0f, 0x06 ] packet for Xbox One S controllers
fixes an issue where controller is stuck in Bluetooth mode and not sending
any inputs.
Signed-off-by: Łukasz Patron <priv.luk@gmail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

input_flush_device() should only be called once the struct file is being
released and no open descriptors remain, but evdev_flush() was calling
it whenever a file descriptor was closed.

This caused uploaded force-feedback effects to be erased when a process
did a dup()/close() on the event FD, called system(), etc.

Call input_flush_device() from evdev_release() instead.
Reported-by: Mathieu Maret <mathieu.maret@gmail.com>
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version
"GDETC1WW (1.81 ) 06/27/2019", whether booted in UEFI or Legacy/CSM mode
the keyboard, Synaptics TouchPad, and TrackPoint either do not function
or stop functioning a few minutes after boot.  This problem has been
noted before, perhaps only occurring on BIOS 1.57 and
later.[1][2][3][4][5]

This model does not have an external PS/2 port, so mux does not appear
to be useful.

Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago
and although the [BIOS changelog] notes "Fixed an issue of UEFI
touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be
insufficient.

Adding 33474HU to the nomux list avoids the issue on my system.

[1]: https://bugs.launchpad.net/bugs/1210748
[2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425
[3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200
[4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115
[5]: https://forums.lenovo.com/topic/findpost/27/1337119
[BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txtSigned-off-by: Kevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/feb8a8339a67025dab3850e6377eb6f3a0e782ba.1587400635.git.kevin@kevinlocke.nameSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

There is now an IIO driver for GP2AP002A00F and GP2AP002S00F in
drivers/iio/light/gp2ap002.c.

Delete this driver, it is unused in the kernel tree and new users can make
use of the IIO driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200417203059.8151-1-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP.
As evdev uses unkeyed wakeups, such a poll receives many spurious
wakeups from uninteresting events.

Use keyed wakeups to allow the wakeup target to more efficiently discard
these uninteresting events.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Link: https://lore.kernel.org/r/20200410233557.3892-1-kl@kl.wtfSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

A 'y' is missing in spear-keyboard.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200412095711.9107-1-christophe.jaillet@wanadoo.frSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This should be 'tca6416', not 'tca6146'
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200413152329.4435-1-christophe.jaillet@wanadoo.frSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Based on available information this uses the singletouch irtouch
protocol. This is tested and confirmed to be fully functional on
the BonXeon TP hardware I have.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://lore.kernel.org/r/20200413184217.55700-1-james.hilliard1@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case there is no advantage of doing this
apart from that we want to make cros_ec_cmd_xfer() a private function
for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200414210434.1534982-1-enric.balletbo@collabora.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

MMS345L is another first generation touch screen from Melfas,
which uses the same registers as MMS152.

However, using I2C_M_NOSTART for it causes errors when reading:

	i2c i2c-0: sendbytes: NAK bailout.
	mms114 0-0048: __mms114_read_reg: i2c transfer failed (-5)

The driver works fine as soon as I2C_M_NOSTART is removed.
Reviewed-by: Andi Shyti <andi@etezian.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200405170904.61512-1-stephan@gerhold.net
[dtor: removed separate mms345l handling, made everyone use standard
transfer mode, propagated the 10bit addressing flag to the read part of the
transfer as well.]
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Elan uses the least significant bit of byte 33 to signal the type of
contact (finger versus palm). The default value is 1 for all firmwares,
which is reported as MT_TOOL_FINGER. If firmware supports palm detection,
the bit will change to 0 and the driver will report such contact as
MT_TOOL_PALM.
Signed-off-by: Johnny Chuang <johnny.chuang@emc.com.tw>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://lore.kernel.org/r/1585551756-29066-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>