X86_MATCH_VFM_CPU_TYPE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– X86_MATCH_VFM_CPU_TYPE(9) πŸ’–

okay so bestie, welcome to X86_MATCH_VFM_CPU_TYPE(9) from the Kernel API Manual. This one is lowkey a baddie: it matches an encoded vendor/family/model/type combo, and the whole page is short enough to read before your iced coffee melts. 🧊✨

🌸 NAME 🌸

X86_MATCH_VFM_CPU_TYPE β€” matches the encoded vendor/family/model/type. That's it, that's the name, and it ate. πŸ’…

✨ SYNOPSIS ✨

Here's the call, copied exactly so you can't mess it up:

X86_MATCH_VFM_CPU_TYPE (vfm , type , data );

πŸŽ€ ARGUMENTS πŸŽ€

  • vfm β€” the encoded combo, with 8-bits each for vendor, family, model. So yes: vendor + family + model all packed in there. 🫢
  • type β€” the CPU type, e.g. P-core, E-core. That's the core flavor, bestie. πŸ”₯
  • data β€” driver specific data or NULL. The internal storage format is unsigned long. The supplied value, pointer etc. is cast to unsigned long internally. No cap, that cast is happening. πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

The kernel file to peek at is ./arch/x86/include/asm/cpu_device_id.h. Here's the whole related-macro crew, no cap:


Source/version tea: ./arch/x86/include/asm Β· date: October 2026 Β· footer tag: X86_MATCH_VFM_CPU_TYPE(9). That's the whole page, bestie β€” go match some encoded vendor/family/model/type and slay. πŸ’–βœ¨

πŸ“¦ where this page comes from