On Thu, Nov 10, 2022 at 12:33 PM Andre Przywara <andre.przywara@xxxxxxx> wrote: > This is actually an argument in favour of it: at the moment *every* OS > (or DT user) has to carry some form of this table[1]. For U-Boot this is a > major pain, for instance, and we came up with some minimal and > simplified version of that (assuming one pinmux per function name, > ignoring different mappings in different ports: [2]), but we are already > touching its limits. That's a compelling argument. I don't know about reusing the existing pinmux property in a new way which differs from the standard one: pinmux: description: The list of numeric pin ids and their mux settings that properties in the node apply to (either this, "pins" or "groups" have to be specified) $ref: /schemas/types.yaml#/definitions/uint32-array You should rather invent something like "sunxi,pin-mux-val" or so. That makes me happy to merge it at least, I don't see any problem with it. > And I don't think this DT argument counts anyway: we already store a much > bigger chunk of "information" in the DT, namely the function name. This has > no technical meaning, really, other than to map this to a 4-bit value > internally. I don't know why we have an information like "UART0 is using > the 'uart0' pin group" in the DT, but refuse to put the actual > hardware information in there. We could possibly even get rid of the > string, and derive this from the node name, if we need some human readable > identifier. These exist for consistency and maintenance, they are established standard bindings: Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml Associating a function "uart0" with something like [ "uart0-txrx", uart0-rtscts" ] by a line such as: groups = "uart0-txrx", "uart0-rtscts"; is simple to understand, and makes it easier for maintainers who have to look at a lot of different platforms with different muxes. So these are there for human readability. I.e. the goal of standard properties is not to minimize amount of information (which is your goal here) but to structure things in a way that makes maintenance easier by being similar on several platforms. Some systems deviate from standard properties, and admittedly this way of structuring things with strings is maybe not the ultimate. The most deviating one is: Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt which is used by OMAP and HiSilicon. Some feel this should never have been merged. But it was merged. By me. There is also the pinmux property above which some systems use for putting in enumerated magic. That's part of the standard but makes the standard somewhat incoherent. This difference in pin control DT patterns is because we could not come up with something that was acceptable for all and the result of some diplomacy when the subsystem was created around 2011-2012. The thing is that I am not a very consistent and stubborn person and I think more along the lines of the IETF motto "rough consensus and running code". The DT people were different back in 2011, and also softer around the edges, not as strict and not insisting on things being done one way for all systems. Their ambitions have stepped up since. So these are the people you need to convince. I suggest you propose the bindings with the patch set by Cc devicetree@xxxxxxxxxxxxxxx using the custom "sunxi,pin" or whatever name you want and see if the DT reviewers agree with this solution. If they say nothing in like 2 weeks I usually merge things that I find non-objectionable anyways. Yours, Linus Walleij