GPIO(4)

💅 GPIO(4) — the gpiobus situation, explained

okay bestie, welcome to GPIO(4), straight out of the Kernel Interfaces Manual ✨ this is the whole gpiobus — GPIO bus system — and honestly it's giving "tiny pins, big main character energy" 🔥

---

🌸 SYNOPSIS

so like, if you wanna compile these devices into your kernel and use the device hints, you gotta put these lines in your kernel configuration file, no cap:

device gpio
device gpioiic
device gpioled

and then — plot twist — there are extra device entries depending on your architecture. we love a per-platform moment 💅

For the ARM architecture, add:

device a10_gpio
device bcm_gpio
device imx51_gpio
device lpcgpio
device mv_gpio
device ti_gpio
device gpio_avila
device gpio_cambria
device zy7_gpio
device pxagpio

For the MIPS architecture, add:

device ar71xxx_gpio
device octeon_gpio
device rt305_gpio

For the POWERPC architecture, add:

device wiigpio
device macgpio

For the RISC-V architecture, add:

device sifive_gpio

like yes, they really did make a whole roster 🫶

---

🦋 DESCRIPTION

so the gpiobus system hands you a simple interface to the GPIO pins — the ones that are usually hanging out on embedded architectures — and it can also give the system bit banging style devices. icon behavior honestly ✨

the acronym GPIO means “General-Purpose Input/Output.” periodt 💅

the BUS physically consists of multiple pins that can be configured for input/output, IRQ delivery, SDA/SCL iicbus use, etc. like little multitaskers 🎀

on some embedded architectures (like MIPS), discovery of the bus and configuration of the pins is done via device.hints(5) in the platform's kernel config(5) file.

on some others (like ARM), where FDT(4) is used to describe the device tree, the bus discovery is done via the DTS passed to the kernel — and that can be either statically compiled in, or handled by a variety of ways where the boot loader (or an Open Firmware enabled system) passes the DTS blob to the kernel at boot. very "it depends" of it 😭

---

🧚 the device.hints(5) hints

on a device.hints(5) based system, these hints can be used to configure drivers for devices attached to gpiobus pins:

• hint.driver.unit.at — the gpiobus where the device is attached. for example, "gpiobus0". driver and unit are the driver name and the unit number for the device driver. iykyk 🌸
• hint.driver.unit.pins — this is a bitmask of the pins on the gpiobus that are connected to the device. the pins will be allocated to the specified driver instance. heads up bestie: only pins with numbers from 0 to 31 can be specified using this hint 🫶
• hint.driver.unit.pin_list — this is a list of pin numbers of pins on the gpiobus that are connected to the device. the pins will be allocated to the specified driver instance. this is a more user friendly alternative to the pins hint. additionally, this hint allows specifying pin numbers greater than 31 👑 the numbers can be decimal or hexadecimal with 0x prefix. any non-digit character can be used as a separator — for example, it can be a comma, a slash or a space. the separator can be followed by any number of space characters. literally so flexible, ate 💅

---

💜 the ar71xx_gpio-only hints

the following device.hints(5) are only provided by the ar71xx_gpio driver — exclusive fr fr:

• hint.gpio.%d.pinmask — this is a bitmask of pins on the GPIO board that we would like to expose for use to the host operating system. to expose pin 0, 4 and 7, use the bitmask of 10010001 converted to the hexadecimal value 0x0091. math queen behavior 🧮
• hint.gpio.%d.pinon — this is a bitmask of pins on the GPIO board that will be set to ON at host start. to set pin 2, 5 and 13 to be set ON at boot, use the bitmask of 10000000010010 converted to the hexadecimal value 0x2012 ✨
• hint.gpio.function_set
• hint.gpio.function_clear — these are bitmasks of pins that will remap a pin to handle a specific function (USB, UART TX/RX, etc) in the Atheros function registers. this is mainly used to set/clear functions that we need when they are set up or not set up by uBoot.

---

and simply put — each pin of the GPIO interface is connected to an input/output of some device in a system. that's the whole vibe 🌈

---

🔥 SEE ALSO

gpioiic(4), gpioled(4), iicbus(4), device.hints(5), gpioctl(8)

go read those too, bestie, they're all linked 🫶

---

🎀 HISTORY

the gpiobus manual page first appeared in FreeBSD 10.0. a classic, honestly ⭐

---

👑 AUTHORS

this manual page was written by Sean Bruno <sbruno@FreeBSD.org>. thank you for your service 🫡💖

---

ok that's the whole page, no gatekeeping here 💅 go forth and configure those pins, bestie 🦋

— Debian, August 28, 2025 — GPIO(4) — that's a wrap, mwah 🎀✨