[RFC PATCH 0/2] mac80211: antenna configuration

[RFC PATCH 0/2] mac80211: antenna configuration

[Bruno Randolf]

hi!

this adds antenna configuration via nl80211. patches for iw will follow
shortly.

i have followed holger schurig's suggestion to use a bitmap for allowed
antennas. when multiple antennas are selected in the bitmap, the driver may use
diversity. i think that this allows for the most flexible, yet simple
configuration of antennas, and drivers can just reject configurations they
cannot support. i hope that this will also be generic enough for 802.11n with
multiple antennas - but for the moment i think the most important use case is
that we sometimes know that only one antenna is available and we want to
disable diversity and use only one fixed antenna. at least for ath5k this is
sometimes necessary to get good results with only one antenna.

please check it out and let me know what you think,
bruno

---

Bruno Randolf (2):
      mac80211: Add nl80211 antenna configuration
      ath5k: Add support for cfg80211 antenna setting


 drivers/net/wireless/ath/ath5k/base.c |   34 ++++++++++
 include/linux/nl80211.h               |   12 +++
 include/net/cfg80211.h                |    3 +
 include/net/mac80211.h                |    2 +
 net/mac80211/cfg.c                    |   16 +++++
 net/mac80211/driver-ops.h             |   21 ++++++
 net/wireless/nl80211.c                |  114 +++++++++++++++++++++++++++++++++
 7 files changed, 202 insertions(+), 0 deletions(-)

-- 
Signature

[RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Bruno Randolf]

Allow setting TX and RX antenna configuration via nl80211/cfg80211.

The antenna configuration is defined as a bitmap of allowed antennas. This
bitmap is 8 bit at the moment, each bit representing one antenna. If multiple
antennas are selected, the driver may use diversity for receive and transmit.
This allows for a simple, yet flexible configuration interface for antennas,
while drivers may reject configurations they cannot support.

Signed-off-by: Bruno Randolf <br1@einfach.org>
---
 include/linux/nl80211.h   |   12 +++++
 include/net/cfg80211.h    |    3 +
 include/net/mac80211.h    |    2 +
 net/mac80211/cfg.c        |   16 ++++++
 net/mac80211/driver-ops.h |   21 ++++++++
 net/wireless/nl80211.c    |  114 +++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 168 insertions(+), 0 deletions(-)

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index b7c77f9..46a2c76 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -341,6 +341,9 @@
  *	of any other interfaces, and other interfaces will again take
  *	precedence when they are used.
  *
