All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <hschaa@suse.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC v2] basic background scan
Date: Wed, 24 Sep 2008 17:55:15 +0200	[thread overview]
Message-ID: <200809241755.15950.hschaa@suse.de> (raw)
In-Reply-To: <1222270421.4257.37.camel@johannes.berg>

Am Mittwoch, 24. September 2008 17:33:41 schrieb Johannes Berg:
> On Wed, 2008-09-24 at 17:19 +0200, Helmut Schaa wrote:
> > Am Mittwoch, 24. September 2008 16:46:18 schrieb Johannes Berg:
> > > On Wed, 2008-09-24 at 16:36 +0200, Helmut Schaa wrote:
> > > > Could somebody please have a look at the TODO comments (I have no
> > > > idea how to wait until all null-func frames are ACKed)? Thanks.
> > >
> > > It's not really possible.
> > >
> > :(
>
> What I meant to say is that it'll give problems with drivers that don't
> do status reporting properly, and what are you going to do when one of
> them fails anyway? retry it? how long? assume the connection was lost if
> it isn't acked? I see little point in it to start with.

The main reason why I'd like to know when the frame was acked is that it might 
happen (and it did happen in my tests already) that the frame notifying the 
AP about entering power save state wasn't send before switching to another 
channel. Hence the AP won't buffer any frames for us.

> > > > +				netif_tx_wake_all_queues(sdata->dev);
> > >
> > > This is worsening a problem we already have -- you can enable queues
> > > that the driver asked to be disabled. Until we fix that, I don't think
> > > we should tempt our luck even more.
> >
> > I see! That's really problematic.
> > Do you have already an idea on how to fix it?
>
> Not really; introduce bits somewhere to keep track of who wants to
> enable/disable queues I guess.

A first trivial solution would be to just store which queues are active
when the scan is started and restarting only these queues after the scan
completed.

> > > And why is sw_scanning false if bg_scanning is true anyway?
> >
> > During a background scan the sw_scanning flag is set when a scan phase is
> > active and unset when an operation phase is active. Therefore I did not
> > need to adapt all checks for sw_scanning.
>
> Oh, hmm, ok, that might make the enum problematic. Or do something like
>
> SCAN_OFF,
> SCAN_BG,
> SCAN_SW,
> SCAN_HW
>
> then you can check for scan >= SCAN_SW

Maybe. Thinking about it.

Helmut

  reply	other threads:[~2008-09-24 15:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24 14:36 [RFC v2] basic background scan Helmut Schaa
2008-09-24 14:46 ` Johannes Berg
2008-09-24 15:19   ` Helmut Schaa
2008-09-24 15:33     ` Johannes Berg
2008-09-24 15:55       ` Helmut Schaa [this message]
2008-09-24 15:59         ` Johannes Berg
2008-09-24 16:07           ` Helmut Schaa
2008-09-24 16:06         ` Tomas Winkler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200809241755.15950.hschaa@suse.de \
    --to=hschaa@suse.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.