Zinitix touch controllers can use some of the sense lines for virtual
keys (like those found on many phones). Add support for those keys.

Signed-off-by: Nikita Travkin <nikita@trvn.ru>

In some configrations the touch controller can support the touch-keys.
Doucument the linux,keycodes property that enables those keys and
specifies the keycodes that should be used to report the key events.

Signed-off-by: Nikita Travkin <nikita@trvn.ru>

Zinitix BT532 is another touch controller that seem to implement the
same interface as an already supported BT541. Add it to the driver.

Signed-off-by: Nikita Travkin <nikita@trvn.ru>

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.

Cc: Mark Brown <broonie@kernel.org>
Cc: Michael Srba <Michael.Srba@seznam.cz>
Cc: phone-devel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[Slightly changed the legacy regulator detection]
Signed-off-by: Nikita Travkin <nikita@trvn.ru>

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.

Cc: Mark Brown <broonie@kernel.org>
Cc: Michael Srba <Michael.Srba@seznam.cz>
Cc: phone-devel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[Fixed dt_schema_check error]
Signed-off-by: Nikita Travkin <nikita@trvn.ru>

… gets enabled

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.

Fixes: 2682265 ("Input: add zinitix touchscreen driver")
Signed-off-by: Nikita Travkin <nikita@trvn.ru>

The ili251x firmware can be updated, this is used when switching between
different modes of operation of the touch surface, e.g. glove operation.
This patch implements the firmware update mechanism triggered by a write
into an sysfs attribute.

The firmware itself is distributed as an intel hex file with non-standard
types. The first two lines are of type 0xad, which indicates the start of
DataFlash payload, that is always at address 0xf000 on the ili251x, so it
can be dropped, and 0xac which indicates the position of firmware info in
the Application payload, that is always at address 0x2020 on the ili251x
and we do not care. The rest of the firmware is data of type 0x00, and we
care about that. To convert the firmware hex file into something usable
by the kernel, remove the first two lines and then use ihex2fw:

 $ tail -n +3 input.hex > temp.hex
 $ ./tools/firmware/ihex2fw temp.hex firmware/ilitek/ili251x.bin

To trigger the firmware update, place firmware file ilitek/ili251x.bin
into /lib/firmware/, write into firmware_update sysfs attribute and wait
about 30-40 seconds. The firmware update is slow. Afterward, verify the
firmware_version and mode sysfs attributes to check whether the firmware
got updated and the controller switched back to application (AP) mode by
reading out 'mode' attribute in sysfs.

Note that the content of firmware_version, e.g. 0600.0005.abcd.aa04 can
be matched to the content of the firmware hex file. The first four bytes,
0x06 0x00 0x00 0x05 can be found at ^:102030 00 05000006, the next four
bytes 0xab 0xcd 0xaa 0x04 at ^:10F000 00 nnnnnnnn ABCDAA04.

Note that the protocol differs considerably between the ili2xxx devices,
this patch therefore implements this functionality only for ili251x that
I can test.

Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20210831202506.181927-3-marex@denx.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The ili251x firmware protocol permits readout of firmware version,
protocol version, mcu version and current mode (application, boot
loader, forced update). These information are useful when updating
the firmware on the il251x, e.g. to avoid updating the same firmware
into the device multiple times. The locking is now necessary to avoid
races between interrupt handler and the sysfs readouts.

Note that the protocol differs considerably between the ili2xxx devices,
this patch therefore implements this functionality only for ili251x that
I can test.

Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20210831202506.181927-2-marex@denx.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The ili251x firmware protocol permits readout of panel resolution,
implement this, but make it possible to override this value using
DT bindings. This way, older DTs which contain touchscreen-size-x
and touchscreen-size-y properties will behave just like before and
new DTs may avoid specifying these for ILI251x.

Note that the command format is different on other controllers, so
this functionality is isolated to ILI251x.

Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20210831202506.181927-1-marex@denx.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

On some devices, e.g. Sony Xperia M4 Aqua, warm reset is used to reboot
device into bootloader and recovery mode.  Instead of always doing hard
reset, add a check on reboot_mode for possible warm reset.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20210714095850.27185-3-shawn.guo@linaro.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some drivers like Qualcomm pm8941-pwrkey need to access 'reboot_mode'
for triggering reboot between cold and warm mode.  Export the symbol, so
that drivers built as module can still access the symbol.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210714095850.27185-2-shawn.guo@linaro.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The MODULE_DEVICE_TABLE already creates proper alias for platform
driver.  Having another MODULE_ALIAS causes the alias to be duplicated.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210916170514.137977-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We are using devm_input_allocate_device() that already sets parent
of the input device, there is no need to do that again.

Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/YWpiZqrfC9+GQsM4@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Change the comment to a normal (non-kernel-doc) comment to avoid
these kernel-doc warnings:

max8925_onkey.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * MAX8925 ONKEY driver
max8925_onkey.c:2: warning: missing initial short description on line:
 * MAX8925 ONKEY driver

Fixes: 3734574 ("Input: enable onkey driver of max8925")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20211002045943.9406-1-rdunlap@infradead.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

When request_irq() returns -EPORBE_DEFER we should abort probe and try
again later instead of trying to engage IRQ trigger workaround.

Link: https://lore.kernel.org/r/20210910045039.4020199-3-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of manipulating capability bits directly use
input_set_capability(). Also stop setting EV_ABS explicitly as
input_set_abs_params() does it for us.

Link: https://lore.kernel.org/r/20210910045039.4020199-2-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Set input device's bus type as BUS_SPI and use model as product ID.

Link: https://lore.kernel.org/r/20210910045039.4020199-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

