* 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. 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. Regards, Tony