+ * @NL80211_CMD_SET_ANTENNA: Set a bitmap of antennas to use.
+ * @NL80211_CMD_GET_ANTENNA: Get antenna configuration from driver.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -441,6 +444,9 @@ enum nl80211_commands {
 
 	NL80211_CMD_SET_CHANNEL,
 
+	NL80211_CMD_SET_ANTENNA,
+	NL80211_CMD_GET_ANTENNA,
+
 	/* add new commands above here */
 
 	/* used to define NL80211_CMD_MAX below */
@@ -725,6 +731,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
  *	connected to this BSS.
  *
+ * @NL80211_ATTR_ANTENNA_TX: Bitmap of antennas to use for transmitting.
+ * @NL80211_ATTR_ANTENNA_RX: Bitmap of antennas to use for receiving.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -882,6 +891,9 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_AP_ISOLATE,
 
+	NL80211_ATTR_ANTENNA_TX,
+	NL80211_ATTR_ANTENNA_RX,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b44a2e5..8861f40 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1176,6 +1176,9 @@ struct cfg80211_ops {
 	int	(*set_cqm_rssi_config)(struct wiphy *wiphy,
 				       struct net_device *dev,
 				       s32 rssi_thold, u32 rssi_hyst);
+
+	int	(*set_antenna)(struct wiphy *wiphy, u8 tx_ant, u8 rx_ant);
+	int	(*get_antenna)(struct wiphy *wiphy, u8 *tx_ant, u8 *rx_ant);
 };
 
 /*
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9448a5b..1a8f97a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1694,6 +1694,8 @@ struct ieee80211_ops {
 	int (*testmode_cmd)(struct ieee80211_hw *hw, void *data, int len);
 #endif
 	void (*flush)(struct ieee80211_hw *hw, bool drop);
+	int (*set_antenna)(struct ieee80211_hw *hw, u8 tx_ant, u8 rx_ant);
+	int (*get_antenna)(struct ieee80211_hw *hw, u8 *tx_ant, u8 *rx_ant);
 };
 
 /**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index c7000a6..efd04bc 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1560,6 +1560,20 @@ static int ieee80211_action(struct wiphy *wiphy, struct net_device *dev,
 				    channel_type, buf, len, cookie);
 }
 
+static int ieee80211_set_antenna(struct wiphy *wiphy, u8 tx_ant, u8 rx_ant)
+{
+	struct ieee80211_local *local = wiphy_priv(wiphy);
+
+	return drv_set_antenna(local, tx_ant, rx_ant);
+}
+
+static int ieee80211_get_antenna(struct wiphy *wiphy, u8 *tx_ant, u8 *rx_ant)
+{
+	struct ieee80211_local *local = wiphy_priv(wiphy);
+
+	return drv_get_antenna(local, tx_ant, rx_ant);
+}
+
 struct cfg80211_ops mac80211_config_ops = {
 	.add_virtual_intf = ieee80211_add_iface,
 	.del_virtual_intf = ieee80211_del_iface,
@@ -1611,4 +1625,6 @@ struct cfg80211_ops mac80211_config_ops = {
 	.cancel_remain_on_channel = ieee80211_cancel_remain_on_channel,
 	.action = ieee80211_action,
 	.set_cqm_rssi_config = ieee80211_set_cqm_rssi_config,
+	.set_antenna = ieee80211_set_antenna,
+	.get_antenna = ieee80211_get_antenna,
 };
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 997008e..d6fe1b7 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -373,4 +373,25 @@ static inline void drv_flush(struct ieee80211_local *local, bool drop)
 	if (local->ops->flush)
 		local->ops->flush(&local->hw, drop);
 }
+
+static inline int drv_set_antenna(struct ieee80211_local *local,
+				  u8 tx_ant, u8 rx_ant)
+{
+	int ret = -EOPNOTSUPP;
+	might_sleep();
+	if (local->ops->set_antenna)
+		ret = local->ops->set_antenna(&local->hw, tx_ant, rx_ant);
+	return ret;
+}
+
+static inline int drv_get_antenna(struct ieee80211_local *local,
+				  u8 *tx_ant, u8 *rx_ant)
+{
+	int ret = -EOPNOTSUPP;
+	might_sleep();
+	if (local->ops->get_antenna)
+		ret = local->ops->get_antenna(&local->hw, tx_ant, rx_ant);
+	return ret;
+}
+
 #endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index aaa1aad..dbfc126 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -153,6 +153,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
 	[NL80211_ATTR_CQM] = { .type = NLA_NESTED, },
 	[NL80211_ATTR_LOCAL_STATE_CHANGE] = { .type = NLA_FLAG },
 	[NL80211_ATTR_AP_ISOLATE] = { .type = NLA_U8 },
+	[NL80211_ATTR_ANTENNA_TX] = { .type = NLA_U8 },
+	[NL80211_ATTR_ANTENNA_RX] = { .type = NLA_U8 },
 };
 
 /* policy for the attributes */
@@ -4963,6 +4965,106 @@ out:
 	return err;
 }
 
