Dan,
On 05/16/2018 11:17 PM, Dan Murphy wrote:
Jacek and Andy
On 05/16/2018 04:13 PM, Dan Murphy wrote:
Jacek and Andy
On 05/16/2018 04:02 PM, Jacek Anaszewski wrote:
Hi Andy and Dan,
I will make all the changes then. I don't want to go through and ack each one.
Let me clarify. I
_led), GFP_KERNEL);
sizeof(*led) and one line in the result
And this?
Ack.
+ { },
Terminators better w/o comma.
Looking at other drivers adding comma's on the sentinel is accepted. See the
as3645a driver
So what?
Terminator at compile time even better.
+ {},
Ditto.
See above
See above.
--
Best regards,
Jacek Anaszewski
ne line in the result
And this?
Ack.
+ { },
Terminators better w/o comma.
Looking at other drivers adding comma's on the sentinel is accepted. See the
as3645a driver
So what?
Terminator at compile time even better.
+ {},
Ditto.
See above
See above.
--
Best regards,
Jacek Anaszewski
Dan,
On 05/15/2018 11:50 PM, Dan Murphy wrote:
Jacek
On 05/15/2018 04:24 PM, Jacek Anaszewski wrote:
Dan,
Thanks for the update. Please refer to my comments below.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED
Dan,
On 05/15/2018 11:50 PM, Dan Murphy wrote:
Jacek
On 05/15/2018 04:24 PM, Jacek Anaszewski wrote:
Dan,
Thanks for the update. Please refer to my comments below.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED
Dan,
On 05/15/2018 11:29 PM, Dan Murphy wrote:
Jacek
On 05/15/2018 04:13 PM, Jacek Anaszewski wrote:
Hi Dan,
Thanks for the update.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan
Dan,
On 05/15/2018 11:29 PM, Dan Murphy wrote:
Jacek
On 05/15/2018 04:13 PM, Jacek Anaszewski wrote:
Hi Dan,
Thanks for the update.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan
{ "LM36010", CHIP_LM36010 },
+ { "LM36011", CHIP_LM36011 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, lm3601x_id);
+
+static const struct of_device_id of_lm3601x_leds_match[] = {
+ { .compatible = "ti,lm36010", },
+ { .compatible = "ti,lm36011", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
+
+static struct i2c_driver lm3601x_i2c_driver = {
+ .driver = {
+ .name = "lm3601x",
+ .of_match_table = of_lm3601x_leds_match,
+ },
+ .probe = lm3601x_probe,
+ .remove = lm3601x_remove,
+ .id_table = lm3601x_id,
+};
+module_i2c_driver(lm3601x_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
+MODULE_AUTHOR("Dan Murphy <dmur...@ti.com>");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
CHIP_LM36010 },
+ { "LM36011", CHIP_LM36011 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, lm3601x_id);
+
+static const struct of_device_id of_lm3601x_leds_match[] = {
+ { .compatible = "ti,lm36010", },
+ { .compatible = "ti,lm36011", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
+
+static struct i2c_driver lm3601x_i2c_driver = {
+ .driver = {
+ .name = "lm3601x",
+ .of_match_table = of_lm3601x_leds_match,
+ },
+ .probe = lm3601x_probe,
+ .remove = lm3601x_remove,
+ .id_table = lm3601x_id,
+};
+module_i2c_driver(lm3601x_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
+MODULE_AUTHOR("Dan Murphy ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
led-sources = <1>;
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
Best regards,
Jacek Anaszewski
= <1>;
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
Best regards,
Jacek Anaszewski
latform_driver sc27xx_led_driver = {
+ .driver = {
+ .name = "sprd-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
+ .remove = sc27xx_led_remove,
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu <xiaotong...@spreadtrum.com>");
+MODULE_LICENSE("GPL v2");
Patch set applied to the for-next branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
.name = "sprd-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
+ .remove = sc27xx_led_remove,
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu ");
+MODULE_LICENSE("GPL v2");
Patch set applied to the for-next branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
Dan,
On 05/14/2018 10:07 PM, Dan Murphy wrote:
Jacek
On 05/11/2018 03:27 PM, Jacek Anaszewski wrote:
Dan,
On 05/11/2018 02:12 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
Hi Dan,
On 05/10/2018 09:10 PM, Dan Murphy wrote:
On 05/10
Dan,
On 05/14/2018 10:07 PM, Dan Murphy wrote:
Jacek
On 05/11/2018 03:27 PM, Jacek Anaszewski wrote:
Dan,
On 05/11/2018 02:12 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
Hi Dan,
On 05/10/2018 09:10 PM, Dan Murphy wrote:
On 05/10
ync.
So should we remove this code from the Max77693 driver too and fail probe as
being asked
in this driver?
Yes, that would match what the bindings require.
--
Best regards,
Jacek Anaszewski
ync.
So should we remove this code from the Max77693 driver too and fail probe as
being asked
in this driver?
Yes, that would match what the bindings require.
--
Best regards,
Jacek Anaszewski
ch that begins thread [0].
[0] https://lkml.org/lkml/2017/11/15/27
[1] https://lkml.org/lkml/2017/12/8/470
--
Best regards,
Jacek Anaszewski
ch that begins thread [0].
[0] https://lkml.org/lkml/2017/11/15/27
[1] https://lkml.org/lkml/2017/12/8/470
--
Best regards,
Jacek Anaszewski
Dan,
On 05/11/2018 02:12 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
Hi Dan,
On 05/10/2018 09:10 PM, Dan Murphy wrote:
On 05/10/2018 02:06 PM, Dan Murphy wrote:
Pavel
On 05/10/2018 01:54 PM, Pavel Machek wrote:
Hi!
Introduce
Dan,
On 05/11/2018 02:12 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
Hi Dan,
On 05/10/2018 09:10 PM, Dan Murphy wrote:
On 05/10/2018 02:06 PM, Dan Murphy wrote:
Pavel
On 05/10/2018 01:54 PM, Pavel Machek wrote:
Hi!
Introduce
Hi Dan,
On 05/11/2018 01:56 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:48 PM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the patch.
On 05/10/2018 07:47 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED
Hi Dan,
On 05/11/2018 01:56 PM, Dan Murphy wrote:
Jacek
Thanks for the review
On 05/10/2018 03:48 PM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the patch.
On 05/10/2018 07:47 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED
gt;;
+ flash-max-timeout-us = <800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "ir:torch";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
Best regards,
Jacek Anaszewski
flash-max-timeout-us = <800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "ir:torch";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
Best regards,
Jacek Anaszewski
LM3601X_MODE_STANDBY);
+
+ return 0;
+}
+
+static const struct i2c_device_id lm3601x_id[] = {
+ { "LM36010", CHIP_LM36010 },
+ { "LM36011", CHIP_LM36011 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, lm3601x_id);
+
+static const struct of_device_id of_lm3601x_leds_match[] = {
+ { .compatible = "ti,lm36010", },
+ { .compatible = "ti,lm36011", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
+
+static struct i2c_driver lm3601x_i2c_driver = {
+ .driver = {
+ .name = "lm3601x",
+ .of_match_table = of_lm3601x_leds_match,
+ },
+ .probe = lm3601x_probe,
+ .remove = lm3601x_remove,
+ .id_table = lm3601x_id,
+};
+module_i2c_driver(lm3601x_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
+MODULE_AUTHOR("Dan Murphy <dmur...@ti.com>");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
BY);
+
+ return 0;
+}
+
+static const struct i2c_device_id lm3601x_id[] = {
+ { "LM36010", CHIP_LM36010 },
+ { "LM36011", CHIP_LM36011 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, lm3601x_id);
+
+static const struct of_device_id of_lm3601x_leds_match[] = {
+ { .compatible = "ti,lm36010", },
+ { .compatible = "ti,lm36011", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
+
+static struct i2c_driver lm3601x_i2c_driver = {
+ .driver = {
+ .name = "lm3601x",
+ .of_match_table = of_lm3601x_leds_match,
+ },
+ .probe = lm3601x_probe,
+ .remove = lm3601x_remove,
+ .id_table = lm3601x_id,
+};
+module_i2c_driver(lm3601x_i2c_driver);
+
+MODULE_DESCRIPTION("Texas Instruments Flash Lighting driver for LM3601X");
+MODULE_AUTHOR("Dan Murphy ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
required if strobe is not
desired by the customer hence
why I have a separate DT node for it.
Dan
Dan
Best regards,
Pavel
--
Best regards,
Jacek Anaszewski
s not
desired by the customer hence
why I have a separate DT node for it.
Dan
Dan
Best regards,
Pavel
--
Best regards,
Jacek Anaszewski
mentation. It wouldn't much
differ from the custom pattern approach though, unless I'm missing some
gain of having pattern setting in a uniformly named single sysfs file
(with semantics differing from driver to driver).
--
Best regards,
Jacek Anaszewski
he custom pattern approach though, unless I'm missing some
gain of having pattern setting in a uniformly named single sysfs file
(with semantics differing from driver to driver).
--
Best regards,
Jacek Anaszewski
ntroller address.
the controller...
+Required child properties:
+- reg: Number of LED line (could be from 0 to 2).
Uff. "Port this LED is connected to"?
With that fixed...
Acked-by: Pavel Machek <pa...@ucw.cz>
Pavel
--
Best regards,
Jacek Anaszewski
ired child properties:
+- reg: Number of LED line (could be from 0 to 2).
Uff. "Port this LED is connected to"?
With that fixed...
Acked-by: Pavel Machek
Pavel
--
Best regards,
Jacek Anaszewski
Hi Uwe,
On 05/08/2018 10:17 PM, Uwe Kleine-König wrote:
Hello Jacek,
On Tue, May 08, 2018 at 09:33:14PM +0200, Jacek Anaszewski wrote:
Thank you for the patch. It looks fine, but please split
the drivers/net/can/led.c related changes into a separate one.
I renamed led_trigger_rename_static
Hi Uwe,
On 05/08/2018 10:17 PM, Uwe Kleine-König wrote:
Hello Jacek,
On Tue, May 08, 2018 at 09:33:14PM +0200, Jacek Anaszewski wrote:
Thank you for the patch. It looks fine, but please split
the drivers/net/can/led.c related changes into a separate one.
I renamed led_trigger_rename_static
.
[0] https://lkml.org/lkml/2017/3/23/33
[1] https://lkml.org/lkml/2017/11/15/27
--
Best regards,
Jacek Anaszewski
ml/2017/11/15/27
--
Best regards,
Jacek Anaszewski
+MODULE_DEVICE_TABLE(of, sc27xx_led_of_match);
+
+static struct platform_driver sc27xx_led_driver = {
+ .driver = {
+ .name = "sprd-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
"remove" op will be needed as well for mutex_destroy().
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu <xiaotong...@spreadtrum.com>");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
.name = "sprd-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
"remove" op will be needed as well for mutex_destroy().
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
Hi Uwe,
Thank you for the patch. It looks fine, but please split
the drivers/net/can/led.c related changes into a separate one.
Best regards,
Jacek Anaszewski
On 05/08/2018 12:05 PM, Uwe Kleine-König wrote:
This allows one to simplify drivers that provide a trigger with a
non-constant name
Hi Uwe,
Thank you for the patch. It looks fine, but please split
the drivers/net/can/led.c related changes into a separate one.
Best regards,
Jacek Anaszewski
On 05/08/2018 12:05 PM, Uwe Kleine-König wrote:
This allows one to simplify drivers that provide a trigger with a
non-constant name
green@1 {
s/green/led/
+ label = "green";
+ reg = <0x1>;
+ };
+
+ blue@2 {
s/blue/led/
+ label = "blue";
+ reg = <0x2>;
+ };
+};
--
Best regards,
Jacek Anaszewski
+ label = "green";
+ reg = <0x1>;
+ };
+
+ blue@2 {
s/blue/led/
+ label = "blue";
+ reg = <0x2>;
+ };
+};
--
Best regards,
Jacek Anaszewski
= {
+ .driver = {
+ .name = "sc27xx-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu <xiaotong...@spreadtrum.com>");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
struct of_device_id sc27xx_led_of_match[] = {
+ { .compatible = "sprd,sc27xx-bltc", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sc27xx_led_of_match);
+
+static struct platform_driver sc27xx_led_driver = {
+ .driver = {
+ .name = "sc27xx-bltc",
+ .of_match_table = sc27xx_led_of_match,
+ },
+ .probe = sc27xx_led_probe,
+};
+
+module_platform_driver(sc27xx_led_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
+MODULE_AUTHOR("Xiaotong Lu ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
and thanks for your input,
Uwe
--
Best regards,
Jacek Anaszewski
and thanks for your input,
Uwe
--
Best regards,
Jacek Anaszewski
On 04/03/2018 09:09 PM, Jacek Anaszewski wrote:
> Hi Linus,
>
> Please pull LED updates for 4.17-rc1:
>
> New LED class driver:
> - add driver for Mellanox regmap LEDs
>
> Improvement to ledtrig-activity:
It should be of course: "Improvement to ledtrig-disk
On 04/03/2018 09:09 PM, Jacek Anaszewski wrote:
> Hi Linus,
>
> Please pull LED updates for 4.17-rc1:
>
> New LED class driver:
> - add driver for Mellanox regmap LEDs
>
> Improvement to ledtrig-activity:
It should be of course: "Improvement to ledtrig-disk
-03-20 20:28:00 +0100)
Thanks,
Jacek Anaszewski
LED updates for 4.17-rc1
Hans Ulli Kroll (1):
leds: Fix wrong dmi_match on PC Engines APU LEDs
Linus Walleij (1
-03-20 20:28:00 +0100)
Thanks,
Jacek Anaszewski
LED updates for 4.17-rc1
Hans Ulli Kroll (1):
leds: Fix wrong dmi_match on PC Engines APU LEDs
Linus Walleij (1
Hi Hans,
On 03/18/2018 03:24 PM, Hans Ulli Kroll wrote:
> Hi Jacek
>
> On Sat, 10 Mar 2018, Jacek Anaszewski wrote:
>
>> Hi Hans,
>>
>> Thank you for the patch.
>>
>> On 03/05/2018 06:09 PM, Hans Ulli Kroll wrote:
>>> APU has compared to APU2
Hi Hans,
On 03/18/2018 03:24 PM, Hans Ulli Kroll wrote:
> Hi Jacek
>
> On Sat, 10 Mar 2018, Jacek Anaszewski wrote:
>
>> Hi Hans,
>>
>> Thank you for the patch.
>>
>> On 03/05/2018 06:09 PM, Hans Ulli Kroll wrote:
>>> APU has compared to APU2
On 03/19/2018 02:37 PM, Greg KH wrote:
> On Sat, Mar 17, 2018 at 08:31:01AM +0100, Jacek Anaszewski wrote:
>> This reverts commit 86b9fa2190907f4f550d9d6bf490c5f89ca33836.
>>
>> The commit being reverted has two flaws:
>> - it introduces a regression, fixed i
On 03/19/2018 02:37 PM, Greg KH wrote:
> On Sat, Mar 17, 2018 at 08:31:01AM +0100, Jacek Anaszewski wrote:
>> This reverts commit 86b9fa2190907f4f550d9d6bf490c5f89ca33836.
>>
>> The commit being reverted has two flaws:
>> - it introduces a regression, fixed i
* otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Signed-off-by: Matthieu CASTET <matthieu.cas...@parrot.com>
Reported-by: Sasha Levin <alexander.le...@microsoft.com>
Reported-by: Matthias Schiffer <mschif...@universe-fac
* otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Signed-off-by: Matthieu CASTET
Reported-by: Sasha Levin
Reported-by: Matthias Schiffer
Signed-off-by: Jacek Anaszewski
---
drivers/leds/led-core.c | 1 +
1 file changed, 1 insertion
-by tags
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2):
Revert "led: core: Fix brightness setting when setting delay_off=0"
led: core: Clear LED_BLINK_SW flag in led_blink_set()
drivers/leds/led-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.1.4
-by tags
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2):
Revert "led: core: Fix brightness setting when setting delay_off=0"
led: core: Clear LED_BLINK_SW flag in led_blink_set()
drivers/leds/led-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.1.4
.le...@microsoft.com>
Reported-by: Matthias Schiffer <mschif...@universe-factory.net>
Signed-off-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
inde
Schiffer
Signed-off-by: Jacek Anaszewski
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index d70d4a5..3bce448 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -186,7 +186,7 @@ void
This reverts commit 86b9fa2190907f4f550d9d6bf490c5f89ca33836.
The commit being reverted has two flaws:
- it introduces a regression, fixed in the upstream
commit 7b6af2c53192f1766892ef40c8f48a413509ed72.
- it has truncated commit message
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1
This reverts commit 86b9fa2190907f4f550d9d6bf490c5f89ca33836.
The commit being reverted has two flaws:
- it introduces a regression, fixed in the upstream
commit 7b6af2c53192f1766892ef40c8f48a413509ed72.
- it has truncated commit message
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1
The fix for brightness setting when setting delay_off=0 introduces
a regression and has truncated commit message. Revert that patch
and apply the one-line change required to fix the original issue
in the way appropriate for the 4.9 code base.
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2
* otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Signed-off-by: Matthieu CASTET <matthieu.cas...@parrot.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
---
drivers/leds/led-core.c | 1 +
1 file changed,
The fix for brightness setting when setting delay_off=0 introduces
a regression and has truncated commit message. Revert that patch
and apply the one-line change required to fix the original issue
in the way appropriate for the 4.9 code base.
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2
* otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Signed-off-by: Matthieu CASTET
Signed-off-by: Jacek Anaszewski
---
drivers/leds/led-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/led-core.c b/drivers/leds/l
asoning it has a truncated commit
message).
>> Should I just revert the single 2b83ff96f51d commit here instead?
>
> I believe so, yes.
>
> I'm not aware of any _really bad_ issues with LED subsystem in
> 4.9. Take a look at changelog of
> 2b83ff96f51d0b039c4561b9f95c824d7bddb85c -- it fixes rather
> theoretical issue; user can reproduce it by hand in shell, but,
> well... don't do it then.
Greg mentioned that 4.9.87 release fixed some LED issue for someone,
and it was the only LED related patch in that release.
> The rest of fixes ... fix some more theoretical races. I don't think
> it is -stable material, as I pointed out before.
--
Best regards,
Jacek Anaszewski
asoning it has a truncated commit
message).
>> Should I just revert the single 2b83ff96f51d commit here instead?
>
> I believe so, yes.
>
> I'm not aware of any _really bad_ issues with LED subsystem in
> 4.9. Take a look at changelog of
> 2b83ff96f51d0b039c4561b9f95c824d7bddb85c -- it fixes rather
> theoretical issue; user can reproduce it by hand in shell, but,
> well... don't do it then.
Greg mentioned that 4.9.87 release fixed some LED issue for someone,
and it was the only LED related patch in that release.
> The rest of fixes ... fix some more theoretical races. I don't think
> it is -stable material, as I pointed out before.
--
Best regards,
Jacek Anaszewski
On 03/12/2018 04:45 PM, Matthias Schiffer wrote:
> On 03/12/2018 04:28 PM, Greg KH wrote:
>> On Mon, Mar 12, 2018 at 04:00:01PM +0100, Matthias Schiffer wrote:
>>> On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
>>>> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>&
On 03/12/2018 04:45 PM, Matthias Schiffer wrote:
> On 03/12/2018 04:28 PM, Greg KH wrote:
>> On Mon, Mar 12, 2018 at 04:00:01PM +0100, Matthias Schiffer wrote:
>>> On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
>>>> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>&
t;)) {
> apu_led->profile = apu1_led_profile;
> apu_led->platform = APU1_LED_PLATFORM;
> apu_led->num_led_instances = ARRAY_SIZE(apu1_led_profile);
>
If it fails here, then how it is possible that it succeeds
in the apu_led_init() ?
--
Best regards,
Jacek Anaszewski
t;profile = apu1_led_profile;
> apu_led->platform = APU1_LED_PLATFORM;
> apu_led->num_led_instances = ARRAY_SIZE(apu1_led_profile);
>
If it fails here, then how it is possible that it succeeds
in the apu_led_init() ?
--
Best regards,
Jacek Anaszewski
On 03/08/2018 06:24 PM, Greg Kroah-Hartman wrote:
> On Wed, Mar 07, 2018 at 09:39:08PM +0100, Jacek Anaszewski wrote:
>> Hi Ben,
>>
>> On 03/07/2018 04:32 PM, Ben Hutchings wrote:
>>> On Fri, 2018-03-02 at 09:51 +0100, Greg Kroah-Hartman wrote:
>>>> 4
On 03/08/2018 06:24 PM, Greg Kroah-Hartman wrote:
> On Wed, Mar 07, 2018 at 09:39:08PM +0100, Jacek Anaszewski wrote:
>> Hi Ben,
>>
>> On 03/07/2018 04:32 PM, Ben Hutchings wrote:
>>> On Fri, 2018-03-02 at 09:51 +0100, Greg Kroah-Hartman wrote:
>>>> 4
> this fix probably isn't needed, though I can't tell whether it does any
> harm.
We discussed it in [0]. This patch is not needed for 4.4 and what's
more more it is harmful. It introduces a bug, fixed in [1].
[0] https://lkml.org/lkml/2018/2/6/726
[1[ https://patchwork.kernel.org/patch/10253933/
--
Best regards,
Jacek Anaszewski
d, though I can't tell whether it does any
> harm.
We discussed it in [0]. This patch is not needed for 4.4 and what's
more more it is harmful. It introduces a bug, fixed in [1].
[0] https://lkml.org/lkml/2018/2/6/726
[1[ https://patchwork.kernel.org/patch/10253933/
--
Best regards,
Jacek Anaszewski
gt;;
led-max-microamp = <2>;
};
led@1 {
label = "blue:power";
reg = <1>;
led-max-microamp = <20000>;
};
led@2 {
label = "green:power";
reg = <2>;
led-max-microamp = <2>;
};
You can refer to drivers/leds/leds-lp8860.c on how to construct
the label. Generally from the discussions with DT maintainer
it turned out that we shouldn't have controller name in the LED
class device name at all, but it will have to be addressed globally
for all LED class drivers at once at some point.
[0] https://patchwork.kernel.org/patch/10093757/
--
Best regards,
Jacek Anaszewski
led@1 {
label = "blue:power";
reg = <1>;
led-max-microamp = <2>;
};
led@2 {
label = "green:power";
reg = <2>;
led-max-microamp = <2>;
};
You can refer to drivers/leds/leds-lp8860.c on how to construct
the label. Generally from the discussions with DT maintainer
it turned out that we shouldn't have controller name in the LED
class device name at all, but it will have to be addressed globally
for all LED class drivers at once at some point.
[0] https://patchwork.kernel.org/patch/10093757/
--
Best regards,
Jacek Anaszewski
r-4.16-rc3
for you to fetch changes up to a988681dbbca01c64d86455c0153899870d7a63c:
MAINTAINERS: Remove Richard Purdie from LED maintainers (2018-02-19 20:23:49
+0100)
Thanks,
Jacek Anaszewski
LED update to M
r-4.16-rc3
for you to fetch changes up to a988681dbbca01c64d86455c0153899870d7a63c:
MAINTAINERS: Remove Richard Purdie from LED maintainers (2018-02-19 20:23:49
+0100)
Thanks,
Jacek Anaszewski
LED update to M
Richard has been inactive on the linux-leds list for a long time.
After email discussion we agreed on removing him from
the LED maintainers, which will better reflect the actual status.
Cc: Richard Purdie <rpur...@rpsys.net>
Signed-off-by: Jacek Anaszewski <jacek.anaszew...@
Richard has been inactive on the linux-leds list for a long time.
After email discussion we agreed on removing him from
the LED maintainers, which will better reflect the actual status.
Cc: Richard Purdie
Signed-off-by: Jacek Anaszewski
---
MAINTAINERS | 1 -
1 file changed, 1 deletion
o fix this one?
Without mutually exclusive section you can always be preempted
after wait test succeeds and before requesting new brightness.
Then the other process can jump in, request other brightness
(and change it in struct led_classdev via led_set_brightness_nosleep()),
which causes we end up with non deterministic LED class device
state after that.
Every solution without mutually exclusive section is prone to races
here.
--
Best regards,
Jacek Anaszewski
o fix this one?
Without mutually exclusive section you can always be preempted
after wait test succeeds and before requesting new brightness.
Then the other process can jump in, request other brightness
(and change it in struct led_classdev via led_set_brightness_nosleep()),
which causes we end up with non deterministic LED class device
state after that.
Every solution without mutually exclusive section is prone to races
here.
--
Best regards,
Jacek Anaszewski
Any comments? I'd like to have some acks before applying
this patch.
Adding more people showing recently interest in the LED subsystem
related development.
Thanks,
Jacek Anaszewski
On 01/17/2018 10:12 PM, Jacek Anaszewski wrote:
> Commit d23a22a74fde ("leds: delay led_set_brightness if
Any comments? I'd like to have some acks before applying
this patch.
Adding more people showing recently interest in the LED subsystem
related development.
Thanks,
Jacek Anaszewski
On 01/17/2018 10:12 PM, Jacek Anaszewski wrote:
> Commit d23a22a74fde ("leds: delay led_set_brightness if
's explanation.
>
> I might be missing something, but Jacek suggested I pull another patch
> before this one?
Just to clarify:
For 4.14 below patches are chosen correctly:
[PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when
setting delay_off=0
[PATCH AUTOSEL for 4.14 094/110] leds: core: Fix regression caused by
commit 2b83ff96f51d
For 4.9 both above patches are needed preceded by:
eb1610b4c273 ("led: core: Fix blink_brightness setting race")
The issue the patch [PATCH AUTOSEL for 4.14 065/110] fixes was
introduced in 4.7, and thus it should be removed from the series
for 3.18 and 4.4.
--
Best regards,
Jacek Anaszewski
's explanation.
>
> I might be missing something, but Jacek suggested I pull another patch
> before this one?
Just to clarify:
For 4.14 below patches are chosen correctly:
[PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when
setting delay_off=0
[PATCH AUTOSEL for 4.14 094/110] leds: core: Fix regression caused by
commit 2b83ff96f51d
For 4.9 both above patches are needed preceded by:
eb1610b4c273 ("led: core: Fix blink_brightness setting race")
The issue the patch [PATCH AUTOSEL for 4.14 065/110] fixes was
introduced in 4.7, and thus it should be removed from the series
for 3.18 and 4.4.
--
Best regards,
Jacek Anaszewski
On 02/03/2018 10:22 PM, Jacek Anaszewski wrote:
> Hi Sasha,
>
> All 3.18, 4.4 and 4.9 also require the follow-up
> patch [0], similarly like autosel did it for 4.14,
> since this one alone breaks the other use case.
Actually after taking closer look, it turns out that
the pa
On 02/03/2018 10:22 PM, Jacek Anaszewski wrote:
> Hi Sasha,
>
> All 3.18, 4.4 and 4.9 also require the follow-up
> patch [0], similarly like autosel did it for 4.14,
> since this one alone breaks the other use case.
Actually after taking closer look, it turns out that
the pa
ld clear LED_BLINK_SW.
>
> Cc: linux-l...@vger.kernel.org
> Signed-off-by: Matthieu CASTET <matthieu.cas...@parrot.com>
> Signed-off-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
> Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
> ---
> drivers/led
ED_BLINK_SW
> *** if brightness=0, led off
> *** else apply brightness if next timer <--- timer is stop, and will never
> apply new setting
> ** otherwise set led_set_brightness_nosleep
>
> To fix that, when we delete the timer, we should clear LED_BLINK_SW.
>
> Cc: lin
at:
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
tags/leds_for_4.16-rc1
for you to fetch changes up to 6a836631e303cec7fd9469ae53a4d97d0360eb38:
leds: ledtrig-transient: Add SPDX license identifiers (2018-01-11 21:24:17
+0100)
Thanks,
Jacek Anaszewski
at:
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
tags/leds_for_4.16-rc1
for you to fetch changes up to 6a836631e303cec7fd9469ae53a4d97d0360eb38:
leds: ledtrig-transient: Add SPDX license identifiers (2018-01-11 21:24:17
+0100)
Thanks,
Jacek Anaszewski
workqueue in the place of use.
Reported-by: Craig McQueen <craig.mcqu...@innerrange.com.au>
Signed-off-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
---
Craig,
It would be great if you could confirm if this fixes your use case.
drivers/leds/led-core.c | 79 +++
workqueue in the place of use.
Reported-by: Craig McQueen
Signed-off-by: Jacek Anaszewski
---
Craig,
It would be great if you could confirm if this fixes your use case.
drivers/leds/led-core.c | 79 +++-
drivers/leds/trigger/ledtrig-activity.c | 3 --
se> and
> +// Neil Brown <ne...@suse.de>
>
> #include
> #include
> @@ -238,4 +231,4 @@ module_exit(transient_trig_exit);
>
> MODULE_AUTHOR("Shuah Khan <shuahk...@gmail.com>");
> MODULE_DESCRIPTION("Transient LED trigger");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>
Applied.
--
Best regards,
Jacek Anaszewski
+// Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's
> +// ledtrig-heartbeat.c
> +// Design and use-case input from Jonas Bonn and
> +// Neil Brown
>
> #include
> #include
> @@ -238,4 +231,4 @@ module_exit(transient_trig_exit);
>
> MODULE_AUTHOR("Shuah Khan ");
> MODULE_DESCRIPTION("Transient LED trigger");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>
Applied.
--
Best regards,
Jacek Anaszewski
4 @@ module_exit(transient_trig_exit);
>
> MODULE_AUTHOR("Shuah Khan <shuahk...@gmail.com>");
> MODULE_DESCRIPTION("Transient LED trigger");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>
[0] https://www.mail-archive.com/netdev@vger.kernel.org/msg204598.html
--
Best regards,
Jacek Anaszewski
901 - 1000 of 3275 matches
Mail list logo
