[PATCH 3/4] leds: netdev trigger: add documentation to leds/common.txt

[PATCH 3/4] leds: netdev trigger: add documentation to leds/common.txt

[Rasmus Villemoes]

The various sysfs files used to configure a netdev-triggered LED are
already documented, but let's also add "netdev" to the list of things
one can reasonably set linux,default-trigger to.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 Documentation/devicetree/bindings/leds/common.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 70876ac11367..7cb88460a47c 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -39,6 +39,9 @@ Optional properties for child nodes:
      "timer" - LED flashes at a fixed, configurable rate
      "pattern" - LED alters the brightness for the specified duration with one
                  software timer (requires "led-pattern" property)
+     "netdev" - LED can be configured via sysfs files (see
+                Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
+                to reflect the state and activity of a net device.
 
 - led-pattern : Array of integers with default pattern for certain triggers.
                 Each trigger may parse this property differently:
-- 
2.20.1

[PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

It can be quite convenient to initialize a netdev-triggered LED with a
device name and setting the rx,tx,link properties from device tree,
instead of having to do that in an init script in userspace.

My main motivation for this is to be able to switch away from the
deprecated CONFIG_CAN_LEDS, so add an example based on that and add a
pointer in the net/can/Kconfig file.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 .../devicetree/bindings/leds/common.txt       | 17 ++++++++++
 drivers/leds/trigger/ledtrig-netdev.c         | 31 +++++++++++++++++++
 drivers/net/can/Kconfig                       |  3 +-
 3 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 7cb88460a47c..4f3a97e73417 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -43,6 +43,23 @@ Optional properties for child nodes:
                 Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
                 to reflect the state and activity of a net device.
 
+                The optional child node netdev can be used to
+                configure initial values for the link, rx, tx and
+                device_name properties. For example, setting
+                linux,default-trigger = "netdev" and adding the child
+                node
+
+                netdev {
+                    rx;
+                    tx;
+                    link;
+                    device-name = "can0";
+                };
+
+                can be used to replace 'linux,default-trigger =
+                "can0-rxtx"' that relies on the deprecated
+                CONFIG_CAN_LEDS.
+
 - led-pattern : Array of integers with default pattern for certain triggers.
                 Each trigger may parse this property differently:
                 - one-shot : two numbers specifying delay on and delay off (in ms),
diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index 55153a7e8433..1f7c86df1e91 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -20,6 +20,7 @@
 #include <linux/list.h>
 #include <linux/module.h>
 #include <linux/netdevice.h>
+#include <linux/of.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
 #include "../leds.h"
@@ -395,6 +396,35 @@ static void netdev_trig_work(struct work_struct *work)
 			(atomic_read(&trigger_data->interval)*2));
 }
 
+static void netdev_trig_of_init(struct led_classdev *led_cdev,
+				struct led_netdev_data *trigger_data)
+{
+	struct device_node *np = led_cdev->dev->of_node;
+	const char *device_name;
+
+	if (!np)
+		return;
+	np = of_get_child_by_name(np, "netdev");
+	if (!np)
+		return;
+
+	if (of_property_read_bool(np, "link"))
+		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
+	if (of_property_read_bool(np, "tx"))
+		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
+	if (of_property_read_bool(np, "rx"))
+		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
+	if (!of_property_read_string(np, "device-name", &device_name)) {
+		unsigned len = strlen(device_name);
+
+		if (len < IFNAMSIZ)
+			set_device(trigger_data, device_name, len);
+	}
+	set_baseline_state(trigger_data);
+
+	of_node_put(np);
+}
+
 static int netdev_trig_activate(struct led_classdev *led_cdev)
 {
 	struct led_netdev_data *trigger_data;
@@ -418,6 +448,7 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
 	trigger_data->mode = 0;
 	atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
 	trigger_data->last_activity = 0;
+	netdev_trig_of_init(led_cdev, trigger_data);
 
 	led_set_trigger_data(led_cdev, trigger_data);
 
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e0f0ad7a550a..91703a96b636 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -77,7 +77,8 @@ config CAN_LEDS
 	# everything that this driver is doing. This is marked as broken
 	# because it uses stuff that is intended to be changed or removed.
 	# Please consider switching to the netdev trigger and confirm it
-	# fulfills your needs instead of fixing this driver.
+	# fulfills your needs instead of fixing this driver. See e.g.
+	# Documentation/devicetree/bindings/leds/common.txt
 	depends on BROKEN
 	select LEDS_TRIGGERS
 	---help---
-- 
2.20.1

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Uwe Kleine-König]

Hello,

On Wed, Mar 13, 2019 at 09:26:15PM +0100, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script in userspace.

Well, you'd do this in an udev rule instead of an init script.

> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS, so add an example based on that and add a
> pointer in the net/can/Kconfig file.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  .../devicetree/bindings/leds/common.txt       | 17 ++++++++++
>  drivers/leds/trigger/ledtrig-netdev.c         | 31 +++++++++++++++++++
>  drivers/net/can/Kconfig                       |  3 +-
>  3 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..4f3a97e73417 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,23 @@ Optional properties for child nodes:
>                  Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                  to reflect the state and activity of a net device.
>  
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example, setting
> +                linux,default-trigger = "netdev" and adding the child
> +                node
> +
> +                netdev {
> +                    rx;
> +                    tx;
> +                    link;
> +                    device-name = "can0";

Maybe make this:

	device = <&can0>;

?

> +                };
> +
> +                can be used to replace 'linux,default-trigger =
> +                "can0-rxtx"' that relies on the deprecated
> +                CONFIG_CAN_LEDS.

Mentioning "CONFIG_CAN_LEDS" is wrong for a binding document that is
supposed to be independent from the kernel.

>  - led-pattern : Array of integers with default pattern for certain triggers.
>                  Each trigger may parse this property differently:
>                  - one-shot : two numbers specifying delay on and delay off (in ms),
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index 55153a7e8433..1f7c86df1e91 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -20,6 +20,7 @@
>  #include <linux/list.h>
>  #include <linux/module.h>
>  #include <linux/netdevice.h>
> +#include <linux/of.h>
>  #include <linux/spinlock.h>
>  #include <linux/timer.h>
>  #include "../leds.h"
> @@ -395,6 +396,35 @@ static void netdev_trig_work(struct work_struct *work)
>  			(atomic_read(&trigger_data->interval)*2));
>  }
>  
> +static void netdev_trig_of_init(struct led_classdev *led_cdev,
> +				struct led_netdev_data *trigger_data)
> +{
> +	struct device_node *np = led_cdev->dev->of_node;
> +	const char *device_name;
> +
> +	if (!np)
> +		return;
> +	np = of_get_child_by_name(np, "netdev");
> +	if (!np)
> +		return;
> +
> +	if (of_property_read_bool(np, "link"))
> +		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
> +	if (of_property_read_bool(np, "tx"))
> +		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
> +	if (of_property_read_bool(np, "rx"))
> +		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
> +	if (!of_property_read_string(np, "device-name", &device_name)) {
> +		unsigned len = strlen(device_name);
> +
> +		if (len < IFNAMSIZ)
> +			set_device(trigger_data, device_name, len);

if set_device contained the length check you'd have it in only one
place.

> +	}
> +	set_baseline_state(trigger_data);
> +
> +	of_node_put(np);
> +}
> +
>  static int netdev_trig_activate(struct led_classdev *led_cdev)
>  {
>  	struct led_netdev_data *trigger_data;
> @@ -418,6 +448,7 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
>  	trigger_data->mode = 0;
>  	atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
>  	trigger_data->last_activity = 0;
> +	netdev_trig_of_init(led_cdev, trigger_data);
>  
>  	led_set_trigger_data(led_cdev, trigger_data);
>  
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index e0f0ad7a550a..91703a96b636 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -77,7 +77,8 @@ config CAN_LEDS
>  	# everything that this driver is doing. This is marked as broken
>  	# because it uses stuff that is intended to be changed or removed.
>  	# Please consider switching to the netdev trigger and confirm it
> -	# fulfills your needs instead of fixing this driver.
> +	# fulfills your needs instead of fixing this driver. See e.g.
> +	# Documentation/devicetree/bindings/leds/common.txt
>  	depends on BROKEN
>  	select LEDS_TRIGGERS
>  	---help---

This hunk can better live in the patch adding to
Documentation/devicetree/bindings/leds/common.txt or a separate patch.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

On 14/03/2019 10.36, Uwe Kleine-König wrote:
> Hello,
> 
> On Wed, Mar 13, 2019 at 09:26:15PM +0100, Rasmus Villemoes wrote:
>> It can be quite convenient to initialize a netdev-triggered LED with a
>> device name and setting the rx,tx,link properties from device tree,
>> instead of having to do that in an init script in userspace.
> 
> Well, you'd do this in an udev rule instead of an init script.

Perhaps, if my userspace had udev. But even then, if I have to modify my
userspace in order to upgrade the kernel (which is what I'm trying to
avoid, for a number of reasons), I'd probably still do it in a
seven-line init script instead of trying to wrap my head around
udev/mdev rule writing.

Initializing the netdev trigger from DT data is certainly in line with
what is possible for certain other triggers via the led-pattern property.

Just out of curiosity, do you have a udev rule (template) for this?

>>  
>> +                The optional child node netdev can be used to
>> +                configure initial values for the link, rx, tx and
>> +                device_name properties. For example, setting
>> +                linux,default-trigger = "netdev" and adding the child
>> +                node
>> +
>> +                netdev {
>> +                    rx;
>> +                    tx;
>> +                    link;
>> +                    device-name = "can0";
> 
> Maybe make this:
> 
> 	device = <&can0>;

Huh? I don't think there's any guarantee that the netdevice has a DT
node/phandle, and even if it did, how would the init code map from that
phandle to the string it should fill into ->device_name? Since DT
natively has bools and strings, it's much more natural to just use those
types which map nicely to the sysfs properties.

> ?
> 
>> +                };
>> +
>> +                can be used to replace 'linux,default-trigger =
>> +                "can0-rxtx"' that relies on the deprecated
>> +                CONFIG_CAN_LEDS.
> 
> Mentioning "CONFIG_CAN_LEDS" is wrong for a binding document that is
> supposed to be independent from the kernel.

Well, this is in relation to the already linux-specific
linux,default-trigger binding. But I can certainly reword this to a
simple example that doesn't mention what it replaces and why, and just
move the mentioning of CONFIG_CAN_LEDS to the commit message.

>>  - led-pattern : Array of integers with default pattern for certain triggers.
>>                  Each trigger may parse this property differently:
>>                  - one-shot : two numbers specifying delay on and delay off (in ms),
>> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
>> index 55153a7e8433..1f7c86df1e91 100644
>> --- a/drivers/leds/trigger/ledtrig-netdev.c
>> +++ b/drivers/leds/trigger/ledtrig-netdev.c
>> @@ -20,6 +20,7 @@
>>  #include <linux/list.h>
>>  #include <linux/module.h>
>>  #include <linux/netdevice.h>
>> +#include <linux/of.h>
>>  #include <linux/spinlock.h>
>>  #include <linux/timer.h>
>>  #include "../leds.h"
>> @@ -395,6 +396,35 @@ static void netdev_trig_work(struct work_struct *work)
>>  			(atomic_read(&trigger_data->interval)*2));
>>  }
>>  
>> +static void netdev_trig_of_init(struct led_classdev *led_cdev,
>> +				struct led_netdev_data *trigger_data)
>> +{
>> +	struct device_node *np = led_cdev->dev->of_node;
>> +	const char *device_name;
>> +
>> +	if (!np)
>> +		return;
>> +	np = of_get_child_by_name(np, "netdev");
>> +	if (!np)
>> +		return;
>> +
>> +	if (of_property_read_bool(np, "link"))
>> +		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
>> +	if (of_property_read_bool(np, "tx"))
>> +		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
>> +	if (of_property_read_bool(np, "rx"))
>> +		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
>> +	if (!of_property_read_string(np, "device-name", &device_name)) {
>> +		unsigned len = strlen(device_name);
>> +
>> +		if (len < IFNAMSIZ)
>> +			set_device(trigger_data, device_name, len);
> 
> if set_device contained the length check you'd have it in only one
> place.

I considered that, but rejected it because it complicates the existing
user of set_device() (where the call happens under a lock; from the
_of_init function, nobody else knows about the trigger_data instance
yet). But on second thought, I think you're right that it's better done
in that one place. So I'll refactor.

>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
>> index e0f0ad7a550a..91703a96b636 100644
>> --- a/drivers/net/can/Kconfig
>> +++ b/drivers/net/can/Kconfig
>> @@ -77,7 +77,8 @@ config CAN_LEDS
>>  	# everything that this driver is doing. This is marked as broken
>>  	# because it uses stuff that is intended to be changed or removed.
>>  	# Please consider switching to the netdev trigger and confirm it
>> -	# fulfills your needs instead of fixing this driver.
>> +	# fulfills your needs instead of fixing this driver. See e.g.
>> +	# Documentation/devicetree/bindings/leds/common.txt
>>  	depends on BROKEN
>>  	select LEDS_TRIGGERS
>>  	---help---
> 
> This hunk can better live in the patch adding to
> Documentation/devicetree/bindings/leds/common.txt or a separate patch.

OK, will move to separate patch.

Rasmus

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

On Wed 2019-03-13 21:26:15, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script in userspace.
> 
> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS, so add an example based on that and add a
> pointer in the net/can/Kconfig file.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  .../devicetree/bindings/leds/common.txt       | 17 ++++++++++
>  drivers/leds/trigger/ledtrig-netdev.c         | 31 +++++++++++++++++++
>  drivers/net/can/Kconfig                       |  3 +-
>  3 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..4f3a97e73417 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,23 @@ Optional properties for child nodes:
>                  Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                  to reflect the state and activity of a net device.
>  
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example, setting
> +                linux,default-trigger = "netdev" and adding the child
> +                node
> +
> +                netdev {
> +                    rx;
> +                    tx;
> +                    link;
> +                    device-name = "can0";
> +                };
> +
> +                can be used to replace 'linux,default-trigger =
> +                "can0-rxtx"' that relies on the deprecated
> +                CONFIG_CAN_LEDS.

I'm sorry, but no, not like this. I see it works for you, only having
single can device, but it would quickly break with two of them and two
ethernets are rather common.

So this will need to be device = <&phandle_of_ethernet_device> or
something like that. There may be example with usb port triggers.

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

On 14/03/2019 11.29, Pavel Machek wrote:
> On Wed 2019-03-13 21:26:15, Rasmus Villemoes wrote:
>> It can be quite convenient to initialize a netdev-triggered LED with a
>> device name and setting the rx,tx,link properties from device tree,
>> instead of having to do that in an init script in userspace.
>>
>> +                The optional child node netdev can be used to
>> +                configure initial values for the link, rx, tx and
>> +                device_name properties. For example, setting
>> +                linux,default-trigger = "netdev" and adding the child
>> +                node
>> +
>> +                netdev {
>> +                    rx;
>> +                    tx;
>> +                    link;
>> +                    device-name = "can0";
>> +                };
>> +
>> +                can be used to replace 'linux,default-trigger =
>> +                "can0-rxtx"' that relies on the deprecated
>> +                CONFIG_CAN_LEDS.
> 
> I'm sorry, but no, not like this. I see it works for you, only having
> single can device, but it would quickly break with two of them and two
> ethernets are rather common.
> 
> So this will need to be device = <&phandle_of_ethernet_device> or
> something like that. There may be example with usb port triggers.

Huh? I have two CAN devices, and there are two LEDs on the front panel
labeled CAN-A and CAN-B; my device tree nodes for that are

		cana {
			label = "cana:green:activity";
			gpios = <&gpio0 10 0>;
			default-state = "off";
			linux,default-trigger = "netdev";

			netdev {
				rx;
				tx;
				link;
				device-name = "can0";
			};
		};

		canb {
			label = "canb:green:activity";
			gpios = <&gpio0 5 0>;
			default-state = "off";
			linux,default-trigger = "netdev";

			netdev {
				rx;
				tx;
				link;
				device-name = "can1";
			};
		};

and this works just fine. The only change from the old DT is the
addition of the netdev nodes and changing linux,default-trigger from
"can0-rxtx", "can1-rxtx" to both "netdev".

Rasmus

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Thu 2019-03-14 12:26:38, Rasmus Villemoes wrote:
> On 14/03/2019 11.29, Pavel Machek wrote:
> > On Wed 2019-03-13 21:26:15, Rasmus Villemoes wrote:
> >> It can be quite convenient to initialize a netdev-triggered LED with a
> >> device name and setting the rx,tx,link properties from device tree,
> >> instead of having to do that in an init script in userspace.
> >>
> >> +                The optional child node netdev can be used to
> >> +                configure initial values for the link, rx, tx and
> >> +                device_name properties. For example, setting
> >> +                linux,default-trigger = "netdev" and adding the child
> >> +                node
> >> +
> >> +                netdev {
> >> +                    rx;
> >> +                    tx;
> >> +                    link;
> >> +                    device-name = "can0";
> >> +                };
> >> +
> >> +                can be used to replace 'linux,default-trigger =
> >> +                "can0-rxtx"' that relies on the deprecated
> >> +                CONFIG_CAN_LEDS.
> > 
> > I'm sorry, but no, not like this. I see it works for you, only having
> > single can device, but it would quickly break with two of them and two
> > ethernets are rather common.
> > 
> > So this will need to be device = <&phandle_of_ethernet_device> or
> > something like that. There may be example with usb port triggers.
> 
> Huh? I have two CAN devices, and there are two LEDs on the front panel
> labeled CAN-A and CAN-B; my device tree nodes for that are
...
> and this works just fine. The only change from the old DT is the
> addition of the netdev nodes and changing linux,default-trigger from
> "can0-rxtx", "can1-rxtx" to both "netdev".

Yeah and now insert the modules for the can devices in different
order... May not happen in your case but will be fairly common for
ethernets.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

On 14/03/2019 13.00, Pavel Machek wrote:
linux,default-trigger from
> 
> Yeah and now insert the modules for the can devices in different
> order... May not happen in your case but will be fairly common for
> ethernets.

Unpredictable device names is not a problem I'm trying to solve, nor one
that actually occurs on embedded systems. And even if one has such a
system, one is likely running udev or similar to rename devices to
something sane and predictable, in which case a fixed string _still_
works fine. Or one uses udev rules to munge the netdev trigger sysfs
files, and has applications dealing with devices appearing as banana457.

OK, so there's of_find_net_device_by_node, so a phandle solution might
also be possible, and might work just as well for my case. But I still
think initializing with a fixed string is the simplest and sanest thing
to do.

Rasmus

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

On Thu 2019-03-14 14:19:42, Rasmus Villemoes wrote:
> On 14/03/2019 13.00, Pavel Machek wrote:
> linux,default-trigger from
> > 
> > Yeah and now insert the modules for the can devices in different
> > order... May not happen in your case but will be fairly common for
> > ethernets.
> 
> Unpredictable device names is not a problem I'm trying to solve, nor one
> that actually occurs on embedded systems. And even if one has such a
> system, one is likely running udev or similar to rename devices to
> something sane and predictable, in which case a fixed string _still_
> works fine. Or one uses udev rules to munge the netdev trigger sysfs
> files, and has applications dealing with devices appearing as banana457.
> 
> OK, so there's of_find_net_device_by_node, so a phandle solution might
> also be possible, and might work just as well for my case. But I still
> think initializing with a fixed string is the simplest and sanest thing
> to do.

Simplest, yes. Mergeable, no. Sorry.

Udev will not help with renaming -- it runs after kernel boot, while
udev parsing is usually done before userland starts.

Plus, device tree should really describe hardware, and be usable with
other operating systems. Of course, there are exceptions, but "can0"
is unneccessarily linux-specific.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

On 17/03/2019 20.11, Pavel Machek wrote:
> On Thu 2019-03-14 14:19:42, Rasmus Villemoes wrote:
>> On 14/03/2019 13.00, Pavel Machek wrote:
>> linux,default-trigger from
>>>
> Udev will not help with renaming -- it runs after kernel boot, while
> udev parsing is usually done before userland starts.

This is simply plain wrong. The netdev trigger explicitly tracks a
netdevice _by name_, and has netdev notifier in place to get notified
should a netdevice by that name ever appear.

> Plus, device tree should really describe hardware, and be usable with
> other operating systems. Of course, there are exceptions, but "can0"
> is unneccessarily linux-specific.

And "linux,netdev-trigger" is not linux-specific? And why are you so
hung up on the can example, it would work just as fine for usb0 or whatever.

Anyway, to whoever is responsible for merging this stuff, please at most
apply patch 1, factoring out the string-to-netdev handling doesn't make
much sense without the final configure-from-dt stuff.

Rasmus

Re: [PATCH 4/4] leds: netdev trigger: allow setting initial values in device tree

[Jacek Anaszewski]

Hi Rasmus,

Thank you for the patch set.

I have one comment below.

On 3/13/19 9:26 PM, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script in userspace.
> 
> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS, so add an example based on that and add a
> pointer in the net/can/Kconfig file.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>   .../devicetree/bindings/leds/common.txt       | 17 ++++++++++
>   drivers/leds/trigger/ledtrig-netdev.c         | 31 +++++++++++++++++++
>   drivers/net/can/Kconfig                       |  3 +-
>   3 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..4f3a97e73417 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,23 @@ Optional properties for child nodes:
>                   Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                   to reflect the state and activity of a net device.
>   
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example, setting
> +                linux,default-trigger = "netdev" and adding the child
> +                node
> +
> +                netdev {
> +                    rx;
> +                    tx;
> +                    link;
> +                    device-name = "can0";
> +                };
> +
> +                can be used to replace 'linux,default-trigger =
> +                "can0-rxtx"' that relies on the deprecated
> +                CONFIG_CAN_LEDS.
> +
>   - led-pattern : Array of integers with default pattern for certain triggers.
>                   Each trigger may parse this property differently:
>                   - one-shot : two numbers specifying delay on and delay off (in ms),
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index 55153a7e8433..1f7c86df1e91 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -20,6 +20,7 @@
>   #include <linux/list.h>
>   #include <linux/module.h>
>   #include <linux/netdevice.h>
> +#include <linux/of.h>
>   #include <linux/spinlock.h>
>   #include <linux/timer.h>
>   #include "../leds.h"
> @@ -395,6 +396,35 @@ static void netdev_trig_work(struct work_struct *work)
>   			(atomic_read(&trigger_data->interval)*2));
>   }
>   
> +static void netdev_trig_of_init(struct led_classdev *led_cdev,
> +				struct led_netdev_data *trigger_data)
> +{
> +	struct device_node *np = led_cdev->dev->of_node;
> +	const char *device_name;
> +
> +	if (!np)
> +		return;
> +	np = of_get_child_by_name(np, "netdev");
> +	if (!np)
> +		return;
> +
> +	if (of_property_read_bool(np, "link"))
> +		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
> +	if (of_property_read_bool(np, "tx"))
> +		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
> +	if (of_property_read_bool(np, "rx"))
> +		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
> +	if (!of_property_read_string(np, "device-name", &device_name)) {
> +		unsigned len = strlen(device_name);
> +
> +		if (len < IFNAMSIZ)
> +			set_device(trigger_data, device_name, len);
> +	}
> +	set_baseline_state(trigger_data);
> +
> +	of_node_put(np);
> +}
> +
>   static int netdev_trig_activate(struct led_classdev *led_cdev)
>   {
>   	struct led_netdev_data *trigger_data;
> @@ -418,6 +448,7 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
>   	trigger_data->mode = 0;
>   	atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
>   	trigger_data->last_activity = 0;
> +	netdev_trig_of_init(led_cdev, trigger_data);

You want to execute this only if recently introduced flag
LED_INIT_DEFAULT_TRIGGER is set. Please compare how
drivers/leds/trigger/ledtrig-pattern.c uses it.

>   
>   	led_set_trigger_data(led_cdev, trigger_data);
>   
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index e0f0ad7a550a..91703a96b636 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -77,7 +77,8 @@ config CAN_LEDS
>   	# everything that this driver is doing. This is marked as broken
>   	# because it uses stuff that is intended to be changed or removed.
>   	# Please consider switching to the netdev trigger and confirm it
> -	# fulfills your needs instead of fixing this driver.
> +	# fulfills your needs instead of fixing this driver. See e.g.
> +	# Documentation/devicetree/bindings/leds/common.txt
>   	depends on BROKEN
>   	select LEDS_TRIGGERS
>   	---help---
> 

-- 
Best regards,
Jacek Anaszewski

[PATCH v2 5/6] leds: netdev trigger: add documentation to leds/common.txt

[Rasmus Villemoes]

The various sysfs files used to configure a netdev-triggered LED are
already documented, but let's also add "netdev" to the list of things
one can reasonably set linux,default-trigger to.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 Documentation/devicetree/bindings/leds/common.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 70876ac11367..7cb88460a47c 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -39,6 +39,9 @@ Optional properties for child nodes:
      "timer" - LED flashes at a fixed, configurable rate
      "pattern" - LED alters the brightness for the specified duration with one
                  software timer (requires "led-pattern" property)
+     "netdev" - LED can be configured via sysfs files (see
+                Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
+                to reflect the state and activity of a net device.
 
 - led-pattern : Array of integers with default pattern for certain triggers.
                 Each trigger may parse this property differently:
-- 
2.20.1

[PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

It can be quite convenient to initialize a netdev-triggered LED with a
device name and setting the rx,tx,link properties from device tree,
instead of having to do that in an init script (or udev rule) in
userspace.

My main motivation for this is to be able to switch away from the
deprecated CONFIG_CAN_LEDS. The example added to common.txt
corresponds to switching linux,default-trigger = "can0-rxtx" to
"netdev" and adding the indicated netdev subnode.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 .../devicetree/bindings/leds/common.txt       | 11 +++++++
 drivers/leds/trigger/ledtrig-netdev.c         | 30 +++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 7cb88460a47c..f8078c4cf6f8 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -43,6 +43,17 @@ Optional properties for child nodes:
                 Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
                 to reflect the state and activity of a net device.
 
+                The optional child node netdev can be used to
+                configure initial values for the link, rx, tx and
+                device_name properties. For example,
+
+                netdev {
+                    rx;
+                    tx;
+                    link;
+                    device-name = "can0";
+                };
+
 - led-pattern : Array of integers with default pattern for certain triggers.
                 Each trigger may parse this property differently:
                 - one-shot : two numbers specifying delay on and delay off (in ms),
diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index e4a76ce4e4c7..387932cfea55 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -20,6 +20,7 @@
 #include <linux/list.h>
 #include <linux/module.h>
 #include <linux/netdevice.h>
+#include <linux/of.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
 #include "../leds.h"
@@ -400,6 +401,33 @@ static void netdev_trig_work(struct work_struct *work)
 			(atomic_read(&trigger_data->interval)*2));
 }
 
+static void netdev_trig_of_init(struct led_classdev *led_cdev,
+				struct led_netdev_data *trigger_data)
+{
+	struct device_node *np = led_cdev->dev->of_node;
+	const char *device_name;
+
+	if (!np)
+		return;
+	np = of_get_child_by_name(np, "netdev");
+	if (!np)
+		return;
+
+	if (of_property_read_bool(np, "link"))
+		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
+	if (of_property_read_bool(np, "tx"))
+		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
+	if (of_property_read_bool(np, "rx"))
+		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
+	if (!of_property_read_string(np, "device-name", &device_name))
+		netdev_trig_set_device(trigger_data, device_name,
+				       strlen(device_name));
+
+	set_baseline_state(trigger_data);
+
+	of_node_put(np);
+}
+
 static int netdev_trig_activate(struct led_classdev *led_cdev)
 {
 	struct led_netdev_data *trigger_data;
@@ -423,6 +451,8 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
 	trigger_data->mode = 0;
 	atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
 	trigger_data->last_activity = 0;
+	if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER)
+		netdev_trig_of_init(led_cdev, trigger_data);
 
 	led_set_trigger_data(led_cdev, trigger_data);
 
-- 
2.20.1

Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Jacek Anaszewski]

