[RFC][RFT][PATCH 0/5] ar9170: ar9170 driver

[RFC][RFT][PATCH 0/5] ar9170: ar9170 driver

[Christian Lamparter]

Johannes' ar9170 has been in development for a while.
However he is very busy pushing on the mac80211 stack...

I'll take a bite and try to help with ar9170 kernel inclusion.
before the fatal bit-rot claims a victim.

the diffstat:
 MAINTAINERS                          |    8
 drivers/net/wireless/Kconfig         |    1
 drivers/net/wireless/Makefile        |    1
 drivers/net/wireless/ar9170/Kconfig  |   23
 drivers/net/wireless/ar9170/Makefile |    6
 drivers/net/wireless/ar9170/ar9170.h |  177 ++++
 drivers/net/wireless/ar9170/cmd.c    |  118 ++
 drivers/net/wireless/ar9170/cmd.h    |   87 ++
 drivers/net/wireless/ar9170/eeprom.h |  179 ++++
 drivers/net/wireless/ar9170/hw.h     |  385 +++++++++
 drivers/net/wireless/ar9170/led.c    |  167 +++
 drivers/net/wireless/ar9170/mac.c    |  302 +++++++
 drivers/net/wireless/ar9170/main.c   | 1486 +++++++++++++++++++++++++++++++++++
 drivers/net/wireless/ar9170/phy.c    | 1223 ++++++++++++++++++++++++++++
 drivers/net/wireless/ar9170/usb.c    |  754 +++++++++++++++++
 drivers/net/wireless/ar9170/usb.h    |   80 +
 16 files changed, 4997 insertions(+)

obvious fact: that's nearly 5000 lines of code...

I really hope that you guys have a few comments and tips , so we hit 5k ;-)

Please give me some feedback and mmmmooore patches!
And don't forget to update the copyright boilerplate!

Enjoy!

[RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Christian Lamparter]

Based on the number of mails I got, this driver should be ready for inclusion.
So, this is probably the last RFC and the official patches will follow on
sunday (only if no one finds a bug that needs to be fixed ASAP.)

Changes:
	- enabled HW crypto acceleration (on by default)
	- report noise and signal levels in dBm
	- sniffer/promiscouous mode now works in BSS
	- LED code rework
	- fixed last remaining checkpatch.pl ERRORs

Features:
	- managed and (full) monitor mode
		(other modes may work too... but were not tested)
	- QoS 
	- tx status => automatic rate control
	- offload for ccmp, tkip & wep
	- programmable LEDs

Note: The whole patch series can be found in the linux-wireless archive.
e.g: http://marc.info/?l=linux-wireless&r=1&b=200903&w=2 

Regards,
	Chr

---
John what's your verdict? would you accept the driver in its current state?

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

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

Hello Christian!

> Based on the number of mails I got, this driver should be ready for
> inclusion.

ACK

> So, this is probably the last RFC and the official patches will follow on
> sunday (only if no one finds a bug that needs to be fixed ASAP.)

This is not same driver. Its much different, and I couldn't follow the changes in Johannes' git repository.

Today, if have implement rate control (the needed ieee80211_tx_status_irqsafe() calls) for the original code. Now after one hour this code already outdated. :/

In your code the implementation of it is not yet complete?

Regards
Alina

-- 
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt?
Jetzt absichern: https://homebanking.gmx.net/?mc=mail@footer.hb

