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:   Mon, 5 Sep 2016 11:28:41 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Jacek Anaszewski <j.anaszewski@...sung.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 4 September 2016 at 02:24, Alan Stern <stern@...land.harvard.edu> wrote:
> On Sat, 3 Sep 2016, Jacek Anaszewski wrote:
>
>> >> 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.
>
> The patch could be changed to remove that assumption.

I did this assumption for a reason. There are many devices with more
than 1 USB port and these ports are handled by the same controllers,
just different ports. Let me share USB details of my SmartRG SR400ac
device with 2 physical USB ports:

Physical USB 3.0 port is handled by following controllers and their
root hub ports:
1) OHCI's port 1
2) EHCI's port 1
3) XHCI's port 1

Physical USB 2.0 port is handled by following controllers and their
root hub ports:
1) OHCI's port 2
2) EHCI's port 2


This devices has 3 separated LEDs. I'll list them and tell which ports
should be assigned to them:

bcm53xx:green:usb3 should have assigned:
1) OHCI's port 1
2) EHCI's port 1

bcm53xx:white:usb3 should have assigned:
1) XHCI's port 1

bcm53xx:white:usb2 should have assigned:
1) OHCI's port 2
2) EHCI's port 2


As you can see, I need to specify ports precisely. Assigning a single
port is not enough. Assigning whole hub is too much. So none 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
would be sufficient here :(

-- 
Rafał