From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754569AbcFGIol (ORCPT ); Tue, 7 Jun 2016 04:44:41 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:58187 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753547AbcFGIoh (ORCPT ); Tue, 7 Jun 2016 04:44:37 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, Thomas Petazzoni , Jason Cooper , Scott Branden , Jon Mason , Jingoo Han , Pratyush Anand , linux-kernel@vger.kernel.org, rfi@lists.rocketboards.org, linux-renesas-soc@vger.kernel.org, Simon Horman , Thierry Reding , Tanmay Inamdar , Ray Jui , linux-tegra@vger.kernel.org, Ley Foon Tan , Michal Simek , =?ISO-8859-1?Q?S=F6ren?= Brinkmann Subject: Re: [PATCH v1 00/25] PCI: Request host bridge window resources Date: Tue, 07 Jun 2016 10:21:36 +0200 Message-ID: <3416214.BpvATlfaN7@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160606225630.20936.77349.stgit@bhelgaas-glaptop2.roam.corp.google.com> References: <20160606225630.20936.77349.stgit@bhelgaas-glaptop2.roam.corp.google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:HC/kfPUHqV2a02/se2zlEuCr8UyS64lxIsFgnjG5V1PYD/bACzr pkDP3e/GeIFxTfdF3jF0Ab5Kq7Fysd4kwcvUsvQNyaQdHWSL/gRW9k1Y7I1H904mTxdX/5t x8KMS88r1Wrua+9mtbzPHJG2lyP8tF41h2AT8SuUfWvNryPZcZ9FLZbgXgaVXRieO/f5lQD gpHMFfTa0bYNJ4oSezoJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PgNUhtFOeDU=:PP1G1I9OyoDMbbDb4VX94m nIGcgTOswj9p+9yLhkJhuU1pQk87yj4BWGshGPVoNzwNA30gTnxWEJwQxaMcwlCnlfndgf0no CsxIRjgDVHCjWNJdjzerFD8ehd+zWBUlmH94yWs7Xyc31nm5ure6EBpa/5Adxj5OEGxBCBi4d YG+hz7kb9Ul5UIBligAM1ADi3SrB4VxJd7QnfmV74nQT8PJMkNiEj7Vf0lo4AsaUPJ4ZjUYXi j3CAPE6N7zg32bkLn8TQTbJ86SLLcjKNIut/VSWMiVDpdZaMoFH4zttAMAfR4Oq63B+xbYYGA 36cccO0Rkxucqz2JF9hjrvtAKmwWLLgFG76IXOhGpD+xHdEYbX9MOaoc4swnQ8Fbe5BQxe592 aQEj8mkDibX7gnG4bW8ww/dA6j9miUUz8MVBEXEwcQnvk6pj7nFbewweR3zwxvJyyXELx54cv kKkpM12ZfSp2xS9zRP4bCXXUH/kIwofbhrX/U7JcLWNWhYctcO1uRI9ShfsUylQ380WSiP4dj iB3rn381c8EhvkYndeGuPrnUbP4G05tsCekJS3IBKU++JTv+lX6Q6Yw+EsccrZjC99ExKvgFS lM4AMnutVj6FOjTQurM1WRg3L4MrfLCYLaZodr3MwyKCgdEHgjAvN+ysaXP8O9IufSG49zF/E uJb2Ck6Y1EunLEs/4bASMGqqOzaBAz4/4jXC8wO4WUhkTEcM462YtEtW4yNQvPY+ONtpSv0Ps lZBZOFtn7Jc4XwwO Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote: > Several host bridge drivers (designware and all derivatives, iproc, > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port > windows they forward downstream to the PCI bus. > > That means the PCI core can't request resources for PCI bridge > windows and PCI BARs. > > Several other drivers (altera, generic, mvebu, rcar, tegra) do request > the windows, but use some duplicated code to do it. > > This adds a new devm_request_pci_bus_resources() interface and changes > these drivers to use it. It also fixes several error paths where we failed > to free the resource list allocated by of_pci_get_host_bridge_resources(). > > Tegra guys, please take a look at "PCI: tegra: Remove top-level resource > from hierarchy" in particular. Removing the top-level resource definitely > makes /proc/iomem look uglier (although it will look more like that of > other drivers). A short-term fix could be to include device information in > the resource name. I think a better long-term fix would be to make the DT > or platform device core request all the resources from the DT. > > Comments welcome. I expect we'll trip over something here, so I marked > this "v1" and I don't plan to put it into -next for a while. > > This is on my pci/host-request-windows branch, which you can pull or view > at https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows This looks very nice. There is one related aspect that I have been grumbling about for a while, but I don't know what the driver is actually supposed to do there: For the IORESOURCE_IO resources, some drivers request the MMIO address that the window is mapped into, some drivers request the PIO range, and some of them request both. I also believe the resource that gets put into the bridge resources list is not always the same one (or maybe that got fixed by now). What do you think is the correct behavior here, should the driver only request the PIO range with parent=ioport_resource, or should it also request the MMIO window for the I/O ports with parent=iomem_resource? In the latter case, any idea how that can be generalized? Another aspect is that we already have the gen_pci_parse_request_of_pci_ranges() function that does the same as your new devm_request_pci_bus_resources() and then a few other things. I have been wondering whether we could move that function into common code convert drivers to use that wherever possible, but I guess we can always do that as a follow-up after this series. Arnd