RE: [PATCH 09/28] mac80211: pass the TWT support bits in extended caps to the driver

> > On Mon, 2018-09-03 at 09:28 +, Grumbach, Emmanuel wrote: > > > > > For managed mode, the driver will need to check the HE cap along with > > the extended capabilities to determine whether AP supports TWT or not. > > Do you have any idea why it's there twi

RE: [PATCH 09/28] mac80211: pass the TWT support bits in extended caps to the driver

> > > Since those bits are present in the HE Cap as well, we can set the > > capability bits in the Extended Capabilities IE based on what is > > advertised in the HE Cap IE. > > It's not clear to me what this is trying to say, you don't seem to do anything > with the HE capabilities in the

RE: [linuxwifi] Simultaneous 2.4 GHz WiFi and Bluetooth issue on Intel Dual Band Wireless-AC 8260

> On 04/20/2018 01:03 AM, Emmanuel Grumbach wrote: > >> Under Windows 10, the hardware appears to work without issue. > >> Additionally, I believe I managed to warm-reboot from Windows 10 to > >> Linux (with Bluetooth connected), and was able to continue using the > >> same 2.4 GHz WiFi and

RE: [linuxwifi] Null pointer dereference in iwlwifi when starting ad-hoc network

Hi, > I get this oops in 4.15rc9 when doing the following: > > # iw dev wlp2s0 set type ibss > # ip link set dev wlp2s0 up > # iw dev wlp2s0 ibss join "TEST" 2412 > > The oops happens after some delay (approx. 5 seconds). > > Hardware is: > > 02:00.0 Network controller: Intel Corporation

Re: [PATCH 0/5] iwlwifi: updates intended for v4.16 2017-12-23

Hi Kale, On Fri, 2018-01-12 at 13:31 +0200, Kalle Valo wrote: > From: Luca Coelho > > > > Hi, > > > > Here's the fourth and probably last batch of patches intended for > > 4.16. Nothing major, just continued development, some cleanups and > > small fixes here and

RE: [PATCH] mac80211: always update the PM state of a peer on MGMT / DATA frames

> > The 2016 version of the spec is more generic about when the AP should > update the power management state of the peer: > the AP shall update the state based on any management or data frames. This > means that even non-bufferable management frames should be looked at to > update to maintain

RE: [PATCH 06/10] cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}

> > On Tue, 2017-09-05 at 16:49 +, Grumbach, Emmanuel wrote: > > On Tue, 2017-09-05 at 16:30 +0200, Johannes Berg wrote: > > > On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote: > > > > > > > + regd = get_wiphy_regdom(wiphy); > > >

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On Tue, 2017-08-15 at 10:49 +0300, Emmanuel Grumbach wrote: > On Tue, 2017-08-15 at 10:16 +0300, Kalle Valo wrote: > > "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes: > > > > > On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote: > > >

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On Tue, 2017-08-15 at 10:16 +0300, Kalle Valo wrote: > "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes: > > > On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote: > > > Emmanuel Grumbach <emmanuel.grumb...@intel.com> writes: > &g

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On Mon, 2017-08-14 at 13:36 -0700, Igor Mitsyanko wrote: > On 08/14/2017 01:13 PM, Grumbach, Emmanuel wrote: > > > It is kind of not clear right now for drivers where to get > > > information from: > > > - NL attributes passed from userspace and forwarded to a dri

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On Mon, 2017-08-14 at 13:08 -0700, Igor Mitsyanko wrote: > On 08/14/2017 12:22 PM, Arend van Spriel wrote: > > On 14-08-17 15:49, Emmanuel Grumbach wrote: > > > User space can now allow the kernel to associate to an AP > > > that requires MFP or that doesn't have MFP enabled in the > > > same

Re: [PATCH] nl80211: add an option to allow MFP without requiring it

On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote: > Emmanuel Grumbach writes: > > > User space can now allow the kernel to associate to an AP > > that requires MFP or that doesn't have MFP enabled in the > > same NL80211_CMD_CONNECT command. > > The driver /

RE: [PATCH] mac80211: don't look at the PM bit of BAR frames

> > On 06/08/2017 04:00 AM, Emmanuel Grumbach wrote: > > When a peer sends a BAR frame with PM bit clear, we should not modify > > its PM state as madated by the spec in > > 802.11-20012 10.2.1.2. > > > > Signed-off-by: Emmanuel Grumbach > >

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

