* Re: [PATCH 01/30] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
From: Ian Molton @ 2017-08-31 15:17 UTC (permalink / raw)
To: Arend van Spriel, linux-wireless
In-Reply-To: <4a840cca-d07a-15a7-7d31-b8269bb9feb3@broadcom.com>
On 30/08/17 19:51, Arend van Spriel wrote:
> 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.
Not a problem - I don't mind nits being pointed out. Not at all.
> Other than that...
Will update it in the next (hopefully last!) rev.
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Ta :)
>> 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(-)
-Ian
^ permalink raw reply
* Re: [PATCH 03/30] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
From: Ian Molton @ 2017-08-31 15:19 UTC (permalink / raw)
To: Arend van Spriel, linux-wireless
In-Reply-To: <91172916-24b6-a52a-8ef2-ab891fcce5a0@broadcom.com>
On 30/08/17 19:59, Arend van Spriel wrote:
>> +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.
I checked this locally, and its fine. I suspect its getting mangled
somewhere along the way.
It looks fine in my original email - I see 4 tabs and a space.
-Ian
^ permalink raw reply
* Re: [PATCH] rtlwifi: refactor code in halbtcoutsrc module
From: Larry Finger @ 2017-08-31 15:25 UTC (permalink / raw)
To: Gustavo A. R. Silva, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20170830164602.GA16413@embeddedgus>
On 08/30/2017 11:46 AM, Gustavo A. R. Silva wrote:
> 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.
The value of *s32_tmp is not dependent on the link state, thus this patch is
correct, but I request that it be changed. Future developments will modify
halbtc_get_wifi_rssi() making it more complicated and not as easily inlined as
this patch. In short, if you remove it here, we will have to add it later.
Thanks,
Larrt
>
> .../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;
>
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Larry Finger @ 2017-08-31 15:33 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <20170831075514.GA12340@redhat.com>
On 08/31/2017 02:55 AM, Stanislaw Gruszka wrote:
> I think it is the issue addressed by this 4.12 patch:
> https://marc.info/?l=linux-wireless&m=150366111408179&w=2
>
> Patch for 4.13+ kernels is here:
> https://marc.info/?l=linux-wireless&m=150367345912061&w=2
A potential problem with this solution is that commit 41977e86c984 ("rt2x00: add
support for MT7620") has been in the kernel since 4.12.0, but the openSUSE
problem was reported not to occur until 4.12.8. I have asked that this patch be
applied to the openSUSE source and a special test kernel be generated for our
OP. I will let you know what develops. I do not have the necessary hardware to
do the test in house.
Should the patch to wireless-drivers be annotated with a Stable reference so
that it is added to 4.12 and 4.13?
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH 13/30] brcmfmac: Clarify if using braces.
From: Ian Molton @ 2017-08-31 15:35 UTC (permalink / raw)
To: Arend van Spriel, linux-wireless
In-Reply-To: <78917893-6b3d-9cfc-1f32-e27226ae6189@broadcom.com>
On 30/08/17 20:11, Arend van Spriel 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().
I thought it to be part of the general codingstyle for the kernel that
multi-line ifs and elses should be in braces, although I accept that
technically the if-clause is a single block-level statement.
Having said that, *this* specific example falls into a grey area in the
codingstyle, which covers multi-statement, multi-line if() clauses and
single-statement, single-line ones. It does not cover single-statement,
multi-line examples such as the one here.
Whilst I can't therefore definitively justify my position, I can show,
for example, line 999 in net/mac80211/iface.c where a for() statement
uses braces around the skb_queue_walk()
for (i = 0; i < IEEE80211_MAX_QUEUES; i++) {
skb_queue_walk_safe(&local->pending[i], skb, tmp) {
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
if (info->control.vif == &sdata->vif) {
__skb_unlink(skb, &local->pending[i]);
ieee80211_free_txskb(&local->hw, skb);
}
}
}
And the following in ath9k_htc_tx_cleanup_queue()
if (process) {
skb_queue_walk_safe(&queue, skb, tmp) {
__skb_unlink(skb, &queue);
ath9k_htc_tx_process(priv, skb, NULL);
}
}
So I feel that we should do the same.
-Ian
^ permalink raw reply
* Re: [PATCH 18/30] brcmfmac: Cleanup offsetof()
From: Ian Molton @ 2017-08-31 15:37 UTC (permalink / raw)
To: Arend van Spriel, linux-wireless
In-Reply-To: <c4412aaa-1c66-44d5-1f0b-cc208aad7e60@broadcom.com>
On 30/08/17 20:37, Arend van Spriel wrote:
> On 22-08-17 13:25, Ian Molton wrote:
>> +#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.
I'm fine with that. Will change.
-Ian
^ permalink raw reply
* Re: [PATCH] wl1251: add a missing spin_lock_init()
From: David Miller @ 2017-08-31 17:33 UTC (permalink / raw)
To: pavel
Cc: kvalo, torvalds, xiyou.wangcong, akpm, netdev, linux-kernel,
linux-wireless
In-Reply-To: <20170831144743.GA21261@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Thu, 31 Aug 2017 16:47:43 +0200
> Dave, Linus -- can you still take the patch?
Pavel, please do not bypass maintainers like this.
It's really rude, and if you do things like that instead of
trying to work properly with us, your relationship with
these maintainers will suffer in the long term.
Thank you.
^ permalink raw reply
* Re: [v3,1/2] ath10k: add the PCI PM core suspend/resume ops
From: Kalle Valo @ 2017-08-31 18:18 UTC (permalink / raw)
To: ryanhsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1503438455-6133-1-git-send-email-ryanhsu@qti.qualcomm.com>
ryanhsu@qti.qualcomm.com wrote:
> The actual PCI suspend/resume in ath10k has been handled in wow.c,
> but in the case of the device doesn't support remote wakeup,
> the .hif_suspend() and .hif_resume() will never be handled.
>
> ath10k_wow_op_suspend()
> {
> if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
> ar->running_fw->fw_file.fw_features))) {
> ret = 1;
> goto exit;
> }
>
> ....
>
> ret = ath10k_hif_suspend(ar);
> }
>
> So register the PCI PM core to support the suspend/resume if the device
> doesn't support remote wakeup.
>
> Signed-off-by: Ryan Hsu <ryanhsu@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
32faa3f0ee50 ath10k: add the PCI PM core suspend/resume ops
393b706cf20c ath10k: configure and enable the wakeup capability
--
https://patchwork.kernel.org/patch/9916215/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wl1251: add a missing spin_lock_init()
From: Pavel Machek @ 2017-08-31 18:57 UTC (permalink / raw)
To: David Miller
Cc: kvalo, torvalds, xiyou.wangcong, akpm, netdev, linux-kernel,
linux-wireless
In-Reply-To: <20170831.103305.1809212990680774811.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]
Hi!
> From: Pavel Machek <pavel@ucw.cz>
> Date: Thu, 31 Aug 2017 16:47:43 +0200
>
> > Dave, Linus -- can you still take the patch?
>
> Pavel, please do not bypass maintainers like this.
>
> It's really rude, and if you do things like that instead of
> trying to work properly with us, your relationship with
> these maintainers will suffer in the long term.
Do you mean I'm being rude to Kalle, or rude to you?
In the part you snipped, Kalle asked me to do just that:
# I'm not planning to submit pull requests to 4.13 anymore. If you think
# this is so important that it needs to be applied in the last minute (I
# don't) you could always try to convince Dave to take it directly.
..and as I still believe patch should go in, that's what I did.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] wl1251: add a missing spin_lock_init()
From: David Miller @ 2017-08-31 19:26 UTC (permalink / raw)
To: pavel
Cc: kvalo, torvalds, xiyou.wangcong, akpm, netdev, linux-kernel,
linux-wireless
In-Reply-To: <20170831185718.GA31245@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Thu, 31 Aug 2017 20:57:19 +0200
> Hi!
>
>> From: Pavel Machek <pavel@ucw.cz>
>> Date: Thu, 31 Aug 2017 16:47:43 +0200
>>
>> > Dave, Linus -- can you still take the patch?
>>
>> Pavel, please do not bypass maintainers like this.
>>
>> It's really rude, and if you do things like that instead of
>> trying to work properly with us, your relationship with
>> these maintainers will suffer in the long term.
>
> Do you mean I'm being rude to Kalle, or rude to you?
He said "to David", not "David and Linus".
^ permalink raw reply
* Re: [PATCH] wl1251: add a missing spin_lock_init()
From: Pavel Machek @ 2017-08-31 19:59 UTC (permalink / raw)
To: David Miller
Cc: kvalo, torvalds, xiyou.wangcong, akpm, netdev, linux-kernel,
linux-wireless
In-Reply-To: <20170831.122645.872320547726000124.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Hi!
On Thu 2017-08-31 12:26:45, David Miller wrote:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Thu, 31 Aug 2017 20:57:19 +0200
>
> > Hi!
> >
> >> From: Pavel Machek <pavel@ucw.cz>
> >> Date: Thu, 31 Aug 2017 16:47:43 +0200
> >>
> >> > Dave, Linus -- can you still take the patch?
> >>
> >> Pavel, please do not bypass maintainers like this.
> >>
> >> It's really rude, and if you do things like that instead of
> >> trying to work properly with us, your relationship with
> >> these maintainers will suffer in the long term.
> >
> > Do you mean I'm being rude to Kalle, or rude to you?
>
> He said "to David", not "David and Linus".
Ok. If I knew you would be replying so quickly, I'd acted
differently. I did not want to be rude.
But I'd still like to get the patch in. Do you plan to send another
pull request to Linus, and can you take the patch, please?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] wl1251: add a missing spin_lock_init()
From: David Miller @ 2017-08-31 20:10 UTC (permalink / raw)
To: pavel
Cc: kvalo, torvalds, xiyou.wangcong, akpm, netdev, linux-kernel,
linux-wireless
In-Reply-To: <20170831195933.GA2788@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Thu, 31 Aug 2017 21:59:33 +0200
> Do you plan to send another pull request to Linus, and can you take
> the patch, please?
Yes and yes.
^ permalink raw reply
* Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
From: Brian Norris @ 2017-08-31 20:21 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare
In-Reply-To: <1504118818-1749-1-git-send-email-gbhat@marvell.com>
On Thu, Aug 31, 2017 at 12:16:58AM +0530, Ganapathi Bhat wrote:
> 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)
It doesn't feel like ignoring errors is the best approach here,
especially when it's only a single command that we could easily just
skip.
So, why don't you just skip it, like this?
if (!adapter->mfg_mode) {
ret = mwifiex_send_cmd(...);
if (ret)
goto err_set_bss_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;
Same here; I think it's safe to just completely skip
mwifiex_sta_init_cmd(), no?
Brian
>
> mwifiex_setup_ht_caps(&wiphy->bands[NL80211_BAND_2GHZ]->ht_cap, priv);
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] ath9k: remove cast to void pointer
From: Joe Perches @ 2017-08-31 21:29 UTC (permalink / raw)
To: Himanshu Jha, kvalo; +Cc: ath9k-devel, linux-wireless, netdev, linux-kernel
In-Reply-To: <1504184863-9732-1-git-send-email-himanshujha199640@gmail.com>
On Thu, 2017-08-31 at 18:37 +0530, Himanshu Jha wrote:
> casting to void pointer from any pointer type and vice-versa is done
> implicitly and therefore casting is not needed in such a case.
You said you were going to remember to mention the tool
and script that did this.
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: fix long debug print
From: Joe Perches @ 2017-08-31 21:57 UTC (permalink / raw)
To: Luca Coelho, kvalo; +Cc: linux-wireless, Liad Kaufman, Luca Coelho
In-Reply-To: <20170825082730.31388-2-luca@coelho.fi>
On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> From: Liad Kaufman <liad.kaufman@intel.com>
>
> There is a debug print that sometimes reaches over
> 110 chars, thus generating a warning in those cases.
What emits a warning here?
^ permalink raw reply
* [PATCH 13/31] timer: Remove meaningless .data/.function assignments
From: Kees Cook @ 2017-08-31 23:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Krzysztof Halasa, Aditya Shankar, Ganesh Krishna,
Greg Kroah-Hartman, Jens Axboe, netdev, linux-wireless, devel,
linux-kernel
In-Reply-To: <1504222183-61202-1-git-send-email-keescook@chromium.org>
Several timer users needlessly reset their .function/.data fields during
their timer callback, but nothing else changes them. Some users do not
use their .data field at all. Each instance is removed here.
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Aditya Shankar <aditya.shankar@microchip.com>
Cc: Ganesh Krishna <ganesh.krishna@microchip.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jens Axboe <axboe@fb.com>
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/block/amiflop.c | 3 +--
drivers/net/wan/hdlc_cisco.c | 2 --
drivers/net/wan/hdlc_fr.c | 2 --
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +---
4 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index c4b1cba27178..6680d75bc857 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -323,7 +323,7 @@ static void fd_deselect (int drive)
}
-static void motor_on_callback(unsigned long nr)
+static void motor_on_callback(unsigned long ignored)
{
if (!(ciaa.pra & DSKRDY) || --on_attempts == 0) {
complete_all(&motor_on_completion);
@@ -344,7 +344,6 @@ static int fd_motor_on(int nr)
fd_select(nr);
reinit_completion(&motor_on_completion);
- motor_on_timer.data = nr;
mod_timer(&motor_on_timer, jiffies + HZ/2);
on_attempts = 10;
diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index c696d42f4502..6c98d85f2773 100644
--- a/drivers/net/wan/hdlc_cisco.c
+++ b/drivers/net/wan/hdlc_cisco.c
@@ -276,8 +276,6 @@ static void cisco_timer(unsigned long arg)
spin_unlock(&st->lock);
st->timer.expires = jiffies + st->settings.interval * HZ;
- st->timer.function = cisco_timer;
- st->timer.data = arg;
add_timer(&st->timer);
}
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index de42faca076a..7da2424c28a4 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -644,8 +644,6 @@ static void fr_timer(unsigned long arg)
state(hdlc)->settings.t391 * HZ;
}
- state(hdlc)->timer.function = fr_timer;
- state(hdlc)->timer.data = arg;
add_timer(&state(hdlc)->timer);
}
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 68fd5b3b8b2d..2fca2b017093 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -275,7 +275,7 @@ static void update_scan_time(void)
last_scanned_shadow[i].time_scan = jiffies;
}
-static void remove_network_from_shadow(unsigned long arg)
+static void remove_network_from_shadow(unsigned long unused)
{
unsigned long now = jiffies;
int i, j;
@@ -296,7 +296,6 @@ static void remove_network_from_shadow(unsigned long arg)
}
if (last_scanned_cnt != 0) {
- hAgingTimer.data = arg;
mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME));
}
}
@@ -313,7 +312,6 @@ static int is_network_in_shadow(struct network_info *pstrNetworkInfo,
int i;
if (last_scanned_cnt == 0) {
- hAgingTimer.data = (unsigned long)user_void;
mod_timer(&hAgingTimer, jiffies + msecs_to_jiffies(AGING_TIME));
state = -1;
} else {
--
2.7.4
^ permalink raw reply related
* [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
From: Eric Bentley @ 2017-08-31 23:37 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: arend.vanspriel@broadcom.com
DQpSZXR1cm4gZXJyb3Igd2hlbiBmYWlsaW5nIHRvIHNldCBwb3dlciBtYW5hZ2VtZW50IGNhcGFi
aWxpdGllcyBmbGFnLiAgVGhpcyB3aWxsIGNhdXNlIHRoZSBzdXNwZW5kIHRvIGZhaWwgYnV0IHRo
ZSByYWRpbw0Kd2lsbCBjb250aW51ZSB0byBvcGVyYXRlLiAgQWxsb3dpbmcgdGhpcyB0byBmYWls
IHdpdGhvdXQgcmVwb3J0aW5nIGVycm9yIHdpbGwgY2F1c2UgdGhlIHJhZGlvIHRvIGJlIG5vbi1m
dW5jdGlvbmFsIG9uIA0KcmVzdW1lIGFzIGl0IHdpbGwgaGF2ZSBsb3N0IHBvd2VyLg0KDQpTaWdu
ZWQtb2ZmLWJ5OiBFcmljIEJlbnRsZXkgPGVyaWMuYmVudGxleUBsYWlyZHRlY2guY29tPg0KDQot
LS0NCiBkcml2ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNt
c2RoLmMgfCA0ICsrKy0NCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAxIGRlbGV0
aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9icmNt
ODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9i
cmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMNCmluZGV4IDcyMTM5YjUuLjJmN2QwM2YgMTAwNjQ0
DQotLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMv
YmNtc2RoLmMNCisrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2Jyb2FkY29tL2JyY204MDIxMS9i
cmNtZm1hYy9iY21zZGguYw0KQEAgLTEyNjQsOCArMTI2NCwxMCBAQCBzdGF0aWMgaW50IGJyY21m
X29wc19zZGlvX3N1c3BlbmQoc3RydWN0IGRldmljZSAqZGV2KQ0KIAkJZWxzZQ0KIAkJCXNkaW9f
ZmxhZ3MgfD0gTU1DX1BNX1dBS0VfU0RJT19JUlE7DQogCX0NCi0JaWYgKHNkaW9fc2V0X2hvc3Rf
cG1fZmxhZ3Moc2Rpb2Rldi0+ZnVuY1sxXSwgc2Rpb19mbGFncykpDQorCWlmIChzZGlvX3NldF9o
b3N0X3BtX2ZsYWdzKHNkaW9kZXYtPmZ1bmNbMV0sIHNkaW9fZmxhZ3MpKSAoDQogCQlicmNtZl9l
cnIoIkZhaWxlZCB0byBzZXQgcG1fZmxhZ3MgJXhcbiIsIHNkaW9fZmxhZ3MpOw0KKwkJcmV0dXJu
IC1FSU5WQUw7DQorCX0NCiAJcmV0dXJuIDA7DQogfQ0KIA0KLS0gDQoyLjYuMC5HSVQNCg0KDQoN
Cg==
^ permalink raw reply
* [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
From: Eric Bentley @ 2017-08-31 23:44 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: arend.vanspriel@broadcom.com
Return error when failing to set power management capabilities flag.=A0 Thi=
s will cause the suspend to fail but the radio
will continue to operate.=A0 Allowing this to fail without reporting error =
will cause the radio to be non-functional on=A0
resume as it will have lost power.
Signed-off-by: Eric Bentley <eric.bentley@lairdtech.com>
---
=A0drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
=A01 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/dr=
ivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 72139b5..2f7d03f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -1264,8 +1264,10 @@ static int brcmf_ops_sdio_suspend(struct device *dev=
)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sd=
io_flags |=3D MMC_PM_WAKE_SDIO_IRQ;
=A0=A0=A0=A0=A0=A0=A0=A0 }
-=A0=A0=A0=A0=A0=A0 if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags=
))
+=A0=A0=A0=A0=A0=A0 if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags=
)) (
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 brcmf_err("Failed to set p=
m_flags %x\n", sdio_flags);
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -EINVAL;
+=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0=A0 return 0;
=A0}
=A0
--=A0
2.6.0.GIT
=
^ permalink raw reply related
* Re: [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
From: Steve deRosier @ 2017-08-31 23:49 UTC (permalink / raw)
To: Eric Bentley; +Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com
In-Reply-To: <BY1PR0201MB0904426CF17EF719FA343B1C839D0@BY1PR0201MB0904.namprd02.prod.outlook.com>
On Thu, Aug 31, 2017 at 4:44 PM, Eric Bentley
<Eric.Bentley@lairdtech.com> wrote:
> - if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags))
> + if (sdio_set_host_pm_flags(sdiodev->func[1], sdio_flags)) (
Hi Eric,
Shouldn't that be a '{' instead of '('? Maybe I'm missing some
context, but that doesn't look compilable.
:)
- Steve
^ permalink raw reply
* Re: [PATCH] Correctly fail to suspend when SDIO does not support power on suspend
From: Eric Bentley @ 2017-09-01 0:01 UTC (permalink / raw)
To: Steve deRosier
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com
In-Reply-To: <CALLGbRKbKWdo7BeDWUi24iP4OJDh-3WGdxEVBJCuYQ44==pE7g@mail.gmail.com>
WWVwIOKAkyB0cmllZCB0byBjbGVhbiBzb21lIHdoaXRlIHNwYWNlIHVwIGF0IHRoZSBsYXN0IG1p
bnV0ZeKApnVnaA0KDQpPbiA4LzMxLzE3LCA3OjQ5IFBNLCAic3RldmUuZGVyb3NpZXJAZ21haWwu
Y29tIG9uIGJlaGFsZiBvZiBTdGV2ZSBkZVJvc2llciIgPHN0ZXZlLmRlcm9zaWVyQGdtYWlsLmNv
bSBvbiBiZWhhbGYgb2YgZGVyb3NpZXJAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIE9uIFRodSwg
QXVnIDMxLCAyMDE3IGF0IDQ6NDQgUE0sIEVyaWMgQmVudGxleQ0KICAgIDxFcmljLkJlbnRsZXlA
bGFpcmR0ZWNoLmNvbT4gd3JvdGU6DQogICAgPiAtICAgICAgIGlmIChzZGlvX3NldF9ob3N0X3Bt
X2ZsYWdzKHNkaW9kZXYtPmZ1bmNbMV0sIHNkaW9fZmxhZ3MpKQ0KICAgID4gKyAgICAgICBpZiAo
c2Rpb19zZXRfaG9zdF9wbV9mbGFncyhzZGlvZGV2LT5mdW5jWzFdLCBzZGlvX2ZsYWdzKSkgKA0K
ICAgIA0KICAgIEhpIEVyaWMsDQogICAgDQogICAgU2hvdWxkbid0IHRoYXQgYmUgYSAneycgaW5z
dGVhZCBvZiAnKCc/ICBNYXliZSBJJ20gbWlzc2luZyBzb21lDQogICAgY29udGV4dCwgYnV0IHRo
YXQgZG9lc24ndCBsb29rIGNvbXBpbGFibGUuDQogICAgDQogICAgOikNCiAgICANCiAgICAtIFN0
ZXZlDQogICAgDQoNCg==
^ permalink raw reply
* Re: [PATCH v2] Correctly fail to suspend when SDIO does not support power on suspend
From: Eric Bentley @ 2017-09-01 0:04 UTC (permalink / raw)
To: Steve deRosier
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com
UmV0dXJuIGVycm9yIHdoZW4gZmFpbGluZyB0byBzZXQgcG93ZXIgbWFuYWdlbWVudCBjYXBhYmls
aXRpZXMgZmxhZy4gIFRoaXMgd2lsbCBjYXVzZSB0aGUgc3VzcGVuZCB0byBmYWlsIGJ1dCB0aGUg
cmFkaW8NCndpbGwgY29udGludWUgdG8gb3BlcmF0ZS4gIEFsbG93aW5nIHRoaXMgdG8gZmFpbCB3
aXRob3V0IHJlcG9ydGluZyBlcnJvciB3aWxsIGNhdXNlIHRoZSByYWRpbyB0byBiZSBub24tZnVu
Y3Rpb25hbCBvbiANCnJlc3VtZSBhcyBpdCB3aWxsIGhhdmUgbG9zdCBwb3dlci4NCg0KU2lnbmVk
LW9mZi1ieTogRXJpYyBCZW50bGV5IGVyaWMuYmVudGxleUBsYWlyZHRlY2guY29tDQotLS0NCnYy
OiBjb3JyZWN0ZWQgZXJyYW50ICggd2l0aCB7DQotLS0NCiBkcml2ZXJzL25ldC93aXJlbGVzcy9i
cm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMgfCA0ICsrKy0NCiAxIGZpbGUgY2hh
bmdlZCwgMyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9kcml2
ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMgYi9k
cml2ZXJzL25ldC93aXJlbGVzcy9icm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMN
CmluZGV4IDcyMTM5YjUuLjJmN2QwM2YgMTAwNjQ0DQotLS0gYS9kcml2ZXJzL25ldC93aXJlbGVz
cy9icm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMNCisrKyBiL2RyaXZlcnMvbmV0
L3dpcmVsZXNzL2Jyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9iY21zZGguYw0KQEAgLTEyNjQs
OCArMTI2NCwxMCBAQCBzdGF0aWMgaW50IGJyY21mX29wc19zZGlvX3N1c3BlbmQoc3RydWN0IGRl
dmljZSAqZGV2KQ0KICAgICAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgc2Rpb19mbGFncyB8PSBNTUNfUE1fV0FLRV9TRElPX0lSUTsNCiAgICAgICAgIH0NCi0gICAg
ICAgaWYgKHNkaW9fc2V0X2hvc3RfcG1fZmxhZ3Moc2Rpb2Rldi0+ZnVuY1sxXSwgc2Rpb19mbGFn
cykpDQorICAgICAgIGlmIChzZGlvX3NldF9ob3N0X3BtX2ZsYWdzKHNkaW9kZXYtPmZ1bmNbMV0s
IHNkaW9fZmxhZ3MpKSB7DQogICAgICAgICAgICAgICAgIGJyY21mX2VycigiRmFpbGVkIHRvIHNl
dCBwbV9mbGFncyAleFxuIiwgc2Rpb19mbGFncyk7DQorICAgICAgICAgICAgICAgcmV0dXJuIC1F
SU5WQUw7DQorICAgICAgIH0NCiAgICAgICAgIHJldHVybiAwOw0KIH0NCiANCi0tIA0KMi42LjAu
R0lUDQoNCg0K
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Larry Finger @ 2017-09-01 2:06 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <20170831075514.GA12340@redhat.com>
On 08/31/2017 02:55 AM, Stanislaw Gruszka wrote:
> On Wed, Aug 30, 2017 at 12:03:06PM -0500, Larry Finger wrote:
>> 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?
>
> I think it is the issue addressed by this 4.12 patch:
> https://marc.info/?l=linux-wireless&m=150366111408179&w=2
>
> Patch for 4.13+ kernels is here:
> https://marc.info/?l=linux-wireless&m=150367345912061&w=2
That patch did fix the problem. Thanks for the help.
Larry
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
From: Joe Perches @ 2017-09-01 4:05 UTC (permalink / raw)
To: Ganapathi Bhat, linux-wireless
Cc: Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare
In-Reply-To: <1504122674-3379-3-git-send-email-gbhat@marvell.com>
On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote:
> 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")'
[]
> diff --git 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;
Why not use a ratelimit?
^ permalink raw reply
* Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments
From: Greg Kroah-Hartman @ 2017-09-01 5:09 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Krzysztof Halasa, Aditya Shankar, Ganesh Krishna,
Jens Axboe, netdev, linux-wireless, devel, linux-kernel
In-Reply-To: <1504222183-61202-14-git-send-email-keescook@chromium.org>
On Thu, Aug 31, 2017 at 04:29:25PM -0700, Kees Cook wrote:
> Several timer users needlessly reset their .function/.data fields during
> their timer callback, but nothing else changes them. Some users do not
> use their .data field at all. Each instance is removed here.
>
> Cc: Krzysztof Halasa <khc@pm.waw.pl>
> Cc: Aditya Shankar <aditya.shankar@microchip.com>
> Cc: Ganesh Krishna <ganesh.krishna@microchip.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jens Axboe <axboe@fb.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Cc: devel@driverdev.osuosl.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/block/amiflop.c | 3 +--
> drivers/net/wan/hdlc_cisco.c | 2 --
> drivers/net/wan/hdlc_fr.c | 2 --
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +---
> 4 files changed, 2 insertions(+), 9 deletions(-)
For the staging driver:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2] Correctly fail to suspend when SDIO does not support power on suspend
From: Kalle Valo @ 2017-09-01 5:30 UTC (permalink / raw)
To: Eric Bentley
Cc: Steve deRosier, linux-wireless@vger.kernel.org,
arend.vanspriel@broadcom.com
In-Reply-To: <F895C8CD-1D0E-46CB-9C12-5B4775E76217@lairdtech.com>
Eric Bentley <Eric.Bentley@lairdtech.com> writes:
> Return error when failing to set power management capabilities flag. This will cause the suspend to fail but the radio
> will continue to operate. Allowing this to fail without reporting error will cause the radio to be non-functional on
> resume as it will have lost power.
>
> Signed-off-by: Eric Bentley eric.bentley@lairdtech.com
Word wrap the commit log to 72 chars (or so) per line. Also add a prefix
to the title:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
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