linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] irqchip/renesas-intc-irqpin: fallback enhancements
@ 2016-12-09 10:50 Simon Horman
  2016-12-09 10:50 ` [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last Simon Horman
  2016-12-09 10:50 ` [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding Simon Horman
  0 siblings, 2 replies; 7+ messages in thread
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
  To: Thomas Gleixner, Jason Cooper, Marc Zyngier
  Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
	devicetree, Simon Horman

Hi,

this short series aims to improve the fallback compatibility strings
for the renesas-intc-irqpin driver.

Based on v4.9-rc1.

Simon Horman (2):
  irqchip/renesas-intc-irqpin: List fallback compatibility last
  irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding

 .../interrupt-controller/renesas,intc-irqpin.txt   | 44 ++++++++++++----------
 drivers/irqchip/irq-renesas-intc-irqpin.c          |  4 +-
 2 files changed, 27 insertions(+), 21 deletions(-)

-- 
2.7.0.rc3.207.g0ac5344

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
  2016-12-09 10:50 [PATCH 0/2] irqchip/renesas-intc-irqpin: fallback enhancements Simon Horman
@ 2016-12-09 10:50 ` Simon Horman
  2016-12-09 12:45   ` Geert Uytterhoeven
  2016-12-09 10:50 ` [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding Simon Horman
  1 sibling, 1 reply; 7+ messages in thread
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
  To: Thomas Gleixner, Jason Cooper, Marc Zyngier
  Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
	devicetree, Simon Horman

Improve readability by listing the rmobile fallback compatibility string
after the more-specific compatibility strings they provide a fallback for.

This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 713177d97c7a..5fe1207a079c 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -374,7 +374,6 @@ static const struct intc_irqpin_config intc_irqpin_rmobile = {
 };
 
 static const struct of_device_id intc_irqpin_dt_ids[] = {
-	{ .compatible = "renesas,intc-irqpin", },
 	{ .compatible = "renesas,intc-irqpin-r8a7778",
 	  .data = &intc_irqpin_irlm_r8a777x },
 	{ .compatible = "renesas,intc-irqpin-r8a7779",
@@ -383,6 +382,7 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
 	  .data = &intc_irqpin_rmobile },
 	{ .compatible = "renesas,intc-irqpin-sh73a0",
 	  .data = &intc_irqpin_rmobile },
+	{ .compatible = "renesas,intc-irqpin", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);
-- 
2.7.0.rc3.207.g0ac5344

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
  2016-12-09 10:50 [PATCH 0/2] irqchip/renesas-intc-irqpin: fallback enhancements Simon Horman
  2016-12-09 10:50 ` [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last Simon Horman
@ 2016-12-09 10:50 ` Simon Horman
  2016-12-09 12:52   ` Geert Uytterhoeven
  1 sibling, 1 reply; 7+ messages in thread
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
  To: Thomas Gleixner, Jason Cooper, Marc Zyngier
  Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
	devicetree, Simon Horman

In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
descendant of the former or vice versa.

We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.

For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 .../interrupt-controller/renesas,intc-irqpin.txt   | 44 ++++++++++++----------
 drivers/irqchip/irq-renesas-intc-irqpin.c          |  2 +
 2 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
index 772c550d3b4b..e5a5251be9f5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
 
 Required properties:
 
-- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
-  as fallback.
-  Examples with soctypes are:
+- compatible:
     - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
     - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
     - "renesas,intc-irqpin-r8a7779" (R-Car H1)
     - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
+    - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
+    - "renesas,intc-irqpin"         (generic device)
+
+    When compatible with a generic R-Car version, nodes must list the
+    SoC-specific version corresponding to the platform first followed by
+    the generic R-Car version.
+
+    "renesas,intc-irqpin" must be present and last.
 
 - reg: Base address and length of each register bank used by the external
   IRQ pins driven by the interrupt controller hardware module. The base
@@ -39,24 +45,22 @@ Optional properties:
 Example
 -------
 
-	irqpin1: interrupt-controller@e6900004 {
-		compatible = "renesas,intc-irqpin-r8a7740",
+	irqpin0: interrupt-controller@fe78001c {
+		compatible = "renesas,intc-irqpin-r8a7779",
+			     "renesas,rcar-gen1-intc-irqpin",
 			     "renesas,intc-irqpin";
 		#interrupt-cells = <2>;
+		status = "disabled";
 		interrupt-controller;
-		reg = <0xe6900004 4>,
-			<0xe6900014 4>,
-			<0xe6900024 1>,
-			<0xe6900044 1>,
-			<0xe6900064 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
-		power-domains = <&pd_a4s>;
+		reg = <0xfe78001c 4>,
+			<0xfe780010 4>,
+			<0xfe780024 4>,
+			<0xfe780044 4>,
+			<0xfe780064 4>,
+			<0xfe780000 4>;
+		interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+		sense-bitfield-width = <2>;
 	};
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5fe1207a079c..70095b61a90a 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -378,6 +378,8 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
 	  .data = &intc_irqpin_irlm_r8a777x },
 	{ .compatible = "renesas,intc-irqpin-r8a7779",
 	  .data = &intc_irqpin_irlm_r8a777x },
+	{ .compatible = "renesas,rcar-gen1-intc-irqpin",
+	  .data = &intc_irqpin_irlm_r8a777x },
 	{ .compatible = "renesas,intc-irqpin-r8a7740",
 	  .data = &intc_irqpin_rmobile },
 	{ .compatible = "renesas,intc-irqpin-sh73a0",
-- 
2.7.0.rc3.207.g0ac5344

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
  2016-12-09 10:50 ` [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last Simon Horman
@ 2016-12-09 12:45   ` Geert Uytterhoeven
  0 siblings, 0 replies; 7+ messages in thread
From: Geert Uytterhoeven @ 2016-12-09 12:45 UTC (permalink / raw)
  To: Simon Horman
  Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
	Magnus Damm, linux-kernel, Linux-Renesas, devicetree

Hi Simon,

On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Improve readability by listing the rmobile fallback compatibility string

s/rmobile/generic/

> after the more-specific compatibility strings they provide a fallback for.
>
> This does not effect run-time behaviour as it is the order in the DTB that
> determines which compatibility string is used.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
> index 713177d97c7a..5fe1207a079c 100644
> --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> @@ -374,7 +374,6 @@ static const struct intc_irqpin_config intc_irqpin_rmobile = {
>  };
>
>  static const struct of_device_id intc_irqpin_dt_ids[] = {
> -       { .compatible = "renesas,intc-irqpin", },
>         { .compatible = "renesas,intc-irqpin-r8a7778",
>           .data = &intc_irqpin_irlm_r8a777x },
>         { .compatible = "renesas,intc-irqpin-r8a7779",
> @@ -383,6 +382,7 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
>           .data = &intc_irqpin_rmobile },
>         { .compatible = "renesas,intc-irqpin-sh73a0",
>           .data = &intc_irqpin_rmobile },
> +       { .compatible = "renesas,intc-irqpin", },

BTW, I'm wondering what's the added value of keeping the generic
"renesas,intc-irqpin" fallback. There is no user of the pure generic version
only, and all SoC-specific versions are treated slightly different.

>         {},
>  };
>  MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
  2016-12-09 10:50 ` [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding Simon Horman
@ 2016-12-09 12:52   ` Geert Uytterhoeven
  2016-12-12 18:43     ` Rob Herring
  0 siblings, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2016-12-09 12:52 UTC (permalink / raw)
  To: Simon Horman
  Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
	Magnus Damm, linux-kernel, Linux-Renesas, devicetree

Hi Simon,

On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the

it's

> relationship between IP blocks might be. For example, I believe that
> r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  .../interrupt-controller/renesas,intc-irqpin.txt   | 44 ++++++++++++----------
>  drivers/irqchip/irq-renesas-intc-irqpin.c          |  2 +
>  2 files changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> index 772c550d3b4b..e5a5251be9f5 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
>
>  Required properties:
>
> -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
> -  as fallback.
> -  Examples with soctypes are:
> +- compatible:
>      - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
>      - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
>      - "renesas,intc-irqpin-r8a7779" (R-Car H1)
>      - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
> +    - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)

Does it make sense to add a new family-specific compatible value to a driver
that's unlikely to receive more users in the future? More recent SoCs use
renesas,irqc.

If the answer is yes, do we want one for SH/R-Mobile too?

> +    - "renesas,intc-irqpin"         (generic device)
> +
> +    When compatible with a generic R-Car version, nodes must list the
> +    SoC-specific version corresponding to the platform first followed by
> +    the generic R-Car version.
> +
> +    "renesas,intc-irqpin" must be present and last.
>
>  - reg: Base address and length of each register bank used by the external
>    IRQ pins driven by the interrupt controller hardware module. The base
> @@ -39,24 +45,22 @@ Optional properties:
>  Example
>  -------
>
> -       irqpin1: interrupt-controller@e6900004 {
> -               compatible = "renesas,intc-irqpin-r8a7740",
> +       irqpin0: interrupt-controller@fe78001c {
> +               compatible = "renesas,intc-irqpin-r8a7779",
> +                            "renesas,rcar-gen1-intc-irqpin",

And now we have three compatible values to list...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
  2016-12-09 12:52   ` Geert Uytterhoeven
@ 2016-12-12 18:43     ` Rob Herring
  2016-12-14  8:03       ` Simon Horman
  0 siblings, 1 reply; 7+ messages in thread
From: Rob Herring @ 2016-12-12 18:43 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Simon Horman, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Magnus Damm, linux-kernel, Linux-Renesas, devicetree

On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
> 
> it's
> 
> > relationship between IP blocks might be. For example, I believe that
> > r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
> > descendant of the former or vice versa.
> >
> > We can, however, by examining the documentation and behaviour of the
> > hardware at run-time observe that the current driver implementation appears
> > to be compatible with the IP blocks on SoCs within a given generation.
> >
> > For the above reasons and convenience when enabling new SoCs a
> > per-generation fallback compatibility string scheme being adopted for
> > drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  .../interrupt-controller/renesas,intc-irqpin.txt   | 44 ++++++++++++----------
> >  drivers/irqchip/irq-renesas-intc-irqpin.c          |  2 +
> >  2 files changed, 26 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > index 772c550d3b4b..e5a5251be9f5 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
> >
> >  Required properties:
> >
> > -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
> > -  as fallback.
> > -  Examples with soctypes are:
> > +- compatible:
> >      - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
> >      - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
> >      - "renesas,intc-irqpin-r8a7779" (R-Car H1)
> >      - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
> > +    - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
> 
> Does it make sense to add a new family-specific compatible value to a driver
> that's unlikely to receive more users in the future? More recent SoCs use
> renesas,irqc.

If that's the case, then no. Please don't go crazy with your generic 
strings. I don't mind them, but I don't know that I'd call it best 
practice.

Rob

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
  2016-12-12 18:43     ` Rob Herring
@ 2016-12-14  8:03       ` Simon Horman
  0 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2016-12-14  8:03 UTC (permalink / raw)
  To: Rob Herring
  Cc: Geert Uytterhoeven, Thomas Gleixner, Jason Cooper, Marc Zyngier,
	Magnus Damm, linux-kernel, Linux-Renesas, devicetree

On Mon, Dec 12, 2016 at 12:43:11PM -0600, Rob Herring wrote:
> On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote:
> > Hi Simon,
> > 
> > On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
> > <horms+renesas@verge.net.au> wrote:
> > > In the case of Renesas R-Car hardware we know that there are generations of
> > > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
> > 
> > it's
> > 
> > > relationship between IP blocks might be. For example, I believe that
> > > r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
> > > descendant of the former or vice versa.
> > >
> > > We can, however, by examining the documentation and behaviour of the
> > > hardware at run-time observe that the current driver implementation appears
> > > to be compatible with the IP blocks on SoCs within a given generation.
> > >
> > > For the above reasons and convenience when enabling new SoCs a
> > > per-generation fallback compatibility string scheme being adopted for
> > > drivers for Renesas SoCs.
> > >
> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > ---
> > >  .../interrupt-controller/renesas,intc-irqpin.txt   | 44 ++++++++++++----------
> > >  drivers/irqchip/irq-renesas-intc-irqpin.c          |  2 +
> > >  2 files changed, 26 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > > index 772c550d3b4b..e5a5251be9f5 100644
> > > --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > > +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > > @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
> > >
> > >  Required properties:
> > >
> > > -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
> > > -  as fallback.
> > > -  Examples with soctypes are:
> > > +- compatible:
> > >      - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
> > >      - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
> > >      - "renesas,intc-irqpin-r8a7779" (R-Car H1)
> > >      - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
> > > +    - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
> > 
> > Does it make sense to add a new family-specific compatible value to a driver
> > that's unlikely to receive more users in the future? More recent SoCs use
> > renesas,irqc.
> 
> If that's the case, then no. Please don't go crazy with your generic 
> strings. I don't mind them, but I don't know that I'd call it best 
> practice.

Understood. I do not see any new users of this driver on the horizon
and given the above I withdraw this patch.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-12-14  8:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-09 10:50 [PATCH 0/2] irqchip/renesas-intc-irqpin: fallback enhancements Simon Horman
2016-12-09 10:50 ` [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last Simon Horman
2016-12-09 12:45   ` Geert Uytterhoeven
2016-12-09 10:50 ` [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding Simon Horman
2016-12-09 12:52   ` Geert Uytterhoeven
2016-12-12 18:43     ` Rob Herring
2016-12-14  8:03       ` Simon Horman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).