Re: [PATCH v3 1/2] mmc: API for accessing host supported maximum segment count and size

Hi On 2016-6-6 19:53, Amitkumar Karwar wrote: From: Xinming Hu sdio device drivers need be able to get the host supported max_segs and max_seg_size, so that they know the buffer size to allocate while utilizing the scatter/gather DMA buffer list. This patch provides API for

Re: [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

On 7 June 2016 at 04:12, Toke Høiland-Jørgensen wrote: > Toke Høiland-Jørgensen writes: > >>> [snip] >>> >>> I also found one of my notes in my version of this - how can we >>> estimate the duration of an A-MPDU, when we only get hardware >>> de-encapsulated frames?

Re: [ldv-project] [net] libertas: potential race condition

On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > > Hi! > > > > There is a potential race condition in  > > drivers/net/wireless/libertas/libertas.ko. > > In the function lbs_hard_start_xmit(..), line 159, a socket buffer >

[PATCH] libertas_tf: Remove create_workqueue

alloc_workqueue replaces deprecated create_workqueue(). A dedicated workqueue has been used since the workitem (viz >cmd_work per priv, which maps to lbtf_cmd_work) is involved in actual command processing and may be used on a memory reclaim path. The workitems require forward progress under

Re: [PATCH] rtl8xxxu: fix typo on variable name, compare against correct variable

Jes Sorensen writes: > Colin King writes: >> From: Colin Ian King >> >> path_b_ok is being assigned but immediately after path_a_ok is being >> compared to the value 0x03. This appears to be a typo on the >> variable

[PATCH] brcmfmac: slightly simplify building interface combinations

This change reorders some operations in brcmf_setup_ifmodes in hope to make it simpler: 1) It allocates arrays right before filling them. This way it's easier to follow requested array length as it's immediately followed by code filling it. It's easier to check e.g. why we need 4 entries for

Re: [PATCH 0/2] ath10k: Add support for QCA9887

Hi Sven, On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote: > On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote: > [...] > > [shafi] it would be helpful if you can share your basic test results (if its > > possible to share). Have you tried to bring up the card in 5ghz

Re: [PATCH 0/2] ath10k: Add support for QCA9887

On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote: [...] > [shafi] it would be helpful if you can share your basic test results (if its > possible to share). Have you tried to bring up the card in 5ghz (or) 2ghz. > Or both of them were tried ? * 5GHz-only (I have no 2.4GHz capable

Re: [ldv-project] [net] libertas: potential race condition

07.06.2016 18:39, Dan Williams пишет: On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: Hi! There is a potential race condition in drivers/net/wireless/libertas/libertas.ko. In the function lbs_hard_start_xmit(..), line 159, a socket buffer is written to priv->current_skb with a

Re: linux-4.7-rc2/drivers/net/wireless/ath/ath6kl/wmi.c:2547]: (style) Redundant condition

