PCI(9)

🦋 PCI(9) — the PCI bus interface 🦋

okay so this is PCI(9) from the Kernel Developer's Manual, and bestie it is A LOT — it's the whole PCI function squad. Lowkey the biggest glow-up in kernel land. Let's get into it 💅

---

💖 NAME 💖

pci, pci_alloc_msi, pci_alloc_msix, pci_clear_pme, pci_disable_busmaster, pci_disable_io, pci_enable_busmaster, pci_enable_io, pci_enable_pme, pci_find_bsf, pci_find_cap, pci_find_dbsf, pci_find_device, pci_find_extcap, pci_find_htcap, pci_find_next_cap, pci_find_next_extcap, pci_find_next_htcap, pci_find_pcie_root_port, pci_get_id, pci_get_max_payload, pci_get_max_read_req, pci_get_powerstate, pci_get_vpd_ident, pci_get_vpd_readonly, pci_has_pm, pci_iov_attach, pci_iov_attach_name, pci_iov_detach, pci_msi_count, pci_msix_count, pci_msix_pba_bar, pci_msix_table_bar, pci_pending_msix, pci_read_config, pci_release_msi, pci_remap_msix, pci_restore_state, pci_save_state, pci_set_max_read_req, pci_set_powerstate, pci_write_config, pcie_adjust_config, pcie_flr, pcie_get_max_completion_timeout, pcie_read_config, pcie_wait_for_pending_transactions, pcie_write_config — the whole crew, one page, all of them serving the PCI bus interface. periodt 🌈

---

✨ SYNOPSIS ✨

like, the whole cast list with their exact signatures — no cap, copy these character for character:

#include <sys/bus.h>
#include <dev/pci/pcireg.h>
#include <dev/pci/pcivar.h>

int
pci_alloc_msi(device_t dev, int *count);

int
pci_alloc_msix(device_t dev, int *count);

void
pci_clear_pme(device_t dev);

int
pci_disable_busmaster(device_t dev);

int
pci_disable_io(device_t dev, int space);

int
pci_enable_busmaster(device_t dev);

int
pci_enable_io(device_t dev, int space);

void
pci_enable_pme(device_t dev);

device_t
pci_find_bsf(uint8_t bus, uint8_t slot, uint8_t func);

int
pci_find_cap(device_t dev, int capability, int *capreg);

device_t
pci_find_dbsf(uint32_t domain, uint8_t bus, uint8_t slot, uint8_t func);

device_t
pci_find_device(uint16_t vendor, uint16_t device);

int
pci_find_extcap(device_t dev, int capability, int *capreg);

int
pci_find_htcap(device_t dev, int capability, int *capreg);

int
pci_find_next_cap(device_t dev, int capability, int start, int *capreg);

int
pci_find_next_extcap(device_t dev, int capability, int start,
    int *capreg);

int
pci_find_next_htcap(device_t dev, int capability, int start,
    int *capreg);

device_t
pci_find_pcie_root_port(device_t dev);

int
pci_get_id(device_t dev, enum pci_id_type type, uintptr_t *id);

int
pci_get_max_payload(device_t dev);

int
pci_get_max_read_req(device_t dev);

int
pci_get_powerstate(device_t dev);

int
pci_get_vpd_ident(device_t dev, const char **identptr);

int
pci_get_vpd_readonly(device_t dev, const char *kw, const char **vptr);

bool
pci_has_pm(device_t dev);

int
pci_msi_count(device_t dev);

int
pci_msix_count(device_t dev);

int
pci_msix_pba_bar(device_t dev);

int
pci_msix_table_bar(device_t dev);

int
pci_pending_msix(device_t dev, u_int index);

uint32_t
pci_read_config(device_t dev, int reg, int width);

int
pci_release_msi(device_t dev);

int
pci_remap_msix(device_t dev, int count, const u_int *vectors);

void
pci_restore_state(device_t dev);

void
pci_save_state(device_t dev);

int
pci_set_max_read_req(device_t dev, int size);

int
pci_set_powerstate(device_t dev, int state);

void
pci_write_config(device_t dev, int reg, uint32_t val, int width);

uint32_t
pcie_adjust_config(device_t dev, int reg, uint32_t mask, uint32_t val,
    int width);

bool
pcie_flr(device_t dev, u_int max_delay, bool force);

int
pcie_get_max_completion_timeout(device_t dev);

uint32_t
pcie_read_config(device_t dev, int reg, int width);

