1. 01 4月, 2014 9 次提交
    • 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
  2. 28 3月, 2014 31 次提交