Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC 2/7] cfg80211: express channels with a KHz component
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
References: <20200401062150.3324-1-thomas@adapt-ip.com>
 <20200401062150.3324-3-thomas@adapt-ip.com>
 <52850c8eb3131ca742eea30a21a7e685a3a3045b.camel@sipsolutions.net>
 <69451a0a-4bca-36f8-4295-9a386585c244@adapt-ip.com>
 <bbc12ff536862a8ca693c20b8721092979c49a36.camel@sipsolutions.net>
From:   Thomas Pedersen <thomas@adapt-ip.com>
Message-ID: <b8068983-f6c8-8f9c-c131-8e8d0c229aa0@adapt-ip.com>
Date:   Wed, 1 Apr 2020 14:32:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <bbc12ff536862a8ca693c20b8721092979c49a36.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 4/1/20 10:53 AM, Johannes Berg wrote:
> On Wed, 2020-04-01 at 10:30 -0700, Thomas Pedersen wrote:
>>>> +static int __ieee80211_frequency_to_channel(u32 freq)
>>>
>>> export the double-underscore helpers like this one instead? That'd still
>>> be less code overall, IMHO.
>>
>> I didn't want to change the interface for
>> ieee80211_frequency_to_channel(). It's a little confusing that one takes
>> MHz, but the __ieee80211_frequency_to_channel() takes KHz? By giving the
>> _khz() hint in the wrapper we were trying to make it explicit. Similar
>> to below.
> 
> Right. I think that's fine. I was just wondering if / thinking that it
> may be better to just export ieee80211_freq_khz_to_channel(), and
> express the other ones as inline function in terms of that?
> 
>>> And maybe here? In fact, how is __ieee80211_get_channel() even different
>>> from ieee80211_get_channel_khz()?
>>
>> It's not. I thought the _khz() hint was helpful for the reader to keep
>> the units straight.
> 
> Agree, but then you don't need the double-underscore version and can
> just express the old one in terms of the _khz one?
> 
>> What do you think about keeping the interfaces in place, but otherwise
>> converting them to inline functions (where it makes sense)?
> 
> Yes, I think that's what I had in mind.

OK I get it. That is a lot cleaner.

-- 
thomas