Rasmus,

Thank you for the update.
Still, there is one thing to improve.

On 3/14/19 3:06 PM, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script (or udev rule) in
> userspace.
> 
> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS. The example added to common.txt
> corresponds to switching linux,default-trigger = "can0-rxtx" to
> "netdev" and adding the indicated netdev subnode.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>   .../devicetree/bindings/leds/common.txt       | 11 +++++++
>   drivers/leds/trigger/ledtrig-netdev.c         | 30 +++++++++++++++++++
>   2 files changed, 41 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..f8078c4cf6f8 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,17 @@ Optional properties for child nodes:
>                   Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                   to reflect the state and activity of a net device.
>   
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example,
> +
> +                netdev {
> +                    rx;
> +                    tx;
> +                    link;
> +                    device-name = "can0";
> +                };
> +
>   - led-pattern : Array of integers with default pattern for certain triggers.
>                   Each trigger may parse this property differently:
>                   - one-shot : two numbers specifying delay on and delay off (in ms),
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index e4a76ce4e4c7..387932cfea55 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -20,6 +20,7 @@
>   #include <linux/list.h>
>   #include <linux/module.h>
>   #include <linux/netdevice.h>
> +#include <linux/of.h>
>   #include <linux/spinlock.h>
>   #include <linux/timer.h>
>   #include "../leds.h"
> @@ -400,6 +401,33 @@ static void netdev_trig_work(struct work_struct *work)
>   			(atomic_read(&trigger_data->interval)*2));
>   }
>   
> +static void netdev_trig_of_init(struct led_classdev *led_cdev,
> +				struct led_netdev_data *trigger_data)
> +{
> +	struct device_node *np = led_cdev->dev->of_node;
> +	const char *device_name;
> +
> +	if (!np)
> +		return;
> +	np = of_get_child_by_name(np, "netdev");
> +	if (!np)
> +		return;
> +
> +	if (of_property_read_bool(np, "link"))
> +		__set_bit(NETDEV_LED_LINK, &trigger_data->mode);
> +	if (of_property_read_bool(np, "tx"))
> +		__set_bit(NETDEV_LED_TX, &trigger_data->mode);
> +	if (of_property_read_bool(np, "rx"))
> +		__set_bit(NETDEV_LED_RX, &trigger_data->mode);
> +	if (!of_property_read_string(np, "device-name", &device_name))
> +		netdev_trig_set_device(trigger_data, device_name,
> +				       strlen(device_name));
> +
> +	set_baseline_state(trigger_data);
> +
> +	of_node_put(np);
> +}
> +
>   static int netdev_trig_activate(struct led_classdev *led_cdev)
>   {
>   	struct led_netdev_data *trigger_data;
> @@ -423,6 +451,8 @@ static int netdev_trig_activate(struct led_classdev *led_cdev)
>   	trigger_data->mode = 0;
>   	atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
>   	trigger_data->last_activity = 0;
> +	if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER)
> +		netdev_trig_of_init(led_cdev, trigger_data);

