The PS/2 bus defines the data and clock line be open drain, therefore
for both enforce the particular GPIO flags in the driver.
Without enforcing to flag at least the clock gpio as open drain we run
into the following warning:
WARNING: CPU: 1 PID: 40 at drivers/gpio/gpiolib.c:3175 gpiochip_enable_irq+0x54/0x90
gpiochip_enable_irq() warns on a GPIO being configured as output while
serving as IRQ source without being flagged as open drain.
Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de>
Link: https://lore.kernel.org/r/20220215180829.63543-4-danilokrummrich@dk-develop.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Sending the data before processing the stop bit from the device already
saves the data of the current xfer in case the stop bit is missed.
However, when TX xfers are enabled this introduces a race condition when
a peripheral driver using the bus immediately requests a TX xfer from IRQ
context.
Therefore the data must be send after receiving the stop bit, although
it is possible the data is lost when missing the stop bit.
Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de>
Link: https://lore.kernel.org/r/20220215160208.34826-5-danilokrummrich@dk-develop.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Actually, there's no extra clock pulse to wait for.
The assumption of an extra clock pulse was mistakenly derived from the
fact that by the time this driver was introduced the GPIO controller of
the test machine (bcm2835) generated spurious interrupts.
Since now spurious interrupts are handled properly this can and must be
removed in order to make TX xfers work properly.
While at it, remove duplicate gpiod_direction_input(). The data gpio
must already be configured to act as input when receiving the ACK bit.
This patch is tested with the original hardware (peripherals and board)
the driver was developed on.
Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de>
Link: https://lore.kernel.org/r/20220215160208.34826-4-danilokrummrich@dk-develop.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Using jiffies for the IRQ timekeeping is not sufficient for two reasons:
(1) Usually jiffies have a resolution of 1ms to 10ms. The IRQ intervals
based on the clock frequency of PS2 protocol specification (10kHz -
16.7kHz) are between ~60us and 100us only. Therefore only those IRQ
intervals can be detected which are either at the end of a transfer
or are overly delayed. While this is sufficient in most cases, since
we have quite a lot of ways to detect faulty transfers, it can
produce false positives in rare cases: When the jiffies value
changes right between two interrupt that are in time, we wrongly
assume that we missed one or more clock cycles.
(2) Some gpio controllers (e.g. the one in the bcm283x chips) may generate
spurious IRQs when processing interrupts in the frequency given by PS2
devices.
Both issues can be fixed by using ktime resolution for IRQ timekeeping.
However, it is still possible to miss clock cycles without detecting
them. When the PS2 device generates the falling edge of the clock signal
we have between ~30us and 50us to sample the data line, because after
this time we reach the next rising edge at which the device changes the
data signal already. But, the only thing we can detect is whether the
IRQ interval is within the given period. Therefore it is possible to
have an IRQ latency greater than ~30us to 50us, sample the wrong bit on
the data line and still be on time with the next IRQ. However, this can
only happen when within a given transfer the IRQ latency increases
slowly.
___ ______ ______ ______ ___
\ / \ / \ / \ /
\ / \ / \ / \ /
\______/ \______/ \______/ \______/
|-----------------| |--------|
60us/100us 30us/50us
Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de>
Link: https://lore.kernel.org/r/20220215160208.34826-3-danilokrummrich@dk-develop.de
Signed-off-by: Dmitry 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: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/20220208174806.17183-1-jose.exposito89@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some pmics of the mt6397 family (such as MT6358), have two IRQs per
physical key: one for press event, another for release event.
The mtk-pmic-keys driver assumes that each key only has one
IRQ. The key index and the RES_IRQ resource index have a 1/1 mapping.
This won't work for MT6358, as we have multiple resources (2) for one key.
To prepare mtk-pmic-keys to support MT6358, retrieve IRQs by name
instead of by index.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20220121140323.4080640-2-mkorpershoek@baylibre.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
ASoC: Fixes for v5.17
Quite a few fixes here, including an unusually large set in the core
spurred on by various testing efforts as well as the usual small driver
fixes. There are quite a few fixes for out of bounds writes in both the
core and the various Qualcomm drivers, plus a couple of fixes for
locking in the DPCM code.
Pull input updates from Dmitry Torokhov:
"Updates to Goodix touchscreen driver (addition of pen support) and
Silead touchscreen driver (also addition of pen support and parsing of
embedded firmware to determine screen size), along with assorted fixes
for other drivers"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: ti_am335x_tsc - fix a typo in a comment
Input: zinitix - add compatible for bt532
Input: zinitix - handle proper supply names
dt-bindings: input/ts/zinitix: Convert to YAML, fix and extend
Input: axp20x-pek - revert "always register interrupt handlers" change
Input: gpio-keys - avoid clearing twice some memory
Input: byd - fix typo in a comment
Input: ucb1400_ts - remove redundant variable penup
Input: ti_am335x_tsc - lower the X and Y sampling time
Input: ti_am335x_tsc - fix STEPCONFIG setup for Z2
Input: ti_am335x_tsc - set ADCREFM for X configuration
Input: silead - add pen support
Input: silead - add support for EFI-embedded fw using different min/max coordinates
Input: goodix - 2 small fixes for pen support
Input: goodix - improve gpiod_get() error logging
Input: goodix - add pen support
Input: ff-core - correct magnitude setting for rumble compatibility
Input: palmas-pwrbutton - make a couple of arrays static const
Input: wacom_i2c - clean up the query device fields
Input: palmas-pwrbutton - use bitfield helpers
Pull tty/serial driver updates from Greg KH:
"Here is the big set of tty/serial driver updates for 5.17-rc1.
Nothing major in here, just lots of good updates and fixes, including:
- more tty core cleanups from Jiri as well as mxser driver cleanups.
This is the majority of the core diffstat
- tty documentation updates from Jiri
- platform_get_irq() updates
- various serial driver updates for new features and hardware
- fifo usage for 8250 console, reducing cpu load a lot
- LED fix for keyboards, long-time bugfix that went through many
revisions
- minor cleanups
All have been in linux-next for a while with no reported problems"
* tag 'tty-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (119 commits)
serial: core: Keep mctrl register state and cached copy in sync
serial: stm32: correct loop for dma error handling
serial: stm32: fix flow control transfer in DMA mode
serial: stm32: rework TX DMA state condition
serial: stm32: move tx dma terminate DMA to shutdown
serial: pl011: Drop redundant DTR/RTS preservation on close/open
serial: pl011: Drop CR register reset on set_termios
serial: pl010: Drop CR register reset on set_termios
serial: liteuart: fix MODULE_ALIAS
serial: 8250_bcm7271: Fix return error code in case of dma_alloc_coherent() failure
Revert "serdev: BREAK/FRAME/PARITY/OVERRUN notification prototype V2"
tty: goldfish: Use platform_get_irq() to get the interrupt
serdev: BREAK/FRAME/PARITY/OVERRUN notification prototype V2
tty: serial: meson: Drop the legacy compatible strings and clock code
serial: pmac_zilog: Use platform_get_irq() to get the interrupt
serial: bcm63xx: Use platform_get_irq() to get the interrupt
serial: ar933x: Use platform_get_irq() to get the interrupt
serial: vt8500: Use platform_get_irq() to get the interrupt
serial: altera_jtaguart: Use platform_get_irq_optional() to get the interrupt
serial: pxa: Use platform_get_irq() to get the interrupt
...
Pull input fix from Dmitry Torokhov:
"A small fixup to the Zinitix touchscreen driver to avoid enabling the
IRQ line before we successfully requested it"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: zinitix - make sure the IRQ is allocated before it gets enabled
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: Linus Walleij <linus.walleij@linaro.org>
[Slightly changed the legacy regulator detection]
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-4-nikita@trvn.ru
Signed-off-by: Dmitry 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: Linus Walleij <linus.walleij@linaro.org>
Fixes: 26822652c8 ("Input: add zinitix touchscreen driver")
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ru
Signed-off-by: Dmitry 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 9747070c11 ("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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20220106111647.66520-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull input fixes from Dmitry Torokhov:
"Two small fixups for spaceball joystick driver and appletouch touchpad
driver"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: spaceball - fix parsing of movement data packets
Input: appletouch - initialize work before device registration
Pull input fixes from Dmitry Torokhov:
"A few small updates to drivers.
Of note we are now deferring probes of i8042 on some Asus devices as
the controller is not ready to respond to queries first time around
when the driver is compiled into the kernel"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312
Input: atmel_mxt_ts - fix double free in mxt_read_info_block
Input: goodix - fix memory leak in goodix_firmware_upload
Input: goodix - add id->model mapping for the "9111" model
Input: goodix - try not to touch the reset-pin on x86/ACPI devices
Input: i8042 - enable deferred probe quirk for ASUS UM325UA
Input: elantech - fix stack out of bound access in elantech_change_report_id()
Input: iqs626a - prohibit inlining of channel parsing functions
Input: i8042 - add deferred probe support
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: Dario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20211212125358.14416-4-dariobin@libero.it
Signed-off-by: Dmitry 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: 1b8be32e69 ("Input: add support for TI Touchscreen controller")
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Link: https://lore.kernel.org/r/20211212125358.14416-2-dariobin@libero.it
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211122220637.11386-3-hdegoede@redhat.com
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211122220637.11386-2-hdegoede@redhat.com
Signed-off-by: Dmitry 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: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20211130135039.13726-1-ckeepax@opensource.cirrus.com
Signed-off-by: Dmitry 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 921daeeca9 ("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: a7d4b17166 ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211206091116.44466-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
