1. 05 5月, 2011 2 次提交
  2. 11 2月, 2011 1 次提交
    • D
      Input: ads7846 - check proper condition when freeing gpio · 0fbc9fdb
      Dmitry Torokhov 提交于
      When driver uses custom pendown detection method gpio_pendown is not
      set up and so we should not try to free it, otherwise we are presented
      with:
      
      ------------[ cut here ]------------
      WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x100/0x12c()
      Modules linked in:
      [<c0061208>] (unwind_backtrace+0x0/0xe4) from [<c0091f58>](warn_slowpath_common+0x4c/0x64)
      [<c0091f58>] (warn_slowpath_common+0x4c/0x64) from [<c0091f88>](warn_slowpath_null+0x18/0x1c)
      [<c0091f88>] (warn_slowpath_null+0x18/0x1c) from [<c024e610>](gpio_free+0x100/0x12c)
      [<c024e610>] (gpio_free+0x100/0x12c) from [<c03e9fbc>](ads7846_probe+0xa38/0xc5c)
      [<c03e9fbc>] (ads7846_probe+0xa38/0xc5c) from [<c02cff14>](spi_drv_probe+0x18/0x1c)
      [<c02cff14>] (spi_drv_probe+0x18/0x1c) from [<c028bca4>](driver_probe_device+0xc8/0x184)
      [<c028bca4>] (driver_probe_device+0xc8/0x184) from [<c028bdc8>](__driver_attach+0x68/0x8c)
      [<c028bdc8>] (__driver_attach+0x68/0x8c) from [<c028b4c8>](bus_for_each_dev+0x48/0x74)
      [<c028b4c8>] (bus_for_each_dev+0x48/0x74) from [<c028ae08>](bus_add_driver+0xa0/0x220)
      [<c028ae08>] (bus_add_driver+0xa0/0x220) from [<c028c0c0>](driver_register+0xa8/0x134)
      [<c028c0c0>] (driver_register+0xa8/0x134) from [<c0050550>](do_one_initcall+0xcc/0x1a4)
      [<c0050550>] (do_one_initcall+0xcc/0x1a4) from [<c00084e4>](kernel_init+0x14c/0x214)
      [<c00084e4>] (kernel_init+0x14c/0x214) from [<c005b494>](kernel_thread_exit+0x0/0x8)
      ---[ end trace 4053287f8a5ec18f ]---
      
      Also rearrange ads7846_setup_pendown() to have only one exit point
      returning success.
      Reported-by: NSourav Poddar <sourav.poddar@ti.com>
      Acked-by: NWolfram Sang <w.sang@pengutronix.de>
      Reviewed-by: NCharulatha V <charu@ti.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      0fbc9fdb
  3. 21 1月, 2011 1 次提交
  4. 18 10月, 2010 1 次提交
    • J
      Input: ads7846 - switch to using threaded IRQ · 2991a1ca
      Jason Wang 提交于
      Commit 91143379 introduces regulator operations in ads7846 touchscreen
      driver. Among these operations, some are called while holding a
      spinlock. On many platforms regulators reside on slow buses, such as
      I2C/SPI and require sleep while accessing them.
      
      The touchscreen itself is also a SPI device and currently relies on
      asynchronous SPI access to avoid sleeping in interrupt context. Let's
      switch to using threaded IRQ to be able to access SPI bus
      synchronously (which simplifies driver a bit); it also allows safe
      access to the regulators as well.
      
      This has been tested on the ti_omap3530evm board:
       1) using ts_lib after normal boot
       2) using ts_lib after "#echo 1/0 > /sys/bus/spi/devices/spi0.1/disable"
       3) using ts_lib after "#echo mem > /sys/power/state" and "wake up"
      
      Also tested on pandora.
      
      Based on original patch by Dmitry Torokhov.
      Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NJason Wang <jason77.wang@gmail.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      2991a1ca
  5. 04 7月, 2010 2 次提交
  6. 28 6月, 2010 1 次提交
  7. 02 6月, 2010 1 次提交
  8. 27 5月, 2010 1 次提交
    • K
      Input: ads7846 - return error on regulator_get() failure · 067fb2f6
      Kevin Hilman 提交于
      In probe(), if regulator_get() failed, an error code was not being
      returned causing the driver to be successfully bound, even though
      probe failed.  This in turn caused the suspend, resume and remove
      methods to be registered and accessed via the SPI core.  Since these
      functions all access private driver data using pointers that had been
      freed during the failed probe, this would lead to unpredictable
      behavior.
      
      This patch ensures that probe() returns an error code in this failure
      case so the driver is not bound.
      
      Found using lockdep and noticing the lock used in the suspend/resum
      path pointed to a bogus lock due to the freed memory.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      067fb2f6
  9. 11 3月, 2010 1 次提交
  10. 10 3月, 2010 1 次提交
  11. 25 2月, 2010 1 次提交
  12. 24 11月, 2009 2 次提交
  13. 23 9月, 2009 1 次提交
  14. 11 6月, 2009 1 次提交
  15. 20 5月, 2009 2 次提交
  16. 16 4月, 2009 1 次提交
    • B
      Input: ads7846 - fix unsafe disable_irq · 3f3e7c6e
      Ben Nizette 提交于
      The use of disable_irq inside the handler for the interrupt being
      disabled has always been dangerous.  disable_irq should wait for that
      handler to complete before returning -> deadlock.
      
      For some reason this wasn't actually the case until 3aa551c9 was merged
      but since this time, the ads7846 driver has deadlocked the system on
      first interrupt.
      
      Convert the driver to use the handler-safe _nosync variant.
      Signed-off-by: NBen Nizette <bn@niasdigital.com>
      Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3f3e7c6e
  17. 12 4月, 2009 1 次提交
  18. 30 3月, 2009 1 次提交
  19. 23 12月, 2008 1 次提交
  20. 25 11月, 2008 1 次提交
    • P
      hrtimer: removing all ur callback modes · ca109491
      Peter Zijlstra 提交于
      Impact: cleanup, move all hrtimer processing into hardirq context
      
      This is an attempt at removing some of the hrtimer complexity by
      reducing the number of callback modes to 1.
      
      This means that all hrtimer callback functions will be ran from HARD-irq
      context.
      
      I went through all the 30 odd hrtimer callback functions in the kernel
      and saw only one that I'm not quite sure of, which is the one in
      net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.
      
      Furthermore, the hrtimer core now calls callbacks directly with IRQs
      disabled in case you try to enqueue an expired timer. If this timer is a
      periodic timer (which should use hrtimer_forward() to advance its time)
      then it might be possible to end up in an inf. recursive loop due to the
      fact that hrtimer_forward() doesn't round up to the next timer
      granularity, and therefore keeps on calling the callback - obviously
      this needs a fix.
      
      Aside from that, this seems to compile and actually boot on my dual core
      test box - although I'm sure there are some bugs in, me not hitting any
      makes me certain :-)
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ca109491
  21. 30 10月, 2008 1 次提交
  22. 09 10月, 2008 1 次提交
  23. 18 9月, 2008 1 次提交
  24. 11 9月, 2008 2 次提交
  25. 24 7月, 2008 2 次提交
  26. 15 4月, 2008 1 次提交
  27. 02 4月, 2008 1 次提交
  28. 14 3月, 2008 1 次提交
  29. 21 1月, 2008 1 次提交
  30. 06 12月, 2007 1 次提交
  31. 20 10月, 2007 1 次提交
  32. 10 10月, 2007 1 次提交
  33. 18 7月, 2007 2 次提交