+static int nl80211_set_antenna(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev;
+	int res;
+	u8 rx_ant = 0, tx_ant = 0;
+
+	if (!info->attrs[NL80211_ATTR_WIPHY] ||
+	    !info->attrs[NL80211_ATTR_ANTENNA_TX] ||
+	    !info->attrs[NL80211_ATTR_ANTENNA_RX]) {
+		return -EINVAL;
+	}
+
+	tx_ant = nla_get_u8(info->attrs[NL80211_ATTR_ANTENNA_TX]);
+	rx_ant = nla_get_u8(info->attrs[NL80211_ATTR_ANTENNA_RX]);
+
+	rtnl_lock();
+
+	rdev = cfg80211_get_dev_from_info(info);
+	if (IS_ERR(rdev)) {
+		res = -ENODEV;
+		goto unlock_rtnl;
+	}
+
+	if (!rdev->ops->set_antenna) {
+		res = -EOPNOTSUPP;
+		goto unlock_rdev;
+	}
+
+	res = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
+
+ unlock_rdev:
+	cfg80211_unlock_rdev(rdev);
+
+ unlock_rtnl:
+	rtnl_unlock();
+	return res;
+}
+
+static int nl80211_get_antenna(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev;
+	struct sk_buff *msg;
+	void *hdr;
+	int res;
+	u8 tx_ant, rx_ant;
+
+	if (!info->attrs[NL80211_ATTR_WIPHY])
+		return -EINVAL;
+
+	rtnl_lock();
+
+	rdev = cfg80211_get_dev_from_info(info);
+	if (IS_ERR(rdev)) {
+		res = -ENODEV;
+		goto unlock_rtnl;
+	}
+
+	if (!rdev->ops->get_antenna) {
+		res = -EOPNOTSUPP;
+		goto unlock_rdev;
+	}
+
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+	if (!msg) {
+		res = -ENOMEM;
+		goto unlock_rdev;
+	}
+
+	hdr = nl80211hdr_put(msg, info->snd_pid, info->snd_seq, 0,
+			     NL80211_CMD_GET_ANTENNA);
+	if (!hdr) {
+		res = -ENOMEM;
+		goto free_msg;
+	}
+
+	res = rdev->ops->get_antenna(&rdev->wiphy, &tx_ant, &rx_ant);
+	if (res)
+		goto free_msg;
+
+	NLA_PUT_U32(msg, NL80211_ATTR_ANTENNA_TX, tx_ant);
+	NLA_PUT_U32(msg, NL80211_ATTR_ANTENNA_RX, rx_ant);
+
+	genlmsg_end(msg, hdr);
+	res = genlmsg_reply(msg, info);
+	goto unlock_rdev;
+
+ nla_put_failure:
+	res = -ENOBUFS;
+
+ free_msg:
+	nlmsg_free(msg);
+
+ unlock_rdev:
+	cfg80211_unlock_rdev(rdev);
+
+ unlock_rtnl:
+	rtnl_unlock();
+	return res;
+}
+
 static struct genl_ops nl80211_ops[] = {
 	{
 		.cmd = NL80211_CMD_GET_WIPHY,
@@ -5279,6 +5381,18 @@ static struct genl_ops nl80211_ops[] = {
 		.policy = nl80211_policy,
 		.flags = GENL_ADMIN_PERM,
 	},
+	{
+		.cmd = NL80211_CMD_SET_ANTENNA,
+		.doit = nl80211_set_antenna,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+	},
+	{
+		.cmd = NL80211_CMD_GET_ANTENNA,
+		.doit = nl80211_get_antenna,
+		.policy = nl80211_policy,
+		/* can be retrieved by unprivileged users */
+	},
 };
 
 static struct genl_multicast_group nl80211_mlme_mcgrp = {

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Johannes Berg]

On Tue, 2010-05-11 at 17:39 +0900, Bruno Randolf wrote:

> +	[NL80211_ATTR_ANTENNA_TX] = { .type = NLA_U8 },
> +	[NL80211_ATTR_ANTENNA_RX] = { .type = NLA_U8 },
>  };

> +	tx_ant = nla_get_u8(info->attrs[NL80211_ATTR_ANTENNA_TX]);
> +	rx_ant = nla_get_u8(info->attrs[NL80211_ATTR_ANTENNA_RX]);

> +	NLA_PUT_U32(msg, NL80211_ATTR_ANTENNA_TX, tx_ant);
> +	NLA_PUT_U32(msg, NL80211_ATTR_ANTENNA_RX, rx_ant);

