linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rpurdie@rpsys.net (Richard Purdie)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] mc13783: add LED support
Date: Wed, 26 May 2010 13:01:08 +0100	[thread overview]
Message-ID: <1274875268.24079.1.camel@rex> (raw)
In-Reply-To: <20100517200017.GA25262@sirena.org.uk>

On Mon, 2010-05-17 at 21:00 +0100, Mark Brown wrote:
> On Mon, May 17, 2010 at 09:02:42PM +0200, Uwe Kleine-K?nig wrote:
> > On Mon, May 17, 2010 at 06:40:22PM +0200, Philippe R?tornaz wrote:
> 
> > > +static void mc13783_led_set(struct led_classdev *led_cdev,
> > > +			   enum led_brightness value)
> > > +{
> > > +	struct mc13783_led *led;
> > > +
> > > +	led = container_of(led_cdev, struct mc13783_led, cdev);
> > > +	led->new_brightness = value;
> > > +	schedule_work(&led->work);
> > > +}
> 
> > I wonder why you don't set the registers directly here, but use a work
> > struct instead.
> 
> The LED API allows clients to configure the LEDs from interrupt context
> so for devices on blocking buses (like this) the driver needs to defer
> the actual implementation of the change.
> 
> It'd be nice to add helpers for this to the LED core, there's quite a
> few drivers implementing this idiom now - a flag that does the deferring
> of the set() for example.

Agreed, or a wrapper around the core which deferred implementations
could just use. I'm open to patches :)

Cheers,

Richard

  reply	other threads:[~2010-05-26 12:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-17 16:40 [PATCH 0/2] mc13783: LED support Philippe Rétornaz
2010-05-17 16:40 ` [PATCH 1/2] mc13783: add " Philippe Rétornaz
2010-05-17 16:40   ` [PATCH 2/2] mx31moboard: Add MC13783 led support Philippe Rétornaz
2010-05-17 19:02   ` [PATCH 1/2] mc13783: add LED support Uwe Kleine-König
2010-05-17 20:00     ` Mark Brown
2010-05-26 12:01       ` Richard Purdie [this message]
2010-05-26 15:58         ` Mark Brown
2010-05-18 11:27     ` Philippe Rétornaz
2010-05-25 14:57       ` Daniel Mack
2010-05-25 15:06         ` Philippe Rétornaz
2010-05-26 12:03           ` Richard Purdie

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=1274875268.24079.1.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=linux-arm-kernel@lists.infradead.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 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).