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]

Date:   Sat, 3 Sep 2016 11:17:58 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
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 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.

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).

>  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.

Alan Stern