From: Niklas Cassel <cassel@kernel.org>
To: Koichiro Den <den@valinux.co.jp>
Cc: jingoohan1@gmail.com, mani@kernel.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
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, Frank.Li@nxp.com, 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
Subject: Re: [PATCH v9 4/5] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU
Date: Fri, 23 Jan 2026 09:51:19 +0100 [thread overview]
Message-ID: <aXM2hwCrziK2I8OL@ryzen> (raw)
In-Reply-To: <l7wknbayighcczjkqfwhbaqrepjtbgxxstgkntoqvnrs7dnm6g@wvmy67ky37pv>
On Fri, Jan 23, 2026 at 10:16:21AM +0900, Koichiro Den wrote:
> >
> > There might be other EPC drivers that don't disable all BARs in their .init(), so I would say that simply checking if the BAR has an address is not sufficient to guarantee that an EPF driver has called set_bar().
> >
>
> Even if an EPC driver does not reset the BAR in their .init() and some
> default translation is left exposed, wouldn't it be safe as long as
> dw_pcie_ep_ib_atu_addr() succeeds in programming inbound mappings for the
> entire BAR?
For e.g. on RK3588, the default HW configuration of the DWC controller has
all 5 BARs as enabled, with a size of 1 GB.
There is no inbound address translation for these BARs by default.
So for it to be safe, the size of the set_bar() call would have to
match the current size of the BAR, but how should the EPF driver know
that when it has not called set_bar() yet?
dw_pcie_ep_read_bar_assigned() does not return the current size of the
BAR. So you can't verify that the set_bar() call has the same size as
the BARs "default size".
>
> That said, such usage apparently contradicts the documented usage (1st
> set_bar with no submap, then with submap) described in the docs and commit
> messages in this series, and allowing it would make things unnecessarily
> complicated. So I agree that adding such a safeguard is the right approach.
>
> >
> > I think the safest option is my second suggestion because then we know that we will only call
> > dw_pcie_ep_ib_atu_addr()
> >
> > When:
> >
> > 1) If ep->epf_bar[bar] is set:
> > https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/controller/dwc/pcie-designware-ep.c#L363
> >
> >
> > 2) All the other requirements to dynamically update a BAR is also met:
> >
> > https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/controller/dwc/pcie-designware-ep.c#L368-L370
> >
>
> That makes sense, and it ensures that the behavior always accords with the
> docs and commit messages in this series.
I think it makes most sense to put the "use_addr_translation = true"
after the check:
/*
* We can only dynamically change a BAR if the new BAR size and
* BAR flags do not differ from the existing configuration.
*/
if (ep->epf_bar[bar]->barno != bar ||
ep->epf_bar[bar]->size != size ||
ep->epf_bar[bar]->flags != flags)
return -EINVAL;
So we know that dw_pcie_ep_ib_atu_addr() is only called when the size is the
same.
Kind regards,
Niklas
WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@kernel.org>
To: Koichiro Den <den@valinux.co.jp>
Cc: jingoohan1@gmail.com, mani@kernel.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
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, Frank.Li@nxp.com, 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
Subject: Re: [PATCH v9 4/5] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU
Date: Fri, 23 Jan 2026 09:51:19 +0100 [thread overview]
Message-ID: <aXM2hwCrziK2I8OL@ryzen> (raw)
In-Reply-To: <l7wknbayighcczjkqfwhbaqrepjtbgxxstgkntoqvnrs7dnm6g@wvmy67ky37pv>
On Fri, Jan 23, 2026 at 10:16:21AM +0900, Koichiro Den wrote:
> >
> > There might be other EPC drivers that don't disable all BARs in their .init(), so I would say that simply checking if the BAR has an address is not sufficient to guarantee that an EPF driver has called set_bar().
> >
>
> Even if an EPC driver does not reset the BAR in their .init() and some
> default translation is left exposed, wouldn't it be safe as long as
> dw_pcie_ep_ib_atu_addr() succeeds in programming inbound mappings for the
> entire BAR?
For e.g. on RK3588, the default HW configuration of the DWC controller has
all 5 BARs as enabled, with a size of 1 GB.
There is no inbound address translation for these BARs by default.
So for it to be safe, the size of the set_bar() call would have to
match the current size of the BAR, but how should the EPF driver know
that when it has not called set_bar() yet?
dw_pcie_ep_read_bar_assigned() does not return the current size of the
BAR. So you can't verify that the set_bar() call has the same size as
the BARs "default size".
>
> That said, such usage apparently contradicts the documented usage (1st
> set_bar with no submap, then with submap) described in the docs and commit
> messages in this series, and allowing it would make things unnecessarily
> complicated. So I agree that adding such a safeguard is the right approach.
>
> >
> > I think the safest option is my second suggestion because then we know that we will only call
> > dw_pcie_ep_ib_atu_addr()
> >
> > When:
> >
> > 1) If ep->epf_bar[bar] is set:
> > https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/controller/dwc/pcie-designware-ep.c#L363
> >
> >
> > 2) All the other requirements to dynamically update a BAR is also met:
> >
> > https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/controller/dwc/pcie-designware-ep.c#L368-L370
> >
>
> That makes sense, and it ensures that the behavior always accords with the
> docs and commit messages in this series.
I think it makes most sense to put the "use_addr_translation = true"
after the check:
/*
* We can only dynamically change a BAR if the new BAR size and
* BAR flags do not differ from the existing configuration.
*/
if (ep->epf_bar[bar]->barno != bar ||
ep->epf_bar[bar]->size != size ||
ep->epf_bar[bar]->flags != flags)
return -EINVAL;
So we know that dw_pcie_ep_ib_atu_addr() is only called when the size is the
same.
Kind regards,
Niklas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-01-23 8:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 8:49 [PATCH v9 0/5] PCI: endpoint: BAR subrange mapping support Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 8:49 ` [PATCH v9 1/5] PCI: endpoint: Add dynamic_inbound_mapping EPC feature Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 8:49 ` [PATCH v9 2/5] PCI: endpoint: Add BAR subrange mapping support Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 9:03 ` Niklas Cassel
2026-01-22 9:03 ` Niklas Cassel
2026-01-22 8:49 ` [PATCH v9 3/5] PCI: dwc: Advertise dynamic inbound " Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 9:00 ` Niklas Cassel
2026-01-22 9:00 ` Niklas Cassel
2026-01-22 8:49 ` [PATCH v9 4/5] PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 9:23 ` Niklas Cassel
2026-01-22 9:23 ` Niklas Cassel
2026-01-22 14:29 ` Koichiro Den
2026-01-22 14:29 ` Koichiro Den
2026-01-22 16:59 ` Niklas Cassel
2026-01-22 16:59 ` Niklas Cassel
2026-01-23 1:16 ` Koichiro Den
2026-01-23 1:16 ` Koichiro Den
2026-01-23 8:51 ` Niklas Cassel [this message]
2026-01-23 8:51 ` Niklas Cassel
2026-01-23 14:28 ` Koichiro Den
2026-01-23 14:28 ` Koichiro Den
2026-01-24 14:22 ` Koichiro Den
2026-01-24 14:22 ` Koichiro Den
2026-01-22 8:49 ` [PATCH v9 5/5] Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage Koichiro Den
2026-01-22 8:49 ` Koichiro Den
2026-01-22 9:07 ` Niklas Cassel
2026-01-22 9:07 ` Niklas Cassel
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=aXM2hwCrziK2I8OL@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=Frank.Li@nxp.com \
--cc=alexandre.torgue@foss.st.com \
--cc=bhelgaas@google.com \
--cc=christian.bruel@foss.st.com \
--cc=den@valinux.co.jp \
--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-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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.