Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

From: Jacek Anaszewski
Date: Thu Aug 25 2016 - 14:48:50 EST

On 08/25/2016 04:30 PM, Alan Stern wrote:
On Thu, 25 Aug 2016, Jacek Anaszewski wrote:

I'd see it as follows:

#cat available_ports
#1-1 1-2 2-1

#echo "1-1" > new_port

#cat observed_ports

#echo "2-1" > new_port

#cat observed_ports
#1-1 2-1

We've already had few discussions about the sysfs designs trying
to break the one-value-per-file rule for LED class device, and
there was always strong resistance against.

This scheme has multiple values in both the available_ports and
observed_ports files. :-( Not that I have any better suggestions...

Right, I forgot to add a note here, that this follows space
separated list pattern similarly as in case of triggers attribute.
Of course other suggestions are welcome.

Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.

What kind of description do you mean? Where should it be used / where
should it appear?

Product name/symbol. Actually it should be USB subsystem responsibility
to provide the means for querying the product name by port id, if it
is possible at all.

cat /sys/bus/usb/devices/PORT/product
cat /sys/bus/usb/devices/PORT/manufacturer

These will work if there is a device registered under PORT.

I've found only idProduct and idVendor files. They indeed uniquely
identify the device, but the numbers are not human readable.
Is there a way to retrieve the corresponding names in kernel?
Does the lsusb command do the mapping in the user space or maybe
it takes the names from kernel?

Best regards,
Jacek Anaszewski