[PATCH V2] leds: trigger: Introduce an USB port trigger

[PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

This commit adds a new trigger that can turn on LED when USB device gets
connected to the USB port. This can be useful for various home routers
that have USB port and a proper LED telling user a device is connected.

Right now this trigger is usable with a proper DT only, there isn't a
way to specify USB ports from user space. This may change in a future.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
V2: The first version got support for specifying list of USB ports from
    user space only. There was a (big try &) discussion on adding DT
    support. It led to a pretty simple solution of comparing of_node of
    usb_device to of_node specified in usb-ports property.
    Since it appeared DT support may be simpler and non-DT a bit more
    complex, this version drops previous support for "ports" and
    "new_port" and focuses on DT only. The plan is to see if this
    solution with DT is OK, get it accepted and then work on non-DT.

Felipe: if there won't be any objections I'd like to ask for your Ack.
---
 Documentation/devicetree/bindings/leds/common.txt |  11 ++
 Documentation/leds/ledtrig-usbport.txt            |  19 ++
 drivers/leds/trigger/Kconfig                      |   8 +
 drivers/leds/trigger/Makefile                     |   1 +
 drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
 5 files changed, 245 insertions(+)
 create mode 100644 Documentation/leds/ledtrig-usbport.txt
 create mode 100644 drivers/leds/trigger/ledtrig-usbport.c

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index af10678..75536f7 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -50,6 +50,12 @@ property can be omitted.
 For controllers that have no configurable timeout the flash-max-timeout-us
 property can be omitted.
 
+Trigger specific properties for child nodes:
+
+usbport trigger:
+- usb-ports : List of USB ports that usbport should observed for turning on a
+	      given LED.
+
 Examples:
 
 system-status {
@@ -58,6 +64,11 @@ system-status {
 	...
 };
 
+usb {
+	label = "USB";
+	usb-ports = <&ohci_port1>, <&ehci_port1>;
+};
+
 camera-flash {
 	label = "Flash";
 	led-sources = <0>, <1>;
diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
new file mode 100644
index 0000000..642c4cd
--- /dev/null
+++ b/Documentation/leds/ledtrig-usbport.txt
@@ -0,0 +1,19 @@
+USB port LED trigger
+====================
+
+This LED trigger can be used for signaling user a presence of USB device in a
+given port. It simply turns on LED when device appears and turns it off when it
+disappears.
+
+It requires specifying a list of USB ports that should be observed. This can be
+done in DT by setting a proper property with list of a phandles. If more than
+one port is specified, LED will be turned on as along as there is at least one
+device connected to any of ports.
+
+This trigger can be activated from user space on led class devices as shown
+below:
+
+  echo usbport > trigger
+
+Nevertheless, current there isn't a way to specify list of USB ports from user
+space.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 9893d91..5b8e7c7 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -126,4 +126,12 @@ config LEDS_TRIGGER_PANIC
 	  a different trigger.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_USBPORT
+	tristate "USB port LED trigger"
+	depends on LEDS_TRIGGERS && USB && OF
+	help
+	  This allows LEDs to be controlled by USB events. This trigger will
+	  enable LED if some USB device gets connected to any of ports specified
+	  in DT.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 8cc64a4..80e2494 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)	+= ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)	+= ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)	+= ledtrig-camera.o
 obj-$(CONFIG_LEDS_TRIGGER_PANIC)	+= ledtrig-panic.o
