On Mon, Oct 16, 2017 at 4:03 AM, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > On Mon, Oct 16, 2017 at 10:56:32AM +0200, Lothar Waßmann wrote: >> Hi, >> >> On Mon, 16 Oct 2017 09:17:26 +0200 Uwe Kleine-König wrote: >> > Hello, >> > >> > On Wed, Oct 11, 2017 at 01:05:38PM +0200, Lothar Waßmann wrote: >> > > diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts >> > > index 211e67d..3c852f7 100644 >> > > --- a/arch/arm/boot/dts/imx28-tx28.dts >> > > +++ b/arch/arm/boot/dts/imx28-tx28.dts >> > > @@ -328,8 +328,7 @@ >> > > reg = <0x20>; >> > > pinctrl-names = "default"; >> > > pinctrl-0 = <&tx28_pca9554_pins>; >> > > - interrupt-parent = <&gpio3>; >> > > - interrupts = <28 0>; >> > > + interrupts-extended = <&gpio3 28 IRQ_TYPE_NONE>; >> > > gpio-controller; >> > > #gpio-cells = <2>; >> > > interrupt-controller; >> > >> > While interrupts-extended looks nice, >> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > has: >> > >> > "interrupts-extended" should only be used when a device has >> > multiple interrupt parents. >> > >> > If this is still true, this patch is wrong. >> > >> Thanks for the hint. It really helps to read the documentation >> sometimes, rahter than relying on existing code only... >> >> A quick check shows, that more than 100 of the 130 uses of >> interrupts-extended are wrong. :( > > That's why I honestly consider that these documentation bits are stale. > I adapted the Subject to maybe catch the attention of the devicetree > guys. The documentation is correct as that is recommended practice IMO. I wouldn't go fixing the 100 cases found either. > (BTW: The current wording is likely imprecise. I'd expect that it really > should mean "Use interrupt-parent + interrupts if possible", but the > following still fulfills the documented condition: "should" is pretty standard to mean recommended vs. "shall" or "must" meaning required. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
