staging: No option to select rtl8192su in linux-2.6.33-rc2
If you have no other wireless drivers selected then RealTek RTL8192SU does not show up in menuconfig for staging.
rtl8192su needs the "select WIRELESS_EXT" fix for "wext: refactor"?
as done for some in:
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=commitdiff;h=125b181aec7a67c71234284ecf6d9c729d05deda
Also:
rtl8192u, wlan-ng, wlags49_h2(?)
Hi Chris,
Quoted 5 lines
If you have no other wireless drivers selected then RealTek RTL8192SU does not show up in menuconfig for staging.
rtl8192su needs the "select
WIRELESS_EXT" fix for "wext: refactor"?
Quoted 8 lines
as done for some in:
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=commitdiff;h=125b181aec7a67c71234284ecf6d9c729d05dedaAlso:
rtl8192u, wlan-ng,wlags49_h2(?)
if staging drivers break, then please create a patch and mail it do Greg. Don't bother linux-wireless with it since nobody here actually cares about the staging drivers.
Regards
Marcel
Quoted 13 lines · Marcel Holtmann
Hi Chris,
Quoted 11 lines
If you have no other wireless drivers selected then RealTek RTL8192SU does not show up in menuconfig for staging.
rtl8192su needs the "select
WIRELESS_EXT" fix for "wext: refactor"?as done for some in:
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=commitdiff;h=125b181aec7a67c71234284ecf6d9c729d05deda
Quoted 6 lines
Quoted 2 lines
Also:
rtl8192u, wlan-ng,wlags49_h2(?)if staging drivers break, then please create a patch and mail it do Greg. Don't bother linux-wireless with it since nobody here actually cares about the staging drivers.
"nobody cares" is not entirely true - AFAIK, code in the staging area is unreliable/unsuitable/"poor" code which serves the sole purpose of being there for scavenging and references for re-write (because there is no equivalent functionality, even alleged, in mainline); so people looking at the staging code for ideas or references is welcomed. It is just that there is no hints of any support or vague guarantee that any of it works for any fitness of purpose. i.e. patches which fix problems, or migrate functionality out of the staging area to main-line, are welcomed, but questions and request for help on understanding or making any of it work, are not.
Quoted 11 lines
Regards
Marcel
--
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
Quoted 10 lines · Hin-Tak Leung
"nobody cares" is not entirely true - AFAIK, code in the staging area is unreliable/unsuitable/"poor" code which serves the sole purpose of being there for scavenging and references for re-write (because there is no equivalent functionality, even alleged, in mainline); so people looking at the staging code for ideas or references is welcomed. It is just that there is no hints of any support or vague guarantee that any of it works for any fitness of purpose. i.e. patches which fix problems, or migrate functionality out of the staging area to main-line, are welcomed, but questions and request for help on understanding or making any of it work, are not.
I just bought an wireless usb key based on realtek 8192. If nobody is working on making a driver for it, I'd like to try.
But I am wondering where/how to start.
Should I follow the TODO file from Greg in staging :
( which seems to merge : rtl8192e rtl8192su rtl8192u )
TODO:
- prepare private ieee80211 stack for merge with rtl8187se's version:
- remove rtl8192su's specific dead code
- cleanup ieee80211.h
- move rtl8192su's specific code out from ieee80211.h
- abstract rtl819su's specific code
- use list_for_each_safe() in ieee80211_crypto_deinit
- switch to use shared "librtl" instead of private ieee80211 stack
- switch to use LIB80211
- switch to use MAC80211
- switch to use EEPROM_93CX6
- use kernel coding style
- checkpatch.pl fixes
- sparse fixes
- integrate with drivers/net/wireless/rtl818x
Or use rtl818x tree to start a new device ?
Signature · 1 line
Frédéric Leroy
Quoted 22 lines · Frederic Leroy
Quoted 10 lines · Hin-Tak Leung
"nobody cares" is not entirely true - AFAIK, code in the staging area is unreliable/unsuitable/"poor" code which serves the sole purpose of being there for scavenging and references for re-write (because there is no equivalent functionality, even alleged, in mainline); so people looking at the staging code for ideas or references is welcomed. It is just that there is no hints of any support or vague guarantee that any of it works for any fitness of purpose. i.e. patches which fix problems, or migrate functionality out of the staging area to main-line, are welcomed, but questions and request for help on understanding or making any of it work, are not.
I just bought an wireless usb key based on realtek 8192. If nobody is working on making a driver for it, I'd like to try.
But I am wondering where/how to start.
Should I follow the TODO file from Greg in staging :
( which seems to merge : rtl8192e rtl8192su rtl8192u )
Quoted 15 lines
TODO:
- prepare private ieee80211 stack for merge with rtl8187se's version:
- remove rtl8192su's specific dead code
- cleanupieee80211.h
- move rtl8192su's specific code out fromieee80211.h
- abstract rtl819su's specific code
- uselist_for_each_safe()inieee80211_crypto_deinit
- switch to use shared "librtl" instead of private ieee80211 stack
- switch to use LIB80211
- switch to use MAC80211
- switch to useEEPROM_93CX6
- use kernel coding style
- checkpatch.pl fixes
- sparse fixes
- integrate withdrivers/net/wireless/rtl818x
This is a reasonable plan overall, although I might quibble with the order.
Quoted 1 line
Or use rtl818x tree to start a new device ?
YMMV, but given the code I've seen for the Realtek drivers in staging I might be inclined to start by forking rtl8180 and making the necessary hardware changes from there.
Hth!
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 4 lines · John W. Linville
[...]
Quoted 3 lines
Should I follow the TODO file from Greg in staging :
( which seems to merge : rtl8192e rtl8192su rtl8192u ) [...]
Quoted 8 lines
This is a reasonable plan overall, although I might quibble with the order.
Quoted 1 line
Or use rtl818x tree to start a new device ?
YMMV, but given the code I've seen for the Realtek drivers in staging I might be inclined to start by forking rtl8180 and making the necessary hardware changes from there.
It was my impression too, but as you say, YMMV. It will be my first driver, although I already hacked the kernel, make netfilters modules and read lwn ;).
For the process, it is still unclear for me. I copy rtl8180*[ch] to rtl8192*[ch], and start to hack into to make clean git patches ?
On which tree should I base my work :git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git ?
Quoted 1 line
hth!
It helps :)
Signature · 1 line
Frédéric Leroy
Quoted 10 lines · Frederic Leroy
It was my impression too, but as you say, YMMV. It will be my first driver, although I already hacked the kernel, make netfilters modules and read lwn ;).
For the process, it is still unclear for me. I copy rtl8180*[ch] to rtl8192*[ch], and start to hack into to make clean git patches ?
On which tree should I base my work :
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git?
Before you start with the mainline driver, I would suggest a little cleanup of the driver in staging. The Realtek drivers are full of dead code such as
// unused code that is not a comment
or
if (0) {
....
} else {
...
}or
#ifdef SOMECONFIGVARIABLE .... #else ....
#endif
and finally
if (priv->config_var) {
....
} else {
....
}where config_var is set to some initial value and _NEVER_ changed.
When you are trying to translate their code to a new driver, such dead code is a major distraction. My recommendations are as follows:
* Make certain the driver in staging works in its present form.
* Prepare a patch to eliminate the unused branches of if(0) and if(1) code and the code that has been commented out. After the driver is tested to check for silly mistakes and the patch passes scripts/checkpatch, push the patch to GregKH for inclusion in future releases. If something prevents you from reaching the goal of a mainline driver, at least your efforts will be not be lost.
* Next pick one of the ifdef variables, determine if the existing make file sets it, and eliminate it from the code. After successful testing, push that patch to Greg. Repeat until all such configuration variables are eliminated.
* Now start working on the priv->config_var stuff that never changes.
* The next step would be to convert the driver to use the standard EEPROM module rather than their code. I just did that for the RTL8187SE driver. I can provide a copy of that patch if it has not reached wireless-testing by the time you need it.
After the staging driver is leaner and cleaner, then you can start on the port. As the RTL8192SU is a USB device, you may want to start with rtl8187 rather than rtl8180, which is a PCI device. Once you reach the point of getting a driver that has minimal functionality, you can use the USB capture routines to compare your version with the one that works.
Writing a new driver is a very involved process as I have found with the RTL8187SE. In fact, my first two attempts failed, in large part because I did not do the steps above. The current attempt looks more promising as it has successfully read the EEPROM and is about 1000 register read/write steps toward getting the device initialized.
Larry
Quoted 2 lines · Larry Finger
[...]
* Make certain the driver in staging works in its present form.
Currently, I use it currently and seems stable.
Quoted 9 lines
* Prepare a patch to eliminate the unused branches of if(0) and if(1) [...]
After the staging driver is leaner and cleaner, then you can start on the port. As the RTL8192SU is a USB device, you may want to start with rtl8187 rather than rtl8180, which is a PCI device. Once you reach the point of getting a driver that has minimal functionality, you can use the USB capture routines to compare your version with the one that works.
Quoted 5 lines
Writing a new driver is a very involved process as I have found with the RTL8187SE. In fact, my first two attempts failed, in large part because I did not do the steps above. The current attempt looks more promising as it has successfully read the EEPROM and is about 1000 register read/write steps toward getting the device initialized.
Thanks for your wise advice Larry.
I will follow it.
Signature · 1 line
Frédéric Leroy
Quoted 20 lines · Frederic Leroy
Quoted 4 lines · John W. Linville
[...]
Quoted 3 lines
Should I follow the TODO file from Greg in staging :
( which seems to merge : rtl8192e rtl8192su rtl8192u ) [...]Quoted 8 lines
This is a reasonable plan overall, although I might quibble with the order.
Quoted 1 line
Or use rtl818x tree to start a new device ?
YMMV, but given the code I've seen for the Realtek drivers in staging I might be inclined to start by forking rtl8180 and making the necessary hardware changes from there.
It was my impression too, but as you say, YMMV. It will be my first driver, although I already hacked the kernel, make netfilters modules and read lwn ;).
Quoted 5 lines
For the process, it is still unclear for me. I copy rtl8180*[ch] to rtl8192*[ch], and start to hack into to make clean git patches ?
On which tree should I base my work :
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git?
It is probably useful to pull fromgit://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
as well - I think wireless-testing's log may be more granular
Quoted 8 lines · Hin-Tak Leung
Quoted 2 lines · Frederic Leroy
On which tree should I base my work :
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git?It is probably useful to pull from
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
as well - I think wireless-testing's log may be more granular
I saw it. But I have a problem with this tree. The rtl8192su driver don't compile :
CC [M] drivers/staging/rtl8192su/r8180_93cx6.o
In file included from drivers/staging/rtl8192su/r8192U.h:43,
from drivers/staging/rtl8192su/r8180_93cx6.h:16,
from drivers/staging/rtl8192su/r8180_93cx6.c:21:drivers/staging/rtl8192su/ieee80211/ieee80211.h:612: erreur: redefinition of ‘struct ieee80211_hdr_3addr’ make[3]: *** [drivers/staging/rtl8192su/r8180_93cx6.o] Erreur 1
For the moment, I am working on linux-2.6-stable tree for removing dead code in staging and check that it breaks nothing.
Signature · 1 line
Frédéric Leroy
Quoted 17 lines · Frederic Leroy
Quoted 8 lines · Hin-Tak Leung
Quoted 2 lines · Frederic Leroy
On which tree should I base my work :
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git?It is probably useful to pull from
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
as well - I think wireless-testing's log may be more granularI saw it. But I have a problem with this tree. The rtl8192su driver don't compile :
CC [M]
drivers/staging/rtl8192su/r8180_93cx6.o
In file included fromdrivers/staging/rtl8192su/r8192U.h:43,
Quoted 7 lines
from drivers/staging/rtl8192su/r8180_93cx6.h:16, from drivers/staging/rtl8192su/r8180_93cx6.c:21:
drivers/staging/rtl8192su/ieee80211/ieee80211.h:612: erreur: redefinition of ‘struct ieee80211_hdr_3addr’ make[3]: *** [drivers/staging/rtl8192su/r8180_93cx6.o] Erreur 1For the moment, I am working on linux-2.6-stable tree for removing dead code in staging and check that it breaks nothing.
There was a similar problem with the RTL8187SE driver when the ieee80211_hdr_3addr struct was added to ieee80211.h. My patch for that problem is commit b6b1ac69372da99 in wireless-testing. BTW, the mainline kernel will have this problem when the 2.6.34 merge happens. I recommend fixing it ASAP.
Larry