Replacement for local->hw.conf.channel

Replacement for local->hw.conf.channel

[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?

Thanks,
Ben

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

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

[Johannes Berg]

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.

johannes

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

[Ben Greear]

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?

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


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

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

[Johannes Berg]

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.

johannes

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

[Ben Greear]

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

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

[Johannes Berg]

> > 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?

> 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

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

[Ben Greear]

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