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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fd6a12b6-334d-98c6-4492-ba36474d6b22@gmail.com>
Date:   Sat, 3 Sep 2016 21:12:50 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Jacek Anaszewski <j.anaszewski@...sung.com>,
        Rafał Miłecki <zajec5@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Richard Purdie <rpurdie@...ys.net>,
        Felipe Balbi <balbi@...nel.org>,
        Peter Chen <hzpeterchen@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Rafał Miłecki <rafal@...ecki.pl>,
        Jonathan Corbet <corbet@....net>,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Stephan Linz <linz@...pro.net>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        "open list:LED SUBSYSTEM" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

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