+Frank, Rob, devicetree list On 2/16/21 9:35 AM, Michal Simek wrote: > Hi, > > I have a question about expectations when pinctrl setting is applied. In > DTS all nodes are described in the order available in DT. > > uart-default { > mux { > ... > }; > > conf { > ... > }; > }; > > I don't know if this standard description or not. I definitely see other > pinctrl drivers which are using different structure. > > Anyway when overlay is applied the order has changed to > uart-default { > conf { > ... > }; > > mux { > ... > }; > }; > > which is causing issue because pin is configured first via conf node > before it is requested via mux. This is something what firmware is > checking and error out. > > That's why I want to check with you if this is issue with DT binding > description we use in zynqmp pinctrl driver posted here > https://lore.kernel.org/linux-arm-kernel/1613131643-60062-1-git-send-email-lakshmi.sai.krishna.potthuri@xxxxxxxxxx/ > > I have also tried to use init and default configuration where init is > called just with mux setting and then default is called just with config > but the issue is there as well because in pinctrl_commit_state() > previous state is checked and for MUXes pinmux_disable_setting() is > called which release a pin. And then configuration in default is called > but without requesting pin which fails for the same reason as above. > > That's why my questions are: > Are we using incorrect DT description? > And is there a need sort subnodes in a way that mux should be called > first by core before configuration? > Or is there any different way how to do it? Node ordering and property ordering within a node are not defined in the Linux kernel. If a subsystem or property is depending upon a certain order, they must implement a method other than the order as accessed by of_* functions. And as you noted, use of an overlay may also change ordering. -Frank > > Thanks, > Michal >