Allow setting of TX and RX antennas configuration via nl80211.
The antenna configuration is defined as a bitmap of allowed antennas to use.
This API can be used to mask out antennas which are not attached or should not
be used for other reasons like regulatory concerns or special setups.
Separate bitmaps are used for RX and TX to allow configuring different antennas
for receiving and transmitting. Each bitmap is 32 bit long, each bit
representing one antenna, starting with antenna 1 at the first bit. If an
antenna bit is set, this means the driver is allowed to use this antenna for RX
or TX respectively; if the bit is not set the hardware is not allowed to use
this antenna.
Using bitmaps has the benefit of allowing for a flexible configuration
interface which can support many different configurations and which can be used
for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
specific assumptions, drivers can use this information to know which antennas
are actually attached to the system and derive their capabilities based on
that.
802.11n devices should enable or disable chains, based on which antennas are
present (If all antennas belonging to a particular chain are disabled, the
entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
Antenna selection) should be calculated based on the available chains after
applying the antenna masks. Should a 802.11n device have diversity antennas
attached to one of their chains, diversity can be enabled or disabled based on
the antenna information.
Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
to enable or disable antenna diversity.
While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
but useful configurations as follows:
1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
have a low gain antenna for TX in order to keep within the regulatory
constraints and a high gain antenna for RX in order to receive weaker signals
("speak softly, but listen harder"). This can be useful for building long-shot
outdoor links. Another usage of this setup is having a low-noise pre-amplifier
on antenna 1 and a power amplifier on the other antenna. This way transmit
noise is mostly kept out of the low noise receive channel.
(This would be bitmaps: tx 1 rx 2).
2) Another similar setup is: Use RX diversity on both antennas, but always send
on antenna 1. Again that would allow us to benefit from a higher gain RX
antenna, while staying within the legal limits.
(This would be: tx 0 rx 3).
3) And finally there can be special experimental setups in research and
development even with pre 802.11n hardware where more than 2 antennas are
available. It's good to keep the API simple, yet flexible.
Signed-off-by: Bruno Randolf <[email protected]>
--
v7: Made bitmasks 32 bit wide and rebased to latest wireless-testing.
---
include/linux/nl80211.h | 25 +++++++++++++++++++++++++
include/net/cfg80211.h | 3 +++
net/wireless/nl80211.c | 31 ++++++++++++++++++++++++++++++-
3 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index fb877b5..17c5c88 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -804,6 +804,28 @@ enum nl80211_commands {
* @NL80211_ATTR_SUPPORT_IBSS_RSN: The device supports IBSS RSN, which mostly
* means support for per-station GTKs.
*
+ * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
+ * This can be used to mask out antennas which are not attached or should
+ * not be used for transmitting. If an antenna is not selected in this
+ * bitmap the hardware is not allowed to transmit on this antenna.
+ *
+ * Each bit represents one antenna, starting with antenna 1 at the first
+ * bit. Depending on which antennas are selected in the bitmap, 802.11n
+ * drivers can derive which chainmasks to use (if all antennas belonging to
+ * a particular chain are disabled this chain should be disabled) and if
+ * a chain has diversity antennas wether diversity should be used or not.
+ * HT capabilities (STBC, TX Beamforming, Antenna selection) can be
+ * derived from the available chains after applying the antenna mask.
+ * Non-802.11n drivers can derive wether to use diversity or not.
+ * Drivers may reject configurations or RX/TX mask combinations they cannot
+ * support by returning -EINVAL.
+ *
+ * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for receiving.
+ * This can be used to mask out antennas which are not attached or should
+ * not be used for receiving. If an antenna is not selected in this bitmap
+ * the hardware should not be configured to receive on this antenna.
+ * For a more detailed descripton see @NL80211_ATTR_WIPHY_ANTENNA_TX.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -973,6 +995,9 @@ enum nl80211_attrs {
NL80211_ATTR_SUPPORT_IBSS_RSN,
+ NL80211_ATTR_WIPHY_ANTENNA_TX,
+ NL80211_ATTR_WIPHY_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 e5702f5..07425e6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1304,6 +1304,9 @@ struct cfg80211_ops {
void (*mgmt_frame_register)(struct wiphy *wiphy,
struct net_device *dev,
u16 frame_type, bool reg);
+
+ int (*set_antenna)(struct wiphy *wiphy, u32 tx_ant, u32 rx_ant);
+ int (*get_antenna)(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant);
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4e78e3f..1f1df59 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -166,7 +166,11 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_WIPHY_TX_POWER_SETTING] = { .type = NLA_U32 },
[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] = { .type = NLA_U32 },
+
[NL80211_ATTR_FRAME_TYPE] = { .type = NLA_U16 },
+
+ [NL80211_ATTR_WIPHY_ANTENNA_TX] = { .type = NLA_U32 },
+ [NL80211_ATTR_WIPHY_ANTENNA_RX] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -526,7 +530,6 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
dev->wiphy.rts_threshold);
NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_COVERAGE_CLASS,
dev->wiphy.coverage_class);
-
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_SCAN_SSIDS,
dev->wiphy.max_scan_ssids);
NLA_PUT_U16(msg, NL80211_ATTR_MAX_SCAN_IE_LEN,
@@ -545,6 +548,16 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
if (dev->wiphy.flags & WIPHY_FLAG_CONTROL_PORT_PROTOCOL)
NLA_PUT_FLAG(msg, NL80211_ATTR_CONTROL_PORT_ETHERTYPE);
+ if (dev->ops->get_antenna) {
+ u32 tx_ant = 0, rx_ant = 0;
+ int res;
+ res = dev->ops->get_antenna(&dev->wiphy, &tx_ant, &rx_ant);
+ if (!res) {
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_ANTENNA_TX, tx_ant);
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_ANTENNA_RX, rx_ant);
+ }
+ }
+
nl_modes = nla_nest_start(msg, NL80211_ATTR_SUPPORTED_IFTYPES);
if (!nl_modes)
goto nla_put_failure;
@@ -1024,6 +1037,22 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
goto bad_res;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
+ info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
+ u32 tx_ant, rx_ant;
+ if (!rdev->ops->set_antenna) {
+ result = -EOPNOTSUPP;
+ goto bad_res;
+ }
+
+ tx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX]);
+ rx_ant = nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]);
+
+ result = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
+ if (result)
+ goto bad_res;
+ }
+
changed = 0;
if (info->attrs[NL80211_ATTR_WIPHY_RETRY_SHORT]) {
Allow antenna configuration by calling driver's function for it.
We disallow antenna configuration if the wiphy is already running, mainly to
make life easier for 802.11n drivers which need to recalculate HT capabilites.
Signed-off-by: Bruno Randolf <[email protected]>
---
include/net/mac80211.h | 2 ++
net/mac80211/cfg.c | 19 ++++++++++++++++
net/mac80211/driver-ops.h | 23 ++++++++++++++++++++
net/mac80211/driver-trace.h | 50 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9fdf982..fb6671d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1793,6 +1793,8 @@ struct ieee80211_ops {
void (*channel_switch)(struct ieee80211_hw *hw,
struct ieee80211_channel_switch *ch_switch);
int (*napi_poll)(struct ieee80211_hw *hw, int budget);
+ int (*set_antenna)(struct ieee80211_hw *hw, u32 tx_ant, u32 rx_ant);
+ int (*get_antenna)(struct ieee80211_hw *hw, u32 *tx_ant, u32 *rx_ant);
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 18bd0e5..c9c870c 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1621,6 +1621,23 @@ static void ieee80211_mgmt_frame_register(struct wiphy *wiphy,
ieee80211_queue_work(&local->hw, &local->reconfig_filter);
}
+static int ieee80211_set_antenna(struct wiphy *wiphy, u32 tx_ant, u32 rx_ant)
+{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+
+ if (local->started)
+ return -EOPNOTSUPP;
+
+ return drv_set_antenna(local, tx_ant, rx_ant);
+}
+
+static int ieee80211_get_antenna(struct wiphy *wiphy, u32 *tx_ant, u32 *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,
@@ -1673,4 +1690,6 @@ struct cfg80211_ops mac80211_config_ops = {
.mgmt_tx = ieee80211_mgmt_tx,
.set_cqm_rssi_config = ieee80211_set_cqm_rssi_config,
.mgmt_frame_register = ieee80211_mgmt_frame_register,
+ .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 1698382..c27a422 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -428,4 +428,27 @@ static inline void drv_channel_switch(struct ieee80211_local *local,
trace_drv_return_void(local);
}
+
+static inline int drv_set_antenna(struct ieee80211_local *local,
+ u32 tx_ant, u32 rx_ant)
+{
+ int ret = -EOPNOTSUPP;
+ might_sleep();
+ if (local->ops->set_antenna)
+ ret = local->ops->set_antenna(&local->hw, tx_ant, rx_ant);
+ trace_drv_set_antenna(local, tx_ant, rx_ant, ret);
+ return ret;
+}
+
+static inline int drv_get_antenna(struct ieee80211_local *local,
+ u32 *tx_ant, u32 *rx_ant)
+{
+ int ret = -EOPNOTSUPP;
+ might_sleep();
+ if (local->ops->get_antenna)
+ ret = local->ops->get_antenna(&local->hw, tx_ant, rx_ant);
+ trace_drv_get_antenna(local, *tx_ant, *rx_ant, ret);
+ return ret;
+}
+
#endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6831fb1..7773fb9 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -862,6 +862,56 @@ TRACE_EVENT(drv_channel_switch,
)
);
+TRACE_EVENT(drv_set_antenna,
+ TP_PROTO(struct ieee80211_local *local, u32 tx_ant, u32 rx_ant, int ret),
+
+ TP_ARGS(local, tx_ant, rx_ant, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ __field(u32, tx_ant)
+ __field(u32, rx_ant)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ __entry->tx_ant = tx_ant;
+ __entry->rx_ant = rx_ant;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " tx_ant:%d rx_ant:%d ret:%d",
+ LOCAL_PR_ARG, __entry->tx_ant, __entry->rx_ant, __entry->ret
+ )
+);
+
+TRACE_EVENT(drv_get_antenna,
+ TP_PROTO(struct ieee80211_local *local, u32 tx_ant, u32 rx_ant, int ret),
+
+ TP_ARGS(local, tx_ant, rx_ant, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ __field(u32, tx_ant)
+ __field(u32, rx_ant)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ __entry->tx_ant = tx_ant;
+ __entry->rx_ant = rx_ant;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " tx_ant:%d rx_ant:%d ret:%d",
+ LOCAL_PR_ARG, __entry->tx_ant, __entry->rx_ant, __entry->ret
+ )
+);
+
/*
* Tracing for API calls that drivers call.
*/
On 2010-11-10 4:52 PM, Johannes Berg wrote:
> On Wed, 2010-11-10 at 12:50 +0900, Bruno Randolf wrote:
>
>> 802.11n devices should enable or disable chains, based on which antennas are
>> present (If all antennas belonging to a particular chain are disabled, the
>> entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
>> Antenna selection) should be calculated based on the available chains after
>> applying the antenna masks. Should a 802.11n device have diversity antennas
>> attached to one of their chains, diversity can be enabled or disabled based on
>> the antenna information.
>
> I'm not entirely convinced that this is a good idea. Nor that, even if
> 11n devices were to implement it, they should all implementing their own
> code to update the HT capabilities. However, I suppose that nothing
> forces them to implement it, and when somebody does I can still complain
> when they put everything into the driver.
Drivers already need to calculate their HT capabilities based on the
number of chains.
If chains get masked out based on the antenna mask settings, the driver
code would most of the time only need minor refactoring for updating the
settings which wouldn't necessarily result in any new code duplication
at all.
- Felix
On Tue November 23 2010 00:31:21 Johannes Berg wrote:
> On Mon, 2010-11-22 at 11:33 +0900, Bruno Randolf wrote:
> > On Sat November 20 2010 03:45:37 Johannes Berg wrote:
> > > You'll need to provide documentation updates for this ASAP.
> >
> > What do you mean? There is lots of kerneldoc in my patch. Is it not
> > enough?
>
> Not for the cfg80211 ops afaict, or did I just miss that?
True. Sorry. I will add it.
bruno
On Wed, 2010-11-10 at 12:50 +0900, Bruno Randolf wrote:
> 802.11n devices should enable or disable chains, based on which antennas are
> present (If all antennas belonging to a particular chain are disabled, the
> entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
> Antenna selection) should be calculated based on the available chains after
> applying the antenna masks. Should a 802.11n device have diversity antennas
> attached to one of their chains, diversity can be enabled or disabled based on
> the antenna information.
I'm not entirely convinced that this is a good idea. Nor that, even if
11n devices were to implement it, they should all implementing their own
code to update the HT capabilities. However, I suppose that nothing
forces them to implement it, and when somebody does I can still complain
when they put everything into the driver.
johannes
On Sat November 20 2010 03:45:37 Johannes Berg wrote:
> You'll need to provide documentation updates for this ASAP.
What do you mean? There is lots of kerneldoc in my patch. Is it not enough?
bruno
Support setting the antenna configuration via cfg/mac80211. At the moment only
allow the simple pre-defined configurations we already have (fixed antenna A/B
or diversity), but more advanced settings are possible to implement.
Signed-off-by: Bruno Randolf <[email protected]>
---
drivers/net/wireless/ath/ath5k/base.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index b9f93fb..fe116de 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3413,6 +3413,36 @@ static int ath5k_conf_tx(struct ieee80211_hw *hw, u16 queue,
return ret;
}
+static int ath5k_set_antenna(struct ieee80211_hw *hw, u32 tx_ant, u32 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) == 3 && (rx_ant & 3) == 3)
+ ath5k_hw_set_antenna_mode(sc->ah, AR5K_ANTMODE_DEFAULT);
+ else
+ return -EINVAL;
+ return 0;
+}
+
+static int ath5k_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant, u32 *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;
+}
+
static const struct ieee80211_ops ath5k_hw_ops = {
.tx = ath5k_tx,
.start = ath5k_start,
@@ -3433,6 +3463,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,
};
/********************\
On Wed, 2010-11-10 at 16:59 +0100, Felix Fietkau wrote:
> > I'm not entirely convinced that this is a good idea. Nor that, even if
> > 11n devices were to implement it, they should all implementing their own
> > code to update the HT capabilities. However, I suppose that nothing
> > forces them to implement it, and when somebody does I can still complain
> > when they put everything into the driver.
> Drivers already need to calculate their HT capabilities based on the
> number of chains.
> If chains get masked out based on the antenna mask settings, the driver
> code would most of the time only need minor refactoring for updating the
> settings which wouldn't necessarily result in any new code duplication
> at all.
Good point.
johannes
On Mon, 2010-11-22 at 11:33 +0900, Bruno Randolf wrote:
> On Sat November 20 2010 03:45:37 Johannes Berg wrote:
> > You'll need to provide documentation updates for this ASAP.
>
> What do you mean? There is lots of kerneldoc in my patch. Is it not enough?
Not for the cfg80211 ops afaict, or did I just miss that?
johannes
You'll need to provide documentation updates for this ASAP.
johannes
On Sat November 20 2010 03:49:38 Johannes Berg wrote:
> On Fri, 2010-11-19 at 10:45 -0800, Johannes Berg wrote:
> > You'll need to provide documentation updates for this ASAP.
>
> I also expect a patch that adds discoverability of the availability of
> these commands, using a flag through mac80211 so that the commands are
> only discovered as available when the _driver_ implements them, not just
> if _mac80211_ implements them. Also with checking that the flag is set
> and rejecting them if not in the nl80211 functions.
Ok. Will do, but I need some time.
bruno
On Fri, 2010-11-19 at 10:45 -0800, Johannes Berg wrote:
> You'll need to provide documentation updates for this ASAP.
I also expect a patch that adds discoverability of the availability of
these commands, using a flag through mac80211 so that the commands are
only discovered as available when the _driver_ implements them, not just
if _mac80211_ implements them. Also with checking that the flag is set
and rejecting them if not in the nl80211 functions.
johannes
On Wed December 1 2010 17:48:57 Johannes Berg wrote:
> On Wed, 2010-12-01 at 07:54 +0100, Johannes Berg wrote:
> > On Wed, 2010-12-01 at 15:47 +0900, Bruno Randolf wrote:
> > > Already merged.
> > >
> > > git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
> >
> > Oops, sorry -- was on iwlwifi tree which didn't merge yet and got
> > confused thinking it was mac80211 only.
>
> Actually, I take that back. The patch *was* for mac80211 even though it
> claimed to be for cfg80211, and you still need to do the cfg80211
> versions.
Oh, sorry! So many interfaces... ;)
Patch on the way...
bruno
On Thu, 2010-12-02 at 16:23 +0900, Bruno Randolf wrote:
> On Wed December 1 2010 17:48:57 Johannes Berg wrote:
> > On Wed, 2010-12-01 at 07:54 +0100, Johannes Berg wrote:
> > > On Wed, 2010-12-01 at 15:47 +0900, Bruno Randolf wrote:
> > > > Already merged.
> > > >
> > > > git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
> > >
> > > Oops, sorry -- was on iwlwifi tree which didn't merge yet and got
> > > confused thinking it was mac80211 only.
> >
> > Actually, I take that back. The patch *was* for mac80211 even though it
> > claimed to be for cfg80211, and you still need to do the cfg80211
> > versions.
>
> Oh, sorry! So many interfaces... ;)
> Patch on the way...
Thanks!
johannes
On Wed, Dec 1, 2010 at 11:28 PM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2010-12-02 at 16:23 +0900, Bruno Randolf wrote:
>> On Wed December 1 2010 17:48:57 Johannes Berg wrote:
>> > On Wed, 2010-12-01 at 07:54 +0100, Johannes Berg wrote:
>> > > On Wed, 2010-12-01 at 15:47 +0900, Bruno Randolf wrote:
>> > > > Already merged.
>> > > >
>> > > > git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
>> > >
>> > > Oops, sorry -- was on iwlwifi tree which didn't merge yet and got
>> > > confused thinking it was mac80211 only.
>> >
>> > Actually, I take that back. The patch *was* for mac80211 even though it
>> > claimed to be for cfg80211, and you still need to do the cfg80211
>> > versions.
>>
>> Oh, sorry! So many interfaces... ;)
>> Patch on the way...
>
> Thanks!
I wonder if this configuration API will work with this 19 antenna design :-P
http://www.wired.com/epicenter/2010/12/ruckus-wifi-3g/
I think so!
Luis
On Wed, 2010-12-01 at 15:47 +0900, Bruno Randolf wrote:
> Already merged.
>
> git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
Oops, sorry -- was on iwlwifi tree which didn't merge yet and got
confused thinking it was mac80211 only.
johannes
On Wed December 1 2010 15:43:37 Johannes Berg wrote:
> On Wed, 2010-11-24 at 10:45 +0900, Bruno Randolf wrote:
> > On Tue November 23 2010 00:31:21 Johannes Berg wrote:
> > > On Mon, 2010-11-22 at 11:33 +0900, Bruno Randolf wrote:
> > > > On Sat November 20 2010 03:45:37 Johannes Berg wrote:
> > > > > You'll need to provide documentation updates for this ASAP.
> > > >
> > > > What do you mean? There is lots of kerneldoc in my patch. Is it not
> > > > enough?
> > >
> > > Not for the cfg80211 ops afaict, or did I just miss that?
> >
> > True. Sorry. I will add it.
>
> Ping.
Already merged.
git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
On Wed, 2010-12-01 at 07:54 +0100, Johannes Berg wrote:
> On Wed, 2010-12-01 at 15:47 +0900, Bruno Randolf wrote:
>
> > Already merged.
> >
> > git show 79b1c460a0b55e55981c25c56597c4d5d2872de3
>
> Oops, sorry -- was on iwlwifi tree which didn't merge yet and got
> confused thinking it was mac80211 only.
Actually, I take that back. The patch *was* for mac80211 even though it
claimed to be for cfg80211, and you still need to do the cfg80211
versions.
johannes
On Sat November 20 2010 03:49:38 Johannes Berg wrote:
> On Fri, 2010-11-19 at 10:45 -0800, Johannes Berg wrote:
> > You'll need to provide documentation updates for this ASAP.
>
> I also expect a patch that adds discoverability of the availability of
> these commands, using a flag through mac80211 so that the commands are
> only discovered as available when the _driver_ implements them, not just
> if _mac80211_ implements them. Also with checking that the flag is set
> and rejecting them if not in the nl80211 functions.
I just mailed a patch implementing this. I don't use a flag but a variable
available_antennas in wiphy, just like with the number of queues. I hope this
is what you had in mind.
bruno
On Wed, 2010-11-24 at 10:45 +0900, Bruno Randolf wrote:
> On Tue November 23 2010 00:31:21 Johannes Berg wrote:
> > On Mon, 2010-11-22 at 11:33 +0900, Bruno Randolf wrote:
> > > On Sat November 20 2010 03:45:37 Johannes Berg wrote:
> > > > You'll need to provide documentation updates for this ASAP.
> > >
> > > What do you mean? There is lots of kerneldoc in my patch. Is it not
> > > enough?
> >
> > Not for the cfg80211 ops afaict, or did I just miss that?
>
> True. Sorry. I will add it.
Ping.