Re: [RFC] Addition of kernel

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

Hi Martyn,

On Mon, Jun 17, 2019 at 10:29 AM Martyn Welch
<martyn.welch@xxxxxxxxxxxxx> wrote:

> We are currently in the position that we would like to pre-configure
> some GPIOs at boot time and be able to later affect the state of GPIOs
> configured as outputs or read the state of GPIOs previously configured
> as inputs.

I have discussed this several times in the past, I soon have to
make a collection of links to the old discussions so we don't have
to repeat ourselves :)

Here are some:

Discussion with Rob Herring:
https://marc.info/?l=linux-gpio&m=145749645728713&w=2

https://marc.info/?l=linux-gpio&m=153440711326259&w=2
In response to:
https://marc.info/?l=linux-kernel&m=153436471811875&w=2

> Initially we are thinking of providing a device-tree node containing a
> "gpio-default" property and would contain a lot of the same properties
> as "gpio-hog".
>
> Code wise, it would seem to need to follow roughly the same flow as
> gpio-hog, but avoid running "gpiod_request_commit()" so that the GPIO
> line could later be requested by user space.
>
> I suspect there's a whole load of details that I'm missing at this
> stage and I've not fully thought through the implications for later
> removal.
>
> Does something like this seem viable upstream?

I am all for it, the trick is to come up with a syntax that passes the
review of the device tree people. They did not like the idea to extend
the hogs, and dislike the way hogs were made in the first place.

I would suspect that something more similar to gpio-line-names
sits better with them, like gpio-initial-states = in -, out 1, out 0, in -. ...
however that would work.

There are some custom bindings for this already that should
ideally be phased over to the generic bindings as part of the
patch set.

Yours,
Linus Walleij