We don't necessarily want OF settings to be used for initialization on
each LED trigger activation for the LED class device, but only on the
first one. That's why the triggers using this flags clean it here:

led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;

>   
>   	led_set_trigger_data(led_cdev, trigger_data);
>   
> 

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Rasmus Villemoes]

On 14/03/2019 15.24, Jacek Anaszewski wrote:
> Rasmus,
> 
> Thank you for the update.
> Still, there is one thing to improve.
> 

>>   static int netdev_trig_activate(struct led_classdev *led_cdev)
>>   {
>>       struct led_netdev_data *trigger_data;
>> @@ -423,6 +451,8 @@ static int netdev_trig_activate(struct
>> led_classdev *led_cdev)
>>       trigger_data->mode = 0;
>>       atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
>>       trigger_data->last_activity = 0;
>> +    if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER)
>> +        netdev_trig_of_init(led_cdev, trigger_data);
> 
> We don't necessarily want OF settings to be used for initialization on
> each LED trigger activation for the LED class device, but only on the
> first one. That's why the triggers using this flags clean it here:
> 
> led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;

Right, I noticed that pattern, but wondered about it. If this is
supposed to be a general thing, why isn't it just done by the trigger
core after the call of led_trigger_set() in the two places the bit gets
set? I.e.

		led_cdev->flags |= LED_INIT_DEFAULT_TRIGGER;
		led_trigger_set(led_cdev, trig);
