(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...
__________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
--- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:
<snipped>
> 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
------------
__________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Pavel Roskin wrote:
> On Thu, 2008-06-26 at 13:33 -0500, Larry Finger wrote:
>
>> 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.
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 :-).
Herton Ronaldo Krzesinski wrote:
> Small corrections to last message:
>
> Em Thursday 26 June 2008 17:40:09 Herton Ronaldo Krzesinski escreveu:
>> 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
>
>> after this with value '0', the vendor driver both on win/linux does this, was
>> another mistake that I didn't see:
>> 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:"
>
>> + rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);
>> and does things in another order, so I moved code:
>> + 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 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)
>
>> - 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.
I have put your patch into the wireless-testing code. So far, I have
not seen any particular improvement in the performance, etc. of the
device, but I'll continue to play with it.
Larry
Larry Finger wrote:
> Hin-Tak Leung wrote:
>> --- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:
<snipped>
>> 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).
Em Thursday 26 June 2008 17:44:43 Larry Finger escreveu:
> Hin-Tak Leung wrote:
<snip>
>
> > 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.
In the vendor driver this is commented as being the 8187B hardware version
register (it's a raw value address used in the code with a comment). I should
have commented the line as something like "read 8187b hardware version
register", or may be add a field to struct rtl818x_csr. One more thing to add
to the patch. In fact I would like to have a datasheet or ask to someone that
has to confirm this.
>
> Larry
>
--
[]'s
Herton
On Sun, Jun 15, 2008 at 12:59:54AM +0000, Hin-Tak Leung wrote:
> (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 ?
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.
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Hin-Tak Leung wrote:
>
>
> Larry Finger wrote:
>> Hin-Tak Leung wrote:
>>> --- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:
> <snipped>
>>> 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).
My fstab entry was set "noauto". Once it was mounted, then it shows
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=8187 Rev= 2.00
S: Manufacturer=Manufacturer_Realtek
S: Product=RTL8187B_WLAN_Adapter
S: SerialNumber=00e04c000001
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
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?
Larry
Hin-Tak Leung wrote:
> Pavel Roskin wrote:
>> On Thu, 2008-06-26 at 13:33 -0500, Larry Finger wrote:
>>
>>> 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.
>
> 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?
It is a Level One WNC-0301USB dongle. I bought it as an interim
replacement when the PCIe interface in my laptop expired and I could
not get it fixed at that time. I was quite put out when Linux couldn't
drive it as I needed Linux for my E-mail and it had to be wireless. I
tried ndiswrapper with it, but that didn't work either. I finally
settled on running Windows XP with Linux as a virtual machine running
under VirtualBox. It wasn't pretty, but it worked.
> 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".
Good idea. It probably won't change anything other than make us feel good.
> 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.
I will prepare a patch with these warnings.
> 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
On Wed, Jun 25, 2008 at 09:59:05AM -0500, Larry Finger wrote:
> 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?
--
Matthew Garrett | [email protected]
John W. Linville wrote:
>
> 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! :-)
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?
Larry
Hin-Tak Leung wrote:
> --- On Thu, 26/6/08, Matthew Garrett <[email protected]> wrote:
> <snipped>
>> 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
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.
Does anyone have an 8187b with an ProdID of 0x8187 and a Product
string that does not say 8187B?
Larry
(am still not on linux-wireless, please cc: when replying...)
Larry Finger wrote:
> John W. Linville wrote:
<snipped>
>> 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! :-)
Great - I have checked out the whole git of wireless-testing a few days ago
and will try to find some time to track down how some of the recent changes
elsewhere broke, and do some of the stuff 'properly'.
> 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?
Both and/or attaching to the redhat bugzilla :-). (have as many people
seeing/testing...) There is a newer vendor driver out from the one Herton based
on, so that might fix something; also the control queue switching I mentioned in
the my forward port effort may have something to do with that.
Cheers, and looking forward to moving this forward :-).
Hin-Tak
On Sun, Jun 15, 2008 at 12:59:54AM +0000, Hin-Tak Leung wrote:
> (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! :-)
Thanks,
John
--
John W. Linville
[email protected]
(I am not on linux-wireless so please CC: me if replying)
Uwe Hermann wrote:
> On Sun, Jun 15, 2008 at 12:59:54AM +0000, Hin-Tak Leung wrote:
<snipped>
>> The rest of the story is at:
>> https://bugzilla.redhat.com/show_bug.cgi?id=432280
<snipped>
> 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.
Yes, this is getting out of hand! Your page actually contains a few forked
code I don't know about... I think I can summarize the situation as this:
1) there are two main branches of drivers which work to various extent with
various kernel versions, excluding ndiswrapper usage. One is a vendor driver
(I had 1024.0822.2007, but the 1031.0125.2008 on one's web site seems to be
newer) based on the old pre-2.6.22 stack, and Herton's rewrite based on the new
mac80211 stack.
2) the vendor driver (and the old stack) is considered dead-end by the
linux-wireless people; also it suffers from "bit-rot" as it is largely
unmaintained (there is no identifiable person to contact, and this is the first
time I heard of the one's web site newer version) and can't keep up with
progress in the rest of the kernel.
3) Herton's driver (I think he didn't have the actual hardware) was missing
a couple of lines about the management frames (details in the redhat bugzilla)
so in its original form can scan but can't associate; it was considered at one
point to be included in the kernel a few months ago. It also suffers from some
extent of bit-rot in the last couple of months. I think I am the one currently
maintaining it, and various CC: in the redhat bugzilla has reported success with
current kernel.
So I propose these steps:
1) I think Herton wrote the new code based on 1024.0822 . We need to find out
a) any useful difference between 1024.0822 and 1031.0125
b) did herton have any doubts, etc while looking at 1024.0822?
2) anybody wants to review the difference of my update on herton's?
The most important and necessary part is the management frames change, the
rest is just to cope with bit-rot; I explained that I needed to add an inline
(which should be taken out when added to wireless-testing), and
I don't know where the multi-queue data structure has gone, so I have
hardcoded 6. I am willing to answer any questions or go over why I changed
what I have changed to stop the bit rotting going any further.
Any patch would bit-rot if it doesn't go into the rest of the wireless stack,
so we should get this done.
Hin-Tak
Small corrections to last message:
Em Thursday 26 June 2008 17:40:09 Herton Ronaldo Krzesinski escreveu:
>
> 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
> after this with value '0', the vendor driver both on win/linux does this, was
> another mistake that I didn't see:
> 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:"
> + rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);
> and does things in another order, so I moved code:
> + 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 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)
> - 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.
>
--
[]'s
Herton
Em Thursday 26 June 2008 16:45:34 Hin-Tak Leung escreveu:
> Pavel Roskin wrote:
> > On Thu, 2008-06-26 at 13:33 -0500, Larry Finger wrote:
> >> 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.
>
> 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 :-).
The vendor driver I have here uses this revision information of 8187B inside
rtl8225z2_SetTXPowerLevel function, for changing of radio registers. Do you
have this too? It only checks if it's a 8187B of revB or not.
Also not using endpoint 12 for management frames was indeed a bug in original
patch. As a curious thing, I tried too to debug the rtl8187b using the
windows driver under ndiswrapper while analysing the traffic of commands with
usbmon, I noted that the windows driver does a different setup, in fact the
initialization is almost the same but later it starts to write data to index
1304, ie:
c6d1eb80 286218884 S Co:1:003:0 s 40 04 0000 1304 0002 2 = 700b
c6d1eb80 286219207 C Co:1:003:0 0 2 >
c6d1eb80 286220241 S Co:1:003:0 s 40 04 0000 1304 0002 2 = 01ee
c6d1eb80 286220583 C Co:1:003:0 0 2 >
c6d1eb80 286221617 S Co:1:003:0 s 40 04 0000 1304 0002 2 = d244
c6d1eb80 286221957 C Co:1:003:0 0 2 >
c6d1eb80 286222990 S Co:1:003:0 s 40 04 0000 1304 0002 2 = 1344
c6d1eb80 286223330 C Co:1:003:0 0 2 >
The linux driver from realtek doesn't do this until where I could see. I tried
to emulate the same behaviour but didn't got good results so I dropped it.
Also when debugging this and checking registers I noticed other small errors
in original patch too, the following is not a ready to apply patch (and not
diffed against latest wireless-testing), just to get the idea and I'll comment
the parts:
diff -p -up linux-2.6.24/drivers/net/wireless/rtl8187.h.orig linux-2.6.24/drivers/net/wireless/rtl8187.h
--- linux-2.6.24/drivers/net/wireless/rtl8187.h.orig 2008-06-25 13:22:17.000000000 -0400
+++ linux-2.6.24/drivers/net/wireless/rtl8187.h 2008-06-25 13:22:54.000000000 -0400
@@ -76,7 +76,7 @@ struct rtl8187_tx_hdr {
struct rtl8187b_tx_hdr {
__le32 flags;
__le16 rts_duration;
- __le16 len;
+ __le16 plcp_len;
__le32 unused_1;
__le16 unused_2;
__le16 tx_duration;
diff -p -up linux-2.6.24/drivers/net/wireless/rtl8187_dev.c.orig linux-2.6.24/drivers/net/wireless/rtl8187_dev.c
--- linux-2.6.24/drivers/net/wireless/rtl8187_dev.c.orig 2008-06-25 13:24:34.000000000 -0400
+++ linux-2.6.24/drivers/net/wireless/rtl8187_dev.c 2008-06-25 15:25:07.000000000 -0400
@@ -377,8 +377,8 @@ static int rtl8187_init_hw(struct ieee80
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg | RTL818X_CONFIG3_ANAPARAM_WRITE);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8225_ANAPARAM_ON);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8187_RTL8225_ANAPARAM_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8187_RTL8225_ANAPARAM2_ON);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg & ~RTL818X_CONFIG3_ANAPARAM_WRITE);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL);
@@ -397,8 +397,8 @@ static int rtl8187_init_hw(struct ieee80
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg | RTL818X_CONFIG3_ANAPARAM_WRITE);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8225_ANAPARAM_ON);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8187_RTL8225_ANAPARAM_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8187_RTL8225_ANAPARAM2_ON);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg & ~RTL818X_CONFIG3_ANAPARAM_WRITE);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL);
@@ -506,9 +506,9 @@ static int rtl8187b_init_hw(struct ieee8
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
reg |= RTL818X_CONFIG3_ANAPARAM_WRITE | RTL818X_CONFIG3_GNT_SELECT;
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, 0x727f3f52);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM, 0x45090658);
- rtl818x_iowrite8(priv, &priv->map->ANAPARAM3, 0);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8187B_RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8187B_RTL8225_ANAPARAM_ON);
+ rtl818x_iowrite8(priv, &priv->map->ANAPARAM3, RTL8187B_RTL8225_ANAPARAM3_ON);
rtl818x_iowrite8(priv, (u8 *)0xFF61, 0x10);
reg = rtl818x_ioread8(priv, (u8 *)0xFF62);
@@ -566,6 +566,8 @@ static int rtl8187b_init_hw(struct ieee8
rtl818x_iowrite32(priv, &priv->map->RF_TIMING, 0x00004001);
+ rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);
+
rtl818x_iowrite16_idx(priv, (__le16 *)0xFF72, 0x569A, 2);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
diff -p -up linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.c.orig linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.c
--- linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.c.orig 2008-06-25 13:28:37.000000000 -0400
+++ linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.c 2008-06-25 15:29:33.000000000 -0400
@@ -306,7 +306,7 @@ void rtl8225_rf_set_tx_power(struct ieee
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg | RTL818X_CONFIG3_ANAPARAM_WRITE);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8187_RTL8225_ANAPARAM2_ON);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg & ~RTL818X_CONFIG3_ANAPARAM_WRITE);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL);
@@ -489,10 +489,10 @@ static const u8 rtl8225z2_ofdm[] = {
0x00, 0x60, 0x00, 0x00, 0x00, 0x5c, 0x00, 0x00,
0x40, 0x00, 0x40, 0x00, 0x00, 0x00, 0xa8, 0x26,
0x32, 0x33, 0x07, 0xa5, 0x6f, 0x55, 0xc8, 0xb3,
- 0x0a, 0xe1, 0x2C, 0x8a, 0x86, 0x83, 0x34, 0x0f,
+ 0x0a, 0xe1, 0x2c, 0x4a, 0x86, 0x83, 0x34, 0x0f,
0x4f, 0x24, 0x6f, 0xc2, 0x6b, 0x40, 0x80, 0x00,
0xc0, 0xc1, 0x58, 0xf1, 0x00, 0xe4, 0x90, 0x3e,
- 0x6d, 0x3c, 0xfb, 0x07
+ 0x6d, 0x3c, 0xfb, 0xc7
};
static const u8 rtl8225z2_tx_power_cck_ch14[] = {
@@ -557,7 +557,7 @@ void rtl8225z2_8187_rf_set_tx_power(stru
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg | RTL818X_CONFIG3_ANAPARAM_WRITE);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8225_ANAPARAM2_ON);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8187_RTL8225_ANAPARAM2_ON);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg & ~RTL818X_CONFIG3_ANAPARAM_WRITE);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL);
@@ -866,7 +866,7 @@ void rtl8225z2_8187b_rf_init(struct ieee
rtl818x_iowrite8(priv, &priv->map->TX_GAIN_CCK, 0x03);
rtl818x_iowrite8(priv, &priv->map->TX_GAIN_OFDM, 0x07);
- rtl818x_iowrite8(priv, &priv->map->TX_ANTENNA, 0x03);
+ rtl818x_iowrite8(priv, &priv->map->TX_ANTENNA, 0x03); msleep(1);
rtl8225_write_phy_ofdm(dev, 0x80, 0x12);
for (i = 0; i < ARRAY_SIZE(rtl8225z2_agc); i++) {
@@ -879,6 +879,10 @@ void rtl8225z2_8187b_rf_init(struct ieee
for (i = 0; i < ARRAY_SIZE(rtl8225z2_ofdm); i++) {
rtl8225_write_phy_ofdm(dev, i, rtl8225z2_ofdm[i]);
}
+ 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);
rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
rtl818x_iowrite8(priv, &priv->map->SLOT, 9);
@@ -889,15 +893,13 @@ void rtl8225z2_8187b_rf_init(struct ieee
rtl818x_iowrite8(priv, (u8 *)0xFF2D, 0x5B);
rtl818x_iowrite8(priv, (u8 *)0xFF79, 0x5B);
rtl818x_iowrite32(priv, (__le32 *)0xFFF0, (7 << 12) | (3 << 8) | 28);
+ rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
rtl818x_iowrite32(priv, (__le32 *)0xFFF4, (7 << 12) | (3 << 8) | 28);
+ rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
rtl818x_iowrite32(priv, (__le32 *)0xFFF8, (7 << 12) | (3 << 8) | 28);
+ rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
rtl818x_iowrite32(priv, (__le32 *)0xFFFC, (7 << 12) | (3 << 8) | 28);
rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
-
- rtl8225_write_phy_ofdm(dev, 0x97, 0x46); msleep(1);
- rtl8225_write_phy_ofdm(dev, 0xa4, 0xb6); msleep(1);
- rtl8225_write_phy_ofdm(dev, 0x85, 0xfc); msleep(1);
- rtl8225_write_phy_cck(dev, 0xc1, 0x88); msleep(1);
}
void rtl8225_rf_stop(struct ieee80211_hw *dev)
@@ -910,8 +912,19 @@ void rtl8225_rf_stop(struct ieee80211_hw
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
reg = rtl818x_ioread8(priv, &priv->map->CONFIG3);
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg | RTL818X_CONFIG3_ANAPARAM_WRITE);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM2, RTL8225_ANAPARAM2_OFF);
- rtl818x_iowrite32(priv, &priv->map->ANAPARAM, RTL8225_ANAPARAM_OFF);
+ if (!priv->is_rtl8187b) {
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2,
+ RTL8187_RTL8225_ANAPARAM2_OFF);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM,
+ RTL8187_RTL8225_ANAPARAM_OFF);
+ } else {
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM2,
+ RTL8187B_RTL8225_ANAPARAM2_OFF);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM,
+ RTL8187B_RTL8225_ANAPARAM_OFF);
+ rtl818x_iowrite32(priv, &priv->map->ANAPARAM3,
+ RTL8187B_RTL8225_ANAPARAM3_OFF);
+ }
rtl818x_iowrite8(priv, &priv->map->CONFIG3, reg & ~RTL818X_CONFIG3_ANAPARAM_WRITE);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_NORMAL);
}
diff -p -up linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.h.orig linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.h
--- linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.h.orig 2008-06-25 15:13:28.000000000 -0400
+++ linux-2.6.24/drivers/net/wireless/rtl8187_rtl8225.h 2008-06-25 15:20:41.000000000 -0400
@@ -15,10 +15,17 @@
#ifndef RTL8187_RTL8225_H
#define RTL8187_RTL8225_H
-#define RTL8225_ANAPARAM_ON 0xa0000a59
-#define RTL8225_ANAPARAM2_ON 0x860c7312
-#define RTL8225_ANAPARAM_OFF 0xa00beb59
-#define RTL8225_ANAPARAM2_OFF 0x840dec11
+#define RTL8187_RTL8225_ANAPARAM_ON 0xa0000a59
+#define RTL8187_RTL8225_ANAPARAM2_ON 0x860c7312
+#define RTL8187_RTL8225_ANAPARAM_OFF 0xa00beb59
+#define RTL8187_RTL8225_ANAPARAM2_OFF 0x840dec11
+
+#define RTL8187B_RTL8225_ANAPARAM_ON 0x45090658
+#define RTL8187B_RTL8225_ANAPARAM2_ON 0x727f3f52
+#define RTL8187B_RTL8225_ANAPARAM3_ON 0x00
+#define RTL8187B_RTL8225_ANAPARAM_OFF 0x55480658
+#define RTL8187B_RTL8225_ANAPARAM2_OFF 0x72003f50
+#define RTL8187B_RTL8225_ANAPARAM3_OFF 0x00
void rtl8225_write(struct ieee80211_hw *, u8 addr, u16 data);
u16 rtl8225_read(struct ieee80211_hw *, u8 addr);
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
after this with value '0', the vendor driver both on win/linux does this, was
another mistake that I didn't see:
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:
+ rtl818x_iowrite8_idx(priv, (u8 *)0xFF4E, 1, 2);
and does things in another order, so I moved code:
+ 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.
--
[]'s
Herton
On Thu, 2008-06-26 at 13:33 -0500, Larry Finger wrote:
> 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.
--
Regards,
Pavel Roskin