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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <71c301ea-0be7-4349-92d6-93b3ffc9c593@kernel.org>
Date: Wed, 2 Apr 2025 10:45:08 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Rob Herring <robh@...nel.org>,
 Patrice Chotard <patrice.chotard@...s.st.com>
Cc: Conor Dooley <conor+dt@...nel.org>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 christophe.kerello@...s.st.com, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v7 2/7] dt-bindings: memory-controllers: Add STM32 Octo
 Memory Manager controller

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