[-- Attachment #2: rate_control.patch --]
[-- Type: text/x-patch, Size: 5498 bytes --]

diff --git a/ar9170.h b/ar9170.h
index 4ad272c..b65da25 100644
--- a/ar9170.h
+++ b/ar9170.h
@@ -70,6 +70,8 @@ enum ar9170_rf_init_mode {
 #define AR9170_MAX_RX_BUFFER_SIZE		8192
 #define AR9170_NUM_RX_URBS			16
 
+#define AR9170_MAX_TX_STATUS			10
+
 struct ar9170;
 
 struct ar9170_led {
@@ -102,9 +104,8 @@ struct ar9170 {
 	int readlen;
 	u8 *readbuf;
 
-	struct sk_buff *tx_status_queue_head;
-	struct sk_buff *tx_status_queue_tail;
 	spinlock_t tx_status_lock;
+	struct sk_buff_head tx_status_queue;
 
 	/* power calibration data */
 	u8 power_5G_leg[4];
diff --git a/hw.h b/hw.h
index 7eae0ea..4d6c69c 100644
--- a/hw.h
+++ b/hw.h
@@ -149,7 +149,7 @@ enum ar9170_cmd {
 #define AR9170_MAC_REG_FTF_ACK			BIT(29)
 #define AR9170_MAC_REG_FTF_CFE			BIT(30)
 #define AR9170_MAC_REG_FTF_CFE_ACK		BIT(31)
-#define AR9170_MAC_REG_FTF_DEFAULTS		0x0500ffff
+#define AR9170_MAC_REG_FTF_DEFAULTS		0x2500ffff
 
 #define AR9170_MAC_REG_RX_TOTAL			(AR9170_MAC_REG_BASE + 0x6A0)
 #define AR9170_MAC_REG_RX_CRC32			(AR9170_MAC_REG_BASE + 0x6A4)
diff --git a/main.c b/main.c
index 8a9ddf7..7319c20 100644
--- a/main.c
+++ b/main.c
@@ -220,6 +220,7 @@ static int ar9170_op_start(struct ieee80211_hw *hw)
 static void ar9170_op_stop(struct ieee80211_hw *hw)
 {
 	struct ar9170 *ar = hw->priv;
+	struct sk_buff *skb;
 
 	mutex_lock(&ar->mutex);
 
@@ -228,54 +229,53 @@ static void ar9170_op_stop(struct ieee80211_hw *hw)
 
 	ar->started = false;
 
-	mutex_unlock(&ar->mutex);
-}
+	while ((skb = skb_dequeue(&ar->tx_status_queue)))
+		dev_kfree_skb_any(skb);
 
-#if 0
-static inline void ar9170_add_tx_status_skb(struct ar9170 *ar,
-					    struct sk_buff *skb)
-{
-	skb->next = NULL;
-
-	if (ar->tx_status_queue_tail) {
-		ar->tx_status_queue_tail->next = skb;
-		ar->tx_status_queue_tail = skb;
-	} else {
-		ar->tx_status_queue_tail = skb;
-		ar->tx_status_queue_head = skb;
-	}
+	mutex_unlock(&ar->mutex);
 }
 
-static inline struct sk_buff *ar9170_get_tx_status_skb(struct ar9170 *ar)
+static void ar9170_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
+                             int ack_signal, bool success)
 {
-	struct sk_buff *skb;
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 
-	skb = ar->tx_status_queue_head;
+	ieee80211_tx_info_clear_status(info);
 
-	if (skb) {
-		ar->tx_status_queue_head = skb->next;
-		if (ar->tx_status_queue_tail == skb)
-			ar->tx_status_queue_tail = NULL;
-	}
+	if (success)
+		info->flags |= IEEE80211_TX_STAT_ACK;
+	info->status.ack_signal = ack_signal;
 
-	return skb;
+	ieee80211_tx_status_irqsafe(hw, skb);
 }
-#endif
 
 static void tx_urb_complete(struct urb *urb)
 {
-	struct sk_buff *skb = (void *)urb->context;
-/*
+	struct sk_buff *skb = (struct sk_buff *)urb->context;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-	struct ar9170 *ar = info->rate_driver_data[0];
- */
+	struct ieee80211_hw *hw = info->rate_driver_data[0];
+	struct ar9170 *ar = hw->priv;
+	struct sk_buff *outdated_skb;
 
 	/*
 	 * For proper rate control we really need to provide
-	 * TX status callbacks. For now, don't.
+	 * TX status callbacks.
 	 */
+
+	skb_pull(skb, sizeof(struct ar9170_tx_control));
+	if (urb->status || (info->flags & IEEE80211_TX_CTL_NO_ACK))
+		ar9170_tx_status(hw, skb, 0, !urb->status);
+	else {
+		skb_queue_tail(&ar->tx_status_queue, skb);
+
+		while (skb_queue_len(&ar->tx_status_queue) > AR9170_MAX_TX_STATUS) {
+			outdated_skb = skb_dequeue(&ar->tx_status_queue);
+			if (outdated_skb)
+				ar9170_tx_status(hw, outdated_skb, 0, 0);
+		}
+	}
+
 	usb_free_urb(urb);
-	dev_kfree_skb_irq(skb);
 }
 
 int ar9170_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
@@ -419,7 +419,7 @@ int ar9170_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
 	if (!urb)
 		goto free;
 
-	info->rate_driver_data[0] = ar;
+	info->rate_driver_data[0] = hw;
 
 	usb_fill_bulk_urb(urb, ar->udev,
 			  usb_sndbulkpipe(ar->udev, AR9170_EP_TX),
@@ -881,6 +881,7 @@ static struct ar9170 *ar9170_alloc(struct usb_interface *intf)
 	mutex_init(&ar->mutex);
 	spin_lock_init(&ar->cmdlock);
 	spin_lock_init(&ar->tx_status_lock);
+	skb_queue_head_init(&ar->tx_status_queue);
 	INIT_WORK(&ar->filter_config_work, ar9170_set_filters);
 	INIT_WORK(&ar->led_work, ar9170_update_leds);
 	INIT_WORK(&ar->beacon_work, ar9170_new_beacon);
@@ -1107,6 +1108,10 @@ static void ar9170_handle_mpdu(struct ar9170 *ar, u8 *buf, int len)
 	struct ieee80211_rx_status status;
 	int mpdu_len, i;
 	u8 error, antennas = 0, decrypt;
+	struct ieee80211_hdr *rx_hdr;
+	unsigned long flags;
+	struct sk_buff *tx_skb;
+	struct ieee80211_hdr *tx_hdr;
 	__le16 fc;
 	int reserved;
 
@@ -1239,8 +1244,30 @@ static void ar9170_handle_mpdu(struct ar9170 *ar, u8 *buf, int len)
 	}
 
 	buf += sizeof(struct ar9170_rx_head);
-	fc = *(__le16 *)buf;
 
+	/*
+	 * For proper rate control we really need to provide
+	 * TX status callbacks.
+	 */
+
+	rx_hdr = (struct ieee80211_hdr *)buf;
+	if (ieee80211_is_ack(rx_hdr->frame_control)) {
+		spin_lock_irqsave(&ar->tx_status_queue.lock, flags);
+
+		skb_queue_walk(&ar->tx_status_queue, tx_skb) {
+			tx_hdr = (struct ieee80211_hdr *)tx_skb->data;
+			if (memcmp(tx_hdr->addr2, rx_hdr->addr1, ETH_ALEN) == 0) {
+				__skb_unlink(tx_skb, &ar->tx_status_queue);
+				printk("!!!\n");
+				ar9170_tx_status(ar->hw, tx_skb, status.signal, 1);
+				break;
+			}
+		}
+
+		spin_unlock_irqrestore(&ar->tx_status_queue.lock, flags);
+	}
+
+	fc = *(__le16 *)buf;
 	if (ieee80211_is_data_qos(fc) ^ ieee80211_has_a4(fc))
 		reserved=32+2;
 	else

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Greg KH]

On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> Based on the number of mails I got, this driver should be ready for inclusion.
> So, this is probably the last RFC and the official patches will follow on
> sunday (only if no one finds a bug that needs to be fixed ASAP.)

Wonderful!

When the driver goes into the "real" portion of drivers/net please let
me know and I'll drop the otus driver from the drivers/staging/
location.

thanks,

greg k-h

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Christian Lamparter]

On Friday 20 March 2009 21:07:36 Alina Friedrichsen wrote:
> Hello Christian!
Hello!

> > Based on the number of mails I got, this driver should be ready for
> > inclusion.
> 
> ACK
Good ;-)
 
> > So, this is probably the last RFC and the official patches will follow on
> > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> 
> This is not same driver. Its much different, and I couldn't follow the changes in Johannes' git repository.
Well, the USB code was rewritten & "outsourced" into a separate module...
I did that because:
1. we might want to replace most of the "common" code with portions of ath9k.
    (no one, except Atheros' developers can really us with ANI/BC/HT/
    ABOLT/VAP etc. ;-) )

