Re: [PATCH 10/10] qtnfmac: support MAC address based access control

On Tue, Dec 19, 2017 at 5:58 PM, Johannes Berg wrote: > On Tue, 2017-12-19 at 13:37 +0100, Arend van Spriel wrote: >> On 12/19/2017 12:19 PM, Sergey Matyukevich wrote: >> > > > Not yet. At the moment enum nl80211_ap_sme_features in >> > > > uapi/linux/nl80211.h >> > >

Re: [PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

On Tue, Dec 19, 2017 at 09:11:30PM +0100, Johannes Berg wrote: > I'm not really sure what that problem was - I think a combination of > missing clean-files and this perhaps? Anyway, I applied another fix for > this today, and it's on the way to Linus's tree, along with the missing > clean-files

Re: [PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

On Tue, 2017-12-19 at 11:23 -0800, Brian Norris wrote: > > In practice, this is seen often by having a separate source and build > directory, where the build artifacts remain but the source tree changes > (even if Seth's cert doesn't change, it might get created/removed when > checking out

[PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

The current rule for generating the {shipped,extra}-certs.c source files might create an invalid C source file, containing redefinitions of the same variables: CC [M] net/wireless/shipped-certs.o net/wireless/shipped-certs.c:686:10: error: redefinition of 'shipped_regdb_certs' const u8

Re: pull-request: wireless-drivers-next 2017-12-18

From: Kalle Valo Date: Mon, 18 Dec 2017 16:17:24 +0200 > a pull request for 4.16 to net-next tree. This is a big one, but on the > other hand most of the stuff here has been some time on linux-next so > hopefully there are no nasty surprises. Even though Arnd just send a >

[PATCH][next] wcn36xx: remove redundant assignment to msg_body.min_ch_time

From: Colin Ian King msg_body.min_ch_time is being assigned twice; remove the redundant first assignment. Detected by CoverityScan, CID#1463042 ("Unused Value") Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/wcn36xx/smd.c | 1 -

Re: [RFC PATCH 2/2] nl80211: implement beacon change notifier

Hi Sergey, Sorry for the long delay. On Tue, 2017-12-05 at 23:31 +0300, Sergey Matyukevich wrote: > > By the way, speaking about GET_CMD_BEACON and its possible users in the > community. There is already a stub for it in nl80211 uapi headers. What > was the original idea for that ? Or was it

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

On Tue, 2017-12-19 at 13:37 +0100, Arend van Spriel wrote: > On 12/19/2017 12:19 PM, Sergey Matyukevich wrote: > > > > Not yet. At the moment enum nl80211_ap_sme_features in > > > > uapi/linux/nl80211.h > > > > is commented out. For MAC-based ACL the following things are being > > > > checked >

Re: pull-request: iwlwifi 2017-11-19

On Tue, 2017-12-19 at 14:52 +0100, Sedat Dilek wrote: > On Wed, Nov 29, 2017 at 9:20 AM, Luca Coelho wrote: > > On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote: > > > On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho > > > wrote: > > > > On Tue, 2017-11-21 at

Re: pull-request: mac80211 2017-12-19

From: Johannes Berg Date: Tue, 19 Dec 2017 10:57:09 +0100 > Other work has been hectic, and I got caught by rc4. We still > have a few more fixes though - and more build issues were > reported. > > Please pull and let me know if there's any problem. Pulled, thanks

Re: [PATCH] staging: wilc1000: Fix lines ending with parentheses

On Sat, Dec 16, 2017 at 01:25:19PM +0530, Aditya Shankar wrote: > This patch fixes the "Lines should not end with a '('" > problem reported by checkpatch > > Signed-off-by: Aditya Shankar > --- > drivers/staging/wilc1000/linux_mon.c | 12 ++-- > 1 file

Re: pull-request: iwlwifi 2017-11-19

On Wed, Nov 29, 2017 at 9:20 AM, Luca Coelho wrote: > On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote: >> On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho wrote: >> > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: >> > > On Mon, Nov 20, 2017 at 12:02 PM,

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

Thank you very much. I'll let you know. Compiling now. On Tue, 19 Dec 2017, Stanislaw Gruszka wrote: Date: Tue, 19 Dec 2017 13:54:32 From: Stanislaw Gruszka To: Enrico Mioso Cc: linux-wireless@vger.kernel.org, Johannes Berg

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

On Tue, Dec 19, 2017 at 01:43:11PM +0100, Enrico Mioso wrote: > I am going to test this on a LEDE build. > Should I leave the mmio workaround patch applied as per OpenWRT default, or > should I leave it off ? > I'll leave it off by default. Please remove it. If things would work then retest with

[PATCH 00/11] brcmfmac: restructuring sdio access functions - final drop

This is the third series of patches which were originally submitted by Ian Molton. For some patches I reworded the commit message. The series is intended for 4.16 and applies to the master branch of the wireless-drivers-next repository. Arend van Spriel (5): brcmfmac: Rename buscore to core

[PATCH 09/11] brcmfmac: Remove array of functions

Replace the array of functions with a pair of pointers to the relevant functions. Signed-off-by: Ian Molton Acked-by: Arend van Spriel Signed-off-by: Arend van Spriel ---

[PATCH 08/11] brcmfmac: Clean up interrupt macros

From: Ian Molton Make it more obvious that this code acually enables interrupts, and provide nice definitions for the bits in the register. Signed-off-by: Ian Molton Acked-by: Arend van Spriel Signed-off-by: Arend van

[PATCH 11/11] brcmfmac: rename brcmf_sdiod_buff_{read,write}() functions

Rename functions to brcmf_sdio_skbuff_{read,write}() as we pass an skbuff to this function. Signed-off-by: Arend van Spriel --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 48 +++--- 1 file changed, 24 insertions(+), 24 deletions(-) diff

[PATCH 01/11] brcmfmac: Remove {r,w}_sdreg32

From: Ian Molton Remove yet another IO function from the code and replace with one that already exists. Signed-off-by: Ian Molton Reviewed-by: Arend van Spriel [arend: keep address calculation, ie. (base + offset) in one

[PATCH 05/11] brcmfmac: Remove func0 from function array

From: Ian Molton func0 is not provided by the mmc stack as a function when probing. Instead providing specific access functions to read/write it. This prepares for a patch to remove the actual array entry itself. Signed-off-by: Ian Molton Acked-by:

[PATCH 07/11] brcmfmac: Replace function index with function pointer

From: Ian Molton In preparation for removing the function array, remove all code that refers to function by index and replace with pointers to the function itself. Signed-off-by: Ian Molton Reviewed-by: Arend van Spriel

[PATCH 06/11] brcmfmac: More efficient and slightly easier to read fixup for 4339 chips

Its more efficient to test the register we're interested in first, potentially avoiding two more comparisons, and therefore always avoiding one comparison per call on all other chips. Signed-off-by: Ian Molton [arend: fix some checkpatch warnings] Signed-off-by: Arend van

[PATCH 10/11] brcmfmac: add comment block in brcmf_sdio_buscore_read()

In brcmf_sdio_buscore_read() there is some special handling upon register access to chipid register of the chipcommon core. Add comment explaining why it is done here. Signed-off-by: Arend van Spriel --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7

[PATCH 03/11] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.

From: Ian Molton The IO functions operate within the Chipcommon IO window. Explicitly set this, rather than relying on the last initialisation IO access to leave it set to the right value by chance. Signed-off-by: Ian Molton Acked-by: Arend van Spriel

[PATCH 02/11] brcmfmac: Rename buscore to core for consistency

Avoid confusion with unrelated _buscore labels. Signed-off-by: Ian Molton Acked-by: Arend van Spriel [arend: only do the rename] Signed-off-by: Arend van Spriel ---

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

I am going to test this on a LEDE build. Should I leave the mmio workaround patch applied as per OpenWRT default, or should I leave it off ? I'll leave it off by default. thank you again, Enrico On Tue, 19 Dec 2017, Stanislaw Gruszka wrote: Date: Tue, 19 Dec 2017 13:27:07 From: Stanislaw

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

First of all - thank you very very much. i'll try the two patches ASAP, and let you know. Thank you very much for the help to solve this. Enrico On Tue, 19 Dec 2017, Stanislaw Gruszka wrote: Date: Tue, 19 Dec 2017 13:27:07 From: Stanislaw Gruszka To: Enrico Mioso

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

On 12/19/2017 12:19 PM, Sergey Matyukevich wrote: Not yet. At the moment enum nl80211_ap_sme_features in uapi/linux/nl80211.h is commented out. For MAC-based ACL the following things are being checked on wiphy registration: complete flag WIPHY_FLAG_HAVE_AP_SME, non-zero max_acl_mac_addrs, and

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

On Mon, Dec 18, 2017 at 04:21:42PM +0100, Stanislaw Gruszka wrote: > Hi > > On Sat, Dec 16, 2017 at 07:33:47PM +0100, Enrico Mioso wrote: > > I tested the Archer MR200 device removing the patch as you suggested: > >

Re: BCM4356 does not initalize after firmware update

On Tue, Dec 19, 2017 at 12:36:36PM +0100, Arend van Spriel wrote: > On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote: > >On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote: > >># cat /sys/kernel/debug/brcmfmac/:03:00.0/revinfo > > > >vendorid: 0x14e4 > >deviceid: 0x43ec >

Re: BCM4356 does not initalize after firmware update

On 12/15/2017 1:20 PM, Stanislaw Gruszka wrote: On Fri, Dec 15, 2017 at 12:10:34PM +0100, Arend van Spriel wrote: # cat /sys/kernel/debug/brcmfmac/:03:00.0/revinfo vendorid: 0x14e4 deviceid: 0x43ec radiorev: 0.41.32.105 chipnum: 17238 (4356) chiprev: 2 chippkg: 2 corerev: 48 boardid:

[PATCH 1/2] rt2x00: pause almost full queue early

Do not drop >tx_lock and acquire it again to pause queue when available entries are below the threshold. Patch should mitigate problem of frequently printed errors: "Error - Dropping frame due to full tx queue" Signed-off-by: Stanislaw Gruszka ---

[PATCH 2/2] rt2x00: do not pause queue unconditionally on error path

Pausing queue without checking threshold is racy with txdone path. Moreover we do not need pause queue on any error, but only if queue is full - in case when we send RTS frame ( other cases of almost full queue are already handled in rt2x00queue_write_tx_frame() ). Patch fixes of theoretically

[PATCH v2 06/10] qtnfmac: fix rssi data passed to wireless core

Fix RSSI values passed to wireless core by qtnfmac driver: - fix RSSI values in scan results: driver registers wiphy with CFG80211_SIGNAL_TYPE_MBM signal type, so mBm should be passed using DBM_TO_MBM macro - accompany firmware changes fixing RSSI values in received mgmt frames update qlink

[PATCH v2 0/10] qtnfmac: regular portion of fixes and features

Hello Kalle and all, Here is the next set of patches for qtnfmac driver. This set enables the following features: - radar detection and CAC support - MAC-based ACL support - make GET_STA_STATS format more flexible and future-proof - inform wireless core about supported extended capabilities

[PATCH v2 04/10] qtnfmac: change default interface mode from AP to STA

From: Igor Mitsyanko To mimic mac80211 behaviour, change default interface type from AP to STA. Signed-off-by: Igor Mitsyanko --- drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 2 +-

[PATCH v2 01/10] qtnfmac: check that MAC exists in regulatory notifier

From: Igor Mitsyanko It is possible that regulatory notifier is called before MAC data was allocated. We need to verify that MAC data exists before trying to send a regulatory change event. Signed-off-by: Igor Mitsyanko ---

[PATCH v2 03/10] qtnfmac: add support for radar detection and CAC

From: Igor Mitsyanko Implement two parts of radar handling logic: - cfg80211 .start_radar_detect callback to allow nl80211 to initiate CAC - radar event to allow wlan device to advertize CAC and radar events Signed-off-by: Igor Mitsyanko

[PATCH v2 07/10] qtnfmac: fill wiphy's extended capabilities

From: Vasily Ulyanov These are needed to inform userspace about features the hardware supports (e.g. BSS Transition Management 802.11v) Signed-off-by: Vasily Ulyanov --- drivers/net/wireless/quantenna/qtnfmac/commands.c | 44

[PATCH v2 10/10] qtnfmac: support MAC address based access control

From: Vasily Ulyanov This allows a running AP to blacklist STAs by their MAC addresses respecting the configured policy (either accept or deny unless listed). It can be setup on .start_ap or with .set_mac_acl commands. Signed-off-by: Vasily Ulyanov

[PATCH v2 08/10] qtnfmac: modify GET_STA_STATS cmd format for back/forward compatibility

From: Igor Mitsyanko A set of per-STA statistics can potentially change quite often. To ensure backwards and forward compatibility, modify GET_STA_STATS command format: - introduce two TLV types - first TLV is a variable-sized bitmap of statistics values

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

> > Not yet. At the moment enum nl80211_ap_sme_features in uapi/linux/nl80211.h > > is commented out. For MAC-based ACL the following things are being checked > > on wiphy registration: complete flag WIPHY_FLAG_HAVE_AP_SME, non-zero > > max_acl_mac_addrs, and set_mac_acl cfg80211 callback. > > I

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

On Tue, 2017-12-19 at 13:42 +0300, Sergey Matyukevich wrote: > Not yet. At the moment enum nl80211_ap_sme_features in uapi/linux/nl80211.h > is commented out. For MAC-based ACL the following things are being checked > on wiphy registration: complete flag WIPHY_FLAG_HAVE_AP_SME, non-zero >

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

Hello Johannes, > > I guess it should be possible to do some kind of source address filtering > > in hardware. But it looks like your question is whether it makes sense > > or not. Probably not, I have no idea. > > Either way, I see no reason to support it if nobody has a driver for it > :) > >

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

Hi, > I guess it should be possible to do some kind of source address filtering > in hardware. But it looks like your question is whether it makes sense > or not. Probably not, I have no idea. Either way, I see no reason to support it if nobody has a driver for it :) > By the way, what do you

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

Hello Johannes, > > Meanwhile now it is not yet clear to me what should be done for driver which > > supports MAC-based ACL, but not full-fledged AP SME. > > Are you sure that such a device can even exist? It'd have to drop the > auth frames, so they can't be handled by the host? Is there much

Re: oops on cloned-mac 802.11s stations

On Mon, 2017-12-18 at 03:44 +0100, Gui Iribarren wrote: > Steps to reproduce: > join a 802.11s mesh with a nodeA, and then join the same 802.11s mesh > with another nodeB, so that both nodes MAC addresses are exactly the > same (i.e. nodeB is "cloning" nodeA MAC) > > Expected result: > nodeA and

pull-request: mac80211 2017-12-19

Hi Dave, Other work has been hectic, and I got caught by rc4. We still have a few more fixes though - and more build issues were reported. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit 0afe9d4ab9d40c281bdcdd118661fe8e4bdcef18:

Re: [PATCH] mac80211: Fix setting TX power on monitor interfaces

Hi, > Since monitor_sdata->vif.type is also NL80211_IFTYPE_MONITOR, > the warning would still appear with the patch to cfg.c, so I excluded > that case from the WARN_ON_ONCE condition. > > I hope that makes sense?! Yeah, looks good. > if (wdev) { > sdata =

Re: [PATCH 1/2] cfg80211/nl80211: Optional authentication offload to userspace

On Fri, 2017-12-15 at 08:51 +, Srinivas Dasari wrote: > > don’t we actually need a flag in NL80211_CMD_CONNECT that indicates that > > userspace is able to actually handle NL80211_CMD_EXTERNAL_AUTH. It is nice > > >that there is feature for userspace to see if the driver supports it, but >

Re: [PATCH v3 1/3] mac80211: Add TXQ scheduling API

On Thu, 2017-12-14 at 13:44 +0100, Felix Fietkau wrote: > > First we should revert these patches. FWIW, I've just done that, if only to make the mt76 merge possible. > We can respin them shortly after in a modified form where > ieee80211_next_txq takes a 'queue' argument. I'll leave the two of

Re: [PATCH] wireless: Always rewrite generated files from scratch

On Thu, 2017-12-14 at 14:33 +0100, Thierry Reding wrote: > From: Thierry Reding > > Currently the certs C code generation appends to the generated files, > which is most likely a leftover from commit 715a12334764 ("wireless: > don't write C files on failures"). This causes

Re: [PATCH 2/3] rtlwifi: Add beacon check mechanism to check if AP settings changed.

On Thu, 2017-12-14 at 10:06 -0600, Larry Finger wrote: > Does mac80211 have this facility? If so, how would we tap into it? If this > capability does not exist in mac80211, how would one add it? I have never > devoted much effort to looking at the internals of mac80211. It really should, and

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

On Mon, 2017-12-18 at 19:18 +0300, Sergey Matyukevich wrote: > Meanwhile now it is not yet clear to me what should be done for driver which > supports MAC-based ACL, but not full-fledged AP SME. Are you sure that such a device can even exist? It'd have to drop the auth frames, so they can't be

[PATCH] cfg80211: ship certificates as hex files

From: Johannes Berg Not only does this remove the need for the hexdump code in most normal kernel builds (still there for the extra directory), but it also removes the need to ship binary files, which apparently is somewhat problematic, as Randy reported. While at it,