[PATCH RESEND 0/2] Add generic GIC compat strings

[PATCH RESEND 0/2] Add generic GIC compat strings

[Nikolay Borisov]

Currently the GIC (in drivers/irqchip/irq-gic.c) is referred to with
implementation-specific strings (e.g. "arm.cortex-a9-gic"), which is a
little unwieldy due to the number of different CPUs we now have with GIC
support.

These 2 patches add the generic arm,gic-v[1,2] compat strings and also change
the respective documentation.

Nikolay Borisov (2):
  irqchip: Add generic gic-v1/gic-v2 compat strings.
  documentation/devicetree: Update GIC compat strings

 Documentation/devicetree/bindings/arm/gic.txt | 2 ++
 drivers/irqchip/irq-gic.c                     | 2 ++
 2 files changed, 4 insertions(+)

-- 
1.8.1.5

[PATCH RESEND 1/2] irqchip: Add generic gic-v1/gic-v2 compat strings.

[Nikolay Borisov]

The current set of GIC compatible strings only contains specific
implementations (e.g. arm,cortex-a9-gic) rather than revisions of the
standard (e.g. arm,gic-v2), so each new implementation must either claim
to be an extension of an existing implementation or have a new string
added to the driver. This may be problematic when workarounds are
required for bugs in particular implementations, as said workaround may
end up targeting a wider set of implementations than intended.

To prevent these issues, this patch adds compatible strings for the
revisions of the GIC spec which all GIC implementations should be able
to claim conformance to in addition to any particular implementation
specific string, e.g.

compatible = "$VENDOR,specific-gic-variant", "arm,gic-v2";

Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com>
Acked-by: Mark Rutland <Mark.Rutland@arm.com>
---
 drivers/irqchip/irq-gic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 57d165e..89e9b05 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1073,6 +1073,8 @@ gic_of_init(struct device_node *node, struct device_node *parent)
 }
 IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
 IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
+IRQCHIP_DECLARE(gic_v1, "arm,gic-v1", gic_of_init);
+IRQCHIP_DECLARE(gic_v2, "arm,gic-v2", gic_of_init);
 IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
 
-- 
1.8.1.5

[PATCH RESEND 1/2] irqchip: Add generic gic-v1/gic-v2 compat strings.

[Rob Herring]

On Wed, May 21, 2014 at 8:48 AM, Nikolay Borisov
<Nikolay.Borisov@arm.com> wrote:
> The current set of GIC compatible strings only contains specific
> implementations (e.g. arm,cortex-a9-gic) rather than revisions of the
> standard (e.g. arm,gic-v2), so each new implementation must either claim
> to be an extension of an existing implementation or have a new string
> added to the driver. This may be problematic when workarounds are
> required for bugs in particular implementations, as said workaround may
> end up targeting a wider set of implementations than intended.
>
> To prevent these issues, this patch adds compatible strings for the
> revisions of the GIC spec which all GIC implementations should be able
> to claim conformance to in addition to any particular implementation
> specific string, e.g.

This just encourages not having specific properties which then also
prevents being able to add work-arounds later. SOCs using the a9 or
a15 string ONLY that are not an a9 or a15 are wrong. That's what we
should fix. Adding more generic strings is not going to help that. Do
you have a specific work-around you need to implement?

Given that the GIC specs are obviously meaningless since we now have
GICv2 with 16 core support as well as the special exynos gics, I'm not
inclined to accept this.

Rob

> compatible = "$VENDOR,specific-gic-variant", "arm,gic-v2";
>
> Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com>
> Acked-by: Mark Rutland <Mark.Rutland@arm.com>
> ---
>  drivers/irqchip/irq-gic.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 57d165e..89e9b05 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -1073,6 +1073,8 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>  }
>  IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
>  IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
> +IRQCHIP_DECLARE(gic_v1, "arm,gic-v1", gic_of_init);
> +IRQCHIP_DECLARE(gic_v2, "arm,gic-v2", gic_of_init);
>  IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
>  IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>
> --
> 1.8.1.5
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 1/2] irqchip: Add generic gic-v1/gic-v2 compat strings.

[Mark Rutland]

On Wed, May 21, 2014 at 10:27:33PM +0100, Rob Herring wrote:
> On Wed, May 21, 2014 at 8:48 AM, Nikolay Borisov
> <Nikolay.Borisov@arm.com> wrote:
> > The current set of GIC compatible strings only contains specific
> > implementations (e.g. arm,cortex-a9-gic) rather than revisions of the
> > standard (e.g. arm,gic-v2), so each new implementation must either claim
> > to be an extension of an existing implementation or have a new string
> > added to the driver. This may be problematic when workarounds are
> > required for bugs in particular implementations, as said workaround may
> > end up targeting a wider set of implementations than intended.
> >
> > To prevent these issues, this patch adds compatible strings for the
> > revisions of the GIC spec which all GIC implementations should be able
> > to claim conformance to in addition to any particular implementation
> > specific string, e.g.
> 
> This just encourages not having specific properties which then also
> prevents being able to add work-arounds later. SOCs using the a9 or
> a15 string ONLY that are not an a9 or a15 are wrong. That's what we
> should fix. Adding more generic strings is not going to help that. Do
> you have a specific work-around you need to implement?

