From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Minghuan Lian" <minghuan.Lian@nxp.com>,
"Mingkai Hu" <mingkai.hu@nxp.com>, "Roy Zang" <roy.zang@nxp.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Srikanth Thokala" <srikanth.thokala@intel.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Kunihiko Hayashi" <hayashi.kunihiko@socionext.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Marek Vasut" <marek.vasut+renesas@gmail.com>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Manikanta Maddireddy" <mmaddireddy@nvidia.com>,
"Koichiro Den" <den@valinux.co.jp>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Frank Li" <Frank.Li@nxp.com>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v3 1/9] PCI: endpoint: Introduce pci_epc_bar_type BAR_64BIT_UPPER
Date: Wed, 11 Mar 2026 11:38:50 +0100 [thread overview]
Message-ID: <abFGOoZUX_vexLWR@fedora> (raw)
In-Reply-To: <dtxdgxrewfby5hu3cu3pu5kljylm627uc43sw75gk7loimmm6r@ei4w6wmqgd6a>
Hello Mani,
On Wed, Mar 11, 2026 at 12:05:59PM +0530, Manivannan Sadhasivam wrote:
(snip)
> This also brings the question, do we really need to mark the preceding BAR?
From a pure code PoV, marking the preceding BAR is enough even with the
current code:
https://github.com/torvalds/linux/blob/v7.0-rc3/drivers/pci/endpoint/pci-epc-core.c#L101-L103
However, the current documentation claims that the succeeding BAR must be
marked as BAR_RESERVED:
https://github.com/torvalds/linux/blob/v7.0-rc3/include/linux/pci-epc.h#L207-L210
I want to change this to BAR_64BIT_UPPER / BAR_64BIT_UPPER_BASE, so we can use
BAR_RESERVED for BARs that expose fixed hardware resources (e.g. eDMA regs).
Thus, an EPC driver does not strictly need mark the succeeding BAR with anything.
This was done mostly for clarity. (E.g. with BAR_64BIT_UPPER_BASE it is obvious
that this BAR cannot be a standalone 32-bit BAR.)
If we don't mark the succeeding BAR with anything, IMO, it is less obvious that
the succeeding BAR cannot be used as a standalone 32-bit BAR.
But... since the code already does the "right thing". We could simply nuke this
part of the documentation, and drop the .type for all BARs succeeding a
.only_64bit BAR, if you prefer that option over having a dedicated type for the
"upper base of a 64-bit BAR".
> Why can't we let the PCI EPC core to always assume that if the previous BAR
> has 'only_64bit' bit set, next BAR cannot be used as a standalone 32bit BAR?
>
> I find it weird or redundant to mark both BARs.
Redundant, yes, but in my opinion marking both BARs makes it unambigious
that two BARs are used when a BAR is "only_64bit".
E.g. Manikanta originally wanted to add code comments for the upper part of
the 64-bit BAR:
https://lore.kernel.org/linux-pci/20260217-master-v1-2-727e26cdfaf5@nvidia.com/
Sure, we can just skip the .type for the succeeding BAR...
But is that really better than clearly showing that a "forced" 64-bit BAR will
always occupy two BARs?
Tell me what you prefer:
1) s/BAR_RESERVED/BAR_64BIT_UPPER_BASE/
2) Change documentation and drop .type for a BAR following a .only_64bit BAR.
And I will respin with that.
Kind regards,
Niklas
next prev parent reply other threads:[~2026-03-11 10:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 9:59 [PATCH v3 0/9] PCI: endpoint: Differentiate between disabled and reserved BARs Niklas Cassel
2026-03-02 9:59 ` [PATCH v3 1/9] PCI: endpoint: Introduce pci_epc_bar_type BAR_64BIT_UPPER Niklas Cassel
2026-03-11 6:35 ` Manivannan Sadhasivam
2026-03-11 10:38 ` Niklas Cassel [this message]
2026-03-11 17:12 ` Manivannan Sadhasivam
2026-03-02 9:59 ` [PATCH v3 5/9] PCI: dwc: Replace certain BAR_RESERVED with BAR_DISABLED in glue drivers Niklas Cassel
2026-03-02 9:59 ` [PATCH v3 6/9] PCI: dwc: Disable BARs in common code instead of in each glue driver 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=abFGOoZUX_vexLWR@fedora \
--to=cassel@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=den@valinux.co.jp \
--cc=dlemoal@kernel.org \
--cc=geert+renesas@glider.be \
--cc=hayashi.kunihiko@socionext.com \
--cc=imx@lists.linux.dev \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--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=mhiramat@kernel.org \
--cc=minghuan.Lian@nxp.com \
--cc=mingkai.hu@nxp.com \
--cc=mmaddireddy@nvidia.com \
--cc=robh@kernel.org \
--cc=roy.zang@nxp.com \
--cc=srikanth.thokala@intel.com \
--cc=thierry.reding@gmail.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