> > On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote: > > Hi, > > Hi, > > > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure > > that we don't index tid_data with this. Hence I think the proper fix is: > > >

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

Hi, > Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask > > Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid, > which gives 16 possible values for tid. > This is problematic because IWL_MAX_TID_COUNT is 8, so indexing > iwl_priv::tid_data can

RE: Regression with Intel 3160 AP: client not reconnecting

> > Hi Jarek, > > [snip] > > > What might be the cause? Is there anything I can do to help debug or > > fix this? > > Thanks for the detailed bug report and analysis! I can't analyse this in depth > right now, can you please file a bug on bugzilla.kernel.org? When you do so, please CC

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

> > On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote: > > > > > > 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

RE: [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 >

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

Hi Luis, > > 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

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On Thu, 2016-09-15 at 10:59 -0700, Ben Greear wrote: > On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote: > > On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote: > > > On 09/15/2016 07:06 AM, Valo, Kalle wrote: > > > > Ben Greear <gree...@candelatech.com> writ

Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.

On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote: > On 09/15/2016 07:06 AM, Valo, Kalle wrote: > > Ben Greear writes: > > > > > On 09/14/2016 07:18 AM, Valo, Kalle wrote: > > > > gree...@candelatech.com writes: > > > > > > > > > From: Ben Greear

pull request: iwlwifi 2016-04-12

Hi Kalle, Here is a pull request for 4.6. I have here a patch that was merged to -next already, but clearly, it should have been routed through the current cycle's trees. Sorry about that. The patch is: commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368 Author: Ayala Beker

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

> On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote: > > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote: > >>> If I understad correctly this error happen 100% of the time, not > >>> only during init. Hence seems there is an issue here, i.e. cur_uc

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

> > On Mon, Jul 11, 2016 at 06:27:30PM +, Grumbach, Emmanuel wrote: > > I guess that works, but it seems wrong to me. Usually, registration > > should happen only upon INIT, and yes, at that time the firmware is > > not ready to provide the information yet. >

Re: [PATCH -next] iwlwifi: mvm: use setup_timer instead of init_timer and data fields

On Tue, 2016-07-12 at 11:40 +, weiyj...@163.com wrote: > From: Wei Yongjun > > Use setup_timer function instead of initializing timer with the > function > and data fields > > Signed-off-by: Wei Yongjun > --- Thanks - I picked

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

On Mon, 2016-07-11 at 14:19 -0400, Prarit Bhargava wrote: > > On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote: > > On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava > > wrote: > > > > > > Didn't get any feedback or review comments on this patch. > > > Resending ... > > > >

pull request: new firmware files for all mvm wireless devices

Hi Kyle, Intel is releasing new firmware versions for all its mvm wireless devices. For devices 7260, 7265 and 3160, this is the last firmware updates. We may still have critical bug fixes, but those won't get any new major releases. They will stay with -17.ucode. For 7265D and up, we release

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

> > Emmanuel Grumbach wrote: > > In that case, please try -21.ucode and send me again the output of the > firmware error. > > $ dmesg | grep iwlwifi > [ 14.858440] iwlwifi :04:00.0: Unsupported splx structure > [ 14.863591] iwlwifi :04:00.0: loaded firmware version 21.361477.0 >

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

> > Emmanuel Grumbach wrote: > > Can you please try the newest firmware? > > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux- > firmware.git/commit/?id=72266846faa78b939a864842a2aa6ecd8fe6989b > > Yes, I've tried the newest firmware. The problem still persists. > > > You should pick

RE: Problem: iwlwifi: Microcode SW error detected. Restarting 0x2000000

> > With a current kernel my wifi won't work after suspending and resuming > my laptop (a ThinkPadd 11e). > This has worked in 4.0.0 and below, so this is a regression. > The commit that introduced this issue is > 8d193ca26cc28019e760b77830295a0c349d90dc. > > How to reproduce: > 1. Boot. > 2.

pull request: iwlwifi 2016-05-04

Hi Kalle, I know it is extremely late in the cycle, but this patch is intended for 4.6... It fixes a regression I introduced: a P2P specification violation as mentioned in the commit message. The patch is rather big in terms of number of lines changed, but the semantics is very simple. I have to

Re: RSS configuration in iwlwifi

On Wed, 2016-04-20 at 19:22 +0300, Emmanuel Grumbach wrote: > On Wed, 2016-04-20 at 16:47 +0100, Ben Hutchings wrote: > > On Wed, 2016-04-20 at 15:30 +, Grumbach, Emmanuel wrote: > > > Hi Ben, > > > > > > > > > Thanks for looking at our code. &g

Re: RSS configuration in iwlwifi

On Wed, 2016-04-20 at 16:47 +0100, Ben Hutchings wrote: > On Wed, 2016-04-20 at 15:30 +0000, Grumbach, Emmanuel wrote: > > Hi Ben, > > > > > > Thanks for looking at our code. > > > > > > On Wed, 2016-04-20 at 16:08 +0100, Ben Hutchings wrote

Re: RSS configuration in iwlwifi

Hi Ben, Thanks for looking at our code. On Wed, 2016-04-20 at 16:08 +0100, Ben Hutchings wrote: > I'm not sure if you were aware, but there is a standard API for > configuring RSS in network drivers, part of ethtool_ops. I think > iwlwifi should implement that rather than a driver-specific

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote: > On Fri, Apr 15, 2016 at 04:16:02AM +0000, Grumbach, Emmanuel wrote: > > [1] > > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi > > fi.git/ > > It is very strange to pull from th

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote: > Hi, > > so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip. > After that, wifi is dead in the water. Anyone have a clue? > > And 4.5 seems fine, I'm typing from it as we speak. > ... > [ 661.142657] [

Re: pull request: iwlwifi 2016-04-12

On Tue, 2016-04-12 at 11:14 +0300, Emmanuel Grumbach wrote: > Hi Kalle, > > I have here a pull request for 4.6. There is patch in this pull > request > that has been sent to -next already but should really have been > included in the current cycle. Sorry for the mess. > > The commit appears in

pull request: iwlwifi 2016-04-12

Hi Kalle, I have here a pull request for 4.6. There is patch in this pull request that has been sent to -next already but should really have been included in the current cycle. Sorry for the mess. The commit appears in -next as: commit a0b09f13036cedfd67c9cb4b9d05138e7022723d Author: Ayala

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

> On Sun, Apr 10, 2016 at 1:28 PM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: > >> > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote: > >> Is the iwlwifi driver capable of capturing data frames when the > >> channel bonding is set to 80M

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

> On Tue, Apr 5, 2016 at 4:34 PM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: > > On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote: > >> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel > >> <emmanuel.grumb...@intel.com> wrote: >

RE: [PATCHv3 RESEND 01/11] cfg80211: add start / stop NAN commands

> > On Tue, Mar 29, 2016 at 12:34:59PM +0300, Emmanuel Grumbach wrote: > > This allows user space to start/stop NAN interface. > > A NAN interface is like P2P device in a few aspects: it doesn't have a > > netdev associated to it. > > Add the new interface type and prevent operations that can't

RE: [PATCHv3 RESEND 01/11] cfg80211: add start / stop NAN commands

> On Tue, Mar 29, 2016 at 12:34:59PM +0300, Emmanuel Grumbach wrote: > > Define several attributes that may be configured by user space when > > starting NAN functionality (master preference and dual band operation) > > > diff --git a/include/uapi/linux/nl80211.h > >

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote: > On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: > > > > > > Hello, > > > > > > I am trying to capture packets that are exchanged between an AP &g

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

> > Hello, > > I am trying to capture packets that are exchanged between an AP and a > smartphone on the 5Ghz frequency. For generating traffic, I upload UDP > traffic from a laptop PC towards the smartphone using iperf. > > The problem is that I can see _only_ the control frames like RTS/CTS,

pull request: iwlwifi-next 2016-03-30

Hi Kalle, This is a pull request for 4.7. Lots of work here and more to come when dependencies on mac80211 will be resolved. Let me know if you have issues! Thanks. The following changes since commit 1200b6809dfd9d73bc4c7db76d288c35fa4b2ebe: Merge

pull request: iwlwifi 2016-03-30

Hi Kalle, This is a pull request for 4.6 that includes 2 trivial fixes. Please let me know if you have issues. Thanks! The following changes since commit 1200b6809dfd9d73bc4c7db76d288c35fa4b2ebe: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2016-03-19 10:05:34 -0700)

Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote: > From: Colin Ian King > > isr_stats is written twice with the same value, remove one of the > redundant assignments to isr_stats. > > Signed-off-by: Colin Ian King > --- Applied -

