Skip to contentSkip to conversation

PCI: fix build errors with CONFIG_PCI=n

PATCH In review Randy.Dunlap 2 participants 6 messages Nov 16, 2004 – Nov 17, 2004 Parallel port

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 PCI: fix build errors with CONFIG_PCI=n

Fix (most of) kernel build for CONFIG_PCI=n. Fixes these 3 errors:

1. drivers/parport/parport_pc.c:3162: error: `parport_init_mode' undeclared (first use in this function)

2. arch/x86_64/kernel/built-in.o(.text+0x8186): In function `quirk_intel_irqbalance':
: undefined reference to `raw_pci_ops'

Kconfig change:
3. arch/x86_64/kernel/pci-gart.c:194: error: `pci_bus_type' undeclared (first use in this function)

Still does not fix these 2 (similar):
a. drivers/built-in.o(.text+0x3dcd8): In function `pnpacpi_allocated_resource':
: undefined reference to pcibios_penalize_isa_irq' b. drivers/built-in.o(.text+0xb4d4): In function pnpbios_parse_allocated_irqresource':
: undefined reference to `pcibios_penalize_isa_irq'

diffstat:=

  arch/i386/kernel/quirks.c    |    3 ++-
  arch/x86_64/Kconfig          |    1 +
  drivers/parport/parport_pc.c |   22 ++++++++++++++++++----
  3 files changed, 21 insertions(+), 5 deletions(-)
drivers/parport/parport_pc.c renamed from drivers/parport/parport_pc.c~config_pci +18 -4
diff -Naurp ./drivers/parport/parport_pc.c~config_pci ./drivers/parport/parport_pc.c
@@ -3154,8 +3154,9 @@ static int __init parport_parse_dma(cons
 				     PARPORT_DMA_NONE, PARPORT_DMA_NOFIFO);
 }
 
