1. 03 Apr, 2017 2 commits
  2. 01 Apr, 2017 1 commit
    • H. Nikolaus Schaller's avatar
      Input: bma150 - remove support for bma150 · f069b5a0
      H. Nikolaus Schaller authored
      This essentially reverts commit baf28d91 ("Input: bma150 - avoid
      binding to bma180 if IIO bma180 driver present") and commit ef3714fd
      ("Input: bma150 - extend chip detection for bma180")
      
      Rationale: initially (2012) the GTA04 device using a bma180 chip simply
      referenced the bma150 platform driver in its board file [1] which happened
      to work in all scenarios that were tested.
      
      When conversion to DT started (2014), we needed to make the driver be still
      recognised. Hence we introduced the compatibility to the bma180 chip in
      Linux 3.15-rc5 [2] without further checks if it is really 100% compatible.
      This worked flawlessly for years with the GTA04 device.
      
      Recently (2016), Hans de Goede pointed out that the chips are not as
      similar as they appeared and the driver works with the bma180 for the GTA04
      only by good luck. He proposed to remove the bma180 support completely [3],
      but we still did need it until we have a replacement. Thus, a conditional
      compile was added.
      
      We have now developed a generic iio-input-bridge which works with any 2 or
      3 axis iio based accelerometer. It has been tested on GTA04 and Pyra and
      works as expected. Therefore we can remove the bma180 support from this
      driver completely. User-space API compatibility can be restored by using
      the iio-input-bridge.
      
      Maybe it is time to convert the bma150 driver to iio as well and retire the
      accelerometer input drivers completely but this is a different story and
      task.
      
      [1]: https://github.com/neilbrown/linux/blob/gta04/3.2.y/arch/arm/mach-omap2/board-omap3gta04.c#L976
      [2]: https://patchwork.kernel.org/patch/3961171/
      [3]: https://patchwork.kernel.org/patch/9325481/
      
      
      
      Signed-off-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      f069b5a0
  3. 29 Mar, 2017 4 commits
  4. 25 Mar, 2017 8 commits
  5. 23 Mar, 2017 4 commits
  6. 18 Mar, 2017 1 commit
  7. 17 Mar, 2017 2 commits
  8. 15 Mar, 2017 1 commit
  9. 09 Mar, 2017 9 commits
  10. 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
  11. 07 Mar, 2017 4 commits
  12. 01 Mar, 2017 3 commits