Re: [PATCH v2] cfg80211: add start / stop NAN commands

On Thu, 2016-03-24 at 19:30 +0100, Arend Van Spriel wrote: > > On 24-3-2016 16:12, Emmanuel Grumbach wrote: > > This allows user space to start/stop NAN interface. > > A NAN interface is like P2P device in a few aspects: it > > doesn't have a netdev associated to it. > > Add the new interface

Re: [PATCH v3] iwlwifi: dvm: use alloc_ordered_workqueue()

On 03/19/2016 07:15 AM, Eva Rachel Retuya wrote: > Use alloc_ordered_workqueue() to allocate the workqueue instead of > create_singlethread_workqueue() since the latter is deprecated and is > scheduled > for removal. > > There are work items doing related operations that shouldn't be swapped

Re: iwlwifi incomplete initialization in Linux 4.5?

On 03/16/2016 11:44 PM, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 2:23 PM, Linus Torvalds > wrote: >> >>> Do you use 20Mhz or 40MHz? >> >> HT20 on 2.4GHz, HT40 on 5GHz. >> >> At least that's the wireless AP setup. >> >>> Basically, I'd like to see the output

RE: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()

> Hello, > > On Thu, Mar 17, 2016 at 01:43:22PM +0100, Johannes Berg wrote: > > On Thu, 2016-03-17 at 20:37 +0800, Eva Rachel Retuya wrote: > > > Use alloc_workqueue() to allocate the workqueue instead of > > > create_singlethread_workqueue() since the latter is deprecated and > > > is scheduled

