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
#1-1
#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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
