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

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:

quoted

On Wed, May 21, 2014 at 8:48 AM, Nikolay Borisov
[off-list ref] wrote:

quoted

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.

quoted

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.