From mboxrd@z Thu Jan  1 00:00:00 1970
From: heiko@sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 22 Jul 2014 23:45:47 +0200
Subject: [PATCH] ARM: dts: rk3188-radxarock: add GPIO IR receiver node
In-Reply-To: <20140714190355.GA16904@gmail.com>
References: <1405253401-15534-1-git-send-email-b.galvani@gmail.com>
 <2390327.HZxnbJmfOO@diego> <20140714190355.GA16904@gmail.com>
Message-ID: <3433422.DZFVBm30W2@diego>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Am Montag, 14. Juli 2014, 21:04:26 schrieb Beniamino Galvani:
> On Sun, Jul 13, 2014 at 02:37:40PM +0200, Heiko St?bner wrote:
> > Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:
> > > This adds a device tree node for the infrared receiver connected to a
> > > GPIO pin on the Radxa Rock.
> > > 
> > > Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
> > > ---
> > > 
> > >  arch/arm/boot/dts/rk3188-radxarock.dts |   13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
> > > b/arch/arm/boot/dts/rk3188-radxarock.dts index 19d45b4..1d87bcb 100644
> > > --- a/arch/arm/boot/dts/rk3188-radxarock.dts
> > > +++ b/arch/arm/boot/dts/rk3188-radxarock.dts
> > > @@ -23,6 +23,13 @@
> > > 
> > >  		reg = <0x60000000 0x80000000>;
> > >  	
> > >  	};
> > > 
> > > +	ir_recv: ir-receiver {
> > > +		compatible = "gpio-ir-receiver";
> > > +		gpios = <&gpio0 10 1>;
> > > +		pinctrl-names = "default";
> > > +		pinctrl-0 = <&ir_recv_pin>;
> > > +	};
> > > +
> > 
> > hmm, on second glance, I'm actually not sure if this shouldn't belong in
> > the soc subnode, like the gpio-keys and leds.
> 
> (adding devicetree mailing list)
> 
> I placed the IR receiver under the root node after looking at what
> other boards do, for example:
> 
>   imx6dl-hummingboard.dts
>   imx6qdl-cubox-i.dtsi
>   dove-cubox.dts
> 
> On the other hand, if gpio-keys and leds are under the soc node
> probably it makes sense to follow the same rule also for the IR
> receiver.

your way was the right one actually ... using artificial subnodes is not 
encouraged at all - see comments I received , so the soc node itself also may 
go away.

I'll add the patch to my queue.


Heiko