From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760001AbcBYIgr (ORCPT ); Thu, 25 Feb 2016 03:36:47 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:63839 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758272AbcBYIgo (ORCPT ); Thu, 25 Feb 2016 03:36:44 -0500 From: Arnd Bergmann To: Kishon Vijay Abraham I Cc: Paul Gortmaker , linux-kernel@vger.kernel.org, Bjorn Helgaas , devicetree@vger.kernel.org, Frank Rowand , Geert Uytterhoeven , Grant Likely , Ley Foon Tan , Murali Karicheri , Rob Herring , Russell King , Stanimir Varbanov , Thierry Reding , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 0/5] Modularize PCI_DW related drivers. Date: Thu, 25 Feb 2016 09:35:43 +0100 Message-ID: <2837386.VTD89bjPJz@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56CEB7BC.7010803@ti.com> References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com> <6350001.oOdGGcH81x@wuerfel> <56CEB7BC.7010803@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qoYvihfQM/FJECSaPxJHhNRwabH7pCep15u19DtcZe4t+VtRXiA pCLNyvSxM1LeXQXbKtJavLaLgGuEqCRBmd9YYpJV2ezmvsvY4fF4O4eDwEmIKhtwEdFheDK 0oDHBQhL7e5GNuqoDxSWr34uuDLG/z49UWXLvOThgAvzznDfKEFJM9rYZxlobGuwwfnvl8D NWUNxd9Hnh+p9PWerf2Cg== X-UI-Out-Filterresults: notjunk:1;V01:K0:FToH6K8fQys=:MA9iEghKiX6HX5xb+uCc38 MDxM3VJ/wtzaLsRlLCYoxsE9izDdU3nkl2JRr6h7inl0azJ61SqzvBouxGh0pbOKpbAVenBWF MDmyQmxhbRYB5k/ejgT7R2kaRrVD+vc//+potbhvALFfo/rSjQJV+nOIMKJ2QEvIvdo5nbgKU EdA78lqOP1J5EvhvxsKTJ1iEgHyG+Bw2M8yq3xzed0T1bnnrCVK2MKKx9JiLoz997gzUS1KsB ZGD4lXZ4bIhuJRqlVyNVdHDcwqVZb2Bq3E8X2LWWsTyTdEXqMgeDNxjT/lgj8XkQRD2YLd2uw SOOPgwBdl7lObPU61nTRSE6nhZIQtFOSnYvBLkkG/arrj71HwXSFjpgCgVWf4VI7FZKiDeAmi qbiGOdpgt3NFvd2nOY5uCz2+nZxxjbXunob8tc2Dft6k3khWwyizd9NJvdZdvG5uFbuNmmLnk fn5VBQ0MZf9E7UwDHbha+31H+yh2QXSlDsHReyQ0x0WUQp+1ghUoflqwQmhMYOEbYtSwSkxxX FCMJ7H/AtrOw37fpLkhNKH1bmF4ooECQVn6rWu+auRR8GbIAb+oU96ooWx7XQJWvy/jSaYN9N nBz1WuZ7aow8XWGgfvBs3PgvRzTW3ls+bTwwMRWfRiKbwctmnIUo2pLLEqJSrxVSQ4gXos13N NdBiH+khI8R414oG1m/5iQCFcSDbo9Ian6uBRdstFUFGw7GcVsOPr7EWSGYL4sKvPOEH+oKKn UGUBHYPd0S7p35b0dbMMV270VGGzhBOc1MsscIiB2gzQW6Sn2uRFPl4HB6iN89yNOvpLYV0eS KWYkVQwadf8zaAcIdPmSL+25143pkQQg5aaSfFFqRmV2EFLQu6cuAzLXtcQRHL6dnIIUDAB9w v5pCjHpoDvoFlFgkzhf+OAhtM6J6X80fP9THZT1q8= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 25 February 2016 13:43:48 Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Wednesday 24 February 2016 02:34 PM, Arnd Bergmann wrote: > > On Wednesday 24 February 2016 11:39:26 Kishon Vijay Abraham I wrote: > >> Hi, > >> > >> On Monday 08 February 2016 05:30 AM, Paul Gortmaker wrote: > >>> In a recent patch series that aimed to remove code related to module > >>> unload for PCI support that was simply non modular, the discussion > >>> led to people wanting to keep the code and push towards taking the > >>> steps needed to support moving it towards tristate instead[1]. > >>> > >>> Here, we take step one, which is simply making the Kconfig change > >>> and then dealing with any build fallout or modpost fallout. What > >>> amounts to essentially a sanity build test. To be clear, these > >>> have not been runtime validated; that will need to be done by those > >>> with access to real hardware. However, the changes are not anything > >>> that should disrupt any existing built-in validation, so real world > >>> users should not be impacted by this change. > >>> > >>> We start with a smaller family of drivers; those that actively select > >>> PCI_DW, as a nice self contained group to test the waters and see if > >>> everyone is still good with this approach before investing more time > >>> on a wider scale to other pci/host/ code blocks. > >>> > >>> As such the drivers here share a dependency on having the same group > >>> of functions exported in order to successfully complete modpost. > >>> > >>> In addition, we have to stray outside drivers/pci to add exports > >>> in two places; once for an ARM fault handler, and once for an OF > >>> variable. > >>> > >>> The pci-keystone-dw.c instance was handled separately because it > >>> consists of two source files that need their own group of driver > >>> specific exports above and beyond the "shared" ones. > >>> > >>> Then we convert the Kconfig for all remaining at once; we could have > >>> done it on a per driver basis for ease of revert if anyone really > >>> objects, but since it would be a one line change, that seemed like > >>> not a real concern. > >>> > >>> Build testing was done on the linux-next tree for arm allmodconfig. > >> > >> I took these patches and gave a test with DRA7xx board. As expected there was > >> no issues when the driver was built-in. However when I tried to rmmod/modprobe > >> I got this error [2]. > > > > Thanks for testing this! > > > >> [2] -> http://pastebin.ubuntu.com/15185894/ > > > > It looks like you are hitting the BUG_ON() in ioremap_pte_range() > > that checks if a virtual address already has a page table entry, > > which in turn is probably a result of dw_pcie_host_init() > > calling pci_remap_iospace() again for the same memory area > > it has called the last time, and no cleanup done inbetween. > > > > Could you try adding a pci_unmap_iospace() and calling that > > in the device remove function? Let me know if you need help > > implementing it. > > That didn't look straight forward to me :-( I'll try to see this next week. Any > help from you will make it simpler for me. I tried writing the function now, and I think it's actually quite easy: void pci_unmap_iospace(const struct resource *res) { #if defined(PCI_IOBASE) && defined(CONFIG_MMU) return iounmap(PCI_IOBASE + res->start); #endif } You just need to pass the same resource in here htat you pass into pci_remap_iospace(). Arnd