+obj-$(CONFIG_LEDS_TRIGGER_USBPORT)	+= ledtrig-usbport.o
diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
new file mode 100644
index 0000000..97b064c
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-usbport.c
@@ -0,0 +1,206 @@
+/*
+ * USB port LED trigger
+ *
+ * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include "../leds.h"
+
+struct usbport_trig_port {
+	struct device_node *np;
+	struct list_head list;
+};
+
+struct usbport_trig_data {
+	struct led_classdev *led_cdev;
+	struct list_head ports;
+	struct notifier_block nb;
+	int count; /* Amount of connected matching devices */
+};
+
+static int usbport_trig_check_usb_dev(struct usb_device *usb_dev, void *data)
+{
+	struct usbport_trig_data *usbport_data = data;
+	struct device_node *np = usb_dev->dev.of_node;
+	struct usbport_trig_port *port;
+
+	list_for_each_entry(port, &usbport_data->ports, list) {
+		if (port->np == np) {
+			usbport_data->count++;
+			break;
+		}
+	}
+
+	return 0;
+}
+
+static int usbport_trig_get_ports(struct usbport_trig_data *usbport_data)
+{
+	struct led_classdev *led_cdev = usbport_data->led_cdev;
+	struct device *dev = led_cdev->dev;
+	struct device_node *np = dev->of_node;
+	struct of_phandle_args args;
+	struct usbport_trig_port *port;
+	int count, i;
+
+	if (!np)
+		return -ENOENT;
+
+	count = of_count_phandle_with_args(np, "usb-ports", NULL);
+	if (count < 0) {
+		dev_warn(dev, "Failed to get USB ports for %s\n",
+			 np->full_name);
+		return count;
+	}
+
+	if (!count) {
+		dev_warn(dev, "There aren't USB ports assigned to the %s\n",
+			 np->full_name);
+		return -ENOENT;
+	}
+
+	for (i = 0; i < count; i++) {
+		int err;
+
+		err = of_parse_phandle_with_args(np, "usb-ports", NULL, i,
+						 &args);
+		if (err) {
+			dev_err(dev, "Failed to get USB port phandle at index %d: %d\n",
+				i, err);
+			continue;
+		}
+
+		port = kzalloc(sizeof(*port), GFP_KERNEL);
+		if (port) {
+			port->np = args.np;
+			list_add_tail(&port->list, &usbport_data->ports);
+		}
+
+		of_node_put(args.np);
+	}
+
+	usb_for_each_dev(usbport_data, usbport_trig_check_usb_dev);
+	if (usbport_data->count)
+		led_set_brightness_nosleep(led_cdev, LED_FULL);
+
+	list_for_each_entry(port, &usbport_data->ports, list) {
+		dev_dbg(dev, "Added USB port %s\n", port->np->full_name);
+	}
+
+	return 0;
+}
+
+static bool usbport_trig_match(struct usbport_trig_data *usbport_data,
+			       struct usb_device *usb_dev)
+{
+	struct device_node *np = usb_dev->dev.of_node;
+	struct usbport_trig_port *port;
+
+	if (!np)
+		return false;
+
+	list_for_each_entry(port, &usbport_data->ports, list) {
+		if (port->np == np)
+			return true;
+	}
+
+	return false;
+}
+
+static int usbport_trig_notify(struct notifier_block *nb, unsigned long action,
+			       void *data)
+{
+	struct usbport_trig_data *usbport_data = container_of(nb, struct usbport_trig_data, nb);
+	struct led_classdev *led_cdev = usbport_data->led_cdev;
+
+	switch (action) {
+	case USB_DEVICE_ADD:
+		if (usbport_trig_match(usbport_data, data)) {
+			if (usbport_data->count++ == 0)
+				led_set_brightness_nosleep(led_cdev, LED_FULL);
+		}
+		break;
+	case USB_DEVICE_REMOVE:
+		if (usbport_trig_match(usbport_data, data)) {
+			if (--usbport_data->count == 0)
+				led_set_brightness_nosleep(led_cdev, LED_OFF);
+		}
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static void usbport_trig_activate(struct led_classdev *led_cdev)
+{
+	struct usbport_trig_data *usbport_data;
+
+	usbport_data = kzalloc(sizeof(*usbport_data), GFP_KERNEL);
+	if (!usbport_data)
+		return;
+	led_cdev->trigger_data = usbport_data;
+
+	usbport_data->led_cdev = led_cdev;
+
+	INIT_LIST_HEAD(&usbport_data->ports);
+	usbport_trig_get_ports(usbport_data);
+
+	usbport_data->nb.notifier_call = usbport_trig_notify,
+	usb_register_notify(&usbport_data->nb);
+
+	led_cdev->activated = true;
+}
+
+static void usbport_trig_deactivate(struct led_classdev *led_cdev)
+{
+	struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
+	struct usbport_trig_port *port, *tmp;
+
+	if (!led_cdev->activated)
+		return;
+
+	usb_unregister_notify(&usbport_data->nb);
+
+	list_for_each_entry_safe(port, tmp, &usbport_data->ports, list) {
+		list_del(&port->list);
+		kfree(port);
+	}
+
+	kfree(usbport_data);
+
+	led_cdev->activated = false;
+}
+
+static struct led_trigger usbport_led_trigger = {
+	.name     = "usbport",
+	.activate = usbport_trig_activate,
+	.deactivate = usbport_trig_deactivate,
+};
+
+static int __init usbport_trig_init(void)
+{
+	return led_trigger_register(&usbport_led_trigger);
+}
+
+static void __exit usbport_trig_exit(void)
+{
+	led_trigger_unregister(&usbport_led_trigger);
+}
+
+module_init(usbport_trig_init);
+module_exit(usbport_trig_exit);
+
+MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
+MODULE_DESCRIPTION("USB port trigger");
+MODULE_LICENSE("GPL");
-- 
1.8.4.5

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Peter Chen]

On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> +
> +usbport trigger:
> +- usb-ports : List of USB ports that usbport should observed for turning on a
> +	      given LED.
> +

%s/should/should be

>  Examples:
>  
>  system-status {
> @@ -58,6 +64,11 @@ system-status {
>  	...
>  };
>  
> +usb {
> +	label = "USB";
> +	usb-ports = <&ohci_port1>, <&ehci_port1>;
> +};
> +
>  camera-flash {
>  	label = "Flash";
>  	led-sources = <0>, <1>;
> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
> new file mode 100644
> index 0000000..642c4cd
> --- /dev/null
> +++ b/Documentation/leds/ledtrig-usbport.txt
> @@ -0,0 +1,19 @@
> +USB port LED trigger
> +====================
> +
> +This LED trigger can be used for signaling user a presence of USB device in a
> +given port. It simply turns on LED when device appears and turns it off when it
> +disappears.
> +
> +It requires specifying a list of USB ports that should be observed. This can be
> +done in DT by setting a proper property with list of a phandles. If more than
> +one port is specified, LED will be turned on as along as there is at least one
> +device connected to any of ports.
> +
> +This trigger can be activated from user space on led class devices as shown
> +below:
> +
> +  echo usbport > trigger
> +
> +Nevertheless, current there isn't a way to specify list of USB ports from user
> +space.
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index 9893d91..5b8e7c7 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -126,4 +126,12 @@ config LEDS_TRIGGER_PANIC
>  	  a different trigger.
>  	  If unsure, say Y.
>  
> +config LEDS_TRIGGER_USBPORT
> +	tristate "USB port LED trigger"
> +	depends on LEDS_TRIGGERS && USB && OF
> +	help
> +	  This allows LEDs to be controlled by USB events. This trigger will
> +	  enable LED if some USB device gets connected to any of ports specified
> +	  in DT.
> +
>  endif # LEDS_TRIGGERS
> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
> index 8cc64a4..80e2494 100644
> --- a/drivers/leds/trigger/Makefile
> +++ b/drivers/leds/trigger/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)	+= ledtrig-default-on.o
>  obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)	+= ledtrig-transient.o
>  obj-$(CONFIG_LEDS_TRIGGER_CAMERA)	+= ledtrig-camera.o
>  obj-$(CONFIG_LEDS_TRIGGER_PANIC)	+= ledtrig-panic.o
> +obj-$(CONFIG_LEDS_TRIGGER_USBPORT)	+= ledtrig-usbport.o
> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
> new file mode 100644
> index 0000000..97b064c
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> @@ -0,0 +1,206 @@
> +/*
> + * USB port LED trigger
> + *
> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or (at
> + * your option) any later version.
> + */

GPL v2 only.

> +MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
> +MODULE_DESCRIPTION("USB port trigger");
> +MODULE_LICENSE("GPL");

GPL v2

After you fix above, feel free to add:
Reviewed-by: Peter Chen <peter.chen@nxp.com>

-- 

Best Regards,
Peter Chen

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> +
>> +usbport trigger:
>> +- usb-ports : List of USB ports that usbport should observed for turning on a
>> +           given LED.
>> +
>
> %s/should/should be

Thanks.


>> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
>> new file mode 100644
>> index 0000000..97b064c
>> --- /dev/null
>> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> @@ -0,0 +1,206 @@
>> +/*
>> + * USB port LED trigger
>> + *
>> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or (at
>> + * your option) any later version.
>> + */
>
> GPL v2 only.
>
>> +MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
>> +MODULE_DESCRIPTION("USB port trigger");
>> +MODULE_LICENSE("GPL");
>
> GPL v2

What's the reason for this? I don't have any real preference, but I
never heard heard about kernel/Linux preference neither.

-- 
Rafał

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Peter Chen]

On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> +
> >> +usbport trigger:
> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
> >> +           given LED.
> >> +
> >
> > %s/should/should be
> 
> Thanks.
> 
> 
> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
> >> new file mode 100644
> >> index 0000000..97b064c
> >> --- /dev/null
> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> @@ -0,0 +1,206 @@
> >> +/*
> >> + * USB port LED trigger
> >> + *
> >> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or (at
> >> + * your option) any later version.
> >> + */
> >
> > GPL v2 only.
> >
> >> +MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
> >> +MODULE_DESCRIPTION("USB port trigger");
> >> +MODULE_LICENSE("GPL");
> >
> > GPL v2
> 
> What's the reason for this? I don't have any real preference, but I
> never heard heard about kernel/Linux preference neither.
> 

https://en.wikipedia.org/wiki/Linux_kernel

-- 

Best Regards,
Peter Chen

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 18 July 2016 at 07:40, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
>> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> >> +
>> >> +usbport trigger:
>> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
>> >> +           given LED.
>> >> +
>> >
>> > %s/should/should be
>>
>> Thanks.
>>
>>
>> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
>> >> new file mode 100644
>> >> index 0000000..97b064c
>> >> --- /dev/null
>> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> >> @@ -0,0 +1,206 @@
>> >> +/*
>> >> + * USB port LED trigger
>> >> + *
>> >> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or modify
>> >> + * it under the terms of the GNU General Public License as published by
>> >> + * the Free Software Foundation; either version 2 of the License, or (at
>> >> + * your option) any later version.
>> >> + */
>> >
>> > GPL v2 only.
>> >
>> >> +MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
>> >> +MODULE_DESCRIPTION("USB port trigger");
>> >> +MODULE_LICENSE("GPL");
>> >
>> > GPL v2
>>
>> What's the reason for this? I don't have any real preference, but I
>> never heard heard about kernel/Linux preference neither.
>>
>
> https://en.wikipedia.org/wiki/Linux_kernel

