Please pull 'upstream' branch of rt2x00

Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi John,

Today a very quick release of 2.0.4,
reason for this quick followup on 2.0.3 are the fixes
regarding the USB ID and the rt61pci interrupts.

The latter one (hopefully) resolves an bugreport recently
raised in the Fedora Bugzilla. (I'll update the report in a few seconds)

And yes I have read the mails of today regarding patch submissions,
so I'll start sending the individual patches as well along with this pull request. ;)

Short note about the state of rt2x00:
  - Code cleaning is progressing, next version will probably contain
    the result of Lindent run. But after that I don't expect big changes regarding
    code style.

  - Writing "Magical" values to the registers has been reduced as much as possible,
    most values that are still magical are really magic and I have no clue on what they
    exactly mean, except that those values should be written. ;)

  - Suspend/resume is completely broken. I am not sure how the device should
    correctly suspend/resume. Most important points on this area are
    deregistering/registering ieee80211_hw and reassociation after resume.
    I am gathering some more info on this, and will post a bigger report on the mailinglist
    in a few days.

  - Statistics reading. Noise and Signal are still empty...
    It would really be nice to have some value to report for these statistics.

  - Bug reports show definite progress, rt2x00 doesn't really seem to break things,
    but neither is it doing a usefull things...

Ivo

---

The following changes since commit 9cc4f5142dd983d178b158e782d5e60900e48270:
  Michael Wu (1):
        mac80211: use more GFP_KERNEL instead of GFP_ATOMIC

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/ upstream

Adam Baker (1):
      rt2x00: Don't export unneeded symbols

Ivo van Doorn (13):
      rt2x00: Check permissions on debugfs write
      Merge branch 'wireless-dev'
      rt2x00: Use rts_cts_rate for CTS frames
      rt2x00: Cleanup allocation/initialization
      rt2x00: rt61pci interrupts are called on MCU CMD done
      rt2x00: Reduce requirement for debugfs wrapper functions
      rt2x00: Don't toggle promisc mode in link_tuner
      rt2x00: Fix MAC address initialization for multiple interfaces
      Merge branch 'wireless-dev'
      rt2x00: Check for all errors on RXdone
      rt2x00: Parse chipset revision for RT chip validation
      rt2x00: Release 2.0.4
      Merge branch 'wireless-dev'

 drivers/net/wireless/mac80211/rt2x00/rt2400pci.c   |   83 +--
 drivers/net/wireless/mac80211/rt2x00/rt2400pci.h   |    2 +-
 drivers/net/wireless/mac80211/rt2x00/rt2500pci.c   |   90 +---
 drivers/net/wireless/mac80211/rt2x00/rt2500pci.h   |    2 +-
 drivers/net/wireless/mac80211/rt2x00/rt2500usb.c   |  105 ++---
 drivers/net/wireless/mac80211/rt2x00/rt2500usb.h   |    4 +-
 drivers/net/wireless/mac80211/rt2x00/rt2x00.h      |   17 +-
 drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c |  237 +++------
 drivers/net/wireless/mac80211/rt2x00/rt2x00debug.h |   27 +-
 drivers/net/wireless/mac80211/rt2x00/rt2x00dev.c   |  560 ++++++++++----------
 drivers/net/wireless/mac80211/rt2x00/rt2x00dev.h   |    1 -
 drivers/net/wireless/mac80211/rt2x00/rt2x00mac.c   |   57 ++-
 drivers/net/wireless/mac80211/rt2x00/rt2x00pci.c   |   58 ++-
 drivers/net/wireless/mac80211/rt2x00/rt2x00usb.c   |  126 +++--
 drivers/net/wireless/mac80211/rt2x00/rt2x00usb.h   |    1 -
 drivers/net/wireless/mac80211/rt2x00/rt61pci.c     |   99 ++---
 drivers/net/wireless/mac80211/rt2x00/rt61pci.h     |    2 +-
 drivers/net/wireless/mac80211/rt2x00/rt73usb.c     |  100 ++---
 drivers/net/wireless/mac80211/rt2x00/rt73usb.h     |    2 +-
 19 files changed, 731 insertions(+), 842 deletions(-)

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[John W. Linville]

On Wed, Jul 25, 2007 at 10:49:47PM +0200, Ivo van Doorn wrote:

> Today a very quick release of 2.0.4,
> reason for this quick followup on 2.0.3 are the fixes
> regarding the USB ID and the rt61pci interrupts.

Ivo,

Thanks for the post -- I merged them into wireless-dev.  You might
also notice that I moved the driver files up two levels into
drivers/net/wireless (along w/ the other drivers).

Any idea when you'll be ready for rt2x00 to go upstream?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi,

> > Today a very quick release of 2.0.4,
> > reason for this quick followup on 2.0.3 are the fixes
> > regarding the USB ID and the rt61pci interrupts.
> 
> Ivo,
> 
> Thanks for the post -- I merged them into wireless-dev.  You might
> also notice that I moved the driver files up two levels into
> drivers/net/wireless (along w/ the other drivers).

