1. 25 7月, 2009 2 次提交
    • R
      iwlwifi: inform user about rfkill state changes · 4c423a2b
      Reinette Chatre 提交于
      rfkill state changes are mostly available through debug messages.
      These are significant enough to always make user aware of so
      we turn them into warnings.
      
      Also insert a missing newline in some rfkill related debug message.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4c423a2b
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre 提交于
      * Deprecate the "debug50" module parameter used to obtain
        5000 series and up debugging. Replace it with "debug" module
        parameter to match with original driver and be consistent
        between them. The "debug50" module parameter can still be used,
        except that the module parameter is not writable in keeping
        with its previous state. We currently just mark it as "deprecated"
        and do not have it in the feature-removal-schedule. Some more
        cleanup of module parameters needs to be done and can then be
        entered together.
      
      * Only make "debug" module parameters visible if the driver
        is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
        a lot of confusion where users think they have set debug flags
        but yet cannot see any debug output.
      
      * Make module parameters writable. This eliminates the need for the
        "debug_level" sysfs file, which can now also be deprecated and
        added to feature-removal-schedule. This file is in significant
        use though with many iwlwifi documents and text referring users
        to it. We can thus not take its removal lightly and keep it around.
      
      With iwlcore shared between iwlagn and iwl3945 we really do not need
      debug module parameters for each but can instead have one debug
      module parameter for the iwlcore module. The same issue is here as
      with the sysfs file - a lot of iwlwifi documentation and text (like
      bug reports) rely on iwlagn and iwl3945 having this module parameter,
      so changing this to a module parameter of iwlcore will have significant
      impact and we do not do this for that reason.
      
      One consequence of this patch is that if a user is running a system
      with both 3945 and later hardware then the setting of the one module
      parameter will affect the value of the other. The likelihood of this
      seems low - and even if this setup is present it does not seem like an
      issue for both modules to run with the same debug level.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
  2. 22 7月, 2009 1 次提交
  3. 11 7月, 2009 2 次提交
  4. 23 5月, 2009 1 次提交
  5. 23 4月, 2009 2 次提交
  6. 22 4月, 2009 2 次提交
    • R
      iwlwifi: DMA fixes · df833b1d
      Reinette Chatre 提交于
      A few issues wrt DMA were uncovered when using the driver with swiotlb.
      - driver should not use memory after it has been mapped
      - iwl3945's RX queue management cannot use all of iwlagn because
        the size of the RX buffer is different. Revert back to using
        iwl3945 specific routines that map/unmap memory.
      - no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
        we can just call pci_unmap_single initially
      - only map the memory area that will be used by device. this is especially
        relevant to the mapping of iwl_cmd. we should not map the entire
        structure because the meta data at the beginning of structure contains
        the address to be used later for unmapping. If the address to be used for
        unmapping is stored in mapped data it creates a problem.
      - ensure that _if_ memory needs to be modified after it is mapped that we
        call _sync_single_for_cpu first, and then release it back to device with
        _sync_single_for_device
      - we mapped the wrong length of data for host commands, with mapped length
        differing with length provided to device, fix that.
      
      Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
      help to find these issues.
      
      This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Tested-by: NJason Andryuk <jandryuk@gmail.com>
      Tested-by: NBen Gamari <bgamari@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      df833b1d
    • R
      iwlwifi: add debugging for TX path · d2ee9cd2
      Reinette Chatre 提交于
      When debugging TX issues it is helpful to know the seq nr of the
      frame being transmitted. The seq nr is printed as part of ucode's
      log informing us which frame is being processed. Having this information
      printed in driver log makes it easy to match activities between driver
      and firmware.
      
      Also make possible to print TX flags directly. These are already printed
      as part of entire TX command, but having it printed directly in cpu format
      makes it easier to look at.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d2ee9cd2
  7. 28 3月, 2009 3 次提交
  8. 28 2月, 2009 1 次提交
  9. 26 2月, 2009 1 次提交
  10. 10 2月, 2009 2 次提交
  11. 30 1月, 2009 9 次提交
  12. 20 12月, 2008 1 次提交
  13. 13 12月, 2008 2 次提交
  14. 05 12月, 2008 1 次提交
  15. 26 11月, 2008 3 次提交
  16. 22 11月, 2008 2 次提交
  17. 11 11月, 2008 1 次提交
  18. 01 11月, 2008 4 次提交