[PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Hin-Tak Leung]

There was a problem with the integrated patch posted by Pavel on May 22 -
for those who did not get good result, please retry; We identified some code
for detecting early 8187B's with an 8187 id which seems to have a weaker
chip and Larry is working on a 7th patch for it - people having 8187B's with an
0x8187 id should get in touch.

Each of the 6 passes checkpatch.pl, and compiles cleanly with wireless-testing 
head one after the other. The first two modifies the header files, the 3rd adds
radio routines. 4th and 5th modifies the main driver code and the division
is somewhat arbitrary; the 6th updates Kconfig.

---------
rtl8187: Adding Realtek rtl8187B support

Herton wrote most of this based on the Realtek vendor driver, with
contributions from John W. Linville and feedbacks from Pavel. Hin-Tak
fixed tranmission of management frames and got it to work. Pavel removed
procfs support and tidied up the patch. Larry split the patch into 6 parts.

HTL, 2008-07-01:
There is occasional problem with unloading - modprobe -r and ksoftirqd
takes up all CPU time (on x86_64, dual core).

HRK, 2008-04-09:
Rate control doesn't work for 8187b, for 8187 it never worked either.
If you set rate manually to something lower (I found that for 2-3 meters
from AP 11M seems to be the best setting) it works much better (there aren't
stalls/packet drops).

PR, 2008-05-22:
The driver loads and initializes the device successfully.  Bringing the
interface up is very slow (10 to 20 seconds), but it works.  Scanning
works, ... [Edited] Association to APs without encryption works ...
[Edited] Unloading the module is working.

Matthew Garrett wrote on 2008-06-23:
Some vendors are shipping 8187bs with the 0x8187 product id, so the driver
really needs to probe rather than having a static setup of which is which.

Hauke Mehrtens wrote on 2008-01-12 regarding 8187 rate control:
If the rate goes over 11M no TCP/IP traffic goes through the wireless
connecting. If rate is set to auto and the rate control algorithm changes
it to something less than 11M TCP/IP traffic goes through, but if it is more
than 11M no TCP/IP traffic goes through the wireless link. With
"iwconfig wlan0 rate 11M" everything works.

Michael Wu wrote on 6 Nov 2007 on 8187 rate control:
.... you can find the specs for the 8186 floating around on the net
which tells you a bit about the registers. Doesn't tell you anything about
the rx/tx path of the usb variant, which is a bit inferior to the rx/tx path
of the pci chips. There's no easy way to do tx ack reporting on the rtl8187.
The only solutions that could work involve some polling or a different rate
control algorithm.

[PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Hin-Tak Leung]

- Apologies for posting this twice - forgot I have another e-mail account
which doesn't wrap lines :-).

There was a problem with the integrated patch posted by Pavel on May 22 -
for those who did not get good result, please retry; We identified some code
for detecting early 8187B's with an 8187 id which seems to have a weaker
chip and Larry is working on a 7th patch for it - people having 8187B's with an
0x8187 id should get in touch.

---------
rtl8187: Adding Realtek rtl8187B support

[PATCH 1/6] rtl8187: updating rtl8187.h to support RTL8187B
[PATCH 2/6] rtl8187: updating rtl818x.h to support RTL8187B
[PATCH 3/6] rtl8187: updating rtl8187_rtl8225.c to support RTL8187B
[PATCH 4/6] rtl8187: change part 1 of rtl8187_dev.c to support RTL8187B
[PATCH 5/6] rtl8187: change part 2 of rtl8187_dev.c to support RTL8187B
[PATCH 6/6] rtl8187: updating Kconfig to support RTL8187B

Herton wrote most of this based on the Realtek vendor driver, with
contributions from John W. Linville and feedbacks from Pavel. Hin-Tak
fixed tranmission of management frames and got it to work. Pavel removed
procfs support and tidied up the patch. Larry split the patch into 6 parts.

HTL, 2008-07-01:
There is occasional problem with unloading - modprobe -r and ksoftirqd
takes up all CPU time (on x86_64, dual core).

HRK, 2008-04-09:
Rate control doesn't work for 8187b, for 8187 it never worked either.
If you set rate manually to something lower (I found that for 2-3 meters
from AP 11M seems to be the best setting) it works much better (there aren't
stalls/packet drops).

PR, 2008-05-22:
The driver loads and initializes the device successfully.  Bringing the
interface up is very slow (10 to 20 seconds), but it works.  Scanning
works, ... [Edited] Association to APs without encryption works ...
[Edited] Unloading the module is working.

Matthew Garrett wrote on 2008-06-23:
Some vendors are shipping 8187bs with the 0x8187 product id, so the driver
really needs to probe rather than having a static setup of which is which.

Hauke Mehrtens wrote on 2008-01-12 regarding 8187 rate control:
If the rate goes over 11M no TCP/IP traffic goes through the wireless
connecting. If rate is set to auto and the rate control algorithm changes
it to something less than 11M TCP/IP traffic goes through, but if it is more
than 11M no TCP/IP traffic goes through the wireless link. With
"iwconfig wlan0 rate 11M" everything works.

Michael Wu wrote on 6 Nov 2007 on 8187 rate control:
... you can find the specs for the 8186 floating around on the net
which tells you a bit about the registers. Doesn't tell you anything about
the rx/tx path of the usb variant, which is a bit inferior to the rx/tx path
of the pci chips. There's no easy way to do tx ack reporting on the rtl8187.
The only solutions that could work involve some polling or a different rate
control algorithm.

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Larry Finger]

Hin-Tak,

