From: Luca Coelho
When IBSS was implemented for DQA, we missid a few places where it
should be handled in the same way as AP.
Fixes: ee48b72211f8 ("iwlwifi: mvm: support ibss in dqa mode")
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 3 ++-
1 file changed, 2 in
From: Mordechai Goodstein
Before TVQM, all TX queues were allocated straight at init.
With TVQM, queues are allocated on demand and hence we need
to check if a queue exists before dereferencing it.
Fixes: 66128fa08806 ("iwlwifi: move to TVQM mode")
Signed-off-by: Mordechai Goodstein
Signed-off-
From: Luca Coelho
Hi,
As promised, I'll start sending things out as soon as possible, so I'm
already sending fixes intended for the 4.13 rc series, even before
it's out. :)
Some of the issues solved are:
* A few NULL pointer dereferences in the recovery flow;
* A small but important fix for IB
Hi All,
We use the mwifiex driver for wifi from kernel-backports-4.2.6.1 for
kernel version 3.2.26 and mwifiex driver from kernel tree 4.1.8
without backporting for kernel 4.1.8.
We are having issues connecting to the access point and looks like
authenticating issues during the initial associatio
From: Emmanuel Grumbach
Sometimes, we can have an firmware crash while trying to
recover from a previous firmware problem.
When that happens, lots of things can go wrong. For example
the stations don't get added properly to mvm->fw_id_to_mac_id.
Mac80211 tries to stop A-MPDU upon reconfig but in
From: Emmanuel Grumbach
iwlagn_check_ratid_empty takes the tid as a parameter, but
it doesn't check that it is not IWL_TID_NON_QOS.
Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array
with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS]
is a bad idea.
This happened in iwlagn_rx_
From: Dan Carpenter
We don't set the error code here so we end up returning ERR_PTR(0) which
is NULL. The caller doesn't expect that so it results in a NULL
dereference.
Fixes: 2e5d4a8f61dc ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: Dan Carpenter
Signed-off-by: Luca
From: Johannes Berg
A hardware/firmware error may happen at any point in time. In
particular, it might happen while mac80211 is in the middle of
a flow. We observed the following situation:
* mac80211 is in authentication flow, in ieee80211_prep_connection()
* iwlwifi firmware crashes, but no e
From: Emmanuel Grumbach
iwl_trace_data is somewhat confusing. It returns a bool
that tells if the payload of the skb should be added to
the tx_data event. If it returns false, then the payload
of the skb is added to the tx event.
The purpose is to be able to start tracing with
-e iwlwifi
and rec
This patch will fix memory leak when firmware request fails
Signed-off-by: Souptick Joarder
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 4
drivers/net/wirele
On 07/04/2017 02:21 AM, Souptick Joarder wrote:
This patch will fix memory leak when firmware load fails
Signed-off-by: Souptick Joarder
The patch title needs to be improved. "Handle memory free" tells us nothing
NACK.
Larry
On Tue, 4 Jul 2017 13:12:18 +0800
Dison River wrote:
> Hi all:
> I'd found several address leaks of "skb" buffer.When i have a
> arbitrary address write vulnerability in kernel(enabled kASLR),I can
> use skb's address find sk_destruct's address and overwrite it. And
> then,invoke close(sock_fd) f
On 07/04/2017 07:22 AM, Souptick Joarder wrote:
Any Comment for this patch ?
If you keep bugging me about your patches, I will automatically NACK them.
I have more important things to do than reviewing your patches.
FYI, Chaoming Li no longer works on these drivers.
Larry
On Wed, Jun 28,
On 04.07.2017 13:01, Kalle Valo wrote:
> Stefan Assmann writes:
>
>> Defining DEBUG_RTL871X in rtw_debug.h causes the following compile error:
>> CC [M] drivers/staging/rtl8723bs/core/rtw_mlme.o
>> In file included from drivers/staging/rtl8723bs/core/rtw_mlme.c:18:0:
>> drivers/staging/rtl8723
On 07/04/2017 04:49 PM, Kalle Valo wrote:
> Andrey Ryabinin writes:
>
>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a
>> laptop with ath10k card.
>>
>>
>> [37207.593370] [ cut here ]
>> [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274
(I was on vacation and inbox exploded again)
Brian Norris writes:
> On Thu, Jun 22, 2017 at 03:02:34PM +0200, Johannes Berg wrote:
>> On Wed, 2017-06-21 at 11:27 -0700, Brian Norris wrote:
>
>> > > Without checking the code now, it seems entirely plausible that
>> > > this is
>> > > holding some
Andrey Ryabinin writes:
> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a
> laptop with ath10k card.
>
>
> [37207.593370] [ cut here ]
> [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274
> net_rx_action+0x258/0x360
> [37207.593381] Modules
Souptick Joarder writes:
> Any Comment for this patch ?
Please don't top most and include the whole patch in the reply. It
clutters the patchwork among others.
--
Kalle Valo
Any Comment for this patch ?
On Wed, Jun 28, 2017 at 6:02 PM, Souptick Joarder wrote:
> Removing unused dummy function
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 12 --
Hi Larry,
On Wed, Jun 28, 2017 at 1:27 PM, Souptick Joarder wrote:
> _rtl92cu_init_usb_aggregation() can be removed as it is dummy one
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/dri
Stefan Assmann writes:
> Defining DEBUG_RTL871X in rtw_debug.h causes the following compile error:
> CC [M] drivers/staging/rtl8723bs/core/rtw_mlme.o
> In file included from drivers/staging/rtl8723bs/core/rtw_mlme.c:18:0:
> drivers/staging/rtl8723bs/core/rtw_mlme.c: In function ‘rtw_restruct_s
Hi Tony,
> > When working with wl18xx the nvs file is used for defining an alternate
> > mac address and override the default mac address that is stored inside
> > the wl18xx chip.
> >
> > The following commits:
> > c815fde wlcore: spi: Populate config firmware data
> > d776fc8 wlcore: sdio: Popul
Hi Tony,
>
> * Kalle Valo [170703 04:30]:
> > "Reizer, Eyal" writes:
> >
> > > When working with wl18xx the nvs file is used for defining an alternate
> > > mac address and override the default mac address that is stored inside
> > > the wl18xx chip.
> > > update the structure field with the sa
* Reizer, Eyal [170703 23:58]:
> When working with wl18xx the nvs file is used for defining an alternate
> mac address and override the default mac address that is stored inside
> the wl18xx chip.
>
> The following commits:
> c815fde wlcore: spi: Populate config firmware data
> d776fc8 wlcore: sd
* Kalle Valo [170703 04:30]:
> "Reizer, Eyal" writes:
>
> > When working with wl18xx the nvs file is used for defining an alternate
> > mac address and override the default mac address that is stored inside
> > the wl18xx chip.
> > update the structure field with the same default nvs file name t
On Tue, Jul 04, 2017 at 01:12:18PM +0800, Dison River wrote:
> Hi all:
> I'd found several address leaks of "skb" buffer.When i have a
> arbitrary address write vulnerability in kernel(enabled kASLR),I can
> use skb's address find sk_destruct's address and overwrite it. And
> then,invoke close(sock
This patch will fix memory leak when firmware load fails
Signed-off-by: Souptick Joarder
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 4
drivers/net/wireless/
27 matches
Mail list logo
