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: [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 RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

> > Prarit Bhargava writes: > > > On 07/13/2016 03:24 AM, Luca Coelho wrote: > > > >> I totally agree with Emmanuel and Kalle. We should not change this. > >> It is a design decision to return an error when the interface is > >> down, this is very common with other subsystems

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 ... > > > >

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: [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 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: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()

> > Use alloc_workqueue() to allocate the workqueue instead of > create_singlethread_workqueue() since the latter is deprecated and is > scheduled > for removal. I can't see any indication of that in the code of workqueue. Can you share details about that? > > There are work items doing

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: [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] 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 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] iwlwifi: fix compare_const_fl.cocci warnings

Hi Julia, On 11/27/2015 06:11 PM, Julia Lawall wrote: > Move constants to the right of binary operators. > > Generated by: scripts/coccinelle/misc/compare_const_fl.cocci > > Signed-off-by: Fengguang Wu > Signed-off-by: Julia Lawall > --- > > This

RE: [PATCH 4/7] iwlwifi: fix a problematic usage of WARN_ON_ONCE()

> > WARN_ON_ONCE() takes a condition rather than a format string. This patch > converted WARN_ON_ONCE() to WARN_ONCE() instead. > > Signed-off-by: Geliang Tang > --- > drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v2] net: tso: add support for IPv6

On 10/26/2015 10:14 AM, Toshiaki Makita wrote: > On 2015/10/26 16:47, Grumbach, Emmanuel wrote: >> On 10/26/2015 06:03 AM, Toshiaki Makita wrote: >>> On 2015/10/26 5:02, Emmanuel Grumbach wrote: >>>> Adding IPv6 for the TSO helper API is trivial: >>>&g

Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6

Hi, On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: > Hi, > > linux-next 20151022 > > Can be reproduced reliably? Seems like a bad race between the end of session protection for the authentication and the start of the session protection for the deauth. I think I found the hole in the locks

Re: [PATCH v2] net: tso: add support for IPv6

