[PATCH 0/5] Fix various issues with leds-pwm

[PATCH 0/5] Fix various issues with leds-pwm

[Russell King - ARM Linux]

This patch series fixes various problems with leds-pwm.

The first patch is very important to solve a boot time oops on OMAP
boards (and probably others) which has recently shown its face.

The next two clean up leds-pwm so that we can avoid the madness of
having entirely separate initialisation paths for DT and non-DT, which
I believe is the core cause of the initial problem.

The last two patches add support for LEDs connected in the opposite
sense to PWM outputs, where either the PWM does not support inversion,
or does not support it in a way that works sanely with leds-pwm.  These
add a new property to leds-pwm, hence why that patch (and this cover)
copies the DT people.

The first patch is an absolute must for going.

 .../devicetree/bindings/leds/leds-pwm.txt          |   2 +
 drivers/leds/leds-pwm.c                            | 161 ++++++++++-----------
 2 files changed, 82 insertions(+), 81 deletions(-)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 3/5] leds: leds-pwm: convert OF parsing code to use led_pwm_add()

[Russell King]

Convert the OF parsing code to use the common PWM LED registration code,
which means we have a consistent method, and single point where the
registration happens for both paths.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/leds/leds-pwm.c | 62 ++++++++++++++++++-------------------------------
 1 file changed, 23 insertions(+), 39 deletions(-)

diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2e6b6c5ca0e9..e1b4c23a409a 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -94,7 +94,7 @@ static void led_pwm_cleanup(struct led_pwm_priv *priv)
 }
 
 static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
