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 17:41:09 2016 +
Comm
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, allowin
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 thr
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
---
drivers/net/wireless/intel/
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
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
---
drivers/net/wireless/intel/i
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 --git a/drivers/net
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, Kalle Valo wrote:
(Adding linux-wireless)
Arend or Rafał, would
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
lin
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 sta
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 c
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 curre
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 #EPs=
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 16:08
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 ethtool_{get|set}_link_k
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)
>
> Arend or Rafał, would you be able to look at this build problem?
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 at
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 02:02, kbuild test robot wrote:
>> Hi Kalle,
>>
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 firmware load for
brcm
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 NVRAM file isn't c
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,
>
> FYI, the error/warning still remains.
>
>
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:
https://git.kernel.org
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 the fallback path. It
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
head: 8b1b41ee74f9712c355d
(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: 8b1b41ee74f9712c355d66dc105bbea663ae0afd
>>
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 warnings like:
>>> [ 10
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
> brcm/brcmfmac43602-pcie.txt failed with
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 firmware
loading function we can achieve t
28 matches
Mail list logo
