Re: [PATCH v7 2/7] dt-bindings: memory-controllers: Add STM32 Octo Memory Manager controller

[Krzysztof Kozlowski <krzk@kernel.org>]

On 02/04/2025 00:20, Rob Herring wrote:
>> +      clocks = <&rcc CK_BUS_OSPIIOM>,
>> +               <&scmi_clk CK_SCMI_OSPI1>,
>> +               <&scmi_clk CK_SCMI_OSPI2>;
>> +      clock-names = "omm", "ospi1", "ospi2";
>> +      resets = <&rcc OSPIIOM_R>,
>> +               <&scmi_reset RST_SCMI_OSPI1>,
>> +               <&scmi_reset RST_SCMI_OSPI2>;
>> +      reset-names = "omm", "ospi1", "ospi2";
>> +      access-controllers = <&rifsc 111>;
>> +      power-domains = <&CLUSTER_PD>;
>> +      #address-cells = <2>;
>> +      #size-cells = <1>;
>> +      st,syscfg-amcr = <&syscfg 0x2c00 0x7>;
>> +      st,omm-req2ack-ns = <0>;
>> +      st,omm-mux = <0>;
>> +      st,omm-cssel-ovr = <0>;
>> +
>> +      spi@0 {
>> +        compatible = "st,stm32mp25-ospi";
>> +        reg = <0 0 0x400>;
>> +        memory-region = <&mm_ospi1>;
>> +        interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
>> +        dmas = <&hpdma 2 0x62 0x00003121 0x0>,
>> +               <&hpdma 2 0x42 0x00003112 0x0>;
>> +        dma-names = "tx", "rx";
>> +        clocks = <&scmi_clk CK_SCMI_OSPI1>;
>> +        resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>;
> 
> Looks like you are duplicating properties in the parent and child nodes. 
> Maybe that accurately models the h/w, but if it is just so the drivers 
> can get the resources from "the driver's node", you can always just look 
> in the child nodes for the resources (as probably you want to drop the 
> per instance resources from the parent).


The current solution was actually my suggestion because if a parent
device has to toggle child's reset, it means it actually is the consumer
of that reset one way or another. IOW, it is one of its resources.

This also might matter for some of the implementations because we might
need to setup device links or do some probe-ordering (in the future)
between parent and the reset provider.

Without reset resource in the parent, I could imagine probe order:
1. parent (pokes into the child for reset)
2. reset and clock providers
3. child
which would defer between 1 and 2.

With parent having the resource it would be re-ordered into:
1. reset and clock providers
2. parent
3. child


Best regards,
Krzysztof