Re: DT overlay applied via pinctrl description

[Frank Rowand]

+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
>