-		       struct led_pwm *led)
+		       struct led_pwm *led, struct device_node *child)
 {
 	struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
 	int ret;
@@ -108,7 +108,10 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
 	led_data->cdev.max_brightness = led->max_brightness;
 	led_data->cdev.flags = LED_CORE_SUSPENDRESUME;
 
-	led_data->pwm = devm_pwm_get(dev, led->name);
+	if (child)
+		led_data->pwm = devm_of_pwm_get(dev, child, NULL);
+	else
+		led_data->pwm = devm_pwm_get(dev, led->name);
 	if (IS_ERR(led_data->pwm)) {
 		ret = PTR_ERR(led_data->pwm);
 		dev_err(dev, "unable to request PWM for %s: %d\n",
@@ -116,6 +119,9 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
 		return ret;
 	}
 
+	if (child)
+		led_data->period = pwm_get_period(led_data->pwm);
+
 	led_data->can_sleep = pwm_can_sleep(led_data->pwm);
 	if (led_data->can_sleep)
 		INIT_WORK(&led_data->work, led_pwm_work);
@@ -131,53 +137,30 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
 	return ret;
 }
 
-static int led_pwm_create_of(struct platform_device *pdev,
-			     struct led_pwm_priv *priv)
+static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
 {
 	struct device_node *child;
-	int ret;
-
-	for_each_child_of_node(pdev->dev.of_node, child) {
-		struct led_pwm_data *led_dat = &priv->leds[priv->num_leds];
+	struct led_pwm led;
+	int ret = 0;
 
-		led_dat->cdev.name = of_get_property(child, "label",
-						     NULL) ? : child->name;
+	memset(&led, 0, sizeof(led));
 
-		led_dat->pwm = devm_of_pwm_get(&pdev->dev, child, NULL);
-		if (IS_ERR(led_dat->pwm)) {
-			dev_err(&pdev->dev, "unable to request PWM for %s\n",
-				led_dat->cdev.name);
-			ret = PTR_ERR(led_dat->pwm);
-			goto err;
-		}
-		/* Get the period from PWM core when n*/
-		led_dat->period = pwm_get_period(led_dat->pwm);
+	for_each_child_of_node(dev->of_node, child) {
+		led.name = of_get_property(child, "label", NULL) ? :
+			   child->name;
 
-		led_dat->cdev.default_trigger = of_get_property(child,
+		led.default_trigger = of_get_property(child,
 						"linux,default-trigger", NULL);
 		of_property_read_u32(child, "max-brightness",
-				     &led_dat->cdev.max_brightness);
-
-		led_dat->cdev.brightness_set = led_pwm_set;
-		led_dat->cdev.brightness = LED_OFF;
-		led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
-
-		led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
-		if (led_dat->can_sleep)
-			INIT_WORK(&led_dat->work, led_pwm_work);
+				     &led.max_brightness);
 
-		ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
-		if (ret < 0) {
-			dev_err(&pdev->dev, "failed to register for %s\n",
-				led_dat->cdev.name);
+		ret = led_pwm_add(dev, priv, &led, child);
+		if (ret) {
 			of_node_put(child);
-			goto err;
+			break;
 		}
-		priv->num_leds++;
 	}
 
-	return 0;
-err:
 	return ret;
 }
 
@@ -203,12 +186,13 @@ static int led_pwm_probe(struct platform_device *pdev)
 
 	if (pdata) {
 		for (i = 0; i < count; i++) {
-			ret = led_pwm_add(&pdev->dev, priv, &pdata->leds[i]);
+			ret = led_pwm_add(&pdev->dev, priv, &pdata->leds[i],
+					  NULL);
 			if (ret)
 				break;
 		}
 	} else {
-		ret = led_pwm_create_of(pdev, priv);
+		ret = led_pwm_create_of(&pdev->dev, priv);
 	}
 
 	if (ret) {
-- 
1.8.3.1

[PATCH 5/5] leds: leds-pwm: add DT support for LEDs wired to supply

[Russell King]

The non-DT driver allowed an active low property to be specified, but DT
is missing this in its description.  Add the property to the DT binding
document, making it optional.  It defaults to active high, which retains
compatibility with existing descriptions.

This should only be used for causes where the LED is wired to supply,
and the PWM does not sensibly support its own inversion.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/devicetree/bindings/leds/leds-pwm.txt | 2 ++
 drivers/leds/leds-pwm.c                             | 1 +
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt
index 7297107cf832..6c6583c35f2f 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -13,6 +13,8 @@ node's name represents the name of the corresponding LED.
   For the pwms and pwm-names property please refer to:
   Documentation/devicetree/bindings/pwm/pwm.txt
 - max-brightness : Maximum brightness possible for the LED
+- active-low : (optional) For PWMs where the LED is wired to supply
+  rather than ground.
 - label :  (optional)
   see Documentation/devicetree/bindings/leds/common.txt
 - linux,default-trigger :  (optional)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 1d47742c551f..fb1eafe09324 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -155,6 +155,7 @@ static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
 
 		led.default_trigger = of_get_property(child,
 						"linux,default-trigger", NULL);
+		led.active_low = of_property_read_bool(child, "active-low");
 		of_property_read_u32(child, "max-brightness",
 				     &led.max_brightness);
 
-- 
1.8.3.1

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Bryan Wu]

On Sun, Apr 6, 2014 at 3:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This patch series fixes various problems with leds-pwm.
>
> The first patch is very important to solve a boot time oops on OMAP
> boards (and probably others) which has recently shown its face.
>
> The next two clean up leds-pwm so that we can avoid the madness of
> having entirely separate initialisation paths for DT and non-DT, which
> I believe is the core cause of the initial problem.
>
> The last two patches add support for LEDs connected in the opposite
> sense to PWM outputs, where either the PWM does not support inversion,
> or does not support it in a way that works sanely with leds-pwm.  These
> add a new property to leds-pwm, hence why that patch (and this cover)
> copies the DT people.
>
> The first patch is an absolute must for going.
>

Cool, I think Thierry is good for this patchset. I'm going to merge it
with Thierry's ack and queue it for 3.16 merge window.

-Bryan


>  .../devicetree/bindings/leds/leds-pwm.txt          |   2 +
>  drivers/leds/leds-pwm.c                            | 161 ++++++++++-----------
>  2 files changed, 82 insertions(+), 81 deletions(-)
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Russell King - ARM Linux]

On Mon, Apr 07, 2014 at 02:31:00PM -0700, Bryan Wu wrote:
> On Sun, Apr 6, 2014 at 3:18 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > This patch series fixes various problems with leds-pwm.
> >
> > The first patch is very important to solve a boot time oops on OMAP
> > boards (and probably others) which has recently shown its face.
> >
> > The next two clean up leds-pwm so that we can avoid the madness of
> > having entirely separate initialisation paths for DT and non-DT, which
> > I believe is the core cause of the initial problem.
> >
> > The last two patches add support for LEDs connected in the opposite
> > sense to PWM outputs, where either the PWM does not support inversion,
> > or does not support it in a way that works sanely with leds-pwm.  These
> > add a new property to leds-pwm, hence why that patch (and this cover)
> > copies the DT people.
> >
> > The first patch is an absolute must for going.
> >
> 
> Cool, I think Thierry is good for this patchset. I'm going to merge it
> with Thierry's ack and queue it for 3.16 merge window.

I don't mind the majority of the patch set being queued for the next
merge window, but I object to the first patch being delayed.  The
first patch is a very necessary bug fix for a regression that has
cropped up since -rc7.

It may not be the fault of leds-pwm, but it's leds-pwm which is most
certainly buggy.  kfree'ing a work_struct which is active is *not*
on.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Bryan Wu]

On Mon, Apr 7, 2014 at 2:33 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Apr 07, 2014 at 02:31:00PM -0700, Bryan Wu wrote:
>> On Sun, Apr 6, 2014 at 3:18 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > This patch series fixes various problems with leds-pwm.
>> >
>> > The first patch is very important to solve a boot time oops on OMAP
>> > boards (and probably others) which has recently shown its face.
>> >
>> > The next two clean up leds-pwm so that we can avoid the madness of
>> > having entirely separate initialisation paths for DT and non-DT, which
>> > I believe is the core cause of the initial problem.
>> >
>> > The last two patches add support for LEDs connected in the opposite
>> > sense to PWM outputs, where either the PWM does not support inversion,
>> > or does not support it in a way that works sanely with leds-pwm.  These
>> > add a new property to leds-pwm, hence why that patch (and this cover)
>> > copies the DT people.
>> >
>> > The first patch is an absolute must for going.
>> >
>>
>> Cool, I think Thierry is good for this patchset. I'm going to merge it
>> with Thierry's ack and queue it for 3.16 merge window.
>
> I don't mind the majority of the patch set being queued for the next
> merge window, but I object to the first patch being delayed.  The
> first patch is a very necessary bug fix for a regression that has
> cropped up since -rc7.
>
> It may not be the fault of leds-pwm, but it's leds-pwm which is most
> certainly buggy.  kfree'ing a work_struct which is active is *not*
> on.
>

Sure, actually just after I sent out my previous email, I think I need
add your first patch into my git pull request for 3.15 merge window.
So no worries, I will do that.

Thanks,
-Bryan

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Russell King - ARM Linux]

