On 14-3-2017 23:19, Johannes Berg wrote:
> On Tue, 2017-03-14 at 21:51 +0000, Arend van Spriel wrote:
>> To support network namespace the driver must assure all created
>> network interfaces are in the same namespace as the wiphy instance.
>
> FWIW, looks fine to me.
Th
To support network namespace the driver must assure all created
network interfaces are in the same namespace as the wiphy instance.
Reported-by: Mark Asselstine
Signed-off-by: Arend van Spriel
---
Hi Mark,
Please check this patch. I can not say I am an expert when it comes
to using namespaces
On 14-3-2017 14:21, Mark Asselstine wrote:
> On Tuesday, March 14, 2017 1:41:02 PM EDT Arend Van Spriel wrote:
>> On 14-3-2017 12:28, Johannes Berg wrote:
>>>> It never came up with any projects so far.
>
> Myself and one of my colleagues had thought that this might be
On 14-3-2017 12:28, Johannes Berg wrote:
>
>> It never came up with any projects so far. I doubt that the patch
>> below is sufficient. I suspect something more is needed. Using git
>> blame I ended up finding these commits:
>>
>> a272a72 mac80211: allow using network namespaces
>
> This is neede
+ linux-wireless
+ Johannes
On 13-3-2017 19:15, Mark Asselstine wrote:
> Hello Arend,
>
> I am thinking about proposing the following patch on linux-wireless but would
> like to ask you your thoughts first. I have looked in detail at the kernel
> code, the brcmfmac development pages, the mailin
On 13-3-2017 10:33, Arend Van Spriel wrote:
> On 6-3-2017 15:50, Daniel J Blueman wrote:
>> On 6 March 2017 at 21:00, Arend Van Spriel
>> wrote:
>>> + linux-wireless
>>>
>>> On 6-3-2017 8:14, Daniel J Blueman wrote:
>>>> KASAN reported
On 6-3-2017 15:50, Daniel J Blueman wrote:
> On 6 March 2017 at 21:00, Arend Van Spriel
> wrote:
>> + linux-wireless
>>
>> On 6-3-2017 8:14, Daniel J Blueman wrote:
>>> KASAN reported 'struct wireless_dev wdev' was read after being freed.
>>> F
This series is rework in the driver getting fwsignal out of the way for
protocols that do not need it. For example PCIe devices do not need that
functionality. To summarize:
* use fwsignal functionality only for bcdc protocol.
This series applies to the master branch of the wireless-drivers-nex
From: Franky Lin
fwsignal is only used by bcdc. Create a new protocol interface function
brcmf_proto_add_if for core module to notify protocol layer upon a new
interface is created.
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac
From: Franky Lin
Create a new protocol interface function brcmf_proto_reset_if for core
module to notify protocol layer when interface role changes.
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 7 +++
drivers/net
From: Franky Lin
brcmf_txflowblock is invoked by sdio and usb bus module which are using
bcdc protocol. This patch makes it a bcdc API instead of a core module
function.
Reviewed-by: Arend Van Spriel
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom
From: Franky Lin
brcmf_txcomplete is invoked by sdio and usb bus module which are using
bcdc protocol. So move it from core module into bcdc layer.
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 20
From: Franky Lin
Create a new protocol interface function brcmf_proto_del_if for core
module to notify protocol layer upon interface deletion.
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 7 +++
drivers/net
On 10-3-2017 9:08, Hans de Goede wrote:
> Hi,
>
> On 08-03-17 12:16, Hans de Goede wrote:
>> Hi,
>>
>> On 08-03-17 11:15, Arend Van Spriel wrote:
>>> On 8-3-2017 10:26, Arend Van Spriel wrote:
>>>> On 8-3-2017 9:24, Hans de Goede wrote:
>>&
On 3-3-2017 13:21, Johannes Berg wrote:
> On Tue, 2017-02-28 at 12:06 +0100, Arend Van Spriel wrote:
>> On 21-2-2017 12:46, Johannes Berg wrote:
>>>
>>>>>> Would this work for you? We should have wpa_supplicant
>>>>>> support
>>>>&
Instead add a new brcmf_info macro and use that.
Acked-by: Arend van Spriel
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Fix brcm_err typo (should be brcmf_err) in CONFIG_BRCM_TRACING case
> Changes in v3:
> -Use do { } while (0) around macro
> -Rebase on top of
On 9-3-2017 9:09, Hans de Goede wrote:
> Hi all,
>
> On 08-03-17 21:44, Arend Van Spriel wrote:
>>
>>
>> On 8-3-2017 18:53, Joe Perches wrote:
>>> On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote:
>>>> Hi,
>>>
>>> And h
On 8-3-2017 18:53, Joe Perches wrote:
> On Wed, 2017-03-08 at 17:57 +0100, Hans de Goede wrote:
>> Hi,
>
> And hello back to you.
Also hello.
>> On 08-03-17 17:34, Joe Perches wrote:
>>> On Wed, 2017-03-08 at 09:23 +0100, Hans de Goede wrote:
Using pr_err for things which are not errors i
On 8-3-2017 11:20, Johannes Berg wrote:
> From: Johannes Berg
>
> If the user rate mask results in no (basic) rates being usable,
> clear it. Also, if we're already operating when it's set, reject
> it instead.
>
> Technically, selecting basic rates as the criterion is a bit too
> restrictive, b
On 8-3-2017 11:08, Hans de Goede wrote:
> HI,
>
> On 08-03-17 10:57, Kalle Valo wrote:
>> Arend Van Spriel writes:
>>
>>> On 8-3-2017 9:23, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 07-03-17 10:59, Arend Van Spriel wrote:
>
On 8-3-2017 9:24, Hans de Goede wrote:
> Hi,
>
> On 07-03-17 11:03, Arend Van Spriel wrote:
>>
>>
>> On 27-2-2017 22:45, Hans de Goede wrote:
>>> The firmware responding with -EBUSY when trying to add an extra
>>> virtual-if
>>> is a normal th
On 8-3-2017 10:26, Arend Van Spriel wrote:
> On 8-3-2017 9:24, Hans de Goede wrote:
>> Hi,
>>
>> On 07-03-17 11:03, Arend Van Spriel wrote:
>>>
>>>
>>> On 27-2-2017 22:45, Hans de Goede wrote:
>>>> The firmware responding with -EBUSY
On 8-3-2017 9:23, Hans de Goede wrote:
> Hi,
>
> On 07-03-17 10:59, Arend Van Spriel wrote:
>> On 27-2-2017 22:45, Hans de Goede wrote:
>>> Using pr_err for things which are not errors is a bad idea. E.g. it
>>> will cause the plymouth bootsplash screen to dro
On 7-3-2017 14:39, Kalle Valo wrote:
> Rafał Miłecki writes:
>
>> On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote:
>>> From: Igor Mitsyanko
>>>
>>> This patch adds support for new FullMAC WiFi driver for Quantenna
>>> QSR10G chipsets.
>>>
>>> QSR10G (aka Pearl) is Quantenna's 8x8,
On 5-3-2017 4:15, Brennan Ashton wrote:
> The firmware in the current tree for the BCM43341 hardware seems to
> result in some issues with the 5GHz band. phy info would show the
> band, but scanning would not return any 5GHz networks. The current
> version in the tree is 6.10.190.49 A newer ver
errors getting logged.
>
> Check for a status of BRCMF_E_STATUS_ABORT and in this case simply
> cleanly exit the cfg80211_escan_handler. This also avoids a
> BRCMF_E_STATUS_ABORT event arriving after a new scan has been started
> causing the new scan to complete prematurely without
On 6-3-2017 23:01, Johannes Berg wrote:
> From: Johannes Berg
>
> There isn't really much harm in not ignoring, since it doesn't
> represent a valid rate, but since we already ignore the HT one
> also ignore VHT. Also simplify the code a bit.
>
> Signed-off-by: Johannes Berg
> ---
> net/mac802
On 27-2-2017 22:45, Hans de Goede wrote:
> Using pr_err for things which are not errors is a bad idea. E.g. it
> will cause the plymouth bootsplash screen to drop back to the text
> console so that the user can see the error, which is not what we
> normally want to happen.
>
> Instead add a new br
On 7-3-2017 10:44, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo wrote:
>>> Arend Van Spriel writes:
>>>
>>>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>>>> With KASAN and a couple of o
On 27-2-2017 22:45, Hans de Goede wrote:
> The country code gets set to "00" by default at boot, ignore this
> rather then logging an error about it.
Acked-by: Arend van Spriel
> Signed-off-by: Hans de Goede
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac
On 27-2-2017 22:45, Hans de Goede wrote:
> The firmware responding with -EBUSY when trying to add an extra virtual-if
> is a normal thing, do not print an error for this.
This may be something we need to look into. It seems to me the interface
combinations needs to be fixed so we do not try to p
On 7-3-2017 9:42, Johannes Berg wrote:
>
>>>
>>> /*
>>> -* BSS_MEMBERSHIP_SELECTOR_HT_PHY is defined in
>>> 802.11n-2009
>>> -* 7.3.2.2 as a magic value instead of a rate.
>>> Hence, skip it.
>>> +* Skip HT and VHT BSS membership selectors since
+ linux-wireless
On 6-3-2017 8:14, Daniel J Blueman wrote:
> KASAN reported 'struct wireless_dev wdev' was read after being freed.
> Fix by freeing after the access.
I would rather like to see the KASAN report, because something is off
here. This function is called with wdev as a parameter so how
On 6-3-2017 11:38, Arnd Bergmann wrote:
> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel
> wrote:
>> On 2-3-2017 17:38, Arnd Bergmann wrote:
>>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put
>>> an object
>>> on the stack,
+ linux-wireless
On 6-3-2017 8:04, Daniel J Blueman wrote:
> When resuming from suspend with a BCM43602 on Ubuntu 16.04 with
> 4.9.13, we see use after free [1].
>
> We see the struct cfg80211_ops is accessed in the resume path, after
> it was previously freed:
>
> (gdb) list *(brcmf_cfg80211_at
On 2-3-2017 17:38, Arnd Bergmann wrote:
> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an
> object
> on the stack, which will each require a redzone with KASAN and lead to
> possible
> stack overflow:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:
tespace are intended here.
Acked-by: Arend van Spriel
> Signed-off-by: Arnd Bergmann
> ---
> .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507
> +---
> 1 file changed, 697 insertions(+), 810 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b
me.
>
> I'm leaving the original indentation to make the review easier.
Thanks ;-)
Acked-by: Arend van Spriel
> Signed-off-by: Arnd Bergmann
> ---
> .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178
> -
> 1 file changed, 104 insertions
brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of
> 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> Here, I'm reducing the stack size by marking as many local variables as
> 'static const' as I can without changing the actual code.
Acked-by: A
On 3-3-2017 13:28, Johannes Berg wrote:
>> +void cfg80211_connect_done(struct net_device *dev, const u8 *bssid,
>> + struct cfg80211_bss *bss, const u8
>> *req_ie,
>> + size_t req_ie_len, const u8 *resp_ie,
>> + size_t resp_ie_len, c
On 3-3-2017 13:21, Johannes Berg wrote:
> On Tue, 2017-02-28 at 12:06 +0100, Arend Van Spriel wrote:
>> On 21-2-2017 12:46, Johannes Berg wrote:
>>>
>>>>>> Would this work for you? We should have wpa_supplicant
>>>>>> support
>>>&g
On 3-3-2017 13:20, Johannes Berg wrote:
> On Thu, 2017-02-23 at 16:26 +0530, Jithu Jance wrote:
>> On Thu, Feb 23, 2017 at 4:10 PM, Arend Van Spriel
>> wrote:
>>>
>>> Ehm. Looking at the code in wpa_supplicant_event_assoc() it would
>>> be
>>>
d not be a device that bcmdhd would try to bind to.
Regards,
Arend
> Regards
> Ravin
>
> On 1 March 2017 at 18:59, Arend Van Spriel
> wrote:
>> On 28-2-2017 23:28, Jouni Malinen wrote:
>>> On Tue, Feb 28, 2017 at 04:06:48PM +0530, ravin goyal wrote:
>>>&g
On 2-3-2017 9:59, Johannes Berg wrote:
>
>>> + int (*del_pmk)(struct wiphy *wiphy, struct
>>> net_device *dev,
>>> + const u8 *aa);
>>
>> Minor nit, but prefer clr_pmk to clear the pmk.
>
> Why? You don't have "the PMK" that you can clear, you have "a PMK" (for
> the
Hoi Jouni,
Not sure which email address to use ;-) I noticed a while ago that FILS
offloading was on the agenda of wireless workshop in Santa Fe. Recently,
looked at the FILS patches that were applied upstream and noticed:
static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rde
On 21-2-2017 12:46, Johannes Berg wrote:
>
Would this work for you? We should have wpa_supplicant support
too, but need to ask Andrei to look at that.
>>
>> Forgot to reply to this. Yes, this will work. Can come up with
>> wpa_supp changes.
>
> No, we have them. Just need to see where t
On 28-2-2017 11:00, Rafał Miłecki wrote:
> On 28 February 2017 at 10:50, Arend Van Spriel
> wrote:
>> On 27-2-2017 13:06, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> This helper function is pretty trivial and we can easily do without it.
>
On 27-2-2017 13:06, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This helper function is pretty trivial and we can easily do without it.
> What's important though it's one of FWS (Firmware Signalling)
> dependencies in core.c. The plan is to make FWS required by BCDC only so
> we don't have to
On 24-2-2017 14:43, Rafał Miłecki wrote:
> On 2017-02-24 14:21, Arend Van Spriel wrote:
>> On 24-2-2017 13:27, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
>>> brcmfmac ther
On 25-2-2017 14:37, c_tr...@qti.qualcomm.com wrote:
> From: Tamizh chelvam
>
> This patchset add support for BTCOEX feature to enable/disable and
> modifying btcoex priority value via nl80211
>
> Tamizh chelvam (4):
> ath10k: Add support to enable or disable btcoex via nl80211
> ath10k: Add
On 24-2-2017 14:10, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It avoids some unnecessary work. Most likely there wasn't much sense in
> doing this before bus reset anyway, as reset is supposed to put chip
> into default state. In PCIe code (only bus implementing reset) we e.g.
> use watchdog
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
> 4366c0. Cutting name at the letter isn't a good idea as sometimes we may
> have e.g. a0 and a1.
As explained in 1/2, the revision may change but if rom imag
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
> brcmfmac there is support for 43602a1 and from what I know supporting
> 43602a0 would require loading a different firmware.
This is not necessarily true. It
On 24-2-2017 11:26, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
>> On 24-2-2017 10:43, Jörg Krause wrote:
>>> Hi Arend,
>>>
>>> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>>>
On 24-2-2017 10:43, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>
>> On 23-2-2017 21:21, Jörg Krause wrote:
>>> Hi,
>>>
>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
>&
On 23-2-2017 21:53, Rafał Miłecki wrote:
> Hi guys,
>
> On 12 September 2016 at 07:22, Rafał Miłecki wrote:
>> Few months ago Hante added support for 4366c0 to the brcmfmac. There
>> are already few devices with this chipset on the market. We even have
>> some related bug report at kernel:
>> htt
On 23-2-2017 21:21, Jörg Krause wrote:
> Hi,
>
> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> 'wpa_cli wps_pin any', the following messages are printed:
>
> """
>> wps_pin any
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
> [ 4011.78
On 21-2-2017 13:37, Johannes Berg wrote:
> From: Avraham Stern
>
> Add API for setting the PMK to the driver. For FT support, allow
> setting also the PMK-R0 Name.
>
> This can be used by drivers that support 4-Way handshake offload
> while IEEE802.1X authentication is managed by upper layers.
On 23-2-2017 11:36, Arend Van Spriel wrote:
> On 22-2-2017 13:24, Jithu Jance wrote:
>> Hi Jouni, Johannes et al.,
>>
>> On Wed, Feb 22, 2017 at 1:27 AM, Arend Van Spriel
>> wrote:
>>> On 21-2-2017 13:37, Johannes Berg wrote:
>>>>
On 22-2-2017 13:24, Jithu Jance wrote:
> Hi Jouni, Johannes et al.,
>
> On Wed, Feb 22, 2017 at 1:27 AM, Arend Van Spriel
> wrote:
>> On 21-2-2017 13:37, Johannes Berg wrote:
>>>
>>>> What I am also missing is how to deal with NL80211_CMD_CONNECTED
>
On 21-2-2017 15:47, Johannes Berg wrote:
>
>> The .len verifies that it's at least that long. We're thus ignoring
>> additional bytes in the PSK case if they're present, which I suppose
>> we should fix by checking the exact length in the code separately.
>>
libnl seems to have the notion of mi
On 23-2-2017 8:08, Julia Lawall wrote:
>> Thanks for the feedback Arend, I really appreciate it. I've decided to go
>> with
>> these changes in my follow-up patch request:
>>
>> - rename tstrRSSI to 'rssi_history_buffer' as Aren suggested since it makes
>> the
>> purpose of the struct clear
>> -
On 21-2-2017 11:28, Marcin Rokicki wrote:
> The empty 'return;' statement in a void function should be
> used to return from somewhere else than the end.
>
> Signed-off-by: Marcin Rokicki
> ---
>
> Changes for v2
> -remove only return statement instead of empty err label
> which can be used
On 22-2-2017 18:14, Tahia Khan wrote:
> Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl:
>
> Avoid CamelCase:
> Avoid CamelCase:
> Avoid CamelCase:
Just a generic remark that may help you with other changes you will be
making in the linux kernel. Warnings from checkpatch
On 21-2-2017 13:37, Johannes Berg wrote:
>
>> What I am also missing is how to deal with NL80211_CMD_CONNECTED
>> event signalling. Should that be given after (un)successful
>> completion of the 4-way handshake or should we have a separate event
>> for that?
>
> That's a good point. I don't thin
On 21-2-2017 12:46, Johannes Berg wrote:
>
Would this work for you? We should have wpa_supplicant support
too, but need to ask Andrei to look at that.
>>
>> Forgot to reply to this. Yes, this will work. Can come up with
>> wpa_supp changes.
>
> No, we have them. Just need to see where
On 21-2-2017 12:34, Arend Van Spriel wrote:
> On 21-2-2017 11:40, Johannes Berg wrote:
>> On Tue, 2017-02-21 at 11:32 +0100, Arend Van Spriel wrote:
>>> On 21-2-2017 11:09, Johannes Berg wrote:
>>>> From: Eliad Peller
>>>>
>>>> Let driv
On 21-2-2017 11:40, Johannes Berg wrote:
> On Tue, 2017-02-21 at 11:32 +0100, Arend Van Spriel wrote:
>> On 21-2-2017 11:09, Johannes Berg wrote:
>>> From: Eliad Peller
>>>
>>> Let drivers advertise support for station-mode 4-way
On 21-2-2017 11:09, Johannes Berg wrote:
> From: Eliad Peller
>
> Let drivers advertise support for station-mode 4-way handshake
> offloading with a new NL80211_EXT_FEATURE_4WAY_HANDSHAKE_OFFLOAD_STA
> flag.
I find use of the term OFFLOAD a bit redundant as it is implied by its
presence anyway.
ls as well, then it's a
> right moment to print an error.
>
> This should reduce amount of false reports from users seeing this
> warning while having wireless working perfectly fine.
I think FW_OPT_NO_WARN does not cover all warnings in firmware_class
although I did not chec
On 21-2-2017 10:04, Marcin Rokicki wrote:
> The empty 'return;' statement in a void function should be
> used to return from somewhere else then the end.
>
> Signed-off-by: Marcin Rokicki
> ---
> drivers/net/wireless/ath/ath10k/core.c | 11 +--
> 1 file changed, 5 insertions(+), 6 dele
Hi Johannes,
Internally I am asked to look at "pmk plumbing" patches allowing
firmware to deal with 4-way handshake. Now I noticed this topic being
discussed during last wireless workshop in Santa Fe [1].
I do not recall any follow-up after that. At least no concrete patches,
right? Also in wpa_s
On 20-2-2017 10:19, Johannes Berg wrote:
> On Wed, 2017-02-15 at 10:37 +0000, Arend van Spriel wrote:
>> Another review round for multiple scheduled scan support in nl80211.
>>
>
>
> Looks fine to me. Not sure I see much value in splitting patches 4/5,
> but whichever
On 19-2-2017 20:00, Stefan Holzmann wrote:
> Hello,
>
> I think my problem was just a firmware version issue. When I use the firmware
> file "fw_bcm4343.bin" from here
> https://android.googlesource.com/platform/hardware/broadcom/wlan I'am able
> establish a P2P connection.
> Is this the latest
On 17-2-2017 22:33, Stefan Holzmann wrote:
> Hello,
>
> I have problems to get WiFi P2P on a Nanopi NEO Air board up and running. The
> board uses a AP6212 WiFi module with the BCM4343A0 SDIO chipset (ID: 0xa9a6).
Hi Stefan
FYI, SDIO ID: A9A6 is BCM43430.
> Connecting to an AP as normal WiFi
On 16-2-2017 11:01, Kalle Valo wrote:
> Arend Van Spriel writes:
>
>> On 16-2-2017 10:39, Rafał Miłecki wrote:
>>> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>>>> (Adding linux-wireless)
>>>>
>>>> Randy Dunlap writes:
>>>&
On 16-2-2017 10:32, Rafał Miłecki wrote:
> On 2017-02-16 10:18, Arend Van Spriel wrote:
>> On 16-2-2017 10:04, Rafał Miłecki wrote:
>>> On 2017-02-16 09:38, Arend Van Spriel wrote:
>>>> On 16-2-2017 8:26, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki
On 16-2-2017 10:39, Rafał Miłecki wrote:
> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>> (Adding linux-wireless)
>>
>> Randy Dunlap writes:
>>
>>> On 02/07/17 02:02, kbuild test robot wrote:
Hi Kalle,
FYI, the error/warning still remains.
tree:
https://git.kernel.org
On 16-2-2017 10:04, Rafał Miłecki wrote:
> On 2017-02-16 09:38, Arend Van Spriel wrote:
>> On 16-2-2017 8:26, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> Failing to load NVRAM file isn't critical if we manage to get platform
>>>
On 16-2-2017 8:26, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Failing to load NVRAM file isn't critical if we manage to get platform
> one in the fallback path. It means warnings like:
> [ 10.801506] brcmfmac :01:00.0: Direct firmware load for
> brcm/brcmfmac43602-pcie.txt failed with
On 15-2-2017 11:55, ravin goyal wrote:
> okay thanks for the help.
No intent to blow you off. I just do not support that driver nor anyone
else on this list.
Regards,
Arend
> regards
> ravin
>
> On 15 February 2017 at 16:20, Arend Van Spriel
> wrote:
>>
>>
>
On 14-2-2017 21:11, Johannes Berg wrote:
> On Tue, 2017-02-14 at 21:09 +0100, Arend Van Spriel wrote:
>> On 14-2-2017 14:12, Johannes Berg wrote:
>>> On Tue, 2017-02-14 at 14:07 +0100, Arend Van Spriel wrote:
>>>
>>>>> No. But there was a size lim
On 15-2-2017 11:41, Johannes Berg wrote:
> On Wed, 2017-02-15 at 11:34 +0100, Arend Van Spriel wrote:
>> On 15-2-2017 11:34, Arend Van Spriel wrote:
>>> On 15-2-2017 10:48, Johannes Berg wrote:
>>>> On Wed, 2017-02-15 at 10:36 +0100, Arend Van Spriel wrote:
>>&g
On 15-2-2017 11:38, ravin goyal wrote:
> that is what I have found on my banana pi board running raspbian lite
> 3.4.112-sun8i.
> removing bcmdhd results in removing my wlan0 interface from the
> list(iwconfig/ifconfig/ip).
Ok. If it is raspbian that choose to include bcmdhd in their distro I
wo
Allow driver to indicate which scheduled scan request is being aborted
by providing the request id.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2
For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
V3:
- remove WIPHY_FLAG_SUPPORTS_SCHED_SCAN.
- make
: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
include/net/cfg80211.h | 2 ++
net/wireless/nl80211.c | 23 +++
net/wireless/nl80211.h | 3 +--
net/wireless/scan.c| 5 ++---
4 files changed, 16 insertions
Have proper request id filled in the SCHED_SCAN_RESULTS notification
toward user-space by having the driver provide it through the api.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/ath/ath6kl
Another review round for multiple scheduled scan support in nl80211.
The patches apply to master branch of mac80211-next repository.
changelog:
V3:
- addressed comments on "nl80211: allow multiple active scheduled scan
requests"
- reordered first two patches.
Arend van
On 15-2-2017 11:34, Arend Van Spriel wrote:
> On 15-2-2017 10:48, Johannes Berg wrote:
>> On Wed, 2017-02-15 at 10:36 +0100, Arend Van Spriel wrote:
>>>
>>>> I'm not really sure what to do - we don't really want to print a
>>>> message on some
On 15-2-2017 10:48, Johannes Berg wrote:
> On Wed, 2017-02-15 at 10:36 +0100, Arend Van Spriel wrote:
>>
>>> I'm not really sure what to do - we don't really want to print a
>>> message on something that might have been received from the peer, I
>>>
On 15-2-2017 10:54, ravin goyal wrote:
> Hello, I have a banana pi m2+ running raspbian lite 3.4.112-sun8i
> I am running hostapd on it
>
> My wireless chip is AP6212 ,when I start hostapd sometime it runs
> sometime it leads to kernel crash
>
> please follow this link to see the kernel messages:
On 15-2-2017 10:16, Johannes Berg wrote:
> On Wed, 2017-02-15 at 10:08 +0100, Arend Van Spriel wrote:
>> [snip]
>>
>> Looks good to me.
>
> Thanks for checking :)
>
>>> + /* not covered or invalid combination received */
>>
>> Do you wa
On 14-2-2017 14:22, Johannes Berg wrote:
> From: Johannes Berg
>
> IEEE 802.11-2016 extended the VHT capability fields to allow
> indicating the number of spatial streams depending on the
> actually used bandwidth, add support for decoding this.
>
> Signed-off-by: Johannes Berg
> ---
> include
On 14-2-2017 14:12, Johannes Berg wrote:
> On Tue, 2017-02-14 at 14:07 +0100, Arend Van Spriel wrote:
>
>>> No. But there was a size limit on how much older userspace could
>>> process before we did the splitting.
>>
>> I see. So basically adding stuff
On 24-1-2017 10:40, Johannes Berg wrote:
>> +/* leave request id zero for legacy request
>> + * or if driver does not support multi-scheduled scan
>> + */
>> +if (want_multi && rdev->wiphy.max_sched_scan_reqs > 1) {
>
> Why do the >1 check here? It probably doesn't really make a di
On 14-2-2017 13:51, Johannes Berg wrote:
> On Tue, 2017-02-14 at 13:35 +0100, Arend Van Spriel wrote:
>> On 24-1-2017 10:40, Johannes Berg wrote:
>>>
>>>> + * @max_sched_scan_reqs: maximum number of scheduled scan
>>>> requests
>>>>
On 24-1-2017 10:40, Johannes Berg wrote:
>
>> + * @max_sched_scan_reqs: maximum number of scheduled scan requests
>> that
>> + * the device can run concurrently.
>
> Perhaps we should get rid of WIPHY_FLAG_SUPPORTS_SCHED_SCAN and just
> set this to 1 for such devices? Otherwise we have two diffe
On 13-2-2017 11:14, Tobias Klauser wrote:
> Instead of using a private copy of struct net_device_stats in struct
> brcm_if, use stats from struct net_device. Also remove the now
> unnecessary .ndo_get_stats function.
Acked-by: Arend van Spriel
> Signed-off-by: To
1101 - 1200 of 2460 matches
Mail list logo