-static int __init parport_init_mode_setup(const char *str) {
-
+#ifdef CONFIG_PCI
+static int __init parport_init_mode_setup(const char *str)
+{
 	printk(KERN_DEBUG "parport_pc.c: Specified parameter parport_init_mode=%s\n", str);
 
 	if (!strcmp (str, "spp"))
@@ -3170,11 +3171,16 @@ static int __init parport_init_mode_setu
 		parport_init_mode=5;
 	return 1;
 }
+#else
+static int __inline__ __init parport_init_mode_setup(const char *str)
+{
+	return 1;
+}
+#endif
 
 #ifdef MODULE
 static const char *irq[PARPORT_PC_MAX_PORTS];
 static const char *dma[PARPORT_PC_MAX_PORTS];
-static const char *init_mode;
 
 MODULE_PARM_DESC(io, "Base I/O address (SPP regs)");
 module_param_array(io, int, NULL, 0);
@@ -3189,8 +3195,14 @@ module_param_array(dma, charp, NULL, 0);
 MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation");
 module_param(verbose_probing, int, 0644);
 #endif
+
+#ifdef CONFIG_PCI
+static const char *init_mode;
 MODULE_PARM_DESC(init_mode, "Initialise mode for VIA VT8231 port (spp, ps2, epp, ecp or ecpepp)");
 MODULE_PARM(init_mode, "s");
+#else
+#define init_mode	0
+#endif
 
 static int __init parse_parport_params(void)
 {
@@ -3314,7 +3326,9 @@ __setup ("parport=", parport_setup);
  * parport_init_mode=[spp|ps2|epp|ecp|ecpepp]
  */
 
-__setup("parport_init_mode=",parport_init_mode_setup);
+#ifdef CONFIG_PCI
+__setup("parport_init_mode=", parport_init_mode_setup);
+#endif
 
 #endif
 
arch/i386/kernel/quirks.c renamed from arch/i386/kernel/quirks.c~config_pci +2 -1
diff -Naurp ./arch/i386/kernel/quirks.c~config_pci ./arch/i386/kernel/quirks.c
@@ -1,10 +1,11 @@
 /*
  * This file contains work-arounds for x86 and x86_64 platform bugs.
  */
+#include <linux/config.h>
 #include <linux/pci.h>
 #include <linux/irq.h>
 
-#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP)
+#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
 {
arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig~config_pci +1 -0
diff -Naurp ./arch/x86_64/Kconfig~config_pci ./arch/x86_64/Kconfig
@@ -306,6 +306,7 @@ config NR_CPUS
 
 config GART_IOMMU
 	bool "IOMMU support"
+	depends on PCI
 	help
 	  Support the K8 IOMMU. Needed to run systems with more than 4GB of memory
 	  properly with 32-bit PCI devices that do not support DAC (Double Address
#1 lore raw
Quoted 4 lines · Randy.Dunlap

Fix (most of) kernel build for CONFIG_PCI=n. Fixes these 3 errors:

1. drivers/parport/parport_pc.c:3162: error: `parport_init_mode' undeclared (first use in this function)

Life is easier if you do not use attachments.
(Then I can more easily comment the code.)

You write

  -static int __init parport_init_mode_setup(const char *str) {
  -
  +#ifdef CONFIG_PCI
  +static int __init parport_init_mode_setup(const char *str)

In my tree I have

  static int __init parport_init_mode_setup(char *str) {

in order to avoid the warning for

  __setup("parport_init_mode=",parport_init_mode_setup);

since the parameter is a int (*setup_func)(char *); - see

  struct obs_kernel_param {
        const char *str;
        int (*setup_func)(char *);
        int early;
  };

Apart from this prototype change I only moved the single line

  static int __initdata parport_init_mode = 0;

outside the #ifdef's. Is that not good enough, and better than introducing more #ifdef's? Keeps the source smaller.

Andries

#2 lore raw
Quoted 10 lines · Andries Brouwer
Quoted 4 lines · Randy.Dunlap

Fix (most of) kernel build for CONFIG_PCI=n. Fixes these 3 errors:

1. drivers/parport/parport_pc.c:3162: error: `parport_init_mode' undeclared (first use in this function)

Life is easier if you do not use attachments.
(Then I can more easily comment the code.)

I understand. If the decision were only so simple.

Quoted 15 lines

You write

  -static int __init parport_init_mode_setup(const char *str) {
  -
  +#ifdef CONFIG_PCI
  +static int __init parport_init_mode_setup(const char *str)

In my tree I have

  static int __init parport_init_mode_setup(char *str) {

in order to avoid the warning for

  __setup("parport_init_mode=",parport_init_mode_setup);
Quoted 7 lines

since the parameter is a int (*setup_func)(char *); - see

  struct obs_kernel_param {
        const char *str;
        int (*setup_func)(char *);
        int early;
  };

Yes, I'm familiar with that, but I made a patch against current top of tree.

Quoted 6 lines

Apart from this prototype change I only moved the single line

  static int __initdata parport_init_mode = 0;

outside the #ifdef's. Is that not good enough, and better than introducing more #ifdef's? Keeps the source smaller.

It can be good enough. It keeps the source smaller, at the expense of adding some unneeded code (the parport_init_mode_setup() function e.g.).

Signature · 1 line
~Randy
#3 lore raw
Quoted 4 lines · Randy.Dunlap
Quoted 1 line

static int __init parport_init_mode_setup(char *str) {

Yes, I'm familiar with that, but I made a patch against current top of tree.

I don't understand. Will you send another patch to fix the prototype?

Andries

#4 lore raw
Quoted 10 lines · Andries Brouwer
Quoted 4 lines · Randy.Dunlap
Quoted 1 line

static int __init parport_init_mode_setup(char *str) {

Yes, I'm familiar with that, but I made a patch against current top of tree.

I don't understand. Will you send another patch to fix the prototype?

Sorry, I did that yesterday:
http://lkml.org/lkml/2004/11/15/133

It didn't show up in today's patch because Andrew's "the perfect patch" says:
(http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt)

b) Make sure that your patches apply to the latest version of the kernel tree. Either straight from bitkeeper or from ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/

Signature · 1 line
~Randy
#5 lore raw
Quoted 3 lines · Randy.Dunlap
Quoted 1 line

I don't understand. Will you send another patch to fix the prototype?

Sorry, I did that yesterday:

Ah, OK.