Message-ID: <492B13E0.8070107@gmail.com> (sfid-20081124_215150_463600_B6E7EBAE)
Date: Mon, 24 Nov 2008 15:51:44 -0500
From: Richard Farina <sidhayn@gmail.com>
MIME-Version: 1.0
To: Nick Kossifidis <mickflemm@gmail.com>
CC: Johannes Berg <johannes@sipsolutions.net>,
	Michael Renzmann <mrenzmann@madwifi-project.org>,
	wireless <linux-wireless@vger.kernel.org>
Subject: Re: [Fwd: please don't regress ath5k.h]
References: <492A14A7.4040808@gmail.com>	 <1205.94.79.146.217.1227505499.squirrel@webmail.madwifi.org>	 <1227507381.3599.55.camel@johannes.berg> <492AC870.3030103@gmail.com> <40f31dec0811241225s1109b83aw244c96f2cb8ed59@mail.gmail.com>
In-Reply-To: <40f31dec0811241225s1109b83aw244c96f2cb8ed59@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: linux-wireless-owner@vger.kernel.org

Nick Kossifidis wrote:
> 2008/11/24 Richard Farina <sidhayn@gmail.com>:
>   
>> Johannes Berg wrote:
>>     
>>> On Mon, 2008-11-24 at 06:44 +0100, Michael Renzmann wrote:
>>>
>>>       
>>>> Hi.
>>>>
>>>> Richard Farina wrote:
>>>>
>>>>         
>>>>> I recently saw this additional comment added to wireless-testing.git and
>>>>> it has me a bit concerned.  I use this feature for a specific patch set
>>>>> that I maintain and it would break it pretty bad to remove this.
>>>>>
>>>>>           
>>>> Just an idea: what prevents you to add a patch to that patchset that
>>>> reenables the amount of code you require from the CHAN_DEBUG stuff should
>>>> it be removed upstream?
>>>>
>>>>         
>>> Seconded, upstream should remove all the junk that it doesn't directly
>>> need.
>>>
>>> johannes
>>>
>>>       
>> I actually don't have a problem with removing chan_debug, I was merely
>> requesting that the size hack it enables not be removed.
>>
>> More specifically in base.h I believe the code I specifically require is:
>>
>> #if CHAN_DEBUG
>> #define ATH_CHAN_MAX    (26+26+26+200+200)
>> #else
>> #define ATH_CHAN_MAX    (14+14+14+252+20)
>> #endif
>>
>>
>> When removing chan_debug just please leave the higher max.  To be honest I
>> don't know for sure what this code means but since enabling it fixes my
>> patch it is clearly required.  There is no reason to be removing this as I
>> am hoping to push a few patches upstream to properly support the
>> capabilities of the hardware.
>>
>> Thanks,
>> Rick
>>     
>
>   
Thanks a lot, I've been waiting for you to give your opinion.
> CHAN_DEBUG is an option i used a lot of time ago while debuging
> channel flags on madwifi-old-openhal. When we switched to mac80211 and
> ath5k, this code got useless, it just changes the maximum number of
> channels the driver allocates and has nothing to do with debuging,
> that's why i've put that TODO there. If you just want to register more
> channels on mac80211, you can always change or redefine ATH_CHAN_MAX.
>
>   
Considering the fact that I don't really understand how you have it laid 
now right now (I just know that I needed more) I certainly have no 
issues with you cleaning up the code, I am only requesting that while 
you are cleaning up you keep in mind that I'd like to be able to use all 
of the hardware that I bought and not 1/10th of it :-)
> However have in mind that card supports (at it's best) 26 2.4GHz
> channels and nearly 250 (i think) 5Ghz channels (eg. with 5Mhz
>   
I currently have 70 supported frequencies on the .11b/g radio and 241 on 
the .11a radio.  I am 99% sure that there are more frequencies that can 
be set on the .11a radio, up to a maximum of 160 more is what I will be 
testing next time I have a decent spectrum analyzer near me.
> spacing) but we currently allocate much more (ATH_CHAN_MAX is huge)
> because in madwifi-old-openhal we had to separate b channels from g
> channels and gTurbo channels (so 3*26) etc (same for a /a turbo) which
> is nonsense.
>
>   
I agree, that does sound like nonsense and a likely source of my confusion.
> So on the technical side this code is crap and i must clean it up asap
> :P even if we want to support all available hw frequencies we should
> at least allocate them one time, not 3 ! Also not all channels are
> actually available, synth might be able to tune to a wide range of
> frequencies but the whole card is not just the MAC/PHY chip. For
> example tuning your card to a frequency that hasn't been calibrated
> can (and probably will) result pretty bad performance and tx
> corruption due to mis-calibrated PHY. On extreme situations some other
> parts of your card (probably the power amplifier or parts of auto-gain
> control) might be permanently damaged, resulting a useless card (i
> have reports of fried cards while tuning them way out of range -eg
> 6Ghz).
>
>   
Actually it was 6.1GHz, I know this because I'm pretty sure I was the 
one that reported the failure to you ;-)
> We can't support anything like that upstream, the best we can do is
> provide a module option on ath5k to register all available hw channels
> on mac80211 (and then crda takes over) for users that want to
> experiment with different crda tables (eg. users that have licenses
> etc) and know what they are doing, but the default behavior should be
> to only register ISM channels to be on the safe side.
>
>   
In my opinion it is best for the driver to support the full feature set 
of the hardware and as you suggested to allow crda to do it's job and 
enforce the reg domain.  I would never expect oldreg or crda to allow 
you to set these crazy licensed frequencies by default, but the fact is, 
some of us are licensed and maintaining a driver patch for every wifi 
card I own (57 if you are interested) is a bit stupid when all I'm 
really doing is making the driver run the hardware.  In the future it 
would of course be nice to allow registered and licensed users (Amateur 
radio community, etc) to use these cards as they are capable.

Honestly I'm not sure why so many are dead set against this, all I'm 
asking is for the driver to run the hardware properly so that I don't 
need to patch as many things.  I don't expect my debug patches to crda 
to be added upstream, nor my cruel hack to old reg.  The cards will 
remain as they are now, incapable of breaking the law, I'm not asking to 
change that.

Thanks,
Rick Farina