On Fri, Sep 16, 2022 at 8:12 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Fri, Sep 16, 2022 at 9:11 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > Of course we were not the first ones to think about it... > > :D > > > I'll read through it later. Was there any particular reason why this > > never made its way into the kernel? > > Inability to drive through a DT binding that was acceptable for the > DT binding maintainers. AFAICT, this came up briefly in 2015, then 2017, then 2019. (You're a year late this time.) A nice regular pattern to not get something upstream... > A good idea to get it passed I think would be to ask Rob (with some > examples) how he thinks it should look and finalize the bindings > before coding. My issue was more that by the time the kernel or even bootloader runs, quite a bit of time has passed given all the firmware that runs nowadays. Doesn't a safe state need to be set as early as possible? Like probably before anything using DT? A node per GPIO could end up being a lot of nodes and I can certainly see folks just initializing every GPIO. That would be a lot of bloat. As I see it we need 4 bits per line: direction, state(high/low), pull up/down/none. Finally, don't non-GPIO pins need the same thing? You don't want a default output driving what needs to be an input. Of course, a good h/w designer wouldn't design such a thing. Rob