STRUCT IIO_TRIGGER(9)

💖 NAME 💖

okay bestie, welcome to struct iio_trigger(9) from the Kernel API Manual — it’s the industrial I/O trigger device page, and it’s giving kernel-internals main character energy. ✨

✨ SYNOPSIS ✨

here’s the exact struct layout, no cap — every field stays exactly where it belongs:

struct iio_trigger {
    const struct iio_trigger_ops    *ops;
    struct module                   *owner;
    int id;
    const char                      *name;
    struct device                   dev;
    struct list_head                list;
    struct list_head                alloc_list;
    atomic_t use_count;
    struct irq_chip                 subirq_chip;
    int subirq_base;
    struct iio_subirq subirqs[CONFIG_IIO_CONSUMERS_PER_TRIGGER];
    unsigned long pool[BITS_TO_LONGS(CONFIG_IIO_CONSUMERS_PER_TRIGGER)];
    struct mutex                    pool_lock;
    bool attached_own_device;
    struct work_struct              reenable_work;
 };

🎀 Members 🎀

member-by-member, bestie — keep those bracket tags exactly as they are:

• ops — [DRIVER] the operations structure. this is the driver’s whole blueprint vibe.
• owner — [INTERN] the owner of this driver module. internal business, but important.
• id — [INTERN] the unique id number. everyone needs their own little number, fr fr.
• name — [DRIVER] the unique name. iconic, one-of-one behavior.
• dev — [DRIVER] the associated device, if relevant. not every trigger has one attached, and that’s fine.
• list — [INTERN] used in maintenance of the global trigger list. it’s on the master list, periodt.
• alloc_list — [DRIVER] used for the driver specific trigger list. this one’s for the driver’s own little group chat.
• use_count — [INTERN] use count for the trigger. keeping track of who’s using it rn.
• subirq_chip — [INTERN] associate 'virtual' irq chip. yes, virtual — it’s giving simulated irq energy.
• subirq_base — [INTERN] base number for irqs provided by the trigger. the starting number, basically.
• subirqs — [INTERN] information about the 'child' irqs. the little irq children, adorable.
• pool — [INTERN] bitmap of irqs currently in use. who’s taken and who’s free, mapped out.
• pool_lock — [INTERN] protection of the irq pool. gotta keep that pool safe from chaos.
• attached_own_device — [INTERN] if we are using our own device as trigger, i.e. if we registered a poll function to the same device as the one providing the trigger. 🫶
• reenable_work — [INTERN] work item used to ensure reenable can sleep. sleepy reenable? handled.

🦋 SEE ALSO 🦋

go peek at these, iykyk:

• Kernel file ./include/linux/iio/trigger.h
• struct iio_trigger_ops(9)
• iio_trigger_set_drvdata(9)
• iio_trigger_get_drvdata(9)
• iio_trigger_register(9)
• iio_trigger_unregister(9)
• iio_trigger_set_immutable(9)
• iio_trigger_using_own(9)

okay that’s the whole page, bestie 🫶 source/version: ./include/linux/iio · date: October 2026 · page: struct iio_trigger(9). periodt. 💅✨