Re: iwlwifi incomplete initialization in Linux 4.5?

On 03/16/2016 11:23 PM, Linus Torvalds wrote: > On Wed, Mar 16, 2016 at 2:13 PM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: >> >> This ... typically means that the firmware got stuck while sending >> packets. Can you tell me on what band your router

Re: iwlwifi incomplete initialization in Linux 4.5?

Hi Linus, On 03/16/2016 10:48 PM, Linus Torvalds wrote: > So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made > the wireless no longer work with a 4.5 kernel. I could get the > occasional packets through, but not many, and ti would hang for ten > seconds at a time, and then

Re: iwlwifi incomplete initialization in Linux 4.5?

Replying to self to remove people who were added in CC and should really have been BCC'ed. On 03/16/2016 11:13 PM, Grumbach, Emmanuel wrote: > Hi Linus, > > On 03/16/2016 10:48 PM, Linus Torvalds wrote: >> So I upgraded the firmware on my Intel NUC (NUC6i3SYK), and that made

Re: pull request: iwlwifi -21.ucode firmware

On 03/10/2016 08:50 PM, Kyle McMartin wrote: > On Thu, Mar 10, 2016 at 07:29:15AM +0000, Grumbach, Emmanuel wrote: >> Hi Kyle, >> >> This is a pull request to include our latest available firmware into >> mainline linux-firmware.git. >> >> It includes

pull request: iwlwifi -21.ucode firmware

Hi Kyle, This is a pull request to include our latest available firmware into mainline linux-firmware.git. It includes -21.ucode for various devices including devices for which this is the first supported firmware (3168 and 8265). This firmware is supported starting kernel 4.6. Please pull!

pull request: iwlwifi-next 2016-03-09

Hi Kalle, this is the very last pull request for 4.6. I hope it is not too late. Most of it are fixes for code that is already in wireless-drivers.next.git. There are a few other patches as well. Let me know if you have issues! Thank you. The following changes since commit

RE: [PATCH] mac80211: Set global RRM capability

> Subject: [PATCH] mac80211: Set global RRM capability > > Allow publishing RRM capabilities for features that are not HW dependent. > > Signed-off-by: Emmanuel Grumbach > --- Err... please ignore.. > net/mac80211/main.c | 3 ++- > 1 file changed, 2

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

On 03/07/2016 07:15 PM, Avery Pennarun wrote: > On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote: >> If I can just get a coherent patch set that I can build, I will gladly >> join you on the testing ath9k in particular... can probably do ath10k, >> too - and do a bit of

Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak

On 03/06/2016 02:04 PM, Kalle Valo wrote: > Luca Coelho writes: > >> On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote: >>> Emmanuel Grumbach writes: >>> From: Matti Gottlieb If the opmode is stopped and

