RE: [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update dma-ranges for PCIe

[Biju Das]

> -----Original Message-----
> From: Claudiu Beznea <claudiu.beznea@xxxxxxxxx>
> Sent: 19 September 2025 08:39
> To: geert <geert@xxxxxxxxxxxxxx>
> Cc: bhelgaas@xxxxxxxxxx; lpieralisi@xxxxxxxxxx; kwilczynski@xxxxxxxxxx; mani@xxxxxxxxxx;
> robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx; magnus.damm <magnus.damm@xxxxxxxxx>;
> p.zabel@xxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Claudiu Beznea
> <claudiu.beznea.uj@xxxxxxxxxxxxxx>; wsa+renesas <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update dma-ranges for PCIe
> 
> Hi, Geert,
> 
> On 9/18/25 13:00, Geert Uytterhoeven wrote:
> > Hi Claudiu,
> >
> > On Thu, 18 Sept 2025 at 11:47, Claudiu Beznea <claudiu.beznea@xxxxxxxxx> wrote:
> >> On 9/18/25 12:09, Geert Uytterhoeven wrote:
> >>> On Fri, 12 Sept 2025 at 14:24, Claudiu <claudiu.beznea@xxxxxxxxx> wrote:
> >>>> From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
> >>>>
> >>>> The first 128MB of memory is reserved on this board for secure area.
> >>>> Secure area is a RAM region used by firmware. The
> >>>> rzg3s-smarc-som.dtsi memory node (memory@48000000) excludes the secure area.
> >>>> Update the PCIe dma-ranges property to reflect this.
> >>>>
> >>>> Tested-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
> >>>
> >>> Thanks for your patch!
> >>>
> >>>> --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> >>>> +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
> >>>> @@ -214,6 +214,16 @@ &sdhi2 {
> >>>>  };
> >>>>  #endif
> >>>>
> >>>> +&pcie {
> >>>> +       /* First 128MB is reserved for secure area. */
> >>>
> >>> Do you really have to take that into account here?  I believe that
> >>> 128 MiB region will never be used anyway, as it is excluded from the
> >>> memory map (see memory@48000000).
> >>>
> >>>> +       dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0x0
> >>>> + 0x38000000>;
> >>>
> >>> Hence shouldn't you add
> >>>
> >>>     dma-ranges = <0x42000000 0 0x48000000 0 0x48000000 0x0
> >>> 0x38000000>;
> >
> > Oops, I really meant (forgot to edit after copying it):
> >
> >     dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x0
> > 0x40000000>;
> >
> >>>
> >>> to the pcie node in arch/arm64/boot/dts/renesas/r9a08g045s33.dtsi
> >>> instead, like is done for all other Renesas SoCs that have PCIe?
> >>
> >> I chose to add it here as the rzg3s-smarc-som.dtsi is the one that
> >> defines the available memory for board, as the available memory is
> >> something board dependent.
> >
> > But IMHO it is independent from the amount of memory on the board.
> > On other SoCs, it has a comment:
> >
> >      /* Map all possible DDR as inbound ranges */
> >
> >>
> >> If you consider it is better to have it in the SoC file, please let me know.
> >
> > Hence yes please.
> >
> > However, I missed you already have:
> >
> >     /* Map all possible DRAM ranges (4 GB). */
> >     dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0x1 0x0>;
> >
> > in r9a08g045.dtsi, so life's good.
> >
> > +
> >>>> +};
> >>>> +
> >>>> +&pcie_port0 {
> >>>> +       clocks = <&versa3 5>;
> >>>> +       clock-names = "ref";
> >>>> +};
> >>>
> >>> This is not related.
> >>
> >> Ah, right! Could you please let me know if you prefer to have another
> >> patch or to update the patch description?
> >
> > Given the dma-ranges changes is IMHO not needed,
> 
> I kept it here as the driver configures the PCIe registers for the inbound windows with the values
> passed though the dma-ranges. This is done through
> rzg3s_pcie_set_inbound_windows() -> rzg3s_pcie_set_inbound_window(). The controller will be aware that
> the secure area zone is something valid to work with. In that case, if my understanding of PCIe windows
> is right, I added this in the idea that an endpoint (a malicious one?) could DMA into/from secure area
> if we don't exclude it here?

That is an interesting issue. The endpoint (malicious one) should get DATA abort in that case.

Cheers,
Biju