From: Greg KH <gregkh@linuxfoundation.org>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: device present in lsusb, disappears in lsusb -t
Date: Thu, 12 Oct 2023 14:50:35 +0200 [thread overview]
Message-ID: <2023101203-marine-chatter-692e@gregkh> (raw)
In-Reply-To: <0c2a2a23-28dd-4c83-b7af-d5421501e411@interlog.com>
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
next prev parent reply other threads:[~2023-10-12 12:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023101203-marine-chatter-692e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dgilbert@interlog.com \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox