Re: [PATCH v2 -next] intel: iwlwifi: use DEFINE_MUTEX() for mutex lock

On Thu, 2020-12-24 at 21:25 +0800, Zheng Yongjun wrote: > mutex lock can be initialized automatically with DEFINE_MUTEX() > rather than explicitly calling mutex_init(). > > Signed-off-by: Zheng Yongjun > --- Thanks! I have now applied this internally and it will reach the mainline following our

Re: [linuxwifi] [PATCH] net: iwlwifi: remove trailing semicolon in macro definition

On Fri, 2020-11-27 at 10:07 -0800, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix > --- Thank you. I applied this now to our internal tree and this will reach the mainline following our usual process. -- Cheers, Luca.

Re: [PATCH net-next] iwlwifi: fix old-style-declaration warning

On Mon, 2021-03-22 at 22:51 +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The correct order is 'static const', not 'const static', as seen from > make W=1: > > drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:14:1: error: 'static' is not at > beginning of declaration

Re: [PATCH v2] iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle())

On Tue, 2021-03-02 at 11:34 +0100, Jiri Kosina wrote: > From: Jiri Kosina > > We can't call netif_napi_add() with rxq-lock held, as there is a potential > for deadlock as spotted by lockdep (see below). rxq->lock is not > protecting anything over the netif_napi_add() codepath anyway, so let's >

Re: [PATCH] iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle())

On Tue, 2021-03-02 at 10:27 +0100, Jiri Kosina wrote: > On Mon, 1 Mar 2021, Johannes Berg wrote: > > > > I am getting the splat below with Linus' tree as of today (5.11-rc1, > > > fe07bfda2fb). I haven't started to look into the code yet, but apparently > > > this has been already reported by

Re: [PATCH] iwlwifi: fix ARCH=i386 compilation warnings

On Tue, 2021-03-02 at 07:58 +0200, Kalle Valo wrote: > Pierre-Louis Bossart writes: > > > An unsigned long variable should rely on '%lu' format strings, not '%zd' > > > > Fixes: a1a6a4cf49ece ("iwlwifi: pnvm: implement reading PNVM from UEFI") > > Signed-off-by: Pierre-Louis Bossart > > --- >

Re: [BUG] iwlwifi: card unusable after firmware crash

Hi Jakub et al, On Wed, 2020-12-09 at 09:13 -0800, Jakub Kicinski wrote: > On Tue, 8 Dec 2020 23:17:48 + Rui Salvaterra wrote: > > Hi, Luca, > > > > On Tue, 8 Dec 2020 at 16:27, Coelho, Luciano > > wrote: > > > On Tue, 2020-12-08

Re: [BUG] iwlwifi: card unusable after firmware crash

On Tue, 2020-12-08 at 11:27 +, Rui Salvaterra wrote: > Hi, everyone, > > I'm running Linux 5.10-rc7 with this firmware/hardware: > > [1.431878] iwlwifi :02:00.0: loaded firmware version > 29.198743027.0 7265D-29.ucode op_mode iwlmvm > [1.431899] iwlwifi :02:00.0: Detected

Re: Wifi hangs

Adding Guy Damary Guy, can you help with this one? I believe there is a bugzilla issue for this already... -- Cheers, Luca. On Thu, 2020-11-19 at 17:42 +0100, Gonsolo wrote: > Hi! > > Sporadically my wifi hangs. Any idea why? > This is on a 5.10.0-051000rc2-lowlatency kernel from >

Re: linux-next: Signed-off-by missing for commit in the wireless-drivers tree

On Wed, 2020-11-11 at 10:23 +0200, Kalle Valo wrote: > Stephen Rothwell writes: > > > Commit > > > > 97cc16943f23 ("iwlwifi: mvm: write queue_sync_state only for sync") > > > > is missing a Signed-off-by from its author. > > Doh, missed that. But as it has s-o-b from Johannes and Luca, both

Re: [patch 28/35] net: iwlwifi: Remove in_interrupt() from tracing macro.

On Sun, 2020-09-27 at 21:49 +0200, Thomas Gleixner wrote: > From: Sebastian Andrzej Siewior > > The usage of in_interrupt) in driver code is phased out. > > The iwlwifi_dbg tracepoint records in_interrupt() seperately, but that's > superfluous because the trace header already records all kind

Re: [PATCH] wireless: iwlwifi: fix minor code style issues

On Sat, 2017-09-23 at 12:31 +0200, Christoph Böhmwalder wrote: > Fixes three trivial issues as reported by checkpatch.pl, namely two > switch/case indentation issues and one alignment issue in a multiline comment. > > Signed-off-by: Christoph Böhmwalder > --- Thanks,

Re: [PATCH] wireless: iwlwifi: fix minor code style issues