On Mon, Apr 07, 2014 at 02:36:26PM -0700, Bryan Wu wrote:
> On Mon, Apr 7, 2014 at 2:33 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Apr 07, 2014 at 02:31:00PM -0700, Bryan Wu wrote:
> >> On Sun, Apr 6, 2014 at 3:18 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > This patch series fixes various problems with leds-pwm.
> >> >
> >> > The first patch is very important to solve a boot time oops on OMAP
> >> > boards (and probably others) which has recently shown its face.
> >> >
> >> > The next two clean up leds-pwm so that we can avoid the madness of
> >> > having entirely separate initialisation paths for DT and non-DT, which
> >> > I believe is the core cause of the initial problem.
> >> >
> >> > The last two patches add support for LEDs connected in the opposite
> >> > sense to PWM outputs, where either the PWM does not support inversion,
> >> > or does not support it in a way that works sanely with leds-pwm.  These
> >> > add a new property to leds-pwm, hence why that patch (and this cover)
> >> > copies the DT people.
> >> >
> >> > The first patch is an absolute must for going.
> >> >
> >>
> >> Cool, I think Thierry is good for this patchset. I'm going to merge it
> >> with Thierry's ack and queue it for 3.16 merge window.
> >
> > I don't mind the majority of the patch set being queued for the next
> > merge window, but I object to the first patch being delayed.  The
> > first patch is a very necessary bug fix for a regression that has
> > cropped up since -rc7.
> >
> > It may not be the fault of leds-pwm, but it's leds-pwm which is most
> > certainly buggy.  kfree'ing a work_struct which is active is *not*
> > on.
> >
> 
> Sure, actually just after I sent out my previous email, I think I need
> add your first patch into my git pull request for 3.15 merge window.
> So no worries, I will do that.