Re: [PATCH] mac80211_hwsim: Set global RRM capability

On 03/03/2016 05:45 PM, Johannes Berg wrote: > On Wed, 2016-03-02 at 12:36 +0000, Grumbach, Emmanuel wrote: >>> >> I had the same thinking, but somehow people convinced me that a >> driver may prefer not to advertise this without its explicit >> consent. >

pull request: iwlwifi-next 2016-03-02

Hi Kalle, This is a pull request for 4.6. It is big because a lot of patches were waiting for code in mac80211-next which is now in net-next. As you figured, I need you to pull Johannes's mac80211-next-for-davem-2016-02-26 before you pull this from me. Of course, you can just merge net-next.

pull request: iwlwifi 2016-02-25

Hi Kalle, This is a pull request for 4.5 still. Two small fixes. One of them has a really visible impact when we remove stations. Let me know if you have issues! Thanks. The following changes since commit 20aa99bbddae74bded68338f9ba200ccae02858b: iwlwifi: pcie: fix erroneous return value

RE: intel7260 - iface up sometimes failed

> > Hi Janusz, > > > > > Hello, > > > > I have intel7260 connected via external PCIe + DELL latitude e6430. > > > > [ 5199.805417] iwlwifi :04:00.0: enabling device (0100 -> 0102) [ > > 5199.809222] iwlwifi :04:00.0: loaded firmware version > > 17.275772.0 op_mode iwlmvm > > [

RE: intel7260 - iface up sometimes failed

Hi Janusz, > > Hello, > > I have intel7260 connected via external PCIe + DELL latitude e6430. > > [ 5199.805417] iwlwifi :04:00.0: enabling device (0100 -> 0102) [ > 5199.809222] iwlwifi :04:00.0: loaded firmware version > 17.275772.0 op_mode iwlmvm > [ 5199.819548] iwlwifi

pull request: iwlwifi-2016-02-16

Hi Kalle, This is a pull request for 4.5. Apart from my RF-Kill fix, the patches are really small. My RF-Kill patch needed to move code around to avoid adding a forward declaration and on the way there were a few very trivial code style fixes, that were needed to make checkpatch happy. Let me

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

On 02/15/2016 11:21 AM, Eliad Peller wrote: > On Mon, Feb 15, 2016 at 11:16 AM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: >> >> On 02/15/2016 11:06 AM, Eliad Peller wrote: >>> On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel >>> <e

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

On 02/15/2016 11:06 AM, Eliad Peller wrote: > On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel > <emmanuel.grumb...@intel.com> wrote: >> >> On 02/14/2016 09:33 PM, Johannes Berg wrote: >>> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote: >>>

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

On 02/14/2016 09:33 PM, Johannes Berg wrote: > On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote: >> >> Since the 3rd patch needs to be dropped anyway, let's route this one >> through my tree as usual. > It doesn't really have to be dropped, why? We can just make the same > adjustment

Re: [PATCH] codel: add forgotten inline to functions in header file

fixing linux-wireless address ... On 02/11/2016 04:30 PM, Eric Dumazet wrote: > On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote: >> Signed-off-by: Emmanuel Grumbach >> --- >> -static bool codel_should_drop(const struct sk_buff *skb, >> -

Re: [PATCH] codel: add forgotten inline to functions in header file

On 02/11/2016 05:12 PM, Eric Dumazet wrote: > On Thu, 2016-02-11 at 15:05 +0000, Grumbach, Emmanuel wrote: > > >> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the >> codel_get_time and associated utils (_before, _after) in iwlwifi. >> They'r

Re: [PATCH] iwlwifi: fix erroneous return value

On 02/10/2016 07:10 PM, Anton Protopopov wrote: > The iwl_trans_pcie_start_fw() function may return the positive value EIO > instead of -EIO in case of error. > > Signed-off-by: Anton Protopopov > --- > drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +- > 1 file

Re: [RFC RESEND] iwlwifi: pcie: transmit queue auto-sizing

On 02/05/2016 12:06 AM, Dave Taht wrote: > I am not on linux-wireless nor netdev presently, but... > > On Thu, Feb 4, 2016 at 12:16 PM, Emmanuel Grumbach > wrote: >> As many (all?) WiFi devices, Intel WiFi devices have >> transmit queues which have 256 transmit

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

On 02/04/2016 10:46 PM, Ben Greear wrote: > On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote: >> As many (all?) WiFi devices, Intel WiFi devices have >> transmit queues which have 256 transmit descriptors >> each and each descriptor corresponds to an MPDU. >> This means that when it is full, the

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[ snip ] > >> > > > > Are you sure that the antenna that reported 0 "recovers" and reports good > values later? > > In fact it does, but apparently that's not the problem (I've checked with > monitor device and after seeing zeros during calibration I see packets and > max rate coming in from

Re: [PATCH 04/31] iwlwifi: pcie: add initial RTPM support for PCI

On 02/01/2016 04:32 PM, Kalle Valo wrote: > Emmanuel Grumbach writes: > >> From: Luca Coelho >> >> Add an initial implementation of runtime power management (RTPM) for >> PCI devices. With this patch, RTPM is only used when wifi is off >>

Re: [PATCH 04/31] iwlwifi: pcie: add initial RTPM support for PCI

On 02/01/2016 04:38 PM, Grumbach, Emmanuel wrote: > > On 02/01/2016 04:32 PM, Kalle Valo wrote: >> Emmanuel Grumbach <emmanuel.grumb...@intel.com> writes: >> >>> From: Luca Coelho <luciano.coe...@intel.com> >>> >>> Add an initial impl

pull request: iwlwifi-next 2016-01-31

Hi Kalle, This is a pull request for 4.6. Please pull. Thanks! The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2016-01-12 18:57:02 -0800) are available in the git repository at:

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

> > 2016-01-27 2:46 GMT-05:00 Grumbach, Emmanuel > <emmanuel.grumb...@intel.com>: > >> Hi > >> > >> 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel > >> <emmanuel.grumb...@intel.com>: > >> > > >> > > >>

pull request: iwlwifi 2016-01-26

Hi Kalle, This is the first round of fixes for 4.5. Most of them are really trivial. The TPC stats one stands out a little bit. It can fix traffic issues which are typically hard to debug. Please pull and let me know if you have issues. I also have a batch of patches for -next, but

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

> Hi > > 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel > <emmanuel.grumb...@intel.com>: > > > > > > On 01/26/2016 12:20 AM, Nikolay Martynov wrote: > >> It looks like sometimes firmware returns zero for chain noise and > >> signal durin

Re: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

On 01/26/2016 12:20 AM, Nikolay Martynov wrote: > It looks like sometimes firmware returns zero for chain noise and signal > during calibration period. This seems to be a known problem and current > implementation accounts for this by ignoring invalid data when all chains > return zero signal

Re: pull request: iwlwifi 2016-01-26

Hi Kalle, On 01/26/2016 03:51 PM, Kalle Valo wrote: > "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes: > >> This is the first round of fixes for 4.5. Most of them are really >> trivial. The TPC stats one stands out a little bit. It can fix traffic

Re: pull request: iwlwifi 2016-01-26

On 01/26/2016 04:01 PM, Johannes Berg wrote: >>> There's a conflict due to 8f57e4d930d, how should I fix it? > I think we can thus drop my patch - that commit fixes the issue that > Andrew had reported as well, and that I worked around by casting the > result... now that abs() has a consistent

Re: [PATCH] iwlwifi: Document missing module options

Hi, On 01/07/2016 12:24 AM, Rodrigo Freire wrote: > This patch documents two missing module options in the internal > code comment block. > > Signed-off-by: Rodrigo Freire > --- > drivers/net/wireless/iwlwifi/iwl-modparams.h |2 ++ > 1 files changed, 2 insertions(+), 0

pull request: iwlwifi-next 2016-01-07

Hi Kalle, Here is the last round of patches for 4.5. Most of them are small and / or fixes. Let me know if you have issues. FYI - I scripted a few checks so that I hope that the internal tags that leaked in the previous pull request won't leak any more. The following changes since commit

Re: pull request: iwlwifi-next 2016-01-07

Me again, On 01/07/2016 02:46 PM, Grumbach, Emmanuel wrote: > Hi Kalle, > > Here is the last round of patches for 4.5. Most of them are small and / or > fixes. > Let me know if you have issues. > FYI - I scripted a few checks so that I hope that the internal tags that > lea

Re: [PATCH RESEND] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd

Hi, On 12/30/2015 07:15 PM, Nicholas Krause wrote: > This fixes error handling in the function iwl_pcie_enqueue_hcmd > by checking if all calls to the function wl_pcie_txq_build_tfd > have failed by returning a error code and if so jump to the goto > label out from the cleaning up of acquired

Re: [PATCH 44/45] iwlwifi: fix printf specifier

On 12/23/2015 06:08 AM, Joe Perches wrote: > On Mon, 2015-12-21 at 22:50 +0200, Emmanuel Grumbach wrote: >> Smatch warned about a bad specifier being used. Fix that. > I see nothing here other than a signed/unsigned > issue that shouldn't need fixing. The conversion > from hex to decimal may

Re: pull request: iwlwifi-next-2015-12-21

On 12/21/2015 10:49 PM, Grumbach, Emmanuel wrote: > Hi Kalle, > > here is a pull request for 4.5. I guess there will be one more after that > depending on when Linus will open the merge window I guess. > The diffstat look awful and I have no clue why. It looks as if I had done th

pull request: iwlwifi-next-2015-12-21

Hi Kalle, here is a pull request for 4.5. I guess there will be one more after that depending on when Linus will open the merge window I guess. The diffstat look awful and I have no clue why. It looks as if I had done the whole code reorganisation... So we have a pretty large pull request here.

RE: [PATCH] mac80211: fix PS-Poll handling

> > My commit below broken PS-Poll handling. In case the driver > has no frames buffered, driver_release_tids will be 0, but > calling find_highest_prio_tid() with 0 as a parameter is > not a good idea: > fls(0) - 1 = -1. > This bug caused mac80211 to think that frames were buffered > in the

RE: pull request: iwlwifi 2015-12-16

> > "Grumbach, Emmanuel" <emmanuel.grumb...@intel.com> writes: > > > This is a pull request with small fixes for 4.4. Note that due to the > > large number of files being renamed, you need to set merge.renameLimit > > to a big number to merge wl-drv in

pull request: iwlwifi 2015-12-16

Hi Kalle, This is a pull request with small fixes for 4.4. Note that due to the large number of files being renamed, you need to set merge.renameLimit to a big number to merge wl-drv into wl-drv-next but you probably noticed that already :) The following changes since commit

