[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE1C82FB3D0EC64DB1F752C81CBD1101391FC38C@DFRE01.ent.ti.com>
Date: Wed, 13 Jul 2016 10:11:25 +0000
From: "Machani, Yaniv" <yanivma@...com>
To: Johannes Berg <johannes@...solutions.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "Hahn, Maital" <maitalm@...com>
Subject: 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@...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
Powered by blists - more mailing lists