From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936503AbcIWJwq (ORCPT ); Fri, 23 Sep 2016 05:52:46 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:49488 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932636AbcIWJwn (ORCPT ); Fri, 23 Sep 2016 05:52:43 -0400 From: Arnd Bergmann 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 Date: Fri, 23 Sep 2016 11:51:49 +0200 Message-ID: <1760643.vMTR5o5E9g@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <57E40665.8080005@gmail.com> References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:RFSn/y79+r3Dpy3cVTZPmtd5pJ6RZJldVs+RKmhuo5xv6BgGvWX DJs60oR0ynuLBdeESVwOtPoiJK+1p82ekJ0gjXgSeufaxDCezimhcm+MrOkC69Et+LHa7A1 FKxaNoTnshO4tGrk8bBxwYB0u2Ja6S/BPjuQKwfjb230rdvp27XcK/uE4o+N3HexsX9bgb2 BSYwJ6IYqM/d7WaINNytg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bHMh9z4ACwA=:JKIUzwzwXzFNUNAn8T3glu qdJXz7aJFwLJ7ZkcueKDM9AiVEJj/ZCwyIKFUDjZCtHa4Fpj8ea8Ni7oWK1dsrnq/V2y/u7cm W3sXnnfaFZA7Wzbv/XnNFnmmqVRYv1oSgtDYzfboN98e26rqzBR0tWMlnrR5LMgLcWjymkqel o8gFod9LV71d+Yp1SjYN0KZCtin+fp3R1e/TTX63GP+46Pb7tk1rRl2NAiz8cAYzFClBl2bpm V7XCDG1VxkstQIX7InArIflTTojPEyok2IqwB3Js58FLlEYkj0wF98NgCYyukZWbtL4IpnCVx EBxya0eZ9FYRyarjxJGOOXkzmzWXS7Hu70qYiIpoxxY//EH+Quh20l+EhwumTrkIXo+QoiGxj vLdjcfOIBZW+A5x9ALAnID+I5thXDDOKhLtvnLOv85oFskEXoyyDoVO2O7FWtalBLKbEumSYW YQ6TdKv3noUqRm+fYmjr53ArGUkvJq2C1/5iwImFk9PZBQHHJK1D8p2AcaK3Ki7++9gjS8CwU 429YbqyIdPhbwCFWrpNEyvjYgpjQr2uSxsPTAtFk3s/tRC1ecCCxlarJuRvPJwyVp4oryR9S7 0XgOgjSEQdEqJHATNWkGU+Je5m879vjfNvM0ipFPlfiBRDGEOYvjynqiQahL5i62n+Nrt9TgM zlPzzjLLqeFHlO3/fq8JKCsm/UX1gY8B1tyy1u+DjCebwNDmqptT0cF79wiBFEggFCVUT5t1L I9UHWZVzopm/JmQ7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > If we don't, it seems the LPC specific IO address will conflict with PCI > host bridges' logical IO. > > Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is > normal for ISA similar > devices), after arch_of_address_to_pio(), the r->start will be set as > 0x100, r->end will be set as > 0x3FF. And if there is one PCI host bridge who request a IO window size > over 0x400 at the same > time, the corresponding r->start and r->end will be set as 0x0, 0x3FF > after of_address_to_resource > for this host bridge. Then the IO conflict happens. You would still need to reserve some space in the io_range_list to avoid possible conflicts, which is a bit ugly with the current definition of pci_register_io_range, but I'm sure can be done. One way I can think of would be to change pci_register_io_range() to just return the logical port number directly (it already knows it!), and pass an invalid physical address (e.g. #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for invalid translations. Another alternative that just occurred to me would be to move the pci_address_to_pio() call from __of_address_to_resource() into of_bus_pci_translate() and then do the special handling for the ISA/LPC bus in of_bus_isa_translate(). Arnd