From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de ([212.227.126.130]:50318 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750824AbbASQ7a (ORCPT ); Mon, 19 Jan 2015 11:59:30 -0500 From: Arnd Bergmann To: Rob Herring Cc: Lorenzo Pieralisi , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , Liviu Dudau , Mohit Kumar , Jingoo Han , Bjorn Helgaas , Rob Herring Subject: Re: [RFC PATCH 0/3] drivers: port PCIe designware to new DT parsing API Date: Mon, 19 Jan 2015 17:59 +0100 Message-ID: <1539153.bO1tVUM2dB@wuerfel> In-Reply-To: References: <1420644571-18928-1-git-send-email-lorenzo.pieralisi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: linux-pci-owner@vger.kernel.org List-ID: On Monday 19 January 2015 10:40:39 Rob Herring wrote: > > I don't really like exposing ranges to host drivers. We've worked to > not do that. So perhaps we need to rethink the API. I think we need to > provide each range as a pair of resources which are the CPU address > and PCI address. Perhaps an iterator is kind of pointless here. We do > different things for each one. Are there cases with more than a single > i/o space, non-prefetch memory and prefetch memory range? Perhaps we > should just get the i/o and memory resources as separate calls. Just > tossing out some ideas here. Nice idea, that could be similar to platform_get_resource(). We probably also need the distinction between CPU address and (parent) bus address here. In most drivers they are the same, but we actually need to program the latter one into the PCI host bridge registers. Arnd