Upstreaming tethering

[Adam Williamson]

Hi, all.

I'd like to have tethering with WM devices working out of the box in
Mandriva 2009.

(For anyone who doesn't know - 'tethering' is using the mobile device as
a modem, having it connected to your PC and letting your PC use its
internet connection).

Right now it seems that the usb_rndis_lite version of the kernel modules
supports this, but the kernel.org version doesn't. Diffing rndis_host.c
I can see this obvious difference:

@@ -576,7 +711,11 @@
/* "ActiveSync" is an undocumented variant of RNDIS, used in WM5 */
USB_INTERFACE_INFO(USB_CLASS_MISC, 1, 1),
.driver_info = (unsigned long) &rndis_info,
-},
+}, {
+ /* RNDIS for HTC tethering */
+ USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
+ .driver_info = (unsigned long) &rndis_info,
+},
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);

but is that all that's needed? Is there more? Is there any reason we
cannot submit this change to upstream kernel devs so we can have
tethering support in the kernel.org modules? Thanks!

[David Eriksson]

Post by Adam Williamson
Hi, all.
I'd like to have tethering with WM devices working out of the box in
Mandriva 2009.
(For anyone who doesn't know - 'tethering' is using the mobile device as
a modem, having it connected to your PC and letting your PC use its
internet connection).
Right now it seems that the usb_rndis_lite version of the kernel modules
supports this, but the kernel.org version doesn't. Diffing rndis_host.c
@@ -576,7 +711,11 @@
/* "ActiveSync" is an undocumented variant of RNDIS, used in WM5 */
USB_INTERFACE_INFO(USB_CLASS_MISC, 1, 1),
.driver_info = (unsigned long) &rndis_info,
-},
+}, {
+ /* RNDIS for HTC tethering */
+ USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
+ .driver_info = (unsigned long) &rndis_info,
+},
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
but is that all that's needed? Is there more? Is there any reason we
cannot submit this change to upstream kernel devs so we can have
tethering support in the kernel.org modules? Thanks!

Is this actually working? Can anyone confirm?


Best regards,

David Eriksson


http://www.divideandconquer.se/
--

[Adam Williamson]

Post by David Eriksson

Post by Adam Williamson
Hi, all.
I'd like to have tethering with WM devices working out of the box in
Mandriva 2009.
(For anyone who doesn't know - 'tethering' is using the mobile device as
a modem, having it connected to your PC and letting your PC use its
internet connection).
Right now it seems that the usb_rndis_lite version of the kernel modules
supports this, but the kernel.org version doesn't. Diffing rndis_host.c
@@ -576,7 +711,11 @@
/* "ActiveSync" is an undocumented variant of RNDIS, used in WM5 */
USB_INTERFACE_INFO(USB_CLASS_MISC, 1, 1),
.driver_info = (unsigned long) &rndis_info,
-},
+}, {
+ /* RNDIS for HTC tethering */
+ USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
+ .driver_info = (unsigned long) &rndis_info,
+},
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
but is that all that's needed? Is there more? Is there any reason we
cannot submit this change to upstream kernel devs so we can have
tethering support in the kernel.org modules? Thanks!

Is this actually working? Can anyone confirm?

It seems so, yes:

http://forum.eeeuser.com/viewtopic.php?id=36316

[John Carr]

Post by Adam Williamson

Post by David Eriksson

Post by Adam Williamson
Hi, all.
I'd like to have tethering with WM devices working out of the box in
Mandriva 2009.
(For anyone who doesn't know - 'tethering' is using the mobile device

as

Post by David Eriksson

Post by Adam Williamson
a modem, having it connected to your PC and letting your PC use its
internet connection).
Right now it seems that the usb_rndis_lite version of the kernel

modules

Post by David Eriksson

Post by Adam Williamson
supports this, but the kernel.org version doesn't. Diffing

rndis_host.c

Post by David Eriksson

Post by Adam Williamson
@@ -576,7 +711,11 @@
/* "ActiveSync" is an undocumented variant of RNDIS, used in WM5 */
USB_INTERFACE_INFO(USB_CLASS_MISC, 1, 1),
.driver_info = (unsigned long) &rndis_info,
-},
+}, {
+ /* RNDIS for HTC tethering */
+ USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
+ .driver_info = (unsigned long) &rndis_info,
+},
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
but is that all that's needed? Is there more? Is there any reason we
cannot submit this change to upstream kernel devs so we can have
tethering support in the kernel.org modules? Thanks!

Is this actually working? Can anyone confirm?

http://forum.eeeuser.com/viewtopic.php?id=36316
--
adamw

Yes it works. As far as I know, it needs a WM6 device though. Then you just
turn on internet connection sharing, connect your device, and boom, network
manager does the rest. (Or you need to dhclient the interface).

