From: Segher Boessenkool <segher@kernel.crashing.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
Stuart Yoder <b08248@freescale.com>
Subject: Re: [PATCH] powerpc: document new interrupt-array property
Date: Sat, 24 Feb 2007 12:11:56 +0100 [thread overview]
Message-ID: <c3142d07a3c85adb9e67659ee5953c45@kernel.crashing.org> (raw)
In-Reply-To: <1172298948.1902.20.camel@localhost.localdomain>
>> It would be nicer to keep the "interrupts" property and
>> add a property "interrupt-parents" with the same number
>> of entries, that encodes the same as "interrupt-parent"
>> but per interrupt. You keep more in line with the
>> "normal" stuff and I suspect it's less code to parse as
>> well.
>
> There are pro and cons to this approach. I did think about it
> initially.
> The main cons is that "interrupts" becomes harder to parse as you ahve
> to walk interrupt-parents at the same time to get the #interrupt-cells
> of each entry.
Yeah, you have to do some things inside of the interrupt
parsing loop, that you normally can move outside of the
loop. That's true in the "interrupt-array" case too, you
just get the interrupt parent from somewhere else. It's
in the nature of this extension.
> Also, it adds more potential for stupid breakage (how
> shluld the parser react if interrupt-parents has less entries than
> interrupts ?)
Just fail loudly. Just like it should do if it notes
something else nonsensical (a non-phandle in the
"interrupt-array" case, for example, or running out
of encoded integers while parsing).
> The pro, which is quite important too, is that it's a common assuption
> that you have interrupts when you have an "interrupts" property,
> period.
Yes, it would be a lot closer to the generic case, only add
to the interrupt mapping binding, not change anything in the
base OF spec.
> In fact, it would indeed fit a bit better in the current parser.
Yeah I think so too.
>> Wrong place to document this? It's true for all interrupt
>> specifiers.
>
> Might be worth giving a crazy example where the 2 interrupt specifiers
> have different size.
I'd rather not. Anyway, this was in reply to:
>> +Note: the number of cells needed to represent the
>> +interrupt-specifier is determined by the #interrupt-cells
>> +property of the interrupt parent.
Which is a general statement about interrupt specifiers.
Nowhere does the "booting without OF" doc define interrupt
specifiers before it uses them; do that, move this comment
there, and put a comment saying "each entry in "interrupts"
can potentially have a different # of interrupt cells, you
have to look at the corresponding interrupt parent to find
out" in its place?
Segher
prev parent reply other threads:[~2007-02-24 11:12 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-21 23:25 [PATCH] powerpc: document new interrupt-array property Stuart Yoder
2007-02-22 0:29 ` Kumar Gala
2007-02-22 1:18 ` David Gibson
2007-02-22 7:01 ` Segher Boessenkool
2007-02-22 10:34 ` David Gibson
2007-02-22 11:06 ` Segher Boessenkool
2007-02-22 15:47 ` Yoder Stuart-B08248
2007-02-22 17:09 ` Segher Boessenkool
2007-02-23 19:15 ` Yoder Stuart-B08248
2007-02-23 21:30 ` Segher Boessenkool
2007-02-23 21:57 ` Yoder Stuart-B08248
2007-02-23 22:30 ` Segher Boessenkool
2007-02-24 6:42 ` Benjamin Herrenschmidt
2007-02-24 6:40 ` Benjamin Herrenschmidt
2007-02-24 11:24 ` Segher Boessenkool
2007-02-26 4:16 ` David Gibson
2007-02-26 5:36 ` Segher Boessenkool
2007-02-26 13:08 ` David Gibson
2007-02-26 14:26 ` Segher Boessenkool
2007-02-27 2:32 ` David Gibson
2007-02-27 2:52 ` Segher Boessenkool
2007-02-27 3:45 ` David Gibson
2007-02-27 11:49 ` Segher Boessenkool
2007-02-28 0:40 ` David Gibson
2007-02-28 1:00 ` Segher Boessenkool
2007-02-28 6:40 ` Benjamin Herrenschmidt
2007-02-26 16:53 ` Yoder Stuart-B08248
2007-02-22 22:57 ` David Gibson
2007-02-23 0:07 ` Segher Boessenkool
2007-02-23 0:33 ` David Gibson
2007-02-23 0:50 ` Segher Boessenkool
2007-02-23 16:07 ` Yoder Stuart-B08248
2007-02-23 16:14 ` Kumar Gala
2007-02-23 17:00 ` Segher Boessenkool
2007-02-23 16:55 ` Segher Boessenkool
2007-02-23 17:01 ` Yoder Stuart-B08248
2007-02-23 17:51 ` Segher Boessenkool
2007-02-22 22:48 ` David Gibson
2007-02-23 0:25 ` Segher Boessenkool
2007-02-24 6:30 ` Benjamin Herrenschmidt
2007-02-24 11:16 ` Segher Boessenkool
2007-02-22 7:19 ` Segher Boessenkool
2007-02-24 6:35 ` Benjamin Herrenschmidt
2007-02-24 11:11 ` Segher Boessenkool [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3142d07a3c85adb9e67659ee5953c45@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=b08248@freescale.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).