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>
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>
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>
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: kernel test robot <lkp@intel.com>
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20211129004104.453930-1-jeff@labundy.com
Signed-off-by: Dmitry 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=1190256
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Samuel Čavoj <samuel@cavoj.net>
Link: https://lore.kernel.org/r/20211117063757.11380-1-tiwai@suse.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are identified by their nodenames directly in the
xenbus driver, which requires to update this list in case a new device
type being non-essential is added (this was missed for several types
in the past).
In order to avoid this problem, add a "not_essential" flag to struct
xenbus_driver which can be set to "true" by the respective frontend.
Set this flag for the frontends currently regarded to be not essential
(vkbs and vfb) and use it for testing in the xenbus driver.
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20211022064800.14978-2-jgross@suse.com
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Pull input updates from Dmitry Torokhov:
"Just one new driver (Cypress StreetFighter touchkey), and no input
core changes this time.
Plus various fixes and enhancements to existing drivers"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (54 commits)
Input: iforce - fix control-message timeout
Input: wacom_i2c - use macros for the bit masks
Input: ili210x - reduce sample period to 15ms
Input: ili210x - improve polled sample spacing
Input: ili210x - special case ili251x sample read out
Input: elantench - fix misreporting trackpoint coordinates
Input: synaptics-rmi4 - Fix device hierarchy
Input: i8042 - Add quirk for Fujitsu Lifebook T725
Input: cap11xx - add support for cap1206
Input: remove unused header <linux/input/cy8ctmg110_pdata.h>
Input: ili210x - add ili251x firmware update support
Input: ili210x - export ili251x version details via sysfs
Input: ili210x - use resolution from ili251x firmware
Input: pm8941-pwrkey - respect reboot_mode for warm reset
reboot: export symbol 'reboot_mode'
Input: max77693-haptic - drop unneeded MODULE_ALIAS
Input: cpcap-pwrbutton - do not set input parent explicitly
Input: max8925_onkey - don't mark comment as kernel-doc
Input: ads7846 - do not attempt IRQ workaround when deferring probe
Input: ads7846 - use input_set_capability()
...
