vme_irq_request(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 NAME 🌸

okay so bestie, welcome to the vme_irq_request(9) page from the Kernel API Manual πŸ’–

vme_irq_request β€” Request a specific VME interrupt. πŸ’…


✨ SYNOPSIS ✨

lowkey here's the exact signature, no cap:

       int vme_irq_request (struct vme_dev *vdev , int level , int statid ,
       void (*callback)(int level, int statid, void *priv_data) , void
       *priv_data );

πŸŽ€ ARGUMENTS πŸŽ€

  • vdev β€” Pointer to VME device struct vme_dev assigned to driver instance. like, this is your device's whole identity bestie 🫢
  • level β€” Interrupt priority being requested. the priority vibe check ⭐
  • statid β€” Interrupt vector being requested. the vector in question, periodt πŸŽ€
  • callback β€” Pointer to callback function called when VME interrupt/vector received. this is the function that gets pinged when the interrupt/vector shows up πŸ“ž
  • priv_data β€” Generic pointer that will be passed to the callback function. your lil extra data package, hand-delivered to the callback πŸ“

πŸ’… DESCRIPTION πŸ’…

Request callback to be attached as a handler for VME interrupts with provided level and statid.

so the whole vibe is: you're asking for your callback to be attached as the handler for VME interrupts that match the level and statid you gave. it's giving "put me on the interrupt guest list" ✨


🫢 RETURN 🫢

  • 0 β€” Zero on success. slay, it worked πŸ’–
  • -EINVAL β€” on invalid vme device, level or if the function is not supported. not it 😭
  • -EBUSY β€” if the level/statid combination is already in use. occupied, bestie, try another combo πŸ’€
  • Hardware specific errors also possible. yeah, hardware can absolutely do its own thing πŸ™ˆ

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file: ./drivers/staging/vme_user/vme.c

the whole friend group roll call, iykyk:


okay that's the whole page, mwah πŸ’‹ β€” source/version: ./drivers/staging/vme_user; date: October 2026; page: vme_irq_request(9). bye bestie πŸ¦‹

πŸ“¦ where this page comes from