bool
pcie_wait_for_pending_transactions(device_t dev, u_int max_delay);

void
pcie_write_config(device_t dev, int reg, uint32_t val, int width);

and then there's the event-handler + SR-IOV corner of the fam, which brings its own include 💜

void
pci_event_fn(void *arg, device_t dev);

EVENTHANDLER_REGISTER(pci_add_device, pci_event_fn);

EVENTHANDLER_DEREGISTER(pci_delete_resource, pci_event_fn);

#include <dev/pci/pci_iov.h>

int
pci_iov_attach(device_t dev, nvlist_t *pf_schema, nvlist_t *vf_schema);

int
pci_iov_attach_name(device_t dev, nvlist_t *pf_schema,
    nvlist_t *vf_schema, const char *fmt, ...);

int
pci_iov_detach(device_t dev);

---

💅 DESCRIPTION 💅

so the pci set of functions is what you use for managing PCI devices. iconic behaviour. they're split into several groups, and honestly the friend-group chat has five separate channels:

• raw configuration access
• locating devices
• device information
• device configuration
• message signaled interrupts

we're covering the first three in this part, so let's GO 🎀

🎀 Raw Configuration Access 🎀

pci_read_config() — reads data from the PCI configuration space of the device dev, at offset reg, with width specifying the size of the access. it's giving "just peek at the register real quick" 🔍

pci_write_config() — writes the value val to the PCI configuration space of the device dev, at offset reg, with width specifying the size of the access. this one's the "ok now we change it" one ✍️

pcie_adjust_config() — modifies the value of a register in the PCI-express capability register set of device dev. the offset reg specifies a relative offset in the register set, with width specifying the size of the access. the new value of the register is computed by modifying the bits set in mask to the value in val. any bits not specified in mask are preserved. and it returns the previous value of the register, so you literally always know what you changed. read-modify-write but make it cute 💫

pcie_read_config() — reads the value of a register in the PCI-express capability register set of device dev. offset reg is a relative offset in the register set, width is the size of the access 🌸

pcie_write_config() — writes the value val to a register in the PCI-express capability register set of device dev. offset reg is a relative offset in the register set, width is the size of the access ✨

NOTE: device drivers should only use these functions for functionality that is not available via another pci() function. like, don't be that driver. use the nice helper if the nice helper exists 🙈

🔎 Locating Devices 🔎

