[PATCH 0/4] PCI: rcar, rcar-gen2: More Gen2 compat strings

[PATCH 0/4] PCI: rcar, rcar-gen2: More Gen2 compat strings

[Simon Horman]

Hi,

this short series adds generic gen2 and soc-specific r8a7793 compat strings
to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to provide
a complete set of compat strings for known Gen2 SoCs.

Simon Horman (4):
  PCI: rcar-gen2: Add generic compatibility string
  PCI: rcar-gen2: Add device tree support for r8a7793
  PCI: rcar: Add Gen2 fallback compatibility string
  PCI: rcar: Add device tree support for r8a7793

 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 ++++++++++--
 Documentation/devicetree/bindings/pci/rcar-pci.txt      | 14 +++++++++++---
 drivers/pci/host/pci-rcar-gen2.c                        |  1 +
 drivers/pci/host/pcie-rcar.c                            |  1 +
 4 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.1.4

[PATCH 0/4] PCI: rcar, rcar-gen2: More Gen2 compat strings

[Simon Horman]

Hi,

this short series adds generic gen2 and soc-specific r8a7793 compat strings
to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to provide
a complete set of compat strings for known Gen2 SoCs.

Simon Horman (4):
  PCI: rcar-gen2: Add generic compatibility string
  PCI: rcar-gen2: Add device tree support for r8a7793
  PCI: rcar: Add Gen2 fallback compatibility string
  PCI: rcar: Add device tree support for r8a7793

 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 ++++++++++--
 Documentation/devicetree/bindings/pci/rcar-pci.txt      | 14 +++++++++++---
 drivers/pci/host/pci-rcar-gen2.c                        |  1 +
 drivers/pci/host/pcie-rcar.c                            |  1 +
 4 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.1.4

[PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 Family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
 drivers/pci/host/pci-rcar-gen2.c                        |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 891463cb09c2..b19be08a8113 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,7 +8,14 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
 	      "renesas,pci-r8a7791" for the R8A7791 SoC;
-	      "renesas,pci-r8a7794" for the R8A7794 SoC.
+	      "renesas,pci-r8a7794" for the R8A7794 SoC;
+	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
+
+
+	      When compatible with the generic version, nodes must list the
+	      SoC-specific version corresponding to the platform first
+	      followed by the generic version.
+
 - reg:	A list of physical regions to access the device: the first is
 	the operational registers for the OHCI/EHCI controllers and the
 	second is for the bridge configuration and control registers.
@@ -32,7 +39,7 @@ Optional properties:
 Example SoC configuration:
 
 	pci0: pci@ee090000  {
-		compatible = "renesas,pci-r8a7790";
+		compatible = "renesas,pci-r8a7790", "renesas,pci-gen2";
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		reg = <0x0 0xee090000 0x0 0xc00>,
 		      <0x0 0xee080000 0x0 0x1100>;
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index 62951165dcbb..a93403823353 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -430,6 +430,7 @@ static int rcar_pci_probe(struct platform_device *pdev)
 }
 
 static struct of_device_id rcar_pci_of_match[] = {
+	{ .compatible = "renesas,pci-gen2", },
 	{ .compatible = "renesas,pci-r8a7790", },
 	{ .compatible = "renesas,pci-r8a7791", },
 	{ .compatible = "renesas,pci-r8a7794", },
-- 
2.1.4

[PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 Family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
 drivers/pci/host/pci-rcar-gen2.c                        |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 891463cb09c2..b19be08a8113 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,7 +8,14 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
 	      "renesas,pci-r8a7791" for the R8A7791 SoC;
-	      "renesas,pci-r8a7794" for the R8A7794 SoC.
+	      "renesas,pci-r8a7794" for the R8A7794 SoC;
+	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
+
+
+	      When compatible with the generic version, nodes must list the
+	      SoC-specific version corresponding to the platform first
+	      followed by the generic version.
+
 - reg:	A list of physical regions to access the device: the first is
 	the operational registers for the OHCI/EHCI controllers and the
 	second is for the bridge configuration and control registers.
@@ -32,7 +39,7 @@ Optional properties:
 Example SoC configuration:
 
 	pci0: pci@ee090000  {
-		compatible = "renesas,pci-r8a7790";
+		compatible = "renesas,pci-r8a7790", "renesas,pci-gen2";
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		reg = <0x0 0xee090000 0x0 0xc00>,
 		      <0x0 0xee080000 0x0 0x1100>;
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index 62951165dcbb..a93403823353 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -430,6 +430,7 @@ static int rcar_pci_probe(struct platform_device *pdev)
 }
 
 static struct of_device_id rcar_pci_of_match[] = {
+	{ .compatible = "renesas,pci-gen2", },
 	{ .compatible = "renesas,pci-r8a7790", },
 	{ .compatible = "renesas,pci-r8a7791", },
 	{ .compatible = "renesas,pci-r8a7794", },
-- 
2.1.4

[PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

Simply document new compat strings.
There appears to be no need for a driver updates.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index b19be08a8113..7c231b3e5872 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,6 +8,7 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
 	      "renesas,pci-r8a7791" for the R8A7791 SoC;
+	      "renesas,pci-r8a7793" for the R8A7793 SoC;
 	      "renesas,pci-r8a7794" for the R8A7794 SoC;
 	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
 
-- 
2.1.4

[PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

Simply document new compat strings.
There appears to be no need for a driver updates.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index b19be08a8113..7c231b3e5872 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,6 +8,7 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
 	      "renesas,pci-r8a7791" for the R8A7791 SoC;
+	      "renesas,pci-r8a7793" for the R8A7793 SoC;
 	      "renesas,pci-r8a7794" for the R8A7794 SoC;
 	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
 
-- 
2.1.4

[PATCH 3/4] PCI: rcar: Add Gen2 fallback compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 Family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 13 ++++++++++---
 drivers/pci/host/pcie-rcar.c                       |  1 +
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 29d3b989d3b0..872cea085be8 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -1,8 +1,15 @@
 * Renesas RCar PCIe interface
 
 Required properties:
-- compatible: should contain one of the following
-	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
+	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
+	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
+	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
+
+	    When compatible with the generic version, nodes must list the
+	    SoC-specific version corresponding to the platform first
+	    followed by the generic version.
+
 - reg: base address and length of the pcie controller registers.
 - #address-cells: set to <3>
 - #size-cells: set to <2>
@@ -25,7 +32,7 @@ Example:
 SoC specific DT Entry:
 
 	pcie: pcie@fe000000 {
-		compatible = "renesas,pcie-r8a7791";
+		compatible = "renesas,pcie-r8a7791", "renesas,pcie-gen2";
 		reg = <0 0xfe000000 0 0x80000>;
 		#address-cells = <3>;
 		#size-cells = <2>;
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index f4fa6c537448..17ee0422ddb1 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -917,6 +917,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
 
 static const struct of_device_id rcar_pcie_of_match[] = {
 	{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
+	{ .compatible = "renesas,pcie-gen2", .data = rcar_pcie_hw_init },
 	{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
 	{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
 	{},
-- 
2.1.4

[PATCH 3/4] PCI: rcar: Add Gen2 fallback compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 Family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 13 ++++++++++---
 drivers/pci/host/pcie-rcar.c                       |  1 +
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 29d3b989d3b0..872cea085be8 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -1,8 +1,15 @@
 * Renesas RCar PCIe interface
 
 Required properties:
-- compatible: should contain one of the following
-	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
+	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
+	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
+	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
+
+	    When compatible with the generic version, nodes must list the
+	    SoC-specific version corresponding to the platform first
+	    followed by the generic version.
+
 - reg: base address and length of the pcie controller registers.
 - #address-cells: set to <3>
 - #size-cells: set to <2>
@@ -25,7 +32,7 @@ Example:
 SoC specific DT Entry:
 
 	pcie: pcie@fe000000 {
-		compatible = "renesas,pcie-r8a7791";
+		compatible = "renesas,pcie-r8a7791", "renesas,pcie-gen2";
 		reg = <0 0xfe000000 0 0x80000>;
 		#address-cells = <3>;
 		#size-cells = <2>;
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index f4fa6c537448..17ee0422ddb1 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -917,6 +917,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
 
 static const struct of_device_id rcar_pcie_of_match[] = {
 	{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
+	{ .compatible = "renesas,pcie-gen2", .data = rcar_pcie_hw_init },
 	{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
 	{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
 	{},
-- 
2.1.4

[PATCH 4/4] PCI: rcar: Add device tree support for r8a7793

[Simon Horman]

Simply document new compat strings.
As a previous patch adds a generic R-Car Gen2 compat string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

---
* The r8a7792 and r8a7794 are omitted from this change as the
  hardware in question does not appear to be present on those SoCs.
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 872cea085be8..4548b9b54165 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -4,6 +4,7 @@ Required properties:
 compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
 	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
 	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
+	    "renesas,pcie-r8a7793" for the R8A7793 SoC;
 	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
 
 	    When compatible with the generic version, nodes must list the
-- 
2.1.4

[PATCH 4/4] PCI: rcar: Add device tree support for r8a7793

[Simon Horman]

Simply document new compat strings.
As a previous patch adds a generic R-Car Gen2 compat string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

---
* The r8a7792 and r8a7794 are omitted from this change as the
  hardware in question does not appear to be present on those SoCs.
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 872cea085be8..4548b9b54165 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -4,6 +4,7 @@ Required properties:
 compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
 	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
 	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
+	    "renesas,pcie-r8a7793" for the R8A7793 SoC;
 	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
 
 	    When compatible with the generic version, nodes must list the
-- 
2.1.4

Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Geert Uytterhoeven]

On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Add fallback compatibility string for R-Car Gen 2 Family.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
>  drivers/pci/host/pci-rcar-gen2.c                        |  1 +
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index 891463cb09c2..b19be08a8113 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,7 +8,14 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>               "renesas,pci-r8a7791" for the R8A7791 SoC;
> -             "renesas,pci-r8a7794" for the R8A7794 SoC.
> +             "renesas,pci-r8a7794" for the R8A7794 SoC;
> +             "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.

Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"?

Else you'll be in trouble when Renesas starts focussing on airplanes
(R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2).

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

Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Geert Uytterhoeven]

On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> Add fallback compatibility string for R-Car Gen 2 Family.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
>  drivers/pci/host/pci-rcar-gen2.c                        |  1 +
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index 891463cb09c2..b19be08a8113 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,7 +8,14 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>               "renesas,pci-r8a7791" for the R8A7791 SoC;
> -             "renesas,pci-r8a7794" for the R8A7794 SoC.
> +             "renesas,pci-r8a7794" for the R8A7794 SoC;
> +             "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.

Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"?

Else you'll be in trouble when Renesas starts focussing on airplanes
(R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Geert Uytterhoeven]

On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Add fallback compatibility string for R-Car Gen 2 Family.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
>  drivers/pci/host/pci-rcar-gen2.c                        |  1 +
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index 891463cb09c2..b19be08a8113 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,7 +8,14 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>               "renesas,pci-r8a7791" for the R8A7791 SoC;
> -             "renesas,pci-r8a7794" for the R8A7794 SoC.
> +             "renesas,pci-r8a7794" for the R8A7794 SoC;
> +             "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.

Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"?

Else you'll be in trouble when Renesas starts focussing on airplanes
(R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2).

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

Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Simon Horman]

On Tue, Dec 01, 2015 at 09:41:49AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> > Add fallback compatibility string for R-Car Gen 2 Family.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
> >  drivers/pci/host/pci-rcar-gen2.c                        |  1 +
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > index 891463cb09c2..b19be08a8113 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > @@ -8,7 +8,14 @@ OHCI and EHCI controllers.
> >  Required properties:
> >  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> >               "renesas,pci-r8a7791" for the R8A7791 SoC;
> > -             "renesas,pci-r8a7794" for the R8A7794 SoC.
> > +             "renesas,pci-r8a7794" for the R8A7794 SoC;
> > +             "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
> 
> Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"?
> 
> Else you'll be in trouble when Renesas starts focussing on airplanes
> (R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2).

Point taken.

I think renesas,pci-rcar-gen2 should work well enough.

Re: [PATCH 1/4] PCI: rcar-gen2: Add generic compatibility string

[Simon Horman]

On Tue, Dec 01, 2015 at 09:41:49AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 1, 2015 at 8:24 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> > Add fallback compatibility string for R-Car Gen 2 Family.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +++++++++--
> >  drivers/pci/host/pci-rcar-gen2.c                        |  1 +
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > index 891463cb09c2..b19be08a8113 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > @@ -8,7 +8,14 @@ OHCI and EHCI controllers.
> >  Required properties:
> >  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> >               "renesas,pci-r8a7791" for the R8A7791 SoC;
> > -             "renesas,pci-r8a7794" for the R8A7794 SoC.
> > +             "renesas,pci-r8a7794" for the R8A7794 SoC;
> > +             "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
> 
> Shouldn't that be "renesas,pci-rcar-gen" or "renesas,pci-rcar2"?
> 
> Else you'll be in trouble when Renesas starts focussing on airplanes
> (R-Plane Gen2), rockets (R-Rocket Gen2), or IoT (R-IoT Gen2).

Point taken.

I think renesas,pci-rcar-gen2 should work well enough.

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Bjorn Helgaas]

Hi Simon,

On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> Simply document new compat strings.
> There appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index b19be08a8113..7c231b3e5872 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>  	      "renesas,pci-r8a7791" for the R8A7791 SoC;
> +	      "renesas,pci-r8a7793" for the R8A7793 SoC;

What's the benefit of adding a string here if the driver doesn't check
for it?  Since the driver doesn't look for it, there's no way to test
anything.

It doesn't seem like this file is an authoritative source of names, so
if we add it here, there's the possibility the r8a7793 will be
canceled or renamed, and then we'd have to update this if the driver
ever did need an r8a7793-specific quirk.  If we waited until the
driver actually needs a quirk, then we'd know exactly what name to
look for and we could update the driver, DT, and doc all together.

>  	      "renesas,pci-r8a7794" for the R8A7794 SoC;
>  	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Bjorn Helgaas]

Hi Simon,

On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> Simply document new compat strings.
> There appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> index b19be08a8113..7c231b3e5872 100644
> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
>  Required properties:
>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>  	      "renesas,pci-r8a7791" for the R8A7791 SoC;
> +	      "renesas,pci-r8a7793" for the R8A7793 SoC;

What's the benefit of adding a string here if the driver doesn't check
for it?  Since the driver doesn't look for it, there's no way to test
anything.

It doesn't seem like this file is an authoritative source of names, so
if we add it here, there's the possibility the r8a7793 will be
canceled or renamed, and then we'd have to update this if the driver
ever did need an r8a7793-specific quirk.  If we waited until the
driver actually needs a quirk, then we'd know exactly what name to
look for and we could update the driver, DT, and doc all together.

>  	      "renesas,pci-r8a7794" for the R8A7794 SoC;
>  	      "renesas,pci-gen2" for a generic R-Car Gen2 compatible device.
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
>> Simply document new compat strings.
>> There appears to be no need for a driver updates.
>>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> index b19be08a8113..7c231b3e5872 100644
>> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
>>  Required properties:
>>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>>             "renesas,pci-r8a7791" for the R8A7791 SoC;
>> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
>
> What's the benefit of adding a string here if the driver doesn't check
> for it?  Since the driver doesn't look for it, there's no way to test
> anything.

If we ever discover a difference between PCI on r8a7793 compared to PCI on
other SoCs of the R-Car Gen2 family, we can handle that difference in the
driver.

> It doesn't seem like this file is an authoritative source of names, so

Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
for their existence in the binding documentation. Hence we always add the
compatible values to the DT binding docs, before we start using them.

> if we add it here, there's the possibility the r8a7793 will be
> canceled or renamed, and then we'd have to update this if the driver
> ever did need an r8a7793-specific quirk.  If we waited until the

I don't understand what you mean here.

> driver actually needs a quirk, then we'd know exactly what name to
> look for and we could update the driver, DT, and doc all together.

If we update driver, DT, and doc only after we discover the need for a quirk,
it's already too late, due to stable DT rules. Hence we always document and
use SoC-specific compatible values, sometimes combined with family-specific
compatible values. The driver only matches to the as least specific value as
possible.

I hope this clears up your worries.

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

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
>> Simply document new compat strings.
>> There appears to be no need for a driver updates.
>>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> index b19be08a8113..7c231b3e5872 100644
>> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
>> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
>>  Required properties:
>>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
>>             "renesas,pci-r8a7791" for the R8A7791 SoC;
>> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
>
> What's the benefit of adding a string here if the driver doesn't check
> for it?  Since the driver doesn't look for it, there's no way to test
> anything.

If we ever discover a difference between PCI on r8a7793 compared to PCI on
other SoCs of the R-Car Gen2 family, we can handle that difference in the
driver.

> It doesn't seem like this file is an authoritative source of names, so

Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
for their existence in the binding documentation. Hence we always add the
compatible values to the DT binding docs, before we start using them.

> if we add it here, there's the possibility the r8a7793 will be
> canceled or renamed, and then we'd have to update this if the driver
> ever did need an r8a7793-specific quirk.  If we waited until the

I don't understand what you mean here.

> driver actually needs a quirk, then we'd know exactly what name to
> look for and we could update the driver, DT, and doc all together.

If we update driver, DT, and doc only after we discover the need for a quirk,
it's already too late, due to stable DT rules. Hence we always document and
use SoC-specific compatible values, sometimes combined with family-specific
compatible values. The driver only matches to the as least specific value as
possible.

I hope this clears up your worries.

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

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Bjorn Helgaas]

On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> Hi Bjorn,
> 
> On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> >> Simply document new compat strings.
> >> There appears to be no need for a driver updates.
> >>
> >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >> ---
> >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> index b19be08a8113..7c231b3e5872 100644
> >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> >>  Required properties:
> >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> >
> > What's the benefit of adding a string here if the driver doesn't check
> > for it?  Since the driver doesn't look for it, there's no way to test
> > anything.
> 
> If we ever discover a difference between PCI on r8a7793 compared to PCI on
> other SoCs of the R-Car Gen2 family, we can handle that difference in the
> driver.
> 
> > It doesn't seem like this file is an authoritative source of names, so
> 
> Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> for their existence in the binding documentation. Hence we always add the
> compatible values to the DT binding docs, before we start using them.
> 
> > if we add it here, there's the possibility the r8a7793 will be
> > canceled or renamed, and then we'd have to update this if the driver
> > ever did need an r8a7793-specific quirk.  If we waited until the
> 
> I don't understand what you mean here.
> 
> > driver actually needs a quirk, then we'd know exactly what name to
> > look for and we could update the driver, DT, and doc all together.
> 
> If we update driver, DT, and doc only after we discover the need for a quirk,
> it's already too late, due to stable DT rules. Hence we always document and
> use SoC-specific compatible values, sometimes combined with family-specific
> compatible values. The driver only matches to the as least specific value as
> possible.

The stable DT rules seem to be the key here, but I don't know what
they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
doesn't clear it up for me.

I was assuming vendors could ship a DT in a platform ROM, in the same
way platforms ship with an ACPI system description.  For ACPI, the
_HID/_CID in the ROM in the field is authoritative in the sense that
we have to regard it as a fixed, unchangeable feature of the platform.
If we want a driver to recognize that device, we have to build the ID
from the ROM into the driver, and it doesn't matter what is documented
in the spec or in the kernel source.

If we had a one-sentence description of why adding the doc update when
we actually need it is too late, that would probably be enough.

I'm perfectly happy with the PCI changes, so if somebody else wants to
just merge all these via a DT tree, I'm happy to ack the PCI ones.

Bjorn

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Bjorn Helgaas]

On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> Hi Bjorn,
> 
> On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> >> Simply document new compat strings.
> >> There appears to be no need for a driver updates.
> >>
> >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >> ---
> >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> index b19be08a8113..7c231b3e5872 100644
> >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> >>  Required properties:
> >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> >
> > What's the benefit of adding a string here if the driver doesn't check
> > for it?  Since the driver doesn't look for it, there's no way to test
> > anything.
> 
> If we ever discover a difference between PCI on r8a7793 compared to PCI on
> other SoCs of the R-Car Gen2 family, we can handle that difference in the
> driver.
> 
> > It doesn't seem like this file is an authoritative source of names, so
> 
> Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> for their existence in the binding documentation. Hence we always add the
> compatible values to the DT binding docs, before we start using them.
> 
> > if we add it here, there's the possibility the r8a7793 will be
> > canceled or renamed, and then we'd have to update this if the driver
> > ever did need an r8a7793-specific quirk.  If we waited until the
> 
> I don't understand what you mean here.
> 
> > driver actually needs a quirk, then we'd know exactly what name to
> > look for and we could update the driver, DT, and doc all together.
> 
> If we update driver, DT, and doc only after we discover the need for a quirk,
> it's already too late, due to stable DT rules. Hence we always document and
> use SoC-specific compatible values, sometimes combined with family-specific
> compatible values. The driver only matches to the as least specific value as
> possible.

The stable DT rules seem to be the key here, but I don't know what
they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
doesn't clear it up for me.

I was assuming vendors could ship a DT in a platform ROM, in the same
way platforms ship with an ACPI system description.  For ACPI, the
_HID/_CID in the ROM in the field is authoritative in the sense that
we have to regard it as a fixed, unchangeable feature of the platform.
If we want a driver to recognize that device, we have to build the ID
from the ROM into the driver, and it doesn't matter what is documented
in the spec or in the kernel source.

If we had a one-sentence description of why adding the doc update when
we actually need it is too late, that would probably be enough.

I'm perfectly happy with the PCI changes, so if somebody else wants to
just merge all these via a DT tree, I'm happy to ack the PCI ones.

Bjorn

Re: [PATCH 3/4] PCI: rcar: Add Gen2 fallback compatibility string

[Bjorn Helgaas]

On Tue, Dec 01, 2015 at 04:24:31PM +0900, Simon Horman wrote:
> Add fallback compatibility string for R-Car Gen 2 Family.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 13 ++++++++++---
>  drivers/pci/host/pcie-rcar.c                       |  1 +
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 29d3b989d3b0..872cea085be8 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -1,8 +1,15 @@
>  * Renesas RCar PCIe interface
>  
>  Required properties:
> -- compatible: should contain one of the following
> -	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
> +compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> +	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
> +	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
> +	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
> +
> +	    When compatible with the generic version, nodes must list the
> +	    SoC-specific version corresponding to the platform first
> +	    followed by the generic version.
> +
>  - reg: base address and length of the pcie controller registers.
>  - #address-cells: set to <3>
>  - #size-cells: set to <2>
> @@ -25,7 +32,7 @@ Example:
>  SoC specific DT Entry:
>  
>  	pcie: pcie@fe000000 {
> -		compatible = "renesas,pcie-r8a7791";
> +		compatible = "renesas,pcie-r8a7791", "renesas,pcie-gen2";
>  		reg = <0 0xfe000000 0 0x80000>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index f4fa6c537448..17ee0422ddb1 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -917,6 +917,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
>  
>  static const struct of_device_id rcar_pcie_of_match[] = {
>  	{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
> +	{ .compatible = "renesas,pcie-gen2", .data = rcar_pcie_hw_init },
>  	{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
>  	{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
>  	{},
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] PCI: rcar: Add Gen2 fallback compatibility string

[Bjorn Helgaas]

On Tue, Dec 01, 2015 at 04:24:31PM +0900, Simon Horman wrote:
> Add fallback compatibility string for R-Car Gen 2 Family.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 13 ++++++++++---
>  drivers/pci/host/pcie-rcar.c                       |  1 +
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 29d3b989d3b0..872cea085be8 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -1,8 +1,15 @@
>  * Renesas RCar PCIe interface
>  
>  Required properties:
> -- compatible: should contain one of the following
> -	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
> +compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> +	    "renesas,pcie-r8a7790" for the R8A7790 SoC;
> +	    "renesas,pcie-r8a7791" for the R8A7791 SoC;
> +	    "renesas,pcie-gen2" for a generic R-Car Gen2 compatible device.
> +
> +	    When compatible with the generic version, nodes must list the
> +	    SoC-specific version corresponding to the platform first
> +	    followed by the generic version.
> +
>  - reg: base address and length of the pcie controller registers.
>  - #address-cells: set to <3>
>  - #size-cells: set to <2>
> @@ -25,7 +32,7 @@ Example:
>  SoC specific DT Entry:
>  
>  	pcie: pcie@fe000000 {
> -		compatible = "renesas,pcie-r8a7791";
> +		compatible = "renesas,pcie-r8a7791", "renesas,pcie-gen2";
>  		reg = <0 0xfe000000 0 0x80000>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index f4fa6c537448..17ee0422ddb1 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -917,6 +917,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
>  
>  static const struct of_device_id rcar_pcie_of_match[] = {
>  	{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
> +	{ .compatible = "renesas,pcie-gen2", .data = rcar_pcie_hw_init },
>  	{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
>  	{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
>  	{},
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

On Mon, Dec 07, 2015 at 09:38:33AM -0600, Bjorn Helgaas wrote:
> On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> > Hi Bjorn,
> > 
> > On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> > >> Simply document new compat strings.
> > >> There appears to be no need for a driver updates.
> > >>
> > >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > >> ---
> > >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> > >>  1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> index b19be08a8113..7c231b3e5872 100644
> > >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> > >>  Required properties:
> > >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> > >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> > >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> > >
> > > What's the benefit of adding a string here if the driver doesn't check
> > > for it?  Since the driver doesn't look for it, there's no way to test
> > > anything.
> > 
> > If we ever discover a difference between PCI on r8a7793 compared to PCI on
> > other SoCs of the R-Car Gen2 family, we can handle that difference in the
> > driver.
> > 
> > > It doesn't seem like this file is an authoritative source of names, so
> > 
> > Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> > for their existence in the binding documentation. Hence we always add the
> > compatible values to the DT binding docs, before we start using them.
> > 
> > > if we add it here, there's the possibility the r8a7793 will be
> > > canceled or renamed, and then we'd have to update this if the driver
> > > ever did need an r8a7793-specific quirk.  If we waited until the
> > 
> > I don't understand what you mean here.
> > 
> > > driver actually needs a quirk, then we'd know exactly what name to
> > > look for and we could update the driver, DT, and doc all together.
> > 
> > If we update driver, DT, and doc only after we discover the need for a quirk,
> > it's already too late, due to stable DT rules. Hence we always document and
> > use SoC-specific compatible values, sometimes combined with family-specific
> > compatible values. The driver only matches to the as least specific value as
> > possible.
> 
> The stable DT rules seem to be the key here, but I don't know what
> they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
> doesn't clear it up for me.
> 
> I was assuming vendors could ship a DT in a platform ROM, in the same
> way platforms ship with an ACPI system description.  For ACPI, the
> _HID/_CID in the ROM in the field is authoritative in the sense that
> we have to regard it as a fixed, unchangeable feature of the platform.
> If we want a driver to recognize that device, we have to build the ID
> from the ROM into the driver, and it doesn't matter what is documented
> in the spec or in the kernel source.
> 
> If we had a one-sentence description of why adding the doc update when
> we actually need it is too late, that would probably be enough.

I agree that would be useful.

> I'm perfectly happy with the PCI changes, so if somebody else wants to
> just merge all these via a DT tree, I'm happy to ack the PCI ones.

I have no fixed ideas about who should take these changes
but I think you could take them through the PCI tree if you
are so inclined.

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

On Mon, Dec 07, 2015 at 09:38:33AM -0600, Bjorn Helgaas wrote:
> On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> > Hi Bjorn,
> > 
> > On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> > >> Simply document new compat strings.
> > >> There appears to be no need for a driver updates.
> > >>
> > >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > >> ---
> > >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> > >>  1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> index b19be08a8113..7c231b3e5872 100644
> > >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> > >>  Required properties:
> > >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> > >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> > >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> > >
> > > What's the benefit of adding a string here if the driver doesn't check
> > > for it?  Since the driver doesn't look for it, there's no way to test
> > > anything.
> > 
> > If we ever discover a difference between PCI on r8a7793 compared to PCI on
> > other SoCs of the R-Car Gen2 family, we can handle that difference in the
> > driver.
> > 
> > > It doesn't seem like this file is an authoritative source of names, so
> > 
> > Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> > for their existence in the binding documentation. Hence we always add the
> > compatible values to the DT binding docs, before we start using them.
> > 
> > > if we add it here, there's the possibility the r8a7793 will be
> > > canceled or renamed, and then we'd have to update this if the driver
> > > ever did need an r8a7793-specific quirk.  If we waited until the
> > 
> > I don't understand what you mean here.
> > 
> > > driver actually needs a quirk, then we'd know exactly what name to
> > > look for and we could update the driver, DT, and doc all together.
> > 
> > If we update driver, DT, and doc only after we discover the need for a quirk,
> > it's already too late, due to stable DT rules. Hence we always document and
> > use SoC-specific compatible values, sometimes combined with family-specific
> > compatible values. The driver only matches to the as least specific value as
> > possible.
> 
> The stable DT rules seem to be the key here, but I don't know what
> they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
> doesn't clear it up for me.
> 
> I was assuming vendors could ship a DT in a platform ROM, in the same
> way platforms ship with an ACPI system description.  For ACPI, the
> _HID/_CID in the ROM in the field is authoritative in the sense that
> we have to regard it as a fixed, unchangeable feature of the platform.
> If we want a driver to recognize that device, we have to build the ID
> from the ROM into the driver, and it doesn't matter what is documented
> in the spec or in the kernel source.
> 
> If we had a one-sentence description of why adding the doc update when
> we actually need it is too late, that would probably be enough.

I agree that would be useful.

> I'm perfectly happy with the PCI changes, so if somebody else wants to
> just merge all these via a DT tree, I'm happy to ack the PCI ones.

I have no fixed ideas about who should take these changes
but I think you could take them through the PCI tree if you
are so inclined.

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

On Tue, Dec 08, 2015 at 09:45:19AM +0900, Simon Horman wrote:
> On Mon, Dec 07, 2015 at 09:38:33AM -0600, Bjorn Helgaas wrote:
> > On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> > > Hi Bjorn,
> > > 
> > > On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> > > >> Simply document new compat strings.
> > > >> There appears to be no need for a driver updates.
> > > >>
> > > >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > >> ---
> > > >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> > > >>  1 file changed, 1 insertion(+)
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> index b19be08a8113..7c231b3e5872 100644
> > > >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> > > >>  Required properties:
> > > >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> > > >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> > > >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> > > >
> > > > What's the benefit of adding a string here if the driver doesn't check
> > > > for it?  Since the driver doesn't look for it, there's no way to test
> > > > anything.
> > > 
> > > If we ever discover a difference between PCI on r8a7793 compared to PCI on
> > > other SoCs of the R-Car Gen2 family, we can handle that difference in the
> > > driver.
> > > 
> > > > It doesn't seem like this file is an authoritative source of names, so
> > > 
> > > Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> > > for their existence in the binding documentation. Hence we always add the
> > > compatible values to the DT binding docs, before we start using them.
> > > 
> > > > if we add it here, there's the possibility the r8a7793 will be
> > > > canceled or renamed, and then we'd have to update this if the driver
> > > > ever did need an r8a7793-specific quirk.  If we waited until the
> > > 
> > > I don't understand what you mean here.
> > > 
> > > > driver actually needs a quirk, then we'd know exactly what name to
> > > > look for and we could update the driver, DT, and doc all together.
> > > 
> > > If we update driver, DT, and doc only after we discover the need for a quirk,
> > > it's already too late, due to stable DT rules. Hence we always document and
> > > use SoC-specific compatible values, sometimes combined with family-specific
> > > compatible values. The driver only matches to the as least specific value as
> > > possible.
> > 
> > The stable DT rules seem to be the key here, but I don't know what
> > they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
> > doesn't clear it up for me.
> > 
> > I was assuming vendors could ship a DT in a platform ROM, in the same
> > way platforms ship with an ACPI system description.  For ACPI, the
> > _HID/_CID in the ROM in the field is authoritative in the sense that
> > we have to regard it as a fixed, unchangeable feature of the platform.
> > If we want a driver to recognize that device, we have to build the ID
> > from the ROM into the driver, and it doesn't matter what is documented
> > in the spec or in the kernel source.
> > 
> > If we had a one-sentence description of why adding the doc update when
> > we actually need it is too late, that would probably be enough.
> 
> I agree that would be useful.

Sorry for letting this slip. How about the following in the relevant changelogs:

	By documenting this compat sting it may be used in DTSs shipped,
	for example as part of ROMs. It must be used in conjunction with
	the Gen2 fallback compat string. At this time there are no known
	differences between the r8a7793 IP block and that implemented by
	the driver for the Gen2 fallback compat string. Thus there is no
	need to update the driver as the use of the Gen2 fallback compat
	string will activate the correct code in the current driver while
	leaving the option for r8a7793-specific driver code to be activated
	in an updated driver should the need arise.

> > I'm perfectly happy with the PCI changes, so if somebody else wants to
> > just merge all these via a DT tree, I'm happy to ack the PCI ones.
> 
> I have no fixed ideas about who should take these changes
> but I think you could take them through the PCI tree if you
> are so inclined.

Re: [PATCH 2/4] PCI: rcar-gen2: Add device tree support for r8a7793

[Simon Horman]

On Tue, Dec 08, 2015 at 09:45:19AM +0900, Simon Horman wrote:
> On Mon, Dec 07, 2015 at 09:38:33AM -0600, Bjorn Helgaas wrote:
> > On Sat, Dec 05, 2015 at 11:38:37AM +0100, Geert Uytterhoeven wrote:
> > > Hi Bjorn,
> > > 
> > > On Fri, Dec 4, 2015 at 10:26 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Tue, Dec 01, 2015 at 04:24:30PM +0900, Simon Horman wrote:
> > > >> Simply document new compat strings.
> > > >> There appears to be no need for a driver updates.
> > > >>
> > > >> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > >> ---
> > > >>  Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
> > > >>  1 file changed, 1 insertion(+)
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> index b19be08a8113..7c231b3e5872 100644
> > > >> --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
> > > >> @@ -8,6 +8,7 @@ OHCI and EHCI controllers.
> > > >>  Required properties:
> > > >>  - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
> > > >>             "renesas,pci-r8a7791" for the R8A7791 SoC;
> > > >> +           "renesas,pci-r8a7793" for the R8A7793 SoC;
> > > >
> > > > What's the benefit of adding a string here if the driver doesn't check
> > > > for it?  Since the driver doesn't look for it, there's no way to test
> > > > anything.
> > > 
> > > If we ever discover a difference between PCI on r8a7793 compared to PCI on
> > > other SoCs of the R-Car Gen2 family, we can handle that difference in the
> > > driver.
> > > 
> > > > It doesn't seem like this file is an authoritative source of names, so
> > > 
> > > Yes it is. When adding compatible values to a DTS, checkpatch.pl will check
> > > for their existence in the binding documentation. Hence we always add the
> > > compatible values to the DT binding docs, before we start using them.
> > > 
> > > > if we add it here, there's the possibility the r8a7793 will be
> > > > canceled or renamed, and then we'd have to update this if the driver
> > > > ever did need an r8a7793-specific quirk.  If we waited until the
> > > 
> > > I don't understand what you mean here.
> > > 
> > > > driver actually needs a quirk, then we'd know exactly what name to
> > > > look for and we could update the driver, DT, and doc all together.
> > > 
> > > If we update driver, DT, and doc only after we discover the need for a quirk,
> > > it's already too late, due to stable DT rules. Hence we always document and
> > > use SoC-specific compatible values, sometimes combined with family-specific
> > > compatible values. The driver only matches to the as least specific value as
> > > possible.
> > 
> > The stable DT rules seem to be the key here, but I don't know what
> > they are.  I found Documentation/devicetree/bindings/ABI.txt, but it
> > doesn't clear it up for me.
> > 
> > I was assuming vendors could ship a DT in a platform ROM, in the same
> > way platforms ship with an ACPI system description.  For ACPI, the
> > _HID/_CID in the ROM in the field is authoritative in the sense that
> > we have to regard it as a fixed, unchangeable feature of the platform.
> > If we want a driver to recognize that device, we have to build the ID
> > from the ROM into the driver, and it doesn't matter what is documented
> > in the spec or in the kernel source.
> > 
> > If we had a one-sentence description of why adding the doc update when
> > we actually need it is too late, that would probably be enough.
> 
> I agree that would be useful.

Sorry for letting this slip. How about the following in the relevant changelogs:

	By documenting this compat sting it may be used in DTSs shipped,
	for example as part of ROMs. It must be used in conjunction with
	the Gen2 fallback compat string. At this time there are no known
	differences between the r8a7793 IP block and that implemented by
	the driver for the Gen2 fallback compat string. Thus there is no
	need to update the driver as the use of the Gen2 fallback compat
	string will activate the correct code in the current driver while
	leaving the option for r8a7793-specific driver code to be activated
	in an updated driver should the need arise.

> > I'm perfectly happy with the PCI changes, so if somebody else wants to
> > just merge all these via a DT tree, I'm happy to ack the PCI ones.
> 
> I have no fixed ideas about who should take these changes
> but I think you could take them through the PCI tree if you
> are so inclined.