On Fri, Sep 16, 2022 at 3:47 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > 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... :D > > 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? So that is less related to the bindings and more related to the implementation, right? I think this has always been seen as "default state at the point when the operating system boots" but possibly we should just add a flag or something to the bindings to say how early-ish the particular default safe state config applies? > 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. I don't know exactly which use cases people have here, but yeah definitely biasing for example, so a certain line can go out of reset thanks to getting pulled up. I imagined something like a ngpios long array: /* Initial states */ gpio-init-states = <GPIO_OUT_LOW, GPIO_OUT_HIGH, GPIO_NO_CHANGE, GPIO_NO_CHANGE, GPIO_OUT_HIGH ...>; these defines does not exist in include/dt-bindings/gpio/gpio.h, it's just my idea of it. > Finally, don't non-GPIO pins need the same thing? You don't want a > default output driving what needs to be an input. The pin control subsystem has something like this, in the "default" and "init" states the pins are set to a default mux/pin config. So for SoC GPIOs in many cases this problem is already solved by using pin control states and hogs, as pin control is often used as a back-end for GPIO. e.g. all Qualcomm platforms TLMM. GPIO lines however can also be on a I2C or USB expander or something where pin control is not applicable at all, so this would be for initializing lines on those controllers. Yours, Linus Walleij