rt2x00: Increase REGISTER_BUSY_COUNT

From: RA-Jay Hung <[email protected]>

When send out skb data to mac80211, orignal code will cause mac80211 unaligned access, so modify code to make mac80211 can natural access.

Signed-off-by RA-Jay Hung <[email protected]>

Signed-off-by Ivo van Doorn <[email protected]>

---
 drivers/net/wireless/rt2x00/rt2x00queue.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

drivers/net/wireless/rt2x00/rt2x00queue.c +4 -2

index dc54317..a3d79c7 100644
@@ -204,8 +204,10 @@ void rt2x00queue_remove_l2pad(struct sk_buff *skb, unsigned int header_length)
 	if (!l2pad)
 		return;
 
-	memmove(skb->data + l2pad, skb->data, header_length);
-	skb_pull(skb, l2pad);
+	memmove(skb->data + header_length, skb->data + header_length + l2pad,
+				skb->len - header_length - l2pad);
+
+	skb_trim(skb, skb->len - l2pad);
 }
 
 static void rt2x00queue_create_tx_descriptor_seq(struct queue_entry *entry,

Am Samstag 13 November 2010 schrieb Ivo van Doorn:

Quoted 4 lines

From: RA-Jay Hung <[email protected]>

When send out skb data to mac80211, orignal code will cause mac80211 unaligned access, so modify code to make mac80211 can natural access.

And this introduces the same panic again :(

The problem is the following:

We don't pass the skb in the same state back to mac80211 as we got it.

When inserting the l2pad we're moving the header and thus reduce headroom. This patch modifies the bahavior during l2pad removal to not move the header back into its old position but instead moves the payload. Thus the skb keeps the reduced headroom. If this skb gets requeued into rt2x00 (which can happen when the frame wasn't acked and the according STA is known to e in powersave mode) the header and payload get aligned again further reducing headroom which results in a too small headroom for the TXWI and thus a skb_under_panic.

Quoted 7 lines

When inserting the l2pad we're moving the header and thus reduce headroom. This patch modifies the bahavior during l2pad removal to not move the header back into its old position but instead moves the payload. Thus the skb keeps the reduced headroom. If this skb gets requeued into rt2x00 (which can happen when the frame wasn't acked and the according STA is known to e in powersave mode) the header and payload get aligned again further reducing headroom which results in a too small headroom for the TXWI and thus a skb_under_panic.

Hmm, John merged that patch already. However, I would prefer if it would get reverted due to the occasional panics in AP mode.

Jay, I didn't notice any performance degradation on MIPS, on which architecture did you test?

Jay, Ivo, any objections against reverting this one?

Quoted 11 lines

Quoted 7 lines

When inserting the l2pad we're moving the header and thus reduce headroom. This patch modifies the bahavior during l2pad removal to not move the header back into its old position but instead moves the payload. Thus the skb keeps the reduced headroom. If this skb gets requeued into rt2x00 (which can happen when the frame wasn't acked and the according STA is known to e in powersave mode) the header and payload get aligned again further reducing headroom which results in a too small headroom for the TXWI and thus a skb_under_panic.

Hmm, John merged that patch already. However, I would prefer if it would get reverted due to the occasional panics in AP mode.

Quoted 2 lines

Jay, I didn't notice any performance degradation on MIPS, on which architecture did you test?

My test environment as below
Architecture is AMD Athlon 64 X2 Dual Core, and use rt3070 to test throughput. Before not patch code, the throughput just only 5, 6M, but after patch, throughput can achieve about 40M on open air. How about your test?

Quoted 1 line

Jay, Ivo, any objections against reverting this one?

I agree to revert this one because this will cause tool small headroom of your mention. We need to supply another patch when resolve all issue. Thanks.

John, should I send a follow-up (with a nice description why it this is needed) or are you simply reverting this one?

Quoted 2 lines · Helmut Schaa

John, should I send a follow-up (with a nice description why it this is needed) or are you simply reverting this one?

Is there no chance for a fix in short order?

Quoted 6 lines · John W. Linville

Quoted 2 lines · Helmut Schaa

