Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: brcmfmac & DEL_INTERFACE
To:     Denis Kenzior <denkenz@gmail.com>
References: <089d2d0a-a802-3c2b-4993-e17326028d1f@gmail.com>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
From:   Arend Van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <5679a6a1-e4a1-1f55-5b6d-21b178201078@broadcom.com>
Date:   Tue, 28 May 2019 22:27:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <089d2d0a-a802-3c2b-4993-e17326028d1f@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 5/28/2019 8:16 PM, Denis Kenzior wrote:
> Hi Arend,
> 
> We noticed that brcmfmac doesn't support .del_virtual_intf for 
> non-p2p/ap interface types.  Any chance this can be added?
> 
> We currently remove all wifi interfaces and re-create the needed ones 
> with SOCKET_OWNER set, and it would be nice if we didn't need to treat 
> brcmfmac specially.

This came up recently. During probe the driver creates a network 
interface that we refer to as primary interface. We consider this 
non-virtual and ownership is with the driver. My guess is that this 
concept comes from the WEXT era, where we did not have the ieee80211 phy 
objects to interact with the driver from user-space. I suppose you don't 
mind the creation of this interface and just want to allow removing it, 
right?

Regards,
Arend