undefined reference to pci_io_base
I'm trying to understand the intended design of the inb() and outb() macros in asm-powerpc/io.h. They are causing me some grief when I set CONFIG_PCI=n:
drivers/built-in.o: undefined reference to `pci_io_base'
This is coming from drivers/char/mem.c, which is always built in, and is referencing pci_io_base through inb() and outb().
Anyway, it seems asm-powerpc/io.h has two sets of io macros, one set for iSeries, and one generic set for everything else. The problem arises because the generic macros just use the eeh macros in eeh.h, which in turn, directly use pci_io_base.
I can think of three solutions to this that work for me, but I'm not sure which, if any, would be the most proper. One would be to just have this in io.h:
#if defined(CONFI_PCI) extern unsigned long pci_io_base; #else #define pci_io_base 0 #endif
Another would be to have this in some file that is always built in, like setup-common.c:
#if !defined(CONFI_PCI) unsigned long pci_io_base; EXPORT_SYMBOL(pci_io_base); #endif
A third would be to have another set of io macros in io.h that are used when CONFIG_PCI=n.
Comments welcome.
-Geoff
Quoted 19 lines · Geoff Levand
I'm trying to understand the intended design of the
inb()andoutb()macros inasm-powerpc/io.h. They are causing me some grief when I setCONFIG_PCI=n:
drivers/built-in.o: undefined reference to `pci_io_base'This is coming from
drivers/char/mem.c, which is always built in, and is referencingpci_io_basethroughinb()andoutb().Anyway, it seems
asm-powerpc/io.hhas two sets of io macros, one set for iSeries, and one generic set for everything else. The problem arises because the generic macros just use the eeh macros ineeh.h, which in turn, directly usepci_io_base.I can think of three solutions to this that work for me, but I'm not sure which, if any, would be the most proper. One would be to just have this in
io.h:
Quoted 5 lines
#if defined(CONFI_PCI) extern unsigned long pci_io_base; #else #define pci_io_base 0 #endif
This makes the most sense to me; it compiles to something nice.
Quoted 7 lines
Another would be to have this in some file that is always built in, like
setup-common.c:#if !defined(CONFI_PCI) unsigned long pci_io_base; EXPORT_SYMBOL(pci_io_base); #endif
This compiles to something ugly and pointless ...
Quoted 2 lines
A third would be to have another set of io macros in
io.hthat are used whenCONFIG_PCI=n.
I'm not sure that yet-another set of macros improves readabily. Those macros are already fairly byzantine in thier inter-connections.
--linas
Quoted 8 lines
Quoted 6 lines
#if defined(CONFI_PCI) extern unsigned long pci_io_base; #else #define pci_io_base 0 #endifThis makes the most sense to me; it compiles to something nice.
Agreed.
Ben.
Quoted 9 lines · Geoff Levand
I'm trying to understand the intended design of the
inb()andoutb()macros inasm-powerpc/io.h. They are causing me some grief when I setCONFIG_PCI=n:
drivers/built-in.o: undefined reference to `pci_io_base'This is coming from
drivers/char/mem.c, which is always built in, and is referencingpci_io_basethroughinb()andoutb().
Hmmm. inb and outb are designed for accessing PCI I/O space. I guess we could turn them into BUG() when CONFIG_PCI=n.
Paul.
Quoted 6 lines · Paul Mackerras
Quoted 4 lines · Geoff Levand
I'm trying to understand the intended design of the
inb()andoutb()macros inasm-powerpc/io.h. They are causing me some grief when I setCONFIG_PCI=n:
Quoted 8 lines
Quoted 5 lines
drivers/built-in.o: undefined reference to `pci_io_base'This is coming from
drivers/char/mem.c, which is always built in, and is referencingpci_io_basethroughinb()andoutb().Hmmm. inb and outb are designed for accessing PCI I/O space. I guess we could turn them into
BUG()whenCONFIG_PCI=n.
I just looked at drivers/char/mem.c and the code in question is surrounded by
#if defined(CONFIG_ISA) || !defined(__mc68000__)
which seems just plain wrong.
It should probably be changed to
#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
This code surrounds fileops to enale fileio on /dev/port which maps to inb/outb.
Do we want to enable /dev/port for pci space ??
--linas
Quoted 23 lines · Linas Vepstas
Quoted 6 lines · Paul Mackerras
Quoted 4 lines · Geoff Levand
I'm trying to understand the intended design of the
inb()andoutb()macros inasm-powerpc/io.h. They are causing me some grief when I setCONFIG_PCI=n:Quoted 8 lines
Quoted 5 lines
drivers/built-in.o: undefined reference to `pci_io_base'This is coming from
drivers/char/mem.c, which is always built in, and is referencingpci_io_basethroughinb()andoutb().Hmmm. inb and outb are designed for accessing PCI I/O space. I guess we could turn them into
BUG()whenCONFIG_PCI=n.I just looked at
drivers/char/mem.cand the code in question is surrounded by#if
defined(CONFIG_ISA)|| !defined(__mc68000__)which seems just plain wrong.
Quoted 8 lines
It should probably be changed to
#if (
defined(CONFIG_ISA)||defined(CONFIG_PCI)) && !defined(__mc68000__)This code surrounds fileops to enale fileio on
/dev/portwhich maps to inb/outb.Do we want to enable
/dev/portfor pci space ??
I found the same, but was thinking
#if defined(CONFIG_ISA) && !defined(__mc68000__)
So it is only built when CONFIG_ISA=y. Is there any reason to always have it whit PCI?
Paul, can I send you that fix, or should I send it to someone else?
-Geoff
Quoted 6 lines · Geoff Levand
I found the same, but was thinking
#if
defined(CONFIG_ISA)&& !defined(__mc68000__)So it is only built when
CONFIG_ISA=y. Is there any reason to always have it whit PCI?
It's occasionally useful with PCI && !ISA. It's pretty useless with !PCI && !ISA.
Quoted 2 lines
Paul, can I send you that fix, or should I send it to someone else?
Send it to Andrew Morton.
Paul.
Quoted 9 lines · Paul Mackerras
Quoted 6 lines · Geoff Levand
I found the same, but was thinking
#if
defined(CONFIG_ISA)&& !defined(__mc68000__)So it is only built when
CONFIG_ISA=y. Is there any reason to always have it whit PCI?
Quoted 7 lines
It's occasionally useful with PCI && !ISA. It's pretty useless with !PCI && !ISA.
Quoted 2 lines
Paul, can I send you that fix, or should I send it to someone else?
Send it to Andrew Morton.
For anyone interested, I sent that out here:
http://lkml.org/lkml/2006/8/29/374
-Geoff