Replacement for local->hw.conf.channel

DISCUSSION Ben Greear 2 participants 7 messages Jul 4, 2013 – Jul 9, 2013

Share & tools

Ben Greear

author

2013-07-04 00:01 UTC #0 lore raw

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?

Thanks,
Ben

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Johannes Berg

2013-07-04 07:28 UTC #1 lore raw

Quoted 5 lines · Ben Greear

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.

johannes

Ben Greear

author

2013-07-08 18:20 UTC #2 lore raw

Quoted 10 lines · Johannes Berg

Quoted 5 lines · Ben Greear
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?

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;

I haven't tried that yet in 3.10 or later, so maybe I don't need the hw.conf.channel in new code anyway.

Thanks,
Ben

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Johannes Berg

2013-07-08 18:31 UTC #3 lore raw

Quoted 12 lines · Ben Greear

Quoted 10 lines · Johannes Berg
Quoted 5 lines · Ben Greear
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.

Quoted 5 lines

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).

Quoted 7 lines

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.

johannes

Ben Greear

author

2013-07-08 18:47 UTC #4 lore raw

Quoted 24 lines · Johannes Berg

Quoted 12 lines · Ben Greear
Quoted 10 lines · Johannes Berg
Quoted 5 lines · Ben Greear
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.
Quoted 5 lines
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).
Quoted 2 lines
In 3.9, ath9k_htc was giving me a null channel in the code below:

Quoted 7 lines

Quoted 5 lines
	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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

Johannes Berg

2013-07-09 14:35 UTC #5 lore raw

Quoted 12 lines

Quoted 12 lines
No, don't use that in any new code. It's purely for compatibility with drivers that aren't converted to channel contexts (yet).
Quoted 7 lines
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;

Quoted 4 lines

Quoted 1 line
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?

Quoted 4 lines

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?

johannes

Ben Greear

author

2013-07-09 16:32 UTC #6 lore raw

Quoted 12 lines · Johannes Berg

Quoted 12 lines
Quoted 12 lines
No, don't use that in any new code. It's purely for compatibility with drivers that aren't converted to channel contexts (yet).
Quoted 7 lines
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;

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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.

Quoted 9 lines

Quoted 4 lines
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

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com