Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1442293 > unrolled thread

RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are  stopped "Machani, Yaniv" <yanivma@ti.com> - 2016-07-13 12:20 +0200
    Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are  stopped Bob Copeland <me@bobcopeland.com> - 2016-07-13 15:40 +0200
      RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are  stopped "Machani, Yaniv" <yanivma@ti.com> - 2016-07-13 22:00 +0200

#1442293 — RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

On Wed, Jun 29, 2016 at 10:14:19, Johannes Berg wrote:
> Cc: Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> > From: Maital Hahn <maitalm@ti.com>
> >
> > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > de-initialization process will be stopping the beacons, similar to ap.
> > Update ieee80211_stop_mesh() flow accordingly.
> >
> How well have you tested that with other drivers?
> 

Sorry for the delayed response (I've been out) and thanks for your comments,
I have tested it with RT3572 as well, and didn't see any issue.
I'll update the comment to reflect that.

Thanks,
Yaniv

> Changing behaviour to something a single driver desires isn't 
> necessarily the best thing to do, since there always are multiple drivers.
> 
> If you're able to demonstrate that it works with the other drivers I'm 
> willing to take that - the change makes sense after all, and it seems 
> drivers must support this ordering since peers are also removed 
> dynamically... But still. Don't just make a change like that without 
> even giving any indication why you think it's fine for other drivers!
> 
> johannes

[toc] | [next] | [standalone]

#1442461

On Wed, Jul 13, 2016 at 10:11:25AM +0000, Machani, Yaniv wrote:
> > > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > > de-initialization process will be stopping the beacons, similar to ap.
> > > Update ieee80211_stop_mesh() flow accordingly.
> > >
> > How well have you tested that with other drivers?
> > 
> 
> Sorry for the delayed response (I've been out) and thanks for your comments,
> I have tested it with RT3572 as well, and didn't see any issue.
> I'll update the comment to reflect that.

I'll give this a test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.

-- 
Bob Copeland %% http://bobcopeland.com/

[toc] | [prev] | [next] | [standalone]

#1442796

On Wed, Jul 13, 2016 at 16:33:38, Bob Copeland wrote:
> linux- wireless@vger.kernel.org; netdev@vger.kernel.org; Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Wed, Jul 13, 2016 at 10:11:25AM +0000, Machani, Yaniv wrote:
> > > > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > > > de-initialization process will be stopping the beacons, similar to ap.
> > > > Update ieee80211_stop_mesh() flow accordingly.
> > > >
> > > How well have you tested that with other drivers?
> > >
> >
> > Sorry for the delayed response (I've been out) and thanks for your 
> > comments, I have tested it with RT3572 as well, and didn't see any issue.
> > I'll update the comment to reflect that.
> 
> I'll give this a test on ath10k and wcn36xx as they are the ones most 
> likely to care about ordering.
> 

Thank you,
Yaniv
> --
> Bob Copeland %% http://bobcopeland.com/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web