[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110830171424.71465472@v0nbox>
Date: Tue, 30 Aug 2011 17:14:24 -0400
From: Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Mark Brown <broonie@...nsource.wolfsonmicro.com>, x86@...nel.org,
Jonas Fonseca <jonas.fonseca@...oirfairelinux.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [v2 3/4] platform: (TS-5500) add LED support
On Mon, 29 Aug 2011 22:37:53 -0700,
"H. Peter Anvin" <hpa@...or.com> wrote:
> On 08/29/2011 03:16 PM, Mark Brown wrote:
> > On Fri, Aug 26, 2011 at 07:40:26PM -0400, Vivien Didelot wrote:
> >
> >> +static void ts5500_led_work(struct work_struct *work)
> >> +{
> >> + struct ts5500_led *led = container_of(work, struct
> >> ts5500_led, work);
> >> + u8 val = led->new_brightness ? led->bit : 0;
> >> +
> >> + outb(val, led->ioaddr);
> >> +}
> >
> > Can you not do outb() from atomic context? The reason lots of LED
> > drivers update the hardware in a workqueue is that they communicate
> > with the hardware over buses that can't be used in atomic context
> > like I2C or SPI but if that's not an issue then the workqueue is
> > not required and the code can be simplified.
>
> outb() can definitely be executed from atomic context.
>
> -hpa
Good to know, thanks. I removed the work_struct and instead lock a mutex
before setting led->new_brightness and calling outb().
Vivien.
--
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/
Powered by blists - more mailing lists