Hi Greg,
sorry for the delay, I was on vacation.
On 08/08/2015 11:51 PM, gre...@linuxfoundation.org wrote:
The patch below does not apply to the 3.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the
The patch below does not apply to the 3.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree,
then please email the backport, including the original git commit id to
stable@vger.kernel.org.
I'll drop this one for 3.10.
Conflicts are too big for my
On Tue, Nov 11, 2014 at 02:55:33AM +0200, Emmanuel Grumbach wrote:
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
commit 9180ac50716a097a407c6d7e7e4589754a922260 upstream.
The LTR is the handshake between the device and the root complex about
the latency allowed when the bus
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
to the 3.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-
queue.git;a=summary
The filename of
On Mon, Nov 10, 2014 at 08:39:06AM +, Grumbach, Emmanuel wrote:
This is a note to let you know that I've just added the patch titled
iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
to the 3.17-stable tree which can be found at:
http
This card appears in an Asus TP300LA laptop (from Chris Mens). lspci
output:
02:00.0 Network controller [0280]: Intel Corporation Wireless 7260
[8086:08b1] (rev cb)
Subsystem: Intel Corporation Device [8086:4c70]
Verified against v3.10.54 and v3.17-rc5-13-g2324067.
This card appears in an Asus TP300LA laptop (from Chris Mens). lspci
output:
02:00.0 Network controller [0280]: Intel Corporation Wireless 7260
[8086:08b1] (rev cb)
Subsystem: Intel Corporation Device [8086:4c70]
Verified against v3.10.54 and v3.17-rc5-13-g2324067.
Cc:
On Sun, Aug 31, 2014 at 05:39:45PM +, Grumbach, Emmanuel wrote:
Please consider the following commits for the various stable trees,
which greatly reduce the number of disconnections due to beacon loss
seen with Intel 7260 wireless. These are benficial starting with
3.11, when
On Sun, Aug 31, 2014 at 12:04:19PM +, Grumbach, Emmanuel wrote:
-Original Message-
From: Luis Henriques [mailto:luis.henriq...@canonical.com]
Sent: Monday, August 18, 2014 12:31 PM
To: linux-ker...@vger.kernel.org; stable@vger.kernel.org; kernel-
t...@lists.ubuntu.com
-Original Message-
From: Luis Henriques [mailto:luis.henriq...@canonical.com]
Sent: Monday, August 18, 2014 12:31 PM
To: linux-ker...@vger.kernel.org; stable@vger.kernel.org; kernel-
t...@lists.ubuntu.com
Cc: Grumbach, Emmanuel; Luis Henriques
Subject: [PATCH 3.11 005/137] iwlwifi
Please consider the following commits for the various stable trees, which
greatly reduce the number of disconnections due to beacon loss seen with
Intel 7260 wireless. These are benficial starting with 3.11, when beacon
monitoring support was first added to iwlmvm (the second commit may
apply
On Sun, May 18, 2014 at 11:21:40AM +0300, Emmanuel Grumbach wrote:
From: Alexander Bondar alexander.bon...@intel.com
commit c63722cfd441bd3a99c65fa4c40bc65d7776e772 upstream
Enable beacon filter only if at least one beacon from candidate AP is
received before or after association.
On 05/19/2014 10:21 PM, Emmanuel Grumbach wrote:
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
This feature has been causing trouble - disable it for now.
Fixes are available, but they are too big to be backported.
Just to make sure, 3.12 does not need this, right?
Yes
On 05/19/2014 10:21 PM, Emmanuel Grumbach wrote:
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
This feature has been causing trouble - disable it for now.
Fixes are available, but they are too big to be backported.
Just to make sure, 3.12 does not need this, right?
Yes - 3.12
From: Alexander Bondar alexander.bon...@intel.com
commit c63722cfd441bd3a99c65fa4c40bc65d7776e772 upstream
Enable beacon filter only if at least one beacon from candidate AP is received
before or after association. Check this condition before enabling BF upon
secured association
On Sat, 2014-03-22 at 09:51 -0700, Greg Kroah-Hartman wrote:
On Sat, Mar 22, 2014 at 05:28:02PM +0100, Andreas Sturmlechner wrote:
Original Message from: Greg Kroah-Hartman
gre...@linuxfoundation.org
Does Linus's tree also have this problem for you? Or does it work
there? If
The patch below does not apply to the 3.13-stable tree.
If someone wants it applied there, or to any other stable or longterm tree,
then please email the backport, including the original git commit id to
stable@vger.kernel.org.
N/M - after all, this patch isn't crucial in 3.13. We don't
From: Emmanuel Grumbach [mailto:egrumb...@gmail.com]
Sent: Tuesday, February 04, 2014 7:13 PM
To: Greg KH
Cc: stable@vger.kernel.org; Grumbach, Emmanuel
Subject: [PATCH 3.10] iwlwifi: pcie: enable oscillator for L1 exit
I wrote here 3.10, but same resolution should work for 3.11 (you'll
On Tue, Feb 04, 2014 at 05:15:16PM +, Grumbach, Emmanuel wrote:
From: Emmanuel Grumbach [mailto:egrumb...@gmail.com]
Sent: Tuesday, February 04, 2014 7:13 PM
To: Greg KH
Cc: stable@vger.kernel.org; Grumbach, Emmanuel
Subject: [PATCH 3.10] iwlwifi: pcie: enable oscillator
From: Grumbach, Emmanuel
Sent: Tuesday, February 04, 2014 7:45 PM
To: 'Luis Henriques'
Cc: Emmanuel Grumbach; Greg KH; stable@vger.kernel.org
Subject: RE: [PATCH 3.10] iwlwifi: pcie: enable oscillator for L1 exit
On Tue, Feb 04, 2014 at 05:15:16PM +, Grumbach, Emmanuel wrote
On Tue, Aug 20, 2013 at 11:22:21PM +0300, Emmanuel Grumbach wrote:
On Tue, Aug 6, 2013 at 4:42 PM, Greg KH g...@kroah.com wrote:
On Tue, Aug 06, 2013 at 02:39:39PM +0200, Johannes Berg wrote:
[Emmanuel is on vacation, I'll cover for him]
On Fri, 2013-08-02 at 17:02 +0800, Greg KH
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
This small patch series enables 7260 and 3160 devices on 3.9 kernel. Three
patches are already in linux.git (3.11-rc1).
One patch is 3.9 specific and disables configuration that is not supported in
3.9.
Will resend without the Change-ID
Commit e3d4bc8cc0230e8dc8033484666f03f87392a8c4 upstream.
Backported for 3.9-stable. Reinstated IWL_FIRST_AMPDU_QUEUE which was
obsoleted by IWL_MVM_FIRST_AGG_QUEUE in 398e8c6 3.10-rc1. And adjusted
context.
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
Move the counter for
Commit 51b6b9e029e81c857f9d8d17060f499cd25febdb upstream.
Backported for 3.9-stable. Adjusted context.
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
Without this command, the firmware will filter out all the multicast frames.
Let
them all in as for now. Later we will want to
commit 2d5d50ee596361566f7f84300117cba7d7672bc5 upstream.
Backported for 3.8. Adjusted context.
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed and might send HCMD
So I thought that if the patch is in linux-next it is acceptable for stable,
but I misunderstood the rules.
This patch will be sent to 3.7 with stable as CC-ed. Sorry for that.
commit 4e760f1ab267edcd6e4b232ff732fc9cdc659ebb upstream.
This can happen when we shut down suddenly an
Hi, this triggers the following build warning:
linux-stable/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c: In function
'iwl_trans_pcie_tx_start':
linux-stable/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c:874:2: warning:
passing argument 1 of 'iwl_write_prph' from incompatible pointer type
Subject: [PATCH 3.0] iwlwifi: don't mess up the SCD when removing a key
commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream.
When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid
I see, but I send all my patches from Intel's smtp, which automatically adds
that (trust me, I am not typing that every time :-)), and you seem to have no
issues with the other patches.
Anyway, Johaness, can you please send this one from @sipsolutions.net ?
On Thu, Jun 07, 2012 at 06:01:29PM
Subject: [PATCH] iwlwifi: fix the Transmit Frame Descriptor rings
commit ebed633c61c023e5d1aa4ed159cd67406e9e37c2 upstream.
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to
The patch below does not apply to the 3.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to stable@vger.kernel.org.
thanks,
greg k-h
-- original commit
31 matches
Mail list logo
