Date: Tue, 07 Jun 2011 15:01:46 -0700 From: Matt <sendtomatt@gmail.com> To: bschmidt@freebsd.org Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 Message-ID: <4DEE9FCA.7030302@gmail.com> In-Reply-To: <201106070811.56236.bschmidt@freebsd.org> References: <4DD365A2.3090106@gmail.com> <20110606022257.39093142.ray@ddteam.net> <4DED769A.6040405@gmail.com> <201106070811.56236.bschmidt@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/06/11 23:11, Bernhard Schmidt wrote: > On Tuesday, June 07, 2011 02:53:46 Matt wrote: >> On 06/05/11 16:22, Aleksandr Rybalko wrote: >>> Hi folks, >>> >>> On Sun, 05 Jun 2011 15:24:52 -0700 >>> Matt<sendtomatt@gmail.com> wrote: >>> >>>> On 05/18/11 00:36, Adrian Chadd wrote: >>>>> On 18 May 2011 15:02, Sergey V. Dyatko<sergey.dyatko@gmail.com> >>>>> wrote: >>>>> >>>>>> As far I know Alexandr is too busy now (ported fbsd into one of >>>>>> d-link device). Hi have plans port ral code from openbsd. IIRC it >>>>>> was discussed not so long ago, in current@ >>>>> This thread reads to me like "hi, would someone like to pick up >>>>> Alex's work, liase with Alex/Bernhard, and bring the code up to >>>>> scratch so we can commit it to FreeBSD". >>>>> >>>>> Matt, how's your C? :) >>>>> >>>>> >>>>> Adrian >>>>> >>>> I've successfully got Alexandr's code worked into the Ral driver. >>>> This mainly involved some changes to if_ral_pci.c, renaming some >>>> softc stuff and pulling PCI code out of rt2860_attach. >>> Must say, that code not mine, wrote by Alexander Egorenkov (based on >>> OpenBSD one) + OpenBSD part for 3090 (but seems w/o LEDs :) ) and plus >>> my part for wireless embedded into SoC like RT3052F. >>> >>>> It's stable so far, WPA2 works fine as does Host AP etc (haven't >>>> tried with encryption). I haven't tested AHdemo, I assume monitor >>>> mode works. >>>> >>>> I want to eventually go through and place some chip specific fixes >>>> for 3090 etc., and possibly compare functions between different >>>> sources and make sure we're doing it right. >>>> >>>> Some questions: >>>> 1) If I kldunload if_ral while associated and flood pinging, I get >>>> "no route" for a while and then a page fault (only bug I've found so >>>> far). I assume this is something dumb I've done during detach? >>>> >>>> 2) My LED does not work. I have this in a Thinkpad WWAN slot, which >>>> are known to have issues with LED on some chips. A broadcom 4321 did >>>> activate the led in this slot. Can anyone confirm if they had a >>>> working LED using Alexandr's RT2860 stand alone driver? Or does work >>>> on LED code need to occur? >>>> >>>> Cheers, I'll remove my ugly printfs and post a patch or tarball later >>>> today. >>> Anyway, we (Adrian, Bernhard, PseudoCylon and me) discuss what there is >>> preferred to port current version of OpenBSD `ral` driver, and keep it >>> sync in future. But only one problem here, we all don't have time >>> right now for that :) >>> >>>> Matt >>> I hope someone found a time for it :) >>> >>> WBW >> Well, in anycase here is the patch I made for Ral. If no one wants to >> work on trying to port OpenBSD ral, I can try, but I am still learning >> very much! >> >> http://pastebin.com/GeAGVjtR >> >> Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile >> >> Note about patch, it's still alpha quality in that it has a known bug >> (do not kldunload while interface is running!) and it is largely >> untested. Changes include softc, pci code& all functions put in >> monolithic file (to help compare against OpenBSD ral, mainly). They are >> in the wrong order for now, however. Ultimate plan was to compare >> side-by-side with OpenBSD ral to assist porting. >> >> There is still an "ecosystem" of includes per rt2860 original, didn't >> get around to combining them. > Doesn't look bad at first glance, thx! At least the if_ral_pci.c > part looks like I'd have done it. ;) > > Do you have some unified diff also? I'd take a closer look then, > maybe we can get that into the tree. > I'll make unified diffs tonight...that's diff -u oldfile newfile >> bigpatch.patch, right? I'll keep hacking some changes into it...it sounds like LEDs never worked on x86/amd64 non-embedded platforms? It complains about extension channels some as well, so I may see what that's about. Thanks all! Matt In the Hat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DEE9FCA.7030302>