On Wed, Aug 26, 2020 at 05:35:43PM +0300, Heikki Krogerus wrote:

On Wed, Aug 26, 2020 at 03:20:14PM +0200, Linus Walleij wrote:

quoted

Hi Dmitry,

On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov
[off-list ref] wrote:

quoted

On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote:

quoted

quoted

The goal I'm working toward is to rid the kernel of the global
GPIO numberspace.

This means GPIO lines should be references by the local offset
on the GPIO chip.

This patch set starts to move gpio_keys toward using GPIO
look-up tables instead of global GPIO numbers to find their
GPIOs.

As an example I did (I think) the necessary patches to
convert DaVinci and i.MX to use this. There are several users
also x86 platform devices.

(...)

quoted

I think this is a worthy goal, but I wonder if we could get static GPIO
descriptors work with fwnode_get_named_gpiod() so we could retire the
platform data parsing altogether. We'd need to extend static device
properties to have notion of children though.

Do we have this now? I've looked at Heikki's et al work
on software nodes but I cannot see whether we are there now.

We have fwnode_create_software_node() and friends, but
I haven't seen if this can be used with input and GPIO descriptors
are still a bit on the side. I can create a lot of properties but
not really add a descriptor table as a software node as far as
I can tell. I'm also a bit lost on whether it will be possible
to get there sadly :/

I'm sorry but I'm not completely sure what is this about? Are software
nodes still missing something that would prevent us from for example
using them to describe the GPIO information exactly the same way it is
described in DT? I don't know if that is what we want, but I'm just
trying to understand what is still missing? Dmitry?

No, my changes to improve the fwnode handling of references have landed,
a while ago, so now I need to refresh the series of patches to gpiolib I
was working on around Plumbers time last year. Linus seemed mostly OK
with them, so it just a matter of finding time and picking this up
again.

Thanks.

-- 
Dmitry