2. The otus driver talks about SPI devices. So maybe one day, we will need to
    add another frontend for the people with a handhelds or tablet with such a
    chip.

Now, what "changes" are you referring to?
Most of the qos, hw & rate control changes were already present in Johannes' tree.
And all I did was moving lines from other mac80211 driver around. :)
 
> Today, if have implement rate control (the needed ieee80211_tx_status_irqsafe() calls) for the original code. Now after one hour this code already outdated. :/
well, this "rate control" code was already part of the first RFC...
which was posted earlier this week?!

> In your code the implementation of it is not yet complete?
What's missing? Well, there is no BA (fail) & MCS rate report, true...
But under normal operation the rate should go up or down depending on the
current link quality.

However, please tell me about your idea. As my way of solving this issue
properly has some drawbacks (of course, I'm _fully_ aware of them)!

Regards,
	Chr

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Christian Lamparter]

On Friday 20 March 2009 21:13:26 Greg KH wrote:
> On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > Based on the number of mails I got, this driver should be ready for inclusion.
> > So, this is probably the last RFC and the official patches will follow on
> > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> 
> Wonderful!
:-)

> When the driver goes into the "real" portion of drivers/net please let
> me know and I'll drop the otus driver from the drivers/staging/
> location.
Well, I doubt that we can replace Otus, ever...

