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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.