Re: Replacement for local->hw.conf.channel

[Ben Greear <greearb@candelatech.com>]

On 07/08/2013 11:31 AM, Johannes Berg wrote:
> On Mon, 2013-07-08 at 11:20 -0700, Ben Greear wrote:
>> On 07/04/2013 12:27 AM, Johannes Berg wrote:
>>> On Wed, 2013-07-03 at 17:01 -0700, Ben Greear wrote:
>>>> I'm trying to port some patches forward to 3.10....
>>>>
>>>> I am trying to find the current channel for a radio.  Since
>>>> hw.conf.channel no longer exists, what is the best way to
>>>> go about this?
>>>
>>> Well there's hw.conf.chandef.chan now I think, but that can be NULL and
>>> generic mac80211 code must not use it. There's no single current channel
>>> any more, you want vif->chanctx or so.
>>
>>   From looking at the scanning code (line 542 or so), it appears
>>
>> local->_oper_chandef.chan
>>
>> might work?
>
> No, don't use that in any new code. It's purely for compatibility with
> drivers that aren't converted to channel contexts (yet).
>
>> In 3.9, ath9k_htc was giving me a null channel in the code below:
>>
>> 	chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
>> 	if (chanctx_conf)
>> 		channel = chanctx_conf->def.chan;
>> 	else
>> 		channel = NULL;
>
> Well that of course happens if the vif isn't bound to a channel context.

Any opinions on what to return in ethtool stats for frequency if
there is no channel context?

If there is a quick way to just return whatever the hardware is
currently using, I think that is best, but if there is not
a reliable way to do this then, some hard coded default
like 0 is probably best.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com