Please pull patch-bomb for iwlwifi

Hi,

This patch series catches wireless-dev up to the stand-alone iwlwifi tree version 0.1.3.

There are totally 117 patches so I won't post them one by one on the list. Please find the commit series for the changes in the patch bomb:

    iwlwifi-efe55d8fa702a23724bf44fdd54059f8c4480941.tgz

at
http://intellinuxwireless.org/iwlwifi/patches/

This is based on wireless-dev commit:

    3382ada69e6796da1675b0c5d064a472e9db2822

---
 drivers/net/wireless/mac80211/iwlwifi/Makefile     |    2 +-
 drivers/net/wireless/mac80211/iwlwifi/base.c       | 2832 +++++++++++++------
 .../net/wireless/mac80211/iwlwifi/iwl-3945-rs.c    |   22 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-3945.c   |  488 ++---
 drivers/net/wireless/mac80211/iwlwifi/iwl-3945.h   |    7 +
 .../net/wireless/mac80211/iwlwifi/iwl-4965-hw.h    |  184 +-
 .../net/wireless/mac80211/iwlwifi/iwl-4965-rs.c    |  518 +++--
 .../net/wireless/mac80211/iwlwifi/iwl-4965-rs.h    |   11 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-4965.c   | 2917 +++++++++++---------
 drivers/net/wireless/mac80211/iwlwifi/iwl-4965.h   |  160 +-
 .../net/wireless/mac80211/iwlwifi/iwl-channel.h    |    8 +-
 .../net/wireless/mac80211/iwlwifi/iwl-commands.h   |   30 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-debug.h  |    9 +
 .../net/wireless/mac80211/iwlwifi/iwl-helpers.h    |  125 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-hw.h     |  188 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-io.h     |    4 +-
 drivers/net/wireless/mac80211/iwlwifi/iwl-priv.h   |   51 +-
 drivers/net/wireless/mac80211/iwlwifi/iwlwifi.h    |  158 +-
 18 files changed, 4650 insertions(+), 3064 deletions(-)

Adel Gadllah (12):
iwlwifi: remove unneded locking in iwl_nic_start
iwlwifi: add iwl_ prefix to module param variables
iwlwifi: move include to top of the file in iwl-helpers.h
iwlwifi: use pci_iomap rather than ioremap_nocache
iwlwifi: use mask instead of % in iwl-4965.c
iwlwifi: replace ieee80211_is_* macros with inline functions
iwlwifi: remove braces for single line of code
iwlwifi: replace todoG with TODO
iwlwifi: add iwl_hw prefix to reg_* functions
iwlwifi: replace with GLOBAL_ARRAY_SIZE with ARRAY_SIZE
iwlwifi: many coding style cleanups
iwlwifi: replace d_ prefix with iwl_mac_ for mac80211 callbacks

Ben M Cahill (14):
iwlwifi: Stabilize and streamline interrupts
iwlwifi: Clean up interrupt support for 3945
iwlwifi: Fix IRQ handle bit checking issue
iwlwifi: Unify and streamline 3945 and 4965 uCode load and launch
iwlwifi: Enable full ssi/noise/signal quality reporting to mac80211
iwlwifi: Refactor sensitivity algorithms
iwlwifi: Compact debug output for false alarms
iwlwifi: Don't use sensitivity data for SNR during SCAN
iwlwifi: Fix bug in iwl4965_sens_energy_cck(), improves performance
iwlwifi: Fix 4965 A-band scans showing incorrect channels
iwlwifi: Move iwl_get_antenna_flags() to 3945-specific function
iwlwifi: Temporary workaround to fix Rx stop issue
iwlwifi: Restore full operation of the chain_noise algorithm
iwlwifi: fix driver unusable when loading with HW RFKILL on

Bob Beers (1):
iwlwifi: Fix iwl4965_kw_init coding style

Charles Gales (1):
iwlwifi: Fixed some issues while porting to a PowerPC Platform

Christian Hesse (1):
iwlwifi: Fix compile problem if CONFIG_IWLWIFI_DEBUG is unset

Hong Liu (9):
iwlwifi: Fix suspend/resume problem
iwlwifi: rs_rate_scale_perform cleanup
iwlwifi: add channel switch cmd handling for iwl4965
iwlwifi: add void channel switch handling function in iwl3945
iwlwifi: fix firmware error after txpower off->on
iwlwifi: fix cannot ping AP after rfkill on->off
iwlwifi: fix firmware error after switch txpower in A band
iwlwifi: fix iwl_hw_nic_reset in iwl3945
iwlwifi: fix iwl3945 not usable when loading with hw rfkill on

Ian Schram (4):
iwlwifi: add 8086:4230 pci id for iwl4965
iwlwifi: remove grabs restricted access from iwl_verify_bsm
iwlwifi: remove warning message when loading the module
iwlwifi: remove useless call for iwl_rx_queue_space

James Ketrenos (2):
iwlwifi: Fix problem with limited Tx power for iwl3945
iwlwifi: Fix possible sign/endian problem with voltage compensation