Well, Linux is released under GPL v2, I'm well aware of that. It means
all its code needs to be GPL v2 compatible. There are multiple
compatible licenses: MIT, BSD 3-clause, BSD 2-clause. The one I used
allows treating code as GPL V2 as well. I could release this code
using MIT and it should be acceptable as well.

I still don't see what's wrong with the picked license.

-- 
Rafał

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Peter Chen]

On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
> On 18 July 2016 at 07:40, Peter Chen <hzpeterchen@gmail.com> wrote:
> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
> >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> >> +
> >> >> +usbport trigger:
> >> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
> >> >> +           given LED.
> >> >> +
> >> >
> >> > %s/should/should be
> >>
> >> Thanks.
> >>
> >>
> >> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> new file mode 100644
> >> >> index 0000000..97b064c
> >> >> --- /dev/null
> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> @@ -0,0 +1,206 @@
> >> >> +/*
> >> >> + * USB port LED trigger
> >> >> + *
> >> >> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
> >> >> + *
> >> >> + * This program is free software; you can redistribute it and/or modify
> >> >> + * it under the terms of the GNU General Public License as published by
> >> >> + * the Free Software Foundation; either version 2 of the License, or (at
> >> >> + * your option) any later version.
> >> >> + */
> >> >

In your COPYRIGHT, it says "or any later version". But afaik, It should
not be on GPL v3.

Peter
> >> > GPL v2 only.
> >> >
> >> >> +MODULE_AUTHOR("Rafał Miłecki <rafal.milecki@gmail.com>");
> >> >> +MODULE_DESCRIPTION("USB port trigger");
> >> >> +MODULE_LICENSE("GPL");
> >> >
> >> > GPL v2
> >>
> >> What's the reason for this? I don't have any real preference, but I
> >> never heard heard about kernel/Linux preference neither.
> >>
> >
> > https://en.wikipedia.org/wiki/Linux_kernel
> 
> Well, Linux is released under GPL v2, I'm well aware of that. It means
> all its code needs to be GPL v2 compatible. There are multiple
> compatible licenses: MIT, BSD 3-clause, BSD 2-clause. The one I used
> allows treating code as GPL V2 as well. I could release this code
> using MIT and it should be acceptable as well.
> 
> I still don't see what's wrong with the picked license.
> 
> -- 
> Rafał

-- 

Best Regards,
Peter Chen

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 18 July 2016 at 07:53, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 07:40, Peter Chen <hzpeterchen@gmail.com> wrote:
>> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> >> On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
>> >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> >> >> +
>> >> >> +usbport trigger:
>> >> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
>> >> >> +           given LED.
>> >> >> +
>> >> >
>> >> > %s/should/should be
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
>> >> >> new file mode 100644
>> >> >> index 0000000..97b064c
>> >> >> --- /dev/null
>> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> >> >> @@ -0,0 +1,206 @@
>> >> >> +/*
>> >> >> + * USB port LED trigger
>> >> >> + *
>> >> >> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
>> >> >> + *
>> >> >> + * This program is free software; you can redistribute it and/or modify
>> >> >> + * it under the terms of the GNU General Public License as published by
>> >> >> + * the Free Software Foundation; either version 2 of the License, or (at
>> >> >> + * your option) any later version.
>> >> >> + */
>> >> >
>
> In your COPYRIGHT, it says "or any later version". But afaik, It should
> not be on GPL v3.

If one picks my code, modifies it, relicenses it using GPL v3, we
can't include it anymore. It's the same story as with BSD systems and
their BSD licenses. If one picks e.g. BSD 3-clause licensed code,
makes it GPL, releases it (e.g. by putting in Linux), BSD can't use it
anymore.

Still, this license is GPL v2 compatible and as is it can be included
in the Linux.

-- 
Rafał

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-07-18 08:55:52, Rafał Miłecki wrote:
> On 18 July 2016 at 07:53, Peter Chen <hzpeterchen@gmail.com> wrote:
> > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 07:40, Peter Chen <hzpeterchen@gmail.com> wrote:
> >> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> >> On 18 July 2016 at 04:31, Peter Chen <hzpeterchen@gmail.com> wrote:
> >> >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> >> >> +
> >> >> >> +usbport trigger:
> >> >> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
> >> >> >> +           given LED.
> >> >> >> +
> >> >> >
> >> >> > %s/should/should be
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> new file mode 100644
> >> >> >> index 0000000..97b064c
> >> >> >> --- /dev/null
> >> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> @@ -0,0 +1,206 @@
> >> >> >> +/*
> >> >> >> + * USB port LED trigger
> >> >> >> + *
> >> >> >> + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
> >> >> >> + *
> >> >> >> + * This program is free software; you can redistribute it and/or modify
> >> >> >> + * it under the terms of the GNU General Public License as published by
> >> >> >> + * the Free Software Foundation; either version 2 of the License, or (at
> >> >> >> + * your option) any later version.
> >> >> >> + */
> >> >> >
> >
> > In your COPYRIGHT, it says "or any later version". But afaik, It should
> > not be on GPL v3.
> 
> If one picks my code, modifies it, relicenses it using GPL v3, we
> can't include it anymore. It's the same story as with BSD systems and
> their BSD licenses. If one picks e.g. BSD 3-clause licensed code,
> makes it GPL, releases it (e.g. by putting in Linux), BSD can't use it
> anymore.
> 
> Still, this license is GPL v2 compatible and as is it can be included
> in the Linux.

Anything GPLv2 compatible is fair game for the kernel. GPLv2+ is very
common for the kernel.

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

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> > @@ -0,0 +1,206 @@
> > +/*
> > + * USB port LED trigger
> > + *
> > + * Copyright (C) 2016 Rafał Miłecki <rafal.milecki@gmail.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or (at
> > + * your option) any later version.
> > + */
> 
> GPL v2 only.

No, you are not going to tell people which license they can use for
their kernel code.

GPL v2+ is perfectly fine for the kernel.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rob Herring]

On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> This commit adds a new trigger that can turn on LED when USB device gets
> connected to the USB port. This can be useful for various home routers
> that have USB port and a proper LED telling user a device is connected.
> 
> Right now this trigger is usable with a proper DT only, there isn't a
> way to specify USB ports from user space. This may change in a future.
> 
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
> V2: The first version got support for specifying list of USB ports from
>     user space only. There was a (big try &) discussion on adding DT
>     support. It led to a pretty simple solution of comparing of_node of
>     usb_device to of_node specified in usb-ports property.
>     Since it appeared DT support may be simpler and non-DT a bit more
>     complex, this version drops previous support for "ports" and
>     "new_port" and focuses on DT only. The plan is to see if this
>     solution with DT is OK, get it accepted and then work on non-DT.
> 
> Felipe: if there won't be any objections I'd like to ask for your Ack.
> ---
>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
>  Documentation/leds/ledtrig-usbport.txt            |  19 ++
>  drivers/leds/trigger/Kconfig                      |   8 +
>  drivers/leds/trigger/Makefile                     |   1 +
>  drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
>  5 files changed, 245 insertions(+)
>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index af10678..75536f7 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -50,6 +50,12 @@ property can be omitted.
>  For controllers that have no configurable timeout the flash-max-timeout-us
>  property can be omitted.
>  
> +Trigger specific properties for child nodes:
> +
> +usbport trigger:
> +- usb-ports : List of USB ports that usbport should observed for turning on a
> +	      given LED.

I think this should be more generic such that it could work for disk or 
network LEDs too. Perhaps 'led-triggers = <nodes>'? trigger is a bit of 
a Linux name, but I haven't thought of anything better. Really, I'd 
prefer the link in the other direction (e.g. port node have a 'leds" or 
'*-leds' property), but that's maybe harder to parse.

