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

[Ben Greear <greearb@candelatech.com>]

On 07/09/2013 07:35 AM, Johannes Berg wrote:
>
>>> 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?
>
> Why even bother doing so? "iw dev" shows the frequency and channel width
> just fine, no?

Ethtool API can be a lot easier to code to than netlink (or parsing
iw text output), but it's a small issue.

If iw does return the results I'd be looking for, then maybe I can
go figure out how it gets that info in the kernel and use that
in the netlink code.

>> 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.
>
> Well there's no such concept as "what the hardware is currently using"
> in this case, the channel is completely pointless when there's no
> channel context at all. There might be something like the current scan
> channel, but what value would there be in returning that?

Ok, it's not a big deal either way...and I can work around it in user-space
by walking the list of all VIFs on a radio and grab the channel of any
that are actually associated and returning good info...

Thanks,
Ben


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