On Sat, 2017-09-23 at 12:31 +0200, Christoph Böhmwalder wrote: > Fixes three trivial issues as reported by checkpatch.pl, namely two > switch/case indentation issues and one alignment issue in a multiline comment. > > Signed-off-by: Christoph Böhmwalder > --- Thanks, applied to our internal

Re: [PATCH RESEND] wireless: iwlwifi: fix minor code style issues

On Mon, 2017-09-25 at 13:37 +0200, Christoph Böhmwalder wrote: > Fixes three trivial issues as reported by checkpatch.pl, namely two switch/case indentation issues and one alignment issue in a multiline comment. Signed-off-by: Christoph Böhmwalder --- Why are you

Re: [PATCH RESEND] wireless: iwlwifi: fix minor code style issues

On Mon, 2017-09-25 at 13:37 +0200, Christoph Böhmwalder wrote: > Fixes three trivial issues as reported by checkpatch.pl, namely two switch/case indentation issues and one alignment issue in a multiline comment. Signed-off-by: Christoph Böhmwalder --- Why are you already resending this? You

Re: [GIT] Networking

On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote: > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano > <luciano.coe...@intel.com> wrote: > > > > This seems to be a problem with backwards-compatibility with FW version > > 27. We are now in version 31[1] a

Re: [GIT] Networking

On Wed, 2017-09-06 at 21:57 -0700, Linus Torvalds wrote: > On Wed, Sep 6, 2017 at 9:11 PM, Coelho, Luciano > wrote: > > > > This seems to be a problem with backwards-compatibility with FW version > > 27. We are now in version 31[1] and upgrading will probably fix

Re: [GIT] Networking

On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote: > This pull request completely breaks Intel wireless for me. > > This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). > > That remains a very standard Intel machine with absolutely zero odd > things going on. > > The

Re: [GIT] Networking

On Wed, 2017-09-06 at 16:27 -0700, Linus Torvalds wrote: > This pull request completely breaks Intel wireless for me. > > This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a). > > That remains a very standard Intel machine with absolutely zero odd > things going on. > > The

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-17 at 15:38 +0200, Jiri Kosina wrote: > Hi, > > anything new on this front please? > > The splat (and therefore deadlock potential) is still there with current > Linus' tree. Sorry, haven't had more time to spend on it. I'll do it this evening. But, just to clarify, the

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-17 at 15:38 +0200, Jiri Kosina wrote: > Hi, > > anything new on this front please? > > The splat (and therefore deadlock potential) is still there with current > Linus' tree. Sorry, haven't had more time to spend on it. I'll do it this evening. But, just to clarify, the

Re: [PATCH v3] iwlwifi: Demote messages about fw flags size to info

On Thu, 2017-08-03 at 07:47 -0700, João Paulo Rechi Vita wrote: > These messages are not reporting a real error, just the fact that the > firmware knows about more flags than the driver. > > Currently these messages are presented to the user during boot if there > is no bootsplash covering the

Re: [PATCH v3] iwlwifi: Demote messages about fw flags size to info

On Thu, 2017-08-03 at 07:47 -0700, João Paulo Rechi Vita wrote: > These messages are not reporting a real error, just the fact that the > firmware knows about more flags than the driver. > > Currently these messages are presented to the user during boot if there > is no bootsplash covering the

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-03 at 13:02 +0300, Kalle Valo wrote: > "Coelho, Luciano" <luciano.coe...@intel.com> writes: > > > On Thu, 2017-08-03 at 11:10 +0200, Jiri Kosina wrote: > > > On Mon, 31 Jul 2017, Jiri Kosina wrote: > > > > > > > Hi, > &

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-03 at 13:02 +0300, Kalle Valo wrote: > "Coelho, Luciano" writes: > > > On Thu, 2017-08-03 at 11:10 +0200, Jiri Kosina wrote: > > > On Mon, 31 Jul 2017, Jiri Kosina wrote: > > > > > > > Hi, > > > > > >

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-03 at 11:10 +0200, Jiri Kosina wrote: > On Mon, 31 Jul 2017, Jiri Kosina wrote: > > > Hi, > > > > booting current Linus' tree, I'm seeing lockdep splat (see the end of this > > mail). > > > > Apparently, there is AB-BA between tz->lock and mvm->mutex through the CPU > >

Re: [linuxwifi] x86/thermal: AB-BA dependency between mvm->mutex and tz->lock

