Re: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals

On Fri, 2016-08-05 at 10:56 +0530, Purushottam Kushwaha wrote: > This commit provides the option for the host drivers to advertise the > support for different beacon intervals among the respective interface > combinations, through supp_diff_beacon_int (bool). Neither your commit message nor the

Re: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

On Friday 05 August 2016 02:01 AM, Arnd Bergmann wrote: On Thursday, August 4, 2016 10:22:43 PM CEST Arvind Yadav wrote: index df8ea79..ada9070 100644 --- a/include/soc/fsl/qe/ucc_fast.h +++ b/include/soc/fsl/qe/ucc_fast.h @@ -165,10 +165,12 @@ struct ucc_fast_private { int

Re: Buggy rhashtable walking

> So I'm going to fix this by consolidating identical objects into > a single rhashtable entry which also lets us get rid of the > insecure_elasticity setting. Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? (Luckily) the colliding key case

[PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

This switches ath9k over to using the mac80211 intermediate software queueing mechanism for data packets. It removes the queueing inside the driver, except for the retry queue, and instead pulls from mac80211 when a packet is needed. The retry queue is used to store a packet that was pulled but

Re: Buggy rhashtable walking

On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > Hm. Would you rather allocate a separate head entry for the hashtable, > or chain the entries? My plan is to build support for this directly into rhashtable. So I'm adding a struct rhlist_head that would be used in place of

Re: Buggy rhashtable walking

On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: > On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > > > Hm. Would you rather allocate a separate head entry for the > > hashtable, > > or chain the entries? > > My plan is to build support for this directly into rhashtable. >

Re: [PATCH] cfg80211: Add support for user configurable beacon data rate

On Fri, 2016-08-05 at 10:05 +0530, Purushottam Kushwaha wrote: >  > +static int nl80211_parse_tx_bitrate_mask(struct genl_info *info, > +  struct cfg80211_bitrate_mask *mask); I think you should move the function instead. > @@ -3457,6 +3459,11 @@ static int

Re: [PATCH 4/4] ath10k: Enable support for QCA9984

On Thursday 04 August 2016 07:50 PM, bharath yadav wrote: > Hi., > I am trying to enable support for QCA9984 on latest stable backports-4.4.2-1 > using the above patch. > > downloaded > "https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/ath/; > (ath.git) has the patch > applied for

[v5.2] ucc_slow: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

IS_ERR_VALUE() assumes that parameter is an unsigned long. It can not be used to check if 'unsigned int' is passed insted. Which tends to reflect an error. In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8. IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095). IS_ERR_VALUE() of 'unsigned

Re: [PATCH] ath10k: hide kernel addresses from logs using %pK format specifier

On Thu, 2016-08-04 at 19:21 +0530, c_mke...@qti.qualcomm.com wrote: > From: Maharaja Kennadyrajan > > With the %pK format specifier we hide the kernel addresses > with the help of kptr_restrict sysctl. > In this patch, %p is changed to %pK in the driver code. > > The

Re: [PATCH v3] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command

On Wed, 2016-08-03 at 10:07 +0900, Masashi Honma wrote: > Previously, NL80211_MESHCONF_HT_OPMODE rejected correct flag > combination, ex) IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED | > IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT. > > This was caused by simple comparison with value 16. This causes >

pull-request: mac80211 2016-08-05

Hi Dave, Here's a first set of fixes for the current cycle. See the tag message for more information. I'll probably have a follow-up fix for the real problem in mac80211 that caused the crash later, but for now we have this patch and it makes sense and fixes the crash, even if the behaviour

Re: Buggy rhashtable walking

On 08/05/2016 03:50 AM, Johannes Berg wrote: On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? My plan is to build support for

RE: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

From: Arvind Yadav > Sent: 04 August 2016 17:53 > IS_ERR_VALUE() assumes that parameter is an unsigned long. > It can not be used to check if 'unsigned int' is passed insted. > Which tends to reflect an error. > In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8. > IS_ERR_VALUE(x) is

[PATCH] Staging: rtl8723au: rtw_ieee80211: Fixed operators spacing style issues

Fixed spaces around operators to fix their coding style issues. Signed-off-by: Shiva Kerdel --- drivers/staging/rtl8723au/core/rtw_ieee80211.c | 80 +- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git

[PATCH 1/1] brcmfmac: fix pmksa->bssid usage

The struct cfg80211_pmksa defines its bssid field as: const u8 *bssid; contrary to struct brcmf_pmksa, which uses: u8 bssid[ETH_ALEN]; Therefore in brcmf_cfg80211_del_pmksa(), >bssid takes the address of this field (of type u8**), not the one of its content (which would be u8*).

TCP data throughput for BCM43362

Hi, I'm using a custom ARM board with an BCM43362 wifi chip from Broadcom. The wifi chip is attached via SDIO to the controller with a clock of 48MHz. Linux kernel version is 4.7. When measuring the network bandwidth with iperf3 I get a bandwith of only around 5 Mbps. I found a similar thread at

Re: TCP data throughput for BCM43362

Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel : >Op 5 aug. 2016 22:46 schreef "Jörg Krause" >: >> >> Hi, >> >> I'm using a custom ARM board with an BCM43362 wifi chip from >Broadcom. >> The wifi chip is attached via SDIO to

[RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Ted, Herbert, I sent a question to the ATH9K RNG some time ago to the developers. See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html I have not yet received a word and I think this issue should be resolved. Thanks Stephan ---8<--- The ATH9K driver implements an RNG