pci_find_bsf() — looks up the device_t of a PCI device, given its bus, slot, and func. heads up: the slot number actually refers to the number of the device on the bus, which does not necessarily indicate its geographic location in terms of a physical slot. (yes that naming choice is chaotic, we don't talk about it 💀) also, if the system has multiple PCI domains, pci_find_bsf() only searches the first one. actually it's equivalent to this exactly:

pci_find_dbsf(0, bus, slot, func);

pci_find_dbsf() — looks up the device_t of a PCI device, given its domain, bus, slot, and func. same deal on slot: it refers to the number of the device on the bus, not necessarily its geographic location in terms of a physical slot 🦋

pci_find_device() — looks up the device_t of a PCI device, given its vendor and device IDs. important: there can be multiple matches for this search, and this function only returns the first matching device. so fr fr, don't assume it's the only one 👑

🌟 Device Information 🌟

pci_find_cap() — locates the first instance of a PCI capability register set for the device dev. the capability to locate is specified by ID via capability. constant macros of the form PCIY_xxx for standard capability IDs are defined in <dev/pci/pcireg.h>. if the capability is found, then *capreg is set to the offset in configuration space of the capability register set, and pci_find_cap() returns zero. if the capability is not found, or the device doesn't support capabilities, pci_find_cap() returns an error. slay when it works, error when it doesn't 💅

pci_find_next_cap() — locates the next instance of a PCI capability register set for the device dev. start should be the *capreg returned by a prior pci_find_cap() or pci_find_next_cap(). when no more instances are located, pci_find_next_cap() returns an error. it's the "keep scrolling" of capabilities 😌

pci_has_pm() — returns true if dev supports power management ⚡

pci_find_extcap() — locates the first instance of a PCI-express extended capability register set for the device dev. the extended capability to locate is specified by ID via capability. constant macros of the form PCIZ_xxx for standard extended capability IDs are defined in <dev/pci/pcireg.h>. if the extended capability is found, then *capreg is set to the offset in configuration space of the extended capability register set, and pci_find_extcap() returns zero. if the extended capability is not found, or the device is not a PCI-express device, pci_find_extcap() returns an error 🌸

pci_find_next_extcap() — locates the next instance of a PCI-express extended capability register set for the device dev. start should be the *capreg returned by a prior pci_find_extcap() or pci_find_next_extcap(). when no more instances are located, pci_find_next_extcap() returns an error 🧚

pci_find_htcap() — locates the first instance of a HyperTransport capability register set for the device dev. the capability to locate is specified by type via capability. constant macros of the form PCIM_HTCAP_xxx for standard HyperTransport capability types are defined in <dev/pci/pcireg.h>. if the capability is found, then *capreg is set to the offset in configuration space of the capability register set, and pci_find_htcap() returns zero. if the capability is not found, or the device is not a HyperTransport device, pci_find_htcap() returns an error 💜

pci_find_next_htcap() — locates the next instance of a HyperTransport capability register set for the device dev. start should be the *capreg returned by a prior pci_find_htcap() or pci_find_next_htcap(). when no more instances are located, pci_find_next_htcap() returns an error 🌈

pci_find_pcie_root_port() — walks up the PCI device hierarchy to locate the PCI-express root port upstream of dev. if a root port is not found, pci_find_pcie_root_port() returns NULL. it's literally climbing the family tree to find the main character 👑

pci_get_id() — reads an identifier from a device. the type flag specifies which identifier to read. these are the supported flags:

• PCI_ID_RID — read the routing identifier for the device.
• PCI_ID_MSI — read the MSI routing ID. some interrupt controllers need this to route MSI and MSI-X interrupts.

pci_get_vpd_ident() — fetches a device's Vital Product Data (VPD) identifier string. if the device dev supports VPD and provides an identifier string, then *identptr is set to point at a read-only, null-terminated copy of the identifier string, and pci_get_vpd_ident() returns zero. if the device doesn't support VPD, or doesn't provide an identifier string, then pci_get_vpd_ident() returns an error. read-only bestie, do NOT touch 🫶

---

ok and that's the device info channel wrapped — next up we've got device configuration and message signaled interrupts, and trust, there is so much more where this came from 💖

The pci_get_vpd_readonly() function is your VPD read-only keyword hookup for the device dev. You tell it which keyword via the two character string kw — yes, exactly two characters, bestie. If the device supports VPD and actually has a read-only value for that keyword, then *vptr gets pointed at a read-only, null-terminated copy of the value, and pci_get_vpd_readonly() returns zero. If the device doesn’t support VPD or doesn’t provide the requested keyword, then pci_get_vpd_readonly() returns an error. No value, no vibes.

The pcie_get_max_completion_timeout() function returns the maximum completion timeout configured for the device dev in microseconds. If dev is not a PCI-express device, pcie_get_max_completion_timeout() returns zero. And when completion timeouts are disabled for dev, this function returns the maximum timeout that would be used if timeouts were enabled. Cute, right?

The pcie_wait_for_pending_transactions() function waits for any pending transactions initiated by the device dev to complete. It checks for pending transactions by polling the transactions pending flag in the PCI-express device status register. It returns true once the transaction pending flag is clear. If transactions are still pending after max_delay milliseconds, pcie_wait_for_pending_transactions() returns false. If max_delay is set to zero, pcie_wait_for_pending_transactions() performs a single check; otherwise, this function may sleep while polling the transactions pending flag. And pcie_wait_for_pending_transactions returns true if dev is not a PCI-express device. Slay, but keep that exact spelling — no extra parens.

🛠️ Device Configuration 🛠️

The pci_enable_busmaster() function enables PCI bus mastering for the device dev, by setting the PCIM_CMD_BUSMASTEREN bit in the PCIR_COMMAND register. The pci_disable_busmaster() function clears this bit.

The pci_enable_io() function enables memory or I/O port address decoding for the device dev, by setting the PCIM_CMD_MEMEN or PCIM_CMD_PORTEN bit in the PCIR_COMMAND register appropriately. The pci_disable_io() function clears the appropriate bit. The space argument specifies which resource is affected; this can be either SYS_RES_MEMORY or SYS_RES_IOPORT as appropriate. Device drivers should generally not use these routines directly. The PCI bus will enable decoding automatically when a SYS_RES_MEMORY or SYS_RES_IOPORT resource is activated via bus_alloc_resource(9) or bus_activate_resource(9).

The pci_get_max_payload() function returns the current maximum TLP payload size in bytes for a PCI-express device. If the dev device is not a PCI-express device, pci_get_max_payload() returns zero.

The pci_get_max_read_req() function returns the current maximum read request size in bytes for a PCI-express device. If the dev device is not a PCI-express device, pci_get_max_read_req() returns zero.

The pci_set_max_read_req() sets the PCI-express maximum read request size for dev. The requested size may be adjusted, and pci_set_max_read_req() returns the actual size set in bytes. If the dev device is not a PCI-express device, pci_set_max_read_req() returns zero.

The pci_get_powerstate() function returns the current power state of the device dev. If the device does not support power management capabilities, then the default state of PCI_POWERSTATE_D0 is returned. The following power states are defined by PCI:

• PCI_POWERSTATE_D0 — State in which device is on and running. It is receiving full power from the system and delivering full functionality to the user.
• PCI_POWERSTATE_D1 — Class-specific low-power state in which device context may or may not be lost. Buses in this state cannot do anything to the bus, to force devices to lose context.
• PCI_POWERSTATE_D2 — Class-specific low-power state in which device context may or may not be lost. Attains greater power savings than PCI_POWERSTATE_D1. Buses in this state can cause devices to lose some context. Devices must be prepared for the bus to be in this state or higher.
• PCI_POWERSTATE_D3_HOT — State in which the device is off and not running. Device context is lost, and power from the device can be (but is not necessarily) removed.
• PCI_POWERSTATE_D3_COLD — Same as PCI_POWERSTATE_D3_HOT, except power has been removed from the device.
• PCI_POWERSTATE_UNKNOWN — State of the device is unknown.

The pci_set_powerstate() function is used to transition the device dev to the PCI power state state. If the device does not support power management capabilities or it does not support the specific power state state, then the function will fail with EOPNOTSUPP. That’s a hard fail, bestie — not a gentle nudge.

The pci_clear_pme() function is used to clear any pending PME# signal and disable generation of power management events.

The pci_enable_pme() function is used to enable generation of power management events before suspending a device.

The pci_iov_attach() function is used to advertise that the given device (and associated device driver) supports PCI Single-Root I/O Virtualization (SR-IOV). A driver that supports SR-IOV must implement the PCI_IOV_INIT(9), PCI_IOV_ADD_VF(9) and PCI_IOV_UNINIT(9) methods. This function should be called during the DEVICE_ATTACH(9) method. If this function returns an error, it is recommended that the device driver still successfully attaches, but runs with SR-IOV disabled. The pf_schema and vf_schema parameters are used to define what device-specific configuration parameters the device driver accepts when SR-IOV is enabled for the Physical Function (PF) and for individual Virtual Functions (VFs) respectively. See pci_iov_schema(9) for details on how to construct the schema. If either the pf_schema or vf_schema is invalid or specifies parameter names that conflict with parameter names that are already in use, pci_iov_attach() will return an error and SR-IOV will not be available on the PF device. If a driver does not accept configuration parameters for either the PF device or the VF devices, the driver must pass an empty schema for that device. The SR-IOV infrastructure takes ownership of the pf_schema and vf_schema and is responsible for freeing them. The driver must never free the schemas itself.

The pci_iov_attach_name() function is a variant of pci_iov_attach() that allows the name of the associated character device in /dev/iov to be specified by fmt. The pci_iov_attach() function uses the name of dev as the device name.

The pci_iov_detach() function is used to advise the SR-IOV infrastructure that the driver for the given device is attempting to detach and that all SR-IOV resources for the device must be released. This function must be called during the DEVICE_DETACH(9) method if pci_iov_attach() was successfully called on the device and pci_iov_detach() has not subsequently been called on the device and returned no error. If this function returns an error, the DEVICE_DETACH(9) method must fail and return an error, as detaching the PF driver while VF devices are active would cause system instability. Like, actual instability. Do not ignore this. This function is safe to call and will always succeed if pci_iov_attach() previously failed with an error on the given device, or if pci_iov_attach() was never called on the device.

The pci_save_state() and pci_restore_state() functions can be used by a device driver to save and restore standard PCI config registers. The pci_save_state() function must be invoked while the device has valid state before pci_restore_state() can be used. If the device is not in the fully-powered state (PCI_POWERSTATE_D0) when pci_restore_state() is invoked, then the device will be transitioned to PCI_POWERSTATE_D0 before any config registers are restored.

The pcie_flr() function requests a Function Level Reset (FLR) of dev. If dev is not a PCI-express device or does not support Function Level Resets via the PCI-express device control register, false is returned. Pending transactions are drained by disabling busmastering and calling pcie_wait_for_pending_transactions() before resetting the device. The max_delay argument specifies the maximum timeout to wait for pending transactions as described for pcie_wait_for_pending_transactions(). If pcie_wait_for_pending_transactions() fails with a timeout and force is false, busmastering is re-enabled and false is returned. If pcie_wait_for_pending_transactions() fails with a timeout and force is true, the device is reset despite the timeout. After the reset has been requested, pcie_flr sleeps for at least 100 milliseconds before returning true. Note that pcie_flr does not save and restore any state around the reset. The caller should save and restore state as needed. That last bit is lowkey important — don’t make pcie_flr do your state homework for you.

📡 Message Signaled Interrupts 📡

Message Signaled Interrupts (MSI) and Enhanced Message Signaled Interrupts (MSI-X) are PCI capabilities that provide an alternate method for PCI devices to signal interrupts. The legacy INTx interrupt is available to PCI devices as a SYS_RES_IRQ resource with a resource ID of zero. MSI and MSI-X interrupts are available to PCI devices as one or more SYS_RES_IRQ resources with resource IDs greater than zero. A driver must ask the PCI bus to allocate MSI or MSI-X interrupts using pci_alloc_msi() or pci_alloc_msix() before it can use MSI or MSI-X SYS_RES_IRQ resources. A driver is not allowed to use the legacy INTx SYS_RES_IRQ resource if MSI or MSI-X interrupts have been allocated, and attempts to allocate MSI or MSI-X interrupts will fail if the driver is currently using the legacy INTx SYS_RES_IRQ resource. A driver is only allowed to use either MSI or MSI-X, but not both. Pick one, bestie. This is not a “why not both” situation.

The pci_msi_count() function returns the maximum number of MSI messages supported by the device dev. If the device does not support MSI, then pci_msi_count() returns zero.

The pci_alloc_msi() function attempts to allocate *count MSI messages for the device dev. The pci_alloc_msi() function may allocate fewer messages than requested for various reasons including requests for more messages than the device dev supports, or if the system has a shortage of available MSI messages. On success, *count is set to the number of messages allocated and pci_alloc_msi() returns zero. The SYS_RES_IRQ resources for the allocated messages will be available at consecutive resource IDs beginning with one. If pci_alloc_msi() is not able to allocate any messages, it returns an error. Note that MSI only supports message counts that are powers of two; requests to allocate a non-power of two count of messages will fail. Two, four, eight, sixteen — math girlies only, no cap.

Okay so next up, pci_release_msi() — literally the cleanup queen 💅 she hands back any allocated MSI or MSI-X messages to the system, no cap. But bestie, heads up: if any MSI or MSI-X SYS_RES_IRQ resources are still allocated by the driver or still have a configured interrupt handler, she will fail with EBUSY. Rude but fair. pci_release_msi() returns zero on success and an error on failure. Periodt.

Then there's pci_msix_count() — she tells you the max number of MSI-X messages that device dev can support. And if the device doesn't support MSI-X at all? She returns zero. That's it, that's the whole vibe. 🦋

pci_msix_pba_bar() is giving map-girl energy: she returns the offset in configuration space of the Base Address Register (BAR) that contains the MSI-X Pending Bit Array (PBA) for device dev. You can use that returned value as the resource ID with bus_alloc_resource(9) and bus_release_resource(9) to allocate the BAR ✨. If the device doesn't support MSI-X, pci_msix_pba_bar() returns -1. Sad but true.

Same situation with pci_msix_table_bar() — she returns the offset in configuration space of the BAR containing the MSI-X vector table for device dev. That returned value is also usable as the resource ID with bus_alloc_resource(9) and bus_release_resource(9) to allocate the BAR. And if the device doesn't support MSI-X, pci_msix_table_bar() returns -1. Matching outfits, iconic. 🎀

Now, the main character: pci_alloc_msix() 🔥 she attempts to allocate *count MSI-X messages for the device dev. And here's the thing — she may allocate fewer messages than you requested, for various reasons, including asking for more messages than device dev supports, or if the system is having a shortage of available MSI-X messages 😭. On success, *count is set to the number of messages actually allocated, and pci_alloc_msix() returns zero.

For MSI-X messages, the resource ID for each SYS_RES_IRQ resource identifies the index in the MSI-X table of the corresponding message. So a resource ID of one maps to the first index of the MSI-X table; a resource ID of two identifies the second index in the table, etc. pci_alloc_msix() assigns the *count messages allocated to the first *count table indices. If she's not able to allocate any messages at all, she returns an error. And unlike MSI, MSI-X does not require message counts that are powers of two — so no forced evenness, she's flexible like that 🌸.

Big important note bestie: the BARs containing the MSI-X vector table and PBA must be allocated via bus_alloc_resource(9) before calling pci_alloc_msix() and must not be released until after calling pci_release_msi(). Also note that the vector table and PBA may be stored in the same BAR or in different BARs. Don't get caught lacking 🙈

pci_pending_msix() is the little detective 🔍 she examines the dev device's PBA to determine the pending status of the MSI-X message at table index index. If the indicated message is pending, this function returns a non-zero value; otherwise, it returns zero. And passing an invalid index to this function will result in undefined behavior 😭 so like, don't do that. For real.

As mentioned in the description of pci_alloc_msix(), MSI-X messages are initially assigned to the first N table entries. But a driver may use a different distribution of available messages to table entries via the pci_remap_msix() function — she's the remix queen 👑. Note that this function must be called after a successful call to pci_alloc_msix() but before any of the SYS_RES_IRQ resources are allocated. Order matters, always. pci_remap_msix() returns zero on success, or an error on failure.

The vectors array should contain count message vectors. The array maps directly to the MSI-X table in that the first entry in the array specifies the message used for the first entry in the MSI-X table, the second entry in the array corresponds to the second entry in the MSI-X table, etc. The vector value in each array index can either be zero, to indicate that no message should be assigned to the corresponding MSI-X table entry, or it can be a number from one to N (where N is the count returned from the previous call to pci_alloc_msix()) to indicate which of the allocated messages should be assigned to the corresponding MSI-X table entry. Slay, mapping 💅

If pci_remap_msix() succeeds, each MSI-X table entry with a non-zero vector will have an associated SYS_RES_IRQ resource whose resource ID corresponds to the table index as described above for pci_alloc_msix(). MSI-X table entries with a vector of zero will not have an associated SYS_RES_IRQ resource. Additionally, if any of the original messages allocated by pci_alloc_msix() are not used in the new distribution of messages in the MSI-X table, they will be released automatically ✨. But note: if a driver wishes to use fewer messages than were allocated by pci_alloc_msix(), the driver must use a single, contiguous range of messages beginning with one in the new distribution. pci_remap_msix() will fail if this condition is not met. No skipping numbers, bestie, that's the rule 😤

🦋 Device Events 🦋

The pci_add_device event handler is invoked every time a new PCI device is added to the system. This includes the creation of Virtual Functions via SR-IOV. New device, who dis 💖

The pci_delete_device event handler is invoked every time a PCI device is removed from the system. Bye bestie 👋

Both event handlers pass the device_t object of the relevant PCI device as dev to each callback function. Both event handlers are invoked while dev is unattached but with valid instance variables. Noted and memorized 🧚

---

🌈 SEE ALSO 🌈

• pci(4)
• pciconf(8)
• bus_alloc_resource(9)
• bus_dma(9)
• bus_release_resource(9)
• bus_setup_intr(9)
• bus_teardown_intr(9)
• devclass(9)
• device(9)
• driver(9)
• eventhandler(9)
• rman(9)

“NewBus”, FreeBSD Developers' Handbook, https://docs.freebsd.org/en/books/developers-handbook/.

Shanley and Anderson, PCI System Architecture, Addison-Wesley, 2nd Edition, ISBN 0-201-30974-2.

---

👑 AUTHORS 👑

This manual page was written by Bruce M Simpson <bms@FreeBSD.org> and John Baldwin <jhb@FreeBSD.org>. Absolute legends, we stan 🫶

---

💀 BUGS 💀

Okay so the kernel PCI code has a number of references to “slot numbers”. And listen — these do not refer to the geographic location of PCI devices, but to the device number assigned by the combination of the PCI IDSEL mechanism and the platform firmware. This should be taken note of when working with the kernel PCI code. Do not get it twisted 🙈

Also the PCI bus driver should allocate the MSI-X vector table and PBA internally as necessary rather than requiring the caller to do so. Like, it really should. Not me side-eyeing the API design 😭

---

And that's a wrap bestie!! This page is from Debian, dated March 27, 2025, and it's the PCI(9) manual page — go forth and PCI responsibly 💖✨🎀