Re: iwlwifi - L1 Enabled - LTR Enabled loop

On 12/14/2015 01:04 AM, Arend van Spriel wrote: > On 12/12/2015 12:32 AM, Johannes Berg wrote: >> On Fri, 2015-12-11 at 15:17 -0800, Luis R. Rodriguez wrote: >>> I just tried a base config from opensuse, then localmodconfig, then >>> 'make xenconfig' (which I need) and that worked. I can't debug

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

On 12/08/2015 06:03 PM, Krishna Chaitanya wrote: > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach > wrote: >> index 7a76ce6..f4a5287 100644 >> --- a/net/mac80211/ht.c >> +++ b/net/mac80211/ht.c >> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

On 12/08/2015 06:35 PM, Krishna Chaitanya wrote: > > > On Dec 8, 2015 10:01 PM, "Grumbach, Emmanuel" > <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>> wrote: > > > > > > > > On 12/08/2015 06:03 PM, Krishna Chait

Re: [PATCH 2/2] mac80211: support hw managing reorder logic

On 12/08/2015 07:09 PM, Grumbach, Emmanuel wrote: > From: Sara Sharon <sara.sha...@intel.com> > > Enable driver to manage the reordering logic itself. > This is needed for example for the iwlwifi driver that > supports hardware based reordering. > > type=feature Ouc

Re: [PATCH 2/9] mac80211: limit the A-MSDU Tx based on peer's capabilities

On 12/08/2015 09:11 PM, Krishna Chaitanya wrote: > > > On Dec 9, 2015 12:37 AM, "Grumbach, Emmanuel" > <emmanuel.grumb...@intel.com <mailto:emmanuel.grumb...@intel.com>> wrote: > > > > > > > > On 12/08/2015 07:49 PM, Krishna Chaitanya w

Re: [PATCH 24/41] iwlwifi: mvm: move fw-dbg code to separate file

On 12/01/2015 08:53 PM, Kalle Valo wrote: > Emmanuel Grumbach writes: > >> From: Golan Ben-Ami >> >> The fw debug functionality is big enough to warrant >> a separate file. Move existing related functions to the new file. >> >>

  1   2   3   >