date:20160903

Re: [PATCH 2/2] mwifiex: simplify length computation for some memset

2016-09-03 Thread Julian Calaby

Hi All,

On Mon, Aug 8, 2016 at 5:39 PM, Christophe JAILLET
 wrote:
> This patch should be a no-op. It just simplifies code by using the name of
> a variable instead of its type when calling 'sizeof'.
>
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] Add protection to get_expected_throughput opcode

2016-09-03 Thread Julian Calaby

Hi Maxim,

On Thu, Aug 11, 2016 at 8:38 PM, Maxim Altshul  wrote:
> The patch is done with respect to the patch that was applied:
> [PATCH v3] mac80211: mesh: Add support for HW RC implementation
>
> 1. Patch adds protection as we discussed
> 2. Patch changes the function call that is made in the mesh patch
> to comply with the change.
>
> Maxim Altshul (1):
>   mac80211: Add protection to get_expected_throughput opcode
>
>  net/mac80211/driver-ops.h | 8 
>  net/mac80211/sta_info.c   | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)

Where's the patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] ath10k: Spelling and miscellaneous neatening

2016-09-03 Thread Julian Calaby

Hi All,

On Tue, Aug 30, 2016 at 3:05 AM, Joe Perches  wrote:
> Correct some trivial comment typos.
> Remove unnecessary parentheses in a long line.
> Convert a return; before the end of a void function definition to just ;
>
> Signed-off-by: Joe Perches 

This all looks correct to me. I wish you'd put the code changes in a
separate patch, however it's all noted in the commit log, so...

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] staging: wilc1000: fix spelling mistake: "retyring" -> "retrying"

2016-09-03 Thread Julian Calaby

Hi All,

On Sun, Aug 28, 2016 at 9:28 PM, Colin King  wrote:
> From: Colin Ian King 
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King 

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

2016-09-03 Thread Julian Calaby

Hi All,

On Sun, Sep 4, 2016 at 2:43 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistakes in dev_dbg message.
>
> Signed-off-by: Colin Ian King 

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: wcn36xx: Implement print_reg indication

2016-09-03 Thread Kalle Valo

Bjorn Andersson  wrote:
> Some firmware versions sends a "print register indication", handle this
> by printing out the content.
> 
> Cc: Nicolas Dechesne 
> Signed-off-by: Bjorn Andersson 

This doesn't apply anymore, please rebase.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9208737/

Re: ath9k: bring back direction setting in ath9k_{start_stop}

2016-09-03 Thread Kalle Valo

Giedrius Statkevi?ius  wrote:
> A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup
> led_pin initial") that broken the WLAN status led on my laptop with
> AR9287 after suspending and resuming.
> 
> Steps to reproduce:
> * Suspend (laptop)
> * Resume (laptop)
> * Observe that the WLAN led no longer turns ON/OFF depending on the
>   status and is always red
> 
> Even though for my case it only needs to be set to OUT in ath9k_start
> but for consistency bring back the IN direction setting as well.
> 
> Cc: Miaoqing Pan 
> Cc: Kalle Valo 
> Cc: 
> Signed-off-by: Giedrius Statkevičius 

I'm planning to queue this to 4.8 if no objections.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9309829/

Re: rtlwifi/rtl8192de: Fix print format string

2016-09-03 Thread Kalle Valo

Oleg Drokin  wrote:
> %ul was likely meant as %lu to print an unsigned long,
> not an unsigned with a letter l at the end.
> But in fact the value printed is u32 anyway, so just drop
> the l completely.
> 
> Signed-off-by: Oleg Drokin 
> Acked-by: Larry Finger 

Thanks, 1 patch applied to wireless-drivers-next.git:

5856cd5b8dda rtlwifi/rtl8192de: Fix print format string

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9302259/

Re: [1/3] mwifiex: make "PCI-E is not the winner" print more informative

2016-09-03 Thread Kalle Valo

Stanislaw Gruszka  wrote:
> Printing ret and adapter->winner do not provide any useful information
> as those are always 0 at point where the massage is printed. Print value
> read from reg->fw_status register instead.
> 
> Stanislaw Gruszka 

