From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753124AbbJNJpu (ORCPT ); Wed, 14 Oct 2015 05:45:50 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:54561 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751804AbbJNJpr (ORCPT ); Wed, 14 Oct 2015 05:45:47 -0400 From: Arnd Bergmann To: Gabriele Paoloni Cc: "Wangzhou (B)" , Bjorn Helgaas , Bjorn Helgaas , "jingoohan1@gmail.com" , "pratyush.anand@gmail.com" , "linux@arm.linux.org.uk" , "thomas.petazzoni@free-electrons.com" , "lorenzo.pieralisi@arm.com" , "james.morse@arm.com" , "Liviu.Dudau@arm.com" , "jason@lakedaemon.net" , "robh@kernel.org" , "gabriel.fernandez@linaro.org" , "Minghuan.Lian@freescale.com" , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , zhangjukuo , qiuzhenfa , "liudongdong (C)" , qiujiang , "xuwei (O)" , "Liguozhu (Kenneth)" , "Wangkefeng (Kevin)" , Rob Herring Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05 Date: Wed, 14 Oct 2015 11:42:27 +0200 Message-ID: <5959363.QRL4hSioHL@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1444445957-239522-1-git-send-email-wangzhou1@hisilicon.com> <7409042.iUdOP6FlU8@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:JXPbUR3YMW7BpdPPAulx1Q3sf01VuX97K9KY6praUYZiWTNVFgz vBMaCAR30abNfURT0E3nucDKpEc2g7DdgNLz9t4U0U3oYmItIvNoi7waP4ZI0IEpq7SK/7W 1t6BWAn2QB9xPfjBwWGz/6+yp6cPR3JVvq6W0TCd41L7iYLnb/befNbxgsa2jTsnhDbiQ3W lOjoQOKG4lKF6SHotTnaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XRH3HdQcOTk=:ztNzBqeMubv2C/f/dmbWhH kR8enoP6UxFFFLqfBSRWKCMvLdUJfDogPDhgQJi0zInTX3SEgyvT7vZ4SLokTxPq+9WH6JT1/ V7G4zYmjqIUmZ9hXDJtxX1l4e1HdUvm8zC8Zlp+nFKZFpA2L4mK0CjAETHiVhX+zoAv5nUZT2 YQYudnZ9Kc1c7tume0H+ls4RzbfTNGliI8V+sY9wh6wva+7+pg58hlVxkG4nRY5bG32iwpPcF iok2kS0RGX4p7tBr1oHAw8bohWNgZbD3+pejSgrgnDtvQOMw/Ah0lrH4fgvRyjmP05CvYkK3L 6OdPEjWB5kRoBBePiuwbpvRg0Cs1Sz6mM7/EtspKnLOWkUnAZEFmJq6b3W7YxFeVmNxtMznxb nIzs8vkUJMqEdpKtlTQsKkB/E2Yo3PX6oKPCObaRWORdfzsaJzGoulAZYOwoMaJ8WZx5oDIFv oOM6B+Yu1kLER2eQq39VSgneZ4K5wHrkhXpp1gYNKBdSjZsU+Qp1iMEFGr3Pv6BoDBHn/DI11 +UlvSmtg4u9KwpaNd6/+l/PPFx34gcduf+QPzZiRyPPRYbmxXBJ/kTobP7mVzzI1dV3NTJDmR K57X3DUVLy/vLMh68xJzbUU4eugmlnj65P4lIYVdf/gbJ4HsKUWybO9nkWAlWx7I65ICv2dKt NzRhLL3rM+1WTiTT7OiTqfM/NODGUvwTqrfvTbU+4DTLnNPBz3RCCtw6e0UVB2WSBx+vLrNLJ M0Li/GXtMbE3Mimt Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 14 October 2015 09:31:48 Gabriele Paoloni wrote: > > > > > To me it sounds more appropriate to adopt subsys_initcall() for all > > the > > > PCI Host Bridge controllers rather than having them as loadable > > modules... > > > > > > What is your view? > > > > subsys_initcall() sounds odd because it's a driver rather than a > > subsystem, > > but I realize that most of the other levels don't fit any better. > > Yes well I was seeing for example the vgaarb > http://lxr.free-electrons.com/source/drivers/gpu/vga/vgaarb.c#L1357 > > That in the init is calling pci_get_subsys() > > So I was wondering that the PCI devices may not be registered unless > we also init the PCI host bridge through subsys_initcall()... I think this should work as is: the code first looks for devices that are already there and then registers a notifier for devices that show up later. This is meant to work for both devices that are hotplugged at a later point as well as PCI buses that are already there but not yet probed. > But then maybe is the vgaarb to be buggy... Possible. It may well be that the code is only tested on x86, which always probes its PCI very early. > > As I said, it's not really a choice we have to make in the source code, > > we can use subsys_initcall together with module_exit(), or we can > > create a helper macro that is similar to module_platform_driver() > > specifically for PCI that uses a particular initcall level. > > Ok got it. But I guess this needs to be thought and applied to all > the PCI host bridge controllers... > > So maybe for this driver I can use module_platform_driver_probe() > and then we can see... Sounds good. Let's focus on getting the driver merged first and then follow up with a patch to get this right for all PCI hosts. Arnd