On Tue, Apr 8, 2008 at 9:59 PM, John W. Linville <linville at tuxdriver.com> wrote: > On Mon, Apr 07, 2008 at 11:42:52PM -0700, Greg KH wrote: > > On Tue, Apr 08, 2008 at 11:46:48AM +0530, JoJo jojo wrote: > > > > > e) wireless is a mess because of FCC regulations, they want > > > manufacturers to limit the operating capabilities of the > > > device(frequencies), manufacturers figure that its cheaper to do this > > > in s/w rather than h/w, by making a closed source firmware. I don't > > > see how we can improve this situation unless you can help EU legislate > > > it away (assuming US is a lost cause) > > > > The whole FCC thing is, in my personal opinion, a big excuse that some > > companies are using to not release the code for their hardware. If you > > notice, other companies do not believe this and have released code. > > I think it is actually some of both. Regulators (particularly the > FCC) have failed to eliminate the spectre of threat that might come > from opening specs and/or source code from vendors. Further, they > continue to countenance the notion that closed-source software is > somehow equivalent to locking-down a hardware device. This provides > enough "cover" for vendors to "run home" to an unfriendly stance > against open source if they have any desire to do so for whatever > other reasons may exist (embarassment about sloppy specs, perceived > competitive advantage, etc). > > > > Either way, the very capable, and active developers of the > > linux-wireless projects are working to resolve all of the wireless > > driver issues. If you have questions or concerns about these types of > > devices, please contact them. > > On behalf of my developers (who do all the work), I appreciate your > vote of confidence! > > While I'm here, let me invite any budding reverse engineers to > join us on linux-wireless at vger.kernel.org. As Greg mentioned the > reverse-engineered ath5k and b43 (and b43legacy) drivers continue > to develop, but both projects could use more help. In particular > the b43 folks need help reverse engineering the 802.11n devices. > > Also, there is a project underway to reverse-engineer support for > Airgo devices. I regret that I haven't spent much time with that > project, but I think it is well underway. Is the reverse engneer of Airgo device taken charge by Jeff Williams (http://airgo.wdwconsulting.net/mymoin)? We refer to it to developed the driver, however the driver is unstable. Jeff said the reverse engneer is carried out by hard research. Now I am reversing engneer the driver of Airgo device on Window. By the way, there is a strange assembly code from IDA Pro(a disassemble tool). I can not understand it. Where should the Windows assembly code be discussed? The assembly code is very simple, just write a value to ioremap space and check whether it take affect. However it is different between the value written(100h) and the value checked(10h). The assembly code(from IDA Pro 5.0): sub_13C00 proc near var_4= dword ptr -4 arg_0= dword ptr 8 push esi mov esi, [esp+arg_0] mov al, [esi+24Ah] test al, al jz short loc_13C71 mov eax, [esi+31F4h] push 100h ; Value add eax, 3000h push eax ; Register call ds:WRITE_REGISTER_ULONG mov eax, [esi+31F4h] mov ecx, [eax+3000h] mov [esp+arg_0], ecx mov edx, [esp+arg_0] and edx, 10h cmp dl, 10h jnz short loc_13C71 push edi mov edi, ds:KeStallExecutionProcessor lea esp, [esp+0] loc_13C50: ; MicroSeconds push 32h call edi ; KeStallExecutionProcessor mov eax, [esi+31F4h] mov eax, [eax+3000h] mov [esp+4+arg_0], eax mov ecx, [esp+4+arg_0] and ecx, 10h cmp cl, 10h jz short loc_13C50 pop edi loc_13C71: pop esi retn 4 sub_13C00 endp > > Beyond that there are projects underway for Marvell PCI hardware, > both the older 83xx and the newer 86xx stuff. The 83xx support > (using the mrv8k driver) is farther along, while the 86xx stuff > has made little progress. Marvell is at least somewhat friendly to > having these supported, although their documentation is a bit lax. > There are however (unmergeable) sample drivers available for each. > > Also lurking out there is support for the USB-based Prism2 devices. > The linux-wlan project had support for these, but the kernel.org > kernels do not. Hardware can be a bit hard to find... > > Well, enough food for thought for one message... :-) > > John > -- > John W. Linville > linville at tuxdriver.com > > > _______________________________________________ > devel mailing list > devel at linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel >
