Skip to contentSkip to conversation

staging: No option to select rtl8192su in linux-2.6.33-rc2

DISCUSSION Chris Mayo 6 participants 11 messages Dec 28, 2009 – Feb 17, 2010

lore
Share & tools
lore

Chris Mayo

author
#0 lore raw

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"?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3d23e349d807177eaf519d444677cee86b1a04cf

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(?)

#1 lore raw

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

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3d23e349d807177eaf519d444677cee86b1a04cf

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(?)

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

#2 lore raw
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"?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3d23e349d807177eaf519d444677cee86b1a04cf

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

#3 lore raw
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
#4 lore raw
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
- 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

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.
#5 lore raw
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
#6 lore raw
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

#7 lore raw
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
#8 lore raw
In reply to Frederic 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 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

#9 lore raw
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
#10 lore raw
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 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,

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 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.

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