Hm it appears the following reply was stuck (no SMTP response or something): On Thu, Nov 7, 2019 at 11:42 PM Rob Herring <robh@xxxxxxxxxx> wrote: > As pinctrl bindings have a flexible structure and no standard child node > naming convention, creating a single pinctrl schema doesn't work. Instead, > create schemas for the pin mux and config nodes which device pinctrl schema > can reference. > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > Cc: linux-gpio@xxxxxxxxxxxxxxx > Signed-off-by: Rob Herring <robh@xxxxxxxxxx> Patch applied. I am a big fan of schemas. I still feel like swimming in deep waters sometimes when using it and like I "fake it til I make it", I suppose one day I will grok the inner transcendental meaning of this notation. Maybe. > We're starting to see pinctrl schema doing their own definitions for > generic properties, so we need to get something in place to reference. ACK. > Maybe this could be combined into a single schema? Spliting it was > easier in order to just copy over the existing documentation. We can surely do that later. > Reading thru pinctrl-bindings.txt, I'm wondering if some of it is out > of date. Do we let new bindings not use the generic muxing properties? > Do we really need to be so flexible for child node structure? The bindings are quite flexible because we simply could not agree on a single semantic. Initially AT91, i.MX and pinctrl-single used the strategy of just storing u32's in the tree to be poked into registers to set up a certain muxing rather than strings to identify groups and functions. I tried to push and define the generic string-based muxing of functions with groups and also using strings for pin configuration. The downside of this approach is that pins need to be bundled into groups based on use case. This is not perfect: sometimes we get the wrong groups because all use cases can not be predicted when writing a driver. A typical example would be that a UART group would be four pins [RX TX CTS RTS]. Late the author realized that systems actually want two groups [RX TX] [CTS RTS] so they can punt out the [CTS RTS] group and reuse that for e.g. GPIO when only RX and TX is in use. At some point I was pretty heavily pushed by some contributors who thought the idea to define groups for all use cases was vain and wanted to use enumed numerals to define all their settings on a per-pin basis and who felt the generic muxing (and generic config) was inappropriate for their use cases. This goes especially for STM32 and Rockchip IIRC but I could be wrong. TI followed this pattern with the k3 and dra drivers. This was something like 50% of the pin control community at the time, not a vocal minority but a vocal 50%. So I caved in and merged them. I could not really stand in the way for this vital piece of infrastructure as it essentially stops the systems from even booting a mainline kernel. I assumed it was the lesser evil. The fact of the day is that a significant portion of the pin control authors like the magic numbers from defined in <dt-bindings/pinctrl/*.h> files (sometimes corresponding to register values) and the case is rather lost: these will be around and there will likely also be more of them. I personally prefer the string based configuration (functions muxed to groups and abstract standard strings for configs) as the higher abstraction gives a better fit with the ambitions of the device tree. But it is not like the per-pin and magic numbers lack merit. Yours, Linus Walleij
