Skip to content

L
linux
Switch branch/tag
  1. 12 Oct, 2019 1 commit
    • Evan Green's avatar
      Input: synaptics-rmi4 - avoid processing unknown IRQs · 363c5387
      Evan Green authored 
      rmi_process_interrupt_requests() calls handle_nested_irq() for
each interrupt status bit it finds. If the irq domain mapping for
this bit had not yet been set up, then it ends up calling
handle_nested_irq(0), which causes a NULL pointer dereference.

There's already code that masks the irq_status bits coming out of the
hardware with current_irq_mask, presumably to avoid this situation.
However current_irq_mask seems to more reflect the actual mask set
in the hardware rather than the IRQs software has set up and registered
for. For example, in rmi_driver_reset_handler(), the current_irq_mask
is initialized based on what is read from the hardware. If the reset
value of this mask enables IRQs that Linux has not set up yet, then
we end up in this situation.

There appears to be a third unused bitmask that used to serve this
purpose, fn_irq_bits. Use that bitmask instead of current_irq_mask
to avoid calling handle_nested_irq() on IRQs that have not yet been
set up.
Signed-off-by: default avatarEvan Green <evgreen@chromium.org>
Reviewed-by: default avatarAndrew Duggan <aduggan@synaptics.com>
Link: https://lore.kernel.org/r/20191008223657.163366-1-evgreen@chromium.org
Cc: stable@vger.kernel.org
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      363c5387
  3. 08 Oct, 2019 1 commit
    • Hans de Goede's avatar
      Input: soc_button_array - partial revert of support for newer surface devices · bcf05957
      Hans de Goede authored 
      Commit c3941593 ("Input: soc_button_array - add support for newer
surface devices") not only added support for the MSHW0040 ACPI HID,
but for some reason it also makes changes to the error handling of the
soc_button_lookup_gpio() call in soc_button_device_create(). Note ideally
this seamingly unrelated change would have been made in a separate commit,
with a message explaining the what and why of this change.

I guess this change may have been added to deal with -EPROBE_DEFER errors,
but in case of the existing support for PNP0C40 devices, treating
-EPROBE_DEFER as any other error is deliberate, see the comment this
commit adds for why.

The actual returning of -EPROBE_DEFER to the caller of soc_button_probe()
introduced by the new error checking causes a serious regression:

On devices with so called virtual GPIOs soc_button_lookup_gpio() will
always return -EPROBE_DEFER for these fake GPIOs, when this happens
during the second call of soc_button_device_create() we already have
successfully registered our first child. This causes the kernel to think
we are making progress with probing things even though we unregister the
child before again before we return the -EPROBE_DEFER. Since we are making
progress the kernel will retry deferred-probes again immediately ending
up stuck in a loop with the following showing in dmesg:

[  124.022697] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6537
[  124.040764] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6538
[  124.056967] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6539
[  124.072143] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6540
[  124.092373] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6541
[  124.108065] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6542
[  124.128483] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6543
[  124.147141] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6544
[  124.165070] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6545
[  124.179775] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6546
[  124.202726] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6547
<continues on and on and on>

And 1 CPU core being stuck at 100% and udev hanging since it is waiting
for the modprobe of soc_button_array to return.

This patch reverts the soc_button_lookup_gpio() error handling changes,
fixing this regression.

Fixes: c3941593 ("Input: soc_button_array - add support for newer surface devices")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205031Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Tested-by: default avatarMaximilian Luz <luzmaximilian@gmail.com>
Acked-by: default avatarMaximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20191005105551.353273-1-hdegoede@redhat.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      bcf05957
  5. 02 Oct, 2019 2 commits
  7. 16 Sep, 2019 1 commit
  9. 06 Sep, 2019 3 commits
  11. 02 Sep, 2019 11 commits
  13. 29 Aug, 2019 1 commit
    • Stephen Boyd's avatar
      Input: i8042 - enable wakeup on a stable struct device · c8a144b2
      Stephen Boyd authored 
      We don't know when the device will be added with device_add() in
serio_add_port() because serio_add_port() is called from a workqueue
that this driver schedules by calling serio_register_port(). The best we
can know is that the device will definitely not have been added yet when
the start callback is called on the serio device.

While it hasn't been shown to be a problem, proactively move the wakeup
enabling calls to the start hook so that we don't race with the
workqueue calling device_add(). This will avoid racy situations where
code tries to add wakeup sysfs attributes for this device from
dpm_sysfs_add() but the path in device_set_wakeup_capable() has already
done so.
Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      c8a144b2
  15. 20 Aug, 2019 4 commits
  17. 16 Aug, 2019 1 commit
  19. 14 Aug, 2019 1 commit
    • Stephen Boyd's avatar
      Input: remove dev_err() usage after platform_get_irq() · 0bec8b7e
      Stephen Boyd authored 
      We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.

// <smpl>
@@
expression ret;
struct platform_device *E;
@@

ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);

if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// </smpl>

While we're here, remove braces on if statements that only have one
statement (manually).
Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      0bec8b7e
  21. 12 Aug, 2019 10 commits
  23. 11 Aug, 2019 3 commits
  25. 10 Aug, 2019 1 commit
    • Linus Torvalds's avatar
      Merge tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · 296d05cb
      Linus Torvalds authored 
      Pull RISC-V updates from Paul Walmsley:
 "A few minor RISC-V updates for v5.3-rc4:

   - Remove __udivdi3() from the 32-bit Linux port, converting the only
     upstream user to use do_div(), per Linux policy

   - Convert the RISC-V standard clocksource away from per-cpu data
     structures, since only one is used by Linux, even on a multi-CPU
     system

   - A set of DT binding updates that remove an obsolete text binding in
     favor of a YAML binding, fix a bogus compatible string in the
     schema (thus fixing a "make dtbs_check" warning), and clarifies the
     future values expected in one of the RISC-V CPU properties"

* tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  dt-bindings: riscv: fix the schema compatible string for the HiFive Unleashed board
  dt-bindings: riscv: remove obsolete cpus.txt
  RISC-V: Remove udivdi3
  riscv: delay: use do_div() instead of __udivdi3()
  dt-bindings: Update the riscv,isa string description
  RISC-V: Remove per cpu clocksource
      296d05cb
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7