2013-06-11 15:58:21

by Thomas Huehn

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

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 <[email protected]>
Signed-off-by: Thomas Huehn <[email protected]>
---
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



2013-06-11 19:24:35

by Johannes Berg

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

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


2013-06-12 19:00:13

by John W. Linville

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

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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2013-06-11 19:17:21

by Thomas Huehn

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

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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html


2013-06-11 17:46:31

by Christian Lamparter

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

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


2013-06-11 19:53:55

by Johannes Berg

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

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



2013-06-11 19:49:14

by Christian Lamparter

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

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