u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Stefan Roese <sr@denx.de>
Cc: u-boot@lists.denx.de, "Pali Rohár" <pali@kernel.org>,
	"Marek Behún" <marek.behun@nic.cz>
Subject: [PATCH u-boot-marvell 09/10] arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge
Date: Thu, 11 Nov 2021 16:35:48 +0100	[thread overview]
Message-ID: <20211111153549.29111-10-kabel@kernel.org> (raw)
In-Reply-To: <20211111153549.29111-1-kabel@kernel.org>

From: Pali Rohár <pali@kernel.org>

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
 drivers/pci/pci-aardvark.c | 54 +++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 8abbc3ffe8..a92f00d0af 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -202,7 +202,7 @@ struct pcie_advk {
 	int			sec_busno;
 	struct udevice		*dev;
 	struct gpio_desc	reset_gpio;
-	u32			cfgcache[(0x34 - 0x10) / 4];
+	u32			cfgcache[(0x3c - 0x10) / 4];
 	bool			cfgcrssve;
 };
 
@@ -389,20 +389,19 @@ static int pcie_advk_read_config(const struct udevice *bus, pci_dev_t bdf,
 	}
 
 	/*
-	 * The configuration space of the PCI Bridge on primary (local) bus is
+	 * The configuration space of the PCI Bridge on primary (first) bus is
 	 * not accessible via PIO transfers like all other PCIe devices. PCI
 	 * Bridge config registers are available directly in Aardvark memory
-	 * space starting at offset zero. Moreover PCI Bridge registers in the
-	 * range 0x10 - 0x34 are not available and register 0x38 (Expansion ROM
-	 * Base Address) is at offset 0x30.
-	 * We therefore read configuration space content of the primary PCI
-	 * Bridge from our virtual cache.
+	 * space starting at offset zero. The PCI Bridge config space is of
+	 * Type 0, but the BAR registers (including ROM BAR) don't have the same
+	 * meaning as in the PCIe specification. Therefore do not access BAR
+	 * registers and non-common registers (those which have different
+	 * meaning for Type 0 and Type 1 config space) of the primary PCI Bridge
+	 * and instead read their content from driver virtual cfgcache[].
 	 */
 	if (busno == pcie->first_busno) {
-		if (offset >= 0x10 && offset < 0x34)
+		if ((offset >= 0x10 && offset < 0x34) || (offset >= 0x38 && offset < 0x3c))
 			data = pcie->cfgcache[(offset - 0x10) / 4];
-		else if ((offset & ~3) == PCI_ROM_ADDRESS1)
-			data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);
 		else
 			data = advk_readl(pcie, offset & ~3);
 
