Commit Graph

67 Commits

Author SHA1 Message Date
Thomas Weißschuh
ab477b766e leds: triggers: Flush pending brightness before activating trigger
The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.

Fixes: 0db37915d9 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6e ("leds: avoid flush_work in atomic context")
Cc: stable@vger.kernel.org
Tested-by: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 16:56:07 +01:00
Hans de Goede
b1bbd20f35 leds: trigger: Call synchronize_rcu() before calling trig->activate()
Some triggers call led_trigger_event() from their activate() callback
to initialize the brightness of the LED for which the trigger is being
activated.

In order for the LED's initial state to be set correctly this requires that
the led_trigger_event() call uses the new version of trigger->led_cdevs,
which has the new LED.

AFAICT led_trigger_event() will always use the new version when it is
running on the same CPU as where the list_add_tail_rcu() call was made,
which is why the missing synchronize_rcu() has not lead to bug reports.
But if activate() is pre-empted, sleeps or uses a worker then
the led_trigger_event() call may run on another CPU which may still use
the old trigger->led_cdevs list.

Add a synchronize_rcu() call to ensure that any led_trigger_event() calls
done from activate() always use the new list.

Triggers using led_trigger_event() from their activate() callback are:
net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21 11:57:10 +01:00
Hans de Goede
c0dc9adf94 leds: trigger: Unregister sysfs attributes before calling deactivate()
Triggers which have trigger specific sysfs attributes typically store
related data in trigger-data allocated by the activate() callback and
freed by the deactivate() callback.

Calling device_remove_groups() after calling deactivate() leaves a window
where the sysfs attributes show/store functions could be called after
deactivation and then operate on the just freed trigger-data.

Move the device_remove_groups() call to before deactivate() to close
this race window.

This also makes the deactivation path properly do things in reverse order
of the activation path which calls the activate() callback before calling
device_add_groups().