John, should I send a follow-up (with a nice description why it this is needed) or are you simply reverting this one?

Is there no chance for a fix in short order?

I may have an idea on how we can fix this, without incurring the performance penalty.

Basic idea is to no longer work on the original skb that mac80211 supplied us, but to
use a copy of that skb. This would prevent us from having to undo any changes we did,
as we can simply return the original skb to mac80211 (which wasn't modified in the first
place).
I'm not sure how this would impact performance, but it would allow us a lot less copying
around to undo the changes done before uploading to the HW.

However, I won't be able to look into that opportunity before the weekend.

Helmut, can you wait that long and hold off reverting until then?

Am Mittwoch 17 November 2010 schrieb Gertjan van Wingerde:

Quoted 8 lines

Quoted 6 lines · John W. Linville

Quoted 2 lines · Helmut Schaa

John, should I send a follow-up (with a nice description why it this is needed) or are you simply reverting this one?

Is there no chance for a fix in short order?

I don't have a clever idea on how to fix that without reverting this commit. IMO this patch is just not correct as it passes the skb back to mac80211 with reduced headroom (due to the header & payload alignment) which causes trouble when mac80211 requeues the frame. Of course just requesting 4 additional bytes headroom would "fix" the symptoms but sounds like a hack to me.

Quoted 2 lines

I may have an idea on how we can fix this, without incurring the performance penalty.

I'm still not convinced that this is really the root cause for the performance issues Jay noticed. AFAIK mac80211 doesn't access the payload anymore when reporting the frame back (with some exceptions like monitor interfaces).

Jay, could you please run a few more performance tests with and without this patch to track down if this issue is really the cause for the performance degradation?

Quoted 10 lines

Basic idea is to no longer work on the original skb that mac80211 supplied us, but to
use a copy of that skb. This would prevent us from having to undo any changes we did,
as we can simply return the original skb to mac80211 (which wasn't modified in the first
place).
I'm not sure how this would impact performance, but it would allow us a lot less copying
around to undo the changes done before uploading to the HW.

But cloning the skb would double the amount of memory needed to transmit each frame. Not sure though if that behaves better or not. Might be worth a try.

Am Mittwoch 17 November 2010 schrieb Gertjan van Wingerde:

Quoted 8 lines

Quoted 6 lines · John W. Linville

Quoted 2 lines · Helmut Schaa

John, should I send a follow-up (with a nice description why it this is needed) or are you simply reverting this one?

Is there no chance for a fix in short order?

I don't have a clever idea on how to fix that without reverting this commit. IMO this patch is just not correct as it passes the skb back to mac80211 with reduced headroom (due to the header & payload alignment) which causes trouble when mac80211 requeues the frame. Of course just requesting 4 additional bytes headroom would "fix" the symptoms but sounds like a hack to me.

Quoted 2 lines

I may have an idea on how we can fix this, without incurring the performance penalty.

I'm still not convinced that this is really the root cause for the performance issues Jay noticed. AFAIK mac80211 doesn't access the payload anymore when reporting the frame back (with some exceptions like monitor interfaces).

Jay, could you please run a few more performance tests with and without this patch to track down if this issue is really the cause for the performance degradation?

Quoted 10 lines

Basic idea is to no longer work on the original skb that mac80211 supplied us, but to
use a copy of that skb. This would prevent us from having to undo any changes we did,
as we can simply return the original skb to mac80211 (which wasn't modified in the first
place).
I'm not sure how this would impact performance, but it would allow us a lot less copying
around to undo the changes done before uploading to the HW.

But cloning the skb would double the amount of memory needed to transmit each frame. Not sure though if that behaves better or not. Might be worth a try.

Quoted 3 lines

However, I won't be able to look into that opportunity before the weekend.

Helmut, can you wait that long and hold off reverting until then?

From 52beaf9b38475520bfdc2eea920fc7f45993bba4 Mon Sep 17 00:00:00 2001

Quoted 3 lines

Jay, could you please run a few more performance tests with and without this patch to track down if this issue is really the cause for the performance degradation?

Quoted 16 lines

Quoted 10 lines