At the moment the touch keys have key codes assigned from the device
tree. In some cases, users might want to change the key code from
userspace. There is existing functionality for this in the input core
using the EVIOCSKEYCODE ioctl, which is integrated for example into udev.

Make it possible to use this functionality for tm2-touchkey by simply
making the input core aware of the array that holds the keycodes.
Similar code also exists in mcs_touchkey and mpr121_touchkey.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20211013112305.41574-2-stephan@gerhold.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Report the index of pressed touch key as MSC_SCAN code to userspace
so it is possible to identify which of the keys was pressed (not
just the function that is currently assigned to the key).

This is done similarly also in mcs_touchkey and mpr121_touchkey.

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20211013112305.41574-1-stephan@gerhold.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This fixes the following warning from sparse:

  CC [M]  drivers/input/misc/adxl34x.o
  CHECK   drivers/input/misc/adxl34x.c
drivers/input/misc/adxl34x.c:245:29: warning: cast to restricted __le16
drivers/input/misc/adxl34x.c:248:29: warning: cast to restricted __le16
drivers/input/misc/adxl34x.c:251:29: warning: cast to restricted __le16

Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/YWZIjb91d6aAwgss@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

By using managed resources (devm) we are able to streamline error handling
in probe and remove most of the custom remove method.

Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/YWZGKWgdarGtvtYA@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of manually toggling interrupt as wakeup source in suspend/resume
methods, let's declare keypad interrupt and wakeup interrupt and leave the
rest to the PM core.

Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20211012013735.3523140-3-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Also drop parenthesis around macros that do not use expressions as they are
not needed.

Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20211012013735.3523140-2-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of guarding suspend/resume methods with #ifdef CONFIG_PM
let's mark them as __maybe_unused as this allows better compile
coverage.

Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20211012013735.3523140-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Up to now tsc200x_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.

Also the return value of i2c and spi remove callbacks is ignored anyway.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211012153945.2651412-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Up to now adxl34x_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.

Also the return value of i2c and spi remove callbacks is ignored anyway.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211012153945.2651412-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The device may take up to 100ms to become responsive during probe, so
prefer asynchronous probing to avoid delaying the rest of the system.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20211007111217.1935858-1-john@metanate.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

I have a ST1633 touch controller which fails to probe due to a timeout
waiting for the controller to become ready.  Increasing the minimum
delay to 100ms ensures that the probe sequence completes successfully.

The ST1633 datasheet says nothing about the maximum delay here and the
ST1232 I2C protocol document says "wait until" with no notion of a
timeout.

Since this only runs once during probe, being generous with the timout
seems reasonable and most likely the device will become ready
eventually.

(It may be worth noting that I saw this issue with a PREEMPT_RT patched
kernel which probably has tighter wakeups from usleep_range() than other
preemption models.)

Fixes: f605be6 ("Input: st1232 - wait until device is ready before reading resolution")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Commit 0464777 ("dt-bindings: input: Convert ChipOne ICN8318
binding to a schema") converts chipone_icn8318.txt to chipone,icn8318.yaml,
but missed to adjust its reference in MAINTAINERS.

Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
a broken reference.

Repair this file reference in CHIPONE ICN8318 I2C TOUCHSCREEN DRIVER.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20211005075451.29691-12-lukas.bulwahn@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Overlapping input and output arguments to snprintf() are
undefined behavior in C99:

drivers/input/joystick/analog.c: In function 'analog_name':
drivers/input/joystick/analog.c:428:3: error: 'snprintf' argument 4 overlaps destination object 'analog' [-Werror=restrict]
  428 |   snprintf(analog->name, sizeof(analog->name), "%s %d-hat",
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  429 |     analog->name, hweight16(analog->mask & ANALOG_HATS_ALL));
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/joystick/analog.c:420:40: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
  420 | static void analog_name(struct analog *analog)
      |                         ~~~~~~~~~~~~~~~^~~~~~

Change this function to use the simpler seq_buf interface instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210927101416.1569609-1-arnd@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.

Fixes: 96c8395 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210927134104.38648-1-broonie@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

…set()

The helper function devm_add_action_or_reset() will internally
call devm_add_action(), and if devm_add_action() fails then it will
execute the action mentioned and return the error code. So
use devm_add_action_or_reset() instead of devm_add_action()
to simplify the error handling, reduce the code.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210922125954.533-1-caihuoqing@baidu.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

…on_or_reset()

The helper function devm_add_action_or_reset() will internally
call devm_add_action(), and if devm_add_action() fails then it will
execute the action mentioned and return the error code. So
use devm_add_action_or_reset() instead of devm_add_action()
to simplify the error handling, reduce the code.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210922125212.95-3-caihuoqing@baidu.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The helper function devm_add_action_or_reset() will internally
call devm_add_action(), and if devm_add_action() fails then it will
execute the action mentioned and return the error code. So
use devm_add_action_or_reset() instead of devm_add_action()
to simplify the error handling, reduce the code.

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210922125212.95-2-caihuoqing@baidu.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some Goodix touchscreen controllers, such as for example the GT912,
don't have flash-storage for their firmware.

These models require the OS to load the firmware at runtime, as well as
some other special handling. Add support for this to the goodix driver.

This patch was developed and tested on a Glavey TM800A550L tablet.

Note the "goodix,main-clk" and "firmware-name" device-properties used
by the new code are *not* documented in the
Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
device-tree bindings for now.

Not documenting these is intentional. This is done because this code has
only been tested on x86/ACPI so far, where devicetree is not used.
Instead these properties are set through a software-fwnode attached to the
device by the drivers/platform/x86/touchscreen_dmi.c code. This means that
the use of this properties for now is purely a kernel-internal thing and
the name/working of the properties may still be changed for now.

Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920150643.155872-7-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>