On Tue, Jul 28, 2015 at 4:16 PM, Johan Hovold [off-list ref] wrote:

That said, this is a step along the lines that we have discussed in the
past. Adding pin functions (line names) to generic pin nodes in DT makes
sense, but we need to think through the details first. For example:

 - Should we allow duplicate pin functions (line names)? We need to
   consider not just on-chip controllers, but also hot-pluggable
   controllers and device-tree overlays.

I guess the typical example is if we have two identical GPIO
expanders. We have this with arch/arm/boot/dts/ste-nomadik-nhk15.dts
for example.

With this scheme, they will simply have to name their lines
uniquely for things to work since /sys/class/gpio is a flat
space, not hierarchic per-gpiochip (as would be preferred,
should this be sane to maintain).

 - Should we allow initial configurations to be specified and still
   allow (some) pins to be requested later ("soft" hogging)?

That is a key idea in this patch set.

Maybe we need a "userspace hog" to mark these specifically as
not used by the operating system. (Bringing me back to my
tirade about people doing stupid things in userspace just because
they don't know about all the nice GPIO stuff in the kernel.)

 - Should we specify pin directionality? I've suggested elsewhere that
   adding such limitations (e.g. as a mask) may make sense in cases were
   changing pin direction is known to cause damage.

We have the flag jamming IRQ lines to be input, but input-only
and output-only seems reasonable for hogs in reaction to the
current "input", "output-low" and "output-high" properties.

Could be a separate patch though.

 - What would a new gpio interface look like?

Yeah :/ people are scared of adding chardevs it seems.

I think they are kind of nice, the biggest problem seems to be
totally confused userspace with udev and mdev and none of
them ever knows about new stuff and people get problems
becuase of old rootfs:es.

Yours,
Linus Walleij