public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, magnus.damm@gmail.com,
	p.zabel@pengutronix.de, linux-pci@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update dma-ranges for PCIe
Date: Fri, 19 Sep 2025 11:48:06 +0300	[thread overview]
Message-ID: <a3ce3fd1-6aca-49e4-b86b-75557526d62e@tuxon.dev> (raw)
In-Reply-To: <lunqwki2orbf5gjyo4a5kz6ko3rs5w6fspbantqcv7b2vxe5ku@734remr6z4lp>



On 9/19/25 11:25, Manivannan Sadhasivam wrote:
> On Fri, Sep 19, 2025 at 10:38:52AM +0300, Claudiu Beznea wrote:
>> 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@tuxon.dev> wrote:
>>>> On 9/18/25 12:09, Geert Uytterhoeven wrote:
>>>>> On Fri, 12 Sept 2025 at 14:24, Claudiu <claudiu.beznea@tuxon.dev> wrote:
>>>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>>
>>>>>> 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@sang-engineering.com>
>>>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>>
>>>>> 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's true. But do you really have an usecase to setup inbound window for the
> endpoints? What does the endpoint do with this memory?

I don't have a usecase for this. I did this update just to be safe for the
described scenario.

> 
> - Mani
> 


  reply	other threads:[~2025-09-19  8:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-12 12:24 [PATCH v4 0/6] PCI: rzg3s-host: Add PCIe driver for Renesas RZ/G3S SoC Claudiu
2025-09-12 12:24 ` [PATCH v4 1/6] dt-bindings: PCI: renesas,r9a08g045s33-pcie: Add documentation for the PCIe IP on Renesas RZ/G3S Claudiu
2025-09-12 13:41   ` Krzysztof Kozlowski
2025-09-12 13:45     ` Claudiu Beznea
2025-09-12 12:24 ` [PATCH v4 2/6] PCI: rzg3s-host: Add Renesas RZ/G3S SoC host driver Claudiu
2025-09-19  8:45   ` Manivannan Sadhasivam
2025-09-19  9:28     ` Claudiu Beznea
2025-09-29 17:35       ` Manivannan Sadhasivam
2025-09-12 12:24 ` [PATCH v4 3/6] arm64: dts: renesas: r9a08g045: Add PCIe node Claudiu
2025-09-26  9:45   ` Geert Uytterhoeven
2025-09-12 12:24 ` [PATCH v4 4/6] arm64: dts: renesas: rzg3s-smarc-som: Update dma-ranges for PCIe Claudiu
2025-09-18  9:09   ` Geert Uytterhoeven
2025-09-18  9:47     ` Claudiu Beznea
2025-09-18 10:00       ` Geert Uytterhoeven
2025-09-19  7:38         ` Claudiu Beznea
2025-09-19  7:53           ` Biju Das
2025-09-19  8:25           ` Manivannan Sadhasivam
2025-09-19  8:48             ` Claudiu Beznea [this message]
2025-09-12 12:24 ` [PATCH v4 5/6] arm64: dts: renesas: rzg3s-smarc: Enable PCIe Claudiu
2025-09-26  9:49   ` Geert Uytterhoeven
2025-09-12 12:24 ` [PATCH v4 6/6] arm64: defconfig: Enable PCIe for the Renesas RZ/G3S SoC Claudiu
2025-09-12 13:41   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a3ce3fd1-6aca-49e4-b86b-75557526d62e@tuxon.dev \
    --to=claudiu.beznea@tuxon.dev \
    --cc=bhelgaas@google.com \
    --cc=claudiu.beznea.uj@bp.renesas.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mani@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox