Realtek 8187B wireless support with product id 0x8197/0x8189

(I am not on linux-wireless so please CC: me if replying)

This is a patch against compat-wireless-2008-06-14 to work with 2.6.25.6-55.fc9.x86_64 kernel headers. I am using it right now so it works for me, YMMV.

It is mostly a patch from Herton a few months ago to add support for
Realtek 8187B. Herton's patch was missing a little quirk change for usb endpoint 12 for management frame; and I ported it forward to current fedora 9 kernel headers.

The rest of the story is at:
https://bugzilla.redhat.com/show_bug.cgi?id=432280

I have a few questions during the porting:

- control->queue, which the herton's change used, for switching between 4 tramission queue at end point 6,7,5,4, has disappeared. I hard-coded 6 in this version, (see commemt #37 for background), but what's the correct way to do this in current wireless-2.6 code?

- compat-wireless seems to use a small inlined routine
from http://article.gmane.org/gmane.linux.kernel.wireless.general/15830,
which isn't in the redhat header yet. so I have added an ifndef at the top of rtl8187_dev.c . so the patch needs to have that part removed if commited to compat-wireless.

- obviously it is getting a bit painful to forward-port the patch every time something else changes or something else changes in the header... what can I do to make this go into wireless-2.6 ?

On Sun, Jun 15, 2008 at 12:59:54AM +0000, Hin-Tak Leung wrote:

Quoted 2 lines

The rest of the story is at:
https://bugzilla.redhat.com/show_bug.cgi?id=432280

ACK, same here. I'm an owner of a 'One A110' mini-laptop (see
http://a110wiki.de/wiki/Wireless) and the situation is really getting uncontrollable with a gazillion of tarballs and patches for the R8187B driver floating around, all of them with small differences...

(the ID on this laptop is 0bda:8189 btw)

I'm very interested to see something get merged upstream, and I'm also willing to test whatever needs testing on my hardware.

(I am not on linux-wireless so please CC: me if replying)

This is a patch against compat-wireless-2008-06-14 to work with 2.6.25.6-55.fc9.x86_64 kernel headers. I am using it right now so it works for me, YMMV.

It is mostly a patch from Herton a few months ago to add support for
Realtek 8187B. Herton's patch was missing a little quirk change for usb endpoint 12 for management frame; and I ported it forward to current fedora 9 kernel headers.

The rest of the story is at:
https://bugzilla.redhat.com/show_bug.cgi?id=432280

I have a few questions during the porting:

- control->queue, which the herton's change used, for switching between 4 tramission queue at end point 6,7,5,4, has disappeared. I hard-coded 6 in this version, (see commemt #37 for background), but what's the correct way to do this in current wireless-2.6 code?

- compat-wireless seems to use a small inlined routine
from http://article.gmane.org/gmane.linux.kernel.wireless.general/15830,
which isn't in the redhat header yet. so I have added an ifndef at the top of rtl8187_dev.c . so the patch needs to have that part removed if commited to compat-wireless.

- obviously it is getting a bit painful to forward-port the patch every time something else changes or something else changes in the header... what can I do to make this go into wireless-2.6 ?

I think I have forward-port the patch mostly correctly, but I'd like to hear about comments, etc and how to make it better...

Thanks for your effort on this issue. I am very proud of the way you and others have participated in improving this patch as documented in the bugzilla link above.

I apologize for having been slow to respond but I seem to constantly be buried in patches... That is even more true today since I have recently been on vacation. Still, this patch has been languishing in my mailbox too long!

Please review the guidelines here:

http://linux.yyz.us/patch-format.html

If possible, please wrap your changelog comment lines at 80 columns or less. Also you should probably include Signed-off-by lines from Herton and Pavel. And please include the patch inline if possible for easier review -- use a mailer that preserves whitespace correctly.

I may have more specific comments about the patch itself later, but now I really need to get caught-up on some other merging. I just wanted to ensure that you knew I was not (completely) ignoring your efforts! :-)

John W. Linville wrote:

Quoted 3 lines

I may have more specific comments about the patch itself later, but now I really need to get caught-up on some other merging. I just wanted to ensure that you knew I was not (completely) ignoring your efforts! :-)

I have been using this patch on my Level 1 WNC-0301USB device. There are still problems with the TX code as it can associate only about 1 try in 10, but RX seems to be fine. I have been too busy to sort out the problems, but I have fixed the patch to get rid of checkpatch warnings and errors, which includes the "Signed-off-by" lines.

Would you like me to send the updated version to you, or should I send it to linux-wireless and John?

Would you like me to send the updated version to you, or should I send it to linux-wireless and John?

One thing I noticed is that the 0x8187 USB ID seems to be used for both
plain and b devices, so I suspect we're going to need some more
intelligent probing than just basing it off USB ID. IIRC, the endpoint
descriptions are different?

--- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:
<snipped>

Quoted 4 lines

