On Wed, 2013-11-06 at 11:51 +0100, Johannes Berg wrote:
> On Tue, 2013-11-05 at 22:54 +0200, Luciano Coelho wrote:
> > With a CSA count of 0, we won't transmit any CSA beacons, because the
> > switch will happen before the next TBTT. To avoid extra work and
> > potential confusion in the drivers, complete the CSA immediately,
> > instead of waiting for the driver to call ieee80211_csa_finish().
>
> Does it make sense to go to the workqueue rather than do it inline?
I guess not, it could be done inline too.
> Maybe we should just reject this? I'm a bit worried that this might
> confuse drivers that expect a certain order of calls?
AFAICT only ath9k is using this in the mainline. This change is only
related to the AP role, not to the client role (of which there are many
other users).
In terms of the order of calls, the difference is that in the past we
had this:
1. Set CSA beacon;
2. When count reaches 1, the driver calls ieee80211_csa_finish();
3. We call drv_change_chanctx();
4. Set new channel beacon.
(This continues to be the case with my patch when count > 1)
With my patch, if count <= 1, we do this instead:
1. Call drv_change_chanctx();
2. Set new channel beacon.
The main problem without my patch is that the driver shouldn't beacon
with the CSA element when the count starts <= 1, so it won't have a
chance to check if the count reached 1 to call ieee80211_csa_finish().
The other way to do this is:
1. Set CSA beacon;
2. Before setting the beacon, the driver checks if the count is <= 1;
3. If that's the case, the driver calls ieee80211_csa_finish()
immediatelly; otherwise it waits until the count becomes 1;
4. We call drv_change_chanctx();
5. Set new channel beacon.
With this, we get some useless churn and need to make sure the drivers
do the right thing...
Do you have any other proposal?
--
Cheers,
Luca.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