That isn't right.

johannes

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Johannes Berg]

On Tue, 2010-05-11 at 17:39 +0900, Bruno Randolf wrote:
> Allow setting TX and RX antenna configuration via nl80211/cfg80211.
> 
> The antenna configuration is defined as a bitmap of allowed antennas. This
> bitmap is 8 bit at the moment, each bit representing one antenna. If multiple
> antennas are selected, the driver may use diversity for receive and transmit.
> This allows for a simple, yet flexible configuration interface for antennas,
> while drivers may reject configurations they cannot support.

This is missing advertising whether or not the commands are available.
Look for the CMD() macro.

johannes

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Johannes Berg]

On Tue, 2010-05-11 at 17:39 +0900, Bruno Randolf wrote:


> +static inline int drv_set_antenna(struct ieee80211_local *local,
> +				  u8 tx_ant, u8 rx_ant)
> +{
> +	int ret = -EOPNOTSUPP;
> +	might_sleep();
> +	if (local->ops->set_antenna)
> +		ret = local->ops->set_antenna(&local->hw, tx_ant, rx_ant);
> +	return ret;
> +}
> +
> +static inline int drv_get_antenna(struct ieee80211_local *local,
> +				  u8 *tx_ant, u8 *rx_ant)
> +{
> +	int ret = -EOPNOTSUPP;
> +	might_sleep();
> +	if (local->ops->get_antenna)
> +		ret = local->ops->get_antenna(&local->hw, tx_ant, rx_ant);
> +	return ret;
> +}

Oh .. and add tracing please.

johannes

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Luis R. Rodriguez]

On Tue, May 11, 2010 at 1:39 AM, Bruno Randolf <br1@einfach.org> wrote:

Subject should be for cfg80211, not mac80211. In fact can you submit
the mac80211 stuff in a separate secondary patch? Some more comments
below.

> Allow setting TX and RX antenna configuration via nl80211/cfg80211.

I think we should call this TX / RX chainmask given that with 802.11n
hardware this is what this is called.

> The antenna configuration is defined as a bitmap of allowed antennas. This
> bitmap is 8 bit at the moment, each bit representing one antenna.

If you use chainmask for this instead of 'antenna configuration' the
wording would be something like:

The chainmask is defined as a bitmap of chain configurations used for TX/RX. The
bitmap allows for configuring up to up to 4 chains for both TX and RX,
4 bits for each TX chain, 4 bits for each RX chain.

> If multiple
> antennas are selected, the driver may use diversity for receive and transmit.

For 802.11n this is called "selection diversity" but typically just
referred to as "diversity", for legacy this is called "antenna
diversity". It may be good to elaborate how selection diversity or
antenna diversity might be enabled, ie, will this be another command,
or what. I think for legacy another command makes sense, and it may be
possible for us to use the same command for enabling selection
diversity, I am not sure if we can fine tune the diversity algorithm
at this time, I will have to review this and get back to you.

> This allows for a simple, yet flexible configuration interface for antennas,
> while drivers may reject configurations they cannot support.

:) !

  Luis

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Johannes Berg]

On Tue, 2010-05-11 at 11:14 -0700, Luis R. Rodriguez wrote:

> > Allow setting TX and RX antenna configuration via nl80211/cfg80211.
> 
> I think we should call this TX / RX chainmask given that with 802.11n
> hardware this is what this is called.

Well, but even with 11n hw you might be able to select _antennas_ rather
than chains. I'm convinced we'll need to differentiate that very
closely, and 11g hw has only antenna, not chain, selection.

johannes

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Luis R. Rodriguez]

On Tue, May 11, 2010 at 11:19 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-05-11 at 11:14 -0700, Luis R. Rodriguez wrote:
>
>> > Allow setting TX and RX antenna configuration via nl80211/cfg80211.
>>
>> I think we should call this TX / RX chainmask given that with 802.11n
>> hardware this is what this is called.
>
> Well, but even with 11n hw you might be able to select _antennas_ rather
> than chains. I'm convinced we'll need to differentiate that very
> closely, and 11g hw has only antenna, not chain, selection.