One thing I noticed is that the 0x8187 USB ID seems to be used for both plain and b devices, so I suspect we're going to need some more intelligent probing than just basing it off USB ID. IIRC, the endpoint descriptions are different?

This is my /proc/bus/usb/devices entry- anybody who has a 0x8187 which behaves like a 8187b posting theirs? You remember correctly - 8187 sends through endpoint 2, 8187b uses 4,5,6,7 and 12 (0x0c).
----------

T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=8197 Rev= 2.00
S:  Manufacturer=Manufacturer_Realtek
S:  Product=RTL8187B_WLAN_Adapter S:  SerialNumber=<masked>
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 9 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8187
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Quoted 1 line · Hin-Tak Leung

--- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:

Quoted 9 lines

E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

My device doesn't show up in /proc, but /sys/bus/usb/devices/1-5/product shows it to have the same Product string as yours, with a ProdID of 8187.

Quoted 2 lines · Larry Finger

Quoted 1 line · Hin-Tak Leung

--- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:

<snipped>

Quoted 11 lines

Quoted 9 lines

E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

My device doesn't show up in /proc, but /sys/bus/usb/devices/1-5/product shows it to have the same Product string as yours, with a ProdID of 8187.

<snipped>

Is your usbfs mounted? you should have an entry similiar to this in your fstab:
----------
none /proc/bus/usb usbfs auto 0 0
----------
and that gives you the /proc/bus/usb/devices entries. Most userland usb device drivers (libusb - scanners, ptp digital cameras) need the /proc/bus/usb hierachy to work.
The usb endpoint list is a functional difference between the 8187 and 8187b. (it runs to 0c for the 8187b, and does not have a 02 entry which the 8187 uses).

Do I understand correctly that it might be better to check for the existence of endpoint 02 for an 8187 device? Or would it be better to look for endpoint 12 to set it as an 8187B?

Quoted 1 line · Larry Finger

Do I understand correctly that it might be better to check for the existence of endpoint 02 for an 8187 device? Or would it be better to look for endpoint 12 to set it as an 8187B?

It's probably OK either way, but I would look at some number that takes more than just 2 values (true and false). Say, the number of endpoints would be such number. This way, it there is some elusive 8187A or 8187C, it may have a different number and won't be mistaken for known chipsets.

Of course, we cannot guarantee anything. It's just a matter of general sanity that may or may not help. But sometimes it helps.

Quoted 10 lines · Pavel Roskin

Quoted 1 line · Larry Finger

Do I understand correctly that it might be better to check for the existence of endpoint 02 for an 8187 device? Or would it be better to look for endpoint 12 to set it as an 8187B?

It's probably OK either way, but I would look at some number that takes more than just 2 values (true and false). Say, the number of endpoints would be such number. This way, it there is some elusive 8187A or 8187C, it may have a different number and won't be mistaken for known chipsets.

Quoted 2 lines

Of course, we cannot guarantee anything. It's just a matter of general sanity that may or may not help. But sometimes it helps.

Larry's 8187 indeed looks like a 8187B i.e. the OEM being naughty and needs some serious lashing there... where does it come from - what brand and what is it bundled with?

The 8187/8187b code actually *uses* the
endpoints to send management frames for association - that's a functional difference and it is not possible to drive a 8187 as if it is a 8187b or vice versa. In the absence of
more authoritative answers like reading from a register or something, counting
the endpoints - I would actually go a bit further and demand the used endpoints
being there and in the right direction and propertes (int/bulk) - would seem
to be a good idea. As for what to do "if things don't add up", at least a warning through dmesg "give the OEM some lashing for calling a 8187b 0x8187".

I think Larry's question could be re-phrased as: if there is a preculiar device with *both* end point 2 and endpoint 12, what to treat it as?

I would be inclined to treat it as the newer chip - but some big warning, or even refusing to carry on, is probably in order.

Herton's code also seem to distinguish revC/revD/revE of different 8187B's - I don't seem to have seen those distinctions in the original vendor code, but maybe I haven't look hard enough :-).

Hin-Tak Leung wrote:

Quoted 6 lines

Herton's code also seem to distinguish revC/revD/revE of different 8187B's -
I don't seem to have seen those distinctions in the original vendor code, but
maybe I haven't look hard enough :-).

I have not found them either. FWIW, my device is reported as RTL8187BvE V0 + rtl8225z2. The decision comes from rtl818x_ioread8(priv, (u8 *)0xFFE1), but I don't know what is at that address.

Larry

Quoted 5 lines · Pavel Roskin

Quoted 3 lines · Larry Finger

Do I understand correctly that it might be better to check for the existence of endpoint 02 for an 8187 device? Or would it be better to look for endpoint 12 to set it as an 8187B?

Quoted 8 lines

It's probably OK either way, but I would look at some number that takes more than just 2 values (true and false). Say, the number of endpoints would be such number. This way, it there is some elusive 8187A or 8187C, it may have a different number and won't be mistaken for known chipsets.

