Re: irqchip heirarchy DT "break" series awareness?

On Tue, Apr 07, 2015 at 11:21:35AM +0100, Marc Zyngier wrote:

Hi Thomas,

On 07/04/15 10:59, Thomas Petazzoni wrote:

quoted

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.

quoted

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

FWIW when routable-irqs was introduced I negatively reviewed it, stating
that it was backwards, and that the crossbar driver should request the
appropriate domain dynamically [1]. We _knew_ it was wrong at the time,
but people decided to ignore that review because it was easier to do
things in a broken way.

A more general issue is that people hack in the minimal amount of DT
parsing code to an existing driver and rely on platform data and code to
do the heavy lifting, rather than doing a clean break with DT (which
would highlight deficiencies in the bndings). You end up with the worst
of both worlds, because you depend on both an incomplete DT and
implementation-specific platform data/code.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211530.html