Adam, It needs a bit more than what you have. Not much, though. I landed my
tethering patch in r2998.

svn diff
https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite-r2997:2998

Enjoy
John

[Adam Williamson]

Post by John Carr
Yes it works. As far as I know, it needs a WM6 device though. Then you
just turn on internet connection sharing, connect your device, and
boom, network manager does the rest. (Or you need to dhclient the
interface).
Adam, It needs a bit more than what you have. Not much, though. I
landed my tethering patch in r2998.
svn diff
https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite
-r2997:2998

OK, great. So as I said - is there any potential problem with this which
would prevent it from being submitted to kernel.org folks? Or can we
send it there? And by we I mean 'you', as lkml scares me :)

[John Carr]

Post by Adam Williamson

Post by John Carr
Yes it works. As far as I know, it needs a WM6 device though. Then you
just turn on internet connection sharing, connect your device, and
boom, network manager does the rest. (Or you need to dhclient the
interface).
Adam, It needs a bit more than what you have. Not much, though. I
landed my tethering patch in r2998.
svn diff
https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite
-r2997:2998

OK, great. So as I said - is there any potential problem with this which
would prevent it from being submitted to kernel.org folks? Or can we
send it there? And by we I mean 'you', as lkml scares me :)
--
adamw

For anyone listening, we talked about this on IRC and Adam is upstreaming
this for us.

John

[Mark Ellis]

On Fri, Jul 18, 2008 at 8:15 PM, Adam Williamson

Post by John Carr
Yes it works. As far as I know, it needs a WM6 device

though. Then you

Post by John Carr
just turn on internet connection sharing, connect your

device, and

Post by John Carr
boom, network manager does the rest. (Or you need to

dhclient the

Post by John Carr
interface).
Adam, It needs a bit more than what you have. Not much,

though. I

Post by John Carr
landed my tethering patch in r2998.
svn diff

https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite

Post by John Carr
-r2997:2998

OK, great. So as I said - is there any potential problem with this which
would prevent it from being submitted to kernel.org folks? Or can we
send it there? And by we I mean 'you', as lkml scares me :)
--
adamw
For anyone listening, we talked about this on IRC and Adam is
upstreaming this for us.
John

Ok, whoa :)

I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.

I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.

To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.

In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

Mark

[Adam Williamson]

Post by Mark Ellis
Ok, whoa :)
I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.
I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.
To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.
In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

Doing it one thing at a time seems sane anyway. Submitting a big clump
of stuff would likely result in some of it getting held up by debates
about the other stuff. Tethering is a small, pretty safe (should be :>)
patch which has been tested to work, so I think it's OK to submit it on
its own.

The other big thing that I know of is John's infamous 'dirty patch' that
fixes -110 errors on certain devices (including several owned by MDV
users). He wants to clean this up before submitting it upstream. He says
he'll probably get time to work on this next week. That isn't even in
usb-rndis-lite SVN head, though - it's still a separate patch.

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis
Ok, whoa :)
I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.
I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.
To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.
In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

Doing it one thing at a time seems sane anyway. Submitting a big clump
of stuff would likely result in some of it getting held up by debates
about the other stuff. Tethering is a small, pretty safe (should be :>)
patch which has been tested to work, so I think it's OK to submit it on
its own.
The other big thing that I know of is John's infamous 'dirty patch' that
fixes -110 errors on certain devices (including several owned by MDV
users). He wants to clean this up before submitting it upstream. He says
he'll probably get time to work on this next week. That isn't even in
usb-rndis-lite SVN head, though - it's still a separate patch.
--

Agreed that submitting a big patch of unrelated items is bad.

I just think it may be a little simpler if we know that, at point A, we
had submitted everything we had, as patches 1,2, and 3. As I said, I
really don't know what has been submitted, what needs to be submitted.
If someone does, cool !

Mark

[Mark Ellis]

Post by Mark Ellis

Post by Adam Williamson

Post by Mark Ellis
Ok, whoa :)
I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.
I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.
To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.
In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

Doing it one thing at a time seems sane anyway. Submitting a big clump
of stuff would likely result in some of it getting held up by debates
about the other stuff. Tethering is a small, pretty safe (should be :>)
patch which has been tested to work, so I think it's OK to submit it on
its own.
The other big thing that I know of is John's infamous 'dirty patch' that
fixes -110 errors on certain devices (including several owned by MDV
users). He wants to clean this up before submitting it upstream. He says
he'll probably get time to work on this next week. That isn't even in
usb-rndis-lite SVN head, though - it's still a separate patch.
--

Agreed that submitting a big patch of unrelated items is bad.
I just think it may be a little simpler if we know that, at point A, we
had submitted everything we had, as patches 1,2, and 3. As I said, I
really don't know what has been submitted, what needs to be submitted.
If someone does, cool !
Mark

