linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Mikhak <alan.mikhak@sifive.com>
To: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
	lorenzo.pieralisi@arm.com, amurray@thegoodpenguin.co.uk,
	bhelgaas@google.com, kishon@ti.com, paul.walmsley@sifive.com
Cc: Alan Mikhak <alan.mikhak@sifive.com>
Subject: [PATCH] PCI: Warn about MEM resource size being too big
Date: Mon, 30 Mar 2020 17:19:47 -0700	[thread overview]
Message-ID: <1585613987-8453-1-git-send-email-alan.mikhak@sifive.com> (raw)

Output a warning for MEM resource size with
non-zero upper 32-bits.

ATU programming functions limit the size of
the translated region to 4GB by using a u32 size
parameter. Function dw_pcie_prog_outbound_atu()
does not program the upper 32-bit ATU limit
register. This may result in undefined behavior
for resource sizes with non-zero upper 32-bits.

For example, a 128GB address space starting at
physical CPU address of 0x2000000000 with size of
0x2000000000 needs the following values programmed
into the lower and upper 32-bit limit registers:
 0x3fffffff in the upper 32-bit limit register
 0xffffffff in the lower 32-bit limit register

Currently, only the lower 32-bit limit register is
programmed with a value of 0xffffffff but the upper
32-bit limit register is not being programmed.
As a result, the upper 32-bit limit register remains
at its default value after reset of 0x0. This would
be a problem for a 128GB PCIe space because in
effect its size gets reduced to 4GB.

ATU programming functions can be changed to
specify a u64 size parameter for the translated
region. Along with this change, the internal
calculation of the limit address, the address of
the last byte in the translated region, needs to
change such that both the lower 32-bit and upper
32-bit limit registers can be programmed correctly.

Changing the ATU programming functions is high
impact. Without change, this issue can go
unnoticed. A warning may prompt the user to
look into possible issues.

This limitation also means that multiple ATUs
would need to be used to map larger regions.

Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 395feb8ca051..37a8c71ef89a 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -325,6 +325,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
 	struct pci_bus *child;
 	struct pci_host_bridge *bridge;
 	struct resource *cfg_res;
+	resource_size_t mem_size;
 	u32 hdr_type;
 	int ret;
 
@@ -362,7 +363,10 @@ int dw_pcie_host_init(struct pcie_port *pp)
 		case IORESOURCE_MEM:
 			pp->mem = win->res;
 			pp->mem->name = "MEM";
-			pp->mem_size = resource_size(pp->mem);
+			mem_size = resource_size(pp->mem);
+			if (upper_32_bits(mem_size))
+				dev_warn(dev, "MEM resource size too big\n");
+			pp->mem_size = mem_size;
 			pp->mem_bus_addr = pp->mem->start - win->offset;
 			break;
 		case 0:
-- 
2.7.4


             reply	other threads:[~2020-03-31  0:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31  0:19 Alan Mikhak [this message]
2020-03-31 20:12 ` [PATCH] PCI: Warn about MEM resource size being too big Bjorn Helgaas
2020-03-31 20:36   ` Alan Mikhak
2020-04-01 20:29     ` Bjorn Helgaas
2020-04-01 21:01       ` Alan Mikhak
2020-04-01 22:02         ` Alan Mikhak
2020-04-02  0:04           ` Alan Mikhak

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=1585613987-8453-1-git-send-email-alan.mikhak@sifive.com \
    --to=alan.mikhak@sifive.com \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=paul.walmsley@sifive.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;
as well as URLs for NNTP newsgroup(s).