* [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits
@ 2019-04-02 1:33 marek.vasut
2019-04-02 1:33 ` [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
` (5 more replies)
0 siblings, 6 replies; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
From: Marek Vasut <marek.vasut+renesas@gmail.com>
Replace macros using constants with BIT()s instead, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V2: Bundle this patch with other cleanups before resending
V3: Add Wolfram's R-B
V4: Add Geert's R-B
V5: Rebase on next/master 20190401
---
drivers/pci/controller/pcie-rcar.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index 6a4e435bd35f..542b5bbf4bf1 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -47,14 +47,14 @@
/* Transfer control */
#define PCIETCTLR 0x02000
#define DL_DOWN BIT(3)
-#define CFINIT 1
+#define CFINIT BIT(0)
#define PCIETSTR 0x02004
-#define DATA_LINK_ACTIVE 1
+#define DATA_LINK_ACTIVE BIT(0)
#define PCIEERRFR 0x02020
#define UNSUPPORTED_REQUEST BIT(4)
#define PCIEMSIFR 0x02044
#define PCIEMSIALR 0x02048
-#define MSIFE 1
+#define MSIFE BIT(0)
#define PCIEMSIAUR 0x0204c
#define PCIEMSIIER 0x02050
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
@ 2019-04-02 1:33 ` marek.vasut
2019-04-03 9:27 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
` (4 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
From: Marek Vasut <marek.vasut+renesas@gmail.com>
Replace unsigned long with u32 and unsigned int in register accessor
functions, since they access 32bit registers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V2: Bundle this patch with other cleanups before resending
V3: Add Wolfram's R-B
V4: Change reg to unsigned int
V5: Rebase on next/master 20190401
---
drivers/pci/controller/pcie-rcar.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index 542b5bbf4bf1..317f688b1fd2 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -154,14 +154,13 @@ struct rcar_pcie {
struct rcar_msi msi;
};
-static void rcar_pci_write_reg(struct rcar_pcie *pcie, unsigned long val,
- unsigned long reg)
+static void rcar_pci_write_reg(struct rcar_pcie *pcie, u32 val,
+ unsigned int reg)
{
writel(val, pcie->base + reg);
}
-static unsigned long rcar_pci_read_reg(struct rcar_pcie *pcie,
- unsigned long reg)
+static u32 rcar_pci_read_reg(struct rcar_pcie *pcie, unsigned int reg)
{
return readl(pcie->base + reg);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-04-02 1:33 ` [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
@ 2019-04-02 1:33 ` marek.vasut
2019-04-02 6:24 ` Wolfram Sang
2019-04-03 9:28 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
` (3 subsequent siblings)
5 siblings, 2 replies; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc
From: Marek Vasut <marek.vasut+renesas@gmail.com>
Replace various variable types with u32 or unsigned int type for
variables holding register values, since the registers are 32bit.
Note that rcar_pcie_msi_irq() still uses various variable types
because both find_first_bit() and __fls() require various variable
types as an argument.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V2: - s@unsigned long@various variable types@ in the commit message
- Replace int with unsigned int for the $shift variable
- Replace int with unsigned int / u32 in rcar_pcie_config_access()
V3: - Change shift from u32 to unsigned int
- Change addr and data in phy_write_reg() from unsigned int to u32
V4: - Change reg to unsigned int in rcar_pcie_config_access()
V5: Rebase on next/master 20190401
---
drivers/pci/controller/pcie-rcar.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index 317f688b1fd2..9d0e63945842 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -172,7 +172,7 @@ enum {
static void rcar_rmw32(struct rcar_pcie *pcie, int where, u32 mask, u32 data)
{
- int shift = 8 * (where & 3);
+ unsigned int shift = 8 * (where & 3);
u32 val = rcar_pci_read_reg(pcie, where & ~3);
val &= ~(mask << shift);
@@ -182,7 +182,7 @@ static void rcar_rmw32(struct rcar_pcie *pcie, int where, u32 mask, u32 data)
static u32 rcar_read_conf(struct rcar_pcie *pcie, int where)
{
- int shift = 8 * (where & 3);
+ unsigned int shift = 8 * (where & 3);
u32 val = rcar_pci_read_reg(pcie, where & ~3);
return val >> shift;
@@ -193,7 +193,7 @@ static int rcar_pcie_config_access(struct rcar_pcie *pcie,
unsigned char access_type, struct pci_bus *bus,
unsigned int devfn, int where, u32 *data)
{
- int dev, func, reg, index;
+ unsigned int dev, func, reg, index;
dev = PCI_SLOT(devfn);
func = PCI_FUNC(devfn);
@@ -297,8 +297,9 @@ static int rcar_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 val)
{
struct rcar_pcie *pcie = bus->sysdata;
- int shift, ret;
+ unsigned int shift;
u32 data;
+ int ret;
ret = rcar_pcie_config_access(pcie, RCAR_PCI_ACCESS_READ,
bus, devfn, where, &data);
@@ -508,10 +509,10 @@ static int phy_wait_for_ack(struct rcar_pcie *pcie)
}
static void phy_write_reg(struct rcar_pcie *pcie,
- unsigned int rate, unsigned int addr,
- unsigned int lane, unsigned int data)
+ unsigned int rate, u32 addr,
+ unsigned int lane, u32 data)
{
- unsigned long phyaddr;
+ u32 phyaddr;
phyaddr = WRITE_CMD |
((rate & 1) << RATE_POS) |
@@ -1119,7 +1120,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rcar_pcie *pcie;
- unsigned int data;
+ u32 data;
int err;
int (*phy_init_fn)(struct rcar_pcie *);
struct pci_host_bridge *bridge;
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-04-02 1:33 ` [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
2019-04-02 1:33 ` [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
@ 2019-04-02 1:33 ` marek.vasut
2019-04-03 9:27 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 5/6] PCI: rcar: Clean up debug messages marek.vasut
` (2 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
From: Marek Vasut <marek.vasut+renesas@gmail.com>
Replace (8 * n) with (BITS_PER_BYTE * n) to make bit shift operations
consistent. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V2: Bundle this patch with other cleanups before resending
V3: Add Wolfram's R-B
V4: Change the patch from n << 3 to BITS_PER_BYTE * n
V5: Rebase on next/master 20190401
---
drivers/pci/controller/pcie-rcar.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index 9d0e63945842..d9b8c7cd9fba 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -172,7 +172,7 @@ enum {
static void rcar_rmw32(struct rcar_pcie *pcie, int where, u32 mask, u32 data)
{
- unsigned int shift = 8 * (where & 3);
+ unsigned int shift = BITS_PER_BYTE * (where & 3);
u32 val = rcar_pci_read_reg(pcie, where & ~3);
val &= ~(mask << shift);
@@ -182,7 +182,7 @@ static void rcar_rmw32(struct rcar_pcie *pcie, int where, u32 mask, u32 data)
static u32 rcar_read_conf(struct rcar_pcie *pcie, int where)
{
- unsigned int shift = 8 * (where & 3);
+ unsigned int shift = BITS_PER_BYTE * (where & 3);
u32 val = rcar_pci_read_reg(pcie, where & ~3);
return val >> shift;
@@ -282,9 +282,9 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
}
if (size == 1)
- *val = (*val >> (8 * (where & 3))) & 0xff;
+ *val = (*val >> (BITS_PER_BYTE * (where & 3))) & 0xff;
else if (size == 2)
- *val = (*val >> (8 * (where & 2))) & 0xffff;
+ *val = (*val >> (BITS_PER_BYTE * (where & 2))) & 0xffff;
dev_dbg(&bus->dev, "pcie-config-read: bus=%3d devfn=0x%04x where=0x%04x size=%d val=0x%08lx\n",
bus->number, devfn, where, size, (unsigned long)*val);
@@ -310,11 +310,11 @@ static int rcar_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
bus->number, devfn, where, size, (unsigned long)val);
if (size == 1) {
- shift = 8 * (where & 3);
+ shift = BITS_PER_BYTE * (where & 3);
data &= ~(0xff << shift);
data |= ((val & 0xff) << shift);
} else if (size == 2) {
- shift = 8 * (where & 2);
+ shift = BITS_PER_BYTE * (where & 2);
data &= ~(0xffff << shift);
data |= ((val & 0xffff) << shift);
} else
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH V5 5/6] PCI: rcar: Clean up debug messages
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (2 preceding siblings ...)
2019-04-02 1:33 ` [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
@ 2019-04-02 1:33 ` marek.vasut
2019-04-03 9:28 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-04-03 9:27 ` [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits Simon Horman
5 siblings, 1 reply; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
From: Marek Vasut <marek.vasut+renesas@gmail.com>
Drop useless casts from debug messages, they are no longer needed
due to the data type cleanup.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
V2: - Bundle this patch with other cleanups before resending
- Add R-B from Geert
V3: Add Wolfram's R-B
V4: No change
V5: Rebase on next/master 20190401
---
drivers/pci/controller/pcie-rcar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index d9b8c7cd9fba..168bc6b9bb93 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -286,8 +286,8 @@ static int rcar_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
else if (size == 2)
*val = (*val >> (BITS_PER_BYTE * (where & 2))) & 0xffff;
- dev_dbg(&bus->dev, "pcie-config-read: bus=%3d devfn=0x%04x where=0x%04x size=%d val=0x%08lx\n",
- bus->number, devfn, where, size, (unsigned long)*val);
+ dev_dbg(&bus->dev, "pcie-config-read: bus=%3d devfn=0x%04x where=0x%04x size=%d val=0x%08x\n",
+ bus->number, devfn, where, size, *val);
return ret;
}
@@ -306,8 +306,8 @@ static int rcar_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
if (ret != PCIBIOS_SUCCESSFUL)
return ret;
- dev_dbg(&bus->dev, "pcie-config-write: bus=%3d devfn=0x%04x where=0x%04x size=%d val=0x%08lx\n",
- bus->number, devfn, where, size, (unsigned long)val);
+ dev_dbg(&bus->dev, "pcie-config-write: bus=%3d devfn=0x%04x where=0x%04x size=%d val=0x%08x\n",
+ bus->number, devfn, where, size, val);
if (size == 1) {
shift = BITS_PER_BYTE * (where & 3);
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (3 preceding siblings ...)
2019-04-02 1:33 ` [PATCH V5 5/6] PCI: rcar: Clean up debug messages marek.vasut
@ 2019-04-02 1:33 ` marek.vasut
2019-04-02 6:28 ` Wolfram Sang
` (2 more replies)
2019-04-03 9:27 ` [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits Simon Horman
5 siblings, 3 replies; 17+ messages in thread
From: marek.vasut @ 2019-04-02 1:33 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, Geert Uytterhoeven, Phil Edworthy, Simon Horman,
Wolfram Sang, linux-renesas-soc
From: Marek Vasut <marek.vasut+renesas@gmail.com>
The MSI message address in the RC address space can be 64 bit. The
R-Car PCIe RC supports such a 64bit MSI message address as well.
The code currently uses virt_to_phys(__get_free_pages()) to obtain
a reserved page for the MSI message address, and the return value
of which can be a 64 bit physical address on 64 bit system.
However, the driver only programs PCIEMSIALR register with the bottom
32 bits of the virt_to_phys(__get_free_pages()) return value and does
not program the top 32 bits into PCIEMSIAUR, but rather programs the
PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
SoCs, however may fail on new 64 bit R-Car SoCs.
Since from a PCIe controller perspective, an inbound MSI is a memory
write to a special address (in case of this controller, defined by
the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
never hits the DRAM _and_ because allocation of an MSI by a PCIe card
driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
cause memory corruption or other issues.
There is however the possibility that if virt_to_phys(__get_free_pages())
returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
to 0x0 _and_ if the system had physical RAM at the address matching the
value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
physical address matching the value of PCIEMSIALR and a remote write to
such a buffer by a PCIe card would trigger a spurious MSI.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pci@vger.kernel.org
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V2: - s/it's/its/ in commit message
- Add R-B from Geert
V3: - Reworded commit message and thus dropped Geerts R-B
V4: - Add Geert's R-B again
V5: - Rebase on next/master 20190401
- Use {lower,upper}_32_bits() instead of >> 32
---
drivers/pci/controller/pcie-rcar.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index 168bc6b9bb93..5e0102796345 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -892,7 +892,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
{
struct device *dev = pcie->dev;
struct rcar_msi *msi = &pcie->msi;
- unsigned long base;
+ phys_addr_t base;
int err, i;
mutex_init(&msi->lock);
@@ -933,8 +933,8 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
msi->pages = __get_free_pages(GFP_KERNEL, 0);
base = virt_to_phys((void *)msi->pages);
- rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
- rcar_pci_write_reg(pcie, 0, PCIEMSIAUR);
+ rcar_pci_write_reg(pcie, lower_32_bits(base) | MSIFE, PCIEMSIALR);
+ rcar_pci_write_reg(pcie, upper_32_bits(base), PCIEMSIAUR);
/* enable all MSI interrupts */
rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
--
2.20.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values
2019-04-02 1:33 ` [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
@ 2019-04-02 6:24 ` Wolfram Sang
2019-04-03 9:28 ` Simon Horman
1 sibling, 0 replies; 17+ messages in thread
From: Wolfram Sang @ 2019-04-02 6:24 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Tue, Apr 02, 2019 at 03:33:04AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Replace various variable types with u32 or unsigned int type for
> variables holding register values, since the registers are 32bit.
> Note that rcar_pcie_msi_irq() still uses various variable types
> because both find_first_bit() and __fls() require various variable
> types as an argument.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Good that you found phy_write_reg meanwhile. I wanted to comment on that
back then but forgot the mail in the Draft folder :(
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
@ 2019-04-02 6:28 ` Wolfram Sang
2019-04-03 9:29 ` Simon Horman
2019-04-04 9:28 ` Lorenzo Pieralisi
2 siblings, 0 replies; 17+ messages in thread
From: Wolfram Sang @ 2019-04-02 6:28 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]
On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> The MSI message address in the RC address space can be 64 bit. The
> R-Car PCIe RC supports such a 64bit MSI message address as well.
> The code currently uses virt_to_phys(__get_free_pages()) to obtain
> a reserved page for the MSI message address, and the return value
> of which can be a 64 bit physical address on 64 bit system.
>
> However, the driver only programs PCIEMSIALR register with the bottom
> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
> not program the top 32 bits into PCIEMSIAUR, but rather programs the
> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
> SoCs, however may fail on new 64 bit R-Car SoCs.
>
> Since from a PCIe controller perspective, an inbound MSI is a memory
> write to a special address (in case of this controller, defined by
> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
> cause memory corruption or other issues.
>
> There is however the possibility that if virt_to_phys(__get_free_pages())
> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
> to 0x0 _and_ if the system had physical RAM at the address matching the
> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
> physical address matching the value of PCIEMSIALR and a remote write to
> such a buffer by a PCIe card would trigger a spurious MSI.
Very good descripion!
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I double-checked with the datasheets previously.
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (4 preceding siblings ...)
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
@ 2019-04-03 9:27 ` Simon Horman
5 siblings, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:27 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Tue, Apr 02, 2019 at 03:33:02AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Replace macros using constants with BIT()s instead, no functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I feel a sense of déjà vu when reading this.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> V2: Bundle this patch with other cleanups before resending
> V3: Add Wolfram's R-B
> V4: Add Geert's R-B
> V5: Rebase on next/master 20190401
> ---
> drivers/pci/controller/pcie-rcar.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index 6a4e435bd35f..542b5bbf4bf1 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -47,14 +47,14 @@
> /* Transfer control */
> #define PCIETCTLR 0x02000
> #define DL_DOWN BIT(3)
> -#define CFINIT 1
> +#define CFINIT BIT(0)
> #define PCIETSTR 0x02004
> -#define DATA_LINK_ACTIVE 1
> +#define DATA_LINK_ACTIVE BIT(0)
> #define PCIEERRFR 0x02020
> #define UNSUPPORTED_REQUEST BIT(4)
> #define PCIEMSIFR 0x02044
> #define PCIEMSIALR 0x02048
> -#define MSIFE 1
> +#define MSIFE BIT(0)
> #define PCIEMSIAUR 0x0204c
> #define PCIEMSIIER 0x02050
>
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors
2019-04-02 1:33 ` [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
@ 2019-04-03 9:27 ` Simon Horman
0 siblings, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:27 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Tue, Apr 02, 2019 at 03:33:03AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Replace unsigned long with u32 and unsigned int in register accessor
> functions, since they access 32bit registers.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)
2019-04-02 1:33 ` [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
@ 2019-04-03 9:27 ` Simon Horman
0 siblings, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:27 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Tue, Apr 02, 2019 at 03:33:05AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Replace (8 * n) with (BITS_PER_BYTE * n) to make bit shift operations
> consistent. No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 5/6] PCI: rcar: Clean up debug messages
2019-04-02 1:33 ` [PATCH V5 5/6] PCI: rcar: Clean up debug messages marek.vasut
@ 2019-04-03 9:28 ` Simon Horman
0 siblings, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:28 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Tue, Apr 02, 2019 at 03:33:06AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Drop useless casts from debug messages, they are no longer needed
> due to the data type cleanup.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values
2019-04-02 1:33 ` [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
2019-04-02 6:24 ` Wolfram Sang
@ 2019-04-03 9:28 ` Simon Horman
1 sibling, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:28 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc
On Tue, Apr 02, 2019 at 03:33:04AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Replace various variable types with u32 or unsigned int type for
> variables holding register values, since the registers are 32bit.
> Note that rcar_pcie_msi_irq() still uses various variable types
> because both find_first_bit() and __fls() require various variable
> types as an argument.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-04-02 6:28 ` Wolfram Sang
@ 2019-04-03 9:29 ` Simon Horman
2019-04-04 9:28 ` Lorenzo Pieralisi
2 siblings, 0 replies; 17+ messages in thread
From: Simon Horman @ 2019-04-03 9:29 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc
On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> The MSI message address in the RC address space can be 64 bit. The
> R-Car PCIe RC supports such a 64bit MSI message address as well.
> The code currently uses virt_to_phys(__get_free_pages()) to obtain
> a reserved page for the MSI message address, and the return value
> of which can be a 64 bit physical address on 64 bit system.
>
> However, the driver only programs PCIEMSIALR register with the bottom
> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
> not program the top 32 bits into PCIEMSIAUR, but rather programs the
> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
> SoCs, however may fail on new 64 bit R-Car SoCs.
>
> Since from a PCIe controller perspective, an inbound MSI is a memory
> write to a special address (in case of this controller, defined by
> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
> cause memory corruption or other issues.
>
> There is however the possibility that if virt_to_phys(__get_free_pages())
> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
> to 0x0 _and_ if the system had physical RAM at the address matching the
> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
> physical address matching the value of PCIEMSIALR and a remote write to
> such a buffer by a PCIe card would trigger a spurious MSI.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-04-02 6:28 ` Wolfram Sang
2019-04-03 9:29 ` Simon Horman
@ 2019-04-04 9:28 ` Lorenzo Pieralisi
2019-04-04 15:48 ` Marek Vasut
2 siblings, 1 reply; 17+ messages in thread
From: Lorenzo Pieralisi @ 2019-04-04 9:28 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc
On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.vasut@gmail.com wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> The MSI message address in the RC address space can be 64 bit. The
> R-Car PCIe RC supports such a 64bit MSI message address as well.
> The code currently uses virt_to_phys(__get_free_pages()) to obtain
> a reserved page for the MSI message address, and the return value
> of which can be a 64 bit physical address on 64 bit system.
>
> However, the driver only programs PCIEMSIALR register with the bottom
> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
> not program the top 32 bits into PCIEMSIAUR, but rather programs the
> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
> SoCs, however may fail on new 64 bit R-Car SoCs.
>
> Since from a PCIe controller perspective, an inbound MSI is a memory
> write to a special address (in case of this controller, defined by
> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
> cause memory corruption or other issues.
>
> There is however the possibility that if virt_to_phys(__get_free_pages())
> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
> to 0x0 _and_ if the system had physical RAM at the address matching the
> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
> physical address matching the value of PCIEMSIALR and a remote write to
> such a buffer by a PCIe card would trigger a spurious MSI.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> V2: - s/it's/its/ in commit message
> - Add R-B from Geert
> V3: - Reworded commit message and thus dropped Geerts R-B
> V4: - Add Geert's R-B again
> V5: - Rebase on next/master 20190401
> - Use {lower,upper}_32_bits() instead of >> 32
If that's the only reason you resent this series I will add the
lower_32_bits() code myself.
Please do not rebase on top of next, apply code on top of a fixed -rc1
(we are currently using v5.1-rc1) and if there are dependencies on code
already queued do let us know, we will handle conflicts in next
ourselves.
Lorenzo
> ---
> drivers/pci/controller/pcie-rcar.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index 168bc6b9bb93..5e0102796345 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -892,7 +892,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> struct rcar_msi *msi = &pcie->msi;
> - unsigned long base;
> + phys_addr_t base;
> int err, i;
>
> mutex_init(&msi->lock);
> @@ -933,8 +933,8 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
> msi->pages = __get_free_pages(GFP_KERNEL, 0);
> base = virt_to_phys((void *)msi->pages);
>
> - rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
> - rcar_pci_write_reg(pcie, 0, PCIEMSIAUR);
> + rcar_pci_write_reg(pcie, lower_32_bits(base) | MSIFE, PCIEMSIALR);
> + rcar_pci_write_reg(pcie, upper_32_bits(base), PCIEMSIAUR);
>
> /* enable all MSI interrupts */
> rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-04 9:28 ` Lorenzo Pieralisi
@ 2019-04-04 15:48 ` Marek Vasut
2019-04-04 16:27 ` Lorenzo Pieralisi
0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2019-04-04 15:48 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc
On 4/4/19 11:28 AM, Lorenzo Pieralisi wrote:
> On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.vasut@gmail.com wrote:
>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>
>> The MSI message address in the RC address space can be 64 bit. The
>> R-Car PCIe RC supports such a 64bit MSI message address as well.
>> The code currently uses virt_to_phys(__get_free_pages()) to obtain
>> a reserved page for the MSI message address, and the return value
>> of which can be a 64 bit physical address on 64 bit system.
>>
>> However, the driver only programs PCIEMSIALR register with the bottom
>> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
>> not program the top 32 bits into PCIEMSIAUR, but rather programs the
>> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
>> SoCs, however may fail on new 64 bit R-Car SoCs.
>>
>> Since from a PCIe controller perspective, an inbound MSI is a memory
>> write to a special address (in case of this controller, defined by
>> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
>> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
>> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
>> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
>> cause memory corruption or other issues.
>>
>> There is however the possibility that if virt_to_phys(__get_free_pages())
>> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
>> to 0x0 _and_ if the system had physical RAM at the address matching the
>> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
>> physical address matching the value of PCIEMSIALR and a remote write to
>> such a buffer by a PCIe card would trigger a spurious MSI.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Phil Edworthy <phil.edworthy@renesas.com>
>> Cc: Simon Horman <horms+renesas@verge.net.au>
>> Cc: Wolfram Sang <wsa@the-dreams.de>
>> Cc: linux-renesas-soc@vger.kernel.org
>> To: linux-pci@vger.kernel.org
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> V2: - s/it's/its/ in commit message
>> - Add R-B from Geert
>> V3: - Reworded commit message and thus dropped Geerts R-B
>> V4: - Add Geert's R-B again
>> V5: - Rebase on next/master 20190401
>> - Use {lower,upper}_32_bits() instead of >> 32
>
> If that's the only reason you resent this series I will add the
> lower_32_bits() code myself.
Yes, you asked me to resend the whole series after the bot complained.
> Please do not rebase on top of next, apply code on top of a fixed -rc1
> (we are currently using v5.1-rc1) and if there are dependencies on code
> already queued do let us know, we will handle conflicts in next
> ourselves.
So do you want me to resend this one more time ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-04-04 15:48 ` Marek Vasut
@ 2019-04-04 16:27 ` Lorenzo Pieralisi
0 siblings, 0 replies; 17+ messages in thread
From: Lorenzo Pieralisi @ 2019-04-04 16:27 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc
On Thu, Apr 04, 2019 at 05:48:36PM +0200, Marek Vasut wrote:
> On 4/4/19 11:28 AM, Lorenzo Pieralisi wrote:
> > On Tue, Apr 02, 2019 at 03:33:07AM +0200, marek.vasut@gmail.com wrote:
> >> From: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>
> >> The MSI message address in the RC address space can be 64 bit. The
> >> R-Car PCIe RC supports such a 64bit MSI message address as well.
> >> The code currently uses virt_to_phys(__get_free_pages()) to obtain
> >> a reserved page for the MSI message address, and the return value
> >> of which can be a 64 bit physical address on 64 bit system.
> >>
> >> However, the driver only programs PCIEMSIALR register with the bottom
> >> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
> >> not program the top 32 bits into PCIEMSIAUR, but rather programs the
> >> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
> >> SoCs, however may fail on new 64 bit R-Car SoCs.
> >>
> >> Since from a PCIe controller perspective, an inbound MSI is a memory
> >> write to a special address (in case of this controller, defined by
> >> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
> >> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
> >> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
> >> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
> >> cause memory corruption or other issues.
> >>
> >> There is however the possibility that if virt_to_phys(__get_free_pages())
> >> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
> >> to 0x0 _and_ if the system had physical RAM at the address matching the
> >> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
> >> physical address matching the value of PCIEMSIALR and a remote write to
> >> such a buffer by a PCIe card would trigger a spurious MSI.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> >> Cc: Simon Horman <horms+renesas@verge.net.au>
> >> Cc: Wolfram Sang <wsa@the-dreams.de>
> >> Cc: linux-renesas-soc@vger.kernel.org
> >> To: linux-pci@vger.kernel.org
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> ---
> >> V2: - s/it's/its/ in commit message
> >> - Add R-B from Geert
> >> V3: - Reworded commit message and thus dropped Geerts R-B
> >> V4: - Add Geert's R-B again
> >> V5: - Rebase on next/master 20190401
> >> - Use {lower,upper}_32_bits() instead of >> 32
> >
> > If that's the only reason you resent this series I will add the
> > lower_32_bits() code myself.
>
> Yes, you asked me to resend the whole series after the bot complained.
https://lists.01.org/pipermail/kbuild-all/2019-April/059428.html
> > Please do not rebase on top of next, apply code on top of a fixed -rc1
> > (we are currently using v5.1-rc1) and if there are dependencies on code
> > already queued do let us know, we will handle conflicts in next
> > ourselves.
>
> So do you want me to resend this one more time ?
No, in the message above I wanted to say I would make the update
myself.
Regardless, please never send patches aimed at the PCI tree
on top on -next.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-04-04 16:27 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-02 1:33 [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-04-02 1:33 ` [PATCH V5 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
2019-04-03 9:27 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
2019-04-02 6:24 ` Wolfram Sang
2019-04-03 9:28 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
2019-04-03 9:27 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 5/6] PCI: rcar: Clean up debug messages marek.vasut
2019-04-03 9:28 ` Simon Horman
2019-04-02 1:33 ` [PATCH V5 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-04-02 6:28 ` Wolfram Sang
2019-04-03 9:29 ` Simon Horman
2019-04-04 9:28 ` Lorenzo Pieralisi
2019-04-04 15:48 ` Marek Vasut
2019-04-04 16:27 ` Lorenzo Pieralisi
2019-04-03 9:27 ` [PATCH V5 1/6] PCI: rcar: Clean up remaining macros defining bits Simon Horman
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).