From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934162AbcIOIY3 (ORCPT ); Thu, 15 Sep 2016 04:24:29 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:60643 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934027AbcIOIXV (ORCPT ); Thu, 15 Sep 2016 04:23:21 -0400 From: Arnd Bergmann To: Gabriele Paoloni Cc: "linux-arm-kernel@lists.infradead.org" , Yuanzhichang , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "gregkh@linuxfoundation.org" , "benh@kernel.crashing.org" , John Garry , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "xuwei (O)" , Linuxarm , "linux-serial@vger.kernel.org" , "linux-pci@vger.kernel.org" , "zourongrong@gmail.com" , "liviu.dudau@arm.com" , "kantyzc@163.com" , "zhichang.yuan02@gmail.com" Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 Date: Thu, 15 Sep 2016 10:22:23 +0200 Message-ID: <8360154.kzsE8V8pTW@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <5869118.UilSPY9Sai@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qnkYKU1hRqydU41y0DXtYf5VfDT/+x4LhzPSSh5rauHwZ14sdM/ sipamelEWGy4iSN1uHGgOjqBfdZZNy89qsUPsnhXhmRUDeL+wmcakhZs3CwSqADASFxgc5p Tt5h06wEmOYQmGccQJYKXWErIckudaWgh7W0sHWgux73wYWaHI9EyYq0tbqA3hrZ9CXTodf AN/CgoQCvhfLczkbfP9QA== X-UI-Out-Filterresults: notjunk:1;V01:K0:aWy9Qrrq07o=:m7QakEZ38NCH/YXiabW4uR p3K6aPMRbQI58SNobA7ze827DETzdbsz5gb7hPGpJAirVJZsr1Ez3EMCIAS3WoiWQK5GgQWFx NNxpdAXCWy5csP4U9gF9IBeqxFQmmJUh1P5J4p/pPxBVrO9+jZfgDcChvqJcKGVhTu/3n6Yq6 KT3s7b3csOru+NUSe7paSFT9KH5dwjO/3lieJ8G+lypaLvH6VCNPpjqaL1qScKkfi9eGZEXQe QSQ/wR+tXoY6pLSIah3jDcE8FK1vTx3jirpxFRX5dpJ4+gsZ8B0ACRt2vzuz4WwwpyZL5R4+s DS2LEQTQ8pGo9S6/8swCVJL2Bs2QGSdiLZJztbxoDvobDJX7eh0xsJlmTFRjzeOtCdgfAExMi VZhf3IWQl02drkPGqC8ZQjozPStci4FdWVM97Nr5dSBbGvbSGceioGULDsCA+Uo1FpVYxFyzc 4wwkt08Axpve/0IQ+Bwt0yCe+YCWlv/P0iYdqY442JHn/1oPlmQYkgU9v5skEqTx22WaMEOpj LkDeqmzPhDlXWSs6b6TKk0GKaBJGi3CjQoch5BcAAe3o73ogTLweE+xEJaZxOW17XAKEoPeCC SEk98Fex4LTAT5BKh02w66CKkPzSpfp9za3dV+VQfbs6d4aYHDGE25S9lQ2DvEAb1Ra7obeTw LVkrUSlqe5SZ4coKYw8MxSQEwGDlL5pQRk1KLxQus/WwQlar2lxgXBmc0igW4iZqE76q0aECO d8R05TAW9O7BxXxM Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni wrote: > > From <<3.1.1. Open Firmware Properties for Bus Nodes>> in > http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > I quote: > "There shall be an entry in the "ranges" property for each > of the Memory and/or I/O spaces if that address space is > mapped through the bridge." > > It seems to me that it is ok to have 1:1 address mapping and that > therefore of_translate_address() should fail if "ranges" is not > present. The key here is the definition of "mapped through the bridge". I can only understand this as "directly mapped", i.e. an I/O port of the child bus corresponds directly to a memory address on the parent bus, but this is not the case here. The problem with adding the mapping here is that it looks like it should be valid to create a page table entry for the address returned from the translation and access it through a pointer dereference, but that is clearly not possible. > This is also explained quite well in > http://lxr.free-electrons.com/source/drivers/of/address.c#L490 > > what do you think? This is a separate issue, and only relevant for Apple Macintosh machines as well as the PA-Semi sdc. Arnd