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] [day] [month] [year] [list]

Message-ID: <20250402134725.GA145044-robh@kernel.org>
Date: Wed, 2 Apr 2025 08:47:25 -0500
From: Rob Herring <robh@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Patrice Chotard <patrice.chotard@...s.st.com>,
	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 Wed, Apr 02, 2025 at 10:45:08AM +0200, Krzysztof Kozlowski wrote:
> 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

Okay, fair enough.

Rob