Re: [Power.org:parch] Re: RFC: proposal to extend the open-pic interrupt specifierdefinition

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, Jan 13, 2010 at 10:23 AM, Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> Grant Likely wrote:
>>
>> On Wed, Jan 13, 2010 at 7:19 AM, Yoder Stuart-B08248
>> <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>>>>
>>>> It does not sound sane or
>>>> particularly parseable to stuff it into bitfields within the second
>>>> cell.
>>>
>>> I think it is somewhat sane compared to the alternatives.  The
>>> second cell encodes information about the interrupt source.  Allowing
>>> some of those bits to encode information besides level/sense
>>> doesn't seem that difficult.
>>
>> Not difficult.  Ugly, unnecessary, and sounds like a premature
>> optimization.
>
> It is not optimization, but functionality.

I don't doubt you need the data.  What I object to is stuffing it all
into a single cell since I think it is an unneeded optimization that
also makes it less user friendly.

>>>> Users have enough trouble parsing irq specifiers as is.  It makes me
>>>> nervous to see even more complicated irq specifiers being devised.
>>>
>>> Yes, they become slightly more complicated, but the complexity needs to
>>> go somewhere.
>>
>> Then at the very least do it as separate cells.  Carving cells into
>> multiple fields is pretty ugly when cells are cheap.
>
> That means that all the interrupt specifiers in an existing tree have to be
> updated with the larger numer of cells whenever such an interrupt is added,
> since #interrupt-cells applies globally to the MPIC interrupt domain.  It's
> unnecessary churn.

Pish.  You're talking about updating the interrupt properties in each
affected .dts file, and it only needs to be done when the new binding
is applied.  It will simply be adding a bunch of '0' cells to the
beginning of each existing interrupts property in the file.  Easy to
review, not a hard change to make, and easier to use/understand
binding for a long time to come.  BTW, how many .dts files do we
really have in the tree right now that will be using the new binding?
I'm guessing not many.  Heck, I'll even volunteer to make the change
in all affected .dts files when then new binding comes on-line.

Make the change now and don't burden us with a binding we'll be
cursing for the next 10 years.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.