On Thu, Nov 11, 2021 at 04:31:28PM +0100, Linus Walleij wrote: > On Thu, Nov 11, 2021 at 12:14 AM Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > > > While working with pinctrl in Linux I started wondering if we could > > start specifying pins in DT instead of Linux drivers. When working with > > DT we usually avoid hardcoding hardware description in drivers so it > > isn't clear to me why it doesn't apply to pins. I thought we were... > Historically this is what pinctrl-single.c does. > Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt > > At the time we created pin control there was a bit back-and-forth and > the conclusion was that there is not one-size-fits all for pin defines. > > The reason TI (Tony) wanted to push the information into DT > was that what he gets is a number of unprocessed ASIC datasets, > that are then turned into tables with a script. Header files or DTS > source alike, but some kind of tables. > > 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. The question is more can the data be static (complete) and correct? That doesn't work for quirk properties nor entire clock trees with a node per clock. Pins? Maybe. That's a flat thing and you should know all the pins up front. Rob
