From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbdBAMat convert rfc822-to-8bit (ORCPT ); Wed, 1 Feb 2017 07:30:49 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:8560 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbdBAMar (ORCPT ); Wed, 1 Feb 2017 07:30:47 -0500 From: Gabriele Paoloni To: Alexander Graf , John Garry , Yuanzhichang , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "robh+dt@kernel.org" , "frowand.list@gmail.com" , "bhelgaas@google.com" , "rafael@kernel.org" , "mark.rutland@arm.com" , "brian.starkey@arm.com" , "olof@lixom.net" , "arnd@arndb.de" , "linux-arm-kernel@lists.infradead.org" CC: "lorenzo.pieralisi@arm.com" , "benh@kernel.crashing.org" , "linux-kernel@vger.kernel.org" , Linuxarm , "devicetree@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-serial@vger.kernel.org" , "minyard@acm.org" , "liviu.dudau@arm.com" , "zourongrong@gmail.com" , "zhichang.yuan02@gmail.com" , "kantyzc@163.com" , "xuwei (O)" Subject: RE: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced Thread-Topic: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced Thread-Index: AQHSdgvQJWG2f17QSU6NQQhMhFy3EKFRS/GAgAFU64CAAGX1AIABGjBw Date: Wed, 1 Feb 2017 12:29:39 +0000 Message-ID: References: <1485241525-201782-1-git-send-email-yuanzhichang@hisilicon.com> <1485241525-201782-2-git-send-email-yuanzhichang@hisilicon.com> <5dc0dc9c-124e-398f-a3b2-40059268e859@suse.de> <6d5523be-1841-18b9-9b83-6f7e591ed66b@huawei.com> <1a1f1e70-b6e7-f3c6-2b86-348b3d28edfe@suse.de> In-Reply-To: <1a1f1e70-b6e7-f3c6-2b86-348b3d28edfe@suse.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.181.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5891D4BF.0073,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2280b7aea1d21048a7b675fa983f48f8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex > -----Original Message----- > From: Alexander Graf [mailto:agraf@suse.de] [...] > >> > >> I like the extio idea. That allows us to handle all PIO requests on > >> platforms that don't have native PIO support via different routes > >> depending on the region they're in. Unfortunately we now we have 2 > >> frameworks for handling sparse PIO regions: One in extio, one in > PCI. > >> > >> Why don't we just merge the two? Most of the code that has #ifdef > >> PCI_IOBASE throughout the code base sounds like an ideal candidate > to > >> get migrated to extio instead. Then we only have a single framework > to > >> worry about ... > > > > To be clear, are you suggesting we merge the functionality from > > pci_register_io_range(), pci_pio_to_address(), pci_address_to_pio() > into > > extio, so extio manages all PIO? > > Yes, I guess so. > > > And having a single type of node to > > register PIO ranges, by amalgamating struct extio_node and io_range > (as > > Bjorn mentioned)? > > I'm not quite sure I follow you here. Basically I think you want a > generic "non-x86 PIO" framework that PCI just plugs into. > > I don't think that necessarily means you want to statically allocate > regions of that PIO space to separate (pseudo-)devices. Instead, > everyone shares that space and should be able to fail gracefully if > some > space is already occupied. > > > It would make sense. We would be somewhat decoupling PIO from PCI. > > Yes :). > > > I think that other architectures, like PPC, and other code would need > to > > be fixed up to handle this. > > I think only PPC, Microblaze and ARM are using this. Grep for > PCI_IOBASE. It's not that many. > > > We need to consider all the other challenges/obstacles to this. > > Well, getting our abstraction levels right to me sounds like it's worth > the obstacles. > I have had a quick look and I think it should not be too difficult to unify the two frameworks. I'll follow up soon on this thread with a code sketch Thanks Gab [...]