So, I see this commit in mainline:

commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
Merge: 75e300c8ba58 2f05e1d4458f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Dec 15 12:52:42 2012 -0800

    Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
    
    Pull LED subsystem update from Bryan Wu.
    
    * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (47 commits)

Yet I don't see this patch series in it.  What's the story behind the
lack of progress on this?

Your April response clearly indicated that the entire patch set was going
in during the 3.16 merge window.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Bryan Wu]

On Thu, Jun 12, 2014 at 10:12 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Apr 07, 2014 at 02:36:26PM -0700, Bryan Wu wrote:
>> On Mon, Apr 7, 2014 at 2:33 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Apr 07, 2014 at 02:31:00PM -0700, Bryan Wu wrote:
>> >> On Sun, Apr 6, 2014 at 3:18 PM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > This patch series fixes various problems with leds-pwm.
>> >> >
>> >> > The first patch is very important to solve a boot time oops on OMAP
>> >> > boards (and probably others) which has recently shown its face.
>> >> >
>> >> > The next two clean up leds-pwm so that we can avoid the madness of
>> >> > having entirely separate initialisation paths for DT and non-DT, which
>> >> > I believe is the core cause of the initial problem.
>> >> >
>> >> > The last two patches add support for LEDs connected in the opposite
>> >> > sense to PWM outputs, where either the PWM does not support inversion,
>> >> > or does not support it in a way that works sanely with leds-pwm.  These
>> >> > add a new property to leds-pwm, hence why that patch (and this cover)
>> >> > copies the DT people.
>> >> >
>> >> > The first patch is an absolute must for going.
>> >> >
>> >>
>> >> Cool, I think Thierry is good for this patchset. I'm going to merge it
>> >> with Thierry's ack and queue it for 3.16 merge window.
>> >
>> > I don't mind the majority of the patch set being queued for the next
>> > merge window, but I object to the first patch being delayed.  The
>> > first patch is a very necessary bug fix for a regression that has
>> > cropped up since -rc7.
>> >
>> > It may not be the fault of leds-pwm, but it's leds-pwm which is most
>> > certainly buggy.  kfree'ing a work_struct which is active is *not*
>> > on.
>> >
>>
>> Sure, actually just after I sent out my previous email, I think I need
>> add your first patch into my git pull request for 3.15 merge window.
>> So no worries, I will do that.
>
> So, I see this commit in mainline:
>
> commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
> Merge: 75e300c8ba58 2f05e1d4458f
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Sat Dec 15 12:52:42 2012 -0800
>

Are you sure? this was a git pull in 2012. At that time I didn't get
any patch from you.

The latest pull was

commit 4162877d3ffa900b618c369c490c7faa6af60e47
Merge: 6c61403 14f5716
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Apr 10 09:06:10 2014 -0700

    Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds

    Pull LED updates from Bryan Wu:
     "This cycle we got:
       - new driver for leds-mc13783
       - bug fixes
       - code cleanup"

    * 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
      leds: make sure we unregister a trigger only once
      leds: leds-pwm: properly clean up after probe failure

