[PATCH] carl9170: make use of the new rate control API

[PATCH] carl9170: make use of the new rate control API

[Thomas Huehn]

This patch enabels carl9170 to use the new rate table to lookup each
mrr rate and retry information per packet.

Signed-off-by: Benjamin Vahl <bvahl@net.t-labs.tu-berlin.de>
Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
---
 drivers/net/wireless/ath/carl9170/carl9170.h |    1 +
 drivers/net/wireless/ath/carl9170/tx.c       |    8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
index 9dce106..ddaa149 100644
--- a/drivers/net/wireless/ath/carl9170/carl9170.h
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
@@ -322,6 +322,7 @@ struct ar9170 {
 
 	/* MAC */
 	enum carl9170_erp_modes erp_mode;
+	struct ieee80211_tx_rate rates[4];
 
 	/* PHY */
 	struct ieee80211_channel *channel;
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index c61cafa..d21c81d 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -266,6 +266,7 @@ static void carl9170_tx_release(struct kref *ref)
 	struct carl9170_tx_info *arinfo;
 	struct ieee80211_tx_info *txinfo;
 	struct sk_buff *skb;
+	int size;
 
 	arinfo = container_of(ref, struct carl9170_tx_info, ref);
 	txinfo = container_of((void *) arinfo, struct ieee80211_tx_info,
@@ -324,6 +325,9 @@ static void carl9170_tx_release(struct kref *ref)
 		}
 	}
 
+	size = min_t(int, sizeof(txinfo->status.rates), sizeof(ar->rates));
+	memcpy(txinfo->status.rates, ar->rates, size);
+
 	skb_pull(skb, sizeof(struct _carl9170_tx_superframe));
 	ieee80211_tx_status_irqsafe(ar->hw, skb);
 }
@@ -982,6 +986,8 @@ static int carl9170_tx_prepare(struct ar9170 *ar,
 			txc->s.ampdu_settings, factor);
 	}
 
+	ieee80211_get_tx_rates(info->control.vif, sta, skb, ar->rates, ARRAY_SIZE(ar->rates));
+
 	/*
 	 * NOTE: For the first rate, the ERP & AMPDU flags are directly
 	 * taken from mac_control. For all fallback rate, the firmware
@@ -989,7 +995,7 @@ static int carl9170_tx_prepare(struct ar9170 *ar,
 	 */
 	for (i = 0; i < CARL9170_TX_MAX_RATES; i++) {
 		__le32 phy_set;
-		txrate = &info->control.rates[i];
+		txrate = &ar->rates[i];
 		if (txrate->idx < 0)
 			break;
 
-- 
1.7.9.5

Re: [PATCH] carl9170: make use of the new rate control API

[Christian Lamparter]

On Tuesday, June 11, 2013 05:57:17 PM Thomas Huehn wrote:
> This patch enabels carl9170 to use the new rate table to lookup each
> mrr rate and retry information per packet.

???

carl9170 already supports the new rate control API (Patch from 2013-04-23).
<http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>

Can you please tell me what you think is missing?

Regards,
	Chr

Re: [PATCH] carl9170: make use of the new rate control API

[Thomas Hühn]

Hi Christian,

I have not seen that patch in wireless-next, that's why I overlooked it… sorry.

> 
> ???
> 
> carl9170 already supports the new rate control API (Patch from 2013-04-23).
> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> 
> Can you please tell me what you think is missing?
> 

You patch looks good to me.
As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
Should this be done in carl9170 as well ?

Greetinsg,
Thomas

> Regards,
> 	Chr
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] carl9170: make use of the new rate control API

[Johannes Berg]

On Tue, 2013-06-11 at 21:17 +0200, Thomas Hühn wrote:
> Hi Christian,
> 
> I have not seen that patch in wireless-next, that's why I overlooked it… sorry.
> 
> > 
> > ???
> > 
> > carl9170 already supports the new rate control API (Patch from 2013-04-23).
> > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> > 
> > Can you please tell me what you think is missing?
> > 
> 
> You patch looks good to me.
> As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> Should this be done in carl9170 as well ?

I think that patch is wrong actually, probably should just do the rcu
protection inside the function. However the patch is completely wrong
anyway (C isn't python) so ...

johannes

Re: [PATCH] carl9170: make use of the new rate control API

[Christian Lamparter]

On Tuesday, June 11, 2013 09:24:28 PM Johannes Berg wrote:
> On Tue, 2013-06-11 at 21:17 +0200, Thomas Hühn wrote:
> > Hi Christian,
> > 
> > I have not seen that patch in wireless-next, that's why I overlooked it... sorry.
You are right and it's not in wireless-testing.git either. That's a bit odd.

John,

was this patch overlooked/lost or was there a problem with it?
(Or: can you please put it into wireless-next)

> > > carl9170 already supports the new rate control API (Patch from 2013-04-23).
> > > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> > > 
> > > Can you please tell me what you think is missing?
> > > 
> > 
> > You patch looks good to me.
> > As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> > Should this be done in carl9170 as well ?
> 
> I think that patch is wrong actually, probably should just do the rcu
> protection inside the function. However the patch is completely wrong
> anyway (C isn't python) so ...
Uh, that's confusing. We are now talking about the patch from Thomas, right?
If so: the previous "new rate control api" feature patch for carl9170 should
be fine in this regard.

Regards,
	Chr

Re: [PATCH] carl9170: make use of the new rate control API

[Johannes Berg]

On Tue, 2013-06-11 at 21:49 +0200, Christian Lamparter wrote:

> > > As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> > > Should this be done in carl9170 as well ?
> > 
> > I think that patch is wrong actually, probably should just do the rcu
> > protection inside the function. However the patch is completely wrong
> > anyway (C isn't python) so ...
> Uh, that's confusing. We are now talking about the patch from Thomas, right?
> If so: the previous "new rate control api" feature patch for carl9170 should
> be fine in this regard.

No, Calvin Owens's patch.

johannes

Re: [PATCH] carl9170: make use of the new rate control API

[John W. Linville]

On Tue, Jun 11, 2013 at 09:49:09PM +0200, Christian Lamparter wrote:
> On Tuesday, June 11, 2013 09:24:28 PM Johannes Berg wrote:
> > On Tue, 2013-06-11 at 21:17 +0200, Thomas Hühn wrote:
> > > Hi Christian,
> > > 
> > > I have not seen that patch in wireless-next, that's why I overlooked it... sorry.
> You are right and it's not in wireless-testing.git either. That's a bit odd.
> 
> John,
> 
> was this patch overlooked/lost or was there a problem with it?
> (Or: can you please put it into wireless-next)

No idea, but I don't seem to have it.  Can you resend it?

> > > > carl9170 already supports the new rate control API (Patch from 2013-04-23).
> > > > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> > > > 
> > > > Can you please tell me what you think is missing?
> > > > 
> > > 
> > > You patch looks good to me.
> > > As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> > > Should this be done in carl9170 as well ?
> > 
> > I think that patch is wrong actually, probably should just do the rcu
> > protection inside the function. However the patch is completely wrong
> > anyway (C isn't python) so ...
> Uh, that's confusing. We are now talking about the patch from Thomas, right?
> If so: the previous "new rate control api" feature patch for carl9170 should
> be fine in this regard.
> 
> Regards,
> 	Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.