Thanks.
But one request, do you mind if I put all rt2x00 files into
a new folder drivers/net/wireless/rt2x00 ?
There are 25 files that belong to rt2x00 and it would be nice
if I can have them grouped together.

> Any idea when you'll be ready for rt2x00 to go upstream?

Not really sure I want to have at least atop making the
suspend/resume result into a big kernel panic, and adhoc
mode should come back to live.
All other reported bugs are more rare and appear not affect
that many people.
So hopefully within 1 or 2 months should rt2x00 reach a condition
where I am more confident about moving a bit further upstream.

Ivo

Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi John,

Well finally rt2x00 2.0.7 is released, unfortunately it will
not be the last release in the 2.0.* series as promised earlier.

This series contains lots of bugfixes, but some of the more
critical issues are still present. rt2x00 is however becoming
more usable for more people, so the progress is there. ;)

I'll do my best to make the next release 2.0.8 the last in the
2.0.* series so 2.1.0 can be moved upstream. :)

Ivo

---
The following changes since commit f5a420590f3f6a45ee5bca0048640f0f24852315:
  John W. Linville (1):
        Merge branch 'b43' into everything

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/ upstream

Ivo van Doorn (27):
      rt2x00: Correctly configure packet filter in monitor mode
      rt2x00: Clear MAC and BSSID when non-monitor interface goes down
      rt2x00: Check return value of usb_control_msg()
      rt2x00: Clear all fields on start_link_tune()
      rt2x00: Don't increase rx_failed for individual frames
      rt2x00: Set vgc_level during reset_tuner
      rt2x00: Schedule beacon update
      rt2x00: Be consistent with unsigned
      rt2x00: Correctly reset TX/RX success/failed counters
      rt2x00: Rework RF register handling
      rt2x00: rt2x00_ring_free returns invalid length
      rt2x00: Use caching for USB transfers
      rt2x00: Cleanup set_state for rt61 and rt73
      rt2x00: Fix register initialization ordering
      rt2x00: memset descriptor before use
      rt2x00: Remove IEEE80211_HW_WEP_INCLUDE_IV flag
      rt2x00: Cleanup TXD flags
      rt2x00: Add byte-ordering annotation for MAC and BSSID
      rt2x00: Correctly set TXD retry flag
      rt2x00: Move rt2x00 files into rt2x00 folder
      rt2x00: Add file pattern to MAINTAINER entry
      rt2x00: Fix PLCP setup
      rt2x00: Clean up RATEMASK handling
      rt2x00: Add rt2x00lib_reset_link_tuner()
      rt2x00: Always check if mac80211 requested TX status update
      rt2x00: Lindent
      rt2x00: rt2x00 2.0.7

Luca Tettamanti (1):
      Fix off-by-one error in debugfs helpers

Mattias Nissler (2):
      rt2x00: Fix width of filter field.
      rt2x00: Store firmware in memory

 MAINTAINERS                                        |    1 +
 drivers/net/wireless/Kconfig                       |  131 +------
 drivers/net/wireless/Makefile                      |   23 +-
 drivers/net/wireless/rt2x00/Kconfig                |  130 ++++++
 drivers/net/wireless/rt2x00/Makefile               |   22 +
 drivers/net/wireless/{ => rt2x00}/rt2400pci.c      |  149 ++++---
 drivers/net/wireless/{ => rt2x00}/rt2400pci.h      |    0 
 drivers/net/wireless/{ => rt2x00}/rt2500pci.c      |  409 ++++++++++--------
 drivers/net/wireless/{ => rt2x00}/rt2500pci.h      |    0 
 drivers/net/wireless/{ => rt2x00}/rt2500usb.c      |  382 +++++++++-------
 drivers/net/wireless/{ => rt2x00}/rt2500usb.h      |    0 
 drivers/net/wireless/{ => rt2x00}/rt2x00.h         |   56 ++-
 drivers/net/wireless/{ => rt2x00}/rt2x00config.c   |   14 +-
 drivers/net/wireless/{ => rt2x00}/rt2x00debug.c    |   23 +-
 drivers/net/wireless/{ => rt2x00}/rt2x00debug.h    |    0 
 drivers/net/wireless/{ => rt2x00}/rt2x00dev.c      |  221 ++++++----
 drivers/net/wireless/{ => rt2x00}/rt2x00firmware.c |   43 ++-
 drivers/net/wireless/{ => rt2x00}/rt2x00lib.h      |    5 +
 drivers/net/wireless/{ => rt2x00}/rt2x00mac.c      |   15 +-
 drivers/net/wireless/{ => rt2x00}/rt2x00pci.c      |    7 +-
 drivers/net/wireless/{ => rt2x00}/rt2x00pci.h      |    0 
 drivers/net/wireless/{ => rt2x00}/rt2x00reg.h      |   56 ++-
 drivers/net/wireless/{ => rt2x00}/rt2x00rfkill.c   |    0 
 drivers/net/wireless/{ => rt2x00}/rt2x00ring.h     |    6 +-
 drivers/net/wireless/{ => rt2x00}/rt2x00usb.c      |  114 ++++-
 drivers/net/wireless/{ => rt2x00}/rt2x00usb.h      |   60 +++-
 drivers/net/wireless/{ => rt2x00}/rt61pci.c        |  466 ++++++++------------
 drivers/net/wireless/{ => rt2x00}/rt61pci.h        |    0 
 drivers/net/wireless/{ => rt2x00}/rt73usb.c        |  471 +++++++++++---------
 drivers/net/wireless/{ => rt2x00}/rt73usb.h        |    0 
 30 files changed, 1532 insertions(+), 1272 deletions(-)
 create mode 100644 drivers/net/wireless/rt2x00/Kconfig
 create mode 100644 drivers/net/wireless/rt2x00/Makefile
 rename drivers/net/wireless/{ => rt2x00}/rt2400pci.c (94%)
 rename drivers/net/wireless/{ => rt2x00}/rt2400pci.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2500pci.c (84%)
 rename drivers/net/wireless/{ => rt2x00}/rt2500pci.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2500usb.c (81%)
 rename drivers/net/wireless/{ => rt2x00}/rt2500usb.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00.h (94%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00config.c (92%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00debug.c (94%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00debug.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00dev.c (85%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00firmware.c (84%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00lib.h (94%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00mac.c (97%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00pci.c (98%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00pci.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00reg.h (80%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00rfkill.c (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00ring.h (96%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00usb.c (85%)
 rename drivers/net/wireless/{ => rt2x00}/rt2x00usb.h (65%)
 rename drivers/net/wireless/{ => rt2x00}/rt61pci.c (89%)
 rename drivers/net/wireless/{ => rt2x00}/rt61pci.h (100%)
 rename drivers/net/wireless/{ => rt2x00}/rt73usb.c (82%)
 rename drivers/net/wireless/{ => rt2x00}/rt73usb.h (100%)

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[John W. Linville]

On Sun, Aug 19, 2007 at 08:18:30PM +0200, Ivo van Doorn wrote:

> Well finally rt2x00 2.0.7 is released, unfortunately it will
> not be the last release in the 2.0.* series as promised earlier.

Merged to wireless-dev...

-- 
John W. Linville
linville@tuxdriver.com

Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi John,

Here is the 2.0.12 release of rt2x00.
I noticed you only pulled 2 patches from the 2.0.11 release,
and I don't know why you dropped the remaining patches.
This means that this pull requests also contains the remaining
2.0.11 patches...

Lots of bugfixes this time, finally rfkill is working, link speeds issues
have been resolved and some packet loss issues are gone.

All indivual patches can also be found here:
http://kernel.org//pub/linux/kernel/people/ivd/rt2x00-2.0.12/

Ivo

---

The following changes since commit 0119130478b1706232d79c768cb587c5e0c615de:
  John W. Linville (1):
        Merge branch 'fixes-jgarzik' into everything

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/ upstream

Adam Baker (2):
      rt2x00: Unconstify rt2x00dev
      rt2x00: Place mutex around USB register access

Ivo van Doorn (15):
      rt2x00: Move quality statistics into seperate structure
      rt2x00: Use enum defines
      rt2x00: Correctly translate mac80211 antenna setup to rt2x00
      rt2x00: SW diversity should default to antenna B
      rt2x00: Remove rt2x00_clear_link
      rt2x00: Implement SW diversity
      rt2x00: Cleanup if-statements
      rt2x00: Release rt2x00 2.0.11
      rt2x00: Disable RX when switching antenna
      rt2x00: Split rt61/rt73 antenna selection into RX and TX antenna
      rt2x00: Input-polldev requires input device
      rt2x00: Detect initial rfkill state on register
      rt2x00: Remove unused variables
      rt2x00: Remove data_desc structure
      rt2x00: Release rt2x00 2.0.12

Mattias Nissler (4):
      rt2x00: Fix antenna selection.
      rt2x00: Rework rt61 antenna selection.
      rt2x00: Rework rt73 antenna selection
      rt2x00: Correctly set ACK bit in tx descriptors

 drivers/net/wireless/rt2x00/rt2400pci.c    |  104 +++++----
 drivers/net/wireless/rt2x00/rt2400pci.h    |    4 +-
 drivers/net/wireless/rt2x00/rt2500pci.c    |  112 +++++-----
 drivers/net/wireless/rt2x00/rt2500pci.h    |    4 +-
 drivers/net/wireless/rt2x00/rt2500usb.c    |  169 +++++++++-----
 drivers/net/wireless/rt2x00/rt2500usb.h    |   17 ++-
 drivers/net/wireless/rt2x00/rt2x00.h       |  192 ++++++++++++----
 drivers/net/wireless/rt2x00/rt2x00config.c |   95 ++++++++-
 drivers/net/wireless/rt2x00/rt2x00debug.h  |    4 +-
 drivers/net/wireless/rt2x00/rt2x00dev.c    |  212 +++++++++++++++---
 drivers/net/wireless/rt2x00/rt2x00lib.h    |    2 +
 drivers/net/wireless/rt2x00/rt2x00pci.c    |    4 +-
 drivers/net/wireless/rt2x00/rt2x00pci.h    |    8 +-
 drivers/net/wireless/rt2x00/rt2x00rfkill.c |   44 ++++-
 drivers/net/wireless/rt2x00/rt2x00ring.h   |   23 +--
 drivers/net/wireless/rt2x00/rt2x00usb.c    |   38 +++-
 drivers/net/wireless/rt2x00/rt2x00usb.h    |   19 +-
 drivers/net/wireless/rt2x00/rt61pci.c      |  332 ++++++++++++++--------------
 drivers/net/wireless/rt2x00/rt61pci.h      |   14 +-
 drivers/net/wireless/rt2x00/rt73usb.c      |  198 ++++++++++-------
 drivers/net/wireless/rt2x00/rt73usb.h      |   14 +-
 21 files changed, 1071 insertions(+), 538 deletions(-)

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[John W. Linville]

On Sat, Oct 27, 2007 at 01:34:34PM +0200, Ivo van Doorn wrote:

> Here is the 2.0.12 release of rt2x00.
> I noticed you only pulled 2 patches from the 2.0.11 release,
> and I don't know why you dropped the remaining patches.
> This means that this pull requests also contains the remaining
> 2.0.11 patches...

I haven't dropped them.  I'll be merging them for 2.6.25.  The patches
that got merged were sent as fixes for 2.6.24.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

On Saturday 27 October 2007, John W. Linville wrote:
> On Sat, Oct 27, 2007 at 01:34:34PM +0200, Ivo van Doorn wrote:
> 
> > Here is the 2.0.12 release of rt2x00.
> > I noticed you only pulled 2 patches from the 2.0.11 release,
> > and I don't know why you dropped the remaining patches.
> > This means that this pull requests also contains the remaining
> > 2.0.11 patches...
> 
> I haven't dropped them.  I'll be merging them for 2.6.25.  The patches
> that got merged were sent as fixes for 2.6.24.

Ah ok. Thanks.

Ivo

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

On Saturday 27 October 2007, Ivo van Doorn wrote:
> On Saturday 27 October 2007, John W. Linville wrote:
> > On Sat, Oct 27, 2007 at 01:34:34PM +0200, Ivo van Doorn wrote:
> > 
> > > Here is the 2.0.12 release of rt2x00.
> > > I noticed you only pulled 2 patches from the 2.0.11 release,
> > > and I don't know why you dropped the remaining patches.
> > > This means that this pull requests also contains the remaining
> > > 2.0.11 patches...
> > 
> > I haven't dropped them.  I'll be merging them for 2.6.25.  The patches
> > that got merged were sent as fixes for 2.6.24.
> 
> Ah ok. Thanks.

Btw, is there any branch in wireless-2.6 which in this case contains all
pending patches? (So those that also includes the patches which will
be merged for the next kernel).
I could use that branch to update rt2x00.git from.

Ivo

Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi John,

Here is the 2.0.14 release of rt2x00. Again lots of bugfixes,
and unfortunately we are still not there yet. I am afraid
rt2500usb and rt61pci are lost causes for the 2.6.24 release,
they are both broken, and I haven't figured out what is causing
this.

Next release will contain more interesting stuff, most of those
patches are already done, but due to testing and fine tuning I
have kept those patches back for this release. They primarily
cover basic support for virtual interfaces, led triggers, and some
first patches to make rt2x00lib support rt2800 (Yes, work on those
drivers has begun).

All indivual patches can also be found here:
http://kernel.org//pub/linux/kernel/people/ivd/rt2x00-2.0.14/

Ivo

---
The following changes since commit 2d0811f5ed506397d85792abfd8ef0983f4e8b7c:
  John W. Linville (1):
        fixup 'everything' after 'upstream-davem' rebase and patch modification

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/ upstream

Ivo van Doorn (12):
      rt2x00: Fix chipset debugfs file
      rt2x00: Always call ieee80211_stop_queue() when return NETDEV_TX_BUSY
      rt2x00: Only set the TBCN flag when the interface is configured to send beacons.
      rt2x00: Store queue idx and entry idx in data_ring and data_entry
      rt2x00: Move start() and stop() handlers into rt2x00lib.c
      rt2x00: Put 802.11 data on 4 byte boundary
      rt2x00: Move packet filter flags
      rt2x00: Cleanup write_tx_desc() arguments
      rt2x00: Determine MY_BSS from descriptor
      rt2x00: Move init_txring and init_rxring into rt2x00lib
      rt2x00: Correctly initialize data and desc pointer
      rt2x00: Release rt2x00 2.0.14

 drivers/net/wireless/rt2x00/rt2400pci.c   |  102 +++++++--------------
 drivers/net/wireless/rt2x00/rt2500pci.c   |   88 ++++++------------
 drivers/net/wireless/rt2x00/rt2500usb.c   |   36 +++++---
 drivers/net/wireless/rt2x00/rt2x00.h      |   32 ++++---
 drivers/net/wireless/rt2x00/rt2x00debug.c |   13 +--
 drivers/net/wireless/rt2x00/rt2x00dev.c   |  142 ++++++++++++++++++++++++-----
 drivers/net/wireless/rt2x00/rt2x00lib.h   |    4 +-
 drivers/net/wireless/rt2x00/rt2x00mac.c   |   59 +++---------
 drivers/net/wireless/rt2x00/rt2x00pci.c   |   28 ++++--
 drivers/net/wireless/rt2x00/rt2x00ring.h  |   13 +++
 drivers/net/wireless/rt2x00/rt2x00usb.c   |   87 ++++++++----------
 drivers/net/wireless/rt2x00/rt2x00usb.h   |    5 +-
 drivers/net/wireless/rt2x00/rt61pci.c     |  114 +++++++++---------------
 drivers/net/wireless/rt2x00/rt73usb.c     |   35 ++++---
 14 files changed, 378 insertions(+), 380 deletions(-)

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Will Dyson]

On Jan 6, 2008 5:37 PM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> Hi John,
>
> Here is the 2.0.14 release of rt2x00. Again lots of bugfixes,
> and unfortunately we are still not there yet. I am afraid
> rt2500usb and rt61pci are lost causes for the 2.6.24 release,
> they are both broken, and I haven't figured out what is causing
> this.

Hi Ivo,

Sorry to be out of the loop, but what is wrong with rt61pci? It works
really really well for me, using John's "everything" branch.

Hmm. Looking at Linus's tree, I can see that rt61pci is missing at
least 1 critical fix from Mattias Nissler that has been in
wireless-2.6 for a long time now.

rt2x00: Allow rt61 to catch up after a missing tx report

I'd be pretty disappointed if we released 2.6.24 without this. It is a
simple fix for a really obnoxious problem (although one that triggers
rarely on my hardware).

There are also a bunch of antenna selection fixes that never went
upstream. These are required for my card to operate well at rates
greater than 1Mbit, even when fairly close to the AP.

But aside from these issues, the latest 2.6.24-rc7 seems ok for me. My
testing of it is somewhat limited, due to the terrible performance.
But I can associate, browse the web and run iperf tests.

-- 
Will Dyson

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[John W. Linville]

On Thu, Jan 10, 2008 at 06:52:40AM -0500, Will Dyson wrote:

> Hmm. Looking at Linus's tree, I can see that rt61pci is missing at
> least 1 critical fix from Mattias Nissler that has been in
> wireless-2.6 for a long time now.
> 
> rt2x00: Allow rt61 to catch up after a missing tx report
> 
> I'd be pretty disappointed if we released 2.6.24 without this. It is a
> simple fix for a really obnoxious problem (although one that triggers
> rarely on my hardware).

This one can be cherry-picked fairly easily for 2.6.24.  Ivo, any
reason not to do that?
 
> There are also a bunch of antenna selection fixes that never went
> upstream. These are required for my card to operate well at rates
> greater than 1Mbit, even when fairly close to the AP.

Can you identify specific patches?  If so I can evaluate whether they
apply easily to 2.6.24 or if they need significant rework.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

On Thursday 10 January 2008, John W. Linville wrote:
> On Thu, Jan 10, 2008 at 06:52:40AM -0500, Will Dyson wrote:
> 
> > Hmm. Looking at Linus's tree, I can see that rt61pci is missing at
> > least 1 critical fix from Mattias Nissler that has been in
> > wireless-2.6 for a long time now.
> > 
> > rt2x00: Allow rt61 to catch up after a missing tx report
> > 
> > I'd be pretty disappointed if we released 2.6.24 without this. It is a
> > simple fix for a really obnoxious problem (although one that triggers
> > rarely on my hardware).
> 
> This one can be cherry-picked fairly easily for 2.6.24.  Ivo, any
> reason not to do that?

Nope, if it can be merged into 2.6.24 easily it should indeed go upstream.

> > There are also a bunch of antenna selection fixes that never went
> > upstream. These are required for my card to operate well at rates
> > greater than 1Mbit, even when fairly close to the AP.
> 
> Can you identify specific patches?  If so I can evaluate whether they
> apply easily to 2.6.24 or if they need significant rework.

I'm afraid the antenna code concerns the antenna diversity which is quite
a lot of code. I'm not sure how easily it can be merged, but I expect it to
be somewhat troublesome.

Ivo

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Will Dyson]

On Jan 10, 2008 10:46 AM, John W. Linville <linville@tuxdriver.com> wrote:
> On Thu, Jan 10, 2008 at 06:52:40AM -0500, Will Dyson wrote:
> > There are also a bunch of antenna selection fixes that never went
> > upstream. These are required for my card to operate well at rates
> > greater than 1Mbit, even when fairly close to the AP.
>
> Can you identify specific patches?  If so I can evaluate whether they
> apply easily to 2.6.24 or if they need significant rework.

rt2x00: Rework rt61 antenna selection
(ca9aaeec2d36dd4a00fea6443c53e935cbfa59ef)

However, it definitely depends on

rt2x00: Split rt61/rt73 antenna selection into RX and TX antenna
(9da4cdaefb5e8e2e3be813d94ce7b401e60ff391)

This patch itself has further dependencies:
[PATCH] rt2x00: Correctly translate mac80211 antenna setup to rt2x00
[PATCH] rt2x00: Move quality statistics into seperate structure).

It looks fairly easy to merge around that last quality statistics
patch. But I am uncertain if it is a good idea. I can try it and post
the result if you are interested.

-- 
Will Dyson

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi,

> > Here is the 2.0.14 release of rt2x00. Again lots of bugfixes,
> > and unfortunately we are still not there yet. I am afraid
> > rt2500usb and rt61pci are lost causes for the 2.6.24 release,
> > they are both broken, and I haven't figured out what is causing
> > this.
> 
> Hi Ivo,
> 
> Sorry to be out of the loop, but what is wrong with rt61pci? It works
> really really well for me, using John's "everything" branch.

My tests indicate rt61pci is currently not working, I just did some regression
testing and it seems the 2.0.14 version is to blame. I still have to run git-bisect
to determine the exact patch that broke it.

Ivo

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Stefan Lippers-Hollmann]

Hi

On Donnerstag, 10. Januar 2008, Will Dyson wrote:
[...]
> Sorry to be out of the loop, but what is wrong with rt61pci? It works
> really really well for me, using John's "everything" branch.
> 
> Hmm. Looking at Linus's tree, I can see that rt61pci is missing at
> least 1 critical fix from Mattias Nissler that has been in
> wireless-2.6 for a long time now.
> 
> rt2x00: Allow rt61 to catch up after a missing tx report
> 
> I'd be pretty disappointed if we released 2.6.24 without this. It is a
> simple fix for a really obnoxious problem (although one that triggers
> rarely on my hardware).

The same goes for (which can be easily rediffed against linux-2.6):
	[PATCH 06/12] rt2x00: Put 802.11 data on 4 byte boundary
without it, at least rt61pci, rt73usb and rt2500usb (plain 
2.6.24-rc7-git2) trigger the well known:

WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-git2-slh64-smp-1 #1

Call Trace:
 <IRQ>  [<ffffffff80232e4a>] __wake_up_common+0x5a/0x90
 [<ffffffff881fed9e>] :mac80211:__ieee80211_rx+0xbde/0xd00
 [<ffffffff880cb3e6>] :ehci_hcd:ehci_work+0x5d6/0x8e0
 [<ffffffff881f028b>] :mac80211:ieee80211_tasklet_handler+0xbb/0x120
 [<ffffffff80243507>] tasklet_action+0x47/0xb0
 [<ffffffff80243415>] __do_softirq+0x75/0xe0
 [<ffffffff8020d62c>] call_softirq+0x1c/0x30
 [<ffffffff8020f9f5>] do_softirq+0x35/0x90
 [<ffffffff802432a6>] irq_exit+0x96/0xa0
 [<ffffffff8020fad0>] do_IRQ+0x80/0x100
 [<ffffffff8020af60>] default_idle+0x0/0x40
 [<ffffffff8020af60>] default_idle+0x0/0x40
 [<ffffffff8020c981>] ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff80220e60>] lapic_next_event+0x0/0x10
 [<ffffffff8020af89>] default_idle+0x29/0x40
 [<ffffffff8020b00f>] cpu_idle+0x6f/0xe0

> There are also a bunch of antenna selection fixes that never went
> upstream. These are required for my card to operate well at rates
> greater than 1Mbit, even when fairly close to the AP.
> 
> But aside from these issues, the latest 2.6.24-rc7 seems ok for me. My
> testing of it is somewhat limited, due to the terrible performance.
> But I can associate, browse the web and run iperf tests.

I can just agree to this statement, rt73usb works really well (at steady 
~2.4 MB/s) and rt61pci is the first driver to actually work at all (yes, 
the same performance issues, but rt61-legacy freezes using wpa2psk; 
rt2500usb seems to have more problems).

All tests based on plain 2.6.24-rc7-git2 (amd64 and wpa2psk/ CCMP) + the 
following patches:
- [PATCH 06/12] rt2x00: Put 802.11 data on 4 byte boundary
- [PATCH] rt2x00: Corectly initialize rt2500usb MAC

Thanks a lot
	Stefan Lippers-Hollmann

Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

Hi John,

Only 5 patches, but they do bump rt2x00 to a new version: 2.2.0
This series will add HW crypto support to rt2x00, by default it
has been enabled for rt61pci and rt73usb.

rt2500usb has also been created, but currently does not work
since it requires different handling then rt61pci and rt73usb. Because
I am focussing on different areas in rt2x00 now, it will take some
time before I get back to rt2500usb HW crypto (if there are any volunteers
to take a shot at rt2500usb HW crypto, they are welcome).

rt2500pci supports HW crypto as well, but I won't implement it due
to the way it has to be enabled. It comes down to the fact that during
TX the key has to be provided, and after the encryption an interupt will
be raised after which the frame can be kicked to the air. In the RX path
the same happens, including that after RX the key has to be provided
as well. This will cause the number of IRQ events to double during HW
crypto, and several changes are required in mac80211 to make it possible.
Because of that I see no point in doing anything with it.

Ivo

----
The following changes since commit 2471b779e2f93d76bd4c041e4a8f5a27c859d7ce:
  John W. Linville (1):
        Revert "mac80211: add direct probe before association"

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git/ upstream

Ivo van Doorn (5):
      rt2x00: Implement HW encryption
      rt2x00: Implement HW encryption (rt61pci)
      rt2x00: Implement HW encryption (rt73usb)
      rt2x00: Gather channel information in structure
      rt2x00: Release rt2x00 2.2.0

 drivers/net/wireless/rt2x00/Kconfig        |    6 +
 drivers/net/wireless/rt2x00/Makefile       |    1 +
 drivers/net/wireless/rt2x00/rt2400pci.c    |   40 ++--
 drivers/net/wireless/rt2x00/rt2400pci.h    |   22 +--
 drivers/net/wireless/rt2x00/rt2500pci.c    |   39 +++--
 drivers/net/wireless/rt2x00/rt2500pci.h    |   17 +-
 drivers/net/wireless/rt2x00/rt2500usb.c    |   39 +++--
 drivers/net/wireless/rt2x00/rt2500usb.h    |   17 +-
 drivers/net/wireless/rt2x00/rt2x00.h       |   64 +++++-
 drivers/net/wireless/rt2x00/rt2x00config.c |    4 +
 drivers/net/wireless/rt2x00/rt2x00crypto.c |  215 +++++++++++++++++++
 drivers/net/wireless/rt2x00/rt2x00debug.c  |   97 +++++++++
 drivers/net/wireless/rt2x00/rt2x00dev.c    |   48 +++--
 drivers/net/wireless/rt2x00/rt2x00lib.h    |   47 ++++
 drivers/net/wireless/rt2x00/rt2x00mac.c    |  110 +++++++++-
 drivers/net/wireless/rt2x00/rt2x00queue.c  |   81 +++++++-
 drivers/net/wireless/rt2x00/rt2x00queue.h  |   73 ++++++-
 drivers/net/wireless/rt2x00/rt2x00reg.h    |   19 ++-
 drivers/net/wireless/rt2x00/rt61pci.c      |  298 ++++++++++++++++++++++++--
 drivers/net/wireless/rt2x00/rt61pci.h      |   38 ++--
 drivers/net/wireless/rt2x00/rt73usb.c      |  314 +++++++++++++++++++++++++---
 drivers/net/wireless/rt2x00/rt73usb.h      |   38 ++--
 22 files changed, 1418 insertions(+), 209 deletions(-)
 create mode 100644 drivers/net/wireless/rt2x00/rt2x00crypto.c

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Will Dyson]

On Mon, Aug 4, 2008 at 10:36 AM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> Hi John,
>
> Only 5 patches, but they do bump rt2x00 to a new version: 2.2.0
> This series will add HW crypto support to rt2x00, by default it
> has been enabled for rt61pci and rt73usb.

Seems to work well on my rt61pci card!

In fact, it reports a higher link quality (and maintains a higher
bitrate) than the version in current wireless-testing. The quality
report also fluctuates less than previously. This is consistent over a
few hours of testing with streaming PCM audio.

I do get a lockdep warning when bringing up the device, however.

=============================================
[ INFO: possible recursive locking detected ]
2.6.27-rc1-rt2-wl #1
---------------------------------------------
rt61pci/4405 is trying to acquire lock:
 (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
ieee80211_scan_completed+0x172/0x320 [mac80211]

but task is already holding lock:
 (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
ieee80211_scan_completed+0x172/0x320 [mac80211]

other info that might help us debug this:
3 locks held by rt61pci/4405:
 #0:  ((name)){--..}, at: [<ffffffff80250741>] run_workqueue+0xa1/0x230
 #1:  (&(&local->scan_work)->work){--..}, at: [<ffffffff80250741>]
run_workqueue+0xa1/0x230
 #2:  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
ieee80211_scan_completed+0x172/0x320 [mac80211]

stack backtrace:
Pid: 4405, comm: rt61pci Not tainted 2.6.27-rc1-rt2-wl #1

Call Trace:
 [<ffffffff802657ac>] __lock_acquire+0xb1c/0x12d0
 [<ffffffff8024939e>] ? __mod_timer+0xbe/0xe0
 [<ffffffff80265fb9>] lock_acquire+0x59/0x80
 [<ffffffffa014cc52>] ? ieee80211_scan_completed+0x172/0x320 [mac80211]
 [<ffffffff8055e5d4>] _spin_lock+0x34/0x50
 [<ffffffffa014cc52>] ieee80211_scan_completed+0x172/0x320 [mac80211]
 [<ffffffffa014d0bb>] ieee80211_sta_scan_work+0x8b/0x210 [mac80211]
 [<ffffffffa014d030>] ? ieee80211_sta_scan_work+0x0/0x210 [mac80211]
 [<ffffffffa014d030>] ? ieee80211_sta_scan_work+0x0/0x210 [mac80211]
 [<ffffffff8025078b>] run_workqueue+0xeb/0x230
 [<ffffffff80250977>] worker_thread+0xa7/0x120
 [<ffffffff80254f30>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff802508d0>] ? worker_thread+0x0/0x120
 [<ffffffff80254b89>] kthread+0x49/0x80
 [<ffffffff8020d5b9>] child_rip+0xa/0x11
 [<ffffffff8020cbc3>] ? restore_args+0x0/0x30
 [<ffffffff80254b40>] ? kthread+0x0/0x80
 [<ffffffff8020d5af>] ? child_rip+0x0/0x11


-- 
Will Dyson

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Larry Finger]

Will Dyson wrote:
> On Mon, Aug 4, 2008 at 10:36 AM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
>> Hi John,
>>
>> Only 5 patches, but they do bump rt2x00 to a new version: 2.2.0
>> This series will add HW crypto support to rt2x00, by default it
>> has been enabled for rt61pci and rt73usb.
> 
> Seems to work well on my rt61pci card!
> 
> In fact, it reports a higher link quality (and maintains a higher
> bitrate) than the version in current wireless-testing. The quality
> report also fluctuates less than previously. This is consistent over a
> few hours of testing with streaming PCM audio.
> 
> I do get a lockdep warning when bringing up the device, however.
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.27-rc1-rt2-wl #1
> ---------------------------------------------
> rt61pci/4405 is trying to acquire lock:
>  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> ieee80211_scan_completed+0x172/0x320 [mac80211]
> 
> but task is already holding lock:
>  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> ieee80211_scan_completed+0x172/0x320 [mac80211]
> 

I get that same lockdep warning when using the mainline kernel with b43. It 
doesn't seem to cause any problems.

Larry

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

On Tuesday 05 August 2008, Larry Finger wrote:
> Will Dyson wrote:
> > On Mon, Aug 4, 2008 at 10:36 AM, Ivo van Doorn <ivdoorn@gmail.com> wrote:
> >> Hi John,
> >>
> >> Only 5 patches, but they do bump rt2x00 to a new version: 2.2.0
> >> This series will add HW crypto support to rt2x00, by default it
> >> has been enabled for rt61pci and rt73usb.
> > 
> > Seems to work well on my rt61pci card!
> > 
> > In fact, it reports a higher link quality (and maintains a higher
> > bitrate) than the version in current wireless-testing. The quality
> > report also fluctuates less than previously. This is consistent over a
> > few hours of testing with streaming PCM audio.
> > 
> > I do get a lockdep warning when bringing up the device, however.
> > 
> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 2.6.27-rc1-rt2-wl #1
> > ---------------------------------------------
> > rt61pci/4405 is trying to acquire lock:
> >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > 
> > but task is already holding lock:
> >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > 
> 
> I get that same lockdep warning when using the mainline kernel with b43. It 
> doesn't seem to cause any problems.

Sounds like a mac80211 bug then, can't find something obvious at first glance,
but perhaps Johannes has an idea?

Ivo

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On Tue, 2008-08-05 at 20:30 +0200, Ivo van Doorn wrote:

> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.27-rc1-rt2-wl #1
> > > ---------------------------------------------
> > > rt61pci/4405 is trying to acquire lock:
> > >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > > 
> > > but task is already holding lock:
> > >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > > 
> > 
> > I get that same lockdep warning when using the mainline kernel with b43. It 
> > doesn't seem to cause any problems.
> 
> Sounds like a mac80211 bug then, can't find something obvious at first glance,
> but perhaps Johannes has an idea?

I ignore everything with the TX lock in it because those have been
wrongly annotated in a bunch of versions, including -rc1 afaik.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Rt2400-devel] Please pull 'upstream' branch of rt2x00

[Ivo van Doorn]

On Tuesday 05 August 2008, Johannes Berg wrote:
> On Tue, 2008-08-05 at 20:30 +0200, Ivo van Doorn wrote:
> 
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 2.6.27-rc1-rt2-wl #1
> > > > ---------------------------------------------
> > > > rt61pci/4405 is trying to acquire lock:
> > > >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > > > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > > > 
> > > > but task is already holding lock:
> > > >  (_xmit_IEEE80211#2){-...}, at: [<ffffffffa014cc52>]
> > > > ieee80211_scan_completed+0x172/0x320 [mac80211]
> > > > 
> > > 
> > > I get that same lockdep warning when using the mainline kernel with b43. It 
> > > doesn't seem to cause any problems.
> > 
> > Sounds like a mac80211 bug then, can't find something obvious at first glance,
> > but perhaps Johannes has an idea?
> 
> I ignore everything with the TX lock in it because those have been
> wrongly annotated in a bunch of versions, including -rc1 afaik.

Heh ok. :)

Ivo