From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934136AbcAMLGy (ORCPT ); Wed, 13 Jan 2016 06:06:54 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35153 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933470AbcAMLGv (ORCPT ); Wed, 13 Jan 2016 06:06:51 -0500 Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc To: liviu.dudau@arm.com, Arnd Bergmann References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <5694C6A4.8060308@huawei.com> <20160112101418.GO13633@e106497-lin.cambridge.arm.com> <4052627.BRvFkUij6q@wuerfel> <20160113100911.GU13633@e106497-lin.cambridge.arm.com> Cc: Rongrong Zou , devicetree@vger.kernel.org, Catalin Marinas , Corey Minyard , gregkh@linuxfoundation.org, Will Deacon , linux-kernel@vger.kernel.org, linuxarm@huawei.com, benh@kernel.crashing.org, linux-arm-kernel@lists.infradead.org From: Rongrong Zou Message-ID: <56962FC2.1070101@gmail.com> Date: Wed, 13 Jan 2016 19:06:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160113100911.GU13633@e106497-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/13 18:09, liviu.dudau@arm.com wrote: > On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote: >> On Tuesday 12 January 2016 10:14:18 liviu.dudau@arm.com wrote: >>> >>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is >>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa >>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have >>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>; >>> >>> >> >> A missing ranges property means that there is no translation, while an >> empty ranges means a 1:1 translation to the parent bus. >> >> We really want the former here, as I/O port addresses are not mapped into >> the MMIO space of the parent bus. > > Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no > useful suggestions on what the right behaviour should be. > I had tried to modify the drivers/of/address.c to address this problem, but it looks not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 . Regards, Rongrong From mboxrd@z Thu Jan 1 00:00:00 1970 From: zourongrong@gmail.com (Rongrong Zou) Date: Wed, 13 Jan 2016 19:06:42 +0800 Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc In-Reply-To: <20160113100911.GU13633@e106497-lin.cambridge.arm.com> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <5694C6A4.8060308@huawei.com> <20160112101418.GO13633@e106497-lin.cambridge.arm.com> <4052627.BRvFkUij6q@wuerfel> <20160113100911.GU13633@e106497-lin.cambridge.arm.com> Message-ID: <56962FC2.1070101@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2016/1/13 18:09, liviu.dudau at arm.com wrote: > On Tue, Jan 12, 2016 at 11:54:59PM +0100, Arnd Bergmann wrote: >> On Tuesday 12 January 2016 10:14:18 liviu.dudau at arm.com wrote: >>> >>> OK, looking at of_translate_one() comments it looks like a missing "ranges" property is >>> only accepted on PowerPC. I suggest you have an empty "ranges" property in your isa >>> parent node, that will signal to the OF parsing code that the mapping is 1:1. Then have >>> the IPMI node use the reg = <0x0 0xe4 4>; property values instead of reg = <0x1 0xe4 4>; >>> >>> >> >> A missing ranges property means that there is no translation, while an >> empty ranges means a 1:1 translation to the parent bus. >> >> We really want the former here, as I/O port addresses are not mapped into >> the MMIO space of the parent bus. > > Agree. However of_translate_one()'s behaviour doesn't match our expectations and I have no > useful suggestions on what the right behaviour should be. > I had tried to modify the drivers/of/address.c to address this problem, but it looks not so general. I'm not sure you have seen this: https://lkml.org/lkml/2016/1/10/89 . Regards, Rongrong