Of course, we cannot guarantee anything. It's just a matter of general sanity that may or may not help. But sometimes it helps.

Larry's 8187 indeed looks like a 8187B i.e. the OEM being naughty and needs some serious lashing there... where does it come from - what brand and what is it bundled with?

The 8187/8187b code actually *uses* the
endpoints to send management frames for association - that's a functional difference and it is not possible to drive a 8187 as if it is a 8187b or vice versa. In the absence of
more authoritative answers like reading from a register or something, counting the endpoints - I would actually go a bit further and demand the used endpoints being there and in the right direction and propertes (int/bulk) - would seem to be a good idea. As for what to do "if things don't add up", at least a warning through dmesg "give the OEM some lashing for calling a 8187b 0x8187".

I think Larry's question could be re-phrased as: if there is a preculiar device with *both* end point 2 and endpoint 12, what to treat it as?

I would be inclined to treat it as the newer chip - but some big warning, or even refusing to carry on, is probably in order.

Herton's code also seem to distinguish revC/revD/revE of different 8187B's
- I don't seem to have seen those distinctions in the original vendor code, but maybe I haven't look hard enough :-).

There are main 6 changes on the diff above:

- len is probably plcp_len field like on r818{0,5}, on vendor driver it was specified as 'length'
- To turn ANAPARAM off we need especial value like when turning on, for ANAPARAM*_OFF values I used the stock values from the hardware after a cold boot
- The write to the address 0xFFF0 seems to need always a write to ACM_CONTROL

drivers/net/wireless/rtl8187_dev.c renamed from drivers/net/wireless/rtl8187_dev.c.orig +1 -0

+	rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);

and does things in another order, so I moved code:

drivers/net/wireless/rtl8187_rtl8225.c renamed from drivers/net/wireless/rtl8187_rtl8225.c.orig +4 -1

+	rtl8225_write_phy_cck(dev, 0xc1, 0x88); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0x97, 0x46); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0xa4, 0x86); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0x85, 0xfb); msleep(1);
 
- I changed "static const u8 rtl8225z2_ofdm[]" because of when looking the usb

traffic with usbmon and ndiswrapper it was different in that values, the win driver has the values.

- I placed msleep(1) after write TX_ANTENNA, as all already in kernel realtek code need this why rtl8187b does not? Better to play safe.

As I don't have docs I have to appeal to this kind of things... sorry for the everything in one patch, I wasn't available to look more into this, but better post what I have found until now.

Small corrections to last message:

Em Thursday 26 June 2008 17:40:09 Herton Ronaldo Krzesinski escreveu:

Quoted 8 lines

There are main 6 changes on the diff above:

- len is probably plcp_len field like on r818{0,5}, on vendor driver it was specified as 'length'
- To turn ANAPARAM off we need especial value like when turning on, for ANAPARAM*_OFF values I used the stock values from the hardware after a cold boot
- The write to the address 0xFFF0 seems to need always a write to ACM_CONTROL

I mean 0xFFF0 to 0xFFFC

drivers/net/wireless/rtl8187_rtl8225.c void rtl8225z2_8187b_rf_init(struct ieee

Quoted 6 lines

after this with value '0', the vendor driver both on win/linux does this, was another mistake that I didn't see:

drivers/net/wireless/rtl8187_rtl8225.c renamed from drivers/net/wireless/rtl8187_rtl8225.c.orig +1 -1

 	rtl818x_iowrite32(priv, (__le32 *)0xFFF0, (7 << 12) | (3 << 8) | 28);
+	rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
 
- Win driver writes to 0xFF4E and , so I added the same thing:

"- Win driver writes to 0xFF4E, so I added the same thing:"

Quoted 7 lines

drivers/net/wireless/rtl8187_dev.c renamed from drivers/net/wireless/rtl8187_dev.c.orig +1 -0

+	rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);

and does things in another order, so I moved code:

drivers/net/wireless/rtl8187_rtl8225.c renamed from drivers/net/wireless/rtl8187_rtl8225.c.orig +4 -0

+	rtl8225_write_phy_cck(dev, 0xc1, 0x88); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0x97, 0x46); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0xa4, 0x86); msleep(1);
+	rtl8225_write_phy_ofdm(dev, 0x85, 0xfb); msleep(1);

Quoted 3 lines

- I changed "static const u8 rtl8225z2_ofdm[]" because of when looking the usb traffic with usbmon and ndiswrapper it was different in that values, the win driver has the values.

"- I changed "static const u8 rtl8225z2_ofdm[]" because of when looking the usb
traffic with usbmon and ndiswrapper it was different in that values" (drop last sentence)

Quoted 6 lines

- I placed msleep(1) after write TX_ANTENNA, as all already in kernel realtek code need this why rtl8187b does not? Better to play safe.

As I don't have docs I have to appeal to this kind of things... sorry for the everything in one patch, I wasn't available to look more into this, but better post what I have found until now.