David Binderman writes: > Hello there, > > linux-4.7-rc2/drivers/net/wireless/ath/ath6kl/wmi.c:2547]: (style) > Redundant condition: If 'EXPR <= 7', the comparison 'EXPR < 8' is > always true. > > Source code is > > if (!((params->user_pri < 8) && >

linux-4.7-rc2/drivers/net/wireless/ath/ath6kl/wmi.c:2547]: (style) Redundant condition

Hello there, linux-4.7-rc2/drivers/net/wireless/ath/ath6kl/wmi.c:2547]: (style) Redundant condition: If 'EXPR <= 7', the comparison 'EXPR < 8' is always true. Source code is if (!((params->user_pri < 8) && (params->user_pri <= 0x7) && This might be a possible cut'n'paste error.

Re: [PATCH 0/2] ath10k: Add support for QCA9887

Hi Sven, On Mon, May 30, 2016 at 01:12:27PM +0200, Sven Eckelmann wrote: > On Friday 27 May 2016 12:44:52 Valo, Kalle wrote: > [...] > > > But maybe I should add that the results with the original AP147 firmware > > > also > > > wasn't better. > > > > That doesn't sound good. Maybe a

Re: [ldv-project] [net] libertas: potential race condition

On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > Hi! > > There is a potential race condition in  > drivers/net/wireless/libertas/libertas.ko. > In the function lbs_hard_start_xmit(..), line 159, a socket buffer > is  > written to priv->current_skb with a spin_lock protection. > In the

Re: [PATCH 5/6] ath9k: Use defined constants consistently.

On 2016-06-07 15:10, Benjamin Berg wrote: > From: Benjamin Berg > > Signed-off-by: Benjamin Berg > --- > drivers/net/wireless/ath/ath9k/main.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git

[PATCH 4/6] ath9k: Expose tsf_adjustment in mac80211 tsf getters and setters.

From: Benjamin Berg Signed-off-by: Benjamin Berg --- drivers/net/wireless/ath/ath9k/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index

[PATCH 2/6] ath9k: Handle channel context in get_/set_/reset_tsf

From: Benjamin Berg Signed-off-by: Benjamin Berg --- drivers/net/wireless/ath/ath9k/main.c | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/main.c

[PATCH 5/6] ath9k: Use defined constants consistently.

From: Benjamin Berg Signed-off-by: Benjamin Berg --- drivers/net/wireless/ath/ath9k/main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/main.c

[PATCH 3/6] ath9k: Use tsf offset helper in ath9k_hw_reset

From: Benjamin Berg Not much of a change. Only small fix is that we don't assume that exactly 1.5ms have passed for the second AR91xx SoC TSF setting. Signed-off-by: Benjamin Berg --- drivers/net/wireless/ath/ath9k/hw.c | 16

Re: [PATCH v2] wireless-regdb: Republic of Korea: Add 60GHz regulatory rules

On Thu, Jun 02, 2016 at 10:33:05PM +0300, Maya Erez wrote: > Add 60GHz regulatory rules for Korea (KR). > Source is > http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99 > > Signed-off-by: Maya Erez

Re: [v2,01/21] ath10k: Fix crash related to printing features.

Ben Greear wrote: > From: Ben Greear > > This looks like a regression from > c4cdf753 (move fw_features to struct ath10k_fw_file) > > Signed-off-by: Ben Greear Thanks, 1 patch applied to ath-current branch of

Re: [1/2] ath10k: add QCA9887 chipset support

Sven Eckelmann wrote: > Add the hardware name, revision, firmware names and update the pci_id > table. > > QA9887 HW1.0 is supposed to be similar to QCA988X HW2.0 . Details about > he firmware interface are currently unknown. > > Signed-off-by: Sven Eckelmann

Re: [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Toke Høiland-Jørgensen writes: >> [snip] >> >> I also found one of my notes in my version of this - how can we >> estimate the duration of an A-MPDU, when we only get hardware >> de-encapsulated frames? > > Well in my case I'm sidestepping this by getting the TX duration from > a

[ldv-project] [net] libertas: potential race condition

Hi! There is a potential race condition in drivers/net/wireless/libertas/libertas.ko. In the function lbs_hard_start_xmit(..), line 159, a socket buffer is written to priv->current_skb with a spin_lock protection. In the function lbs_mac_event_disconnected(..), lines 50-51, the field

Re: [RFC/RFT 5/5] ath9k: Count RX airtime in airtime deficit

Adrian Chadd writes: > [snip] > > I also found one of my notes in my version of this - how can we > estimate the duration of an A-MPDU, when we only get hardware > de-encapsulated frames? Well in my case I'm sidestepping this by getting the TX duration from a register in the

Re: wext: making deprecation more visible

> I know we can't remove wext because of legacy applications but is > there anything more we can do to make the users aware that wext is > depreciated and really should be avoided? For example a onetime > kernel warning? Or is that too spammy? Anything else? The problem is that wext is in this

[PATCH] brcmfmac: include required headers in cfg80211.h

Without this including cfg80211.h in a wrong order could result in: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:122:24: error: array type has incomplete element type struct brcmf_wsec_key key[BRCMF_MAX_DEFAULT_KEYS]; ^