Thanks, 3 patches applied to wireless-drivers-next.git:

fd3fbb65cab8 mwifiex: make "PCI-E is not the winner" print more informative
09dd9ec598c3 mwifiex: print status of FW ready event
b9aebb69ecd3 mwifiex: do not print dot when downloading FW

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9299495/

Re: wl18xx: add time sync configuration api

2016-09-03 Thread Kalle Valo

Guy Mishol  wrote:
> Add time sync configuration api.
> The new api allows to configure the synchronization
> mode (STA/AP/MESH) and (in case of Mesh mode) the
> master address of each zone.
> 
> Signed-off-by: Guy Mishol 

Thanks, 1 patch applied to wireless-drivers-next.git:

c5aa9541818a wl18xx: add time sync configuration api

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9297563/

Re: [v2,1/1] brcmfmac: fix pmksa->bssid usage

2016-09-03 Thread Kalle Valo

Nicolas Iooss  wrote:
> 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*).  Remove the & operator to make brcmf_dbg("%pM") and memcmp()
> behave as expected.
> 
> This bug have been found using a custom static checker (which checks the
> usage of %p... attributes at build time).  It has been introduced in
> commit 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code"),
> which replaced pmksa->bssid by >bssid while refactoring the code,
> without modifying struct cfg80211_pmksa definition.
> 
> Replace [i].bssid with pmk[i].bssid too to make the code clearer,
> this change does not affect the semantic.
> 
> Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nicolas Iooss 

Thanks, 1 patch applied to wireless-drivers-next.git:

7703773ef1d8 brcmfmac: fix pmksa->bssid usage

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9295351/

Re: [v2] brcmfmac: Add USB ID for Cisco Linksys AE1200

2016-09-03 Thread Kalle Valo

Ismael Luceno  wrote:
> The AE1200 comes with different revisions of the BCM43235 chipset,
> but all have the same USB ID. Only revision 3 can be supported.
> 
> Signed-off-by: Ismael Luceno 

Thanks, 1 patch applied to wireless-drivers-next.git:

bccf3ffc8c6d brcmfmac: Add USB ID for Cisco Linksys AE1200

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9294493/

Re: rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()

2016-09-03 Thread Kalle Valo

Christian Engelmayer  wrote:
> In case of (rtlhal->oem_id != RT_CID_DEFAULT), the function directly
> returns and leaks the already allocated hwinfo memory. Go through the
> correct exit path.
> 
> Signed-off-by: Christian Engelmayer 
> Acked-by: Larry Finger 

Thanks, 1 patch applied to wireless-drivers-next.git:

3eeacaa902a3 rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9272147/

Re: [V2] rtlwifi: Fix missing country code for Great Britain

2016-09-03 Thread Kalle Valo

Larry Finger  wrote:
> Some RTL8821AE devices sold in Great Britain have the country code of
> 0x25 encoded in their EEPROM. This value is not tested in the routine
> that establishes the regulatory info for the chip. The fix is to set
> this code to have the same capabilities as the EU countries. In addition,
> the channels allowed for COUNTRY_CODE_ETSI were more properly suited
> for China and Israel, not the EU. This problem has also been fixed.
> 
> Signed-off-by: Larry Finger 
> Cc: Stable 

Thanks, 1 patch applied to wireless-drivers-next.git:

0c9d34915307 rtlwifi: Fix missing country code for Great Britain

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9294303/

Re: zd1211rw: fix spelling mistake "firmeware" -> "firmware"

2016-09-03 Thread Kalle Valo

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in dev_err message.
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to wireless-drivers-next.git:

b46b599328e6 zd1211rw: fix spelling mistake "firmeware" -> "firmware"

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9294163/

Re: [01/20] rtl8xxxu: Mark 0x20f4:0x648b as tested

2016-09-03 Thread Kalle Valo

Jes Sorensen  wrote:
> From: Jes Sorensen 
> 
> Successfully tested by Jocelyn Mayer
> 
> Reported-by: J. Mayer 
> Signed-off-by: Jes Sorensen 

