On Mon, Oct 04, 2010 at 09:41:56AM -0700, Johannes Berg wrote:
> On Mon, 2010-10-04 at 09:38 -0700, Luis R. Rodriguez wrote:
> > On Mon, Oct 04, 2010 at 06:15:52AM -0700, Johannes Berg wrote:
> > > On Fri, 2010-10-01 at 16:33 -0400, Luis R. Rodriguez wrote:
> > >
> > > > @@ -2203,6 +2204,14 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
> > > > return -EALREADY;
> > > > }
> > > >
> > > > + /*
> > > > + * right before this was authentication, that was on
> > > > + * the same the wk->chan so we need to ensure we temporarily
> > > > + * go back to the operating channel to send the disassocation.
> > > > + */
> > > > + local->tmp_channel = NULL;
> > > > + ieee80211_hw_config(local, 0);
> > > > +
> > >
> > > Yikes, no, you can't do this. You don't know what has been merged with
> > > the authentication work item, etc.
> >
> > What do you mean? Auth/Assoc will be handled separately and the
> > target channel will also be handled for each work item run, what
> > issues can arise from sending us back to the home channel towards
> > the end of this call here?
>
> Another work item, like a remain-on-channel, might have been started on
> the same channel ("merged").
But how do this break that other work from moving forward in its respective
channel? The work_work loop makes sure to check if we require a channel
change on the work item.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
