public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: "Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Krzysztof Wilczy���ski" <kw@linux.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] misc: pci_endpoint_test: Set reserved BARs for each SoCs
Date: Tue, 17 Dec 2024 09:19:28 +0100	[thread overview]
Message-ID: <Z2E0EDC3tV76303d@ryzen> (raw)
In-Reply-To: <20241216073941.2572407-2-hayashi.kunihiko@socionext.com>

Hello Hayashisan,

On Mon, Dec 16, 2024 at 04:39:41PM +0900, Kunihiko Hayashi wrote:
> There are bar numbers that cannot be used on the endpoint.
> So instead of SoC-specific conditions, add "reserved_bar" bar number
> bitmap to the SoC data.

I think that it was mistake to put is_am654_pci_dev() checks in
pci_endpoint_test.c in the first place. However, let's not make the
situation worse by introducing a reserved_bar bitmap on the host side as
well.

IMO, we should not have any logic for this the host side at all.


Just like for am654, rk3588 has a BAR (BAR4) that should not be written by
pci_endpoint_test.c (as it exposes the ATU registers in BAR4, so if the
host writes this BAR, all address translation will be broken).

An EPC driver can mark a BAR as reserved and that is exactly was rk3588
does for BAR4:
https://github.com/torvalds/linux/blob/v6.13-rc3/drivers/pci/controller/dwc/pcie-dw-rockchip.c#L300

Marking a BAR as reserved means that an EPF driver should not touch that
BAR at all.

However, this by itself is not enough if the BAR is enabled by default,
in that case we also need to disable the BAR for the host side to not
be able to write to it:
https://github.com/torvalds/linux/blob/v6.13-rc3/drivers/pci/controller/dwc/pcie-dw-rockchip.c#L248-L249


If we look at am654, we can see that it does set BAR0 and BAR1 as reserved:
https://github.com/torvalds/linux/blob/v6.13-rc3/drivers/pci/controller/dwc/pci-keystone.c#L967-L968

The problem is that am654 does not also disable these BARs by default.


If you look at most DWC based EPC drivers:
drivers/pci/controller/dwc/pci-dra7xx.c:                dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pci-imx6.c:          dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pci-layerscape-ep.c:         dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-artpec6.c:              dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-designware-plat.c:              dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-dw-rockchip.c:          dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-qcom-ep.c:              dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-rcar-gen4.c:            dw_pcie_ep_reset_bar(pci, bar);
drivers/pci/controller/dwc/pcie-uniphier-ep.c:          dw_pcie_ep_reset_bar(pci, bar);

They call dw_pcie_ep_reset_bar() in EP init for all BARs.
(An EPF driver will be able to re-enable all BARs that are not marked as
reserved.)

am654 seems to be the exception here.


If you simply add code that disables all BARs by default in am654, you
should be able to remove these ugly is_am654_pci_dev() checks in the host
driver, and the host driver should not be able to write to these reserved
BARs, as they will never get enabled by pci-epf-test.c.


Kind regards,
Niklas

  reply	other threads:[~2024-12-17  8:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16  7:39 [PATCH 1/2] misc: pci_endpoint_test: Fix irq_type to convey the correct type Kunihiko Hayashi
2024-12-16  7:39 ` [PATCH 2/2] misc: pci_endpoint_test: Set reserved BARs for each SoCs Kunihiko Hayashi
2024-12-17  8:19   ` Niklas Cassel [this message]
2024-12-19 11:17     ` Kunihiko Hayashi
2024-12-19 13:08       ` Niklas Cassel
2024-12-23 11:51         ` Kunihiko Hayashi
2024-12-23 12:05           ` Niklas Cassel
2024-12-24 11:39             ` Kunihiko Hayashi

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=Z2E0EDC3tV76303d@ryzen \
    --to=cassel@kernel.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.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