On Mon, Oct 28, 2013 at 09:47:44PM +0000, Stephen Warren wrote: > On 10/27/2013 07:46 AM, Grant Likely wrote: > > On Tue, 15 Oct 2013 21:39:23 +0100, Grant Likely <grant.lik...@linaro.org> > > wrote: > >> The standard interrupts property in device tree can only handle > >> interrupts coming from a single interrupt parent. If a device is wired > >> to multiple interrupt controllers, then it needs to be attached to a > >> node with an interrupt-map property to demux the interrupt specifiers > >> which is confusing. It would be a lot easier if there was a form of the > >> interrupts property that allows for a separate interrupt phandle for > >> each interrupt specifier. > >> > >> This patch does exactly that by creating a new interrupts-extended > >> property which reuses the phandle+arguments pattern used by GPIOs and > >> other core bindings. > >> > >> Signed-off-by: Grant Likely <grant.lik...@linaro.org> > >> Cc: Rob Herring <rob.herr...@calxeda.com> > > > > Alright, I want to merge this one. I've got an Ack from Tony, general > > agreement from an in person converstaion from Ben (aside from wishing he > > could think of a better property name), and various rumblings of > > approval from anyone I talked to about it at ksummit. I'd like to have > > something more that that to put into the commit text. Please take a look > > and let me know if you agree/disagree with this binding. > > The new binding makes sense to me. So, the binding, > Acked-by: Stephen Warren <swar...@nvidia.com> > > A couple of minor perhaps bikesheddy comments below. > > >> diff --git > >> a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > >> b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > >> +Nodes that describe devices which generate interrupts must contain an > >> either an > >> +"interrupts" property or an "interrupts-extended" property. These > >> properties > > "interrupts-ex" would be shorter, although I guess slightly harder to > guess its purpose, unless you're familiar with "ex" in symbol names.
I'd prefer a more precise name. IMO "-extended" is preferable to "-ex". > > ... > >> +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? I think recommending a behaviour relating to parsing is valid. Parsing notes in bindings make it very easy to write an extensible binding. I think if we'd just stated that having both properties was invalid you would not have a problem? > > >> 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. > This sounds reasonable to me, but I'd definitely want the kernel to scream (though I appreciate that's separate from the binding details). Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
