On 7/7/20 8:04 PM, Randy Dunlap wrote:
Drop the doubled word "for".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: Dan Murphy
Cc: linux-l...@vger.kernel.org
---
Documentation/leds/ledtrig-transient.rst |
On 10/8/19 10:00 PM, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 12:17 PM Jacek Anaszewski
> wrote:
>>
>> On 10/8/19 5:00 PM, Rob Herring wrote:
>>> On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
>>>>
>>>> Rob,
>>>>
&g
hat was what you had on mind)
have singular form 'led'.
>>>> We already have 'flash-leds' in use and with the same definition, so
>>>> lets continue that and use 'backlight-leds'.
>>> OK
>>
>> I am taking that back. I have added of_get_led() and devm_of_get_led()
>> to the LED core to make it easier to get a LED from the DT. I modeled
>> the interface like it is done for PWM, PHYs or clocks. The property
>> containing list/array of phandle is always named the same. To get one
>> particular PWM/PHY/clock, a identifier (name or integer) must be provided.
>
> It can be done as we do support that with '-gpios', but yes, it is a
> bit more painful to deal with.
>
>> So unless there is a strong incentive to do otherwise I's rather keep
>> this name here.
>
> In that case, this needs to be documented as a common LED binding, not
> something hidden away in this binding.
>
> Rob
>
--
Best regards,
Jacek Anaszewski
hat was what you had on mind)
have singular form 'led'.
>>>> We already have 'flash-leds' in use and with the same definition, so
>>>> lets continue that and use 'backlight-leds'.
>>> OK
>>
>> I am taking that back. I have added of_get_led() and devm_of_get_led()
>> to the LED core to make it easier to get a LED from the DT. I modeled
>> the interface like it is done for PWM, PHYs or clocks. The property
>> containing list/array of phandle is always named the same. To get one
>> particular PWM/PHY/clock, a identifier (name or integer) must be provided.
>
> It can be done as we do support that with '-gpios', but yes, it is a
> bit more painful to deal with.
>
>> So unless there is a strong incentive to do otherwise I's rather keep
>> this name here.
>
> In that case, this needs to be documented as a common LED binding, not
> something hidden away in this binding.
>
> Rob
>
--
Best regards,
Jacek Anaszewski
_cdev->dev->of_node = to_of_node(init_data->fwnode);
> + }
>
> if (ret)
> dev_warn(parent, "Led %s renamed to %s due to name collision",
>
--
Best regards,
Jacek Anaszewski
ross devices.
We can think of adding it to the TODO list, but this is another story.
This is the background. However, since Jean pointed to the few
other similar cases when of_node is being initialized in addition
to fwnode I deem there is no issue and we can do the same in the
LED core.
No action in regulator core is required then.
--
Best regards,
Jacek Anaszewski
On 10/3/19 9:41 PM, Mark Brown wrote:
> On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote:
>> On 10/3/19 8:35 PM, Mark Brown wrote:
>>> On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
>>>> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wr
Hi Mark,
On 10/3/19 8:35 PM, Mark Brown wrote:
> On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
>> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
>>> On 03/10/2019 12:42, Sebastian Reichel wrote:
>>>> On Thu, Oct 03, 2019 at 10:28:09AM +0
;>> +
>>> + led_dev = class_find_device_by_of_node(leds_class, led_node);
>> If you convert led_node into a fwnode, you can use
>> class_find_device_by_fwnode() instead. That way the
>> first patch can just be dropped.
>
> Thanks for the reviews.
>
> The first patch could be dropped indeed, but it would break something
> else I'm working on: getting regulator support in the LED core.
>
> This has been discussed during the v7 iteration of this series.
I wonder if it wouldn't make sense to add support for fwnode
parsing to regulator core. Or maybe it is either somehow supported
or not supported on purpose?
These are questions to regulator maintainers.
Adding Liam and Mark.
--
Best regards,
Jacek Anaszewski
Hi Jean,
On 10/2/19 3:58 PM, Jean-Jacques Hiblot wrote:
> Hi Jacek,
>
> On 24/09/2019 23:03, Jacek Anaszewski wrote:
>> Hi Jean,
>>
>> Thank you for rebasing the set
>>
>> On 9/18/19 4:57 PM, Jean-Jacques Hiblot wrote:
>>> If initializatio
_node(init_data->fwnode);
It would be step backwards. You can do the conversion in the place of
use i.e. in devm_led_get().
> + }
>
> if (ret)
> dev_warn(parent, "Led %s renamed to %s due to name collision",
>
--
Best regards,
Jacek Anaszewski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
h
> +++ b/include/linux/leds.h
> @@ -199,6 +199,8 @@ extern void led_classdev_resume(struct led_classdev
> *led_cdev);
>
> extern struct led_classdev *of_led_get(struct device_node *np, int index);
> extern void led_put(struct led_classdev *led_cdev);
> +struct led_classdev *__must_check devm_led_get(struct device *dev,
> +int index);
>
> /**
> * led_blink_set - set blinking with software fallback
>
--
Best regards,
Jacek Anaszewski
* LED Core
> */
> @@ -196,6 +197,9 @@ extern void devm_led_classdev_unregister(struct device
> *parent,
> extern void led_classdev_suspend(struct led_classdev *led_cdev);
> extern void led_classdev_resume(struct led_classdev *led_cdev);
>
> +extern struct led_classdev *of_led_get(struct device_node *np, int index);
> +extern void led_put(struct led_classdev *led_cdev);
> +
> /**
> * led_blink_set - set blinking with software fallback
> * @led_cdev: the LED to start blinking
>
--
Best regards,
Jacek Anaszewski
Hi Jean,
Please rebase your patch set onto linux-leds.git [0] -
we've had some updates in the meantime and now your
set doesn't apply.
Best regards,
Jacek Anaszewski
On 9/10/19 3:27 PM, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds basic support for
On 7/22/19 11:23 PM, Jacek Anaszewski wrote:
> On 7/22/19 9:06 AM, Lee Jones wrote:
>> On Thu, 18 Jul 2019, Jacek Anaszewski wrote:
>>
>>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
>>>> This series aims to add a led-backlight driver, similar to pwm-backligh
ault-state DT property can be also set to "on"
>> (see Documentation/devicetree/bindings/leds/common.txt).
>
> Yes, except that it does not work with all drivers :-(. In particular,
> it does not work with lm3532.
>
> We should really move more of the device tree parsing into core, so
> that there's one place to fix...
Right. We could have something similar to led_get_default_pattern().
led_get_default_state() ?
--
Best regards,
Jacek Anaszewski
On 7/22/19 9:06 AM, Lee Jones wrote:
> On Thu, 18 Jul 2019, Jacek Anaszewski wrote:
>
>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
>>> This series aims to add a led-backlight driver, similar to pwm-backlight,
>>> but using a LED class device underneath.
>&g
ctive (and display is usually active when trigger is activated).
default-state DT property can be also set to "on"
(see Documentation/devicetree/bindings/leds/common.txt).
You could make use of LED_INIT_DEFAULT_TRIGGER flag and
parse DT property in the activate op. Similar approach has been
applied e.g. in ledtrig-pattern.c.
--
Best regards,
Jacek Anaszewski
| 6 +
> 6 files changed, 402 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> create mode 100644 drivers/video/backlight/led_bl.c
>
For the whole set:
Acked-by: Jacek Anaszewski
Lee - we need to creat
; +
> + leds = <&led1>, <&led2>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + };
>
--
Best regards,
Jacek Anaszewski
her than
hardware capabilities than it should be more likely handled
by userspace.
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
[1]: Documentation/devicetree/bindings/gpio/gpio.txt
--
Best regards,
Jacek Anaszewski
h that fixes this problem is
> (http://coccinelle.lip6.fr):
>
[...]
--
Best Regards,
Jacek Anaszewski
checks of type
> unsigned <= 0
> exactly for the reasons above.
>
> However I have left two other checks as they seems to me more suspicious -
> they
> are always true or false. But as Dmitry and Andrew pointed out Linus have
> quite
> strong opinion against removing range checks in such cases as he finds it
> clearer. I think it applies to patches 29-36. I am not sure about patches
> 26-28,37.
Dropped 30/38 and 31/38 from LED tree then.
--
Best Regards,
Jacek Anaszewski
23 matches
Mail list logo
