1. 18 8月, 2010 2 次提交
    • J
      iwlwifi: fix 3945 filter flags · 8b8ab9d5
      Johannes Berg 提交于
      Applying the filter flags directly as done since
      
      commit 3474ad63
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Apr 29 04:43:05 2010 -0700
      
          iwlwifi: apply filter flags directly
      
      broke 3945 under some unknown circumstances, as
      reported by Alex.
      
      Since I want to keep the direct application of
      filter flags on iwlagn, duplicate the code into
      both 3945 and agn and remove committing the
      RXON that broke things from the 3945 version.
      
      Cc: stable@kernel.org [2.6.35]
      Reported-by: NAlex Romosan <romosan@sycorax.lbl.gov>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8b8ab9d5
    • J
      ipw2100: don't sync status queue entries · c206a04f
      John W. Linville 提交于
      These are allocated with pci_alloc_consistent, so calling
      pci_dma_sync_single_for_cpu is incorrect usage of the API.  Remove this
      misuse and consequently avoid the following backtrace:
      
      WARNING: at lib/dma-debug.c:902 check_sync+0xce/0x43a()
      Hardware name: 2373HU6
      ipw2100 0000:02:02.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000034e88008] [size=8 bytes]
      Modules linked in: microcode ipw2100(+) snd_seq_device ppdev libipw nsc_ircc snd_pcm lib80211 video output irda parport_pc cfg80211 parport thinkpad_acpi e1000 iTCO_wdt crc_ccitt snd_timer iTCO_vendor_support snd i2c_i801 pcspkr rfkill soundcore joydev snd_page_alloc yenta_socket radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
      Pid: 0, comm: swapper Tainted: G        W   2.6.35-wl+ #8
      Call Trace:
       [<c043aa42>] warn_slowpath_common+0x6a/0x7f
       [<c05d252a>] ? check_sync+0xce/0x43a
       [<c043aaca>] warn_slowpath_fmt+0x2b/0x2f
       [<c05d252a>] check_sync+0xce/0x43a
       [<c046189a>] ? print_lock_contention_bug+0x11/0xb2
       [<c05d2b6f>] debug_dma_sync_single_for_cpu+0x47/0x49
       [<c06cbd3c>] ? ehci_irq+0x31/0x331
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a221d>] pci_dma_sync_single_for_cpu.clone.1+0x42/0x4b [ipw2100]
       [<f82a23a2>] ipw2100_irq_tasklet+0x17c/0x5e9 [ipw2100]
       [<c043fd87>] tasklet_action+0x78/0xcb
       [<c0440293>] __do_softirq+0xc4/0x183
       [<c044038d>] do_softirq+0x3b/0x5f
       [<c04404d0>] irq_exit+0x3a/0x6d
       [<c0404423>] do_IRQ+0x8b/0x9f
       [<c04038b5>] common_interrupt+0x35/0x3c
       [<c062ecfa>] ? acpi_idle_enter_simple+0xfe/0x13c
       [<c045007b>] ? exit_itimers+0x2d/0x73
       [<c062ecfc>] ? acpi_idle_enter_simple+0x100/0x13c
       [<c070bf10>] cpuidle_idle_call+0x78/0xdc
       [<c040251c>] cpu_idle+0x9b/0xb7
       [<c07b1dd2>] rest_init+0xa6/0xab
       [<c0a4b96d>] start_kernel+0x389/0x38e
       [<c0a4b0c9>] i386_start_kernel+0xc9/0xd0
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c206a04f
  2. 14 8月, 2010 6 次提交
  3. 12 8月, 2010 2 次提交
    • R
      ath9k_htc: fix panic on packet injection using airbase-ng tool. · da93f106
      Rajkumar Manoharan 提交于
      This should fix the oops which occurs during the packet injection
      on monitor interface.
      
      EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
       [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
       [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
       [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
       [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
       [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
       [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
       [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
       [<c04b97c2>] ? __alloc_skb+0x52/0x130
       [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
       [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
       [<c0567e1e>] ? packet_snd+0x21e/0x250
       [<c05684a2>] ? packet_sendmsg+0x32/0x40
       [<c04b4c63>] ? sock_aio_write+0x113/0x130
       [<c0207934>] ? do_sync_write+0xc4/0x100
       [<c0167740>] ? autoremove_wake_function+0x0/0x50
       [<c02f4414>] ? security_file_permission+0x14/0x20
       [<c0207ad4>] ? rw_verify_area+0x64/0xe0
       [<c01e6458>] ? handle_mm_fault+0x338/0x390
       [<c0207cd5>] ? vfs_write+0x185/0x1a0
       [<c058db20>] ? do_page_fault+0x160/0x3a0
       [<c0208512>] ? sys_write+0x42/0x70
       [<c01033ec>] ? syscall_call+0x7/0xb
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      da93f106
    • J
      ipw2100: register pm_qos request before registering pci driver · 2f81b471
      John W. Linville 提交于
      It is necessary to call pm_qos_add_request prior to calling
      pm_qos_update_request.  It was revealed that ipw2100 has been
      doing this wrong since "pm_qos: Get rid of the allocation in
      pm_qos_add_request()" (commit 82f68251)
      added a WARN that results in the following backtrace:
      
      WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
      pm_qos_update_request() called for unknown object
      Call Trace:
      [<c1024088>] ? warn_slowpath_common+0x78/0xb0
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1024153>] ? warn_slowpath_fmt+0x33/0x40
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
      [<c11961c9>] ? vsnprintf+0xc9/0x530
      [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
      [<c12f542d>] ? register_netdevice+0x7d/0x3c0
      [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
      [<c12f579f>] ? register_netdev+0x2f/0x40
      [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
      [<c11a5ebb>] ? local_pci_probe+0xb/0x10
      [<c11a6d49>] ? pci_device_probe+0x69/0x90
      [<c1224704>] ? driver_probe_device+0x74/0x180
      [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
      [<c1224889>] ? __driver_attach+0x79/0x80
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c1223fa2>] ? bus_for_each_dev+0x52/0x80
      [<c1224586>] ? driver_attach+0x16/0x20
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c122395f>] ? bus_add_driver+0x17f/0x250
      [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
      [<c11a6c80>] ? pci_device_remove+0x0/0x40
      [<c1224b13>] ? driver_register+0x63/0x120
      [<c11a6f96>] ? __pci_register_driver+0x36/0xa0
      [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
      [<c1001122>] ? do_one_initcall+0x32/0x170
      [<c1087078>] ? __vunmap+0xb8/0xf0
      [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
      [<c10510c1>] ? sys_init_module+0x161/0x1000
      [<c108f847>] ? sys_close+0x67/0xe0
      [<c13647c1>] ? syscall_call+0x7/0xb
      
      This patch moves pm_qos_add_request prior to pci_register_driver in
      ipw2100 in order to avoid this problem.
      Reported-by: NChristoph Fritz <chf.fritz@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2f81b471
  4. 11 8月, 2010 1 次提交
  5. 10 8月, 2010 8 次提交
    • M
      Bluetooth: Use 3-DH5 payload size for default ERTM max PDU size · db12d647
      Mat Martineau 提交于
      The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
      the default L2CAP MTU.  That default MTU is calculated from the size
      of two DH5 packets, minus ACL and L2CAP b-frame header overhead.
      
      ERTM is used with newer basebands that typically support larger 3-DH5
      packets, and i-frames and s-frames have more header overhead.  With
      clean RF conditions, basebands will typically attempt to use 1021-byte
      3-DH5 packets for maximum throughput.  Adjusting for 2 bytes of ACL
      headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
      of payload.
      
      This PDU size imposes less overhead for header bytes and gives the
      baseband the option to choose 3-DH5 packets, but is small enough for
      ERTM traffic to interleave well with other L2CAP or SCO data.
      672-byte payloads do not allow the most efficient over-the-air
      packet choice, and cannot achieve maximum throughput over BR/EDR.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      db12d647
    • M
      Bluetooth: Fix incorrect setting of remote_tx_win for L2CAP ERTM · cff70fae
      Mat Martineau 提交于
      remote_tx_win is intended to be set on receipt of an L2CAP
      configuration request.  The value is used to determine the size of the
      transmit window on the remote side of an ERTM connection, so L2CAP
      can stop sending frames when that remote window is full.
      
      An incorrect remote_tx_win value will cause the stack to not fully
      utilize the tx window (performance impact), or to overfill the remote
      tx window (causing dropped frames or a disconnect).
      
      This patch removes an extra setting of remote_tx_win when a
      configuration response is received.  The transmit window has a
      different meaning in a response - it is an informational value
      less than or equal to the local tx_win.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cff70fae
    • M
      Bluetooth: Change default L2CAP ERTM retransmit timeout · fa235562
      Mat Martineau 提交于
      The L2CAP specification requires that the ERTM retransmit timeout be at
      least 2 seconds for BR/EDR connections.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fa235562
    • M
      Bluetooth: Fix endianness issue with L2CAP MPS configuration · 86b1b263
      Mat Martineau 提交于
      Incoming configuration values must be converted to native CPU order
      before use.  This fixes a bug where a little-endian MPS value is
      compared to a native CPU value.  On big-endian processors, this
      can cause ERTM and streaming mode segmentation to produce PDUs
      that are larger than the remote stack is expecting, or that would
      produce fragmented skbs that the current FCS code cannot handle.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      86b1b263
    • J
      iwlagn: fix rts cts protection · 94597ab2
      Johannes Berg 提交于
      Currently the driver will try to protect all frames,
      which leads to a lot of odd things like sending an
      RTS with a zeroed RA before multicast frames, which
      is clearly bogus.
      
      In order to fix all of this, we need to take a step
      back and see what we need to achieve:
       * we need RTS/CTS protection if requested by
         the AP for the BSS, mac80211 tells us this
       * in that case, CTS-to-self should only be
         enabled when mac80211 tells us
       * additionally, as a hardware workaround, on
         some devices we have to protect aggregated
         frames with RTS
      
      To achieve the first two items, set up the RXON
      accordingly and set the protection required flag
      in the transmit command when mac80211 requests
      protection for the frame.
      
      To achieve the last item, set the rate-control
      RTS-requested flag for all stations that we have
      aggregation sessions with, and set the protection
      required flag when sending aggregated frames (on
      those devices where this is required).
      
      Since otherwise bugs can occur, do not allow the
      user to override the RTS-for-aggregation setting
      from sysfs any more.
      
      Finally, also clean up the way all these flags get
      set in the driver and move everything into the
      device-specific functions.
      
      Cc: stable@kernel.org [2.6.35]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      94597ab2
    • J
      cfg80211: fix locking in action frame TX · fe100acd
      Johannes Berg 提交于
      Accesses to "wdev->current_bss" must be
      locked with the wdev lock, which action
      frame transmission is missing.
      
      Cc: stable@kernel.org [2.6.33+]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fe100acd
    • J
      libertas: fix build break by including linux/sched.h · a9fda88b
      John W. Linville 提交于
        CC [M]  drivers/net/wireless/libertas/cfg.o
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_scan_worker’:
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: ‘TASK_NORMAL’ undeclared (first use in this function)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: (Each undeclared identifier is reported only once
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: for each function it appears in.)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_cfg_connect’:
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘signal_pending’
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘schedule_timeout’
      Reported-by: NBen Greear <greearb@candelatech.com>
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a9fda88b
    • J
      Revert "p54pci: Add PCI ID for SMC2802W" · 2f2f8f2a
      John W. Linville 提交于
      This reverts commit 5f7aebd8.
      
      Apparently, that PCI ID data was incorrectly taken from the subsystem
      information.  The actual ID matches another already known ID.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2f2f8f2a
  6. 09 8月, 2010 4 次提交
  7. 08 8月, 2010 7 次提交
  8. 07 8月, 2010 3 次提交
  9. 06 8月, 2010 7 次提交