> +
>  Examples:
>  
>  system-status {
> @@ -58,6 +64,11 @@ system-status {
>  	...
>  };
>  
> +usb {
> +	label = "USB";

It's not really clear in the example this is an LED node as it is 
incomplete.

> +	usb-ports = <&ohci_port1>, <&ehci_port1>;
> +};
> +
>  camera-flash {
>  	label = "Flash";
>  	led-sources = <0>, <1>;
> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
> new file mode 100644
> index 0000000..642c4cd
> --- /dev/null
> +++ b/Documentation/leds/ledtrig-usbport.txt
> @@ -0,0 +1,19 @@
> +USB port LED trigger
> +====================
> +
> +This LED trigger can be used for signaling user a presence of USB device in a
> +given port. It simply turns on LED when device appears and turns it off when it
> +disappears.
> +
> +It requires specifying a list of USB ports that should be observed. This can be
> +done in DT by setting a proper property with list of a phandles. If more than
> +one port is specified, LED will be turned on as along as there is at least one
> +device connected to any of ports.
> +
> +This trigger can be activated from user space on led class devices as shown
> +below:
> +
> +  echo usbport > trigger

Why do I have to do this (by default)? I already specified in the DT 
what the connection is. It should come up working OOTB, or don't put it 
in DT.

> +Nevertheless, current there isn't a way to specify list of USB ports from user
> +space.

s/current/currently/

This is a problem since if it works by default and you switch to a 
different trigger, there's no way to get back to the default (unless 
you remember the ports).

Rob

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 20 July 2016 at 03:02, Rob Herring <robh@kernel.org> wrote:
> On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> This commit adds a new trigger that can turn on LED when USB device gets
>> connected to the USB port. This can be useful for various home routers
>> that have USB port and a proper LED telling user a device is connected.
>>
>> Right now this trigger is usable with a proper DT only, there isn't a
>> way to specify USB ports from user space. This may change in a future.
>>
>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> ---
>> V2: The first version got support for specifying list of USB ports from
>>     user space only. There was a (big try &) discussion on adding DT
>>     support. It led to a pretty simple solution of comparing of_node of
>>     usb_device to of_node specified in usb-ports property.
>>     Since it appeared DT support may be simpler and non-DT a bit more
>>     complex, this version drops previous support for "ports" and
>>     "new_port" and focuses on DT only. The plan is to see if this
>>     solution with DT is OK, get it accepted and then work on non-DT.
>>
>> Felipe: if there won't be any objections I'd like to ask for your Ack.
>> ---
>>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
>>  Documentation/leds/ledtrig-usbport.txt            |  19 ++
>>  drivers/leds/trigger/Kconfig                      |   8 +
>>  drivers/leds/trigger/Makefile                     |   1 +
>>  drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
>>  5 files changed, 245 insertions(+)
>>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
>>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
>> index af10678..75536f7 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -50,6 +50,12 @@ property can be omitted.
>>  For controllers that have no configurable timeout the flash-max-timeout-us
>>  property can be omitted.
>>
>> +Trigger specific properties for child nodes:
>> +
>> +usbport trigger:
>> +- usb-ports : List of USB ports that usbport should observed for turning on a
>> +           given LED.
>
> I think this should be more generic such that it could work for disk or
> network LEDs too. Perhaps 'led-triggers = <nodes>'? trigger is a bit of
> a Linux name, but I haven't thought of anything better. Really, I'd
> prefer the link in the other direction (e.g. port node have a 'leds" or
> '*-leds' property), but that's maybe harder to parse.

I was already thinking on this as I plan to add "netdev" trigger at
some point in the future. I'd like to use "net-devices" for it (as a
equivalent or "usb-ports").

However there is a problem with your idea of sharing "led-triggers"
between triggers.. Consider device with generic purpose LED that
should be controllable by a user. I believe we should let user switch
it's state, e.g. with:
echo usbport > trigger
echo netdev > trigger
with a shared property I don't see how we couldn't handle it properly.
I don't think we can use anything like:
led-triggers = <&ohci_port1>, <&ehci_port1>, <&ethmac0>;
I'd get even more complicated if we ever need cells for any trigger.
AFAIK it's not allowed to mix handles with different cells like:
led-triggers = <&ohci_port1>, <&foo 5>, <&ethmac0>;

These problems made me use trigger-specific properies for specifying
LED triggers. Do you have any other idea for sharing a property &
avoiding above problems at the same time?


>> +
>>  Examples:
>>
>>  system-status {
>> @@ -58,6 +64,11 @@ system-status {
>>       ...
>>  };
>>
>> +usb {
>> +     label = "USB";
>
> It's not really clear in the example this is an LED node as it is
> incomplete.

What do you mean by incomplete? Should I include e.g. ohci_port1 in
this example?


>> +     usb-ports = <&ohci_port1>, <&ehci_port1>;
>> +};
>> +
>>  camera-flash {
>>       label = "Flash";
>>       led-sources = <0>, <1>;
>> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
>> new file mode 100644
>> index 0000000..642c4cd
>> --- /dev/null
>> +++ b/Documentation/leds/ledtrig-usbport.txt
>> @@ -0,0 +1,19 @@
>> +USB port LED trigger
>> +====================
>> +
>> +This LED trigger can be used for signaling user a presence of USB device in a
>> +given port. It simply turns on LED when device appears and turns it off when it
>> +disappears.
>> +
>> +It requires specifying a list of USB ports that should be observed. This can be
>> +done in DT by setting a proper property with list of a phandles. If more than
>> +one port is specified, LED will be turned on as along as there is at least one
>> +device connected to any of ports.
>> +
>> +This trigger can be activated from user space on led class devices as shown
>> +below:
>> +
>> +  echo usbport > trigger
>
> Why do I have to do this (by default)? I already specified in the DT
> what the connection is. It should come up working OOTB, or don't put it
> in DT.

Just specifying connection with "usb-ports" (or "led-triggers") won't
enable a given trigger and it shouldn't. There is already a way to
specify default trigger using property "linux,default-trigger". So you
can specify:
1) Default one with:
linux,default-trigger = "usbport";
2) On runtime:
echo usbport > trigger


>> +Nevertheless, current there isn't a way to specify list of USB ports from user
>> +space.
>
> s/current/currently/
>
> This is a problem since if it works by default and you switch to a
> different trigger, there's no way to get back to the default (unless
> you remember the ports).

There is no such problem. You can freely do:
echo none > trigger
(e.g. to disable LED during night or whatever)
and then:
echo usbport > trigger

This will make "usbport" use triggers specified in DT as expected.

-- 
Rafał

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rob Herring]

