usb_autopm_*() removal build failure...

usb_autopm_*() removal build failure...

[David Miller]

These routines are referenced by code in drivers/net/usb/kaweth.c and
in a comment in drivers/net/wimax/i2400m/usb-tx.c

The former causes a build failure.

drivers/net/usb/kaweth.c: In function 'kaweth_open':
drivers/net/usb/kaweth.c:719: error: implicit declaration of function 'usb_autopm_enable'
  CC      lib/syscall.o
  CC [M]  drivers/net/tokenring/tmspci.o
  CC [M]  drivers/char/synclink_gt.o
make[3]: *** [drivers/net/usb/kaweth.o] Error 1
make[2]: *** [drivers/net/usb] Error 2
make[2]: *** Waiting for unfinished jobs....

Just FYI...

Re: usb_autopm_*() removal build failure...

[Greg KH]

On Fri, Dec 11, 2009 at 05:45:51PM -0800, David Miller wrote:
> 
> These routines are referenced by code in drivers/net/usb/kaweth.c and
> in a comment in drivers/net/wimax/i2400m/usb-tx.c
> 
> The former causes a build failure.
> 
> drivers/net/usb/kaweth.c: In function 'kaweth_open':
> drivers/net/usb/kaweth.c:719: error: implicit declaration of function 'usb_autopm_enable'
>   CC      lib/syscall.o
>   CC [M]  drivers/net/tokenring/tmspci.o
>   CC [M]  drivers/char/synclink_gt.o
> make[3]: *** [drivers/net/usb/kaweth.o] Error 1
> make[2]: *** [drivers/net/usb] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> Just FYI...

That was resolved with a patch that Oliver sent you a while ago.  I'll
dig it up and resend it.

thanks,

greg k-h

Re: usb_autopm_*() removal build failure...

[Greg KH]

On Fri, Dec 11, 2009 at 05:45:51PM -0800, David Miller wrote:
> 
> These routines are referenced by code in drivers/net/usb/kaweth.c and
> in a comment in drivers/net/wimax/i2400m/usb-tx.c
> 
> The former causes a build failure.
> 
> drivers/net/usb/kaweth.c: In function 'kaweth_open':
> drivers/net/usb/kaweth.c:719: error: implicit declaration of function 'usb_autopm_enable'
>   CC      lib/syscall.o
>   CC [M]  drivers/net/tokenring/tmspci.o
>   CC [M]  drivers/char/synclink_gt.o
> make[3]: *** [drivers/net/usb/kaweth.o] Error 1
> make[2]: *** [drivers/net/usb] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> Just FYI...

Here's the patch, sent back in August:
	 http://marc.info/?l=linux-netdev&m=125071045301270&w=2

Can you take it from there, or do you need me to forward it on?

thanks,

greg k-h

Re: usb_autopm_*() removal build failure...

[David Miller]

From: Greg KH <gregkh@suse.de>
Date: Fri, 11 Dec 2009 20:05:24 -0800

> Here's the patch, sent back in August:
> 	 http://marc.info/?l=linux-netdev&m=125071045301270&w=2
> 
> Can you take it from there, or do you need me to forward it on?

I tossed this into the net-2.6 tree, but...

I would recommend that in the future when you have the
dependency of an API change that's going to break the
build, you take in the necessary change.  And you make
sure such a commit is in your tree before the commit
that removes the API.

That posting had all the markings of something that wasn't
my business applying:

1) the subject said "usb" and nothing about networking or
   a specific networking driver

2) it was resolving an API issue introduced by another tree

This also means you weren't doing allmodconfig builds on your USB tree
this entire time, because if you had you would have realized that this
fix belonged there not in net-2.6 :-)  And if the USB bits were
going in via -next I'm really surprised Stephen Rothwell wasn't
complaining about this too :)

Anyways, next time, please resolve API issues internally when you
do things that will break the build otherwise.

We can merge it all together during the merge window just fine.

Thanks!

Re: usb_autopm_*() removal build failure...

[Greg KH]

On Fri, Dec 11, 2009 at 09:47:14PM -0800, David Miller wrote:
> From: Greg KH <gregkh@suse.de>
> Date: Fri, 11 Dec 2009 20:05:24 -0800
> 
> > Here's the patch, sent back in August:
> > 	 http://marc.info/?l=linux-netdev&m=125071045301270&w=2
> > 
> > Can you take it from there, or do you need me to forward it on?
> 
> I tossed this into the net-2.6 tree, but...
> 
> I would recommend that in the future when you have the
> dependency of an API change that's going to break the
> build, you take in the necessary change.  And you make
> sure such a commit is in your tree before the commit
> that removes the API.

I did at first, so I dropped the API change from my tree.  Then Alan and
Oliver pointed out that the changes were already in your tree, and I
looked and saw the first one, so just assumed the 2 other ones were
there, and turned off all network USB drivers in my build in order to
handle this.

Then yesterday, Stephen reported that this one driver failed to build,
which I didn't pick up on until today, after the tree had been sent to
Linus.

So, a mixup on my part, I'm sorry about that.

> Anyways, next time, please resolve API issues internally when you
> do things that will break the build otherwise.

Will do.

thanks for your patience.

greg k-h

Re: usb_autopm_*() removal build failure...

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Hi Dave,

On Fri, 11 Dec 2009 21:47:14 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> This also means you weren't doing allmodconfig builds on your USB tree
> this entire time, because if you had you would have realized that this
> fix belonged there not in net-2.6 :-)  And if the USB bits were
> going in via -next I'm really surprised Stephen Rothwell wasn't
> complaining about this too :)

I did - a posting on Dec 9 with subject "linux-next: staging tree build
failure" (which should have been "usb tree" - and I corrected that).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: usb_autopm_*() removal build failure...

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 12 Dec 2009 17:56:42 +1100

> Hi Dave,
> 
> On Fri, 11 Dec 2009 21:47:14 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>> This also means you weren't doing allmodconfig builds on your USB tree
>> this entire time, because if you had you would have realized that this
>> fix belonged there not in net-2.6 :-)  And if the USB bits were
>> going in via -next I'm really surprised Stephen Rothwell wasn't
>> complaining about this too :)
> 
> I did - a posting on Dec 9 with subject "linux-next: staging tree build
> failure" (which should have been "usb tree" - and I corrected that).

Awesome, my faith in the human race is restored :-)