* [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
@ 2019-03-25 11:40 ` marek.vasut
2019-03-27 11:24 ` Simon Horman
2019-03-25 11:40 ` [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
` (6 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: marek.vasut @ 2019-03-25 11:40 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
---
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 5b8736f0cd6b..3db693b4410e 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -152,14 +152,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] 24+ messages in thread
* Re: [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors
2019-03-25 11:40 ` [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
@ 2019-03-27 11:24 ` Simon Horman
0 siblings, 0 replies; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:24 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:40:57PM +0100, 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>
> ---
> V2: Bundle this patch with other cleanups before resending
> V3: Add Wolfram's R-B
> V4: Change reg to unsigned int
> ---
> 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 5b8736f0cd6b..3db693b4410e 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -152,14 +152,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 [flat|nested] 24+ messages in thread
* [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-03-25 11:40 ` [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
@ 2019-03-25 11:40 ` marek.vasut
2019-03-27 11:25 ` Simon Horman
2019-03-25 11:40 ` [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
` (5 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: marek.vasut @ 2019-03-25 11:40 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()
---
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 3db693b4410e..6699211fdc9a 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -170,7 +170,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);
@@ -180,7 +180,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;
@@ -191,7 +191,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);
@@ -295,8 +295,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);
@@ -506,10 +507,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) |
@@ -1117,7 +1118,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] 24+ messages in thread
* Re: [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values
2019-03-25 11:40 ` [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
@ 2019-03-27 11:25 ` Simon Horman
0 siblings, 0 replies; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:25 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc
On Mon, Mar 25, 2019 at 12:40:58PM +0100, 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>
> ---
> 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()
> ---
> 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 3db693b4410e..6699211fdc9a 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -170,7 +170,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);
> @@ -180,7 +180,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;
> @@ -191,7 +191,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);
> @@ -295,8 +295,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);
> @@ -506,10 +507,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) |
> @@ -1117,7 +1118,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 [flat|nested] 24+ messages in thread
* [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-03-25 11:40 ` [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
2019-03-25 11:40 ` [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
@ 2019-03-25 11:40 ` marek.vasut
2019-03-25 11:45 ` Geert Uytterhoeven
2019-03-27 11:26 ` Simon Horman
2019-03-25 11:41 ` [PATCH V4 5/6] PCI: rcar: Clean up debug messages marek.vasut
` (4 subsequent siblings)
7 siblings, 2 replies; 24+ messages in thread
From: marek.vasut @ 2019-03-25 11:40 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>
---
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
---
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 6699211fdc9a..96210768e774 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -170,7 +170,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);
@@ -180,7 +180,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;
@@ -280,9 +280,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);
@@ -308,11 +308,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] 24+ messages in thread
* Re: [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)
2019-03-25 11:40 ` [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
@ 2019-03-25 11:45 ` Geert Uytterhoeven
2019-03-27 11:26 ` Simon Horman
1 sibling, 0 replies; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-25 11:45 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, Linux-Renesas, Wolfram Sang
On Mon, Mar 25, 2019 at 12:41 PM <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>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)
2019-03-25 11:40 ` [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
2019-03-25 11:45 ` Geert Uytterhoeven
@ 2019-03-27 11:26 ` Simon Horman
1 sibling, 0 replies; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:26 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:40:59PM +0100, 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: Simon Horman <horms+renesas@verge.net.au>
> ---
> 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
> ---
> 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 6699211fdc9a..96210768e774 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -170,7 +170,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);
> @@ -180,7 +180,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;
> @@ -280,9 +280,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);
> @@ -308,11 +308,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 [flat|nested] 24+ messages in thread
* [PATCH V4 5/6] PCI: rcar: Clean up debug messages
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (2 preceding siblings ...)
2019-03-25 11:40 ` [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
@ 2019-03-25 11:41 ` marek.vasut
2019-03-27 11:27 ` Simon Horman
2019-03-25 11:41 ` [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
` (3 subsequent siblings)
7 siblings, 1 reply; 24+ messages in thread
From: marek.vasut @ 2019-03-25 11:41 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
---
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 96210768e774..c6013f95bdb2 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -284,8 +284,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;
}
@@ -304,8 +304,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] 24+ messages in thread
* Re: [PATCH V4 5/6] PCI: rcar: Clean up debug messages
2019-03-25 11:41 ` [PATCH V4 5/6] PCI: rcar: Clean up debug messages marek.vasut
@ 2019-03-27 11:27 ` Simon Horman
0 siblings, 0 replies; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:27 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:41:00PM +0100, 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.
Great! The fewer casts the better.
> 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>
> ---
> V2: - Bundle this patch with other cleanups before resending
> - Add R-B from Geert
> V3: Add Wolfram's R-B
> V4: No change
> ---
> 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 96210768e774..c6013f95bdb2 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -284,8 +284,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;
> }
> @@ -304,8 +304,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 [flat|nested] 24+ messages in thread
* [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (3 preceding siblings ...)
2019-03-25 11:41 ` [PATCH V4 5/6] PCI: rcar: Clean up debug messages marek.vasut
@ 2019-03-25 11:41 ` marek.vasut
2019-03-27 11:30 ` Simon Horman
2019-03-29 19:32 ` Geert Uytterhoeven
2019-03-26 13:04 ` [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits Lorenzo Pieralisi
` (2 subsequent siblings)
7 siblings, 2 replies; 24+ messages in thread
From: marek.vasut @ 2019-03-25 11:41 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
---
drivers/pci/controller/pcie-rcar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
index c6013f95bdb2..62d2de9fbf1c 100644
--- a/drivers/pci/controller/pcie-rcar.c
+++ b/drivers/pci/controller/pcie-rcar.c
@@ -890,7 +890,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);
@@ -932,7 +932,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
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, base >> 32, PCIEMSIAUR);
/* enable all MSI interrupts */
rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
--
2.20.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-25 11:41 ` [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
@ 2019-03-27 11:30 ` Simon Horman
2019-03-27 12:22 ` Geert Uytterhoeven
2019-03-29 19:32 ` Geert Uytterhoeven
1 sibling, 1 reply; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:30 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc
On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
Does this warrant a Fixes tag?
That notwithstanding,
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> 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
> ---
> drivers/pci/controller/pcie-rcar.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index c6013f95bdb2..62d2de9fbf1c 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -890,7 +890,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);
> @@ -932,7 +932,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
> 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, base >> 32, PCIEMSIAUR);
>
> /* enable all MSI interrupts */
> rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-27 11:30 ` Simon Horman
@ 2019-03-27 12:22 ` Geert Uytterhoeven
2019-03-28 3:03 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-27 12:22 UTC (permalink / raw)
To: Simon Horman
Cc: Marek Vasut, linux-pci, Marek Vasut, Geert Uytterhoeven,
Phil Edworthy, Wolfram Sang, Linux-Renesas
On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
>
> Does this warrant a Fixes tag?
(digging in old sent email)
Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-27 12:22 ` Geert Uytterhoeven
@ 2019-03-28 3:03 ` Marek Vasut
2019-03-28 8:02 ` Geert Uytterhoeven
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2019-03-28 3:03 UTC (permalink / raw)
To: Geert Uytterhoeven, Simon Horman
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, Linux-Renesas
On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
>> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
>>
>> Does this warrant a Fixes tag?
>
> (digging in old sent email)
> Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
But does it really fix that commit, given that on Gen2 and earlier, it
was not broken as those were 32bit platforms ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-28 3:03 ` Marek Vasut
@ 2019-03-28 8:02 ` Geert Uytterhoeven
2019-03-28 16:28 ` Lorenzo Pieralisi
0 siblings, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-28 8:02 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Horman, linux-pci, Marek Vasut, Geert Uytterhoeven,
Phil Edworthy, Wolfram Sang, Linux-Renesas
Hi Marek,
On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> > On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
> >> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
> >>
> >> Does this warrant a Fixes tag?
> >
> > (digging in old sent email)
> > Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
>
> But does it really fix that commit, given that on Gen2 and earlier, it
> was not broken as those were 32bit platforms ?
It does not fix the bug on that commit, as the bug cannot happen on arm32.
It does fix that commit, in that that commit used "unsigned long" for a
physical address, which is wrong, even on arm32 (esp. with LPAE).
If you insist on having a Fixes tag for a commit where the bug could be
seen:
Fixes: e015f88c368da1e6 ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
Apart from that, drivers should use the DMA API instead of virt_to_phys().
However, now we have a better understanding of how MSI interrupts work,
we don't even need to allocate that page. All we need is the physical
address of a page that is guaranteed not to be backed by RAM
(i.e. not to be a valid target for a legitimate PCI bus mastering transaction).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-28 8:02 ` Geert Uytterhoeven
@ 2019-03-28 16:28 ` Lorenzo Pieralisi
2019-03-28 16:31 ` Geert Uytterhoeven
0 siblings, 1 reply; 24+ messages in thread
From: Lorenzo Pieralisi @ 2019-03-28 16:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marek Vasut, Simon Horman, linux-pci, Marek Vasut,
Geert Uytterhoeven, Phil Edworthy, Wolfram Sang, Linux-Renesas
On Thu, Mar 28, 2019 at 09:02:00AM +0100, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut <marek.vasut@gmail.com> wrote:
> > On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> > > On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
> > >> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
> > >>
> > >> Does this warrant a Fixes tag?
> > >
> > > (digging in old sent email)
> > > Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
> >
> > But does it really fix that commit, given that on Gen2 and earlier, it
> > was not broken as those were 32bit platforms ?
>
> It does not fix the bug on that commit, as the bug cannot happen on arm32.
> It does fix that commit, in that that commit used "unsigned long" for a
> physical address, which is wrong, even on arm32 (esp. with LPAE).
> If you insist on having a Fixes tag for a commit where the bug could be
> seen:
> Fixes: e015f88c368da1e6 ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
>
> Apart from that, drivers should use the DMA API instead of virt_to_phys().
> However, now we have a better understanding of how MSI interrupts
> work, we don't even need to allocate that page. All we need is the
> physical address of a page that is guaranteed not to be backed by RAM
> (i.e. not to be a valid target for a legitimate PCI bus mastering
> transaction).
Agreed but I would merge this patch first since it is a fix
and update it later.
Shall I go with the Fixes: tag above ?
Thanks,
Lorenzo
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-28 16:28 ` Lorenzo Pieralisi
@ 2019-03-28 16:31 ` Geert Uytterhoeven
2019-03-29 9:53 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-28 16:31 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Marek Vasut, Simon Horman, linux-pci, Marek Vasut,
Geert Uytterhoeven, Phil Edworthy, Wolfram Sang, Linux-Renesas
Hi Lorenzo,
On Thu, Mar 28, 2019 at 5:28 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 28, 2019 at 09:02:00AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut <marek.vasut@gmail.com> wrote:
> > > On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
> > > > On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
> > > >> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
> > > >>
> > > >> Does this warrant a Fixes tag?
> > > >
> > > > (digging in old sent email)
> > > > Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
> > >
> > > But does it really fix that commit, given that on Gen2 and earlier, it
> > > was not broken as those were 32bit platforms ?
> >
> > It does not fix the bug on that commit, as the bug cannot happen on arm32.
> > It does fix that commit, in that that commit used "unsigned long" for a
> > physical address, which is wrong, even on arm32 (esp. with LPAE).
> > If you insist on having a Fixes tag for a commit where the bug could be
> > seen:
> > Fixes: e015f88c368da1e6 ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
> >
> > Apart from that, drivers should use the DMA API instead of virt_to_phys().
> > However, now we have a better understanding of how MSI interrupts
> > work, we don't even need to allocate that page. All we need is the
> > physical address of a page that is guaranteed not to be backed by RAM
> > (i.e. not to be a valid target for a legitimate PCI bus mastering
> > transaction).
>
> Agreed but I would merge this patch first since it is a fix
> and update it later.
Sure, definitely.
> Shall I go with the Fixes: tag above ?
Fine for me, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-28 16:31 ` Geert Uytterhoeven
@ 2019-03-29 9:53 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2019-03-29 9:53 UTC (permalink / raw)
To: Geert Uytterhoeven, Lorenzo Pieralisi
Cc: Simon Horman, linux-pci, Marek Vasut, Geert Uytterhoeven,
Phil Edworthy, Wolfram Sang, Linux-Renesas
On 3/28/19 5:31 PM, Geert Uytterhoeven wrote:
> Hi Lorenzo,
>
> On Thu, Mar 28, 2019 at 5:28 PM Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 28, 2019 at 09:02:00AM +0100, Geert Uytterhoeven wrote:
>>> On Thu, Mar 28, 2019 at 4:19 AM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 3/27/19 1:22 PM, Geert Uytterhoeven wrote:
>>>>> On Wed, Mar 27, 2019 at 12:30 PM Simon Horman <horms@verge.net.au> wrote:
>>>>>> On Mon, Mar 25, 2019 at 12:41:01PM +0100, 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>
>>>>>>
>>>>>> Does this warrant a Fixes tag?
>>>>>
>>>>> (digging in old sent email)
>>>>> Fixes: 290c1fb358605402 ("PCI: rcar: Add MSI support for PCIe")
>>>>
>>>> But does it really fix that commit, given that on Gen2 and earlier, it
>>>> was not broken as those were 32bit platforms ?
>>>
>>> It does not fix the bug on that commit, as the bug cannot happen on arm32.
>>> It does fix that commit, in that that commit used "unsigned long" for a
>>> physical address, which is wrong, even on arm32 (esp. with LPAE).
>>> If you insist on having a Fixes tag for a commit where the bug could be
>>> seen:
>>> Fixes: e015f88c368da1e6 ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
>>>
>>> Apart from that, drivers should use the DMA API instead of virt_to_phys().
>>> However, now we have a better understanding of how MSI interrupts
>>> work, we don't even need to allocate that page. All we need is the
>>> physical address of a page that is guaranteed not to be backed by RAM
>>> (i.e. not to be a valid target for a legitimate PCI bus mastering
>>> transaction).
>>
>> Agreed but I would merge this patch first since it is a fix
>> and update it later.
>
> Sure, definitely.
>
>> Shall I go with the Fixes: tag above ?
>
> Fine for me, thanks!
I don't feel strongly either way.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-25 11:41 ` [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-03-27 11:30 ` Simon Horman
@ 2019-03-29 19:32 ` Geert Uytterhoeven
2019-03-30 7:45 ` Marek Vasut
1 sibling, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-29 19:32 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, Linux-Renesas
Hi Marek,
On Mon, Mar 25, 2019 at 12:41 PM <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
> ---
> drivers/pci/controller/pcie-rcar.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index c6013f95bdb2..62d2de9fbf1c 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -890,7 +890,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);
> @@ -932,7 +932,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
> 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, base >> 32, PCIEMSIAUR);
As reported by 0day, this causes a warning on arm32 without LPAE:
drivers/pci/controller/pcie-rcar.c:935:32: warning: right shift
count >= width of type
Using upper_32_bits() instead of an explicit shift should fix that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
2019-03-29 19:32 ` Geert Uytterhoeven
@ 2019-03-30 7:45 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2019-03-30 7:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, Linux-Renesas
On 3/29/19 8:32 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Mar 25, 2019 at 12:41 PM <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
>> ---
>> drivers/pci/controller/pcie-rcar.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
>> index c6013f95bdb2..62d2de9fbf1c 100644
>> --- a/drivers/pci/controller/pcie-rcar.c
>> +++ b/drivers/pci/controller/pcie-rcar.c
>> @@ -890,7 +890,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);
>> @@ -932,7 +932,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
>> 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, base >> 32, PCIEMSIAUR);
>
> As reported by 0day, this causes a warning on arm32 without LPAE:
>
> drivers/pci/controller/pcie-rcar.c:935:32: warning: right shift
> count >= width of type
>
> Using upper_32_bits() instead of an explicit shift should fix that.
I saw the report too.
Lorenzo, do you want a separate patch to squash with this or V5 ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (4 preceding siblings ...)
2019-03-25 11:41 ` [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
@ 2019-03-26 13:04 ` Lorenzo Pieralisi
2019-03-26 16:48 ` Marek Vasut
2019-03-27 11:24 ` Simon Horman
2019-03-29 14:09 ` Lorenzo Pieralisi
7 siblings, 1 reply; 24+ messages in thread
From: Lorenzo Pieralisi @ 2019-03-26 13:04 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:40:56PM +0100, 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>
> ---
> V2: Bundle this patch with other cleanups before resending
> V3: Add Wolfram's R-B
> V4: Add Geert's R-B
> ---
> drivers/pci/controller/pcie-rcar.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Hi Marek,
I assume this series makes:
https://patchwork.ozlabs.org/patch/1053779/
https://patchwork.ozlabs.org/patch/1057454/
obsolete, please let me know and I will drop
them from the PCI patches queue, I will get to
this series later for v5.2.
Thanks,
Lorenzo
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index c8febb009454..5b8736f0cd6b 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -46,14 +46,14 @@
>
> /* Transfer control */
> #define PCIETCTLR 0x02000
> -#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] 24+ messages in thread
* Re: [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits
2019-03-26 13:04 ` [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits Lorenzo Pieralisi
@ 2019-03-26 16:48 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2019-03-26 16:48 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc, Wolfram Sang
On 3/26/19 2:04 PM, Lorenzo Pieralisi wrote:
> On Mon, Mar 25, 2019 at 12:40:56PM +0100, 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>
>> ---
>> V2: Bundle this patch with other cleanups before resending
>> V3: Add Wolfram's R-B
>> V4: Add Geert's R-B
>> ---
>> drivers/pci/controller/pcie-rcar.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Hi Marek,
Hi,
> I assume this series makes:
>
> https://patchwork.ozlabs.org/patch/1053779/
> https://patchwork.ozlabs.org/patch/1057454/
>
> obsolete, please let me know and I will drop
> them from the PCI patches queue, I will get to
> this series later for v5.2.
Yes, I decided to merge the two series together to make it easier to pick.
Thanks
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (5 preceding siblings ...)
2019-03-26 13:04 ` [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits Lorenzo Pieralisi
@ 2019-03-27 11:24 ` Simon Horman
2019-03-29 14:09 ` Lorenzo Pieralisi
7 siblings, 0 replies; 24+ messages in thread
From: Simon Horman @ 2019-03-27 11:24 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:40:56PM +0100, 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>
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
> ---
> 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 c8febb009454..5b8736f0cd6b 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -46,14 +46,14 @@
>
> /* Transfer control */
> #define PCIETCTLR 0x02000
> -#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] 24+ messages in thread
* Re: [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
` (6 preceding siblings ...)
2019-03-27 11:24 ` Simon Horman
@ 2019-03-29 14:09 ` Lorenzo Pieralisi
7 siblings, 0 replies; 24+ messages in thread
From: Lorenzo Pieralisi @ 2019-03-29 14:09 UTC (permalink / raw)
To: marek.vasut
Cc: linux-pci, Marek Vasut, Geert Uytterhoeven, Phil Edworthy,
Simon Horman, Wolfram Sang, linux-renesas-soc, Wolfram Sang
On Mon, Mar 25, 2019 at 12:40:56PM +0100, 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>
> ---
> V2: Bundle this patch with other cleanups before resending
> V3: Add Wolfram's R-B
> V4: Add Geert's R-B
> ---
> drivers/pci/controller/pcie-rcar.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied the series to pci/rcar for v5.2, thanks.
Lorenzo
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index c8febb009454..5b8736f0cd6b 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -46,14 +46,14 @@
>
> /* Transfer control */
> #define PCIETCTLR 0x02000
> -#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] 24+ messages in thread