Re: [RFC 5/6] ath9k: enable DFS pulse detection

[Christian Lamparter <chunkeey@googlemail.com>]

On Tuesday, October 04, 2011 04:17:35 PM Zefir Kurtisi wrote:
> On 10/04/2011 03:38 PM, Christian Lamparter wrote:
> > On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
> >> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
> >> <chunkeey@googlemail.com> wrote:
> >>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
> >>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> >>>>>
> >>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> >>>>> ---
> >>>>>  drivers/net/wireless/ath/ath9k/main.c |   12 ++++++++++++
> >>>>>  1 files changed, 12 insertions(+), 0 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> >>>>> index e8aeb98..5defebe 100644
> >>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
> >>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
> >>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
> >>>>>                        "Unable to reset channel, reset status %d\n", r);
> >>>>>                goto out;
> >>>>>        }
> >>>>> +#ifdef CONFIG_ATH9K_DFS
> >>>>
> >>>> Please spare the #ifdef and just call something within dfs.c, then
> >>>> dfs.h would wrap it to nothing if DFS is disabled.
> >>> Why would anyone want to disable DFS driver support?
> >>> I would say: drop the ifdefs altogether since DFS
> >>> is and will be "required".
> >>
> >> Because DFS requires to be properly tested before being enabled.
> > Testing if a driver detects a pulse is "trivial" compared to the
> > stuff mac80211/cfg80211 and hostapd will have to do to make a
> > channel-change as smooth as possible. I think if there's a DFS
> > "OFF" switch, it should be in hostapd and I hope more people
> > agree on this one.  
> > 
> Yes on both. Work on the management part of the DFS module has just
> been started by TI guys. When this is in, hostapd will be able to
> query the driver's DFS detection capabilities and leave DFS channels
> disabled for those devices with no (or insufficient) support
> (like it is generally done today for DFS channels).
> 
> The proper way for a driver's OFF switch would then be to just
> announce missing DFS capabilities.
Actually, I think we already have a flag for such a
purpose:
 * @IEEE80211_HW_SPECTRUM_MGMT:
 *      Hardware supports spectrum management defined in 802.11h
AFAIK 802.11h[now integrated in 802.11-2007] included DFS, right? 

> >> You may also want to simply disable DFS if you do not want to
> >> deal with the regulatory test implications of having it enabled.
> > AFAIK you can't "simply" disable the DFS requirement: hostapd
> > (hw_features.c), [cfg80211] (checks if tx on secondary channel
> > is possible) and mac80211 (tx.c) all have checks. Indeed, the
> > easiest way is to modify crda's database. So there's no need
> > for an extra compile-time option.
> > 
> There might be a demand for conditional compiling in addition to
> DFS capabilities announcements to reduce memory footprint, since
> (especially) pattern matching algorithms will increase it significantly.
I don't think memory footprint is such a big problem. After all ath9k
has around 170 kb [please correct me if I'm wrong here] of initvals
for all supported solutions since AR5008.

Regards,
	Chr