Good job getting these posted. For the first time in a long time, my unit was 
able to connect and authenticate. It certainly looks as if you solved the ep12 
problem. I'm using the device to write this E-mail.

Unfortunately, your mailer still wrapped some lines in the patches. It wasn't 
difficult to repair them, but it still is a bother. For the next round, we can 
work out a procedure that uses the mail utility to send the patches. I've used 
this method since Linville was unable to process my patches that were sent from 
Thunderbird.

The patch to revise the detection of B units with an 8187 ID is ready. I can 
send it at any time.

Larry

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[John W. Linville]

On Tue, Jul 08, 2008 at 08:39:36AM -0500, Larry Finger wrote:
> Hin-Tak,
>
> Good job getting these posted. For the first time in a long time, my unit 
> was able to connect and authenticate. It certainly looks as if you solved 
> the ep12 problem. I'm using the device to write this E-mail.
>
> Unfortunately, your mailer still wrapped some lines in the patches. It 
> wasn't difficult to repair them, but it still is a bother. For the next 
> round, we can work out a procedure that uses the mail utility to send the 
> patches. I've used this method since Linville was unable to process my 
> patches that were sent from Thunderbird.

FWIW, git-send-email does a decent job.  If you commit your patches
in a git tree, you can use git-format-patch to extract them and then
git-send-email to send them out -- works fairly well.

> The patch to revise the detection of B units with an 8187 ID is ready. I 
> can send it at any time.

Please do!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Hin-Tak Leung]

On Tue, Jul 8, 2008 at 2:39 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Hin-Tak,
>
> Good job getting these posted. For the first time in a long time, my unit
> was able to connect and authenticate. It certainly looks as if you solved
> the ep12 problem. I'm using the device to write this E-mail.

Very good! I am wondering about whether Pavel's negative experience came
from the accidental brokenness after tidy up. The clean version is so
obviously cleaner,
except it moved the management frame decision after skb_pull() which
munched skb.
That's so *unobvious* - I don't expect any structs with ->data, etc to
be mutate.

I only spotted the difference when I load the two modules one
after the other and I wasn't getting the same connectivity -
and looked at the diffs from usbmon in debugfs. (obviously
if I am sending in the patches I need to "eat-my-own-dog-food").

> Unfortunately, your mailer still wrapped some lines in the patches. It
> wasn't difficult to repair them, but it still is a bother. For the next
> round, we can work out a procedure that uses the mail utility to send the
> patches. I've used this method since Linville was unable to process my
> patches that were sent from Thunderbird.

Damn... Yes, I just looked at my gmail Sent folder and saw that.
What do people do to send in-line patches? I guess I have to learn to use
git-send-email properly. This is too hard :-).

> The patch to revise the detection of B units with an 8187 ID is ready. I can
> send it at any time.

Only you have the right hardware to test, so go ahead and post if you
are happy with the change.

Hin-Tak

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Hin-Tak Leung]

On Tue, Jul 8, 2008 at 3:04 PM, John W. Linville <linville@tuxdriver.com> wrote:
> FWIW, git-send-email does a decent job.  If you commit your patches
> in a git tree, you can use git-format-patch to extract them and then
> git-send-email to send them out -- works fairly well.

Sorry for send this out a 3rd time! took me a couple of hours to get
git-send-email to work fo me :-).
I hope this last round is correct... (or I'll have to throw in the towel...).

Hin-Tak

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[John W. Linville]

On Tue, Jul 08, 2008 at 05:24:26PM +0100, Hin-Tak Leung wrote:
> On Tue, Jul 8, 2008 at 3:04 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > FWIW, git-send-email does a decent job.  If you commit your patches
> > in a git tree, you can use git-format-patch to extract them and then
> > git-send-email to send them out -- works fairly well.
> 
> Sorry for send this out a 3rd time! took me a couple of hours to get
> git-send-email to work fo me :-).
> I hope this last round is correct... (or I'll have to throw in the towel...).

It looks better, although FWIW I was able to fix-up the 2nd round by
hand without much problems. :-)

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Hin-Tak Leung]

On Tue, Jul 8, 2008 at 8:02 PM, John W. Linville <linville@tuxdriver.com> wrote:
<snipped>
> It looks better, although FWIW I was able to fix-up the 2nd round by
> hand without much problems. :-)

Wow, you have already committed to wireless-testing... that means it
will be on fedora 9 soon :-).

Thanks a lot.

Hin-Tak

Re: [PATCH 0/6] rtl8187: Adding Realtek rtl8187B support

[Pavel Roskin]

Quoting Hin-Tak Leung <hintak.leung@gmail.com>:

> On Tue, Jul 8, 2008 at 8:02 PM, John W. Linville   
> <linville@tuxdriver.com> wrote:
> <snipped>
>> It looks better, although FWIW I was able to fix-up the 2nd round by
>> hand without much problems. :-)
>
> Wow, you have already committed to wireless-testing... that means it
> will be on fedora 9 soon :-).

I've tested the latest wireless-testing.  It's working with both  
rtl8187 and 8187b, which is great!

The time of bringing the interface up are significant in both cases:  
7.5 seconds for rtl8187 and 15 seconds for rtl8187b.

I was able to connect to a WPA2 enabled AP with both devices.   
Unfortunately, I've seen the same problem with both devices.  If  
wpa_supplicant is running, there is a 50% probability that it would  
fail to connect initially, and all further scans will come empty.   
I've seen a similar problem with a PCI based rtl8185, although it was  
less likely.

Anyway, both rtl8187 and rtl8187b are working equally well, except  
that the startup time is twice as long for rtl8187b.

-- 
Regards,
Pavel Roskin