[Toybox] [PATCH] lspci: add -x.

Thu Apr 6 10:00:18 PDT 2023

On Thu, Apr 6, 2023 at 9:46 AM Rob Landley <rob at landley.net> wrote:

> On 4/5/23 16:30, enh via Toybox wrote:
> > I caught someone using pciutils lspci, asked why, and -x (including
> > -xxx) and -v (specifically -vvv) were the reasons. I took a quick look,
> > and -x in particular seemed easy
>
> Sigh, -v is gonna be fun. (I think I have some todo notes on it somewhere?)
>
> Another difference is debian's lspci sorts the output entries, and toybox
> is
> spitting them out in the order the OS returns them. (Given that "sorting"
> is
> what I used DIRTREE_BREADTH for last time, I suspect
> populate-sort-traverse is a
> missing lib/dirtree.c function I need to design. Possibly a new
> DIRTREE_SORTED
> flag...)
>
> > (modulo the TODO I've left in the code).
>
> Specifically:
>
> +    // TODO: where does the "0000:" come from?
> +    snprintf(toybuf, sizeof(toybuf),
> "/sys/bus/pci/devices/0000:%s/config",
>
> Let's see, linux Documentation/filesystems/sysfs.rst does not contain the
> string
> "pci", so search for "bus" and
>
> bus/ contains flat directory layout of the various bus types in the
> kernel. Each bus's directory contains two subdirectories::
>
>         devices/
>         drivers/
>
> Followed by, I kid you not, "TODO: Finish this section." When was that...
>
> 929f6378df7d0   (Patrick Mochel 2003-01-10 04:45:58 -0600       332)TODO:
> Finish
> this section.
>
> Just over twenty years ago. Well of course. (Remember how I said the
> linux-kernel development community has been contracting as it continually
> raises
> the barrier not just to entry but to continued participation? Yeah, that.)
>
> Ok, switching over to looking at the source code, find . -name pci,
> drivers/pci
> looks likely, grep '"bus' * finds proc.c, and grep '[:]' proc.c to see who
> is
> printing out a colon finds:
>
>                         sprintf(name, "%04x:%02x", pci_domain_nr(bus),
>                                         bus->number);
>
> on line 416, and THAT is in include/linux/pci.h where it's always 0 unless
> you've enabled CONFIG_PCI_DOMAINS, and THAT config symbol lives in
> drivers/pci/Kconfig where it DOES NOT HAVE ANY HELP TEXT. Because of
> course not.
>
> Here's the patch that added it, which ALSO doesn't say what it is:
>
> https://lwn.net/Articles/35497/
>
> Right, Jonathan Corbet wrote a book, which explains what Linux thinks PCI
> Domains are:
>
>
> https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch12.html#:~:text=domains
>
> Apparently they came up with their own name for PCI segments for some
> reason,
> and despite claiming that "modern workstations" now have two of them, the
> book
> does not actually have an example with a domain number other than zero.
>
> > I notice that half the pci devices on my machine are missing from the
> > toybox lspci output versus the pciutils lspci --- it looks like
> > scan_uevent() is returning 2 for the bridges?
>
> The downside of doing this kind of plumbing is the need for test hardware
> to try
> it on to experience the full range of weird crap different drivers are
> emitting. :(
>
> If scan_uevent returning 2 means the relevant uevent file had only two of
> "DRIVER=", "PCI_CLASS=%x" and "PCI_ID=%x:%x", which I'm not seeing here?
>
> $ egrep -Hc '(DRIVER|PCI_CLASS|PCI_ID)=' /sys/bus/pci/devices/*/uevent
> /sys/bus/pci/devices/0000:00:00.0/uevent:3
> /sys/bus/pci/devices/0000:00:02.0/uevent:3
> /sys/bus/pci/devices/0000:00:14.0/uevent:3
> /sys/bus/pci/devices/0000:00:16.0/uevent:3
> /sys/bus/pci/devices/0000:00:19.0/uevent:3
> /sys/bus/pci/devices/0000:00:1a.0/uevent:3
> /sys/bus/pci/devices/0000:00:1b.0/uevent:3
> /sys/bus/pci/devices/0000:00:1c.0/uevent:3
> /sys/bus/pci/devices/0000:00:1c.1/uevent:3
> /sys/bus/pci/devices/0000:00:1c.2/uevent:3
> /sys/bus/pci/devices/0000:00:1c.3/uevent:3
> /sys/bus/pci/devices/0000:00:1c.5/uevent:3
> /sys/bus/pci/devices/0000:00:1d.0/uevent:3
> /sys/bus/pci/devices/0000:00:1f.0/uevent:3
> /sys/bus/pci/devices/0000:00:1f.2/uevent:3
> /sys/bus/pci/devices/0000:00:1f.3/uevent:3
> /sys/bus/pci/devices/0000:02:00.0/uevent:3
> /sys/bus/pci/devices/0000:0b:00.0/uevent:3
>

yeah, sorry, i hadn't had time to look any further to see _what_ was
missing. changing one character in your grep is easy though...

...looks like pci bridges don't have a driver?

$ egrep -H '(DRIVER|PCI_CLASS|PCI_ID)=' /sys/bus/pci/devices/*/uevent
/sys/bus/pci/devices/0000:00:00.0/uevent:PCI_CLASS=60000
/sys/bus/pci/devices/0000:00:00.0/uevent:PCI_ID=8086:1237
/sys/bus/pci/devices/0000:00:01.0/uevent:PCI_CLASS=60100
/sys/bus/pci/devices/0000:00:01.0/uevent:PCI_ID=8086:7110
/sys/bus/pci/devices/0000:00:01.3/uevent:PCI_CLASS=68000
/sys/bus/pci/devices/0000:00:01.3/uevent:PCI_ID=8086:7113
/sys/bus/pci/devices/0000:00:03.0/uevent:DRIVER=virtio-pci
/sys/bus/pci/devices/0000:00:03.0/uevent:PCI_CLASS=0000
/sys/bus/pci/devices/0000:00:03.0/uevent:PCI_ID=1AF4:1004
/sys/bus/pci/devices/0000:00:04.0/uevent:DRIVER=virtio-pci
/sys/bus/pci/devices/0000:00:04.0/uevent:PCI_CLASS=20000
/sys/bus/pci/devices/0000:00:04.0/uevent:PCI_ID=1AF4:1000
/sys/bus/pci/devices/0000:00:05.0/uevent:DRIVER=virtio-pci
/sys/bus/pci/devices/0000:00:05.0/uevent:PCI_CLASS=FF00
/sys/bus/pci/devices/0000:00:05.0/uevent:PCI_ID=1AF4:1005
$

> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230406/92519318/attachment.htm>