STRUCT INTEL_VSEC_DEVICE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct intel_vsec_device(9) β€” like, the Kernel API Manual, but make it make sense

okay so bestie, gather round, because today we're reading struct intel_vsec_device from the struct intel_vsec_device(9) page and honestly? it's giving "auxbus but make it extra." no cap, this is the struct that carries all the Auxbus-specific device info, and once you see it laid out you'll be like ohhh that's what that field was for. 🫢


✨ NAME ✨

struct intel_vsec_device β€” Auxbus specific device information. that's it, that's the whole vibe check. πŸ’…


🌸 SYNOPSIS 🌸

here's the whole struct, character for character, because we do NOT paraphrase code in this house:

struct intel_vsec_device {
    struct auxiliary_device auxdev;
    struct device *dev;
    u32 (*acpi_disc)[PMT_DISC_DWORDS];
    enum intel_vsec_disc_source src;
    struct ida *ida;
    int num_resources;
    int id;
    void *priv_data;
    size_t priv_data_size;
    unsigned long quirks;
    u64 base_addr;
    unsigned long cap_id;
    struct resource resource[];
};

like, look at her. main character struct energy fr fr. πŸ‘‘


πŸŽ€ Members πŸŽ€

okay now we go field by field, bestie, no skipping, we're doing ALL of them:

  • auxdev β€” the auxbus device struct for auxbus access. literally her whole reason for existing, the auxbus entry pass. ✨
  • dev β€” the struct device associated with the device. yes it's a device inside a device situation, don't overthink it, it's fine. πŸ¦‹
  • acpi_disc β€” the ACPI discovery tables! each entry is two QWORDs in little-endian format, exactly as defined by the PMT ACPI spec. heads up though: this one is valid only when src == INTEL_VSEC_DISC_ACPI. so like, read the src field first, bestie, i'm begging. πŸ™ˆ
  • src β€” the source of the discovery table data. this is your "which flavor of discovery are we doing" field, and it decides whether acpi_disc or resource is even real. πŸ‘€
  • ida β€” id reference. short, sweet, iconic. πŸ’œ
  • num_resources β€” number of resources. it does what it says on the tin, no notes. ⭐
  • id β€” xarray id. yes it's an id and there's an ida field, no they're not the same thing, we don't ask questions, we just copy them correctly. πŸ’€
  • priv_data β€” any private data needed. your little pocket of secrets, bestie. πŸ“
  • priv_data_size β€” size of the private data area. because priv_data needs a priv_data_size, they're a matching set, obsessed. πŸŽ€
  • quirks β€” specified quirks. every good struct has some quirks, honestly relatable. 🌸
  • base_addr β€” base address of entries (if specified). the "(if specified)" is doing a lot of heavy lifting there so keep it in mind. πŸ”₯
  • cap_id β€” the enumerated id of the vsec feature. not to be confused with id, which is the xarray id, we've been over this. πŸ’…
  • resource β€” PCI discovery resources (BAR windows), one per discovery instance. and just like acpi_disc had a condition, this one does too: valid only when src == INTEL_VSEC_DISC_PCI. ok so the pattern is: check src, then touch the pointer. periodt. 🌈
fr fr the two "valid only when" caveats are the whole point of this struct β€” src tells you which of acpi_disc / resource actually means anything. don't go reading a field that isn't valid for your src, that's how you get sad undefined-behavior vibes. 😭

🧚 SEE ALSO 🧚

go read these next, bestie, they're all in Kernel file ./include/linux/intel_vsec.h:

  • struct intel_vsec_header(9)
  • struct pmt_callbacks(9)
  • struct intel_vsec_platform_info(9)
  • struct oobmsm_plat_info(9)

iykyk, it's a whole little friend group of structs and they all reference each other. 🫢


πŸ‘‘ the cute sign-off πŸ‘‘

and that's the page!! this one lives in ./include/linux, dated October 2026, in the Kernel API Manual. slay, ate, left no crumbs. now go check your src field before you dereference anything, bestie, and i'll see you in the next manpage. βœ¨πŸ’–πŸŽ€

πŸ“¦ where this page comes from