irqchip heirarchy DT "break" series awareness?
Jason Cooper
jason at lakedaemon.net
Tue Apr 7 06:06:38 PDT 2015
On Tue, Apr 07, 2015 at 11:21:35AM +0100, Marc Zyngier wrote:
> Hi Thomas,
>
> On 07/04/15 10:59, Thomas Petazzoni wrote:
>
> > But the point of the slides stand: even for a piece of hardware as
> > well-documented as the GIC, as widely used as the GIC, with as many
> > bright and smart engineers looking into it, the community has not been
> > able to put out a DT binding that can be kept stable. How can we expect
> > such a DT binding stability to occur for undocumented hardware, or
> > SoC-specific hardware blocks that are definitely a lot less used than
> > the GIC ?
>
> The problem at hand is not so much the GIC itself, but the fact that
> only the GIC was described in DT. The GIC binding is unchanged, but some
> additional hardware is now described.
Well, if that were the case we wouldn't have a break in DT
compatibility. I suppose what we're going for here is "removed GIC
binding properties (arm,routable-irqs) that didn't describe hardware".
Similar for crossbar and the others that were inappropriately relying on
gic_arch_extn implementation to model the (incorrect) hardware
description.
> If the relationship between the GIC and the shadow interrupt controllers
> had been described, we would have avoided breaking the compatibility. I
> guess it was too tempting to reuse pre-DT mechanisms and to forget about
> this entirely.
I'm not sure tempting is the right word. Everyone has known since this
project began that we were striving to describe the hardware. I suspect
the reason we got to where we are is that people *assumed* the code was
describing the hardware, and so wrote bindings reflecting their
understanding. iow, we don't have enough hardware engineers reviewing
bindings :-P
Be that as it may, I'm not trying to rehash the decision. It's clearly
the correct thing to do. Otherwise, I wouldn't have pulled it in. What
I am trying to do here is make sure a) we have full awareness by
everybody not directly involved, and b) make sure I have my ducks in a
row if ThomasG/Linus raises questions regarding the pull request.
thx,
Jason.
More information about the linux-arm-kernel
mailing list