1. 21 Dec, 2011 6 commits
    • Luis R. Rodriguez's avatar
      ath9k: fix roadkill due to Joe's patch on ath_dbg() changes · ec9a5705
      Luis R. Rodriguez authored
      Joe changed ath_dbg() to simpify code but while his patch was
      being merged dfs.c was born and as such did not get the change
      Joe envisioned. This fixes that. Test compiled with:
      
       make allmodconfig
      
      Cc: Joe Perches <joe@perches.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: John W. Linville <linville@tuxdriver.com>
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ec9a5705
    • Johannes Berg's avatar
      iwlagn: fix (remove) use of PAGE_SIZE · 10667136
      Johannes Berg authored
      The ICT code erroneously uses PAGE_SIZE. The bug
      is that PAGE_SIZE isn't necessarily 4096, so on
      such platforms this code will not work correctly
      as we'll try to attempt to read an index in the
      table that the device never wrote, it always has
      4096-byte pages.
      
      Additionally, the manual alignment code here is
      unnecessary -- Documentation/DMA-API-HOWTO.txt
      states:
        The cpu return address and the DMA bus master address are both
        guaranteed to be aligned to the smallest PAGE_SIZE order which
        is greater than or equal to the requested size.  This invariant
        exists (for example) to guarantee that if you allocate a chunk
        which is smaller than or equal to 64 kilobytes, the extent of the
        buffer you receive will not cross a 64K boundary.
      
      Just use appropriate new constants and get rid of
      the alignment code.
      
      Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      10667136
    • Alan Cox's avatar
      rt2800: Add support for the Fujitsu Stylistic Q550 · 3ac44670
      Alan Cox authored
      Just another USB identifier.
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3ac44670
    • Andres Salomon's avatar
      libertas: clean up scan thread handling · afbca95f
      Andres Salomon authored
      The libertas scan thread expects priv->scan_req to be non-NULL.  In theory,
      it should always be set.  In practice, we've seen the following oops:
      
      [ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004
      [ 8363.067490] pgd = c0004000
      [ 8363.078393] [00000004] *pgd=00000000
      [ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT
      [ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan]
      [ 8363.107490] CPU: 0    Not tainted  (3.0.0-gf7ccc69 #671)
      [ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas]
      [ 8363.118326] LR is at 0x0
      [ 8363.120836] pc : [<bf03a854>]    lr : [<00000000>]    psr: 60000113
      [ 8363.120845] sp : ee66bf48  ip : 00000000  fp : 00000000
      [ 8363.120845] r10: ee2c2088  r9 : c04e2efc  r8 : eef97005
      [ 8363.132231] r7 : eee0716f  r6 : ee2c02c0  r5 : ee2c2088  r4 : eee07160
      [ 8363.137419] r3 : 00000000  r2 : a0000113  r1 : 00000001  r0 : eee07160
      [ 8363.143896] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [ 8363.157630] Control: 10c5387d  Table: 2e754019  DAC: 00000015
      [ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8)
      
      While I've not found a smoking gun, there are two places that raised red flags
      for me.  The first is in _internal_start_scan, when we queue up a scan; we
      first queue the worker, and then set priv->scan_req.  There's theoretically
      a 50mS delay which should be plenty, but doing things that way just seems
      racy (and not in the good way).
      
      The second is in the scan worker thread itself.  Depending on the state of
      priv->scan_channel, we cancel pending scan runs and then requeue a run in
      300mS.  We then send the scan command down to the hardware, sleep, and if
      we get scan results for all the desired channels, we set priv->scan_req to
      NULL.  However, it that's happened in less than 300mS, what happens with
      the pending scan run?
      
      This patch addresses both of those concerns.  With the patch applied, we
      have not seen the oops in the past two weeks.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      afbca95f
    • Luis R. Rodriguez's avatar
      ath9k: classify DFS debug header further · 092fadb0
      Luis R. Rodriguez authored
      DFS_DEBUG_H is very generic, instead use something more specific
      to ath9k such as ATH9K_DFS_DEBUG_H.
      Reported-by: default avatarJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      092fadb0
    • John W. Linville's avatar
  2. 20 Dec, 2011 10 commits
  3. 19 Dec, 2011 24 commits