Re: [PATCH] powerpc: document new interrupt-array property

[Segher Boessenkool <segher@kernel.crashing.org>]

>> It can't do a 100% job (of course; if it could it wouldn't
>> need a device tree at all since it would be omniscient), but
>> it still can do quite a reasonable job.
>
> Not in at least one common case:  where all interrupt controllers are
> of the same type.

You'll get a lot of collisions in that case, easy to detect.

>> And this isn't the end of the story; the kernel won't say
>> "huh where's my IRQ" but it will try a few more options
>> first (at least on PCI, it can be true on other buses as
>> well in principle) and quite likely it will return some
>> bad number.
>
> Um.. examples?  I can't think of any case except legacy ISA when we'd
> have either reason or method to go beyond the device tree information.

PCI isn't required to have a device tree at all, with the
flat tree.

>> And very likely ends up with a conflict on that second interrupt
>> since some other device uses it as well.  Stuff will complain
>> at initialisation time still and all is fine.
>
> Only if the other driver is present and doesn't allow sharing.

If _either_ doesn't allow sharing, i.e., almost all of
the time.

>> That would be the programmer who programmed the device tree
>> (unless he doesn't test his work) so I can't see why he would
>> be baffled.
>
> Not necessarily.  Maybe the error condition never happens in the
> device tree programmer's network environment.  The driver seems to
> work just fine for him.

Which just means he didn't do a proper job of testing.

> What?  It's perfectly possible to share level triggered interrupts.
> PCI devices do it all the time.

Erm yeah I goofed, sorry :-)

>> Yeah, funky interrupt problems are a bitch to resolve,
>> aren't they.  But the interrupt can't be shared so this
>> case cannot happen either.
>
> Again, yes they can be.

SoC interrupts shared?  Not very likely...
Sure in principle anything can happen.

>> Now back to the meat of the matter:
>>
>> Whenever you're writing a device tree, after every small
>> change to the tree you should check it for validity (by
>> hand or some checking tool), and see if it works on all
>> kernel versions you claim to support too (not quite the
>> same thing, heh).  If things go wrong you know what change
>> caused it.
>
> Ah, yes, every change should be tested in every configuration.  Lovely
> idea, never going to happen.

One device tree == one configuration.  Static
device trees are easy, heh.

>> And, lastly, the most important point that you conveniently
>> snipped off on your reply:
>>
>>>> Anyway, it's all a question of deployment: you just
>>>> have to make sure your users use a new enough kernel
>>>> with your device tree (and device), which you have
>>>> to do *anyway*.  Also DTS files are still conveniently
>>>> shipped with the kernel so it's even less of a problem.
>>
>> If you care about compatibility to random kernel versions
>> instead, you'd better not do surgery on the interrupt
>> mapping binding at all but just put an extra interrupt
>> nexus in your device tree.

It's still sitting here...

We can have a pointless fight over how hard to debug
certain device tree bugs are, but that's not really
important is it.


Segher