Actually, it would be cool if anything that went to lkml was just cc'd
to synce-devel ?

What is John's dirty patch ? Does it cover the Samsung timeout thing ?

Mark

[Adam Williamson]

Post by Mark Ellis
Ok, whoa :)
I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.
I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.
To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.
In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

OK, so here's the status now as far as I know:

The tethering patch has been committed today by David Brownell. So the
two major reasons for rndis-lite's existence are now no longer valid:
kernel.org git now has support for WM5 and WM6 devices, and for
tethering.

As I understand it, any remaining differences between the upstream code
and rndis-lite are now essentially details. I guess it would be feasible
to audit the remaining differences and submit any changes that are
actually useful upstream, with a view to killing usb-rndis-lite
permanently - would that be possible? David Brownell (upstream) is
explicitly interested in any remaining differences between the two: he'd
like to see rndis-lite go away through anything it does better being
merged upstream.

Aside from that the major remaining issue is the infamous John Carr
Dirty Patch, which he claims to be getting free time to work on this
week ;). If that could be cleaned up and upstreamed, I think we'd be in
good shape in terms of the upstream kernel doing everything synce needs.
Right? Or did I miss anything?

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis
Ok, whoa :)
I was all ready to start a 'kernel status' thread, and the train went
without me. Don't get me wrong, this is good, but is there anything else
we want to submit to the kernel guys ? Considering how long it took to
get to the stage we're at, it's worth thinking it through first.
I intended to have a good look through usb-rndis-lite and compare it to
the latest kernel before we had this discussion, but hey.
To my knowledge, and the quick browse I had, we don't have anything in
usbnet and cdc_ether that needs to be submitted.
In rndis_host, obviously there is the subject of this thread, but has
the Samsung timeout patch been submitted? Anyone know of anything else ?

The tethering patch has been committed today by David Brownell. So the
kernel.org git now has support for WM5 and WM6 devices, and for
tethering.

Hurrah !

Post by Adam Williamson
As I understand it, any remaining differences between the upstream code
and rndis-lite are now essentially details. I guess it would be feasible
to audit the remaining differences and submit any changes that are
actually useful upstream, with a view to killing usb-rndis-lite
permanently - would that be possible? David Brownell (upstream) is
explicitly interested in any remaining differences between the two: he'd
like to see rndis-lite go away through anything it does better being
merged upstream.

I'm not kernel'ly enough to spot subtle improvements. I did notice that
the timeout patch got included in a different form, which is good.

I guess usb-rndis-lite will still be around until all the common distros
are using later kernels, but at least we're on the right track.

Post by Adam Williamson
Aside from that the major remaining issue is the infamous John Carr
Dirty Patch, which he claims to be getting free time to work on this
week ;). If that could be cleaned up and upstreamed, I think we'd be in
good shape in terms of the upstream kernel doing everything synce needs.
Right? Or did I miss anything?
--
adamw

You guys have too much fun on #synce :) You've got me intrigued about
the Dirty Patch...

Mark

[John Carr]

Post by Mark Ellis

Post by Adam Williamson
Aside from that the major remaining issue is the infamous John Carr
Dirty Patch, which he claims to be getting free time to work on this
week ;). If that could be cleaned up and upstreamed, I think we'd be in
good shape in terms of the upstream kernel doing everything synce needs.
Right? Or did I miss anything?
--
adamw

You guys have too much fun on #synce :) You've got me intrigued about
the Dirty Patch...
Mark

The dirty patch, the thing of legends. It exists in SVN here:

http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch

As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.

The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Mark, you should come in #synce more... :-)

John

[Mark Ellis]

Post by John Carr
http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch
As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.
The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Yes, it's still lurking in the background :)

I'm casting for comments, I've had quite a few cases where this has
solved a connection problem, and I'd love to get it upstream. While I
can see what it's doing though, I can't _really_ see what it's doing.
I'm tempted to just take it as is to the usb guys and see what they
think, but wanted to throw it out to you guys first.

Help !

Ta
Mark

[Adam Williamson]

Post by Mark Ellis

Post by John Carr
http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch
As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.
The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Yes, it's still lurking in the background :)
I'm casting for comments, I've had quite a few cases where this has
solved a connection problem, and I'd love to get it upstream. While I
can see what it's doing though, I can't _really_ see what it's doing.
I'm tempted to just take it as is to the usb guys and see what they
think, but wanted to throw it out to you guys first.
Help !

don't ask me, you're the one who wrote it =)

seriously, I know practically zip about the code/hardware side of this
stuff, I am not a hacker. All I've ever worked on is the packaging. So,
um, sorry, but I've no clue.

[Mark Ellis]

Post by Adam Williamson

Post by Mark Ellis

