1. 24 11月, 2012 2 次提交
  2. 31 10月, 2012 1 次提交
  3. 30 10月, 2012 1 次提交
  4. 29 9月, 2012 1 次提交
  5. 20 9月, 2012 6 次提交
  6. 19 9月, 2012 1 次提交
  7. 14 9月, 2012 1 次提交
  8. 13 9月, 2012 1 次提交
  9. 22 8月, 2012 1 次提交
    • T
      workqueue: use mod_delayed_work() instead of __cancel + queue · e7c2f967
      Tejun Heo 提交于
      Now that mod_delayed_work() is safe to call from IRQ handlers,
      __cancel_delayed_work() followed by queue_delayed_work() can be
      replaced with mod_delayed_work().
      
      Most conversions are straight-forward except for the following.
      
      * net/core/link_watch.c: linkwatch_schedule_work() was doing a quite
        elaborate dancing around its delayed_work.  Collapse it such that
        linkwatch_work is queued for immediate execution if LW_URGENT and
        existing timer is kept otherwise.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> 
      e7c2f967
  10. 25 7月, 2012 1 次提交
    • S
      Input: synaptics - handle out of bounds values from the hardware · c0394506
      Seth Forshee 提交于
      The touchpad on the Acer Aspire One D250 will report out of range values
      in the extreme lower portion of the touchpad. These appear as abrupt
      changes in the values reported by the hardware from very low values to
      very high values, which can cause unexpected vertical jumps in the
      position of the mouse pointer.
      
      What seems to be happening is that the value is wrapping to a two's
      compliment negative value of higher resolution than the 13-bit value
      reported by the hardware, with the high-order bits being truncated. This
      patch adds handling for these values by converting them to the
      appropriate negative values.
      
      The only tricky part about this is deciding when to treat a number as
      negative. It stands to reason that if out of range values can be
      reported on the low end then it could also happen on the high end, so
      not all out of range values should be treated as negative. The approach
      taken here is to split the difference between the maximum legitimate
      value for the axis and the maximum possible value that the hardware can
      report, treating values greater than this number as negative and all
      other values as positive. This can be tweaked later if hardware is found
      that operates outside of these parameters.
      
      BugLink: http://bugs.launchpad.net/bugs/1001251
      Cc: stable@vger.kernel.org
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      c0394506
  11. 11 7月, 2012 1 次提交
  12. 08 7月, 2012 1 次提交
  13. 07 7月, 2012 1 次提交
  14. 11 5月, 2012 5 次提交
  15. 05 5月, 2012 3 次提交
  16. 02 5月, 2012 4 次提交
  17. 26 4月, 2012 2 次提交
  18. 21 4月, 2012 1 次提交
  19. 11 4月, 2012 1 次提交
  20. 10 4月, 2012 3 次提交
  21. 05 4月, 2012 1 次提交
  22. 04 4月, 2012 1 次提交