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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx> wrote: >>>>> >>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@xxxxxxxxxxx> >>>>> --- >>>>> 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. >> 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. > Regards, > Chr Zefir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
