From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Grant Likely <grant.likely@linaro.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring <rob.herring@calxeda.com>,
Mark Rutland <mark.rutland@arm.com>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [RFC 9/9] of/irq: create interrupts-extended property
Date: Tue, 29 Oct 2013 10:16:14 +1100 [thread overview]
Message-ID: <1383002174.5117.19.camel@pasglop> (raw)
In-Reply-To: <526EDB80.7080406@wwwdotorg.org>
On Mon, 2013-10-28 at 15:47 -0600, Stephen Warren wrote:
> "interrupts-ex" would be shorter, although I guess slightly harder to
> guess its purpose, unless you're familiar with "ex" in symbol names.
>
> ...
> >> +A device node may contain either "interrupts" or "interrupts-extended", but not
> >> +both. If both properties are present, then the operating system should log an
> >> +error
>
> That sounds rather like prescribing SW behaviour, which I thought DT
> bindings shouldn't do?
>
> >> and use only the data in "interrupts".
>
> ... so perhaps that's better phrased as:
>
> A device node may contain either "interrupts" or "interrupts-extended",
> but not both. If both properties are present, the data in "interrupts"
> takes precedence.
So let's add a coat of paint to this shed :-)
Either it's an error, or we have a precedence rule. If it's an error
then there is no point having a precedence rule, the DT is broken and
might be in all sort of other ways, the precedence is pointless, there's
no telling what property is correct.
However, if we have a precedence rule, then it should be the other way
around, interrupts-extended takes precedence.
A concrete example:
A device has two interrupts "INT0" and "INT1". One goes to PICA, the
other one to PICB,
the first one is necessary for basic use, the second one is only
necessary for some advanced/new functionality.
It makes sense in this case to have the device-tree do:
interrupts = < INT0 >;
interrupt-parent = <&PICA>;
interrupts-extended = <&PICA, INT0, &PICB, INT1>;
Because that way:
- An old kernel which doesn't understand interrupts-extended but *also*
only uses the first interrupt (doesn't exploit the advanced/new
functionalities) will work by picking up interrupts+interrupt-parent,
- A newer kernel which does understand interrupts-extended can then
make use of it to support the advanced/new functionalities.
Cheers,
Ben.
next prev parent reply other threads:[~2013-10-28 23:17 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 20:39 [RFC 0/9] of: refactor IRQ parsing and add interrupts-extended implementation Grant Likely
[not found] ` < 1381869563-16083-10-git-send-email-grant.likely@linaro.org>
[not found] ` < CAEgOgz6=HhBkb2KtxcmHpNdE_0sNngw0NaL2SnLWj1opZkO3SA@mail.gmail.com>
[not found] ` < 20131112065405.C75E8C42024@trevor.secretlab.ca>
[not found] ` < CAEgOgz6j8YsvFgq8ZbE20ocHPA0C-eUGBb7F1gNiVBvJXLa8_g@mail.gmail.com>
[not found] ` < 20131112085038.B6A75C421BB@trevor.secretlab.ca>
[not found] ` < CAEgOgz4dM1zQdFpOkUwZqAUMUBe2eh3j1Ah0KgomVAOGgrPsVw@mail.gmail.com>
[not found] ` < 20131113061425.667F9C41807@trevor.secretlab.ca>
[not found] ` < CAEgOgz5BWzo-LGddjG6ZUtKt6GHxLmDUEndFOdVrn+1HTPvpGQ@mail.gmail.com>
[not found] ` < 20131124213212.226B8C402C3@trevor.secretlab.ca>
2013-10-15 20:39 ` [RFC 1/9] of/irq: Rename of_irq_map_* functions to of_irq_parse_* Grant Likely
2013-10-16 10:47 ` Michal Simek
2013-10-15 20:39 ` [RFC 2/9] of/irq: Replace of_irq with of_phandle_args Grant Likely
2013-10-15 20:39 ` [RFC 3/9] of/irq: simplify args to irq_create_of_mapping Grant Likely
2013-10-15 20:39 ` [RFC 4/9] of/irq: Refactor interrupt-map parsing Grant Likely
2013-10-29 16:23 ` Olof Johansson
2013-10-31 1:19 ` Ming Lei
[not found] ` <CACxGe6uE+KvycQq3XBavRcvprff6PhBaxX54W_Cb1cfuVpMXvQ@mail.gmail.com>
2013-10-31 18:57 ` Olof Johansson
2013-11-01 14:48 ` Grant Likely
2013-11-01 17:53 ` Grant Likely
2013-11-01 18:54 ` Grant Likely
2013-11-02 4:16 ` Ming Lei
2013-11-04 5:04 ` Olof Johansson
2013-11-05 15:18 ` Tomasz Figa
2013-11-05 15:21 ` [PATCH 1/2] of: irq: Fix interrupt-map entry matching Tomasz Figa
2013-11-07 11:32 ` Tomasz Figa
2013-11-07 16:40 ` Rob Herring
2013-11-07 22:11 ` Tomasz Figa
2013-11-08 9:37 ` Grant Likely
2013-11-07 11:50 ` Sachin Kamat
2013-11-05 15:21 ` [PATCH 2/2] of: irq: Check for reg property presence only when parsing interrupt-map Tomasz Figa
2013-11-07 11:33 ` Tomasz Figa
2013-11-01 19:07 ` [RFC 4/9] of/irq: Refactor interrupt-map parsing Stephen Warren
2013-10-31 20:45 ` [RFC 4/9] of/irq: Refactor interrupt-map parsing [CPU hotplug clockevents issue] Stephen Warren
2013-10-15 20:39 ` [RFC 5/9] of: Add helper for printing an of_phandle_args structure Grant Likely
2013-10-15 20:39 ` [RFC 6/9] of: Add testcases for interrupt parsing Grant Likely
2013-10-15 20:39 ` [RFC 7/9] of/irq: Create of_irq_parse_and_map_pci() to consolidate arch code Grant Likely
2013-10-15 20:39 ` [RFC 8/9] microblaze/pci: Drop PowerPC-ism from irq parsing Grant Likely
2013-10-15 20:39 ` [RFC 9/9] of/irq: create interrupts-extended property Grant Likely
2013-10-17 17:33 ` Tony Lindgren
2013-10-27 13:46 ` Grant Likely
2013-10-27 20:24 ` Rob Herring
2013-10-28 3:16 ` Mark Rutland
2013-10-28 6:54 ` Kumar Gala
2013-10-28 21:47 ` Stephen Warren
2013-10-28 22:49 ` Mark Rutland
2013-10-28 23:16 ` Benjamin Herrenschmidt [this message]
2013-10-28 6:54 ` Kumar Gala
2013-10-28 23:41 ` Grant Likely
2013-11-11 22:58 ` Peter Crosthwaite
2013-11-12 6:54 ` Grant Likely
2013-11-12 7:49 ` Peter Crosthwaite
2013-11-12 8:50 ` Grant Likely
2013-11-12 23:17 ` Peter Crosthwaite
2013-11-13 6:14 ` Grant Likely
2013-11-24 7:04 ` Peter Crosthwaite
2013-11-24 21:32 ` Grant Likely
2013-11-27 9:06 ` Peter Crosthwaite
2013-11-27 14:17 ` Grant Likely
2013-11-28 7:28 ` Peter Crosthwaite
2013-10-17 17:30 ` [RFC 0/9] of: refactor IRQ parsing and add interrupts-extended implementation Tony Lindgren
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=1383002174.5117.19.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@kernel.crashing.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.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).