[PATCH 1/2] mwifiex: change width of MAC control variable

Firmware has started making use of reserved field. Accordingly change curr_pkt_filter from u16 to u32. Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/fw.h | 18 -- drivers/net/wireless/marvell/mwifiex/main.h| 2 +-

[PATCH 2/2] mwifiex: Enable dynamic bandwidth signalling

Enable dynamic bandwidth signalling by setting the corresponding bit in MAC control register. Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/init.c | 3 ++- 2 files changed, 3 insertions(+), 1

Re: wl1251 & mac address & calibration data

On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote: For the new API a solution for "fallback mechanisms" should be clean though and I am looking to stay as far as possible from the existing mess. A solution to help both the old API and new API is possible for the "fallback mechanism" though -- but

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

On Thursday 15 December 2016 03:08 PM, Johannes Berg wrote: > >> This rx path only checks if the driver has advertised >> it's support of 802.11 header encap/decap offload for >> data frames. > > I'm not even sure I see the point in that? Other than that (and the > various other offload

Re: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX

Hi Johannes, Thanks for the comments On 2016-12-13 21:39, Johannes Berg wrote: > >  /** > > + * wiphy_btcoex_support_flags > > + * This enum has the driver supported frame types for > > BTCOEX. > > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for > > BTCOEX > > + *

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote: > >>> I agree. Dynamic switch part is buggy, we can start with not >>> allowing interfaces resulting in dynamic switch. >> >> Does this mean that when bringing up multiple interfaces, users would >> need to figure out the 'magic' order

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hi Christian, > On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote: > > I am also thinking, as of now there is not much use in appending > > the extended peer stats (which gets periodically ) to the linked list > > '>debug.fw_stats.peers_extd)' and should we get rid of

Re: [Patch] NFC: trf7970a:

On Wed, Dec 14, 2016 at 03:31:23PM -0700, Mark Greer wrote: > I'll start on this > tonight but won't likely get far until tomorrow. In the meantime, > if you and/or your contractor make progress, please share. Geoff, Which version of neard are you using? 0.16? Mark --

Re: wl1251 & mac address & calibration data

On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel wrote: > On 15-12-2016 16:33, Pali Rohár wrote: >> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote: >>> (Adding Luis because he has been working on request_firmware() lately) >>> >>> Pali Rohár

Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote: > From: Jaret Cantu > > Repeated polling attempts cause a NULL dereference error to occur. > This is because the curent state of the trf7970a is reading but > a request has been made to send a command. > >

Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry Missing commit description. > diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c > index 2d2a077..b4c37ab 100644 > --- a/drivers/nfc/trf7970a.c > +++ b/drivers/nfc/trf7970a.c >

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

Hi Geoff. On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote: > From: Geoff Lansberry Please add an informative commit description to all of your commits. No matter how trivial this patch may seem to you now, it may not be to others (or to you in a few years). >

Re: ath10k firmware sends probes on DFS channels without radar detection

On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote: > > > Thanks for the suggestion, I already tried something like this in > > > wmi.c, with the same result: > > > > > > - Before patching the firmware scans DFS channels actively (with > > probes). > > > > > > - After patching, the

[PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

From: Geoff Lansberry --- .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++ drivers/nfc/trf7970a.c | 42 -- 2 files changed, 34 insertions(+), 11 deletions(-) diff --git

[PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

From: Jaret Cantu Repeated polling attempts cause a NULL dereference error to occur. This is because the curent state of the trf7970a is reading but a request has been made to send a command. The solution is to properly kill the waiting reading (workqueue) before

[PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

From: Geoff Lansberry --- Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++ drivers/nfc/trf7970a.c | 13 - 2 files changed, 14 insertions(+), 1 deletion(-) diff --git

Re: [RFC v2 11/11] ath10k: Added sdio support

On 12/15/2016 05:40 PM, Valo, Kalle wrote: > Erik Stromdahl writes: > >> Initial HIF sdio/mailbox implementation. >> >> Signed-off-by: Erik Stromdahl >> --- >> drivers/net/wireless/ath/ath10k/Kconfig |6 + >>

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

On 15-12-2016 6:15, Michael S. Tsirkin wrote: > That's the default now, no need for makefiles to set it. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/bluetooth/Makefile| 2 -- > drivers/net/can/Makefile |

Re: wl1251 & mac address & calibration data

On 15-12-2016 16:33, Pali Rohár wrote: > On Thu Dec 15 09:18:44 2016 Kalle Valo wrote: >> (Adding Luis because he has been working on request_firmware() lately) >> >> Pali Rohár writes: >> > So no, there is no argument against... request_firmware()

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

On 12/14/2016 09:15 PM, Michael S. Tsirkin wrote: > __bitwise__ used to mean "yes, please enable sparse checks > unconditionally", but now that we dropped __CHECK_ENDIAN__ > __bitwise is exactly the same. > There aren't many users, replace it by __bitwise everywhere. > > Signed-off-by: Michael S.

[PATCH 02/14 V2] rtlwifi: Remove RT_TRACE messages that use DBG_EMERG

These messages are always logged and represent error conditions, thus we can use pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 - eliminate some files that should not have been sent, and remove the module name from the format.

[PATCH 12/14 V2] rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 14/14 V2] rtlwifi: Remove some redundant code

The symbol DBG_EMERG is no longer used and is removed. In a number of places, the code has redundant messages. For example, if the failure for the firmware to run is logged, it is not necessary to log that the firmware has been started. In addition, extraneous braces are removed. Signed-off-by:

[PATCH 04/14 V2] rtlwifi: rtl8723be: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 11/14 V2] rtlwifi: rtl8192ce: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 09/14 V2] rtlwifi: rtl8192de: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 08/14] rtlwifi: rtl8192se: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 05/14 V2] rtlwifi: rtl8723ae: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 13/14 V2] rtlwifi: rtl8188ee: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 07/14 V2] rtlwifi: rtl8723-common: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 10/14 V2] rtlwifi: rtl8192cu: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 06/14 V2] rtlwifi: rtl8192ee: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 03/14 V2] rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG

This is a step toward eliminating the RT_TRACE macros. Those calls that have DBG_EMERG as the level are always logged, and they represent error conditions, thus they are replaced with pr_err(). Signed-off-by: Larry Finger Cc: Ping-Ke Shih --- V2 -

[PATCH 00/14 V2] rtlwifi: Start reworking of debug system

Following the discussion regarding the patch entitled "rtlwifi: Add BTC_TRACE_STRING to new btcoex", we are reworking the entire debug system. This set of patches does the following: 1. Replaces every invocation of RT_ASSERT with WARN_ON. With this change, triggering these conditions with now

RE: ath10k firmware sends probes on DFS channels without radar detection

> -Message d'origine- > De : Ben Greear [mailto:gree...@candelatech.com] > Envoyé : jeudi 15 décembre 2016 17:33 > À : Jean-Pierre Tosoni; 'Jouni Malinen' > Cc : linux-wireless@vger.kernel.org; ath...@lists.infradead.org > Objet : Re: ath10k firmware sends probes on DFS channels without

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote: > __bitwise__ used to mean "yes, please enable sparse checks > unconditionally", but now that we dropped __CHECK_ENDIAN__ > __bitwise is exactly the same. > There aren't many users, replace it by __bitwise everywhere. > >

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hello Shafi, On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote: > I am also thinking, as of now there is not much use in appending > the extended peer stats (which gets periodically ) to the linked list > '>debug.fw_stats.peers_extd)' and should we get rid of the

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hi Christian, I am also thinking, as of now there is not much use in appending the extended peer stats (which gets periodically ) to the linked list '>debug.fw_stats.peers_extd)' and should we get rid of the below (and the required cleanup as well) list_splice_tail_init(_extd,

Re: [RFC v2 11/11] ath10k: Added sdio support

Erik Stromdahl writes: > Initial HIF sdio/mailbox implementation. > > Signed-off-by: Erik Stromdahl > --- > drivers/net/wireless/ath/ath10k/Kconfig |6 + > drivers/net/wireless/ath/ath10k/Makefile |3 + >

Re: ath10k firmware sends probes on DFS channels without radar detection

On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote: Jouni, Thanks for the suggestion, I already tried something like this in wmi.c, with the same result: - Before patching the firmware scans DFS channels actively (with probes). - After patching, the firmware scans DFS channels passively *until*

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hello Christian, On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote: > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote: > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan > > > wrote: > > > > On Mon, Dec 05, 2016 at

Re: wl1251 & mac address & calibration data

On Thu Dec 15 09:18:44 2016 Kalle Valo wrote: > (Adding Luis because he has been working on request_firmware() lately) > > Pali Rohár writes: > > > > > So no, there is no argument against... request_firmware() in > > > > fallback mode with userspace

RE: ath10k firmware sends probes on DFS channels without radar detection

Jouni, Thanks for the suggestion, I already tried something like this in wmi.c, with the same result: - Before patching the firmware scans DFS channels actively (with probes). - After patching, the firmware scans DFS channels passively *until* any beacon is received on the DFS channel. When

[PATCH 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include

drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by: Corentin Labbe --- drivers/nfc/nxp-nci/i2c.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c

[PATCH 2/3] nfc: pn544: Remove unneeded linux/miscdevice.h include

drivers/nfc/pn544/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by: Corentin Labbe --- drivers/nfc/pn544/i2c.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c index

[PATCH 3/3] nfc: st21nfca: Remove unneeded linux/miscdevice.h include

drivers/nfc/st21nfca/i2c.c does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by: Corentin Labbe --- drivers/nfc/st21nfca/i2c.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/nfc/st21nfca/i2c.c

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

> > I agree. Dynamic switch part is buggy, we can start with not > > allowing interfaces resulting in dynamic switch. > > Does this mean that when bringing up multiple interfaces, users would > need to figure out the 'magic' order that works? I think we need to talk about hardware capabilities

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On 2016-12-15 13:01, Thiagarajan, Vasanthakumar wrote: > On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote: >>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration >>> + * implementing 802.11 encap/decap for data frames changed. >>>*/ >>> enum ieee80211_conf_changed {

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote: > __bitwise__ used to mean "yes, please enable sparse checks > unconditionally", but now that we dropped __CHECK_ENDIAN__ > __bitwise is exactly the same. > There aren't many users, replace it by __bitwise everywhere. > >

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote: > >> There is a field, no_80211_encap, added to ieee80211_tx_info:control >> to mark if the 802.11 encapsulation is offloaded to driver. >> There is also a new callback for tx completion status indication >> to handle data frames using

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

On Thu, Dec 15, 2016 at 07:15:30AM +0200, Michael S. Tsirkin wrote: > That's the default now, no need for makefiles to set it. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/bluetooth/Makefile| 2 -- > drivers/net/can/Makefile

Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

On Tue, Dec 13, 2016 at 04:56:55PM +0100, Johannes Berg wrote: > Regarding reusing attributes, we have (for the BSS selection thing) the > attribute NL80211_BSS_SELECT_ATTR_RSSI_ADJUST, which is really quite > similar to your new NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since > while

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote: > >> Drivers advertising this capability should also implement other >> functionalities which deal with 802.11 frame format like below > >> - ADDBA/DELBA offload > > This shouldn't be necessary. Ok. Since driver/hw needs to

Hello Beautiful

How you doing today? I hope you are doing well. My name is Bentley, from the US. I'm in Syria right now fighting ISIS. I want to get to know you better, if I may be so bold. I consider myself an easy-going man, and I am currently looking for a relationship in which I feel loved. Please tell me

Re: [RFC 0/3] Add new data path for ethernet frame format

On Thursday 15 December 2016 02:38 PM, Johannes Berg wrote: > On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote: >> This patch set adds a new data path to offload 802.11 header >> encap/decap to driver or hardware. Drivers having support >> for ieee80211 header encap/decap and

Re: [PATCH 01/10] mac80211: minstrel_ht: move supported bitrate mask out of group data

That all looks good, applied. johannes

Re: [PATCH] mac80211: only alloc mem if a station doesnt exist yet

On Wed, 2016-12-14 at 17:28 +0100, Koen Vandeputte wrote: > This speeds up the function in case a station already exists by > avoiding > calling an expensive kzalloc just to free it again after the next > check. It's not like this is called often, but yeah - still makes sense. Applied. johannes

Re: [PATCH v2] mac80211: fix legacy and invalid rx-rate rpt

On Wed, 2016-12-14 at 11:30 -0800, gree...@candelatech.com wrote: > From: Ben Greear > > This fixes obtaining the rate info via sta_set_sinfo > when the rx rate is invalid (for instance, on IBSS > interface that has received no frames from one of its > peers). > > This

Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format

> This rx path only checks if the driver has advertised > it's support of 802.11 header encap/decap offload for > data frames. I'm not even sure I see the point in that? Other than that (and the various other offload requirements), it seems that encap/decap could be considered orthogonal. > +

Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

> There is a field, no_80211_encap, added to ieee80211_tx_info:control > to mark if the 802.11 encapsulation is offloaded to driver. > There is also a new callback for tx completion status indication > to handle data frames using 802.11 encap offload. I'm not sure I see the need for this? Maybe

Re: ath10k: Avoid potential page alloc BUG_ON in tx free path

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc' > have NULL pointer checks to avoid crash if they are called twice > but this is as of now not

Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

> Drivers advertising this capability should also implement other > functionalities which deal with 802.11 frame format like below > - ADDBA/DELBA offload This shouldn't be necessary. > - Hardware rate control Neither is this, if we find some API to do sampling. The existing rate

Re: [RFC 0/3] Add new data path for ethernet frame format

On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote: > This patch set adds a new data path to offload 802.11 header > encap/decap to driver or hardware. Drivers having support > for ieee80211 header encap/decap and other offload functionalities > which can't be done before encap or

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

Hello. On 15/12/16 06:15, Michael S. Tsirkin wrote: __bitwise__ used to mean "yes, please enable sparse checks unconditionally", but now that we dropped __CHECK_ENDIAN__ __bitwise is exactly the same. There aren't many users, replace it by __bitwise everywhere. Signed-off-by: Michael S.

Re: ath9k: Turn ath_txq_lock/unlock() into static inlines.

Toke Høiland-Jørgensen wrote: > These are one-line functions that just call spin_lock/unlock_bh(); turn > them into static inlines to avoid the function call overhead. > > Signed-off-by: Toke Høiland-Jørgensen Patch applied to ath-next branch of ath.git, thanks. 5c4607ebaabe

Re: [v3] ath9k: Introduce airtime fairness scheduling between stations

Toke Høiland-Jørgensen wrote: > This reworks the ath9k driver to schedule transmissions to connected > stations in a way that enforces airtime fairness between them. It > accomplishes this by measuring the time spent transmitting to or > receiving from a station at TX and RX completion, and

Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements

Martin Blumenstingl writes: > There are two types of swapping the EEPROM data in the ath9k driver. > Before this series one type of swapping could not be used without the > other. > > The first type of swapping looks at the "magic bytes" at the start of > the

Re: wl1251 & mac address & calibration data

(Adding Luis because he has been working on request_firmware() lately) Pali Rohár writes: >> > So no, there is no argument against... request_firmware() in >> > fallback mode with userspace helper is by design blocking and >> > waiting for userspace. But waiting for some

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

On 12/15/2016 06:15 AM, Michael S. Tsirkin wrote: > That's the default now, no need for makefiles to set it. > > Signed-off-by: Michael S. Tsirkin > --- [...] > drivers/net/can/Makefile | 1 - For drivers/net/can/Makefile: Acked-by: Marc