Basic idea is to no longer work on the original skb that mac80211 supplied us, but to
use a copy of that skb. This would prevent us from having to undo any changes we did,
as we can simply return the original skb to mac80211 (which wasn't modified in the first
place).
I'm not sure how this would impact performance, but it would allow us a lot less copying
around to undo the changes done before uploading to the HW.

But cloning the skb would double the amount of memory needed to transmit each frame. Not sure though if that behaves better or not. Might be worth a try.

Quoted 2 lines

However, I won't be able to look into that opportunity before the weekend.

Quoted 2 lines

Quoted 1 line

Helmut, can you wait that long and hold off reverting until then?

OK. Find attached the patch I cooked up. AFAICS the driver still works correctly, but unfortunately I am unable to test performance and throughput of the driver with this patch.

Jay and Helmut, can you test this patch before I submit it?

Hi,

Quoted 3 lines

Quoted 3 lines

Jay, could you please run a few more performance tests with and without this patch to track down if this issue is really the cause for the performance degradation?

I check sniffer and mac80211 code, I think bad TX throughput should be my environment has a lot APs and more packets will collides because of without protection in TX direction. So the patch is not related to this issue. Helmut, We can revert this patch. Sorry for inconvenience.

Quoted 16 lines

Quoted 16 lines

Quoted 10 lines

Basic idea is to no longer work on the original skb that mac80211 supplied us, but to
use a copy of that skb. This would prevent us from having to undo any changes we did,
as we can simply return the original skb to mac80211 (which wasn't modified in the first
place).
I'm not sure how this would impact performance, but it would allow us a lot less copying
around to undo the changes done before uploading to the HW.

But cloning the skb would double the amount of memory needed to transmit each frame. Not sure though if that behaves better or not. Might be worth a try.

Quoted 2 lines

However, I won't be able to look into that opportunity before the weekend.

Quoted 9 lines

Quoted 2 lines

Quoted 1 line

Helmut, can you wait that long and hold off reverting until then?

OK. Find attached the patch I cooked up. AFAICS the driver still works correctly, but unfortunately I am unable to test performance and throughput of the driver with this patch.

Jay and Helmut, can you test this patch before I submit it?

