PCI_CONF_READ(9)

πŸ“¦ in nixpkgs unstable

okay so bestie, welcome to PCI_CONF_READ(9) from the Kernel Developer’s Manual β€” we’re talking PCI config space manipulation, and it’s giving β€œtiny functions, big kernel energy” βœ¨πŸ’…

πŸ’– NAME πŸ’–

pci_make_tag, pci_decompose_tag, pci_conf_read, pci_conf_write β€” PCI config space manipulation functions πŸŽ€

✨ SYNOPSIS ✨

#include <alpha/pci/pci_machdep.h>
#include <i386/pci/pci_machdep.h>
#include <machine/pci_machdep.h>

pcitag_t
pci_make_tag(pci_chipset_tag_t pc, int bus, int dev, int func);

void
pci_decompose_tag(pci_chipset_tag_t pc, pcitag_t tag, int *busp,
    int *devp, int *funcp);

pcireg_t
pci_conf_read(pci_chipset_tag_t pc, pcitag_t tag, int reg);

void
pci_conf_write(pci_chipset_tag_t pc, pcitag_t tag, int reg,
    pcireg_t val);

πŸ¦‹ DESCRIPTION πŸ¦‹

These functions are your little backstage pass to PCI configuration space πŸ”₯ They let you make tags, take tags apart, and read or write config space registers. iconic behavior, honestly.

πŸŽ€ the types, bestie πŸŽ€

The following types are defined in the machine dependent include file <pci_machdep.h>:

  • pci_chipset_tag_t β€” a PCI chipset descriptor
  • pcitag_t β€” a PCI device tag
  • pcireg_t β€” a PCI register datum

🌸 how the tag situation works 🌸

So to access PCI configuration space, you first make a device tag with pci_make_tag, giving it the PCI chipset tag pc and the device spec as a tuple of bus, dev, func. The PCI tag composition is a PCI chipset dependent operation, although it’s often as simple as a shift and logical OR combination. slay for simple bit math πŸ’…

pci_decompose_tag does the reverse operation. Once a tag is composed, you can do config space reads and writes with pci_conf_read and pci_conf_write, respectively. Access to PCI configuration space is only provided for whole pcireg_t items, which is usually a 32-bit integer. no sneaky partial reads, bestie 😭

Access to non-existent PCI devices do not (or should not) generate any kinds of faults or interruptions, and thus allow for easy device scanning by cycling through all possible device and function numbers for a given bus. that’s the vibe check that makes scanning work πŸ¦‹

πŸ”₯ config space registers, for the girlies who like offsets πŸ”₯

Below is an overview of defined PCI configuration space registers for devices:

  • 0x00 β€” Vendor (lower word) and Product (higher word) identification (see /sys/dev/pci/pcidevs for a comprehensive list).
  • 0x04 β€” Commands and Status register.
  • 0x08 β€” PCI device’s class and subclass IDs. See /sys/dev/pci/pcireg.h for PCI_CLASS_* and PCI_SUBCLASS_* definitions.
  • 0x0c β€” Specify (low byte to high): cache line size, PCI latency timer, header type, and BIST.
  • 0x10 - 0x28 β€” Base address registers for I/O and memory space mapped registers.
  • 0x28 β€” CardBus CIS register.
  • 0x2c β€” Similar to 0x00 register’s definitions for a subsystem identification.
  • 0x34 β€” A pointer to the capabilities list. Each item is an offset in the configuration space itself.
  • 0x3c β€” Interrupt line and pin numbers.

πŸ‘‘ SEE ALSO πŸ‘‘

cardbus(4), pci(4), pci_intr_map(9) 🌈

πŸ’€ HISTORY πŸ’€

These functions first appeared in OpenBSD 1.2. vintage but still main character energy πŸ‘‘


πŸ’Œ and that’s the whole page, bestie β€” brought to you by Debian, dated November 13, 2024, under the manual name PCI_CONF_READ(9). byeee πŸ«ΆπŸŽ€

πŸ“¦ where this page comes from