ting led-max-microamp\n");
> +
> + if (led->full_scale_current > LM3532_FS_CURR_MAX)
> + led->full_scale_current = LM3532_FS_CURR_MAX;
One more nit: we have min() macro in kernel.h for such things.
> + }
>
> if (led->mode == LM3532_BL_MODE_ALS) {
> led->mode = LM3532_ALS_CTRL;
>
--
Best regards,
Jacek Anaszewski
On 8/29/19 11:08 AM, Enrico Weigelt, metux IT consult wrote:
> On 22.07.19 22:12, Jacek Anaszewski wrote:
>
> Hi,
>
>> Patch set applied along with the update for the patch 5/6.
>
> What's the status of this patch set ?
> Doesn't seem to have landed in Torvalds tre
>
> be a log of that it is missing.
That's why I used lower log level (info). But it's up to you. I will
not insist on keeping the logging for missing property case.
> Dan
>
>> } else {
>> dev_info(>client->dev,
>> led-max-microamp property is missing\n")
>> }
>>
>>> full_scale_current should be 0 if not populated and in the init only if
>>> this variable is set does
>>>
>>> the code program the register otherwise it is default of 20.2 mA.
>
--
Best regards,
Jacek Anaszewski
e(child), >led_dev);
We no longer have devm_of_led_classdev_register(). You must use
devm_led_classdev_register_ext().
--
Best regards,
Jacek Anaszewski
struct ti_lmu_bank *lmu_bank)
> ramp_down =
> ti_lmu_common_convert_ramp_to_index(lmu_bank->ramp_down_usec);
> }
>
> - if (ramp_up < 0 || ramp_down < 0)
> - return -EINVAL;
> -
> ramp = (ramp_up << 4) | ramp_down;
>
> return regmap_write(regmap, lmu_bank->runtime_ramp_reg, ramp);
>
I've applied the patch but amended SHA1 in the Fixes tag - in mainline
it is 3fce8e1eb994.
--
Best regards,
Jacek Anaszewski
gt; if (ret) {
> @@ -319,7 +335,13 @@ static int lm3532_led_disable(struct lm3532_led
> *led_data)
> return ret;
> }
>
> - return regulator_disable(led_data->priv->regulator);
> + ret = regulator_disable(led_data->priv->regulator);
> + if (ret < 0)
> + return ret;
> +
> + led_data->enabled = 0;
> +
> + return 0;
> }
>
> static int lm3532_brightness_set(struct led_classdev *led_cdev,
>
Applied.
--
Best regards,
Jacek Anaszewski
On 8/27/19 11:33 PM, Jacek Anaszewski wrote:
> On 8/25/19 11:32 AM, Pavel Machek wrote:
>> On Tue 2019-08-20 14:53:04, Dan Murphy wrote:
>>> Change the define name of the full scale current registers.
>>>
>>> Signed-off-by: Dan Murphy
>>
>> Acke
On 8/27/19 1:31 PM, Pavel Machek wrote:
> On Mon 2019-08-26 23:02:19, Jacek Anaszewski wrote:
>> Replace preprocessor macro aliases for legacy LED registration helpers
>> with inline functions. It will allow to avoid misleading compiler error
>> messages about missing symbol
On 8/25/19 11:32 AM, Pavel Machek wrote:
> On Tue 2019-08-20 14:53:04, Dan Murphy wrote:
>> Change the define name of the full scale current registers.
>>
>> Signed-off-by: Dan Murphy
>
> Acked-by: Pavel Machek
>
Thanks, applied.
--
Best regards,
Jacek Anaszewski
er(dev, >cdev);
> if (ret < 0)
> return ret;
Applied.
--
Best regards,
Jacek Anaszewski
ou have it assigned.
We'll soon receive complaints from static checkers about pointless
assignment.
I'd distinguish between cases when parsing failed,
and when property has not been provided.
if (fwnode_property_present(child, "led-max-microamp")) {
if (fwnode_property_read_u32(child, "led-max-microamp",
>full_scale_current);
dev_err(>client->dev,
"Failed to parse led-max-microamp property\n")
} else {
dev_info(>client->dev,
led-max-microamp property is missing\n")
}
> full_scale_current should be 0 if not populated and in the init only if
> this variable is set does
>
> the code program the register otherwise it is default of 20.2 mA.
--
Best regards,
Jacek Anaszewski
Dan,
On 8/27/19 3:37 PM, Dan Murphy wrote:
> Jacek
>
> On 8/26/19 2:34 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 8/26/19 4:53 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 8/24/19 10:18 AM, Jacek Anaszewski wrote:
>>>> Hi Dan,
&g
) function had been used in the code.
Signed-off-by: Jacek Anaszewski
Cc: Pavel Machek
Cc: Dan Murphy
---
include/linux/leds.h | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d101fd13e18e
Dan,
On 8/26/19 4:53 PM, Dan Murphy wrote:
> Jacek
>
> On 8/24/19 10:18 AM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the patch.
>>
>> On 8/23/19 9:55 PM, Dan Murphy wrote:
>>> Fix the coccinelle issues found in the TI LMU common code
ce the lm3532 LED driver")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
>
Tags should now be correct.
--
Best regards,
Jacek Anaszewski
g = LM3532_REG_ZONE_CFG_A + led->control_bank * 2;
> -
> - return regmap_update_bits(priv->regmap, brightnes_config_reg,
> - LM3532_I2C_CTRL, LM3532_ALS_CTRL);
> + return regmap_write(priv->regmap, LM3532_ALS_CONFIG, als->config);
> }
>
> static int lm3532_parse_als(struct lm3532_data *priv)
> @@ -634,9 +653,6 @@ static int lm3532_probe(struct i2c_client *client,
> return ret;
> }
>
> - if (drvdata->enable_gpio)
> - gpiod_direction_output(drvdata->enable_gpio, 1);
> -
> return ret;
> }
>
>
Patch set applied.
--
Best regards,
Jacek Anaszewski
_ramp_to_index(unsigned int
> usec)
> int ti_lmu_common_set_ramp(struct ti_lmu_bank *lmu_bank)
> {
> struct regmap *regmap = lmu_bank->regmap;
> - u8 ramp, ramp_up, ramp_down;
> + int ramp, ramp_up, ramp_down;
>
> if (lmu_bank->ramp_up_usec == 0 && lmu_bank->ramp_down_usec == 0) {
> ramp_up = 0;
>
--
Best regards,
Jacek Anaszewski
list_lock, flags);
> led_set_brightness(led_cdev, LED_OFF);
> + kfree(event);
>
> return ret;
> }
>
Added tag:
Fixes: 52c47742f79d ("leds: triggers: send uevent when changing triggers")
and applied.
--
Best regards,
Jacek Anaszewski
Dan,
On 8/2/19 4:14 PM, Dan Murphy wrote:
> Jacek
>
> On 7/31/19 3:44 PM, Jacek Anaszewski wrote:
>> Dan,
>>
> [...]
>> + for (i = 0; i < mcled_cdev->num_leds; i++) {
>> + ret = sscanf(buf + offset, "%i%n", [i]
Dan,
On 8/1/19 9:17 PM, Dan Murphy wrote:
> Jacek
>
> On 8/1/19 1:52 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the patch set. Please find my comments
>> in the code below.
>>
>> On 8/1/19 5:14 PM, Dan Murphy wrote:
>>
troller@38 {
> reg = <0>;
> led-sources = <2>;
> ti,led-mode = <1>;
> + ti,fs-current = <21800>;
> label = ":backlight";
> linux,default-trigger = "backlight";
> };
>
--
Best regards,
Jacek Anaszewski
urces");
> if (led->num_leds > LM3532_MAX_LED_STRINGS) {
> @@ -587,7 +606,13 @@ static int lm3532_parse_node(struct lm3532_data *priv)
> goto child_out;
> }
>
> - lm3532_init_registers(led);
> + ret = lm3532_init_registers(led);
> + if (ret) {
> + dev_err(>client->dev, "register init err: %d\n",
> + ret);
> + fwnode_handle_put(child);
> + goto child_out;
> + }
>
> i++;
> }
> @@ -634,9 +659,6 @@ static int lm3532_probe(struct i2c_client *client,
> return ret;
> }
>
> - if (drvdata->enable_gpio)
> - gpiod_direction_output(drvdata->enable_gpio, 1);
> -
> return ret;
> }
>
>
--
Best regards,
Jacek Anaszewski
Dan,
On 7/31/19 9:06 PM, Dan Murphy wrote:
> Jacek
>
> On 7/29/19 3:50 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 7/25/19 8:28 PM, Dan Murphy wrote:
>>> Introduce a multicolor class that groups colored LEDs
>>> within a LED node.
>>>
>&
Dan,
On 7/31/19 8:55 PM, Dan Murphy wrote:
> Jacek
>
> Thanks for looking
You're welcome.
> On 7/31/19 1:45 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the patch. My comments are below.
>>
>> On 7/25/19 8:28 PM, Dan Murphy wrote:
&g
Hi Dan,
Thank you for the patch. My comments are below.
On 7/25/19 8:28 PM, Dan Murphy wrote:
> Update the lp5523 to use the multi color framework.
>
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/leds-lp5523.c| 13 ++
> drivers/leds/leds-lp55xx-common.c | 153
"Cannot read color\n");
> +
> + led->mc_cdev.available_colors |= (1 << color_id);
> + num_colors++;
> +
> + }
> +
> + led->priv = priv;
> + led->mc_cdev.ops = _mc_ops;
> + led->mc_cdev.num_leds = num_colors;
> + led->mc_cdev.led_cdev = >led_dev;
> + led->led_dev.brightness_set_blocking = lp50xx_brightness_set;
> + led->led_dev.brightness_get = lp50xx_brightness_get;
> + ret = led_classdev_multicolor_register_ext(>client->dev,
> +>mc_cdev,
> +_data);
Why not devm_* prefixed version?
[...]
--
Best regards,
Jacek Anaszewski
_mccdev(
> + struct led_classdev *lcdev)
> +{
> + return container_of(lcdev, struct led_classdev_mc, led_cdev);
> +}
> +
> +/**
> + * led_classdev_multicolor_register_ext - register a new object of
> led_classdev
> + * class with support for multicolor LEDs
> + * @parent: the multicolor LED to register
> + * @mcled_cdev: the led_classdev_mc structure for this device
> + * @init_data: the LED class Multi color device initialization data
> + *
> + * Returns: 0 on success or negative error value on failure
> + */
> +extern int led_classdev_multicolor_register_ext(struct device *parent,
> + struct led_classdev_mc *mcled_cdev,
> + struct led_init_data *init_data);
> +
> +#define led_classdev_multicolor_register(parent, mcled_cdev) \
> + led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL)
> +
> +/**
> + * led_classdev_multicolor_unregister - unregisters an object of led_classdev
> + * class with support for multicolor LEDs
> + * @mcled_cdev: the multicolor LED to unregister
> + *
> + * Unregister a previously registered via led_classdev_multicolor_register
> + * object
> + */
> +extern void led_classdev_multicolor_unregister(struct led_classdev_mc
> *mcled_cdev);
> +
> +extern int devm_led_classdev_multicolor_register(struct device *parent,
> + struct led_classdev_mc *mcled_cdev);
> +
> +extern void devm_led_classdev_multicolor_unregister(struct device *parent,
> +struct led_classdev_mc *mcled_cdev);
> +
> +/* Set brightness for the monochrome LED cluster */
> +extern void set_cluster_brightness(struct led_classdev_mc *mcled_cdev,
> + enum led_brightness brightness,
> + int adj_value[]);
> +
> +/* Read current cluster brightness */
> +extern void get_cluster_brightness(struct led_classdev_mc *mcled_cdev,
> +int brightness_val[]);
> +
> +#endif /* __LINUX_MULTICOLOR_LEDS_H_INCLUDED */
>
I'll review remaining patches (drivers) next time.
[0] https://lore.kernel.org/linux-leds/20160825124948.ga15...@kroah.com/
--
Best regards,
Jacek Anaszewski
> + led-sources = <8 11 17>;
> + };
> + };
> +
> + multi-led@4 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <4>;
> + color = ;
> + function = LED_FUNCTION_ACTIVITY;
> +
> + led@12 {
> + reg = <12>;
> + color = ;
> + };
> +
> + led@13 {
> + reg = <13>;
> + color = ;
> + };
> +
> + led@14 {
> + reg = <14>;
> + color = ;
> + };
> + };
> +
> +};
>
--
Best regards,
Jacek Anaszewski
+255
> +echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
> +
> +adjusted_red_value = 128 * 138/255 = 69
> +adjusted_green_value = 128 * 43/255 = 21
> +adjusted_blue_value = 128 * 226/255 = 113
> +
> +Reading the parent brightness file will return the current brightness value
> of
> +the color LED group.
> +
> +cat /sys/class/leds/rgb:grouped_leds/max_brightness
> +255
> +
> +echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
> +
> +cat /sys/class/leds/rgb:grouped_leds/max_brightness
s/max_brightness/brightness/
But I'd skip the three above examples - they are trivial and this part
of the interface works identically as the current LED class interface.
> +128
> +
> +
>
--
Best regards,
Jacek Anaszewski
/sys/class/leds//colors//max_intensity.
> +
> +What:/sys/class/leds//colors//max_intensity
> +Date:Sept 2019
> +KernelVersion: TBD
> +Contact: Dan Murphy
> +Description: read only
> + Maximum intensity level for the LED color, default is
> + 255 (LED_FULL).
> +
> + If the LED does not support different intensity levels, this
> + should be 1.
>
--
Best regards,
Jacek Anaszewski
drivers/leds/leds-netxbig.c | 70 +--
> .../platform_data/leds-kirkwood-netxbig.h | 54 --
> 3 files changed, 51 insertions(+), 74 deletions(-)
> delete mode 100644 include/linux/platform_data/leds-kirkwood-netxbig.h
[...]
Applied.
--
Best regards,
Jacek Anaszewski
rv = devm_of_led_classdev_register(dev, child, >cdev);
+ rv = devm_led_classdev_register(dev, >cdev);
if (rv)
goto err_node_put;
and melded it with the original one to not break the bisect.
If you have any doubts please let me know.
Best regards,
Jacek Anaszewski
26 would be nice to have but I presume it needs more discussion
>> and analysis.
>
> Idea is good, but I'd sort the file in different way.
>
> Best regards,
> Pavel
>
[0]
https://git.kernel.org/pub/scm/linux
319X_CURRENT_MAX;
>
> - if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> return -EIO;
>
> is31 = devm_kzalloc(>dev, sizeof(*is31), GFP_KERNEL);
>
Applied.
--
Best regards,
Jacek Anaszewski
92_FLASH_MODE_CURR_PERCENT(45)
> | KTD2692_REG_FLASH_CURRENT_BASE);
>
Applied.
--
Best regards,
Jacek Anaszewski
"Simon Shields ");
> -MODULE_DESCRIPTION("AN32059A LED driver");
> +MODULE_DESCRIPTION("AN30259A LED driver");
> MODULE_LICENSE("GPL v2");
>
Applied.
--
Best regards,
Jacek Anaszewski
Patch set applied along with the update for the patch 5/6.
--
Best regards,
Jacek Anaszewski
On 7/18/19 3:31 PM, Jean-Jacques Hiblot wrote:
>
> On 18/07/2019 14:24, Jacek Anaszewski wrote:
>> Hi Jean,
>>
>> Thank you for the updated patch set.
>>
>> I have some more comments below.
>>
>> On 7/17/19 3:59 PM, Jean-Jacques Hiblot wrote:
>&
Hi Pavel,
Thanks for the review.
On 7/18/19 1:03 PM, Pavel Machek wrote:
> Hi!
>
>> Add a documentation for standard LED functions with regard
>> to differences in meaning between cases when devicename section
>> of LED name is present or not.
>>
>
htness_sync);
>
> diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
> index 47b229469069..5aa5c038bd38 100644
> --- a/drivers/leds/leds.h
> +++ b/drivers/leds/leds.h
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
>
> static inline int led_get_brightness(struct led_classdev *led_cdev)
> {
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 9b2bf574a17a..bee8e3f8 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -123,6 +123,10 @@ struct led_classdev {
>
> /* Ensures consistent access to the LED Flash Class device */
> struct mutexled_access;
> +
> + /* regulator */
> + struct regulator*regulator;
> + boolregulator_state;
> };
>
> extern int of_led_classdev_register(struct device *parent,
>
--
Best regards,
Jacek Anaszewski
and analysis.
Best regards,
Jacek Anaszewski
On 6/9/19 9:07 PM, Jacek Anaszewski wrote:
> Changes from v4:
>
> - switched "charge" function name to "charging"
> - added "cpu", "mute", "micmute", "disk-activity", "panic", &
name.
>> + */
>> +if (!devicename) {
>> +strncpy(led_classdev_name, props.label,
>> + LED_MAX_NAME_SIZE);
>> +} else {
>> +snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s:%s",
>> + devicename, props.label);
>> +}
>
> Unlike snprintf(), strncpy() does not guarantee NULL termination.
Indeed. I'll change strncpy to strscpy.
> I did not check the shell script.
>
> With that fixed,
>
> Acked-by: Pavel Machek
Thanks!
--
Best regards,
Jacek Anaszewski
gt;> attention.
>
> Good idea. Shall I repost a changed patch ? (or repost the whole queue)
Please send only the patch in question (and bump the version).
--
Best regards,
Jacek Anaszewski
Dan,
On 7/16/19 9:27 PM, Dan Murphy wrote:
> Jacek
>
> On 7/16/19 2:18 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thanks for the update. I have some nits below, please take a look.
>>
>> On 7/1/19 10:46 PM, Dan Murphy wrote:
[...]
>>> +The u
ritten to each LED will be adjusted
> +base on this value
We probably need to state here that any amendment to color intensity
values resets brightness to its max value.
> +cat /sys/class/leds/rgb:grouped_leds/max_brightness
> +255
> +echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
> +
> +adjusted_red_value = 128 * (138/255) = 69
> +adjusted_green_value = 128 * (43/255) = 21
> +adjusted_blue_value = 128 * (226/255) = 113
Drop parentheses.
> +
> +Reading the parent brightness file will return the current brightness value
> of
> +the color LED group.
> +
> +cat /sys/class/leds/rgb:grouped_leds/max_brightness
> +255
> +
> +echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
> +
> +cat /sys/class/leds/rgb:grouped_leds/max_brightness
> +128
> +
> +
>
--
Best regards,
Jacek Anaszewski
eds.h
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
>
> static inline int led_get_brightness(struct led_classdev *led_cdev)
> {
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 9b2bf574a17a..bee8e3f8 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -123,6 +123,10 @@ struct led_classdev {
>
> /* Ensures consistent access to the LED Flash Class device */
> struct mutexled_access;
> +
> + /* regulator */
> + struct regulator*regulator;
> + boolregulator_state;
> };
>
> extern int of_led_classdev_register(struct device *parent,
>
--
Best regards,
Jacek Anaszewski
t->dev, flash->flash_node, >fled, NULL,
>
Applied to for-5.4 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
rs/leds/leds-max77650.c
> @@ -145,3 +145,4 @@ module_platform_driver(max77650_led_driver);
> MODULE_DESCRIPTION("MAXIM 77650/77651 LED driver");
> MODULE_AUTHOR("Bartosz Golaszewski ");
> MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:max77650-led");
>
Applied to for-5.4 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
/j.anaszewski/linux-leds.git
tags/leds-for-5.3-rc1
for you to fetch changes up to 2605085fba22792f3d4a6b856c7c5a05492d1fde:
dt: leds-lm36274.txt: fix a broken reference to ti-lmu.txt (2019-06-28
20:57:36 +0200)
Thanks,
Jacek Anaszewski
ings and dts files. Of course, as documentation
states, it will be possible to propose new ones if none of existing
fit for given application. This is only an initial set.
> 26.06.19 22:05, Jacek Anaszewski пише:
>> Gentle reminder.
>>
>> Pavel, Dan - any conclusions?
Gentle reminder.
Pavel, Dan - any conclusions?
This patch is the main part of the proposed changes,
so it would be good to spot any remaining issues.
What needs a consensus is also a new
Documentation/leds/led-functions.txt file I introduce
in the patch 26/26.
Best regards,
Jacek Anaszewski
Dan,
On 6/20/19 10:06 PM, Dan Murphy wrote:
Jacek
Thanks for the review
You're welcome.
On 6/20/19 11:10 AM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the v5.
I will confine myself to commenting only some parts since
the rest will undergo rework due to removal of sync API.
On 5/23
L-2.0
+
+/* LED Multicolor class interface
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
Let's have C++ comment style also here.
+#ifndef __LINUX_MULTICOLOR_LEDS_H_INCLUDED
+#define __LINUX_MULTICOLOR_LEDS_H_INCLUDED
+
+#include
+#include
[...]
--
Best regards,
Jacek Anaszewski
(here sticking to
the numeration from the patch).
--
Best regards,
Jacek Anaszewski
to 11e1bbc116a75d4a93122ea0a3b2be814922d864:
leds: lm36274: Introduce the TI LM36274 LED driver (2019-06-07 20:40:07 +0200)
Thanks,
Jacek Anaszewski
TI LMU LED support rework and introduction of two new drivers
with DT bindings
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Daniel Mack
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/leds/leds-lt3593.txt | 11 ---
1 file changed, 8 insertions(
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Acked-by: Pavel Machek
---
drivers/leds/leds-sc27xx-bltc.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/leds
Introduce dedicated properties for conveying information about
LED function and color. Mark old "label" property as deprecated.
Additionally function-enumerator property is being provided
for the cases when neither function nor color can be used
for LED differentiation.
Signed-off
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt | 10 ++
1 file changed, 6 insertions(
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski
Tested-by: Dan Murphy
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3601x.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Oleh Kravchenko
Reviewed-by: Rob Herring
---
.../devicetree/bindings/leds/leds-cr0014114.txt| 26 --
1 file changed,
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski
Cc
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski
Cc: Daniel Mack
Acked-by: Pavel Machek
---
drivers/leds/leds-lt3593.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lt3593.c b
Switch to using generic LED support for composing LED class
device name.
While at it, avoid iterating through available child of nodes
in favor of obtaining single expected child node using single
call to of_get_next_available_child().
Signed-off-by: Jacek Anaszewski
Acked-by: Pavel Machek
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Reviewed-by: Rob Herring
Reviewed-by: Dan Murphy
---
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 9 +++--
1 file changed, 7 insertions(
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Reviewed-by: Dan Murphy
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/leds/leds-lm3601x.txt | 10 --
1 file changed, 8 inser
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski
Acked
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/leds/leds-aat1290.txt | 12
1 file changed, 8 insertions(+), 4 deletions(
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Simon Shields
Reviewed-by: Rob Herring
---
.../devicetree/bindings/leds/leds-an30259a.txt | 22 +-
1 file changed, 17 inser
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Linus Walleij
Reviewed-by: Rob Herring
---
.../devicetree/bindings/leds/leds-gpio.txt | 23 +++---
1 file changed, 16 inser
new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski
Cc: Oleh Kravchenko
Acked-by: Pavel Machek
---
drivers/leds/leds-cr0014114.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/leds/leds-cr0014114.c b/drivers/leds/leds-cr0014114.c
in
new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski
Tested-by: Dan Murphy
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 4f413a7c5
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski
Cc: Simon Shields
---
drivers/leds/leds-an30259a.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-an30259a.c b/drivers
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Also, fix malformed syntax of address-cells and size-cells
in the example.
Signed-off-by: Jacek Anaszewski
Cc: Sakari Ailus
Reviewed-by: Rob Herring
---
.../devicetree/bindings/l
Add a documentation for standard LED functions with regard
to differences in meaning between cases when devicename section
of LED name is present or not.
Signed-off-by: Jacek Anaszewski
---
Documentation/leds/led-functions.txt | 223 +++
Documentation/leds/leds
nce that information had been
already available in sysfs. The script performs also basic validation
of a LED class device name.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Cc: Pavel Machek
Cc: Dan Murphy
Cc: Daniel Mack
Cc: Linus Walleij
Cc: Oleh Kravchenko
Cc: Sakari Ailus
Cc: Si
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski
Cc: Linus Walleij
---
drivers/leds/leds-gpio.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds
Add initial set of common LED function definitions.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Cc: Daniel Mack
Cc: Linus Walleij
Cc: Oleh Kravchenko
Cc: Sakari Ailus
Cc: Simon Shields
Reviewed-by: Rob Herring
Acked-by: Pavel Machek
Reviewed-by: Dan Murphy
---
include/dt-bindings
n path basing on the struct led_classdev's "name" property.
Three existing users of devm_of_led_classdev_registers() are modified
to use devm_led_classdev_register(), which will not impact their
operation since they in fact didn't need to pass struct device_node on
registration from the beginning
Refer to new "function" and "color" properties and mark "label"
as deprecated.
Signed-off-by: Jacek Anaszewski
Reviewed-by: Dan Murphy A
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/leds/leds-lm3692x.txt | 9 +++--
1 file changed, 7 inser
Add common LED color identifiers.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Cc: Daniel Mack
Cc: Linus Walleij
Cc: Oleh Kravchenko
Cc: Sakari Ailus
Cc: Simon Shields
Reviewed-by: Rob Herring
Acked-by: Pavel Machek
Reviewed-by: Dan Murphy
---
include/dt-bindings/leds/common.h | 11
ot; DT property, is being requested during reviews of new
LED class drivers for almost a year now, then those drivers are the first
candidates for optimalization and the first users of the new
led_compose_name() API. The modifications were tested with Qemu,
by stubbing the driver internals where hardwar
tness
+255
+
+echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
+
+cat /sys/class/leds/rgb:grouped_leds/max_brightness
+128
+
+
--
Best regards,
Jacek Anaszewski
#!/usr/bin/python3.5
from PIL import Image
import sys
import time
WIDTH = 500
HEIGHT = 500
def print_usage():
print
On 6/9/19 1:05 PM, Pavel Machek wrote:
On Sun 2019-06-09 13:03:40, Jacek Anaszewski wrote:
Hi Wolfram,
Thank you for the patches.
On 6/8/19 12:55 PM, Wolfram Sang wrote:
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Signed-off
/34 and 5/34:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
-regulator branch. I'll create a pull
request once I get a confirmation from you saying that everything
is as expected.
Best regards,
Jacek Anaszewski
On 6/5/19 2:56 PM, Dan Murphy wrote:
Hello
The v5 patchset missed adding in the new validation code.
Patch 1 of the v5 series was squashed into patch 4
in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
tags/led-fixes-for-5.2-rc3
for you to fetch changes up to 8c0f693c6effbc3f42f77a9e81209af9af20910c:
leds: avoid flush_work in atomic context (2019-05-31 22:29:14 +0200)
Thanks,
Jacek Anaszewski
Dan,
On 6/1/19 12:41 AM, Dan Murphy wrote:
Jacek
On 5/31/19 4:57 PM, Jacek Anaszewski wrote:
Dan,
On 5/31/19 11:07 PM, Dan Murphy wrote:
Hello
On 5/31/19 2:44 PM, Jacek Anaszewski wrote:
On 5/31/19 8:23 AM, Lee Jones wrote:
On Thu, 30 May 2019, Jacek Anaszewski wrote:
On 5/30/19 9:38
Dan,
On 5/31/19 11:07 PM, Dan Murphy wrote:
Hello
On 5/31/19 2:44 PM, Jacek Anaszewski wrote:
On 5/31/19 8:23 AM, Lee Jones wrote:
On Thu, 30 May 2019, Jacek Anaszewski wrote:
On 5/30/19 9:38 AM, Lee Jones wrote:
On Wed, 29 May 2019, Jacek Anaszewski wrote:
On 5/29/19 3:58 PM, Lee Jones
On 5/31/19 8:23 AM, Lee Jones wrote:
On Thu, 30 May 2019, Jacek Anaszewski wrote:
On 5/30/19 9:38 AM, Lee Jones wrote:
On Wed, 29 May 2019, Jacek Anaszewski wrote:
On 5/29/19 3:58 PM, Lee Jones wrote:
On Fri, 24 May 2019, Jacek Anaszewski wrote:
Hi,
On 5/23/19 9:09 PM, Dan Murphy wrote
On 5/30/19 9:38 AM, Lee Jones wrote:
On Wed, 29 May 2019, Jacek Anaszewski wrote:
On 5/29/19 3:58 PM, Lee Jones wrote:
On Fri, 24 May 2019, Jacek Anaszewski wrote:
Hi,
On 5/23/19 9:09 PM, Dan Murphy wrote:
Pavel
Thanks for the review
On 5/23/19 7:50 AM, Pavel Machek wrote:
Hi!
+++ b
On 5/29/19 3:58 PM, Lee Jones wrote:
On Fri, 24 May 2019, Jacek Anaszewski wrote:
Hi,
On 5/23/19 9:09 PM, Dan Murphy wrote:
Pavel
Thanks for the review
On 5/23/19 7:50 AM, Pavel Machek wrote:
Hi!
+++ b/drivers/leds/leds-lm36274.c
+static int lm36274_parse_dt(struct lm36274
On 5/22/19 9:02 PM, Mark Brown wrote:
On Wed, May 22, 2019 at 08:27:32PM +0200, Jacek Anaszewski wrote:
On 5/21/19 11:15 PM, Mark Brown wrote:
On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:
regulator: lm363x: Make the gpio register enable flexible
find it reasonable to proceed with these immutable
branches workflow, I would first prefer to see Linus' approval for that.
This is nothing new.
I just wanted to make sure. We will see if Linus will have something
to add.
--
Best regards,
Jacek Anaszewski
subsystem is involved, like e.g. regulator
framework in case of recent extension of ti-lmu driver.
So far you haven't complained about this specific workflow, but I'd like
to make sure how you see it.
--
Best regards,
Jacek Anaszewski
On 5/28/19 8:19 PM, Dan Murphy wrote:
Jacek
On 5/28/19 12:44 PM, Jacek Anaszewski wrote:
Dan,
On 5/28/19 7:32 PM, Dan Murphy wrote:
Jacek
On 5/27/19 3:00 PM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the update.
One thing is missing here - we need to document how legacy brightness
Dan,
On 5/28/19 7:32 PM, Dan Murphy wrote:
Jacek
On 5/27/19 3:00 PM, Jacek Anaszewski wrote:
Hi Dan,
Thank you for the update.
One thing is missing here - we need to document how legacy brightness
levels map to the sub-LED color levels, i.e. what you do in
multicolor_set_brightness().
Ok
Hi Dan,
Thank you for the update.
One thing is missing here - we need to document how legacy brightness
levels map to the sub-LED color levels, i.e. what you do in
multicolor_set_brightness().
Best regards,
Jacek Anaszewski
On 5/23/19 9:08 PM, Dan Murphy wrote:
Add a documentation of LED
*label;
@@ -72,7 +71,6 @@ static int max77650_led_probe(struct platform_device *pdev)
u32 reg;
dev = >dev;
- parent = dev->parent;
of_node = dev->of_node;
if (!of_node)
Applied.
--
Best regards,
Jacek Anaszewski
--format='Fixes: %h ("%s")'
Fixed that and applied to the for-next branch and will push
it upstream after a bit of testing for rc3 or rc4.
Best regards,
Jacek Anaszewski
On 5/26/19 9:38 AM, Pavel Machek wrote:
It turns out that various triggers use led_blink_setup() from atomic
cont
201 - 300 of 3275 matches
Mail list logo
