drivers/staging/ks7010 hardware test

Hi Wolfram, I began testing the card you sent today. I'm getting a firmware load error like you mentioned. I checked out code from when you originally merged into staging, however I built the module in a 4.9 kernel. To help me track down the issue could you please tell me what testing you

[PATCH 01/14] mwifiex: pcie: properly synchronize, disable interrupts in driver callbacks

It seems that the implicit assumption of the mwifiex {enable,disable}_int() callbacks is that after ->disable_int(), all interrupt handling should be complete (synchronized) and not fire again until after ->enable_int(). Also, interrupts should not be serviced until after the first ->enable_int().

[PATCH 07/14] mwifiex: fixup init_channel_scan_gap error case

In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/main.c | 3 ++- 1 file changed, 2

[PATCH 02/14] mwifiex: reunite copy-and-pasted remove/reset code

When PCIe FLR code was added, it explicitly copy-and-pasted much of mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary, as almost all of the code should be reused. Let's reunite what we can for now. The only functional changes for now: * call netif_device_detach() in the

[PATCH 10/14] mwifiex: pcie: stop masking interrupts in FW downloader

The upper layers already have disabled our interrupts (haven't called ->enable_int() yet for probe(), and we call ->disable_int() before trying to reset), so this is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 6 -- 1

[PATCH 11/14] mwifiex: utilize netif_tx_{wake,stop}_all_queues()

We're open-coding these. Just use the helpers. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/init.c | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/init.c

[PATCH 03/14] mwifiex: reset interrupt status across device reset

When resetting the device, we might have queued up interrupts that didn't get a chance to finish processing. We really don't need to handle them at this point; we just want to make sure they don't cause us to try to process old commands from before the device was reset. Signed-off-by: Brian

[PATCH 04/14] mwifiex: pcie: don't allow cmd buffer reuse after reset

In rogue cases (due to other bugs) it's possible we try to process an old command response *after* resetting the device. This could trigger a double-free (or the SKB can get reallocated elsewhere...causing other memory corruptions) in mwifiex_pcie_process_cmd_complete(). For safety (and symmetry)

[PATCH 12/14] mwifiex: don't open-code ARRAY_SIZE()

Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +--- drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 ++-- drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 5 ++--- 3 files changed, 5 insertions(+), 12 deletions(-)

[PATCH 05/14] mwifiex: re-register wiphy across reset

In general, it's helpful to use the same code for device removal as for device reset, as this tends to have fewer bugs. Let's move the wiphy unregistration code into the common reset and removal code. In particular, it's very hard to properly handle the reset sequence when something fails.

[PATCH 09/14] mwifiex: pcie: remove redundant synchronize_irq()

free_irq() already calls synchronize_irq() in a non-racy manner. Calling synchronize_irq() here is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 13/14] mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()

It's always called with 'true' -- we only determine it 'false' locally within this function. So drop the parameter. Also, this should be 'bool' (since we use true/false), not 'u32'. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5

[PATCH 06/14] mwifiex: don't short-circuit netdev notifiers on interface deletion

When we leave the delete interface function, there are still netdev hooks that might try to process the device. We're short-circuiting some of that by changing the interface type and clearing ieee80211_ptr. This means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is currently a

[PATCH 08/14] mwifiex: ensure "disable auto DS" struct is initialized

The .idle_time field *should* be unused, but technically, we're allowing unitialized stack garbage to pass all the way through to the firmware host command. Let's zero it out instead. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 6

[PATCH 14/14] mwifiex: pcie: fix whitespace

This keeps annoying me. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index

Re: WPA and WPA2

On Wed, May 24, 2017 at 11:44:00AM -0500, Dan Williams wrote: > On Wed, 2017-05-24 at 17:34 +1000, Tobin C. Harding wrote: > > On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote: > > > Hi, > > > > > > I am attempting to rewrite the ks7010 WEXT driver > > > (drivers/staging/ks7010) >

Re: WPA and WPA2

On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote: > Just a small correction: > > On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote: > > > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused. > > PTK and GTK, and in theory you could have more than two GTKs but that's

Re: pull-request: mac80211 2017-05-23

From: Johannes Berg Date: Tue, 23 May 2017 14:42:55 +0200 > I have just two fixes here, one of the scheduled scan issue that > Sander Eikelenboom found, and the other properly makes mesh more > strictly check its extension headers. > > Please pull and let me know if

Re: WPA and WPA2

Just a small correction: On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote: > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused. PTK and GTK, and in theory you could have more than two GTKs but that's not usually done. > Because WEXT is pretty convoluted, I woudn't necessarily

Re: [PATCH] nfc: Fix the sockaddr length sanitization in llcp_sock_connect

On Wed, May 24, 2017 at 3:26 AM, Mateusz Jurczyk wrote: > Fix the sockaddr length verification in the connect() handler of NFC/LLCP > sockets, to compare against the size of the actual structure expected on > input (sockaddr_nfc_llcp) instead of its shorter version

Re: WPA and WPA2

