From: Chen-Yu Tsai <wenst@chromium.org>
To: Rob Herring <robh@kernel.org>, Manivannan Sadhasivam <mani@kernel.org>
Cc: "Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Ryder Lee" <ryder.lee@mediatek.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
Date: Tue, 9 Jun 2026 12:33:24 +0900 [thread overview]
Message-ID: <CAGXv+5F94K7JJz9pMg5=7-YoXjT_ux8SvBKP17BA36mXYTYo6w@mail.gmail.com> (raw)
In-Reply-To: <CAGXv+5GK6+X3-eY8PbrLTsSwK2Uk2URiQti_Gd_9C=RwRaJ44Q@mail.gmail.com>
On Tue, Jun 2, 2026 at 4:02 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> On Tue, Jun 2, 2026 at 5:48 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, May 19, 2026 at 12:51:49PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, May 18, 2026 at 05:02:11PM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, May 15, 2026 at 8:34 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > >
> > > > > On Fri, May 15, 2026 at 05:16:19PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Thu, May 14, 2026 at 7:48 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > >
> > > > > > > On Thu, May 14, 2026 at 03:54:29PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, May 14, 2026 at 1:23 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, May 08, 2026 at 02:36:32PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > > On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> > > > > > > > > > controller memory access could be limited to a small region by the
> > > > > > > > > > firmware configuring a memory protection unit. This memory region
> > > > > > > > > > must be assigned to the PCIe controller so that the OS knows to
> > > > > > > > > > use that region. Otherwise PCIe devices would not work properly.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > So this means, the PCIe devices can only access a specific carveout memory
> > > > > > > > > configured by MPU for DMA? If so, you should use 'dma-ranges' as suggested by
> > > > > > > > > Rob.
> > > > > > > > >
> > > > > > > > > 'memory-region' also serves the purpose, but for PCI, we have the dedicated
> > > > > > > > > 'dma-ranges' property.
> > > > > > > >
> > > > > > > > I think I need some sort of guide on writing the 'dma-ranges' property,
> > > > > > > > because it is not working for me.
> > > > > > > >
> > > > > > > > I'm adding
> > > > > > > >
> > > > > > > > dma-ranges = <0x42000000 0 0x00000000 0 0xc0000000 0 0x4000000>;
> > > > > > > >
> > > > > > >
> > > > > > > So the device DMA address start from 0x0? Isn't it a 1:1 mapping?
> > > > > >
> > > > > > I actually don't know. But
> > > > > >
> > > > > > > dma-ranges = <0x42000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > > > >
> > > > > > this didn't work either.
> > > > >
> > > > >
> > > > > Hmm. Can you print the DMA address programmed to the device? i.e., the address
> > > > > returned by dma_map_single() in the driver.
> > > >
> > > > On a working system still using the restricted-dma-pool memory region,
> > > > it gives something like 0x00000000c0009000, so indeed it is 1:1 mapping?
> > >
> > > It has to be 1:1 mapping.
> > >
> > > > These are for the RX/TX descriptors [1][2].
> > > >
> > > > When using dma-ranges, the failure is from dma_alloc_coherent() [3][4],
> > > > which is the descriptor ring. On a working system, this is something
> > > > like 0x00000000c0c9d000, so again 1:1.
> > > >
> > > > [1] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L221
> > > > [2] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L829
> > > > [3] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L192
> > > > [4] https://elixir.bootlin.com/linux/v7.0.8/source/drivers/net/wireless/realtek/rtw88/pci.c#L265
> > > >
> > > > > Also, using prefetchable flag is not correct for DMA memory. You should use:
> > > > >
> > > > > dma-ranges = <0x02000000 0 0xc0000000 0 0xc0000000 0 0x4000000>;
> > > >
> > > > This didn't work either. What exactly is supposed to handle dma-ranges?
> > > > I see some code parsing it in the PCI core, but it just saves it to a list.
> > > >
> > >
> > > I think the failure is due to marking the memory as 'reserved' in DT. With
> > > 'dma-ranges', the allocator will only ensure that the allocated memory stays
> > > within this limit. But the allocator itself will not use this property to
> > > allocate from the reserved region.
> >
> > So the region should not be reserved. Reserved generally means the OS
> > shouldn't use the region (though maybe a specific driver/device can). It
> > should just be a CMA area I think.
>
> No. The whole reason for this is that we want an isolated piece of memory
> for PCIe so that PCIe transfers cannot corrupt memory used by other parts
> of the system. Normally the IOMMU provides the isolation. On this platform
> there is no IOMMU for the PCIe controller.
>
> System memory isolation as setup by the firmware already restricts the
> PCIe controller to only be able to use this region. And we absolutely do
> not want any other part of the system, be it kernel, DMA buffers, or
> userspace, to use it.
>
> And also, if it is not reserved, the kernel is free to put "other" reserved
> regions, such as the default CMA region or the software IO TLB region in
> this piece of memory.
>
> So I believe using memory-region is the way to go. The memory needs to be
> reserved, and assigned to just the PCIe controller.
Ping? We need this merged for the coming cycle.
next prev parent reply other threads:[~2026-06-09 3:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 6:36 [PATCH] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer Chen-Yu Tsai
2026-05-08 17:54 ` Bjorn Helgaas
2026-05-11 5:15 ` Chen-Yu Tsai
2026-05-11 10:04 ` AngeloGioacchino Del Regno
2026-05-13 23:15 ` Rob Herring
2026-05-14 8:12 ` Chen-Yu Tsai
2026-05-14 5:23 ` Manivannan Sadhasivam
2026-05-14 7:54 ` Chen-Yu Tsai
2026-05-14 11:48 ` Manivannan Sadhasivam
2026-05-15 9:16 ` Chen-Yu Tsai
2026-05-15 12:34 ` Manivannan Sadhasivam
2026-05-18 9:02 ` Chen-Yu Tsai
2026-05-19 7:21 ` Manivannan Sadhasivam
2026-05-19 8:42 ` Chen-Yu Tsai
2026-06-01 21:48 ` Rob Herring
2026-06-02 7:02 ` Chen-Yu Tsai
2026-06-09 3:33 ` Chen-Yu Tsai [this message]
2026-06-12 14:32 ` Rob Herring (Arm)
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='CAGXv+5F94K7JJz9pMg5=7-YoXjT_ux8SvBKP17BA36mXYTYo6w@mail.gmail.com' \
--to=wenst@chromium.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=ryder.lee@mediatek.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).