1. 24 7月, 2012 4 次提交
    • F
      leds: fix led_brightness_set when soft-blinking · 43786482
      Fabio Baltieri 提交于
      Move led_stop_software_blink() code into led_brightness_set() to ensure
      software blink timer is stopped and cleared when changing trigger.
      
      Also use led_set_brightness() instead of calling
      led_cdev->brightness_set() directly to keep led_cdev->brightness
      consistent with current LED status.
      
      This ensure proper cleaning when changing triggers, as without this fix
      a LED may be turned off while leaving it's led_cdev->brightness = 1,
      leading to an erratic software-blink behaviour.
      
      The problem was easy to reproduce by changing the trigger from "timer"
      to "oneshot".
      Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      43786482
    • F
      ledtrig-ide-disk: use generic one-shot blink api · 3740e49c
      Fabio Baltieri 提交于
      Convert ledtrig-ide-disk code to use the generic API for one-shot LED
      blinking.
      
      This patch changes slightly the behaviour of the trigger, as while the
      original version kept the LED on under heavy activity, the new one keeps
      a constant on-off blink at 1 / (2 * BLINK_DELAY) Hz.
      
      (bryan.wu@canonical.com: remove 2 useless included header files)
      Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      3740e49c
    • F
      leds: add oneshot blink functions · 5bb629c5
      Fabio Baltieri 提交于
      Add two new functions, led_blink_set_oneshot and
      led_trigger_blink_oneshot, to be used by triggers for one-shot blink of
      led devices.
      
      This is implemented extending the existing software-blink code, and uses
      the same timer and handler function.
      
      The behavior of the code is to do a blink-on, blink-off sequence when
      the function is called, ignoring other calls until the sequence is
      completed so that the leds keep blinking at constant rate if the
      functions are called repeatedly.
      
      This is meant to be used by drivers which needs to trigger on sporadic
      event, but doesn't have clear busy/idle trigger points.
      
      After the blink sequence the led remains off. This behavior can be
      inverted setting the "invert" argument, which blink the led off, than on
      and leave the led on after the sequence.
      
      (bryan.wu@canonical.com: rebase to commit 'leds: don't disable blinking
      when writing the same value to delay_on or delay_off')
      Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
      Acked-by: NShuah Khan <shuahkhan@gmail.com>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      5bb629c5
    • B
      led-triggers: rename *trigger to *trig for unified naming scheme · eb202621
      Bryan Wu 提交于
      No functional change.
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      eb202621
  2. 04 7月, 2012 1 次提交
    • A
      leds: heartbeat: fix bug on panic · fb31fbeb
      Alexander Holler 提交于
      With commit 49dca5ae I introduced
      a bug (visible if CONFIG_PROVE_RCU is enabled) which occures when a panic
      has happened:
      
      [ 1526.520230] ===============================
      [ 1526.520230] [ INFO: suspicious RCU usage. ]
      [ 1526.520230] 3.5.0-rc1+ #12 Not tainted
      [ 1526.520230] -------------------------------
      [ 1526.520230] /c/kernel-tests/mm/include/linux/rcupdate.h:436 Illegal context switch in RCU read-side critical section!
      [ 1526.520230]
      [ 1526.520230] other info that might help us debug this:
      [ 1526.520230]
      [ 1526.520230]
      [ 1526.520230] rcu_scheduler_active = 1, debug_locks = 0
      [ 1526.520230] 3 locks held by net.agent/3279:
      [ 1526.520230]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff82f85962>] do_page_fault+0x193/0x390
      [ 1526.520230]  #1:  (panic_lock){+.+...}, at: [<ffffffff82ed2830>] panic+0x37/0x1d3
      [ 1526.520230]  #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff810b9b28>] rcu_lock_acquire+0x0/0x29
      [ 1526.520230]
      [ 1526.520230] stack backtrace:
      [ 1526.520230] Pid: 3279, comm: net.agent Not tainted 3.5.0-rc1+ #12
      [ 1526.520230] Call Trace:
      [ 1526.520230]  [<ffffffff810e1570>] lockdep_rcu_suspicious+0x109/0x112
      [ 1526.520230]  [<ffffffff810bfe3a>] rcu_preempt_sleep_check+0x45/0x47
      [ 1526.520230]  [<ffffffff810bfe5a>] __might_sleep+0x1e/0x19a
      [ 1526.520230]  [<ffffffff82f8010e>] down_write+0x26/0x81
      [ 1526.520230]  [<ffffffff8276a966>] led_trigger_unregister+0x1f/0x9c
      [ 1526.520230]  [<ffffffff8276def5>] heartbeat_reboot_notifier+0x15/0x19
      [ 1526.520230]  [<ffffffff82f85bf5>] notifier_call_chain+0x96/0xcd
      [ 1526.520230]  [<ffffffff82f85cba>] __atomic_notifier_call_chain+0x8e/0xff
      [ 1526.520230]  [<ffffffff81094b7c>] ? kmsg_dump+0x37/0x1eb
      [ 1526.520230]  [<ffffffff82f85d3f>] atomic_notifier_call_chain+0x14/0x16
      [ 1526.520230]  [<ffffffff82ed28e1>] panic+0xe8/0x1d3
      [ 1526.520230]  [<ffffffff811473e2>] out_of_memory+0x15d/0x1d3
      
      So in case of a panic, now just turn of the LED. Other approaches like
      scheduling a work to unregister the trigger aren't working because there
      isn't much which still runs after a panic occured (except timers).
      Signed-off-by: NAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
      fb31fbeb
  3. 12 6月, 2012 3 次提交
  4. 30 5月, 2012 11 次提交
  5. 11 5月, 2012 1 次提交
  6. 17 4月, 2012 1 次提交
  7. 24 3月, 2012 19 次提交