Mohamed Abbas (26):
iwlwifi: Fix association problem
iwlwifi: enable/disable sensitivity with CONFIG_IWLWIFI_SENSITIVITY
iwlwifi: Fix a driver stability issue
iwlwifi: Fix rate index for 11B
iwlwifi: Fix compilation when HT is enabled
iwlwifi: sensitivity calibration from STATISTICS_NOTIFICATION only
iwlwifi: fix 11n rate scaling and more sinsitivity fixes
iwlwifi: Fix power management
iwlwifi: Fix 60M rate problem
iwlwifi: add 11n modes checkups
iwlwifi: Fix firmware assert when switch from 11n AP to none
iwlwifi: switch between antenna's when transmitting management frames
iwlwifi: Fix beacon interval difference between 3945 and 4965
iwlwifi: fix sinsitivity error
iwlwifi: fix rate scaling issues
iwlwifi: fix scaning while calling config_interface
iwlwifi: Fix iwl4965 stability issue
iwlwifi: fix post assoc on 4965
iwlwifi: fix assert after switching to 2.4 from 5.2 fat channel
iwlwifi: fix scan problems
iwlwifi: set ready flag after post assoc
iwlwifi: QoS support
iwlwifi: fix add station error on scanning
iwlwifi: Tx/Rx aggregation support for IEEE 802.11n
iwlwifi: fix a kernel panic bug during module unload
iwlwifi: Set RX queue size for 4965 to 256

Ron Rindjunsky (2):
iwlwifi: fix legacy counter
iwlwifi: clean fill link quall cmd

Tomas Winkler (31):
iwlwifi: iwl_full_rxon_required assocation
iwlwifi: Fix iwl4965 default values for device id 0x4230
iwlwifi: uCode load endinanity fix
iwlwifi: Fix endianity issue in loading BSM image
iwlwifi: Removed todoG comment
iwlwifi: Endianity fix: skb buffer pointer was swtiched twice
iwlwifi: Fix edianity tagging for rx bd
iwlwifi: Fixing iwl4965_tx_queue_set_status endianity issues and collaterals
iwlwifi: Endianity fix removed iwl4965_sched_queue2ratid
iwlwifi: Endianity cleaning up iwl4965_tx_queue_agg_enable
iwlwifi: Fixing aggregation enable locking
iwlwifi: introducing IWL_DEBUG_LIMIT (net_ratelimit) macro
iwlwifi: ratio2dB make it static
iwlwifi: preventing unnecessary SGI to LGI switches
iwlwifi: Rate scaling debug fixes
iwlwifi: set HT retry number to 3
iwlwifi: Enianity fix for Alive command conversion
iwlwifi: fix no 6/9Mbps rates in TX
iwlwifi: Rate scaling typo fix
iwlwifi: Allocate scan buffer only for host command queue
iwlwifi: Rate scaling peer rates mask checking (legacy rates)
iwlwifi: iwl4965 kill rate setting in sta host command
iwlwifi: fixing addsta host command endinianity
iwlwifi: tx_skb QoS control endianity fix
iwlwifi: pass BAR to mac80211
iwlwifi: fix power save for AP mode
iwlwifi: iwl4965_rx_reply_rx endianity fix
iwlwifi: fix incorrect debug message
iwlwifi: fix iwl_mac_ht_tx_agg_stop
iwlwifi: Fix aggregation disable locking issue
iwlwifi: rate scaling enabling SGI in MIMO

