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

[Rafał Miłecki]

On 29 July 2016 at 09:09, Rafał Miłecki  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  wrote:
>> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>>> On 20 July 2016 at 03:02, Rob Herring  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 
>>> >> ---
>>> >> 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 = '? 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 

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  wrote:
> On Wed, Jul 20, 2016 at 10:06:23AM +0200, Rafał Miłecki wrote:
>> On 20 July 2016 at 03:02, Rob Herring  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 
>> >> ---
>> >> 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 = '? 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 

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  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 
> >> ---
> >> 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 = '? 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 = <_port1>, <_port1>, <>;
> 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 = <_port1>, < 5>, <>;

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 

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  wrote:
> > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 07:40, Peter Chen  wrote:
> >> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> >> On 18 July 2016 at 04:31, Peter Chen  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 000..97b064c
> >> >> >> --- /dev/null
> >> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> @@ -0,0 +1,206 @@
> >> >> >> +/*
> >> >> >> + * USB port LED trigger
> >> >> >> + *
> >> >> >> + * Copyright (C) 2016 Rafał Miłecki 
> >> >> >> + *
> >> >> >> + * 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafał Miłecki]

On 20 July 2016 at 03:02, Rob Herring  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 
>> ---
>> 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 = '? 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 = <_port1>, <_port1>, <>;
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 = <_port1>, < 5>, <>;

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 = <_port1>, <_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 000..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 

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 
> > + *
> > + * 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 linux-usb" in
the body of a message to majord...@vger.kernel.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 
> ---
> 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 = '? 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 = <_port1>, <_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 000..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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafał Miłecki]

On 18 July 2016 at 07:53, Peter Chen  wrote:
> On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 07:40, Peter Chen  wrote:
>> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> >> On 18 July 2016 at 04:31, Peter Chen  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 000..97b064c
>> >> >> --- /dev/null
>> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> >> >> @@ -0,0 +1,206 @@
>> >> >> +/*
>> >> >> + * USB port LED trigger
>> >> >> + *
>> >> >> + * Copyright (C) 2016 Rafał Miłecki 
>> >> >> + *
>> >> >> + * 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ł
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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  wrote:
> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 04:31, Peter Chen  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 000..97b064c
> >> >> --- /dev/null
> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> @@ -0,0 +1,206 @@
> >> >> +/*
> >> >> + * USB port LED trigger
> >> >> + *
> >> >> + * Copyright (C) 2016 Rafał Miłecki 
> >> >> + *
> >> >> + * 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 ");
> >> >> +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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafał Miłecki]

On 18 July 2016 at 07:40, Peter Chen  wrote:
> On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
>> On 18 July 2016 at 04:31, Peter Chen  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 000..97b064c
>> >> --- /dev/null
>> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> >> @@ -0,0 +1,206 @@
>> >> +/*
>> >> + * USB port LED trigger
>> >> + *
>> >> + * Copyright (C) 2016 Rafał Miłecki 
>> >> + *
>> >> + * 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 ");
>> >> +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ł
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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  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 000..97b064c
> >> --- /dev/null
> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> @@ -0,0 +1,206 @@
> >> +/*
> >> + * USB port LED trigger
> >> + *
> >> + * Copyright (C) 2016 Rafał Miłecki 
> >> + *
> >> + * 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 ");
> >> +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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafał Miłecki]

On 18 July 2016 at 04:31, Peter Chen  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 000..97b064c
>> --- /dev/null
>> +++ b/drivers/leds/trigger/ledtrig-usbport.c
>> @@ -0,0 +1,206 @@
>> +/*
>> + * USB port LED trigger
>> + *
>> + * Copyright (C) 2016 Rafał Miłecki 
>> + *
>> + * 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 ");
>> +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ł
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 = <_port1>, <_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 000..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 000..97b064c
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> @@ -0,0 +1,206 @@
> +/*
> + * USB port LED trigger
> + *
> + * Copyright (C) 2016 Rafał Miłecki 
> + *
> + * 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 ");
> +MODULE_DESCRIPTION("USB port trigger");
> +MODULE_LICENSE("GPL");

GPL v2

After you fix above, feel free to add:
Reviewed-by: Peter Chen 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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 
---
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 = <_port1>, <_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 000..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 000..97b064c
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-usbport.c
@@ -0,0 +1,206 @@
+/*
+ * USB port LED trigger
+ *
+ * Copyright (C) 2016 Rafał Miłecki 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include