Re: device present in lsusb, disappears in lsusb -t

[Douglas Gilbert <dgilbert@interlog.com>]

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