1. 21 May, 2008 5 commits
    • Ivo van Doorn's avatar
      rt2x00: Preserve descriptor information after memmove() · 70a96109
      Ivo van Doorn authored
      Due to usage of memmove() in rt2x00usb the descriptor can become
      corrupted because it is being overwritten by the data part.
      Overall having the descriptor in front of the frame is a bad idea,
      we can however use the skb->cb array for this task, since that
      contains more then enough room to hold the entire descriptor and
      preserve the information long enough.
      After this we can also cleanup the alignment code a bit to make it
      work a bit more flexible to allow for all kinds of odd header lengths.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Gertjan van Wingerde's avatar
      rt2x00: Fix queue related oops in case of deselected mac80211 multi-queue feature. · 61448f88
      Gertjan van Wingerde authored
      With the integration of the mac80211 multiqueue patches it has become possible that the
      mac80211 layer modifies the number of TX queues that is stored inside the ieee80211_hw
      structure, especially when multi-queue is not selected.
      The rt2x00 drivers are not well suited to handle that situation, as they allocate the
      queue structures before mac80211 has modified the number of queues it is going to use,
      and also expect the number of allocated queues to match the hardware implementation.
      Hence, ensure that rt2x00 maintains by itself the number of queues that the hardware
      supports, and, at the same time, making is not dependent on the preservation of contents
      inside a mac80211 structure.
      Signed-off-by: default avatarGertjan van Wingerde <gwingerde@kpnplanet.nl>
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Ivo van Doorn's avatar
      rt2x00: Remove ieee80211_tx_control argument from write_tx_desc() · 61486e0f
      Ivo van Doorn authored
      Move the last remaining information details read from ieee80211_tx_control
      in the drivers to the txentry_desc structure. After this we can
      remove ieee80211_tx_control from the argument list for the callback function,
      which makes it easier when the control information is moved into skb->cb
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Ivo van Doorn's avatar
      rt2x00: Fix TX status reporting · fb55f4d1
      Ivo van Doorn authored
      The tx_status enumeration was broken since the introduction
      of rt61pci. That driver uses different values to report the
      status of the tx action.
      This would lead to frames that were reported as success but
      actually failed to be send out, or frames that were neither
      successfull or failure which were reported as failure.
      Fix this by change the TX status reporting and more explicitely
      check for failure or success. Note that a third possibility is
      added "unknown". Not all hardware (USB) can report the actual
      TX status, for rt61pci some frames will receive this status
      because the TXdone handler is never called for those frames.
      This unknown will now be handled as neither success or failure,
      so we no longer increment the failure counter while this conclusion
      could not be determined from the real status of the frame.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Ivo van Doorn's avatar
      rt2x00: trim skb_frame_desc to 32 bytes · 5a6e5999
      Ivo van Doorn authored
      Remove frame_type from skb_frame_desc and pass it
      as argument to rt2x00debug_dump_frame().
      Change data_len and desc_len to unsigned short
      to save another 4 bytes in skb_frame_desc. Note that
      this was the only location where the data_len and
      desc_len was not yet treated as unsigned short.
      This trim is required to help mac80211 with adding
      the TX control and TX status informtation into the
      skb->cb structure. When that happens, drivers will
      have approximately 40 bytes left to use freely.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  2. 14 May, 2008 1 commit
    • Bruno Randolf's avatar
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf authored
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  3. 12 May, 2008 3 commits
  4. 07 May, 2008 10 commits
  5. 01 May, 2008 2 commits
  6. 23 Apr, 2008 1 commit
  7. 16 Apr, 2008 1 commit
  8. 09 Apr, 2008 1 commit
  9. 08 Apr, 2008 1 commit
  10. 01 Apr, 2008 4 commits
  11. 27 Mar, 2008 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Ignore set_state(STATE_SLEEP) failure · 9896322a
      Ivo van Doorn authored
      Some hardware never seem to accept the "goto sleep" command, since the legacy
      drivers don't have suspend and resume handlers the entire code for it was
      basically a educated guess (based on the "enable radio" code).
      This patch will only print a warning when the "goto sleep" command fails, and
      just continues as usual. Perhaps that means the device will not reach a sleep
      state and consumes more power then it should, but it is equally possible it
      simply needs some seconds longer to sleep. Anyway, by making the command
      non-fatal it will not block the rest of the suspend procedure.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  12. 25 Mar, 2008 3 commits
    • Ivo van Doorn's avatar
      rt2x00: Fix in_atomic() usage · 3a643d24
      Ivo van Doorn authored
      rt73usb and rt2500usb used in_atomic to determine
      if a configuration step should be rescheduled or not.
      Since in_atomic() is not a valid method to determine
      if sleeping is allowed we should fix the way this is handled
      by adding a new flag to rt2x00.
      In addition mark LED class support for the drivers broken
      since that also uses the broken in_atomic() method but
      so far no solution exists to have LED triggers work only
      in scheduled context.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Ivo van Doorn's avatar
      rt2x00: Fix rate detection for invalid signals · 866a0503
      Ivo van Doorn authored
      It has been observed on rt2500pci hardware that some
      frames received with signal 0x0C do not have the OFDM
      flag set.
      Signals can have 2 meanings:
       1) The PLCP value
       2) The bitrate * 10
      For rt2500pci (1) is for frames received with a OFDM rate,
      and (2) is for frames received with a CCK rate.
      But 0x0C is a invalid bitrate value but is a valid PLCP
      value for 54Mbs (obvious OFDM rate).
      This means that it is possible that the hardware does not
      set the OFDM bit correctly under all circumstances.
      This results in rt2x00 failing to detect the rate and
      mac80211 triggering a WARN_ON() and dropping the frame.
      To bypass this, print a warning when such a frame is received,
      and reset the rate to the lowest supported rate for the current band.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Ivo van Doorn's avatar
      rt2x00: Add dev_flags to rx descriptor · 19d30e02
      Ivo van Doorn authored
      The rxdone_entry_desc structure contains 3 fields
      which are always 1 or 0. We can safe 8 bytes by
      replacing them with a single dev_flags fields which
      contain the flags for those settings.
      Additionally we can remove the OFDM flag since it
      is no longer used since the introduction of the
      SIGNAL_PLCP flag.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  13. 24 Mar, 2008 1 commit
  14. 18 Mar, 2008 1 commit
  15. 13 Mar, 2008 5 commits