Re: [PATCH v3 09/10] rtlwifi: use debugfs to debug.

Hi Ping-Ke, [auto build test WARNING on wireless-drivers-next/master] [also build test WARNING on next-20170630] [cannot apply to v4.12-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Larry

[PATCH] rtlwifi: fix simple_open.cocci warnings

drivers/net/wireless/realtek/rtlwifi/debug.c:398:11-27: WARNING opportunity for simple_open, see also structure on line 418 Remove an open coded simple_open() function and replace file operations references to the function with simple_open() instead. Generated by:

Re: [PATCH] bcma: gpio: Correct number of GPIOs for BCM53573

On 30 June 2017 at 21:02, Florian Fainelli wrote: > Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16. > > Fixes: 3f37ec79dd21 ("bcma: support BCM53573 series of wireless SoCs") > Signed-off-by: Florian Fainelli Looks good.

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 23-06-17 23:53, Luis R. Rodriguez wrote: > On Tue, May 16, 2017 at 10:41:08AM +0200, Arend Van Spriel wrote: >> On 16-5-2017 1:13, Luis R. Rodriguez wrote: >>> Since no upstream delta is needed for firmwared I'd like to first encourage >>> evaluating the above. While distributions don't carry

[PATCH] bcma: gpio: Correct number of GPIOs for BCM53573

Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16. Fixes: 3f37ec79dd21 ("bcma: support BCM53573 series of wireless SoCs") Signed-off-by: Florian Fainelli --- drivers/bcma/driver_gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bcma/driver_gpio.c

RE: [EXT] Re: [PATCH] mwifiex: correct channel stat buffer overflows

Hi Brian, > -- > On Thu, Jun 29, 2017 at 06:23:54PM -0700, Brian Norris wrote: > > mwifiex records information about various channels as it receives > scan > > information. It does this by appending to a buffer that was sized to

Re: [PATCH] mwifiex: correct channel stat buffer overflows

On Thu, Jun 29, 2017 at 06:23:54PM -0700, Brian Norris wrote: > mwifiex records information about various channels as it receives scan > information. It does this by appending to a buffer that was sized > to the max number of supported channels on any band, but there are > numerous problems: > >

WARN_ON_ONCE(work > weight) in napi_poll()

I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with ath10k card. [37207.593370] [ cut here ] [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274 net_rx_action+0x258/0x360 [37207.593381] Modules linked in: snd_hda_codec_realtek

Re: pull-request: iwlwifi-next 2017-06-30

On Fri, 2017-06-30 at 14:04 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > Hi Kalle, > > > > Here's my final pull-request intended for v4.13.  Again, this pull- > > request includes the last two patchsets I sent out.  Most importantly, > > it contains critical fixes and FW

Re: pull-request: iwlwifi-next 2017-06-30

Luca Coelho writes: > Hi Kalle, > > Here's my final pull-request intended for v4.13.  Again, this pull- > request includes the last two patchsets I sent out.  Most importantly, > it contains critical fixes and FW API changes to support the upcoming FW > that we will release

[PATCH] staging: wilc1000: fix a typo: "incative" -> "inactive"

From: Colin Ian King Trivial fix to typos in netdev_err error messages. I should have spotted this in a previous round of spelling mistake checks on this driver but this one slipped through. Signed-off-by: Colin Ian King ---

pull-request: iwlwifi-next 2017-06-30

Hi Kalle, Here's my final pull-request intended for v4.13.  Again, this pull- request includes the last two patchsets I sent out.  Most importantly, it contains critical fixes and FW API changes to support the upcoming FW that we will release publicly for the 9000 HW family.  More details in the

[PATCH][-next] rtlwifi: kfree entry until after entry->bssid has been accessed

From: Colin Ian King The current code kfree's entry and then dereferences it by accessing entry->bssid. Avoid the dereference-after-free by moving the kfree after the access to entry->bssid. Detected by CoverityScan, CID#1448600 ("Read from pointer after free")

[GIT] [4.13] NFC update

Hi David, This is the NFC pull request for 4.13. We have: - A conversion to unified device and GPIO APIs for the fdp, pn544, and st{21,-nci} drivers. - A fix for NFC device IDs allocation. - A fix for the nfcmrvl driver firmware download mechanism. - A trf7970a DT and GPIO cleanup and clock

[PATCH v3] rtlwifi: Replace hardcode value with macro

In _rtl_init_mac80211(), hardcoded value for hw->max_listen_interval and hw->max_rate_tries are replaced by macro. Signed-off-by: Souptick Joarder --- drivers/net/wireless/realtek/rtlwifi/base.c | 6 +++--- drivers/net/wireless/realtek/rtlwifi/base.h | 2 ++ 2 files

[bug report] rtlwifi: Add rx ampdu cfg for btcoexist.

Hello Ping-Ke Shih, The patch 2635664e6e4a: "rtlwifi: Add rx ampdu cfg for btcoexist." from Jun 18, 2017, leads to the following static checker warning: drivers/net/wireless/realtek/rtlwifi/base.c:1664 rtl_rx_ampdu_apply() error: uninitialized symbol 'reject_agg'.

Re: rfkill(8) move and improvements

On Thu, Jun 29, 2017 at 10:23:12PM +0100, Sami Kerola wrote: > On 29 June 2017 at 15:04, Johannes Berg wrote: > >> The otherday I ran powertop and it did rfkill to save battery, which > >> was particularly annoying because I had not installed rfkill(8) > >> package. >

Re: mwifiex: do not update MCS set from hostapd

Ganapathi Bhat wrote: > We should not copy the MCS set from hostapd RX-STBC. We > have to just use the MCS set supported by the hardware. > This fixes an issue, where mwifiex is advertising wrong > MCS sets in beacons. > > Fixes: 474a41e94dfc ("mwifiex: update MCS set as per

Re: ieee80211: update public action codes

Peter Oh wrote: > From: Peter Oh > > Update Public Action field values as updated in IEEE Std 802.11-2016, > so that modules/drivers can refer it. > > Signed-off-by: Peter Oh > Reviewed-by: Johannes Berg

Re: [v2] nl80211: Don't verify owner_nlportid on NAN commands

Luciano Coelho wrote: > From: Andrei Otcheretianski > > If NAN interface is created with NL80211_ATTR_SOCKET_OWNER, the socket > that is used to create the interface is used for all NAN operations and > reporting NAN events. > However, it turns

Re: [V3, 6/9] brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK

Arend Van Spriel wrote: > From: Arend van Spriel > > The firmware may have supplicant code built-in. This is detected > by the driver and indicated in the wiphy features flags. User-space > can use this flag to determine whether or not to

Re: [V3, 6/9] brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK

Arend Van Spriel wrote: > From: Arend van Spriel > > The firmware may have supplicant code built-in. This is detected > by the driver and indicated in the wiphy features flags. User-space > can use this flag to determine whether or not to

pull-request: wireless-drivers-next 2017-06-30

Hi Dave, here's a pull request to net-next for 4.13. Actually not really that big this time, more info in the signed tag below. Please let me know if you have any problems. Intel has new hardware coming up and they just submitted patches to iwlwifi supporting that, but because the patches were