Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On 2017/1/13 13:29, Matt Ranostay wrote: Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

Cc: devicet...@vger.kernel.org Signed-off-by: Matt Ranostay --- .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++ .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- 2 files changed, 20 insertions(+), 1 deletion(-)

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787

Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay wrote: > Allow power sequencing for the Marvell SD8787 Wifi/BT chip. > This can be abstracted to other chipsets if needed in the future. Er crap seems how the main patch file got dropped out. Resubmitting in a minute...

[PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Matt Ranostay (2): devicetree: document vmmc-supply and mmc-pwrseq options mmc: pwrseq: add support for Marvell SD8787 chip

[PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options

Cc: devicet...@vger.kernel.org Signed-off-by: Matt Ranostay --- Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt

[PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig | 10

[RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

Hi! In preparation to be submitted upstream I started to clean up a huge pile of patches for rt2x00 we have been carrying along for quite a while (some for more than half a decade!). Some of them are fixes, most importantly Serge Vasilugin fixed setting the HT20/HT40 filter which got us much

linux-next: build warning after merge of the wireless-drivers-next tree

Hi all, After merging the wireless-drivers-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove': drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status' may be used

[PATCH 4/4] cfg80211: Fix documentation for connect result

The function documentation for cfg80211_connect_bss() and cfg80211_connect_result() was still claiming that they are used only for a success case while these functions can now be used to report both success and various failure cases. The actual use cases were already described in the connect()

[PATCH v2 3/4] cfg80211: Specify the reason for connect timeout

From: Purushottam Kushwaha This enhances the connect timeout API to also carry the reason for the timeout. These reason codes for the connect time out are represented by enum nl80211_timeout_reason and are passed to user space through a new attribute

[PATCH v3 1/4] cfg80211: Add support to randomize TA of Public Action frames

From: vamsi krishna Add support to use a random local address (Address 2 = TA in transmit and the same address in receive functionality) for Public Action frames in order to improve privacy of WLAN clients. Applications fill the random transmit address in the frame

[PATCH v4 2/4] cfg80211: Add support to sched scan to report better BSSs

From: vamsi krishna Enhance sched scan to support option of finding a better BSS while in connected state. Firmware scans the medium and reports when it finds a known BSS which has better RSSI than the current connected BSS. New attributes to specify the relative RSSI

[PATCH 2/2] mwifiex: pcie: don't delay for sleep cookie when not required

Wifi modules like 8997 don't support the "sleep cookie", and so most of the time, we just time out in the mwifiex_delay_for_sleep_cookie() function ("max count reached while accessing sleep cookie"). This is a waste of time, and we should skip it for modules without the sleep cookie flag.

[PATCH 1/2] mwifiex: pcie: use posted write to wake up firmware

Depending on system factors (e.g., the PCIe link PM state), the first read to wake up the Wifi firmware can take a long time. There is no reason to use a (blocking, non-posted) read at this point, so let's just use a write instead. Write vs. read doesn't matter functionality-wise -- it's just a

Re: [PATCH v2 12/13] wil6210: set dma mask to reflect device capability

On 2017-01-12 15:06, Maya Erez wrote: From: Hamad Kadmany 11ad device supports 48 bit addresses, reflect that by setting the dma mask accordingly. Signed-off-by: Hamad Kadmany Signed-off-by: Maya Erez

Re: [PATCH] mac80211: prevent skb/txq mismatch

Yay! This sounds like a potential fix for this? https://bugs.lede-project.org/index.php?do=details_id=368 Are all the ath10k chipsets excluded by commit: 4ca1807815aa6801aaced7fdefa9edacc2521767 Still needed to be excluded?

Re: [PATCH] mac80211: prevent skb/txq mismatch

On 2017-01-12 15:28, Michal Kazior wrote: > Station structure is considered as not uploaded > (to driver) until drv_sta_state() finishes. This > call is however done after the structure is > attached to mac80211 internal lists and hashes. > This means mac80211 can lookup (and use) station >

[PATCH] Revert "bcma: init serial console directly from ChipCommon code"

From: Rafał Miłecki This reverts commit 4c81acab3816 ("bcma: init serial console directly from ChipCommon code") as it broke IRQ assignment. Getting IRQ with bcma_core_irq helper on SoC requires MIPS core to be set. It happens *after* ChipCommon initialization so we can't do

Re: [PATCH] ath10k: prevent sta pointer rcu violation

On 12 January 2017 at 16:46, Johannes Berg wrote: > On Thu, 2017-01-12 at 16:14 +0100, Michal Kazior wrote: >> Station pointers are RCU protected so driver must >> be extra careful if it tries to store them >> internally for later use outside of the RCU >> section it

Re: [PATCH] ath10k: prevent sta pointer rcu violation

On Thu, 2017-01-12 at 16:14 +0100, Michal Kazior wrote: > Station pointers are RCU protected so driver must > be extra careful if it tries to store them > internally for later use outside of the RCU > section it obtained it in. > > It was possible for station teardown to race with > some htt

[PATCH] ath10k: prevent sta pointer rcu violation

Station pointers are RCU protected so driver must be extra careful if it tries to store them internally for later use outside of the RCU section it obtained it in. It was possible for station teardown to race with some htt events. The possible outcome could be a use-after-free and a crash. Only

Re: [next] rtlwifi: rtl8192de: fix missing curly braces

Vincent wrote: > Restore some curly braces that have been removed in commit c93ac39da006457f > ("rtlwifi: Remove some redundant code") while removing redundant messages > and extraneous braces. > > This fixes the following smatch warning: > >

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

On Thu, Jan 12, 2017 at 03:32:20PM +0100, Johannes Berg wrote: > > > We don't.. This discussion here is about the C API where we cannot > > remove the argument from the call without adding yet another inline > > wrapper, but the actual function that generates the netlink message > > does not add

Re: mwifiex: don't include mac80211.h

Johannes Berg wrote: > From: Johannes Berg > > This driver doesn't use mac80211, so it shouldn't include mac80211.h, > include only the necessary cfg80211.h instead. > > Signed-off-by: Johannes Berg Depends on:

Re: [PATCH] mac80211: prevent skb/txq mismatch

On Thu, Jan 12, 2017 at 03:51:20PM +0100, Johannes Berg wrote: > On Thu, 2017-01-12 at 20:15 +0530, Mohammed Shafi Shajakhan wrote: > > > > > Reported-by: Mohammed Shafi Shajakhan > > > Signed-off-by: Michal Kazior > > > > Signed-off-by:

Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c

Amitkumar Karwar writes: >> But these didn't. Can you please rebase these and resubmit in one >> patchset? Less conflicts that way. >> > > The problem here is you tried to apply the patches in reverse order. Sorry > for the confusion. > Please apply pending patches in

Re: [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv

Amitkumar Karwar wrote: > From: Xinming Hu > > main_process is not expected to be running when shutdown_drv function > is called. currently we wait for main_process completion in the > function. > > Actually the caller has already made sure main_process

Re: [PATCH] mac80211: prevent skb/txq mismatch

On Thu, Jan 12, 2017 at 03:28:41PM +0100, Michal Kazior wrote: > Station structure is considered as not uploaded > (to driver) until drv_sta_state() finishes. This > call is however done after the structure is > attached to mac80211 internal lists and hashes. > This means mac80211 can lookup (and

Re: [PATCH] mac80211: prevent skb/txq mismatch

On Thu, 2017-01-12 at 20:15 +0530, Mohammed Shafi Shajakhan wrote: > > > Reported-by: Mohammed Shafi Shajakhan > > Signed-off-by: Michal Kazior > > Signed-off-by: Mohammed Shafi Shajakhan That makes no sense,

Re: mwifiex: use module_*_driver helper macros

Amitkumar Karwar wrote: > After user_rmmod global flag removal, *_init_module() and > *_cleanup_module() have become just a wrapper functions. > We will get rid of them with the help of module_*_driver() macros. > > For pcie, existing ".init_if" handler has same name as what

Re: [1/5] mwifiex: get rid of mwifiex_do_flr wrapper

Amitkumar Karwar wrote: > From: Xinming Hu > > This patch gets rid of mwifiex_do_flr. We will call > mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly. > These two general purpose functions will be useful for > sdio card reset handler. > >

Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c

Amitkumar Karwar wrote: > From: Xinming Hu > > Next patch in this series is going to use mwifiex_read_reg() in remove > handlers. The changes here are prerequisites to avoid forward > declarations. > > Signed-off-by: Xinming Hu >

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

> We don't.. This discussion here is about the C API where we cannot > remove the argument from the call without adding yet another inline > wrapper, but the actual function that generates the netlink message > does not add the timeout reason attribute for success or explicit > rejection cases.

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

On Thu, Jan 12, 2017 at 03:06:19PM +0100, Johannes Berg wrote: > On Thu, 2017-01-12 at 13:58 +, Malinen, Jouni wrote: > > > > > I think this description is misleading - one could easily > > > understand > > > "for other cases" to indicate for the cases that the AP did > > > explicitly > > >

[PATCH] mac80211: prevent skb/txq mismatch

Station structure is considered as not uploaded (to driver) until drv_sta_state() finishes. This call is however done after the structure is attached to mac80211 internal lists and hashes. This means mac80211 can lookup (and use) station structure before it is uploaded to a driver. If this

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

On Thu, 2017-01-12 at 13:58 +, Malinen, Jouni wrote: > > > I think this description is misleading - one could easily > > understand > > "for other cases" to indicate for the cases that the AP did > > explicitly > > reject it, but that's obviously not true. > > Well, the expectation here

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

On Wed, Jan 11, 2017 at 02:26:06PM +0100, Johannes Berg wrote: > On Wed, 2017-01-11 at 13:13 +, Malinen, Jouni wrote: > > > > > > @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct > > > > wireless_dev *wdev) > > > >   case CFG80211_CONN_AUTH_FAILED: > > > > +

Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout

On Wed, Jan 11, 2017 at 02:31:31PM +0100, Johannes Berg wrote: > > + * @timeout_reason: reason for connection timeout. This is used when > > the > > + * connection fails due to a timeout instead of an explicit > > rejection from > > + * the AP. 0 (NL80211_CONNECT_TIMEOUT_UNSPECIFIED) is used > >

RE: [PATCH v3 1/3] cfg80211: Add support to sched scan to report better BSSs

> -Original Message- > From: Johannes Berg [mailto:johan...@sipsolutions.net] > > > So you see a use-case for doing a scan with @relative_rssi being > > > zero, right? > > > > Yes. Zero value for relative_rssi is also valid. > > Or negative even, I guess? Yes, this can be negative

[PATCH v2 04/13] wil6210: remove __func__ from debug printouts

From: Lazar Alexei __func__ is automatically added to printouts by dynamic debug mechanism and by wil_info/wil_err macros. Remove __func__ from debug printouts to avoid duplication. Signed-off-by: Lazar Alexei Signed-off-by: Maya

[PATCH v2 01/13] wil6210: add sysfs file for FTM calibration

From: Lior David In fine timing measurements, the calculation is affected by 2 parts: timing of packets over the air, which is platform independent, and platform-specific delays, which are dependent on things like antenna cable length and type. Add a sysfs file which

[PATCH v2 00/13] wil6210 patches

The following set of patches include various wil6210 fixes Changes from V1: - Fix copyright year to 2017 - Add a patch to convert symbolic permissions to octal permissions to fix checkpatch errors and align to latest kernel preference - Fix "set dma mask to reflect device capability" commit

[PATCH v2 03/13] wil6210: support loading dedicated image for sparrow-plus devices

From: Lazar Alexei Driver may be used in platforms where some use sparrow cards while other use sparrow-plus cards, where different FW image is needed. Add the capability to load dedicated FW image in case sparrow-plus card is detected and fallback to default image

[PATCH v2 02/13] wil6210: add disable_ap_sme module parameter

From: Dedy Lansky By default, AP SME is handled by driver/FW. In case disable_ap_sme is true, driver doesn't turn-on WIPHY_FLAG_HAVE_AP_SME and the responsibility for AP SME is passed to user space. With AP SME disabled, driver reports assoc request frame to user

[PATCH v2 13/13] wil6210: convert symbolic permissions to octal permissions

Symbolic permissions are no longer recommended. This patch changes the symbolic permissions in wil6210 driver to octal permissions. Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/cfg80211.c | 2 +- drivers/net/wireless/ath/wil6210/debugfs.c | 128

[PATCH v2 05/13] wil6210: support new WMI-only FW capability

From: Dedy Lansky WMI_ONLY FW is used for testing in production. It cannot be used for scan/connect, etc. In case FW reports this capability, driver will not allow interface up. Signed-off-by: Dedy Lansky Signed-off-by: Maya Erez

[PATCH v2 11/13] wil6210: option to override A-BFT length in start AP/PCP

From: Lior David Add an option to specify and override the A-BFT length when starting an AP/PCP. See IEEE P802.11-2016, 10.38.5. The abft_len must be set before starting AP/PCP. It is only needed for diagnostics and certification. Signed-off-by: Lior David

[PATCH v2 07/13] wil6210: protect against false interrupt during reset sequence

From: Hamad Kadmany During reset sequence it is seen that device is generating an interrupt eventhough interrupts are masked at device level. Add workaround to disable the interrupts from host side during reset and clear any pending interrupts before re-enabling

[PATCH v2 12/13] wil6210: set dma mask to reflect device capability

From: Hamad Kadmany 11ad device supports 48 bit addresses, reflect that by setting the dma mask accordingly. Signed-off-by: Hamad Kadmany Signed-off-by: Maya Erez ---

[PATCH v2 10/13] wil6210: report association ID (AID) per station in debugfs

From: Lior David Add reporting of the association ID (AID) for each station as part of the stations file in the debugfs. Valid AID values are 1-254. 0 is reported if the AID is unknown or not reported by firmware. Signed-off-by: Lior David

[PATCH v2 09/13] wil6210: align to latest auto generated wmi.h

From: Lior David Align to latest version of the auto generated wmi file describing the interface with FW. Signed-off-by: Lior David Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/wmi.h | 45

[PATCH v2 08/13] wil6210: fix for broadcast workaround in PBSS

From: Lior David Currently we do not have full support for broadcast from a station inside a PBSS network. We have a workaround where instead of broadcast we do a unicast to every known station in the PBSS. This workaround was performed only for P2P clients. This fix

[PATCH v2 06/13] wil6210: missing reinit_completion in wmi_call

From: Lior David The code in wmi_call uses the wil->wmi_call completion structure to wait for a reply. In some scenarios, complete was called twice on the completion structure. This happened mainly with a disconnect event which can arrive both unsolicited and as a

Re: [PATCH 6/9] rt2800: fallback from mcs8 to mcs7

On 2017-01-06 14:05, Stanislaw Gruszka wrote: > If we do not fallback to lower rate, we are unable to calculate > correctly number of retries in TX status code. > > Signed-off-by: Stanislaw Gruszka I think falling back from the lowest dual-stream to the highest single-stream

Re: ath9k: fix spelling mistake: "meaurement" -> "measurement"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in ath_err message > > Signed-off-by: Colin Ian King Patch applied to ath-next branch of ath.git, thanks. 714ee339ff90 ath9k: fix

Re: [1/2] ath9k: ar9002_mac: kill off ACCESS_ONCE()

Mark Rutland wrote: > For several reasons, it is desirable to use {READ,WRITE}_ONCE() in > preference to ACCESS_ONCE(), and new code is expected to use one of the > former. So far, there's been no reason to change most existing uses of > ACCESS_ONCE(), as these aren't

Re: [1/2] ath10k: htc: Removal of unused struct members

Erik Stromdahl wrote: > Removed tx_credits_per_max_message and tx_credit_size > from struct ath10k_htc_ep since they are not used > anywhere in the code. > > They are just written, never read. > > Signed-off-by: Erik Stromdahl 2 patches

Re: ath5k: drop bogus warning on drv_set_key with unsupported cipher

Felix Fietkau wrote: > Simply return -EOPNOTSUPP instead. > > Cc: sta...@vger.kernel.org > Signed-off-by: Felix Fietkau Patch applied to ath-next branch of ath.git, thanks. a70e1d6fd6b5 ath5k: drop bogus warning on drv_set_key with unsupported cipher --

Re: net: wireless: ath: wil6210: constify cfg80211_ops structures

Bhumika Goyal wrote: > cfg80211_ops structures are only passed as an argument to the function > wiphy_new. This argument is of type const, so cfg80211_ops strutures > having this property can be declared as const. > Done using Coccinelle > > @r1 disable optional_qualifier @ >

Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()

Bjorn Andersson wrote: > The correct include file for getting errno constants and ERR_PTR() is > linux/err.h, rather than linux/errno.h, so fix the include. > > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled > smem_state") > Acked-by: Andy Gross

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Thursday, January 12, 2017 10:16:00 AM CET Johannes Berg wrote: > And I realized only now that this was a different place ... Right, it was a few hundred randconfigs later after I had confirmed that the first patch fixed all the configurations that were broken at first. > I've just added the

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

> Come to think of it, I'm thinking I should drop this patch and the > driver should just use iwe_stream_add_event() instead? It'll be > somewhat tricky to get the length correct though. No, turns out that's basically impossible with all the compat etc. stuff here. johannes

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote: > > > > Applied. Also fixed the typo in the subject :) > > Thanks! Unfortunately I now got another warning for the same > function, and though I would have expected the

Re: wl1251 & mac address & calibration data

Hi! > >> But overwriting that one file is not possible as it next update of > >> linux-firmware package will overwrite it back. It break any normal usage > >> of package management. > >> > >> Also it is ridiculously broken by design if some "boot" files needs to > >> be overwritten to

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote: > > > > Applied. Also fixed the typo in the subject :) > > Thanks! Unfortunately I now got another warning for the same > function, and though I would have expected the