public inbox for linuxppc-dev@ozlabs.org
 help / color / mirror / Atom feed
From: Koichiro Den <den@valinux.co.jp>
To: jingoohan1@gmail.com, mani@kernel.org, lpieralisi@kernel.org,
	kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
	cassel@kernel.org, Frank.Li@nxp.com
Cc: vigneshr@ti.com, s-vadapalli@ti.com, hongxing.zhu@nxp.com,
	l.stach@pengutronix.de, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, minghuan.Lian@nxp.com, mingkai.hu@nxp.com,
	roy.zang@nxp.com, jesper.nilsson@axis.com, heiko@sntech.de,
	srikanth.thokala@intel.com, marek.vasut+renesas@gmail.com,
	yoshihiro.shimoda.uh@renesas.com, geert+renesas@glider.be,
	magnus.damm@gmail.com, christian.bruel@foss.st.com,
	mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
	thierry.reding@gmail.com, jonathanh@nvidia.com,
	hayashi.kunihiko@socionext.com, mhiramat@kernel.org,
	kishon@kernel.org, jirislaby@kernel.org, rongqianfeng@vivo.com,
	18255117159@163.com, shawn.lin@rock-chips.com,
	nicolas.frattaroli@collabora.com, linux.amoon@gmail.com,
	vidyas@nvidia.com, shuah@kernel.org, linux-omap@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@axis.com,
	linux-rockchip@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-tegra@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH v10 5/8] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage
Date: Sat, 24 Jan 2026 23:50:09 +0900	[thread overview]
Message-ID: <20260124145012.2794108-6-den@valinux.co.jp> (raw)
In-Reply-To: <20260124145012.2794108-1-den@valinux.co.jp>

The current documentation implies that pci_epc_set_bar() is only used
before the host enumerates the endpoint.

In practice, some Endpoint Controllers support calling pci_epc_set_bar()
multiple times for the same BAR (without clearing it) in order to update
inbound address translations after the host has programmed the BAR base
address, which some Endpoint Functions such as vNTB already rely on.
Add document text for that.

Also document the expected call flow for BAR subrange mapping
(pci_epf_bar.num_submap / pci_epf_bar.submap), which may require a
second pci_epc_set_bar() call after the host has programmed the BAR base
address.

Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
 Documentation/PCI/endpoint/pci-endpoint.rst | 24 +++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst
index 0741c8cbd74e..4697377adeae 100644
--- a/Documentation/PCI/endpoint/pci-endpoint.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint.rst
@@ -95,6 +95,30 @@ by the PCI endpoint function driver.
    Register space of the function driver is usually configured
    using this API.
 
+   Some endpoint controllers also support calling pci_epc_set_bar() again
+   for the same BAR (without calling pci_epc_clear_bar()) to update inbound
+   address translations after the host has programmed the BAR base address.
+   Endpoint function drivers can check this capability via the
+   dynamic_inbound_mapping EPC feature bit.
+
+   When pci_epf_bar.num_submap is non-zero, the endpoint function driver is
+   requesting BAR subrange mapping using pci_epf_bar.submap. This requires
+   the EPC to advertise support via the subrange_mapping EPC feature bit.
+
+   When an EPF driver wants to make use of the inbound subrange mapping
+   feature, it requires that the BAR base address has been programmed by
+   the host during enumeration. Thus, it needs to call pci_epc_set_bar()
+   twice for the same BAR (requires dynamic_inbound_mapping): first with
+   num_submap set to zero and configuring the BAR size, then after the PCIe
+   link is up and the host enumerates the endpoint and programs the BAR
+   base address, again with num_submap set to non-zero value.
+
+   Note that when making use of the inbound subrange mapping feature, the
+   EPF driver must not call pci_epc_clear_bar() between the two
+   pci_epc_set_bar() calls, because clearing the BAR can clear/disable the
+   BAR register or BAR decode on the endpoint while the host still expects
+   the assigned BAR address to remain valid.
+
 * pci_epc_clear_bar()
 
    The PCI endpoint function driver should use pci_epc_clear_bar() to reset
-- 
2.51.0



  parent reply	other threads:[~2026-01-24 14:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-24 14:50 [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Koichiro Den
2026-01-24 14:50 ` [PATCH v10 1/8] PCI: endpoint: Add dynamic_inbound_mapping EPC feature Koichiro Den
2026-01-24 14:50 ` [PATCH v10 2/8] PCI: endpoint: Add BAR subrange mapping support Koichiro Den
2026-01-24 14:50 ` [PATCH v10 3/8] PCI: dwc: Advertise dynamic inbound " Koichiro Den
2026-03-13 15:59   ` Christian Bruel
2026-03-13 18:18     ` Bjorn Helgaas
2026-03-16 12:26       ` Christian Bruel
2026-03-14  4:33     ` Koichiro Den
2026-03-16 12:41       ` Christian Bruel
2026-03-16 12:57         ` Niklas Cassel
2026-03-16 13:29           ` Christian Bruel
2026-03-16 13:50             ` Koichiro Den
2026-01-24 14:50 ` [PATCH v10 4/8] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU Koichiro Den
2026-01-26 10:25   ` Niklas Cassel
2026-01-24 14:50 ` Koichiro Den [this message]
2026-01-24 14:50 ` [PATCH v10 6/8] PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support Koichiro Den
2026-01-24 14:50 ` [PATCH v10 7/8] misc: pci_endpoint_test: Add BAR subrange mapping test case Koichiro Den
2026-01-24 14:50 ` [PATCH v10 8/8] selftests: pci_endpoint: " Koichiro Den
2026-01-28 13:47 ` [PATCH v10 0/8] PCI: endpoint: BAR subrange mapping support Manivannan Sadhasivam

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=20260124145012.2794108-6-den@valinux.co.jp \
    --to=den@valinux.co.jp \
    --cc=18255117159@163.com \
    --cc=Frank.Li@nxp.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=christian.bruel@foss.st.com \
    --cc=festevam@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=heiko@sntech.de \
    --cc=hongxing.zhu@nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=jesper.nilsson@axis.com \
    --cc=jingoohan1@gmail.com \
    --cc=jirislaby@kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=kernel@pengutronix.de \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@axis.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux.amoon@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lpieralisi@kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mani@kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=minghuan.Lian@nxp.com \
    --cc=mingkai.hu@nxp.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=robh@kernel.org \
    --cc=rongqianfeng@vivo.com \
    --cc=roy.zang@nxp.com \
    --cc=s-vadapalli@ti.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.lin@rock-chips.com \
    --cc=shawnguo@kernel.org \
    --cc=shuah@kernel.org \
    --cc=srikanth.thokala@intel.com \
    --cc=thierry.reding@gmail.com \
    --cc=vidyas@nvidia.com \
    --cc=vigneshr@ti.com \
    --cc=yoshihiro.shimoda.uh@renesas.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