On Wed, Jan 13, 2010 at 10:23 AM, Scott Wood <[email protected]> wrote: > Grant Likely wrote: >> >> On Wed, Jan 13, 2010 at 7:19 AM, Yoder Stuart-B08248 >> <[email protected]> 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