+		led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;

I can certainly add clearing the flag to my code, just wondering.

Rasmus

Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Jacek Anaszewski]

On 3/14/19 4:05 PM, Rasmus Villemoes wrote:
> On 14/03/2019 15.24, Jacek Anaszewski wrote:
>> Rasmus,
>>
>> Thank you for the update.
>> Still, there is one thing to improve.
>>
> 
>>>    static int netdev_trig_activate(struct led_classdev *led_cdev)
>>>    {
>>>        struct led_netdev_data *trigger_data;
>>> @@ -423,6 +451,8 @@ static int netdev_trig_activate(struct
>>> led_classdev *led_cdev)
>>>        trigger_data->mode = 0;
>>>        atomic_set(&trigger_data->interval, msecs_to_jiffies(50));
>>>        trigger_data->last_activity = 0;
>>> +    if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER)
>>> +        netdev_trig_of_init(led_cdev, trigger_data);
>>
>> We don't necessarily want OF settings to be used for initialization on
>> each LED trigger activation for the LED class device, but only on the
>> first one. That's why the triggers using this flags clean it here:
>>
>> led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
> 
> Right, I noticed that pattern, but wondered about it. If this is
> supposed to be a general thing, why isn't it just done by the trigger
> core after the call of led_trigger_set() in the two places the bit gets
> set? I.e.
> 
> 		led_cdev->flags |= LED_INIT_DEFAULT_TRIGGER;
> 		led_trigger_set(led_cdev, trig);
> +		led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
> 
> I can certainly add clearing the flag to my code, just wondering.

