On Fri, Nov 24, 2017 at 6:19 PM, Andre Przywara <andre.przywara@xxxxxxx> wrote: > On 24/11/17 13:31, Thierry Reding wrote: >> Register values don't belong in a device tree. > > I don't think that's true in a general way. This "pinmux" is already an > accepted property and used for exactly that purpose in other pinctrl > drivers: > $ git grep -l '[^,]pinmux = ' arch/arm{,64}/boot/dts > Plus the fsl,pinmux-ids property, which seems to serve the same purpose. There are several examples of register values (and register numbers even!) being encoded in the kernel. What we need to ask is whether that is good in the general case or bad. I don't even think that has a clear answer, it's a grey area. So we need to avoid "arguments from consistency" which reads something like "you allowed this thing A so now you must allow this thing B which is similar". It is not a helpful approach to the problem. Some drivers encode a bunch of data into the device tree, pinctrl-single is the most extreme. This conflict between in-DT and in-driver data storage has been there since pinctrl was created and was the result of a compromise between OMAPs needs and everyone else, especially Tegra. The opinions on this - and it is really opinions, not facts - differ between people and over time. Resolving the conflicts is more about classical diplomacy than science unfortunately. I used to think the christian trinity was amusing and inconsistent, but nowadays I understand exactly how the people who came up with the Nicean creed were reasoning. What is paramount for me as subsystem maintainer is the fact that this driver has an active maintainer. And maintainers is what makes things manageable for me. It would be much easier for you to have your way if you were submitting an entirely new driver. Like this pinmux property, it was submitted by the mediatek people because it fits their usecase/hardware especially well. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html