Since day one the touch controller acts as wakeup-source. This seems to
be wrong since the device supports deep-sleep mechanism [1] which
requires a reset to leave it. Also some designs won't use the
touchscreen as wakeup-source.

According discussion [2] we decided to break backward compatibility and
go the common way by using the 'wakeup-source' device-property.

[1] https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x26.pdf
[2] https://patchwork.kernel.org/patch/11149037/Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The current driver behaviour was to enable the wakeup-source everytime.
After discussion [1] we decided to change that behaviour so the device
will act as wakeup-source only if the "wakeup-source" dt-property is
present.

The patch adds the binding documentation to enable the wakeup-source
capability.

[1] https://patchwork.kernel.org/patch/11149037/Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

It seems that the include order is historical increased and no one takes
care of it. Fix this to align it with the common rule to be in a
alphabetical order.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The EP0700MLP1 returns bogus data on the first register read access
(reading the threshold parameter from register 0x00):

    edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40

It ignores writes until then. This patch adds a dummy read after which
the number of sensors and parameter read/writes work correctly.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add __iomem to the apbps2_priv.regs field to make the numerous
warnings about differing address spaces go away. Fixes warnings
such as:

drivers/input/serio/apbps2.c:65:26: warning: incorrect type in argument 1 (different address spaces)
drivers/input/serio/apbps2.c:65:26:    expected void const volatile [noderef] <asn:2> *addr
drivers/input/serio/apbps2.c:65:26:    got unsigned int [noderef] *
drivers/input/serio/apbps2.c:65:26: warning: incorrect type in argument 1 (different address spaces)
drivers/input/serio/apbps2.c:65:26:    expected void const volatile [noderef] <asn:2> *addr
drivers/input/serio/apbps2.c:65:26:    got unsigned int [noderef] *
drivers/input/serio/apbps2.c:65:26: warning: incorrect type in argument 1 (different address spaces)
drivers/input/serio/apbps2.c:65:26:    expected void const volatile [noderef] <asn:2> *addr
drivers/input/serio/apbps2.c:65:26:    got unsigned int [noderef] *
drivers/input/serio/apbps2.c:65:26: warning: incorrect type in argument 1 (different address spaces)
drivers/input/serio/apbps2.c:65:26:    expected void const volatile [noderef] <asn:2> *addr
[rest snipped]
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20191217122507.2157454-1-ben.dooks@codethink.co.ukSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The two device attrbitues are not declared outside this file
so make them static to avoid the following warnings:

drivers/input/misc/axp20x-pek.c:194:1: warning: symbol 'dev_attr_startup' was not declared. Should it be static?
drivers/input/misc/axp20x-pek.c:195:1: warning: symbol 'dev_attr_shutdown' was not declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20191217152541.2167080-1-ben.dooks@codethink.co.ukSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

To avoid flashing incompatible firmware onto a device we should check
whether "Remark ID" in firmware matches with the one in the controller.
This function is supported by Elan's latest version of boot code, so the
driver decides whether to perform the check based on the boot code version.
Signed-off-by: Johnny Chuang <johnny.chuang@emc.com.tw>
Link: https://lore.kernel.org/r/00a901d5af3c$193e9cd0$4bbbd670$@emc.com.twSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This increment of rmi_smbus in rmi_smb_read/write_block() causes
garbage to be read/written.

The first read of SMB_MAX_COUNT bytes is fine, but after that
it is nonsense. Trial-and-error showed that by dropping the
increment of rmiaddr everything is fine and the F54 function
properly works.

I tried a hack with rmi_smb_write_block() as well (writing to the
same F54 touchpad data area, then reading it back), and that
suggests that there too the rmiaddr increment has to be dropped.
It makes sense that if it has to be dropped for read, then it has
to be dropped for write as well.

It looks like the initial work with F54 was done using i2c, not smbus,
and it seems nobody ever tested F54 with smbus. The other functions
all read/write less than SMB_MAX_COUNT as far as I can tell, so this
issue was never noticed with non-F54 functions.

With this change I can read out the touchpad data correctly on my
Lenovo X1 Carbon 6th Gen laptop.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

F34 is a bit special as it reinitializes the device and related driver
structs during the firmware update. This clears the fn_irq_mask which
will then prevent F34 from receiving further interrupts, leading to
timeouts during the firmware update. Make sure to reinitialize the
IRQ enables at the appropriate times.

