From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754083AbcALWxn (ORCPT <rfc822;w@1wt.eu>);
	Tue, 12 Jan 2016 17:53:43 -0500
Received: from mout.kundenserver.de ([212.227.126.187]:58749 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753959AbcALWxl (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 12 Jan 2016 17:53:41 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: liviu.dudau@arm.com
Cc: Rongrong Zou <zourongrong@huawei.com>,
        Rongrong Zou <zourongrong@gmail.com>, devicetree@vger.kernel.org,
        Catalin Marinas <catalin.marinas@arm.com>,
        Corey Minyard <minyard@acm.org>, gregkh@linuxfoundation.org,
        Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org,
        linuxarm@huawei.com, benh@kernel.crashing.org,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc
Date: Tue, 12 Jan 2016 23:52:48 +0100
Message-ID: <4731036.9QlepWb5cE@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <20160112151335.GS13633@e106497-lin.cambridge.arm.com>
References: <568912EE.9030009@huawei.com> <5694E9FF.6030904@huawei.com> <20160112151335.GS13633@e106497-lin.cambridge.arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:Cj49ERbDlEW8js8KaTkAAhnFPUb/gfMz+EC+ih2iv002NahCl8C
 M85JRHNMK6L4Y6kmo8zWOKd1M7z2Kq65edi2XrsGZixoCF5at059qNMv7DRK1NAzMwE955O
 uFiLV6aG2LMuyRDJcf2iUEwMHIPJ0JgI/o6dda23a9xV+zp0HkN9Nnd46HX5pqMEc/UK546
 ki1HgAsuyvO+1TbvPCBEg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:NBov2bU9rLM=:NOq/mHP6nyKRQ1KK4Q5K2x
 ZkQ7pS5K0MzYUzAM/F3y/nhFJ32CzMg5qvApuc8j1bTSzJ14S4h4ZClpA9l1GO0mSNuzps5hT
 /B/ICL0s3H5EMc9Y6PbhJ/gDfRF0ZdGi6lHp9zjOtHiYi+ATHil6E9GFt8eaO8ZRvBHUOFSRg
 1cdj4RnS+xCux5TM7waBWQ1DmXAspYXXb9GS/UkYULi5qZ51STvt68ZwEhgMTe6e67L/h3xvD
 qJRySPGuliQb7xhLNR+dcqD9n0vj5EMBJJ91yyxsawXA4X+yFa+kvzRyEkqsX9v8Ldcy9sRj2
 pCsXARZUb04Eo/0WUdqyFX427txcqXVbD8L6Oj/aoZIbfPSVLlpDA9EkVa68NIEoSMnqWmxGy
 RaJdIocvxnfuLoRP6MtV4JauYcllA1PIYqfw3pu8fAQWVcABdWpI0oN/VFOGbzX9IfrPM/pgK
 8yVfbTFyy/1CKrE+ZcFd0W9TyMXxyz2VcO0y3kY+2GhaV1m57uUSKYYmoJXQfXKPC2LGIrJi+
 RtswANBPQo5e0THjtIuU4JSzLV3KtAVxHUP1OWvaSOeLiLzhW3vxyF+zXM+YwV14TFY4Z7tPo
 R6bySfGnqQFT8ErCyaxE4f4Sy0mOi7B+WNEuFksGx7yg9FUphk+ELL4IQz/KuV27dvRwu9iLT
 8JrOCsH2Twh8VHJb4JfoU0fSpIxDME7mUcvzEaWhsiRFy0bFhOVGjURYlHWKwPiLkQcHam+Wh
 GzAdIBfFlZX+fEPU
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

	Arnd