On Thu, Sep 3, 2009 at 8:19 AM, Pavel Roskin<proski@xxxxxxx> wrote: > On Thu, 2009-09-03 at 12:08 +0530, Sujith wrote: >> CHANNEL_G has to be set for 2GHZ channels since >> IS_CHAN_G() checks for this in channelFlags and not in >> chanmode. To make things messier, ath9k_hw_process_ini() >> checks for CHANNEL_G in chanmode and not in channelFlags. >> The supreme, brain-searing fix is to set the >> flag in both cases. > > My impression is that's a workaround for a bug that lies elsewhere. I > don't think we should apply such patches. > > chanmode and channelFlags seem to duplicate each other. I would use an > enum for distinctive allowed modes and macros to query if the particular > mode has a specific feature (band, modulation, bandwidth etc). > > The enum could use ORed constants for optimization, but such constants > should be used only through the macros. I should mention ath9k_update_ichannel() was the last thing I intended on porting for the new regulatory changes we did on ath9k, when we ditched the old regulatory code, but I left it as it did involve quite a lot more changes in the code. When I reviewed this it seemed we could just rely on the hw->conf.channel->band for many things but in some cases we needed some defines for hw. So -- I'd personally welcome this change as a better alternative needs better planning, and more testing. Luis -- 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