Post by John Carr
http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch
As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.
The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Yes, it's still lurking in the background :)
I'm casting for comments, I've had quite a few cases where this has
solved a connection problem, and I'd love to get it upstream. While I
can see what it's doing though, I can't _really_ see what it's doing.
I'm tempted to just take it as is to the usb guys and see what they
think, but wanted to throw it out to you guys first.
Help !

don't ask me, you're the one who wrote it =)

Not me, John's the culprit :)

Post by Adam Williamson
seriously, I know practically zip about the code/hardware side of this
stuff, I am not a hacker. All I've ever worked on is the packaging. So,
um, sorry, but I've no clue.

No worries, you were just vaguely involved the last time this came up. I
don't know anything about the device driver side either (:

Mark

[John Carr]

Post by Mark Ellis

Post by Adam Williamson

Post by Mark Ellis

Post by John Carr
http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch
As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.
The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Yes, it's still lurking in the background :)
I'm casting for comments, I've had quite a few cases where this has
solved a connection problem, and I'd love to get it upstream. While I
can see what it's doing though, I can't _really_ see what it's doing.
I'm tempted to just take it as is to the usb guys and see what they
think, but wanted to throw it out to you guys first.
Help !

don't ask me, you're the one who wrote it =)

Not me, John's the culprit :)

Post by Adam Williamson
seriously, I know practically zip about the code/hardware side of this
stuff, I am not a hacker. All I've ever worked on is the packaging. So,
um, sorry, but I've no clue.

No worries, you were just vaguely involved the last time this came up. I
Mark

All i remember is examing the user space version of the driver and
noticing it had an extra poke that the kernel side didnt have, i then
tried to hack a similar poke into the kernel driver and came up with
that patch which *seems* to work for some devices, but i cant explain
why it works.

John

[Mark Ellis]

Post by John Carr

Post by Mark Ellis

Post by Adam Williamson

Post by Mark Ellis

Post by John Carr
http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/usb-rndis-lite-samsung.patch
As you can see, i force debug on because i have no idea whether the
patch is sane or not and i want all the debug info i can get. The
reason I consider it dirty is that it needs the rndis_get_in_endpoint
function which is called every time something calls rndis_command.
Ideally that should run once when the driver loads for a given device,
but i felt like i was being too invasive when I started doing that and
whimped out.
The patch exists through careful comparison of the deprecated user
mode and the current kernel mode implementations of usb-rndis, the
poking of an INT IN endpoint being the only difference i found.

Yes, it's still lurking in the background :)
I'm casting for comments, I've had quite a few cases where this has
solved a connection problem, and I'd love to get it upstream. While I
can see what it's doing though, I can't _really_ see what it's doing.
I'm tempted to just take it as is to the usb guys and see what they
think, but wanted to throw it out to you guys first.
Help !

don't ask me, you're the one who wrote it =)

Not me, John's the culprit :)

Post by Adam Williamson
seriously, I know practically zip about the code/hardware side of this
stuff, I am not a hacker. All I've ever worked on is the packaging. So,
um, sorry, but I've no clue.

No worries, you were just vaguely involved the last time this came up. I
Mark

All i remember is examing the user space version of the driver and
noticing it had an extra poke that the kernel side didnt have, i then
tried to hack a similar poke into the kernel driver and came up with
that patch which *seems* to work for some devices, but i cant explain
why it works.
John

Ok, I'll take it to the usb kernel guys when I get a chance and see what
they think. Thanks John.

Mark

[David Eriksson]

Post by John Carr
All i remember is examing the user space version of the driver and
noticing it had an extra poke that the kernel side didnt have, i then
tried to hack a similar poke into the kernel driver and came up with
that patch which *seems* to work for some devices, but i cant explain
why it works.

Maybe Ole André (oleavr) could be of some help here?


Best regards,

David, http://www.divideandconquer.se/


--

[Adam Williamson]

Post by John Carr
Adam, It needs a bit more than what you have. Not much, though. I
landed my tethering patch in r2998.
svn diff
https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite
-r2997:2998

For reference: the patch has to be modified slightly to apply to the
kernel.org code. One of our kernel guys (Thomas Backlund) did this and
it is now in our development kernel. It has been verified to work by at
least one user. The modified patch is:

http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/net-usb-wm6-tethering.patch?view=co

I will send this on to the kernel.org maintainer.

[Mark Ellis]

Post by Adam Williamson

Post by John Carr
Adam, It needs a bit more than what you have. Not much, though. I
landed my tethering patch in r2998.
svn diff
https://synce.svn.sourceforge.net/svnroot/synce/trunk/usb-rndis-lite
-r2997:2998

For reference: the patch has to be modified slightly to apply to the
kernel.org code. One of our kernel guys (Thomas Backlund) did this and
it is now in our development kernel. It has been verified to work by at
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/patches/net-usb-wm6-tethering.patch?view=co
I will send this on to the kernel.org maintainer.
--

Cool !