From mboxrd@z Thu Jan 1 00:00:00 1970 From: benh@kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 13 Jan 2016 16:53:33 +1100 Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc In-Reply-To: <4731036.9QlepWb5cE@wuerfel> References: <568912EE.9030009@huawei.com> <5694E9FF.6030904@huawei.com> <20160112151335.GS13633@e106497-lin.cambridge.arm.com> <4731036.9QlepWb5cE@wuerfel> Message-ID: <1452664413.2403.20.camel@kernel.crashing.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote: > On Tuesday 12 January 2016 15:13:35 liviu.dudau at arm.com?wrote: > > > int of_address_to_resource(struct device_node *dev, int index, > > >????????????????????????? struct resource *r) > > > { > > >?????? ... > > >?????? /* flags can be get here, without ranges property reqired. > > >??????? * if the reg = <0x0 0xe4 4>, I can get flag of > IORESOURCE_MEM, > > >??????? * if the reg = <0x1 0xe4 4>, I can get flag of > IORESOURCE_IO, > >? > > That is strange, the parent node has #address-cells = <2> so the > first two numbers should be part > > of the address and not influence the flags. Can you add some > debugging in of_get_address() and > > try to figure out what bus is used in? *flags = bus- > >get_flags(prop) ? > >? > >? > > This is the standard ISA binding. The first cell is the address space > (IO or MEM), the second cell is the address within that space. This > is similar to how PCI works. Picking up that mid-way, I have LPC busses on power and am using a similar binding. I'll try to grab some examples and review the document tomorrow (only just noticed it while unpiling emails post- vacation). Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Wed, 13 Jan 2016 16:53:33 +1100 Message-ID: <1452664413.2403.20.camel@kernel.crashing.org> References: <568912EE.9030009@huawei.com> <5694E9FF.6030904@huawei.com> <20160112151335.GS13633@e106497-lin.cambridge.arm.com> <4731036.9QlepWb5cE@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4731036.9QlepWb5cE@wuerfel> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann , liviu.dudau-5wv7dgnIgG8@public.gmane.org Cc: Rongrong Zou , Rongrong Zou , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Catalin Marinas , Corey Minyard , gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, Will Deacon , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote: > On Tuesday 12 January 2016 15:13:35 liviu.dudau-5wv7dgnIgG8@public.gmane.org=C2=A0wrote: > > > int of_address_to_resource(struct device_node *dev, int index, > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 struct resource *r) > > > { > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* flags can be get here, wit= hout ranges property reqired. > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * if the reg =3D <0x0 0= xe4 4>, I can get flag of > IORESOURCE_MEM, > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * if the reg =3D <0x1 0= xe4 4>, I can get flag of > IORESOURCE_IO, > >=C2=A0 > > That is strange, the parent node has #address-cells =3D <2> so the > first two numbers should be part > > of the address and not influence the flags. Can you add some > debugging in of_get_address() and > > try to figure out what bus is used in=C2=A0 *flags =3D bus- > >get_flags(prop) ? > >=C2=A0 > >=C2=A0 >=20 > This is the standard ISA binding. The first cell is the address space > (IO or MEM), the second cell is the address within that space. This > is similar to how PCI works. Picking up that mid-way, I have LPC busses on power and am using a similar binding. I'll try to grab some examples and review the document tomorrow (only just noticed it while unpiling emails post- vacation). Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752841AbcAMGOT (ORCPT ); Wed, 13 Jan 2016 01:14:19 -0500 Received: from gate.crashing.org ([63.228.1.57]:51611 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbcAMGOS (ORCPT ); Wed, 13 Jan 2016 01:14:18 -0500 Message-ID: <1452664413.2403.20.camel@kernel.crashing.org> Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc From: Benjamin Herrenschmidt To: Arnd Bergmann , liviu.dudau@arm.com Cc: Rongrong Zou , Rongrong Zou , devicetree@vger.kernel.org, Catalin Marinas , Corey Minyard , gregkh@linuxfoundation.org, Will Deacon , linux-kernel@vger.kernel.org, linuxarm@huawei.com, linux-arm-kernel@lists.infradead.org Date: Wed, 13 Jan 2016 16:53:33 +1100 In-Reply-To: <4731036.9QlepWb5cE@wuerfel> References: <568912EE.9030009@huawei.com> <5694E9FF.6030904@huawei.com> <20160112151335.GS13633@e106497-lin.cambridge.arm.com> <4731036.9QlepWb5cE@wuerfel> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3 (3.18.3-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-01-12 at 23:52 +0100, Arnd Bergmann wrote: > On Tuesday 12 January 2016 15:13:35 liviu.dudau@arm.com wrote: > > > int of_address_to_resource(struct device_node *dev, int index, > > >                          struct resource *r) > > > { > > >       ... > > >       /* flags can be get here, without ranges property reqired. > > >        * if the reg = <0x0 0xe4 4>, I can get flag of > IORESOURCE_MEM, > > >        * if the reg = <0x1 0xe4 4>, I can get flag of > IORESOURCE_IO, > >  > > That is strange, the parent node has #address-cells = <2> so the > first two numbers should be part > > of the address and not influence the flags. Can you add some > debugging in of_get_address() and > > try to figure out what bus is used in  *flags = bus- > >get_flags(prop) ? > >  > >  > > This is the standard ISA binding. The first cell is the address space > (IO or MEM), the second cell is the address within that space. This > is similar to how PCI works. Picking up that mid-way, I have LPC busses on power and am using a similar binding. I'll try to grab some examples and review the document tomorrow (only just noticed it while unpiling emails post- vacation). Cheers, Ben.