From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754177AbcFQTAX (ORCPT ); Fri, 17 Jun 2016 15:00:23 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36889 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752021AbcFQTAU (ORCPT ); Fri, 17 Jun 2016 15:00:20 -0400 Subject: Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces To: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= References: <1464791845-23944-1-git-send-email-zajec5@gmail.com> <574F30D8.5000300@broadcom.com> Cc: "linux-wireless@vger.kernel.org" , Brett Rudley , Arend van Spriel , "Franky (Zhenhui) Lin" , Hante Meuleman , Kalle Valo , Pieter-Paul Giesberts , Franky Lin , "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" , "open list:NETWORKING DRIVERS" , open list From: Arend van Spriel Message-ID: <576448C0.4080102@broadcom.com> Date: Fri, 17 Jun 2016 21:00:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17-06-16 14:30, Rafał Miłecki wrote: > On 1 June 2016 at 21:00, Arend van Spriel wrote: >> On 01-06-16 16:36, Rafał Miłecki wrote: >>> We already support adding extra (AP) interfaces so it also makes an >>> obvious sense to allow deleting them. >>> >>> Adding a new interface is implemented by sending request to firmware for >>> creating a new BSS and waiting for a proper event. Ideally deleting >>> interface should be handled in a similar way. There should be a request >>> to firmware for deleting BSS and firmware should respond with an event. >>> >>> Unfortunately it doesn't seem to work with recent firmwares. They never >>> seem to delete BSS and never send BRCMF_E_IF_DEL. As a workaround this >>> patch deletes Linux interface while keeping a track of BSSes present in >>> a firmware. If there is request for adding a new interface this code is >>> capable of reusing existing BSS-es. >> >> It is not so much an issue of recent firmware. Actually, on recent >> firmware 7.x.y.z and higher there are other command to create *and* >> delete additional interfaces. On the other hand we aim to support a >> large number of devices going back to bcm4329 so we have to come up with >> a scheme to use the new commands or fallback to old api. Let's hope we >> can reuse much of this effort you put in. > > You gave me a complex puzzle there :D It took me a while to find out > what API you meant. Actually, the puzzle was supposed to be for me, but I like your curiosity and persistence in digging up the (partial) info. > Finally I found an interesting wlioctl.h in SDK 9.10.178.27 that gave > me some clue. I got this SDK from ASUS RT-AC1200G+ open souce tarball. > There are 2 interesting structs: > > typedef struct wl_interface_create { > uint16 ver; /* version of this struct */ > uint32 flags; /* flags that defines the operation */ > struct ether_addr mac_addr; /* Optional Mac address */ > uint32 wlc_index; /* Optional wlc index */ > } wl_interface_create_t; > > typedef struct wl_interface_info { > uint16 ver; /* version of this struct */ > struct ether_addr mac_addr; /* MAC address of the interface */ > char ifname[BCM_MSG_IFNAME_MAX]; /* name of interface */ > uint8 bsscfgidx; /* source bsscfg index */ > } wl_interface_info_t; > > I couldn't find any corresponding WLC_* in wlioctl_defs.h, so I guess > I should use WLC_SET_VAR (or WLC_SET_VAR as you prefer) with some (huh)? anyway the api indeed uses what we call an iovar, ie. string-based ioctl. > string. Any tip what would it be? Something like > "wl_interface_create"? Can you reveal such a small secret? It is "interface_create" and "interface_remove". Regards, Arend