I am in the process of converting the driver contained in the file
RTL8192SU_usb_linux_v2.6.0006.20100511.zip obtained from the Realtek
site. This driver is used for the following USB IDs:
Realtek (0x0bda) 0x8171, 0x8172, 0x8173, 0x8174, 0x8712, 0x8713, 0xC512
Correga (0x07aa) 0x0047
D-Link (0x07d1) 0x3303, 0x3302, 0x3300
Skyworth (0x14b2) 0x3300, 0x3301, 0x3302
EnGenius (0x1740) 0x9603, 0x9605
Belkin (0x050d) 0x815F, 0x945A, 0x845A
Guillemot(0x06f8) 0xe031
Edimax (0x7392) 0x7611, 0x7612, 0x7622
Sitecom (0x0DF6) 0x0045
Hawking (0x0E66) 0x0015, 0x0016, 0x1786, 0x1791
Other (0x13D3) 0x3306, 0x3309, 0x3310, 0x3311, 0x3325
Other (0x083A) 0xC512
My initial plan is to modify this driver code for inclusion in
drivers/staging. The above list includes some, but not all, of the IDs
in the driver currently in drivers/staging/rtl8192su. I will likely put
this in as drivers/staging/rtl8712u, which is the name used in the code,
and remove the duplicate IDs from rtl8192su. Once this step is done, I
will then work at modifying it to use mac80211 so that it can go into
mainline.
My test device is a D-Link DWA-130 (14b2:3300). The Realtek driver
compiles cleanly and works as-is for this device on i386 architecture;
however, compilation spews hundreds of warnings when built on x86_64.
Most of these are due to wrong sized integers in pointer - integer
conversions and were easily fixed. The driver also oopsed due to an
illegal array index when getting the channel number from scan data. I
found this problem, and added a fixup and a log message to prevent the
oops. The driver now scans correctly, but cannot connect on x86_64,
which is my second reason for this message.
I know that the size of pointers changes from 32- to 54-bit
architecture, as does the size of longs. I have been through the code
many times, and I think those have been fixed. Are there any other types
of objects that change size? Does anyone have any suggestions on what to
look for?
Thanks,
Larry
On Thu, 2010-05-27 at 11:13 -0500, Larry Finger wrote:
> I know that the size of pointers changes from 32- to 54-bit
> architecture, as does the size of longs. I have been through the code
> many times, and I think those have been fixed. Are there any other types
> of objects that change size? Does anyone have any suggestions on what to
> look for?
Alignment _might_ be different, though I think it isn't actually as long
as we're talking about x86_64 (amd64) only.
If the driver uses wireless extensions (likely), it might have issues
with that too, since they are not very 32/64-bit compat happy (unless
you're using 64-bit userspace exclusively obviously)
I can't think of anything else right now.
johannes
On 05/27/2010 01:06 PM, Johannes Berg wrote:
> On Thu, 2010-05-27 at 11:13 -0500, Larry Finger wrote:
>
>> I know that the size of pointers changes from 32- to 54-bit
>> architecture, as does the size of longs. I have been through the code
>> many times, and I think those have been fixed. Are there any other types
>> of objects that change size? Does anyone have any suggestions on what to
>> look for?
>
> Alignment _might_ be different, though I think it isn't actually as long
> as we're talking about x86_64 (amd64) only.
>
> If the driver uses wireless extensions (likely), it might have issues
> with that too, since they are not very 32/64-bit compat happy (unless
> you're using 64-bit userspace exclusively obviously)
>
> I can't think of anything else right now.
Thanks. The problem I had with the scan channel was with WEXT. It seems
likely that this problem is somewhere in there.
Larry
Le Thu, 27 May 2010 11:13:22 -0500,
Larry Finger <[email protected]> a écrit :
> I am in the process of converting the driver contained in the file
> RTL8192SU_usb_linux_v2.6.0006.20100511.zip obtained from the Realtek
> site. This driver is used for the following USB IDs:
>
> Realtek (0x0bda) 0x8171, 0x8172, 0x8173, 0x8174, 0x8712,
> 0x8713,
> [...]
> My test device is a D-Link DWA-130 (14b2:3300). The Realtek driver
> compiles cleanly and works as-is for this device on i386 architecture;
I own a Trendnet TEW-649UB (usb ids : 0bda:8172).
I got the staging driver working only once. Since then, I found that the
function which sets the channel didn't work.
The 20100511 driver has the same behaviour at first sight, looking at
wireshark trace.
> My initial plan is to modify this driver code for inclusion in
> drivers/staging. The above list includes some, but not all, of the IDs
> in the driver currently in drivers/staging/rtl8192su. I will likely
> put this in as drivers/staging/rtl8712u, which is the name used in
> the code, and remove the duplicate IDs from rtl8192su. Once this step
> is done, I will then work at modifying it to use mac80211 so that it
> can go into mainline.
Some work has been made in the staging driver. Can it be a better
start ?
Have you a repository with your work ? I would like to test it again my
device and if possible join our effort.
--
Frédéric Leroy
Frederic Leroy <fredo@...> writes:
>
> Le Thu, 27 May 2010 11:13:22 -0500,
> Larry Finger <Larry.Finger@...> a écrit :
>
> > I am in the process of converting the driver contained in the file
> > RTL8192SU_usb_linux_v2.6.0006.20100511.zip obtained from the Realtek
> > site. This driver is used for the following USB IDs:
> >
> > Realtek (0x0bda) 0x8171, 0x8172, 0x8173, 0x8174, 0x8712,
> > 0x8713,
> > [...]
> > My test device is a D-Link DWA-130 (14b2:3300). The Realtek driver
> > compiles cleanly and works as-is for this device on i386 architecture;
>
> I own a Trendnet TEW-649UB (usb ids : 0bda:8172).
> I got the staging driver working only once. Since then, I found that the
> function which sets the channel didn't work.
> The 20100511 driver has the same behaviour at first sight, looking at
> wireshark trace.
>
> > My initial plan is to modify this driver code for inclusion in
> > drivers/staging. The above list includes some, but not all, of the IDs
> > in the driver currently in drivers/staging/rtl8192su. I will likely
> > put this in as drivers/staging/rtl8712u, which is the name used in
> > the code, and remove the duplicate IDs from rtl8192su. Once this step
> > is done, I will then work at modifying it to use mac80211 so that it
> > can go into mainline.
>
> Some work has been made in the staging driver. Can it be a better
> start ?
>
> Have you a repository with your work ? I would like to test it again my
> device and if possible join our effort.
>
Hi Frederic,
maybe it's the wrong place to ask, but did you get the work in converting the
original driver any further?
My problem is, i have an usb wlan stick using an realtek 8188su chipset.
I used the (staging) driver for rtl8192su contained in the 2.6.33 kernel
on a amd64-mandriva system and included the usid of the stick, compiled
and installed.
Up to now, the stick is recognized, and scans the surrounding networks.
It also detects the available wlans (displaying their ssids)
But, i never did get it to work when i try to connect to a wpa2-protected
wlan. (never tried open or wep wlans yet).
Could you please assist in how to achieve a connection? Any help is
appreciated...
(other things done already:
- i compiled the driver rtl8192su in the more recent kernel release 2.6.34
and installed it. This one already got my usb-id included, so no further
changes to the code necessary. compiling, installing and using on my amd64
mandriva (still running kernel 2.6.33) had the same effects as above -
scanning wlans is ok, connecting to a wpa2 protected wlan does not work)
As a last resort i tried the original realtek driver, compiled this stuff
and had a kernel panic when inserting the usb stick. According to your
previous posts, this might be due to the pointer problems on an amd64
system as you pointed out.
)
So, any ideas how to proceed?
Thanks,
Claus