Heh you're right, you might have for example 3 antennas but only two
RX chains, for example. I still think it would be good for us to
figure out a way to bring these two notions together on a standard API
for both 11n and legacy, if possible.

  Luis

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Bruno Randolf]

On Wednesday 12 May 2010 03:14:30 Luis R. Rodriguez wrote:
> Subject should be for cfg80211, not mac80211. In fact can you submit
> the mac80211 stuff in a separate secondary patch? Some more comments
> below.

ok.

> I think we should call this TX / RX chainmask given that with 802.11n
> hardware this is what this is called.

from the following discussion, i'll stick with antenna...

> > The antenna configuration is defined as a bitmap of allowed antennas.
> > This bitmap is 8 bit at the moment, each bit representing one antenna.
> 
> If you use chainmask for this instead of 'antenna configuration' the
> wording would be something like:
> 
> The chainmask is defined as a bitmap of chain configurations used for
> TX/RX. The bitmap allows for configuring up to up to 4 chains for both TX
> and RX, 4 bits for each TX chain, 4 bits for each RX chain.

actually we have 8 bit for TX and 8 bit for RX.
 
> > If multiple
> > antennas are selected, the driver may use diversity for receive and
> > transmit.
> 
> For 802.11n this is called "selection diversity" but typically just
> referred to as "diversity", for legacy this is called "antenna
> diversity". It may be good to elaborate how selection diversity or
> antenna diversity might be enabled, ie, will this be another command,
> or what. I think for legacy another command makes sense, and it may be
> possible for us to use the same command for enabling selection
> diversity, I am not sure if we can fine tune the diversity algorithm
> at this time, I will have to review this and get back to you.

my idea was that if multiple antennas are selected in the bitmap this means 
that "antenna diversity" will be enabled. for RX this is clear. for TX this is 
a bit ambigous: it could mean "send on both antennas", which i believe is 
impossible on legacy hardware, so it means "let HW diversity choose TX 
antenna". for 802.11n - i think the TX part is different, because multiple TX 
chains will mean "send on multiple antennas". but otherwise can't we think of 
it as some form of advanced antenna diversity?

of course there are more possibillities of antenna configurations which cannot 
be configured with this api - like the "multiple sector antennas + RTS/CTS on 
omni" configuration of ath5k, but i don't think these are very common. 

the most important use case, imho, is to limit the antennas to one fixed 
antenna, if we know only one antenna is connected. this might well apply for 
802.11n too, no?

bruno

Re: [RFC PATCH 1/2] mac80211: Add nl80211 antenna configuration

[Luis R. Rodriguez]

On Tue, May 11, 2010 at 6:39 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Wednesday 12 May 2010 03:14:30 Luis R. Rodriguez wrote:
>> Subject should be for cfg80211, not mac80211. In fact can you submit
>> the mac80211 stuff in a separate secondary patch? Some more comments
>> below.
>
> ok.
>
>> I think we should call this TX / RX chainmask given that with 802.11n
>> hardware this is what this is called.
>
> from the following discussion, i'll stick with antenna...
>
>> > The antenna configuration is defined as a bitmap of allowed antennas.
>> > This bitmap is 8 bit at the moment, each bit representing one antenna.
>>
>> If you use chainmask for this instead of 'antenna configuration' the
>> wording would be something like:
>>
>> The chainmask is defined as a bitmap of chain configurations used for
>> TX/RX. The bitmap allows for configuring up to up to 4 chains for both TX
>> and RX, 4 bits for each TX chain, 4 bits for each RX chain.
>
> actually we have 8 bit for TX and 8 bit for RX.
>
>> > If multiple
>> > antennas are selected, the driver may use diversity for receive and
>> > transmit.
>>
>> For 802.11n this is called "selection diversity" but typically just
>> referred to as "diversity", for legacy this is called "antenna
>> diversity". It may be good to elaborate how selection diversity or
>> antenna diversity might be enabled, ie, will this be another command,
>> or what. I think for legacy another command makes sense, and it may be
>> possible for us to use the same command for enabling selection
>> diversity, I am not sure if we can fine tune the diversity algorithm
>> at this time, I will have to review this and get back to you.
>
> my idea was that if multiple antennas are selected in the bitmap this means
> that "antenna diversity" will be enabled. for RX this is clear. for TX this is
> a bit ambigous: it could mean "send on both antennas", which i believe is
> impossible on legacy hardware, so it means "let HW diversity choose TX
> antenna". for 802.11n - i think the TX part is different, because multiple TX
> chains will mean "send on multiple antennas". but otherwise can't we think of
> it as some form of advanced antenna diversity?