On Wed, 2017-05-24 at 17:34 +1000, Tobin C. Harding wrote: > On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote: > > Hi, > > > > I am attempting to rewrite the ks7010 WEXT driver > > (drivers/staging/ks7010) > > to use the CFG80211 API. > > > > I am reading 802.11 Wireless Networks

Re: [01/10] rtlwifi: btcoex: 23b 1ant: Special packets statistic in notification

Larry Finger wrote: > From: Ping-Ke Shih > > Count and log special packets of DHCP, EAPOL and ARP, and check whether > the interface is in 4-way handshake. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: Larry Finger

Re: [01/10] rtlwifi: btcoex: 23b 1ant: Switch antenna to wifi or BT.

Larry Finger wrote: > From: Ping-Ke Shih > > Since wifi and BT share the same physical antenna, we should switch antenna > to fit every situation. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: Larry Finger

Re: [v2] rt2x00: Add device ID for Epson WN7512BEP

Tom Gaudasinski wrote: > Make Epson WN7512BEP work by adding its device-id to rt2800usb. Device > contains a Ralink RT3071L, registers as vendor Accton/Arcadyan. > > Signed-off-by: Tom Gaudasinski Patch applied to

Re: ssb: Delete an error message for a failed memory allocation in ssb_devices_register()

SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 17 May 2017 18:12:16 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > >

Re: [v2, 01/10] rt2x00: change function pointers for register accessors

Arnd Bergmann wrote: > This prepares the driver for changing all the 'read' register accessors > to return the value instead of passing it by reference. Since a lot > of them are used in callbacks, this takes care of the callbacks first, > adding a couple of helpers that will be

Re: libertas: Remove function entry/exit debugging

Kees Cook wrote: > In at least one place, the enter/exit debugging was not being correctly > matched. Based on mailing list feedback, it was desired to drop all of > these in favor of using ftrace instead. > > Suggested-by: Joe Perches > Suggested-by:

Re: [v3] libertas: Avoid reading past end of buffer

Kees Cook wrote: > Using memcpy() from a string that is shorter than the length copied means > the destination buffer is being filled with arbitrary data from the kernel > rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN > sizes, like other drivers.

Re: [v2] iwlegacy: warn when enabling power save

Stanislaw Gruszka wrote: > iwlegacy firmware can crash when power save is configured. PS was > allowed in "dbdac2b iwlegacy: properly enable power saving" with belive > that user who enable PS is aware of that and can relate firmware crahes > with PS. However some

Re: wlcore: fix 64K page support

Arnd Bergmann wrote: > In the stable linux-3.16 branch, I ran into a warning in the > wlcore driver: > > drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write': > drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 > bytes is larger than

Re: [PATCHv4] wlcore: add wl1285 compatible

Sebastian Reichel wrote: > Motorola Droid 4 uses a WL1285C. With differences between the > chips not being public let's add explicit binding for wl1285 > instead of relying on wl1283 being very similar. > > Reviewed-by: Rob Herring > Acked-by:

Re: rsi: rsi_91x_core: Use time_after time comparison

Karim Eshapa wrote: > Use time_after kernel macro for time comparison. > > Signed-off-by: Karim Eshapa Patch applied to wireless-drivers-next.git, thanks. c07036f18d93 rsi: rsi_91x_core: Use time_after time comparison --

Re: [v3,01/11] rsi: Rename file rsi_91x_pkt.c to rsi_91x_hal.c

amit karwar wrote: > From: Prameela Rani Garnepudi > > The file rsi_91x_hal.c is going to contain device specific code i.e new > firmware loading method for RS9113 chipset. As the file rsi_91x_pkt.c > contains code to prepare device specific

Re: brcmfmac: brcm43430 Invalid mailbox value issue

On 24 May 2017 at 14:13, Arend van Spriel wrote: > On 24-05-17 14:50, James Hughes wrote: >> We are seeing an issue on Raspberry Pi which uses the bcm43430 chip. It's >> been tested up to 4.9 which still shows the issue (it's been there for some >> time, > 1yr). I'm

Re: brcmfmac: brcm43430 Invalid mailbox value issue

On 24-05-17 14:50, James Hughes wrote: > We are seeing an issue on Raspberry Pi which uses the bcm43430 chip. It's > been tested up to 4.9 which still shows the issue (it's been there for some > time, > 1yr). I'm trying to find someone who can test on 4.11 as I cannot > replicate (The latest

brcmfmac: brcm43430 Invalid mailbox value issue

(Plain text resend) We are seeing an issue on Raspberry Pi which uses the bcm43430 chip. It's been tested up to 4.9 which still shows the issue (it's been there for some time, > 1yr). I'm trying to find someone who can test on 4.11 as I cannot replicate (The latest kernel we have that works on a

brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

Hi, I've crippled a Raspberry Pi 3 (1 core, 200 MHz) and observed that the glomming feature has a definite impact on TX performance, but it looks like at this CPU frequency, the work queue is solicited "too often" by brcmf_sdio_trigger_dpc() and glomming is only doing 4 packets at once,

Re: [PATCH v6] qtnfmac: introduce new FullMAC driver for Quantenna chipsets

