All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <jhovold@gmail.com>
To: Antonio Ospite <ospite@studenti.unina.it>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Richard Purdie <rpurdie@rpsys.net>,
	stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "leds: save the delay values after a successful call to blink_set()"
Date: Fri, 18 Nov 2011 20:06:38 +0100	[thread overview]
Message-ID: <20111118190638.GA19331@localhost> (raw)
In-Reply-To: <20111116222100.323aa751b8a19c0fc2e08a97@studenti.unina.it>

On Wed, Nov 16, 2011 at 10:21:00PM +0100, Antonio Ospite wrote:
> On Mon,  7 Nov 2011 11:36:37 +0100
> Johan Hovold <jhovold@gmail.com> wrote:
> 
> > This reverts commit 6123b0e274503a0d3588e84fbe07c9aa01bfaf5d.
> > 
> > The problem this patch intends to solve has already been fixed by commit
> > 7a5caabd090b8f7 (drivers/leds/ledtrig-timer.c: fix broken sysfs delay
> > handling).
> > 
> > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> 
> Sorry for not replying earlier, I was on vacation.
> 
> Thanks Johan, I've just verified the timer trigger works fine on 3.1
> indeed even without my changes. But keep reading, please.
> 
> > ---
> > 
> > Hi, 
> > 
> > A fix for the problem with the delay parameters not being stored is already in
> > 3.1 (and stable). Rather than storing both values at every call to
> > led_blink_set only the updated value is stored in led_delay_{on,off}_store in
> > ledtrig-timer.c.
> >
> 
> I thought that this was better fixed in the led_blink_set() directly,
> as delay_on and delay_off are led_cdev fields after all, not
> necessarily specific to ledtrig-timer, what about other users of them?
> For example I can see led_blink_set() used in: net/mac80211/led.c
> and led_trigger_blink(), which uses led_blink_set() in:
> drivers/power/power_supply_leds.c
> 
> Maybe I am missing something.

When ledtrig-timer was generalised to led_set_blink() with fallback to
software blinking, the blink_delay_{on,off} parameters were moved to
led_classdev and now have two, partly overlapping uses: to store the
ledtrig-timer delay parameters and to implement generic software
blinking.

Note that both uses are internal -- drivers implementing hardware
blinking through blink_set() receives both parameters at each call and
need not access these fields directly. And apart from the ledtrig-timer
sysfs interface there is no other way to read them back either.

In particular, there is currently no need to update them at each call to
led_blink_set() as far as I can see.

Thanks,
Johan

  reply	other threads:[~2011-11-18 19:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 22:03 [PATCH 0/2] leds: some issues with hardware blinking Antonio Ospite
2011-10-06 22:03 ` [PATCH 1/2] leds: save the delay values after a successful call to blink_set() Antonio Ospite
2011-10-07  7:38   ` Johannes Berg
2011-11-07 10:36     ` [PATCH] Revert "leds: save the delay values after a successful call to blink_set()" Johan Hovold
2011-11-16 21:21       ` Antonio Ospite
2011-11-18 19:06         ` Johan Hovold [this message]
2011-10-06 22:03 ` [PATCH 2/2] leds: turn the blink_timer off before starting to blink Antonio Ospite
2011-10-07  7:39   ` Johannes Berg

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=20111118190638.GA19331@localhost \
    --to=jhovold@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ospite@studenti.unina.it \
    --cc=rpurdie@rpsys.net \
    --cc=stable@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.