Here is your patch for the critical fixing which was merged.

      leds: clevo-mail: Make probe function __init
      leds-ot200: Fix dependencies
      leds-gpio: of: introduce MODULE_DEVICE_TABLE for module autoloading
      leds: clevo-mail: remove __initdata marker
      leds: leds-ss4200: remove __initdata marker
      leds: blinkm: remove unnecessary spaces
      leds: lp5562: remove unnecessary parentheses
      leds: leds-ss4200: remove DEFINE_PCI_DEVICE_TABLE macro
      leds: leds-s3c24xx: Trivial cleanup in header file
      drivers/leds: delete non-required instances of include <linux/init.h>
      leds: leds-gpio: add retain-state-suspended property
      leds: leds-mc13783: Add devicetree support
      leds: leds-mc13783: Remove unnecessary cleaning of registers on exit
      leds: leds-mc13783: Use proper "max_brightness" value fo LEDs
      leds: leds-mc13783: Use LED core PM functions
      leds: leds-mc13783: Add MC34708 LED support
      leds: Turn off led if blinking is disabled
      ledtrig-cpu: Handle CPU hot(un)plugging


>     Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
>
>     Pull LED subsystem update from Bryan Wu.
>
>     * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (47 commits)
>
> Yet I don't see this patch series in it.  What's the story behind the
> lack of progress on this?
>
> Your April response clearly indicated that the entire patch set was going
> in during the 3.16 merge window.
>

The rest of them are queued in my tree
http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/log/?h=for-next

And I will send them out during 3.16 merge window but now mainline is
still 3.15-rc8. I believe this is what we talked about before.

Oh, no, I'm sorry, I messed up 3.16 merge window which is before
3.15-rc1 with 3.17 merge window. And I really mean 3.17 merge window
which is before 3.16-rc1. My bad, I will definitely send them all out
during 3.17 merge window.

Thanks,
-Bryan

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Alexandre Belloni]

Hi,

On 12/06/2014 at 10:37:43 -0700, Bryan Wu wrote :
> On Thu, Jun 12, 2014 at 10:12 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > So, I see this commit in mainline:
> >
> > commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
> > Merge: 75e300c8ba58 2f05e1d4458f
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Sat Dec 15 12:52:42 2012 -0800
> >
> 
> Are you sure? this was a git pull in 2012. At that time I didn't get
> any patch from you.
> 
> The latest pull was
> 
> commit 4162877d3ffa900b618c369c490c7faa6af60e47
> Merge: 6c61403 14f5716
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Apr 10 09:06:10 2014 -0700
> 
>     Merge branch 'for-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
> 

This pull request was for 3.15.

> > Yet I don't see this patch series in it.  What's the story behind the
> > lack of progress on this?
> >
> > Your April response clearly indicated that the entire patch set was going
> > in during the 3.16 merge window.
> >
> 
> The rest of them are queued in my tree
> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/log/?h=for-next
> 
> And I will send them out during 3.16 merge window but now mainline is
> still 3.15-rc8. I believe this is what we talked about before.
> 
> Oh, no, I'm sorry, I messed up 3.16 merge window which is before
> 3.15-rc1 with 3.17 merge window. And I really mean 3.17 merge window
> which is before 3.16-rc1. My bad, I will definitely send them all out
> during 3.17 merge window.
> 

Your for-next branch was in linux-next for a while. You don't seem to
have sent a pull request for 3.16 and the merge window is not closed yet
so you can probably do it now.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Bryan Wu]

