lkml.org 
[lkml]   [2013]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH 1/2] leds: simply LED trigger list management
From
Date
On Thu, 2013-01-17 at 01:06 +0000, Kim, Milo wrote:
> @@ -242,17 +233,15 @@ EXPORT_SYMBOL_GPL(led_trigger_unregister);
> void led_trigger_event(struct led_trigger *trig,
> enum led_brightness brightness)
> {
> - struct list_head *entry;
> + struct led_classdev *led_cdev;
>
> if (!trig)
> return;
>
> read_lock(&trig->leddev_list_lock);
> - list_for_each(entry, &trig->led_cdevs) {
> - struct led_classdev *led_cdev;
> -
> - led_cdev = list_entry(entry, struct led_classdev, trig_list);
> - led_set_brightness(led_cdev, brightness);
> + list_for_each_entry(led_cdev, &leds_list, node) {
> + if (led_cdev->trigger == trig)
> + led_set_brightness(led_cdev, brightness);
> }
> read_unlock(&trig->leddev_list_lock);

Continuing to use trig->leddev_list_lock doesn't seem right. Shouldn't
traversal of leds_list be guarded by the leds_list_lock rwsem? And if
so, is it safe to use a potentially-blocking lock in this context?




\
 
 \ /
  Last update: 2013-01-17 21:02    [W:0.079 / U:2.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site