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