1. 23 Mar, 2017 2 commits
    • Javier Martinez Canillas's avatar
      Input: synaptics_i2c - add OF device ID table · 72bf60f1
      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.
      
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      72bf60f1
    • 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 2 commits