On Fri, Nov 12, 2021 at 2:16 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [211112 11:22]: > > > 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. > > I think you are misunderstanding what I mean here. Ah, okay. Thanks for explaining! > Certainly the driver > needs to know how to deal with the SoC specific hardware. And that we > can easily do that in quite easily already. The device tree data I'm > describing would be similar to the interrupts with instance offset and > generic mux flags. > > See for example the driver for drivers/pinctrl/ti/pinctrl-ti-iodelay.c. > For that driver we have the instance and picosecond iodelay values in > the devicetree, and with #nr-pinctrl cells there could be some generic > pinctrl mux flags. We are missing the generic pinctrl flags part AFAIK. > > > And last but not least the copying it in tons of DT feels like a > > duplication effort., > > Hmm I don't think we have any of that for what I'm describing. But > please take a look at the iodelay example above, maybe I'm not > following. > > > AFAIU the topic, the pin control lacks labeling schema that will > > provide the view from the platform perspective, while driver provides > > from HW perspective. > > Agreed we need a generic labeling schema. -- With Best Regards, Andy Shevchenko
