From: Chen-Yu Tsai <wenst@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
"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, 2 Jun 2026 15:02:28 +0800 [thread overview]
Message-ID: <CAGXv+5GK6+X3-eY8PbrLTsSwK2Uk2URiQti_Gd_9C=RwRaJ44Q@mail.gmail.com> (raw)
In-Reply-To: <20260601214836.GA37779-robh@kernel.org>
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.
Thanks
ChenYu
next prev parent reply other threads:[~2026-06-02 7:02 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 [this message]
2026-06-09 3:33 ` Chen-Yu Tsai
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+5GK6+X3-eY8PbrLTsSwK2Uk2URiQti_Gd_9C=RwRaJ44Q@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).