From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755305AbbCRIvS (ORCPT ); Wed, 18 Mar 2015 04:51:18 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:45431 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755035AbbCRIvL (ORCPT ); Wed, 18 Mar 2015 04:51:11 -0400 Message-ID: <55093C12.7070004@st.com> Date: Wed, 18 Mar 2015 09:49:22 +0100 From: Fabrice Gasnier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Bolle , Gabriel FERNANDEZ CC: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Srinivas Kandagatla , Maxime Coquelin , Patrice Chotard , Russell King , Bjorn Helgaas , Mohit Kumar , Jingoo Han , Lucas Stach , Kishon Vijay Abraham I , Andrew Morton , "David S. Miller" , Greg KH , Mauro Carvalho Chehab , Joe Perches , Tejun Heo , Arnd Bergmann , Viresh Kumar , Thierry Reding , Phil Edworthy , Minghuan Lian , Tanmay Inamdar , , Sachin Kamat , Andrew Lunn , Liviu Dudau , , , , , , Lee Jones , Gabriel Fernandez Subject: Re: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller References: <1426515635-9466-1-git-send-email-gabriel.fernandez@linaro.org> <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> <1426518695.26437.55.camel@x220> In-Reply-To: <1426518695.26437.55.camel@x220> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.48.254.206] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-18_03:2015-03-17,2015-03-18,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, On 03/16/2015 04:11 PM, Paul Bolle wrote: >> +config PCI_ST >> + bool "ST PCIe controller" > You add a bool Kconfig symbol. A week or two ago I saw some patches fly > by that - I think - allowed PCIe controllers to be built modular. Thanks for your review. Are you talking about "PCI: Export symbols of PCI functions" patch, that is part of a series named "pci: iproc: Add Broadcom iProc PCIe support" ? This controller doesn't look like to be based on pcie-designware core driver. Other vendors that are using "pcie-designware" core driver are also make it bool. The current core driver doesn't support module loading/unloading as I see it. If this is required, I also think this should be part of another patchset. What do you think ? Please advise, BR, Fabrice > >> + depends on ARCH_STI || (ARM && COMPILE_TEST) >> + select PCIE_DW >> + help >> + Enable PCIe controller support on ST Socs. This controller is based >> + on Designware hardware and therefore the driver re-uses the >> + Designware core functions to implement the driver. >> --- a/drivers/pci/host/Makefile >> +++ b/drivers/pci/host/Makefile >> +obj-$(CONFIG_PCI_ST) += pci-st.o > If you keep that symbol bool this objectfile will never be part of a > module. > >> diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c >> new file mode 100644 >> index 0000000..470000d >> --- /dev/null >> +++ b/drivers/pci/host/pci-st.c >> +#include > For built-in code this include is, probably, not needed. > >> +MODULE_DEVICE_TABLE(of, st_pcie_of_match); > For built-in code that macro will always be preprocessed away. > >> +/* ST PCIe driver does not allow module unload */ >> +static int __init pcie_init(void) >> +{ >> + return platform_driver_probe(&st_pcie_driver, st_pcie_probe); >> +} >> +device_initcall(pcie_init); > I think the module unload comment is a bit odd for built-in only code. > >> +MODULE_AUTHOR("Fabrice Gasnier "); >> +MODULE_DESCRIPTION("PCI express Driver for ST SoCs"); >> +MODULE_LICENSE("GPL v2"); > These three macros will be, basically, always preprocessed away as long > as this code can't be built to be modular. > > > Paul Bolle > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabrice Gasnier Subject: Re: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller Date: Wed, 18 Mar 2015 09:49:22 +0100 Message-ID: <55093C12.7070004@st.com> References: <1426515635-9466-1-git-send-email-gabriel.fernandez@linaro.org> <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> <1426518695.26437.55.camel@x220> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1426518695.26437.55.camel@x220> Sender: linux-pci-owner@vger.kernel.org To: Paul Bolle , Gabriel FERNANDEZ Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Srinivas Kandagatla , Maxime Coquelin , Patrice Chotard , Russell King , Bjorn Helgaas , Mohit Kumar , Jingoo Han , Lucas Stach , Kishon Vijay Abraham I , Andrew Morton , "David S. Miller" , Greg KH , Mauro Carvalho Chehab , Joe Perches , Tejun Heo , Arnd Bergmann , Viresh Kumar , Thierry Reding List-Id: devicetree@vger.kernel.org Hi Paul, On 03/16/2015 04:11 PM, Paul Bolle wrote: >> +config PCI_ST >> + bool "ST PCIe controller" > You add a bool Kconfig symbol. A week or two ago I saw some patches fly > by that - I think - allowed PCIe controllers to be built modular. Thanks for your review. Are you talking about "PCI: Export symbols of PCI functions" patch, that is part of a series named "pci: iproc: Add Broadcom iProc PCIe support" ? This controller doesn't look like to be based on pcie-designware core driver. Other vendors that are using "pcie-designware" core driver are also make it bool. The current core driver doesn't support module loading/unloading as I see it. If this is required, I also think this should be part of another patchset. What do you think ? Please advise, BR, Fabrice > >> + depends on ARCH_STI || (ARM && COMPILE_TEST) >> + select PCIE_DW >> + help >> + Enable PCIe controller support on ST Socs. This controller is based >> + on Designware hardware and therefore the driver re-uses the >> + Designware core functions to implement the driver. >> --- a/drivers/pci/host/Makefile >> +++ b/drivers/pci/host/Makefile >> +obj-$(CONFIG_PCI_ST) += pci-st.o > If you keep that symbol bool this objectfile will never be part of a > module. > >> diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c >> new file mode 100644 >> index 0000000..470000d >> --- /dev/null >> +++ b/drivers/pci/host/pci-st.c >> +#include > For built-in code this include is, probably, not needed. > >> +MODULE_DEVICE_TABLE(of, st_pcie_of_match); > For built-in code that macro will always be preprocessed away. > >> +/* ST PCIe driver does not allow module unload */ >> +static int __init pcie_init(void) >> +{ >> + return platform_driver_probe(&st_pcie_driver, st_pcie_probe); >> +} >> +device_initcall(pcie_init); > I think the module unload comment is a bit odd for built-in only code. > >> +MODULE_AUTHOR("Fabrice Gasnier "); >> +MODULE_DESCRIPTION("PCI express Driver for ST SoCs"); >> +MODULE_LICENSE("GPL v2"); > These three macros will be, basically, always preprocessed away as long > as this code can't be built to be modular. > > > Paul Bolle > From mboxrd@z Thu Jan 1 00:00:00 1970 From: fabrice.gasnier@st.com (Fabrice Gasnier) Date: Wed, 18 Mar 2015 09:49:22 +0100 Subject: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller In-Reply-To: <1426518695.26437.55.camel@x220> References: <1426515635-9466-1-git-send-email-gabriel.fernandez@linaro.org> <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> <1426518695.26437.55.camel@x220> Message-ID: <55093C12.7070004@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Paul, On 03/16/2015 04:11 PM, Paul Bolle wrote: >> +config PCI_ST >> + bool "ST PCIe controller" > You add a bool Kconfig symbol. A week or two ago I saw some patches fly > by that - I think - allowed PCIe controllers to be built modular. Thanks for your review. Are you talking about "PCI: Export symbols of PCI functions" patch, that is part of a series named "pci: iproc: Add Broadcom iProc PCIe support" ? This controller doesn't look like to be based on pcie-designware core driver. Other vendors that are using "pcie-designware" core driver are also make it bool. The current core driver doesn't support module loading/unloading as I see it. If this is required, I also think this should be part of another patchset. What do you think ? Please advise, BR, Fabrice > >> + depends on ARCH_STI || (ARM && COMPILE_TEST) >> + select PCIE_DW >> + help >> + Enable PCIe controller support on ST Socs. This controller is based >> + on Designware hardware and therefore the driver re-uses the >> + Designware core functions to implement the driver. >> --- a/drivers/pci/host/Makefile >> +++ b/drivers/pci/host/Makefile >> +obj-$(CONFIG_PCI_ST) += pci-st.o > If you keep that symbol bool this objectfile will never be part of a > module. > >> diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c >> new file mode 100644 >> index 0000000..470000d >> --- /dev/null >> +++ b/drivers/pci/host/pci-st.c >> +#include > For built-in code this include is, probably, not needed. > >> +MODULE_DEVICE_TABLE(of, st_pcie_of_match); > For built-in code that macro will always be preprocessed away. > >> +/* ST PCIe driver does not allow module unload */ >> +static int __init pcie_init(void) >> +{ >> + return platform_driver_probe(&st_pcie_driver, st_pcie_probe); >> +} >> +device_initcall(pcie_init); > I think the module unload comment is a bit odd for built-in only code. > >> +MODULE_AUTHOR("Fabrice Gasnier "); >> +MODULE_DESCRIPTION("PCI express Driver for ST SoCs"); >> +MODULE_LICENSE("GPL v2"); > These three macros will be, basically, always preprocessed away as long > as this code can't be built to be modular. > > > Paul Bolle >