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

[Douglas Gilbert <dgilbert@xxxxxxxxxxxx>]

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