* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: James Hughes @ 2017-09-25 9:30 UTC (permalink / raw)
To: Kalle Valo; +Cc: Arend Van Spriel, linux-wireless
In-Reply-To: <CAE_XsMJu9k=j=YSCK3SF7bptHc4+eKVhJdYZaQtbhuYqbx_AZg@mail.gmail.com>
On 25 September 2017 at 10:26, James Hughes
<james.hughes@raspberrypi.org> wrote:
> On 25 September 2017 at 09:18, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>>
>>> The firmware uses a mailbox to communicate to the host what is going
>>> on. In the driver we validate the bit received. Various people seen
>>> the following message:
>>>
>>> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>>>
>>> Bit 4 is cause of this message, but this actually indicates the firmwar=
e
>>> has halted. Handle this bit by giving a more meaningful error message.
>>>
>>> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
>>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
>>> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>
>> Failed to compile:
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function =E2=
=80=98brcmf_p2p_escan=E2=80=99:
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: error: =
=E2=80=98BRCMF_SCANTYPE_ACTIVE=E2=80=99 undeclared (first use in this funct=
ion)
>> sparams->scan_type =3D BRCMF_SCANTYPE_ACTIVE;
>> ^
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: note: eac=
h undeclared identifier is reported only once for each function it appears =
in
>> make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.o] Er=
ror 1
>> make[6]: *** Waiting for unfinished jobs....
>> make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
>> make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
>> make[3]: *** [drivers/net/wireless/broadcom] Error 2
>> make[2]: *** [drivers/net/wireless] Error 2
>> make[1]: *** [drivers/net] Error 2
>> make: *** [drivers] Error 2
>>
>> 7 patches set to Changes Requested.
>>
>> 9948825 [1/7] brcmfmac: handle FWHALT mailbox indication
>> 9948831 [2/7] brcmfmac: disable packet filtering in promiscuous mode
>> 9948829 [3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
>> 9948833 [4/7] brcmfmac: use msecs_to_jiffies() instead of calculation us=
ing HZ
>> 9948827 [5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
>> 9948823 [6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_sc=
an field
>> 9948835 [7/7] brcmfmac: move configuration of probe request IEs
>>
>> --
>> https://patchwork.kernel.org/patch/9948825/
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp=
atches
>>
>
> We (Raspberry Pi) currently have an issue open with Cypress to try and
> determine the cause of the firmware lockup which results in this
> mailbox error, we have some custom firmware that has better firmware
> diagnostics which we have been reporting back to Cypress. Not had any
> progress so far as far as I know. Does this kernel side fix help our
> users in any way or is it simply a better error message?
>
> James
Sorry, should have read the patch first, simply a change to the error
reporting. I'll try and determine how far Cypress have got with the
firmware.
^ permalink raw reply
* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: James Hughes @ 2017-09-25 9:26 UTC (permalink / raw)
To: Kalle Valo; +Cc: Arend Van Spriel, linux-wireless
In-Reply-To: <20170925081816.E31B560C6B@smtp.codeaurora.org>
On 25 September 2017 at 09:18, Kalle Valo <kvalo@codeaurora.org> wrote:
> Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>
>> The firmware uses a mailbox to communicate to the host what is going
>> on. In the driver we validate the bit received. Various people seen
>> the following message:
>>
>> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>>
>> Bit 4 is cause of this message, but this actually indicates the firmware
>> has halted. Handle this bit by giving a more meaningful error message.
>>
>> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
>> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>
> Failed to compile:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function =E2=
=80=98brcmf_p2p_escan=E2=80=99:
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: error: =E2=
=80=98BRCMF_SCANTYPE_ACTIVE=E2=80=99 undeclared (first use in this function=
)
> sparams->scan_type =3D BRCMF_SCANTYPE_ACTIVE;
> ^
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: note: each=
undeclared identifier is reported only once for each function it appears i=
n
> make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.o] Err=
or 1
> make[6]: *** Waiting for unfinished jobs....
> make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
> make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
> make[3]: *** [drivers/net/wireless/broadcom] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
>
> 7 patches set to Changes Requested.
>
> 9948825 [1/7] brcmfmac: handle FWHALT mailbox indication
> 9948831 [2/7] brcmfmac: disable packet filtering in promiscuous mode
> 9948829 [3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
> 9948833 [4/7] brcmfmac: use msecs_to_jiffies() instead of calculation usi=
ng HZ
> 9948827 [5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
> 9948823 [6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_sca=
n field
> 9948835 [7/7] brcmfmac: move configuration of probe request IEs
>
> --
> https://patchwork.kernel.org/patch/9948825/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpa=
tches
>
We (Raspberry Pi) currently have an issue open with Cypress to try and
determine the cause of the firmware lockup which results in this
mailbox error, we have some custom firmware that has better firmware
diagnostics which we have been reporting back to Cypress. Not had any
progress so far as far as I know. Does this kernel side fix help our
users in any way or is it simply a better error message?
James
^ permalink raw reply
* pull-request: wireless-drivers 2017-09-25
From: Kalle Valo @ 2017-09-25 8:55 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here a pull request to net for 4.14, more info in the signed tag below.
Please let me know if there are any problems.
Kalle
The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-09-25
for you to fetch changes up to 3e747fa18202896b5be66b88478352d5880fb8eb:
Merge ath-current from ath.git (2017-09-25 10:06:12 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.14
Quite a lot of fixes this time. Most notable is the brcmfmac fix for a
CVE issue.
iwlwifi
* a couple of bugzilla bugs related to multicast handling
* two fixes for WoWLAN bugs that were causing queue hangs and
re-initialization problems
* two fixes for potential uninitialized variable use reported by Dan
Carpenter in relation to a recently introduced patch
* a fix for buffer reordering in the newly supported 9000 device
family
* fix a race when starting aggregation
* small fix for a recent patch to wake mac80211 queues
* send non-bufferable management frames in the generic queue so they
are not sent on queues that are under power-save
ath10k
* fix a PCI PM related gcc warning
brcmfmac
* CVE-2017-0786: add length check scan results from firmware
* respect passive scan requests from user space
qtnfmac
* fix race in tx path when using multiple interfaces
* cancel ongoing scan when removing the wireless interface
----------------------------------------------------------------
Arend Van Spriel (2):
brcmfmac: add length check in brcmf_cfg80211_escan_handler()
brcmfmac: setup passive scan if requested by user-space
Arnd Bergmann (1):
ath10k: mark PM functions as __maybe_unused
Avraham Stern (2):
iwlwifi: mvm: send all non-bufferable frames on the probe queue
iwlwifi: mvm: wake the correct mac80211 queue
David Spinadel (1):
iwlwifi: mvm: Flush non STA TX queues
Kalle Valo (2):
Merge tag 'iwlwifi-for-kalle-2017-09-15' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge ath-current from ath.git
Luca Coelho (4):
iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD
iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses
iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()
iwlwifi: mvm: set status before calling iwl_mvm_send_cmd_status()
Matt Chen (1):
iwlwifi: mvm: fix wowlan resume failed to load INIT ucode
Naftali Goldstein (1):
iwlwifi: mvm: change state when queueing agg start work
Sara Sharon (1):
iwlwifi: mvm: fix reorder buffer for 9000 devices
Sergey Matyukevich (2):
qtnfmac: lock access to h/w in tx path
qtnfmac: cancel scans on wireless interface changes
drivers/net/wireless/ath/ath10k/pci.c | 7 +--
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 ++++++-------
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 5 ++
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 62 ++++++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 7 +--
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++--
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 9 ++--
drivers/net/wireless/quantenna/qtnfmac/cfg80211.h | 3 ++
drivers/net/wireless/quantenna/qtnfmac/event.c | 2 -
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 9 +++-
.../quantenna/qtnfmac/pearl/pcie_bus_priv.h | 2 +
17 files changed, 125 insertions(+), 46 deletions(-)
^ permalink raw reply
* Re: b43: make const arrays static, reduces object code size
From: Kalle Valo @ 2017-09-25 8:30 UTC (permalink / raw)
To: Colin Ian King
Cc: linux-wireless, b43-dev, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170922153902.15372-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate const arrays on the stack, instead make them static.
> Makes the object code smaller by over 60 bytes:
>
> Before:
> text data bss dec hex filename
> 14816 1296 0 16112 3ef0 b43/phy_ht.o
>
> After:
> text data bss dec hex filename
> 14551 1496 0 16047 3eaf b43/phy_ht.o
>
> (gcc 6.3.0, x86-64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
96cbe3d638e4 b43: make const arrays static, reduces object code size
--
https://patchwork.kernel.org/patch/9966415/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: iwlegacy: make const array static to shink object code size
From: Kalle Valo @ 2017-09-25 8:29 UTC (permalink / raw)
To: Colin Ian King
Cc: Stanislaw Gruszka, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20170921225630.21916-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate const array ac_to_fifo on the stack in an inlined
> function, instead make it static. Makes the object code smaller
> by over 800 bytes:
>
> text data bss dec hex filename
> 159029 33154 1216 193399 2f377 4965-mac.o
>
> text data bss dec hex filename
> 158122 33250 1216 192588 2f04c 4965-mac.o
>
> (gcc version 7.2.0 x86_64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
9b029e178ea1 iwlegacy: make const array static to shink object code size
--
https://patchwork.kernel.org/patch/9964889/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V3, 1/9] qtnfmac: convert channel width from bitfiled to simple enum
From: Kalle Valo @ 2017-09-25 8:28 UTC (permalink / raw)
To: Igor Mitsyanko; +Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170921213437.27457-2-igor.mitsyanko.os@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> This will allow to use qlink channel width values to specify BW setting
> corresponding to enum nl80211_chan_width.
> Current user is converted to apply BIT() macro manually to each individual
> qlink_channel_width enumeration value.
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
9 patches applied to wireless-drivers-next.git, thanks.
77d68147745b qtnfmac: convert channel width from bitfiled to simple enum
fac7f9bf1481 qtnfmac: make "Channel change" event report full channel info
9e5478b608b5 qtnfmac: retrieve current channel info from EP
96d4eaf20fb8 qtnfmac: do not cache channel info from "connect" command
3656ab0fef5b qtnfmac: let wifi card handle channel switch request to the same chan
8c015b9067d6 qtnfmac: pass VIF info to SendChannel command
97397633108a qtnfmac: do not cache CSA chandef info
6bfe61d697cb qtnfmac: remove unused mac::status field
115af851234f qtnfmac: do not report channel changes until wiphy is registered
--
https://patchwork.kernel.org/patch/9964831/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rsi: sdio suspend and resume support
From: Kalle Valo @ 2017-09-25 8:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
In-Reply-To: <1505998288-2041-1-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> wrote:
> From: Karun Eagalapati <karun256@gmail.com>
>
> SDIO suspend and resume handlers are implemented and verified
> that device works after suspend/resume cycle.
>
> Signed-off-by: Karun Eagalapati <karun256@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Patch applied to wireless-drivers-next.git, thanks.
20db07332736 rsi: sdio suspend and resume support
--
https://patchwork.kernel.org/patch/9963895/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rsi: add version information
From: Kalle Valo @ 2017-09-25 8:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Pavani Muthyala
In-Reply-To: <1505998234-1992-1-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> wrote:
> From: Pavani Muthyala <pavani.muthyala@redpinesignals.com>
>
> We will dump information about firmware version, firmware file
> name and operating mode during initialization.
>
> Signed-off-by: Pavani Muthyala <pavani.muthyala@redpinesignals.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Patch applied to wireless-drivers-next.git, thanks.
192524a4992a rsi: add version information
--
https://patchwork.kernel.org/patch/9963891/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: make const array tos_to_ac static, reduces object code size
From: Kalle Valo @ 2017-09-25 8:24 UTC (permalink / raw)
To: Colin Ian King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170919210500.31330-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the read-only const array tos_to_ac on the stack,
> instead make it static. Makes the object code smaller by 250 bytes:
>
> Before:
> text data bss dec hex filename
> 26104 2720 128 28952 7118 wmm.o
>
> After:
> text data bss dec hex filename
> 25758 2816 128 28702 701e wmm.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
7dfb0ebd022b mwifiex: make const array tos_to_ac static, reduces object code size
--
https://patchwork.kernel.org/patch/9960331/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rtl8xxxu: Don't printk raw binary if serial number is not burned in.
From: Kalle Valo @ 2017-09-25 8:24 UTC (permalink / raw)
To: Adam Borowski
Cc: Jes Sorensen, linux-wireless, netdev, Stefano Brivio,
Adam Borowski
In-Reply-To: <20170908103000.6795-1-kilobyte@angband.pl>
Adam Borowski <kilobyte@angband.pl> wrote:
> I assume that a blank efuse comes with all ones, thus I did not bother
> recognizing other possible junk values. This matches 100% of dongles
> I've seen (a single Gembird 8192eu).
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Patch applied to wireless-drivers-next.git, thanks.
e0a576d74782 rtl8xxxu: Don't printk raw binary if serial number is not burned in.
--
https://patchwork.kernel.org/patch/9943635/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmsmac: make const array ucode_ofdm_rates static, reduces object code size
From: Kalle Valo @ 2017-09-25 8:23 UTC (permalink / raw)
To: Colin Ian King
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170922140316.12768-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate const array ucode_ofdm_rates on the stack, instead make it
> static. Makes the object code smaller by 100 bytes:
>
> Before:
> text data bss dec hex filename
> 39482 564 0 40046 9c6e phy_cmn.o
>
> After
> text data bss dec hex filename
> 39326 620 0 39946 9c0a phy_cmn.o
>
> (gcc 6.3.0, x86-64)
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
d5633bb2c62a brcmsmac: make const array ucode_ofdm_rates static, reduces object code size
--
https://patchwork.kernel.org/patch/9966221/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/1] brcmfmac: use setup_timer() helper
From: Kalle Valo @ 2017-09-25 8:21 UTC (permalink / raw)
To: Allen Pais; +Cc: linux-kernel, arend.vanspriel, linux-wireless, Allen Pais
In-Reply-To: <1505997786-12815-1-git-send-email-allen.lkml@gmail.com>
Allen Pais <allen.lkml@gmail.com> wrote:
> Use setup_timer function instead of initializing timer with the
> function and data fields.
>
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
30ac40763939 brcmfmac: use setup_timer() helper
--
https://patchwork.kernel.org/patch/9963851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper
From: Allen @ 2017-09-25 8:20 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-kernel, arend.vanspriel, linux-wireless
In-Reply-To: <87d16f6weu.fsf@kamboji.qca.qualcomm.com>
>
> It's a frequent problem to have misconfigured name in patchwork. I guess
> it happens as the first mail patchwork sees from you is the one stored
> to the database. And if that mail has an incorrect name, that will be
> used from that onwards. You have only onetime chance to fix it yourself
> when you register to patchwork. After that only server admins can fix it
> and you need to contact kernel.org helpdesk.
I have registered again and let's hope it picks the full name going forward.
> Apparently in recent versions of patchwork this should work better but
> kernel.org hasn't updated it yet.
>
I'll write to the admins, ensure it is right.
Thank you.
^ permalink raw reply
* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: Kalle Valo @ 2017-09-25 8:18 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The firmware uses a mailbox to communicate to the host what is going
> on. In the driver we validate the bit received. Various people seen
> the following message:
>
> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>
> Bit 4 is cause of this message, but this actually indicates the firmware
> has halted. Handle this bit by giving a more meaningful error message.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Failed to compile:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function ‘brcmf_p2p_escan’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: error: ‘BRCMF_SCANTYPE_ACTIVE’ undeclared (first use in this function)
sparams->scan_type = BRCMF_SCANTYPE_ACTIVE;
^
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
make[3]: *** [drivers/net/wireless/broadcom] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
7 patches set to Changes Requested.
9948825 [1/7] brcmfmac: handle FWHALT mailbox indication
9948831 [2/7] brcmfmac: disable packet filtering in promiscuous mode
9948829 [3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
9948833 [4/7] brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
9948827 [5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
9948823 [6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
9948835 [7/7] brcmfmac: move configuration of probe request IEs
--
https://patchwork.kernel.org/patch/9948825/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: rtl8821ae: Fix connection lost problem
From: Kalle Valo @ 2017-09-25 8:06 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Stable, Ping-Ke Shih
In-Reply-To: <20170920211505.26171-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read
> of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi
> this change results in reduced stability for the wireless connection.
> This regression was located using bisection.
>
> Fixes: 40b368af4b75 ("rtlwifi: Fix alignment issues")
> Reported-and-tested-by: James Cameron <quozl@laptop.org>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.11+
> Cc: Ping-Ke Shih <pkshih@realtek.com>
Should I queue this for 4.14?
(The first commit was v4.11-rc1.)
--
https://patchwork.kernel.org/patch/9962615/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper
From: Kalle Valo @ 2017-09-25 7:59 UTC (permalink / raw)
To: Allen; +Cc: linux-kernel, arend.vanspriel, linux-wireless
In-Reply-To: <CAOMdWSLYb_LF=TS0jzCU6DC0KVfOa=pZYdMipBF_ynJ6N_0NmQ@mail.gmail.com>
Allen <allen.lkml@gmail.com> writes:
>>
>> Also your name in patchwork is just "Allen", without your lastname. I can fix
>> it this time, but please register to patchwork to fix your name. (Annoyingly
>> patchwork takes the name from it's database, not from the "From:" header)
>
> Ah that's strange. I'll register again.
It's a frequent problem to have misconfigured name in patchwork. I guess
it happens as the first mail patchwork sees from you is the one stored
to the database. And if that mail has an incorrect name, that will be
used from that onwards. You have only onetime chance to fix it yourself
when you register to patchwork. After that only server admins can fix it
and you need to contact kernel.org helpdesk.
Apparently in recent versions of patchwork this should work better but
kernel.org hasn't updated it yet.
--
Kalle Valo
^ permalink raw reply
* Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper
From: Allen @ 2017-09-25 7:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-kernel, arend.vanspriel, linux-wireless
In-Reply-To: <20170925074509.1168960719@smtp.codeaurora.org>
>
> Also your name in patchwork is just "Allen", without your lastname. I can fix
> it this time, but please register to patchwork to fix your name. (Annoyingly
> patchwork takes the name from it's database, not from the "From:" header)
Ah that's strange. I'll register again.
Thanks,
- Allen
> --
> https://patchwork.kernel.org/patch/9963851/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
^ permalink raw reply
* Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper
From: Kalle Valo @ 2017-09-25 7:45 UTC (permalink / raw)
To: Allen; +Cc: linux-kernel, arend.vanspriel, linux-wireless, Allen Pais
In-Reply-To: <1505997786-12815-1-git-send-email-allen.lkml@gmail.com>
Allen <allen.lkml@gmail.com> wrote:
> Use setup_timer function instead of initializing timer with the
> function and data fields.
>
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Also your name in patchwork is just "Allen", without your lastname. I can fix
it this time, but please register to patchwork to fix your name. (Annoyingly
patchwork takes the name from it's database, not from the "From:" header)
--
https://patchwork.kernel.org/patch/9963851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wcn36xx: Disable 5GHz for wcn3620
From: Kalle Valo @ 2017-09-25 7:21 UTC (permalink / raw)
To: Loic Poulain; +Cc: k.eugene.e, kvalo, linux-wireless, wcn36xx, Loic Poulain
In-Reply-To: <1505824403-26798-1-git-send-email-loic.poulain@linaro.org>
Loic Poulain <loic.poulain@linaro.org> wrote:
> wcn3620 can only operate on 2.4GHz band due to RF limitation.
> If wcn36xx digital block is associated with an external IRIS
> RF module, retrieve the id and disable 5GHz band in case of
> wcn3620 id.
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
fd52bdae9ab0 wcn36xx: Disable 5GHz for wcn3620
--
https://patchwork.kernel.org/patch/9958797/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [2/2] ath9k: Avoid a potential deadlock
From: Kalle Valo @ 2017-09-25 7:18 UTC (permalink / raw)
To: Ville Syrjälä
Cc: linux-wireless, QCA ath9k Development, Kalle Valo, netdev,
Ville Syrjälä
In-Reply-To: <20170918195919.15860-2-ville.syrjala@linux.intel.com>
Ville Syrjälä wrote:
> Lockdep warns us that sc_pm_lock and cc_lock can cause a deadlock when
> cc_lock is acquired by itself with interrupts enabled. Disable irqs
> whenever taking cc_lock to avoid this.
>
> [ 19.094524] kworker/u2:0/5 just changed the state of lock:
> [ 19.094578] (&(&sc->sc_pm_lock)->rlock){-.-...}, at: [<f836c00e>] ath_isr+0x15e/0x200 [ath9k]
> [ 19.094674] but this lock took another, HARDIRQ-unsafe lock in the past:
> [ 19.094731] (&(&common->cc_lock)->rlock){+.-...}
> [ 19.094741]
>
> and interrupts could create inverse lock ordering between them.
>
> [ 19.094866]
> other info that might help us debug this:
> [ 19.094926] Possible interrupt unsafe locking scenario:
>
> [ 19.094985] CPU0 CPU1
> [ 19.095036] ---- ----
> [ 19.095086] lock(&(&common->cc_lock)->rlock);
> [ 19.095197] local_irq_disable();
> [ 19.095305] lock(&(&sc->sc_pm_lock)->rlock);
> [ 19.095423] lock(&(&common->cc_lock)->rlock);
> [ 19.095539] <Interrupt>
> [ 19.095636] lock(&(&sc->sc_pm_lock)->rlock);
> [ 19.095745]
> *** DEADLOCK ***
>
> [ 19.095965] 3 locks held by kworker/u2:0/5:
> [ 19.096067] #0: ("%s"wiphy_name(local->hw.wiphy)){.+.+.+}, at: [<c1067f37>] process_one_work+0x127/0x580
> [ 19.096260] #1: ((&local->dynamic_ps_enable_work)){+.+...}, at: [<c1067f37>] process_one_work+0x127/0x580
> [ 19.096447] #2: (&sc->mutex){+.+...}, at: [<f836b8b0>] ath9k_config+0x30/0x1d0 [ath9k]
> [ 19.096639]
> the shortest dependencies between 2nd lock and 1st lock:
> [ 19.096813] -> (&(&common->cc_lock)->rlock){+.-...} ops: 38 {
> [ 19.096816] HARDIRQ-ON-W at:
> [ 19.096816] __lock_acquire+0x57e/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_bh+0x3f/0x50
> [ 19.096816] ath_chanctx_set_channel+0xb6/0x2c0 [ath9k]
> [ 19.096816] ath9k_config+0xa8/0x1d0 [ath9k]
> [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211]
> [ 19.096816] ieee80211_do_open+0x67a/0x920 [mac80211]
> [ 19.096816] ieee80211_open+0x41/0x50 [mac80211]
> [ 19.096816] __dev_open+0xab/0x140
> [ 19.096816] __dev_change_flags+0x89/0x150
> [ 19.096816] dev_change_flags+0x28/0x60
> [ 19.096816] do_setlink+0x290/0x890
> [ 19.096816] rtnl_newlink+0x7cf/0x8e0
> [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0
> [ 19.096816] netlink_rcv_skb+0xb9/0xe0
> [ 19.096816] rtnetlink_rcv+0x1e/0x30
> [ 19.096816] netlink_unicast+0x13a/0x2c0
> [ 19.096816] netlink_sendmsg+0x290/0x380
> [ 19.096816] ___sys_sendmsg+0x1e2/0x280
> [ 19.096816] __sys_sendmsg+0x3f/0x80
> [ 19.096816] SyS_socketcall+0x58c/0x6b0
> [ 19.096816] do_fast_syscall_32+0x96/0x1d0
> [ 19.096816] entry_SYSENTER_32+0x4c/0x7b
> [ 19.096816] IN-SOFTIRQ-W at:
> [ 19.096816] __lock_acquire+0x55a/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock+0x3c/0x50
> [ 19.096816] ath_ps_full_sleep+0x24/0x70 [ath9k]
> [ 19.096816] call_timer_fn+0xa4/0x300
> [ 19.096816] run_timer_softirq+0x1b1/0x560
> [ 19.096816] __do_softirq+0xb0/0x430
> [ 19.096816] do_softirq_own_stack+0x33/0x40
> [ 19.096816] irq_exit+0xad/0xc0
> [ 19.096816] smp_apic_timer_interrupt+0x31/0x40
> [ 19.096816] apic_timer_interrupt+0x37/0x3c
> [ 19.096816] wp_page_copy+0xb8/0x580
> [ 19.096816] do_wp_page+0x64/0x420
> [ 19.096816] handle_mm_fault+0x430/0x990
> [ 19.096816] __do_page_fault+0x18b/0x430
> [ 19.096816] do_page_fault+0xb/0x10
> [ 19.096816] common_exception+0x62/0x6a
> [ 19.096816] INITIAL USE at:
> [ 19.096816] __lock_acquire+0x204/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_bh+0x3f/0x50
> [ 19.096816] ath_chanctx_set_channel+0xb6/0x2c0 [ath9k]
> [ 19.096816] ath9k_config+0xa8/0x1d0 [ath9k]
> [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211]
> [ 19.096816] ieee80211_do_open+0x67a/0x920 [mac80211]
> [ 19.096816] ieee80211_open+0x41/0x50 [mac80211]
> [ 19.096816] __dev_open+0xab/0x140
> [ 19.096816] __dev_change_flags+0x89/0x150
> [ 19.096816] dev_change_flags+0x28/0x60
> [ 19.096816] do_setlink+0x290/0x890
> [ 19.096816] rtnl_newlink+0x7cf/0x8e0
> [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0
> [ 19.096816] netlink_rcv_skb+0xb9/0xe0
> [ 19.096816] rtnetlink_rcv+0x1e/0x30
> [ 19.096816] netlink_unicast+0x13a/0x2c0
> [ 19.096816] netlink_sendmsg+0x290/0x380
> [ 19.096816] ___sys_sendmsg+0x1e2/0x280
> [ 19.096816] __sys_sendmsg+0x3f/0x80
> [ 19.096816] SyS_socketcall+0x58c/0x6b0
> [ 19.096816] do_fast_syscall_32+0x96/0x1d0
> [ 19.096816] entry_SYSENTER_32+0x4c/0x7b
> [ 19.096816] }
> [ 19.096816] ... key at: [<f837b694>] __key.61991+0x0/0xffffc96c [ath9k]
> [ 19.096816] ... acquired at:
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock+0x3c/0x50
> [ 19.096816] ath9k_ps_wakeup+0x85/0xe0 [ath9k]
> [ 19.096816] ath9k_bss_info_changed+0x2a/0x1b0 [ath9k]
> [ 19.096816] ieee80211_bss_info_change_notify+0xf3/0x360 [mac80211]
> [ 19.096816] ieee80211_recalc_txpower+0x33/0x40 [mac80211]
> [ 19.096816] ieee80211_set_tx_power+0x45/0x1d0 [mac80211]
> [ 19.096816] cfg80211_wext_siwtxpower+0xd3/0x350 [cfg80211]
> [ 19.096816] ioctl_standard_call+0x4e/0x400
> [ 19.096816] wext_handle_ioctl+0xf4/0x190
> [ 19.096816] dev_ioctl+0xb7/0x630
> [ 19.096816] sock_ioctl+0x13e/0x2d0
> [ 19.096816] do_vfs_ioctl+0x84/0x750
> [ 19.096816] SyS_ioctl+0x34/0x60
> [ 19.096816] do_fast_syscall_32+0x96/0x1d0
> [ 19.096816] entry_SYSENTER_32+0x4c/0x7b
>
> [ 19.096816] -> (&(&sc->sc_pm_lock)->rlock){-.-...} ops: 597 {
> [ 19.096816] IN-HARDIRQ-W at:
> [ 19.096816] __lock_acquire+0x6ae/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60
> [ 19.096816] ath_isr+0x15e/0x200 [ath9k]
> [ 19.096816] __handle_irq_event_percpu+0x44/0x340
> [ 19.096816] handle_irq_event_percpu+0x1d/0x50
> [ 19.096816] handle_irq_event+0x32/0x60
> [ 19.096816] handle_level_irq+0x81/0x100
> [ 19.096816] handle_irq+0x9c/0xd0
> [ 19.096816] do_IRQ+0x5c/0x120
> [ 19.096816] common_interrupt+0x36/0x3c
> [ 19.096816] _raw_spin_unlock_irqrestore+0x57/0x70
> [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k]
> [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211]
> [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211]
> [ 19.096816] process_one_work+0x1d1/0x580
> [ 19.096816] worker_thread+0x31/0x380
> [ 19.096816] kthread+0xd9/0x110
> [ 19.096816] ret_from_fork+0x19/0x24
> [ 19.096816] IN-SOFTIRQ-W at:
> [ 19.096816] __lock_acquire+0x55a/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60
> [ 19.096816] ath9k_ps_wakeup+0x24/0xe0 [ath9k]
> [ 19.096816] ath9k_tasklet+0x42/0x260 [ath9k]
> [ 19.096816] tasklet_action+0x196/0x1e0
> [ 19.096816] __do_softirq+0xb0/0x430
> [ 19.096816] do_softirq_own_stack+0x33/0x40
> [ 19.096816] irq_exit+0xad/0xc0
> [ 19.096816] do_IRQ+0x65/0x120
> [ 19.096816] common_interrupt+0x36/0x3c
> [ 19.096816] get_page_from_freelist+0x20a/0x970
> [ 19.096816] __alloc_pages_nodemask+0xca/0xed0
> [ 19.096816] __get_free_pages+0x14/0x30
> [ 19.096816] pgd_alloc+0x1d/0x160
> [ 19.096816] mm_init.isra.47+0x13a/0x1b0
> [ 19.096816] copy_process.part.54+0xb55/0x1700
> [ 19.096816] _do_fork+0xd4/0x6a0
> [ 19.096816] SyS_clone+0x27/0x30
> [ 19.096816] do_fast_syscall_32+0x96/0x1d0
> [ 19.096816] entry_SYSENTER_32+0x4c/0x7b
> [ 19.096816] INITIAL USE at:
> [ 19.096816] __lock_acquire+0x204/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60
> [ 19.096816] ath9k_ps_wakeup+0x24/0xe0 [ath9k]
> [ 19.096816] ath9k_start+0x29/0x1f0 [ath9k]
> [ 19.096816] drv_start+0x71/0x270 [mac80211]
> [ 19.096816] ieee80211_do_open+0x31f/0x920 [mac80211]
> [ 19.096816] ieee80211_open+0x41/0x50 [mac80211]
> [ 19.096816] __dev_open+0xab/0x140
> [ 19.096816] __dev_change_flags+0x89/0x150
> [ 19.096816] dev_change_flags+0x28/0x60
> [ 19.096816] do_setlink+0x290/0x890
> [ 19.096816] rtnl_newlink+0x7cf/0x8e0
> [ 19.096816] rtnetlink_rcv_msg+0xbf/0x1f0
> [ 19.096816] netlink_rcv_skb+0xb9/0xe0
> [ 19.096816] rtnetlink_rcv+0x1e/0x30
> [ 19.096816] netlink_unicast+0x13a/0x2c0
> [ 19.096816] netlink_sendmsg+0x290/0x380
> [ 19.096816] ___sys_sendmsg+0x1e2/0x280
> [ 19.096816] __sys_sendmsg+0x3f/0x80
> [ 19.096816] SyS_socketcall+0x58c/0x6b0
> [ 19.096816] do_fast_syscall_32+0x96/0x1d0
> [ 19.096816] entry_SYSENTER_32+0x4c/0x7b
> [ 19.096816] }
> [ 19.096816] ... key at: [<f837b67c>] __key.61994+0x0/0xffffc984 [ath9k]
> [ 19.096816] ... acquired at:
> [ 19.096816] check_usage_forwards+0x118/0x120
> [ 19.096816] mark_lock+0x2e4/0x590
> [ 19.096816] __lock_acquire+0x6ae/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60
> [ 19.096816] ath_isr+0x15e/0x200 [ath9k]
> [ 19.096816] __handle_irq_event_percpu+0x44/0x340
> [ 19.096816] handle_irq_event_percpu+0x1d/0x50
> [ 19.096816] handle_irq_event+0x32/0x60
> [ 19.096816] handle_level_irq+0x81/0x100
> [ 19.096816] handle_irq+0x9c/0xd0
> [ 19.096816] do_IRQ+0x5c/0x120
> [ 19.096816] common_interrupt+0x36/0x3c
> [ 19.096816] _raw_spin_unlock_irqrestore+0x57/0x70
> [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k]
> [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211]
> [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211]
> [ 19.096816] process_one_work+0x1d1/0x580
> [ 19.096816] worker_thread+0x31/0x380
> [ 19.096816] kthread+0xd9/0x110
> [ 19.096816] ret_from_fork+0x19/0x24
>
> [ 19.096816]
> stack backtrace:
> [ 19.096816] CPU: 0 PID: 5 Comm: kworker/u2:0 Not tainted 4.13.0-mgm-ovl+ #51
> [ 19.096816] Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004
> [ 19.096816] Workqueue: phy0 ieee80211_dynamic_ps_enable_work [mac80211]
> [ 19.096816] Call Trace:
> [ 19.096816] <IRQ>
> [ 19.096816] dump_stack+0x16/0x19
> [ 19.096816] print_irq_inversion_bug.part.37+0x16c/0x179
> [ 19.096816] check_usage_forwards+0x118/0x120
> [ 19.096816] ? ret_from_fork+0x19/0x24
> [ 19.096816] ? print_shortest_lock_dependencies+0x1a0/0x1a0
> [ 19.096816] mark_lock+0x2e4/0x590
> [ 19.096816] ? print_shortest_lock_dependencies+0x1a0/0x1a0
> [ 19.096816] __lock_acquire+0x6ae/0x1260
> [ 19.096816] lock_acquire+0xb1/0x1c0
> [ 19.096816] ? ath_isr+0x15e/0x200 [ath9k]
> [ 19.096816] _raw_spin_lock_irqsave+0x45/0x60
> [ 19.096816] ? ath_isr+0x15e/0x200 [ath9k]
> [ 19.096816] ath_isr+0x15e/0x200 [ath9k]
> [ 19.096816] __handle_irq_event_percpu+0x44/0x340
> [ 19.096816] handle_irq_event_percpu+0x1d/0x50
> [ 19.096816] handle_irq_event+0x32/0x60
> [ 19.096816] ? handle_nested_irq+0x100/0x100
> [ 19.096816] handle_level_irq+0x81/0x100
> [ 19.096816] handle_irq+0x9c/0xd0
> [ 19.096816] </IRQ>
> [ 19.096816] do_IRQ+0x5c/0x120
> [ 19.096816] common_interrupt+0x36/0x3c
> [ 19.096816] EIP: _raw_spin_unlock_irqrestore+0x57/0x70
> [ 19.096816] EFLAGS: 00000286 CPU: 0
> [ 19.096816] EAX: f60a3600 EBX: 00000286 ECX: 00000006 EDX: 00000001
> [ 19.096816] ESI: f46c9e68 EDI: f46c8620 EBP: f60b5e8c ESP: f60b5e84
> [ 19.096816] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> [ 19.096816] ath9k_config+0x16a/0x1d0 [ath9k]
> [ 19.096816] ieee80211_hw_config+0xa8/0x5f0 [mac80211]
> [ 19.096816] ? ieee80211_hw_config+0x1db/0x5f0 [mac80211]
> [ 19.096816] ieee80211_dynamic_ps_enable_work+0x1c3/0x680 [mac80211]
> [ 19.096816] ? process_one_work+0x127/0x580
> [ 19.096816] ? process_one_work+0x127/0x580
> [ 19.096816] process_one_work+0x1d1/0x580
> [ 19.096816] ? process_one_work+0x127/0x580
> [ 19.096816] worker_thread+0x31/0x380
> [ 19.096816] kthread+0xd9/0x110
> [ 19.096816] ? process_one_work+0x580/0x580
> [ 19.096816] ? kthread_create_on_node+0x30/0x30
> [ 19.096816] ret_from_fork+0x19/0x24
>
> Cc: QCA ath9k Development <ath9k-devel@qca.qualcomm.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ba24d63dd374 ath9k: Avoid a potential deadlock
--
https://patchwork.kernel.org/patch/9957575/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: make ath10k_hw_ce_regs const
From: Kalle Valo @ 2017-09-25 7:16 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, ath10k, linux-wireless, netdev, linux-kernel,
Bhumika Goyal
In-Reply-To: <1505329312-26432-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> Make them const as they are not modified in the file referencing
> them. They are only stored in the const field 'hw_ce_reg' of an ath10k
> structure. Also, make the declarations in the header const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
496cbf3ebb6b ath10k: make ath10k_hw_ce_regs const
--
https://patchwork.kernel.org/patch/9951901/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [8/10] ath9k: Use ARRAY_SIZE macro
From: Kalle Valo @ 2017-09-25 7:15 UTC (permalink / raw)
To: Thomas Meyer; +Cc: kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1504439110050-1887263060-8-diffsplit-thomas@m3y3r.de>
Thomas Meyer <thomas@m3y3r.de> wrote:
> Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
> yourself.
> Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
> 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
> /ARRAY_SIZE(\1)/g' and manual check/verification.
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
896cbefadf62 ath9k: Use ARRAY_SIZE macro
--
https://patchwork.kernel.org/patch/9936271/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] ath9k: remove cast to void pointer
From: Kalle Valo @ 2017-09-25 7:14 UTC (permalink / raw)
To: Himanshu Jha
Cc: kvalo, ath9k-devel, linux-wireless, linux-kernel, joe,
Himanshu Jha
In-Reply-To: <1504248214-3805-1-git-send-email-himanshujha199640@gmail.com>
Himanshu Jha <himanshujha199640@gmail.com> 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.
>
> Done using Coccinellle.
> Semantic Patch used :
>
> @r@
> expression x;
> void* e;
> type T;
> identifier f;
> @@
>
> (
> *((T *)e)
> |
> ((T *)x)[...]
> |
> ((T *)x)->f
> |
> - (T *)
> e
> )
>
>
> Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
50c8cd44ed5f ath9k: remove cast to void pointer
--
https://patchwork.kernel.org/patch/9933585/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* mwifiex: Firmware wakeup failed in 4.1 kernel
From: Belisko Marek @ 2017-09-25 7:01 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: amitkarwar, nishants
Hi,
I'm using 4.1 stock kernel on imx cpu and 8897 wifi chip connected
over pcie to cpu. I did stress test by disabling AP in loop when wifi
card is connected to perform scanning and reconnect. After 25 attempts
I'll get following and after that wifi is unusable:
mwifiex_pcie 0000:01:00.0: Firmware wakeup failed
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
mwifiex_pcie 0000:01:00.0: failed to get signal information
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
ieee80211 phy0: deleting the crypto keys
I did look to some new patches and found following patch [0] but it
didn't help. Is there anything else I can try to fix this issue?
Thanks a lot.
[0] - https://patchwork.kernel.org/patch/9516615/
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH] mac80211: aead api to reduce redundancy
From: Herbert Xu @ 2017-09-25 6:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Xiang Gao, David S. Miller, linux-crypto, linux-kernel,
linux-wireless, netdev
In-Reply-To: <1506316946.2909.8.camel@sipsolutions.net>
On Mon, Sep 25, 2017 at 07:22:26AM +0200, Johannes Berg wrote:
>
> The code moves to crypto/ though, and I'm not even sure I can vouch for
> the Makefile choice there.
Thanks, I missed that. I don't think this belongs in crypto.
This proposed helper is only useful for wireless so it should
stay there.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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