802.11n has chains but is also allows two antennas to be assigned to
one chain and the hardware then would do something equivalent to
legacy as with antenna diversity for one chain but it is called
"selection diversity" for 802.11n.

> of course there are more possibillities of antenna configurations which cannot
> be configured with this api - like the "multiple sector antennas + RTS/CTS on
> omni" configuration of ath5k, but i don't think these are very common.

Yeah I was reminded of these setups today as well, but as you note it
is rare and the defaults should typically work on those.

> the most important use case, imho, is to limit the antennas to one fixed
> antenna, if we know only one antenna is connected. this might well apply for
> 802.11n too, no?

802.11n does allow for 1 stream devices with a 1x1 TX/RX chain setup
but the hardware *can* have two antennas like your typical legacy
device with diversity enabled. This is the case for AR9285, for
example.

 Luis

[RFC PATCH 2/2] ath5k: Add support for cfg80211 antenna setting

[Bruno Randolf]

Support setting the antenna configuration via cfg80211. At the moment only
allow the simple pre-defined configurations we already have (fixed antenna A/B
or diversity), but more advanced settings should be possible later.

Signed-off-by: Bruno Randolf <br1@einfach.org>
---
 drivers/net/wireless/ath/ath5k/base.c |   34 +++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index a99f310..fbf3d45 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -256,6 +256,8 @@ static void ath5k_sw_scan_start(struct ieee80211_hw *hw);
 static void ath5k_sw_scan_complete(struct ieee80211_hw *hw);
 static void ath5k_set_coverage_class(struct ieee80211_hw *hw,
 		u8 coverage_class);
