From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034482AbcIWNnr (ORCPT ); Fri, 23 Sep 2016 09:43:47 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:56285 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030211AbcIWNnm (ORCPT ); Fri, 23 Sep 2016 09:43:42 -0400 From: Arnd Bergmann To: Gabriele Paoloni Cc: "zhichang.yuan" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "linux-pci@vger.kernel.org" , "gregkh@linuxfoundation.org" , John Garry , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , Yuanzhichang , Linuxarm , "xuwei (O)" , "linux-serial@vger.kernel.org" , "benh@kernel.crashing.org" , "zourongrong@gmail.com" , "liviu.dudau@arm.com" , "kantyzc@163.com" Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 Date: Fri, 23 Sep 2016 15:42:39 +0200 Message-ID: <10705430.q2aqv5uYO3@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> <1760643.vMTR5o5E9g@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:olzqMSQjxDI7NmnIICSkKKEDEl0ZXKjjWa+iwPdfc0EqcdtcpLg 745Vmg7QV+21zMa4TWwPpZVj6J68pQKwWY5SO15AOZ4Cee9BBPRhsbUzK/+LV0NWiNmwsbo GlMsPnnyQh1ZkKHCn43lasmbkuzEKypUo08ltgn6I5/nwJ+E3T5Ens70cUACak9eM5/ayc/ CwWpFEMM/DoJ0D9sObxAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:AfD2LZEscZA=:M0pv+NJ04Dnabt4cA2pKkt i4/anO7xhx6pdUjJSGcIlniACHq2uELqVfkuqzrCs8hvDUj9Dt9aHregOU5Wg4hRDILSCumnR ycmu7OQZuR+aL2oz4K8NXDyC1bZzTCNIhY1/r31RxdUT2VO91GSj6o8VnzkCMWK+p0H0w0cma 14Ul/TAh0Tflq4x7tl7SGOWP8EGbvqmQyA4Qj98MZhqqgASY+eXYgEiuKqNSUmNmcGrusOYbr +B/IKZu1HP9xE8QIh4vKy1hd3eS9iJCU6/WMw3gDdhuQNauWP/SGXq7dhMcH2NGgtv/7V7Qp8 QbEFtzVV8PGxjyU3vUQd+UizYhMORsc21Hfr4llA6TIWihhKiBEx3Sc+3xzWJwDYnRX1K3Kqr CQf0Hc56L8KoqwvvFsGAs2SwZZ/l0PrkIYVBG7VSMLx/wRZ+cLzbGQLvJ6+Aik2hLzqL2seq0 9u5PbRngpC8AM7w7u+rg9smqNdzzbZJU0pLUiZLjaeKuYDz55j/CGcilpqJcy7oy7vhWTOMe9 OO/Tq3M8BCMDmRnEKXg13s1brDB3dZ4/7ak1dSwQBuose6XHGgw28X3974m2eOXYnHweOwdII NTIKr6QP/C8VfanW/1dvzB14ofeqp39adbkDpzoAXsG9gF1VpdUNhfj2Nz1moipJScMU0NoGI KUGeVDO91IqgYGQbIihBZDeG/TQ/oH29FyyU1iNiEJWwvSEkJF2cnPxDJg4U+mmKItPohLeua KUeIkU1k3esRoM/5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 23, 2016 10:23:30 AM CEST Gabriele Paoloni wrote: > Hi Arnd > > > -----Original Message----- > > From: Arnd Bergmann [mailto:arnd@arndb.de] > > Sent: 23 September 2016 10:52 > > To: zhichang.yuan > > Cc: Gabriele Paoloni; linux-arm-kernel@lists.infradead.org; > > devicetree@vger.kernel.org; lorenzo.pieralisi@arm.com; minyard@acm.org; > > linux-pci@vger.kernel.org; gregkh@linuxfoundation.org; John Garry; > > will.deacon@arm.com; linux-kernel@vger.kernel.org; Yuanzhichang; > > Linuxarm; xuwei (O); linux-serial@vger.kernel.org; > > benh@kernel.crashing.org; zourongrong@gmail.com; liviu.dudau@arm.com; > > kantyzc@163.com > > Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on > > Hip06 > > > > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote: > > > For this patch sketch, I have a question. > > > Do we call pci_address_to_pio in arch_of_address_to_pio to get the > > > corresponding logical IO port > > > for LPC?? > > > > > > No, of course not, that would be silly: > > > > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't > > have one because there is no address associated with your PIO, that > > is the entire point of your driver! > > > > Also, we already know the mapping because this is what the inb/outb > > workaround is looking at, so there is absolutely no reason to call it > > either. > > Ok assume that we do not call pci_address_to_pio() for the ISA bus... > The LPC driver will register its phys address range in io_range_list, > then the IPMI driver probe will retrieve its physical address calling > of_address_to_resource and will use the indirect io to access this > address. > > From the perspective of the indirect IO function the input parameter > is an unsigned long addr that (now) can be either: > 1) an IO token coming from a legacy pci device > 2) a phys address that lives on the LPC bus > > These are conceptually two separate address spaces (and actually they > both start from 0). Why? Any IORESOURCE_IO address always refers to the logical I/O port range in Linux, not the physical address that is used on a bus. > If the input parameter can live on different address spaces that are > overlapped, even if I save the used LPC range in arm64_extio_ops->start/end > there is no way for the indirect IO to tell if the input parameter is > an I/O token or a phys address that belongs to LPC... The start address is the offset: if you get an address between 'start' and 'end', you subtract the 'start' from it, and use that to call the registered driver function. That works because we can safely assume that the bus address range that the LPC driver registers starts zero. Arnd