GPIO leds class (outputs) but which class is for inputs?

Hi all,
Linux kernel 5.x.x leds class and device tree node.
I have an GPIO output that controls a relay. The output is put in the device tree as a ‘leds’ node.
Snippet from my device tree.

  led1 {
    label = "board:none:relay0";
    gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
    default-state = "off";

  user_leds_s0: user_leds_s0 {
    pinctrl-single,pins = <
    AM33XX_IOPAD(0x85c, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (T15) gpmc_a7.gpio1[23] relay0 */

  gpio1_pins_default: pinmux_gpio1_pins {
    pinctrl-single,pins = <
      AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7)  /* (T12) gpmc_ad12.gpio1[12] button0 */

I have a pinmux for the relay0 (output) and button0 (input).
I can control the relay thru the command line,
echo “1” > /sys/class/leds/board:none:relay0/brightness
My app can control the output using /dev/mem and mmap (I know that mmap() is not recommended).

The push button will also be read using mmap().

If ‘leds’ are outputs then what class/device tree node is inputs?
Can you provide example of an ‘inputs’ node in the device tree?
How to check the state of the ‘input’ class from the command line?

Thank you,



The kernel CONFIG_LEDS_CLASS option enables the LED sysfs class in /sys/class/leds.

Is there a kernel setting to allow gpio-keys to show up is sysfs?
After adding gpio-keys to the device tree, what directory/folder do gpio-keys show up in?

Thank you,


There is a good writeup for this.


For setting the active_low (or active_low) of an input in the configuration register (bit 0).
Is or-ing GPIO_ACTIVE_LOW allowed in the device tree?

  gpio1_pins_default: pinmux_gpio1_pins {
    pinctrl-single,pins = <
      AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | GPIO_ACTIVE_LOW | MUX_MODE7)  /* (T12) gpmc_ad12.gpio1[12] button0 */

Thank you,

No, you set GPIO_ACTIVE_LOW in gpio_keys node:


I understand better that GPIO_ACTIVE_LOW or GPIO_ACTIVE_HIGH are set in leds and/or gpio-keys node(s). Thank you.

About gpio-keys,
I am confused what original intent of gpio-keys. From the name, My guess is that it was designed to support a matrix of Textexternal buttons that had dedicated predefined purposes.
What is the intended purpose of gpio-keys?

I understand the gpio-keys dt-bindings for compatible, pinctrl-names, pinctrl-0, label, gpios. I don’t understand what "linux,code = " and “gpio-key,xxx” do.
In your example the node is ‘System Wake Up’ (linux,code - <143>). I have seen other linux,code values of 103 “GPIO Key UP”, 108 “GPIO Key DOWN”…

The dt-binding gpio-keys.yaml show that linux,code is required.
I found a list of linux,codes in linux-event-codes.h which gives me the idea that the linux,code tells the kernel that this ‘key’ has a dedicated purpose. I haven’t found an example of setting linux,code to a simple digital input.

My hardware,
I have a GPIO2 input connected via an opto-isolator chip to a motor controller’s digital fault output. When the motor is in a faulted condition the the GPIO input is active. My application uses mmap()* to poll and read the state of the GPIO input to handle the fault condition. The reasons I want (or need) to use gpio-keys is to set the active_low/high state of the input as early as possible. I will be using barebox for my bootloader. Barebox will be built with the my custom device tree. ‘As early as possible’ is when Barebox MLO (or proper) configures the GPIO lines.

I don’t want to set linux,code to a value that causes and event that the kernel to thinks is supposed to do something.

What linux,code is for a discrete digital input only?

*I know that mmap() is not advised but I know of no other way to read/write a bank of GPIO input/output lines at one time. Reading/Writing in one input at a time does not work for my high speed embedded industrial application. Reading/Writing a block of GPIO is a topic for another time.

Thank you,


Those are listed here:

There isn’t a simple input, the closes driver is gpio-keys. You can export the gpio in usespace and use that method, or just use mmap…

There will be “blip” between u-boot and kernel, if your need a guaranteed pin state, use an external logic… gpio-hog can help minimize it, but you lose that pin in userspace…