On Fri, Nov 12, 2021 at 12:16 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * 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. I'm against putting that into DT and here is why. DT is the thing that describes the _platform_. While it's fine to put GPIO expander thingy (and we actually do this with labeling schema for GPIOs, right?), the SoC level of things is a _hardware_ and with all flexibility the DT gives us we will definitely have a deviations on _different_ platforms with _the same_ SoC! To work around this we must have a validation of the pin names and their functions in many places. And last but not least the copying it in tons of DT feels like a duplication effort., AFAIU the topic, the pin control lacks labeling schema that will provide the view from the platform perspective, while driver provides from HW perspective. -- With Best Regards, Andy Shevchenko
