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(?)
On Mon, Dec 28, 2009 at 9:59 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Chris,
>
>> 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(?)
>
> 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.
>
> 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
>
Hi Chris,
> 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(?)
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
Le Sun, 14 Feb 2010 11:21:46 -0600,
Larry Finger <[email protected]> a écrit :
> [...]
> * Make certain the driver in staging works in its present form.
Currently, I use it currently and seems stable.
> * 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.
>
> 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.
--
Frédéric Leroy
On Sat, Feb 13, 2010 at 11:44:56PM +0100, Frederic Leroy wrote:
> Le Thu, 31 Dec 2009 14:38:35 +0000,
> Hin-Tak Leung <[email protected]> a ?crit :
>
> > "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
This is a reasonable plan overall, although I might quibble with
the order.
> 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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 02/17/2010 02:17 AM, Frederic Leroy wrote:
> Le Wed, 17 Feb 2010 00:44:56 +0000,
> Hin-Tak Leung <[email protected]> a écrit :
>
>> On Sun, Feb 14, 2010 at 12:18 PM, Frederic Leroy <[email protected]>
>> wrote:
>>> 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.
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
On 02/14/2010 06:18 AM, Frederic Leroy wrote:
>
> 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
Le Sat, 13 Feb 2010 19:40:10 -0500,
"John W. Linville" <[email protected]> a écrit :
> [...]
> > Should I follow the TODO file from Greg in staging :
> > ( which seems to merge : rtl8192e rtl8192su rtl8192u )
> > [...]
> This is a reasonable plan overall, although I might quibble with
> the order.
>
> > 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 ?
> hth!
It helps :)
--
Frédéric Leroy
Le Thu, 31 Dec 2009 14:38:35 +0000,
Hin-Tak Leung <[email protected]> a écrit :
> "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 ?
--
Frédéric Leroy
On Sun, Feb 14, 2010 at 12:18 PM, Frederic Leroy <[email protected]> wrote:
> Le Sat, 13 Feb 2010 19:40:10 -0500,
> "John W. Linville" <[email protected]> a ?crit :
>
>> [...]
>> > Should I follow the TODO file from Greg in staging :
>> > ( which seems to merge : rtl8192e ?rtl8192su ?rtl8192u )
>> > [...]
>> This is a reasonable plan overall, although I might quibble with
>> the order.
>>
>> > 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 ?
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
Le Wed, 17 Feb 2010 00:44:56 +0000,
Hin-Tak Leung <[email protected]> a écrit :
> On Sun, Feb 14, 2010 at 12:18 PM, Frederic Leroy <[email protected]>
> wrote:
> > 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.
--
Frédéric Leroy