@@ -576,23 +575,22 @@ static int pcie_advk_write_config(struct udevice *bus, pci_dev_t bdf,
 	}
 
 	/*
-	 * As explained in pcie_advk_read_config(), for the configuration
-	 * space of the primary PCI Bridge, we write the content into virtual
-	 * cache.
+	 * As explained in pcie_advk_read_config(), PCI Bridge config registers
+	 * are available directly in Aardvark memory space starting at offset
+	 * zero. Type 1 specific registers are not available, so we write their
+	 * content only into driver virtual cfgcache[].
 	 */
 	if (busno == pcie->first_busno) {
-		if (offset >= 0x10 && offset < 0x34) {
+		if ((offset >= 0x10 && offset < 0x34) ||
+		    (offset >= 0x38 && offset < 0x3c)) {
 			data = pcie->cfgcache[(offset - 0x10) / 4];
 			data = pci_conv_size_to_32(data, value, offset, size);
 			/* This PCI bridge does not have configurable bars */
 			if ((offset & ~3) == PCI_BASE_ADDRESS_0 ||
-			    (offset & ~3) == PCI_BASE_ADDRESS_1)
+			    (offset & ~3) == PCI_BASE_ADDRESS_1 ||
+			    (offset & ~3) == PCI_ROM_ADDRESS1)
 				data = 0x0;
 			pcie->cfgcache[(offset - 0x10) / 4] = data;
-		} else if ((offset & ~3) == PCI_ROM_ADDRESS1) {
-			data = advk_readl(pcie, PCIE_CORE_EXP_ROM_BAR_REG);
-			data = pci_conv_size_to_32(data, value, offset, size);
-			advk_writel(pcie, data, PCIE_CORE_EXP_ROM_BAR_REG);
 		} else {
 			data = advk_readl(pcie, offset & ~3);
 			data = pci_conv_size_to_32(data, value, offset, size);
@@ -830,12 +828,20 @@ static int pcie_advk_setup_hw(struct pcie_advk *pcie)
 	 *
 	 * Note that this Aardvark PCI Bridge does not have a compliant Type 1
 	 * Configuration Space and it even cannot be accessed via Aardvark's
-	 * PCI config space access method. Something like config space is
+	 * PCI config space access method. Aardvark PCI Bridge Config space is
 	 * available in internal Aardvark registers starting at offset 0x0
-	 * and is reported as Type 0. In range 0x10 - 0x34 it has totally
-	 * different registers. So our driver reports Header Type as Type 1 and
-	 * for the above mentioned range redirects access to the virtual
-	 * cfgcache[] buffer, which avoids changing internal Aardvark registers.
+	 * and has format of Type 0 config space.
+	 *
+	 * Moreover Type 0 BAR registers (ranges 0x10 - 0x28 and 0x30 - 0x34)
+	 * have the same format in Marvell's specification as in PCIe
+	 * specification, but their meaning is totally different (and not even
+	 * the same meaning as explained in the corresponding comment in the
+	 * pci_mvebu driver; aardvark is still different).
+	 *
+	 * So our driver converts Type 0 config space to Type 1 and reports
+	 * Header Type as Type 1. Access to BAR registers and to non-existent
+	 * Type 1 registers is redirected to the virtual cfgcache[] buffer,
+	 * which avoids changing unrelated registers.
 	 */
 	reg = advk_readl(pcie, PCIE_CORE_DEV_REV_REG);
 	reg &= ~0xffffff00;
-- 
2.32.0


  parent reply	other threads:[~2021-11-11 15:38 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 15:35 [PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes Marek Behún
2021-11-11 15:35 ` [PATCH u-boot-marvell 01/10] pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe() Marek Behún
2021-11-12 13:59   ` Stefan Roese
2021-11-12 15:44     ` Pali Rohár
2021-11-12 16:07       ` Stefan Roese
2021-11-18 18:06     ` Pali Rohár
2021-11-11 15:35 ` [PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c Marek Behún
2021-11-12 14:01   ` Stefan Roese
2021-11-18 18:01     ` Pali Rohár
2021-11-19  6:55       ` Stefan Roese
2021-11-23 15:59         ` Pali Rohár
2021-11-29  7:46           ` Stefan Roese
2021-11-29  9:06             ` Pali Rohár
2021-11-29  9:22               ` Stefan Roese
2021-11-29 11:47                 ` Pali Rohár
2021-11-29 12:30                   ` Stefan Roese
2021-11-29 13:27                     ` Pali Rohár
2021-11-29 14:28                       ` Pali Rohár
2021-11-29 16:07                         ` Stefan Roese
2021-11-29 17:09                           ` Marek Behún
2021-12-10 11:07                             ` Pali Rohár
2021-12-10 14:23                           ` Pali Rohár
2021-12-13  7:36                             ` Stefan Roese
2021-12-13 10:28                               ` Pali Rohár
2021-11-11 15:35 ` [PATCH u-boot-marvell 03/10] pci: pci_mvebu: Move setup for BAR[0] where other BARs are setup Marek Behún
2021-11-12 14:02   ` Stefan Roese
2021-12-21  8:22   ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 04/10] pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size() Marek Behún
2021-11-12 14:03   ` Stefan Roese
2021-12-21  8:23   ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 05/10] pci: pci_mvebu, pci_aardvark: Fix size of configuration cache Marek Behún
2021-11-12 14:04   ` Stefan Roese
2021-12-15 10:57   ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 06/10] pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge Marek Behún
2021-11-12 14:05   ` Stefan Roese
2021-12-15 10:57   ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 07/10] pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and mbus mapping Marek Behún
2021-11-12 14:18   ` Stefan Roese
2021-11-18 17:46     ` Pali Rohár
2021-11-19  6:27       ` Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 08/10] pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR Marek Behún
2021-11-12 14:19   ` Stefan Roese
2021-12-21  8:23   ` Stefan Roese
2021-11-11 15:35 ` Marek Behún [this message]
2021-11-12 14:19   ` [PATCH u-boot-marvell 09/10] arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge Stefan Roese
2021-11-11 15:35 ` [PATCH u-boot-marvell 10/10] arm: mvebu: turris_mox: Remove extra newline after module topology Marek Behún
2021-11-12 14:20   ` Stefan Roese
2021-12-21  8:23   ` Stefan Roese
2021-12-12 11:23 ` [PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes Pali Rohár
2021-12-13  7:41   ` Stefan Roese
2021-12-13 10:27     ` Pali Rohár
2021-12-15  8:10       ` Stefan Roese
2021-12-16 10:28         ` Pali Rohár
2021-12-18 13:53           ` Stefan Roese
2021-12-20 13:30             ` Pali Rohár
2021-12-21  8:19               ` Stefan Roese
2021-12-21 10:57                 ` Pali Rohár

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=20211111153549.29111-10-kabel@kernel.org \
    --to=kabel@kernel.org \
    --cc=marek.behun@nic.cz \
    --cc=pali@kernel.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /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;
as well as URLs for NNTP newsgroup(s).