Thanks, 20 patches applied to wireless-drivers-next.git:

b81669b9e0b4 rtl8xxxu: Mark 0x20f4:0x648b as tested
76a8e07d49b6 rtl8xxxu: Mark 0x2001:0x3308 as tested
deb6176e5613 rtl8xxxu: Fix error handling if rtl8xxxu_init_device() fails
690a6d268bdf rtl8xxxu: Add TP-Link TL-WN823N v2 to list of supported devices
44abaa08d002 rtl8xxxu: Add TX page defines for 8723b
e366f45d3627 rtl8xxxu: Switch 8723a to use new 
rtl8xxxu_init_queue_reserved_page() routine
b492940dc1f7 rtl8xxxu: Switch 8192cu/8188cu devices to use 
rtl8xxxu_init_queue_reserved_page()
efeb8ce7a98c rtl8xxxu: Remove now obsolete 
rtl8xxxu_old_init_queue_reserved_page()
e02aa3eef786 rtl8xxxu: Simplify code setting TX buffer boundary
dce7548fd970 rtl8xxxu: Add bit definitions for REG_FPGA0_TX_INFO
0b09628948bc rtl8xxxu: Add interrupt bit definitions for gen2 parts
e3ebcd7428c1 rtl8xxxu: Use flag to indicate whether device has TX report timer 
support
ee675cc30e07 rtl8xxxu: Convert flags in rtl8xxxu_fileops to bitflags
eed145ab25a3 rtl8xxxu: Introduce fops bitflag indicating type of thermal meter
be49b1f111c7 rtl8xxxu: Simplify calculating of hw value used for setting TX rate
3972cc579140 rtl8xxxu: Determine the need for SGI before handling specific TX 
desc formats
99afaac4278c rtl8xxxu: Determine need for shore preamble before updating TX 
descriptors
b59415c2dd08 rtl8xxxu: Split filling of TX descriptors into separate functions
77e3980201e7 rtl8xxxu: gen1: Fix non static symbol warning
7329dc13107b rtl8xxxu: Make rtl8xxxu_ampdu_action less chatty

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9291151/

Re: rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()

2016-09-03 Thread Kalle Valo

Christian Engelmayer  wrote:
> In case rtl_get_hwinfo() fails, the function directly returns and leaks the
> already allocated hwinfo memory. Go through the correct exit path.
> 
> Signed-off-by: Christian Engelmayer 
> Acked-by: Larry Finger 

Thanks, 1 patch applied to wireless-drivers-next.git:

a0c7858e7479 rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9272131/

[PATCH] rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

2016-09-03 Thread Colin King

From: Colin Ian King 

Trivial fix to spelling mistakes in dev_dbg message.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 77048db..9cb1efa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3947,11 +3947,11 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, priv->fops->trxff_boundary);
 
ret = rtl8xxxu_download_firmware(priv);
-   dev_dbg(dev, "%s: download_fiwmare %i\n", __func__, ret);
+   dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
if (ret)
goto exit;
ret = rtl8xxxu_start_firmware(priv);
-   dev_dbg(dev, "%s: start_fiwmare %i\n", __func__, ret);
+   dev_dbg(dev, "%s: start_firmware %i\n", __func__, ret);
if (ret)
goto exit;
 
-- 
2.9.3

[PATCH][V2] ath10k: fix memory leak on caldata on error exit path

2016-09-03 Thread Colin King

From: Colin Ian King 

caldata is not being free'd on the error exit path, causing
a memory leak and data definitely should not be freed. Free
caldata instead of data.

Thanks to Kalle Valo for spotting that data should not be
free'd.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath10k/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 9a22c47..afdf0fa 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2725,7 +2725,7 @@ static int ath10k_pci_hif_fetch_cal_eeprom(struct ath10k 
*ar, void **data,
return 0;
 
 err_free:
-   kfree(data);
+   kfree(caldata);
 
return -EINVAL;
 }
-- 
2.9.3

