* Linus Walleij <linus.walleij@xxxxxxxxxx> [211111 15:32]: > At the time (2011?) it was unclear what kind of data should go into > e.g. header and data files in the kernel (modules) and what should > go into the DT. So the approach to put pin information into the DT > was allowed for pinctrl-single. > > The way I have understood it, DT maintainers have since gotten > a bit wary about (ab)using the DT as a container for "anything data" > and prefer that drivers contain details and derive these from > compatible strings. > > As of today, IIUC the DT maintainers are against this scheme. We have some newish tools now compared 2011 though with #pinctrl-cells. And we now have also GENERIC_PINCTRL_GROUPS, GENERIC_PINMUX_FUNCTIONS and GENERIC_PINCONF :) The problem with the pinctrl-single binding is that it uses the hardware specific mux values in addition to the mux register offsets. IMO the values should use Linux generic pinctrl defines instead. Just like we do for the gpio and interrupt bindings. And then the generic pinctrl binding would be very similar to the interrupts-extended binding for example. And with a generic pinctrl binding pinctrl-single could be updated to parse the generic binding naturally too in addition to the legacy binding. > That said, the topic is open in a way. Some people are also annoyed > that some graphics drivers just ask Torvalds to pull 100.000+ lines > of register defnes in some merge windows. The data has to go > somewhere. Yes and the amount of SoC specific LOC under drivers/pinctrl is pretty staggering already. With all that SoC specific data built into the kernel, it's like going camping with all your pants stuffed into your car instead of just the pants you need :) We only need the SoC specific data for the booted SoC, so devicetree and loadable modules makes more sense there compared to the current built-in setup. Regards, Tony
