1. 05 Nov, 2019 2 commits
  2. 21 Oct, 2019 1 commit
  3. 16 Oct, 2019 1 commit
  4. 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
  5. 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
  6. 02 Oct, 2019 2 commits
  7. 16 Sep, 2019 1 commit
  8. 06 Sep, 2019 3 commits
  9. 02 Sep, 2019 11 commits
  10. 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
  11. 20 Aug, 2019 4 commits
  12. 16 Aug, 2019 1 commit
  13. 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
  14. 12 Aug, 2019 10 commits