Devicetree
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] of/irq: lookup 'interrupts-extended' property first
Date: Wed, 6 Aug 2014 09:54:52 -0700	[thread overview]
Message-ID: <20140806165452.GN3711@ld-irv-0074> (raw)
In-Reply-To: <CAGVrzcYfA8rCXGRW7g0JhT4GQKT8SQj+pMvCh25yoXLFGNM_Pw@mail.gmail.com>

Hi Grant, et al,

Can we get a comment here?

On Thu, Jul 31, 2014 at 11:00:01AM -0700, Florian Fainelli wrote:
> 2014-06-19 16:33 GMT-07:00 Florian Fainelli <f.fainelli@gmail.com>:
> > In case the Device Tree blob passed by the boot agent supplies both an
> > 'interrupts-extended' and an 'interrupts' property in order to allow for
> > older kernels to be usable, prefer the new-style 'interrupts-extended'
> > property which convey a lot more information.
> >
> > This allows us to have bootloaders willingly maintaining backwards
> > compatibility with older kernels without entirely deprecating the
> > 'interrupts' property (although that is a clear violation of the binding
> > specified at
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt)

For the patch:

Acked-by: Brian Norris <computersforpeace@gmail.com>

I think it is important that a device tree provide some flexibility on
kernel versions. We only invented 'interrupts-extended' in Linux 3.13,
so it's easy to have device trees that could work only on 3.13+.

Typically, we might say that new features require new kernels, but this
is a very basic piece of the DT infrastructure. In our case, we have
hardware whose basic features can be supported by a single interrupt
parent, and so we used the 'interrupts' property pre-3.13. But when we
want to add some power management features, there's an additional
interrupt parent. Under the current DT binding, we have to switch over
to using 'interrupts-extended' exclusively, and thus we must have a
completely new DTB for >=3.13, and this DTB no longer works with the old
kernels.

How's that for DT stability?

On the other hand, if we support this precedence concept, then a new DTB
can provide both the 'interrupts-extended' and 'interrupts' properties,
and thus be compatible with both pre-3.13 and
post-<whenever-this-is-accepted> kernels.

> Any comments on this? Brian suggested that I update
> interrupt-controller/interrupts.txt to specify the look up ordering
> change as well.

What do you think about the following DT binding doc update to accompany
this change?

Signed-off-by: Brian Norris <computersforpeace@gmail.com>

diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
index 1486497a24c1..ce6a1a072028 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
@@ -4,11 +4,13 @@ Specifying interrupt information for devices
 1) Interrupt client nodes
 -------------------------
 
-Nodes that describe devices which generate interrupts must contain an either an
-"interrupts" property or an "interrupts-extended" property. These properties
-contain a list of interrupt specifiers, one per output interrupt. The format of
-the interrupt specifier is determined by the interrupt controller to which the
-interrupts are routed; see section 2 below for details.
+Nodes that describe devices which generate interrupts must contain an
+"interrupts" property, an "interrupts-extended" property, or both. If both are
+present, the latter should take precedence; the former may be provided simply
+for compatibility with software that does not recognize the latter. These
+properties contain a list of interrupt specifiers, one per output interrupt. The
+format of the interrupt specifier is determined by the interrupt controller to
+which the interrupts are routed; see section 2 below for details.
 
   Example:
 	interrupt-parent = <&intc1>;

  reply	other threads:[~2014-08-06 16:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 23:33 [PATCH] of/irq: lookup 'interrupts-extended' property first Florian Fainelli
     [not found] ` <1403220823-19444-1-git-send-email-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-31 18:00   ` Florian Fainelli
2014-08-06 16:54     ` Brian Norris [this message]
2014-08-06 18:42       ` Rob Herring
2014-08-06 20:12         ` Brian Norris
2014-08-06 21:50           ` Tim Bird
     [not found]             ` <CA+bK7J7LQq4S70ScSynbLTjNMmP=9n3KD2suYRg9JN+pEv-Y7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-06 22:12               ` Florian Fainelli
2014-08-15 12:56                 ` Grant Likely
2014-08-06 22:24             ` Rob Herring

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=20140806165452.GN3711@ld-irv-0074 \
    --to=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.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