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(-)
Signed-off-by: Randy Dunlap <[email protected]>
On Tue, Nov 16, 2004 at 02:34:48PM -0800, Randy.Dunlap wrote:
> 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
Andries Brouwer wrote:
> On Tue, Nov 16, 2004 at 02:34:48PM -0800, Randy.Dunlap wrote:
>
>>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.
> 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;
> };
Yes, I'm familiar with that, but I made a patch against current
top of tree.
> 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.).
--
~Randy
On Tue, Nov 16, 2004 at 03:36:30PM -0800, Randy.Dunlap wrote:
> > 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
Andries Brouwer wrote:
> On Tue, Nov 16, 2004 at 03:36:30PM -0800, Randy.Dunlap wrote:
>
>
>>> 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/
--
~Randy
On Tue, Nov 16, 2004 at 04:13:00PM -0800, Randy.Dunlap wrote:
> >I don't understand. Will you send another patch to fix the prototype?
>
> Sorry, I did that yesterday:
Ah, OK.