Yi Zhu (1):
iwlwifi: remove module param `mode'

Zhu Yi (7):
iwlwifi: switch to use G mode by default
iwlwifi: protect rxb->list by spinlock
iwlwifi: fix gcc warning for printf resource_size_t
iwlwifi: switch channel only if IEEE80211_CONF_CHANNEL_SWITCH is defined
iwlwifi: workaround firmware STATISTICS_NOTIFICATION cmd bug
iwlwifi: remove unused function iwl_hw_tx_queue_alloc
iwlwifi: update driver version to 0.1.3

mabbas (6):
iwlwifi: Read FAT channel information from eeprom
iwlwifi: fix sensitivity calibration
iwlwifi: initialize post assoction data
iwlwifi: fix post association for 4965
iwlwifi: fix post association for 3945
iwlwifi: IBSS connection fix

Hi -

My little patch "iwl3945: provide frequency to radiotap monitor not channel index" here:

http://www.spinics.net/lists/linux-wireless/msg03499.html

which you kindly Ack'd doesn't seem to be listed in the cluster bomb?

-Andy

Based on a brief glance, patches look good to me. Thanks!

Two suggestions:

1) You should post patches to the list for review. Yes, even if there are 117 of them. That is acceptable -- and encouraged -- mailing list etiquette.

2) I would recommend submitting via git. Auke @ Intel does this with e100/e1000/etc. stuff and it works great.

The main suggestion is #1, since it is important to post patches to linux-wireless. #2 is more in the realm of linville's preference.

Jeff

Here I'm wondering if this is needed. For example, for the libertas WLAN driver we have an extra mailing list where people (mostly) post patches for review. Eventually, Dan Williams put them into his tree and then asks Linville to pull from him. But the patches in his GIT tree won't be sent to linux-wireless for individual review.

Now, isn't doing the iwlwifi project the same? There is a mailinglist for this project
(https://lists.sourceforge.net/lists/listinfo/ipw3945-devel)
where anybody is free to join.

A cursory glance (I'm not in this mailing list) at
http://sourceforge.net/mailarchive/forum.php?forum_name=ipw3945-devel
shows that people indeed post patches there for review.

So, if you ask them to post each and every patch on linux-wireless, then other projects should do the same. Some projects (e.g. bcm43xx) mostly do cross-post. Is this the way people should go?

Because there are different gatekeepers between the upstream project and the kernel maybe it should get reposted. What the ipw3945-ites accept can be different from what the mac80211-its can accept and even the lkml-ites can kick stuff at the end of the game according to their differing requirements.

IMO as importantly patches need a visible lifecycle when they are posted. If a patch arrives on a list, either:

- someone should comment or advise triggering debate and/or a retry,
which deprecates the earlier try;

- the patch should be replied to with a NAK because it is unacceptable,
perhaps because it inherently violates something or perhaps because the retry identified as needed from the debate never came;

- the patch should be replied to with a NAK because after debate it is
agreed the intention of the patch can be done better by someone more experienced with the code;

- or the patch should be ACK'd, with some sign of where it is committed
now.

-Andy

Yes, definitely.

* It is unscalable for core wireless developers to scan every individual driver mailing list.

* The amount of review is demonstrably lower when you bypass the core mailing list.

* The amount of information sharing, with regards to common problems and common solutions, is far far lower when people and knowledge are spread out across a wide variety of mailing lists.

* It's a huge pain to scan $N mailing list archives for something, when you could just scan one and be reasonably certain that your search covered all useful areas.

Like open source itself, we want to bring people -together- to work on a common vision. Not have $N competing visions, that are only reconciled when patches are pushed upstream to linville. That puts additional burden on linville, and lowers the quality of the code (as described in more detail in my response to James K just now).

Jeff

And libertas is the shiny example for a properly written wireless driver, riiiight?

Ideally, that should fall off dramatically over time. I'd like to move most patch traffic from libertas-dev to linux-wireless once the patch volume slows down, as I now think it has. So in the future, I wouldn't mind posting most libertas patches to linux-wireless instead of libertas-dev.

I'd also like to just get rid of the libertas-2.6 git tree and make Linville do all the patch merging work in the future, but that should come after we transition most of the patch review to linux-wireless, so maybe in a few months time. Post 2.6.23 there probably shouldn't be much traffic on libertas-dev, I suspect.

Dan

Sure...even better, of course, would to post them as they are written instead of saving them for one big sweep...

Submissions via git are fine in general -- I do reserve the right to rebase them, edit commit comments, etc.

John

John W. Linville
[email protected]

Quite agreed...

Jeff

I have applied these to the wireless-dev tree. It is available now:

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git

Does the current driver (as posted) depend on mac80211 patches which are not upstream at this time?

Do you believe that you have addressed the bulk of the review comments from the previous posting?

Thanks,

John

John W. Linville
[email protected]

The HT part is still not there but it can be mean wihile compiled out in the driver. I'm suppose to submit HT patches soon hoping for tomorrow if everything works fine. I'm rebasing them against latest wireless-dev.git. I will post them inline if you prefer.

I know you've asked us to review the already submitted 11n/HT patches. I'm suggesting that we just patch over them otherwise we lost driver stability and delay the whole process even more. I'm not happy with this solution myself but to bring the complete solution at once will make us silent for another period.

Most of them. The Endian issues fixing is still in progress.

Thanks
Tomas

What do you mean, "patch over them"?

If this means dual solutions for the same problem, it's not very enticing.

Jeff

No, I mean gradually cleaning up the patches. Theoretically first I want to change data structures, then the interfaces, and finally cleaning up flows. but in bottom line I cannot afford to lost stability of the whole project for the period it takes to fix, currently driver works. Or first solution was narrowed to STA and we want to make it works better in IBSS and AP mode as well. I guess the community doesn't really care about our internal constrains but we all live in time and space.

Tomas

Thanks. I also see you move it to the drivers/net/wireless. Good!

The code requires those mac80211 features are all protected by ifdef CONFIG_IWLWIFI_HT or CONFIG_IWLWIFI_HT_AGG, which are not enabled this time. When the mac80211 HT and AGG features are reviewed and merged, we will make iwlwifi HT feature selectable in Kconfig.

I think so. Especially thanks to Adel Gadllah and Ian Schram, they helped to address lots of review items from Jeff and Andrew. I cannot confirm it's 100% done but at least most of them. BTW, we also have developers running PowerPC, so endian issues will also be addressed in practice more than good habit of coding.

Thanks,
-yi