All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org,
	John Linville <linville@tuxdriver.com>,
	Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
Date: Sat, 25 Jul 2009 17:44:02 -0400	[thread overview]
Message-ID: <1248558242.11389.13.camel@mj> (raw)
In-Reply-To: <200907252015.07010.helmut.schaa@googlemail.com>

On Sat, 2009-07-25 at 20:15 +0200, Helmut Schaa wrote:

> > Lack of SCAN_DONE in mac80211_scan_state.  We exit scanning through the
> > "entry point".
> 
> I also thought of a separate state SCAN_DONE or something similar but
> dropped that idea as the only thing this state would have to do is the
> call to ieee80211_scan_completed. So, once the scan is finished we
> just stay in SCAN_DECISION as long as the scan state machine gets poked
> again by a start_scan call.

It's just an idea.  I only touched that code because it was failing for
me.

There is some duplication of information between local->scanning and
local->next_scan_state, but it's probably hard to avoid.

> > Use of "unsigned long" for bitwise fields, such as queue_stop_reasons
> > and scanning.  This reminds me of the good old days where long was
> > always 32 bit, but int wasn't.  I think "unsigned int" should be enough,
> > and you can annotate it with __bitwise to make sparse catch some
> > misuses.
> 
> No objections :)

Sorry, it turns out test_bit() wants unsigned long.  I don't quite like
what it does, but I'm not going to rewrite it.

-- 
Regards,
Pavel Roskin

      parent reply	other threads:[~2009-07-25 21:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-25  5:18 [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel() Pavel Roskin
2009-07-25  8:54 ` Johannes Berg
2009-07-25  9:20   ` Helmut Schaa
2009-07-25 13:06 ` Helmut Schaa
2009-07-25 17:07   ` Pavel Roskin
2009-07-25 18:15     ` Helmut Schaa
2009-07-25 18:34       ` Helmut Schaa
2009-07-25 21:44       ` Pavel Roskin [this message]

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=1248558242.11389.13.camel@mj \
    --to=proski@gnu.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=helmut.schaa@googlemail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /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.