On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
> On 20 July 2016 at 03:02, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> This commit adds a new trigger that can turn on LED when USB device gets
> >> connected to the USB port. This can be useful for various home routers
> >> that have USB port and a proper LED telling user a device is connected.
> >>
> >> Right now this trigger is usable with a proper DT only, there isn't a
> >> way to specify USB ports from user space. This may change in a future.
> >>
> >> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >> ---
> >> V2: The first version got support for specifying list of USB ports from
> >>     user space only. There was a (big try &) discussion on adding DT
> >>     support. It led to a pretty simple solution of comparing of_node of
> >>     usb_device to of_node specified in usb-ports property.
> >>     Since it appeared DT support may be simpler and non-DT a bit more
> >>     complex, this version drops previous support for "ports" and
> >>     "new_port" and focuses on DT only. The plan is to see if this
> >>     solution with DT is OK, get it accepted and then work on non-DT.
> >>
> >> Felipe: if there won't be any objections I'd like to ask for your Ack.
> >> ---
> >>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
> >>  Documentation/leds/ledtrig-usbport.txt            |  19 ++
> >>  drivers/leds/trigger/Kconfig                      |   8 +
> >>  drivers/leds/trigger/Makefile                     |   1 +
> >>  drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
> >>  5 files changed, 245 insertions(+)
> >>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
> >>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> >> index af10678..75536f7 100644
> >> --- a/Documentation/devicetree/bindings/leds/common.txt
> >> +++ b/Documentation/devicetree/bindings/leds/common.txt
> >> @@ -50,6 +50,12 @@ property can be omitted.
> >>  For controllers that have no configurable timeout the flash-max-timeout-us
> >>  property can be omitted.
> >>
> >> +Trigger specific properties for child nodes:
> >> +
> >> +usbport trigger:
> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
> >> +           given LED.
> >
> > I think this should be more generic such that it could work for disk or
> > network LEDs too. Perhaps 'led-triggers = <nodes>'? trigger is a bit of
> > a Linux name, but I haven't thought of anything better. Really, I'd
> > prefer the link in the other direction (e.g. port node have a 'leds" or
> > '*-leds' property), but that's maybe harder to parse.
> 
> I was already thinking on this as I plan to add "netdev" trigger at
> some point in the future. I'd like to use "net-devices" for it (as a
> equivalent or "usb-ports").
> 
> However there is a problem with your idea of sharing "led-triggers"
> between triggers.. Consider device with generic purpose LED that
> should be controllable by a user. I believe we should let user switch
> it's state, e.g. with:
> echo usbport > trigger
> echo netdev > trigger
> with a shared property I don't see how we couldn't handle it properly.

Well, the userspace interface and DT bindings are independent things. 
You can't argue for what the DT binding should look like based on the 
userspace interface.

Perhaps we need a "device trigger" where you echo the device to 
be the trigger (similar to how bind works). If you have something to id 
the device, then you can lookup its struct device and then its of_node 
ptr.

The other problem with your userspace interface is it only works if 
the trigger is defined in DT. It doesn't allow for specifying which usb 
port or which netdev. Any trigger source should be assignable to any 
LED? I can assign the disk activity trigger to the numlock LED if I 
want to...

> I don't think we can use anything like:
> led-triggers = <&ohci_port1>, <&ehci_port1>, <&ethmac0>;
> I'd get even more complicated if we ever need cells for any trigger.
> AFAIK it's not allowed to mix handles with different cells like:
> led-triggers = <&ohci_port1>, <&foo 5>, <&ethmac0>;

It is allowed, but you would have to have a '#led-trigger-cells' 
property in each phandle target.

> These problems made me use trigger-specific properies for specifying
> LED triggers. Do you have any other idea for sharing a property &
> avoiding above problems at the same time?
> 
> 
> >> +
> >>  Examples:
> >>
> >>  system-status {
> >> @@ -58,6 +64,11 @@ system-status {
> >>       ...
> >>  };
> >>
> >> +usb {
> >> +     label = "USB";
> >
> > It's not really clear in the example this is an LED node as it is
> > incomplete.
> 
> What do you mean by incomplete? Should I include e.g. ohci_port1 in
> this example?

label and usb-ports alone in this node does not make an LED node.

> 
> 
> >> +     usb-ports = <&ohci_port1>, <&ehci_port1>;
> >> +};
> >> +
> >>  camera-flash {
> >>       label = "Flash";
> >>       led-sources = <0>, <1>;
> >> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
> >> new file mode 100644
> >> index 0000000..642c4cd
> >> --- /dev/null
> >> +++ b/Documentation/leds/ledtrig-usbport.txt
> >> @@ -0,0 +1,19 @@
> >> +USB port LED trigger
> >> +====================
> >> +
> >> +This LED trigger can be used for signaling user a presence of USB device in a
> >> +given port. It simply turns on LED when device appears and turns it off when it
> >> +disappears.
> >> +
> >> +It requires specifying a list of USB ports that should be observed. This can be
> >> +done in DT by setting a proper property with list of a phandles. If more than
> >> +one port is specified, LED will be turned on as along as there is at least one
> >> +device connected to any of ports.
> >> +
> >> +This trigger can be activated from user space on led class devices as shown
> >> +below:
> >> +
> >> +  echo usbport > trigger
> >
> > Why do I have to do this (by default)? I already specified in the DT
> > what the connection is. It should come up working OOTB, or don't put it
> > in DT.
> 
> Just specifying connection with "usb-ports" (or "led-triggers") won't
> enable a given trigger and it shouldn't. There is already a way to
> specify default trigger using property "linux,default-trigger". So you
> can specify:
> 1) Default one with:
> linux,default-trigger = "usbport";
> 2) On runtime:
> echo usbport > trigger

IMO, these should be mutually exclusive. Either you specify a DT node as 
the trigger or you specify a linux specific trigger.

> >> +Nevertheless, current there isn't a way to specify list of USB ports from user
> >> +space.
> >
> > s/current/currently/
> >
> > This is a problem since if it works by default and you switch to a
> > different trigger, there's no way to get back to the default (unless
> > you remember the ports).
> 
> There is no such problem. You can freely do:
> echo none > trigger
> (e.g. to disable LED during night or whatever)
> and then:
> echo usbport > trigger
> 
> This will make "usbport" use triggers specified in DT as expected.

I think the singular "usbport" trigger is problematic. Look at how cpu 
triggers are done. I can specify which cpu is the trigger. You should be 
able specify which port is the trigger, too.

In summary, I guess what I'm saying is don't push the problems of the 
current userspace interface down to DT.

Rob

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

HI Rob,

I got problems following your objections, so it took me some time to
go back to this.

On 21 July 2016 at 22:42, Rob Herring <robh@kernel.org> wrote:
> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>> On 20 July 2016 at 03:02, Rob Herring <robh@kernel.org> wrote:
>> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> >> This commit adds a new trigger that can turn on LED when USB device gets
>> >> connected to the USB port. This can be useful for various home routers
>> >> that have USB port and a proper LED telling user a device is connected.
>> >>
>> >> Right now this trigger is usable with a proper DT only, there isn't a
>> >> way to specify USB ports from user space. This may change in a future.
>> >>
>> >> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> >> ---
>> >> V2: The first version got support for specifying list of USB ports from
>> >>     user space only. There was a (big try &) discussion on adding DT
>> >>     support. It led to a pretty simple solution of comparing of_node of
>> >>     usb_device to of_node specified in usb-ports property.
>> >>     Since it appeared DT support may be simpler and non-DT a bit more
>> >>     complex, this version drops previous support for "ports" and
>> >>     "new_port" and focuses on DT only. The plan is to see if this
>> >>     solution with DT is OK, get it accepted and then work on non-DT.
>> >>
>> >> Felipe: if there won't be any objections I'd like to ask for your Ack.
>> >> ---
>> >>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
>> >>  Documentation/leds/ledtrig-usbport.txt            |  19 ++
>> >>  drivers/leds/trigger/Kconfig                      |   8 +
>> >>  drivers/leds/trigger/Makefile                     |   1 +
>> >>  drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
>> >>  5 files changed, 245 insertions(+)
>> >>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
>> >>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
>> >> index af10678..75536f7 100644
>> >> --- a/Documentation/devicetree/bindings/leds/common.txt
>> >> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> >> @@ -50,6 +50,12 @@ property can be omitted.
>> >>  For controllers that have no configurable timeout the flash-max-timeout-us
>> >>  property can be omitted.
>> >>
>> >> +Trigger specific properties for child nodes:
>> >> +
>> >> +usbport trigger:
>> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
>> >> +           given LED.
>> >
>> > I think this should be more generic such that it could work for disk or
>> > network LEDs too. Perhaps 'led-triggers = <nodes>'? trigger is a bit of
>> > a Linux name, but I haven't thought of anything better. Really, I'd
>> > prefer the link in the other direction (e.g. port node have a 'leds" or
>> > '*-leds' property), but that's maybe harder to parse.
>>
>> I was already thinking on this as I plan to add "netdev" trigger at
>> some point in the future. I'd like to use "net-devices" for it (as a
>> equivalent or "usb-ports").
>>
>> However there is a problem with your idea of sharing "led-triggers"
>> between triggers.. Consider device with generic purpose LED that
>> should be controllable by a user. I believe we should let user switch
>> it's state, e.g. with:
>> echo usbport > trigger
>> echo netdev > trigger
>> with a shared property I don't see how we couldn't handle it properly.
>
> Well, the userspace interface and DT bindings are independent things.
> You can't argue for what the DT binding should look like based on the
> userspace interface.

