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

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

[Simon Horman]

Hi,

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

Key Changes in v2:
* Include "rcar-" in generic bindings

Simon Horman (4):
  PCI: rcar-gen2: add gen2 fallback 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 v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Simon Horman]

Hi,

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

Key Changes in v2:
* Include "rcar-" in generic bindings

Simon Horman (4):
  PCI: rcar-gen2: add gen2 fallback 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 v2 1/4] PCI: rcar-gen2: 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>

---
v2
* Include "rcar-" in new compatibility string
---
 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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
 	{ .compatible = "renesas,pci-r8a7790", },
 	{ .compatible = "renesas,pci-r8a7791", },
 	{ .compatible = "renesas,pci-r8a7794", },
-- 
2.1.4

[PATCH v2 1/4] PCI: rcar-gen2: 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>

---
v2
* Include "rcar-" in new compatibility string
---
 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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
 	{ .compatible = "renesas,pci-r8a7790", },
 	{ .compatible = "renesas,pci-r8a7791", },
 	{ .compatible = "renesas,pci-r8a7794", },
-- 
2.1.4

Re: [PATCH v2 1/4] PCI: rcar-gen2: add gen2 fallback compatibility string

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:37AM +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: Rob Herring <robh@kernel.org>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
>  	{ .compatible = "renesas,pci-r8a7790", },
>  	{ .compatible = "renesas,pci-r8a7791", },
>  	{ .compatible = "renesas,pci-r8a7794", },
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] PCI: rcar-gen2: add gen2 fallback compatibility string

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:37AM +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: Rob Herring <robh@kernel.org>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
>  	{ .compatible = "renesas,pci-r8a7790", },
>  	{ .compatible = "renesas,pci-r8a7791", },
>  	{ .compatible = "renesas,pci-r8a7794", },
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] PCI: rcar-gen2: add gen2 fallback compatibility string

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:37AM +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>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
>  	{ .compatible = "renesas,pci-r8a7790", },
>  	{ .compatible = "renesas,pci-r8a7791", },
>  	{ .compatible = "renesas,pci-r8a7794", },
> -- 
> 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 v2 1/4] PCI: rcar-gen2: add gen2 fallback compatibility string

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:37AM +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>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..089a99dcdf10 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-rcar-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-rcar-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..9980a4bdae7e 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-rcar-gen2", },
>  	{ .compatible = "renesas,pci-r8a7790", },
>  	{ .compatible = "renesas,pci-r8a7791", },
>  	{ .compatible = "renesas,pci-r8a7794", },
> -- 
> 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

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

[Simon Horman]

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

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

---
* The r8a7792 is omitted from this change as the hardware in question
  does not appear to be present on that SoC.

v2
* No change
---
 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 089a99dcdf10..9c50e0c9d6da 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
-- 
2.1.4

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

[Simon Horman]

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

Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

---
* The r8a7792 is omitted from this change as the hardware in question
  does not appear to be present on that SoC.

v2
* No change
---
 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 089a99dcdf10..9c50e0c9d6da 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
-- 
2.1.4

--
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

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

[Simon Horman]

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

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

---
* The r8a7792 is omitted from this change as the hardware in question
  does not appear to be present on that SoC.

v2
* No change
---
 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 089a99dcdf10..9c50e0c9d6da 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
-- 
2.1.4

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

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:38AM +0900, Simon Horman wrote:
> Simply document new compatibility string.
> As a previous patch adds a generic R-Car Gen2 compatibility string
> there appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Rob Herring <robh@kernel.org>

> 
> ---
> * The r8a7792 is omitted from this change as the hardware in question
>   does not appear to be present on that SoC.
> 
> v2
> * No change
> ---
>  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 089a99dcdf10..9c50e0c9d6da 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:38AM +0900, Simon Horman wrote:
> Simply document new compatibility string.
> As a previous patch adds a generic R-Car Gen2 compatibility string
> there appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Rob Herring <robh@kernel.org>

> 
> ---
> * The r8a7792 is omitted from this change as the hardware in question
>   does not appear to be present on that SoC.
> 
> v2
> * No change
> ---
>  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 089a99dcdf10..9c50e0c9d6da 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 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>

---
v2
* Include "rcar-" in new compatibility string
---
 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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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 v2 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>

---
v2
* Include "rcar-" in new compatibility string
---
 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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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

Re: [PATCH v2 3/4] PCI: rcar: add gen2 fallback compatibility string

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:39AM +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: Rob Herring <robh@kernel.org>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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 devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] PCI: rcar: add gen2 fallback compatibility string

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:39AM +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: Rob Herring <robh@kernel.org>

> 
> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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 devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] PCI: rcar: add gen2 fallback compatibility string

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:39AM +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>

> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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 v2 3/4] PCI: rcar: add gen2 fallback compatibility string

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:39AM +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>

> ---
> v2
> * Include "rcar-" in new compatibility string
> ---
>  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..6b4d2f798386 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-rcar-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-rcar-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..047279bdc3fe 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-rcar-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

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

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility 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.

v2
* No change
---
 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 6b4d2f798386..d529530b27d2 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
 	    When compatible with the generic version, nodes must list the
-- 
2.1.4

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

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility 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.

v2
* No change
---
 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 6b4d2f798386..d529530b27d2 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
 	    When compatible with the generic version, nodes must list the
-- 
2.1.4

Re: [PATCH v2 4/4] PCI: rcar: add device tree support for r8a7793

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:40AM +0900, Simon Horman wrote:
> Simply document new compatibility string.
> As a previous patch adds a generic R-Car Gen2 compatibility string
> there appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Rob Herring <robh@kernel.org>

> 
> ---
> * The r8a7792 and r8a7794 are omitted from this change as the
>   hardware in question does not appear to be present on those SoCs.
> 
> v2
> * No change
> ---
>  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 6b4d2f798386..d529530b27d2 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
>  
>  	    When compatible with the generic version, nodes must list the
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] PCI: rcar: add device tree support for r8a7793

[Rob Herring]

On Thu, Dec 03, 2015 at 07:51:40AM +0900, Simon Horman wrote:
> Simply document new compatibility string.
> As a previous patch adds a generic R-Car Gen2 compatibility string
> there appears to be no need for a driver updates.
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Rob Herring <robh@kernel.org>

