linux-kernel - Re: [PATCH 1/2 (v2)] leds-bcm6328: Reuse bcm6328_led_set() instead of copying its functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <564AE00C.7050303@samsung.com>
Date:	Tue, 17 Nov 2015 09:06:36 +0100
From:	Jacek Anaszewski <j.anaszewski@...sung.com>
To:	Simon Arlott <simon@...e.lp0.eu>
Cc:	Álvaro Fernández Rojas <noltari@...il.com>,
	Jonas Gorski <jogo@...nwrt.org>,
	Richard Purdie <rpurdie@...ys.net>, linux-leds@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 (v2)] leds-bcm6328: Reuse bcm6328_led_set() instead of
 copying its functionality

Hi Alvaro, Simon,

On 11/17/2015 08:42 AM, Simon Arlott wrote:
> On 16/11/15 21:33, Álvaro Fernández Rojas wrote:
>> Still wrong, you are setting the led value after unlocking the spinlock.
>
> I have to unlock it because bcm6328_led_set() locks that spinlock.

Commit message from the first version of the patch justified that
properly. It should be preserved in the final patch:

As bcm6328_led_set() expects to acquire the spinlock, narrow the locking
to only cover reading of the current state. There is no need to hold the
spinlock between reading the current value and setting it again because
the LED device has not yet been registered.

>> El 16/11/2015 a las 21:24, Simon Arlott escribió:
>>> When ensuring a consistent initial LED state in bcm6328_led (as they may
>>> be blinking instead of on/off), the LED register is set using an inverted
>>> copy of bcm6328_led_set(). To avoid further errors relating to active low
>>> handling, call this function directly instead.
>>>
>>> As bcm6328_led_set() acquires the same spinlock again when updating the
>>> register, it is called after unlocking.
>>>
>>> Signed-off-by: Simon Arlott <simon@...e.lp0.eu>
>>> ---
>>>    drivers/leds/leds-bcm6328.c | 8 ++------
>>>    1 file changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
>>> index c7ea5c6..95d0cf9 100644
>>> --- a/drivers/leds/leds-bcm6328.c
>>> +++ b/drivers/leds/leds-bcm6328.c
>>> @@ -314,14 +314,10 @@ static int bcm6328_led(struct device *dev, struct device_node *nc, u32 reg,
>>>    	} else {
>>>    		led->cdev.brightness = LED_OFF;
>>>    	}
>>> -
>>> -	if ((led->active_low && led->cdev.brightness == LED_FULL) ||
>>> -	    (!led->active_low && led->cdev.brightness == LED_OFF))
>>> -		bcm6328_led_mode(led, BCM6328_LED_MODE_ON);
>>> -	else
>>> -		bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
>>>    	spin_unlock_irqrestore(lock, flags);
>>>
>>> +	bcm6328_led_set(&led->cdev, led->cdev.brightness);
>>> +
>>>    	led->cdev.brightness_set = bcm6328_led_set;
>>>    	led->cdev.blink_set = bcm6328_blink_set;
>>>
>>
>
>


-- 
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/