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
> include/net/cf
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 cl
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:
PCI/
>
> 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 fu
>
> 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
>
> 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
> > >
> > > &
> > > >
> > > > 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: 2.
>
> [+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
> >
> > htt
>
>
> .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!
>
> 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:
> >
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 go
>
> 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
>
> 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
>
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 th
> 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
>
> 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.
>
&g
>
> 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.
> >
> > Pl
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.
> >
> > This
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
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] [ cut
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 |
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 wh
> 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 f
>
> 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 relate
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
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(-)
>
> diff
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 res
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 opi
>
> 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.
>
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
>>>>
>>>>
>>>
>
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 protecti
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 i
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
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
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 resourc
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
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 a
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
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 fr
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 8e181320b11de501046cf75c8c309
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
> > >
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
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,
>
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
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
>
>
> 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 th
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, resultin
>
> 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 th
> 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
>
> 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 wo
> 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
> 'iwco
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
>
> 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
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: (http://coccinelle.lip6.
On Thu, 2014-12-18 at 13:07 -0800, Fengguang Wu wrote:
> On Fri, Dec 19, 2014 at 03:42:17AM +0800, Grumbach, Emmanuel wrote:
> > On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> > > Hi All,
> > >
> > > I don't see any relationship between the B
On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> Hi All,
>
> I don't see any relationship between the BUG and this bisected commit.
> Anyway, it's better to report it to the lists than to ignore.
Right - but I have to say that I have no clue how this comment can cause
the bug you are seei
>
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Signed-off-by: Joe Perches
> ---
Applied - thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
> Hi,
>
> on recent Linus git, I regulary get the following backtrace (since 3.17 around
> or so).
> HW is Intel Corporation Wireless 7260 (rev 83)
>
> [ 1774.340980] [ cut here ]
> [ 1774.341003] WARNING: CPU: 2 PID: 2402 at
> /home/arnd/Projekte/kernel/linux-
> 2.6/drive
[Changed subject]
This is really iwlegacy and not iwlwifi.
>
> Hi!
>
> Full dmesg is in the attachment, I guess the troubles started with:
>
> iwl3945 :03:00.0: Queue 4 stuck for 2004 ms.
> iwl3945 :03:00.0: On demand firmware reload
> iwl3945 :03:00.0: Master Disable Timed Out, 10
>
> 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-kernel@vger.kernel.or
> -Original Message-
> From: Luis Henriques [mailto:luis.henriq...@canonical.com]
> Sent: Monday, August 18, 2014 12:31 PM
> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; kernel-
> t...@lists.ubuntu.com
> Cc: Grumbach, Emmanuel; Luis Henriques
> Subject
>
> On 07/06/2014 10:11 AM, Larry Finger wrote:
> > A problem with configuration of IWLWIFI has been bisected to commit
> 48e2934, where a new section was added to
> drivers/net/wireless/iwlwifi/Kconfig with the following code:
> >
> > # don't call it _MODULE -- will confuse Kconfig/fixdep/...
> >
>
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x,
> NULL)
>
> The rcu_assign_pointer() ensures that the initialization of a structure
> is carried out before storing a pointer to that structure.
> And in the case of the NULL pointer, there is no structure to initialize.
> 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
> > >
> > > >
> > > > Does Linus's tree also have this problem for you? Or does it work
> > > > there? If it wo
>
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc allyesconfig)
> failed like this:
>
> drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function
> 'iwl_dbgfs_fw_error_dump_release':
> drivers/net/wireless/iwlwifi/mvm/debugfs.c:161:2: error: implicit declaration
> of
>
> Hi,
> I am not sure who to report this issue so please let me know if this is
> not a proper channel.
>
> My dmesg claims the following:
> [14921.841475] iwlwifi :02:00.0: RF_KILL bit toggled to enable radio.
> [14922.178602] usb 1-1.4: new full-speed USB device number 5 using ehci-pci
>
>
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> > We have literally had this *exact* same issue with firmware loading.
> > Network drivers shouldn't try to load firmware at module load time.
> > Same deal.
>
> It is kind of a chicken and egg problem for (wireless) networking drivers. To
> get
> Subject: [PATCH] iwlwifi: remove duplicate includes
>
> Reported by "make includecheck"
>
> Tested that the corresponding sources still compile well on x86
>
> Signed-off-by: Michael Opdenacker electrons.com>
> ---
Picked up. Thanks.
--
To unsubscribe from this list: send the line "unsubscri
> Subject: [PATCH 08/11] iwlwifi: Remove extern from function prototypes
>
> There are a mix of function prototypes with and without extern in the kernel
> sources. Standardize on not using extern for function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is
>
> lockdep complains about this:
>
> [ 92.094870]CPU0
> [ 92.094871]
> [ 92.094872] lock(&trans_pcie->irq_lock);
> [ 92.094873]
> [ 92.094875] lock(&trans_pcie->irq_lock);
> [ 92.094875]
> *** DEADLOCK ***
Sorry by I am not aware of all the details of
> > > > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins
> wrote:
> > > > > After sending the first 2MB, scp over wireless becomes
> > > > > unbearably slow, with frequent stalls: on this ThinkPad T420s running
> 3.8-rc4 or 3.7.3.
> > > > > Not always, but often.
> > > > >
> > > >
> > > > There is on
>
> Hello all,
>
> Oh the irony, I was just starting an email saying wifi is almost unusable for
> me
> with 3.8 and my machine (a thinkpad t530) completely froze while typing it...
>
> I was going to say I'm getting a lot of:
> iwlwifi :03:00.0: fail to flush all tx fifo queues
>
P
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/iwlwifi/dvm/tx.c between commit f590dcec9445
> ("iwlwifi: fix the reclaimed packet tracking upon flush queue") from Linus'
> tree
> and commit 1c3fea82d6eb ("iwlwifi: improve the reports in TX
> path") fr
>
> On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins wrote:
> > After sending the first 2MB, scp over wireless becomes unbearably
> > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> > Not always, but often.
> >
>
> There is one pending iwlwifi-fixes, dunno if it will
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/wireless/iwlwifi/pcie/trans.c between commit b9d146e30a2d
> ("iwlwifi: collapse wrapper for pcie_capability_read_word()") from the pci
> tree and commit 7afe3705cd4e ("iwlwifi: continue clean up -
> pcie/trans.c") from
75 matches
Mail list logo
