内核驱动占用GPIO后，通过/dev/input/eventX无法获取初始状态的问题

Hey there! Let's work through this GPIO initial state problem you're facing with gpio-keys. I’ve dealt with similar headaches before, so here are a few practical solutions to try out:

1. Use Device Tree Polling to Trigger Initial State Report #

Many gpio-keys drivers support the poll-interval property, which tells the driver to periodically check the GPIO state. The best part? It’ll send the initial state as soon as the driver loads. Just add this to your gpio-keys node in the device tree:

gpio_keys {
    compatible = "gpio-keys";
    pinctrl-names = "default";
    pinctrl-0 = <&gpio_keys_pins>;

    my_target_gpio: button@0 {
        label = "my_gpio_button";
        linux,code = <KEY_CUSTOM>; // Use an appropriate input code matching your use case
        gpios = <&gpio 15 GPIO_ACTIVE_LOW>; // Adjust to your GPIO pin and active level
        poll-interval = <100>; // Poll every 100ms (tweak the value as needed)
    };
};

Once the driver initializes, it’ll immediately poll the GPIO and send the initial state to the input subsystem. You’ll be able to read this state right after opening /dev/input/eventX without waiting for a state change.

2. Modify the gpio-keys Driver to Report Initial State on Probe #

If polling isn’t your style, or your kernel version doesn’t support the poll-interval property, you can tweak the gpio-keys driver code to explicitly send the initial state when it starts up. Look for the gpio_keys_probe function and add this snippet after the input device is initialized:

static int gpio_keys_probe(struct platform_device *pdev)
{
    // ... Keep all existing probe code intact ...

    // Add initial state reporting logic
    for (int i = 0; i < num_keys; i++) {
        struct gpio_button_data *bdata = &pdata->data[i];
        int current_state = gpiod_get_value_cansleep(bdata->gpiod);
        // Map raw GPIO state to input key state (account for active_low configuration)
        input_report_key(input, bdata->code, !current_state ^ bdata->active_low);
        input_sync(input); // Finalize the event report to the input subsystem
    }

    // ... Rest of the probe code ...
}

This will force the driver to send each key’s initial state to the input subsystem as soon as it’s set up—no waiting for a physical state change required.

3. Expose Initial State via a Custom Sysfs Node #

If you don’t want to modify the core gpio-keys driver, you can add a custom sysfs node in your own kernel driver to expose the initial GPIO state. Here’s a quick example:

// Define the read-only sysfs attribute
static ssize_t gpio_initial_state_show(struct device *dev, struct device_attribute *attr, char *buf)
{
    struct my_driver_data *drv_data = dev_get_drvdata(dev);
    int state = gpiod_get_value_cansleep(drv_data->gpio);
    return sprintf(buf, "%d\n", state); // Returns 0 or 1 based on the GPIO's raw state
}
static DEVICE_ATTR_RO(gpio_initial_state);

// In your driver's probe function
static int my_driver_probe(struct platform_device *pdev)
{
    struct my_driver_data *drv_data = devm_kzalloc(&pdev->dev, sizeof(*drv_data), GFP_KERNEL);
    // ... Initialize your GPIO using devm_gpiod_get() ...
    drv_data->gpio = devm_gpiod_get(&pdev->dev, "my-gpio", GPIOD_IN);
    // Create the sysfs node to expose initial state
    device_create_file(&pdev->dev, &dev_attr_gpio_initial_state);
    // ... Rest of your probe logic ...
}

Once the driver loads, you can read the initial state directly from /sys/devices/[your-device-path]/gpio_initial_state before starting to listen for input events.

4. (Not Recommended) Check GPIO Status via DebugFS #

As a last resort, you can check the GPIO’s initial state through the debug filesystem. Run cat /sys/kernel/debug/gpio and look for your GPIO pin—its current state will be listed (either low or high). Note that this is more of a debugging trick than a production solution, since debugFS might not be enabled on all systems, and parsing the output can be fragile.

内容的提问来源于stack exchange，提问作者ArthurLambert