But it would be nice to tell/warn the otus user (and possible devs)
about the existence of an alternative driver, that does not
TAINT the kernel.

> thanks,
> 
> greg k-h

Regards,
	Chr

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Greg KH]

On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > So, this is probably the last RFC and the official patches will follow on
> > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> > 
> > Wonderful!
> :-)
> 
> > When the driver goes into the "real" portion of drivers/net please let
> > me know and I'll drop the otus driver from the drivers/staging/
> > location.
> Well, I doubt that we can replace Otus, ever...

Why, what is lacking in the version you have that is in the otus driver?

thanks,

greg k-h

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Christian Lamparter]

On Friday 20 March 2009 22:25:15 Greg KH wrote:
> On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> > On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > > So, this is probably the last RFC and the official patches will follow on
> > > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> > > 
> > > Wonderful!
> > :-)
> > 
> > > When the driver goes into the "real" portion of drivers/net please let
> > > me know and I'll drop the otus driver from the drivers/staging/
> > > location.
> > Well, I doubt that we can replace Otus, ever...
> 
> Why, what is lacking in the version you have that is in the otus driver?
>
Well, a few features that the vendors uses to encourage potential buyers:
- HT ( 802.11n - aka 300mbps )
- ANI (ambient noise immunity - so it works in noisy environments),
- TPC/DFS (802.11h - crucial if you want to "blast" the 5GHz band 
		      in most countries)
- AP/AD-Hoc 

comes to my mind. That said I didn't really look into otus to see which
of these feature actually works as advertised

Nevertheless ar9170 should fit the bill for users with 802.11b/g
accesspoint just fine.

and of course one could always argue that 802.11n is !still! a draft,
5GHz is not very widespread yet, and ANI only helps on very weak links...

However, I suggest that we wait and see what's the situation when
the first ar9170 bits are about to enter vanilla... deal?

Regards,
	Chr

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Greg KH]

On Fri, Mar 20, 2009 at 11:12:57PM +0100, Christian Lamparter wrote:
> On Friday 20 March 2009 22:25:15 Greg KH wrote:
> > On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> > > On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > > > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > > > So, this is probably the last RFC and the official patches will follow on
> > > > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> > > > 
> > > > Wonderful!
> > > :-)
> > > 
> > > > When the driver goes into the "real" portion of drivers/net please let
> > > > me know and I'll drop the otus driver from the drivers/staging/
> > > > location.
> > > Well, I doubt that we can replace Otus, ever...
> > 
> > Why, what is lacking in the version you have that is in the otus driver?
> >
> Well, a few features that the vendors uses to encourage potential buyers:
> - HT ( 802.11n - aka 300mbps )
> - ANI (ambient noise immunity - so it works in noisy environments),
> - TPC/DFS (802.11h - crucial if you want to "blast" the 5GHz band 
> 		      in most countries)
> - AP/AD-Hoc 
> 
> comes to my mind. That said I didn't really look into otus to see which
> of these feature actually works as advertised
> 
> Nevertheless ar9170 should fit the bill for users with 802.11b/g
> accesspoint just fine.
> 
> and of course one could always argue that 802.11n is !still! a draft,
> 5GHz is not very widespread yet, and ANI only helps on very weak links...
> 
> However, I suggest that we wait and see what's the situation when
> the first ar9170 bits are about to enter vanilla... deal?

