Lary, it's unorthodox, but I took Greg Kroah-Hartman and Mike McCormack out of the CC list. They should not have been in the previous post either: there was a new Subject line. On Thu, Jul 21, 2011 at 12:42:38PM -0500, Larry Finger wrote: > On 07/20/2011 10:40 PM, Ali Bahar wrote: > >As you know, I'd intended to merge Realtek's latest code > >(RTL8192SU_usb_linux_v2.6.6.0.20110401.zip) into r8712u (ie > >drivers/staging/rtl8712/). But the above suggests that I should leave > >this to you. > >This leaves the rest of drivers/staging/rtl8712/TODO: > > > >- switch to use LIB80211 > >- switch to use MAC80211 > > > >Though I can tackle these before the merge, it may be more acceptable > >not to. Any thoughts? > > Ali, > > I have downloaded the file and managed to build it on a 3.0-rc6 > kernel. The only change needed was to make the includes of > <linux/smp_lock.h> be conditional on a kernel < 2.6.39. I guessed at > the version where the Big Kernel Lock disappeared. On reflection, > those includes probably are not needed and could be deleted. Thanks for testing it. > I built the driver on an x86_64 system. The large number of warnings > of the type "cast to pointer from integer of different size" means > that the driver needs a lot of work to function on a 64-bit system. > I did not try to run the driver as I'm sure it would crash my > machine. Most of the changes that I had to make in the original code > were due to 32-/64-bit differences. Thanks for the info. > I don't think it would be worth while to replace the existing r8712u > driver with this one. I would suggest looking at the difference > between the two sets of sources and make patches that implement any I guess I should not have used the word "import": such patches _are_ what I'd intended, rather than any sort of wholesale replacement. Based on my admittedly preliminary knowledge of the r8712u code, I'd expected that a few deltas would be brought in from the new Realtek code, the crypto calls will need to be replaced by the lib80211 functions, and that a big chunk of changes would be needed for providing its mac80211 interface. The latter would/should make some existing mini-bugs/irritants go away. Then, if the mods have proved successful, test the driver for control via the iw interface. My admittedly-rudimentary understanding of mac80211 led me to expect that not much of this driver's code will be remaining! Pretty much the entire upper-half will go! > real changes. It will not be easy as there have been a lot of > cosmetic changes. It may help if I have the original Realtek tarball which you based your work on. I am hoping that a diff against _that_ version will show me only the new deltas -- as opposed to if they have rearranged things too much. I can proceed without it, though. > Unfortunately, converting this driver to mainline is probably not > the way to go. First of all, rtl8192su in mainline should use as > much of the rtlwifi code as possible. Not only the low-level USB > code will be used, but a lot of code can be shared by rtl8192se and > rtl8192su in the same way as rtl8192ce and rtl8192cu share the code This is exactly the sort of big-picture-view which I was lacking (ie rtlwifi as a shared base, and how much the related drivers have in common.) Thanks much. I will look into rtlwifi and the two pairs above. > in rtl8192c. As I see it, we essentially will need to start from > scratch. The things that r8712u does to the hardware will be a > guide, but there will likely be little cut-n-paste. This does not surprise me _too_ much, but it's still a bit more gutting/re-writing than I'd expected. And the requisite analysis of its sister drivers adds to the task. _You_ are in a better position to re-write this from scratch; _my_ plan was to do this incrementally. I'll somehow have to fit the sister-drivers analysis into the following: 1. add the deltas for the new realtek code; 2. replace the crypto calls (eg r8712_tkip_encrypt) with lib80211; 3. add the mac80211 interface. (I suppose this is the point at which I can share code with the other drivers.) 4. check to see if any further work is needed for providing an nl80211 configration interface. Unless if checking such patches will create more work for you than if you were to write everything yourself, I can proceed. regards, ali > Larry _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
