devm_iio_kf...er_setup_ext(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… devm_iio_kf...er_setup_ext(9) πŸ’…

okay bestie so this is from the Kernel API Manual (yes, the kernel has a manual, and yes it's iconic), and we're about to get into kfifo buffers attaching themselves to IIO devices. stay with me, it's actually not that deep 🫢


✨ NAME ✨

devm_iio_kfifo_buffer_setup_ext β€” Allocate a kfifo buffer & attach it to an IIO device 🌸


πŸ¦‹ SYNOPSIS πŸ¦‹

int devm_iio_kfifo_buffer_setup_ext (struct device *dev , struct iio_dev *indio_dev , const struct iio_buffer_setup_ops *setup_ops , const struct iio_dev_attr **buffer_attrs );

πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” the Device object that this kfifo buffer's whole lifetime gets tied to. like, its life literally hangs off this thing πŸ’€
  • indio_dev β€” the device the buffer should be attached to. the main character, fr fr πŸ‘‘
  • setup_ops β€” the setup_ops needed to configure the HW part of the buffer. it's optional, so no pressure bestie πŸ™ˆ
  • buffer_attrs β€” extra sysfs buffer attributes for this IIO buffer ✨

πŸ’– DESCRIPTION πŸ’–

so what this function does is it allocates a kfifo buffer via iio_kfifo_allocate, and then it attaches that buffer to the IIO device via iio_device_attach_buffer. that's the whole vibe check βœ…

it's meant to be a bit of a short-hand / helper function, because apparently there are a few drivers out there that just keep doing this exact same thing β€” and honestly, the way that they kept repeating themselves? not the move. this helper ate. πŸ“


πŸ”₯ RETURN πŸ”₯

0 on success, negative error code on failure. that's it, that's the tea β˜•


🌈 SEE ALSO 🌈

Kernel file ./drivers/iio/buffer/kfifo_buf.c β€” go read it, iykyk πŸ“–


and that's the whole page diva πŸ’œ brought to you by ./drivers/iio/buffer, dated October 2026 β€” bestie the source is literally the buffer directory itself, we love a self-referential moment. mwah, bye! πŸ’…πŸŽ€βœ¨

πŸ“¦ where this page comes from