From: Frank Li <Frank.li@nxp.com>
To: Koichiro Den <den@valinux.co.jp>
Cc: ntb@lists.linux.dev, linux-pci@vger.kernel.org,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
mani@kernel.org, kwilczynski@kernel.org, kishon@kernel.org,
bhelgaas@google.com, corbet@lwn.net, vkoul@kernel.org,
jdmason@kudzu.us, dave.jiang@intel.com, allenbh@gmail.com,
Basavaraj.Natikar@amd.com, Shyam-sundar.S-k@amd.com,
kurt.schwemmer@microsemi.com, logang@deltatee.com,
jingoohan1@gmail.com, lpieralisi@kernel.org, robh@kernel.org,
jbrunet@baylibre.com, fancer.lancer@gmail.com, arnd@arndb.de,
pstanner@redhat.com, elfring@users.sourceforge.net
Subject: Re: [RFC PATCH v2 04/27] PCI: endpoint: Add inbound mapping ops to EPC core
Date: Tue, 2 Dec 2025 10:58:08 -0500 [thread overview]
Message-ID: <aS8MkMlNOaLANauE@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <dqqewhnmesylgqmj7vohhwxs3aqemysgkymayst4p24yhkgszv@prztzziimnx5>
On Tue, Dec 02, 2025 at 03:25:31PM +0900, Koichiro Den wrote:
> On Mon, Dec 01, 2025 at 02:19:55PM -0500, Frank Li wrote:
> > On Sun, Nov 30, 2025 at 01:03:42AM +0900, Koichiro Den wrote:
> > > Add new EPC ops map_inbound() and unmap_inbound() for mapping a subrange
> > > of a BAR into CPU space. These will be implemented by controller drivers
> > > such as DesignWare.
> > >
> > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > ---
> > > drivers/pci/endpoint/pci-epc-core.c | 44 +++++++++++++++++++++++++++++
> > > include/linux/pci-epc.h | 11 ++++++++
> > > 2 files changed, 55 insertions(+)
> > >
> > > diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> > > index ca7f19cc973a..825109e54ba9 100644
> > > --- a/drivers/pci/endpoint/pci-epc-core.c
> > > +++ b/drivers/pci/endpoint/pci-epc-core.c
> > > @@ -444,6 +444,50 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > }
> > > EXPORT_SYMBOL_GPL(pci_epc_map_addr);
> > >
> > > +/**
> > > + * pci_epc_map_inbound() - map a BAR subrange to the local CPU address
> > > + * @epc: the EPC device on which BAR has to be configured
> > > + * @func_no: the physical endpoint function number in the EPC device
> > > + * @vfunc_no: the virtual endpoint function number in the physical function
> > > + * @epf_bar: the struct epf_bar that contains the BAR information
> > > + * @offset: byte offset from the BAR base selected by the host
> > > + *
> > > + * Invoke to configure the BAR of the endpoint device and map a subrange
> > > + * selected by @offset to a CPU address.
> > > + *
> > > + * Returns 0 on success, -EOPNOTSUPP if unsupported, or a negative errno.
> > > + */
> > > +int pci_epc_map_inbound(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset)
> >
> > Supposed need size information? if BAR's size is 4G,
> >
> > you may just want to map from 0x4000 to 0x5000, not whole offset to end's
> > space.
>
> That sounds reasonable, the interface should accept a size parameter so that it
> is flexible enough to configure arbitrary sub-ranges inside a BAR, instead of
> implicitly using "offset to end of BAR".
>
> For the ntb_transport use_remote_edma=1 testing on R‑Car S4 I only needed at
> most two sub-ranges inside one BAR, so a size parameter was not strictly
> necessary in that setup, but I agree that the current interface looks
> half-baked and not very generic. I'll extend it to take size as well.
>
> >
> > commit message said map into CPU space, where CPU address?
>
> The interface currently requires a pointer to a struct pci_epf_bar instance and
> uses its phys_addr field as the CPU physical base address.
> I'm not fully convinced that using struct pci_epf_bar this way is the cleanest
> approach, so I'm open to better suggestions if you have any.
struct pci_epf_bar already have phys_addr and size information.
pci_epc_set_bars(..., struct pci_epf_bar *epf_bar, size_t num_of_bar)
to set many memory regions to one bar space. when num_of_bar is 1, fallback
to exitting pci_epc_set_bar().
If there are IOMMU in EP system, maybe use IOMMU to map to difference place
is easier.
Frank
>
> Koichiro
>
> >
> > Frank
> > > +{
> > > + if (!epc || !epc->ops || !epc->ops->map_inbound)
> > > + return -EOPNOTSUPP;
> > > +
> > > + return epc->ops->map_inbound(epc, func_no, vfunc_no, epf_bar, offset);
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_epc_map_inbound);
> > > +
> > > +/**
> > > + * pci_epc_unmap_inbound() - unmap a previously mapped BAR subrange
> > > + * @epc: the EPC device on which the inbound mapping was programmed
> > > + * @func_no: the physical endpoint function number in the EPC device
> > > + * @vfunc_no: the virtual endpoint function number in the physical function
> > > + * @epf_bar: the struct epf_bar used when the mapping was created
> > > + * @offset: byte offset from the BAR base that was mapped
> > > + *
> > > + * Invoke to remove a BAR subrange mapping created by pci_epc_map_inbound().
> > > + * If the controller has no support, this call is a no-op.
> > > + */
> > > +void pci_epc_unmap_inbound(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset)
> > > +{
> > > + if (!epc || !epc->ops || !epc->ops->unmap_inbound)
> > > + return;
> > > +
> > > + epc->ops->unmap_inbound(epc, func_no, vfunc_no, epf_bar, offset);
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_epc_unmap_inbound);
> > > +
> > > /**
> > > * pci_epc_mem_map() - allocate and map a PCI address to a CPU address
> > > * @epc: the EPC device on which the CPU address is to be allocated and mapped
> > > diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> > > index 4286bfdbfdfa..a5fb91cc2982 100644
> > > --- a/include/linux/pci-epc.h
> > > +++ b/include/linux/pci-epc.h
> > > @@ -71,6 +71,8 @@ struct pci_epc_map {
> > > * region
> > > * @map_addr: ops to map CPU address to PCI address
> > > * @unmap_addr: ops to unmap CPU address and PCI address
> > > + * @map_inbound: ops to map a subrange inside a BAR to CPU address.
> > > + * @unmap_inbound: ops to unmap a subrange inside a BAR and CPU address.
> > > * @set_msi: ops to set the requested number of MSI interrupts in the MSI
> > > * capability register
> > > * @get_msi: ops to get the number of MSI interrupts allocated by the RC from
> > > @@ -99,6 +101,10 @@ struct pci_epc_ops {
> > > phys_addr_t addr, u64 pci_addr, size_t size);
> > > void (*unmap_addr)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > phys_addr_t addr);
> > > + int (*map_inbound)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset);
> > > + void (*unmap_inbound)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset);
> > > int (*set_msi)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > u8 nr_irqs);
> > > int (*get_msi)(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
> > > @@ -286,6 +292,11 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > u64 pci_addr, size_t size);
> > > void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > phys_addr_t phys_addr);
> > > +
> > > +int pci_epc_map_inbound(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset);
> > > +void pci_epc_unmap_inbound(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > + struct pci_epf_bar *epf_bar, u64 offset);
> > > int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no, u8 nr_irqs);
> > > int pci_epc_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
> > > int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no, u16 nr_irqs,
> > > --
> > > 2.48.1
> > >
next prev parent reply other threads:[~2025-12-02 15:58 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-29 16:03 [RFC PATCH v2 00/27] NTB transport backed by remote DW eDMA Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 01/27] PCI: endpoint: pci-epf-vntb: Use array_index_nospec() on mws_size[] access Koichiro Den
2025-12-01 18:59 ` Frank Li
2025-11-29 16:03 ` [RFC PATCH v2 02/27] PCI: endpoint: pci-epf-vntb: Add mwN_offset configfs attributes Koichiro Den
2025-12-01 19:11 ` Frank Li
2025-12-02 6:23 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 03/27] NTB: epf: Handle mwN_offset for inbound MW regions Koichiro Den
2025-12-01 19:14 ` Frank Li
2025-12-02 6:23 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 04/27] PCI: endpoint: Add inbound mapping ops to EPC core Koichiro Den
2025-12-01 19:19 ` Frank Li
2025-12-02 6:25 ` Koichiro Den
2025-12-02 15:58 ` Frank Li [this message]
2025-12-03 14:12 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 05/27] PCI: dwc: ep: Implement EPC inbound mapping support Koichiro Den
2025-12-01 19:32 ` Frank Li
2025-12-02 6:26 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 06/27] PCI: endpoint: pci-epf-vntb: Use pci_epc_map_inbound() for MW mapping Koichiro Den
2025-12-01 19:34 ` Frank Li
2025-12-02 6:26 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 07/27] NTB: Add offset parameter to MW translation APIs Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 08/27] PCI: endpoint: pci-epf-vntb: Propagate MW offset from configfs when present Koichiro Den
2025-12-01 19:35 ` Frank Li
2025-11-29 16:03 ` [RFC PATCH v2 09/27] NTB: ntb_transport: Support offsetted partial memory windows Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 10/27] NTB: core: Add .get_pci_epc() to ntb_dev_ops Koichiro Den
2025-12-01 19:39 ` Frank Li
2025-12-02 6:31 ` Koichiro Den
2025-12-01 21:08 ` Dave Jiang
2025-12-02 6:32 ` Koichiro Den
2025-12-02 14:49 ` Dave Jiang
2025-12-03 15:02 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 11/27] NTB: epf: vntb: Implement .get_pci_epc() callback Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 12/27] damengine: dw-edma: Fix MSI data values for multi-vector IMWr interrupts Koichiro Den
2025-12-01 19:46 ` Frank Li
2025-12-02 6:32 ` Koichiro Den
2025-12-18 6:52 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 13/27] NTB: ntb_transport: Use seq_file for QP stats debugfs Koichiro Den
2025-12-01 19:50 ` Frank Li
2025-12-02 6:33 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 14/27] NTB: ntb_transport: Move TX memory window setup into setup_qp_mw() Koichiro Den
2025-12-01 20:02 ` Frank Li
2025-12-02 6:33 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 15/27] NTB: ntb_transport: Dynamically determine qp count Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 16/27] NTB: ntb_transport: Introduce get_dma_dev() helper Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 17/27] NTB: epf: Reserve a subset of MSI vectors for non-NTB users Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 18/27] NTB: ntb_transport: Introduce ntb_transport_backend_ops Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 19/27] PCI: dwc: ep: Cache MSI outbound iATU mapping Koichiro Den
2025-12-01 20:41 ` Frank Li
2025-12-02 6:35 ` Koichiro Den
2025-12-02 9:32 ` Niklas Cassel
2025-12-02 15:20 ` Frank Li
2025-12-03 8:40 ` Koichiro Den
2025-12-03 10:39 ` Niklas Cassel
2025-12-03 14:36 ` Koichiro Den
2025-12-03 14:40 ` Koichiro Den
2025-12-04 17:10 ` Frank Li
2025-12-05 16:28 ` Frank Li
2025-12-02 6:32 ` Niklas Cassel
2025-12-03 8:30 ` Koichiro Den
2025-12-03 10:19 ` Niklas Cassel
2025-12-03 14:56 ` Koichiro Den
2025-12-08 7:57 ` Niklas Cassel
2025-12-09 8:15 ` Niklas Cassel
2025-12-12 3:56 ` Koichiro Den
2025-12-22 5:10 ` Krishna Chaitanya Chundru
2025-12-22 7:50 ` Niklas Cassel
2025-12-22 8:14 ` Krishna Chaitanya Chundru
2025-12-22 10:21 ` Manivannan Sadhasivam
2025-12-12 3:38 ` Manivannan Sadhasivam
2025-12-18 8:28 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 20/27] NTB: ntb_transport: Introduce remote eDMA backed transport mode Koichiro Den
2025-12-01 21:41 ` Frank Li
2025-12-02 6:43 ` Koichiro Den
2025-12-02 15:42 ` Frank Li
2025-12-03 8:53 ` Koichiro Den
2025-12-03 16:14 ` Frank Li
2025-12-04 15:42 ` Koichiro Den
2025-12-04 20:16 ` Frank Li
2025-12-05 3:04 ` Koichiro Den
2025-12-05 15:06 ` Frank Li
2025-12-18 4:34 ` Koichiro Den
2025-12-01 21:46 ` Dave Jiang
2025-12-02 6:59 ` Koichiro Den
2025-12-02 14:53 ` Dave Jiang
2025-12-03 14:19 ` Koichiro Den
2025-11-29 16:03 ` [RFC PATCH v2 21/27] NTB: epf: Provide db_vector_count/db_vector_mask callbacks Koichiro Den
2025-11-29 16:04 ` [RFC PATCH v2 22/27] ntb_netdev: Multi-queue support Koichiro Den
2025-11-29 16:04 ` [RFC PATCH v2 23/27] NTB: epf: Add per-SoC quirk to cap MRRS for DWC eDMA (128B for R-Car) Koichiro Den
2025-12-01 20:47 ` Frank Li
2025-11-29 16:04 ` [RFC PATCH v2 24/27] iommu: ipmmu-vmsa: Add PCIe ch0 to devices_allowlist Koichiro Den
2025-11-29 16:04 ` [RFC PATCH v2 25/27] iommu: ipmmu-vmsa: Add support for reserved regions Koichiro Den
2025-11-29 16:04 ` [RFC PATCH v2 26/27] arm64: dts: renesas: Add Spider RC/EP DTs for NTB with remote DW PCIe eDMA Koichiro Den
2025-11-29 16:04 ` [RFC PATCH v2 27/27] NTB: epf: Add an additional memory window (MW2) barno mapping on Renesas R-Car Koichiro Den
2025-12-01 22:02 ` [RFC PATCH v2 00/27] NTB transport backed by remote DW eDMA Frank Li
2025-12-02 6:20 ` Koichiro Den
2025-12-02 16:07 ` Frank Li
2025-12-03 8:43 ` Koichiro Den
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=aS8MkMlNOaLANauE@lizhi-Precision-Tower-5810 \
--to=frank.li@nxp.com \
--cc=Basavaraj.Natikar@amd.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=allenbh@gmail.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=dave.jiang@intel.com \
--cc=den@valinux.co.jp \
--cc=dmaengine@vger.kernel.org \
--cc=elfring@users.sourceforge.net \
--cc=fancer.lancer@gmail.com \
--cc=jbrunet@baylibre.com \
--cc=jdmason@kudzu.us \
--cc=jingoohan1@gmail.com \
--cc=kishon@kernel.org \
--cc=kurt.schwemmer@microsemi.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=ntb@lists.linux.dev \
--cc=pstanner@redhat.com \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/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