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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
