All of lore.kernel.org
 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: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 23:33 [PATCH] of/irq: lookup 'interrupts-extended' property first Florian Fainelli
2014-07-31 18:00 ` Florian Fainelli
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 18:42       ` Rob Herring
2014-08-06 20:12       ` Brian Norris
2014-08-06 21:50         ` Tim Bird
2014-08-06 21:50           ` Tim Bird
2014-08-06 22:12           ` Florian Fainelli
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 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.