On Thu, Jun 12, 2014 at 10:56 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Hi,
>
> On 12/06/2014 at 10:37:43 -0700, Bryan Wu wrote :
>> On Thu, Jun 12, 2014 at 10:12 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > So, I see this commit in mainline:
>> >
>> > commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
>> > Merge: 75e300c8ba58 2f05e1d4458f
>> > Author: Linus Torvalds <torvalds@linux-foundation.org>
>> > Date:   Sat Dec 15 12:52:42 2012 -0800
>> >
>>
>> Are you sure? this was a git pull in 2012. At that time I didn't get
>> any patch from you.
>>
>> The latest pull was
>>
>> commit 4162877d3ffa900b618c369c490c7faa6af60e47
>> Merge: 6c61403 14f5716
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Thu Apr 10 09:06:10 2014 -0700
>>
>>     Merge branch 'for-next' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
>>
>
> This pull request was for 3.15.
>
>> > Yet I don't see this patch series in it.  What's the story behind the
>> > lack of progress on this?
>> >
>> > Your April response clearly indicated that the entire patch set was going
>> > in during the 3.16 merge window.
>> >
>>
>> The rest of them are queued in my tree
>> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/log/?h=for-next
>>
>> And I will send them out during 3.16 merge window but now mainline is
>> still 3.15-rc8. I believe this is what we talked about before.
>>
>> Oh, no, I'm sorry, I messed up 3.16 merge window which is before
>> 3.15-rc1 with 3.17 merge window. And I really mean 3.17 merge window
>> which is before 3.16-rc1. My bad, I will definitely send them all out
>> during 3.17 merge window.
>>
>
> Your for-next branch was in linux-next for a while. You don't seem to
> have sent a pull request for 3.16 and the merge window is not closed yet
> so you can probably do it now.
>
>

You guys are right. Today I'm not in good status to work. Looks like
3.16 merge window is open , right? I will send out pull request soon,
actually that's my plan to do that.

-Bryan

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Russell King - ARM Linux]

On Thu, Jun 12, 2014 at 10:37:43AM -0700, Bryan Wu wrote:
> > So, I see this commit in mainline:
> >
> > commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
> > Merge: 75e300c8ba58 2f05e1d4458f
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Sat Dec 15 12:52:42 2012 -0800
> 
> Are you sure? this was a git pull in 2012. At that time I didn't get
> any patch from you.

Yes, it's the wrong commit, sorry.

> The rest of them are queued in my tree
> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/log/?h=for-next
> 
> And I will send them out during 3.16 merge window but now mainline is
> still 3.15-rc8. I believe this is what we talked about before.

I'm not sure why you think that.

First, the merge window is almost over - it opened one week early when
-rc8 was released:

https://lkml.org/lkml/2014/6/1/264

Date	Sun, 1 Jun 2014 19:37:20 -0700
Subject	Linux 3.15-rc8 ... and merge window for 3.16

Secondly, 3.15 was released last Sunday:

Date	Sun, 8 Jun 2014 11:52:27 -0700
Subject	Linux 3.15 .. and continuation of merge window

> Oh, no, I'm sorry, I messed up 3.16 merge window which is before
> 3.15-rc1 with 3.17 merge window. And I really mean 3.17 merge window
> which is before 3.16-rc1. My bad, I will definitely send them all out
> during 3.17 merge window.

Sorry, I sent the patches in /good/ time for the 3.16 merge window -
two months before the current merge window opened... and now you seem
to be saying that you intended to get them *not* into the merge window
two months away from that point, but *five* months away from the point
that you claimed to accept them?

I'm also told that my patches are in next-20140528, and indeed in the
last linux-next, they are still there:

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/leds/leds-pwm.c

So you /can/ send them right now to Linus - the merge window is still
open for 3.16.

As for which merge window... here's a lesson.  This is how it normally
works:

3.15-rc8
3.15
<merge window for 3.16>
3.16-rc1
3.16-rc2
3.16-rc3
...
3.16-rc7
...
3.16
<merge window for 3.17>
3.17-rc1

So, your statement "3.16 merge window which is before 3.15-rc1" is
totally wrong.  The 3.X merge window happens immediately before
3.X-rc1 is released, for any X.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Bryan Wu]

