Return-path: Received: from mail-sn1nam02on0130.outbound.protection.outlook.com ([104.47.36.130]:14949 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751143AbcHKFHU convert rfc822-to-8bit (ORCPT ); Thu, 11 Aug 2016 01:07:20 -0400 From: Wright Feng To: Arend Van Spriel , "brcm80211-dev-list.pdl@broadcom.com" , "franky.lin@broadcom.com" , "hante.meuleman@broadcom.com" , "pieterpg@broadcom.com" , "Chi-Hsien Lin" , "linux-wireless@vger.kernel.org" , "kvalo@codeaurora.org" Subject: RE: [PATCH] brcmfmac: shut down AP and set IBSS mode only on primary interface Date: Thu, 11 Aug 2016 04:53:06 +0000 Message-ID: (sfid-20160811_070727_549172_99C4C057) References: <20160810080100.GA10783@cypress.com> <4d60ec5e-6462-372a-2d3c-5770493e7e98@broadcom.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 10-8-2016 12:15, Arend Van Spriel wrote: > On 10-8-2016 11:44, Wright Feng wrote: > > Hi Arend, > > > > Thanks for the reply. > > > > On 10-8-2016 10:26, Arend Van Spriel wrote: > >> On 10-8-2016 10:01, Wright Feng wrote: > >>> When stopping hostap on virtual interface, driver will set INFRA and > >>> AP mode that may affect the functionality on primary interface. For > >>> example, if we create and stop hostapd on virtual interface then > >>> association cannot work on primary interface because INFRA mode has > >> been set to IBSS. > >>> Hence we shut down AP and set IBSS mode only on primary interface. > >> > >> What is actually the use-case here. Can you elaborate? BRCMF_C_DOWN > >> command turns out to be effectively bring the whole stack down and > >> not just the supplied interface. I suppose you are hitting that issue here as > well, right? > > We want to use AP mode to let client connecting in AP+STA mode with > 43438 wi-fi chip. > > After that, the AP mode will be stopped, and wpa_supplicant cannot > associate to the access point. > > I describe the steps in detail as below. > > 1. Create virtual interface and set mode to __ap 2. start > > wpa_supplicant on primary interface and connect to wireless router. > > 3. start hostap daemon on virtual interface and let client connecting. > > 4. stop hostap daemon > > 5. wpa_supplicant cannot associate to access point normally. > > > > Like you said, the issue may be hit by BRCMF_C_DOWN and same as > > BRCMF_C_SET_INFRA BRCMF_C_SET_INFRA is not just for the supplied > interface either. The default bss will be changed in firmware and let firmware > uses IBSS mode to join. > > About BRCMF_C_DOWN, driver will set BRCMF_C_UP command to bring > device back up so it can be used again. > > However, there is no way to set INFRA mode back except starting AP mode > again. > > Ok. > > >> > >> Regards, > >> Arend > >> > >>> Signed-off-by: Wright Feng > >>> --- > >>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 > >> ++++- > >>> 1 file changed, 4 insertions(+), 1 deletion(-) > >>> > >>> diff --git > >>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c > >>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c > >>> index 2628d5e..0687ab9 100644 > >>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c > >>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c > >>> @@ -4716,6 +4716,8 @@ exit: > >>> > >>> static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, struct > >>> net_device *ndev) { > >>> + struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy); > >>> + struct net_device *primary_ndev = cfg_to_ndev(cfg); > >>> struct brcmf_if *ifp = netdev_priv(ndev); > >>> s32 err; > >>> struct brcmf_fil_bss_enable_le bss_enable; @@ -4723,7 > >>> +4725,8 @@ static int brcmf_cfg80211_stop_ap(struct wiphy *wiphy, > >>> struct net_device *ndev) > >>> > >>> brcmf_dbg(TRACE, "Enter\n"); > >>> > >>> - if (ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) { > >>> + if ((ifp->vif->wdev.iftype == NL80211_IFTYPE_AP) && > >>> + (ndev == primary_ndev)) { > >>> /* Due to most likely deauths outstanding we sleep */ > >>> /* first to make sure they get processed by fw. */ > >>> msleep(400); > >>> -- > >>> 1.9.1 > >>> > >>> > >>> This message and any attachments may contain Cypress (or its > >>> subsidiaries) > >> confidential information. If it has been received in error, please > >> advise the sender and immediately delete this message. > >>> > > > > This message and any attachments may contain Cypress (or its subsidiaries) > confidential information. If it has been received in error, please advise the > sender and immediately delete this message. > > Is there any way for you to get rid of this foot note. It may keep Kalle from > taking this patch. Other option is to take this patch through our internal tree. No problem. I will remove the footnote from the PATCH v2. > > Regards, > Arend This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.