The issue is in F34 code, but the commit in the fixes tag exposed the
issue, as before this commit things would work by accident.

Fixes: 363c5387 (Input: synaptics-rmi4 - avoid processing unknown IRQs)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The touchscreen on the Teclast X89 is mounted upside down in relation to
the display orientation (the touchscreen itself is mounted upright, but the
display is mounted upside-down). Add a quirk for this so that we send
coordinates which match the display orientation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20191202085636.6650-1-hdegoede@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add keycode for toggling electronic privacy screen to the keycodes
definition. Some new laptops have a privacy screen which can be toggled
with a key on the keyboard.
Signed-off-by: Mathew King <mathewk@chromium.org>
Link: https://lore.kernel.org/r/20191017163208.235518-1-mathewk@chromium.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Always return EPOLLOUT from uinput_poll to allow polling /dev/uinput
for writable state.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Link: https://lore.kernel.org/r/20191204025014.5189-1-marcel@holtmann.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Gratuitous NULL initializers rarely help and often prevent compiler
from warning about using uninitialized variable. Let's remove them.
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/20191125211407.GA97812@dtor-wsSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The first generation i.MX6 processors does not send an interrupt when the
power key is pressed. It sends a power down request interrupt if the key is
released before a hard shutdown (5 second press). This should allow
software to bring down the SoC safely.

For this driver to work as a regular power key with the older SoCs, we need
to send a keypress AND release when we get the power down request irq.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Link: https://lore.kernel.org/r/20191125161210.8275-1-robin@protonic.nlSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The v4l2-compliance utility reported several V4L2 API compliance
issues:

- the sequence counter wasn't filled in
- the sequence counter wasn't reset to 0 at the start of streaming
- the returned field value wasn't set to V4L2_FIELD_NONE
- the timestamp wasn't set
- the payload size was undefined if an error was returned
- min_buffers_needed doesn't need to be initialized

Fix these issues.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de
Link: https://lore.kernel.org/r/20191119105118.54285-3-hverkuil-cisco@xs4all.nlSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this
to the smbus_pnp_ids list.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191119105118.54285-2-hverkuil-cisco@xs4all.nlSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
	$ sed -e 's/^        /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/1574306373-29581-1-git-send-email-krzk@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The SCU message's data field used for receiving response data from SCU
should be 32-bit width, as SCU will send back 32-bit width data.

This solves kernel panic when CONFIG_CC_HAVE_STACKPROTECTOR_SYSREG is
enabled.

[    1.950768] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
[    1.980607] Workqueue: events imx_sc_check_for_events
[    1.985657] Call trace:
[    1.988104]  dump_backtrace+0x0/0x140
[    1.991768]  show_stack+0x14/0x20
[    1.995090]  dump_stack+0xb4/0xf8
[    1.998407]  panic+0x158/0x324
[    2.001463]  print_tainted+0x0/0xa8
[    2.004950]  imx_sc_check_for_events+0x18c/0x190
[    2.009569]  process_one_work+0x198/0x320
[    2.013579]  worker_thread+0x48/0x420
[    2.017252]  kthread+0xf0/0x120
[    2.020394]  ret_from_fork+0x10/0x18
[    2.023977] SMP: stopping secondary CPUs
[    2.027901] Kernel Offset: disabled
[    2.031391] CPU features: 0x0002,2100600c
[    2.035401] Memory Limit: none
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Fixes: 688f1dfb ("Input: keyboard - imx_sc: Add i.MX system controller key support")
Link: https://lore.kernel.org/r/1573730499-2224-1-git-send-email-Anson.Huang@nxp.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Only show the 'calibrate' sysfs attribute on chip flavours
which support calibration by writing to a calibration register.

Do this by adding a flag to the chip operations structure.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/20191112210148.3535-2-TheSven73@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Optionally allow the touch screen resolution to be set by adding
it to the chip operations structure. If it is omitted (left zero),
the resolution defaults to 64K. Which is the previously hard-coded
value.

Set the ili2117 resolution to 2048, as indicated in its datasheet.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/20191112210148.3535-1-TheSven73@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The driver's method to retrieve the firmware version on ili2117/
ili2118 chip flavours is incorrect. The firmware version register
address and layout are wrong.

