| Message ID | 20160819124414.24242-5-andrew@aj.id.au |
|---|---|
| State | New |
| Headers | show |
On Fri, Aug 19, 2016 at 10:14:10PM +0930, Andrew Jeffery wrote: > Signed-off-by: Andrew Jeffery <andrew@aj.id.au> > --- > > Since v1: > > Rob: I haven't added your Acked-by here as I've made the following changes and > wanted to get your input: > > * Remove interrupt-controller as an optional property > * Defer to interrupt-controller bindings document for sub-node properties > > I had a discussion with Joel about whether the interrupt-controller capability > should be optional and the conclusion was that it should always be configured > by the driver. This makes an optional interrupt-controller property feel > redundant (and possibly inaccurate if left out) so I've removed it. I don't follow. What do you mean byt "configured by the driver". If the block supports interrupts, then it should be marked as an interrupt-controller. It never should have been optional. The OS can ignore the interrupt properties if it chooses. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2016-08-19 at 09:36 -0500, Rob Herring wrote: > On Fri, Aug 19, 2016 at 10:14:10PM +0930, Andrew Jeffery wrote: > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au> > > --- > > > > Since v1: > > > > Rob: I haven't added your Acked-by here as I've made the following changes and > > wanted to get your input: > > > > * Remove interrupt-controller as an optional property > > * Defer to interrupt-controller bindings document for sub-node properties > > > > I had a discussion with Joel about whether the interrupt-controller capability > > should be optional and the conclusion was that it should always be configured > > by the driver. This makes an optional interrupt-controller property feel > > redundant (and possibly inaccurate if left out) so I've removed it. > I don't follow. What do you mean byt "configured by the driver". If the > block supports interrupts, then it should be marked as an > interrupt-controller. It never should have been optional. The OS can > ignore the interrupt properties if it chooses. Right, clearly there was some confusion on my part. I will fix that up. Thanks for clarifying. Andrew
On Mon, Aug 22, 2016 at 9:46 AM, Andrew Jeffery <andrew@aj.id.au> wrote: > On Fri, 2016-08-19 at 09:36 -0500, Rob Herring wrote: >> On Fri, Aug 19, 2016 at 10:14:10PM +0930, Andrew Jeffery wrote: >> > >> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au> >> > --- >> > >> > Since v1: >> > >> > Rob: I haven't added your Acked-by here as I've made the following changes and >> > wanted to get your input: >> > >> > * Remove interrupt-controller as an optional property >> > * Defer to interrupt-controller bindings document for sub-node properties >> > >> > I had a discussion with Joel about whether the interrupt-controller capability >> > should be optional and the conclusion was that it should always be configured >> > by the driver. This makes an optional interrupt-controller property feel >> > redundant (and possibly inaccurate if left out) so I've removed it. >> I don't follow. What do you mean byt "configured by the driver". If the >> block supports interrupts, then it should be marked as an >> interrupt-controller. It never should have been optional. The OS can >> ignore the interrupt properties if it chooses. > > Right, clearly there was some confusion on my part. I will fix that up. > Thanks for clarifying. > Thanks for clarifying this Rob. With this cleared up, Acked-by: Joel Stanley <joel@jms.id.au> -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt new file mode 100644 index 000000000000..a5ad1eb93ce0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt @@ -0,0 +1,34 @@ +Aspeed GPIO controller Device Tree Bindings +------------------------------------------- + +Required properties: +- #gpio-cells : Should be two + - First cell is the GPIO line number + - Second cell is used to specify optional + parameters (unused) + +- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio" + +- reg : Address and length of the register set for the device +- gpio-controller : Marks the device node as a GPIO controller. +- interrupts : Interrupt specifier (see interrupt bindings for + details) + +Optional properties: + +- interrupt-parent : The parent interrupt controller, optional if inherited + +The gpio and interrupt properties are further described in their respective +bindings documentation: + +- Documentation/devicetree/bindings/gpio/gpio.txt +- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + + Example: + gpio@1e780000 { + #gpio-cells = <2>; + compatible = "aspeed,ast2400-gpio" + gpio-controller; + interrupts = <20>; + reg = <0x1e780000 0x1000>; + };
Signed-off-by: Andrew Jeffery <andrew@aj.id.au> --- Since v1: Rob: I haven't added your Acked-by here as I've made the following changes and wanted to get your input: * Remove interrupt-controller as an optional property * Defer to interrupt-controller bindings document for sub-node properties I had a discussion with Joel about whether the interrupt-controller capability should be optional and the conclusion was that it should always be configured by the driver. This makes an optional interrupt-controller property feel redundant (and possibly inaccurate if left out) so I've removed it. .../devicetree/bindings/gpio/gpio-aspeed.txt | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-aspeed.txt