[linux-stable] 4fc2942b6e kernel BUG at kernel/time/hrtimer.c:109!

Hi Marc, We find this oops in linux-4.4.y. The gcc-6 compiled mainline kernel is fine. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y commit 4fc2942b6e2de2efc8a9d3784d4b0d3543149613 Author: Marc Zyngier AuthorDate: Fri Jan 15

[RFC 2/5] iwlwifi: fix request_module() use

The return value of request_module() being 0 does not mean that the driver which was requested has loaded. To properly check that the driver was loaded each driver can use internal mechanisms to vet the driver is now present. The helper try_then_request_module() was added to help with this,

[RFC 0/5] iwlwifi: enhance final opmode work

Although these are iwlwifi patches, there are some core module, async, firmware questions I'd appreciate a bit more review from folks on -- tx! Firmware folks / async folks / module folks: I started to look to generalize the way the iwlwifi driver uses the firmware API to request for firmware

[RFC 5/5] iwlwifi: convert final opmode work into a workqueue

This lets us offload and share all the final opmode related work necessary for either an opmode driver or new device. This has the most impact for opmode drivers as this now offloads opmode start for each device onto the workqueue. Signed-off-by: Luis R. Rodriguez ---

[RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

The firmware async callback handles the device's opmode start call, but optionally also allows opmode registration to take care of its opmode start. If the firmware callback handles it its error path in case of opmode start failure has a few pieces of code missing from the opmode registration. The

[RFC 3/5] iwlwifi: share opmode start work code

The firmware async callback and the opmode registration share some functionality -- to start the drv's opmode. Move this work into a helper which is shared. This should help us share fixes should these diverging code paths change. Signed-off-by: Luis R. Rodriguez ---

[RFC 4/5] iwlwifi: move opmode loading to shared routine

This helps us compartmentalize all last required opmode work and declutter the async firmware callback. Signed-off-by: Luis R. Rodriguez --- drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 33 +++- 1 file changed, 18 insertions(+), 15 deletions(-) diff

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

Hi Kalle, On Thu, Feb 16, 2017 at 03:18:48PM +0200, Kalle Valo wrote: Arend Van Spriel writes: On 16-2-2017 11:01, Kalle Valo wrote: Arend Van Spriel writes: On 16-2-2017 10:39, Rafał Miłecki wrote: On 02/16/2017 10:31 AM,

[RFC V2 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

For non-ETSI regulatory domain, CAC result on DFS channel may not be valid once moving out of that channel (as done during remain-on-channel, scannning and off-channel tx). Running CAC on an operating DFS channel after every off-channel operation will only add complexity and disturb the current

[RFC V2 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

DFS requirement for ETSI domain (section 4.7.1.4 in ETSI EN 301 893 V1.8.1) is the only one which explicitly states that once DFS channel is marked as available afer the CAC, this channel will remain in available state even moving to a different operating channel. But the same is not explicitly

[RFC V2 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

Sharing DFS channel state across multiple wiphys (radios) could be useful with multiple radios on the system. When one radio completes CAC and markes the channel available another radio can use this information and start beaconing without really doing CAC. Whenever there is a state change in dfs

[RFC V2 0/3] Pre-CAC and sharing DFS state across multiple radios

Currently irrespective of dfs domain and radar detection activity pre-CAC results for a wiphy are retained till the wiphy is detroyed. This may not be preferred in non-ETSI dfs domain where pre-CAC is not explicitly mentioned in the respective DFS requirement spec. This patch set modifies the

[PATCH] ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device

T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1eda ProdID=2315 Rev=01.08 S: Manufacturer=ATHEROS S: Product=USB2.0 WLAN S: SerialNumber=12345 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0

TL-WN823N

Hi, I have a problem with rtl8xxxu driver, which seems to not work with a dongle tp-link TL-WN823N model. I just filled out a 4.9.10 kernel and the device is not fully recognized .. I can only scan network and not link. Thank you lsusb: Bus 002 Device 002: ID 2357:0109 dmesg: [gio feb 16

pull-request: wireless-drivers-next 2017-02-17

Hi Dave, few -next patches I'm still hoping to get to 4.11 to keep my backlog short, nothing major here. Please let me know if there are any problems. Kalle The following changes since commit 3b03cc0783b03ddd668ff3f86419bc67d0664e89: net: natsemi: ns83820: use new api

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

Arend Van Spriel writes: > On 16-2-2017 11:01, Kalle Valo wrote: >> Arend Van Spriel writes: >> >>> On 16-2-2017 10:39, Rafał Miłecki wrote: On 02/16/2017 10:31 AM, Kalle Valo wrote: > (Adding linux-wireless) > >

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

Hi all, Yes sorry, it's a false report related to how we do bisects. CONFIG_BRCM_TRACING=y CONFIG_BRCMDBG=y but DEBUG is not defined. I think it would help if CONFIG_BRCMDBG set DEBUG or if some of the tests for DEBUG used CONFIG_BRCMDBG instead. Arend or Rafał, would you be able to look

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

On 16-2-2017 11:01, Kalle Valo wrote: > Arend Van Spriel writes: > >> On 16-2-2017 10:39, Rafał Miłecki wrote: >>> On 02/16/2017 10:31 AM, Kalle Valo wrote: (Adding linux-wireless) Randy Dunlap writes: > On 02/07/17

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

On 2017-02-16 09:38, Arend Van Spriel wrote: On 16-2-2017 8:26, Rafał Miłecki wrote: From: Rafał Miłecki Failing to load NVRAM file isn't critical if we manage to get platform one in the fallback path. It means warnings like: [ 10.801506] brcmfmac :01:00.0: Direct

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

On 16-2-2017 10:32, Rafał Miłecki wrote: > On 2017-02-16 10:18, Arend Van Spriel wrote: >> On 16-2-2017 10:04, Rafał Miłecki wrote: >>> On 2017-02-16 09:38, Arend Van Spriel wrote: On 16-2-2017 8:26, Rafał Miłecki wrote: > From: Rafał Miłecki > > Failing to load

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

Arend Van Spriel writes: > On 16-2-2017 10:39, Rafał Miłecki wrote: >> On 02/16/2017 10:31 AM, Kalle Valo wrote: >>> (Adding linux-wireless) >>> >>> Randy Dunlap writes: >>> On 02/07/17 02:02, kbuild test robot wrote: > Hi Kalle,

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

On 16-2-2017 10:39, Rafał Miłecki wrote: > On 02/16/2017 10:31 AM, Kalle Valo wrote: >> (Adding linux-wireless) >> >> Randy Dunlap writes: >> >>> On 02/07/17 02:02, kbuild test robot wrote: Hi Kalle, FYI, the error/warning still remains. tree:

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

On 2017-02-16 10:18, Arend Van Spriel wrote: On 16-2-2017 10:04, Rafał Miłecki wrote: On 2017-02-16 09:38, Arend Van Spriel wrote: On 16-2-2017 8:26, Rafał Miłecki wrote: From: Rafał Miłecki Failing to load NVRAM file isn't critical if we manage to get platform one in

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

On 02/16/2017 10:31 AM, Kalle Valo wrote: (Adding linux-wireless) Randy Dunlap writes: On 02/07/17 02:02, kbuild test robot wrote: Hi Kalle, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

(Adding linux-wireless) Randy Dunlap writes: > On 02/07/17 02:02, kbuild test robot wrote: >> Hi Kalle, >> >> FYI, the error/warning still remains. >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head:

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

On 16-2-2017 10:04, Rafał Miłecki wrote: > On 2017-02-16 09:38, Arend Van Spriel wrote: >> On 16-2-2017 8:26, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> Failing to load NVRAM file isn't critical if we manage to get platform >>> one in the fallback path. It means

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

On 16-2-2017 8:26, Rafał Miłecki wrote: > From: Rafał Miłecki > > Failing to load NVRAM file isn't critical if we manage to get platform > one in the fallback path. It means warnings like: > [ 10.801506] brcmfmac :01:00.0: Direct firmware load for >

Re: [PATCH 2/2] brcmfmac: don't warn user if loading firmware file with NVRAM fails

On 2017-02-16 02:19, Andy Shevchenko wrote: On Thu, Feb 16, 2017 at 12:29 AM, Rafał Miłecki wrote: From: Rafał Miłecki This isn't critical as we use platform NVRAM as fallback and it's very common case of all Broadcom home routers. Thanks for the new