I don't understand that. It sounds like you don't want user to have
control over a LED that was specified in DT. If I got it right, it
sounds like a bad idea to me. It's a known case (in marketing, usage
model) to allow user disable all LEDs (e.g. to don't disturb him
during the night). That sounds like a valid usage for me, so I want
user to be able to switch between triggers. And this is of course what
is already supported by triggers and user space interface. With
*current* triggers implementation you can do:
cd /sys/class/leds/foo/
echo none > trigger
echo timer > trigger

So I'm trying to have trigger specific entry in order to support more
than a single trigger.


> Perhaps we need a "device trigger" where you echo the device to
> be the trigger (similar to how bind works). If you have something to id
> the device, then you can lookup its struct device and then its of_node
> ptr.

Are you describing mixing user space interface with DT interface at
this point? Because echoing device sounds like doing some "echo foo >
bar" in user space. If so, I didn't design setting trigger details
from user space yet. I'm aware it'll require more discussion, so I
left it fo later.


> The other problem with your userspace interface is it only works if
> the trigger is defined in DT. It doesn't allow for specifying which usb
> port or which netdev. Any trigger source should be assignable to any
> LED? I can assign the disk activity trigger to the numlock LED if I
> want to...

Well, it's not a surprise, I pretty straightly described it in the
commit message:
> Right now this trigger is usable with a proper DT only, there isn't a
> way to specify USB ports from user space. This may change in a future.
I mean to discuss and add a way of specifying sources to the trigger
in the future.

To answer your question: you can't assign trigger source to the LED.
First you need to assign trigger to the LED. Then some triggers may
allow setting extra parameters.

There are not limitations on assigning triggers. So you can e.g.
assign disk activity trigger to the USB LED. LEDs subsystem doesn't
store info about LED type, only its name.


>> I don't think we can use anything like:
>> led-triggers = <&ohci_port1>, <&ehci_port1>, <&ethmac0>;
>> I'd get even more complicated if we ever need cells for any trigger.
>> AFAIK it's not allowed to mix handles with different cells like:
>> led-triggers = <&ohci_port1>, <&foo 5>, <&ethmac0>;
>
> It is allowed, but you would have to have a '#led-trigger-cells'
> property in each phandle target.
>
>> These problems made me use trigger-specific properies for specifying
>> LED triggers. Do you have any other idea for sharing a property &
>> avoiding above problems at the same time?
>>
>>
>> >> +
>> >>  Examples:
>> >>
>> >>  system-status {
>> >> @@ -58,6 +64,11 @@ system-status {
>> >>       ...
>> >>  };
>> >>
>> >> +usb {
>> >> +     label = "USB";
>> >
>> > It's not really clear in the example this is an LED node as it is
>> > incomplete.
>>
>> What do you mean by incomplete? Should I include e.g. ohci_port1 in
>> this example?
>
> label and usb-ports alone in this node does not make an LED node.

I just followed the current form of
Documentation/devicetree/bindings/leds/common.txt . Should we improve
this while in general? It already has a similar example like this:
system-status {
        label = "Status";
        linux,default-trigger = "heartbeat";
        ...
};


>> >> +     usb-ports = <&ohci_port1>, <&ehci_port1>;
>> >> +};
>> >> +
>> >>  camera-flash {
>> >>       label = "Flash";
>> >>       led-sources = <0>, <1>;
>> >> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
>> >> new file mode 100644
>> >> index 0000000..642c4cd
>> >> --- /dev/null
>> >> +++ b/Documentation/leds/ledtrig-usbport.txt
>> >> @@ -0,0 +1,19 @@
>> >> +USB port LED trigger
>> >> +====================
>> >> +
>> >> +This LED trigger can be used for signaling user a presence of USB device in a
>> >> +given port. It simply turns on LED when device appears and turns it off when it
>> >> +disappears.
>> >> +
>> >> +It requires specifying a list of USB ports that should be observed. This can be
>> >> +done in DT by setting a proper property with list of a phandles. If more than
>> >> +one port is specified, LED will be turned on as along as there is at least one
>> >> +device connected to any of ports.
>> >> +
>> >> +This trigger can be activated from user space on led class devices as shown
>> >> +below:
>> >> +
>> >> +  echo usbport > trigger
>> >
>> > Why do I have to do this (by default)? I already specified in the DT
>> > what the connection is. It should come up working OOTB, or don't put it
>> > in DT.
>>
>> Just specifying connection with "usb-ports" (or "led-triggers") won't
>> enable a given trigger and it shouldn't. There is already a way to
>> specify default trigger using property "linux,default-trigger". So you
>> can specify:
>> 1) Default one with:
>> linux,default-trigger = "usbport";
>> 2) On runtime:
>> echo usbport > trigger
>
> IMO, these should be mutually exclusive. Either you specify a DT node as
> the trigger or you specify a linux specific trigger.

I don't think I'm even able to make them exclusive without reworking
triggers subsystem. It's what is already implemented there and trigger
can't really say it refuses to be unassigned from the LED.
Also if we don't allow changing current trigger (by echo foo >
trigger) it won't be possible to disable LED (e.g. for a night) or
change trigger for some multi purpose LEDs.


>> >> +Nevertheless, current there isn't a way to specify list of USB ports from user
>> >> +space.
>> >
>> > s/current/currently/
>> >
>> > This is a problem since if it works by default and you switch to a
>> > different trigger, there's no way to get back to the default (unless
>> > you remember the ports).
>>
>> There is no such problem. You can freely do:
>> echo none > trigger
>> (e.g. to disable LED during night or whatever)
>> and then:
>> echo usbport > trigger
>>
>> This will make "usbport" use triggers specified in DT as expected.
>
> I think the singular "usbport" trigger is problematic. Look at how cpu
> triggers are done. I can specify which cpu is the trigger. You should be
> able specify which port is the trigger, too.