I think original code should recover the original skb state, so I think we do not need to copy again to send back to mac80211, and one more thing. Could you submit below patch you send us before to rt2x00.git. I think it is more correct in payload = 0 case.

 void rt2x00queue_remove_l2pad(struct sk_buff *skb, unsigned int header_length) {
-       unsigned int l2pad = L2PAD_SIZE(header_length);
+       unsigned int payload_length = skb->len - header_length;
+       unsigned int l2pad = payload_length ? L2PAD_SIZE(header_length) : 0;

       if (!l2pad)
               return;

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

Jay, could you please run a few more performance tests with and without this patch to track down if this issue is really the cause for the performance degradation?

I check sniffer and mac80211 code, I think bad TX throughput should be my environment has a lot APs and more packets will collides because of without protection in TX direction. So the patch is not related to this issue. Helmut, We can revert this patch. Sorry for inconvenience.

Quoted 15 lines

Quoted 6 lines

OK. Find attached the patch I cooked up. AFAICS the driver still works correctly, but unfortunately I am unable to test performance and throughput of the driver with this patch.

Jay and Helmut, can you test this patch before I submit it?

I think original code should recover the original skb state, so I think we do not need to copy again to send back to mac80211, and one more thing. Could you submit below patch you send us before to rt2x00.git. I think it is more correct in payload = 0 case.

void rt2x00queue_remove_l2pad(struct sk_buff *skb, unsigned int header_length) {

(quoted diff) +2 -1

-       unsigned int l2pad = L2PAD_SIZE(header_length);
+       unsigned int payload_length = skb->len - header_length;
+       unsigned int l2pad = payload_length ? L2PAD_SIZE(header_length) : 0;

Quoted 3 lines

       if (!l2pad)
               return;

OK. Indeed if you feel we can simply revert the patch then that will be better. I'll send a patch tonight that reverts it together with the update update.

From: RA-Jay Hung <[email protected]>

Put the assignment of header_length after pull out extra tx headroom

Signed-off-by RA-Jay Hung <[email protected]>

Signed-off-by Ivo van Doorn <[email protected]>

---
 drivers/net/wireless/rt2x00/rt2x00dev.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

drivers/net/wireless/rt2x00/rt2x00dev.c +6 -2

index 3afa2a3..c879f9a 100644
@@ -250,10 +250,9 @@ void rt2x00lib_txdone(struct queue_entry *entry,
 	struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
 	struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
 	enum data_queue_qid qid = skb_get_queue_mapping(entry->skb);
-	unsigned int header_length = ieee80211_get_hdrlen_from_skb(entry->skb);
+	unsigned int header_length, i;
 	u8 rate_idx, rate_flags, retry_rates;
 	u8 skbdesc_flags = skbdesc->flags;
-	unsigned int i;
 	bool success;
 
 	/*

@@ -272,6 +271,11 @@ void rt2x00lib_txdone(struct queue_entry *entry,
 	skbdesc->flags &= ~SKBDESC_DESC_IN_SKB;
 
 	/*
+	 * Determine the length of 802.11 header.
+	 */
+	header_length = ieee80211_get_hdrlen_from_skb(entry->skb);
+
+	/*
 	 * Remove L2 padding which was added during
 	 */
 	if (test_bit(DRIVER_REQUIRE_L2PAD, &rt2x00dev->flags))

Signed-off-by RA-Jay Hung <[email protected]>

Signed-off-by Ivo van Doorn <[email protected]>

These patches appear to have finally brought some life in to the rt307x chips in terms of stability and usability. There are no more duplicate (very few) or lost packets and overall, the driver is improved immensely, however the latency is increased compared to the STA driver. Pinging my gateway with STA yields about 2-3ms average, whereas the rt2800usb is about 8-9ms. The throughput is also about 20% less. Do you think this can be corrected at some point and do you anticipate further improvements in this direction?

These patches appear to have finally brought some life in to the rt307x chips in terms of stability and usability. There are no more duplicate (very few) or lost packets and overall, the driver is improved immensely, however the latency is increased compared to the STA driver. Pinging my gateway with STA yields about 2-3ms average, whereas the rt2800usb is about 8-9ms. The throughput is also about 20% less.

Quoted 7 lines

These patches appear to have finally brought some life in to the rt307x chips in terms of stability and usability. There are no more duplicate (very few) or lost packets and overall, the driver is improved immensely, however the latency is increased compared to the STA driver. Pinging my gateway with STA yields about 2-3ms average, whereas the rt2800usb is about 8-9ms. The throughput is also about 20% less.

I'm runnung rt2800usb (RT3070) in AP mode, and when pinging from the client I get:

[12631.727724] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[12632.727451] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[12638.728027] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 2 status timed out, invoke forced tx handler
[12674.732633] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[12676.732855] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[12679.733581] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
[12779.745991] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler

etc.

I wonder why it is using TX queue 2? Isn't this QID_AC_VI, i.e. it should only be used when some programs uses setsockopt SO_PRIORITY to request QoS for video data?

Lokking through the code, in rt2x00mac_tx():

	enum data_queue_qid qid = skb_get_queue_mapping(skb);

is passed to rt2x00queue_get_queue() which uses
enum data_queue_qid has 2 == QID_AC_VI, but net/core/dev.c dev_pick_tx() calls skb_set_queue_mapping() with 2 == BE
(from ieee802_1d_to_ac, return by ieee80211_netdev_select_queue())

Maybe I'm just confused?

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 6 lines

I wonder why it is using TX queue 2? Isn't this QID_AC_VI, i.e. it should only be used when some programs uses setsockopt SO_PRIORITY to request QoS for video data?

Quoted 8 lines

Lokking through the code, in rt2x00mac_tx():

	enum data_queue_qid qid = skb_get_queue_mapping(skb);

is passed to rt2x00queue_get_queue() which uses
enum data_queue_qid has 2 == QID_AC_VI, but net/core/dev.c dev_pick_tx() calls skb_set_queue_mapping() with 2 == BE
(from ieee802_1d_to_ac, return by ieee80211_netdev_select_queue())

Maybe I'm just confused?

Yep, it is indeed confusing. If you compiled rt2x00 with debug output have a look at the queue setup in dmesg:

[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.

As you can see queue 2 gets the parameters for AC_BE assigned whereas queue 0 gets AC_VO assigned. So the naming within rt2x00 is not consitent with the numbering within mac80211. However, since we configure the queue parameters this should really just be a naming issue.

And btw. queue 0 is used for managment frames as well.

Quoted 24 lines

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 6 lines

I wonder why it is using TX queue 2? Isn't this QID_AC_VI, i.e. it should only be used when some programs uses setsockopt SO_PRIORITY to request QoS for video data?

Quoted 8 lines

Lokking through the code, in rt2x00mac_tx():

	enum data_queue_qid qid = skb_get_queue_mapping(skb);

is passed to rt2x00queue_get_queue() which uses
enum data_queue_qid has 2 == QID_AC_VI, but net/core/dev.c dev_pick_tx() calls skb_set_queue_mapping() with 2 == BE
(from ieee802_1d_to_ac, return by ieee80211_netdev_select_queue())

Maybe I'm just confused?

Yep, it is indeed confusing. If you compiled rt2x00 with debug output have a look at the queue setup in dmesg:

[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0.
[   47.590000] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0.

Quoted 4 lines

As you can see queue 2 gets the parameters for AC_BE assigned whereas queue 0 gets AC_VO assigned. So the naming within rt2x00 is not consitent with the numbering within mac80211. However, since we configure the queue parameters this should really just be a naming issue.

Hm, yes, rt2x00mac_conf_tx() has the same issue that it calls rt2x00queue_get_queue() with an argument which is a mac80211 AC, but expects an enum data_queue_qid. So one could says one bug cancels the other out.

Quoted 1 line

And btw. queue 0 is used for managment frames as well.

Queue 0 means QID_AC_BE? Or AC_VI?

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 5 lines

Hm, yes, rt2x00mac_conf_tx() has the same issue that it calls rt2x00queue_get_queue() with an argument which is a mac80211 AC, but expects an enum data_queue_qid. So one could says one bug cancels the other out.

Right. We could of course add a mac80211-queue <-> rt2x00-queue mapping in the appropriate places or rename the QID_* identifiers accordingly. Not sure if it's worth it ...

Quoted 3 lines

Quoted 1 line

And btw. queue 0 is used for managment frames as well.

Queue 0 means QID_AC_BE? Or AC_VI?

It's AC_VO.

Quoted 7 lines

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 5 lines

Hm, yes, rt2x00mac_conf_tx() has the same issue that it calls rt2x00queue_get_queue() with an argument which is a mac80211 AC, but expects an enum data_queue_qid. So one could says one bug cancels the other out.

Quoted 3 lines

Right. We could of course add a mac80211-queue <-> rt2x00-queue mapping in the appropriate places or rename the QID_* identifiers accordingly. Not sure if it's worth it ...

Hm, reducing confusion enhances maintainability.

Quoted 7 lines · Helmut Schaa

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 6 lines · Helmut Schaa

Quoted 4 lines

Right. We could of course add a mac80211-queue <-> rt2x00-queue mapping in the appropriate places or rename the QID_* identifiers accordingly. Not sure if it's worth it ...

Quoted 4 lines

Quoted 1 line

Hm, reducing confusion enhances maintainability.

I fully agree. I just meant that there are more severe issues in rt2x00 I plan to work on. But feel free to send a patch :)

But is this a mapping problem, or naming problem? Queue 0 is supposed to be the queue with highest priority right?
So that would inficate a naming problem only

Quoted 8 lines · Helmut Schaa

Quoted 7 lines

Am Dienstag 16 November 2010 schrieb Johannes Stezenbach:

Quoted 6 lines · Helmut Schaa

Quoted 4 lines

Right. We could of course add a mac80211-queue <-> rt2x00-queue mapping in the appropriate places or rename the QID_* identifiers accordingly. Not sure if it's worth it ...

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Hm, reducing confusion enhances maintainability.

I fully agree. I just meant that there are more severe issues in rt2x00 I plan to work on. But feel free to send a patch :)

But is this a mapping problem, or naming problem? Queue 0 is supposed to be the queue with highest priority right?
So that would inficate a naming problem only

The main source of confusion for me is the implicit conversion between the queue number 0..3 used by the mac80211 layer and the enum data_queue_qid used by rt2x00, which assignes a different _meaning_ to the numbers.  IMHO the enum values should be rearranged.  Maybe a comment would be good, too.

And I'm still confused.  There is code like e.g. rt2400pci_kick_tx_queue() which tests against QID_AC_BE etc., but does it really the kick the right queue?
IOW, where does the qid passed to it ultimately come from?

 rt2x00mac_tx():   qid = skb_get_queue_mapping(skb);  i.e. 2 for AC_BE -> rt2x00queue_get_queue()  returns queue #2 which has queue->qid == QID_AC_VI -> rt2x00queue_write_tx_frame()
     -> rt2400pci_kick_tx_queue() is called with qid == QID_AC_VI

However what I meant, is when skb->priority is 0, must the highest or the lowest priority be assumed? If it is the highest priority, then rt2x00 uses the incorrect
naming, and all what is needed is to rename the fields everywhere in rt2x00. However is it is the lowest priority, then the naming is correct, and we must change the meaning, in which case we must rename and meaning.

Quoted 6 lines · Ivo Van Doorn

However what I meant, is when skb->priority is 0, must the highest or the lowest priority be assumed? If it is the highest priority, then rt2x00 uses the incorrect
naming, and all what is needed is to rename the fields everywhere in rt2x00. However is it is the lowest priority, then the naming is correct, and we must change the meaning, in which case we must rename and meaning.

I'm working on this:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/012-mac80211-ac-defines.patch

0 is highest prio (AC_VO)

From: Gertjan van Wingerde <[email protected]>

General clean up of the Kconfig part for RT28XX devices.
Also remove the indications of non functional support for rt27xx/rt28xx/rt30xx devices, as this is no longer true. They just work fine.
Finally, remove the experimental indications for rt27xx/rt28xx/rt30xx devices as that is no longer true. Keep the experimental indications for rt33xx/rt35xx devices, though.

Signed-off-by Gertjan van Wingerde <[email protected]>

Acked-by Helmut Schaa <[email protected]>

Signed-off-by Ivo van Doorn <[email protected]>

---
 drivers/net/wireless/rt2x00/Kconfig |   47 ++++++++++++++--------------------

 1 files changed, 19 insertions(+), 28 deletions(-)

drivers/net/wireless/rt2x00/Kconfig +0 -0

index f0f0152..f2be1d3 100644
@@ -154,30 +150,24 @@ config RT2800USB

       select RT2X00_LIB_CRYPTO
       select CRC_CCITT
       ---help---
-         This adds experimental support for rt2800 wireless chipset family.
+         This adds support for rt27xx/rt28xx wireless chipset family. Supported chips: RT2770, RT2870 & RT3070.

-         Known issues:
-         - support for RT2870 chips doesn't work with 802.11n APs yet
-         - support for RT3070 chips is non-functional at the moment -
         When compiled as a module, this driver will be called "rt2800usb.ko".

 if RT2800USB

 config RT2800USB_RT30XX
-       bool "rt2800usb - Include support for rt30xx (USB) devices"
+       bool "rt2800usb - Include support for rt30xx devices" default y
       ---help---
         This adds support for rt30xx wireless chipset family to the rt2800usb driver.
         Supported chips: RT3070, RT3071 & RT3072

-         Support for these devices is non-functional at the moment and is
-         intended for testers and developers.
-
 config RT2800USB_RT33XX
-       bool "rt2800usb - Include support for rt33xx (USB) devices"
+       bool "rt2800usb - Include support for rt33xx devices (EXPERIMENTAL)"
+       depends on EXPERIMENTAL
       default n
       ---help---
         This adds support for rt33xx wireless chipset family to the

IVD,

A minor nit: