“6d25886ee2fbc05a7bf4dae5f5ae345cb73df2fd”上不存在“README.md”
  1. 29 5月, 2015 1 次提交
  2. 20 5月, 2015 1 次提交
  3. 03 2月, 2015 1 次提交
  4. 05 11月, 2014 1 次提交
  5. 20 10月, 2014 1 次提交
  6. 09 10月, 2014 2 次提交
  7. 23 9月, 2014 1 次提交
  8. 17 9月, 2014 1 次提交
  9. 29 8月, 2014 1 次提交
  10. 26 8月, 2014 1 次提交
  11. 07 5月, 2014 1 次提交
  12. 11 4月, 2014 4 次提交
  13. 05 2月, 2014 1 次提交
  14. 08 1月, 2014 1 次提交
  15. 11 12月, 2013 1 次提交
  16. 28 10月, 2013 5 次提交
  17. 16 8月, 2013 1 次提交
  18. 26 7月, 2013 1 次提交
  19. 22 4月, 2013 1 次提交
  20. 12 4月, 2013 1 次提交
  21. 06 3月, 2013 1 次提交
  22. 29 12月, 2012 1 次提交
  23. 07 12月, 2012 1 次提交
  24. 25 10月, 2012 1 次提交
  25. 24 9月, 2012 1 次提交
  26. 22 8月, 2012 1 次提交
  27. 14 8月, 2012 1 次提交
    • T
      workqueue: use mod_delayed_work() instead of cancel + queue · 41f63c53
      Tejun Heo 提交于
      Convert delayed_work users doing cancel_delayed_work() followed by
      queue_delayed_work() to mod_delayed_work().
      
      Most conversions are straight-forward.  Ones worth mentioning are,
      
      * drivers/edac/edac_mc.c: edac_mc_workq_setup() converted to always
        use mod_delayed_work() and cancel loop in
        edac_mc_reset_delay_period() is dropped.
      
      * drivers/platform/x86/thinkpad_acpi.c: No need to remember whether
        watchdog is active or not.  @fan_watchdog_active and related code
        dropped.
      
      * drivers/power/charger-manager.c: Seemingly a lot of
        delayed_work_pending() abuse going on here.
        [delayed_]work_pending() are unsynchronized and racy when used like
        this.  I converted one instance in fullbatt_handler().  Please
        conver the rest so that it invokes workqueue APIs for the intended
        target state rather than trying to game work item pending state
        transitions.  e.g. if timer should be modified - call
        mod_delayed_work(), canceled - call cancel_delayed_work[_sync]().
      
      * drivers/thermal/thermal_sys.c: thermal_zone_device_set_polling()
        simplified.  Note that round_jiffies() calls in this function are
        meaningless.  round_jiffies() work on absolute jiffies not delta
        delay used by delayed_work.
      
      v2: Tomi pointed out that __cancel_delayed_work() users can't be
          safely converted to mod_delayed_work().  They could be calling it
          from irq context and if that happens while delayed_work_timer_fn()
          is running, it could deadlock.  __cancel_delayed_work() users are
          dropped.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      41f63c53
  28. 07 6月, 2012 1 次提交
  29. 12 3月, 2012 1 次提交
    • P
      device.h: cleanup users outside of linux/include (C files) · 51990e82
      Paul Gortmaker 提交于
      For files that are actively using linux/device.h, make sure
      that they call it out.  This will allow us to clean up some
      of the implicit uses of linux/device.h within include/*
      without introducing build regressions.
      
      Yes, this was created by "cheating" -- i.e. the headers were
      cleaned up, and then the fallout was found and fixed, and then
      the two commits were reordered.  This ensures we don't introduce
      build regressions into the git history.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      51990e82
  30. 05 1月, 2012 1 次提交
    • J
      net/rfkill/rfkill-gpio.c: introduce missing kfree · 841f1d92
      Julia Lawall 提交于
      Error handling code following a kmalloc should free the allocated data.
      The label fail_alloc already does this for rfkill.
      
      A simplified version of the semantic match that finds the problem is as
      follows: (http://coccinelle.lip6.fr)
      
      // <smpl>
      @r exists@
      local idexpression x;
      statement S;
      identifier f1;
      position p1,p2;
      expression *ptr != NULL;
      @@
      
      x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
      ...
      if (x == NULL) S
      <... when != x
           when != if (...) { <+...x...+> }
      x->f1
      ...>
      (
       return \(0\|<+...x...+>\|ptr\);
      |
       return@p2 ...;
      )
      
      @script:python@
      p1 << r.p1;
      p2 << r.p2;
      @@
      
      print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      841f1d92
  31. 20 12月, 2011 1 次提交
  32. 01 12月, 2011 1 次提交
反馈
建议
客服 返回
顶部