On Thu, 2017-08-03 at 11:10 +0200, Jiri Kosina wrote: > On Mon, 31 Jul 2017, Jiri Kosina wrote: > > > Hi, > > > > booting current Linus' tree, I'm seeing lockdep splat (see the end of this > > mail). > > > > Apparently, there is AB-BA between tz->lock and mvm->mutex through the CPU > >

Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote: > "Luis R. Rodriguez" writes: > > > > +int request_firmware_nowait(struct module *module, bool uevent, > > > + const char *name, struct device *device, gfp_t gfp, > > > + void

Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote: > "Luis R. Rodriguez" writes: > > > > +int request_firmware_nowait(struct module *module, bool uevent, > > > + const char *name, struct device *device, gfp_t gfp, > > > + void *context, > > > +

Re: [PATCH] iwlwifi: Demote messages about fw flags size to info

On Fri, 2017-07-21 at 07:51 -0700, João Paulo Rechi Vita wrote: > These messages are not reporting a real error, just the fact that the > firmware knows about more flags then the driver. > > Currently these messages are presented to the user during boot if there > is no bootsplash covering the

Re: [PATCH] iwlwifi: Demote messages about fw flags size to info

On Fri, 2017-07-21 at 07:51 -0700, João Paulo Rechi Vita wrote: > These messages are not reporting a real error, just the fact that the > firmware knows about more flags then the driver. > > Currently these messages are presented to the user during boot if there > is no bootsplash covering the

Re: new warning at net/wireless/util.c:1236

On Thu, 2017-05-04 at 07:35 +0300, Kalle Valo wrote: > Linus Torvalds writes: > > > So my Dell XPS 13 seems to have grown a new warning as of the > > networking merge yesterday. > > > > Things still work, but when it starts warning, it generates a *lot* of > >

Re: new warning at net/wireless/util.c:1236

On Thu, 2017-05-04 at 07:35 +0300, Kalle Valo wrote: > Linus Torvalds writes: > > > So my Dell XPS 13 seems to have grown a new warning as of the > > networking merge yesterday. > > > > Things still work, but when it starts warning, it generates a *lot* of > > noise (I got 36 of these within

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > The firmware API does not scale well: when new features are added we > either add a new exported symbol or extend the arguments of existing > routines. For the later case this means we need to traverse the kernel > with a slew of

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > The firmware API does not scale well: when new features are added we > either add a new exported symbol or extend the arguments of existing > routines. For the later case this means we need to traverse the kernel > with a slew of

Re: [PATCH 1/5] firmware: share fw fallback killing on reboot/suspend

Hi Luis, On Wed, 2017-03-29 at 20:24 -0700, Luis R. Rodriguez wrote: > We kill pending fallback requests on suspend and reboot, > the only difference is that on suspend we only kill custom > fallback requests. Provide a wrapper that lets us customize > the request with a flag. > > This also

Re: [PATCH 1/5] firmware: share fw fallback killing on reboot/suspend

Hi Luis, On Wed, 2017-03-29 at 20:24 -0700, Luis R. Rodriguez wrote: > We kill pending fallback requests on suspend and reboot, > the only difference is that on suspend we only kill custom > fallback requests. Provide a wrapper that lets us customize > the request with a flag. > > This also

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

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote: > Didn't get any feedback or review comments on this patch.  Resending > ... > > P. Sorry, this got flooded down my inbox. > ---8<--- > > The iwlwifi driver implements a thermal zone and hwmon device, but > returns -EIO on temperature

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

On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote: > Didn't get any feedback or review comments on this patch.  Resending > ... > > P. Sorry, this got flooded down my inbox. > ---8<--- > > The iwlwifi driver implements a thermal zone and hwmon device, but > returns -EIO on temperature

Re: linux-next: manual merge of the mac80211-next tree with the wireless-drivers-next tree

On Thu, 2016-07-07 at 11:56 +1000, Stephen Rothwell wrote: > Hi Johannes, > > Today's linux-next merge of the mac80211-next tree got a conflict in: > >   drivers/net/wireless/marvell/mwifiex/cmdevt.c > > between commit: > >   a9c790ba23eb ("mwifiex: factor out mwifiex_cancel_scan") > > from

Re: linux-next: manual merge of the mac80211-next tree with the wireless-drivers-next tree

On Thu, 2016-07-07 at 11:56 +1000, Stephen Rothwell wrote: > Hi Johannes, > > Today's linux-next merge of the mac80211-next tree got a conflict in: > >   drivers/net/wireless/marvell/mwifiex/cmdevt.c > > between commit: > >   a9c790ba23eb ("mwifiex: factor out mwifiex_cancel_scan") > > from

Re: [PATCH] iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning

On Fri, 2016-05-27 at 15:07 +0200, Arnd Bergmann wrote: > gcc is apparently unablel to track the state of the local 'resp_v2' > variable across the kzalloc() function, and warns about the response > variable being used without an initialization: > > drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:

Re: [PATCH] iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning

On Fri, 2016-05-27 at 15:07 +0200, Arnd Bergmann wrote: > gcc is apparently unablel to track the state of the local 'resp_v2' > variable across the kzalloc() function, and warns about the response > variable being used without an initialization: > > drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:

Re: [PATCH 1/1] iwlwifi: rs: remove superfluous check

On Wed, 2016-05-18 at 01:31 +0200, Heinrich Schuchardt wrote: > If we dereference a variable anyway in other parts of the code, > there is no need to check against NULL in a single place. NACK.  This is not true. If lq_sta is NULL, it means that mvm_sta is also NULL.  Then we call the

Re: [PATCH 1/1] iwlwifi: rs: remove superfluous check

On Wed, 2016-05-18 at 01:31 +0200, Heinrich Schuchardt wrote: > If we dereference a variable anyway in other parts of the code, > there is no need to check against NULL in a single place. NACK.  This is not true. If lq_sta is NULL, it means that mvm_sta is also NULL.  Then we call the

Re: [GIT] Networking

On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo > wrote: > > > > > > It would be best if you could send a patch either directly to Dave > > or > > Linus to resolve this quickly. > I'm committing my patch myself right

Re: [GIT] Networking

On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 11:58 AM, Kalle Valo > wrote: > > > > > > It would be best if you could send a patch either directly to Dave > > or > > Linus to resolve this quickly. > I'm committing my patch myself right now, since this bug

Re: [GIT] Networking

On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano > <luciano.coe...@intel.com> wrote: > > > > > > I can confirm that 4.6 contains the same bug.  And reverting the > > patch > > I mentioned does so

Re: [GIT] Networking

On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote: > On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano > wrote: > > > > > > I can confirm that 4.6 contains the same bug.  And reverting the > > patch > > I mentioned does solve the problem... >

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano > <luciano.coe...@intel.com> wrote: > > > > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > > > > > > On Wed, May 18, 2016 at 4

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano > wrote: > > > > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > > > > > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano > &

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano > <luciano.coe...@intel.com> wrote: > > > > Hi Emmanuel, Linus, > > > > > > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote: &g

Re: [GIT] Networking

On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote: > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano > wrote: > > > > Hi Emmanuel, Linus, > > > > > > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote: > > > > > > On Wed

Re: [GIT] Networking

Hi Emmanuel, Linus, On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote: > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds > wrote: > > > > On Tue, May 17, 2016 at 12:11 PM, David Miller > > wrote: > > > > > > > > > Highlights: > >

Re: [GIT] Networking

Hi Emmanuel, Linus, On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote: > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds > wrote: > > > > On Tue, May 17, 2016 at 12:11 PM, David Miller > > wrote: > > > > > > > > > Highlights: > > Lowlights: > > > >  1) the iwlwifi driver seems to

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

Hi Kalle, On Mon, 2016-05-16 at 16:10 +0300, Kalle Valo wrote: > (Adding Luca and linux-wireless) > > Stephen Rothwell writes: > > > > > Today's linux-next merge of the wireless-drivers-next tree got a > > conflict in: > > > >  

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

Hi Kalle, On Mon, 2016-05-16 at 16:10 +0300, Kalle Valo wrote: > (Adding Luca and linux-wireless) > > Stephen Rothwell writes: > > > > > Today's linux-next merge of the wireless-drivers-next tree got a > > conflict in: > > > >   drivers/net/wireless/intel/iwlwifi/mvm/tx.c > > > > between

Re: [PATCH] iwlwifi:Fix incorrect fallthrough in switch statement in the function iwl_mvm_check_running_scans

On Tue, 2015-09-22 at 20:24 -0400, Nicholas Krause wrote: > This fixes incorrect fallthrough in the switch statment checking > the scan type passed by the caller to iwl_mvm_check_running_scans > for the switch case IWL_MVM_SCAN_SCHED to return directly after > the call to iwl_mvm_scan_stop in

Re: [PATCH] iwlwifi:Fix incorrect fallthrough in switch statement in the function iwl_mvm_check_running_scans

On Tue, 2015-09-22 at 20:24 -0400, Nicholas Krause wrote: > This fixes incorrect fallthrough in the switch statment checking > the scan type passed by the caller to iwl_mvm_check_running_scans > for the switch case IWL_MVM_SCAN_SCHED to return directly after > the call to iwl_mvm_scan_stop in

rcu_sched self-detected stall on 4.2-rc6

Hi, Yesterday I suddenly got an RCU stall on my machine. I don't know what really led to it, I just started getting "BUG: soft lockup" messages on all my terminals. Here's a small extract of what the logs show: [88989.550488] INFO: rcu_sched self-detected stall on CPU { 0} (t=5250 jiffies

rcu_sched self-detected stall on 4.2-rc6

Hi, Yesterday I suddenly got an RCU stall on my machine. I don't know what really led to it, I just started getting BUG: soft lockup messages on all my terminals. Here's a small extract of what the logs show: [88989.550488] INFO: rcu_sched self-detected stall on CPU { 0} (t=5250 jiffies