Re: [PATCH v2] leds: add new lp8788 led driver

2012-08-01 Thread Mark Brown
On Thu, Jul 26, 2012 at 10:51:18AM +0800, Bryan Wu wrote: > OK, thanks, I've merge this patch through my tree and can I add your ack to > it? Sure, Acked-by: Mark Brown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH v2] leds: add new lp8788 led driver

2012-08-01 Thread Mark Brown
On Thu, Jul 26, 2012 at 10:51:18AM +0800, Bryan Wu wrote: OK, thanks, I've merge this patch through my tree and can I add your ack to it? Sure, Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-25 Thread Bryan Wu
On Thu, Jul 26, 2012 at 2:43 AM, Mark Brown wrote: > On Wed, Jul 25, 2012 at 12:46:56PM +0800, Bryan Wu wrote: > >> I'm going to Ack this driver and Mark will you merge this as whole patchset? > >> Acked-by: Bryan Wu > > It's an MFD so Samuel would normally apply if it were going via the MFD >

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-25 Thread Mark Brown
On Wed, Jul 25, 2012 at 12:46:56PM +0800, Bryan Wu wrote: > I'm going to Ack this driver and Mark will you merge this as whole patchset? > Acked-by: Bryan Wu It's an MFD so Samuel would normally apply if it were going via the MFD tree, though if the dependencies are correct there should be no

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-25 Thread Mark Brown
On Wed, Jul 25, 2012 at 12:46:56PM +0800, Bryan Wu wrote: I'm going to Ack this driver and Mark will you merge this as whole patchset? Acked-by: Bryan Wu bryan...@canonical.com It's an MFD so Samuel would normally apply if it were going via the MFD tree, though if the dependencies are correct

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-25 Thread Bryan Wu
On Thu, Jul 26, 2012 at 2:43 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Jul 25, 2012 at 12:46:56PM +0800, Bryan Wu wrote: I'm going to Ack this driver and Mark will you merge this as whole patchset? Acked-by: Bryan Wu bryan...@canonical.com It's an MFD so Samuel would

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-24 Thread Bryan Wu
On Tue, Jul 24, 2012 at 8:55 PM, Mark Brown wrote: > On Tue, Jul 24, 2012 at 08:23:00AM +0800, Bryan Wu wrote: >> On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown > >> > If the work is flushed then the state that userspace thought was set >> > when the driver is removed will actually be set before the

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-24 Thread Mark Brown
On Tue, Jul 24, 2012 at 08:23:00AM +0800, Bryan Wu wrote: > On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown > > If the work is flushed then the state that userspace thought was set > > when the driver is removed will actually be set before the driver is > > removed. This is fairly minor but might be

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-24 Thread Mark Brown
On Tue, Jul 24, 2012 at 08:23:00AM +0800, Bryan Wu wrote: On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown If the work is flushed then the state that userspace thought was set when the driver is removed will actually be set before the driver is removed. This is fairly minor but might be

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-24 Thread Bryan Wu
On Tue, Jul 24, 2012 at 8:55 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Jul 24, 2012 at 08:23:00AM +0800, Bryan Wu wrote: On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown If the work is flushed then the state that userspace thought was set when the driver is removed will

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-23 Thread Bryan Wu
On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown wrote: > On Sat, Jul 21, 2012 at 02:48:49AM +0800, Bryan Wu wrote: > >> Actually cancel_work_sync() is quite similar to flush_work_sync() >> here. For the timer thing, in fact it is NULL when cancel_work_sync() >> call __cancel_work_timer(). > >> And

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-23 Thread Bryan Wu
On Mon, Jul 23, 2012 at 2:19 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Sat, Jul 21, 2012 at 02:48:49AM +0800, Bryan Wu wrote: Actually cancel_work_sync() is quite similar to flush_work_sync() here. For the timer thing, in fact it is NULL when cancel_work_sync() call

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-22 Thread Mark Brown
On Sat, Jul 21, 2012 at 02:48:49AM +0800, Bryan Wu wrote: > Actually cancel_work_sync() is quite similar to flush_work_sync() > here. For the timer thing, in fact it is NULL when cancel_work_sync() > call __cancel_work_timer(). > And Mark, do you have any advice about the flush_work_sync() and >

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-22 Thread Mark Brown
On Sat, Jul 21, 2012 at 02:48:49AM +0800, Bryan Wu wrote: Actually cancel_work_sync() is quite similar to flush_work_sync() here. For the timer thing, in fact it is NULL when cancel_work_sync() call __cancel_work_timer(). And Mark, do you have any advice about the flush_work_sync() and

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Bryan Wu
On Fri, Jul 20, 2012 at 11:49 PM, Shuah Khan wrote: > On Fri, 2012-07-20 at 08:43 +, Kim, Milo wrote: >> TI LP8788 PMU has the current sink as the keyboard led driver. >> The brightness is controlled by the i2c commands. >> Configurable parameters can be defined in the platform side. >> >>

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread devendra.aaru
Hi, I think a mutex_unlock is missed out, On Fri, Jul 20, 2012 at 2:28 PM, Kim, Milo wrote: > + > +static void lp8788_led_work(struct work_struct *work) > +{ > + struct lp8788_led *led = container_of(work, struct lp8788_led, work); > + enum lp8788_isink_number num = led->isink_num;

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Shuah Khan
On Fri, 2012-07-20 at 08:43 +, Kim, Milo wrote: > TI LP8788 PMU has the current sink as the keyboard led driver. > The brightness is controlled by the i2c commands. > Configurable parameters can be defined in the platform side. > > Patch v2. > (a) use workqueue on changing the brightness > >

[PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Kim, Milo
TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform side. Patch v2. (a) use workqueue on changing the brightness (b) use mutex_lock/unlock when the brightness is set and the

[PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Kim, Milo
TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform side. Patch v2. (a) use workqueue on changing the brightness (b) use mutex_lock/unlock when the brightness is set and the

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Shuah Khan
On Fri, 2012-07-20 at 08:43 +, Kim, Milo wrote: TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform side. Patch v2. (a) use workqueue on changing the brightness (b) use

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread devendra.aaru
Hi, I think a mutex_unlock is missed out, On Fri, Jul 20, 2012 at 2:28 PM, Kim, Milo milo@ti.com wrote: + +static void lp8788_led_work(struct work_struct *work) +{ + struct lp8788_led *led = container_of(work, struct lp8788_led, work); + enum lp8788_isink_number num =

Re: [PATCH v2] leds: add new lp8788 led driver

2012-07-20 Thread Bryan Wu
On Fri, Jul 20, 2012 at 11:49 PM, Shuah Khan shuahk...@gmail.com wrote: On Fri, 2012-07-20 at 08:43 +, Kim, Milo wrote: TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform