All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Bob Copeland <me@bobcopeland.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
	"linville@tuxdriver.com" <linville@tuxdriver.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix()
Date: Wed, 26 Aug 2009 09:29:41 -0700	[thread overview]
Message-ID: <20090826162941.GA4417@mosca> (raw)
In-Reply-To: <b6c5339f0908260708l38208046o43330d9eda808b1e@mail.gmail.com>

On Wed, Aug 26, 2009 at 07:08:55AM -0700, Bob Copeland wrote:
> On Tue, Aug 25, 2009 at 7:38 PM, Luis R. Rodriguez<lrodriguez@atheros.com>
> > First thing I saw upon a quick review was we were relying on our own
> > curband for RX instead of the cfg80211 hw->conf band. Now granted
> > that *may* be updated properly, and it seems that may be the case,
> 
> Looks good at first glance, except it conflicts with changes I
> recently posted.  I'm all for getting rid of driver copies of stuff
> in the stack.

I can rebase.

> > -       /* NB: setup here so ath5k_rate_update is happy */
> > -       if (test_bit(AR5K_MODE_11A, ah->ah_modes))
> > -               ath5k_setcurmode(sc, AR5K_MODE_11A);
> > -       else
> > -               ath5k_setcurmode(sc, AR5K_MODE_11B);
> > -
> 
> I take it ath5k_rate_update didn't really care?

Well I nuked ath5k_setcurmode() and didn't see anything relying on that
stuff.

> >  ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> >  {
> >        ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz)\n",
> > -               sc->curchan->center_freq, chan->center_freq);
> > +               sc->hw->conf.channel->center_freq, chan->center_freq);
> 
> So, does hw->conf.channel change before we're told to change channel,
> or after?

Oh bummer, good thing you asked as I simply assumed it would be set *after*.
Turns out its done prior to the drv_config() call.

        if (chan != local->hw.conf.channel ||
            channel_type != local->hw.conf.channel_type) {
                local->hw.conf.channel = chan;
                local->hw.conf.channel_type = channel_type;
                changed |= IEEE80211_CONF_CHANGE_CHANNEL;
        }

	...

        if (changed && local->open_count) {
                ret = drv_config(local, changed);
		...
	}

I suppose we can just remove that printk ? :)

> > -       if (chan) {
> > -               ath5k_hw_set_imr(ah, 0);
> > -               ath5k_txq_cleanup(sc);
> > -               ath5k_rx_stop(sc);
> > -
> > -               sc->curchan = chan;
> > -               sc->curband = &sc->sbands[chan->band];
> > -       }
> 
> Unless I missed something I think we still want:
> 
>     if (chan_change)
>         ath5k_chan_set(...);

Not sure I follow. Let me explain the logic here a little better.
ath5k_reset() had a check to see if we switched channels. The check
is above, and I moved it ath5k_chan_set() called by the config callback.
Reason for this is channel change *only* occurs through the config callback
so we can be certain no other path will call reset with a channel change
request.

> > -       ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
> > +       ret = ath5k_hw_reset(ah, sc->opmode, chan, chan_change);
> 
> There's just no synchronization of this stuff, not too surprising there
> are races.

config calls for reset seem to be with sc->lock. ath9k uses a mutex to
protect races between mac80211 callback calls, ath5k seems to use the
sc->lock *sometimes*, a good review of that may help but for channel
change this seems protected unless I missed something. Since channel
change goes through the config callback and since the callback protects
through sc->lock I can't see how we'd race against changing channels.

  Luis

  reply	other threads:[~2009-08-26 16:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25 18:25 [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix() Luis R. Rodriguez
2009-08-25 18:45 ` Bob Copeland
2009-08-25 18:58   ` Luis R. Rodriguez
2009-08-25 19:22     ` Bob Copeland
2009-08-25 23:38       ` Luis R. Rodriguez
2009-08-25 23:52         ` Luis R. Rodriguez
2009-08-26 14:08         ` Bob Copeland
2009-08-26 16:29           ` Luis R. Rodriguez [this message]
2009-08-26 17:03             ` Bob Copeland
2009-08-26 20:20               ` Luis R. Rodriguez

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=20090826162941.GA4417@mosca \
    --to=lrodriguez@atheros.com \
    --cc=Luis.Rodriguez@Atheros.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=me@bobcopeland.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.