AFAIK, we don't have a specific workaround required anywhere that these
strings would help with. It's just that generic GIC strings had been
brought up repeatedly with no particular conclusion.

If we simply ensure that new DTS that feature a GIC have
implementation-specific strings in addition to those we already support
(e.g. "arm,cortex-a9-gic"), then I'm fine with that.

> Given that the GIC specs are obviously meaningless since we now have
> GICv2 with 16 core support as well as the special exynos gics, I'm not
> inclined to accept this.

Arguably neither are "true" GICv2, but your point stands.

Cheers,
Mark.

> 
> Rob
> 
> > compatible = "$VENDOR,specific-gic-variant", "arm,gic-v2";
> >
> > Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com>
> > Acked-by: Mark Rutland <Mark.Rutland@arm.com>
> > ---
> >  drivers/irqchip/irq-gic.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index 57d165e..89e9b05 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -1073,6 +1073,8 @@ gic_of_init(struct device_node *node, struct device_node *parent)
> >  }
> >  IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
> >  IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
> > +IRQCHIP_DECLARE(gic_v1, "arm,gic-v1", gic_of_init);
> > +IRQCHIP_DECLARE(gic_v2, "arm,gic-v2", gic_of_init);
> >  IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
> >  IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
> >
> > --
> > 1.8.1.5
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH RESEND 1/2] irqchip: Add generic gic-v1/gic-v2 compat strings.

[Christopher Covington]

Hi Rob,

On 05/22/2014 05:07 AM, Mark Rutland wrote:
> On Wed, May 21, 2014 at 10:27:33PM +0100, Rob Herring wrote:
>> On Wed, May 21, 2014 at 8:48 AM, Nikolay Borisov
>> <Nikolay.Borisov@arm.com> wrote:
>>> The current set of GIC compatible strings only contains specific
>>> implementations (e.g. arm,cortex-a9-gic) rather than revisions of the
>>> standard (e.g. arm,gic-v2), so each new implementation must either claim
>>> to be an extension of an existing implementation or have a new string
>>> added to the driver. This may be problematic when workarounds are
>>> required for bugs in particular implementations, as said workaround may
>>> end up targeting a wider set of implementations than intended.
>>>
>>> To prevent these issues, this patch adds compatible strings for the
>>> revisions of the GIC spec which all GIC implementations should be able
>>> to claim conformance to in addition to any particular implementation
>>> specific string, e.g.
>>
>> This just encourages not having specific properties which then also
>> prevents being able to add work-arounds later. SOCs using the a9 or
>> a15 string ONLY that are not an a9 or a15 are wrong. That's what we
>> should fix. Adding more generic strings is not going to help that. Do
>> you have a specific work-around you need to implement?
> 
> AFAIK, we don't have a specific workaround required anywhere that these
> strings would help with. It's just that generic GIC strings had been
> brought up repeatedly with no particular conclusion.
> 
> If we simply ensure that new DTS that feature a GIC have
> implementation-specific strings in addition to those we already support
> (e.g. "arm,cortex-a9-gic"), then I'm fine with that.
> 
>> Given that the GIC specs are obviously meaningless since we now have
>> GICv2 with 16 core support as well as the special exynos gics, I'm not
>> inclined to accept this.
> 
> Arguably neither are "true" GICv2, but your point stands.

I think the generic string (in addition to the specific one) is a good thing,
and I think it should be done for the PMU and any other specified/architected
hardware as well. If we don't allow for them, a shortcut would be to
masquerade hardware as something that's already supported. It seems like this
needs to be discouraged just as much as omitting the specific string.

The current behavior is that the driver will not run without a specific string
present. What if this were preserved (or replaced with a warning) even with
the addition of support for a generic string?

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

[PATCH 2/2] documentation/devicetree: Update GIC compat strings

[Nikolay Borisov]

This patch adds two new implementation-agonostic GIC compatible strings,
"gic-v1" and "gic-v2". Any implementation compatible with these revisions 
of the spec may include these strings in their compatible list in addition 
to any more specific string.

Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com>i
Acked-by: Mark Rutland <Mark.Rutland@arm.com>
---
 Documentation/devicetree/bindings/arm/gic.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 5573c08..223b4cc 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -12,6 +12,8 @@ Main node required properties:
 
 - compatible : should be one of:
 	"arm,gic-400"
+	"arm,gic-v1"
+	"arm,gic-v2"
 	"arm,cortex-a15-gic"
 	"arm,cortex-a9-gic"
 	"arm,cortex-a7-gic"
-- 
1.8.1.5