* [PATCH V2 0/9] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: igor.mitsyanko.os @ 2017-10-31 1:04 UTC (permalink / raw)
To: linux-wireless; +Cc: sergey.matyukevich.os, vulyanov, johannes
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
This patchset has a goal to make operational parameters (channel, BW,
HT/VHT capabilities) configuration possible for qtnfmac driver.
It was part of bigger changeset when it was V1, rest are already applied.
Changelist V1->V2:
PATCH 8:
- fix a typo causing initialization of HT capabilities with VHT data.
Igor Mitsyanko (9):
qtnfmac: use per-band HT/VHT info from wireless device
qtnfmac: initialize HT/VHT caps "can override" masks
qtnfmac: get rid of PHYMODE capabilities flags
qtnfmac: extend "IE set" TLV to include frame type info
qtnfmac: SCAN results: retreive frame type information from "IE set"
TLV
qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage
qtnfmac: configure and start AP interface with a single command
qtnfmac: include HTCAP and VHTCAP into config AP command
qtnfmac: pass all CONNECT cmd params to wireless card for processing
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 64 +----
drivers/net/wireless/quantenna/qtnfmac/commands.c | 276 +++++++++++++++-------
drivers/net/wireless/quantenna/qtnfmac/commands.h | 9 +-
drivers/net/wireless/quantenna/qtnfmac/core.c | 3 +-
drivers/net/wireless/quantenna/qtnfmac/core.h | 5 +-
drivers/net/wireless/quantenna/qtnfmac/event.c | 83 ++++---
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 138 ++++++-----
7 files changed, 330 insertions(+), 248 deletions(-)
--
2.9.5
^ permalink raw reply
* Re: [PATCH v2 1/3] mac80211: Add TXQ scheduling API
From: kbuild test robot @ 2017-10-31 0:45 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, make-wifi-fast, linux-wireless,
Toke Høiland-Jørgensen
In-Reply-To: <20171027141451.22768-1-toke@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Hi Toke,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mac80211/master]
[also build test ERROR on v4.14-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
config: mips-ip27_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
Note: the linux-review/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903 HEAD aa503ef75660b7c9cb9ede292f03047372517d4e builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> ERROR: "__ath_tx_queue_tid" [drivers/net/wireless/ath/ath9k/ath9k.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 15984 bytes --]
^ permalink raw reply
* [PATCH] mac80211: Update last_ack status for all except probing frames
From: Rajkumar Manoharan @ 2017-10-31 0:29 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
Update last_ack status for all except station probing frames
(i.e null data). Otherwise the station inactivity duration is
cleared whenever AP is checking presence of idle stations by sending
null data frame for every inactive threshold (ap_max_inactivity).
Though the station is idle for longer period, the inactive
time in station dump is restricted ap_max_inactivity threshold.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
net/mac80211/status.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index da7427a41529..24ce416f74cd 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -185,10 +185,21 @@ static void ieee80211_check_pending_bar(struct sta_info *sta, u8 *addr, u8 tid)
static void ieee80211_frame_acked(struct sta_info *sta, struct sk_buff *skb)
{
struct ieee80211_mgmt *mgmt = (void *) skb->data;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
- if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS))
+ /* Update last_ack status for all except station probing frames
+ * (i.e null data). Otherwise the station inactivity duration is cleared
+ * whenever AP is checking presence of idle stations by sending
+ * null data frame for every inactive threshold (ap_max_inactivity).
+ * Though the station is idle for longer period, the inactive time in
+ * station dump is restricted ap_max_inactivity threshold.
+ */
+ if (ieee80211_hw_check(&local->hw, REPORTS_TX_ACK_STATUS) &&
+ !((info->flags & IEEE80211_TX_INTFL_NL80211_FRAME_TX) &&
+ (ieee80211_is_nullfunc(mgmt->frame_control) ||
+ ieee80211_is_qos_nullfunc(mgmt->frame_control))))
sta->status_stats.last_ack = jiffies;
if (ieee80211_is_data_qos(mgmt->frame_control)) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] mac80211: Add TXQ scheduling API
From: kbuild test robot @ 2017-10-31 0:14 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, make-wifi-fast, linux-wireless,
Toke Høiland-Jørgensen
In-Reply-To: <20171027141451.22768-1-toke@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
Hi Toke,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mac80211/master]
[also build test ERROR on v4.14-rc7 next-20171018]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the linux-review/Toke-H-iland-J-rgensen/mac80211-Add-TXQ-scheduling-API/20171030-220903 HEAD aa503ef75660b7c9cb9ede292f03047372517d4e builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath9k/recv.o: In function `ath_rx_tasklet':
>> recv.c:(.text+0x16bc): undefined reference to `__ath_tx_queue_tid'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39531 bytes --]
^ permalink raw reply
* Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007
From: Fengguang Wu @ 2017-10-30 20:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Network Development, Linux Wireless List,
Linux Kernel Mailing List
In-Reply-To: <CA+55aFxA=+iO1cysMnLZz1iNd4W+gEf4Ys9FGoWM+zmuST2KOQ@mail.gmail.com>
On Mon, Oct 30, 2017 at 12:29:47PM -0700, Linus Torvalds wrote:
>On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>>
>> Here are 3 dmesgs related to wireless and 1 from ethernet.
>
>Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
>enabled on the kernel, and your script were to find things like
>"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.
>
>So
>
>> [ 235.425464] BUG: unable to handle kernel paging request at 0000000000010007
>> [ 235.425470] IP: run_timer_softirq+0x13a/0x470
>
>would also then have
>
> run_timer_softirq at timer.c:XYZ
>
>which would make it easier to see exactly _what_ it is that faults. As
>it is, I think there's a fair number of inlining that makes it hard to
>see the cause, but that faddrtoline would make very obvious.
Good idea and tips! It'll definitely help debug the issues where
bisect cannot help.
>Finding that "symbol+xyz/abc" pattern should be fairly easy to
>automate, and should fit the 0day model fairly well. No?
Sure. We'll add DEBUG_INFO and automate faddr2line.
Regards,
Fengguang
^ permalink raw reply
* Re: [EXT] Re: pull-request mwifiex-firmware 2017-10-30
From: Brian Norris @ 2017-10-30 19:47 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
James Cao, Cathy Luo, Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <b2af992abc624cdb8ae5a4c1d2d94090@SC-EXCH02.marvell.com>
On Mon, Oct 30, 2017 at 12:02 PM, Ganapathi Bhat <gbhat@marvell.com> wrote:
> Ok, prepared the follow up patch. Let me also know if we can send a merge request while previous one is pending?
> If that is not the case I will send it as soon as the current request is merged.
That's not up to me. I'm sure the maintainer will let you know if they
need something, eventually. It's so trivial, I don't see why they
couldn't just pull it in without any more fuss.
^ permalink raw reply
* Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007
From: Linus Torvalds @ 2017-10-30 19:29 UTC (permalink / raw)
To: Fengguang Wu
Cc: Network Development, Linux Wireless List,
Linux Kernel Mailing List
In-Reply-To: <20171029234820.nzwavupqlv2iqo3m@wfg-t540p.sh.intel.com>
On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>
> Here are 3 dmesgs related to wireless and 1 from ethernet.
Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.
So
> [ 235.425464] BUG: unable to handle kernel paging request at 0000000000010007
> [ 235.425470] IP: run_timer_softirq+0x13a/0x470
would also then have
run_timer_softirq at timer.c:XYZ
which would make it easier to see exactly _what_ it is that faults. As
it is, I think there's a fair number of inlining that makes it hard to
see the cause, but that faddrtoline would make very obvious.
Finding that "symbol+xyz/abc" pattern should be fairly easy to
automate, and should fit the 0day model fairly well. No?
In this case, the trapping instruction ends up decoding to
0: 4c 8d 6c c5 90 lea -0x70(%rbp,%rax,8),%r13
5: 49 8b 45 00 mov 0x0(%r13),%rax
9: 48 85 c0 test %rax,%rax
c: 74 de je 0xffffffffffffffec
e: 4d 8b 7d 00 mov 0x0(%r13),%r15
12: 4d 89 7c 24 08 mov %r15,0x8(%r12)
17: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
1c: 49 8b 07 mov (%r15),%rax
1f: 49 8b 57 08 mov 0x8(%r15),%rdx
23: 48 85 c0 test %rax,%rax
26: 48 89 02 mov %rax,(%rdx)
29: 74 04 je 0x2f
2b:* 48 89 50 08 mov %rdx,0x8(%rax) <-- trapping instruction
2f: 41 f6 47 2a 20 testb $0x20,0x2a(%r15)
34: 49 c7 47 08 00 00 00 movq $0x0,0x8(%r15)
and %rax has the value 0xffff, so yes, it will trap at 0x10007.
It's not trivial to see just *wjhat* access it is.
I *think* that "testb $32" is checking for TIMER_IRQSAFE in
expire_timers(), and that the oops is due to the list operations in
detach_timer() (inlined).
Which doesn't really help: it looks like the timer lists are corrupt.
With some luck, some register state could have the timer function
pointer in it, and we'd get a hint of *which* timer this is, but that
doesn't look to be the case here either.
I'm not seeing anything to really help debug this here.
Linus
^ permalink raw reply
* RE: [EXT] Re: pull-request mwifiex-firmware 2017-10-30
From: Ganapathi Bhat @ 2017-10-30 19:02 UTC (permalink / raw)
To: Brian Norris
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
James Cao, Cathy Luo, Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <20171030185043.GA100626@google.com>
Hi Brian,
> On Mon, Oct 30, 2017 at 06:47:58PM +0000, Ganapathi Bhat wrote:
> > > --------------------------------------------------------------------
> > > -- On Mon, Oct 30, 2017 at 02:13:31PM +0000, Ganapathi Bhat wrote:
>
> > > > --- a/WHENCE
> > > > +++ b/WHENCE
> > > > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> > > > Version: 16.68.1.p70
> > > >
> > > > File: mrvl/pcieusb8997_combo_v4.bin
> > > > -Version: 16.68.1.p133
> > > > +Version: 16.68.1.p40
> > >
> > > This says .p40, whereas the commit message (and the version tag
> > > within the
> > > firmware) says p140. I think you're missing a "1".
> > I did miss this. Will it make sense to trigger another pull request with just
> the version change?
>
> Sure, why not? Email is cheap, and so is git. Either rewrite the commit or add
> another on top to fix it...
Ok, prepared the follow up patch. Let me also know if we can send a merge request while previous one is pending?
If that is not the case I will send it as soon as the current request is merged.
Thanks,
Ganapathi
^ permalink raw reply
* Re: [EXT] Re: pull-request mwifiex-firmware 2017-10-30
From: Brian Norris @ 2017-10-30 18:50 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
James Cao, Cathy Luo, Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <fb8d8eece601415c83167c500d80ff2f@SC-EXCH02.marvell.com>
On Mon, Oct 30, 2017 at 06:47:58PM +0000, Ganapathi Bhat wrote:
> > ----------------------------------------------------------------------
> > On Mon, Oct 30, 2017 at 02:13:31PM +0000, Ganapathi Bhat wrote:
> > > --- a/WHENCE
> > > +++ b/WHENCE
> > > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> > > Version: 16.68.1.p70
> > >
> > > File: mrvl/pcieusb8997_combo_v4.bin
> > > -Version: 16.68.1.p133
> > > +Version: 16.68.1.p40
> >
> > This says .p40, whereas the commit message (and the version tag within the
> > firmware) says p140. I think you're missing a "1".
> I did miss this. Will it make sense to trigger another pull request with just the version change?
Sure, why not? Email is cheap, and so is git. Either rewrite the commit
or add another on top to fix it...
^ permalink raw reply
* RE: [EXT] Re: pull-request mwifiex-firmware 2017-10-30
From: Ganapathi Bhat @ 2017-10-30 18:47 UTC (permalink / raw)
To: Brian Norris
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
James Cao, Cathy Luo, Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <20171030170308.GA80479@google.com>
Hi Brian,
>
> ----------------------------------------------------------------------
> On Mon, Oct 30, 2017 at 02:13:31PM +0000, Ganapathi Bhat wrote:
> > The following changes since commit
> e0494e95192ac5329989f4d128cf95c417d618cc:
> >
> > linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01
> 23:55:30 +0530)
> >
> > are available in the git repository at:
> >
> > git://git.marvell.com/mwifiex-firmware.git
> >
> > for you to fetch changes up to
> c5bed1294f6cf6bf6cbef612204f96361a3c2539:
> >
> > linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30
> 19:23:05 +0530)
>
> Hooray, your git server is working again! And FWIW:
>
> Tested-by: Brian Norris <briannorris@chromium.org>
>
> But quoting your patch...
>
> > --- a/WHENCE
> > +++ b/WHENCE
> > @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> > Version: 16.68.1.p70
> >
> > File: mrvl/pcieusb8997_combo_v4.bin
> > -Version: 16.68.1.p133
> > +Version: 16.68.1.p40
>
> This says .p40, whereas the commit message (and the version tag within the
> firmware) says p140. I think you're missing a "1".
I did miss this. Will it make sense to trigger another pull request with just the version change?
>
> >
> > File: mrvl/pcie8997_wlan_v4.bin
> > Version: 16.68.1.p97
>
>
> Brian
>
> >
> > ----------------------------------------------------------------
> > Ganapathi Bhat (1):
> > linux-firmware: update Marvell PCIe-USB8997 firmware image
> >
> > WHENCE | 2 +-
> > mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
> > 2 files changed, 1 insertion(+), 1 deletion(-)
Regards,
Ganapathi
^ permalink raw reply
* Re: pull-request mwifiex-firmware 2017-10-30
From: Brian Norris @ 2017-10-30 17:03 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
James Cao, Cathy Luo, Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <9370b3238604464b85bf0c4f8ac79c71@SC-EXCH02.marvell.com>
On Mon, Oct 30, 2017 at 02:13:31PM +0000, Ganapathi Bhat wrote:
> The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:
>
> linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 23:55:30 +0530)
>
> are available in the git repository at:
>
> git://git.marvell.com/mwifiex-firmware.git
>
> for you to fetch changes up to c5bed1294f6cf6bf6cbef612204f96361a3c2539:
>
> linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30 19:23:05 +0530)
Hooray, your git server is working again! And FWIW:
Tested-by: Brian Norris <briannorris@chromium.org>
But quoting your patch...
> --- a/WHENCE
> +++ b/WHENCE
> @@ -757,7 +757,7 @@ File: mrvl/pcieuart8997_combo_v4.bin
> Version: 16.68.1.p70
>
> File: mrvl/pcieusb8997_combo_v4.bin
> -Version: 16.68.1.p133
> +Version: 16.68.1.p40
This says .p40, whereas the commit message (and the version tag within the
firmware) says p140. I think you're missing a "1".
>
> File: mrvl/pcie8997_wlan_v4.bin
> Version: 16.68.1.p97
Brian
>
> ----------------------------------------------------------------
> Ganapathi Bhat (1):
> linux-firmware: update Marvell PCIe-USB8997 firmware image
>
> WHENCE | 2 +-
> mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
> 2 files changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* pull-request mwifiex-firmware 2017-10-30
From: Ganapathi Bhat @ 2017-10-30 14:13 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: linux-wireless@vger.kernel.org, James Cao, Cathy Luo,
Mangesh Malusare, Xinming Hu, Zhiyuan Yang,
Karthik Doddayennegere Ananthapadmanabha, Brian Norris
The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:
linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 23:55:30 +0530)
are available in the git repository at:
git://git.marvell.com/mwifiex-firmware.git
for you to fetch changes up to c5bed1294f6cf6bf6cbef612204f96361a3c2539:
linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-30 19:23:05 +0530)
----------------------------------------------------------------
Ganapathi Bhat (1):
linux-firmware: update Marvell PCIe-USB8997 firmware image
WHENCE | 2 +-
mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 4/5] wlcore: Use common error handling code in wlcore_set_beacon_template()
From: SF Markus Elfring @ 2017-10-30 13:44 UTC (permalink / raw)
To: Julian Calaby, linux-wireless, netdev
Cc: Arend Van Spriel, Eyal Reizer, Iain Hunter, James Minor,
Johannes Berg, Kalle Valo, Maxim Altshul, Pieter-Paul Giesberts,
LKML, kernel-janitors
In-Reply-To: <CAGRGNgUEFpva3ct-idAzip97eVgoDDTeEArAPcjvf90VSORA2g@mail.gmail.com>
>> @@ -4081,9 +4078,8 @@ static int wlcore_set_beacon_template(struct wl1271 *wl,
>> beacon->data,
>> beacon->len, 0,
>> min_rate);
>> -end_bcn:
>> +free_skb:
>
> Why rename the label?
I find it clearer according to the Linux coding style.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 1/5] wlcore: Use common error handling code in wlcore_nvs_cb()
From: SF Markus Elfring @ 2017-10-30 13:40 UTC (permalink / raw)
To: Julian Calaby, linux-wireless, netdev
Cc: Arend Van Spriel, Eyal Reizer, Iain Hunter, James Minor,
Johannes Berg, Kalle Valo, Maxim Altshul, Pieter-Paul Giesberts,
LKML, kernel-janitors
In-Reply-To: <CAGRGNgULQRFo7T2TKr_=xNY9csYXTnnPc4k1AjS2OQ20zg+cbA@mail.gmail.com>
>> @@ -6551,6 +6549,11 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
>> out:
>> release_firmware(fw);
>> complete_all(&wl->nvs_loading_complete);
>> + return;
>> +
>> +power_off:
>
> Name this "out_power_off" to match the other labels.
Do you expect a second approach for this patch series then?
>> + wl1271_power_off(wl);
>> + goto out_free_nvs;
>
> Why not put this in front of the out_free_nvs label?
It seems that I can not really follow this suggestion at the moment.
> It looks weird here.
Which detail do you not like?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 5/5] wlcore: Use common error handling code in wl1271_op_suspend()
From: Julian Calaby @ 2017-10-30 13:40 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Arend Van Spriel, Eyal Reizer,
Iain Hunter, James Minor, Johannes Berg, Kalle Valo,
Maxim Altshul, Pieter-Paul Giesberts, LKML, kernel-janitors
In-Reply-To: <5c4844e8-b519-888d-c772-4f925a4f2a66@users.sourceforge.net>
Hi Markus,
On Mon, Oct 30, 2017 at 7:16 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 29 Oct 2017 20:36:39 +0100
>
> Add a jump target so that a specific error message is stored only once
> at the end of this function implementation.
> Replace two calls of the macro "wl1271_warning" by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
This patch is bogus, moving error messages around like this is just bizarre.
These are both reporting different failures, so the error messages
should be different.
> ---
> drivers/net/wireless/ti/wlcore/main.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
> index 12a9d6509382..a110f61110d5 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -1732,8 +1732,7 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
> ret = wl1271_configure_suspend(wl, wlvif, wow);
> if (ret < 0) {
> mutex_unlock(&wl->mutex);
> - wl1271_warning("couldn't prepare device to suspend");
"couldn't configure device for suspend"?
> - return ret;
> + goto report_preparation_failure;
> }
> }
>
> @@ -1752,10 +1751,8 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
> wl1271_ps_elp_sleep(wl);
> mutex_unlock(&wl->mutex);
>
> - if (ret < 0) {
> - wl1271_warning("couldn't prepare device to suspend");
"couldn't enable power saving"?
> - return ret;
> - }
> + if (ret < 0)
> + goto report_preparation_failure;
>
> /* flush any remaining work */
> wl1271_debug(DEBUG_MAC80211, "flushing remaining works");
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 4/5] wlcore: Use common error handling code in wlcore_set_beacon_template()
From: Julian Calaby @ 2017-10-30 13:33 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Arend Van Spriel, Eyal Reizer,
Iain Hunter, James Minor, Johannes Berg, Kalle Valo,
Maxim Altshul, Pieter-Paul Giesberts, LKML, kernel-janitors
In-Reply-To: <f50c8edf-834d-9003-5a3c-dc83ec4016ce@users.sourceforge.net>
Hi Markus,
On Mon, Oct 30, 2017 at 7:14 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 29 Oct 2017 20:16:22 +0100
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
However,
> ---
> drivers/net/wireless/ti/wlcore/main.c | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
> index 0365b5e40a8d..12a9d6509382 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -4081,9 +4078,8 @@ static int wlcore_set_beacon_template(struct wl1271 *wl,
> beacon->data,
> beacon->len, 0,
> min_rate);
> -end_bcn:
> +free_skb:
Why rename the label?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 3/5] wlcore: Return directly after a failed ieee80211_beacon_get() in wlcore_set_beacon_template()
From: Julian Calaby @ 2017-10-30 13:32 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Arend Van Spriel, Eyal Reizer,
Iain Hunter, James Minor, Johannes Berg, Kalle Valo,
Maxim Altshul, Pieter-Paul Giesberts, LKML, kernel-janitors
In-Reply-To: <6ea50cb4-8871-6752-6275-50da266f0e7d@users.sourceforge.net>
On Mon, Oct 30, 2017 at 7:13 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 29 Oct 2017 20:00:41 +0100
>
> Return directly after a call of the function "ieee80211_beacon_get"
> failed at the beginning.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 1/5] wlcore: Use common error handling code in wlcore_nvs_cb()
From: Julian Calaby @ 2017-10-30 13:28 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Arend Van Spriel, Eyal Reizer,
Iain Hunter, James Minor, Johannes Berg, Kalle Valo,
Maxim Altshul, Pieter-Paul Giesberts, LKML, kernel-janitors
In-Reply-To: <7b40d50f-cdac-bd47-5070-894140f7ceb3@users.sourceforge.net>
Hi Markus,
On Mon, Oct 30, 2017 at 7:11 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 29 Oct 2017 18:38:04 +0100
>
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/wireless/ti/wlcore/main.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
> index c346c021b999..48380d48ef09 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -6551,6 +6549,11 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
> out:
> release_firmware(fw);
> complete_all(&wl->nvs_loading_complete);
> + return;
> +
> +power_off:
Name this "out_power_off" to match the other labels.
> + wl1271_power_off(wl);
> + goto out_free_nvs;
Why not put this in front of the out_free_nvs label? It looks weird here.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 2/5] wlcore: Delete an unnecessary check statement in wlcore_set_beacon_template()
From: Julian Calaby @ 2017-10-30 13:26 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Arend Van Spriel, Eyal Reizer,
Iain Hunter, James Minor, Johannes Berg, Kalle Valo,
Maxim Altshul, Pieter-Paul Giesberts, LKML, kernel-janitors
In-Reply-To: <ccb3f6ab-3c39-9c34-518f-f7f36615930b@users.sourceforge.net>
On Mon, Oct 30, 2017 at 7:12 AM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 29 Oct 2017 19:45:07 +0100
>
> A goto statement jumped to a target which followed a condition check
> immediately without the specification of useful actions between.
> Thus remove such unnecessary source code at the end of this function.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Looks good to me.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [v2,1/5] qtnfmac: modify full Tx queue error reporting
From: Kalle Valo @ 2017-10-30 10:55 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov,
Sergey Matyukevich
In-Reply-To: <20171030101350.21251-2-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> Under heavy load it is normal that h/w Tx queue is almost full all the time
> and reclaim should be done before transmitting next packet. Warning still
> should be reported as well as s/w Tx queues should be stopped in the
> case when reclaim failed.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
5 patches applied to wireless-drivers-next.git, thanks.
e9931f984dd1 qtnfmac: modify full Tx queue error reporting
3dd06cecb1b8 qtnfmac: enable registration of more mgmt frames
bf024645ac9d qtnfmac: drop nonexistent function declaration
c35c0d54a77d qtnfmac: modify full Tx queue recovery
db5c6d4a9b92 qtnfmac: advertise support of inactivity timeout
--
https://patchwork.kernel.org/patch/10032277/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,1/3] rsi: sdio: add WOWLAN support for S3 suspend state
From: Kalle Valo @ 2017-10-30 10:50 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
In-Reply-To: <1509103557-6215-2-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> wrote:
> From: Karun Eagalapati <karun256@gmail.com>
>
> WoWLAN is supported in RS9113 device through GPIO pin2.
> wowlan config frame is internally sent to firmware in mac80211
> suspend handler. Also beacon miss threshold and keep-alive time
> values are increased to avoid un-necessary disconnection with AP.
>
> Signed-off-by: Karun Eagalapati <karun256@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
3 patches applied to wireless-drivers-next.git, thanks.
f3ac4e7394a1 rsi: sdio: add WOWLAN support for S3 suspend state
b6c8d06c8a64 rsi: sdio: Add WOWLAN support for S4 hibernate state
063848c3e155 rsi: sdio: Add WOWLAN support for S5 shutdown state
--
https://patchwork.kernel.org/patch/10029671/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: do not transmit in 11N rates when connected in TKIP security
From: Kalle Valo @ 2017-10-30 10:49 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, Ganapathi Bhat
In-Reply-To: <1509098569-19307-1-git-send-email-gbhat@marvell.com>
Ganapathi Bhat <gbhat@marvell.com> wrote:
> Driver is transmitting in 11N rates, when connected to an AP in
> TKIP security mode. Add a check to disable_11n to fix the issue.
>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
c6c65a8411cf mwifiex: do not transmit in 11N rates when connected in TKIP security
--
https://patchwork.kernel.org/patch/10029519/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: libertas: don't write wdev->ssid/_len
From: Kalle Valo @ 2017-10-30 10:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20171017193745.7604-1-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When joining an IBSS network, wdev->ssid/_len will already be
> set, so there's no need to write them. In any case, they are
> internal cfg80211 values, and have very little user-visible
> impact.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Patch applied to wireless-drivers-next.git, thanks.
39a9cd5a0e4e libertas: don't write wdev->ssid/_len
--
https://patchwork.kernel.org/patch/10012783/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [net-next] rsi: remove unused including <linux/version.h>
From: Kalle Valo @ 2017-10-30 10:44 UTC (permalink / raw)
To: weiyongjun (A)
Cc: Karun Eagalapati, Amitkumar Karwar, Prameela Rani Garnepudi,
Wei Yongjun, linux-wireless
In-Reply-To: <1509167426-93439-1-git-send-email-weiyongjun1@huawei.com>
"weiyongjun \(A\)" <weiyongjun1@huawei.com> wrote:
> Remove including <linux/version.h> that don't need it.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Wei, your name in patchwork is badly formatted. Please register to patchwork
and you should be able to fix it:
https://patchwork.kernel.org/patch/10030879/
--
https://patchwork.kernel.org/patch/10030879/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/5] qtnfmac: modify full Tx queue error reporting
From: Kalle Valo @ 2017-10-30 10:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <20171030094459.kj6nnrrc52wj2bsp@bars>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:
>> > My assumption is that by default all the patches should cleanly apply
>> > to wireless-drivers-next. I could apply the patch in question to
>> > wireless-drivers-next without any issues.
>>
>> Odd. How did you apply it? My script uses 'git am -s -3' individually
>> for each patch in the series, but to my knowledge that shouldn't cause
>> any problems.
>
> It turns out I mechanically rebased my branch on top of w-d-n before writing
> the previous email. Now I could reproduce the same failure when using this
> command for the original patches downloaded from patchwork.
Ok, that makes sense. Most likely when git-rebase does a 3-way merge
automatically and that's why you were able to successfully apply them.
But as git-am was not able to use 3-way merge due to incorrect sha1
information it failed.
> The problem was in conflict with qtnfmac fixes pulled to w-d-n from
> w-d.
Ok, thanks for investigating the root cause.
--
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