Fixes: a7e7a31563 ("leds: triggers: add device attribute support")
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21 11:57:09 +01:00
Hans de Goede
0921a57c91 leds: trigger: Add led_mc_trigger_event() function
Add a new led_mc_trigger_event() function for triggers which want to
change the color of a multi-color LED based on their trigger conditions.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31 12:57:42 +01:00
Heiner Kallweit
822c91e72e leds: trigger: Store brightness set by led_trigger_event()
If a simple trigger is assigned to a LED, then the LED may be off until
the next led_trigger_event() call. This may be an issue for simple
triggers with rare led_trigger_event() calls, e.g. power supply
charging indicators (drivers/power/supply/power_supply_leds.c).
Therefore persist the brightness value of the last led_trigger_event()
call and use this value if the trigger is assigned to a LED.
In addition add a getter for the trigger brightness value.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/b1358b25-3f30-458d-8240-5705ae007a8a@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-28 10:39:49 +00:00
Heiner Kallweit
9225333e48 leds: triggers: Add helper led_match_default_trigger
Avoid code duplication and factor out common functionality to new
helper led_match_default_trigger().

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/d78eef6f-c18c-4546-b83e-6d1890849154@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07 08:48:05 +00:00
Heiner Kallweit
e838a5a110 leds: trigger: Stop exporting trigger_list
Commit 682e98564ffb ("leds: trigger: panic: Simplify
led_trigger_set_panic") removed the last external user of variable
trigger_list. So stop exporting it. If in future a need should arise
again to access this variable, I think we better add some accessor
instead of exporting the variable directly.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/ca185fb1-3a66-46b9-920e-bfecbe39c6bf@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07 08:48:04 +00:00
Heiner Kallweit
e09c706bfb leds: trigger: Load trigger modules on-demand if used as default trigger
Even if a trigger is set as default trigger for a LED device,
the respective trigger module (if built as module) isn't automatically
loaded by the kernel if the LED device is registered. I think we can
do better. Try to load the module asynchronously by alias
ledtrig:<trigger name>. This requires that such an alias is added to
relevant triggers.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/79adb260-06ad-443a-a68e-abe4498c3298@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07 08:47:55 +00:00
Heiner Kallweit
c82a1662d4 leds: trigger: Remove unused function led_trigger_rename_static()
This function was added with a8df7b1ab7 ("leds: add led_trigger_rename
function") 11 yrs ago, but it has no users. So remove it.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/d90f30be-f661-4db7-b0b5-d09d07a78a68@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-12-13 15:55:09 +00:00
Hans de Goede
82f80ef5f3 leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
Not all triggers use LED_INIT_DEFAULT_TRIGGER, which means that it
will not get cleared when the default trigger is a trigger which
does not use it such as "default-on".

If the default trigger then later gets replaced by a trigger which
does check LED_INIT_DEFAULT_TRIGGER, such as "timer" then that trigger
will behave as if it is the default trigger which it should not do.

To fix this clear the LED_INIT_DEFAULT_TRIGGER flag when clearing
the current trigger, so that it will not be set for any subsequently
set (non default) triggers.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://lore.kernel.org/r/20230510162234.291439-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-25 12:16:33 +01:00
Hans de Goede
22720a87d0 leds: Fix oops about sleeping in led_trigger_blink()
led_trigger_blink() calls led_blink_set() from a RCU read-side critical
section so led_blink_set() must not sleep. Note sleeping was not allowed
before the switch to RCU either because a spinlock was held before.

led_blink_set() does not sleep when sw-blinking is used, but
many LED controller drivers with hw blink support have a blink_set
function which may sleep, leading to an oops like this one:

[  832.605062] ------------[ cut here ]------------
[  832.605085] Voluntary context switch within RCU read-side critical section!
[  832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690
<snip>
[  832.606453] Call Trace:
[  832.606466]  <TASK>
[  832.606487]  __schedule+0x9f/0x1480
[  832.606527]  schedule+0x5d/0xe0
[  832.606549]  schedule_timeout+0x79/0x140
[  832.606572]  ? __pfx_process_timeout+0x10/0x10
[  832.606599]  wait_for_completion_timeout+0x6f/0x140
[  832.606627]  i2c_dw_xfer+0x101/0x460
[  832.606659]  ? psi_group_change+0x168/0x400
[  832.606680]  __i2c_transfer+0x172/0x6d0
[  832.606709]  i2c_smbus_xfer_emulated+0x27d/0x9c0
[  832.606732]  ? __schedule+0x430/0x1480
[  832.606753]  ? preempt_count_add+0x6a/0xa0
[  832.606778]  ? get_nohz_timer_target+0x18/0x190
[  832.606796]  ? lock_timer_base+0x61/0x80
[  832.606817]  ? preempt_count_add+0x6a/0xa0
[  832.606842]  __i2c_smbus_xfer+0xa2/0x3f0
[  832.606862]  i2c_smbus_xfer+0x66/0xf0
[  832.606882]  i2c_smbus_read_byte_data+0x41/0x70
[  832.606901]  ? _raw_spin_unlock_irqrestore+0x23/0x40
[  832.606922]  ? __pm_runtime_suspend+0x46/0xc0
[  832.606946]  cht_wc_byte_reg_read+0x2e/0x60
[  832.606972]  _regmap_read+0x5c/0x120
[  832.606997]  _regmap_update_bits+0x96/0xc0
[  832.607023]  regmap_update_bits_base+0x5b/0x90
[  832.607053]  cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove]
[  832.607094]  led_blink_setup+0x28/0x100
[  832.607119]  led_trigger_blink+0x40/0x70
[  832.607145]  power_supply_update_leds+0x1b7/0x1c0
[  832.607174]  power_supply_changed_work+0x67/0xe0
[  832.607198]  process_one_work+0x1c8/0x3c0
[  832.607222]  worker_thread+0x4d/0x380
[  832.607243]  ? __pfx_worker_thread+0x10/0x10
[  832.607258]  kthread+0xe9/0x110
[  832.607279]  ? __pfx_kthread+0x10/0x10
[  832.607300]  ret_from_fork+0x2c/0x50
[  832.607337]  </TASK>
[  832.607344] ---[ end trace 0000000000000000 ]---

Add a new led_blink_set_nosleep() function which defers the actual
led_blink_set() call to a workqueue when necessary to fix this.

This also fixes an existing race where a pending led_set_brightness() has
been deferred to set_brightness_work and might then race with a later
led_cdev->blink_set() call. Note this race is only an issue with triggers
mixing led_trigger_event() and led_trigger_blink() calls, sysfs API
calls and led_trigger_blink_oneshot() are not affected.

Note rather then adding a separate blink_set_blocking callback this uses
the presence of the already existing brightness_set_blocking callback to
detect if the blinking call should be deferred to set_brightness_work.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-25 12:16:31 +01:00
Hans de Goede
e298d8a38b leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters
are pass by reference, so that hw-blink implementations can report
back the actual achieved delays when the values have been rounded
to something the hw supports.

This is really only interesting for the sysfs API / the timer trigger.
Other triggers don't really care about this and none of the callers of
led_trigger_blink[_oneshot]() do anything with the returned delay values.

Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value,
there are 2 reasons for this:

1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not.
So on hw where led_cdev->blink_set() sleeps the call needs to be deferred
to a workqueue, in which case the actual achieved delays are unknown
(this is a preparation patch for the deferring).

2. Since the callers don't care about the actual achieved delays, allowing
callers to directly pass a value leads to simpler code for most callers.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Florian Westphal <fw@strlen.de>
Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-25 12:16:27 +01:00
Johannes Berg
2a5a8fa8b2 leds: trigger: use RCU to protect the led_cdevs list
Even with the previous commit 27af8e2c90
("leds: trigger: fix potential deadlock with libata")
to this file, we still get lockdep unhappy, and Boqun
explained the report here:
https://lore.kernel.org/r/YNA+d1X4UkoQ7g8a@boqun-archlinux

Effectively, this means that the read_lock_irqsave() isn't
enough here because another CPU might be trying to do a
write lock, and thus block the readers.

This is all pretty messy, but it doesn't seem right that
the LEDs framework imposes some locking requirements on
users, in particular we'd have to make the spinlock in the
iwlwifi driver always disable IRQs, even if we don't need
that for any other reason, just to avoid this deadlock.

Since writes to the led_cdevs list are rare (and are done
by userspace), just switch the list to RCU. This costs a
synchronize_rcu() at removal time so we can ensure things
are correct, but that seems like a small price to pay for
getting lock-free iterations and no deadlocks (nor any
locking requirements imposed on users.)

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-09-27 16:16:42 +02:00
Andrea Righi
27af8e2c90 leds: trigger: fix potential deadlock with libata
We have the following potential deadlock condition:

 ========================================================
 WARNING: possible irq lock inversion dependency detected
 5.10.0-rc2+ #25 Not tainted
 --------------------------------------------------------
 swapper/3/0 just changed the state of lock:
 ffff8880063bd618 (&host->lock){-...}-{2:2}, at: ata_bmdma_interrupt+0x27/0x200
 but this lock took another, HARDIRQ-READ-unsafe lock in the past:
  (&trig->leddev_list_lock){.+.?}-{2:2}

 and interrupts could create inverse lock ordering between them.

 other info that might help us debug this:
  Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&trig->leddev_list_lock);
                                local_irq_disable();
                                lock(&host->lock);
                                lock(&trig->leddev_list_lock);
   <Interrupt>
     lock(&host->lock);

  *** DEADLOCK ***

 no locks held by swapper/3/0.

 the shortest dependencies between 2nd lock and 1st lock:
  -> (&trig->leddev_list_lock){.+.?}-{2:2} ops: 46 {
     HARDIRQ-ON-R at:
                       lock_acquire+0x15f/0x420
                       _raw_read_lock+0x42/0x90
                       led_trigger_event+0x2b/0x70
                       rfkill_global_led_trigger_worker+0x94/0xb0
                       process_one_work+0x240/0x560
                       worker_thread+0x58/0x3d0
                       kthread+0x151/0x170
                       ret_from_fork+0x1f/0x30
     IN-SOFTIRQ-R at:
                       lock_acquire+0x15f/0x420
                       _raw_read_lock+0x42/0x90
                       led_trigger_event+0x2b/0x70
                       kbd_bh+0x9e/0xc0
                       tasklet_action_common.constprop.0+0xe9/0x100
                       tasklet_action+0x22/0x30
                       __do_softirq+0xcc/0x46d
                       run_ksoftirqd+0x3f/0x70
                       smpboot_thread_fn+0x116/0x1f0
                       kthread+0x151/0x170
                       ret_from_fork+0x1f/0x30
     SOFTIRQ-ON-R at:
                       lock_acquire+0x15f/0x420
                       _raw_read_lock+0x42/0x90
                       led_trigger_event+0x2b/0x70
                       rfkill_global_led_trigger_worker+0x94/0xb0
                       process_one_work+0x240/0x560
                       worker_thread+0x58/0x3d0
                       kthread+0x151/0x170
                       ret_from_fork+0x1f/0x30
     INITIAL READ USE at:
                           lock_acquire+0x15f/0x420
                           _raw_read_lock+0x42/0x90
                           led_trigger_event+0x2b/0x70
                           rfkill_global_led_trigger_worker+0x94/0xb0
                           process_one_work+0x240/0x560
                           worker_thread+0x58/0x3d0
                           kthread+0x151/0x170
                           ret_from_fork+0x1f/0x30
   }
   ... key      at: [<ffffffff83da4c00>] __key.0+0x0/0x10
   ... acquired at:
    _raw_read_lock+0x42/0x90
    led_trigger_blink_oneshot+0x3b/0x90
    ledtrig_disk_activity+0x3c/0xa0
    ata_qc_complete+0x26/0x450
    ata_do_link_abort+0xa3/0xe0
    ata_port_freeze+0x2e/0x40
    ata_hsm_qc_complete+0x94/0xa0
    ata_sff_hsm_move+0x177/0x7a0
    ata_sff_pio_task+0xc7/0x1b0
    process_one_work+0x240/0x560
    worker_thread+0x58/0x3d0
    kthread+0x151/0x170
    ret_from_fork+0x1f/0x30

 -> (&host->lock){-...}-{2:2} ops: 69 {
    IN-HARDIRQ-W at:
                     lock_acquire+0x15f/0x420
                     _raw_spin_lock_irqsave+0x52/0xa0
                     ata_bmdma_interrupt+0x27/0x200
                     __handle_irq_event_percpu+0xd5/0x2b0
                     handle_irq_event+0x57/0xb0
                     handle_edge_irq+0x8c/0x230
                     asm_call_irq_on_stack+0xf/0x20
                     common_interrupt+0x100/0x1c0
                     asm_common_interrupt+0x1e/0x40
                     native_safe_halt+0xe/0x10
                     arch_cpu_idle+0x15/0x20
                     default_idle_call+0x59/0x1c0
                     do_idle+0x22c/0x2c0
                     cpu_startup_entry+0x20/0x30
                     start_secondary+0x11d/0x150
                     secondary_startup_64_no_verify+0xa6/0xab
    INITIAL USE at:
                    lock_acquire+0x15f/0x420
                    _raw_spin_lock_irqsave+0x52/0xa0
                    ata_dev_init+0x54/0xe0
                    ata_link_init+0x8b/0xd0
                    ata_port_alloc+0x1f1/0x210
                    ata_host_alloc+0xf1/0x130
                    ata_host_alloc_pinfo+0x14/0xb0
                    ata_pci_sff_prepare_host+0x41/0xa0
                    ata_pci_bmdma_prepare_host+0x14/0x30
                    piix_init_one+0x21f/0x600
                    local_pci_probe+0x48/0x80
                    pci_device_probe+0x105/0x1c0
                    really_probe+0x221/0x490
                    driver_probe_device+0xe9/0x160
                    device_driver_attach+0xb2/0xc0
                    __driver_attach+0x91/0x150
                    bus_for_each_dev+0x81/0xc0
                    driver_attach+0x1e/0x20
                    bus_add_driver+0x138/0x1f0
                    driver_register+0x91/0xf0
                    __pci_register_driver+0x73/0x80
                    piix_init+0x1e/0x2e
                    do_one_initcall+0x5f/0x2d0
                    kernel_init_freeable+0x26f/0x2cf
                    kernel_init+0xe/0x113
                    ret_from_fork+0x1f/0x30
  }
  ... key      at: [<ffffffff83d9fdc0>] __key.6+0x0/0x10
  ... acquired at:
    __lock_acquire+0x9da/0x2370
    lock_acquire+0x15f/0x420
    _raw_spin_lock_irqsave+0x52/0xa0
    ata_bmdma_interrupt+0x27/0x200
    __handle_irq_event_percpu+0xd5/0x2b0
    handle_irq_event+0x57/0xb0
    handle_edge_irq+0x8c/0x230
    asm_call_irq_on_stack+0xf/0x20
    common_interrupt+0x100/0x1c0
    asm_common_interrupt+0x1e/0x40
    native_safe_halt+0xe/0x10
    arch_cpu_idle+0x15/0x20
    default_idle_call+0x59/0x1c0
    do_idle+0x22c/0x2c0
    cpu_startup_entry+0x20/0x30
    start_secondary+0x11d/0x150
    secondary_startup_64_no_verify+0xa6/0xab

This lockdep splat is reported after:
commit e918188611 ("locking: More accurate annotations for read_lock()")

To clarify:
 - read-locks are recursive only in interrupt context (when
   in_interrupt() returns true)
 - after acquiring host->lock in CPU1, another cpu (i.e. CPU2) may call
   write_lock(&trig->leddev_list_lock) that would be blocked by CPU0
   that holds trig->leddev_list_lock in read-mode
 - when CPU1 (ata_ac_complete()) tries to read-lock
   trig->leddev_list_lock, it would be blocked by the write-lock waiter
   on CPU2 (because we are not in interrupt context, so the read-lock is
   not recursive)
 - at this point if an interrupt happens on CPU0 and
   ata_bmdma_interrupt() is executed it will try to acquire host->lock,
   that is held by CPU1, that is currently blocked by CPU2, so:

   * CPU0 blocked by CPU1
   * CPU1 blocked by CPU2
   * CPU2 blocked by CPU0

     *** DEADLOCK ***

The deadlock scenario is better represented by the following schema
(thanks to Boqun Feng <boqun.feng@gmail.com> for the schema and the
detailed explanation of the deadlock condition):

 CPU 0:                          CPU 1:                        CPU 2:
 -----                           -----                         -----
 led_trigger_event():
   read_lock(&trig->leddev_list_lock);
 				<workqueue>
 				ata_hsm_qc_complete():
 				  spin_lock_irqsave(&host->lock);
 								write_lock(&trig->leddev_list_lock);
 				  ata_port_freeze():
 				    ata_do_link_abort():
 				      ata_qc_complete():
 					ledtrig_disk_activity():
 					  led_trigger_blink_oneshot():
 					    read_lock(&trig->leddev_list_lock);
 					    // ^ not in in_interrupt() context, so could get blocked by CPU 2
 <interrupt>
   ata_bmdma_interrupt():
     spin_lock_irqsave(&host->lock);

Fix by using read_lock_irqsave/irqrestore() in led_trigger_event(), so
that no interrupt can happen in between, preventing the deadlock
condition.

Apply the same change to led_trigger_blink_setup() as well, since the
same deadlock scenario can also happen in power_supply_update_bat_leds()
-> led_trigger_blink() -> led_trigger_blink_setup() (workqueue context),
and potentially prevent other similar usages.

Link: https://lore.kernel.org/lkml/20201101092614.GB3989@xps-13-7390/
Fixes: eb25cb9956 ("leds: convert IDE trigger to common disk trigger")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-01-31 10:38:03 +01:00
Marek Behún
93690cdf30 leds: trigger: add support for LED-private device triggers
Some LED controllers may come with an internal HW triggering mechanism
for the LED and the ability to switch between SW control and the
internal HW control. This includes most PHYs, various ethernet switches,
the Turris Omnia LED controller or AXP20X PMIC.

This adds support for registering such triggers.

This code is based on work by Pavel Machek <pavel@ucw.cz> and
Ondřej Jirman <megous@megous.com>.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-22 14:42:07 +02:00
Flavio Suligoi
14d3e74f59 leds: fix spelling mistake
Fix typo: "Tigger" --> "Trigger"

Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-12 10:04:59 +02:00
Akinobu Mita
11f7000221 leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
Reading /sys/class/leds/<led>/trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.

Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all available LED triggers
and which trigger is currently activated.

We work around it here by converting /sys/class/leds/<led>/trigger to
binary attribute, which is not limited by length. This is _not_ good
design, do not copy it.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>A
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-11-03 17:38:14 +01:00
Oleh Kravchenko
4016ba8588 led: triggers: Fix dereferencing of null pointer
Error was detected by PVS-Studio:
V522 Dereferencing of the null pointer 'led_cdev->trigger' might take place.

Fixes: 2282e125a4 ("leds: triggers: let struct led_trigger::activate() return an error code")
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-09-05 22:32:45 +02:00
Wenwen Wang
60e2dde1e9 led: triggers: Fix a memory leak bug
In led_trigger_set(), 'event' is allocated in kasprintf(). However, it is
not deallocated in the following execution if the label 'err_activate' or
'err_add_groups' is entered, leading to memory leaks. To fix this issue,
free 'event' before returning the error.

Fixes: 52c47742f7 ("leds: triggers: send uevent when changing triggers")
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-08-20 20:21:22 +02:00
Thomas Gleixner
d2912cb15b treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-19 17:09:55 +02:00
Krzysztof Kozlowski
8146aace60 led: triggers: Initialize LED_INIT_DEFAULT_TRIGGER if trigger is brought after class
Trigger driver can be initialized after the LED class device driver.  In
such case led_trigger_set_default() won't be called and flag
LED_INIT_DEFAULT_TRIGGER should be set from led_trigger_register().

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-12-10 21:31:55 +01:00
Jacek Anaszewski
02d31765bb led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag
Add the flag LED_INIT_DEFAULT_TRIGGER for indicating that trigger
being set is a default trigger for the LED class device, and
thus it should be initialized with settings provided in the fwnode.

Set the flag in the led_trigger_set_default(). It is expected to be
cleared in the activate() op of a trigger after trigger fwnode
initialization data is parsed and applied. This should happen only
once after LED class device registration, to allow leaving triggers
in the idle state on re-apply and let the users apply their own
settings without interference from the default ones.

Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2018-12-10 21:31:55 +01:00
Jacek Anaszewski
c4f7bd4a42 led: triggers: Break the for loop after default trigger is found
It is of no avail to continue iterating through registered
triggers in the led_trigger_set_default() after the trigger to set
has been found. Add "break" statement to fix this omission.

Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2018-12-10 21:10:42 +01:00
Uwe Kleine-König
a7d5904a6f leds: triggers: handle .trigger_data and .activated() in the core
This helps keeping these two fields consistent and drivers don't need to
care for this themselves any more.

Note that .activated isn't set to true automatically because that might
confuse some triggers when deactivating (e.g. ledtrig-gpio).

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-05 23:21:10 +02:00
Uwe Kleine-König
a7e7a31563 leds: triggers: add device attribute support
As many triggers use device attributes, add support for these in
led_trigger_set which allows simplifying the drivers accordingly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-05 23:21:10 +02:00
Uwe Kleine-König
2282e125a4 leds: triggers: let struct led_trigger::activate() return an error code
Given that activating a trigger can fail, let the callback return an
indication. This prevents to have a trigger active according to the
"trigger" sysfs attribute but not functional.

All users are changed accordingly to return 0 for now. There is no intended
change in behaviour.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-07-05 23:21:10 +02:00
Jacek Anaszewski
6f3bad9670 leds: triggers: Check return value of kobject_uevent_env()
Log error message if kobject_uevent_env() fails in led_trigger_set().

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-20 10:22:10 +02:00
Jacek Anaszewski
fbfa197afd leds: triggers: Return from led_trigger_set() if there is nothing to do
If led_trigger_set() is called with "trig" argument set to NULL, and there
is no trigger to remove then the function should return immediately so
as to avoid doing unnecessary allocation and sending uevent.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Reported-by: Daniel Romell <daro@hms.se>
Acked-by Daniel Romell <daro@hms.se>
2016-09-20 10:21:17 +02:00
Nathan Sullivan
3b9b95363c leds: do not overflow sysfs buffer in led_trigger_show
Per the documentation, use scnprintf instead of sprintf to ensure there
is never more than PAGE_SIZE bytes of trigger names put into the
buffer.

Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: Zach Brown <zach.brown@ni.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-08-16 21:34:30 +02:00
Paul Gortmaker
50237863c4 leds: make triggers explicitly non-modular
The Kconfig currently controlling compilation of this code is:

drivers/leds/trigger/Kconfig:menuconfig LEDS_TRIGGERS
drivers/leds/trigger/Kconfig:   bool "LED Trigger support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

We don't replace module.h with init.h since the file doesn't need that.
However it does use EXPORT_SYMBOL, so we add the export.h header.

Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-08-16 21:19:06 +02:00
Heiner Kallweit
a3eac76cdf leds: triggers: return error if invalid trigger name is provided via sysfs
If an invalid trigger name is provided via sysfs currently no error
is returned. Therefore it's not possible to determine whether the
trigger was set successfully.
Fix this by returning -EINVAL if no trigger is matched.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-07-04 08:51:37 +02:00
Ezequiel Garcia
ba93cdce5b leds: triggers: Allow to switch the trigger to "panic" on a kernel panic
This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.

This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-05-06 10:22:09 +02:00
Heiner Kallweit
7296c33ed1 leds: triggers: simplify led_trigger_store
led_trigger_store can be significantly simplified by using sysfs_streq().

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-14 09:22:23 +01:00
Heiner Kallweit
9534cc31dd leds: core: add managed version of led_trigger_register
Complementing devm_led_classdev_register add a managed version of
led_trigger_register.

I omit a managed version of led_classdev_unregister as the equivalent
devm_led_classdev_unregister isn't used in the kernel as of today.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-04 09:57:40 +01:00
Jacek Anaszewski
acd899e4f3 leds: implement sysfs interface locking mechanism
Add a mechanism for locking LED subsystem sysfs interface.
This patch prepares ground for addition of LED Flash Class
extension, whose API will be integrated with V4L2 Flash API.
Such a fusion enforces introducing a locking scheme, which
will secure consistent access to the LED Flash Class device.

The mechanism being introduced allows for disabling LED
subsystem sysfs interface by calling led_sysfs_disable function
and enabling it by calling led_sysfs_enable. The functions
alter the LED_SYSFS_DISABLE flag state and must be called
under mutex lock. The state of the lock is checked with use
of led_sysfs_is_disabled function. Such a design allows for
providing immediate feedback to the user space on whether
the LED Flash Class device is available or is under V4L2 Flash
sub-device control.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-14 14:29:35 -08:00
Sasha Levin
14f5716bc2 leds: make sure we unregister a trigger only once
Currently, we may attempt to unregister a trigger more than once, for
example when we receive two consecutive reboot notifications, or when
we do a regular unregistration plus reboot notification.

This leads to the following error since we try to delete the list node
twice:

[ 2780.254922] WARNING: CPU: 0 PID: 13764 at lib/list_debug.c:53 __list_del_entry+0x3e/0xe0()
[ 2780.265559] list_del corruption, ffffffffa5eb6470->next is LIST_POISON1 (dead000000100100)
[ 2780.271710] Modules linked in:
[ 2780.274156] CPU: 0 PID: 13764 Comm: kworker/0:2 Tainted: G        W     3.14.0-next-20140403-sasha-00012-gef5fa7d-dirty #373
[ 2780.283063] Workqueue: events do_poweroff
[ 2780.285644]  0000000000000009 ffff8800330dbb38 ffffffffa34bfa33 0000000000002fe0
[ 2780.291571]  ffff8800330dbb88 ffff8800330dbb78 ffffffffa015a37c ffff8800330dbb68
[ 2780.296670]  ffffffffa5eb6470 0000000000000000 ffffffffa5eb6400 ffffffffa5ad7430
[ 2780.299756] Call Trace:
[ 2780.301530] dump_stack (lib/dump_stack.c:52)
[ 2780.303802] warn_slowpath_common (kernel/panic.c:418)
[ 2780.306151] warn_slowpath_fmt (kernel/panic.c:433)
[ 2780.308156] __list_del_entry (lib/list_debug.c:51 (discriminator 1))
[ 2780.310800] list_del (lib/list_debug.c:78)
[ 2780.313175] led_trigger_unregister (drivers/leds/led-triggers.c:225)
[ 2780.315599] heartbeat_reboot_notifier (drivers/leds/trigger/ledtrig-heartbeat.c:119)
[ 2780.317247] notifier_call_chain (kernel/notifier.c:95)
[ 2780.320014] __blocking_notifier_call_chain (kernel/notifier.c:316)
[ 2780.323263] blocking_notifier_call_chain (kernel/notifier.c:326)
[ 2780.326096] kernel_power_off (include/linux/kmod.h:95 kernel/reboot.c:153 kernel/reboot.c:179)
[ 2780.327883] do_poweroff (kernel/power/poweroff.c:23)
[ 2780.330748] process_one_work (kernel/workqueue.c:2221 include/linux/jump_label.h:105 include/trace/events/workqueue.h:111 kernel/workqueue.c:2226)
[ 2780.333027] ? process_one_work (include/linux/workqueue.h:186 kernel/workqueue.c:611 kernel/workqueue.c:638 kernel/workqueue.c:2214)
[ 2780.335487] process_scheduled_works (include/linux/list.h:188 kernel/workqueue.c:2277)
[ 2780.337101] worker_thread (kernel/workqueue.c:2352)
[ 2780.338712] ? rescuer_thread (kernel/workqueue.c:2297)
[ 2780.341326] kthread (kernel/kthread.c:219)
[ 2780.343446] ? kthread_create_on_node (kernel/kthread.c:185)
[ 2780.345733] ret_from_fork (arch/x86/kernel/entry_64.S:555)
[ 2780.347168] ? kthread_create_on_node (kernel/kthread.c:185)

Prevent it by making sure we don't attempt to unregister a trigger that
is not in the triggers list.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-04-07 14:47:25 -07:00
Paul Gortmaker
7c7d2a26db drivers/leds: delete non-required instances of include <linux/init.h>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-02-27 09:56:56 -08:00
ZHAO Gang
11e043b53c leds: replace list_for_each with list_for_each_entry
Use the more convenient macro.

Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-27 17:28:52 -08:00
Sachin Kamat
09f5fe7563 leds: led-triggers: Fix checkpatch warnings
Fixes the following type of warnings:
WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ...
then pr_warn(...  to printk(KERN_WARNING ...
WARNING: quoted string split across lines

While at it also fix a coding style issue w.r.t braces.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-11-27 14:49:30 -08:00
Fabio Baltieri
a8df7b1ab7 leds: add led_trigger_rename function
Implements a "led_trigger_rename" function to rename a trigger with
proper locking.

This assumes that led name was originally allocated in non-constant
storage.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-11-26 14:28:50 -08:00
Colin Cross
52c47742f7 leds: triggers: send uevent when changing triggers
Some triggers create sysfs files when they are enabled. Send a uevent
"change" notification whenever the trigger is changed to allow userspace
processes such as udev to modify permissions on the new files.

A change notification will also be sent during registration of led class
devices or led triggers if the default trigger of an led class device
is found.

(bryan.wu@canonical.com: rename trigger to trig to fix the build error)

Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-11 18:32:41 +08:00
Fabio Baltieri
d23a22a74f leds: delay led_set_brightness if stopping soft-blink
Delay execution of led_set_brightness() if need to stop soft-blink
timer.

This allows led_set_brightness to be called in hard-irq context even if
soft-blink was activated on that LED.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-11 18:32:40 +08:00
Fabio Baltieri
86e99d23d0 Revert "leds: use led_set_brightness in led_trigger_event"
This reverts commit a0193cbee0.

The problem with the original commit was that it caused a warning with
the MMC trigger calling del_timer_sync from hard-irq context.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Reported-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-08-13 14:33:02 +08:00
Bryan Wu
20c0e6b878 leds: fix sparse warnings due to missing static
drivers/leds/led-core.c:56:6: sparse: symbol 'led_blink_setup' was not declared. Should it be static?
drivers/leds/led-triggers.c:233:6: sparse: symbol 'led_trigger_blink_setup' was not declared. Should it be static?

Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:35 +08:00
Fabio Baltieri
a0193cbee0 leds: use led_set_brightness in led_trigger_event
Fix led_trigger_event() to use led_set_brightness() instead of
__led_set_brightness(), so that any pending blink timer is stopped before
setting the new brightness value.  Without this fix LED status may be
overridden by a pending timer.

This allows a trigger to use a mix of led_trigger_event(),
led_trigger_blink() and led_trigger_blink_oneshot() without races.

(applied over: leds: Rename led_brightness_set() to led_set_brightness())

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Cc: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:34 +08:00
Shuah Khan
19cd67e2d5 leds: Rename led_brightness_set() to led_set_brightness()
Rename leds external interface led_brightness_set() to led_set_brightness().
This is the second phase of the change to reduce confusion between the
leds internal and external interfaces that set brightness. With this change,
now the external interface is led_set_brightness(). The first phase renamed
the internal interface led_set_brightness() to __led_set_brightness().
There are no changes to the interface implementations.

Signed-off-by: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:34 +08:00
Shuah Khan
0da3e65ba8 leds: Rename led_set_brightness() to __led_set_brightness()
Rename leds internal interface led_set_brightness() to __led_set_brightness()
to reduce confusion between led_set_brightness() and the external interface
led_brightness_set(). led_brightness_set() cancels the timer and then calls
led_set_brightness().

Signed-off-by: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:34 +08:00
Fabio Baltieri
5bb629c504 leds: add oneshot blink functions
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: Fabio Baltieri <fabio.baltieri@gmail.com>
Acked-by: Shuah Khan <shuahkhan@gmail.com>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:34 +08:00
Bryan Wu
eb202621f8 led-triggers: rename *trigger to *trig for unified naming scheme
No functional change.

Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24 07:52:33 +08:00
Kay Sievers
edbaa603eb driver-core: remove sysdev.h usage.
The sysdev.h file should not be needed by any in-kernel code, so remove
the .h file from these random files that seem to still want to include
it.

The sysdev code will be going away soon, so this include needs to be
removed no matter what.

Cc: Jiandong Zheng <jdzheng@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: "Venkatesh Pallipadi
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
2011-12-21 16:26:03 -08:00