From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751805AbcEKLCY (ORCPT ); Wed, 11 May 2016 07:02:24 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:58625 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751324AbcEKLCW (ORCPT ); Wed, 11 May 2016 07:02:22 -0400 From: Arnd Bergmann To: Tomasz Nowicki Cc: "Rafael J. Wysocki" , Bjorn Helgaas , Will Deacon , Catalin Marinas , Hanjun Guo , Lorenzo Pieralisi , Sinan Kaya , jchandra@broadcom.com, robert.richter@caviumnetworks.com, mw@semihalf.com, Liviu.Dudau@arm.com, David Daney , wangyijing@huawei.com, Suravee Suthikulanit , Mark Salter , Linux PCI , "linux-arm-kernel@lists.infradead.org" , ACPI Devel Maling List , Linux Kernel Mailing List , "linaro-acpi@lists.linaro.org" , Jon Masters , andrea.gallo@linaro.org, dhdang@apm.com, jeremy.linton@arm.com, liudongdong3@huawei.com, Christopher Covington Subject: Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code. Date: Wed, 11 May 2016 13:01:18 +0200 Message-ID: <4722186.M8gaIx9LyT@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5732E11A.9090002@semihalf.com> References: <1462893601-8937-1-git-send-email-tn@semihalf.com> <5732E11A.9090002@semihalf.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:pQF8rqNjmStIRdNib2r6W46UcT5v/JkjVBAeq1Zyxe/24tmUz3+ 29ecwfmvx+l80EoVB16zQpl9d2xTr7a8UAO6m/OhNy4lqkDtxc5sjXSYHgPmbRW918xmPub C8Wluiq1nfxBOFkcd5bgClDlZojsLmI2uSiIxhjNHEiC2m7YY7kCu75nJiEcr26ZYpKjzWS aKWQHeLO0hCy76OW2rXUQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:79jn08P3QyY=:CQxRZd/UNhfR2E0Cafxcni kpVtabvh4zbHJL72SbaaAdzm+nQJZoKgjLO4Gce954U0ZKW03BDPQ33exJQerAHlo2YLC1nnP BJ0eY2nwxqF7DVTjvQLv8UHjqfv6ZFpPsLu+N5qf2FyHBIwNXEFtnJ0/zVKj+V0QFMXd0Sdgb 4cnoTPfahtHVOvf0gGOmOZAlqLfLiqfbbZUV0IqDtrTGQdFDRr+/7ItH4zWrUDHH10AAUnB5g G+pX6gUbPJtRw51M69MaioNGn8ttlsDWcFTTuh4nJasX6xHhj7cs1IuqBeDdGOSSk4FknN80F iLnDbzEq6CrpqMSrMrRzkVpGkDm8sMZ9/gFlemHzDaSU0yEOSlpQOhKMHX6HcMSTlIsMo25Q7 u1f/fAdN7B6bdhqh8UxV+LBCaALCorS6QK1yHAeA7XEVCN5rYJDbZjVt9URhD42+EMCnqISHi /EzCKP+/KVy7VhneMlAsLIQecFHr+8iuwZVo4Imu6DRHhioc7NzNkV1kabWDAtzYpP5dY2vpW Kzf1mXTuaTn48wFiTUa9o05GZOAvF4kfa92bi+zJ8w1bRNJ5kY3yB3vrCbNEcafmSbZ0ZkMCH 5meSMIeRprTsJO6/Dr5/k/kVGR8c7zZBF8LYd8rdDE2E+hT7vsOc94OjwgJcOVkuhgORYxNSq ShXe8RB8w7BuvJC4/xpAkT68No7NRdRhM0+DCpo/9Ibt1NLQK6Vha31amNwRLn/4McXERWcVi nqtE/oUX0wkG596W Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 11 May 2016 09:36:58 Tomasz Nowicki wrote: > > > > I understand that this moves code around, but those in-function > > #ifdefs aren't nice. Any chance to get rid of them but putting whole > > functions under the #ifdef? > > > > This is a __weak implementation, so assuming I would move #ifdef out of > function I need to provide another empty __weak stub. I do not know > which solution is more ugly. In any case we can do that cleanup separately. > I'd vote for just dropping the __weak here, given that there is no non-weak implementation. If we end up needing to override this for some architecture or host bridge in the future, we can think about how to best do that then. I agree that should be a separate patch, this one should only move code from one file to another. Arnd