Re: GPIO bindings guidelines (Was: Re: [PATCH v5 10/12] gpio: Support for unified device properties interface)

[Linus Walleij]

On Thu, Oct 23, 2014 at 2:25 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Thursday 23 October 2014 15:02:46 Alexandre Courbot wrote:
>> On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> > On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
>
>> > Drivers that use
>> > existing bindings with the "foo-gpio" form (or worse, "foo-somethingelse"
>> > can use the same internal interface as the drivers that use name plus
>> > index. Do you see a problem using what I suggested for the combined
>> > API:
>> >
>> > __gpiod_get(dev, propname, index); // use property name plus index
>> > gpiod_get(dev, index); // use "gpios" plus index
>> > gpiod_get_named(dev, "name"); use "name-gpios" with index 0
>>
>> Apart from the loosy naming practices which we sometimes see (and
>> which should be caught during review), do you have something against
>> requiring a name for all new GPIO bindings, i.e. for ensuring that all
>> new properties are "name-gpio" and forbidding "gpios"?
>
> Most other subsystems don't require a name, and traditionally we only
> had anonymous indexed properties for a lot of things (registers,
> interrupts, ...).
>
> I still like the idea of using anonymous references for simple things,
> but if you and Linus feel that it's better to mandate names from now on,
> I won't complain.

I think names are nice since it appears in <debugfs>/gpio and makes
device tree using platforms easier to debug.

Moving things into DT already made information hard to follow at
times...

In difference from other things like IRQs or DMAs, GPIOs very often
have a very specific function, does not repeat itself, and thus can
be given a suitable name.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/