The firmware version is not actually used anywhere inside or
outside this driver. There is a dev_dbg() print, but that is
only visible when the developer explicitly compiles in debug
support.

Don't make the code more complicated to preserve a feature that
no-one is using. Remove all code associated with chip firmware
version.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Link: https://lore.kernel.org/r/20191112164429.11225-1-TheSven73@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

device_get_match_data is available now, so we can replace the call
to of_device_get_match_data and remove the FIXME comment.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://lore.kernel.org/r/20191007203343.101466-2-stephan@gerhold.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Bring in improvements to ili2xxx driver, including support for
2117A/2118A controllers.

When I2C client is instantiated with I2C_CLIENT_WAKE flag (either via
"wakeup-source" device property, or via board info flag), it will mark the
main IRQ line as wakeup IRQ, which will ensure that it will be enabled for
wakeup when system transitions to suspend state. Since our suspend/resume
handlers were only managing IRQ wakeup state, they are no longer needed,
and can be removed.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

I2C devices that are supposed to be wakeup sources should be instantiated
with I2C_CLIENT_WAKE flag (which can be either set by in board info, or
retrieved from "wakeup-source" property); individual drivers should not be
marking devices as wakeup sources unconditionally.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of doing if/else if/else on the chip's model number let's define
chip operations structure and use it to perform indirect calls. With number
of protocols supported by the driver growing, this makes it better
maintainable.

This change includes fixes to checks whether the driver should continue
polling the controller by Sven Van Asbroeck <thesven73@gmail.com>.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We are using devm_input_allocate_device() that set's up the parent for
us, no need to do it ourselves.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

input_mt_init_slots() may fail and we need to handle such failures.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Let's switch the driver to using threaded IRQ so that we do not need to
manage the interrupt and work separately, and we do not acknowledge
interrupt until we finished handling it completely.

Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Tested-by: Marek Vasut <marex@denx.de> #  ILI2117
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for ILI2117 touch controller. This controller is similar
to the ILI210x and ILI251x, except for the following differences:
- Reading out of touch data must happen at most 300 mS after the
  interrupt line was asserted. No command must be sent, the data
  are returned upon pure I2C read of 43 bytes long.
- Supports 10 simultaneous touch inputs.
- Touch data format is slightly different.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Rob Herring <robh@kernel.org> # for DT binding
Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd
Tested-by: Sven Van Asbroeck <TheSven73@gmail.com> # ILI2118A variant
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Update example in ad7879 device tree documentation to use generic touch
controller node names.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191026090403.3057-3-marcel@ziswiler.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Fix spelling mistake.
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Link: https://lore.kernel.org/r/1573211947-660-1-git-send-email-f.suligoi@asem.itSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The body of the for loop is only ever run once as the second standard_report
element is never changed from its initial zero init, so the loop condition is
never satisfies after the first run. Equally the start member of the first
element is never changed from 0, so the index offset is always a constant 0.

Remove this needless obfuscation of the code and write it in a straight
forward manner.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191104114454.10500-3-l.stach@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts kxtj9 driver to use the polling
mode of standard input devices and removes dependency on INPUT_POLLDEV.

note that with regular input devices handling polling, there is no longer a
benefit in having separate INPUT_KXTJ9_POLLED_MODE config option.

Link: https://lore.kernel.org/r/20191017204217.106453-23-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Using devm API allows to clean up error handling and drop the remove()
method.

Link: https://lore.kernel.org/r/20191017204217.106453-22-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts bma150 driver to use the polling
mode of standard input devices and removes dependency on INPUT_POLLDEV.

Link: https://lore.kernel.org/r/20191017204217.106453-21-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The driver can be cleaned up by using managed resource helpers.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
[dtor: do not explicitly set parent of input device since we are using devm]
Link: https://lore.kernel.org/r/20191017204217.106453-20-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts mma8450 driver to use the polling
mode of standard input devices and removes dependency on INPUT_POLLDEV.

Link: https://lore.kernel.org/r/20191017204217.106453-19-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts gpio_decoder driver to use
the polling mode of standard input devices and removes dependency on
INPUT_POLLDEV.

Link: https://lore.kernel.org/r/20191017204217.106453-18-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts rb532_button driver to use
the polling mode of standard input devices and removes dependency on
INPUT_POLLDEV.

Link: https://lore.kernel.org/r/20191017204217.106453-17-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>