From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752644AbcGMKL7 (ORCPT ); Wed, 13 Jul 2016 06:11:59 -0400 Received: from arroyo.ext.ti.com ([198.47.19.12]:58937 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751144AbcGMKLs (ORCPT ); Wed, 13 Jul 2016 06:11:48 -0400 From: "Machani, Yaniv" To: Johannes Berg , "linux-kernel@vger.kernel.org" , "David S . Miller" , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" CC: "Hahn, Maital" Subject: RE: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped Thread-Topic: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped Thread-Index: AQHR0dXaB6Qv06QcZUmQ7FOqlDgLSqAWOJ8w Date: Wed, 13 Jul 2016 10:11:25 +0000 Message-ID: References: <20160628111307.8784-1-yanivma@ti.com> <20160628111307.8784-2-yanivma@ti.com> (sfid-20160628_131058_738638_5F9A964D) <1467184459.2461.1.camel@sipsolutions.net> In-Reply-To: <1467184459.2461.1.camel@sipsolutions.net> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.167.188.42] x-exclaimer-md-config: f9c360f5-3d1e-4c3c-8703-f45bf52eff6b Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u6DACfAs002534 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 > > > > 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