Good point. It would have to be applied in both
led_trigger_set_default() and led_trigger_register(). So you either
need to add generic support for clearing the flag (and update the three
users) or update your patch alone.

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

On Thu 2019-03-14 15:06:19, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script (or udev rule) in
> userspace.
> 
> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS. The example added to common.txt
> corresponds to switching linux,default-trigger = "can0-rxtx" to
> "netdev" and adding the indicated netdev subnode.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  .../devicetree/bindings/leds/common.txt       | 11 +++++++
>  drivers/leds/trigger/ledtrig-netdev.c         | 30 +++++++++++++++++++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..f8078c4cf6f8 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,17 @@ Optional properties for child nodes:
>                  Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                  to reflect the state and activity of a net device.
>  
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example,
> +
> +                netdev {
> +                    rx;
> +                    tx;
> +                    link;
> +                    device-name = "can0";

Well, NAK, as explained before. Use phandle.

Alternatively, adding comment why CONFIG_CAN_LEDS can not be removed
just yet near the deprecation note would be acceptable.

									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v2 6/6] leds: netdev trigger: allow setting initial values in device tree

[Rob Herring]

On Thu, Mar 14, 2019 at 03:06:19PM +0100, Rasmus Villemoes wrote:
> It can be quite convenient to initialize a netdev-triggered LED with a
> device name and setting the rx,tx,link properties from device tree,
> instead of having to do that in an init script (or udev rule) in
> userspace.
> 
> My main motivation for this is to be able to switch away from the
> deprecated CONFIG_CAN_LEDS. The example added to common.txt
> corresponds to switching linux,default-trigger = "can0-rxtx" to
> "netdev" and adding the indicated netdev subnode.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  .../devicetree/bindings/leds/common.txt       | 11 +++++++
>  drivers/leds/trigger/ledtrig-netdev.c         | 30 +++++++++++++++++++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 7cb88460a47c..f8078c4cf6f8 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -43,6 +43,17 @@ Optional properties for child nodes:
>                  Documentation/ABI/testing/sysfs-class-led-trigger-netdev)
>                  to reflect the state and activity of a net device.
>  
> +                The optional child node netdev can be used to
> +                configure initial values for the link, rx, tx and
> +                device_name properties. For example,
> +
> +                netdev {

I was going to let the use of netdev slide, but now you have it 
twice and that's a Linuxism.

> +                    rx;
> +                    tx;
> +                    link;

What do these mean?

> +                    device-name = "can0";

can0 is a linux thing and doesn't belong in DT.

> +                };

I really don't like this. What's this going to look like if every 
trigger wants to add something like this? What's special about netdev 
leds?

We really need to decouple the Linux LED trigger design from the DT 
bindings. I have no problem associating LEDs with devices in DT, but it 
shouldn't just bring the LED trigger design into the bindings.