1. 23 Mar, 2017 1 commit
    • Javier Martinez Canillas's avatar
      Input: silead - add OF device ID table · 483e55d9
      Javier Martinez Canillas authored
      The driver doesn't have a struct of_device_id table but supported devices
      are registered via Device Trees. This is working on the assumption that a
      I2C device registered via OF will always match a legacy I2C device ID and
      that the MODALIAS reported will always be of the form i2c:<device>.
      
      But this could change in the future so the correct approach is to have an
      OF device ID table if the devices are registered via OF.
      
      As pointed by Hans de Goede, there's no mssl1680 and this is just used in
      some ACPI systems to identify the gsl1680 chip. So isn't included in the
      OF device ID table since a DT should use the proper device name instead.
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      483e55d9
  2. 18 Mar, 2017 1 commit
  3. 17 Mar, 2017 2 commits
  4. 15 Mar, 2017 1 commit
  5. 09 Mar, 2017 9 commits
  6. 08 Mar, 2017 1 commit
    • Michał Kępień's avatar
      Input: sparse-keymap - use a managed allocation for keymap copy · fabeb165
      Michał Kępień authored
      Some platform drivers use devm_input_allocate_device() together with
      sparse_keymap_setup() in their .probe callbacks.  While using the former
      simplifies error handling, using the latter necessitates calling
      sparse_keymap_free() in the error path and upon module unloading to
      avoid leaking the copy of the keymap allocated by sparse_keymap_setup().
      
      To help prevent such leaks and enable simpler error handling, make
      sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
      that it gets automatically freed.
      
      This works for both managed and non-managed input devices as the keymap
      is freed after the last reference to the input device is dropped.
      
      Note that actions previously taken by sparse_keymap_free(), i.e. taking
      the input device's mutex and zeroing its keycode and keycodemax fields,
      are now redundant because the managed keymap will always be freed after
      the input device is unregistered.
      Signed-off-by: default avatarMichał Kępień <kernel@kempniu.pl>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      fabeb165
  7. 07 Mar, 2017 4 commits
  8. 01 Mar, 2017 4 commits
  9. 25 Feb, 2017 2 commits
  10. 23 Feb, 2017 11 commits
  11. 20 Feb, 2017 1 commit
  12. 19 Feb, 2017 3 commits
    • Linus Torvalds's avatar
      Linux 4.10 · c470abd4
      Linus Torvalds authored
      c470abd4
    • Al Viro's avatar
      Fix missing sanity check in /dev/sg · 137d01df
      Al Viro authored
      What happens is that a write to /dev/sg is given a request with non-zero
      ->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
      to an array full of empty iovecs.
      
      Having write permission to /dev/sg shouldn't be equivalent to the
      ability to trigger BUG_ON() while holding spinlocks...
      
      Found by Dmitry Vyukov and syzkaller.
      
      [ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
        underlying issue.  - Linus ]
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      137d01df
    • Johannes Thumshirn's avatar
      scsi: don't BUG_ON() empty DMA transfers · fd3fc0b4
      Johannes Thumshirn authored
      Don't crash the machine just because of an empty transfer. Use WARN_ON()
      combined with returning an error.
      
      Found by Dmitry Vyukov and syzkaller.
      
      [ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
        cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
        might still be a cause of excessive log spamming.
      
        NOTE! If this warning ever triggers, we may end up leaking resources,
        since this doesn't bother to try to clean the command up. So this
        WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
        much worse.
      
        People really need to stop using BUG_ON() for "this shouldn't ever
        happen". It makes pretty much any bug worse.     - Linus ]
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: James Bottomley <jejb@linux.vnet.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fd3fc0b4