Maybe it would be possible to register separate trigger for every USB
port. I can see some problems like fetching list of possible USB port
(we don't have anything lovely like for_each_possible_cpu). Should
list of ports be read from DT? Or maybe we should create/delete
triggers dynamically as new USB hubs appear? That would require more
logic like detecting how many ports a hub supports.

Anyway, the serious limitation I see is assigning more than a single
port to a LED. One LED can have only 1 trigger assigned at the time.
There are plenty of devices with 1 USB LED and few USB ports. Also
some physical ports are handled by more than 1 controller (up to 3 or
more). We really need a way to assign more than 1 USB port to a single
LED.
This seems to be also a limitation of CPU trigger I didn't notice so
far. What if you have dual CPU device with only 1 CPU activity LED?


> In summary, I guess what I'm saying is don't push the problems of the
> current userspace interface down to DT.

Thanks for your time and looking at this problem with me. I'm afraid
I'll need some more help (or so it seems so far to me).

I'm wondering if we have some misunderstanding on this whole thing
with USB port trigger. Maybe I didn't explain my use case well enough
and it's clear to me only?

I'm coming from OpenWrt/LEDE project which is basically a distribution
for home routers. We deal with a wide range of devices you can find on
a market. We also have plenty of out of tree drivers and solutions I'm
not a big fan of. I'm trying to improve/rewrite them, get them in an
acceptable form and upstream.

One of problems we got are USB LEDs. We have some out of tree driver for them:
http://git.openwrt.org/?p=15.05/openwrt.git;a=blob;f=target/linux/generic/files/drivers/leds/ledtrig-usbdev.c;hb=HEAD
but it doesn't work well. It doesn't have any DT support. It requires
user to know USB ports. He has to write some script that will setup a
trigger on every boot. It works for 1 USB port only.

So I would like to:
1) Have a USB trigger selectable with "linux,default-trigger"
2) Have property next to "linux,default-trigger" specifying USB ports
3) Have trigger follow ports, light LED on if any of them has device connected
4) Allow user to deactivate this trigger (e.g. no LEDs on during night)

Some extra notes:
1) I don't think it's possible for a single trigger to handle various
devices like USB or network ones. Later we may may want to add more
complex stuff like blinking on activity. It's too much to handle in a
single trigger.
2) I'm trying to be thinking future-proof and I think we may need
switching between triggers in the future. I mean allowing user to
choose between some more complex triggers, not just "none" and "foo".
Maybe some status LED (with default-on trigger) that can get network
activity trigger assigned during WPS action? Such a possibility of
changing triggers would go in pair with current implementation (echo
"foo" > trigger).

Does it make my attempts to make any more sense? Can you suggest some
way I should proceed?

