From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934178AbbCPPLm (ORCPT ); Mon, 16 Mar 2015 11:11:42 -0400 Received: from cpsmtpb-ews01.kpnxchange.com ([213.75.39.4]:52423 "EHLO cpsmtpb-ews01.kpnxchange.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933598AbbCPPLj (ORCPT ); Mon, 16 Mar 2015 11:11:39 -0400 Message-ID: <1426518695.26437.55.camel@x220> Subject: Re: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller From: Paul Bolle To: 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 , Fabrice Gasnier , 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 , m-karicheri2@ti.com, Sachin Kamat , Andrew Lunn , Liviu Dudau , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel@stlinux.com, linux-pci@vger.kernel.org, Lee Jones , Gabriel Fernandez Date: Mon, 16 Mar 2015 16:11:35 +0100 In-Reply-To: <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> References: <1426515635-9466-1-git-send-email-gabriel.fernandez@linaro.org> <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2015 15:11:35.0542 (UTC) FILETIME=[7E606160:01D05FFB] X-RcptDomain: vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-03-16 at 15:20 +0100, Gabriel FERNANDEZ wrote: > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > +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. > + 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: Paul Bolle Subject: Re: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller Date: Mon, 16 Mar 2015 16:11:35 +0100 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> Sender: linux-pci-owner@vger.kernel.org To: 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 , Fabrice Gasnier , Kishon Vijay Abraham I , Andrew Morton , "David S. Miller" , Greg KH , Mauro Carvalho Chehab , Joe Perches , Tejun Heo , Arnd Bergmann , Viresh Kumar List-Id: devicetree@vger.kernel.org On Mon, 2015-03-16 at 15:20 +0100, Gabriel FERNANDEZ wrote: > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > +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. > + 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: pebolle@tiscali.nl (Paul Bolle) Date: Mon, 16 Mar 2015 16:11:35 +0100 Subject: [PATCH v2 3/5] PCI: st: Provide support for the sti PCIe controller In-Reply-To: <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> References: <1426515635-9466-1-git-send-email-gabriel.fernandez@linaro.org> <1426515635-9466-4-git-send-email-gabriel.fernandez@linaro.org> Message-ID: <1426518695.26437.55.camel@x220> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2015-03-16 at 15:20 +0100, Gabriel FERNANDEZ wrote: > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > +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. > + 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