1. 02 8月, 2008 1 次提交
  2. 30 7月, 2008 9 次提交
    • J
      mac80211: partially fix skb->cb use · d0f09804
      Johannes Berg 提交于
      This patch fixes mac80211 to not use the skb->cb over the queue step
      from virtual interfaces to the master. The patch also, for now,
      disables aggregation because that would still require requeuing,
      will fix that in a separate patch. There are two other places (software
      requeue and powersaving stations) where requeue can happen, but that is
      not currently used by any drivers/not possible to use respectively.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d0f09804
    • P
      ath5k: don't enable MSI, we cannot handle it yet · 256b152b
      Pavel Roskin 提交于
      MSI is a nice thing, but we cannot enable it without changing the
      interrupt handler.  If we do it, we break MSI capable hardware,
      specifically AR5006 chipset.
      Signed-off-by: NPavel Roskin <proski@gnu.org>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      256b152b
    • B
      ath5k: fix recursive locking in ath5k_beacon_update · bc05116a
      Bob Copeland 提交于
      ath5k_beacon_update takes sc->lock upon entry.  However, it is only
      called from within ath5k_config_interface, which already holds the lock.
      Remove the unnecessary locking from ath5k_beacon_update.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bc05116a
    • B
      ath5k: use positive logic for HP laptop LEDs · 734b5aa9
      Bob Copeland 提交于
      Helge Deller reports that HP laptops (NC4010 and NC6000) use active-
      high signals to turn on the LEDs.  Previous code used active-low for
      all devices.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      734b5aa9
    • J
      Ath5k: suspend/resume fixes · 3e4242b9
      Jiri Slaby 提交于
      - free and re-request irq since it might have changed during suspend
      - disable and enable msi
      - don't set D0 state of the device, it's already done by the PCI layer
      - do restore_state before enable_device, it's safer
      - check ath5k_init return value
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3e4242b9
    • J
      Ath5k: fix dma operation · e86600c7
      Jiri Slaby 提交于
      Don't sync
      - coherent mapping (descriptors)
      - before unmap, it's useless
      - (wrongly anyway -- for_cpu) beacon skb, it's just mapped,
        so by the device yet
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e86600c7
    • J
      Ath5k: flush work · 274c7c36
      Jiri Slaby 提交于
      Make sure that the irq is not in progress after stop. This means
      two things:
      - ensure the intr setting register is set by flushing posted values
      - call synchronize_irq() after that
      
      Also flush stop tx write, inform callers of the tx stop about still
      pending transfers (unsuccessful stop) and finally don't wait another
      3ms in ath5k_rx_stop, since ath5k_hw_stop_rx_dma ensures transfer to
      be finished.
      
      Make sure all writes will be ordered in respect to locks by mmiowb().
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      274c7c36
    • J
      Ath5k: kill tasklets on shutdown · 10488f8a
      Jiri Slaby 提交于
      Don't forget to kill tasklets on stop to not panic if they
      fire after freeing some structures.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      10488f8a
    • J
      Ath5k: fix memory corruption · 3a0f2c87
      Jiri Slaby 提交于
      When signal is noisy, hardware can use all RX buffers and since the last
      entry in the list is self-linked, it overwrites the entry until we link
      new buffers.
      
      Ensure that we don't free this last one until we are 100% sure that it
      is not used by the hardware anymore to not cause memory curruption as
      can be seen below.
      
      This is done by checking next buffer in the list. Even after that we
      know that the hardware refetched the new link and proceeded further
      (the next buffer is ready) we can finally free the overwritten buffer.
      
      We discard it since the status in its descriptor is overwritten (OR-ed
      by new status) too.
      
      =============================================================================
      BUG kmalloc-4096: Poison overwritten
      -----------------------------------------------------------------------------
      
      INFO: 0xffff810067419060-0xffff810067419667. First byte 0x8 instead of 0x6b
      INFO: Allocated in dev_alloc_skb+0x18/0x30 age=1118 cpu=1 pid=0
      INFO: Freed in skb_release_data+0x85/0xd0 age=1105 cpu=1 pid=3718
      INFO: Slab 0xffffe200019d0600 objects=7 used=0 fp=0xffff810067419048 flags=0x40000000000020c3
      INFO: Object 0xffff810067419048 @offset=4168 fp=0xffff81006741c120
      
      Bytes b4 0xffff810067419038:  4f 0b 02 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a O.......ZZZZZZZZ
        Object 0xffff810067419048:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xffff810067419058:  6b 6b 6b 6b 6b 6b 6b 6b 08 42 30 00 00 0b 6b 80 kkkkkkkk.B0...k.
        Object 0xffff810067419068:  f0 5d 00 4f 62 08 a3 64 00 0c 42 16 52 e4 f0 5a 360].Ob.243d..B.R344360Z
        Object 0xffff810067419078:  68 81 00 00 7b a5 b4 be 7d 3b 8f 53 cd d5 de 12 h...{245264276};.S315325336.
        Object 0xffff810067419088:  96 10 0b 89 48 54 23 41 0f 4e 2d b9 37 c3 cb 29 ....HT#A.N-2717303313)
        Object 0xffff810067419098:  d1 e0 de 14 8a 57 2a cc 3b 44 0d 78 7a 19 12 15 321340336..W*314;D.xz...
        Object 0xffff8100674190a8:  a9 ec d4 35 a8 10 ec 8c 40 a7 06 0a 51 a7 48 bb 2513543245250.354.@247..Q247H273
        Object 0xffff8100674190b8:  3e cf a1 c7 38 60 63 3f 51 15 c7 20 eb ba 65 30 >ϡ3078`c?Q.307.353272e0
       Redzone 0xffff81006741a048:  bb bb bb bb bb bb bb bb                         273273273273273273273273
       Padding 0xffff81006741a088:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ
      Pid: 3297, comm: ath5k_pci Not tainted 2.6.26-rc8-mm1_64 #427
      
      Call Trace:
       [<ffffffff802a7306>] print_trailer+0xf6/0x150
       [<ffffffff802a7485>] check_bytes_and_report+0x125/0x180
       [<ffffffff802a75dc>] check_object+0xac/0x260
       [<ffffffff802a9308>] __slab_alloc+0x368/0x6d0
       [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310
       [<ffffffff804b1bd4>] ? __alloc_skb+0x44/0x150
       [<ffffffff80544f82>] ? wireless_send_event+0x142/0x310
       [<ffffffff802aa853>] __kmalloc_track_caller+0xc3/0xf0
       [<ffffffff804b1bfe>] __alloc_skb+0x6e/0x150
      [... stack snipped]
      
      FIX kmalloc-4096: Restoring 0xffff810067419060-0xffff810067419667=0x6b
      
      FIX kmalloc-4096: Marking all objects used
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Acked-by: NNick Kossifidis <mickflemm@gmail.com>
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3a0f2c87
  3. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori 提交于
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  4. 15 7月, 2008 1 次提交
    • J
      mac80211: revamp beacon configuration · 9d139c81
      Johannes Berg 提交于
      This patch changes mac80211's beacon configuration handling
      to never pass skbs to the driver directly but rather always
      require the driver to use ieee80211_beacon_get(). Additionally,
      it introduces "change flags" on the config_interface() call
      to enable drivers to figure out what is changing. Finally, it
      removes the beacon_update() driver callback in favour of
      having IBSS beacon delivered by ieee80211_beacon_get() as well.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9d139c81
  5. 27 6月, 2008 3 次提交
  6. 04 6月, 2008 1 次提交
  7. 22 5月, 2008 4 次提交
  8. 21 5月, 2008 1 次提交
    • B
      ath5k: Fix loop variable initializations · 89fd2e28
      Bob Copeland 提交于
      In ath5k_tasklet_rx, both status structures 'rxs' and 'rs' are
      initialized at the top of the tasklet, but not within the loop.
      If the loop is executed multiple times in the tasklet then the
      variables may see changes from previous packets.
      
      For TKIP, this results in 'Invalid Michael MIC' errors if two packets
      are processed in the tasklet: rxs.flag gets set to RX_DECRYPTED by
      mac80211 when it decrypts the first encrypted packet.  The subsequent
      packet will have RX_DECRYPTED set upon entry to mac80211, so mac80211
      will not try to decrypt it.
      
      We currently initialize all but two fields in the structures, so fix
      the other two.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      89fd2e28
  9. 15 5月, 2008 2 次提交
    • B
      ath5k: Fix loop variable initializations · d6894b5b
      Bob Copeland 提交于
      In ath5k_tasklet_rx, both status structures 'rxs' and 'rs' are
      initialized at the top of the tasklet, but not within the loop.
      If the loop is executed multiple times in the tasklet then the
      variables may see changes from previous packets.
      
      For TKIP, this results in 'Invalid Michael MIC' errors if two packets
      are processed in the tasklet: rxs.flag gets set to RX_DECRYPTED by
      mac80211 when it decrypts the first encrypted packet.  The subsequent
      packet will have RX_DECRYPTED set upon entry to mac80211, so mac80211
      will not try to decrypt it.
      
      We currently initialize all but two fields in the structures, so fix
      the other two.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d6894b5b
    • B
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf 提交于
      trying to clean up the signal/noise code. the previous code in mac80211 had
      confusing names for the related variables, did not have much definition of
      what units of signal and noise were provided and used implicit mechanisms from
      the wireless extensions.
      
      this patch introduces hardware capability flags to let the hardware specify
      clearly if it can provide signal and noise level values and which units it can
      provide. this also anticipates possible new units like RCPI in the future.
      
      for signal:
      
        IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
        IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
        IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW
      
      for noise we currently only have dBm:
      
        IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW
      
      if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
      to provide the maximum value (max_signal) it reports in order for applications
      to make sense of the signal values.
      
      i tried my best to find out for each driver what it can provide and update it
      but i'm not sure (?) for some of them and used the more conservative guess in
      doubt. this can be fixed easily after this patch has been merged by changing
      the hardware flags of the driver.
      
      DRIVER          SIGNAL    MAX	NOISE   QUAL
      -----------------------------------------------------------------
      adm8211         unspec(?) 100   n/a     missing
      at76_usb        unspec(?) (?)   unused  missing
      ath5k           dBm             dBm     percent rssi
      b43legacy       dBm             dBm     percent jssi(?)
      b43             dBm             dBm     percent jssi(?)
      iwl-3945        dBm             dBm     percent snr+more
      iwl-4965        dBm             dBm     percent snr+more
      p54             unspec    127   n/a     missing
      rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
        rt2400        dBm             n/a
        rt2500pci     dBm             n/a
        rt2500usb     dBm             n/a
        rt61pci       dBm             n/a
        rt73usb       dBm             n/a
      rtl8180         unspec(?) 65    n/a     (?)
      rtl8187         unspec(?) 65    (?)     noise(?)
      zd1211          dB(?)     100   n/a     percent
      
      drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
  10. 08 5月, 2008 2 次提交
  11. 29 4月, 2008 1 次提交
  12. 17 4月, 2008 2 次提交
  13. 02 4月, 2008 1 次提交
    • J
      wireless: fix various printk warnings on ia64 (and others) · 06501d29
      John W. Linville 提交于
      drivers/net/wireless/ath5k/base.c: In function `ath5k_check_ibss_tsf':
      drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 5)
      drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 6)
      drivers/net/wireless/ath5k/base.c:1740: warning: long long int format, u64 arg (arg 7)
      drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 8)
      drivers/net/wireless/ath5k/base.c:1757: warning: long long unsigned int format, u64 arg (arg 5)
      drivers/net/wireless/ath5k/base.c:1757: warning: long long unsigned int format, u64 arg (arg 6)
      drivers/net/wireless/iwlwifi/iwl4965-base.c: In function `iwl4965_tx_status_reply_tx':
      drivers/net/wireless/iwlwifi/iwl4965-base.c:3105: warning: long long unsigned int format, u64 arg (arg 6)
      drivers/net/wireless/iwlwifi/iwl-4965.c: In function `iwl4965_rx_reply_rx':
      drivers/net/wireless/iwlwifi/iwl-4965.c:3978: warning: long long unsigned int format, u64 arg (arg 7)
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      06501d29
  14. 08 3月, 2008 4 次提交
  15. 01 3月, 2008 6 次提交
  16. 21 2月, 2008 1 次提交
    • D
      ath5k: Fix build warnings on some 64-bit platforms. · 04f93a87
      David Miller 提交于
      'u64' is not necessarily 'unsigned long long'
      
      drivers/net/wireless/ath5k/base.c: In function 'ath5k_beacon_update_timers':
      drivers/net/wireless/ath5k/base.c:2130: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64'
      drivers/net/wireless/ath5k/base.c:2130: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
      drivers/net/wireless/ath5k/base.c: In function 'ath5k_intr':
      drivers/net/wireless/ath5k/base.c:2391: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'u64'
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      04f93a87