RE: linux-next: build warning after merge of the mac80211-next tree

Hi, > > Hi all, > > After merging the mac80211-next tree, today's linux-next build (htmldocs) > produced this warning: > > include/net/cfg80211.h:6643: warning: expecting prototype for > wiphy_rfkill_set_hw_state(). Prototype was for > wiphy_rfkill_set_hw_state_reason() instead >

RE: [char-misc-next 6/6] mei: bus: add client dma interface

Hi Greg, > On Sun, Feb 07, 2021 at 02:03:11PM +, Winkler, Tomas wrote: > > > > > > On Sat, Feb 06, 2021 at 03:04:34PM +, Winkler, Tomas wrote: > > > > > On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote: > > > > > > From: Alexander Usyskin > > > > > > > > > > > > Expose the

PCI LTR - ASPM handling upon suspend / resume cycle. Regression since 4.18

Hi, Lately we (Intel) have got a few bugs on suspend / resume. The complaint is that our device becomes unavailable after suspend / resume cycle. The bug on which we have most data is [1]. The original submitter reported a regression since commit 9ab105deb60fa76d66cae5548819b4e8703d2056:

RE: linux-next: build warnings after merge of the wireless-drivers-next tree

> > Stephen Rothwell writes: > > > On Fri, 30 Nov 2018 12:05:55 +1100 Stephen Rothwell > wrote: > >> > >> After merging the wireless-drivers-next tree, today's linux-next > >> build > >> (x86_64 allmodconfig) produced these warnings: > >> > >> drivers/net/wireless/intel/iwlwifi/iwl-drv.c: In

RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works

> > On Tue, Dec 11, 2018 at 06:31:47PM +, Grumbach, Emmanuel wrote: > > > On Tue, Dec 11, 2018 at 04:32:25PM +0000, Grumbach, Emmanuel wrote: > > > > > On Tue, Dec 11, 2018 at 06:35:20AM +, Grumbach, Emmanuel > wrote: > > > > > > > &g

RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works

> > On Tue, Dec 11, 2018 at 04:32:25PM +, Grumbach, Emmanuel wrote: > > > On Tue, Dec 11, 2018 at 06:35:20AM +0000, Grumbach, Emmanuel wrote: > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > &

RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works

> > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=201647 > > > > > > > > Bug ID: 201647 > > > >Summary: Intel Wireless card 3165 does not get detected but > > > > bluetooth works > > > >Product: Drivers > > > >Version:

RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works

> > [+cc Emmanuel, LKML] > > On Fri, Nov 09, 2018 at 03:43:06PM -0600, Bjorn Helgaas wrote: > > -- Forwarded message - > > From: > > Date: Fri, Nov 9, 2018 at 4:10 AM > > Subject: [Bug 201647] New: Intel Wireless card 3165 does not get > > detected but bluetooth works > > > >

RE: Fwd: [Bug 201647] New: Intel Wireless card 3165 does not get detected but bluetooth works

> > [+cc Emmanuel, LKML] > > On Fri, Nov 09, 2018 at 03:43:06PM -0600, Bjorn Helgaas wrote: > > -- Forwarded message - > > From: > > Date: Fri, Nov 9, 2018 at 4:10 AM > > Subject: [Bug 201647] New: Intel Wireless card 3165 does not get > > detected but bluetooth works > > > >

RE: [linuxwifi] [PATCH] fix iwlwifi on old cards in v4.19 was Re: 4.19-rc[23] iwlwifi: BUG in swiotlb

> > > .max_tfd_queue_size was ommited for old cards, leading to oops in swiotlb. > > Signed-off-by: Pavel Machek > I picked it up in our tree with minor commit message fixes. I also added the Fixes tag for stable. Thanks!

RE: [linuxwifi] [PATCH] fix iwlwifi on old cards in v4.19 was Re: 4.19-rc[23] iwlwifi: BUG in swiotlb

> > > .max_tfd_queue_size was ommited for old cards, leading to oops in swiotlb. > > Signed-off-by: Pavel Machek > I picked it up in our tree with minor commit message fixes. I also added the Fixes tag for stable. Thanks!

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

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

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

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

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

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: [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 ... > > > > > > P. > > > >

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 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: 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] 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 - thanks. > drivers/net/wireless/intel/iwlwifi/pcie/rx.c |

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 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()

