[PATCH 0/5] Make gpio_keys accept board descriptors

[Linus Walleij]

On Sun, Nov 26, 2017 at 12:33 AM, Dmitry Torokhov
<dmitry.torokhov at gmail.com> wrote:

> I think this is a worthy goal, but I wonder if we could get static GPIO
> descriptors work with fwnode_get_named_gpiod()

I think that will just work, I can try it on something and see.

> so we could retire the
> platform data parsing altogether. We'd need to extend static device
> properties to have notion of children though.

So we are talking about these static device properties I assume?

/**
 * struct gpiod_lookup - lookup table
 * @chip_label: name of the chip the GPIO belongs to
 * @chip_hwnum: hardware number (i.e. relative to the chip) of the GPIO
 * @con_id: name of the GPIO from the device's point of view
 * @idx: index of the GPIO in case several GPIOs share the same name
 * @flags: mask of GPIO_* values
 *
 * gpiod_lookup is a lookup table for associating GPIOs to specific devices and
 * functions using platform data.
 */
struct gpiod_lookup {
        const char *chip_label;
        u16 chip_hwnum;
        const char *con_id;
        unsigned int idx;
        enum gpio_lookup_flags flags;
};

struct gpiod_lookup_table {
        struct list_head list;
        const char *dev_id;
        struct gpiod_lookup table[];
};

The fact that keys are modeled as children in DTS/ACPI DSDT
more of a pecularity to these description languages
providing opaque configuration nodes.

E.g. these children reflects struct gpio_keys_button being a child of
struct gpio_keys_platform_data in the board files. But
it is only one device, "gpio-keys" in the Linux device
model. The buttons/keys are not devices.

Likewise, in device tree the buttons are not really
devices under the "gpio-keys" device, they are just property
nodes in the device tree conveniently set in a hierarchy to
contain the information. I bet ACPI works the same.

Since GPIO descriptors (like clocks, regulators ...) are
associated with the device, this becomes problematic: these
children are not devices. So they need to be associated
with the device to begin with.

In that case, I would opt to just use the
unsigned int idx field for determining child number from
the descriptor table, use con_id for naming the child and
we are back at essentially the same structure as a backend
for fwnode.

Due to the complexity of fwnode requireing an entire
parser for fwnode_operations etc it's a bit of heavy lifting
so I need to think and experiment some more.

Yours,
Linus Walleij