pci_iov_get_pf_drvdata(9)

📦 version 7.3.1, in nixpkgs unstable

✨ pci_iov_get_pf_drvdata(9) ✨

okay so bestie, welcome to the Kernel API Manual — this one's a little function with big "don't talk to me until the PF driver says it's cool" energy 💅

💖 NAME 💖

pci_iov_get_pf_drvdata — literally just returns the drvdata of a PF 🫶

🌸 SYNOPSIS 🌸

void * pci_iov_get_pf_drvdata (struct pci_dev *dev , struct pci_driver *pf_driver );

🎀 ARGUMENTS 🎀

  • dev — the VF pci_dev (yes, the VF, not the PF, stay with me here)
  • pf_driver — the device driver that's required to own the PF. like, mandatory. no substitutes 🔥

🦋 DESCRIPTION 🦋

So here's the vibe check: you must call this from a context that guarantees a VF driver is attached. Periodt. Because the value you get back goes ✨invalid✨ the second the VF driver finishes its remove callback. So don't be out here holding onto it like it's gonna last 😭

The locking? Handled by the driver core, no cap. A VF driver cannot be probed until pci_enable_sriov is called, and pci_disable_sriov doesn't return until all the VF drivers have finished their remove. Iconic behaviour honestly 👑

Also, huge one: the PF driver must call pci_disable_sriov before it starts destroying the drvdata. Like, before. Not during, not after. Before. 🙈

⚠️ lowkey important: return value = invalid after the VF driver's remove callback completes. don't say I didn't warn you 💀

🌈 SEE ALSO 🌈

Kernel file ./drivers/pci/iov.c, plus the whole friend group:

and that's the whole page, bestie 🍓 this lil gem lives over in ./drivers/pci and it's stamped October 2026 — iykyk, go forth and get that PF drvdata responsibly 💜🧚

📦 where this page comes from