* Re: [v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
From: Kalle Valo @ 2017-08-30 16:50 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Daniel Golle
In-Reply-To: <20170825150414.GA9283@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
> initialize TX_PIN_CFG setting. This cause breakage at least on some
> RT3573 devices. To fix the problem patch restores previous behaviour
> for non MT7620 chips.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
> Reported-and-tested-by: Jussi Eloranta <jussi.eloranta@csun.edu>
> Cc: Daniel Golle <daniel@makrotopia.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Daniel Golle <daniel@makrotopia.org>
Patch applied to wireless-drivers-next.git, thanks.
83ec48919389 rt2800: fix TX_PIN_CFG setting for non MT7620 chips
--
https://patchwork.kernel.org/patch/9922285/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rsi: remove memset before memcpy
From: Kalle Valo @ 2017-08-30 16:51 UTC (permalink / raw)
To: Himanshu Jha
Cc: amit.karwar, linux-wireless, netdev, linux-kernel, Himanshu Jha
In-Reply-To: <1504032890-25229-1-git-send-email-himanshujha199640@gmail.com>
Himanshu Jha <himanshujha199640@gmail.com> wrote:
> calling memcpy immediately after memset with the same region of memory
> makes memset redundant.
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
66a3479e1217 rsi: remove memset before memcpy
--
https://patchwork.kernel.org/patch/9927943/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RT2870 failure in kernel 4.12.8
From: Larry Finger @ 2017-08-30 17:03 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa; +Cc: linux-wireless
Stanislaw and Helmut,
In a bug report at https://bugzilla.suse.com/show_bug.cgi?id=1055826, the OP
reports that his RT3572 fails to work after an upgrade from the openSUSE
Tumbleweed kernel 4.12.7 to 4.12.8. I checked the kernel configuration and did
not see any problems.
Are you aware of anyone reporting problems with rt2800usb in 4.12.8 kernels?
Thanks,
Larry
^ permalink raw reply
* [PATCH] rtlwifi: refactor code in halbtcoutsrc module
From: Gustavo A. R. Silva @ 2017-08-30 16:46 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
Function halbtc_get_wifi_rssi always returns rtlpriv->dm.undec_sm_pwdb.
So this function can be removed and the value of
rtlpriv->dm.undec_sm_pwdb assigned to *s32_tmp directly.
This issue was first reported by Coverity as "identical code for different
branches" in function halbtc_get_wifi_rssi.
Addresses-Coverity-ID: 1226793
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
This code was reported by Coverity and it was tested by compilation only.
Chances are this may be a copy/paste error in function
halbtc_get_wifi_rssi. Please, verify.
Also, notice this code has been there since 2014.
.../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index c1eacd8..2a47b97 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -373,17 +373,6 @@ u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)
return ret_val;
}
-static s32 halbtc_get_wifi_rssi(struct rtl_priv *rtlpriv)
-{
- int undec_sm_pwdb = 0;
-
- if (rtlpriv->mac80211.link_state >= MAC80211_LINKED)
- undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
- else /* associated entry pwdb */
- undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
- return undec_sm_pwdb;
-}
-
static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf)
{
struct btc_coexist *btcoexist = (struct btc_coexist *)void_btcoexist;
@@ -479,7 +468,7 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf)
*bool_tmp = false;
break;
case BTC_GET_S4_WIFI_RSSI:
- *s32_tmp = halbtc_get_wifi_rssi(rtlpriv);
+ *s32_tmp = rtlpriv->dm.undec_sm_pwdb;
break;
case BTC_GET_S4_HS_RSSI:
*s32_tmp = 0;
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
From: Gustavo A. R. Silva @ 2017-08-30 16:51 UTC (permalink / raw)
To: Larry Finger, Pkshih, Kalle Valo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <eef42b52-ae7b-e574-237f-209ac8ec033c@lwfinger.net>
Hi Larry,
On 08/30/2017 11:37 AM, Larry Finger wrote:
> On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote:
>> Refactor code in order to avoid identical code for different branches.
>>
>> This issue was detected with the help of Coccinelle.
>>
>> Addresses-Coverity-ID: 1226788
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> This issue was reported by Coverity and it was tested by compilation
>> only.
>> I'm suspicious this may be a copy/paste error. Please, verify.
>
> I have referred this change to the engineers at Realtek. For the moment,
> please hold this patch.
>
> Thanks for reporting the condition.
>
Glad to help. :)
--
Gustavo A. R. Silva
^ permalink raw reply
* [PATCH] rtlwifi: rtl8723be: fix duplicated code for different branches
From: Gustavo A. R. Silva @ 2017-08-30 17:04 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
Refactor code in order to avoid identical code for different branches.
Addresses-Coverity-ID: 1248728
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
This issue was reported by Coverity and it was tested by compilation only.
Please, verify if this is not a copy/paste error.
Also, notice this code has been there since 2014.
drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
index 131c0d1..15c117e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
@@ -883,12 +883,8 @@ static void rtl8723be_dm_txpower_tracking_callback_thermalmeter(
if ((rtldm->power_index_offset[RF90_PATH_A] != 0) &&
(rtldm->txpower_track_control)) {
rtldm->done_txpower = true;
- if (thermalvalue > rtlefuse->eeprom_thermalmeter)
- rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
- index_for_channel);
- else
- rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
- index_for_channel);
+ rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
+ index_for_channel);
rtldm->swing_idx_cck_base = rtldm->swing_idx_cck;
rtldm->swing_idx_ofdm_base[RF90_PATH_A] =
--
2.5.0
^ permalink raw reply related
* Re: [PATCH 00/27] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: Igor Mitsyanko @ 2017-08-30 18:20 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <87ziahni8p.fsf@purkki.adurom.net>
On 08/30/2017 09:16 AM, Kalle Valo wrote:
>
> igor.mitsyanko.os@quantenna.com writes:
>
>> This patchset has a goal to make operational parameters (channel, BW,
>> HT/VHT capabilities) configuration possible for qtnfmac driver.
>> Basically the idea is to make driver level as thin as possible, and let
>> everything to be handled by userspace/nl80211 and wireless device itself.
>
> This patchset is just too big and pain to review. Preferably no more
> than 10-12 patches per set, please. If the patches bigger then the limit
> should be even lower.
Sure, will split in 3 patchsets then.
>
> --
> Kalle Valo
>
^ permalink raw reply
* Re: [PATCH 00/27] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: Igor Mitsyanko @ 2017-08-30 18:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <87r2vtnho6.fsf@purkki.adurom.net>
On 08/30/2017 09:28 AM, Kalle Valo wrote:
>
> External Email
>
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>>> igor.mitsyanko.os@quantenna.com writes:
>>>
>>>> This patchset has a goal to make operational parameters (channel, BW,
>>>> HT/VHT capabilities) configuration possible for qtnfmac driver.
>>>> Basically the idea is to make driver level as thin as possible, and let
>>>> everything to be handled by userspace/nl80211 and wireless device itself.
>>>
>>> This patchset is just too big and pain to review. Preferably no more
>>> than 10-12 patches per set, please. If the patches bigger then the limit
>>> should be even lower.
>>
>> And I noticed that patch 25 didn't make it to patchwork:
>>
>> https://patchwork.kernel.org/project/linux-wireless/list/?state=*&q=qtnfmac
>
> Actually it did but it was an nl80211 patch:
>
> https://patchwork.kernel.org/patch/9921179/
>
> Never ever hide mac80211 or cfg80211 patches within driver patches like
> this. They need to be submitted separately so that everyone sees them.
>
> In some cases it makes sense to submit the driver patches using the new
> cfg80211/mac80211 feature at the same, but then do it so that you have
> the cfg80211/mac80211 patches and the corresponding driver patches as
> last. In that case I assign the whole patchset first to Johannes and
> once he has applied the cfg80211/mac80211 patches he assigns the driver
> patches to me.
Ok, understood.
>
> --
> Kalle Valo
>
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Log chip id and revision
From: Arend van Spriel @ 2017-08-30 18:49 UTC (permalink / raw)
To: Hans de Goede, Kalle Valo; +Cc: linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <20170830135449.1075-1-hdegoede@redhat.com>
On 30-08-17 15:54, Hans de Goede wrote:
> For debugging some problems, it is useful to know the chip revision
> add a brcmf_info message logging this.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> -Put the brcmf_info in brcmf_fw_map_chip_to_name() so that it works for
> e.g. pcie devices too
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 3 +++
> 1 file changed, 3 insertions(+)
^ permalink raw reply
* [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
From: Ganapathi Bhat @ 2017-08-30 18:46 UTC (permalink / raw)
To: linux-wireless
Cc: Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, Ganapathi Bhat
If driver is loaded with 'mfg_mode' enabled, then the sending
commands are not allowed. So, when mwifiex_send_cmd fails in
mwifiex_add_virtual_intf, driver must check for 'mfg_mode' before
returning error.
Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added interface")
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index ffada17..1856205 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2967,11 +2967,11 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE,
HostCmd_ACT_GEN_SET, 0, NULL, true);
- if (ret)
+ if (ret && !adapter->mfg_mode)
goto err_set_bss_mode;
ret = mwifiex_sta_init_cmd(priv, false, false);
- if (ret)
+ if (ret && !adapter->mfg_mode)
goto err_sta_init;
mwifiex_setup_ht_caps(&wiphy->bands[NL80211_BAND_2GHZ]->ht_cap, priv);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 01/30] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
From: Arend van Spriel @ 2017-08-30 18:51 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-2-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> All the other IO functions are the other way round in this
> driver. Make this one match.
Sorry for being a nit, but not sure why the commit message starts with a
tab.
Other than that...
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH 03/30] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
From: Arend van Spriel @ 2017-08-30 18:59 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-4-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> This large function is concealing a LOT of obscure logic about
> how the hardware functions. Time to split it up.
Again the tab. Guess it is your default ;-)
> This first patch splits the function into two pieces - read and write,
> doing away with the rw flag in the process.
>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 94 +++++++++++++++++-----
> 1 file changed, 73 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 2b441ce91d5f..1ee0f91b6c50 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -302,8 +302,8 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn,
> return ret;
> }
>
> -static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
> - u8 regsz, void *data, bool write)
> +static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
> + u8 regsz, void *data)
Thought I mentioned this before, but the indentation should be aligned
to opening bracket.
> {
> u8 func;
> s32 retry = 0;
[...]
> +
> +static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
> + u8 regsz, void *data)
dito here.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 12/30] brcmfmac: Whitespace fixes.
From: Arend van Spriel @ 2017-08-30 19:05 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-13-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
Maybe mention the function you are making whitespace changes in as it
involves only one here.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 916f75e5e7a1..d5d2b2222cc1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -713,6 +713,7 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
> int err;
>
> mypkt = brcmu_pkt_buf_get_skb(nbytes);
> +
> if (!mypkt) {
> brcmf_err("brcmu_pkt_buf_get_skb failed: len %d\n",
> nbytes);
> @@ -727,8 +728,8 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes)
> err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt);
>
> brcmu_pkt_buf_free_skb(mypkt);
> - return err;
>
> + return err;
> }
>
> int brcmf_sdiod_send_pkt(struct brcmf_sdio_dev *sdiodev,
>
^ permalink raw reply
* Re: [PATCH 13/30] brcmfmac: Clarify if using braces.
From: Arend van Spriel @ 2017-08-30 19:11 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-14-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> Whilst this if () statement is technically correct, it lacks clarity.
I don't see the unclarity here. In my opinion people reading the code
should have a good level in C language and a decent level of curiosity
when they come across a function/macro like skb_queue_walk().
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 15/30] brcmfmac: Tidy register definitions a little
From: Arend van Spriel @ 2017-08-30 19:13 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-16-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> Trivial tidy of register definitions.
Thought I already did, but....
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 ++--
> .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 19 ++++++++++---------
> 2 files changed, 12 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()
From: Arend van Spriel @ 2017-08-30 19:32 UTC (permalink / raw)
To: Ian Molton, linux-wireless; +Cc: franky.lin, hante.meuleman
In-Reply-To: <1cad185b-a720-9c13-0c45-43240803162f@mnementh.co.uk>
On 19-08-17 22:02, Ian Molton wrote:
> On 07/08/17 18:51, Ian Molton wrote:
>> On 07/08/17 12:25, Arend van Spriel wrote:
>>>> Handling of -ENOMEDIUM is altered, but as that's pretty much broken
>>>> anyway
>>>> we can ignore that.
>>>
>>> Please explain why you think it is broken.
>>
>> Not got the code to hand right now, but from memory, theres a trapdoor
>> case where the state can wind up set to something that prevents it ever
>> being changed again. I'll dig it up when I get back from holiday (this
>> next few days).
>
> Hi,
>
> Here is the function I had in mind:
>
>
> void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev,
> enum brcmf_sdiod_state state)
> {
> if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM ||
> state == sdiodev->state)
> return;
>
> brcmf_dbg(TRACE, "%d -> %d\n", sdiodev->state, state);
> switch (sdiodev->state) {
> case BRCMF_SDIOD_DATA:
> /* any other state means bus interface is down */
> brcmf_bus_change_state(sdiodev->bus_if, BRCMF_BUS_DOWN);
> break;
> case BRCMF_SDIOD_DOWN:
> /* transition from DOWN to DATA means bus interface is up */
> if (state == BRCMF_SDIOD_DATA)
> brcmf_bus_change_state(sdiodev->bus_if,
> BRCMF_BUS_UP);
> break;
> default:
> break;
> }
> sdiodev->state = state;
> }
>
>
> If it's *ever* called with state = BRCMF_SDIOD_NOMEDIUM it will
> eventually (last line) set sdiodev->state to the same value.
>
> If its ever called again, the first if() statement will make it return
> before ever changing sdiodev->state again, no matter what value is
> passed for state.
>
> This has to be a bug, surely?
I thought I already responded this email. So it is not a bug. It really
was made like this intentional. It is the end state of this little FSM.
The thing is that there was no way to recover. Maybe nowadays with the
MMC stack being able to power sequence the device (provided it is
properly configured in device tree) we may get lucky using
mmc_hw_reset(). But now you need to consider how many times to call that
before giving up and what driver components/states need to be reset as
well. So I would prefer to keep the current behavior until a more
graceful approach has been designed and implemented to replace it.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 18/30] brcmfmac: Cleanup offsetof()
From: Arend van Spriel @ 2017-08-30 19:37 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-19-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> Create a macro to make the code a bit more readable, whilst we're stuck
> with using struct element offsets as register offsets.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 35 +++++++++-------------
> 1 file changed, 14 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index ce19ccf5d1d6..8f3e99da871a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -161,6 +161,8 @@ struct rte_console {
>
> #define CORE_BUS_REG(base, field) \
> (base + offsetof(struct sdpcmd_regs, field))
> +#define __sd_reg(field) \
> + (offsetof(struct sdpcmd_regs, field))
I really dislike __foo() stuff. Please just stick with uppercase for
macros, so SD_REG(). I am fine with dropping the base here.
^ permalink raw reply
* Re: rfkill(8) move and improvements
From: Sami Kerola @ 2017-08-30 19:40 UTC (permalink / raw)
To: Karel Zak; +Cc: Johannes Berg, Marcel Holtmann, linux-wireless, util-linux
In-Reply-To: <alpine.LNX.2.20.1707010956520.7939@imuri>
On 1 July 2017 at 10:06, Sami Kerola <kerolasa@iki.fi> wrote:
> I did couple last minute changes to my remote branch, that should now be
> ready for final review.
>
> git://github.com/kerolasa/lelux-utiliteetit.git rfkill
Hello,
It's been a while. I did not get any review feedback, so I assume changes
were ok. Would it be possible to move forward with the merge to
util-linux upstream?
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply
* Re: [PATCH 19/30] brcmfmac: Remove unused macro.
From: Arend van Spriel @ 2017-08-30 19:40 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-20-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> This macro is used exactly nowhere in the code. Delete it.
this removal could have been done in previous patch making that one a
rename/change of the macro. Anyway....
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 --
> 1 file changed, 2 deletions(-)
^ permalink raw reply
* [PATCH] mwifiex: notify cfg80211 about scan abort
From: Ganapathi Bhat @ 2017-08-30 19:38 UTC (permalink / raw)
To: linux-wireless
Cc: Brian Norris, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, Ganapathi Bhat
Driver sends a series of scan commands to firmware to serve a
user scan request. If an intermediate scan command fails, driver
aborts the scan but it is not being informed to cfg80211. This
will cause issues in applications performing periodic scans.
Fix this by informing scan abort.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 0fba5b1..1bd4e13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -70,11 +70,7 @@
break;
case HostCmd_CMD_802_11_SCAN:
case HostCmd_CMD_802_11_SCAN_EXT:
- mwifiex_cancel_pending_scan_cmd(adapter);
-
- spin_lock_irqsave(&adapter->mwifiex_cmd_lock, flags);
- adapter->scan_processing = false;
- spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, flags);
+ mwifiex_cancel_scan(adapter);
break;
case HostCmd_CMD_MAC_CONTROL:
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 20/30] brcmfmac: Remove repeated calls to brcmf_chip_get_core()
From: Arend van Spriel @ 2017-08-30 19:42 UTC (permalink / raw)
To: Ian Molton, linux-wireless
In-Reply-To: <20170822112550.60311-21-ian@mnementh.co.uk>
On 22-08-17 13:25, Ian Molton wrote:
> There is no need to repeatdly call brcmf_chip_get_core(), which
> traverses a list of cores every time its called (including during
> register access code!).
>
> Call it once, and store a pointer to the core structure. The existing
> code does nto keep track of users of the cores anyway, and even so, this
> will allow for easier refcounting in future.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Ian Molton <ian@mnementh.co.uk>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 25 +++++++++++++---------
> 1 file changed, 15 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 0/2] mwifiex: address URB submission failure
From: Ganapathi Bhat @ 2017-08-30 19:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Ganapathi Bhat
This patch series fixes a driver issue with USB interface. When
URB submission fails due to skb allocation, it is retried in
main thread.
Ganapathi Bhat (1):
mwifiex: print URB submit failure error after threshold attemtps
James Cao (1):
mwifiex: resubmit failed to submit RX URBs in main thread
drivers/net/wireless/marvell/mwifiex/main.c | 11 +++++++++++
drivers/net/wireless/marvell/mwifiex/usb.c | 11 +++++++++--
drivers/net/wireless/marvell/mwifiex/usb.h | 2 ++
3 files changed, 22 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] mwifiex: resubmit failed to submit RX URBs in main thread
From: Ganapathi Bhat @ 2017-08-30 19:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Ganapathi Bhat
In-Reply-To: <1504122674-3379-1-git-send-email-gbhat@marvell.com>
From: James Cao <jcao@marvell.com>
Current driver has 6 Rx data URBs. Once any packet received
kernel calls our callback, in which the same URB will be
resubmitted after Rx indication. In URB submission function a new
skb will be allocated since the previous one is passed to upper
layer (freed later). Since the skb is from a special pool (not
regular memory), skb allocation may fail when kernel holds a lot
of Rx packets on some low resource platforms. The URB will not be
resubmitted in this no free skb case. If driver fails to resubmit
all 6 URBs, Rx will stop. To cover this scenario check and
resubmit Rx URBs in main thread.
Signed-off-by: James Cao <jcao@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b73..c78014b 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -247,6 +247,7 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
{
int ret = 0;
unsigned long flags;
+ struct usb_card_rec *usb_card;
spin_lock_irqsave(&adapter->main_proc_lock, flags);
@@ -278,6 +279,16 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
break;
}
+ /* Try to resubmit RX URB if sunmission failed earlier */
+ if (!atomic_read(&adapter->rx_pending) &&
+ adapter->iface_type == MWIFIEX_USB) {
+ usb_card = adapter->card;
+ if (atomic_read(&usb_card->rx_data_urb_pending) <
+ MWIFIEX_RX_DATA_URB &&
+ adapter->if_ops.submit_rem_rx_urbs)
+ adapter->if_ops.submit_rem_rx_urbs(adapter);
+ }
+
/* Handle pending interrupt if any */
if (adapter->int_status) {
if (adapter->hs_activated)
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
From: Ganapathi Bhat @ 2017-08-30 19:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Ganapathi Bhat
In-Reply-To: <1504122674-3379-1-git-send-email-gbhat@marvell.com>
Current driver prints dev_alloc_skb failures everytime while
submitting RX URBs. This failure might be frequent in some
low resource platforms. So, wait for a threshold failure
count before start priting the error. This change is a follow
up for the 'commit 7b368e3d15c3
("mwifiex: resubmit failed to submit RX URBs in main thread")'
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/usb.c | 11 +++++++++--
drivers/net/wireless/marvell/mwifiex/usb.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index f4f2b9b..98f6973 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -300,9 +300,16 @@ static int mwifiex_usb_submit_rx_urb(struct urb_context *ctx, int size)
if (card->rx_cmd_ep != ctx->ep) {
ctx->skb = dev_alloc_skb(size);
if (!ctx->skb) {
- mwifiex_dbg(adapter, ERROR,
- "%s: dev_alloc_skb failed\n", __func__);
+ if (++card->rx_urb_failure_count >
+ MWIFIEX_RX_URB_FAILURE_THRESHOLD) {
+ mwifiex_dbg(adapter, ERROR,
+ "%s: dev_alloc_skb failed, failure count = %u\n",
+ __func__,
+ card->rx_urb_failure_count);
+ }
return -ENOMEM;
+ } else {
+ card->rx_urb_failure_count = 0;
}
}
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.h b/drivers/net/wireless/marvell/mwifiex/usb.h
index 37abd22..dc4750b 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.h
+++ b/drivers/net/wireless/marvell/mwifiex/usb.h
@@ -43,6 +43,7 @@
#define MWIFIEX_TX_DATA_URB 6
#define MWIFIEX_RX_DATA_URB 6
#define MWIFIEX_USB_TIMEOUT 100
+#define MWIFIEX_RX_URB_FAILURE_THRESHOLD 20
#define USB8766_DEFAULT_FW_NAME "mrvl/usb8766_uapsta.bin"
#define USB8797_DEFAULT_FW_NAME "mrvl/usb8797_uapsta.bin"
@@ -117,6 +118,7 @@ struct usb_card_rec {
u8 rx_cmd_interval;
int tx_cmd_ep_type;
u8 tx_cmd_interval;
+ u32 rx_urb_failure_count;
};
struct fw_header {
--
1.9.1
^ permalink raw reply related
* [PATCH] nl80211: look for HT/VHT capabilities in beacon's tail
From: igor.mitsyanko.os @ 2017-08-30 20:52 UTC (permalink / raw)
To: linux-wireless, johannes; +Cc: sergey.matyukevich.os, avinashp
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
There are no HT/VHT capabilities in cfg80211_ap_settings::beacon_ies,
these should be looked for in beacon's tail instead.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
This is true for hostapd (at least the one in mainline): it does not
include HT/VHT caps and WLAN_EID_SUPP_RATES into beacon_ies.
But worth noting that there is no clear documentation that I could find
on what IEs could and could not be included into beacon_ies.
net/wireless/nl80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ce8542..0df8023 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3791,8 +3791,8 @@ static void nl80211_check_ap_rate_selectors(struct cfg80211_ap_settings *params,
static void nl80211_calculate_ap_params(struct cfg80211_ap_settings *params)
{
const struct cfg80211_beacon_data *bcn = ¶ms->beacon;
- size_t ies_len = bcn->beacon_ies_len;
- const u8 *ies = bcn->beacon_ies;
+ size_t ies_len = bcn->tail_len;
+ const u8 *ies = bcn->tail;
const u8 *rates;
const u8 *cap;
--
2.9.5
^ 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