* Re: [PATCH] brcmfmac: update beacon IE when bss up and clear when stopped
From: Kalle Valo @ 2016-11-16 14:03 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, pieterpg,
brcm80211-dev-list.pdl, linux-wireless, Chi-Hsien Lin,
wright.feng
In-Reply-To: <20161115022322.GA5611@cypress.com>
Wright Feng <wefe@cypress.com> writes:
> Firmware doesn't update beacon vendor IEs when bss is down, so move brcmf_config_ap_mgmt_ie after BSS up. And host driver should clear IEs when AP stopped so that the IEs in host side will be synced with in firmware side.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
Please word wrap the commit log, see Documentation/SubmittingPatches for
more info.
--
Kalle Valo
^ permalink raw reply
* Re: [05/10] rt2800: make ba_size depend on ampdu_factor
From: Kalle Valo @ 2016-11-16 13:59 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1478095865-8651-6-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> We can calculate BA window size (max number of pending frames not
> yet block acked) of remote station using Maximum A-MPDU length factor
> for that station.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Dropping as requested by Stanislaw.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9409241/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC 02/12] ath10k: htc: rx trailer lookahead support
From: Valo, Kalle @ 2016-11-16 13:53 UTC (permalink / raw)
To: Erik Stromdahl
Cc: michal.kazior@tieto.com, linux-wireless,
ath10k@lists.infradead.org
In-Reply-To: <ac58b3f6-4432-b0b6-8b50-c733f898eded@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> On 11/15/2016 10:57 AM, Michal Kazior wrote:
>> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> =
wrote:
>>> The RX trailer parsing is now capable of parsing lookahead reports.
>>> This is needed by SDIO/mbox.
>>=20
>> It'd be useful to know what exactly lookahead will be used for. What
>> payload does it carry.
>>=20
> It carries the 4 first bytes of the next RX message, i.e. the first 4
> bytes of an HTC header.
>
> It is used by the sdio interrupt handler to know if the next packet is a
> part of an RX bundle, which endpoint it belongs to and how long it is
> (so we know how many bytes to allocate).
Please add that to the commit log, it's useful information. Or maybe a
code comment would be better?
>>> +static int
>>> +ath10k_htc_process_lookahead(struct ath10k_htc *htc,
>>> + const struct ath10k_htc_lookahead_report *=
report,
>>> + int len,
>>> + enum ath10k_htc_ep_id eid,
>>> + u32 *next_lk_ahds,
>>=20
>> next_lk_ahds should be u8 or void. From what I understand by glancing
>> through the code it is an agnostic buffer that carries payload which
>> is later interpreted either as eid or htc header, right? void is
>> probably most suitable in this case for passing around and u8 for
>> inline-based storage.
>>=20
> Sounds reasonable, I'll change to void pointer.
>
>> I'd also avoid silly abbreviations. Probably "lookahead" alone is enough=
.
>>=20
> Ok, this abbreviation was actually taken from the ath6kl code. I think
> the intention was to reduce line lengths.
Most likely that comes from the staging ath6kl driver which again is a
fork of the Atheros internal driver. I agree with Michal, better to
avoid silly abbreviations as much as possible. Readability is most
important.
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH v3 5/5] mwifiex: move pcie_work and related variables inside card
From: Amitkumar Karwar @ 2016-11-16 13:09 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Ganapathi Bhat, Amitkumar Karwar
In-Reply-To: <1479301749-14803-1-git-send-email-akarwar@marvell.com>
From: Ganapathi Bhat <gbhat@marvell.com>
Currently pcie_work and related variables are global. It may create
problem while supporting multiple devices simultaneously. Let's move
it inside card structure so that separate instance will be created/
cancelled in init/teardown threads of each connected devices.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v3: This patch is introduced in v3
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 23 ++++++++++++-----------
drivers/net/wireless/marvell/mwifiex/pcie.h | 2 ++
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index c8e69a4..32fa4ed 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -52,7 +52,6 @@ static int mwifiex_pcie_probe_of(struct device *dev)
}
static void mwifiex_pcie_work(struct work_struct *work);
-static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
@@ -222,6 +221,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.mem_type_mapping_tbl = data->mem_type_mapping_tbl;
card->pcie.num_mem_types = data->num_mem_types;
card->pcie.can_ext_scan = data->can_ext_scan;
+ INIT_WORK(&card->work, mwifiex_pcie_work);
}
/* device tree node parsing and platform specific configuration*/
@@ -257,7 +257,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&pcie_work);
+ cancel_work_sync(&card->work);
if (user_rmmod && !adapter->mfg_mode) {
mwifiex_deauthenticate_all(adapter);
@@ -2718,25 +2718,27 @@ static void mwifiex_pcie_device_dump_work(struct mwifiex_adapter *adapter)
mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
}
-static unsigned long iface_work_flags;
-static struct mwifiex_adapter *save_adapter;
static void mwifiex_pcie_work(struct work_struct *work)
{
+ struct pcie_service_card *card =
+ container_of(work, struct pcie_service_card, work);
+
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP,
- &iface_work_flags))
- mwifiex_pcie_device_dump_work(save_adapter);
+ &card->work_flags))
+ mwifiex_pcie_device_dump_work(card->adapter);
}
/* This function dumps FW information */
static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
{
- save_adapter = adapter;
- if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags))
+ struct pcie_service_card *card = adapter->card;
+
+ if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags))
return;
- set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
+ set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
- schedule_work(&pcie_work);
+ schedule_work(&card->work);
}
/*
@@ -3202,7 +3204,6 @@ static void mwifiex_pcie_cleanup_module(void)
/* Set the flag as user is removing this module. */
user_rmmod = 1;
- cancel_work_sync(&pcie_work);
pci_unregister_driver(&mwifiex_pcie);
}
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h b/drivers/net/wireless/marvell/mwifiex/pcie.h
index ae3365d..21ba5e6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -386,6 +386,8 @@ struct pcie_service_card {
#endif
struct mwifiex_msix_context msix_ctx[MWIFIEX_NUM_MSIX_VECTORS];
struct mwifiex_msix_context share_irq_ctx;
+ struct work_struct work;
+ unsigned long work_flags;
};
static inline int
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/5] mwifiex: wait firmware dump complete during card remove process
From: Amitkumar Karwar @ 2016-11-16 13:09 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1479301749-14803-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
Wait for firmware dump complete in card remove function.
For sdio interface, there are two diffenrent cases,
card reset trigger sdio_work and firmware dump trigger sdio_work.
Do code rearrangement for distinguish between these two cases.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: 1. Get rid of reset_triggered flag. Instead split the code and use
__mwifiex_sdio_remove() (Brian Norris/Dmitry Torokhov)
2. "v1 4/5 mwifiex: firmware dump code rearrangement.." is dropped. So
rebased accordingly.
v3: same as [v2,5/5]. The improvement of 'moving pcie_work to card struct'
suggested by Brian is taken care in next patch.
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 6 +++++-
drivers/net/wireless/marvell/mwifiex/sdio.c | 15 ++++++++++++---
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index dd8f7aa..c8e69a4 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -51,6 +51,9 @@ static int mwifiex_pcie_probe_of(struct device *dev)
return 0;
}
+static void mwifiex_pcie_work(struct work_struct *work);
+static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -254,6 +257,8 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
+ cancel_work_sync(&pcie_work);
+
if (user_rmmod && !adapter->mfg_mode) {
mwifiex_deauthenticate_all(adapter);
@@ -2722,7 +2727,6 @@ static void mwifiex_pcie_work(struct work_struct *work)
mwifiex_pcie_device_dump_work(save_adapter);
}
-static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
/* This function dumps FW information */
static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
{
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 16d1d30..78f2cc9 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -46,6 +46,9 @@
*/
static u8 user_rmmod;
+static void mwifiex_sdio_work(struct work_struct *work);
+static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
+
static struct mwifiex_if_ops sdio_ops;
static unsigned long iface_work_flags;
@@ -220,7 +223,7 @@ static int mwifiex_sdio_resume(struct device *dev)
* This function removes the interface and frees up the card structure.
*/
static void
-mwifiex_sdio_remove(struct sdio_func *func)
+__mwifiex_sdio_remove(struct sdio_func *func)
{
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
@@ -249,6 +252,13 @@ static int mwifiex_sdio_resume(struct device *dev)
mwifiex_remove_card(adapter);
}
+static void
+mwifiex_sdio_remove(struct sdio_func *func)
+{
+ cancel_work_sync(&sdio_work);
+ __mwifiex_sdio_remove(func);
+}
+
/*
* SDIO suspend.
*
@@ -2227,7 +2237,7 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
* discovered and initializes them from scratch.
*/
- mwifiex_sdio_remove(func);
+ __mwifiex_sdio_remove(func);
/*
* Normally, we would let the driver core take care of releasing these.
@@ -2568,7 +2578,6 @@ static void mwifiex_sdio_work(struct work_struct *work)
mwifiex_sdio_card_reset_work(save_adapter);
}
-static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
/* This function resets the card */
static void mwifiex_sdio_card_reset(struct mwifiex_adapter *adapter)
{
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/5] mwifiex: get rid of drv_info* adapter variables
From: Amitkumar Karwar @ 2016-11-16 13:09 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1479301749-14803-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
We can avoid drv_info_dump and drv_info_size adapter variables.
This info can be passed to mwifiex_upload_device_dump() as parameters
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: This patch is introduced in v2.
Also, I have dropped "v1 4/5 mwifiex: firmware dump code rearrangement
in pcie.c" patch in this series to avoid rebase efforts for other patches
from Rajat/Brian in queue. I will submit this later.
v3: same as [v2,4/5]
---
drivers/net/wireless/marvell/mwifiex/main.c | 42 ++++++++++++-----------------
drivers/net/wireless/marvell/mwifiex/main.h | 7 +++--
drivers/net/wireless/marvell/mwifiex/pcie.c | 7 +++--
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +++--
4 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 379e084..55ac0cf 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1029,7 +1029,7 @@ void mwifiex_multi_chan_resync(struct mwifiex_adapter *adapter)
}
EXPORT_SYMBOL_GPL(mwifiex_multi_chan_resync);
-void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter)
+int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info)
{
void *p;
char drv_version[64];
@@ -1039,21 +1039,17 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter)
int i, idx;
struct netdev_queue *txq;
struct mwifiex_debug_info *debug_info;
-
- if (adapter->drv_info_dump) {
- vfree(adapter->drv_info_dump);
- adapter->drv_info_dump = NULL;
- adapter->drv_info_size = 0;
- }
+ void *drv_info_dump;
mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump start===\n");
- adapter->drv_info_dump = vzalloc(MWIFIEX_DRV_INFO_SIZE_MAX);
+ /* memory allocate here should be free in mwifiex_upload_device_dump*/
+ drv_info_dump = vzalloc(MWIFIEX_DRV_INFO_SIZE_MAX);
- if (!adapter->drv_info_dump)
- return;
+ if (!drv_info_dump)
+ return 0;
- p = (char *)(adapter->drv_info_dump);
+ p = (char *)(drv_info_dump);
p += sprintf(p, "driver_name = " "\"mwifiex\"\n");
mwifiex_drv_get_driver_version(adapter, drv_version,
@@ -1137,18 +1133,20 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter)
kfree(debug_info);
}
- adapter->drv_info_size = p - adapter->drv_info_dump;
mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump end===\n");
+ *drv_info = drv_info_dump;
+ return p - drv_info_dump;
}
EXPORT_SYMBOL_GPL(mwifiex_drv_info_dump);
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter)
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
+ int drv_info_size)
{
u8 idx, *dump_data, *fw_dump_ptr;
u32 dump_len;
dump_len = (strlen("========Start dump driverinfo========\n") +
- adapter->drv_info_size +
+ drv_info_size +
strlen("\n========End dump========\n"));
for (idx = 0; idx < adapter->num_mem_types; idx++) {
@@ -1178,8 +1176,8 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter)
strcpy(fw_dump_ptr, "========Start dump driverinfo========\n");
fw_dump_ptr += strlen("========Start dump driverinfo========\n");
- memcpy(fw_dump_ptr, adapter->drv_info_dump, adapter->drv_info_size);
- fw_dump_ptr += adapter->drv_info_size;
+ memcpy(fw_dump_ptr, drv_info, drv_info_size);
+ fw_dump_ptr += drv_info_size;
strcpy(fw_dump_ptr, "\n========End dump========\n");
fw_dump_ptr += strlen("\n========End dump========\n");
@@ -1217,18 +1215,12 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter)
struct memory_type_mapping *entry =
&adapter->mem_type_mapping_tbl[idx];
- if (entry->mem_ptr) {
- vfree(entry->mem_ptr);
- entry->mem_ptr = NULL;
- }
+ vfree(entry->mem_ptr);
+ entry->mem_ptr = NULL;
entry->mem_size = 0;
}
- if (adapter->drv_info_dump) {
- vfree(adapter->drv_info_dump);
- adapter->drv_info_dump = NULL;
- adapter->drv_info_size = 0;
- }
+ vfree(drv_info);
}
EXPORT_SYMBOL_GPL(mwifiex_upload_device_dump);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index fd56b5d..d501d03 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -994,8 +994,6 @@ struct mwifiex_adapter {
u8 key_api_major_ver, key_api_minor_ver;
struct memory_type_mapping *mem_type_mapping_tbl;
u8 num_mem_types;
- void *drv_info_dump;
- u32 drv_info_size;
bool scan_chan_gap_enabled;
struct sk_buff_head rx_data_q;
bool mfg_mode;
@@ -1641,8 +1639,9 @@ void mwifiex_hist_data_add(struct mwifiex_private *priv,
u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
u8 rx_rate, u8 ht_info);
-void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter);
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter);
+int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info);
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
+ int drv_info_size);
void *mwifiex_alloc_dma_align_buf(int rx_len, gfp_t flags);
void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
int mwifiex_get_wakeup_reason(struct mwifiex_private *priv, u16 action,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index e4f1f55..dd8f7aa 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2705,9 +2705,12 @@ static void mwifiex_pcie_fw_dump(struct mwifiex_adapter *adapter)
static void mwifiex_pcie_device_dump_work(struct mwifiex_adapter *adapter)
{
- mwifiex_drv_info_dump(adapter);
+ int drv_info_size;
+ void *drv_info;
+
+ drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
mwifiex_pcie_fw_dump(adapter);
- mwifiex_upload_device_dump(adapter);
+ mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
}
static unsigned long iface_work_flags;
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 1235f04..16d1d30 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2547,13 +2547,15 @@ static void mwifiex_sdio_generic_fw_dump(struct mwifiex_adapter *adapter)
static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
+ int drv_info_size;
+ void *drv_info;
- mwifiex_drv_info_dump(adapter);
+ drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
if (card->fw_dump_enh)
mwifiex_sdio_generic_fw_dump(adapter);
else
mwifiex_sdio_fw_dump(adapter);
- mwifiex_upload_device_dump(adapter);
+ mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
}
static void mwifiex_sdio_work(struct work_struct *work)
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/5] mwifiex: do not free firmware dump memory in shutdown_drv
From: Amitkumar Karwar @ 2016-11-16 13:09 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1479301749-14803-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
mwifiex_upload_device_dump() already takes care of freeing firmware dump
memory. Doing the same thing in mwifiex_shutdown_drv() is redundant.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1.
drv_info_dump and drv_info_size need not be in adapter structure. Saparate
patch is created for this (Dmitry Torokhov)
v3: Same as [v2,3/5]
---
drivers/net/wireless/marvell/mwifiex/init.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index f581a15..87cda4f 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -408,8 +408,6 @@ static void mwifiex_free_lock_list(struct mwifiex_adapter *adapter)
static void
mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
{
- int idx;
-
if (!adapter) {
pr_err("%s: adapter is NULL\n", __func__);
return;
@@ -427,23 +425,6 @@ static void mwifiex_free_lock_list(struct mwifiex_adapter *adapter)
mwifiex_dbg(adapter, INFO, "info: free cmd buffer\n");
mwifiex_free_cmd_buffer(adapter);
- for (idx = 0; idx < adapter->num_mem_types; idx++) {
- struct memory_type_mapping *entry =
- &adapter->mem_type_mapping_tbl[idx];
-
- if (entry->mem_ptr) {
- vfree(entry->mem_ptr);
- entry->mem_ptr = NULL;
- }
- entry->mem_size = 0;
- }
-
- if (adapter->drv_info_dump) {
- vfree(adapter->drv_info_dump);
- adapter->drv_info_dump = NULL;
- adapter->drv_info_size = 0;
- }
-
if (adapter->sleep_cfm)
dev_kfree_skb_any(adapter->sleep_cfm);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/5] mwifiex: don't wait for main_process in shutdown_drv
From: Amitkumar Karwar @ 2016-11-16 13:09 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
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 is completed by
performing below actions.
(1) disable interrupts in if_ops->disable_int.
(2) set adapter->surprise_removed = true, main_process wont be queued.
(3) mwifiex_terminate_workqueue(adapter), wait for workqueue to be
completed.
This patch removes redundant wait code and takes care of related
cleanup.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v3: a) This patch is introduced in v3. It replaces "[v2,2/5] mwifiex: use spinlock for
'mwifiex_processing' in shutdown_drv" patch.
b) "[v2,1/5] mwifiex: remove redundant condition in main process" is dropped in
this patch series.
---
drivers/net/wireless/marvell/mwifiex/init.c | 19 ++--------
drivers/net/wireless/marvell/mwifiex/main.c | 55 ++++++++++-------------------
drivers/net/wireless/marvell/mwifiex/main.h | 5 +--
drivers/net/wireless/marvell/mwifiex/util.c | 15 --------
4 files changed, 22 insertions(+), 72 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index b36cb3f..f581a15 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -656,10 +656,9 @@ void mwifiex_free_priv(struct mwifiex_private *priv)
* - Free the adapter
* - Notify completion
*/
-int
+void
mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
{
- int ret = -EINPROGRESS;
struct mwifiex_private *priv;
s32 i;
unsigned long flags;
@@ -667,15 +666,7 @@ void mwifiex_free_priv(struct mwifiex_private *priv)
/* mwifiex already shutdown */
if (adapter->hw_status == MWIFIEX_HW_STATUS_NOT_READY)
- return 0;
-
- adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
- /* wait for mwifiex_process to complete */
- if (adapter->mwifiex_processing) {
- mwifiex_dbg(adapter, WARN,
- "main process is still running\n");
- return ret;
- }
+ return;
/* cancel current command */
if (adapter->curr_cmd) {
@@ -726,11 +717,7 @@ void mwifiex_free_priv(struct mwifiex_private *priv)
mwifiex_adapter_cleanup(adapter);
spin_unlock(&adapter->mwifiex_lock);
-
- /* Notify completion */
- ret = mwifiex_shutdown_fw_complete(adapter);
-
- return ret;
+ adapter->hw_status = MWIFIEX_HW_STATUS_NOT_READY;
}
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index eac44fe..379e084 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -248,15 +248,14 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
if (adapter->mwifiex_processing || adapter->main_locked) {
adapter->more_task_flag = true;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
- goto exit_main_proc;
+ return 0;
} else {
adapter->mwifiex_processing = true;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
}
process_start:
do {
- if ((adapter->hw_status == MWIFIEX_HW_STATUS_CLOSING) ||
- (adapter->hw_status == MWIFIEX_HW_STATUS_NOT_READY))
+ if (adapter->hw_status == MWIFIEX_HW_STATUS_NOT_READY)
break;
/* For non-USB interfaces, If we process interrupts first, it
@@ -464,9 +463,6 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
adapter->mwifiex_processing = false;
spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
-exit_main_proc:
- if (adapter->hw_status == MWIFIEX_HW_STATUS_CLOSING)
- mwifiex_shutdown_drv(adapter);
return ret;
}
EXPORT_SYMBOL_GPL(mwifiex_main_process);
@@ -648,16 +644,14 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
if (adapter->if_ops.unregister_dev)
adapter->if_ops.unregister_dev(adapter);
+ adapter->surprise_removed = true;
+ mwifiex_terminate_workqueue(adapter);
+
if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
pr_debug("info: %s: shutdown mwifiex\n", __func__);
- adapter->init_wait_q_woken = false;
-
- if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
+ mwifiex_shutdown_drv(adapter);
}
- adapter->surprise_removed = true;
- mwifiex_terminate_workqueue(adapter);
+
init_failed = true;
done:
if (adapter->cal_data) {
@@ -1402,11 +1396,8 @@ static void mwifiex_main_work_queue(struct work_struct *work)
}
mwifiex_dbg(adapter, CMD, "cmd: calling mwifiex_shutdown_drv...\n");
- adapter->init_wait_q_woken = false;
- if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
+ mwifiex_shutdown_drv(adapter);
if (adapter->if_ops.down_dev)
adapter->if_ops.down_dev(adapter);
@@ -1512,19 +1503,16 @@ static void mwifiex_main_work_queue(struct work_struct *work)
mwifiex_dbg(adapter, ERROR, "info: %s: unregister device\n", __func__);
if (adapter->if_ops.unregister_dev)
adapter->if_ops.unregister_dev(adapter);
+
+err_kmalloc:
+ adapter->surprise_removed = true;
+ mwifiex_terminate_workqueue(adapter);
if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
mwifiex_dbg(adapter, ERROR,
"info: %s: shutdown mwifiex\n", __func__);
- adapter->init_wait_q_woken = false;
-
- if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
+ mwifiex_shutdown_drv(adapter);
}
-err_kmalloc:
- mwifiex_terminate_workqueue(adapter);
- adapter->surprise_removed = true;
complete_all(adapter->fw_done);
mwifiex_dbg(adapter, INFO, "%s, error\n", __func__);
@@ -1684,17 +1672,13 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
pr_debug("info: %s: unregister device\n", __func__);
if (adapter->if_ops.unregister_dev)
adapter->if_ops.unregister_dev(adapter);
- if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
- pr_debug("info: %s: shutdown mwifiex\n", __func__);
- adapter->init_wait_q_woken = false;
-
- if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
- }
err_registerdev:
adapter->surprise_removed = true;
mwifiex_terminate_workqueue(adapter);
+ if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
+ pr_debug("info: %s: shutdown mwifiex\n", __func__);
+ mwifiex_shutdown_drv(adapter);
+ }
err_kmalloc:
mwifiex_free_adapter(adapter);
@@ -1744,11 +1728,8 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter)
mwifiex_dbg(adapter, CMD,
"cmd: calling mwifiex_shutdown_drv...\n");
- adapter->init_wait_q_woken = false;
- if (mwifiex_shutdown_drv(adapter) == -EINPROGRESS)
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
+ mwifiex_shutdown_drv(adapter);
mwifiex_dbg(adapter, CMD,
"cmd: mwifiex_shutdown_drv done\n");
if (atomic_read(&adapter->rx_pending) ||
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 5c9bd94..fd56b5d 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -248,7 +248,6 @@ enum MWIFIEX_HARDWARE_STATUS {
MWIFIEX_HW_STATUS_INITIALIZING,
MWIFIEX_HW_STATUS_INIT_DONE,
MWIFIEX_HW_STATUS_RESET,
- MWIFIEX_HW_STATUS_CLOSING,
MWIFIEX_HW_STATUS_NOT_READY
};
@@ -1041,9 +1040,7 @@ void mwifiex_wake_up_net_dev_queue(struct net_device *netdev,
int mwifiex_init_fw_complete(struct mwifiex_adapter *adapter);
-int mwifiex_shutdown_drv(struct mwifiex_adapter *adapter);
-
-int mwifiex_shutdown_fw_complete(struct mwifiex_adapter *adapter);
+void mwifiex_shutdown_drv(struct mwifiex_adapter *adapter);
int mwifiex_dnld_fw(struct mwifiex_adapter *, struct mwifiex_fw_image *);
diff --git a/drivers/net/wireless/marvell/mwifiex/util.c b/drivers/net/wireless/marvell/mwifiex/util.c
index 18fbb96..b1ab8da 100644
--- a/drivers/net/wireless/marvell/mwifiex/util.c
+++ b/drivers/net/wireless/marvell/mwifiex/util.c
@@ -146,21 +146,6 @@ int mwifiex_init_fw_complete(struct mwifiex_adapter *adapter)
}
/*
- * Firmware shutdown complete callback handler.
- *
- * This function sets the hardware status to not ready and wakes up
- * the function waiting on the init wait queue for the firmware
- * shutdown to complete.
- */
-int mwifiex_shutdown_fw_complete(struct mwifiex_adapter *adapter)
-{
- adapter->hw_status = MWIFIEX_HW_STATUS_NOT_READY;
- adapter->init_wait_q_woken = true;
- wake_up_interruptible(&adapter->init_wait_q);
- return 0;
-}
-
-/*
* This function sends init/shutdown command
* to firmware.
*/
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2 1/5] mwifiex: remove redundant condition in main process
From: Amitkumar Karwar @ 2016-11-16 13:08 UTC (permalink / raw)
To: Brian Norris, Kalle Valo
Cc: Xinming Hu, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, dmitry.torokhov@gmail.com
In-Reply-To: <20161110194646.GA85922@google.com>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Friday, November 11, 2016 1:17 AM
> To: Kalle Valo
> Cc: Xinming Hu; Amitkumar Karwar; linux-wireless@vger.kernel.org; Cathy
> Luo; Nishant Sarmukadam; rajatja@google.com; dmitry.torokhov@gmail.com
> Subject: Re: [PATCH v2 1/5] mwifiex: remove redundant condition in main
> process
>
> On Mon, Nov 07, 2016 at 08:46:41PM +0200, Kalle Valo wrote:
> > Xinming Hu <huxm@marvell.com> writes:
> >
> > > We have include below change in latest submit
> > > https://patchwork.kernel.org/patch/9407283/
> > > Please drop this patch.
> >
> > When making changes please resend the whole patchset. I do not want
> to
> > individually pick patches from different places, that will eventually
> > go wrong anyway. So I just apply full patchsets.
>
> I'm going to assume that Xinming intended that the entire series be
> resent, possibly without this patch. There were enough other issues in
> the series anyway.
I will submit v3 series shortly.
Regards,
Amitkumar
^ permalink raw reply
* RE: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card
From: Amitkumar Karwar @ 2016-11-16 13:07 UTC (permalink / raw)
To: Brian Norris
Cc: Kalle Valo, Dmitry Torokhov, linux-wireless@vger.kernel.org,
Cathy Luo, Nishant Sarmukadam, Xinming Hu
In-Reply-To: <20161109203710.GA118631@google.com>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Thursday, November 10, 2016 2:07 AM
> To: Amitkumar Karwar
> Cc: Kalle Valo; Dmitry Torokhov; linux-wireless@vger.kernel.org; Cathy
> Luo; Nishant Sarmukadam; Xinming Hu
> Subject: Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in
> remove_card
>
> On Wed, Nov 09, 2016 at 12:35:22PM +0000, Amitkumar Karwar wrote:
> > Hi Brian,
>
> Hi,
>
> > > From: Brian Norris [mailto:briannorris@chromium.org]
> > > Sent: Thursday, November 03, 2016 2:16 AM
> > > To: Kalle Valo
> > > Cc: Dmitry Torokhov; Amitkumar Karwar;
> > > linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> > > Xinming Hu
> > > Subject: Re: [PATCH 5/5] mwifiex: wait for firmware dump completion
> > > in remove_card
> > >
> > > On Thu, Oct 27, 2016 at 04:20:25PM +0300, Kalle Valo wrote:
> > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> > > >
> > > > >> +/* reset_trigger variable is used to identify if
> > > > >> +mwifiex_sdio_remove()
> > > > >> + * is called by sdio_work during reset or the call is from
> > > > >> +sdio
> > > subsystem.
> > > > >> + * We will cancel sdio_work only if the call is from sdio
> > > subsystem.
> > > > >> + */
> > > > >> +static u8 reset_triggered;
> > > > >
> > > > > It would be really great if the driver supported multiple
> devices.
> > > > > IOW please avoid module-globals.
> > > >
> > > > Good catch, it's a hard requirement to support multiple devices
> at
> > > > the same time.
> > >
> > > BTW, this problem is repeated in several places throughout this
> driver.
> > > For instance, look for 'user_rmmod' (why? you shouldn't need to
> > > treat module unload differently...)
> >
> > We have 2 kinds of teardown cases.
> > 1) Chip is going to be powered off.
> > a) System reboot
> > b) Someone manually removed wifi card from system
> > 2) User unloaded the driver.
> >
> > In case 1. b), we can't have logic to terminate WIFI connection and
> > download SHUTDOWN command to firmware, as hardware itself is not
> > present.
>
> That seems like a poor way of determining the difference between hot
> unplug and clean shutdown. What if unplug happens concurrently with
> rmmod? Seems like it'd be better to identify hardware failures as such,
> and just skip talking to HW. Also, for interfaces that support unplug
> well (like USB), shouldn't you be able to get hotplug info from the
> driver core, instead of having to guess the inverse of that ("this was
> not a hotplug") from static variables like that?
>
> > This logic is useful when user just unloads and loads the driver.
> > Firmware download will be skipped in this case, as it's already
> > running. SHUTDOWN command sent during unload has cleared firmware's
> > state.
>
> Why is that useful?
>
> > 'user_rmmod' flag doesn't create problem for supporting multiple
> > devices. The flag is true during module unload OR reboot. It's
> > applicable for all devices.
> >
> > > and the work structs (and corresponding 'saved_adapter' and
> > > 'iface_flags') used for PCIe function-level reset and SDIO reset.
> >
> > We are working on the v3 of this patch series. We will try to get rid
> > of these variables along with global "work_struct" as you suggested.
I observed some crash issues while testing with PCIe/SDIO chipsets after removing user_rmmod. We are still checking them. I will not include user_rmmod removal patch in v3 series. Other pcie_work related global variables are removed in v3 series.
Card is freed and recreated during mwifiex_sdio_card_reset_work(). It is one of the activities in sdio_work. So moving sdio_work inside card won't be straight forward.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 0/8] iw: Add common chandef parser and new DFS related commands
From: Johannes Berg @ 2016-11-16 12:41 UTC (permalink / raw)
To: Benjamin Berg; +Cc: linux-wireless, sw, Benjamin Berg
In-Reply-To: <20161107145943.16761-1-benjamin@sipsolutions.net>
On Mon, 2016-11-07 at 15:59 +0100, Benjamin Berg wrote:
> From: Benjamin Berg <benjamin.berg@open-mesh.com>
>
> Hi,
>
> This patchset adds commands for doing a CAC and sending CSA.
>
> Another change is that parsing of command line frequency and channel
> definitions is split out so that it can be shared between the
> different users.
That's nice :)
I've applied all except for patch 7 - I don't see any justification for
adding that - quite clearly iw will not listen to any radar detection
events, so even for testing/certification this doesn't seem useful
since then you'd want to check/prove that you *do* listen to those ...
johannes
^ permalink raw reply
* Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor
From: Stanislaw Gruszka @ 2016-11-16 12:02 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, Helmut Schaa, Felix Fietkau
In-Reply-To: <e4dfaa30-7dd6-c485-3e30-71bfafbc1502@kresin.me>
On Wed, Nov 16, 2016 at 09:07:00AM +0100, Mathias Kresin wrote:
> Here are the results of the requested tests. Please keep in mind, I'm not in
> a lab environment:
>
> LEDE head
> connect
> action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
> action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
> action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
> action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
No problem here - buf_size corresponds to ampdu_factor.
> ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
> to flush
> ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
> to flush
I think we do not give device enough time to post AMPDU consisted
with bigger amount of frames. If we want to increase ba_size we will
need also some other changes in the driver. Anyway I already request
Kalle to drop this patch. I assume other patches do not cause
regression for you, correct?
Thanks for testing.
Stanislaw
^ permalink raw reply
* [PATCH v2 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
From: Stanislaw Gruszka @ 2016-11-16 11:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Mathias Kresin
In-Reply-To: <1478095865-8651-5-git-send-email-sgruszka@redhat.com>
We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on
rt2800_init_registers() for USB devices. For PCI devices we will use
HW default setting, which is 2, so patch does not change behaviour
on PCI devices.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
v1 -> v2 Changelog fixes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index feceb13..9ecdc4c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -6756,7 +6756,6 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 1);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 1);
- rt2x00_set_field32(®, WPDMA_GLO_CFG_WP_DMA_BURST_SIZE, 2);
rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_WRITEBACK_DONE, 1);
rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Arend Van Spriel @ 2016-11-16 10:38 UTC (permalink / raw)
To: Kalle Valo, Gianfranco Costamagna
Cc: brcm80211-dev-list@broadcom.com, linux-wireless@vger.kernel.org,
nsmaldone@tierratelematics.com, Marco.Arlone@roj.com
In-Reply-To: <87r36dov6u.fsf@purkki.adurom.net>
On 15-11-2016 12:10, Kalle Valo wrote:
> Gianfranco Costamagna <locutusofborg@debian.org> writes:
>
>>> Well, not before you pointed it out ;-). You are welcome to send a patch
>>> fixing it. Otherwise, I will take care of it.
>>
>> attaching a format-patch like version.
>> I don't think we need a Tested-by or whatever, because it is just a typo in a comment.
>> (this is my first contribution, feel free to rebase or change whatever you prefer
>> to make it in line with other styles)
>>
>> (I gave authorship to Marco, the first one who discovered such typo)
>
> [...]
>
>> Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
>
> Please note that you cannot add Signed-off-by for other people without
> their explicit approval (see Documentation/SubmittingPatches). I don't
> know if they did it in this case or not, but wanted to point out this
> anyway.
Thanks, Kalle
It was on my list to give a contrib boot camp here. So let's go over
things here albeit it late.
Hi Gianfrance,
A couple of things from which you may benefit for future contributions.
Basic info can be found in Documentation/SubmittingPatches as Kalle
indicated.
Patches should not be submitted as attachments. After doing 'git
format-patch' the easiest way is using 'git send-email' (which requires
you to have sendmail on your system properly setup). I tend to send
patches to Kalle and Cc: linux-wireless, but that is my personal
preference. Sending it to the list should be sufficient as patchwork
will pick it up [1].
When it comes to attribution of others you should have their approval
for Signed-off-by. However, reading your remarks it seems a proper way
is below:
Reported-by: Arlone Marco <marco.arlone@roj.com>
Tested-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
Signed-off-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>
Regards,
Arend
[1] https://patchwork.kernel.org/project/linux-wireless/list/
^ permalink raw reply
* [PATCH] ath9k: fix NULL pointer dereference
From: miaoqing @ 2016-11-16 9:23 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath9k-devel, devin.tuchsen, Miaoqing Pan
From: Miaoqing Pan <miaoqing@codeaurora.org>
relay_open() may return NULL, check the return value to avoid the crash.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
PGD 41cf28067 PUD 41be92067 PMD 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15 07/04/2011
task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
Stack:
0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
Call Trace:
<IRQ>
[<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
[<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
[<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
Reported-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Tested-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index e2512d5..eedf86b 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -528,6 +528,9 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct ieee80211_h
if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
return 0;
+ if (!spec_priv->rfs_chan_spec_scan)
+ return 1;
+
/* Output buffers are full, no need to process anything
* since there is no space to put the result anyway
*/
@@ -1072,7 +1075,7 @@ static int remove_buf_file_handler(struct dentry *dentry)
void ath9k_cmn_spectral_deinit_debug(struct ath_spec_scan_priv *spec_priv)
{
- if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS)) {
+ if (IS_ENABLED(CONFIG_ATH9K_DEBUGFS) && spec_priv->rfs_chan_spec_scan) {
relay_close(spec_priv->rfs_chan_spec_scan);
spec_priv->rfs_chan_spec_scan = NULL;
}
@@ -1086,6 +1089,9 @@ void ath9k_cmn_spectral_init_debug(struct ath_spec_scan_priv *spec_priv,
debugfs_phy,
1024, 256, &rfs_spec_scan_cb,
NULL);
+ if (!spec_priv->rfs_chan_spec_scan)
+ return;
+
debugfs_create_file("spectral_scan_ctl",
S_IRUSR | S_IWUSR,
debugfs_phy, spec_priv,
--
1.9.1
^ permalink raw reply related
* RE: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Stam, Michel [FINT] @ 2016-11-16 8:54 UTC (permalink / raw)
To: Adrian Chadd
Cc: Johannes Berg, Sebastian Gottschall, Kalle Valo,
Antonio Quartulli, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Antonio Quartulli
In-Reply-To: <CAJ-VmonW7jR0vnnZmj8CsvY-6-O--L68LpBxcuXQ8Pk46AOQNQ@mail.gmail.com>
SGV5IEFkcmlhbiwNCg0KU291bmRzIGxpa2UgYW4gaWRlYSwgYWx0aG91Z2ggdXAgdG8gdGhpcyBw
b2ludCBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBkZXRlY3Qgd2hldGhlciByZXBsdW1iaW5nIGlz
IG5lY2Vzc2FyeS4gZGVjcnlwdF9lcnJvcnMgZG9lcyBub3QgaW5jcmVtZW50IGV4cG9uZW50aWFs
bHkgb24gdGhlIHJlY2VpdmUgcGF0aCwgYXMgZmFyIGFzIEkgc2F3IG9ubHkgb25lIGRlY3J5cHRf
ZXJyb3IgY29tZXMgdGhyb3VnaCwgd2hpY2ggY291bGQganVzdCBhcyB3ZWxsIGJlIGEgY29ycnVw
dGVkIGZyYW1lLiBJIGhhdmUgbm90IHNlZW4gYW55IG90aGVyIGluZGljYXRvcnMgb2YgdGhpcyBp
c3N1ZSwgb3RoZXIgdGhhbiBhIGNvbXBsZXRlIGxhY2sgb2YgY29ubmVjdGl2aXR5IG9uIHVuaWNh
c3QgZnJhbWVzLg0KDQpTbyB0aGlzIGF0dGVtcHQgd2FzIHRvIHNlZSBpZiBJIGNvdWxkIGdldCB0
aGUgbGluayBzdGFibGUsIGluIGFueSB3YXkgcG9zc2libGUsIGJ5IGJsYW5rbHkgcmVwbHVtYmlu
ZyBvbiBldmVyeSByZWtleS4gVGhpcyBzaG91bGQsIGluIHRoZW9yeSAic29sdmUiIHRoZSBpc3N1
ZSwgYWx0aG91Z2ggYXQgdGhlIGNvc3Qgb2YgaHVnZSBwYWNrZXQgbG9zcy4gU28gZmFyLCBubyBn
by4NCg0KSSBhZ3JlZSB0aGF0IHNvbWUgZm9ybSBvZiBrZXkgY2FjaGluZyBtYXkgYmUgbmVjZXNz
YXJ5LiBJdCBpcyBhIHBpdHksIGJlY2F1c2UgdGhlIG1hYzgwMjExIGxheWVyIGRvZXMgaGF2ZSBh
biBpbnRlcmZhY2UgZm9yIGdyYWJiaW5nIHRoZSBrZXlzLCBhbHRob3VnaCBpdCByZXF1aXJlcyB0
aGUgcnRubF9sb2NrLiBBcyBmYXIgYXMgSSBzYXcsIG9ubHkgdGhlIEludGVsIHdpcmVsZXNzIGRy
aXZlciB1c2VzIGl0IHRvIHdyaXRlIHRoZSBrZXlzIGJhY2sgaW50byB0aGUgY2hpcCB1cG9uIHJl
c3VtaW5nIGZyb20gYSBsb3ctcG93ZXIgc3RhdGUuDQoNCktpbmQgcmVnYXJkcywNCkZ1Z3JvIElu
dGVyc2l0ZSBCLlYuDQoNCk1pY2hlbCBTdGFtDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogYWRyaWFuLmNoYWRkQGdtYWlsLmNvbSBbbWFpbHRvOmFkcmlhbi5jaGFkZEBnbWFpbC5j
b21dIE9uIEJlaGFsZiBPZiBBZHJpYW4gQ2hhZGQNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE1
LCAyMDE2IDA6MjUgQU0NClRvOiBTdGFtLCBNaWNoZWwgW0ZJTlRdDQpDYzogSm9oYW5uZXMgQmVy
ZzsgU2ViYXN0aWFuIEdvdHRzY2hhbGw7IEthbGxlIFZhbG87IEFudG9uaW8gUXVhcnR1bGxpOyBh
dGg5ay1kZXZlbEBsaXN0cy5hdGg5ay5vcmc7IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9y
ZzsgQW50b25pbyBRdWFydHVsbGkNClN1YmplY3Q6IFJlOiBbYXRoOWstZGV2ZWxdIFtOT1QgRk9S
IE1FUkdFXSBhdGg5azogd29yayBhcm91bmQga2V5IGNhY2hlIGNvcnJ1cHRpb24NCg0KSGl5YSwN
Cg0KbWF5YmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGlzIHRvIHNldCBhIGZsYWcgdGhhdCBzYXlz
ICJwbGVhc2UNCnJlcGx1bWIiLCB0aGVuIGRvIGEgcmVzZXQsIGFuZCBoYXZlIHRoZSByZXNldCBw
YXRoIHNlZSBpZiB3ZSBuZWVkIHRvDQpyZXBsdW1iIGtleXMgYW5kIGRvIHNvPw0KDQpUbyBtYWtl
IGxvY2tpbmcgbGVzcyB0ZXJyaWJsZSwgbWF5YmUgd2UgbmVlZCB0byBjYWNoZSB0aGUga2V5cyBp
biB0aGUNCmF0aDlrIGRyaXZlciBzb21ld2hlcmUgc28gcmVwbHVtYmluZyBkb2Vzbid0IHJlcXVp
cmUgcmVhY2hpbmcgaW50bw0KbWFjODIwMTEuDQoNCg0KDQotYWRyaWFuDQoNCg==
^ permalink raw reply
* Re: [PATCH 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
From: Mathias Kresin @ 2016-11-16 8:10 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <20161114084238.GA12372@redhat.com>
14.11.2016 09:42, Stanislaw Gruszka:
> On Sat, Nov 05, 2016 at 01:55:14PM +0100, Mathias Kresin wrote:
>> 02.11.2016 15:10, Stanislaw Gruszka:
>>> We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on
>>> rt2800_init_registers().
>>>
>>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>> ---
>>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1 -
>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> index feceb13..9ecdc4c 100644
>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> @@ -6756,7 +6756,6 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
>>> rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
>>> rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 1);
>>> rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 1);
>>> - rt2x00_set_field32(®, WPDMA_GLO_CFG_WP_DMA_BURST_SIZE, 2);
>>
>> More a notice than a potential issue since I don't have much
>> knowledge about the driver/chip internals.
>>
>> But WPDMA_GLO_CFG_WP_DMA_BURST_SIZE in rt2800_init_registers() is
>> set conditionally for rt2x00_is_usb(rt2x00dev), where this one is
>> set unconditionally. Not sure if this change has side effects.
>
> Default HW setting of WP_DMA_BURTS_SIZE is 2, hence patch does not
> change behaviour on PCI devices. However I looked at RT3290 and
> RT5592 PCI vendor drivers and there this value is initialized to 3.
> So I think we can remove is_usb condition in rt2800_init_registers().
Shouldn't one of the explanations (depending on where you decide to set
WP_DMA_BURTS_SIZE) go into the commit message? As said in my last mail,
without further explanation it looks like introducing a bug.
Mathias
^ permalink raw reply
* Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor
From: Mathias Kresin @ 2016-11-16 8:07 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Felix Fietkau
In-Reply-To: <20161114124323.GA31857@redhat.com>
14.11.2016 13:43, Stanislaw Gruszka:
> On Mon, Nov 14, 2016 at 09:45:36AM +0100, Stanislaw Gruszka wrote:
>> Could you check below patch and see if it helps? If it does not,
>> could you printk sta->ht_cap.ampdu_density and ba_size values
>> and provide them here.
>
> Actually please print parameters from below patch. I think ba_size
> should be based on per TID buf_size instead of ampdu_factor, in case
> STA has buf size different for some TIDs.
>
> Also adding Felix to cc since my orginal patch:
> http://marc.info/?l=linux-wireless&m=147809595316289&w=2
> was shamelessly stolen from mt76 driver. Perhaps Felix could provide
> us some expertise.
>
> Thanks
> Stanislaw
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index 2515702..35bc38c 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -7950,6 +7950,8 @@ int rt2800_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> struct rt2x00_sta *sta_priv = (struct rt2x00_sta *)sta->drv_priv;
> int ret = 0;
>
> + printk("action %d sta %pM tid %u buf_size %u ampdu_factor %u\n", params->action, sta->addr, params->tid, params->buf_size, sta->ht_cap.ampdu_factor);
> +
> /*
> * Don't allow aggregation for stations the hardware isn't aware
> * of because tx status reports for frames to an unknown station
>
Here are the results of the requested tests. Please keep in mind, I'm
not in a lab environment:
LEDE head
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.01 sec 544 MBytes 76.1 Mbits/sec sender
0.00-60.01 sec 544 MBytes 76.1 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 609 MBytes 85.1 Mbits/sec 96 sender
0.00-60.00 sec 606 MBytes 84.8 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver (without LEDE rt2x00 patches)
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 522 MBytes 73.0 Mbits/sec sender
0.00-60.02 sec 522 MBytes 73.0 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 583 MBytes 81.5 Mbits/sec 104 sender
0.00-60.00 sec 581 MBytes 81.2 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver + patchset
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 377 MBytes 52.7 Mbits/sec sender
0.00-60.02 sec 377 MBytes 52.6 Mbits/sec receive
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
wired (iperf client) to wireless (iperf server)
* not reliable reproducible stalls/reconnects:
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
* one time I've seen this:
ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame
received with unrecognized signal, mode=0x0001,
signal=0x010c, type=4
* sometimes the same rt2x00queue_flush_queue warning on interface
down
Interval Transfer Bandwidth Retr
0.00-60.00 sec 576 MBytes 80.6 Mbits/sec 447 sender
0.00-60.00 sec 574 MBytes 80.2 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
LEDE + vanilla driver + patchset + increased max psdu
connect
action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3
action 2 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 6 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
action 0 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 64 ampdu_factor 3
wireless (iperf client) to wired (iperf server)
Interval Transfer Bandwidth
0.00-60.02 sec 366 MBytes 51.1 Mbits/sec sender
0.00-60.02 sec 365 MBytes 51.1 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bandwidth Retr
0.00-60.00 sec 569 MBytes 79.6 Mbits/sec 471 sender
0.00-60.00 sec 566 MBytes 79.1 Mbits/sec receiver
on interface down
action 4 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 0 buf_size 0 ampdu_factor 3
action 1 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 0 ampdu_factor 3
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 2 failed
to flush
^ permalink raw reply
* RE: Problems with mwifiex_pcie firmware activation
From: Amitkumar Karwar @ 2016-11-16 6:03 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Nishant Sarmukadam, linux-wireless@vger.kernel.org
In-Reply-To: <20161114101544.GA13943@redhat.com>
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:sgruszka@redhat.com]
> Sent: Monday, November 14, 2016 3:46 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; linux-wireless@vger.kernel.org
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > > The problem looks strange. The patch just splits
> mwifiex_check_fw_status() and increases poll count. It should not have
> any side-effects.
> > > > Our code used to check winner status before this patch also.
> > >
> > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > not work well on some condition and prevent loading firmware into
> > > device.
> >
> > I debug this a bit more on latest wireless-testing-next tree + 3
> > patches I just posted and debug_mask=0x700000ff.
> >
> > On broken system, we do not download FW to device when system is
> > rebooted, due to PCI-E is not the winner. However if system is
> powered
> > OFF and then powered ON, we do FW downloading. Hence download the new
> > FW into device does not make it work as was my theory.
> >
> > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > cases.
> >
> > The difference is that on broken system FW (or HW) do not create new
> > USB Bluetooth device (1286:2046) and do not report
> > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> from
> > USB xhci.
>
> It was discovered that not working device require pcie8897_uapsta.bin
> firmware from ubuntu package to work:
What's the difference between working and non-working device?
> https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> devices/+sourcepub/5936055/+listing-archive-extra
>
> Device initialize like this then:
>
> [ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size
> 689624 bytes
> [ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
> [ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION:
> mwifiex 1.0 (15.150.13.p21)
> [ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0
> (15.150.13.p21)
>
> I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> it seems it's not present nor in upstream linux-firmware repo not in
> http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
>
> Anyway could you modify firmware to support this device or modify
> driver to load 15.150.13.p21 if required and push this F/W image
> upstream ?
>
Last released firmware is 15.68.7.p77
http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
Could you try with it?
If it doesn't work, we need to investigate what is missing in this compared to 15.150.13.p21 and create new 15.68.7.pXX.
Regards,
Amitkumar
^ permalink raw reply
* Re: Bayesian rate control
From: Adrian Chadd @ 2016-11-16 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Björn Smedman, linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <1479202467.12007.26.camel@sipsolutions.net>
On 15 November 2016 at 01:34, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> But there is a per-descriptor TX rate table entry in the driver.
>> FreeBSD uses it to implement its rate control for the intel drivers.
>>
>> What am I missing? :)
>
> Not sure. But there isn't a per-descriptor table in the driver. There's
> a per-station table, that *can* be used in similar ways, but at least
> in Linux none of the APIs are hooked up to the general implementation,
> it's all driver/device-specific code, so it'd be very painful to try to
> experiment with.
Ok. well, we do that. :)
I'll let you know how well it works when I'm doing 11ac with the 7260 driver.
-adrian
^ permalink raw reply
* crda not triggering kernel udev event
From: Matthew Stanger @ 2016-11-16 0:11 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm trying to troubleshoot not being able to set the Regulator Domain
on a custom Yocto 3.14 kernel with a Marvell 88W8887/at91_mci driver
on ARM. Running 'udevadm monitor --environment kernel' there are no
kernel udev events being triggered. I've checked the following common
items, crda is installed in '/usr/sbin' (version 3.18), wireless-regdb
is installed at '/usr/lib/crda/regulatory.bin',
'/etc/modeprobe.d/cfg80211.conf' has 'options cfg80211
ieee80211_regdom=US' & I have udev rules pointing to '/usr/sbin/crda'
in both '/etc/udev/rules.d/' & '/lib/udev/rules.d/'. I have
'COUNTRY=US' set and when I run crda I get 'Failed to set regulatory
domain: -7' and with no kernel udev events in the background and no
cfg80211 messages in dmesg. Oddly if I use wpa_supplicant to connect
to an AP and then stop the wpa_sup service then cfg80211 shows up and
kenel udev messages fire and I'm able to set the reg domain via 'iw
reg set'. Any idea's on what may be going on here or what I could
check would be most appreciated.
Thanks,
Matt
^ permalink raw reply
* Re: [RFC 10/12] ath10k: Added QCA65XX hw definition
From: Erik Stromdahl @ 2016-11-15 18:34 UTC (permalink / raw)
To: Valo, Kalle, michal.kazior@tieto.com
Cc: linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <87wpg5qai1.fsf@qca.qualcomm.com>
On 11/15/2016 11:54 AM, Valo, Kalle wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 14 November 2016 at 17:33, Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/hw.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
>>> index 46142e9..ef45ecf 100644
>>> --- a/drivers/net/wireless/ath/ath10k/hw.h
>>> +++ b/drivers/net/wireless/ath/ath10k/hw.h
>>> @@ -224,6 +224,7 @@ enum ath10k_hw_rev {
>>> ATH10K_HW_QCA9377,
>>> ATH10K_HW_QCA4019,
>>> ATH10K_HW_QCA9887,
>>> + ATH10K_HW_QCA65XX,
>>
>> Are you 100% positive that you're supporting all QCA65XX chips? The
>> rule of thumb is to avoid Xs as much as possible unless totally
>> perfectly completely sure.
>
I admit that I am definitely not totally perfectly completely sure about
this :)
In fact, I don't have a clue what does numbers really mean. All I know
is that the chipset I am using is called QCA6584 which I think is an
automotive version of another chipses called QCA6574. I have tried to
google these numbers up, but it is really hard to find anything useful.
So I thought, hey, why don't I just add a few X'es in there and I have
support for both!
> But the thing is that nobody can't be absolutely sure as we never know
> what marketing comes up within few years again. So I would say that XX
> in chip names should be completely avoided to avoid any confusion. We
> already suffer from this in ath10k with QCA988X and QCA9888 which are
> different designs but the names overlap.
>
> I haven't reviewed Erik's patches yet but I'm surprised why even a new
> enum value is needed here. I was assuming we could use ATH10K_HW_QCA6174
> because AFAIK they share the same design. Any particular reason for
> this?
>
The reason for this was that the switch(hw_rev)-statement in
ath10k_core_create assigns ar->regs and ar->hw_values to structures
containing values that are not applicable for SDIO. I though that I
would potentially need other structures, but after investigating the
qca6174_regs struct, it seems that the values that are applicable for
SDIO are the same.
I will remove this enum and use ATH10K_HW_QCA6174 instead as you
propose. If for some reason I would need other regs and hw_values
structs in the future, we can figure out appropriate names then.
^ permalink raw reply
* Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Brian Norris @ 2016-11-15 18:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless, Cathy Luo, Nishant Sarmukadam,
rajatja
In-Reply-To: <20161115173507.GB22897@dtor-ws>
On Tue, Nov 15, 2016 at 09:35:07AM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote:
> > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > @@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
> > }
> > EXPORT_SYMBOL_GPL(mwifiex_do_flr);
> >
> > +static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
> > +{
> > + struct mwifiex_adapter *adapter = priv;
> > +
> > + if (adapter->irq_wakeup >= 0) {
> > + dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
> > + adapter->wake_by_wifi = true;
> > + disable_irq_nosync(irq);
> > + }
> > +
> > + /* Notify PM core we are wakeup source */
> > + pm_wakeup_event(adapter->dev, 0);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> > {
> > + int ret;
> > struct device *dev = adapter->dev;
> >
> > if (!dev->of_node)
> > return;
> >
> > adapter->dt_node = dev->of_node;
> > + adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> > + if (!adapter->irq_wakeup) {
> > + dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> > + return;
> > + }
>
> I'd rather we used of_irq_get() here, because ti allows handling
> deferrals. of_irq_get_byname() would be even better, but I guess we
> already have bindings in the wild...
This function doesn't handle errors very gracefully at all; we just try,
and if we fail, we just skip the rest...
This could be an argument for rewriting the error handling to stop just
returning -1 in mwifiex_add_card() and use real Linux error codes.
Perhaps that can be a later cleanup?
> > +
> > + ret = devm_request_irq(dev, adapter->irq_wakeup,
> > + mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
>
> irq_of_parse_and_map() (and of_irq_get()) will set trigger flags,
> why do we override them?
>
> > + "wifi_wake", adapter);
> > + if (ret) {
> > + dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
> > + adapter->irq_wakeup, ret);
> > + goto err_exit;
> > + }
> > +
> > + disable_irq(adapter->irq_wakeup);
> > + if (device_init_wakeup(dev, true)) {
> > + dev_err(dev, "fail to init wakeup for mwifiex\n");
> > + goto err_exit;
>
> Leaking interrupt (not forever, but if we are not using wakeup irq there
> is no need to have it claimed).
>
> > + }
> > + return;
> > +
> > +err_exit:
> > + adapter->irq_wakeup = 0;
> > }
>
> I also do not see anyone actually calling mwifiex_probe_of() in this
> patch?
It was added to mwifiex_add_card() in the previous patch, so all users
with a proper ->dt_node would call it.
> >
> > /*
Brian
^ permalink raw reply
* RE: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: voncken @ 2016-11-15 14:37 UTC (permalink / raw)
To: 'Ben Greear'
Cc: linux-wireless, 'OpenWrt Development List', ath10k
In-Reply-To: <581DEE2E.3010502@candelatech.com>
Hi Ben,
Do you plan to release a candelatech firmware with this fix?
Regards.
Cedric Voncken.
> -----Message d'origine-----
> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] De la part de Ben Greear
> Envoyé : samedi 5 novembre 2016 15:35
> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
> Development List; ath10k@lists.infradead.org
> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>
> Looks to me like 10.4 defaults to the right value, but possibly there
> are other issues with it. I tested my CT 10.4 and it worked OK with
> vlans for me.
>
> Thanks,
> Ben
>
> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
> > would be good if qca can fix this bug finally in all available
> > firmwares. its a very annoying issue since a long time
> >
> > Sebastian
> >
> >
> > Am 04.11.2016 um 23:23 schrieb Ben Greear:
> >> The bug appears that vlan-tx-stripping is unconditionally enabled in
> >> at least my firmware. I have re-compiled w/out that flag set, and
> it
> >> appears to work for me.
> >>
> >> Please download this firmware, rename it firmware-2.bin, make sure
> >> you remove/rename any firmware-5.bin (etc) so mine will load, and
> see if that fixes your problem.
> >>
> >> Please note that it is very likely you will have to use same MAC
> >> address for the VLAN devices that the underlying station uses in
> order for this to work.
> >>
> >> https://www.candelatech.com/downloads/tmp/firmware-2-full-
> community.b
> >> in
> >>
> >>
> >> Thanks,
> >> Ben
> >>
> >>
> >> On 11/04/2016 02:50 PM, Ben Greear wrote:
> >>> I can reproduce this in my CT firmware. I'll see if I can fix it,
> >>> but for stock firmware, it might be that changing the driver to use
> >>> Ethernet packet type of native-wifi would make .1q vlans work.
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
> >>>> I met the same problem before,
> >>>> if i modify the 1q header to other value (0xaa00) before go into
> firmware.
> >>>> I can capture the packet in the air I think the vlan packet is
> >>>> dropped in firmware.
> >>>>
> >>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
> >>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
> <openwrt@ezplanet.net> wrote:
> >>>>>> Since the capability is implemented in software you might be
> >>>>>> testing the limit of your router's CPU i/o speed.
> >>>>>
> >>>>> By loading the module in rawmode?
> >>>>>
> >>>>> The AP is an APU and Sta is an APU2.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
> >>>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Old thread but I think the issue is still present.
> >>>>>>>
> >>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
> >>>>>>>
> >>>>>>> To make it work both cards must be loaded in rawmode, AP and
> >>>>>>> Sta, and with no security.
> >>>>>>>
> >>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
> >>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
> >>>>>>>
> >>>>>>> Although it works the throughput is very bad.
> >>>>>>> Are there any alternatives to improve the throughput.
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Bruno
> >>>>>>>
> >>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Message d'origine-----
> >>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
> >>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
> >>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
> >>>>>>>>> VLAN firmware issue
> >>>>>>>>>
> >>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
> >>>>>>>>> for you in other cases as well?
> >>>>>>>>
> >>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Cedric.
> >>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Ben
> >>>>>>>>>
> >>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
> >>>>>>>>>>
> >>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
> >>>>>>>>>>
> >>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
> with eth0.
> >>>>>>>>>> I have a computer with vlan configuration set connected
> >>>>>>>>>> to the STA eth0.
> >>>>>>>>>>
> >>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
> >>>>>>>>>> are not
> >>>>>>>>
> >>>>>>>> sent.
> >>>>>>>>>>
> >>>>>>>>>> I checked with wireless sniffer, and I don't see the
> >>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
> >>>>>>>>>>
> >>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
> >>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
> >>>>>>>>>> from openwrt, and in all cases I have the same issue.
> >>>>>>>>>>
> >>>>>>>>>> Thanks for your help.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
> >>>>>>>>>> linux-wireless" in the body of a message to
> >>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
> >>>>>>>>>> http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
> >>>>>>>>> http://www.candelatech.com
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless"
> >>>>>>>> in
> >>>>>>>> the body of a message to majordomo@vger.kernel.org More
> >>>>>>>> majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> openwrt-devel mailing list
> >>>>>>> openwrt-devel@lists.openwrt.org
> >>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
> devel
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> openwrt-devel mailing list
> >>>>>> openwrt-devel@lists.openwrt.org
> >>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>>>>
> >>>>> _______________________________________________
> >>>>> ath10k mailing list
> >>>>> ath10k@lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/ath10k
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
From: Matthias Schiffer @ 2016-11-15 17:47 UTC (permalink / raw)
To: kvalo; +Cc: ath9k-devel, linux-wireless, ath9k-devel, miaoqing
Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set().
Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.
Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 14b13f0..a35f78b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
WARN_ON(1);
}
- return val;
+ return !!val;
}
EXPORT_SYMBOL(ath9k_hw_gpio_get);
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox