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

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

On 09/03/2016 05:17 PM, Alan Stern wrote:
> On Sat, 3 Sep 2016, Jacek Anaszewski wrote:
>
>>>>> Maybe it would make more sense, in this case, to allow only three
>>>>> possibilities for a USB port activity trigger.  Toggle the LED
>>>>> whenever:
>>>>>
>>>>> 	There is activity on the specified port, or
>>>>>
>>>>> 	There is any activity on any port on the specified hub, or
>>>>>
>>>>> 	There is any USB activity on any port.
>>>>>
>>>>> That ought to cover most of the normal use cases, and it would be
>>>>> simple enough to implement.
>>>>
>>>> What would be the benefit of having a USB port activity trigger,
>>>> for which we would be specifying the port to observe, but in the same
>>>> time we would react on any activity on any port (cases 1 and 3)?
>>>
>>> I meant these three cases to be mutually exclusive.  For a given LED,
>>> you could have only one of those trigger types (like mentioned above,
>>> only one trigger per LED).  For example, you might accept any one of:
>>>
>>> 	echo usb1-4.2 >/sys/class/led/foo/trigger
>>>
>>> 	echo hub1-4 >/sys/class/led/foo/trigger
>>>
>>> 	echo usb >/sys/class/led/foo/trigger
>>>
>>> Yes, it would be possible to have a port-specific trigger for one LED
>>> and an overall USB activity trigger for another LED.  I don't know how
>>> useful this would be -- you could probably imagine some unlikely
>>> scenario.
>>>
>>> The point is that doing things this way wouldn't require any API
>>> violations, and it would allow users to do almost all of the things
>>> they are likely to want.
>>
>> We'd have to define single API for generating USB trigger event,
>> so as not enforce addition of three different API calls to the USB
>> drivers.

Of course this trigger represents yet another type of triggers, that
don't require exposing an API for generating events, but instead
register as listeners to some notifiers. I missed that initially.

> The USB core would need only one LED-API call, which it would make upon
> the completion of an URB.  The trigger code should be able to handle
> all the rest (i.e., see which LEDs should be triggered by that URB).

This is assured by the LED trigger core.

>
>>  The type of USB events that the LED should react upon could be
>> defined by parsing the value written to the sysfs file.
>
> There is only one type of event: completion of an URB.  Triggers would
> differ depending only on the device/port that the URB was aimed at.
> _That_ information could be defined by parsing the value written to the
> sysfs file.
>
>> This of course implies, that we should have single LED USB port trigger.
>>
>> The remaining issue is the sysfs interface design for defining and
>> presenting multiple USB ports. I'm still in favour of a single
>> attribute with space separated list. This scheme is commonly used
>> in existing interfaces.
>
> No such interface is needed if you do things the way I outlined above.
> Each trigger would require the user to specify either one port, one
> hub, or nothing at all.  Multiple ports would not be used.

The patch assumes that it is possible to register trigger for many
ports.

-- 
Best regards,
Jacek Anaszewski