__iio_dev_mode_lock(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ __iio_dev_mode_lock β€” the Kernel API Manual page you've been waiting for ✨

okay so bestie, welcome to the Kernel API Manual entry for __iio_dev_mode_lock. it's short, it's spicy, and it has OPINIONS. let's get into it 🫢


🌸 NAME 🌸

__iio_dev_mode_lock β€” locks the current IIO device mode. that's it. that's the whole vibe check. πŸ”’


πŸ¦‹ SYNOPSIS πŸ¦‹

void __iio_dev_mode_lock(struct iio_dev *indio_dev);

literally one function, one argument, returns nothing (void), no cap. πŸ’…


πŸŽ€ ARGUMENTS πŸŽ€

  • indio_dev β€” the iio_dev that's associated with the device. that's the one you're locking, bestie, the main character of this whole operation πŸ‘‘

πŸ’– DESCRIPTION πŸ’–

okay so here's the tea β˜• β€” if the device is either in direct mode or buffer mode, it is guaranteed to stay that way until __iio_dev_mode_unlock gets called. like, locked in. periodt. πŸ”

⚠️ but listen β€” this function is not meant to be used directly by drivers to protect internal state. if you're a driver and you need to guard your own internal state, you should have your own mechanisms for that matter. this is not your personal bodyguard, it's a mode locker. πŸ™ˆ

and ngl, there are very few cases where a driver actually needs to lock the current mode unconditionally. like, rare rare. so instead, it's recommended that you use iio_device_claim_direct or the iio_device_try_claim_buffer_mode pairs, or related helpers. those are the icons, use those 🌈✨


🧚 SEE ALSO 🧚

kernel file ./drivers/iio/industrialio-core.c β€” that's where the magic lives, go read it iykyk πŸ“–

and the whole friend group:


πŸ‘‘ sign-off πŸ‘‘

this page lives in ./drivers/iio, it's dated October 2026, and it goes by __iio_dev_mode_lock(9) β€” go forth and lock responsibly, bestie. slay πŸ’…πŸ’–πŸŽ€πŸ¦‹β­

πŸ“¦ where this page comes from