[Fwd: please don't regress ath5k.h]

[Fwd: please don't regress ath5k.h]

[Richard Farina]

sorry for sending twice, accidentally sent to owner instead of list...

wireless-testing.git/drivers/net/wireless/ath5k/ath5k.h

/* TODO: Clean up channel debuging -doesn't work anyway- and start
* working on reg. control code using all available eeprom information
* -rev. engineering needed- */
#define CHAN_DEBUG      0


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.  I 
don't believe I need all of the features that chan_debug provides, but 
when I set chan_debug to 0 it severely limits the number of channels 
that I can set the driver to.  I currently maintain a patch that 
supports 471 channels for atheros a/b/g cards and without chan_debug 1 
it simply cuts the top channels off (because it isn't able to have that 
many channels).  It is my opinion that the driver should support what 
the hardware supports and the regulatory requirements should be handled 
by crda as expected, I will submit some patches to this effect asap but 
in the mean time please do not remove chan_debug without enabling 
support for at least 471 channels to be stored (and it would be cool to 
cc me on that patch so I can follow it and make sure it works for me).

Thanks,
Rick Farina

PS> Please note, this is not meant to start a discussion about adding in 
addition channels that may or may not be legal, I promise I'll start 
that discussion next, but this mail is to request that a feature I'm not 
using not be removed from the driver breaking my work.  Thanks.

Re: [Fwd: please don't regress ath5k.h]

[Michael Renzmann]

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?

Bye, Mike

Re: [Fwd: please don't regress ath5k.h]

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Fwd: please don't regress ath5k.h]

[Richard Farina]

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

Re: [Fwd: please don't regress ath5k.h]

[Jouni Malinen]

On Mon, Nov 24, 2008 at 10:29:52AM -0500, Richard Farina wrote:

> 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.

I would actually prefer to reduce this number _way_ down to something
reasonable in the upstream kernel. ath5k should not really register more
than channels 1-14 in 2.4 GHz and 5 GHz channels that are really used
(i.e., only every fourth and only at ISM bands). The maximum number
would be somewhere closer to 40 than 500..

If you have a license to use other frequencies, you can take care of
that with your own private patches, but the upstream kernel should not
do that. Channels in 2.3 GHz or 2.5 GHz or many of the 5 GHz areas that
are currently registered do not really belong here in the upstream
kernel no matter what the hardware might be capable of doing.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [Fwd: please don't regress ath5k.h]

[Richard Farina]

Jouni Malinen wrote:
> On Mon, Nov 24, 2008 at 10:29:52AM -0500, Richard Farina wrote:
>
>   
>> 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.
>>     
>
> I would actually prefer to reduce this number _way_ down to something
> reasonable in the upstream kernel. ath5k should not really register more
> than channels 1-14 in 2.4 GHz and 5 GHz channels that are really used
> (i.e., only every fourth and only at ISM bands). The maximum number
> would be somewhere closer to 40 than 500..
>
> If you have a license to use other frequencies, you can take care of
> that with your own private patches, but the upstream kernel should not
> do that. Channels in 2.3 GHz or 2.5 GHz or many of the 5 GHz areas that
> are currently registered do not really belong here in the upstream
> kernel no matter what the hardware might be capable of doing.
>
>   
Your response to my request seems a bit flawed in my eyes.  Drivers are 
supposed to run the hardware, we have crda to handle limiting the device 
back to to what is legal in your area.  I'm sure there are places where 
it is legal to use 2192MHz and even if not, look at the driver, it has a 
max of 2732MHz set in the driver (for the .11b/g radio), clearly the 
person who wrote that agrees that drivers should support the hardware.

Honestly if you want to argue the legality I purposely posted an RFC for 
that, this change (and this email thread) is to stop a regression that 
would cause the hardware to no longer be fully and properly supported.

Yes, I can maintain my own personal patches to all of the drivers in the 
kernel (as a matter of fact I likely do) but this kind of thing belongs 
in the kernel, we are discussing hardware support, nothing more.  
Limiting the driver to enforce some random regulatory domain is 
pointless and against kernel policy as reg domain enforcement is 
supposed to be handled by crda or oldreg.

Thanks,
Rick

Re: [Fwd: please don't regress ath5k.h]

[Luis R. Rodriguez]

On Mon, Nov 24, 2008 at 10:39 AM, Richard Farina <sidhayn@gmail.com> wrote:
> Jouni Malinen wrote:
>>
>> On Mon, Nov 24, 2008 at 10:29:52AM -0500, Richard Farina wrote:
>>
>>
>>>
>>> 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.
>>>
>>
>> I would actually prefer to reduce this number _way_ down to something
>> reasonable in the upstream kernel. ath5k should not really register more
>> than channels 1-14 in 2.4 GHz and 5 GHz channels that are really used
>> (i.e., only every fourth and only at ISM bands). The maximum number
>> would be somewhere closer to 40 than 500..
>>
>> If you have a license to use other frequencies, you can take care of
>> that with your own private patches, but the upstream kernel should not
>> do that. Channels in 2.3 GHz or 2.5 GHz or many of the 5 GHz areas that
>> are currently registered do not really belong here in the upstream
>> kernel no matter what the hardware might be capable of doing.
>>
>>
>
> Your response to my request seems a bit flawed in my eyes.  Drivers are
> supposed to run the hardware, we have crda to handle limiting the device
> back to to what is legal in your area.

CRDA does indeed handle proper regulatory rules for a country however
keep in mind drivers still need to use the data it is calibrated for.
So although the radio can technically use certain frequency ranges you
will find only find calibrated data for the device's targeted EEPROM
settings and for its world roaming capabilities.

>  I'm sure there are places where it
> is legal to use 2192MHz and even if not, look at the driver, it has a max of
> 2732MHz set in the driver (for the .11b/g radio), clearly the person who
> wrote that agrees that drivers should support the hardware.

Please send patches to the wireless regulatory database if such places
do exist and please provide documentation of such findings:

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git

Once we have listed a country with these settings then it makes sense
to add it to the database and to the card's capabilities. Keep in mind
that the EEPROM will always be respected though (patches pending).

> Honestly if you want to argue the legality I purposely posted an RFC for
> that, this change (and this email thread) is to stop a regression that would
> cause the hardware to no longer be fully and properly supported.

This part is certainly important, and is greatly appreciated.

> Yes, I can maintain my own personal patches to all of the drivers in the
> kernel (as a matter of fact I likely do) but this kind of thing belongs in
> the kernel,

What belongs in the kernel is driver components to make your 802.11
work. The arguments used here are similar to that of disagreeing with
easily allowing mac80211 to allow APs to operate without proper power
save implementation.

> we are discussing hardware support, nothing more.

Yes however the channels must be registered too and the EEPROM must be
respected. More work on that area is in the right direction.

> Limiting the
> driver to enforce some random regulatory domain is pointless and against
> kernel policy as reg domain enforcement is supposed to be handled by crda or
> oldreg.

oldreg is just that -- old, and it will be removed. It was there to
help with the migration and to account for the fact distributions may
not have CRDA packaged yet. Drivers should register channels that make
sense to support for 802.11, not every single channel a radio is
capable of tuning into. If not you'd be seeing the channel list
growing for other drivers  as well.

  Luis

Re: [Fwd: please don't regress ath5k.h]

[Richard Farina]

Luis R. Rodriguez wrote:
> On Mon, Nov 24, 2008 at 10:39 AM, Richard Farina <sidhayn@gmail.com> wrote:
>   
>> Jouni Malinen wrote:
>>     
>>> On Mon, Nov 24, 2008 at 10:29:52AM -0500, Richard Farina wrote:
>>>
>>>
>>>       
>>>> 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.
>>>>
>>>>         
>>> I would actually prefer to reduce this number _way_ down to something
>>> reasonable in the upstream kernel. ath5k should not really register more
>>> than channels 1-14 in 2.4 GHz and 5 GHz channels that are really used
>>> (i.e., only every fourth and only at ISM bands). The maximum number
>>> would be somewhere closer to 40 than 500..
>>>
>>> If you have a license to use other frequencies, you can take care of
>>> that with your own private patches, but the upstream kernel should not
>>> do that. Channels in 2.3 GHz or 2.5 GHz or many of the 5 GHz areas that
>>> are currently registered do not really belong here in the upstream
>>> kernel no matter what the hardware might be capable of doing.
>>>
>>>
>>>       
>> Your response to my request seems a bit flawed in my eyes.  Drivers are
>> supposed to run the hardware, we have crda to handle limiting the device
>> back to to what is legal in your area.
>>     
>
> CRDA does indeed handle proper regulatory rules for a country however
> keep in mind drivers still need to use the data it is calibrated for.
> So although the radio can technically use certain frequency ranges you
> will find only find calibrated data for the device's targeted EEPROM
> settings and for its world roaming capabilities.
>
>   
Considering the fact that multiple companies sell Atheros wireless cards 
that support 4.9GHz and even down to 4.4GHz I'm going to guess that the 
hardware is capable just fine.  If it provides poor performance in 
testing then so be it, but right now, it looks pretty clean on the 
spectrum analyzer from where I was sitting the day I did my testing.
>>  I'm sure there are places where it
>> is legal to use 2192MHz and even if not, look at the driver, it has a max of
>> 2732MHz set in the driver (for the .11b/g radio), clearly the person who
>> wrote that agrees that drivers should support the hardware.
>>     
>
> Please send patches to the wireless regulatory database if such places
> do exist and please provide documentation of such findings:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
>
> Once we have listed a country with these settings then it makes sense
> to add it to the database and to the card's capabilities. Keep in mind
> that the EEPROM will always be respected though (patches pending).
>
>   
This seems kind of silly, I was purposely avoiding updating crda because 
I'm sure that if I do 99% of the people that use these frequencies will 
be breaking the law.  At your request, I will send my suggested change 
set to wireless-regdb.  I only know about the USA but I'm sure if I 
google hard enough I can expand it at a later time.
>> Honestly if you want to argue the legality I purposely posted an RFC for
>> that, this change (and this email thread) is to stop a regression that would
>> cause the hardware to no longer be fully and properly supported.
>>     
>
> This part is certainly important, and is greatly appreciated.
>
>   
>> Yes, I can maintain my own personal patches to all of the drivers in the
>> kernel (as a matter of fact I likely do) but this kind of thing belongs in
>> the kernel,
>>     
>
> What belongs in the kernel is driver components to make your 802.11
> work. The arguments used here are similar to that of disagreeing with
> easily allowing mac80211 to allow APs to operate without proper power
> save implementation.
>
>   
>> we are discussing hardware support, nothing more.
>>     
>
> Yes however the channels must be registered too and the EEPROM must be
> respected. More work on that area is in the right direction.
>
>   
I never said anything about hacking around the eeprom, nor did I even 
mention allowing people to tx on the channels I am adding.  Frankly I'd 
like to see half of what I do remain out of kernel because of the 
obvious problem of abuse, the changes I have outlined so far belong in 
the kernel to allow the hardware to operate to it's full extent.
>> Limiting the
>> driver to enforce some random regulatory domain is pointless and against
>> kernel policy as reg domain enforcement is supposed to be handled by crda or
>> oldreg.
>>     
>
> oldreg is just that -- old, and it will be removed. It was there to
> help with the migration and to account for the fact distributions may
> not have CRDA packaged yet. Drivers should register channels that make
> sense to support for 802.11, not every single channel a radio is
> capable of tuning into. If not you'd be seeing the channel list
> growing for other drivers  as well.
>
>   
Exactly why does 4400MHz not make sense to use 802.11 on in your 
opinion?  NATO disagrees as they have adopted equipment such as this:
http://www.belairnetworks.com/solutions/armed_forces.cfm

wireless-regdb update coming up next...

Thanks,
Rick Farina
>   Luis
>
>   

Re: [Fwd: please don't regress ath5k.h]

[Luis R. Rodriguez]

On Mon, Nov 24, 2008 at 02:21:41PM -0800, Richard Farina wrote:
> Considering the fact that multiple companies sell Atheros wireless cards
> that support 4.9GHz and even down to 4.4GHz I'm going to guess that the
> hardware is capable just fine.  If it provides poor performance in
> testing then so be it, but right now, it looks pretty clean on the
> spectrum analyzer from where I was sitting the day I did my testing.

IIRC the way some of these frequencies work with Ubiquity cards are to
use the hardware's actual center of freqs andand these are then actually
mapped internally to the radio's lower freqs. At least this is how I saw
it working with the cards I had tried a while back.

> >>  I'm sure there are places where it
> >> is legal to use 2192MHz and even if not, look at the driver, it has a max of
> >> 2732MHz set in the driver (for the .11b/g radio), clearly the person who
> >> wrote that agrees that drivers should support the hardware.
> >>
> >
> > Please send patches to the wireless regulatory database if such places
> > do exist and please provide documentation of such findings:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
> >
> > Once we have listed a country with these settings then it makes sense
> > to add it to the database and to the card's capabilities. Keep in mind
> > that the EEPROM will always be respected though (patches pending).
> >
> >
> This seems kind of silly, I was purposely avoiding updating crda because
> I'm sure that if I do 99% of the people that use these frequencies will
> be breaking the law.

CRDA should have what *is* allowed for each country. Your driver then
can use its EEPROM for proper settings for a country. A user can further
enhance compliance by choosing the country he/she is in. What gets into
the kernel is code to properly enable your device for what it is
designed to do. What you end up doing later on (sharks with lasers
on their head) is up to you.

> At your request, I will send my suggested change
> set to wireless-regdb.  I only know about the USA but I'm sure if I
> google hard enough I can expand it at a later time.

Thanks.

> >> Honestly if you want to argue the legality I purposely posted an RFC for
> >> that, this change (and this email thread) is to stop a regression that would
> >> cause the hardware to no longer be fully and properly supported.
> >>
> >
> > This part is certainly important, and is greatly appreciated.
> >
> >
> >> Yes, I can maintain my own personal patches to all of the drivers in the
> >> kernel (as a matter of fact I likely do) but this kind of thing belongs in
> >> the kernel,
> >>
> >
> > What belongs in the kernel is driver components to make your 802.11
> > work. The arguments used here are similar to that of disagreeing with
> > easily allowing mac80211 to allow APs to operate without proper power
> > save implementation.
> >
> >
> >> we are discussing hardware support, nothing more.
> >>
> >
> > Yes however the channels must be registered too and the EEPROM must be
> > respected. More work on that area is in the right direction.
> >
> >
> I never said anything about hacking around the eeprom, nor did I even
> mention allowing people to tx on the channels I am adding.  Frankly I'd
> like to see half of what I do remain out of kernel because of the
> obvious problem of abuse, the changes I have outlined so far belong in
> the kernel to allow the hardware to operate to it's full extent.

I beleive you are missing my point though. I recently reviewed ath9k
regulatory for example and initially I was going to register every
single 5MHz step on the radio as a possibly used frequency. This is not
right because of the point Jouni mentions and a few others:

  * Your active and passive scan will take a lot longer
  * Calibrated data is tuned and tested for each standard channel
    the device has been tested for, not every frequency hop the device
    is capable of.
  * If you have a custom solution you can customize the driver
  * Custom solutions sometimes require 1-1 mapping of an intended
    frequency to a virtual frequency. To know exactly what frequency
    you really are operating requires customizations and patches for
    these type of devices.

What we want to support is standard 802.11 operation for the stanard
user for the regulatory regions in the regulatory database. Experimenters
and people with licenses to operate in non standard frequencies can go
ahead and tweak the driver and support it as they see fit, specially if
the devices have been properly calibrated to do so.

> >> Limiting the
> >> driver to enforce some random regulatory domain is pointless and against
> >> kernel policy as reg domain enforcement is supposed to be handled by crda or
> >> oldreg.
> >>
> >
> > oldreg is just that -- old, and it will be removed. It was there to
> > help with the migration and to account for the fact distributions may
> > not have CRDA packaged yet. Drivers should register channels that make
> > sense to support for 802.11, not every single channel a radio is
> > capable of tuning into. If not you'd be seeing the channel list
> > growing for other drivers  as well.
> >
> >
> Exactly why does 4400MHz not make sense to use 802.11 on in your
> opinion?  NATO disagrees as they have adopted equipment such as this:
> http://www.belairnetworks.com/solutions/armed_forces.cfm

NATO is not a regulatory agency, the FCC and currently the rules to
follow for the US follow Part 15 rules, not what a NATO document tells
you. If you see information on Part 15 rules which indicate you cna use
4400 MHz then by all means do send a patch to the wireless-regdb and
document your finding.

  Luis

Re: [Fwd: please don't regress ath5k.h]

[Nick Kossifidis]

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

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.

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
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.

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).

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.

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [Fwd: please don't regress ath5k.h]

[Richard Farina]

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

Re: [Fwd: please don't regress ath5k.h]

[Nick Kossifidis]

2008/11/24 Nick Kossifidis <mickflemm@gmail.com>:
>
> 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.
>

*Correction: allocate

ATH_CHAN_MAX has nothing to do with how many channels we register,
it's jut used on base.h to set how many channels we 'll have on our
channel array.


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick