* device present in lsusb, disappears in lsusb -t
@ 2023-09-16 0:16 Douglas Gilbert
2023-09-16 11:16 ` Greg KH
0 siblings, 1 reply; 12+ messages in thread
From: Douglas Gilbert @ 2023-09-16 0:16 UTC (permalink / raw)
To: linux-usb
The device in question is this one:
Bus 005 Device 015: ID 0483:572b STMicroelectronics STEVAL-USBC2DP Type-C to
DisplayPort adapter. It is a USB-C alternate mode device (so tbtadm does not
report it).
That adapter is connected to a screen (and working) and to a USB-C port on
a Lenovo TB3 dock [40AN] which in turn is connected to a Thinkpad X13 Gen3's
USB-C port. The Thinkpad is running lk 6.6.0-rc1 with "lsusb (usbutils) 014".
The strange thing is that this device is nowhere to be found in the output
of "lsusb -t". The lsusb manpage describes the '-t' option as: "Tells
lsusb to dump the physical USB device hierarchy as a tree." So is 'physical'
a weasel word in this context, or is there a bug in the '-t' option, or is
there some other explanation?
Doug Gilbert
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-09-16 0:16 device present in lsusb, disappears in lsusb -t Douglas Gilbert
@ 2023-09-16 11:16 ` Greg KH
2023-10-06 2:49 ` Douglas Gilbert
0 siblings, 1 reply; 12+ messages in thread
From: Greg KH @ 2023-09-16 11:16 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: linux-usb
On Fri, Sep 15, 2023 at 08:16:18PM -0400, Douglas Gilbert wrote:
> The device in question is this one:
> Bus 005 Device 015: ID 0483:572b STMicroelectronics STEVAL-USBC2DP Type-C
> to DisplayPort adapter. It is a USB-C alternate mode device (so tbtadm does
> not
> report it).
>
> That adapter is connected to a screen (and working) and to a USB-C port on
> a Lenovo TB3 dock [40AN] which in turn is connected to a Thinkpad X13 Gen3's
> USB-C port. The Thinkpad is running lk 6.6.0-rc1 with "lsusb (usbutils) 014".
>
> The strange thing is that this device is nowhere to be found in the output
> of "lsusb -t". The lsusb manpage describes the '-t' option as: "Tells
> lsusb to dump the physical USB device hierarchy as a tree." So is 'physical'
> a weasel word in this context, or is there a bug in the '-t' option, or is
> there some other explanation?
A number of 'lsusb -t' issues were fixed in the 015 release of usbutils,
so maybe update?
that being said, the -t option is a totally different codepath in the
tool, and shows different things overall. -t shows the drivers that are
bound to the different interfaces, which means that a single device will
show up multiple times in the -t option.
Here's the output of the two things on my local laptop, with just a few
USB devices in it:
$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 003 Device 006: ID 0bda:5634 Realtek Semiconductor Corp. Laptop Camera
Bus 003 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 003 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 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
and then if you give the -v option as well you see a bit more:
$ lsusb -tv
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
ID 0bda:5634 Realtek Semiconductor Corp.
|__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
ID 0bda:5634 Realtek Semiconductor Corp.
|__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
|__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0032 Intel Corp. AX210 Bluetooth
|__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0032 Intel Corp. AX210 Bluetooth
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
What are you seeing missing in your output?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-09-16 11:16 ` Greg KH
@ 2023-10-06 2:49 ` Douglas Gilbert
2023-10-11 9:30 ` Greg KH
0 siblings, 1 reply; 12+ messages in thread
From: Douglas Gilbert @ 2023-10-06 2:49 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb
On 2023-09-16 07:16, Greg KH wrote:
> On Fri, Sep 15, 2023 at 08:16:18PM -0400, Douglas Gilbert wrote:
>> The device in question is this one:
>> Bus 005 Device 015: ID 0483:572b STMicroelectronics STEVAL-USBC2DP Type-C
>> to DisplayPort adapter. It is a USB-C alternate mode device (so tbtadm does
>> not
>> report it).
>>
>> That adapter is connected to a screen (and working) and to a USB-C port on
>> a Lenovo TB3 dock [40AN] which in turn is connected to a Thinkpad X13 Gen3's
>> USB-C port. The Thinkpad is running lk 6.6.0-rc1 with "lsusb (usbutils) 014".
>>
>> The strange thing is that this device is nowhere to be found in the output
>> of "lsusb -t". The lsusb manpage describes the '-t' option as: "Tells
>> lsusb to dump the physical USB device hierarchy as a tree." So is 'physical'
>> a weasel word in this context, or is there a bug in the '-t' option, or is
>> there some other explanation?
>
> A number of 'lsusb -t' issues were fixed in the 015 release of usbutils,
> so maybe update?
>
> that being said, the -t option is a totally different codepath in the
> tool, and shows different things overall. -t shows the drivers that are
> bound to the different interfaces, which means that a single device will
> show up multiple times in the -t option.
>
> Here's the output of the two things on my local laptop, with just a few
> USB devices in it:
>
> $ lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 003: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
> Bus 003 Device 006: ID 0bda:5634 Realtek Semiconductor Corp. Laptop Camera
> Bus 003 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth
> Bus 003 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 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> $ lsusb -t
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
> |__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
> |__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
> |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
> |__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
> |__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
>
> and then if you give the -v option as well you see a bit more:
>
> $ lsusb -tv
> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> ID 1d6b:0003 Linux Foundation 3.0 root hub
> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
> ID 1d6b:0002 Linux Foundation 2.0 root hub
> |__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
> ID 0bda:5634 Realtek Semiconductor Corp.
> |__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
> ID 0bda:5634 Realtek Semiconductor Corp.
> |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
> ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
> |__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
> ID 8087:0032 Intel Corp. AX210 Bluetooth
> |__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
> ID 8087:0032 Intel Corp. AX210 Bluetooth
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
> ID 1d6b:0003 Linux Foundation 3.0 root hub
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
> ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> What are you seeing missing in your output?
lsusb-t.c says:
Copyright (c) 2009 Greg Kroah-Hartman <gregkh@suse.de>
When I tried to contact the author by email off-list with a fair
amount of data (e.g. a copy of /sys from my machine), he claimed
that such an approach was "rude" in the sense that it should have
been sent to this list. Personally I prefer to fix bugs via a
direct email exchange, without the peanut gallery. After all, many
of the bugs found fall into the "brown paper bag" variety.
Plus I felt a bit uncomfortable about publishing the full
contents of /sys from my laptop.
Oh well, each to their own.
Here is a bit more information on this subject:
$ ls /sys/bus/usb/devices
1-0:1.0 3-7:1.1 5-2.1.1.2 5-2.5 6-2.3.4
2-0:1.0 3-7:1.2 5-2.1.1.2:1.0 5-2.5:1.0 6-2.3.4:1.0
3-0:1.0 4-0:1.0 5-2.1.1.2:1.1 6-0:1.0 usb1
3-3 5-0:1.0 5-2.1.1.2:1.2 6-2 usb2
3-3:1.0 5-1 5-2.1.1.2:1.3 6-2.1 usb3
3-4 5-2 5-2.3 6-2:1.0 usb4
3-4:1.0 5-2.1 5-2.3:1.0 6-2.1:1.0 usb5
3-4:1.1 5-2:1.0 5-2.3.4 6-2.1.2 usb6
3-4:1.2 5-2.1.1 5-2.3.4:1.0 6-2.1.2:1.0
3-7 5-2.1:1.0 5-2.3.4.3 6-2.3
3-7:1.0 5-2.1.1:1.0 5-2.3.4.3:2.0 6-2.3:1.0
And the missing device is 5-1 and looks like this:
$ cd /sys/bus/usb/devices/5-1
$ ls_name_value
authorized : 1
avoid_reset_quirk : 0
bcdDevice : 0200
bConfigurationValue : 1
bDeviceClass : 11
bDeviceProtocol : 00
bDeviceSubClass : 00
bmAttributes : c0
bMaxPacketSize0 : 64
bMaxPower : 0mA
bNumConfigurations : 1
bNumInterfaces : 0
busnum : 5
configuration :
descriptors : <contains non-ASCII chars>
dev : 189:526
devnum : 15
devpath : 1
devspec : (null)
idProduct : 572b
idVendor : 0483
ltm_capable : no
manufacturer : STMicroelectronics
maxchild : 0
product : STEVAL-USBC2DP Type-C to DisplayPort adapter
quirks : 0x0
removable : unknown
remove :
rx_lanes : 1
serial : 00000000002B
speed : 12
tx_lanes : 1
uevent : MAJOR=189 MINOR=526 DEVNAME=bus/usb/005/015 DEVTYPE=usb_device
DRIVER=usb PRODUCT=483/572b/200 TYPE=17/0/0 BUSNUM=005 DEVNUM=015
urbnum : 14
version : 2.01
That all looks correct.
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'.
Doug Gilbert
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-06 2:49 ` Douglas Gilbert
@ 2023-10-11 9:30 ` Greg KH
2023-10-11 15:00 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Greg KH @ 2023-10-11 9:30 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: linux-usb
On Thu, Oct 05, 2023 at 10:49:10PM -0400, Douglas Gilbert wrote:
> On 2023-09-16 07:16, Greg KH wrote:
> > On Fri, Sep 15, 2023 at 08:16:18PM -0400, Douglas Gilbert wrote:
> > > The device in question is this one:
> > > Bus 005 Device 015: ID 0483:572b STMicroelectronics STEVAL-USBC2DP Type-C
> > > to DisplayPort adapter. It is a USB-C alternate mode device (so tbtadm does
> > > not
> > > report it).
> > >
> > > That adapter is connected to a screen (and working) and to a USB-C port on
> > > a Lenovo TB3 dock [40AN] which in turn is connected to a Thinkpad X13 Gen3's
> > > USB-C port. The Thinkpad is running lk 6.6.0-rc1 with "lsusb (usbutils) 014".
> > >
> > > The strange thing is that this device is nowhere to be found in the output
> > > of "lsusb -t". The lsusb manpage describes the '-t' option as: "Tells
> > > lsusb to dump the physical USB device hierarchy as a tree." So is 'physical'
> > > a weasel word in this context, or is there a bug in the '-t' option, or is
> > > there some other explanation?
> >
> > A number of 'lsusb -t' issues were fixed in the 015 release of usbutils,
> > so maybe update?
> >
> > that being said, the -t option is a totally different codepath in the
> > tool, and shows different things overall. -t shows the drivers that are
> > bound to the different interfaces, which means that a single device will
> > show up multiple times in the -t option.
> >
> > Here's the output of the two things on my local laptop, with just a few
> > USB devices in it:
> >
> > $ lsusb
> > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > Bus 003 Device 003: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
> > Bus 003 Device 006: ID 0bda:5634 Realtek Semiconductor Corp. Laptop Camera
> > Bus 003 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth
> > Bus 003 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 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
> > $ lsusb -t
> > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
> > |__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
> > |__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
> > |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
> > |__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
> > |__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
> > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
> > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
> >
> > and then if you give the -v option as well you see a bit more:
> >
> > $ lsusb -tv
> > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> > ID 1d6b:0003 Linux Foundation 3.0 root hub
> > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
> > ID 1d6b:0002 Linux Foundation 2.0 root hub
> > |__ Port 7: Dev 6, If 0, Class=Video, Driver=uvcvideo, 480M
> > ID 0bda:5634 Realtek Semiconductor Corp.
> > |__ Port 7: Dev 6, If 1, Class=Video, Driver=uvcvideo, 480M
> > ID 0bda:5634 Realtek Semiconductor Corp.
> > |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M
> > ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
> > |__ Port 10: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
> > ID 8087:0032 Intel Corp. AX210 Bluetooth
> > |__ Port 10: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
> > ID 8087:0032 Intel Corp. AX210 Bluetooth
> > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 20000M/x2
> > ID 1d6b:0003 Linux Foundation 3.0 root hub
> > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
> > ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
> >
> > What are you seeing missing in your output?
>
> lsusb-t.c says:
>
> Copyright (c) 2009 Greg Kroah-Hartman <gregkh@suse.de>
>
> When I tried to contact the author by email off-list with a fair
> amount of data (e.g. a copy of /sys from my machine), he claimed
> that such an approach was "rude" in the sense that it should have
> been sent to this list. Personally I prefer to fix bugs via a
> direct email exchange, without the peanut gallery. After all, many
> of the bugs found fall into the "brown paper bag" variety.
> Plus I felt a bit uncomfortable about publishing the full
> contents of /sys from my laptop.
You don't have to post the full contents of /sys but note that private
emails do not scale well for open source development at all, which is
why it should be done in public for everyone to help.
And anyone working in open source is long used to "brown paper bag"
bugs, it's not an issue for anyone (or should not be, we are all human.)
> Here is a bit more information on this subject:
>
> $ ls /sys/bus/usb/devices
> 1-0:1.0 3-7:1.1 5-2.1.1.2 5-2.5 6-2.3.4
> 2-0:1.0 3-7:1.2 5-2.1.1.2:1.0 5-2.5:1.0 6-2.3.4:1.0
> 3-0:1.0 4-0:1.0 5-2.1.1.2:1.1 6-0:1.0 usb1
> 3-3 5-0:1.0 5-2.1.1.2:1.2 6-2 usb2
> 3-3:1.0 5-1 5-2.1.1.2:1.3 6-2.1 usb3
> 3-4 5-2 5-2.3 6-2:1.0 usb4
> 3-4:1.0 5-2.1 5-2.3:1.0 6-2.1:1.0 usb5
> 3-4:1.1 5-2:1.0 5-2.3.4 6-2.1.2 usb6
> 3-4:1.2 5-2.1.1 5-2.3.4:1.0 6-2.1.2:1.0
> 3-7 5-2.1:1.0 5-2.3.4.3 6-2.3
> 3-7:1.0 5-2.1.1:1.0 5-2.3.4.3:2.0 6-2.3:1.0
>
> And the missing device is 5-1 and looks like this:
> $ cd /sys/bus/usb/devices/5-1
> $ ls_name_value
> authorized : 1
> avoid_reset_quirk : 0
> bcdDevice : 0200
> bConfigurationValue : 1
> bDeviceClass : 11
> bDeviceProtocol : 00
> bDeviceSubClass : 00
> bmAttributes : c0
> bMaxPacketSize0 : 64
> bMaxPower : 0mA
> bNumConfigurations : 1
> bNumInterfaces : 0
> busnum : 5
> configuration :
> descriptors : <contains non-ASCII chars>
> dev : 189:526
> devnum : 15
> devpath : 1
> devspec : (null)
> idProduct : 572b
> idVendor : 0483
> ltm_capable : no
> manufacturer : STMicroelectronics
> maxchild : 0
> product : STEVAL-USBC2DP Type-C to DisplayPort adapter
> quirks : 0x0
> removable : unknown
> remove :
> rx_lanes : 1
> serial : 00000000002B
> speed : 12
> tx_lanes : 1
> uevent : MAJOR=189 MINOR=526 DEVNAME=bus/usb/005/015 DEVTYPE=usb_device
> DRIVER=usb PRODUCT=483/572b/200 TYPE=17/0/0 BUSNUM=005 DEVNUM=015
> urbnum : 14
> version : 2.01
>
> That all looks correct.
>
> 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.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-11 9:30 ` Greg KH
@ 2023-10-11 15:00 ` Alan Stern
2023-10-11 18:51 ` Douglas Gilbert
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2023-10-11 15:00 UTC (permalink / raw)
To: Greg KH; +Cc: Douglas Gilbert, linux-usb
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?
Alan Stern
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-11 15:00 ` Alan Stern
@ 2023-10-11 18:51 ` Douglas Gilbert
2023-10-12 12:50 ` Greg KH
0 siblings, 1 reply; 12+ messages in thread
From: Douglas Gilbert @ 2023-10-11 18:51 UTC (permalink / raw)
To: Alan Stern, Greg KH; +Cc: linux-usb
[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]
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).
Doug Gilbert
[-- Attachment #2: lsusb_t_sysroot.patch --]
[-- Type: text/x-patch, Size: 6279 bytes --]
diff --git a/lsusb-t.c b/lsusb-t.c
index 839321f..3172016 100644
--- a/lsusb-t.c
+++ b/lsusb-t.c
@@ -101,7 +101,11 @@ LIST_HEAD(interfacelist);
LIST_HEAD(usbdevlist);
static struct usbbusnode *usbbuslist;
-static const char sys_bus_usb_devices[] = "/sys/bus/usb/devices";
+#define SBUD_MAX_LEN 128
+
+int max_sbud_len = SBUD_MAX_LEN;
+char sys_bus_usb_devices[SBUD_MAX_LEN] = "/sys/bus/usb/devices";
+
static int indent;
#if 0
@@ -717,6 +721,7 @@ static void print_tree(void)
int lsusb_t(void)
{
+fprintf(stderr, "about to opendir(%s)\n", sys_bus_usb_devices);
DIR *sbud = opendir(sys_bus_usb_devices);
if (sbud) {
walk_usb_devices(sbud);
diff --git a/lsusb.c b/lsusb.c
index 7fa1555..3fbc990 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -3710,6 +3710,7 @@ int main(int argc, char *argv[])
{ "version", 0, 0, 'V' },
{ "verbose", 0, 0, 'v' },
{ "help", 0, 0, 'h' },
+ { "sysfsroot", required_argument, 0, 'S' },
{ "tree", 0, 0, 't' },
{ 0, 0, 0, 0 }
};
@@ -3718,17 +3719,18 @@ int main(int argc, char *argv[])
unsigned int treemode = 0;
int bus = -1, devnum = -1, vendor = -1, product = -1;
const char *devdump = NULL;
+ const char *sysrtp = NULL;
int help = 0;
char *cp;
int status;
setlocale(LC_CTYPE, "");
- while ((c = getopt_long(argc, argv, "D:vtP:p:s:d:Vh",
+ while ((c = getopt_long(argc, argv, "D:vtP:p:s:S:d:Vh",
long_options, NULL)) != EOF) {
switch (c) {
case 'V':
- printf("lsusb (" PACKAGE ") " VERSION "\n");
+ printf("lsusb (" PACKAGE ") " VERSION "++\n");
return EXIT_SUCCESS;
case 'v':
verblevel++;
@@ -3773,6 +3775,10 @@ int main(int argc, char *argv[])
devdump = optarg;
break;
+ case 'S':
+ sysrtp = optarg;
+ break;
+
case '?':
default:
err++;
@@ -3794,6 +3800,9 @@ int main(int argc, char *argv[])
" Selects which device lsusb will examine\n"
" -t, --tree\n"
" Dump the physical USB device hierarchy as a tree\n"
+ " -S <sys_root>, --sysroot=<sys_root>\n"
+ " give alternate root directory for sysfs and devfs "
+ "(def: / )\n"
" -V, --version\n"
" Show version of program\n"
" -h, --help\n"
@@ -3805,6 +3814,23 @@ int main(int argc, char *argv[])
return EXIT_FAILURE;
}
+ if (sysrtp) {
+ if (sysrtp[0] != '/') {
+ fprintf(stderr, "Alternate root for sysfs and devfs "
+ "must start with '/'\n");
+ return EXIT_FAILURE;
+ }
+ if (! set_sysfs_root_name(sysrtp)) {
+ fprintf(stderr, "Failed to set alternate root for "
+ "sysfs, name too long?\n");
+ return EXIT_FAILURE;
+ }
+ if (! set_devfs_root_name(sysrtp)) {
+ fprintf(stderr, "Failed to set alternate root for "
+ "devfs, name too long?\n");
+ return EXIT_FAILURE;
+ }
+ }
/* by default, print names as well as numbers */
if (names_init() < 0)
diff --git a/sysfs.c b/sysfs.c
index e073aa8..46d9ba1 100644
--- a/sysfs.c
+++ b/sysfs.c
@@ -12,19 +12,36 @@
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
+#include <string.h>
#include <linux/limits.h>
#include <libusb.h>
#include "sysfs.h"
+extern int max_sbud_len;
+extern char sys_bus_usb_devices[];
+
/*
* The documentation of libusb_get_port_numbers() says "As per the USB 3.0
* specs, the current maximum limit for the depth is 7."
*/
#define USB_MAX_DEPTH 7
-#define SYSFS_DEV_ATTR_PATH "/sys/bus/usb/devices/%s/%s"
+/* #define SYSFS_DEV_ATTR_PATH "/sys/bus/usb/devices/%s/%s" */
+
+/* static char sysfs_dev_attr_path[196] = "/sys/bus/usb/devices/%s/%s"; */
+
+int /* bool */ set_sysfs_root_name(const char * alternate_root)
+{
+ if ((alternate_root == NULL) ||
+ (strlen(alternate_root) >= (size_t)max_sbud_len))
+ return 0; /* false */
+ snprintf(sys_bus_usb_devices, max_sbud_len, "%s/sys/bus/usb/devices",
+ alternate_root);
+fprintf(stderr, "new sysfs root name: %s\n", sys_bus_usb_devices);
+ return 1; /* true */
+}
int get_sysfs_name(char *buf, size_t size, libusb_device *dev)
{
@@ -56,7 +73,7 @@ int read_sysfs_prop(char *buf, size_t size, char *sysfs_name, char *propname)
char path[PATH_MAX];
buf[0] = '\0';
- snprintf(path, sizeof(path), SYSFS_DEV_ATTR_PATH, sysfs_name, propname);
+ snprintf(path, sizeof(path), "%s/%s/%s", sys_bus_usb_devices, sysfs_name, propname);
fd = open(path, O_RDONLY);
if (fd == -1)
diff --git a/sysfs.h b/sysfs.h
index 63771f5..f7f381b 100644
--- a/sysfs.h
+++ b/sysfs.h
@@ -12,5 +12,7 @@
int get_sysfs_name(char *buf, size_t size, libusb_device *dev);
extern int read_sysfs_prop(char *buf, size_t size, char *sysfs_name, char *propname);
+int /* bool */ set_sysfs_root_name(const char * alternate_root);
+
/* ---------------------------------------------------------------------- */
#endif /* _SYSFS_H */
diff --git a/usbmisc.c b/usbmisc.c
index b12928f..ee776e7 100644
--- a/usbmisc.c
+++ b/usbmisc.c
@@ -25,12 +25,29 @@
#include "usbmisc.h"
+#define DBU_MAX_LEN 256
+
/* ---------------------------------------------------------------------- */
-static const char *devbususb = "/dev/bus/usb";
+/* static const char *devbususb = "/dev/bus/usb"; */
+#define DBU_DEF_PATH "/dev/bus/usb"
+static char devbususb[DBU_MAX_LEN] = DBU_DEF_PATH;
/* ---------------------------------------------------------------------- */
+int /* bool */ set_devfs_root_name(const char * alternate_root)
+{
+ static const size_t dbu_def_path_sz = sizeof(DBU_DEF_PATH);
+ const size_t ar_sz = strlen(alternate_root);
+
+ if (dbu_def_path_sz + ar_sz >= (size_t)DBU_MAX_LEN)
+ return 0; /* false */
+ snprintf(devbususb, ar_sz + dbu_def_path_sz + 1, "%s/dev/bus/usb",
+ alternate_root);
+fprintf(stderr, "new devfs root name: %s\n", devbususb);
+ return 1; /* true */
+}
+
static int readlink_recursive(const char *path, char *buf, size_t bufsize)
{
char temp[PATH_MAX + 1];
diff --git a/usbmisc.h b/usbmisc.h
index 24b27ee..fc06505 100644
--- a/usbmisc.h
+++ b/usbmisc.h
@@ -16,5 +16,7 @@ extern libusb_device *get_usb_device(libusb_context *ctx, const char *path);
extern char *get_dev_string(libusb_device_handle *dev, uint8_t id);
+int /* bool */ set_devfs_root_name(const char * alternate_root);
+
/* ---------------------------------------------------------------------- */
#endif /* _USBMISC_H */
[-- Attachment #3: lsusb_t_sys_dev.tar.xz --]
[-- Type: application/x-xz, Size: 69124 bytes --]
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-11 18:51 ` Douglas Gilbert
@ 2023-10-12 12:50 ` Greg KH
2023-10-12 14:38 ` Douglas Gilbert
0 siblings, 1 reply; 12+ messages in thread
From: Greg KH @ 2023-10-12 12:50 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: Alan Stern, linux-usb
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?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-12 12:50 ` Greg KH
@ 2023-10-12 14:38 ` Douglas Gilbert
2023-10-12 19:10 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Douglas Gilbert @ 2023-10-12 14:38 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-12 14:38 ` Douglas Gilbert
@ 2023-10-12 19:10 ` Alan Stern
2023-10-13 2:12 ` Douglas Gilbert
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2023-10-12 19:10 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: Greg KH, linux-usb
On Thu, Oct 12, 2023 at 10:38:31AM -0400, Douglas Gilbert wrote:
> On 2023-10-12 08:50, Greg KH wrote:
> > 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.
Your dongle is an unusual USB device, in that it has no interfaces.
That's why nothing shows up in the lsusb -t output.
Try applying the patch below.
Alan Stern
lsusb-t.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Index: usbutils-master/lsusb-t.c
===================================================================
--- usbutils-master.orig/lsusb-t.c
+++ usbutils-master/lsusb-t.c
@@ -183,9 +183,12 @@ static void print_usbdevice(struct usbde
char lanes[32];
lanes_to_str(lanes, d->tx_lanes, d->rx_lanes);
- get_class_string(subcls, sizeof(subcls), i->bInterfaceClass);
+ if (i)
+ get_class_string(subcls, sizeof(subcls), i->bInterfaceClass);
- if (i->bInterfaceClass == 9)
+ if (!i)
+ printf("Port %03u: Dev %03u, %sM%s\n", d->portnum, d->devnum, d->speed, lanes);
+ else if (i->bInterfaceClass == 9)
printf("Port %03u: Dev %03u, If %u, Class=%s, Driver=%s/%up, %sM%s\n", d->portnum, d->devnum, i->ifnum, subcls,
i->driver, d->maxchild, d->speed, lanes);
else
@@ -690,11 +693,12 @@ static void sort_busses(void)
static void print_tree_dev_interface(struct usbdevice *d, struct usbinterface *i)
{
indent += 3;
- while (i) {
+ do {
printf(" %*s", indent, "|__ ");
print_usbdevice(d, i);
- i = i->next;
- }
+ if (i)
+ i = i->next;
+ } while (i);
indent -= 3;
}
static void print_tree_dev_children(struct usbdevice *d)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-12 19:10 ` Alan Stern
@ 2023-10-13 2:12 ` Douglas Gilbert
2023-10-13 14:50 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Douglas Gilbert @ 2023-10-13 2:12 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb
On 2023-10-12 15:10, Alan Stern wrote:
> On Thu, Oct 12, 2023 at 10:38:31AM -0400, Douglas Gilbert wrote:
>> On 2023-10-12 08:50, Greg KH wrote:
>>> 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.
>
> Your dongle is an unusual USB device, in that it has no interfaces.
> That's why nothing shows up in the lsusb -t output.
>
> Try applying the patch below.
<snip>
# 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 007, 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 005: Dev 009, 12M
ID 0483:572b STMicroelectronics
|__ 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
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
And there it is: Bus 003. Port 005: Dev 009 !!
Re your "unusual device" comment: welcome to USB-C PD which in a way subverts
"classic" USB.
USB-C port 0 has the ST Micro dongle in it; USB-C port 1 has a PD power adapter:
# lsucpd
port0 [pd0] ====>> partner [pd2]
port1 [pd1] <<==== partner [pd3]
# lsucpd pd2 -c
> pd2: has NO source capabilities
> pd2: sink capabilities:
>> 1:fixed_supply
dual_role_data='0'
dual_role_power='0'
fast_role_swap_current='0'
higher_capability='0'
operational_current='3000mA'
unchunked_extended_messages_supported='0'
unconstrained_power='0'
usb_communication_capable='0'
^^^^^^^^^^^^^
voltage='5000mV'
So port 0's partner says it does _not_ support USB data communications! I
think that means that if anything moves along D+, D-, and the Tx plus Rx
SuperSpeed circuits then it does _not_ follow the USB specs. Further USB PD
potentially sets up alternate modes:
# lsucpd -ll p0p
port0 [pd0] ====>> partner [pd2]
port0-partner [pd2]:
accessory_mode='none'
number_of_alternate_modes='1'
supports_usb_power_delivery='yes'
usb_power_delivery_revision='0.0'
Alternate mode: /sys/class/typec/port0-partner/port0-partner.0
active='yes'
description='DisplayPort'
mode='1'
svid='ff01'
vdo='0x00001085'
So you could argue the 'lsusb -t' should not list this USB-C DP dongle.
IMO a stronger argument is that lsusb and 'lsusb -t' should list the
same devices.
If you submit a patch you can add my "tested-by" to it. Another (little)
bug fixed.
Thanks
Doug Gilbert
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-13 2:12 ` Douglas Gilbert
@ 2023-10-13 14:50 ` Alan Stern
2023-10-13 21:44 ` Douglas Gilbert
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2023-10-13 14:50 UTC (permalink / raw)
To: Douglas Gilbert; +Cc: Greg KH, linux-usb
On Thu, Oct 12, 2023 at 10:12:42PM -0400, Douglas Gilbert wrote:
> # 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 007, 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 005: Dev 009, 12M
> ID 0483:572b STMicroelectronics
> |__ 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
> /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> ID 1d6b:0003 Linux Foundation 3.0 root hub
>
>
> And there it is: Bus 003. Port 005: Dev 009 !!
Not much of an entry, but better than nothing. :-)
> Re your "unusual device" comment: welcome to USB-C PD which in a way subverts
> "classic" USB.
Well, it's not really a subversion. Just using it in a way it wasn't
intended to be used, while still remaining in compliance with the spec.
> USB-C port 0 has the ST Micro dongle in it; USB-C port 1 has a PD power adapter:
>
> # lsucpd
> port0 [pd0] ====>> partner [pd2]
> port1 [pd1] <<==== partner [pd3]
>
> # lsucpd pd2 -c
> > pd2: has NO source capabilities
> > pd2: sink capabilities:
> >> 1:fixed_supply
> dual_role_data='0'
> dual_role_power='0'
> fast_role_swap_current='0'
> higher_capability='0'
> operational_current='3000mA'
> unchunked_extended_messages_supported='0'
> unconstrained_power='0'
> usb_communication_capable='0'
> ^^^^^^^^^^^^^
> voltage='5000mV'
>
> So port 0's partner says it does _not_ support USB data communications! I
> think that means that if anything moves along D+, D-, and the Tx plus Rx
> SuperSpeed circuits then it does _not_ follow the USB specs.
Not quite; if that were true then nothing would have shown up in any of
the lsusb outputs, with or without -t and with or without my patch. The
dongle transfers enough data to be initialized and enumerated.
> Further USB PD
> potentially sets up alternate modes:
>
> # lsucpd -ll p0p
> port0 [pd0] ====>> partner [pd2]
> port0-partner [pd2]:
> accessory_mode='none'
> number_of_alternate_modes='1'
> supports_usb_power_delivery='yes'
> usb_power_delivery_revision='0.0'
> Alternate mode: /sys/class/typec/port0-partner/port0-partner.0
> active='yes'
> description='DisplayPort'
> mode='1'
> svid='ff01'
> vdo='0x00001085'
>
> So you could argue the 'lsusb -t' should not list this USB-C DP dongle.
> IMO a stronger argument is that lsusb and 'lsusb -t' should list the
> same devices.
>
> If you submit a patch you can add my "tested-by" to it. Another (little)
> bug fixed.
Thank you; I will.
Alan Stern
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: device present in lsusb, disappears in lsusb -t
2023-10-13 14:50 ` Alan Stern
@ 2023-10-13 21:44 ` Douglas Gilbert
0 siblings, 0 replies; 12+ messages in thread
From: Douglas Gilbert @ 2023-10-13 21:44 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, linux-usb
On 10/13/23 10:50, Alan Stern wrote:
> On Thu, Oct 12, 2023 at 10:12:42PM -0400, Douglas Gilbert wrote:
>> # 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 007, 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 005: Dev 009, 12M
>> ID 0483:572b STMicroelectronics
>> |__ 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
>> /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
>> ID 1d6b:0003 Linux Foundation 3.0 root hub
>>
>>
>> And there it is: Bus 003. Port 005: Dev 009 !!
>
> Not much of an entry, but better than nothing. :-)
>
>> Re your "unusual device" comment: welcome to USB-C PD which in a way subverts
>> "classic" USB.
>
> Well, it's not really a subversion. Just using it in a way it wasn't
> intended to be used, while still remaining in compliance with the spec.
>
>> USB-C port 0 has the ST Micro dongle in it; USB-C port 1 has a PD power adapter:
>>
>> # lsucpd
>> port0 [pd0] ====>> partner [pd2]
>> port1 [pd1] <<==== partner [pd3]
>>
>> # lsucpd pd2 -c
>>> pd2: has NO source capabilities
>>> pd2: sink capabilities:
>> >> 1:fixed_supply
>> dual_role_data='0'
>> dual_role_power='0'
>> fast_role_swap_current='0'
>> higher_capability='0'
>> operational_current='3000mA'
>> unchunked_extended_messages_supported='0'
>> unconstrained_power='0'
>> usb_communication_capable='0'
>> ^^^^^^^^^^^^^
>> voltage='5000mV'
>>
>> So port 0's partner says it does _not_ support USB data communications! I
>> think that means that if anything moves along D+, D-, and the Tx plus Rx
>> SuperSpeed circuits then it does _not_ follow the USB specs.
>
> Not quite; if that were true then nothing would have shown up in any of
> the lsusb outputs, with or without -t and with or without my patch. The
> dongle transfers enough data to be initialized and enumerated. of
So then there might be two varieties of "usb_communications_capable=0" *** :
those that send enough along D+ and D- to be enumerated; and those that don't
have D+ and D- pins! Many USB PD power adapters are any that second variety.
And it is not the worst idea to have a USB-C M-M cable that is Emarked (so
it can carry up to 5 Amps) and does _not_ connect D+, D- and the SuperSpeed
signals). And this is the cable to use when recharging your USB-C devices
from a public source ...
Doug Gilbert
*** I prefer the snake case variant of "usb_communications_capable" because that
is the term used by the PD specs, not "usb_communication_capable" .
>> Further USB PD
>> potentially sets up alternate modes:
>>
>> # lsucpd -ll p0p
>> port0 [pd0] ====>> partner [pd2]
>> port0-partner [pd2]:
>> accessory_mode='none'
>> number_of_alternate_modes='1'
>> supports_usb_power_delivery='yes'
>> usb_power_delivery_revision='0.0'
>> Alternate mode: /sys/class/typec/port0-partner/port0-partner.0
>> active='yes'
>> description='DisplayPort'
>> mode='1'
>> svid='ff01'
>> vdo='0x00001085'
>>
>> So you could argue the 'lsusb -t' should not list this USB-C DP dongle.
>> IMO a stronger argument is that lsusb and 'lsusb -t' should list the
>> same devices.
>>
>> If you submit a patch you can add my "tested-by" to it. Another (little)
>> bug fixed.
>
> Thank you; I will.
>
> Alan Stern
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-10-13 21:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-16 0:16 device present in lsusb, disappears in lsusb -t Douglas Gilbert
2023-09-16 11:16 ` Greg KH
2023-10-06 2:49 ` Douglas Gilbert
2023-10-11 9:30 ` Greg KH
2023-10-11 15:00 ` Alan Stern
2023-10-11 18:51 ` Douglas Gilbert
2023-10-12 12:50 ` Greg KH
2023-10-12 14:38 ` Douglas Gilbert
2023-10-12 19:10 ` Alan Stern
2023-10-13 2:12 ` Douglas Gilbert
2023-10-13 14:50 ` Alan Stern
2023-10-13 21:44 ` Douglas Gilbert
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.