On 10/26/2015 06:03 AM, Toshiaki Makita wrote: > On 2015/10/26 5:02, Emmanuel Grumbach wrote: >> Adding IPv6 for the TSO helper API is trivial: >> * Don't play with the id (which doesn't exist in IPv6) >> * Correctly update the payload_len (don't include the >> length of the IP header itself)

Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6

On 10/26/2015 10:30 AM, Sergey Senozhatsky wrote: > On (10/26/15 07:51), Grumbach, Emmanuel wrote: >>> On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: >>>> Hi, >>>> >>>> linux-next 20151022 >>>> >>>> >>> >

Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6

On 10/26/2015 09:23 AM, Grumbach, Emmanuel wrote: > Hi, > > On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: >> Hi, >> >> linux-next 20151022 >> >> > > Can be reproduced reliably? > Seems like a bad race between the end of session p

Re: [RFC v3 1/2] iwlwifi: pcie: allow to build an A-MSDU using TSO core

On 10/22/2015 05:27 AM, Eric Dumazet wrote: > On Thu, 2015-10-22 at 00:14 +0000, Grumbach, Emmanuel wrote: > >> >> Well. I guess I should at least check, but even with very small MSS, our >> device supports up to 20 pointers for the same 802.11 packet: 2 are for >&

RE: [RFC v3 2/2] iwlwifi: mvm: send large SKBs to the transport

> > On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote: > > + > > + if (skb->protocol == htons(ETH_P_IP)) { > > + ip_hdr(tmp)->id = ip_hdr(skb)->id; > > Too late, you already called consume_skb(skb). > So this is a potential use after free. Ouch - thanks for

Re: [RFC v4 1/2] iwlwifi: pcie: allow to build an A-MSDU using TSO core

On 10/22/2015 04:08 PM, Grumbach, Emmanuel wrote: > When the op_mode sends an skb whose payload is bigger than > MSS, PCIe will create an A-MSDU out of it. PCIe assumes > that the skb that is coming from the op_mode can fit in one > A-MSDU. It is the op_mode's responsibility

Re: [RFC v3 1/2] iwlwifi: pcie: allow to build an A-MSDU using TSO core

Hi Eric, On 10/22/2015 02:30 AM, Eric Dumazet wrote: > On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote: >> When the op_mode sends an skb whose payload is bigger than >> MSS, PCIe will create an A-MSDU out of it. PCIe assumes >> that the skb that is coming from the op_mode can fit in

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/20/2015 10:21 AM, Grumbach, Emmanuel wrote: On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers keep around the original LSO packet and frees

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers keep around the original LSO packet and frees it normally at TX completion time. Which is why I can't

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers keep around the original LSO packet and frees it normally at TX completion time. I can't see anything

Re: [RFC v3 1/3] iwlwifi: mvm: add real TSO implementation

On 08/20/2015 04:13 PM, Eric Dumazet wrote: On Thu, 2015-08-20 at 11:15 +0300, Emmanuel Grumbach wrote: The segmentation is done completely in software. The driver creates several MPDUs out of a single large send. Each MPDU is a newly allocated SKB. A page is allocated to create the headers

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/20/2015 04:11 PM, Eric Dumazet wrote: On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote: On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core/tso.c avoid this? Because a driver using these helpers

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/20/2015 04:53 PM, Grumbach, Emmanuel wrote: On 08/20/2015 04:11 PM, Eric Dumazet wrote: On Thu, 2015-08-20 at 06:21 +, Grumbach, Emmanuel wrote: On 08/19/2015 11:39 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 19:17 +, Grumbach, Emmanuel wrote: Hm.. how would net/core

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

Hi Eric, First, thank you a lot for your comments. On 08/19/2015 05:14 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: We could have enabled A-MSDU based on xmit-more, but the rationale of using LSO is that when using pfifo-fast, the Qdisc gets one

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On 08/19/2015 07:08 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:07 +, Grumbach, Emmanuel wrote: I'll look at it. I was almost starting to implement that but then I thought with another (good?) reason to use LSO. LSO gives me the guarantee that the packet is directed to one peer

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On 08/19/2015 09:02 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 17:56 +, Grumbach, Emmanuel wrote: So I feel that making net/core/tso.c more complicated just because of our craziness seems an overkill to me. I'll try a bit harder to see how I can use net/core/tso.c, but I have

Re: [RFC v2 1/3] iwlwifi: mvm: add real TSO implementation

On 08/19/2015 05:18 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: The segmentation is done completely in software. The driver creates several MPDUs out of a single large send. Each MPDU is a newly allocated SKB. A page is allocated to create the headers

Re: [RFC v2 0/3] add TSO / A-MSDU TX for iwlwifi

On 08/19/2015 08:20 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 17:00 +, Grumbach, Emmanuel wrote: On 08/19/2015 07:08 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:07 +, Grumbach, Emmanuel wrote: I'll look at it. I was almost starting to implement that but then I thought

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

On 08/19/2015 05:24 PM, Eric Dumazet wrote: On Wed, 2015-08-19 at 15:59 +0300, Emmanuel Grumbach wrote: This allows to release the backpressure on the socket only when the last segment is released. Now the truesize looks like this: if the truesize of the original skb is 65420, all the

Re: [RFC v2 3/3] iwlwifi: mvm: transfer the truesize to the last TSO segment

Hi, On 08/19/2015 10:10 PM, Sergei Shtylyov wrote: Hello. On 08/19/2015 03:59 PM, Emmanuel Grumbach wrote: This allows to release the backpressure on the socket only when the last segment is released. Now the truesize looks like this: if the truesize of the original skb is 65420, all

Re: [PATCH] iwlwifi: out-of-bounds access in iwl_init_sband_channels

Hi, On 08/14/2015 03:36 AM, Adrien Schildknecht wrote: Both loops of this function compare data from the 'chan' array and then check if the index is valid. The 2 conditions should be inverted to avoid an out-of-bounds access. Was that found by a static analyzer or any other automated

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

On 07/22/2015 08:30 PM, nick wrote: On 2015-07-22 01:28 PM, Grumbach, Emmanuel wrote: On 07/22/2015 07:39 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

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

On 07/22/2015 07:39 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 resources

Re: [linuxwifi] [PATCH] iwlwifi:Make various functions void in the file rs.c

Hi, On 07/08/2015 06:03 PM, Nicholas Krause wrote: This makes various functions in the file rs.c void due to these functions never returning a error code to signal to their callers if and how they have failed to complete their intended work. Signed-off-by: Nicholas Krause

Re: [PATCH] iwlwifi:dvm:Return false if resume command data is not same size as received packet for the function iwl_resume_status_fn

On Wed, 2015-06-10 at 12:33 -0400, Nicholas Krause wrote: This makes the function iwl_resume_status_fn return false now if the received packet of type iwl_rx_packet is not the same size as the structure pointer, iwl_resume_data's cmd element in order to signal callers about this error and

Re: [PATCH] iwlwifi:dvm:Return false if resume command data is not same size as received packet for the function iwl_resume_status_fn

On Wed, 2015-06-10 at 12:58 -0400, Nicholas Krause wrote: On June 10, 2015 12:50:45 PM EDT, Grumbach, Emmanuel emmanuel.grumb...@intel.com wrote: On Wed, 2015-06-10 at 12:33 -0400, Nicholas Krause wrote: This makes the function iwl_resume_status_fn return false now if the received packet

Re: [linuxwifi] [PATCH] iwlwifi: Remove use of the deprecacted marco, PTR_RET for the function, iwl_mvm_get_regdomain

On Sat, 2015-05-23 at 20:53 -0400, Nicholas Krause wrote: This removes the use of the two deprecated calls to the marco, PTR_RET in the function, iwl_mvm_get_regdomain and replaces them both with a call to the function, PTR_ERR_OR_ZERO. Signed-off-by: Nicholas Krause xerofo...@gmail.com