1. 13 4月, 2014 22 次提交
  2. 10 4月, 2014 1 次提交
  3. 06 4月, 2014 3 次提交
    • E
      iwlwifi: pcie: don't leave the new NICs awake for commands · e7f76340
      Emmanuel Grumbach 提交于
      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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      e7f76340
    • E
      iwlwifi: mvm: fix the number of channels in family 8000 · 749f1fe1
      Eran Harary 提交于
      Number of channels changed from 40 to 50
      Signed-off-by: NEran Harary <eran.harary@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      749f1fe1
    • A
      iwlwifi: mvm: Handle power management constraints for additional use-cases · 19889025
      Avri Altman 提交于
      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: NAvri Altman <avri.altman@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      19889025
  4. 01 4月, 2014 10 次提交
    • A
      rtl8187: fix use after free on failure path in rtl8187_probe() · a31267c3
      Alexey Khoroshilov 提交于
      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: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a31267c3
    • A
      rtl8180: don't use weird trick to access "far" registers · 6cea5f21
      Andrea Merello 提交于
      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: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6cea5f21
    • D
      rsi: rsi_91x: misleading debug printk · 3f3aa2fb
      Dan Carpenter 提交于
      There is a missing set of curly braces here so the debug output says
      "Probe confirm received" unintentionally.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3f3aa2fb
    • A
      mwifiex: fix spinlock bad magic bug · a7488c79
      Amitkumar Karwar 提交于
      [ 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: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7488c79
    • A
      rtl8187: fix compile warning · aabcaa8b
      Andrea Merello 提交于
      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: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aabcaa8b
    • A
      rtlwifi: rtl8188ee: enable MSI interrupts mode · 2a54eb5e
      Adam Lee 提交于
      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: NAdam Lee <adam.lee@canonical.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a54eb5e
    • A
      rtlwifi: add MSI interrupts mode support · 94010fa0
      Adam Lee 提交于
      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: NAdam Lee <adam.lee@canonical.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      94010fa0
    • A
      mwifiex: use timeout variant for wait_event_interruptible · 52250cbe
      Amitkumar Karwar 提交于
      It has been observed that system hangs during suspend, if host
      sleep activation fails due to a missing interrupt from firmware.
      Use timeout variant, so that the thread will be woken up when
      timer expires.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      52250cbe
    • A
      mwifiex: cancel pending commands for signal · 3d026d09
      Amitkumar Karwar 提交于
      When a thread is interrupted by signal, all
      wait_event_interruptible calls after queueing commands return
      an error. Numbers of commands in pending queue are increased
      in this case. Sometimes all commands nodes in pool are filled.
      
      We will cancel pending commands when signal is received.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d026d09
    • A
      mwifiex: scan command preparation failure handling · 1845bd3a
      Amitkumar Karwar 提交于
      When scan request is received, scan commands are prepared and
      queued into scan pending queue. There is a corner case when
      command nodes are full. So we stop queueing further scan
      commands and return an error. This patch makes sure that
      currently queued commands in scan pending queue are also freed
      in this case.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1845bd3a
  5. 28 3月, 2014 4 次提交