Re: [PATCH] ath10k: fix memory leak on caldata on error exit path

2016-09-03 Thread Colin Ian King

On 02/09/16 16:45, Valo, Kalle wrote:
> Colin King  writes:
> 
>> From: Colin Ian King 
>>
>> caldata is not being free'd on the error exit path, causing
>> a memory leak. kfree it to fix the leak.
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/net/wireless/ath/ath10k/pci.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
>> b/drivers/net/wireless/ath/ath10k/pci.c
>> index 9a22c47..886337c 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2725,6 +2725,7 @@ static int ath10k_pci_hif_fetch_cal_eeprom(struct 
>> ath10k *ar, void **data,
>>  return 0;
>>  
>>  err_free:
>> +kfree(caldata);
>>  kfree(data);
>>  
>>  return -EINVAL;
> 
> I don't think we should free data at all:
> 
> static int ath10k_download_cal_eeprom(struct ath10k *ar)
> {
>   size_t data_len;
>   void *data = NULL;
>   int ret;
> 
>   ret = ath10k_hif_fetch_cal_eeprom(ar, , _len);
> 
> Instead we should free only caldata, right?
> 
Yep, good catch, I'll send V2 later.

Colin

Re: [PATCH] ath9k: bring back direction setting in ath9k_{start_stop}

2016-09-03 Thread Giedrius Statkevičius

Some more users complaining about this:
https://bbs.archlinux.org/viewtopic.php?id=215978

On Thu, Sep 01, 2016 at 08:47:02PM +0300, Giedrius Statkevičius wrote:
> A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup
> led_pin initial") that broken the WLAN status led on my laptop with
> AR9287 after suspending and resuming.
> 
> Steps to reproduce:
> * Suspend (laptop)
> * Resume (laptop)
> * Observe that the WLAN led no longer turns ON/OFF depending on the
>   status and is always red
> 
> Even though for my case it only needs to be set to OUT in ath9k_start
> but for consistency bring back the IN direction setting as well.
> 
> Cc: Miaoqing Pan 
> Cc: Kalle Valo 
> Cc: 
> Signed-off-by: Giedrius Statkevičius 
> ---
[...]

Re: mwifiex: add PCIe function level reset support

2016-09-03 Thread Kalle Valo

Amitkumar Karwar  wrote:
> This patch implements pre and post FLR handlers to support PCIe FLR
> functionality. Software cleanup is performed in pre-FLR whereas
> firmware is downloaded and software is re-initialised in
> post-FLR handler.
> 
> Following command triggers FLR.
> echo "1" > /sys/bus/pci/devices/$NUMBER/reset
> 
> This feature can be used as a recovery mechanism when firmware gets
> hang.
> 
> Signed-off-by: Amitkumar Karwar 

Doesn't apply anymore, please rebase.

Applying: mwifiex: add PCIe function level reset support
fatal: sha1 information is lacking or useless 
(drivers/net/wireless/marvell/mwifiex/main.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: add PCIe function level reset support

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9248233/

Re: [v2] ErrHandling:Make IS_ERR_VALUE_U32 as generic API to avoid IS_ERR_VALUE abuses.

2016-09-03 Thread Kalle Valo

Arvind Yadav  wrote:
> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> It can not be used to check if an 'unsigned int' reflects an error.
> As they pass an 'unsigned int' into a function that takes an
> 'unsigned long' argument. This happens to work because the type
> is sign-extended on 64-bit architectures before it gets converted
> into an unsigned type.
> 
> However, anything that passes an 'unsigned short' or 'unsigned int'
> argument into IS_ERR_VALUE() is guaranteed to be broken, as are
> 8-bit integers and types that are wider than 'unsigned long'.
> 
> It would be nice to any users that are not passing 'unsigned int'
> arguments.
> 
> Signed-off-by: Arvind Yadav 

This touches include/linux/err.h and I'm not very enthusiastic to change
anything in include directory without wider support. I recommend first to just
fix bcma.  And separately you can try to improve linux/err.h via some more
approariate tree, not via wireless trees.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9222139/

Re: [FIX?] brcmfmac: fix possible overflows in flowrings code by bumping u8 to u16

2016-09-03 Thread Kalle Valo

Rafał Miłecki wrote:
> Some devices may use more than 255 flowings, below is log from BCM4366:
> [  194.606245] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 264
> 
> At various places we were using u8 which could lead to storing wrong
> number or infinite loops when indexing incorrectly. Initially this
> issue was spotted as infinite loop in brcmf_flowring_detach.
> 
> Signed-off-by: Rafa? Mi?ecki 

There has been no activity on this patch so I'll drop this. Please resend if
this is still needed.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8172531/

Re: [v2] bcma: use of_dma_configure() to set initial dma mask

2016-09-03 Thread Kalle Valo

Arnd Bergmann  wrote:
> While fixing another bug, I noticed that bcma manually sets up
> a dma_mask pointer for its child devices. We have a generic
> helper for that now, which should be able to cope better with
> any variations that might be needed to deal with cache coherency,
> unusual DMA address offsets, iommus, or limited DMA masks, none
> of which are currently handled here.
> 
> This changes the core to use the of_dma_configure(), like
> we do for platform devices that are probed directly from
> DT.
> 
> Signed-off-by: Arnd Bergmann 

Nobody tested this, so I'll drop the patch.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/8608751/

Re: fix:rtl8xxxu_core: mark symbols static where possible

2016-09-03 Thread Jes Sorensen

Kalle Valo  writes:
> Baoyou Xie  wrote:
>> We get 1 warning about global functions without a declaration
>> in the rtl8xxxu rtl8xxxu_core.c when building with W=1:
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1:
>> warning: no previous prototype for 'rtl8xxxu_gen1_h2c_cmd'
>> [-Wmissing-prototypes]
>> 
>> In fact, this function is only used in the file in which it is declared
>> and don't need a declaration, but can be made static.
>> so this patch marks it 'static'.
>> 
>> Signed-off-by: Baoyou Xie 
>
> The title should be "rtl8xxxu: ". See:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
>
> Also I assume Jes will take this.

Yes to both accounts!

Thanks,
Jes

Re: [PATCHv8 0/4] register-field manipulation macros

2016-09-03 Thread Kalle Valo

Jakub Kicinski  writes:

> Small improvement suggested by Daniel Borkmann - use
> two underscore prefix.
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg125423.html
>
> -- v6 blurb:
>
> This set moves to a global header file macros which I find
> very useful and worth popularising.  The basic problem is
> that since C bitfields are not very dependable accessing
> subfields of registers becomes slightly inconvenient.
> It is nice to have the necessary mask and shift operations
> wrapped in a macro and have that macro compute shift
> at compilation time using FFS.
>
> My implementation follows what Felix Fietkau has done in
> mt76.  Hannes Frederic Sowa suggested more use of standard
> Linux/GCC functions.  Since the RFC I've also added a 
> compile-time check to validate that the value passed to
> setters fits in the mask.
>
> I attempted the use of static inlines instead of macros
> but it makes GCC < 6.0 barf at the BUILD_BUG_ON()s.
> I also noticed that forcing arguments to be u32 for inlines
> makes the compiler use 32bit arithmetic where it could
> get away with 64bit before (on 64bit machines, obviously).
> That's a potential performance concern but probably not
> a very practical one today.  Apart from looking "cleaner"
> static inlines would have the advantage that we could #undef
> the auxiliary macros at the end of the header.
>
> Build bot caught a build failure with -Os set.  AFAICT gcc
> did not handle temporary variable I put in the macro
> expression too well.  I work around that by defining
> __BUILD_BUG_ON_NOT_POWER_OF_2 and using it instead of
> BUILD_BUG_ON(!tmp || is_power_of_2(tmp)).
>
> I'm planning to use those macros in another driver soon,
> Felix may also use them when upstreaming mt76 if he chooses
> to do so.
>
> IMHO if accepted it would be best to push these through
> Kalle's wireless drivers' tree, since the only existing
> user is in drivers/net/wireless/.
>
> v8:
>  - use two underscores for auxiliary macros (Daniel B).
> v7:
>  - drop the explicit type marking (u32/u64) - depend on the type
>of the mask instead;
>  - only allow compilation time constant masks;
>  - barf at "type of register too small to ever match mask" on get;
>  - rename PUT -> PREP.
> v6:
>  - do a full rename in patch 2;
>  - CC many people.
> v5:
>  - repost.
> v4:
>  - add documentation in the header.
> v3:
>  - don't use variables in statement expressions;
>  - use __BUILD_BUG_ON_NOT_POWER_OF_2.
> v2:
>  - change Felix's email address.
>
> Jakub Kicinski (4):
>   add basic register-field manipulation macros
>   mt7601u: remove redefinition of GENMASK
>   mt7601u: remove unnecessary include
>   mt7601u: use linux/bitfield.h

I applied these now to the pending branch of my wireless-drivers-next
tree. Let's see if the kbuild bot finds any problems.

Please also CC lkml, did that now.

-- 
Kalle Valo

Re: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

2016-09-03 Thread Kalle Valo

Javier Martinez Canillas  wrote:
> If request_irq() fails in mwifiex_sdio_probe_of(), only an error message
> is printed but the actual error is not propagated to the caller function.
> 
> Signed-off-by: Javier Martinez Canillas 

What's the conclusion with this patch? Should I drop it or take it?

(The discussion is available from the patchwork link in the signature.)

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9288169/

Re: fix:rtl8xxxu_core: mark symbols static where possible

2016-09-03 Thread Kalle Valo

Baoyou Xie  wrote:
> We get 1 warning about global functions without a declaration
> in the rtl8xxxu rtl8xxxu_core.c when building with W=1:
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1: warning: no 
> previous prototype for 'rtl8xxxu_gen1_h2c_cmd' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is declared
> and don't need a declaration, but can be made static.
> so this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 

The title should be "rtl8xxxu: ". See:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name

Also I assume Jes will take this.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9302457/

Re: [2/2,v2] wlcore: Remove wl pointer from wl_sta structure

2016-09-03 Thread Kalle Valo

Maxim Altshul  wrote:
> This field was added to wl_sta struct to get hw in situations
> where it was not given to driver by mac80211.
> 
> In our case, get_expected_throughput op did not send hw to driver.
> 
> This patch reverts the change, as it is no longer needed due to
> get_expected_throughput op change (hw is now sent as a parameter)
> 
> Signed-off-by: Maxim Altshul 

I'll change the end of commit log to:

This patch reverts the change, as it is no longer needed due to commit
4fdbc67a25ce ("mac80211: call get_expected_throughput only after adding
station") as hw is now sent as a parameter.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9280419/

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

2016-09-03 Thread Felix Fietkau

On 2016-09-02 16:00, Toke Høiland-Jørgensen wrote:
> 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 can't be sent immediately.
> 
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
> 
> Based on Tim's original patch set, but reworked quite thoroughly.
> 
> Cc: Tim Shepard 
> Cc: Felix Fietkau 
> Signed-off-by: Toke Høiland-Jørgensen 
You can add:
Signed-off-by: Felix Fietkau 

- Felix

Re: [1/1] mwifiex: key_material_v2 remove superfluous condition

2016-09-03 Thread Kalle Valo

Heinrich Schuchardt  wrote:
> We are using mac as source address in a memcpy.
> In the lines below we can assume mac is not NULL.
> 
> Signed-off-by: Heinrich Schuchardt 
> Acked-by: Amitkumar Karwar 

Thanks, 1 patch applied to wireless-drivers-next.git:

b0d80f19c14f mwifiex: key_material_v2 remove superfluous condition

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9253367/

Re: [v4] brcmfmac: add missing header dependencies

2016-09-03 Thread Kalle Valo

Baoyou Xie  wrote:
> We get 1 warning when building kernel with W=1:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning: 
> no previous prototype for '__brcmf_err' [-Wmissing-prototypes]
> 
> In fact, this function is declared in brcmfmac/debug.h, so this patch
> adds missing header dependencies.
> 
> Signed-off-by: Baoyou Xie 
> Acked-by: Arnd Bergmann 

Thanks, 1 patch applied to wireless-drivers-next.git:

8af92af3f2d5 brcmfmac: add missing header dependencies

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9303939/

Re: mwifiex: fix missing break on IEEE80211_STYPE_ACTION case

2016-09-03 Thread Kalle Valo

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> The IEEE80211_STYPE_ACTION case is missing a break in the switch
> statement, causing it to fall through to the default case that
> reports a debug message about an unknown frame subtype. Fix this
> by adding in the missing break statement.
> 
> Signed-off-by: Colin Ian King 

Thanks, 1 patch applied to wireless-drivers-next.git:

d393be3ed0be mwifiex: fix missing break on IEEE80211_STYPE_ACTION case

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9283755/

Re: rt2x00usb: Fix error return code

2016-09-03 Thread Kalle Valo

Christophe Jaillet  wrote:
> We know that 'retval = 0' because it has been tested a few lines above.
> So, if 'devm_kmalloc' fails, 0 will be returned instead of an error code.
> Return -ENOMEM instead.
> 
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
> Signed-off-by: Christophe JAILLET 
> Acked-by: Stanislaw Gruszka 

Thanks, 1 patch applied to wireless-drivers-next.git:

410280bac622 rt2x00usb: Fix error return code

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9275379/

Re: [1/3] mwifiex: correct aid value during tdls setup

2016-09-03 Thread Kalle Valo

Amitkumar Karwar  wrote:
> From: Xinming Hu 
> 
> AID gets updated during TDLS setup, but modified value isn't reflected
> in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is
> fixed here.
> 
> Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 

Thanks, 3 patches applied to wireless-drivers-next.git:

b64db1b252e9 mwifiex: correct aid value during tdls setup
41960b4dfdfc mwifiex: add CHAN_REGION_CFG command
72539799104d mwifiex: add custom regulatory domain support

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9271429/

Re: [1/2] mwifiex: fix the length parameter of a memset

2016-09-03 Thread Kalle Valo

Christophe Jaillet  wrote:
> In 'mwifiex_get_ver_ext', we have:
>struct mwifiex_ver_ext ver_ext;
> 
>memset(_ext, 0, sizeof(struct host_cmd_ds_version_ext));
> 
> This is likely that memset'ing sizeof(struct mwifiex_ver_ext) was expected.
> Remove the ambiguity by using the variable name directly instead of its
> type.
> 
> Signed-off-by: Christophe JAILLET 

Thanks, 2 patches applied to wireless-drivers-next.git:

ba852018d493 mwifiex: fix the length parameter of a memset
6a1622000ac9 mwifiex: simplify length computation for some memset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9266889/

Re: [1/1,v2] rtlwifi: remove superfluous condition

2016-09-03 Thread Kalle Valo

Heinrich Schuchardt  wrote:
> If sta == NULL, the changed line will not be reached.
> So no need to check that sta != NULL here.
> 
> Signed-off-by: Heinrich Schuchardt 
> Acked-by: Larry Finger 

Thanks, 1 patch applied to wireless-drivers-next.git:

f898005ff99f rtlwifi: remove superfluous condition

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9260253/

Re: wl3501_cs: Add spinlock to wl3501_reset

2016-09-03 Thread Kalle Valo

Pavel Andrianov  wrote:
> Likely wl3501_reset should acquire spinlock as wl3501_{open, close}.
> One of calls of wl3501_reset has been already protected.
> The others were unprotected and might lead to a race condition.
> The patch adds spinlock into the wl3501_reset and removes it from 
> wl3501_tx_timeout.
> 
> Found by Linux Driver Verification project (linuxtesting.org)
> 
> Signed-off-by: Pavel Andrianov 
> Acked-by: Vaishali Thakkar 

Thanks, 1 patch applied to wireless-drivers-next.git:

bd6b0242652a wl3501_cs: Add spinlock to wl3501_reset

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9255415/

Re: [1/1] mwifiex: remove superfluous condition

2016-09-03 Thread Kalle Valo

Heinrich Schuchardt  wrote:
> for_each_property_of_node is only executed if the
> property prop is not NULL.
> 
> Signed-off-by: Heinrich Schuchardt 
> Acked-by: Amitkumar Karwar 

Thanks, 1 patch applied to wireless-drivers-next.git:

2f69e67058fb mwifiex: remove superfluous condition

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9253329/

Re: ath5k: fix EEPROM dumping via debugfs

2016-09-03 Thread Kalle Valo

Sergey Ryazanov  wrote:
> EEPROM size calculated in 16-bit words, so we should take into account
> this fact during buffer allocation.
> 
> CC: Jiri Slaby 
> CC: Nick Kossifidis 
> CC: Luis R. Rodriguez 
> Signed-off-by: Sergey Ryazanov 

Thanks, 1 patch applied to wireless-drivers-next.git:

af8a9a67c346 ath5k: fix EEPROM dumping via debugfs

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9255675/

Re: bcma: support BCM53573 series of wireless SoCs

2016-09-03 Thread Kalle Valo

Rafał Miłecki wrote:
> BCM53573 seems to be the first series of Northstar family with wireless
> on the chip. The base models are BCM53573-s (A0, A1) and there is also
> BCM47189B0 which seems to be some small modification.
> 
> The only problem with these chipsets seems to be watchdog. It's totally
> unavailable on 53573A0 / 53573A1 and preferable PMU watchdog is broken
> on 53573B0 / 53573B1.
> 
> Signed-off-by: Rafał Miłecki 

Thanks, 1 patch applied to wireless-drivers-next.git:

3f37ec79dd21 bcma: support BCM53573 series of wireless SoCs

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9246319/

Re: [v2, 1/8] mwifiex: Fixed endianness problem for big endian platform

2016-09-03 Thread Kalle Valo

Amitkumar Karwar  wrote:
> From: Karthik D A 
> 
> The driver sends and recives information to and from the firmware.
> Correct endianness should be ensured as firmware follows little
> endian format and host can be little/big endian.
> 
> Signed-off-by: Karthik D A 
> Signed-off-by: Amitkumar Karwar 

Thanks, 8 patches applied to wireless-drivers-next.git:

902831a7629b mwifiex: Fixed endianness problem for big endian platform
e5988c62b9e6 mwifiex: add region code information in debugfs
c8ccf3ade785 mwifiex: fix failed to reconnect after interface disabled/enabled
c2a8f0ff9c6c mwifiex: support random MAC address for scanning
99ffe72cdae4 mwifiex: process rxba_sync event
5536c4aafcac mwifiex: remove misleading disconnect message
432da7d243da mwifiex: add HT aggregation support for adhoc mode
441756b6a6e3 mwifiex: fix radar detection issue

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9245981/

Re: hostap: Use memdup_user() to reuse code

2016-09-03 Thread Kalle Valo

Rajan Vaja  wrote:
> Fix coccicheck warning which recommends to
> use memdup_user() instead of reimplementing its
> code.
> 
> This patch fixes below coccicheck warnings:
> 
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3044:9-16: WARNING
> opportunity for memdup_user
> drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3806:9-16: WARNING
> opportunity for memdup_user
> 
> Signed-off-by: Rajan Vaja 
> Reviewed-by: Julian Calaby 

Thanks, 1 patch applied to wireless-drivers-next.git:

8432ebd66205 hostap: Use memdup_user() to reuse code

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9241109/

Re: [-next] wlcore: spi: fix non static symbol warning

2016-09-03 Thread Kalle Valo

Wei Yongjun  wrote:
> Fixes the following sparse warning:
> 
> drivers/net/wireless/ti/wlcore/spi.c:87:34: warning:
>  symbol 'wilink_data' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun 

Thanks, 1 patch applied to wireless-drivers-next.git:

4ad0579a28c0 wlcore: spi: fix non static symbol warning

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9243695/

45 matches

Mail list logo