[dpdk-stable] patch 'pci: accept 32-bit domain numbers' has been queued to stable release 19.11.3

[luca.boccassi at gmail.com]

Hi,

FYI, your patch has been queued to stable release 19.11.3

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 05/24/20. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Thanks.

Luca Boccassi

---
>From c4d58cd40cf7d8114ccdda5f62999b4a8c52d32f Mon Sep 17 00:00:00 2001
From: Darek Stojaczyk <dariusz.stojaczyk at intel.com>
Date: Tue, 12 May 2020 15:30:57 +0200
Subject: [PATCH] pci: accept 32-bit domain numbers

[ upstream commit 26cfc20feddd9fc5b87842d4c9bda6b9453e2c46 ]

The parsing code was bailing on domains greater than UINT16_MAX,
but domain numbers like that are still valid and present on some systems.
One example is Intel VMD (Volume Management Device), which acts somewhat
as a software-managed PCI switch and its upstream linux driver assigns
all downstream devices a PCI domain of 0x10000.

Parsing a BDF like 10000:01:00.0 was failing before. To fix it, increase
the upper limit of domain number to UINT32_MAX. This matches the size of
struct rte_pci_addr->domain (uint32).

Fixes: af75078fece3 ("first public release")

Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk at intel.com>
Acked-by: Gaetan Rivet <grive at u256.net>
---
 lib/librte_pci/rte_pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c
index d1ab6b414d..ad2cdfebb2 100644
--- a/lib/librte_pci/rte_pci.c
+++ b/lib/librte_pci/rte_pci.c
@@ -72,9 +72,9 @@ pci_dbdf_parse(const char *input, struct rte_pci_addr *dev_addr)
 
 	errno = 0;
 	val = strtoul(in, &end, 16);
-	if (errno != 0 || end[0] != ':' || val > UINT16_MAX)
+	if (errno != 0 || end[0] != ':' || val > UINT32_MAX)
 		return -EINVAL;
-	dev_addr->domain = (uint16_t)val;
+	dev_addr->domain = (uint32_t)val;
 	in = end + 1;
 	in = get_u8_pciaddr_field(in, &dev_addr->bus, ':');
 	if (in == NULL)
-- 
2.20.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2020-05-22 10:37:40.562013852 +0100
+++ 0033-pci-accept-32-bit-domain-numbers.patch	2020-05-22 10:37:39.240414721 +0100
@@ -1,8 +1,10 @@
-From 26cfc20feddd9fc5b87842d4c9bda6b9453e2c46 Mon Sep 17 00:00:00 2001
+From c4d58cd40cf7d8114ccdda5f62999b4a8c52d32f Mon Sep 17 00:00:00 2001
 From: Darek Stojaczyk <dariusz.stojaczyk at intel.com>
 Date: Tue, 12 May 2020 15:30:57 +0200
 Subject: [PATCH] pci: accept 32-bit domain numbers
 
+[ upstream commit 26cfc20feddd9fc5b87842d4c9bda6b9453e2c46 ]
+
 The parsing code was bailing on domains greater than UINT16_MAX,
 but domain numbers like that are still valid and present on some systems.
 One example is Intel VMD (Volume Management Device), which acts somewhat
@@ -14,7 +16,6 @@
 struct rte_pci_addr->domain (uint32).
 
 Fixes: af75078fece3 ("first public release")
-Cc: stable at dpdk.org
 
 Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk at intel.com>
 Acked-by: Gaetan Rivet <grive at u256.net>