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

[Douglas Gilbert <dgilbert@interlog.com>]

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