On Thu, Jun 12, 2014 at 11:03 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jun 12, 2014 at 10:37:43AM -0700, Bryan Wu wrote:
>> > So, I see this commit in mainline:
>> >
>> > commit e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
>> > Merge: 75e300c8ba58 2f05e1d4458f
>> > Author: Linus Torvalds <torvalds@linux-foundation.org>
>> > Date:   Sat Dec 15 12:52:42 2012 -0800
>>
>> Are you sure? this was a git pull in 2012. At that time I didn't get
>> any patch from you.
>
> Yes, it's the wrong commit, sorry.
>
>> The rest of them are queued in my tree
>> http://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/log/?h=for-next
>>
>> And I will send them out during 3.16 merge window but now mainline is
>> still 3.15-rc8. I believe this is what we talked about before.
>
> I'm not sure why you think that.
>
> First, the merge window is almost over - it opened one week early when
> -rc8 was released:
>
> https://lkml.org/lkml/2014/6/1/264
>
> Date    Sun, 1 Jun 2014 19:37:20 -0700
> Subject Linux 3.15-rc8 ... and merge window for 3.16
>
> Secondly, 3.15 was released last Sunday:
>
> Date    Sun, 8 Jun 2014 11:52:27 -0700
> Subject Linux 3.15 .. and continuation of merge window
>
>> Oh, no, I'm sorry, I messed up 3.16 merge window which is before
>> 3.15-rc1 with 3.17 merge window. And I really mean 3.17 merge window
>> which is before 3.16-rc1. My bad, I will definitely send them all out
>> during 3.17 merge window.
>
> Sorry, I sent the patches in /good/ time for the 3.16 merge window -
> two months before the current merge window opened... and now you seem
> to be saying that you intended to get them *not* into the merge window
> two months away from that point, but *five* months away from the point
> that you claimed to accept them?
>
> I'm also told that my patches are in next-20140528, and indeed in the
> last linux-next, they are still there:
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/leds/leds-pwm.c
>
> So you /can/ send them right now to Linus - the merge window is still
> open for 3.16.
>
> As for which merge window... here's a lesson.  This is how it normally
> works:
>
> 3.15-rc8
> 3.15
> <merge window for 3.16>
> 3.16-rc1
> 3.16-rc2
> 3.16-rc3
> ...
> 3.16-rc7
> ...
> 3.16
> <merge window for 3.17>
> 3.17-rc1
>
> So, your statement "3.16 merge window which is before 3.15-rc1" is
> totally wrong.  The 3.X merge window happens immediately before
> 3.X-rc1 is released, for any X.
>

Indeed, let me refresh my brain from working on a strange bug recently.

The root cause is I didn't realize the merge window is open and forget
to send out pull request.  My original plan is to sent them out during
3.16 merge window. I just did.

And you previous email confused me, so I misunderstood the 3.16 merge
window is 3.17-rc1 which should be 3.16-rc1. God damn it, I messed up.

So actually everything is fine, I just send out the pull request.
Your first critical patch was merged during 3.15 cycle and the rest
for 3.16 merge window are in my pull request.

We are good now, right? -:((

-Bryan

Re: [PATCH 0/5] Fix various issues with leds-pwm

[Russell King - ARM Linux]

On Thu, Jun 12, 2014 at 11:16:50AM -0700, Bryan Wu wrote:
> Indeed, let me refresh my brain from working on a strange bug recently.
> 
> The root cause is I didn't realize the merge window is open and forget
> to send out pull request.  My original plan is to sent them out during
> 3.16 merge window. I just did.
> 
> And you previous email confused me, so I misunderstood the 3.16 merge
> window is 3.17-rc1 which should be 3.16-rc1. God damn it, I messed up.
> 
> So actually everything is fine, I just send out the pull request.
> Your first critical patch was merged during 3.15 cycle and the rest
> for 3.16 merge window are in my pull request.
> 
> We are good now, right? -:((

I hope so...  thanks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.