On 2023-10-12 08:50, Greg KH wrote:
On Wed, Oct 11, 2023 at 02:51:28PM -0400, Douglas Gilbert wrote:
On 2023-10-11 11:00, Alan Stern wrote:
On Wed, Oct 11, 2023 at 11:30:39AM +0200, Greg KH wrote:
On Thu, Oct 05, 2023 at 10:49:10PM -0400, Douglas Gilbert wrote:
The code in lsusb-t.c seems to assign a special meaning to "-1" devices
and there is only one of those: "5-1". And the device associated with
"5-1" is the one that does _not_ appear in the output of 'lsusb -t' but
does appear in the output of 'lsusb'.
The code patch of the '-t' option in lsusb is totally separate and apart
from the "normal" portion of lsusb, as you note, it is a separate .c
file as well. -t uses the sysfs representation of the USB devices,
while the other code path uses the 'libusb' representation of the USB
devices. And those seem to differ here (as they do for everyone.)
So if someone wants to take the time to figure out which representation
is "more correct", that would be great. I don't have the bandwidth to
do so for the next few weeks due to travel requirements on my end,
sorry.
Doug, I've looked through the source code in lsusb-t.c (usbutils 015)
and I didn't notice any place where it treats device names containing
"-1" specially. Can you point it out?
Also, if I suggested some debugging additions to the source file, would
you be able to build them and test the result?
Hi Alan,
Attached is a patch that adds support for a '-S <sysroot>' option to lsusb from
usbutils found in GKH's github account. It only works when the '-t' option is
given to show USB devices in a tree like representation. Without the '-t' option
lsusb uses the enumeration services in libusb. The 'lsusb' invocation does find
the device at /tmp/sys/bus/usb/devices/5-1 which is a "product : STEVAL-USBC2DP
Type-C to DisplayPort adapter" made by ST Micro.
Also attached is a pruned representation of /sys and /dev from my machine which
is a Thinkpad X13 G3 with a Lenovo TB3 dock [40AN] connected via USB-C. The
"missing" adapter is connected to that dock. However that indirect
connection
is probably _not_ significant since if I move that dongle to the other USB-C
receptacle on the X13G3 (it has two), the same seen/not_seen issue is
reproduced. And with the direct connect the adapter moves to
/sys/bus/usb/devices/3-5 . So that debunks my theory that the "1" in the "5-1"
is somehow significant.
The attached files differ from those I sent to GKH in one important respect.
I sent Greg my _whole_ sysfs, around 55,000 nodes and that would have included
serial numbers of my machine, my storage devices, MAC addresses, etc. In
the tarball attached below only about 5000 nodes are present after some
pruning with my clone_pseudo_fs utility (in my github account).
I've pushed all of the remaining pending changes for usbutils to the
repo, and added a few of my own that makes the 'lsusb -t' output a bit
more sane (sorted order, proper digit field width, etc.)
Can you try the latest version in github (or on kernel.org, they are
mirrors) and show the output there?
Removed the Lenovo dock [40AN] to lessen the clutter.
~/usbutils$ ./lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 06cb:00f9 Synaptics, Inc.
Bus 003 Device 003: ID 5986:1177 Acer, Inc Integrated Camera
Bus 003 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 005: ID 8087:0033 Intel Corp.
Bus 003 Device 012: ID 0483:572b STMicroelectronics STEVAL-USBC2DP Type-C to
DisplayPort adapter
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
~/usbutils$ ./lsusb -tv
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/3p, 20000M/x2
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 003: Dev 002, If 0, Class=Vendor Specific Class, Driver=, 12M
ID 06cb:00f9 Synaptics, Inc.
|__ Port 004: Dev 003, If 0, Class=Video, Driver=uvcvideo, 480M
ID 5986:1177 Acer, Inc
|__ Port 004: Dev 003, If 1, Class=Video, Driver=uvcvideo, 480M
ID 5986:1177 Acer, Inc
|__ Port 004: Dev 003, If 2, Class=Application Specific Interface, Driver=,
480M
ID 5986:1177 Acer, Inc
|__ Port 007: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 12M
ID 046d:c52b Logitech, Inc. Unifying Receiver
|__ Port 007: Dev 004, If 1, Class=Human Interface Device, Driver=usbhid, 12M
ID 046d:c52b Logitech, Inc. Unifying Receiver
|__ Port 007: Dev 004, If 2, Class=Human Interface Device, Driver=usbhid, 12M
ID 046d:c52b Logitech, Inc. Unifying Receiver
|__ Port 010: Dev 005, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0033 Intel Corp.
|__ Port 010: Dev 005, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0033 Intel Corp.
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
So ID 0483:572b (ST Micro DP dongle) still missing in the 'lsusb -t' output.
Also noticed that the -d and -D options are ignored, without warning, when
the '-t' option is given. If that is a feature, perhaps the manpage should
state that.
Doug Gilbert
