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

[Rob Landley]

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

Rob