Hello,
I was wondering if a Realtek rtl8188 driver was in the works? Here's
Realtek's page:
http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&ProdID=228
The chip is used in devices like the Trendnet TEW-649UB, (newegg page):
http://www.newegg.com/Product/Product.aspx?Item=N82E16833156268
I'd be happy to test on an arm platform.
thanks,
Paul
Doesn't the RTL8192SU driver handle this chipset already?
On Sat, Mar 6, 2010 at 6:45 PM, Paul Thomas <[email protected]> wrote:
> Hello,
>
> I was wondering if a Realtek rtl8188 driver was in the works? Here's
> Realtek's page:
> http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&ProdID=228
>
> The chip is used in devices like the Trendnet TEW-649UB, (newegg page):
> http://www.newegg.com/Product/Product.aspx?Item=N82E16833156268
>
> I'd be happy to test on an arm platform.
>
> thanks,
> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Sat, 2010-03-06 at 19:07 +0100, Gábor Stefanik wrote:
> Doesn't the RTL8192SU driver handle this chipset already?
Yes, I was able to test it. I followed instructions from this site:
http://blog.xff.lt/2009/12/28/canyon-cnp-wf518n2-usb-wireless-linux/
I added the ID
diff --git a/drivers/staging/rtl8192su/r8192U_core.c b/drivers/staging/rtl8192su/r8192U_core.c
index 6f424fe..bec729f 100644
--- a/drivers/staging/rtl8192su/r8192U_core.c
+++ b/drivers/staging/rtl8192su/r8192U_core.c
@@ -130,6 +130,7 @@ static struct usb_device_id rtl8192_usb_id_tbl[] = {
{USB_DEVICE(0x06f8, 0xe031)},
//92SU
{USB_DEVICE(0x0bda, 0x8172)},
+ {USB_DEVICE(0x0bda, 0x8171)},
{}
};
Then I downloaded the driver from
http://xff.lt/stuff/canyon-wifi/rtl8192se_linux_2.6.0013.1204.2009.tar.gz
I took rtl8192sfw.bin from it and put it to /lib/firmware/RTL8192SU (not
RTL8192SE as in the archive).
I was able to load the driver, bring the interface up and scan. I could
not connect to an AP with CCMP for some reason:
# wpa_supplicant -c /etc/wpa_supplicant/mike1.conf -i wlan29 -D wext
ioctl[SIOCSIWPMKSA]: Invalid argument
ioctl[SIOCSIWPMKSA]: Invalid argument
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:25:9c:28:15:62 (SSID='mike1' freq=2437 MHz)
ioctl[SIOCSIWFREQ]: Operation not supported
Association request to the driver failed
But I was able to connect to an unsecured AP:
wlan29 802.11b/g/n li ESSID:"mike2"
Mode:Managed Frequency=2.437 GHz Access Point: 00:26:5A:C2:4C:3D
Bit Rate=130 Mb/s
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=89/100 Signal level=-56 dBm Noise level=-114 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I could also use the firmware called rtl8192sfw492.bin by renaming it to
rtl8192sfw.bin.
--
Regards,
Pavel Roskin
OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
trouble with the PCI dependency. I'm on an arm platform without PCI
(atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
it does compile with warnings, and then when the module loads I get
"r8192s_usb: Unknown symbol wireless_send_event".
I'm happy to hang out and try again when the driver leaves staging,
but I thought I might mention the PCI dependency now.
thanks,
Paul
2010/3/9 Pavel Roskin <[email protected]>:
> On Sun, 2010-03-07 at 16:36 +0100, G?bor Stefanik wrote:
>
>> Maybe with an actual RTL8192SU firmware it would work... just my 2 HUF.
>
> Actually, you are absolutely right! ?The driver is working fine with the
> firmware from rtl8192su_linux_2.6.0002.0708.2009.tar.gz
>
> CCMP is working, and I could browse the web over it!
>
> --
> Regards,
> Pavel Roskin
>
On Sun, 2010-03-07 at 16:36 +0100, Gábor Stefanik wrote:
> Maybe with an actual RTL8192SU firmware it would work... just my 2 HUF.
Actually, you are absolutely right! The driver is working fine with the
firmware from rtl8192su_linux_2.6.0002.0708.2009.tar.gz
CCMP is working, and I could browse the web over it!
--
Regards,
Pavel Roskin
2010/3/7 Pavel Roskin <[email protected]>:
> On Sat, 2010-03-06 at 19:07 +0100, G?bor Stefanik wrote:
>> Doesn't the RTL8192SU driver handle this chipset already?
>
> Yes, I was able to test it. ?I followed instructions from this site:
> http://blog.xff.lt/2009/12/28/canyon-cnp-wf518n2-usb-wireless-linux/
>
> I added the ID
>
> diff --git a/drivers/staging/rtl8192su/r8192U_core.c b/drivers/staging/rtl8192su/r8192U_core.c
> index 6f424fe..bec729f 100644
> --- a/drivers/staging/rtl8192su/r8192U_core.c
> +++ b/drivers/staging/rtl8192su/r8192U_core.c
> @@ -130,6 +130,7 @@ static struct usb_device_id rtl8192_usb_id_tbl[] = {
> ? ? ? ?{USB_DEVICE(0x06f8, 0xe031)},
> ? ? ? ?//92SU
> ? ? ? ?{USB_DEVICE(0x0bda, 0x8172)},
> + ? ? ? {USB_DEVICE(0x0bda, 0x8171)},
> ? ? ? ?{}
> ?};
>
>
> Then I downloaded the driver from
> http://xff.lt/stuff/canyon-wifi/rtl8192se_linux_2.6.0013.1204.2009.tar.gz
>
> I took rtl8192sfw.bin from it and put it to /lib/firmware/RTL8192SU (not
> RTL8192SE as in the archive).
>
> I was able to load the driver, bring the interface up and scan. ?I could
> not connect to an AP with CCMP for some reason:
>
> # wpa_supplicant -c /etc/wpa_supplicant/mike1.conf -i wlan29 -D wext
> ioctl[SIOCSIWPMKSA]: Invalid argument
> ioctl[SIOCSIWPMKSA]: Invalid argument
> CTRL-EVENT-SCAN-RESULTS
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:25:9c:28:15:62 (SSID='mike1' freq=2437 MHz)
> ioctl[SIOCSIWFREQ]: Operation not supported
> Association request to the driver failed
Maybe with an actual RTL8192SU firmware it would work... just my 2 HUF.
>
> But I was able to connect to an unsecured AP:
>
> wlan29 ? ?802.11b/g/n ?li ?ESSID:"mike2"
> ? ? ? ? ?Mode:Managed ?Frequency=2.437 GHz ?Access Point: 00:26:5A:C2:4C:3D
> ? ? ? ? ?Bit Rate=130 Mb/s
> ? ? ? ? ?Retry min limit:7 ? RTS thr:off ? Fragment thr:off
> ? ? ? ? ?Encryption key:off
> ? ? ? ? ?Power Management:off
> ? ? ? ? ?Link Quality=89/100 ?Signal level=-56 dBm ?Noise level=-114 dBm
> ? ? ? ? ?Rx invalid nwid:0 ?Rx invalid crypt:0 ?Rx invalid frag:0
> ? ? ? ? ?Tx excessive retries:0 ?Invalid misc:0 ? Missed beacon:0
>
> I could also use the firmware called rtl8192sfw492.bin by renaming it to
> rtl8192sfw.bin.
>
> --
> Regards,
> Pavel Roskin
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Tue, Mar 30, 2010 at 12:19 AM, Paul Thomas <[email protected]> wrote:
> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
> trouble with the PCI dependency. I'm on an arm platform without PCI
> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
> it does compile with warnings, and then when the module loads I get
> "r8192s_usb: Unknown symbol wireless_send_event".
>
> I'm happy to hang out and try again when the driver leaves staging,
> but I thought I might mention the PCI dependency now.
>
> thanks,
> Paul
wireless_send_event is in wext_core - try adding a dependency on WEXT_CORE.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Sun, 2010-03-07 at 16:36 +0100, Gábor Stefanik wrote:
> 2010/3/7 Pavel Roskin <[email protected]>:
> > I was able to load the driver, bring the interface up and scan. I could
> > not connect to an AP with CCMP for some reason:
> >
> > # wpa_supplicant -c /etc/wpa_supplicant/mike1.conf -i wlan29 -D wext
> > ioctl[SIOCSIWPMKSA]: Invalid argument
> > ioctl[SIOCSIWPMKSA]: Invalid argument
> > CTRL-EVENT-SCAN-RESULTS
> > CTRL-EVENT-SCAN-RESULTS
> > Trying to associate with 00:25:9c:28:15:62 (SSID='mike1' freq=2437 MHz)
> > ioctl[SIOCSIWFREQ]: Operation not supported
> > Association request to the driver failed
>
> Maybe with an actual RTL8192SU firmware it would work... just my 2 HUF.
I brushed up my firmware extraction skills and extracted the firmware
from the latest Windows driver for rtl8188su.
Unfortunately, the results are exactly the same. Scanning works, but
wpa_supplicant fails in the same way.
OK, at least I won't be able to blame the firmware from now on.
--
Regards,
Pavel Roskin
On Thu, May 27, 2010 at 12:06 AM, Pavel Roskin <[email protected]> wrote:
> On Mon, 2010-03-29 at 15:19 -0700, Paul Thomas wrote:
>> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
>> trouble with the PCI dependency. I'm on an arm platform without PCI
>> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
>> it does compile with warnings, and then when the module loads I get
>> "r8192s_usb: Unknown symbol wireless_send_event".
>>
>> I'm happy to hang out and try again when the driver leaves staging,
>> but I thought I might mention the PCI dependency now.
>
> wireless_send_event should be available if WIRELESS_EXT is selected in Kconfig.
>
> But I cannot find the "r8192s_usb" symbol in any staging drivers, so I
> have no idea which driver you are talking about.
r8192s_usb is not a symbol, it is the name of the module being loaded.
>
> I suggest that you don't hijack existing threads to report new issues.
> When reporting a problem, please give the kernel version, the driver
> name and whatever details are needed for others to reproduce the
> problem.
>
>> > CCMP is working, and I could browse the web over it!
>
> Please don't quote parts of the message that are irrelevant to what you
> are saying.
>
> --
> Regards,
> Pavel Roskin
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Mon, 2010-03-29 at 15:19 -0700, Paul Thomas wrote:
> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
> trouble with the PCI dependency. I'm on an arm platform without PCI
> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
> it does compile with warnings, and then when the module loads I get
> "r8192s_usb: Unknown symbol wireless_send_event".
>
> I'm happy to hang out and try again when the driver leaves staging,
> but I thought I might mention the PCI dependency now.
wireless_send_event should be available if WIRELESS_EXT is selected in Kconfig.
But I cannot find the "r8192s_usb" symbol in any staging drivers, so I
have no idea which driver you are talking about.
I suggest that you don't hijack existing threads to report new issues.
When reporting a problem, please give the kernel version, the driver
name and whatever details are needed for others to reproduce the
problem.
> > CCMP is working, and I could browse the web over it!
Please don't quote parts of the message that are irrelevant to what you
are saying.
--
Regards,
Pavel Roskin
On Thu, 2010-05-27 at 00:21 +0200, Gábor Stefanik wrote:
> > But I cannot find the "r8192s_usb" symbol in any staging drivers, so I
> > have no idea which driver you are talking about.
>
> r8192s_usb is not a symbol, it is the name of the module being loaded.
Oh, I see. That means the driver is rtl8192su. But its Kconfig file
already selects WIRELESS_EXT. git log should that it was fixed by the
last commit to drivers/staging/rtl8192su/Kconfig:
commit 784d3119475652d34a8d8ec3911e39c5e3d3036f
Author: Simon Horman <[email protected]>
Date: Mon Dec 21 15:07:10 2009 +1100
Staging: rtl8192su: Build should select WIRELESS_EXT
As for the PCI dependency, it's probably wrong. USB used to depend on
PCI, but I understand it's no longer true.
--
Regards,
Pavel Roskin
On Mon, Mar 29, 2010 at 3:19 PM, Paul Thomas <[email protected]> wrote:
> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
> trouble with the PCI dependency. I'm on an arm platform without PCI
> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
> it does compile with warnings, and then when the module loads I get
> "r8192s_usb: Unknown symbol wireless_send_event".
>
> I'm happy to hang out and try again when the driver leaves staging,
> but I thought I might mention the PCI dependency now.
>
> thanks,
> Paul
I haven't seen any activity on this driver in awhile. Is anyone
working on it? My main request is to remove the PCI dependency. Any
chance of this?
Or does anyone else know of a "mini" wireless adapters with a
supported chipset (i.e. without needing PCI)? Both devices I've
ordered from newegg ended up having the rtl8188 chip.
thanks,
Paul
Hi Paul,
Le Mon, 24 May 2010 17:16:15 -0700,
Paul Thomas <[email protected]> a écrit :
> On Mon, Mar 29, 2010 at 3:19 PM, Paul Thomas <[email protected]>
> wrote:
> > OK, I'd love to get to where Pavel & Gabor are, but I think I'm
> > having trouble with the PCI dependency. I'm on an arm platform
> > without PCI (atmel at91sam9g20). If I remove the PCI dependency
> > from the Kconfig it does compile with warnings, and then when the
> > module loads I get "r8192s_usb: Unknown symbol wireless_send_event".
> [...]
> I haven't seen any activity on this driver in awhile. Is anyone
> working on it? My main request is to remove the PCI dependency. Any
> chance of this?
I started to work on this driver ago. But I didn't continue until
yesterday.
My adapter worked only once the first time. I have the feeling that
there need a lot of work on it until it may work.
I'm slow but still alive ;-) I will try to remove the dependency and
come back to you.
--
Frédéric Leroy
Hi
On Saturday 18 September 2010, Hin-Tak Leung wrote:
> On Fri, Sep 10, 2010 at 12:29 PM, Claus Ried <[email protected]> wrote:
[...]
> The Realtek vendor driver has always bundled its own wpa_supplicant
> and I have wondered what mod they have made. Are you using your distro
> wpa_supplicant or the Realtek vendor bundled one?
Talking about the staging driver in kernel 2.6.35/ 2.6.36 (rtl8192su/
r8192s_usb, I didn't test rtl8712 from {linux,staging}-next yet),
RTL8188S [1] and RTL8191S [2] hardware works quite well for me with
stock wpasupplicant 0.6.10/ 0.7.3 (Debian/ unstable, no hardware
specific patches and using the plain wext backend and no special
configuration). While it takes a little to authenticate succesfully
(20-30 seconds), I have not experienced any problems yet.
Looking at the bundled wpa_supplicant-0.5.10.tar.gz (from
rtl8192su_linux_2.6.0003.0810.2009.tar.gz shipped on the vendor's
driver CD) confirms that its MD5 matches the upstream wpa_supplicant
tarball:
9e7b99da67c47d81121368c6d580d069 *wpa_supplicant-0.5.10.tar.gz
Regards
Stefan Lippers-Hollmann
[1] Longshine LCS-8131N2, 150 MBit/s
0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter
.
usb 1-3: new high speed USB device using ehci_hcd and address 6
usb 1-3: New USB device found, idVendor=0bda, idProduct=8171
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: RTL8188S WLAN Adapter
usb 1-3: Manufacturer: Manufacturer Realtek
usb 1-3: SerialNumber: 00e04c000001
[2] DeLock 88530, 300 MBit/s
0bda:8172 Realtek Semiconductor Corp. RTL8191S WLAN Adapter
.
usb 2-6: new high speed USB device using ehci_hcd and address 2
usb 2-6: New USB device found, idVendor=0bda, idProduct=8172
usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-6: Product: RTL8191S WLAN Adapter
usb 2-6: Manufacturer: Manufacturer Realtek
usb 2-6: SerialNumber: 00e04c000001
Pavel Roskin <proski@...> writes:
>
> On Sun, 2010-03-07 at 16:36 +0100, Gábor Stefanik wrote:
>
> > Maybe with an actual RTL8192SU firmware it would work... just my 2 HUF.
>
> Actually, you are absolutely right! The driver is working fine with the
> firmware from rtl8192su_linux_2.6.0002.0708.2009.tar.gz
>
> CCMP is working, and I could browse the web over it!
>
Hi,
i have the same problems with an rtl8188su based usb wlan stick running on an
amd64 based mandriva 2.6.33 kernel. The current staging drivers (inlcuding the
firmware) do work to some extent, scanning is ok, listing surrounding wlans is
working.
But, i cannot connect to my wpa2 encrypted network using this stick.
Everything is working fine if i am using the internal laptop wlan card (intel
based).
Any ideas why the usb stick won't connect?
Claus
On Fri, Sep 10, 2010 at 12:29 PM, Claus Ried <[email protected]> wrote:
> i have the same problems with an rtl8188su based usb wlan stick running on an
> amd64 based mandriva 2.6.33 kernel. The current staging drivers (inlcuding the
> firmware) do work to some extent, scanning is ok, listing surrounding wlans is
> working.
> But, i cannot connect to my wpa2 encrypted network using this stick.
> Everything is working fine if i am using the internal laptop wlan card (intel
> based).
> Any ideas why the usb stick won't connect?
> Claus
The Realtek vendor driver has always bundled its own wpa_supplicant
and I have wondered what mod they have made. Are you using your distro
wpa_supplicant or the Realtek vendor bundled one?
On Fri, Sep 17, 2010 at 8:37 PM, Hin-Tak Leung <[email protected]> wrote:
> On Fri, Sep 10, 2010 at 12:29 PM, Claus Ried <[email protected]> wrote:
>
>> i have the same problems with an rtl8188su based usb wlan stick running on an
>> amd64 based mandriva 2.6.33 kernel. The current staging drivers (inlcuding the
>> firmware) do work to some extent, scanning is ok, listing surrounding wlans is
>> working.
>> But, i cannot connect to my wpa2 encrypted network using this stick.
>> Everything is working fine if i am using the internal laptop wlan card (intel
>> based).
>> Any ideas why the usb stick won't connect?
>> Claus
>
> The Realtek vendor driver has always bundled its own wpa_supplicant
> and I have wondered what mod they have made. Are you using your distro
> wpa_supplicant or the Realtek vendor bundled one?
So this is working for me now. I'm using the r8712u driver from here:
http://git.kernel.org/?p=linux/kernel/git/lwfinger/r8712u.git;a=summary
With debian's wpa_supplicant v0.6.4.
thanks,
Paul
On 10/31/2010 06:30 AM, Walter Goldens wrote:
>> Perhaps not, but I want to have one that works before
>> removing the staging driver.
>>
>> I think Realtek is serious. After the r8712u driver was
>> ready for inclusion in
>> staging, I sent them a copy of my revisions to their code.
>> Obviously, they
>> studied it. When I received the new code for a
>> mac80211-based driver for the
>> RTL8192CE driver, it was pretty clean and the sort of
>> changes that were needed
>> for the 8712 had already been done. After only a few hours
>> work, the sparse and
>> checkpatch warnings and errors were fixed. As far as I can
>> tell, this code is
>
> By "this code" you mean the code for the PCI chips or the USB ones? This topic here mostly touches on the USB cards, which is why I'm asking. And does that mean you'll include the driver once you've tested the cards?
I mean the PCIe devices. I plan to submit that driver in time to make the 2.6.38
merge. Realtek has not yet sent me the code for the USB devices, but as the chip
and core code is common, it should not be far behind.
Larry
On Sat, Oct 30, 2010 at 4:49 PM, John W. Linville
<[email protected]> wrote:
> On Fri, Oct 29, 2010 at 11:06:35PM -0500, Larry Finger wrote:
>> On 10/29/2010 04:27 PM, G?bor Stefanik wrote:
>> >
>> > AFAIK we only add staging drivers that will eventually move out of
>> > staging. r8712 has no chance of ever leaving staging; a completely new
>> > driver needs to be written (because it isn't mac80211-based).
>>
>> That is correct, but it should not be too long until there is a mac80211 driver
>> for that chip. I just got GPLd sources from Realtek for a mac80211-based driver
>> for the RTL8192CE PCIe device. It will need only a small amount of work to make
>> it ready for mainline. The critical part is that it uses the same chip as is
>> used in the RTL8712 USB device.
>
> Sounds like good news...
>
>> For those that are interested in the RTL8187SE, I'm told that they have a
>> working mac80211 driver for it, but that it is not yet stable.
>
> More good news! ?Even if that device is aging, this indicates that
> Realtek is getting serious about working with the community, even on
> older devices.
However, it may be a good idea to indicate that "it is not yet stable"
AFAIK doesn't preclude inclusion...
>
> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> [email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Hi
On Friday 29 October 2010, Larry Finger wrote:
> On 10/28/2010 04:48 PM, Stefan Lippers-Hollmann wrote:
> >
> > I assume you refer to rtl8712u.bin in your r8712u_firmware tree:
> > http://git.kernel.org/?p=linux/kernel/git/lwfinger/r8712u_firmware.git;a=blob_plain;f=rtl8712u.bin
> > 200fd952db3cc9259b1fd05e3e51966f *rtl8712u.bin
> >
> >> you want to grab the new firmware package, I can send you a copy of the patch.
> >
> > I'd very much like to test the patch(2) needed for rtl8712, if possible.
>
> Attached is the patch. You should place rtl8712u.bin in
> /lib/modules/rtl8712u/rtl8712u.bin.
200fd952db3cc9259b1fd05e3e51966f */lib/firmware/rtl8712u/rtl8712u.bin
[...]
Given this module only needs one firmware image, what about dropping that
subdirectory?
My tests with RTL8188S and RTL8191S are very successful so far, including
the imaginable cornercases (missing firmware, wrong firmware file, etc.).
RTL8188S:
[ 104.239032] usb 1-9: new high speed USB device using ehci_hcd and address 4
[ 104.355650] usb 1-9: New USB device found, idVendor=0bda, idProduct=8171
[ 104.355658] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 104.355664] usb 1-9: Product: RTL8188S WLAN Adapter
[ 104.355669] usb 1-9: Manufacturer: Manufacturer Realtek
[ 104.355673] usb 1-9: SerialNumber: 00e04c000001
[ 104.386766] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
[ 104.393694] r8712u: DriverVersion: v7_0.20100831
[ 104.393728] r8712u: register rtl8712_netdev_ops to netdev_ops
[ 104.393735] r8712u: USB_SPEED_HIGH with 4 endpoints
[ 104.394644] r8712u: Boot from EFUSE: Autoload OK
[ 104.908448] r8712u: CustomerID = 0x0000
[ 104.908454] r8712u: MAC Address from efuse = 00:08:54:99:6f:99
[ 104.910922] usbcore: registered new interface driver r8712u
[ 120.721878] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold
[ 135.957515] lo: Disabled Privacy Extensions
[ 155.603760] r8712u: Loading firmware from "rtl8712u/rtl8712u.bin"
[ 156.246429] r8712u: 1 RCR=0x153f00e
[ 156.247462] r8712u: 2 RCR=0x553f00e
[ 156.352536] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 162.190670] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 166.025559] r8712u: [r8712_got_addbareq_event_callback] mac = 00:27:19:fe:47:84, seq = 16, tid = 0
[ 172.226017] wlan1: no IPv6 routers present
[ 629.891124] r8712u: [r8712_got_addbareq_event_callback] mac = 00:27:19:fe:47:84, seq = 16, tid = 6
RTL8191S:
[ 573.003014] usb 1-3: new high speed USB device using ehci_hcd and address 6
[ 573.119503] usb 1-3: New USB device found, idVendor=0bda, idProduct=8172
[ 573.119507] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 573.119509] usb 1-3: Product: RTL8191S WLAN Adapter
[ 573.119511] usb 1-3: Manufacturer: Manufacturer Realtek
[ 573.119513] usb 1-3: SerialNumber: 00e04c000001
[ 573.128096] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
[ 573.130926] r8712u: DriverVersion: v7_0.20100831
[ 573.130939] r8712u: register rtl8712_netdev_ops to netdev_ops
[ 573.130942] r8712u: USB_SPEED_HIGH with 4 endpoints
[ 573.131499] r8712u: Boot from EFUSE: Autoload OK
[ 573.584756] r8712u: CustomerID = 0x0000
[ 573.584759] r8712u: MAC Address from efuse = 00:02:72:8c:05:16
[ 573.585488] usbcore: registered new interface driver r8712u
[ 598.630199] r8712u: Loading firmware from "rtl8712u/rtl8712u.bin"
[ 599.264458] r8712u: 1 RCR=0x153f00e
[ 599.265210] r8712u: 2 RCR=0x553f00e
[ 599.370062] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 604.898813] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 607.391186] r8712u: [r8712_got_addbareq_event_callback] mac = 00:27:19:fe:47:84, seq = 16, tid = 0
[ 615.266009] wlan1: no IPv6 routers present
[ 2346.336558] r8712u: [r8712_got_addbareq_event_callback] mac = 00:27:19:fe:47:84, seq = 32, tid = 6
With both devices the connection is stable and quite performant (~9 MB/s,
short distance, little channel overlap) against an Atheros/ athk9 based
router running OpenWrt (HT20 && HT40-, b/g/n). In comparison to rtl8192su
the authentification handshake succeeds a lot quicker and without needing
retries, performance is comparable.
I'm following up this mail with a patch covering two minor changes,
selecting FW_LOADER in Kconfig and declaring MODULE_FIRMWARE, feel free
to merge them into your patch.
Thank you a lot, regards
Stefan Lippers-Hollmann
On 09/21/2010 02:20 PM, Stefan Lippers-Hollmann wrote:
> [ Given that I'm bound by Debian's definition of FOSS (DFSG), farray.h
> is a quite unfortunate, as it's not only "non-free" but, given that I
> don't see any licensing information handling the firmware blob in
> staging-next or the original vendor driver, also "undistributable"...
> So far I didn't actually have time to look up how rtl871x_open_fw()
> could be converted to use request_firmware(), but that would at least
> clear the source licensing for r8712u.ko ]
>
> Thanks a lot for your efforts regarding cleaning up rtl8712, while
> rtl8192su/ r8192s_usb works for me almost as well, improvements are
> certainly visible.
In the version in staging, farray.h is covered by the GPL license of the entire
source. It should not cause any problems with Debian.
As part of the inclusion of r8712u in staging, Greg KH asked for a TODO item to
convert the firmware to an external binary. I see this as a 2 step process: (1)
get the firmware binary accepted into linux-firmware, and (2) make it work with
the external loading mechanism. Step 1 has been completed with the following
commit message:
commit c500ee5be41b7954ba9630d7e5d409a24efaf249
Author: Larry Finger <[email protected]>
Date: Wed Oct 20 11:49:59 2010 -0500
Convert firmware for Realtek RTL8192SU (rtl8712u) from embedded to
an external file.
Signed-off-by: Larry Finger <[email protected]>
The code for step 2 is running locally. I'm waiting for the new version of
linux-firmware to propagate through the distros before I submit the patch. If
you want to grab the new firmware package, I can send you a copy of the patch.
Larry
On 10/29/2010 04:27 PM, G?bor Stefanik wrote:
>
> AFAIK we only add staging drivers that will eventually move out of
> staging. r8712 has no chance of ever leaving staging; a completely new
> driver needs to be written (because it isn't mac80211-based).
That is correct, but it should not be too long until there is a mac80211 driver
for that chip. I just got GPLd sources from Realtek for a mac80211-based driver
for the RTL8192CE PCIe device. It will need only a small amount of work to make
it ready for mainline. The critical part is that it uses the same chip as is
used in the RTL8712 USB device.
For those that are interested in the RTL8187SE, I'm told that they have a
working mac80211 driver for it, but that it is not yet stable.
Larry
On Fri, Oct 29, 2010 at 10:26 PM, Walter Goldens
<[email protected]> wrote:
>> With both devices the connection is stable and quite
>> performant (~9 MB/s,
>> short distance, little channel overlap) against an Atheros/
>> athk9 based
>> router running OpenWrt (HT20 && HT40-, b/g/n). In
>> comparison to rtl8192su
>> the authentification handshake succeeds a lot quicker and
>> without needing
>> retries, performance is comparable.
>
> Now, that we're in the habit of adding staging drivers to compat-wireless, shouldn't this one follow the likes of ath6kl and brcm80211? Surely lots of users will benefit from this.
AFAIK we only add staging drivers that will eventually move out of
staging. r8712 has no chance of ever leaving staging; a completely new
driver needs to be written (because it isn't mac80211-based).
>
> Walter
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
* select FW_LOADER
* declare MODULE_FIRMWARE for r8712u
Signed-off-by: Stefan Lippers-Hollmann <[email protected]>
---
drivers/staging/rtl8712/Kconfig | 1 +
drivers/staging/rtl8712/hal_init.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/staging/rtl8712/Kconfig
+++ b/drivers/staging/rtl8712/Kconfig
@@ -3,6 +3,7 @@ config R8712U
depends on WLAN && USB
select WIRELESS_EXT
select WEXT_PRIV
+ select FW_LOADER
default N
---help---
This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130.
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -58,6 +58,7 @@ static u32 rtl871x_open_fw(struct _adapt
*ppmappedfw = (u8 *)((*praw)->data);
return (*praw)->size;
}
+MODULE_FIRMWARE("rtl8712u/rtl8712u.bin");
static void fill_fwpriv(struct _adapter *padapter, struct fw_priv *pfwpriv)
{
On 10/30/2010 01:11 PM, G?bor Stefanik wrote:
> On Sat, Oct 30, 2010 at 4:49 PM, John W. Linville
>>
>> More good news! Even if that device is aging, this indicates that
>> Realtek is getting serious about working with the community, even on
>> older devices.
>
> However, it may be a good idea to indicate that "it is not yet stable"
> AFAIK doesn't preclude inclusion...
Perhaps not, but I want to have one that works before removing the staging driver.
I think Realtek is serious. After the r8712u driver was ready for inclusion in
staging, I sent them a copy of my revisions to their code. Obviously, they
studied it. When I received the new code for a mac80211-based driver for the
RTL8192CE driver, it was pretty clean and the sort of changes that were needed
for the 8712 had already been done. After only a few hours work, the sparse and
checkpatch warnings and errors were fixed. As far as I can tell, this code is
essentially ready for submission; however, I will wait until the sample cards
arrive from Realtek so that I can test those devices. In the very near future,
Not only will there be a driver for the RTL8188CE/RTL8192CE (PCIe), and for the
RTL8188CU/RTL8192CU (USB) devices. These two families use the same chip but
different interfaces. The new drivers will include a common core driver
(rtlwifi.ko) and an interface driver for each interface architecture (rtl8192se
for PCIe).
I also sent them the code I had for a mac80211-based driver for the RTL8187SE.
It was "almost" working, and they seem to have found the part I missed. In
addition, they used that code to learn how to use mac80211. I have not yet seen
their changes, but they said to expect it soon.
It certainly appears that Realtek plans to develop mainline drivers for all
their devices. As only they have the detailed knowledge of the chips, the news
is certainly good. With this help, we should be able to remove the staging
drivers for the Realtek cards.
For the record, I will not receive any compensation from Realtek, other than
their sending me complementary sample devices for testing.
Larry
On 10/28/2010 04:48 PM, Stefan Lippers-Hollmann wrote:
>
> I assume you refer to rtl8712u.bin in your r8712u_firmware tree:
> http://git.kernel.org/?p=linux/kernel/git/lwfinger/r8712u_firmware.git;a=blob_plain;f=rtl8712u.bin
> 200fd952db3cc9259b1fd05e3e51966f *rtl8712u.bin
>
>> you want to grab the new firmware package, I can send you a copy of the patch.
>
> I'd very much like to test the patch(2) needed for rtl8712, if possible.
Attached is the patch. You should place rtl8712u.bin in
/lib/modules/rtl8712u/rtl8712u.bin.
Larry
Hi
On Thursday 28 October 2010, Larry Finger wrote:
> On 09/21/2010 02:20 PM, Stefan Lippers-Hollmann wrote:
[...]
> As part of the inclusion of r8712u in staging, Greg KH asked for a TODO item to
> convert the firmware to an external binary. I see this as a 2 step process: (1)
> get the firmware binary accepted into linux-firmware, and (2) make it work with
> the external loading mechanism. Step 1 has been completed with the following
> commit message:
>
> commit c500ee5be41b7954ba9630d7e5d409a24efaf249
> Author: Larry Finger <[email protected]>
> Date: Wed Oct 20 11:49:59 2010 -0500
>
> Convert firmware for Realtek RTL8192SU (rtl8712u) from embedded to
> an external file.
>
> Signed-off-by: Larry Finger <[email protected]>
>
> The code for step 2 is running locally. I'm waiting for the new version of
> linux-firmware to propagate through the distros before I submit the patch. If
I assume you refer to rtl8712u.bin in your r8712u_firmware tree:
http://git.kernel.org/?p=linux/kernel/git/lwfinger/r8712u_firmware.git;a=blob_plain;f=rtl8712u.bin
200fd952db3cc9259b1fd05e3e51966f *rtl8712u.bin
> you want to grab the new firmware package, I can send you a copy of the patch.
I'd very much like to test the patch(2) needed for rtl8712, if possible.
Regards
Stefan Lippers-Hollmann
> With both devices the connection is stable and quite
> performant (~9 MB/s,
> short distance, little channel overlap) against an Atheros/
> athk9 based
> router running OpenWrt (HT20 && HT40-, b/g/n). In
> comparison to rtl8192su
> the authentification handshake succeeds a lot quicker and
> without needing
> retries, performance is comparable.
Now, that we're in the habit of adding staging drivers to compat-wireless, shouldn't this one follow the likes of ath6kl and brcm80211? Surely lots of users will benefit from this.
Walter
On Fri, Oct 29, 2010 at 11:06:35PM -0500, Larry Finger wrote:
> On 10/29/2010 04:27 PM, G?bor Stefanik wrote:
> >
> > AFAIK we only add staging drivers that will eventually move out of
> > staging. r8712 has no chance of ever leaving staging; a completely new
> > driver needs to be written (because it isn't mac80211-based).
>
> That is correct, but it should not be too long until there is a mac80211 driver
> for that chip. I just got GPLd sources from Realtek for a mac80211-based driver
> for the RTL8192CE PCIe device. It will need only a small amount of work to make
> it ready for mainline. The critical part is that it uses the same chip as is
> used in the RTL8712 USB device.
Sounds like good news...
> For those that are interested in the RTL8187SE, I'm told that they have a
> working mac80211 driver for it, but that it is not yet stable.
More good news! Even if that device is aging, this indicates that
Realtek is getting serious about working with the community, even on
older devices.
John
--
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
[email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
> Perhaps not, but I want to have one that works before
> removing the staging driver.
>
> I think Realtek is serious. After the r8712u driver was
> ready for inclusion in
> staging, I sent them a copy of my revisions to their code.
> Obviously, they
> studied it. When I received the new code for a
> mac80211-based driver for the
> RTL8192CE driver, it was pretty clean and the sort of
> changes that were needed
> for the 8712 had already been done. After only a few hours
> work, the sparse and
> checkpatch warnings and errors were fixed. As far as I can
> tell, this code is
By "this code" you mean the code for the PCI chips or the USB ones? This topic here mostly touches on the USB cards, which is why I'm asking. And does that mean you'll include the driver once you've tested the cards?
> essentially ready for submission; however, I will wait
> until the sample cards
> arrive from Realtek so that I can test those devices. In
> the very near future,
> Not only will there be a driver for the RTL8188CE/RTL8192CE
> (PCIe), and for the
> RTL8188CU/RTL8192CU (USB) devices. These two families use
> the same chip but
> different interfaces. The new drivers will include a common
> core driver
> (rtlwifi.ko) and an interface driver for each interface
> architecture (rtl8192se
> for PCIe).
Realtek has not yet sent me the code for the USB
> devices, but as the chip
> and core code is common, it should not be far behind.
>
> Larry
Hey Larry,
Whats the status quo for the USB driver?
Walter
On 12/16/2010 07:25 AM, Walter Goldens wrote:
> Realtek has not yet sent me the code for the USB
>> devices, but as the chip
>> and core code is common, it should not be far behind.
> Hey Larry,
>
> Whats the status quo for the USB driver?
Realtek is still testing/finishing. They sent me the firmware, which I pushed to
linux-firmware, thus that part is ready.
As we just got the code for the PCIe version into wireless-testing yesterday, I
hope that the good news on it will help the USB effort.
Larry
On Thu, Dec 16, 2010 at 9:10 AM, Larry Finger <[email protected]> wrote:
> On 12/16/2010 07:25 AM, Walter Goldens wrote:
>> Realtek has not yet sent me the code for the USB
>>> devices, but as the chip
>>> and core code is common, it should not be far behind.
>
>> Hey Larry,
>>
>> Whats the status quo for the USB driver?
>
> Realtek is still testing/finishing. They sent me the firmware, which I pushed to
> linux-firmware, thus that part is ready.
>
> As we just got the code for the PCIe version into wireless-testing yesterday, I
> hope that the good news on it will help the USB effort.
>
> Larry
Any word on a mac80211-based driver for the RTL8191SE? PCIe,
vendor/device is 10ec:8172 (comes standard in a lot of new Toshiba
laptops). The RTL8191SE and RTL8192SE use the same driver and
firmware from Realtek. That driver from Realtek is sort of similar to
Realtek's RTL8192CE driver, but, functionally, they look different
enough that I really doubt it would just work if I added the
vendor/device pair and got the rtl8192ce driver to load the right
firmware for the RTL8192SE.
-Brian