> 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: [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: [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()

> > 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: 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 changed, 1 insertion(+), 1

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: [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 deletions(-) > >

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

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 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 looks a bit nicer around the other way, in my

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(-) Already fixed. Thanks. >

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

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

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: [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" > wrote: > >On Wed, 2015-06-10 at 12:33 -0400, Nicholas Krause wrote: > >> This makes the function iwl_resume_status_fn return false now i

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: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: [BUG 4.1.0-rc6] iwlwifi: "Error sending REPLY_TXFIFO_FLUSH: time out after 2000ms"

On Thu, 2015-06-04 at 22:32 +0300, Kirill A. Shutemov wrote: > On Thu, Jun 04, 2015 at 06:13:22PM +0000, Grumbach, Emmanuel wrote: > > On Thu, 2015-06-04 at 20:37 +0300, Kirill A. Shutemov wrote: > > > Hi, > > > > > > I've trigered the bug few times

Re: [BUG 4.1.0-rc6] iwlwifi: Error sending REPLY_TXFIFO_FLUSH: time out after 2000ms

On Thu, 2015-06-04 at 22:32 +0300, Kirill A. Shutemov wrote: On Thu, Jun 04, 2015 at 06:13:22PM +, Grumbach, Emmanuel wrote: On Thu, 2015-06-04 at 20:37 +0300, Kirill A. Shutemov wrote: Hi, I've trigered the bug few times after several suspend/resume cycles. Hardware

Re: pull request: iwlmvm firmware -13.ucode

Signed this time. On Thu, 2015-05-28 at 20:53 +0300, Emmanuel Grumbach wrote: > Hello, > > This is a pull request to include -13.ucode into mainline. > This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all > the devices driven by iwlmvm. > This firmware is supported starting

pull request: iwlmvm firmware -13.ucode

Hello, This is a pull request to include -13.ucode into mainline. This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all the devices driven by iwlmvm. This firmware is supported starting from kernel 4.1 Thanks you. The following changes since commit

pull request: iwlmvm firmware -13.ucode

Hello, This is a pull request to include -13.ucode into mainline. This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all the devices driven by iwlmvm. This firmware is supported starting from kernel 4.1 Thanks you. The following changes since commit

Re: pull request: iwlmvm firmware -13.ucode

Signed this time. On Thu, 2015-05-28 at 20:53 +0300, Emmanuel Grumbach wrote: Hello, This is a pull request to include -13.ucode into mainline. This firmware can run on 7260, 3160, 7265, 7265D and 3165 which are all the devices driven by iwlmvm. This firmware is supported starting from

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Mon, 2015-05-04 at 08:55 +0200, Jiri Kosina wrote: > On Mon, 4 May 2015, Grumbach, Emmanuel wrote: > > > > so over a past few days, I tried to perform a bisect, but failed as > > > expected. The issue is not reliably enough reproducible for me, so I > > >

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Mon, 2015-05-04 at 08:55 +0200, Jiri Kosina wrote: On Mon, 4 May 2015, Grumbach, Emmanuel wrote: so over a past few days, I tried to perform a bisect, but failed as expected. The issue is not reliably enough reproducible for me, so I ended up with a completely bogus commit

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Sun, 2015-05-03 at 23:42 +0200, Jiri Kosina wrote: > Hi, > > so over a past few days, I tried to perform a bisect, but failed as > expected. The issue is not reliably enough reproducible for me, so I ended > up with a completely bogus commit. > > *However*, now that I have been following

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Sun, 2015-05-03 at 23:42 +0200, Jiri Kosina wrote: Hi, so over a past few days, I tried to perform a bisect, but failed as expected. The issue is not reliably enough reproducible for me, so I ended up with a completely bogus commit. *However*, now that I have been following the

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Thu, 2015-04-23 at 14:48 +0200, Piotr Karbowski wrote: > Hello, > > On Thu, Apr 23, 2015 at 11:15 AM, Jiri Kosina wrote: > > On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: > > > >> > I will try it, but I expect the result to be bogus because of this, >

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Thu, 2015-04-23 at 10:15 +0200, Jiri Kosina wrote: > On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: > > > > I've been running current Linus' tree and have been getting system > > > lockups > > > frequently. After a few "silent" lockups, I was able

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Thu, 2015-04-23 at 14:48 +0200, Piotr Karbowski wrote: Hello, On Thu, Apr 23, 2015 at 11:15 AM, Jiri Kosina jkos...@suse.cz wrote: On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: I will try it, but I expect the result to be bogus because of this, unfortunately. I can understand

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

On Thu, 2015-04-23 at 10:15 +0200, Jiri Kosina wrote: On Thu, 23 Apr 2015, Grumbach, Emmanuel wrote: I've been running current Linus' tree and have been getting system lockups frequently. After a few silent lockups, I was able to obtain a dmesg before the machine turned dead

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

Hi, On Wed, 2015-04-22 at 22:42 +0200, Jiri Kosina wrote: > Hi, > > I've been running current Linus' tree and have been getting system lockups > frequently. After a few "silent" lockups, I was able to obtain a dmesg > before the machine turned dead again (wifi stopped working shortly before

Re: iwlwifi getting stuck with current Linus' tree (646da63172)

Hi, On Wed, 2015-04-22 at 22:42 +0200, Jiri Kosina wrote: Hi, I've been running current Linus' tree and have been getting system lockups frequently. After a few silent lockups, I was able to obtain a dmesg before the machine turned dead again (wifi stopped working shortly before that).

RE: linux-next: manual merge of the ftrace tree with the net-next tree

> > Hi Steven, > > Today's linux-next merge of the ftrace tree got a conflict in > drivers/net/wireless/iwlwifi/iwl-devtrace.h between commit 7e1223b50089 > ("iwlwifi: mvm: new Alive / error table API") from the net-next tree and > commit c5ef935d01a2 ("iwlwifi: Move each system tracepoints to

RE: linux-next: manual merge of the ftrace tree with the net-next tree

Hi Steven, Today's linux-next merge of the ftrace tree got a conflict in drivers/net/wireless/iwlwifi/iwl-devtrace.h between commit 7e1223b50089 (iwlwifi: mvm: new Alive / error table API) from the net-next tree and commit c5ef935d01a2 (iwlwifi: Move each system tracepoints to their own

Re: [PATCH] iwlwifi: mvm: fix usage of debug specific variables

Hi, On Wed, 2015-03-04 at 18:59 +0100, Alban Gruin wrote: > Some variables in structs "iwl_mvm" and "iwl_mvm_vif" are used for debug > purpose, and are declared only if CONFIG_IWLWIFI_DEBUGFS is > set. However, some of these variables are used even if > CONFIG_IWLWIFI_DEBUGFS is not set,

Re: [PATCH] iwlwifi: mvm: fix usage of debug specific variables

Hi, On Wed, 2015-03-04 at 18:59 +0100, Alban Gruin wrote: Some variables in structs iwl_mvm and iwl_mvm_vif are used for debug purpose, and are declared only if CONFIG_IWLWIFI_DEBUGFS is set. However, some of these variables are used even if CONFIG_IWLWIFI_DEBUGFS is not set, resulting in a

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

> > On Wed, 31 Dec 2014, Arend van Spriel wrote: > > > You mentioned in the discussion and I quote: "*If* wireless > > maintainers think otherwise, I'll send a revert request to Linus for > > consideration.". However, you did not wait for any response from the > > wireless maintainers nor from

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

> On 12/30/14 23:52, Jiri Kosina wrote: > > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. > > > > It's causing severe userspace breakage. Namely, all the utilities from > > wireless-utils which are relying on CONFIG_WEXT (which means tools > > like 'iwconfig', 'iwlist', etc) are

RE: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

On 12/30/14 23:52, Jiri Kosina wrote: This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. It's causing severe userspace breakage. Namely, all the utilities from wireless-utils which are relying on CONFIG_WEXT (which means tools like 'iwconfig', 'iwlist', etc) are not working

RE: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

On Wed, 31 Dec 2014, Arend van Spriel wrote: You mentioned in the discussion and I quote: *If* wireless maintainers think otherwise, I'll send a revert request to Linus for consideration.. However, you did not wait for any response from the wireless maintainers nor from the author of

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

> > On Tue, 30 Dec 2014, Larry Finger wrote: > > > > > If wireless maintainers think otherwise, I'll send a revert > > > > request to Linus for consideration. > > > > > > I wonder if the reaction would be like this one: > > > > > > https://lkml.org/lkml/2012/12/23/75 > > > > > > :-) > > > > It

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

> Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable" > > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. > > It's causing severe userspace breakage. Namely, all the utilities from > wireless-utils which are relying on CONFIG_WEXT (which means tools like >

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 2014-12-30 at 16:21 +0100, Jiri Kosina wrote: > On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote: > > > > > So why do you used them? > > > > They have been deprecated for a couple of years now. You should be > > > > using nl80211 based tools

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

> > On 12/30/2014 09:23 AM, Emmanuel Grumbach wrote: > > On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina wrote: > >> > >> Hi, > >> > >> I just booted current Linus' tree (5faa0154fe33) on my x200s > >> thinkpad, and wifi doesn't work. iwconfig is telling me that wlan0 > >> interface has no wireless

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

On 12/30/2014 09:23 AM, Emmanuel Grumbach wrote: On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina jkos...@suse.cz wrote: Hi, I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and wifi doesn't work. iwconfig is telling me that wlan0 interface has no wireless

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 2014-12-30 at 16:21 +0100, Jiri Kosina wrote: On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote: So why do you used them? They have been deprecated for a couple of years now. You should be using nl80211 based tools such as iw. A couple of years is not very long where

RE: [PATCH] Revert cfg80211: make WEXT compatibility unselectable

Subject: [PATCH] Revert cfg80211: make WEXT compatibility unselectable This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. It's causing severe userspace breakage. Namely, all the utilities from wireless-utils which are relying on CONFIG_WEXT (which means tools like 'iwconfig',

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 30 Dec 2014, Larry Finger wrote: If wireless maintainers think otherwise, I'll send a revert request to Linus for consideration. I wonder if the reaction would be like this one: https://lkml.org/lkml/2012/12/23/75 :-) It would be a little like that.

Re: [PATCH 12/27] iwlwifi: dvm: main: Use setup_timer

On Fri, 2014-12-26 at 15:35 +0100, Julia Lawall wrote: > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows:

  1   2   >