Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1580889 > unrolled thread

[PATCH] PCI: always build pci-host-common on ARM64

Back to article view | Back to linux.kernel

Contents

  [PATCH] PCI: always build pci-host-common on ARM64 Arnd Bergmann <arnd@arndb.de> - 2017-02-14 22:50 +0100
    Re: [PATCH] PCI: always build pci-host-common on ARM64 Bjorn Helgaas <helgaas@kernel.org> - 2017-02-15 18:00 +0100
      Re: [PATCH] PCI: always build pci-host-common on ARM64 Arnd Bergmann <arnd@arndb.de> - 2017-02-15 23:10 +0100

#1580889 — [PATCH] PCI: always build pci-host-common on ARM64

The Thunder PCI host driver is always built, but it relies on pci_host_common_probe,
so we get a link error here:

drivers/pci/host/pci-thunder-pem.c: In function 'thunder_pem_probe':
drivers/pci/host/pci-thunder-pem.c:412:9: error: implicit declaration of function 'pci_host_common_probe';did you mean 'pci_host_bridge_priv'? [-Werror=implicit-function-declaration]

This adds the common file to the existing hack.

Fixes: ca5ab37b19df ("PCI: Explain ARM64 ACPI/MCFG quirk Kconfig and build strategy")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/pci/host/Makefile | 2 +-
 include/linux/pci-ecam.h  | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index bfe3179ae74c..e97d084f10ea 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_VMD) += vmd.o
 # config options to be enabled, so we always build these drivers on
 # ARM64 and use internal ifdefs to only build the pieces we need
 # depending on whether ACPI, the DT driver, or both are enabled.
-
+obj-$(CONFIG_ARM64) += pci-host-common.o
 obj-$(CONFIG_ARM64) += pcie-hisi.o
 obj-$(CONFIG_ARM64) += pci-thunder-ecam.o
 obj-$(CONFIG_ARM64) += pci-thunder-pem.o
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index f0d2b9451270..ab52692388d1 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -68,9 +68,8 @@ extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops; /* APM X-Gene PCIe v1 */
 extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM X-Gene PCIe v2.x */
 #endif
 
-#ifdef CONFIG_PCI_HOST_GENERIC
 /* for DT-based PCI controllers that support ECAM */
 int pci_host_common_probe(struct platform_device *pdev,
 			  struct pci_ecam_ops *ops);
-#endif
+
 #endif
-- 
2.9.0

[toc] | [next] | [standalone]

#1581456

On Tue, Feb 14, 2017 at 10:42:56PM +0100, Arnd Bergmann wrote:
> The Thunder PCI host driver is always built, but it relies on pci_host_common_probe,
> so we get a link error here:
> 
> drivers/pci/host/pci-thunder-pem.c: In function 'thunder_pem_probe':
> drivers/pci/host/pci-thunder-pem.c:412:9: error: implicit declaration of function 'pci_host_common_probe';did you mean 'pci_host_bridge_priv'? [-Werror=implicit-function-declaration]
> 
> This adds the common file to the existing hack.
> 
> Fixes: ca5ab37b19df ("PCI: Explain ARM64 ACPI/MCFG quirk Kconfig and build strategy")

I'm puzzled.  ca5ab37b19df doesn't *look* like it changes anything.

thunder_pem_probe() is compiled when CONFIG_PCI_HOST_THUNDER_PEM=y,
and it calls pci_host_common_probe().

pci_host_common_probe() is in pci-host-common.c, which is compiled
when CONFIG_PCI_HOST_COMMON=y.  But the declaration below is under
#ifdef CONFIG_PCI_HOST_GENERIC.  Shouldn't it be under #ifdef
CONFIG_PCI_HOST_COMMON instead?

It'd be nice to know what actually broke this (if it's not
ca5ab37b19df) so we can figure out where the fix should be backported.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/pci/host/Makefile | 2 +-
>  include/linux/pci-ecam.h  | 3 +--
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index bfe3179ae74c..e97d084f10ea 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -39,7 +39,7 @@ obj-$(CONFIG_VMD) += vmd.o
>  # config options to be enabled, so we always build these drivers on
>  # ARM64 and use internal ifdefs to only build the pieces we need
>  # depending on whether ACPI, the DT driver, or both are enabled.
> -
> +obj-$(CONFIG_ARM64) += pci-host-common.o
>  obj-$(CONFIG_ARM64) += pcie-hisi.o
>  obj-$(CONFIG_ARM64) += pci-thunder-ecam.o
>  obj-$(CONFIG_ARM64) += pci-thunder-pem.o
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index f0d2b9451270..ab52692388d1 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -68,9 +68,8 @@ extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops; /* APM X-Gene PCIe v1 */
>  extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM X-Gene PCIe v2.x */
>  #endif
>  
> -#ifdef CONFIG_PCI_HOST_GENERIC
>  /* for DT-based PCI controllers that support ECAM */
>  int pci_host_common_probe(struct platform_device *pdev,
>  			  struct pci_ecam_ops *ops);
> -#endif
> +
>  #endif
> -- 
> 2.9.0
> 

[toc] | [prev] | [next] | [standalone]

#1581712

On Wed, Feb 15, 2017 at 5:56 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Feb 14, 2017 at 10:42:56PM +0100, Arnd Bergmann wrote:
>> The Thunder PCI host driver is always built, but it relies on pci_host_common_probe,
>> so we get a link error here:
>>
>> drivers/pci/host/pci-thunder-pem.c: In function 'thunder_pem_probe':
>> drivers/pci/host/pci-thunder-pem.c:412:9: error: implicit declaration of function 'pci_host_common_probe';did you mean 'pci_host_bridge_priv'? [-Werror=implicit-function-declaration]
>>
>> This adds the common file to the existing hack.
>>
>> Fixes: ca5ab37b19df ("PCI: Explain ARM64 ACPI/MCFG quirk Kconfig and build strategy")
>
> I'm puzzled.  ca5ab37b19df doesn't *look* like it changes anything.
>
> thunder_pem_probe() is compiled when CONFIG_PCI_HOST_THUNDER_PEM=y,
> and it calls pci_host_common_probe().
>
> pci_host_common_probe() is in pci-host-common.c, which is compiled
> when CONFIG_PCI_HOST_COMMON=y.  But the declaration below is under
> #ifdef CONFIG_PCI_HOST_GENERIC.  Shouldn't it be under #ifdef
> CONFIG_PCI_HOST_COMMON instead?
>
> It'd be nice to know what actually broke this (if it's not
> ca5ab37b19df) so we can figure out where the fix should be backported.

Right, I misread the commit and got the wrong one. I also ran into a related
problem and will follow up with a new patch that addresses both at once.

Please ignore this version for now.

    Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web