Dennis Kadioglu [Wed, 27 May 2020 06:03:13 +0000 (23:03 -0700)]
Input: synaptics - add a second working PNP_ID for Lenovo T470s
The Lenovo Thinkpad T470s I own has a different touchpad with "LEN007a"
instead of the already included PNP ID "LEN006c". However, my touchpad
seems to work well without any problems using RMI. So this patch adds the
other PNP ID.
Input: applespi - replace zero-length array with flexible-array
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.
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.
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 60f0eef33c4c ("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.
Kevin Locke [Tue, 28 Apr 2020 01:07:20 +0000 (18:07 -0700)]
Input: i8042 - add ThinkPad S230u to i8042 reset list
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.
"... 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."
Input: xpad - add custom init packet for Xbox One S controllers
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.
Input: evdev - call input_flush_device() on release(), not flush()
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.
Kevin Locke [Mon, 20 Apr 2020 17:02:19 +0000 (10:02 -0700)]
Input: i8042 - add ThinkPad S230u to i8042 nomux list
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.
James Hilliard [Sun, 19 Apr 2020 04:17:12 +0000 (21:17 -0700)]
Input: usbtouchscreen - add support for BonXeon TP
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.
Input: cros_ec_keyb - use cros_ec_cmd_xfer_status helper
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.
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>
Johnny Chuang [Thu, 9 Apr 2020 19:42:42 +0000 (12:42 -0700)]
Input: elants_i2c - support palm detection
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.
Hans de Goede [Wed, 1 Apr 2020 20:23:06 +0000 (13:23 -0700)]
Input: i8042 - add Acer Aspire 5738z to nomux list
The Acer Aspire 5738z has a button to disable (and re-enable) the
touchpad next to the touchpad.
When this button is pressed a LED underneath indicates that the touchpad
is disabled (and an event is send to userspace and GNOME shows its
touchpad enabled / disable OSD thingie).
So far so good, but after re-enabling the touchpad it no longer works.
The laptop does not have an external ps2 port, so mux mode is not needed
and disabling mux mode fixes the touchpad no longer working after toggling
it off and back on again, so lets add this laptop model to the nomux list.
Hans de Goede [Wed, 1 Apr 2020 19:53:36 +0000 (12:53 -0700)]
Input: goodix - fix compilation when ACPI support is disabled
acpi_evaluate_object() and acpi_execute_simple_method() are not part of
the group of ACPI related functions which get stubbed by
include/linux/acpi.h when ACPI support is disabled, so the
IRQ_PIN_ACCESS_ACPI_METHOD handling code must be stubbed out.
For consistency use the same #if condition as which is used to replace
goodix_add_acpi_gpio_mappings with a stub.
Fixes: d336efbdfe2d ("Input: goodix - add support for controlling the IRQ pin through ACPI methods") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200401014529.GL75430@dtor-ws
[dtor: stubbed out the ACPI method accessors] Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Thu, 26 Mar 2020 19:54:02 +0000 (12:54 -0700)]
Input: move the new KEY_SELECTIVE_SCREENSHOT keycode
We should try to keep keycodes sequential unless there is a reason to leave
a gap in numbering, so let's move it from 0x280 to 0x27a while we still
can.
Fixes: e0b39f74de08 ("Input: allocate keycode for Selective Screenshot key") Acked-by: Rajat Jain <rajatja@google.com> Link: https://lore.kernel.org/r/20200326182711.GA259753@dtor-ws Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: avoid BIT() macro usage in the serio.h UAPI header
The commit 38a4f117d3e0 ("Input: psmouse - add a custom serio protocol
to send extra information") introduced usage of the BIT() macro
for SERIO_* flags; this macro is not provided in UAPI headers.
Replace if with similarly defined _BITUL() macro defined
in <linux/const.h>.
Fixes: 38a4f117d3e0 ("Input: psmouse - add a custom serio protocol to send extra information") Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> Cc: <stable@vger.kernel.org> # v5.0+ Link: https://lore.kernel.org/r/20200324041341.GA32335@asgard.redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Andrew Duggan [Tue, 24 Mar 2020 22:38:51 +0000 (15:38 -0700)]
Input: synaptics-rmi4 - set reduced reporting mode only when requested
The previous patch "f529da7f099c (Input: synaptics-rmi4 - switch to
reduced reporting mode)" enabled reduced reporting mode unintentionally
on some devices, if the firmware was configured with default Delta X/Y
threshold values. The result unintentionally degrade the performance of
some touchpads.
This patch checks to see that the driver is modifying the delta X/Y
thresholds before modifying the reporting mode.
Yussuf Khalil [Sat, 7 Mar 2020 22:16:31 +0000 (14:16 -0800)]
Input: synaptics - enable RMI on HP Envy 13-ad105ng
This laptop (and perhaps other variants of the same model) reports an
SMBus-capable Synaptics touchpad. Everything (including suspend and
resume) works fine when RMI is enabled via the kernel command line, so
let's add it to the whitelist.
Yannick Fertre [Tue, 24 Mar 2020 19:32:27 +0000 (12:32 -0700)]
Input: goodix - support gt9147 touchpanel
Add support for it by adding compatible and supported chip data
(default settings used).
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Yannick Fertre [Tue, 24 Mar 2020 19:30:19 +0000 (12:30 -0700)]
dt-bindings: touchscreen: goodix: support of gt9147
Add support for it by adding compatible.
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Dmitry Mastykin [Tue, 24 Mar 2020 18:38:49 +0000 (11:38 -0700)]
Input: goodix - add support for more then one touch-key
Some devices with a goodix touchscreen have more then 1 capacitive
touch-key. This commit replaces the current support for a single
touch-key, which ignored the reported key-code. With support for
up to 7 touch-keys, based upon checking the key-code which is
post-fixed to any reported touch-data.
KEY_LEFTMETA is assigned to the first touch-key (it will still be
the default keycode for devices with a single touch-key).
KEY_F1, KEY_F2... are assigned as default keycode for the other
touch-keys.
This commit also add supports for keycode remapping, so that
systemd-udev's hwdb can be used to remap the codes to send
keycodes to match the icons on the buttons for devices with more
then 1 touch-key.
Dmitry Mastykin [Tue, 24 Mar 2020 18:38:28 +0000 (11:38 -0700)]
Input: goodix - fix spurious key release events
The goodix panel sends spurious interrupts after a 'finger up' event,
which always cause a timeout.
We were exiting the interrupt handler by reporting touch_num == 0, but
this was still processed as valid and caused the code to use the
uninitialised point_data, creating spurious key release events.
Report an error from the interrupt handler so as to avoid processing
invalid point_data further.
Hans de Goede [Tue, 24 Mar 2020 18:37:23 +0000 (11:37 -0700)]
Input: goodix - try to reset the controller if the i2c-test fails
On some ACPI/x86 devices (where we use one of the ACPI IRQ pin access
methods) the firmware is buggy, it does not properly reset the controller
at boot, and we cannot communicate with it.
Normally on ACPI/x86 devices we do not want to reset the controller at
probe time since in some cases this causes the controller to loose its
configuration and this is loaded into it by the system's firmware.
So on these systems we leave the reset_controller_at_probe flag unset,
even though we have a access to both the IRQ and reset pins and thus
could reset it.
In the case of the buggy firmware we have to reset the controller to
actually be able to talk to it.
This commit adds a special case for this, if the goodix_i2c_test() fails,
and we have not reset the controller yet; and we do have a way to reset
the controller then retry the i2c-test after resetting the controller.
This fixes the driver failing at probe on ACPI/x86 systems with this
firmware bug.
Hans de Goede [Tue, 24 Mar 2020 18:34:11 +0000 (11:34 -0700)]
Input: goodix - restore config on resume if necessary
Some devices, e.g the Trekstor Primetab S11B, lose there config over
a suspend/resume cycle (likely the controller loses power during suspend).
This commit reads back the config version on resume and if matches the
expected config version it resets the controller and resends the config
we read back and saved at probe time.
Hans de Goede [Tue, 24 Mar 2020 18:33:50 +0000 (11:33 -0700)]
Input: goodix - make goodix_send_cfg() take a raw buffer as argument
Make goodix_send_cfg() take a raw buffer as argument instead of a
struct firmware *cfg, so that it can also be used to restore the config
on resume if necessary.
Hans de Goede [Tue, 24 Mar 2020 18:33:16 +0000 (11:33 -0700)]
Input: goodix - add minimum firmware size check
Our goodix_check_cfg_* helpers do things like:
int i, raw_cfg_len = cfg->size - 2;
...
if (check_sum != cfg->data[raw_cfg_len]) {
When cfg->size < 2, this will end up indexing the cfg->data array with
a negative value, which will not end well.
To fix this this commit adds a new GOODIX_CONFIG_MIN_LENGTH define and
adds a minimum size check for firmware-config files using this new define.
For consistency this commit also adds a new GOODIX_CONFIG_GT9X_LENGTH for
the length used for recent gt9xx and gt1xxx chips, instead of using
GOODIX_CONFIG_MAX_LENGTH for this, so that if other length defines get
added in the future it will be clear that the MIN and MAX defines should
contain the min and max values of all the other defines.
Hans de Goede [Tue, 24 Mar 2020 18:29:10 +0000 (11:29 -0700)]
Input: goodix - move defines to above struct goodix_ts_data declaration
Move the defines to above the struct goodix_ts_data declaration, so
that the MAX defines can be used inside the struct goodix_ts_data
declaration. No functional changes, just moving a block of code.
Hans de Goede [Tue, 24 Mar 2020 18:24:31 +0000 (11:24 -0700)]
Input: goodix - add support for controlling the IRQ pin through ACPI methods
Some Apollo Lake (x86, UEFI + ACPI) devices only list the reset GPIO
in their _CRS table and the bit-banging of the IRQ line necessary to
wake-up the controller from suspend can be done by calling 2 Goodix
custom / specific ACPI methods.
This commit adds support for controlling the IRQ line in this matter,
allowing us to properly suspend the touchscreen controller on such
devices.
Hans de Goede [Tue, 24 Mar 2020 18:23:35 +0000 (11:23 -0700)]
Input: goodix - add support for getting IRQ + reset GPIOs on Bay Trail devices
On most Bay Trail (x86, UEFI + ACPI) devices the ACPI tables do not have
a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding
"irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name
without first manually adding mappings ourselves.
These devices contain 2 GpioIo resource in their _CRS table, on all 4 such
devices which I have access to, the order of the 2 GPIOs is reset, int.
Note that the GPIO to which the touchscreen controller irq pin is connected
is configured in direct-irq mode on these Bay Trail devices, the
pinctrl-baytrail.c driver still allows controlling the pin as a GPIO in
this case, but this is not necessarily the case on other X86 ACPI
platforms, nor do we have a guarantee that the GPIO order is the same
elsewhere, so we limit the use of a _CRS table with 2 GpioIo resources
to Bay Trail devices only.
Hans de Goede [Tue, 24 Mar 2020 18:23:21 +0000 (11:23 -0700)]
Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices
On most Cherry Trail (x86, UEFI + ACPI) devices the ACPI tables do not have
a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding
"irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name
without first manually adding mappings ourselves.
These devices contain 1 GpioInt and 1 GpioIo resource in their _CRS table:
There is no fixed order for these 2. This commit adds code to check that
there is 1 of each as expected and then registers a mapping matching their
order using devm_acpi_dev_add_driver_gpios().
This gives us access to both GPIOs allowing us to properly suspend the
controller during suspend, and making it possible to reset the controller
if necessary.
Hans de Goede [Tue, 24 Mar 2020 18:23:04 +0000 (11:23 -0700)]
Input: goodix - make resetting the controller at probe independent from the GPIO setup
Before this commit we would always reset the controller at probe when we
have access to the GPIOs which are necessary to do a reset.
Doing the reset requires access to the GPIOs, but just because we have
access to the GPIOs does not mean that we should always reset the
controller at probe. On X86 ACPI platforms the BIOS / UEFI firmware will
already have reset the controller and it will have loaded the device
specific config into the controller. Doing the reset sometimes causes the
controller to lose its configuration, so on X86 ACPI platforms this is not
a good idea.
This commit adds a new reset_controller_at_probe boolean to control the
reset at probe behavior.
This commits sets the new bool to true when we set irq_pin_access_method
to IRQ_PIN_ACCESS_GPIO, so there are no functional changes.
Hans de Goede [Tue, 24 Mar 2020 18:12:35 +0000 (11:12 -0700)]
Input: goodix - make loading the config from disk independent from the GPIO setup
At least on X86 ACPI platforms it is not necessary to load the touchscreen
controller config from disk, if it needs to be loaded this has already been
done by the BIOS / UEFI firmware.
Even on other (e.g. devicetree) platforms the config-loading as currently
done has the issue that the loaded cfg file is based on the controller
model, but the actual cfg is device specific, so the cfg files are not
part of linux-firmware and this can only work with a device specific OS
image which includes the cfg file.
And we do not need access to the GPIOs at all to load the config, if we
do not have access we can still load the config.
So all in all tying the decision to try to load the config from disk to
being able to access the GPIOs is not desirable. This commit adds a new
load_cfg_from_disk boolean to control the firmware loading instead.
This commits sets the new bool to true when we set irq_pin_access_method
to IRQ_PIN_ACCESS_GPIO, so there are no functional changes.
Hans de Goede [Tue, 24 Mar 2020 18:12:10 +0000 (11:12 -0700)]
Input: goodix - refactor IRQ pin GPIO accesses
Suspending Goodix touchscreens requires changing the interrupt pin to
output before sending them a power-down command. Followed by wiggling
the interrupt pin to wake the device up, after which it is put back
in input mode.
So far we have only effectively supported this on devices which use
devicetree. On X86 ACPI platforms both looking up the pins; and using a
pin as both IRQ and GPIO is a bit more complicated. E.g. on some devices
we cannot directly access the IRQ pin as GPIO and we need to call ACPI
methods to control it instead.
This commit adds a new irq_pin_access_method field to the goodix_chip_data
struct and adds goodix_irq_direction_output and goodix_irq_direction_input
helpers which together abstract the GPIO accesses to the IRQ pin.
This is a preparation patch for adding support for properly suspending the
touchscreen on X86 ACPI platforms.
Rajat Jain [Wed, 18 Mar 2020 03:03:33 +0000 (20:03 -0700)]
Input: allocate keycode for "Selective Screenshot" key
New Chrome OS keyboards have a "snip" key that is basically a selective
screenshot (allows a user to select an area of screen to be copied).
Allocate a keycode for it.
Dan Carpenter [Fri, 6 Mar 2020 19:50:51 +0000 (11:50 -0800)]
Input: raydium_i2c_ts - fix error codes in raydium_i2c_boot_trigger()
These functions are supposed to return negative error codes but instead
it returns true on failure and false on success. The error codes are
eventually propagated back to user space.
Input: cyapa - replace zero-length array with flexible-array member
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]
Input: tca6416-keypad - replace zero-length array with flexible-array member
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]
Input: gpio_keys_polled - replace zero-length array with flexible-array member
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]
Input: gpio_keys - replace zero-length array with flexible-array member
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]
Input: goldfish_events - replace zero-length array with flexible-array member
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]
Lucas Stach [Sat, 1 Feb 2020 01:38:19 +0000 (17:38 -0800)]
Input: synaptics-rmi4 - switch to reduced reporting mode
When the distance thresholds are set the controller must be in reduced
reporting mode for them to have any effect on the interrupt generation.
This has a potentially large impact on the number of events the host
needs to process.
Samuel Holland [Wed, 22 Jan 2020 06:04:00 +0000 (22:04 -0800)]
Input: axp20x-pek - enable wakeup for all AXP variants
There are many devices, including several mobile battery-powered
devices, using other AXP variants as their PMIC. Allow them to use
the power key as a wakeup source.
Unlike most other power button drivers, this driver unconditionally
enables its wakeup IRQ. It should be using device_may_wakeup() to
respect the userspace configuration of wakeup sources.
Because the AXP20x MFD device uses regmap-irq, the AXP20x PEK IRQs are
nested off of regmap-irq's threaded interrupt handler. The device core
ignores such interrupts, so to actually disable wakeup, we must
explicitly disable all non-wakeup interrupts during suspend.
Input: ads7846 - use new `delay` structure for SPI transfer delays
In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current
`delay_usecs` with `delay` for this driver.
The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).
[1] commit 2b6d4249504234d ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")
Stephan Gerhold [Fri, 17 Jan 2020 21:40:36 +0000 (13:40 -0800)]
Input: pm8xxx-vib - fix handling of separate enable register
Setting the vibrator enable_mask is not implemented correctly:
For regmap_update_bits(map, reg, mask, val) we give in either
regs->enable_mask or 0 (= no-op) as mask and "val" as value.
But "val" actually refers to the vibrator voltage control register,
which has nothing to do with the enable_mask.
So we usually end up doing nothing when we really wanted
to enable the vibrator.
We want to set or clear the enable_mask (to enable/disable the vibrator).
Therefore, change the call to always modify the enable_mask
and set the bits only if we want to enable the vibrator.
The driver was issuing synchronous uninterruptible control requests
without using a timeout. This could lead to the driver hanging on probe
due to a malfunctioning (or malicious) device until the device is
physically disconnected. While sleeping in probe the driver prevents
other devices connected to the same hub from being added to (or removed
from) the bus.
The USB upper limit of five seconds per request should be more than
enough.
Fixes: c907a906b533 ("[PATCH] USB: add driver for Keyspan Digital Remote") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> # 2.6.13 Link: https://lore.kernel.org/r/20200113171715.30621-1-johan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Hans Verkuil [Fri, 17 Jan 2020 04:12:53 +0000 (20:12 -0800)]
Input: rmi_f54 - read from FIFO in 32 byte blocks
The F54 Report Data is apparently read through a fifo and for
the smbus protocol that means that between reading a block of 32
bytes the rmiaddr shouldn't be incremented. However, changing
that causes other non-fifo reads to fail and so that change was
reverted.
This patch changes just the F54 function and it now reads 32 bytes
at a time from the fifo, using the F54_FIFO_OFFSET to update the
start address that is used when reading from the fifo.
This has only been tested with smbus, not with i2c or spi. But I
suspect that the same is needed there since I think similar
problems will occur there when reading more than 256 bytes.
Marco Felsch [Fri, 10 Jan 2020 01:05:00 +0000 (17:05 -0800)]
Input: edt-ft5x06 - use pm core to enable/disable the wake irq
We do not have to handle the wake-irq within the driver because the pm
core can handle this for us. The only use case for the suspend/resume
callbacks was to handle the wake-irq so we can remove the callbacks.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Marco Felsch [Fri, 10 Jan 2020 01:04:36 +0000 (17:04 -0800)]
Input: edt-ft5x06 - make wakeup-source switchable
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.
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.
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>
Marco Felsch [Fri, 10 Jan 2020 01:03:32 +0000 (17:03 -0800)]
Input: edt-ft5x06 - alphabetical include reorder
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>
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>
Johan Hovold [Fri, 10 Jan 2020 20:00:18 +0000 (12:00 -0800)]
Input: gtco - fix endpoint sanity check
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes: 71b3406c487d ("Input: gtco - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Vladis Dronov <vdronov@redhat.com> Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Johan Hovold [Fri, 10 Jan 2020 19:59:52 +0000 (11:59 -0800)]
Input: aiptek - use descriptors of current altsetting
Make sure to always use the descriptors of the current alternate setting
to avoid future issues when accessing fields that may differ between
settings.
Johan Hovold [Fri, 10 Jan 2020 19:59:32 +0000 (11:59 -0800)]
Input: aiptek - fix endpoint sanity check
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could lead to the
driver binding to an invalid interface.
This in turn could cause the driver to misbehave or trigger a WARN() in
usb_submit_urb() that kernels with panic_on_warn set would choke on.
Fixes: dec280780d3f ("Input: aiptek - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Vladis Dronov <vdronov@redhat.com> Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The driver was checking the number of endpoints of the first alternate
setting instead of the current one, something which could be used by a
malicious device (or USB descriptor fuzzer) to trigger a NULL-pointer
dereference.
Miles Chen [Thu, 2 Jan 2020 23:10:16 +0000 (15:10 -0800)]
Input: evdev - convert kzalloc()/vzalloc() to kvzalloc()
We observed a large(order-3) allocation in evdev_open() and it may
cause an OOM kernel panic in kzalloc(), before we getting to the
vzalloc() fallback.
Fix it by converting kzalloc()/vzalloc() to kvzalloc() to avoid the
OOM killer logic as we have a vmalloc fallback.
InputReader invoked oom-killer: gfp_mask=0x240c2c0
(GFP_KERNEL|__GFP_NOWARN|__GFP_COMP|__GFP_ZERO), nodemask=0, order=3,
oom_score_adj=-900
...
(dump_backtrace) from (show_stack+0x18/0x1c)
(show_stack) from (dump_stack+0x94/0xa8)
(dump_stack) from (dump_header+0x7c/0xe4)
(dump_header) from (out_of_memory+0x334/0x348)
(out_of_memory) from (__alloc_pages_nodemask+0xe9c/0xeb8)
(__alloc_pages_nodemask) from (kmalloc_order_trace+0x34/0x128)
(kmalloc_order_trace) from (__kmalloc+0x258/0x36c)
(__kmalloc) from (evdev_open+0x5c/0x17c)
(evdev_open) from (chrdev_open+0x100/0x204)
(chrdev_open) from (do_dentry_open+0x21c/0x354)
(do_dentry_open) from (vfs_open+0x58/0x84)
(vfs_open) from (path_openat+0x640/0xc98)
(path_openat) from (do_filp_open+0x78/0x11c)
(do_filp_open) from (do_sys_open+0x130/0x244)
(do_sys_open) from (SyS_openat+0x14/0x18)
(SyS_openat) from (__sys_trace_return+0x0/0x10)
...
Normal: 12488*4kB (UMEH) 6984*8kB (UMEH) 2101*16kB (UMEH) 0*32kB
0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 139440kB
HighMem: 206*4kB (H) 131*8kB (H) 42*16kB (H) 2*32kB (H) 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2608kB
...
Kernel panic - not syncing: Out of memory and no killable processes...
Signed-off-by: Miles Chen <miles.chen@mediatek.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Linus Torvalds [Sun, 5 Jan 2020 19:15:31 +0000 (11:15 -0800)]
Merge tag 'riscv/for-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"Several fixes for RISC-V:
- Fix function graph trace support
- Prefix the CSR IRQ_* macro names with "RV_", to avoid collisions
with macros elsewhere in the Linux kernel tree named "IRQ_TIMER"
- Use __pa_symbol() when computing the physical address of a kernel
symbol, rather than __pa()
- Mark the RISC-V port as supporting GCOV
One DT addition:
- Describe the L2 cache controller in the FU540 DT file
One documentation update:
- Add patch acceptance guideline documentation"
* tag 'riscv/for-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
Documentation: riscv: add patch acceptance guidelines
riscv: prefix IRQ_ macro names with an RV_ namespace
clocksource: riscv: add notrace to riscv_sched_clock
riscv: ftrace: correct the condition logic in function graph tracer
riscv: dts: Add DT support for SiFive L2 cache controller
riscv: gcov: enable gcov for RISC-V
riscv: mm: use __pa_symbol for kernel symbols
Formalize, in kernel documentation, the patch acceptance policy for
arch/riscv. In summary, it states that as maintainers, we plan to
only accept patches for new modules or extensions that have been
frozen or ratified by the RISC-V Foundation.
We've been following these guidelines for the past few months. In the
meantime, we've received quite a bit of feedback that it would be
helpful to have these guidelines formally documented.
Based on a suggestion from Matthew Wilcox, we also add a link to this
file to Documentation/process/index.rst, to make this document easier
to find. The format of this document has also been changed to align
to the format outlined in the maintainer entry profiles, in accordance
with comments from Jon Corbet and Dan Williams.
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Krste Asanovic <krste@berkeley.edu> Cc: Andrew Waterman <waterman@eecs.berkeley.edu> Cc: Matthew Wilcox <willy@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net>
Paul Walmsley [Fri, 20 Dec 2019 11:09:49 +0000 (03:09 -0800)]
riscv: prefix IRQ_ macro names with an RV_ namespace
"IRQ_TIMER", used in the arch/riscv CSR header file, is a sufficiently
generic macro name that it's used by several source files across the
Linux code base. Some of these other files ultimately include the
arch/riscv CSR include file, causing collisions. Fix by prefixing the
RISC-V csr.h IRQ_ macro names with an RV_ prefix.
Fixes: def77bfd33876 ("riscv: abstract out CSR names for supervisor vs machine mode") Reported-by: Olof Johansson <olof@lixom.net> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Zong Li [Mon, 23 Dec 2019 08:46:14 +0000 (16:46 +0800)]
clocksource: riscv: add notrace to riscv_sched_clock
When enabling ftrace graph tracer, it gets the tracing clock in
ftrace_push_return_trace(). Eventually, it invokes riscv_sched_clock()
to get the clock value. If riscv_sched_clock() isn't marked with
'notrace', it will call ftrace_push_return_trace() and cause infinite
loop.
Signed-off-by: Zong Li <zong.li@sifive.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
[paul.walmsley@sifive.com: cleaned up patch description] Fixes: 53733cf57960 ("clocksource/drivers/riscv_timer: Provide the sched_clock") Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Linus Torvalds [Sun, 5 Jan 2020 03:38:51 +0000 (19:38 -0800)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"17 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
hexagon: define ioremap_uc
ocfs2: fix the crash due to call ocfs2_get_dlm_debug once less
ocfs2: call journal flush to mark journal as empty after journal recovery when mount
mm/hugetlb: defer freeing of huge pages if in non-task context
mm/gup: fix memory leak in __gup_benchmark_ioctl
mm/oom: fix pgtables units mismatch in Killed process message
fs/posix_acl.c: fix kernel-doc warnings
hexagon: work around compiler crash
hexagon: parenthesize registers in asm predicates
fs/namespace.c: make to_mnt_ns() static
fs/nsfs.c: include headers for missing declarations
fs/direct-io.c: include fs/internal.h for missing prototype
mm: move_pages: return valid node id in status if the page is already on the target node
memcg: account security cred as well to kmemcg
kcov: fix struct layout for kcov_remote_arg
mm/zsmalloc.c: fix the migrated zspage statistics.
mm/memory_hotplug: shrink zones when offlining memory
Linus Torvalds [Sun, 5 Jan 2020 03:28:30 +0000 (19:28 -0800)]
Merge tag 'apparmor-pr-2020-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
Pull apparmor fixes from John Johansen:
- performance regression: only get a label reference if the fast path
check fails
- fix aa_xattrs_match() may sleep while holding a RCU lock
- fix bind mounts aborting with -ENOMEM
* tag 'apparmor-pr-2020-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor:
apparmor: fix aa_xattrs_match() may sleep while holding a RCU lock
apparmor: only get a label reference if the fast path check fails
apparmor: fix bind mounts aborting with -ENOMEM
John Johansen [Thu, 2 Jan 2020 13:31:22 +0000 (05:31 -0800)]
apparmor: fix aa_xattrs_match() may sleep while holding a RCU lock
aa_xattrs_match() is unfortunately calling vfs_getxattr_alloc() from a
context protected by an rcu_read_lock. This can not be done as
vfs_getxattr_alloc() may sleep regardles of the gfp_t value being
passed to it.
Fix this by breaking the rcu_read_lock on the policy search when the
xattr match feature is requested and restarting the search if a policy
changes occur.
Fixes: ada1a8786ade ("apparmor: Add support for attaching profiles via xattr, presence and value") Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com> Reported-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: John Johansen <john.johansen@canonical.com>