1. 13 Apr, 2014 29 commits
  2. 09 Apr, 2014 1 commit
  3. 06 Apr, 2014 3 commits
    • Emmanuel Grumbach's avatar
      iwlwifi: pcie: don't leave the new NICs awake for commands · e7f76340
      Emmanuel Grumbach authored
      A hardware bug had been discovered on 7260 / 3160 and 7265
      and the workaround for this bug is to force the NIC to stay
      awake as long as we have host commands in flight. This
      workaround has been introduced for all NICs in a previous
      patch:
      
      b9439491 ("iwlwifi: pcie: keep the NIC awake when commands are in flight")
      
      In newer NICs, this bug is solved, so we can let the NIC go
      to sleep even when we send commands. The hardware will wake
      up when we increment the scheduler write pointer.
      Make the workaround conditional to only use it on affected
      hardware.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      e7f76340
    • Eran Harary's avatar
      iwlwifi: mvm: fix the number of channels in family 8000 · 749f1fe1
      Eran Harary authored
      Number of channels changed from 40 to 50
      Signed-off-by: default avatarEran Harary <eran.harary@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      749f1fe1
    • Avri Altman's avatar
      iwlwifi: mvm: Handle power management constraints for additional use-cases · 19889025
      Avri Altman authored
      Today, the driver logic looks for the conditions to disable
      power management albeit power management should be enabled
      in a very few distinct cases.
      This patch changes the driver logic to enable power
      management once the required conditions met.
      While at it, make some housekeeping and support a few
      additional use cases:
      
      a) Add support for a standalone p2p client:
         Power management should be enabled for a P2P client
         MAC only if the firmware supports it (TLV flag is set).
         Instead we used the DCM flag, therefore we didn't cover
         use cases that did not include the DCM flag.
      
      b) Add support to Same-Channel-Mode (SCM):
         If both clients share the same channel (SCM), and there
         are no other active vifs in the system, power management
         should be enabled only if the firmware supports this
         (TLV flag is set).
      
      c) Fix power management logic for GO/AP:
         Today, when we detect an active GO / AP MAC - we disable
         power management for all the vifs altogether.
         Actually, the correct behavior is to enable power
         management on a client if on a different channel
         (based on the firmware capabilities).
      
      d) Housekeeping - Along with that, this patch includes some
         code-reorganizing: Today the logic of disabling power is
         scattered across several functions, specifically in the
         iterator. For the sake of both readability and
         scalability, we moved this logic to its applicable
         function, leaving the iterator gather information only.
         Furthermore, as power management is a MAC-related
         attribute, we moved the power management member to the
         iwl_mvm_vif structure.
      Signed-off-by: default avatarAvri Altman <avri.altman@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      19889025
  4. 31 Mar, 2014 7 commits
    • Alexey Khoroshilov's avatar
      rtl8187: fix use after free on failure path in rtl8187_probe() · a31267c3
      Alexey Khoroshilov authored
      If allocation of io_dmabuf fails, rtl8187_probe() calls usb_put_dev(udev)
      while usb_get_dev(udev) is not called yet. As a result refcnt is decremented
      incorrectly and usb_dev can be used after memory deallocation.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a31267c3
    • Andrea Merello's avatar
      rtl8180: don't use weird trick to access "far" registers · 6cea5f21
      Andrea Merello authored
      In rtl8180/rtl8185/rtl8187se the register space is represented
      using packed structure type. Register are thus accessed using a
      pointer of this type.
      All registers are packed toghether, and only small gaps are present.
      
      However Rtl8187se has also some "sparse" registers, very far from
      the "main register block".
      
      It could be possible to access them by simply declare huge reserved
      blocks inside the register struct (and this causes NO memory waste).
      However, for various reasons, access to those "far" registers is
      done with special dedicated macros, without declaring them in the
      register struct.
      
      This is done in an intricate manner, that makes code less readable
      and caused static analisys tool to produce warnings.
      
      This patch keeps the "macro" mechanism, but it changes its
      implementation in a simplier and more straightforward way.
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6cea5f21
    • Dan Carpenter's avatar
      rsi: rsi_91x: misleading debug printk · 3f3aa2fb
      Dan Carpenter authored
      There is a missing set of curly braces here so the debug output says
      "Probe confirm received" unintentionally.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3f3aa2fb
    • Amitkumar Karwar's avatar
      mwifiex: fix spinlock bad magic bug · a7488c79
      Amitkumar Karwar authored
      [ 6630.450908] BUG: spinlock bad magic on CPU#1,
                     ksdioirqd/mmc1/355
      [ 6630.450914] Unable to handle kernel NULL pointer dereference
                     at virtual address 0000004f
      [ 6630.450919] pgd = ecbd8000
      [ 6630.450926] [0000004f] *pgd=00000000
      [ 6630.450936]  lock: 0xeea4ab08, .magic: 00000000,
                     .owner: <none>/-1, .owner_cpu: 0
      [ 6630.450939] Backtrace:
      [ 6630.450956] [<c010d354>] (unwind_backtrace+0x0/0x118) from
                     [<c060c238>] (dump_stack+0x28/0x30)
      [ 6630.450960] Internal error: Oops: 5 [#1] SMP ARM
      [ 6630.450964] Modules linked in: uvcvideo videobuf2_vmalloc
      [ 6630.450980] [<c060c238>] (dump_stack+0x28/0x30) from
                     [<c0315ab4>] (spin_dump+0x80/0x94)
      [ 6630.450988] [<c0315ab4>] (spin_dump+0x80/0x94) from
                     [<c0315af4>] (spin_bug+0x2c/0x30)
      [ 6630.450996] [<c0315af4>] (spin_bug+0x2c/0x30) from
                     [<c0315b80>] (do_raw_spin_lock+0x28/0x15c)
      [ 6630.451004] [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) from
                     [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
      [ 6630.451016] [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
                     from [<bf07a7f4>] (mwifiex_exec_next_cmd
                                        +0x6c/0x45c [mwifiex])
      [ 6630.451030] [<bf07a7f4>] (mwifiex_exec_next_cmd+0x6c/0x45c
                     [mwifiex]) from [<bf07834c>]
                     (mwifiex_main_process+0x2c8/0x464 [mwifiex])
      [ 6630.451047] [<bf07834c>] (mwifiex_main_process+0x2c8/0x464
                     [mwifiex]) from [<bf0a093c>]
                     (mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio]
      [ 6630.451064] [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc
                     [mwifiex_sdio]) from [<c04bbde0>]
                     (sdio_irq_thread+0x178/0x31c)
      [ 6630.451079] [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) from
                     [<c0145514>] (kthread+0xc8/0xd8)
      [ 6630.451095] [<c0145514>] (kthread+0xc8/0xd8) from
                     [<c0106118>] (ret_from_fork+0x14/0x20)
      
      This bug has introduced/exposed due to recent patch in which we
      cancel pending commands before suspend (using hs_enabling flag).
      The NULL pointer is dereferenced when both
      mwifiex_cancel_all_pending_cmd() and mwifiex_exec_next_cmd()
      try to access cmd pending queue simultaneously.
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a7488c79
    • Andrea Merello's avatar
      rtl8187: fix compile warning · aabcaa8b
      Andrea Merello authored
      ANAPARAM3 register, defined in the rtl818x common register
      struct, is accessed as 16bit by rtl8187se and as 8bit by rtl8187b.
      Since I have no documentation about this, I can only stick to
      the reference code and to what is known to work.
      
      This issue has been addressed by a patch from Larry Finger
      that introduces an "union", in the register struct.
      In my last patch-set I applied it on the register struct, but
      I forget to update rtl8187 driver too.
      This patch does it.
      
      Suggested-by: Larry Finger <Larry.Finger@lwfinger.net> [ Original patch ]
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      aabcaa8b
    • Adam Lee's avatar
      rtlwifi: rtl8188ee: enable MSI interrupts mode · 2a54eb5e
      Adam Lee authored
      Some HP notebooks using this rtl8188ee hardware module can't get
      AP scan results with pin-based interrupts mode, enabling MSI interrupts
      mode could fix it.
      
      As RealTek's testing results, RTL8188EE works well with both MSI mode
      and pin-based mode fallback.
      Signed-off-by: default avatarAdam Lee <adam.lee@canonical.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2a54eb5e
    • Adam Lee's avatar
      rtlwifi: add MSI interrupts mode support · 94010fa0
      Adam Lee authored
      Add MSI interrupts mode support, enable it when submodules' msi_support
      flag is true, also could fallback to pin-based interrupts mode if MSI
      interrupts mode fails.
      
      RealTek's policy(on modules which work well with MSI interrupts mode) is:
      
      > If the platform supports both MSI and pin-based, use MSI.
      > If the platform supports MSI only, use MSI.
      > If the platform supports pin-based only, use pin-based.
      
      Also as RealTek's testing results, RTL8188EE and RTL8723BE work well
      with both MSI mode and pin-based mode fallback.
      Signed-off-by: default avatarAdam Lee <adam.lee@canonical.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      94010fa0