Sounds good to me, let me know what you want to do then.

thanks,

greg k-h

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

Hello!

> Well, a few features that the vendors uses to encourage potential buy=
ers:
> - HT ( 802.11n - aka 300mbps )

Hopefully someone can implement it.

> - AP/AD-Hoc=20

Ad-Hoc mode with fixed BSSIDs works absolutely fine with this driver. I=
 only didn't find a way to reset the TSF, so that IBSS merges works sta=
ndard compliant.

In the praxis all mesh networks uses fixed BSSIDs.

Regards
Alina

--=20
Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? Der kann`s mit all=
en: http://www.gmx.net/de/go/multimessenger
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

Hallo Christian!

> Now, what "changes" are you referring to?

I wand see this changes in Johannes' git.

> Most of the qos, hw & rate control changes were already present in
> Johannes' tree.

No rate control like minstrel doesn't work in Johannes' git tree. It ha=
ngs ever at 1 MBit and don't come higher.

> What's missing? Well, there is no BA (fail) & MCS rate report, true..=
=2E
> But under normal operation the rate should go up or down depending on=
 the
> current link quality.
>=20
> However, please tell me about your idea. As my way of solving this is=
sue
> properly has some drawbacks (of course, I'm _fully_ aware of them)!

I must test your code first to answer.

Regards
Alina

--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/?mc=3Dmail@footer.hb
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Christian Lamparter]

On Friday 20 March 2009 23:49:20 Alina Friedrichsen wrote:
> > Well, a few features that the vendors uses to encourage potential buyers:
> > - HT ( 802.11n - aka 300mbps )
> 
> Hopefully someone can implement it.

Well, first the rate control algorithm needs to support it ;-).
so there's plenty of time to theorize what to do.

> > - AP/AD-Hoc 
> 
> Ad-Hoc mode with fixed BSSIDs works absolutely fine with this driver. I only didn't find a way to reset the TSF, so that IBSS merges works standard compliant.
> 
> In the praxis all mesh networks uses fixed BSSIDs.
Thanks for confirming!

Regards,
	Chr

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

Hello Christian,

your new code is not compatible with compat-wireless. The function usb_=
poison_anchored_urbs() is missing in the 2.6.27 kernel.

Regards
Alina

--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/?mc=3Dmail@footer.hb
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Johannes Berg]

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

On Sat, 2009-03-21 at 15:59 +0100, Alina Friedrichsen wrote:
> Hello Christian,
> 
> your new code is not compatible with compat-wireless. The function
> usb_poison_anchored_urbs() is missing in the 2.6.27 kernel.

That's something compat has to fix then -- we don't impose any backward
compatibility rules for the kernel code.

johannes

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

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

Hello Johannes!

> > your new code is not compatible with compat-wireless. The function
> > usb_poison_anchored_urbs() is missing in the 2.6.27 kernel.
>=20
> That's something compat has to fix then -- we don't impose any backwa=
rd
> compatibility rules for the kernel code.

ACK, I only want advert on this.

Regards
Alina

--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/?mc=3Dmail@footer.hb
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][RFT][PATCH 0/5 v5] ar9170: ar9170 driver (aka mac80211's otus)

[Alina Friedrichsen]

Hello Christian,

I have now tested your new code with wireless-testing as the complete k=
ernel. It doesn't work and freezes the complete network subsystem. Othe=
r USB sicks like zd1211rw works fine.

Regards
Alina

--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/?mc=3Dmail@footer.hb
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html