gpiochip_add_data(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… gpiochip_add_data(9) β€” the Kernel API Manual, bestie edition πŸŽ€

okay so this one is from the Kernel API Manual (yes, the 9 section, we love a kernel-dev moment) and it's literally the page about registering a gpio_chip. grab a strawberry drink πŸ“, we're doing this.


✨ SYNOPSIS ✨

gpiochip_add_data (gc , data );

that's it. two args. iconic.


🫢 ARGUMENTS 🫢

  • gc β€” the chip you're registering, and heads up: it needs gc->base already initialized before you hand it over. no showing up unprepared πŸ’…
  • data β€” the driver-private data that goes with this chip. it's giving "your stuff, your business" πŸŽ€

🌈 CONTEXT 🌈

potentially before irqs will work 😭 like, yes, it can happen that early. read the description, i'm begging you.


πŸ‘‘ DESCRIPTION πŸ‘‘

so here's the tea β˜•. when gpiochip_add_data gets called very early during boot β€” like, early enough that GPIOs can be freely used β€” then the gc->parent device must be registered before the gpio framework's arch_initcall. otherwise sysfs initialization for GPIOs will fail rudely πŸ’€ and nobody wants that energy in their dmesg.

also, gpiochip_add_data must only be called after gpiolib initialization β€” i.e. after core_initcall. that's the vibe check you cannot skip, fr fr.

and if gc->base is negative? that's the signal to request dynamic assignment of a range of valid GPIOs. you're not picking the number, the kernel is picking the number. main character energy only for the framework 🧚✨


⭐ RETURN ⭐

  • a negative errno if the chip can't be registered β€” for example because gc->base is invalid, or it's already associated with a different chip πŸ™ˆ
  • otherwise it returns zero as a success code. slay. that zero ate πŸ’–

πŸ¦‹ SEE ALSO πŸ¦‹


and that's the whole page, no cap πŸ’œ this one lives in ./include/linux/gpio, dated October 2026 β€” go read the source bestie, it's lowkey all there 🌸🫢

πŸ“¦ where this page comes from