Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
8390 support into a pausing and a non pausing driver core"), ne.c
cause this build failure:
drivers/built-in.o: In function `ne_probe1':
ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_block_output':
ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
Signed-off-by: Atsushi Nemoto <[email protected]>
---
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 1412697..3df231d 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = eip_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
ret = register_netdev(dev);
if (ret)
@@ -794,7 +794,7 @@ retry:
if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
ne_reset_8390(dev);
- NS8390_init(dev,1);
+ NS8390p_init(dev,1);
break;
}
@@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
if (netif_running(dev)) {
ne_reset_8390(dev);
- NS8390_init(dev, 1);
+ NS8390p_init(dev, 1);
netif_device_attach(dev);
}
return 0;
* Atsushi Nemoto <[email protected]> wrote:
> Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
> 8390 support into a pausing and a non pausing driver core"), ne.c
> cause this build failure:
>
> drivers/built-in.o: In function `ne_probe1':
> ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `ne_block_output':
> ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
i just triggered a similar build failure, but in a different
ne2000-derived file:
drivers/built-in.o: In function `hpp_close':
hp-plus.c:(.text+0xd7c1a): undefined reference to `ei_close'
drivers/built-in.o: In function `hpp_open':
hp-plus.c:(.text+0xd7c3c): undefined reference to `ei_interrupt'
hp-plus.c:(.text+0xd7ca9): undefined reference to `ei_open'
drivers/built-in.o: In function `hpp_probe1':
hp-plus.c:(.init.text+0xab54): undefined reference to `ei_poll'
hp-plus.c:(.init.text+0xabed): undefined reference to `NS8390_init'
drivers/built-in.o: In function `hp_plus_probe':
(.init.text+0xac4c): undefined reference to `__alloc_ei_netdev'
make: *** [.tmp_vmlinux1] Error 1
with this config:
http://redhat.com/~mingo/misc/config-Mon_Jul_21_20_21_08_CEST_2008.bad
Ingo
On Mon, 21 Jul 2008 21:15:19 +0200
Ingo Molnar <[email protected]> wrote:
>
> * Atsushi Nemoto <[email protected]> wrote:
>
> > Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
> > 8390 support into a pausing and a non pausing driver core"), ne.c
> > cause this build failure:
> >
> > drivers/built-in.o: In function `ne_probe1':
> > ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
> > drivers/built-in.o: In function `ne_block_output':
> > ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
>
> i just triggered a similar build failure, but in a different
> ne2000-derived file:
I'll take a look. Various odd things happened with the Makefile for this
patch and the follow up fixes. If the followup didn't get applied then
that might explain the breakage.
* Alan Cox <[email protected]> wrote:
> On Mon, 21 Jul 2008 21:15:19 +0200
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * Atsushi Nemoto <[email protected]> wrote:
> >
> > > Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
> > > 8390 support into a pausing and a non pausing driver core"), ne.c
> > > cause this build failure:
> > >
> > > drivers/built-in.o: In function `ne_probe1':
> > > ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
> > > drivers/built-in.o: In function `ne_block_output':
> > > ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
> >
> > i just triggered a similar build failure, but in a different
> > ne2000-derived file:
>
> I'll take a look. Various odd things happened with the Makefile for
> this patch and the follow up fixes. If the followup didn't get applied
> then that might explain the breakage.
ok. I also got:
drivers/built-in.o: In function `hp_probe1':
hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
so i suspect most of the 8390p.o library using ne2000 drivers are
affected?
i think instead of a manual review i think this is better to fix all the
problems:
cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
$(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
sed 's/.o$/.c/g'))
find the full tested patch below. It solves the build failures i
triggered so far.
Ingo
------------->
commit 79f2b8594df44a4f3f11085df656883525b74abd
Author: Ingo Molnar <[email protected]>
Date: Tue Jul 22 09:19:31 2008 +0200
net 8390p: fix interface usage
various drivers were using the wrong APIs:
drivers/built-in.o: In function `hp_probe1':
hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
fixed via:
cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
$(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
sed 's/.o$/.c/g'))
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/net/hp-plus.c | 2 +-
drivers/net/hp.c | 2 +-
drivers/net/ne.c | 2 +-
drivers/net/ne2.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
index c2c4f49..8239939 100644
--- a/drivers/net/hp-plus.c
+++ b/drivers/net/hp-plus.c
@@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
}
outw(Perf_Page, ioaddr + HP_PAGING);
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
/* Leave the 8390 and HP chip reset. */
outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
diff --git a/drivers/net/hp.c b/drivers/net/hp.c
index 8281209..0a8c649 100644
--- a/drivers/net/hp.c
+++ b/drivers/net/hp.c
@@ -389,7 +389,7 @@ static void __init
hp_init_card(struct net_device *dev)
{
int irq = dev->irq;
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
outb_p(irqmap[irq&0x0f] | HP_RUN,
dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
return;
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 3df231d..4a8a4b1 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
}
/* Read the 16 bytes of station address PROM.
- We must first initialize registers, similar to NS8390_init(eifdev, 0).
+ We must first initialize registers, similar to NS8390p_init(eifdev, 0).
We can't reliably read the SAPROM address without this.
(I learned the hard way!). */
{
diff --git a/drivers/net/ne2.c b/drivers/net/ne2.c
index 8f72563..332df75 100644
--- a/drivers/net/ne2.c
+++ b/drivers/net/ne2.c
@@ -404,7 +404,7 @@ static int __init ne2_probe1(struct net_device *dev, int slot)
/* Read the 16 bytes of station address PROM.
We must first initialize registers, similar to
- NS8390_init(eifdev, 0).
+ NS8390p_init(eifdev, 0).
We can't reliably read the SAPROM address without this.
(I learned the hard way!). */
{
> find the full tested patch below. It solves the build failures i
> triggered so far.
Yes - that matches the patch I sent Jeff on the 8th July
Subject: Re: linux-next: Tree for July 8 (ns8390)
From: Alan Cox <[email protected]>
Please try this and if it sorts it fold it into the driver. This is a diff
between my tree and the linux-next tree
---
drivers/net/hp-plus.c | 2 +-
drivers/net/hp.c | 2 +-
drivers/net/ne.c | 8 ++++----
drivers/net/wd.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
On Mon, 21 Jul 2008 23:35:12 +0900 (JST)
Atsushi Nemoto <[email protected]> wrote:
> Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
> 8390 support into a pausing and a non pausing driver core"), ne.c
> cause this build failure:
>
> drivers/built-in.o: In function `ne_probe1':
> ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `ne_block_output':
> ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
Yes - I sent the same to Jeff Garzik early July.
Alan
Ingo Molnar wrote:
> * Alan Cox <[email protected]> wrote:
>
>> On Mon, 21 Jul 2008 21:15:19 +0200
>> Ingo Molnar <[email protected]> wrote:
>>
>>> * Atsushi Nemoto <[email protected]> wrote:
>>>
>>>> Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
>>>> 8390 support into a pausing and a non pausing driver core"), ne.c
>>>> cause this build failure:
>>>>
>>>> drivers/built-in.o: In function `ne_probe1':
>>>> ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
>>>> drivers/built-in.o: In function `ne_block_output':
>>>> ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
>>> i just triggered a similar build failure, but in a different
>>> ne2000-derived file:
>> I'll take a look. Various odd things happened with the Makefile for
>> this patch and the follow up fixes. If the followup didn't get applied
>> then that might explain the breakage.
>
> ok. I also got:
>
> drivers/built-in.o: In function `hp_probe1':
> hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
>
> so i suspect most of the 8390p.o library using ne2000 drivers are
> affected?
>
> i think instead of a manual review i think this is better to fix all the
> problems:
>
> cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
> $(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
> sed 's/.o$/.c/g'))
>
> find the full tested patch below. It solves the build failures i
> triggered so far.
>
> Ingo
>
> ------------->
> commit 79f2b8594df44a4f3f11085df656883525b74abd
> Author: Ingo Molnar <[email protected]>
> Date: Tue Jul 22 09:19:31 2008 +0200
>
> net 8390p: fix interface usage
>
> various drivers were using the wrong APIs:
>
> drivers/built-in.o: In function `hp_probe1':
> hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
>
> fixed via:
>
> cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
> $(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
> sed 's/.o$/.c/g'))
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> drivers/net/hp-plus.c | 2 +-
> drivers/net/hp.c | 2 +-
> drivers/net/ne.c | 2 +-
> drivers/net/ne2.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
> index c2c4f49..8239939 100644
> --- a/drivers/net/hp-plus.c
> +++ b/drivers/net/hp-plus.c
> @@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
> }
>
> outw(Perf_Page, ioaddr + HP_PAGING);
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
> /* Leave the 8390 and HP chip reset. */
> outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
>
> diff --git a/drivers/net/hp.c b/drivers/net/hp.c
> index 8281209..0a8c649 100644
> --- a/drivers/net/hp.c
> +++ b/drivers/net/hp.c
> @@ -389,7 +389,7 @@ static void __init
> hp_init_card(struct net_device *dev)
> {
> int irq = dev->irq;
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
> outb_p(irqmap[irq&0x0f] | HP_RUN,
> dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
> return;
> diff --git a/drivers/net/ne.c b/drivers/net/ne.c
> index 3df231d..4a8a4b1 100644
> --- a/drivers/net/ne.c
> +++ b/drivers/net/ne.c
> @@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
> }
>
> /* Read the 16 bytes of station address PROM.
> - We must first initialize registers, similar to NS8390_init(eifdev, 0).
> + We must first initialize registers, similar to NS8390p_init(eifdev, 0).
> We can't reliably read the SAPROM address without this.
> (I learned the hard way!). */
> {
> diff --git a/drivers/net/ne2.c b/drivers/net/ne2.c
> index 8f72563..332df75 100644
> --- a/drivers/net/ne2.c
> +++ b/drivers/net/ne2.c
> @@ -404,7 +404,7 @@ static int __init ne2_probe1(struct net_device *dev, int slot)
>
> /* Read the 16 bytes of station address PROM.
> We must first initialize registers, similar to
> - NS8390_init(eifdev, 0).
> + NS8390p_init(eifdev, 0).
> We can't reliably read the SAPROM address without this.
> (I learned the hard way!). */
applied
* Jeff Garzik <[email protected]> wrote:
>>>>> drivers/built-in.o: In function `ne_probe1':
>>>>> ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
>>>>> drivers/built-in.o: In function `ne_block_output':
>>>>> ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
>>>> i just triggered a similar build failure, but in a different
>>>> ne2000-derived file:
>>> I'll take a look. Various odd things happened with the Makefile for
>>> this patch and the follow up fixes. If the followup didn't get
>>> applied then that might explain the breakage.
>>
>> ok. I also got:
>>
>> drivers/built-in.o: In function `hp_probe1':
>> hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
>>
>> so i suspect most of the 8390p.o library using ne2000 drivers are
>> affected?
>>
>> i think instead of a manual review i think this is better to fix all
>> the problems:
>>
>> cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
>> $(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
>> sed 's/.o$/.c/g'))
>>
>> find the full tested patch below. It solves the build failures i
>> triggered so far.
>>
>> Ingo
>>
>> ------------->
>> commit 79f2b8594df44a4f3f11085df656883525b74abd
>> Author: Ingo Molnar <[email protected]>
>> Date: Tue Jul 22 09:19:31 2008 +0200
>>
>> net 8390p: fix interface usage
>> various drivers were using the wrong APIs:
>> drivers/built-in.o: In function `hp_probe1':
>> hp.c:(.init.text+0xa280): undefined reference to `NS8390_init'
>> fixed via:
>> cd drivers/net/; sed -i 's/NS8390_/NS8390p_/g' \
>> $(grep -l NS8390_ $(grep 8390p.o Makefile | cut -d' ' -f3 | \
>> sed 's/.o$/.c/g'))
>> Signed-off-by: Ingo Molnar <[email protected]>
>> ---
>> drivers/net/hp-plus.c | 2 +-
>> drivers/net/hp.c | 2 +-
>> drivers/net/ne.c | 2 +-
>> drivers/net/ne2.c | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
>> index c2c4f49..8239939 100644
>> --- a/drivers/net/hp-plus.c
>> +++ b/drivers/net/hp-plus.c
>> @@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
>> }
>> outw(Perf_Page, ioaddr + HP_PAGING);
>> - NS8390_init(dev, 0);
>> + NS8390p_init(dev, 0);
>> /* Leave the 8390 and HP chip reset. */
>> outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
>> diff --git a/drivers/net/hp.c b/drivers/net/hp.c
>> index 8281209..0a8c649 100644
>> --- a/drivers/net/hp.c
>> +++ b/drivers/net/hp.c
>> @@ -389,7 +389,7 @@ static void __init
>> hp_init_card(struct net_device *dev)
>> {
>> int irq = dev->irq;
>> - NS8390_init(dev, 0);
>> + NS8390p_init(dev, 0);
>> outb_p(irqmap[irq&0x0f] | HP_RUN,
>> dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
>> return;
>> diff --git a/drivers/net/ne.c b/drivers/net/ne.c
>> index 3df231d..4a8a4b1 100644
>> --- a/drivers/net/ne.c
>> +++ b/drivers/net/ne.c
>> @@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
>> }
>> /* Read the 16 bytes of station address PROM.
>> - We must first initialize registers, similar to NS8390_init(eifdev, 0).
>> + We must first initialize registers, similar to NS8390p_init(eifdev, 0).
>> We can't reliably read the SAPROM address without this.
>> (I learned the hard way!). */
>> {
>> diff --git a/drivers/net/ne2.c b/drivers/net/ne2.c
>> index 8f72563..332df75 100644
>> --- a/drivers/net/ne2.c
>> +++ b/drivers/net/ne2.c
>> @@ -404,7 +404,7 @@ static int __init ne2_probe1(struct net_device *dev, int slot)
>> /* Read the 16 bytes of station address PROM.
>> We must first initialize registers, similar to
>> - NS8390_init(eifdev, 0).
>> + NS8390p_init(eifdev, 0).
>> We can't reliably read the SAPROM address without this.
>> (I learned the hard way!). */
>
> applied
thanks Jeff. I think the fix below from Atsushi-san might still be
missing from upstream?
Ingo
-------------------->
commit 994cd3a79a431f5ce234478e951856357f4bc94c
Author: Atsushi Nemoto <[email protected]>
Date: Mon Jul 21 23:35:12 2008 +0900
8390: Fix ne.c build
Since commit 055e5110ae0c0c1176a75b78d789294f2ff2f7af ("8390: Split
8390 support into a pausing and a non pausing driver core"), ne.c
cause this build failure:
drivers/built-in.o: In function `ne_probe1':
ne.c:(.init.text+0x2464): undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_block_output':
ne.c:(.text.ne_block_output+0x1b0): undefined reference to `NS8390_init'
Signed-off-by: Atsushi Nemoto <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Alan Cox <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/net/ne.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 2fec612..4a8a4b1 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = eip_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
ret = register_netdev(dev);
if (ret)
@@ -794,7 +794,7 @@ retry:
if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
ne_reset_8390(dev);
- NS8390_init(dev,1);
+ NS8390p_init(dev,1);
break;
}
@@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
if (netif_running(dev)) {
ne_reset_8390(dev);
- NS8390_init(dev, 1);
+ NS8390p_init(dev, 1);
netif_device_attach(dev);
}
return 0;
not sure it's known but despite all the fixes i still get:
drivers/built-in.o: In function `ne_drv_resume':
ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_block_output':
ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
drivers/built-in.o: In function `hpp_close':
hp-plus.c:(.text+0x148c3b): undefined reference to `ei_close'
drivers/built-in.o: In function `hpp_open':
hp-plus.c:(.text+0x148c77): undefined reference to `ei_interrupt'
hp-plus.c:(.text+0x148ce7): undefined reference to `ei_open'
drivers/built-in.o: In function `ne_probe1':
ne.c:(.init.text+0xb532): undefined reference to `NS8390_init'
drivers/built-in.o: In function `hpp_probe1':
hp-plus.c:(.init.text+0xc033): undefined reference to `ei_poll'
drivers/built-in.o: In function `hp_plus_probe':
(.init.text+0xc134): undefined reference to `__alloc_ei_netdev'
make: *** [.tmp_vmlinux1] Error 1
with this config and latest -git (v2.6.26-6371-g338b9bb):
http://redhat.com/~mingo/misc/config-Thu_Jul_24_07_13_29_CEST_2008.bad
Ingo
On Thu, 24 Jul 2008 07:26:03 +0200
Ingo Molnar <[email protected]> wrote:
>
> not sure it's known but despite all the fixes i still get:
I'll have a look at this next week or possibly the week after. The
original patches worked but they spent 3 months going round in circles
and I've completely given up even trying to work out what happened or why
all the previous updates I sent were ignored.
Alan
* Alan Cox <[email protected]> wrote:
> On Thu, 24 Jul 2008 07:26:03 +0200
> Ingo Molnar <[email protected]> wrote:
>
> >
> > not sure it's known but despite all the fixes i still get:
>
> I'll have a look at this next week or possibly the week after. The
> original patches worked but they spent 3 months going round in circles
> and I've completely given up even trying to work out what happened or
> why all the previous updates I sent were ignored.
ok - meanwhile i'm using the workaround hack below.
Ingo
--------------------->
commit 91de2dc9031b92157f067d78aaf2c8e58a965c0d
Author: Ingo Molnar <[email protected]>
Date: Mon Jul 21 21:18:29 2008 +0200
hp-plus.c: work around build failure
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/net/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index fa533c2..1c809e4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1129,6 +1129,8 @@ config EEXPRESS_PRO
config HPLAN_PLUS
tristate "HP PCLAN+ (27247B and 27252A) support"
depends on NET_ISA
+ # broken build with config-Mon_Jul_21_20_21_08_CEST_2008.bad
+ depends on 0
select CRC32
help
If you have a network (Ethernet) card of this type, say Y and read
Alan Cox wrote:
> On Thu, 24 Jul 2008 07:26:03 +0200
> Ingo Molnar <[email protected]> wrote:
>
>> not sure it's known but despite all the fixes i still get:
>
> I'll have a look at this next week or possibly the week after. The
> original patches worked but they spent 3 months going round in circles
> and I've completely given up even trying to work out what happened or why
> all the previous updates I sent were ignored.
My apologies. FWIW, from my point of view the same patch(es) kept
getting fixed and updated and going around in circles, so I kept
waiting. Since it was was a net-next issue (until now), I lowered the
priority and waited to let you guys (you, Andrew, Randy mainly) sort
things out.
So far the only remaining patch I have outstanding and needing to be
applied is from Atsushi-san via Ingo (message id
<[email protected]>)... is that the last of it?
Jeff
On Thu, 24 Jul 2008, Jeff Garzik wrote:
> Alan Cox wrote:
> > On Thu, 24 Jul 2008 07:26:03 +0200
> > Ingo Molnar <[email protected]> wrote:
> >
> > > not sure it's known but despite all the fixes i still get:
> >
> > I'll have a look at this next week or possibly the week after. The
> > original patches worked but they spent 3 months going round in circles
> > and I've completely given up even trying to work out what happened or why
> > all the previous updates I sent were ignored.
>
> My apologies. FWIW, from my point of view the same patch(es) kept getting
> fixed and updated and going around in circles, so I kept waiting. Since it
> was was a net-next issue (until now), I lowered the priority and waited to let
> you guys (you, Andrew, Randy mainly) sort things out.
Randy got frustrated and gave up on this particular issue & patch(es).
This one has gone on far too long...
> So far the only remaining patch I have outstanding and needing to be applied
> is from Atsushi-san via Ingo (message id <[email protected]>)...
> is that the last of it?
--
~Randy
> My apologies. FWIW, from my point of view the same patch(es) kept
> getting fixed and updated and going around in circles, so I kept
> waiting. Since it was was a net-next issue (until now), I lowered the
> priority and waited to let you guys (you, Andrew, Randy mainly) sort
> things out.
>
> So far the only remaining patch I have outstanding and needing to be
> applied is from Atsushi-san via Ingo (message id
> <[email protected]>)... is that the last of it?
I've got a reference tree that I will regenerate and diff against the
upstream GIT tree to check. It looks like some of the ei_ to eip_ changes
have gone for a walk.
Its on my TODO list and now IT821x is working again the panic mode stuff
is over I hope
Alan
On Thu, 24 Jul 2008 07:26:03 +0200
Ingo Molnar <[email protected]> wrote:
>
> not sure it's known but despite all the fixes i still get:
>
> drivers/built-in.o: In function `ne_drv_resume':
> ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `ne_block_output':
> ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
This should do the trick. I can't test it currently as that configuration
now fails to build with mm errors in current git head..
mm/hugetlb.c: In function ‘hugetlb_acct_memory’: mm/hugetlb.c:1507:
error: implicit declaration of function ‘cpuset_mems_nr’
8390: Fix various compile errors
From: Alan Cox <[email protected]>
Some of the original patches got lost along the way, so sort out the
remaining stuff
---
drivers/net/Makefile | 2 +-
drivers/net/ne.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7629c90..f66b79b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -111,7 +111,7 @@ obj-$(CONFIG_EL2) += 3c503.o 8390p.o
obj-$(CONFIG_NE2000) += ne.o 8390p.o
obj-$(CONFIG_NE2_MCA) += ne2.o 8390p.o
obj-$(CONFIG_HPLAN) += hp.o 8390p.o
-obj-$(CONFIG_HPLAN_PLUS) += hp-plus.o 8390p.o
+obj-$(CONFIG_HPLAN_PLUS) += hp-plus.o 8390.o
obj-$(CONFIG_ULTRA) += smc-ultra.o 8390.o
obj-$(CONFIG_ULTRAMCA) += smc-mca.o 8390.o
obj-$(CONFIG_ULTRA32) += smc-ultra32.o 8390.o
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 2fec612..4a8a4b1 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = eip_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
ret = register_netdev(dev);
if (ret)
@@ -794,7 +794,7 @@ retry:
if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
ne_reset_8390(dev);
- NS8390_init(dev,1);
+ NS8390p_init(dev,1);
break;
}
@@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
if (netif_running(dev)) {
ne_reset_8390(dev);
- NS8390_init(dev, 1);
+ NS8390p_init(dev, 1);
netif_device_attach(dev);
}
return 0;
On 25.07.2008 [18:09:35 +0100], Alan Cox wrote:
> On Thu, 24 Jul 2008 07:26:03 +0200
> Ingo Molnar <[email protected]> wrote:
>
> >
> > not sure it's known but despite all the fixes i still get:
> >
> > drivers/built-in.o: In function `ne_drv_resume':
> > ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
> > drivers/built-in.o: In function `ne_block_output':
> > ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
>
> This should do the trick. I can't test it currently as that configuration
> now fails to build with mm errors in current git head..
>
> mm/hugetlb.c: In function ???hugetlb_acct_memory???: mm/hugetlb.c:1507:
> error: implicit declaration of function ???cpuset_mems_nr???
When moving the intialization functions around, I did not remove the
dependency of some helpers on CONFIG_SYSCTL. This led to a large chunk
of code being elided even though it is needed to build hugetlb.o.
Fixes a build failure reported by Alan Cox:
mm/hugetlb.c: In function ‘hugetlb_acct_memory’: mm/hugetlb.c:1507:
error: implicit declaration of function ‘cpuset_mems_nr’
Signed-off-by: Nishanth Aravamudan <[email protected]>
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 41341c4..3be79dc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1026,7 +1026,6 @@ static void __init report_hugepages(void)
}
}
-#ifdef CONFIG_SYSCTL
#ifdef CONFIG_HIGHMEM
static void try_to_free_low(struct hstate *h, unsigned long count)
{
@@ -1386,6 +1385,7 @@ static unsigned int cpuset_mems_nr(unsigned int *array)
return nr;
}
+#ifdef CONFIG_SYSCTL
int hugetlb_sysctl_handler(struct ctl_table *table, int write,
struct file *file, void __user *buffer,
size_t *length, loff_t *ppos)
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
[resending with Linus' address fixed]
On 25.07.2008 [18:09:35 +0100], Alan Cox wrote:
> On Thu, 24 Jul 2008 07:26:03 +0200
> Ingo Molnar <[email protected]> wrote:
>
> >
> > not sure it's known but despite all the fixes i still get:
> >
> > drivers/built-in.o: In function `ne_drv_resume':
> > ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
> > drivers/built-in.o: In function `ne_block_output':
> > ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
>
> This should do the trick. I can't test it currently as that configuration
> now fails to build with mm errors in current git head..
>
> mm/hugetlb.c: In function ???hugetlb_acct_memory???: mm/hugetlb.c:1507:
> error: implicit declaration of function ???cpuset_mems_nr???
When moving the intialization functions around, I did not remove the
dependency of some helpers on CONFIG_SYSCTL. This led to a large chunk
of code being elided even though it is needed to build hugetlb.o.
Fixes a build failure reported by Alan Cox:
mm/hugetlb.c: In function ‘hugetlb_acct_memory’: mm/hugetlb.c:1507:
error: implicit declaration of function ‘cpuset_mems_nr’
Signed-off-by: Nishanth Aravamudan <[email protected]>
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 41341c4..3be79dc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1026,7 +1026,6 @@ static void __init report_hugepages(void)
}
}
-#ifdef CONFIG_SYSCTL
#ifdef CONFIG_HIGHMEM
static void try_to_free_low(struct hstate *h, unsigned long count)
{
@@ -1386,6 +1385,7 @@ static unsigned int cpuset_mems_nr(unsigned int *array)
return nr;
}
+#ifdef CONFIG_SYSCTL
int hugetlb_sysctl_handler(struct ctl_table *table, int write,
struct file *file, void __user *buffer,
size_t *length, loff_t *ppos)
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
On Fri, 25 Jul 2008 13:33:51 -0700
Nishanth Aravamudan <[email protected]> wrote:
> [resending with Linus' address fixed]
>
> On 25.07.2008 [18:09:35 +0100], Alan Cox wrote:
> > On Thu, 24 Jul 2008 07:26:03 +0200
> > Ingo Molnar <[email protected]> wrote:
> >
> > >
> > > not sure it's known but despite all the fixes i still get:
> > >
> > > drivers/built-in.o: In function `ne_drv_resume':
> > > ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
> > > drivers/built-in.o: In function `ne_block_output':
> > > ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
> >
> > This should do the trick. I can't test it currently as that configuration
> > now fails to build with mm errors in current git head..
> >
> > mm/hugetlb.c: In function ???hugetlb_acct_memory???: mm/hugetlb.c:1507:
> > error: implicit declaration of function ???cpuset_mems_nr???
Remind me to give a wedgie to the next gcc developer I meet.
>
> When moving the intialization functions around, I did not remove the
> dependency of some helpers on CONFIG_SYSCTL. This led to a large chunk
> of code being elided even though it is needed to build hugetlb.o.
>
> Fixes a build failure reported by Alan Cox:
>
> mm/hugetlb.c: In function ______hugetlb_acct_memory______: mm/hugetlb.c:1507:
> error: implicit declaration of function ______cpuset_mems_nr______
And the next one.
LANG=C stomps this silliness.
> Signed-off-by: Nishanth Aravamudan <[email protected]>
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 41341c4..3be79dc 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1026,7 +1026,6 @@ static void __init report_hugepages(void)
> }
> }
>
> -#ifdef CONFIG_SYSCTL
> #ifdef CONFIG_HIGHMEM
> static void try_to_free_low(struct hstate *h, unsigned long count)
> {
> @@ -1386,6 +1385,7 @@ static unsigned int cpuset_mems_nr(unsigned int *array)
> return nr;
> }
>
> +#ifdef CONFIG_SYSCTL
> int hugetlb_sysctl_handler(struct ctl_table *table, int write,
> struct file *file, void __user *buffer,
> size_t *length, loff_t *ppos)
>
OK, we had a fix from Ingo but this one is better.
On 25.07.2008 [14:29:21 -0700], Andrew Morton wrote:
> On Fri, 25 Jul 2008 13:33:51 -0700
> Nishanth Aravamudan <[email protected]> wrote:
>
> > [resending with Linus' address fixed]
> >
> > On 25.07.2008 [18:09:35 +0100], Alan Cox wrote:
> > > On Thu, 24 Jul 2008 07:26:03 +0200
> > > Ingo Molnar <[email protected]> wrote:
> > >
> > > >
> > > > not sure it's known but despite all the fixes i still get:
> > > >
> > > > drivers/built-in.o: In function `ne_drv_resume':
> > > > ne.c:(.text+0x146ba4): undefined reference to `NS8390_init'
> > > > drivers/built-in.o: In function `ne_block_output':
> > > > ne.c:(.text+0x146e00): undefined reference to `NS8390_init'
> > >
> > > This should do the trick. I can't test it currently as that configuration
> > > now fails to build with mm errors in current git head..
> > >
> > > mm/hugetlb.c: In function ???hugetlb_acct_memory???: mm/hugetlb.c:1507:
> > > error: implicit declaration of function ???cpuset_mems_nr???
>
> Remind me to give a wedgie to the next gcc developer I meet.
This may have been C&P error on my part, sorry about that.
> > When moving the intialization functions around, I did not remove the
> > dependency of some helpers on CONFIG_SYSCTL. This led to a large chunk
> > of code being elided even though it is needed to build hugetlb.o.
> >
> > Fixes a build failure reported by Alan Cox:
> >
> > mm/hugetlb.c: In function ______hugetlb_acct_memory______: mm/hugetlb.c:1507:
> > error: implicit declaration of function ______cpuset_mems_nr______
>
> And the next one.
>
> LANG=C stomps this silliness.
Yep, I've fixed the configuration of this box (I hope).
Thanks,
Nish
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
On Fri, 25 Jul 2008, Nishanth Aravamudan wrote:
>
> [resending with Linus' address fixed]
Hmm, this doesn't apply for me any more. Can you check the current -git
tree?
Linus
On Fri, 25 Jul 2008 17:32:38 -0700 (PDT)
Linus Torvalds <[email protected]> wrote:
>
>
> On Fri, 25 Jul 2008, Nishanth Aravamudan wrote:
> >
> > [resending with Linus' address fixed]
>
> Hmm, this doesn't apply for me any more. Can you check the current -git
> tree?
>
Is OK, I have a fixed-up version here which I'm about to start testing.
On 25.07.2008 [17:44:56 -0700], Andrew Morton wrote:
> On Fri, 25 Jul 2008 17:32:38 -0700 (PDT)
> Linus Torvalds <[email protected]> wrote:
>
> >
> >
> > On Fri, 25 Jul 2008, Nishanth Aravamudan wrote:
> > >
> > > [resending with Linus' address fixed]
> >
> > Hmm, this doesn't apply for me any more. Can you check the current
> > -git tree?
> >
>
> Is OK, I have a fixed-up version here which I'm about to start testing.
Ah, I see that Linus had already picked up Ingo's fix
(e44d1b2998d62a1f2f4d7eb17b56ba396535509f). While that does fix the
build, it isn't really the right solution. I'm guessing Andrew's version
will be a revert (either real or in patch-form) of that commit and an
application of mine?
Thanks,
Nish
--
Nishanth Aravamudan <[email protected]>
IBM Linux Technology Center
On Fri, 25 Jul 2008 18:25:49 -0700 Nishanth Aravamudan <[email protected]> wrote:
> On 25.07.2008 [17:44:56 -0700], Andrew Morton wrote:
> > On Fri, 25 Jul 2008 17:32:38 -0700 (PDT)
> > Linus Torvalds <[email protected]> wrote:
> >
> > >
> > >
> > > On Fri, 25 Jul 2008, Nishanth Aravamudan wrote:
> > > >
> > > > [resending with Linus' address fixed]
> > >
> > > Hmm, this doesn't apply for me any more. Can you check the current
> > > -git tree?
> > >
> >
> > Is OK, I have a fixed-up version here which I'm about to start testing.
>
> Ah, I see that Linus had already picked up Ingo's fix
> (e44d1b2998d62a1f2f4d7eb17b56ba396535509f).
Yeah, that fixes the build but tosses out a storm of
unused-static-function warnings.
> While that does fix the
> build, it isn't really the right solution. I'm guessing Andrew's version
> will be a revert (either real or in patch-form) of that commit and an
> application of mine?
I'll fix it up.