-- 
Rafał

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 29 July 2016 at 09:09, Rafał Miłecki <zajec5@gmail.com> wrote:
> HI Rob,
>
> I got problems following your objections, so it took me some time to
> go back to this.
>
> On 21 July 2016 at 22:42, Rob Herring <robh@kernel.org> wrote:
>> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>>> On 20 July 2016 at 03:02, Rob Herring <robh@kernel.org> wrote:
>>> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>>> >> This commit adds a new trigger that can turn on LED when USB device gets
>>> >> connected to the USB port. This can be useful for various home routers
>>> >> that have USB port and a proper LED telling user a device is connected.
>>> >>
>>> >> Right now this trigger is usable with a proper DT only, there isn't a
>>> >> way to specify USB ports from user space. This may change in a future.
>>> >>
>>> >> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>>> >> ---
>>> >> V2: The first version got support for specifying list of USB ports from
>>> >>     user space only. There was a (big try &) discussion on adding DT
>>> >>     support. It led to a pretty simple solution of comparing of_node of
>>> >>     usb_device to of_node specified in usb-ports property.
>>> >>     Since it appeared DT support may be simpler and non-DT a bit more
>>> >>     complex, this version drops previous support for "ports" and
>>> >>     "new_port" and focuses on DT only. The plan is to see if this
>>> >>     solution with DT is OK, get it accepted and then work on non-DT.
>>> >>
>>> >> Felipe: if there won't be any objections I'd like to ask for your Ack.
>>> >> ---
>>> >>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
>>> >>  Documentation/leds/ledtrig-usbport.txt            |  19 ++
>>> >>  drivers/leds/trigger/Kconfig                      |   8 +
>>> >>  drivers/leds/trigger/Makefile                     |   1 +
>>> >>  drivers/leds/trigger/ledtrig-usbport.c            | 206 ++++++++++++++++++++++
>>> >>  5 files changed, 245 insertions(+)
>>> >>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
>>> >>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
>>> >> index af10678..75536f7 100644
>>> >> --- a/Documentation/devicetree/bindings/leds/common.txt
>>> >> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>> >> @@ -50,6 +50,12 @@ property can be omitted.
>>> >>  For controllers that have no configurable timeout the flash-max-timeout-us
>>> >>  property can be omitted.
>>> >>
>>> >> +Trigger specific properties for child nodes:
>>> >> +
>>> >> +usbport trigger:
>>> >> +- usb-ports : List of USB ports that usbport should observed for turning on a
>>> >> +           given LED.
>>> >
>>> > I think this should be more generic such that it could work for disk or
>>> > network LEDs too. Perhaps 'led-triggers = <nodes>'? trigger is a bit of
>>> > a Linux name, but I haven't thought of anything better. Really, I'd
>>> > prefer the link in the other direction (e.g. port node have a 'leds" or
>>> > '*-leds' property), but that's maybe harder to parse.
>>>
>>> I was already thinking on this as I plan to add "netdev" trigger at
>>> some point in the future. I'd like to use "net-devices" for it (as a
>>> equivalent or "usb-ports").
>>>
>>> However there is a problem with your idea of sharing "led-triggers"
>>> between triggers.. Consider device with generic purpose LED that
>>> should be controllable by a user. I believe we should let user switch
>>> it's state, e.g. with:
>>> echo usbport > trigger
>>> echo netdev > trigger
>>> with a shared property I don't see how we couldn't handle it properly.
>>
>> Well, the userspace interface and DT bindings are independent things.
>> You can't argue for what the DT binding should look like based on the
>> userspace interface.
>
> I don't understand that. It sounds like you don't want user to have
> control over a LED that was specified in DT. If I got it right, it
> sounds like a bad idea to me. It's a known case (in marketing, usage
> model) to allow user disable all LEDs (e.g. to don't disturb him
> during the night). That sounds like a valid usage for me, so I want
> user to be able to switch between triggers. And this is of course what
> is already supported by triggers and user space interface. With
> *current* triggers implementation you can do:
> cd /sys/class/leds/foo/
> echo none > trigger
> echo timer > trigger
>
> So I'm trying to have trigger specific entry in order to support more
> than a single trigger.
>
>
>> Perhaps we need a "device trigger" where you echo the device to
>> be the trigger (similar to how bind works). If you have something to id
>> the device, then you can lookup its struct device and then its of_node
>> ptr.
>
> Are you describing mixing user space interface with DT interface at
> this point? Because echoing device sounds like doing some "echo foo >
> bar" in user space. If so, I didn't design setting trigger details
> from user space yet. I'm aware it'll require more discussion, so I
> left it fo later.
>
>
>> The other problem with your userspace interface is it only works if
>> the trigger is defined in DT. It doesn't allow for specifying which usb
>> port or which netdev. Any trigger source should be assignable to any
>> LED? I can assign the disk activity trigger to the numlock LED if I
>> want to...
>
> Well, it's not a surprise, I pretty straightly described it in the
> commit message:
>> Right now this trigger is usable with a proper DT only, there isn't a
>> way to specify USB ports from user space. This may change in a future.
> I mean to discuss and add a way of specifying sources to the trigger
> in the future.
>
> To answer your question: you can't assign trigger source to the LED.
> First you need to assign trigger to the LED. Then some triggers may
> allow setting extra parameters.
>
> There are not limitations on assigning triggers. So you can e.g.
> assign disk activity trigger to the USB LED. LEDs subsystem doesn't
> store info about LED type, only its name.
>
>
>>> I don't think we can use anything like:
>>> led-triggers = <&ohci_port1>, <&ehci_port1>, <&ethmac0>;
>>> I'd get even more complicated if we ever need cells for any trigger.
>>> AFAIK it's not allowed to mix handles with different cells like:
>>> led-triggers = <&ohci_port1>, <&foo 5>, <&ethmac0>;
>>
>> It is allowed, but you would have to have a '#led-trigger-cells'
>> property in each phandle target.
>>
>>> These problems made me use trigger-specific properies for specifying
>>> LED triggers. Do you have any other idea for sharing a property &
>>> avoiding above problems at the same time?
>>>
>>>
>>> >> +
>>> >>  Examples:
>>> >>
>>> >>  system-status {
>>> >> @@ -58,6 +64,11 @@ system-status {
>>> >>       ...
>>> >>  };
>>> >>
>>> >> +usb {
>>> >> +     label = "USB";
>>> >
>>> > It's not really clear in the example this is an LED node as it is
>>> > incomplete.
>>>
>>> What do you mean by incomplete? Should I include e.g. ohci_port1 in
>>> this example?
>>
>> label and usb-ports alone in this node does not make an LED node.
>
> I just followed the current form of
> Documentation/devicetree/bindings/leds/common.txt . Should we improve
> this while in general? It already has a similar example like this:
> system-status {
>         label = "Status";
>         linux,default-trigger = "heartbeat";
>         ...
> };
>
>
>>> >> +     usb-ports = <&ohci_port1>, <&ehci_port1>;
>>> >> +};
>>> >> +
>>> >>  camera-flash {
>>> >>       label = "Flash";
>>> >>       led-sources = <0>, <1>;
>>> >> diff --git a/Documentation/leds/ledtrig-usbport.txt b/Documentation/leds/ledtrig-usbport.txt
>>> >> new file mode 100644
>>> >> index 0000000..642c4cd
>>> >> --- /dev/null
>>> >> +++ b/Documentation/leds/ledtrig-usbport.txt
>>> >> @@ -0,0 +1,19 @@
>>> >> +USB port LED trigger
>>> >> +====================
>>> >> +
>>> >> +This LED trigger can be used for signaling user a presence of USB device in a
>>> >> +given port. It simply turns on LED when device appears and turns it off when it
>>> >> +disappears.
>>> >> +
>>> >> +It requires specifying a list of USB ports that should be observed. This can be
>>> >> +done in DT by setting a proper property with list of a phandles. If more than
>>> >> +one port is specified, LED will be turned on as along as there is at least one
>>> >> +device connected to any of ports.
>>> >> +
>>> >> +This trigger can be activated from user space on led class devices as shown
>>> >> +below:
>>> >> +
>>> >> +  echo usbport > trigger
>>> >
>>> > Why do I have to do this (by default)? I already specified in the DT
>>> > what the connection is. It should come up working OOTB, or don't put it
>>> > in DT.
>>>
>>> Just specifying connection with "usb-ports" (or "led-triggers") won't
>>> enable a given trigger and it shouldn't. There is already a way to
>>> specify default trigger using property "linux,default-trigger". So you
>>> can specify:
>>> 1) Default one with:
>>> linux,default-trigger = "usbport";
>>> 2) On runtime:
>>> echo usbport > trigger
>>
>> IMO, these should be mutually exclusive. Either you specify a DT node as
>> the trigger or you specify a linux specific trigger.
>
> I don't think I'm even able to make them exclusive without reworking
> triggers subsystem. It's what is already implemented there and trigger
> can't really say it refuses to be unassigned from the LED.
> Also if we don't allow changing current trigger (by echo foo >
> trigger) it won't be possible to disable LED (e.g. for a night) or
> change trigger for some multi purpose LEDs.
>
>
>>> >> +Nevertheless, current there isn't a way to specify list of USB ports from user
>>> >> +space.
>>> >
>>> > s/current/currently/
>>> >
>>> > This is a problem since if it works by default and you switch to a
>>> > different trigger, there's no way to get back to the default (unless
>>> > you remember the ports).
>>>
>>> There is no such problem. You can freely do:
>>> echo none > trigger
>>> (e.g. to disable LED during night or whatever)
>>> and then:
>>> echo usbport > trigger
>>>
>>> This will make "usbport" use triggers specified in DT as expected.
>>
>> I think the singular "usbport" trigger is problematic. Look at how cpu
>> triggers are done. I can specify which cpu is the trigger. You should be
>> able specify which port is the trigger, too.
>
> Maybe it would be possible to register separate trigger for every USB
> port. I can see some problems like fetching list of possible USB port
> (we don't have anything lovely like for_each_possible_cpu). Should
> list of ports be read from DT? Or maybe we should create/delete
> triggers dynamically as new USB hubs appear? That would require more
> logic like detecting how many ports a hub supports.
>
> Anyway, the serious limitation I see is assigning more than a single
> port to a LED. One LED can have only 1 trigger assigned at the time.
> There are plenty of devices with 1 USB LED and few USB ports. Also
> some physical ports are handled by more than 1 controller (up to 3 or
> more). We really need a way to assign more than 1 USB port to a single
> LED.
> This seems to be also a limitation of CPU trigger I didn't notice so
> far. What if you have dual CPU device with only 1 CPU activity LED?
>
>
>> In summary, I guess what I'm saying is don't push the problems of the
>> current userspace interface down to DT.
>
> Thanks for your time and looking at this problem with me. I'm afraid
> I'll need some more help (or so it seems so far to me).
>
> I'm wondering if we have some misunderstanding on this whole thing
> with USB port trigger. Maybe I didn't explain my use case well enough
> and it's clear to me only?
>
> I'm coming from OpenWrt/LEDE project which is basically a distribution
> for home routers. We deal with a wide range of devices you can find on
> a market. We also have plenty of out of tree drivers and solutions I'm
> not a big fan of. I'm trying to improve/rewrite them, get them in an
> acceptable form and upstream.
>
> One of problems we got are USB LEDs. We have some out of tree driver for them:
> http://git.openwrt.org/?p=15.05/openwrt.git;a=blob;f=target/linux/generic/files/drivers/leds/ledtrig-usbdev.c;hb=HEAD
> but it doesn't work well. It doesn't have any DT support. It requires
> user to know USB ports. He has to write some script that will setup a
> trigger on every boot. It works for 1 USB port only.
>
> So I would like to:
> 1) Have a USB trigger selectable with "linux,default-trigger"
> 2) Have property next to "linux,default-trigger" specifying USB ports
> 3) Have trigger follow ports, light LED on if any of them has device connected
> 4) Allow user to deactivate this trigger (e.g. no LEDs on during night)
>
> Some extra notes:
> 1) I don't think it's possible for a single trigger to handle various
> devices like USB or network ones. Later we may may want to add more
> complex stuff like blinking on activity. It's too much to handle in a
> single trigger.
> 2) I'm trying to be thinking future-proof and I think we may need
> switching between triggers in the future. I mean allowing user to
> choose between some more complex triggers, not just "none" and "foo".
> Maybe some status LED (with default-on trigger) that can get network
> activity trigger assigned during WPS action? Such a possibility of
> changing triggers would go in pair with current implementation (echo
> "foo" > trigger).
>
> Does it make my attempts to make any more sense? Can you suggest some
> way I should proceed?

Ping?

-- 
Rafał