linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Arlott <simon@fire.lp0.eu>
To: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: "Álvaro Fernández Rojas" <noltari@gmail.com>,
	"Jonas Gorski" <jogo@openwrt.org>,
	"Richard Purdie" <rpurdie@rpsys.net>,
	linux-leds@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/2 (v3)] leds-bcm6328: Reuse bcm6328_led_set() instead of copying its functionality
Date: Sun, 22 Nov 2015 20:40:29 +0000	[thread overview]
Message-ID: <5652283D.1050601@simon.arlott.org.uk> (raw)
In-Reply-To: <564AE209.7000106@samsung.com>

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() expects to acquire the spinlock, call it after
unlocking. 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.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
On 17/11/15 08:15, Jacek Anaszewski wrote:
> On 11/17/2015 09:06 AM, Jacek Anaszewski wrote:
>> 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.
> 
> Hmm, if so, then spin_lock in bcm6328_led isn't needed at all, as it
> is guaranteed that no concurrent process will be executing this
> function.

No, it's still required because it has to protect the read/modify/write
for all the other LED devices that use the same register.

 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;
 
-- 
2.1.4

-- 
Simon Arlott

  reply	other threads:[~2015-11-22 20:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-24 16:53 [PATCH] leds: bcm6328: Handle default-state of LEDs correctly Simon Arlott
2015-10-26  8:45 ` Jacek Anaszewski
2015-10-26 12:36   ` Simon Arlott
2015-10-28 10:56     ` Jacek Anaszewski
2015-10-29 19:48       ` [PATCH] leds-bcm6328: Reuse bcm6328_led_set() instead of copying its functionality Simon Arlott
2015-11-04 15:41         ` Jacek Anaszewski
2015-11-04 15:46           ` Álvaro Fernández Rojas
2015-11-05 10:41             ` Jacek Anaszewski
2015-11-15 13:32               ` [PATCH 1/2] " Simon Arlott
2015-11-15 13:34                 ` [PATCH 2/2] leds-bcm6328: Swap LED ON and OFF definitions Simon Arlott
2015-11-23 10:20                   ` Jacek Anaszewski
2015-11-16 14:38                 ` [PATCH 1/2] leds-bcm6328: Reuse bcm6328_led_set() instead of copying its functionality Jacek Anaszewski
2015-11-16 20:24                   ` [PATCH 1/2 (v2)] " Simon Arlott
2015-11-16 21:33                     ` Álvaro Fernández Rojas
2015-11-17  7:42                       ` Simon Arlott
2015-11-17  8:06                         ` Jacek Anaszewski
2015-11-17  8:15                           ` Jacek Anaszewski
2015-11-22 20:40                             ` Simon Arlott [this message]
2015-11-23 10:19                               ` [PATCH 1/2 (v3)] " Jacek Anaszewski
2015-11-23 10:20                     ` [PATCH 1/2 (v2)] " Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5652283D.1050601@simon.arlott.org.uk \
    --to=simon@fire.lp0.eu \
    --cc=j.anaszewski@samsung.com \
    --cc=jogo@openwrt.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=noltari@gmail.com \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).