From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40064 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751519Ab2HVKNP (ORCPT ); Wed, 22 Aug 2012 06:13:15 -0400 Date: Wed, 22 Aug 2012 12:12:53 +0200 From: Stanislaw Gruszka To: Johannes Berg Cc: Mahesh Palivela , Kalle Valo , "linux-wireless@vger.kernel.org" , "linville@tuxdriver.com" Subject: Re: [PATCH] cfg80211: VHT (11ac) Regulatory change Message-ID: <20120822101252.GA6082@redhat.com> (sfid-20120822_121320_462094_71EA2CCE) References: <502E85D9.5050301@posedge.com> <1345480718.4459.37.camel@jlt3.sipsolutions.net> <87d32k7kga.fsf@purkki.adurom.net> <20120821081839.GA2380@redhat.com> <50338E84.3050709@posedge.com> <1345564421.10280.9.camel@jlt3.sipsolutions.net> <5033CE76.6040306@posedge.com> <1345619008.4635.3.camel@jlt3.sipsolutions.net> <20120822090104.GA4959@redhat.com> <1345626282.4635.8.camel@jlt3.sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1345626282.4635.8.camel@jlt3.sipsolutions.net> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Aug 22, 2012 at 11:04:42AM +0200, Johannes Berg wrote: > On Wed, 2012-08-22 at 11:01 +0200, Stanislaw Gruszka wrote: > > > > Yeah but we don't have that yet. We could do it that way, sure, but it > > > has wide-spread implications, since we'll need to > > > - use this new form of specifying channels all over mac80211 and all > > > drivers, > > > - define new nl80211 attributes for it, > > > - write new code in nl80211 to handle all this, > > > - and parse the old attributes into the new data structure(s) so > > > drivers use the new API but userspace can continue to use the old > > > > > > None of that is done yet. > > > > For starters (for regulatory purpose only) would be sufficient to > > implement > > > > regulatory_chan_use_permitted(center freq, bandwidth, whatever else), > > > > and use it where currently IEEE80211_CHAN_NO_HT_X flags are used. > > Yes, in theory. However, if this was intended to use the actual "center > freq, bandwidth, control channel offset" values, then it would be much > better to first actually define a struct to hold those, use it here, and > give it to drivers etc. Otherwise, drivers would have to take, e.g. > > - channel = 1 (2412 MHz) > - HT40+ > > and calculate > > - center freq = 2422 MHz > - bandwidth = 40 > - control channel offset = 0 > > before being able to call this function. To me, that seems wrong. I see, we could add helper function that will calculate center_freq/bandwidth, but starting from defining new channel structure and accompanying code in nl80211/mac80211 is more reasonable. Stanislaw