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