+static int ath5k_set_antenna(struct ieee80211_hw *hw, u8 tx_ant, u8 rx_ant);
+static int ath5k_get_antenna(struct ieee80211_hw *hw, u8 *tx_ant, u8 *rx_ant);
 
 static const struct ieee80211_ops ath5k_hw_ops = {
 	.tx 		= ath5k_tx,
@@ -277,6 +279,8 @@ static const struct ieee80211_ops ath5k_hw_ops = {
 	.sw_scan_start	= ath5k_sw_scan_start,
 	.sw_scan_complete = ath5k_sw_scan_complete,
 	.set_coverage_class = ath5k_set_coverage_class,
+	.set_antenna	= ath5k_set_antenna,
+	.get_antenna	= ath5k_get_antenna,
 };
 
 /*
@@ -3482,3 +3486,33 @@ static void ath5k_set_coverage_class(struct ieee80211_hw *hw, u8 coverage_class)
 	ath5k_hw_set_coverage_class(sc->ah, coverage_class);
 	mutex_unlock(&sc->lock);
 }
+
+static int ath5k_set_antenna(struct ieee80211_hw *hw, u8 tx_ant, u8 rx_ant)
+{
+	struct ath5k_softc *sc = hw->priv;
+
+	if (tx_ant == 1 && rx_ant == 1)
+		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_FIXED_A);
+	else if (tx_ant == 2 && rx_ant == 2)
+		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_FIXED_B);
+	else if (tx_ant == 3 && rx_ant == 3)
+		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_DEFAULT);
+	else
+		return -EOPNOTSUPP;
+	return 0;
+}
+
+static int ath5k_get_antenna(struct ieee80211_hw *hw, u8 *tx_ant, u8 *rx_ant)
+{
+	struct ath5k_softc *sc = hw->priv;
+
+	switch (sc->ah->ah_ant_mode) {
+	case AR5K_ANTMODE_FIXED_A:
+		*tx_ant = 1; *rx_ant = 1; break;
+	case AR5K_ANTMODE_FIXED_B:
+		*tx_ant = 2; *rx_ant = 2; break;
+	case AR5K_ANTMODE_DEFAULT:
+		*tx_ant = 3; *rx_ant = 3; break;
+	}
+	return 0;
+}

Re: [RFC PATCH 2/2] ath5k: Add support for cfg80211 antenna setting

[Johannes Berg]

On Tue, 2010-05-11 at 17:39 +0900, Bruno Randolf wrote:

> +	if (tx_ant == 1 && rx_ant == 1)
> +		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_FIXED_A);
> +	else if (tx_ant == 2 && rx_ant == 2)
> +		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_FIXED_B);
> +	else if (tx_ant == 3 && rx_ant == 3)
> +		ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_DEFAULT);
> +	else
> +		return -EOPNOTSUPP;

That should be -EINVAL, I think.

johannes

Re: [RFC PATCH 0/2] mac80211: antenna configuration

[Johannes Berg]

On Tue, 2010-05-11 at 17:38 +0900, Bruno Randolf wrote:

> i have followed holger schurig's suggestion to use a bitmap for allowed
> antennas. when multiple antennas are selected in the bitmap, the driver may use
> diversity. i think that this allows for the most flexible, yet simple
> configuration of antennas, and drivers can just reject configurations they
> cannot support. i hope that this will also be generic enough for 802.11n with
> multiple antennas

Not sure ... 11n has antennas and chains, but people mix them up
frequently. Does this API even make sense for 11n? Use cases? Should it
be about *antennas*, or about *chains*?

johannes

Re: [RFC PATCH 0/2] mac80211: antenna configuration

[Bruno Randolf]

On Tuesday 11 May 2010 17:53:19 you wrote:
> On Tue, 2010-05-11 at 17:38 +0900, Bruno Randolf wrote:
> > i have followed holger schurig's suggestion to use a bitmap for allowed
> > antennas. when multiple antennas are selected in the bitmap, the driver
> > may use diversity. i think that this allows for the most flexible, yet
> > simple configuration of antennas, and drivers can just reject
> > configurations they cannot support. i hope that this will also be
> > generic enough for 802.11n with multiple antennas
> 
> Not sure ... 11n has antennas and chains, but people mix them up
> frequently. Does this API even make sense for 11n? Use cases? Should it
> be about *antennas*, or about *chains*?

thanks for the review! i'll resend tomorrow.

i personally don't know about 802.11n - and what i need is about *antennas* :)

bruno

Re: [RFC PATCH 0/2] mac80211: antenna configuration

[Luis R. Rodriguez]

On Tue, May 11, 2010 at 2:34 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Tuesday 11 May 2010 17:53:19 you wrote:
>> On Tue, 2010-05-11 at 17:38 +0900, Bruno Randolf wrote:
>> > i have followed holger schurig's suggestion to use a bitmap for allowed
>> > antennas. when multiple antennas are selected in the bitmap, the driver
>> > may use diversity. i think that this allows for the most flexible, yet
>> > simple configuration of antennas, and drivers can just reject
>> > configurations they cannot support. i hope that this will also be
>> > generic enough for 802.11n with multiple antennas
>>
>> Not sure ... 11n has antennas and chains, but people mix them up
>> frequently. Does this API even make sense for 11n? Use cases? Should it
>> be about *antennas*, or about *chains*?
>
> thanks for the review! i'll resend tomorrow.
>
> i personally don't know about 802.11n - and what i need is about *antennas* :)

I figured, let us help you with the 11n review.

  Luis