On Wed, Aug 26, 2020 at 03:20:14PM +0200, Linus Walleij wrote: > Hi Dmitry, > > On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > > > > 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. > (...) > > 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? If there is still something missing, then let's fix that. thanks, -- heikki