> 
> ---
> * The r8a7792 and r8a7794 are omitted from this change as the
>   hardware in question does not appear to be present on those SoCs.
> 
> v2
> * No change
> ---
>  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 6b4d2f798386..d529530b27d2 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-rcar-gen2" for a generic R-Car Gen2 compatible device.
>  
>  	    When compatible with the generic version, nodes must list the
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> provide a complete set of compatibility strings for known Gen2 SoCs.
> 
> Key Changes in v2:
> * Include "rcar-" in generic bindings
> 
> Simon Horman (4):
>   PCI: rcar-gen2: add gen2 fallback 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(-)

I applied these:

>   PCI: rcar-gen2: add gen2 fallback compatibility string
>   PCI: rcar: add gen2 fallback compatibility string

to pci/host-rcar for v4.5, thanks!

I haven't applied the R8A7793 binding documentation updates yet, but
I'll be happy to do so given a short description of why they're
useful (since they don't update a DT or the driver).  Or they could be
merged via a DT tree.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> provide a complete set of compatibility strings for known Gen2 SoCs.
> 
> Key Changes in v2:
> * Include "rcar-" in generic bindings
> 
> Simon Horman (4):
>   PCI: rcar-gen2: add gen2 fallback 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(-)

I applied these:

>   PCI: rcar-gen2: add gen2 fallback compatibility string
>   PCI: rcar: add gen2 fallback compatibility string

to pci/host-rcar for v4.5, thanks!

I haven't applied the R8A7793 binding documentation updates yet, but
I'll be happy to do so given a short description of why they're
useful (since they don't update a DT or the driver).  Or they could be
merged via a DT tree.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Simon Horman]

On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> > Hi,
> > 
> > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> > provide a complete set of compatibility strings for known Gen2 SoCs.
> > 
> > Key Changes in v2:
> > * Include "rcar-" in generic bindings
> > 
> > Simon Horman (4):
> >   PCI: rcar-gen2: add gen2 fallback 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(-)
> 
> I applied these:
> 
> >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >   PCI: rcar: add gen2 fallback compatibility string
> 
> to pci/host-rcar for v4.5, thanks!
> 
> I haven't applied the R8A7793 binding documentation updates yet, but
> I'll be happy to do so given a short description of why they're
> useful (since they don't update a DT or the driver).  Or they could be
> merged via a DT tree.

To clarify: you would like a description in the changelog?

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Simon Horman]

On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> > Hi,
> > 
> > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> > provide a complete set of compatibility strings for known Gen2 SoCs.
> > 
> > Key Changes in v2:
> > * Include "rcar-" in generic bindings
> > 
> > Simon Horman (4):
> >   PCI: rcar-gen2: add gen2 fallback 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(-)
> 
> I applied these:
> 
> >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >   PCI: rcar: add gen2 fallback compatibility string
> 
> to pci/host-rcar for v4.5, thanks!
> 
> I haven't applied the R8A7793 binding documentation updates yet, but
> I'll be happy to do so given a short description of why they're
> useful (since they don't update a DT or the driver).  Or they could be
> merged via a DT tree.

To clarify: you would like a description in the changelog?

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> > > Hi,
> > > 
> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> > > 
> > > Key Changes in v2:
> > > * Include "rcar-" in generic bindings
> > > 
> > > Simon Horman (4):
> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> > 
> > I applied these:
> > 
> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> > >   PCI: rcar: add gen2 fallback compatibility string
> > 
> > to pci/host-rcar for v4.5, thanks!
> > 
> > I haven't applied the R8A7793 binding documentation updates yet, but
> > I'll be happy to do so given a short description of why they're
> > useful (since they don't update a DT or the driver).  Or they could be
> > merged via a DT tree.
> 
> To clarify: you would like a description in the changelog?

Yes, please.  The email discussion so far hasn't contained what I'm
looking for (if it had, I would have just inserted it and been done
with it).

Apparently it has to do with the stable DT rules, which I don't know.
A concrete example would probably help clear it up.

I've applied the parts that touch PCI.  I won't be offended if the
binding documentation patches go as-is via another tree.  It's just
that if *I'm* going to apply them, I'd like to understand better what
the benefit is.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> > > Hi,
> > > 
> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> > > 
> > > Key Changes in v2:
> > > * Include "rcar-" in generic bindings
> > > 
> > > Simon Horman (4):
> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> > 
> > I applied these:
> > 
> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> > >   PCI: rcar: add gen2 fallback compatibility string
> > 
> > to pci/host-rcar for v4.5, thanks!
> > 
> > I haven't applied the R8A7793 binding documentation updates yet, but
> > I'll be happy to do so given a short description of why they're
> > useful (since they don't update a DT or the driver).  Or they could be
> > merged via a DT tree.
> 
> To clarify: you would like a description in the changelog?

Yes, please.  The email discussion so far hasn't contained what I'm
looking for (if it had, I would have just inserted it and been done
with it).

Apparently it has to do with the stable DT rules, which I don't know.
A concrete example would probably help clear it up.

I've applied the parts that touch PCI.  I won't be offended if the
binding documentation patches go as-is via another tree.  It's just
that if *I'm* going to apply them, I'd like to understand better what
the benefit is.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> > >
>> > > Key Changes in v2:
>> > > * Include "rcar-" in generic bindings
>> > >
>> > > Simon Horman (4):
>> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >
>> > I applied these:
>> >
>> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> > >   PCI: rcar: add gen2 fallback compatibility string
>> >
>> > to pci/host-rcar for v4.5, thanks!
>> >
>> > I haven't applied the R8A7793 binding documentation updates yet, but
>> > I'll be happy to do so given a short description of why they're
>> > useful (since they don't update a DT or the driver).  Or they could be
>> > merged via a DT tree.
>>
>> To clarify: you would like a description in the changelog?
>
> Yes, please.  The email discussion so far hasn't contained what I'm
> looking for (if it had, I would have just inserted it and been done
> with it).
>
> Apparently it has to do with the stable DT rules, which I don't know.
> A concrete example would probably help clear it up.

The stable DT rules mean that an old DTS should keep on working with
newer kernels.

Suppose we have two SoCs, that both contain "foo" modules, which look
identical. Hence the DTS for both declares the devices to be compatible
with "vendor,foo".

Later, we discover a difference between the two "foo" modules in the two
SoCs (e.g. a feature present in one of them, or worse, a bug), which we
need to handle in the driver. But how can we distinguish between them?
We can change the compatible value in the DTS, but that means the user
has to update the DTS when updating the kernel. For a new feature that
may be deemed acceptable, for a bug fix that's not acceptable.

Hence we always use an SoC-specific compatible value, which may or may
not be accompanied by a family-specific and/or generic compatible value.
As long as everything can be handled the same, the driver will just match
against the most generic compatible value used. But if needed later, the
driver can be updated to match against a more specific compatible value,
and can have special handling for  a module in a specific SoC.

So that's why we want to have compatible value in the DT bindings that
are not necessarily used by the driver.

In a perfect world, where all hardware is properly documented, or even
Open Source, we wouldn't need this. There we could just declare a device
compatible with what it really is, based on the module's internal version ID
(ideally a git commit ID of its HDL source ;-).

I hope the above explains it. If you have more questions, feel free to ask!

> I've applied the parts that touch PCI.  I won't be offended if the
> binding documentation patches go as-is via another tree.  It's just
> that if *I'm* going to apply them, I'd like to understand better what
> the benefit is.

DT binding updates typically go through the subsystem maintainer,
just like driver updates.

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

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> > >
>> > > Key Changes in v2:
>> > > * Include "rcar-" in generic bindings
>> > >
>> > > Simon Horman (4):
>> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >
>> > I applied these:
>> >
>> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> > >   PCI: rcar: add gen2 fallback compatibility string
>> >
>> > to pci/host-rcar for v4.5, thanks!
>> >
>> > I haven't applied the R8A7793 binding documentation updates yet, but
>> > I'll be happy to do so given a short description of why they're
>> > useful (since they don't update a DT or the driver).  Or they could be
>> > merged via a DT tree.
>>
>> To clarify: you would like a description in the changelog?
>
> Yes, please.  The email discussion so far hasn't contained what I'm
> looking for (if it had, I would have just inserted it and been done
> with it).
>
> Apparently it has to do with the stable DT rules, which I don't know.
> A concrete example would probably help clear it up.

The stable DT rules mean that an old DTS should keep on working with
newer kernels.

Suppose we have two SoCs, that both contain "foo" modules, which look
identical. Hence the DTS for both declares the devices to be compatible
with "vendor,foo".

Later, we discover a difference between the two "foo" modules in the two
SoCs (e.g. a feature present in one of them, or worse, a bug), which we
need to handle in the driver. But how can we distinguish between them?
We can change the compatible value in the DTS, but that means the user
has to update the DTS when updating the kernel. For a new feature that
may be deemed acceptable, for a bug fix that's not acceptable.

Hence we always use an SoC-specific compatible value, which may or may
not be accompanied by a family-specific and/or generic compatible value.
As long as everything can be handled the same, the driver will just match
against the most generic compatible value used. But if needed later, the
driver can be updated to match against a more specific compatible value,
and can have special handling for  a module in a specific SoC.

So that's why we want to have compatible value in the DT bindings that
are not necessarily used by the driver.

In a perfect world, where all hardware is properly documented, or even
Open Source, we wouldn't need this. There we could just declare a device
compatible with what it really is, based on the module's internal version ID
(ideally a git commit ID of its HDL source ;-).

I hope the above explains it. If you have more questions, feel free to ask!

> I've applied the parts that touch PCI.  I won't be offended if the
> binding documentation patches go as-is via another tree.  It's just
> that if *I'm* going to apply them, I'd like to understand better what
> the benefit is.

DT binding updates typically go through the subsystem maintainer,
just like driver updates.

Thanks!

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 v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> > >
>> > > Key Changes in v2:
>> > > * Include "rcar-" in generic bindings
>> > >
>> > > Simon Horman (4):
>> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >
>> > I applied these:
>> >
>> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> > >   PCI: rcar: add gen2 fallback compatibility string
>> >
>> > to pci/host-rcar for v4.5, thanks!
>> >
>> > I haven't applied the R8A7793 binding documentation updates yet, but
>> > I'll be happy to do so given a short description of why they're
>> > useful (since they don't update a DT or the driver).  Or they could be
>> > merged via a DT tree.
>>
>> To clarify: you would like a description in the changelog?
>
> Yes, please.  The email discussion so far hasn't contained what I'm
> looking for (if it had, I would have just inserted it and been done
> with it).
>
> Apparently it has to do with the stable DT rules, which I don't know.
> A concrete example would probably help clear it up.

The stable DT rules mean that an old DTS should keep on working with
newer kernels.

Suppose we have two SoCs, that both contain "foo" modules, which look
identical. Hence the DTS for both declares the devices to be compatible
with "vendor,foo".

Later, we discover a difference between the two "foo" modules in the two
SoCs (e.g. a feature present in one of them, or worse, a bug), which we
need to handle in the driver. But how can we distinguish between them?
We can change the compatible value in the DTS, but that means the user
has to update the DTS when updating the kernel. For a new feature that
may be deemed acceptable, for a bug fix that's not acceptable.

Hence we always use an SoC-specific compatible value, which may or may
not be accompanied by a family-specific and/or generic compatible value.
As long as everything can be handled the same, the driver will just match
against the most generic compatible value used. But if needed later, the
driver can be updated to match against a more specific compatible value,
and can have special handling for  a module in a specific SoC.

So that's why we want to have compatible value in the DT bindings that
are not necessarily used by the driver.

In a perfect world, where all hardware is properly documented, or even
Open Source, we wouldn't need this. There we could just declare a device
compatible with what it really is, based on the module's internal version ID
(ideally a git commit ID of its HDL source ;-).

I hope the above explains it. If you have more questions, feel free to ask!

> I've applied the parts that touch PCI.  I won't be offended if the
> binding documentation patches go as-is via another tree.  It's just
> that if *I'm* going to apply them, I'd like to understand better what
> the benefit is.

DT binding updates typically go through the subsystem maintainer,
just like driver updates.

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

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

Hi Geert,

On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> >> > >
> >> > > Key Changes in v2:
> >> > > * Include "rcar-" in generic bindings
> >> > >
> >> > > Simon Horman (4):
> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> >> >
> >> > I applied these:
> >> >
> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >> > >   PCI: rcar: add gen2 fallback compatibility string
> >> >
> >> > to pci/host-rcar for v4.5, thanks!
> >> >
> >> > I haven't applied the R8A7793 binding documentation updates yet, but
> >> > I'll be happy to do so given a short description of why they're
> >> > useful (since they don't update a DT or the driver).  Or they could be
> >> > merged via a DT tree.
> >>
> >> To clarify: you would like a description in the changelog?
> >
> > Yes, please.  The email discussion so far hasn't contained what I'm
> > looking for (if it had, I would have just inserted it and been done
> > with it).
> >
> > Apparently it has to do with the stable DT rules, which I don't know.
> > A concrete example would probably help clear it up.
> 
> The stable DT rules mean that an old DTS should keep on working with
> newer kernels.
> 
> Suppose we have two SoCs, that both contain "foo" modules, which look
> identical. Hence the DTS for both declares the devices to be compatible
> with "vendor,foo".
> 
> Later, we discover a difference between the two "foo" modules in the two
> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
> need to handle in the driver. But how can we distinguish between them?
> We can change the compatible value in the DTS, but that means the user
> has to update the DTS when updating the kernel. For a new feature that
> may be deemed acceptable, for a bug fix that's not acceptable.
> 
> Hence we always use an SoC-specific compatible value, which may or may
> not be accompanied by a family-specific and/or generic compatible value.
> As long as everything can be handled the same, the driver will just match
> against the most generic compatible value used. But if needed later, the
> driver can be updated to match against a more specific compatible value,
> and can have special handling for  a module in a specific SoC.
> 
> So that's why we want to have compatible value in the DT bindings that
> are not necessarily used by the driver.
> 
> In a perfect world, where all hardware is properly documented, or even
> Open Source, we wouldn't need this. There we could just declare a device
> compatible with what it really is, based on the module's internal version ID
> (ideally a git commit ID of its HDL source ;-).
> 
> I hope the above explains it. If you have more questions, feel free to ask!

The above is all pretty standard device identification technique.
That's not what I've been missing.

But I just had an epiphany.  Tell me if I'm talking sense or
gibberish:

  If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
  file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
  runs checkpatch on that patch, checkpatch will complain unless
  "renesas,pcie-r8a7793" appears somewhere in
  devicetree/bindings/pci/.

So if I understand correctly, the only point of this patch is to shut
up checkpatch in that situation.  It doesn't seem terribly useful to
me because checkpatch is only relevant to Linux kernel patches, and
even there it's optional and advisory.

The latest changelog says "By documenting this compat string it may be
used in DTSs shipped, for example as part of ROMs", which seems to be
saying a DTS may not be shipped unless checkpatch approves of it.
That's a social and procedural question, not a coding question.

It's fine with me if you want to try to enforce that via checkpatch,
but I'd just like to be clear on the mechanism.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

Hi Geert,

On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> >> > >
> >> > > Key Changes in v2:
> >> > > * Include "rcar-" in generic bindings
> >> > >
> >> > > Simon Horman (4):
> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> >> >
> >> > I applied these:
> >> >
> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >> > >   PCI: rcar: add gen2 fallback compatibility string
> >> >
> >> > to pci/host-rcar for v4.5, thanks!
> >> >
> >> > I haven't applied the R8A7793 binding documentation updates yet, but
> >> > I'll be happy to do so given a short description of why they're
> >> > useful (since they don't update a DT or the driver).  Or they could be
> >> > merged via a DT tree.
> >>
> >> To clarify: you would like a description in the changelog?
> >
> > Yes, please.  The email discussion so far hasn't contained what I'm
> > looking for (if it had, I would have just inserted it and been done
> > with it).
> >
> > Apparently it has to do with the stable DT rules, which I don't know.
> > A concrete example would probably help clear it up.
> 
> The stable DT rules mean that an old DTS should keep on working with
> newer kernels.
> 
> Suppose we have two SoCs, that both contain "foo" modules, which look
> identical. Hence the DTS for both declares the devices to be compatible
> with "vendor,foo".
> 
> Later, we discover a difference between the two "foo" modules in the two
> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
> need to handle in the driver. But how can we distinguish between them?
> We can change the compatible value in the DTS, but that means the user
> has to update the DTS when updating the kernel. For a new feature that
> may be deemed acceptable, for a bug fix that's not acceptable.
> 
> Hence we always use an SoC-specific compatible value, which may or may
> not be accompanied by a family-specific and/or generic compatible value.
> As long as everything can be handled the same, the driver will just match
> against the most generic compatible value used. But if needed later, the
> driver can be updated to match against a more specific compatible value,
> and can have special handling for  a module in a specific SoC.
> 
> So that's why we want to have compatible value in the DT bindings that
> are not necessarily used by the driver.
> 
> In a perfect world, where all hardware is properly documented, or even
> Open Source, we wouldn't need this. There we could just declare a device
> compatible with what it really is, based on the module's internal version ID
> (ideally a git commit ID of its HDL source ;-).
> 
> I hope the above explains it. If you have more questions, feel free to ask!

The above is all pretty standard device identification technique.
That's not what I've been missing.

But I just had an epiphany.  Tell me if I'm talking sense or
gibberish:

  If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
  file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
  runs checkpatch on that patch, checkpatch will complain unless
  "renesas,pcie-r8a7793" appears somewhere in
  devicetree/bindings/pci/.

So if I understand correctly, the only point of this patch is to shut
up checkpatch in that situation.  It doesn't seem terribly useful to
me because checkpatch is only relevant to Linux kernel patches, and
even there it's optional and advisory.

The latest changelog says "By documenting this compat string it may be
used in DTSs shipped, for example as part of ROMs", which seems to be
saying a DTS may not be shipped unless checkpatch approves of it.
That's a social and procedural question, not a coding question.

It's fine with me if you want to try to enforce that via checkpatch,
but I'd just like to be clear on the mechanism.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> >> > >
>> >> > > Key Changes in v2:
>> >> > > * Include "rcar-" in generic bindings
>> >> > >
>> >> > > Simon Horman (4):
>> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >> >
>> >> > I applied these:
>> >> >
>> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> >> > >   PCI: rcar: add gen2 fallback compatibility string
>> >> >
>> >> > to pci/host-rcar for v4.5, thanks!
>> >> >
>> >> > I haven't applied the R8A7793 binding documentation updates yet, but
>> >> > I'll be happy to do so given a short description of why they're
>> >> > useful (since they don't update a DT or the driver).  Or they could be
>> >> > merged via a DT tree.
>> >>
>> >> To clarify: you would like a description in the changelog?
>> >
>> > Yes, please.  The email discussion so far hasn't contained what I'm
>> > looking for (if it had, I would have just inserted it and been done
>> > with it).
>> >
>> > Apparently it has to do with the stable DT rules, which I don't know.
>> > A concrete example would probably help clear it up.
>>
>> The stable DT rules mean that an old DTS should keep on working with
>> newer kernels.
>>
>> Suppose we have two SoCs, that both contain "foo" modules, which look
>> identical. Hence the DTS for both declares the devices to be compatible
>> with "vendor,foo".
>>
>> Later, we discover a difference between the two "foo" modules in the two
>> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
>> need to handle in the driver. But how can we distinguish between them?
>> We can change the compatible value in the DTS, but that means the user
>> has to update the DTS when updating the kernel. For a new feature that
>> may be deemed acceptable, for a bug fix that's not acceptable.
>>
>> Hence we always use an SoC-specific compatible value, which may or may
>> not be accompanied by a family-specific and/or generic compatible value.
>> As long as everything can be handled the same, the driver will just match
>> against the most generic compatible value used. But if needed later, the
>> driver can be updated to match against a more specific compatible value,
>> and can have special handling for  a module in a specific SoC.
>>
>> So that's why we want to have compatible value in the DT bindings that
>> are not necessarily used by the driver.
>>
>> In a perfect world, where all hardware is properly documented, or even
>> Open Source, we wouldn't need this. There we could just declare a device
>> compatible with what it really is, based on the module's internal version ID
>> (ideally a git commit ID of its HDL source ;-).
>>
>> I hope the above explains it. If you have more questions, feel free to ask!
>
> The above is all pretty standard device identification technique.
> That's not what I've been missing.
>
> But I just had an epiphany.  Tell me if I'm talking sense or
> gibberish:
>
>   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
>   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
>   runs checkpatch on that patch, checkpatch will complain unless
>   "renesas,pcie-r8a7793" appears somewhere in
>   devicetree/bindings/pci/.
>
> So if I understand correctly, the only point of this patch is to shut
> up checkpatch in that situation.  It doesn't seem terribly useful to
> me because checkpatch is only relevant to Linux kernel patches, and
> even there it's optional and advisory.
>
> The latest changelog says "By documenting this compat string it may be
> used in DTSs shipped, for example as part of ROMs", which seems to be
> saying a DTS may not be shipped unless checkpatch approves of it.
> That's a social and procedural question, not a coding question.
>
> It's fine with me if you want to try to enforce that via checkpatch,
> but I'd just like to be clear on the mechanism.

A DT binding (e.g. a compatible value) may only be used in a DTS after it's
been documented and approved in a DT binding document.

Checkpath is just a tool. AFAIK there's no other tool enforcing the above.

As both DTSes and DT binding documents are (still) in the kernel, and changes
to them go in the kernel through patches, and most people run checkpatch
on patches, I think having the check in checkpatch makes perfect sense.
Adding and using yet another tool would complicate matters.

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 v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> >> > >
>> >> > > Key Changes in v2:
>> >> > > * Include "rcar-" in generic bindings
>> >> > >
>> >> > > Simon Horman (4):
>> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >> >
>> >> > I applied these:
>> >> >
>> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> >> > >   PCI: rcar: add gen2 fallback compatibility string
>> >> >
>> >> > to pci/host-rcar for v4.5, thanks!
>> >> >
>> >> > I haven't applied the R8A7793 binding documentation updates yet, but
>> >> > I'll be happy to do so given a short description of why they're
>> >> > useful (since they don't update a DT or the driver).  Or they could be
>> >> > merged via a DT tree.
>> >>
>> >> To clarify: you would like a description in the changelog?
>> >
>> > Yes, please.  The email discussion so far hasn't contained what I'm
>> > looking for (if it had, I would have just inserted it and been done
>> > with it).
>> >
>> > Apparently it has to do with the stable DT rules, which I don't know.
>> > A concrete example would probably help clear it up.
>>
>> The stable DT rules mean that an old DTS should keep on working with
>> newer kernels.
>>
>> Suppose we have two SoCs, that both contain "foo" modules, which look
>> identical. Hence the DTS for both declares the devices to be compatible
>> with "vendor,foo".
>>
>> Later, we discover a difference between the two "foo" modules in the two
>> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
>> need to handle in the driver. But how can we distinguish between them?
>> We can change the compatible value in the DTS, but that means the user
>> has to update the DTS when updating the kernel. For a new feature that
>> may be deemed acceptable, for a bug fix that's not acceptable.
>>
>> Hence we always use an SoC-specific compatible value, which may or may
>> not be accompanied by a family-specific and/or generic compatible value.
>> As long as everything can be handled the same, the driver will just match
>> against the most generic compatible value used. But if needed later, the
>> driver can be updated to match against a more specific compatible value,
>> and can have special handling for  a module in a specific SoC.
>>
>> So that's why we want to have compatible value in the DT bindings that
>> are not necessarily used by the driver.
>>
>> In a perfect world, where all hardware is properly documented, or even
>> Open Source, we wouldn't need this. There we could just declare a device
>> compatible with what it really is, based on the module's internal version ID
>> (ideally a git commit ID of its HDL source ;-).
>>
>> I hope the above explains it. If you have more questions, feel free to ask!
>
> The above is all pretty standard device identification technique.
> That's not what I've been missing.
>
> But I just had an epiphany.  Tell me if I'm talking sense or
> gibberish:
>
>   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
>   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
>   runs checkpatch on that patch, checkpatch will complain unless
>   "renesas,pcie-r8a7793" appears somewhere in
>   devicetree/bindings/pci/.
>
> So if I understand correctly, the only point of this patch is to shut
> up checkpatch in that situation.  It doesn't seem terribly useful to
> me because checkpatch is only relevant to Linux kernel patches, and
> even there it's optional and advisory.
>
> The latest changelog says "By documenting this compat string it may be
> used in DTSs shipped, for example as part of ROMs", which seems to be
> saying a DTS may not be shipped unless checkpatch approves of it.
> That's a social and procedural question, not a coding question.
>
> It's fine with me if you want to try to enforce that via checkpatch,
> but I'd just like to be clear on the mechanism.

A DT binding (e.g. a compatible value) may only be used in a DTS after it's
been documented and approved in a DT binding document.

Checkpath is just a tool. AFAIK there's no other tool enforcing the above.

As both DTSes and DT binding documents are (still) in the kernel, and changes
to them go in the kernel through patches, and most people run checkpatch
on patches, I think having the check in checkpatch makes perfect sense.
Adding and using yet another tool would complicate matters.

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 v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Fri, Feb 05, 2016 at 08:43:55AM +0100, Geert Uytterhoeven wrote:
> On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> >> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> >> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> >> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> >> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> >> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> >> >> > >
> >> >> > > Key Changes in v2:
> >> >> > > * Include "rcar-" in generic bindings
> >> >> > >
> >> >> > > Simon Horman (4):
> >> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> >> >> >
> >> >> > I applied these:
> >> >> >
> >> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >> >> > >   PCI: rcar: add gen2 fallback compatibility string
> >> >> >
> >> >> > to pci/host-rcar for v4.5, thanks!
> >> >> >
> >> >> > I haven't applied the R8A7793 binding documentation updates yet, but
> >> >> > I'll be happy to do so given a short description of why they're
> >> >> > useful (since they don't update a DT or the driver).  Or they could be
> >> >> > merged via a DT tree.
> >> >>
> >> >> To clarify: you would like a description in the changelog?
> >> >
> >> > Yes, please.  The email discussion so far hasn't contained what I'm
> >> > looking for (if it had, I would have just inserted it and been done
> >> > with it).
> >> >
> >> > Apparently it has to do with the stable DT rules, which I don't know.
> >> > A concrete example would probably help clear it up.
> >>
> >> The stable DT rules mean that an old DTS should keep on working with
> >> newer kernels.
> >>
> >> Suppose we have two SoCs, that both contain "foo" modules, which look
> >> identical. Hence the DTS for both declares the devices to be compatible
> >> with "vendor,foo".
> >>
> >> Later, we discover a difference between the two "foo" modules in the two
> >> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
> >> need to handle in the driver. But how can we distinguish between them?
> >> We can change the compatible value in the DTS, but that means the user
> >> has to update the DTS when updating the kernel. For a new feature that
> >> may be deemed acceptable, for a bug fix that's not acceptable.
> >>
> >> Hence we always use an SoC-specific compatible value, which may or may
> >> not be accompanied by a family-specific and/or generic compatible value.
> >> As long as everything can be handled the same, the driver will just match
> >> against the most generic compatible value used. But if needed later, the
> >> driver can be updated to match against a more specific compatible value,
> >> and can have special handling for  a module in a specific SoC.
> >>
> >> So that's why we want to have compatible value in the DT bindings that
> >> are not necessarily used by the driver.
> >>
> >> In a perfect world, where all hardware is properly documented, or even
> >> Open Source, we wouldn't need this. There we could just declare a device
> >> compatible with what it really is, based on the module's internal version ID
> >> (ideally a git commit ID of its HDL source ;-).
> >>
> >> I hope the above explains it. If you have more questions, feel free to ask!
> >
> > The above is all pretty standard device identification technique.
> > That's not what I've been missing.
> >
> > But I just had an epiphany.  Tell me if I'm talking sense or
> > gibberish:
> >
> >   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
> >   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
> >   runs checkpatch on that patch, checkpatch will complain unless
> >   "renesas,pcie-r8a7793" appears somewhere in
> >   devicetree/bindings/pci/.
> >
> > So if I understand correctly, the only point of this patch is to shut
> > up checkpatch in that situation.  It doesn't seem terribly useful to
> > me because checkpatch is only relevant to Linux kernel patches, and
> > even there it's optional and advisory.
> >
> > The latest changelog says "By documenting this compat string it may be
> > used in DTSs shipped, for example as part of ROMs", which seems to be
> > saying a DTS may not be shipped unless checkpatch approves of it.
> > That's a social and procedural question, not a coding question.
> >
> > It's fine with me if you want to try to enforce that via checkpatch,
> > but I'd just like to be clear on the mechanism.
> 
> A DT binding (e.g. a compatible value) may only be used in a DTS after it's
> been documented and approved in a DT binding document.
> 
> Checkpath is just a tool. AFAIK there's no other tool enforcing the above.
> 
> As both DTSes and DT binding documents are (still) in the kernel, and changes
> to them go in the kernel through patches, and most people run checkpatch
> on patches, I think having the check in checkpatch makes perfect sense.
> Adding and using yet another tool would complicate matters.

Like I said, it's fine with me if your DTS process relies on
checkpatch, and I'm not suggesting any other tool.

I'm just trying to get clarity on the nitty-gritty technical benefits
of this patch, and I think it is "this patch enables people to add a
DTS containing 'renesas,pcie-r8a7793' to the kernel source without
having checkpatch complain."

If the convention is that OEMs can't ship a DT unless it's in the
kernel source and has passed checkpatch, that's fine, but it can't be
enforced by a kernel patch.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Bjorn Helgaas]

On Fri, Feb 05, 2016 at 08:43:55AM +0100, Geert Uytterhoeven wrote:
> On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
> >> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
> >> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
> >> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
> >> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
> >> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
> >> >> > >
> >> >> > > Key Changes in v2:
> >> >> > > * Include "rcar-" in generic bindings
> >> >> > >
> >> >> > > Simon Horman (4):
> >> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
> >> >> >
> >> >> > I applied these:
> >> >> >
> >> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
> >> >> > >   PCI: rcar: add gen2 fallback compatibility string
> >> >> >
> >> >> > to pci/host-rcar for v4.5, thanks!
> >> >> >
> >> >> > I haven't applied the R8A7793 binding documentation updates yet, but
> >> >> > I'll be happy to do so given a short description of why they're
> >> >> > useful (since they don't update a DT or the driver).  Or they could be
> >> >> > merged via a DT tree.
> >> >>
> >> >> To clarify: you would like a description in the changelog?
> >> >
> >> > Yes, please.  The email discussion so far hasn't contained what I'm
> >> > looking for (if it had, I would have just inserted it and been done
> >> > with it).
> >> >
> >> > Apparently it has to do with the stable DT rules, which I don't know.
> >> > A concrete example would probably help clear it up.
> >>
> >> The stable DT rules mean that an old DTS should keep on working with
> >> newer kernels.
> >>
> >> Suppose we have two SoCs, that both contain "foo" modules, which look
> >> identical. Hence the DTS for both declares the devices to be compatible
> >> with "vendor,foo".
> >>
> >> Later, we discover a difference between the two "foo" modules in the two
> >> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
> >> need to handle in the driver. But how can we distinguish between them?
> >> We can change the compatible value in the DTS, but that means the user
> >> has to update the DTS when updating the kernel. For a new feature that
> >> may be deemed acceptable, for a bug fix that's not acceptable.
> >>
> >> Hence we always use an SoC-specific compatible value, which may or may
> >> not be accompanied by a family-specific and/or generic compatible value.
> >> As long as everything can be handled the same, the driver will just match
> >> against the most generic compatible value used. But if needed later, the
> >> driver can be updated to match against a more specific compatible value,
> >> and can have special handling for  a module in a specific SoC.
> >>
> >> So that's why we want to have compatible value in the DT bindings that
> >> are not necessarily used by the driver.
> >>
> >> In a perfect world, where all hardware is properly documented, or even
> >> Open Source, we wouldn't need this. There we could just declare a device
> >> compatible with what it really is, based on the module's internal version ID
> >> (ideally a git commit ID of its HDL source ;-).
> >>
> >> I hope the above explains it. If you have more questions, feel free to ask!
> >
> > The above is all pretty standard device identification technique.
> > That's not what I've been missing.
> >
> > But I just had an epiphany.  Tell me if I'm talking sense or
> > gibberish:
> >
> >   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
> >   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
> >   runs checkpatch on that patch, checkpatch will complain unless
> >   "renesas,pcie-r8a7793" appears somewhere in
> >   devicetree/bindings/pci/.
> >
> > So if I understand correctly, the only point of this patch is to shut
> > up checkpatch in that situation.  It doesn't seem terribly useful to
> > me because checkpatch is only relevant to Linux kernel patches, and
> > even there it's optional and advisory.
> >
> > The latest changelog says "By documenting this compat string it may be
> > used in DTSs shipped, for example as part of ROMs", which seems to be
> > saying a DTS may not be shipped unless checkpatch approves of it.
> > That's a social and procedural question, not a coding question.
> >
> > It's fine with me if you want to try to enforce that via checkpatch,
> > but I'd just like to be clear on the mechanism.
> 
> A DT binding (e.g. a compatible value) may only be used in a DTS after it's
> been documented and approved in a DT binding document.
> 
> Checkpath is just a tool. AFAIK there's no other tool enforcing the above.
> 
> As both DTSes and DT binding documents are (still) in the kernel, and changes
> to them go in the kernel through patches, and most people run checkpatch
> on patches, I think having the check in checkpatch makes perfect sense.
> Adding and using yet another tool would complicate matters.

Like I said, it's fine with me if your DTS process relies on
checkpatch, and I'm not suggesting any other tool.

I'm just trying to get clarity on the nitty-gritty technical benefits
of this patch, and I think it is "this patch enables people to add a
DTS containing 'renesas,pcie-r8a7793' to the kernel source without
having checkpatch complain."

If the convention is that OEMs can't ship a DT unless it's in the
kernel source and has passed checkpatch, that's fine, but it can't be
enforced by a kernel patch.

Bjorn

Re: [PATCH v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Feb 5, 2016 at 5:10 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Feb 05, 2016 at 08:43:55AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
>> >> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> >> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> >> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> >> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> >> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> >> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> >> >> > >
>> >> >> > > Key Changes in v2:
>> >> >> > > * Include "rcar-" in generic bindings
>> >> >> > >
>> >> >> > > Simon Horman (4):
>> >> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >> >> >
>> >> >> > I applied these:
>> >> >> >
>> >> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> >> >> > >   PCI: rcar: add gen2 fallback compatibility string
>> >> >> >
>> >> >> > to pci/host-rcar for v4.5, thanks!
>> >> >> >
>> >> >> > I haven't applied the R8A7793 binding documentation updates yet, but
>> >> >> > I'll be happy to do so given a short description of why they're
>> >> >> > useful (since they don't update a DT or the driver).  Or they could be
>> >> >> > merged via a DT tree.
>> >> >>
>> >> >> To clarify: you would like a description in the changelog?
>> >> >
>> >> > Yes, please.  The email discussion so far hasn't contained what I'm
>> >> > looking for (if it had, I would have just inserted it and been done
>> >> > with it).
>> >> >
>> >> > Apparently it has to do with the stable DT rules, which I don't know.
>> >> > A concrete example would probably help clear it up.
>> >>
>> >> The stable DT rules mean that an old DTS should keep on working with
>> >> newer kernels.
>> >>
>> >> Suppose we have two SoCs, that both contain "foo" modules, which look
>> >> identical. Hence the DTS for both declares the devices to be compatible
>> >> with "vendor,foo".
>> >>
>> >> Later, we discover a difference between the two "foo" modules in the two
>> >> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
>> >> need to handle in the driver. But how can we distinguish between them?
>> >> We can change the compatible value in the DTS, but that means the user
>> >> has to update the DTS when updating the kernel. For a new feature that
>> >> may be deemed acceptable, for a bug fix that's not acceptable.
>> >>
>> >> Hence we always use an SoC-specific compatible value, which may or may
>> >> not be accompanied by a family-specific and/or generic compatible value.
>> >> As long as everything can be handled the same, the driver will just match
>> >> against the most generic compatible value used. But if needed later, the
>> >> driver can be updated to match against a more specific compatible value,
>> >> and can have special handling for  a module in a specific SoC.
>> >>
>> >> So that's why we want to have compatible value in the DT bindings that
>> >> are not necessarily used by the driver.
>> >>
>> >> In a perfect world, where all hardware is properly documented, or even
>> >> Open Source, we wouldn't need this. There we could just declare a device
>> >> compatible with what it really is, based on the module's internal version ID
>> >> (ideally a git commit ID of its HDL source ;-).
>> >>
>> >> I hope the above explains it. If you have more questions, feel free to ask!
>> >
>> > The above is all pretty standard device identification technique.
>> > That's not what I've been missing.
>> >
>> > But I just had an epiphany.  Tell me if I'm talking sense or
>> > gibberish:
>> >
>> >   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
>> >   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
>> >   runs checkpatch on that patch, checkpatch will complain unless
>> >   "renesas,pcie-r8a7793" appears somewhere in
>> >   devicetree/bindings/pci/.
>> >
>> > So if I understand correctly, the only point of this patch is to shut
>> > up checkpatch in that situation.  It doesn't seem terribly useful to
>> > me because checkpatch is only relevant to Linux kernel patches, and
>> > even there it's optional and advisory.
>> >
>> > The latest changelog says "By documenting this compat string it may be
>> > used in DTSs shipped, for example as part of ROMs", which seems to be
>> > saying a DTS may not be shipped unless checkpatch approves of it.
>> > That's a social and procedural question, not a coding question.
>> >
>> > It's fine with me if you want to try to enforce that via checkpatch,
>> > but I'd just like to be clear on the mechanism.
>>
>> A DT binding (e.g. a compatible value) may only be used in a DTS after it's
>> been documented and approved in a DT binding document.
>>
>> Checkpath is just a tool. AFAIK there's no other tool enforcing the above.
>>
>> As both DTSes and DT binding documents are (still) in the kernel, and changes
>> to them go in the kernel through patches, and most people run checkpatch
>> on patches, I think having the check in checkpatch makes perfect sense.
>> Adding and using yet another tool would complicate matters.
>
> Like I said, it's fine with me if your DTS process relies on
> checkpatch, and I'm not suggesting any other tool.
>
> I'm just trying to get clarity on the nitty-gritty technical benefits
> of this patch, and I think it is "this patch enables people to add a
> DTS containing 'renesas,pcie-r8a7793' to the kernel source without
> having checkpatch complain."

Indeed. And once ''renesas,pcie-r8a7793' is in the DTS, we can handle quirks of
the PCIe implementation in r8a7793, if ever needed in the future, without
requiring a DTS update.

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 v2 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Geert Uytterhoeven]

Hi Bjorn,

On Fri, Feb 5, 2016 at 5:10 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Feb 05, 2016 at 08:43:55AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Feb 4, 2016 at 11:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Fri, Dec 11, 2015 at 04:58:06PM +0100, Geert Uytterhoeven wrote:
>> >> On Fri, Dec 11, 2015 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> > On Fri, Dec 11, 2015 at 11:14:34AM +0900, Simon Horman wrote:
>> >> >> On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote:
>> >> >> > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote:
>> >> >> > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility
>> >> >> > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
>> >> >> > > provide a complete set of compatibility strings for known Gen2 SoCs.
>> >> >> > >
>> >> >> > > Key Changes in v2:
>> >> >> > > * Include "rcar-" in generic bindings
>> >> >> > >
>> >> >> > > Simon Horman (4):
>> >> >> > >   PCI: rcar-gen2: add gen2 fallback 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(-)
>> >> >> >
>> >> >> > I applied these:
>> >> >> >
>> >> >> > >   PCI: rcar-gen2: add gen2 fallback compatibility string
>> >> >> > >   PCI: rcar: add gen2 fallback compatibility string
>> >> >> >
>> >> >> > to pci/host-rcar for v4.5, thanks!
>> >> >> >
>> >> >> > I haven't applied the R8A7793 binding documentation updates yet, but
>> >> >> > I'll be happy to do so given a short description of why they're
>> >> >> > useful (since they don't update a DT or the driver).  Or they could be
>> >> >> > merged via a DT tree.
>> >> >>
>> >> >> To clarify: you would like a description in the changelog?
>> >> >
>> >> > Yes, please.  The email discussion so far hasn't contained what I'm
>> >> > looking for (if it had, I would have just inserted it and been done
>> >> > with it).
>> >> >
>> >> > Apparently it has to do with the stable DT rules, which I don't know.
>> >> > A concrete example would probably help clear it up.
>> >>
>> >> The stable DT rules mean that an old DTS should keep on working with
>> >> newer kernels.
>> >>
>> >> Suppose we have two SoCs, that both contain "foo" modules, which look
>> >> identical. Hence the DTS for both declares the devices to be compatible
>> >> with "vendor,foo".
>> >>
>> >> Later, we discover a difference between the two "foo" modules in the two
>> >> SoCs (e.g. a feature present in one of them, or worse, a bug), which we
>> >> need to handle in the driver. But how can we distinguish between them?
>> >> We can change the compatible value in the DTS, but that means the user
>> >> has to update the DTS when updating the kernel. For a new feature that
>> >> may be deemed acceptable, for a bug fix that's not acceptable.
>> >>
>> >> Hence we always use an SoC-specific compatible value, which may or may
>> >> not be accompanied by a family-specific and/or generic compatible value.
>> >> As long as everything can be handled the same, the driver will just match
>> >> against the most generic compatible value used. But if needed later, the
>> >> driver can be updated to match against a more specific compatible value,
>> >> and can have special handling for  a module in a specific SoC.
>> >>
>> >> So that's why we want to have compatible value in the DT bindings that
>> >> are not necessarily used by the driver.
>> >>
>> >> In a perfect world, where all hardware is properly documented, or even
>> >> Open Source, we wouldn't need this. There we could just declare a device
>> >> compatible with what it really is, based on the module's internal version ID
>> >> (ideally a git commit ID of its HDL source ;-).
>> >>
>> >> I hope the above explains it. If you have more questions, feel free to ask!
>> >
>> > The above is all pretty standard device identification technique.
>> > That's not what I've been missing.
>> >
>> > But I just had an epiphany.  Tell me if I'm talking sense or
>> > gibberish:
>> >
>> >   If a patch adds a use of "renesas,pcie-r8a7793" in a .dts, .c, or .h
>> >   file, e.g., in arch/arm/boot/dts/ or in the driver, and somebody
>> >   runs checkpatch on that patch, checkpatch will complain unless
>> >   "renesas,pcie-r8a7793" appears somewhere in
>> >   devicetree/bindings/pci/.
>> >
>> > So if I understand correctly, the only point of this patch is to shut
>> > up checkpatch in that situation.  It doesn't seem terribly useful to
>> > me because checkpatch is only relevant to Linux kernel patches, and
>> > even there it's optional and advisory.
>> >
>> > The latest changelog says "By documenting this compat string it may be
>> > used in DTSs shipped, for example as part of ROMs", which seems to be
>> > saying a DTS may not be shipped unless checkpatch approves of it.
>> > That's a social and procedural question, not a coding question.
>> >
>> > It's fine with me if you want to try to enforce that via checkpatch,
>> > but I'd just like to be clear on the mechanism.
>>
>> A DT binding (e.g. a compatible value) may only be used in a DTS after it's
>> been documented and approved in a DT binding document.
>>
>> Checkpath is just a tool. AFAIK there's no other tool enforcing the above.
>>
>> As both DTSes and DT binding documents are (still) in the kernel, and changes
>> to them go in the kernel through patches, and most people run checkpatch
>> on patches, I think having the check in checkpatch makes perfect sense.
>> Adding and using yet another tool would complicate matters.
>
> Like I said, it's fine with me if your DTS process relies on
> checkpatch, and I'm not suggesting any other tool.
>
> I'm just trying to get clarity on the nitty-gritty technical benefits
> of this patch, and I think it is "this patch enables people to add a
> DTS containing 'renesas,pcie-r8a7793' to the kernel source without
> having checkpatch complain."

Indeed. And once ''renesas,pcie-r8a7793' is in the DTS, we can handle quirks of
the PCIe implementation in r8a7793, if ever needed in the future, without
requiring a DTS update.

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