This patch series catches wireless-dev up to the stand-alone
iwlwifi tree.
I don't have a kernel tree for pulls to be made against. The commit
series for the changes below can be found in the patch bomb:
iwlwifi-8af8d95343e10cae5876907dc5b75b536c53bcb3.tgz
at
http://intellinuxwireless.org/iwlwifi/patches/
This is based on wireless-dev commit:
3480b61c08559777c57b95e346507b26253ca8bb
Signed-off-by: James Ketrenos <[email protected]>
---
drivers/net/wireless/mac80211/iwlwifi/Makefile | 6
drivers/net/wireless/mac80211/iwlwifi/base.c | 809 +++++--
drivers/net/wireless/mac80211/iwlwifi/iwl-3945-rs.c | 969 +++++++++
drivers/net/wireless/mac80211/iwlwifi/iwl-3945-rs.h | 72
drivers/net/wireless/mac80211/iwlwifi/iwl-3945.c | 33
drivers/net/wireless/mac80211/iwlwifi/iwl-4965-hw.h | 263 +-
drivers/net/wireless/mac80211/iwlwifi/iwl-4965-rs.c | 2013 +++++++++++++++++++
drivers/net/wireless/mac80211/iwlwifi/iwl-4965-rs.h | 285 ++
drivers/net/wireless/mac80211/iwlwifi/iwl-4965.c | 1586 ++++++++++----
drivers/net/wireless/mac80211/iwlwifi/iwl-4965.h | 88
drivers/net/wireless/mac80211/iwlwifi/iwl-channel.h | 26
drivers/net/wireless/mac80211/iwlwifi/iwl-commands.h | 55
drivers/net/wireless/mac80211/iwlwifi/iwl-debug.h | 6
drivers/net/wireless/mac80211/iwlwifi/iwl-eeprom.h | 44
drivers/net/wireless/mac80211/iwlwifi/iwl-helpers.h | 117 -
drivers/net/wireless/mac80211/iwlwifi/iwl-hw.h | 91
drivers/net/wireless/mac80211/iwlwifi/iwl-io.h | 38
drivers/net/wireless/mac80211/iwlwifi/iwl-priv.h | 17
drivers/net/wireless/mac80211/iwlwifi/iwlwifi.h | 37
19 files changed, 5532 insertions(+), 1023 deletions(-)
---
Ben M Cahill (1):
iwlwifi: Improve readability and content of 4965 error log.
Hong Liu (12):
iwlwifi: remove priv->down and add priv->restart
iwlwifi: fix rf-kill problem
iwlwifi: rf-kill resume fix
iwlwifi: fix wireless interface missing after resume
iwlwifi: station manipulation functions cleanup
iwlwifi: reformat function iwl_sync_staion
iwlwifi: replace warn_unused_result with __must_check
iwlwifi: kill magic nums in iwl_eeprom_init
iwlwifi: free ucode_data_backup
iwlwifi: remove IWL == 3945 block in iwl-4965.c
iwlwifi: fix iwl_read_ucode endian issue
iwlwifi: remove FREE_FRAME_THRESHOLD reference
James Ketrenos (14):
iwlwifi: Removed iwl_link_up and repurposed iwl_link_down
iwlwifi: Add 3945 specific rate control algorithm back in
iwlwifi: Added comment indicating why pci.h is needed in iwlwifi.h
iwlwifi: Update version base.c stamp to 0.0.22
iwlwifi: Leading whitespace problem typo.
iwlwifi: Update version base.c stamp to 0.0.24
iwlwifi: Fix warning in iwl_set_bits on 32-bit boundary bit-fields
iwlwifi: Removed old comment about iwl-4965.c not being functional
iwlwifi: whitespace fixes for labels incorrectly indented
iwlwifi: Fixed clean_whitespace to correct leading spaces vs. tabs
iwlwifi: Fixed leading space vs. tab inconsistencies
iwlwifi: Fixed problem with building when CONFIG_IWLWIFI_HT=n
iwlwifi: Resolve style issues reported by checkpatch.pl
iwlwifi: Update version base.c stamp to 0.0.25
Mohamed Abbas (2):
iwlwifi: add iwl4965 rate scaling
iwlwifi: add 11n connection support
Tomas Winkler (6):
iwlwifi: removed unused constant MAX_REAL_TX_QUEUE_NUM
iwlwifi: RTS_DEFAULT_RETRY_LIMIT FIX (4965)
iwlwifi: correct tx cmd byte count constants
iwlwifi: iwlwifif: iwl4965_kw_free fix
iwlwifi: ieee80211_get_qos_ctrl - corrected
iwlwifi: iwl_dma_addr2rbd_ptr - commit
mabbas (6):
iwlwifi: Calculate 4965 temperature immediately after "initialize" alive
iwlwifi: Replace "-", which could easily be misread as a negative sign, with ":"
iwlwifi: fix stabilty with switching between AP
iwlwifi: reset 11n data on startup
iwlwifi: add sensitivity calibration
iwlwifi: add ibss connection support
On Wed, Jul 25, 2007 at 04:43:14PM +0200, Holger Schurig wrote:
> > 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.
>
> 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.
And libertas is the shiny example for a properly written wireless driver,
riiiight?
Tomas Winkler wrote:
> 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.
What do you mean, "patch over them"?
If this means dual solutions for the same problem, it's not very enticing.
Jeff
On Wed, Jul 25, 2007 at 10:23:21AM -0400, Jeff Garzik wrote:
> 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.
Sure...even better, of course, would to post them as they are written
instead of saving them for one big sweep...
> 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.
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]
John W. Linville wrote:
> On Wed, Jul 25, 2007 at 10:23:21AM -0400, Jeff Garzik wrote:
>
>> 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.
>
> Sure...even better, of course, would to post them as they are written
> instead of saving them for one big sweep...
Quite agreed...
Jeff
On Wed, Jul 25, 2007 at 04:57:54PM +0800, Zhu Yi wrote:
> 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
>
> Signed-off-by: Zhu Yi <[email protected]>
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]
Somebody in the thread at some point said:
> 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
Holger Schurig wrote:
> 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?
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
> 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.
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?
On Wed, 2007-07-25 at 16:43 +0200, Holger Schurig wrote:
> > 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.
>
> 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.
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
> 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?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/25/07, John W. Linville <[email protected]> wrote:
> On Wed, Jul 25, 2007 at 04:57:54PM +0800, Zhu Yi wrote:
>
> > 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
> >
> > Signed-off-by: Zhu Yi <[email protected]>
>
> 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?
>
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.
> Do you believe that you have addressed the bulk of the review comments
> from the previous posting?
Most of them. The Endian issues fixing is still in progress.
Thanks
Tomas
> Thanks,
>
> John
> --
> John W. Linville
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 7/26/07, Jeff Garzik <[email protected]> wrote:
> Tomas Winkler wrote:
> > 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.
>
>
> What do you mean, "patch over them"?
>
> If this means dual solutions for the same problem, it's not very enticing.
>
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
> Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, 2007-07-25 at 16:07 -0400, John W. Linville wrote:
>
> 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
Thanks. I also see you move it to the drivers/net/wireless. Good!
> Does the current driver (as posted) depend on mac80211 patches which
> are not upstream at this time?
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.
> Do you believe that you have addressed the bulk of the review comments
> from the previous posting?
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