On 11/06/2025 16:08, Clement LE GOFFIC wrote:
On 6/11/25 08:35, Krzysztof Kozlowski wrote:
On 10/06/2025 15:33, Clement LE GOFFIC wrote:
On 6/10/25 14:38, Krzysztof Kozlowski wrote:
On 10/06/2025 14:02, Clement LE GOFFIC wrote:
On 5/29/25 11:01, Krzysztof Kozlowski wrote:
On 28/05/2025 14:14, Clement LE GOFFIC wrote:
Nodes should not be disabled by default if they are complete. That's why
+ };
+
+ hdp: pinctrl@5002a000 {
+ compatible = "st,stm32mp131-hdp";
+ reg = <0x5002a000 0x400>;
+ clocks = <&rcc HDP>;
status = "disabled";
Why are you disabling it? What is missing?
Nothing is missing just disabled by default.
The node is then enabled when needed in board's dts file.
I asked what is missing. Drop.
Hi Krzysztof, OK I better understand now.
So yes the 'pinctrl-*' properties which are board dependent are lacking.
These are not properties of this node.
Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
I don't get it..
These properties have no meaning here, so the hardware description is
complete. You claim that you miss them thus device is incomplete is just
not correct: these properties do not belong here! They belong to the
board but even there they are totally optional. Why would they be a
required resource?
To remind: we talk here ONLY about required resources.
Yes, 'pinctrl-*' properties belongs to the board and are not required.
So nothing is missing.
This hdp node in the SoC dtsi file can be enabled by default.
But the hdp driver will probe and do nothing because without the
'pinctrl-*' properties from the board files it would not be able to
access to any pin.
Pinctrl has other features in general, including interfaces to userspace
(as pretty often combined with gpio, although not sure if relevant here).
I consider enabling this driver by default in SoC dtsi file as just
increasing the boot time on "every" board.
It's the board dts that requires the hdp and provides the 'pinctrl-*'
properties to connect the hdp to some SoC pin and then to some signal on
the board. For me it's natural to have the status okay only in the board
dts file.
The DTS is not the way to optimize boot processes. It is OS-independent
hardware description. My BSD system for example uses smart driver which
avoids probing, but also my user-space needs this device to talk over
exposed interface, so why choice of Linux probing should affect others?
Best regards,
Krzysztof