> > IIRC the idea was to use 'send_probe_response' for now and then to > > implement the use of NL80211_RXMGMT_FLAG_ANSWERED flag in hostapd, at > > least for probe requests for the start. But it definitely doesn't > > make sense if you plan to get rid of this flag in the long run. > > No no! I'm

Re: WPA and WPA2

On Wed, 2017-05-24 at 20:13 +1000, Tobin C. Harding wrote: > For this driver I think it matters. It is not a soft MAC driver, but > it is not a Full MAC either. The firmware was released in 2009, I > don't imagine it is getting any updates. The WEXT driver adds/checks > the TKIP Michael MIC in

[PATCH] nfc: Fix the sockaddr length sanitization in llcp_sock_connect

Fix the sockaddr length verification in the connect() handler of NFC/LLCP sockets, to compare against the size of the actual structure expected on input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc). Both structures are defined in include/uapi/linux/nfc.h. The fields specific

Re: WPA and WPA2

On Wed, May 24, 2017 at 09:40:51AM +0200, Johannes Berg wrote: > On Wed, 2017-05-24 at 17:27 +1000, Tobin C. Harding wrote: > > > I am attempting to rewrite the ks7010 WEXT driver > > (drivers/staging/ks7010) to use the CFG80211 API. > > Heh, I wasn't even aware of this driver yet. Thanks for

Re: rtlwifi: fix REG_USTIME_TSF register definition

Kevin Lo wrote: > The REG_USTIME_TSF (US Time Tuning for TSF) definition of Realtek chips > should be 0x55C. > > Signed-off-by: Kevin Lo Larry, is this ok to take? -- https://patchwork.kernel.org/patch/9737421/

Re: [v3 10/11] rsi: Add new firmware loading method

Amitkumar Karwar writes: > From: Prameela Rani Garnepudi > > The older firmware loading method has been deprecated and not in use > for any chipets. New method is introduced which works based on soft > boot loader. In this method, complete RAM

Re: [Linux-4.9.28] iwlwifi 6230 AGN: Microcode SW error detected

On Wed, 2017-05-24 at 10:15 +0200, Sedat Dilek wrote: > On Wed, May 24, 2017 at 9:57 AM, Luca Coelho wrote: > > On Wed, 2017-05-24 at 09:41 +0200, Sedat Dilek wrote: > > > Hi, > > > > Hi Sedat, > > > > > > > I am seeing the below/following in my logs today. > > > My AP is a

Re: [Linux-4.9.28] iwlwifi 6230 AGN: Microcode SW error detected

On Wed, May 24, 2017 at 9:57 AM, Luca Coelho wrote: > On Wed, 2017-05-24 at 09:41 +0200, Sedat Dilek wrote: >> Hi, > > Hi Sedat, > > >> I am seeing the below/following in my logs today. >> My AP is a Lenovo Moto-Z with LTE support. >> >> Can you comment on this? >> Is this a

Re: [Linux-4.9.28] iwlwifi 6230 AGN: Microcode SW error detected

On Wed, 2017-05-24 at 09:41 +0200, Sedat Dilek wrote: > Hi, Hi Sedat, > I am seeing the below/following in my logs today. > My AP is a Lenovo Moto-Z with LTE support. > > Can you comment on this? > Is this a "buggy" firmware and a new firmware around? Looks like a buggy firmware, but

Re: WPA and WPA2

On Wed, 2017-05-24 at 17:27 +1000, Tobin C. Harding wrote: > I am attempting to rewrite the ks7010 WEXT driver > (drivers/staging/ks7010) to use the CFG80211 API. Heh, I wasn't even aware of this driver yet. > As I understand, first there was WEP. Correct. > Next we got a marketing term WPA

Re: WPA and WPA2

On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote: > Hi, > > I am attempting to rewrite the ks7010 WEXT driver (drivers/staging/ks7010) > to use the CFG80211 API. > > I am reading 802.11 Wireless Networks - Matthew S. Gast for reference. > > I have some confusion regarding

WPA and WPA2

Hi, I am attempting to rewrite the ks7010 WEXT driver (drivers/staging/ks7010) to use the CFG80211 API. I am reading 802.11 Wireless Networks - Matthew S. Gast for reference. I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and ie's? As I understand, first there was WEP. Next we

Re: [PATCH v6] qtnfmac: introduce new FullMAC driver for Quantenna chipsets

> Hostapd registers for acton frames and probe requests. In our case > probe responses are sent by firmware. However hostapd needs to look > at them anyway in certain usecases. Bug hostapd doesn't try to > respond to probe requests when option 'send_probe_response = 0' is > set in hostapd config.

[RFC] skbuff: introduce skb_put_zero()

From: Johannes Berg This pattern was introduced a number of times in mac80211 just now, and since it's present in a number of other places it makes sense to add a little helper for it. The transformations of all code were done with the following spatch: @@ identifier

Re: [PATCH v2 0/2] extend mac80211 mesh DFS and CSA functionality

On Tue, 2017-05-23 at 17:00 +0200, Simon Wunderlich wrote: > This patchset includes the remaining two patches for the CSA > handling, with Johannes change suggestions integrated. Applied, thanks for respinning. I made a small change and removed the return from ieee80211_ie_build_wide_bw_cs()