public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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,
	Frank.Li@nxp.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] PCI: endpoint: BAR subrange mapping support
Date: Tue, 6 Jan 2026 10:30:40 +0100	[thread overview]
Message-ID: <aVzWQIOgdtyjom3Y@fedora> (raw)
In-Reply-To: <gb3mr7onokhufasxaeoxiqft22incwxxlf43m6jcrhrem3477j@63oi3ztvbqku>

On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > 
> > You should also verify that the sum of all the sizes in the pci_epf_bar_submap
> > array adds up to exactly pci_epf_bar->size.
> 
> I didn't think this was a requirement. I experimented with it just now, and
> seems to me that no harm is caused even if the sum of the submap sizes is
> less than the BAR size. Could you point me to any description of this
> requirement in the databook if available?

3.10.7 Inbound Features
"Without address translation, your application address is passed from the
TLPs directly through the application interface."


Thus, when there is not an explicit translation, the DWC controller passes
through a transaction untranslated.

Sure, if there is no physical memory or IO registers at the physical address
corresponding to the PCI address trying to be accessed, no harm done.

But because of the potential security implications, I think it is good to
ensure that the whole PCI address range of the BAR has a physical mapping.


Kind regards,
Niklas

  parent reply	other threads:[~2026-01-06  9:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-05  8:02 [PATCH 0/2] PCI: endpoint: BAR subrange mapping support Koichiro Den
2026-01-05  8:02 ` [PATCH 1/2] PCI: endpoint: Add " Koichiro Den
2026-01-05  8:02 ` [PATCH 2/2] PCI: dwc: ep: Support BAR subrange inbound mapping via address-match iATU Koichiro Den
2026-01-05 16:55 ` [PATCH 0/2] PCI: endpoint: BAR subrange mapping support Niklas Cassel
2026-01-06  1:52   ` Koichiro Den
2026-01-06  3:09     ` Koichiro Den
2026-01-06  9:16       ` Niklas Cassel
2026-01-06 12:39         ` Koichiro Den
2026-01-06  9:30     ` Niklas Cassel [this message]
2026-01-06 12:32       ` 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=aVzWQIOgdtyjom3Y@fedora \
    --to=cassel@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=den@valinux.co.jp \
    --cc=jingoohan1@gmail.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@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