netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Brett Rudley <brudley@broadcom.com>,
	Arend van Spriel <arend@broadcom.com>,
	"Franky (Zhenhui) Lin" <frankyl@broadcom.com>,
	Hante Meuleman <meuleman@broadcom.com>,
	Kalle Valo <kvalo@codeaurora.org>,
	Pieter-Paul Giesberts <pieterpg@broadcom.com>,
	Franky Lin <franky.lin@broadcom.com>,
	"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER"
	<brcm80211-dev-list@broadcom.com>,
	"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces
Date: Fri, 17 Jun 2016 21:00:16 +0200	[thread overview]
Message-ID: <576448C0.4080102@broadcom.com> (raw)
In-Reply-To: <CACna6rzcfYu=3qoMsTCShHUWbpz-0-uWgogVLWJwiNv228PhPQ@mail.gmail.com>

On 17-06-16 14:30, Rafał Miłecki wrote:
> On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspriel@broadcom.com> 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

  reply	other threads:[~2016-06-17 19:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 14:36 [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces Rafał Miłecki
2016-06-01 19:00 ` Arend van Spriel
2016-06-17 12:30   ` Rafał Miłecki
2016-06-17 19:00     ` Arend van Spriel [this message]
2016-06-17 20:44       ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=576448C0.4080102@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=arend@broadcom.com \
    --cc=brcm80211-dev-list@broadcom.com \
    --cc=brudley@broadcom.com \
    --cc=franky.lin@broadcom.com \
    --cc=frankyl@broadcom.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=meuleman@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pieterpg@broadcom.com \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).