* [RFC PATCHv5] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 11:00 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 14 ++++++++++
net/mac80211/driver-ops.h | 17 ++++++++++++
net/mac80211/driver-trace.h | 25 ++++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..69f0a63 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,53 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +659,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +702,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC PATCHv5] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-27 11:11 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274958042-25573-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, 2010-05-27 at 14:00 +0300, Juuso Oikarinen wrote:
[...]
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
Btw, a patch changelog after the --- would be good.
Like, for example,
v5: no changes, still don't fix interface type crash
> +static int ieee80211_ifa_changed(struct notifier_block *nb,
> + unsigned long data, void *arg)
> +{
> + struct in_ifaddr *ifa = arg;
> + struct ieee80211_local *local =
> + container_of(nb, struct ieee80211_local,
> + ifa_notifier);
> + struct net_device *ndev = ifa->ifa_dev->dev;
> + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> + struct ieee80211_sub_if_data *sdata;
> + struct ieee80211_if_managed *ifmgd;
> +
> + /* Make sure it's our interface that got changed */
> + if (!wdev)
> + return NOTIFY_DONE;
> +
> + if (wdev->wiphy != local->hw.wiphy)
> + return NOTIFY_DONE;
> +
> + /* We are concerned about IP addresses only when associated */
> + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> + ifmgd = &sdata->u.mgd;
> + mutex_lock(&ifmgd->mtx);
> + if (ifmgd->associated)
> + ieee80211_set_arp_filter(sdata);
> + mutex_unlock(&ifmgd->mtx);
> +
> + return NOTIFY_DONE;
> +}
Ok ...
Was I not clear enough? I thought I was or you'd have asked, but I can
spell it out too:
This *will* crash if you use an interface of a type other than
managed/station. You need to check the interface type here and
document that the callback will only be invoked for managed mode
interfaces.
johannes
^ permalink raw reply
* Re: [RFC PATCHv5] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 11:22 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274958697.3669.33.camel@jlt3.sipsolutions.net>
On Thu, 2010-05-27 at 13:11 +0200, ext Johannes Berg wrote:
> On Thu, 2010-05-27 at 14:00 +0300, Juuso Oikarinen wrote:
>
> [...]
>
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
>
> Btw, a patch changelog after the --- would be good.
>
> Like, for example,
>
> v5: no changes, still don't fix interface type crash
>
>
> > +static int ieee80211_ifa_changed(struct notifier_block *nb,
> > + unsigned long data, void *arg)
> > +{
> > + struct in_ifaddr *ifa = arg;
> > + struct ieee80211_local *local =
> > + container_of(nb, struct ieee80211_local,
> > + ifa_notifier);
> > + struct net_device *ndev = ifa->ifa_dev->dev;
> > + struct wireless_dev *wdev = ndev->ieee80211_ptr;
> > + struct ieee80211_sub_if_data *sdata;
> > + struct ieee80211_if_managed *ifmgd;
> > +
> > + /* Make sure it's our interface that got changed */
> > + if (!wdev)
> > + return NOTIFY_DONE;
> > +
> > + if (wdev->wiphy != local->hw.wiphy)
> > + return NOTIFY_DONE;
> > +
> > + /* We are concerned about IP addresses only when associated */
> > + sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
> > + ifmgd = &sdata->u.mgd;
> > + mutex_lock(&ifmgd->mtx);
> > + if (ifmgd->associated)
> > + ieee80211_set_arp_filter(sdata);
> > + mutex_unlock(&ifmgd->mtx);
> > +
> > + return NOTIFY_DONE;
> > +}
>
> Ok ...
>
> Was I not clear enough? I thought I was or you'd have asked, but I can
> spell it out too:
>
> This *will* crash if you use an interface of a type other than
> managed/station. You need to check the interface type here and
> document that the callback will only be invoked for managed mode
> interfaces.
Hmm,
I'm sorry. This time I appear to have forgotten to commit :'(
I had added this:
/* ARP filtering is only supported in managed mode */
if (sdata->vif.type != NL80211_IFTYPE_STATION)
return NOTIFY_DONE;
And even tested that with ad-hoc. I'll just have to go again.
-Juuso
>
> johannes
>
> --
> 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
^ permalink raw reply
* [RFC PATCHv6] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 11:42 UTC (permalink / raw)
To: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
v6: Add check for managed mode in "ieee80211_ifa_changed"
---
include/net/mac80211.h | 14 +++++++++
net/mac80211/driver-ops.h | 17 +++++++++++
net/mac80211/driver-trace.h | 25 +++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 63 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..d6eb0b6 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,58 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+
+ /* ARP filtering is only supported in managed mode */
+ if (sdata->vif.type != NL80211_IFTYPE_STATION)
+ return NOTIFY_DONE;
+
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +664,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +707,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC PATCHv6] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-27 11:47 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274960533-395-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, 2010-05-27 at 14:42 +0300, Juuso Oikarinen wrote:
> Some hardware allow extended filtering of ARP frames not intended for
> the host. To perform such filtering, the hardware needs to know the current
> IP address(es) of the host, bound to its interface.
>
> Add support for ARP filtering to mac80211 by adding a new op to the driver
> interface, allowing to configure the current IP addresses. This op is called
> upon association with the currently configured address(es), and when
> associated whenever the IP address(es) change.
>
> This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
> need ARP filtering.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Yay.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Hmm. Actually, something I just thought of during our IRC discussion,
should we turn it off when we disassociate or something? Do we even
care? I guess not since it'll be reconfigured after the next
association?
johannes
^ permalink raw reply
* Re: [RFC PATCHv6] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 12:07 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274960825.3669.37.camel@jlt3.sipsolutions.net>
On Thu, 2010-05-27 at 13:47 +0200, ext Johannes Berg wrote:
> On Thu, 2010-05-27 at 14:42 +0300, Juuso Oikarinen wrote:
> > Some hardware allow extended filtering of ARP frames not intended for
> > the host. To perform such filtering, the hardware needs to know the current
> > IP address(es) of the host, bound to its interface.
> >
> > Add support for ARP filtering to mac80211 by adding a new op to the driver
> > interface, allowing to configure the current IP addresses. This op is called
> > upon association with the currently configured address(es), and when
> > associated whenever the IP address(es) change.
> >
> > This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
> > need ARP filtering.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> Yay.
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
YAY! :D
>
> Hmm. Actually, something I just thought of during our IRC discussion,
> should we turn it off when we disassociate or something? Do we even
> care? I guess not since it'll be reconfigured after the next
> association?
>
This is how I was thinking. After disassociation we shouldn't be seeing
data frames anyway, and on next assoc, we set the addresses again.
-Juuso
> johannes
>
> --
> 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
^ permalink raw reply
* Re: [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Benoit Papillault @ 2010-05-27 12:09 UTC (permalink / raw)
To: Johannes Berg
Cc: Bruno Randolf, linville, juuso.oikarinen, ath5k-devel,
linux-wireless
In-Reply-To: <1274947716.3669.13.camel@jlt3.sipsolutions.net>
Le 27/05/2010 10:08, Johannes Berg a écrit :
> On Thu, 2010-05-27 at 09:45 +0900, Bruno Randolf wrote:
>> IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5& 11 Mbits are
>> mandatory rates for what they call High Rate direct sequence spread spectrum
>> (HR/DSSS) PHY (with long PLCP).
>
> You're confused. Clause 18 is 11g, we knew that those were mandatory
> there, see the code you're modifying.
>
> Clause 15 is 11b, and it shouldn't change.
>
> So NACK.
>
> johannes
I just dig through the various standards and besides there are still
some grey areas in my mind (like what is HR/DSSS/PBCC mentioned in
Clause 18 or DSSS-OFDM as specified in Clause 19, hopefully both are
optional), we have :
802.11a = Clause 17, called OFDM
802.11b = Clause 15 (called DSSS) & Clause 18 (called HR/DSSS).
802.11g = Clause 19, called ERP with lots of variants : ERP-DSSS/CCK,
ERP-OFDM, ERP-PBCC
802.11n = Clause 20, called HT for High Throughput, which also includes
DUP-OFDM
Clause 15 defines 1 Mbits and 2 Mbits rates, long PLCP only
Clause 18 defines 5.5 Mbits and 11 Mbits. Optionally, short PLCP is
available for 2 Mbits, 5.5 Mbits and 11 Mbits. Since it's optional, such
short PLCP rates are probably not part of the mandatory rates.
Basic rate set must includes mandatory rates set. This is apparently
what every other AP do today and I indeed see no points in adding more
rates to the basic rate set other than what is already defined in the
mandatory rate set (except we cannot rely on this rule when joining an
existing BSS/IBSS, of course).
Does the patch you posted is intended to create a 802.11b only or
802.11bg AP/IBSS with a 802.11g hardware for instance?
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Johannes Berg @ 2010-05-27 12:13 UTC (permalink / raw)
To: Benoit Papillault
Cc: Bruno Randolf, linville, juuso.oikarinen, ath5k-devel,
linux-wireless
In-Reply-To: <4BFE60EF.7020800@free.fr>
On Thu, 2010-05-27 at 14:09 +0200, Benoit Papillault wrote:
> 802.11a = Clause 17, called OFDM
> 802.11b = Clause 15 (called DSSS) & Clause 18 (called HR/DSSS).
Are you sure? Isn't clause 15 pre-amendement?
> Clause 15 defines 1 Mbits and 2 Mbits rates, long PLCP only
> Clause 18 defines 5.5 Mbits and 11 Mbits. Optionally, short PLCP is
> available for 2 Mbits, 5.5 Mbits and 11 Mbits. Since it's optional, such
> short PLCP rates are probably not part of the mandatory rates.
>
> Basic rate set must includes mandatory rates set.
I don't think this is true.
> This is apparently
> what every other AP do today and I indeed see no points in adding more
> rates to the basic rate set other than what is already defined in the
> mandatory rate set (except we cannot rely on this rule when joining an
> existing BSS/IBSS, of course).
Sure, you can add more than say 11b mandatory rates to specifically
exclude non-11g stations from it to improve performance.
johannes
^ permalink raw reply
* [PATCH] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-27 12:32 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Some hardware allow extended filtering of ARP frames not intended for
the host. To perform such filtering, the hardware needs to know the current
IP address(es) of the host, bound to its interface.
Add support for ARP filtering to mac80211 by adding a new op to the driver
interface, allowing to configure the current IP addresses. This op is called
upon association with the currently configured address(es), and when
associated whenever the IP address(es) change.
This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
need ARP filtering.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
---
include/net/mac80211.h | 14 +++++++++
net/mac80211/driver-ops.h | 17 +++++++++++
net/mac80211/driver-trace.h | 25 +++++++++++++++++
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/main.c | 63 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 11 +++++++-
6 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index de22cbf..169251c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -19,6 +19,7 @@
#include <linux/wireless.h>
#include <linux/device.h>
#include <linux/ieee80211.h>
+#include <linux/inetdevice.h>
#include <net/cfg80211.h>
/**
@@ -1535,6 +1536,16 @@ enum ieee80211_ampdu_mlme_action {
* of the bss parameters has changed when a call is made. The callback
* can sleep.
*
+ * @configure_arp_filter: Configuration function for hardware ARP query filter.
+ * This function is called with all the IP addresses configured to the
+ * interface as argument - all ARP queries targeted to any of these
+ * addresses must pass through. If the hardware filter does not support
+ * enought addresses, hardware filtering must be disabled. The ifa_list
+ * argument may be NULL, indicating that filtering must be disabled.
+ * This function is called upon association complete with current
+ * address(es), and while associated whenever the IP address(es) change.
+ * The callback can sleep.
+ *
* @prepare_multicast: Prepare for multicast filter configuration.
* This callback is optional, and its return value is passed
* to configure_filter(). This callback must be atomic.
@@ -1674,6 +1685,9 @@ struct ieee80211_ops {
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
u32 changed);
+ int (*configure_arp_filter)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
struct netdev_hw_addr_list *mc_list);
void (*configure_filter)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4f22713..978850e 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -83,6 +83,23 @@ static inline void drv_bss_info_changed(struct ieee80211_local *local,
trace_drv_bss_info_changed(local, sdata, info, changed);
}
+struct in_ifaddr;
+static inline int drv_configure_arp_filter(struct ieee80211_local *local,
+ struct ieee80211_vif *vif,
+ struct in_ifaddr *ifa_list)
+{
+ int ret = 0;
+
+ might_sleep();
+
+ if (local->ops->configure_arp_filter)
+ ret = local->ops->configure_arp_filter(&local->hw, vif,
+ ifa_list);
+
+ trace_drv_configure_arp_filter(local, vif_to_sdata(vif), ifa_list, ret);
+ return ret;
+}
+
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
struct netdev_hw_addr_list *mc_list)
{
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6a9b234..577460d 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -219,6 +219,31 @@ TRACE_EVENT(drv_bss_info_changed,
)
);
+TRACE_EVENT(drv_configure_arp_filter,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct in_ifaddr *ifa_list, int ret),
+
+ TP_ARGS(local, sdata, ifa_list, ret),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->ret = ret;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT LOCAL_PR_FMT " ret:%d",
+ VIF_PR_ARG, LOCAL_PR_ARG, __entry->ret
+ )
+);
+
TRACE_EVENT(drv_prepare_multicast,
TP_PROTO(struct ieee80211_local *local, int mc_count, u64 ret),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1a9e2da..8356a08 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -851,6 +851,7 @@ struct ieee80211_local {
struct work_struct dynamic_ps_disable_work;
struct timer_list dynamic_ps_timer;
struct notifier_block network_latency_notifier;
+ struct notifier_block ifa_notifier;
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
@@ -996,6 +997,7 @@ void ieee80211_send_pspoll(struct ieee80211_local *local,
void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency);
int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
struct ieee80211_bss *bss,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 22a384d..d6eb0b6 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -329,6 +329,58 @@ static void ieee80211_recalc_smps_work(struct work_struct *work)
mutex_unlock(&local->iflist_mtx);
}
+int ieee80211_set_arp_filter(struct ieee80211_sub_if_data *sdata)
+{
+ struct in_device *idev;
+ int ret = 0;
+
+ BUG_ON(!sdata);
+ ASSERT_RTNL();
+
+ idev = sdata->dev->ip_ptr;
+ if (!idev)
+ return 0;
+
+ ret = drv_configure_arp_filter(sdata->local, &sdata->vif,
+ idev->ifa_list);
+ return ret;
+}
+
+static int ieee80211_ifa_changed(struct notifier_block *nb,
+ unsigned long data, void *arg)
+{
+ struct in_ifaddr *ifa = arg;
+ struct ieee80211_local *local =
+ container_of(nb, struct ieee80211_local,
+ ifa_notifier);
+ struct net_device *ndev = ifa->ifa_dev->dev;
+ struct wireless_dev *wdev = ndev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ /* Make sure it's our interface that got changed */
+ if (!wdev)
+ return NOTIFY_DONE;
+
+ if (wdev->wiphy != local->hw.wiphy)
+ return NOTIFY_DONE;
+
+ /* We are concerned about IP addresses only when associated */
+ sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+
+ /* ARP filtering is only supported in managed mode */
+ if (sdata->vif.type != NL80211_IFTYPE_STATION)
+ return NOTIFY_DONE;
+
+ ifmgd = &sdata->u.mgd;
+ mutex_lock(&ifmgd->mtx);
+ if (ifmgd->associated)
+ ieee80211_set_arp_filter(sdata);
+ mutex_unlock(&ifmgd->mtx);
+
+ return NOTIFY_DONE;
+}
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -612,14 +664,22 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_max_network_latency;
result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
-
if (result) {
rtnl_lock();
goto fail_pm_qos;
}
+ local->ifa_notifier.notifier_call = ieee80211_ifa_changed;
+ result = register_inetaddr_notifier(&local->ifa_notifier);
+ if (result)
+ goto fail_ifa;
+
return 0;
+ fail_ifa:
+ pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
+ &local->network_latency_notifier);
+ rtnl_lock();
fail_pm_qos:
ieee80211_led_exit(local);
ieee80211_remove_interfaces(local);
@@ -647,6 +707,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
pm_qos_remove_notifier(PM_QOS_NETWORK_LATENCY,
&local->network_latency_notifier);
+ unregister_inetaddr_notifier(&local->ifa_notifier);
rtnl_lock();
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0839c4e..0fa1fa3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2078,8 +2078,17 @@ static enum work_done_result ieee80211_assoc_done(struct ieee80211_work *wk,
cfg80211_send_assoc_timeout(wk->sdata->dev,
wk->filter_ta);
return WORK_DONE_DESTROY;
+ } else {
+ mutex_unlock(&wk->sdata->u.mgd.mtx);
+
+ /*
+ * configure ARP filter IP addresses to the driver,
+ * intentionally outside the mgd mutex.
+ */
+ rtnl_lock();
+ ieee80211_set_arp_filter(wk->sdata);
+ rtnl_unlock();
}
- mutex_unlock(&wk->sdata->u.mgd.mtx);
}
cfg80211_send_rx_assoc(wk->sdata->dev, skb->data, skb->len);
--
1.6.3.3
^ permalink raw reply related
* [PATCH] mac80211: clean up ieee80211_stop_tx_ba_session
From: Johannes Berg @ 2010-05-27 12:41 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
There's no sense in letting anything but internal
mac80211 functions set the initiator to anything
but WLAN_BACK_INITIATOR, since WLAN_BACK_RECIPIENT
is only valid when we have received a frame from
the peer, which we react to directly in mac80211.
The debugfs code I recently added got this wrong
as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 +--
include/net/mac80211.h | 6 ++----
net/mac80211/agg-tx.c | 7 +++----
net/mac80211/debugfs_sta.c | 3 +--
net/mac80211/driver-trace.h | 10 ++++------
5 files changed, 11 insertions(+), 18 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2010-05-27 14:31:11.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-05-27 14:32:19.000000000 +0200
@@ -2331,16 +2331,14 @@ void ieee80211_start_tx_ba_cb_irqsafe(st
* ieee80211_stop_tx_ba_session - Stop a Block Ack session.
* @sta: the station whose BA session to stop
* @tid: the TID to stop BA.
- * @initiator: if indicates initiator DELBA frame will be sent.
*
- * Return: error if no sta with matching da found, success otherwise
+ * Return: negative error if the TID is invalid, or no aggregation active
*
* Although mac80211/low level driver/user space application can estimate
* the need to stop aggregation on a certain RA/TID, the session level
* will be managed by the mac80211.
*/
-int ieee80211_stop_tx_ba_session(struct ieee80211_sta *sta, u16 tid,
- enum ieee80211_back_parties initiator);
+int ieee80211_stop_tx_ba_session(struct ieee80211_sta *sta, u16 tid);
/**
* ieee80211_stop_tx_ba_cb - low level driver ready to stop aggregate.
--- wireless-testing.orig/net/mac80211/agg-tx.c 2010-05-27 14:31:32.000000000 +0200
+++ wireless-testing/net/mac80211/agg-tx.c 2010-05-27 14:34:25.000000000 +0200
@@ -538,14 +538,13 @@ int __ieee80211_stop_tx_ba_session(struc
return ret;
}
-int ieee80211_stop_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
- enum ieee80211_back_parties initiator)
+int ieee80211_stop_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid)
{
struct sta_info *sta = container_of(pubsta, struct sta_info, sta);
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
- trace_api_stop_tx_ba_session(pubsta, tid, initiator);
+ trace_api_stop_tx_ba_session(pubsta, tid);
if (!local->ops->ampdu_action)
return -EINVAL;
@@ -553,7 +552,7 @@ int ieee80211_stop_tx_ba_session(struct
if (tid >= STA_TID_NUM)
return -EINVAL;
- return __ieee80211_stop_tx_ba_session(sta, tid, initiator);
+ return __ieee80211_stop_tx_ba_session(sta, tid, WLAN_BACK_INITIATOR);
}
EXPORT_SYMBOL(ieee80211_stop_tx_ba_session);
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn-rs.c 2010-05-27 14:34:01.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn-rs.c 2010-05-27 14:34:07.000000000 +0200
@@ -313,8 +313,7 @@ static int rs_tl_turn_on_agg_for_tid(str
*/
IWL_DEBUG_HT(priv, "Fail start Tx agg on tid: %d\n",
tid);
- ieee80211_stop_tx_ba_session(sta, tid,
- WLAN_BACK_INITIATOR);
+ ieee80211_stop_tx_ba_session(sta, tid);
}
} else
IWL_ERR(priv, "Fail finding valid aggregation tid: %d\n", tid);
--- wireless-testing.orig/net/mac80211/driver-trace.h 2010-05-27 14:34:29.000000000 +0200
+++ wireless-testing/net/mac80211/driver-trace.h 2010-05-27 14:34:47.000000000 +0200
@@ -850,25 +850,23 @@ TRACE_EVENT(api_start_tx_ba_cb,
);
TRACE_EVENT(api_stop_tx_ba_session,
- TP_PROTO(struct ieee80211_sta *sta, u16 tid, u16 initiator),
+ TP_PROTO(struct ieee80211_sta *sta, u16 tid),
- TP_ARGS(sta, tid, initiator),
+ TP_ARGS(sta, tid),
TP_STRUCT__entry(
STA_ENTRY
__field(u16, tid)
- __field(u16, initiator)
),
TP_fast_assign(
STA_ASSIGN;
__entry->tid = tid;
- __entry->initiator = initiator;
),
TP_printk(
- STA_PR_FMT " tid:%d initiator:%d",
- STA_PR_ARG, __entry->tid, __entry->initiator
+ STA_PR_FMT " tid:%d",
+ STA_PR_ARG, __entry->tid
)
);
--- wireless-testing.orig/net/mac80211/debugfs_sta.c 2010-05-27 14:37:41.000000000 +0200
+++ wireless-testing/net/mac80211/debugfs_sta.c 2010-05-27 14:37:59.000000000 +0200
@@ -210,8 +210,7 @@ static ssize_t sta_agg_status_write(stru
if (start)
ret = ieee80211_start_tx_ba_session(&sta->sta, tid);
else
- ret = ieee80211_stop_tx_ba_session(&sta->sta, tid,
- WLAN_BACK_RECIPIENT);
+ ret = ieee80211_stop_tx_ba_session(&sta->sta, tid);
} else {
__ieee80211_stop_rx_ba_session(sta, tid, WLAN_BACK_RECIPIENT, 3);
ret = 0;
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: fix dma sync in rx path
From: Felix Fietkau @ 2010-05-27 13:51 UTC (permalink / raw)
To: Ming Lei; +Cc: lrodriguez, linux-wireless, linville
In-Reply-To: <20100515182540.6f4e140c@tom-lei>
On 2010-05-15 12:25 PM, Ming Lei wrote:
> From edd368e7436e7a80c5a43e7ad40cff1f3fa20806 Mon Sep 17 00:00:00 2001
> From: Ming Lei <tom.leiming@gmail.com>
> Date: Fri, 14 May 2010 17:35:51 +0800
> Subject: [PATCH 2/2] ath9k: fix dma sync in rx path(v2)
>
> If buffer is to be accessed by cpu after dma is over, but
> between dma mapping and dma unmapping, we should use
> dma_sync_single_for_cpu to sync the buffer between cpu with
> device. And dma_sync_single_for_device is used to let
> device gain the buffer again.
>
> v2: Felix pointed out dma_sync_single_for_device is needed to return
> buffer to device if an unsuccessful status bit check is found.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Sorry for the delay. I've tested your patch and it works for me.
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Bob Copeland @ 2010-05-27 14:31 UTC (permalink / raw)
To: Richard Farina; +Cc: Gábor Stefanik, Weedy, linux-wireless, Johannes Berg
In-Reply-To: <4BFDEBDC.4070304@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]
On Wed, May 26, 2010 at 11:49 PM, Richard Farina <sidhayn@gmail.com> wrote:
> Bob Copeland wrote:
>> Ok, it should be enough to look at the filter flags instead of
>> the opmode -- I knew in the back of my mind that the monitor
>> stuff was bogus (part of the reason I did the patch in the first
>> place) but just got confused by what was already there I guess.
>
> I've got a lot of people very interested in this fix. Let me know what kind
> of support you need to make this happen. You know where to find me on irc
> ;-)
Ok, can you and Weedy try this patch?
Use the attachment -- gmail will screw up the whitespace, but I included
it inline for reference.
Weedy, if you want reported-by credit can you give your full name and
preferred email address?
From: Bob Copeland <me@bobcopeland.com>
Date: Thu, 27 May 2010 08:54:38 -0400
Subject: [PATCH] ath5k: retain promiscuous setting
Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up
filter flags setting" introduced a regression in monitor mode such
that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not
preserve it across subsequent calls to configure_filter. This patch
restores the original functionality.
Cc: stable@kernel.org
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
Note, a better fix would be to just unconditionally look at new_flags,
but this is the minimal change for stable. I'll add fixing all this
stuff up to my todo.
drivers/net/wireless/ath/ath5k/base.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c
b/drivers/net/wireless/ath/ath5k/base.c
index 9c27623..9e023b8 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3153,13 +3153,15 @@ static void ath5k_configure_filter(struct
ieee80211_hw *hw,
if (changed_flags & (FIF_PROMISC_IN_BSS | FIF_OTHER_BSS)) {
if (*new_flags & FIF_PROMISC_IN_BSS) {
- rfilt |= AR5K_RX_FILTER_PROM;
__set_bit(ATH_STAT_PROMISC, sc->status);
} else {
__clear_bit(ATH_STAT_PROMISC, sc->status);
}
}
+ if (test_bit(ATH_STAT_PROMISC, sc->status))
+ rfilt |= AR5K_RX_FILTER_PROM;
+
/* Note, AR5K_RX_FILTER_MCAST is already enabled */
if (*new_flags & FIF_ALLMULTI) {
mfilt[0] = ~0;
--
1.6.3.3
--
Bob Copeland %% www.bobcopeland.com
[-- Attachment #2: 0001-ath5k-retain-promiscuous-setting.patch --]
[-- Type: text/x-patch, Size: 1638 bytes --]
From befe47a84a22312e0547d04cd3d250b0e49ecf54 Mon Sep 17 00:00:00 2001
From: Bob Copeland <me@bobcopeland.com>
Date: Thu, 27 May 2010 08:54:38 -0400
Subject: [PATCH] ath5k: retain promiscuous setting
Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up
filter flags setting" introduced a regression in monitor mode such
that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not
preserve it across subsequent calls to configure_filter. This patch
restores the original functionality.
Cc: stable@kernel.org
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
Note, a better fix would be to just unconditionally look at new_flags,
but this is the minimal change for stable. I'll add fixing all this
stuff up to my todo.
drivers/net/wireless/ath/ath5k/base.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c27623..9e023b8 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3153,13 +3153,15 @@ static void ath5k_configure_filter(struct ieee80211_hw *hw,
if (changed_flags & (FIF_PROMISC_IN_BSS | FIF_OTHER_BSS)) {
if (*new_flags & FIF_PROMISC_IN_BSS) {
- rfilt |= AR5K_RX_FILTER_PROM;
__set_bit(ATH_STAT_PROMISC, sc->status);
} else {
__clear_bit(ATH_STAT_PROMISC, sc->status);
}
}
+ if (test_bit(ATH_STAT_PROMISC, sc->status))
+ rfilt |= AR5K_RX_FILTER_PROM;
+
/* Note, AR5K_RX_FILTER_MCAST is already enabled */
if (*new_flags & FIF_ALLMULTI) {
mfilt[0] = ~0;
--
1.6.3.3
^ permalink raw reply related
* Re: A mailing list for regulatory wireless-regdb changes
From: John W. Linville @ 2010-05-27 15:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Woodhouse, linux-wireless, Michael Green, David Quan,
Emmanuel Grumbach
In-Reply-To: <AANLkTik_bztAq5aLTHTlcD3ug0QeXfkEf-vPhkzEUA_6@mail.gmail.com>
On Thu, May 27, 2010 at 01:15:50AM -0700, Luis R. Rodriguez wrote:
> David, can I trouble you for a mailman wireless-regdb mailing list on
> infradead.org? This would be used by those who are not developers and
> do not need to be subscribed to linux-wireless. An example are
> regulatory guys at different companies and generally interested
> people/developers on the topic. This should hopefully accelerate the
> turn around time for reviewing of patches and also a good placeholder
> for us to go back and check the discussions that went on about this.
Is this really necessary?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: A mailing list for regulatory wireless-regdb changes
From: David Woodhouse @ 2010-05-27 15:34 UTC (permalink / raw)
To: John W. Linville
Cc: Luis R. Rodriguez, linux-wireless, Michael Green, David Quan,
Emmanuel Grumbach
In-Reply-To: <20100527150515.GB2486@tuxdriver.com>
On Thu, 2010-05-27 at 11:05 -0400, John W. Linville wrote:
> On Thu, May 27, 2010 at 01:15:50AM -0700, Luis R. Rodriguez wrote:
> > David, can I trouble you for a mailman wireless-regdb mailing list on
> > infradead.org? This would be used by those who are not developers and
> > do not need to be subscribed to linux-wireless. An example are
> > regulatory guys at different companies and generally interested
> > people/developers on the topic. This should hopefully accelerate the
> > turn around time for reviewing of patches and also a good placeholder
> > for us to go back and check the discussions that went on about this.
>
> Is this really necessary?
Feel free not to use it :)
--
dwmw2
^ permalink raw reply
* Re: A mailing list for regulatory wireless-regdb changes
From: John W. Linville @ 2010-05-27 15:43 UTC (permalink / raw)
To: David Woodhouse
Cc: Luis R. Rodriguez, linux-wireless, Michael Green, David Quan,
Emmanuel Grumbach
In-Reply-To: <1274974452.20576.20410.camel@macbook.infradead.org>
On Thu, May 27, 2010 at 04:34:12PM +0100, David Woodhouse wrote:
> On Thu, 2010-05-27 at 11:05 -0400, John W. Linville wrote:
> > On Thu, May 27, 2010 at 01:15:50AM -0700, Luis R. Rodriguez wrote:
> > > David, can I trouble you for a mailman wireless-regdb mailing list on
> > > infradead.org? This would be used by those who are not developers and
> > > do not need to be subscribed to linux-wireless. An example are
> > > regulatory guys at different companies and generally interested
> > > people/developers on the topic. This should hopefully accelerate the
> > > turn around time for reviewing of patches and also a good placeholder
> > > for us to go back and check the discussions that went on about this.
> >
> > Is this really necessary?
>
> Feel free not to use it :)
Just hoping to avoid unnecessary confusion -- I suppose it is fine
if that is what people want...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Conversion of driver for Realtek 8192SU
From: Larry Finger @ 2010-05-27 16:13 UTC (permalink / raw)
To: John Linville, Greg KH; +Cc: wireless
I am in the process of converting the driver contained in the file
RTL8192SU_usb_linux_v2.6.0006.20100511.zip obtained from the Realtek
site. This driver is used for the following USB IDs:
Realtek (0x0bda) 0x8171, 0x8172, 0x8173, 0x8174, 0x8712, 0x8713, 0xC512
Correga (0x07aa) 0x0047
D-Link (0x07d1) 0x3303, 0x3302, 0x3300
Skyworth (0x14b2) 0x3300, 0x3301, 0x3302
EnGenius (0x1740) 0x9603, 0x9605
Belkin (0x050d) 0x815F, 0x945A, 0x845A
Guillemot(0x06f8) 0xe031
Edimax (0x7392) 0x7611, 0x7612, 0x7622
Sitecom (0x0DF6) 0x0045
Hawking (0x0E66) 0x0015, 0x0016, 0x1786, 0x1791
Other (0x13D3) 0x3306, 0x3309, 0x3310, 0x3311, 0x3325
Other (0x083A) 0xC512
My initial plan is to modify this driver code for inclusion in
drivers/staging. The above list includes some, but not all, of the IDs
in the driver currently in drivers/staging/rtl8192su. I will likely put
this in as drivers/staging/rtl8712u, which is the name used in the code,
and remove the duplicate IDs from rtl8192su. Once this step is done, I
will then work at modifying it to use mac80211 so that it can go into
mainline.
My test device is a D-Link DWA-130 (14b2:3300). The Realtek driver
compiles cleanly and works as-is for this device on i386 architecture;
however, compilation spews hundreds of warnings when built on x86_64.
Most of these are due to wrong sized integers in pointer - integer
conversions and were easily fixed. The driver also oopsed due to an
illegal array index when getting the channel number from scan data. I
found this problem, and added a fixup and a log message to prevent the
oops. The driver now scans correctly, but cannot connect on x86_64,
which is my second reason for this message.
I know that the size of pointers changes from 32- to 54-bit
architecture, as does the size of longs. I have been through the code
many times, and I think those have been fixed. Are there any other types
of objects that change size? Does anyone have any suggestions on what to
look for?
Thanks,
Larry
^ permalink raw reply
* Regulatory problem with multiple wireless interfaces
From: Lukáš Turek @ 2010-05-27 16:10 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 5456 bytes --]
Hi,
I reported this first in ath5k-devel, but now I'm convinced the problem lies
in the cfg80211 regulatory framework.
When there is more than one wireless card installed, sometimes the CRDA reply
for first detected card's request gets into the kernel before next card is
requested and everything is fine. But sometimes CRDA replies too late and
kernel sends multiple request, one for each card. The behavior is completely
random, different every boot.
This is dmesg output from a system with three AR5414 PCI cards, all with
regdomain 0x36 (Czech Republic) exhibiting this problem:
ath5k 0000:02:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ath5k 0000:02:01.0: registered as 'phy0'
ath: EEPROM regdomain: 0x36
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: CZ
ath: Regpair used: 0x36
udev: renamed network interface eth0 to eth2
udev: renamed network interface eth1_rename to eth0
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
ath5k 0000:02:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath5k 0000:02:02.0: registered as 'phy1'
ath: EEPROM regdomain: 0x36
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: CZ
ath: Regpair used: 0x36
cfg80211: Calling CRDA for country: CZ
phy1: Selected rate control algorithm 'minstrel'
ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
ath5k 0000:02:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
ath5k 0000:02:03.0: registered as 'phy2'
ath: EEPROM regdomain: 0x36
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: CZ
ath: Regpair used: 0x36
cfg80211: Calling CRDA for country: CZ
udev: renamed network interface wlan1 to wlan3
phy2: Selected rate control algorithm 'minstrel'
ath5k phy2: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
cfg80211: Calling CRDA for country: CZ
udev: renamed network interface wlan1 to wlan2
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
The result is that all but the last card stay in world regdomain with channels
100-140 unavailable. Only the last card has correct channels enabled. I had
to disable some code at 4 places to get it working, so there might be mutiple
bugs, or they all have some common cause, but I couldn't find any. The ugly
patch I used is attached, hopefully it will provide some pointers to find out
what's wrong.
My guess is that the main problem is the use of the global variable
last_request, which is incompatible with asynchronous replies from CRDA.
Unfortunately it's quite hard for me to debug this problem because of the
random behavior and especially because I don't understand the purpose of some
parts of the regulatory code - for example why do you calculate the
intersection at all, and don't just set on each card whatever regdomain is in
its EEPROM? What should happen if all cards have different regdomains?
Lukas Turek
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 422da20..52536ae 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1156,6 +1156,8 @@ static int freq_reg_info_regd(struct wiphy *wiphy,
wiphy->regd)
regd = wiphy->regd;
+ regd = cfg80211_regdomain; //HACK
+
if (!regd)
return -EINVAL;
@@ -1286,7 +1288,7 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
bw_flags = IEEE80211_CHAN_NO_HT40;
if (last_request->initiator == NL80211_REGDOM_SET_BY_DRIVER &&
- request_wiphy && request_wiphy == wiphy &&
+ request_wiphy && /* request_wiphy == wiphy && */ //HACK
request_wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY) {
/*
* This gaurantees the driver's requested regulatory domain
@@ -1327,6 +1329,8 @@ static void handle_band(struct wiphy *wiphy, enum ieee80211_band band)
static bool ignore_reg_update(struct wiphy *wiphy,
enum nl80211_reg_initiator initiator)
{
+ return false; //HACK
+
if (!last_request)
return true;
if (initiator == NL80211_REGDOM_SET_BY_CORE &&
@@ -2499,7 +2503,7 @@ static int __set_regdom(const struct ieee80211_regdomain *rd)
if (last_request->initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE) {
- intersected_rd = regdom_intersect(rd, cfg80211_regdomain);
+ intersected_rd = regdom_intersect(rd, rd); //HACK
if (!intersected_rd)
return -EINVAL;
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: A mailing list for regulatory wireless-regdb changes
From: Luis R. Rodriguez @ 2010-05-27 16:44 UTC (permalink / raw)
To: John W. Linville
Cc: David Woodhouse, linux-wireless, Michael Green, David Quan,
Emmanuel Grumbach
In-Reply-To: <20100527154350.GA3728@tuxdriver.com>
On Thu, May 27, 2010 at 8:43 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, May 27, 2010 at 04:34:12PM +0100, David Woodhouse wrote:
>> On Thu, 2010-05-27 at 11:05 -0400, John W. Linville wrote:
>> > On Thu, May 27, 2010 at 01:15:50AM -0700, Luis R. Rodriguez wrote:
>> > > David, can I trouble you for a mailman wireless-regdb mailing list on
>> > > infradead.org? This would be used by those who are not developers and
>> > > do not need to be subscribed to linux-wireless. An example are
>> > > regulatory guys at different companies and generally interested
>> > > people/developers on the topic. This should hopefully accelerate the
>> > > turn around time for reviewing of patches and also a good placeholder
>> > > for us to go back and check the discussions that went on about this.
>> >
>> > Is this really necessary?
>>
>> Feel free not to use it :)
>
> Just hoping to avoid unnecessary confusion -- I suppose it is fine
> if that is what people want...
I do not know how else to help speed up review without having to wait
for a intermediary delay of someone at a company forwarding some
regulatory changes e-mail to a person who is supposed to review them.
With the list we would have a direct way for people to communicate
with the folks who do care about regulatory and who may have roles who
do that.
If people do not mind the constant "please give us a few days" e-mails
then things work without the list but then we (at least Atheros) just
need to make sure regulatory change e-mails do get to the proper folks
for review because we (Atheros) is committed to reviewing these
changes.
Luis
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Weedy @ 2010-05-27 17:40 UTC (permalink / raw)
To: Bob Copeland
Cc: Richard Farina, Gábor Stefanik, linux-wireless,
Johannes Berg
In-Reply-To: <AANLkTin3VSp_FcSiadD4efE1Yo1vKiDXmOngsHEKiQmF@mail.gmail.com>
On Thu, May 27, 2010 at 10:31 AM, Bob Copeland <me@bobcopeland.com> wrote:
>
> Ok, can you and Weedy try this patch?
Works for me but I only have 2 active APs around me at work. When I
get home I'll have access to a cloud.
> Weedy, if you want reported-by credit can you give your full name and
> preferred email address?
Do I have to? I don't really want to tie my name to this email :/
^ permalink raw reply
* Re: Conversion of driver for Realtek 8192SU
From: Johannes Berg @ 2010-05-27 18:06 UTC (permalink / raw)
To: Larry Finger; +Cc: John Linville, Greg KH, wireless
In-Reply-To: <4BFE9A22.5040005@lwfinger.net>
On Thu, 2010-05-27 at 11:13 -0500, Larry Finger wrote:
> I know that the size of pointers changes from 32- to 54-bit
> architecture, as does the size of longs. I have been through the code
> many times, and I think those have been fixed. Are there any other types
> of objects that change size? Does anyone have any suggestions on what to
> look for?
Alignment _might_ be different, though I think it isn't actually as long
as we're talking about x86_64 (amd64) only.
If the driver uses wireless extensions (likely), it might have issues
with that too, since they are not very 32/64-bit compat happy (unless
you're using 64-bit userspace exclusively obviously)
I can't think of anything else right now.
johannes
^ permalink raw reply
* [PATCH]: ath: Fix uninitialized variable warnings
From: Prarit Bhargava @ 2010-05-27 18:15 UTC (permalink / raw)
To: linux-wireless, linville; +Cc: Prarit Bhargava
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]
Fixes 'make -j24 CONFIG_DEBUG_SECTION_MISMATCH=y' warning:
drivers/net/wireless/ath/ath9k/eeprom_4k.c: In function ‘ath9k_hw_get_4k_gain_boundaries_pdadcs.clone.1’:
drivers/net/wireless/ath/ath9k/eeprom_4k.c:311: error: ‘minPwrT4’ may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/eeprom_9287.c: In function ‘ath9k_hw_get_AR9287_gain_boundaries_pdadcs’:
drivers/net/wireless/ath/ath9k/eeprom_9287.c:302: error: ‘minPwrT4’ may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/eeprom_def.c: In function ‘ath9k_hw_get_def_gain_boundaries_pdadcs.clone.0’:
drivers/net/wireless/ath/ath9k/eeprom_def.c:679: error: ‘minPwrT4’ may be used uninitialized in this function
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 41a77d1..e25a2ab 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -249,6 +249,7 @@ static void ath9k_hw_get_4k_gain_boundaries_pdadcs(struct ath_hw *ah,
struct chan_centers centers;
#define PD_GAIN_BOUNDARY_DEFAULT 58;
+ memset(&minPwrT4, 0, AR9287_NUM_PD_GAINS);
ath9k_hw_get_channel_centers(ah, chan, ¢ers);
for (numPiers = 0; numPiers < availPiers; numPiers++) {
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index b471db5..9b0478d 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -245,6 +245,7 @@ static void ath9k_hw_get_AR9287_gain_boundaries_pdadcs(struct ath_hw *ah,
static u8 vpdTableI[AR5416_EEP4K_NUM_PD_GAINS]
[AR5416_MAX_PWR_RANGE_IN_HALF_DB];
+ memset(&minPwrT4, 0, AR9287_NUM_PD_GAINS);
ath9k_hw_get_channel_centers(ah, chan, ¢ers);
for (numPiers = 0; numPiers < availPiers; numPiers++) {
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index e591ad6..9019b6e 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -618,6 +618,7 @@ static void ath9k_hw_get_def_gain_boundaries_pdadcs(struct ath_hw *ah,
int16_t minDelta = 0;
struct chan_centers centers;
+ memset(&minPwrT4, 0, AR9287_NUM_PD_GAINS);
ath9k_hw_get_channel_centers(ah, chan, ¢ers);
for (numPiers = 0; numPiers < availPiers; numPiers++) {
^ permalink raw reply related
* Re: Conversion of driver for Realtek 8192SU
From: Larry Finger @ 2010-05-27 18:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Greg KH, wireless
In-Reply-To: <1274983581.3669.60.camel@jlt3.sipsolutions.net>
On 05/27/2010 01:06 PM, Johannes Berg wrote:
> On Thu, 2010-05-27 at 11:13 -0500, Larry Finger wrote:
>
>> I know that the size of pointers changes from 32- to 54-bit
>> architecture, as does the size of longs. I have been through the code
>> many times, and I think those have been fixed. Are there any other types
>> of objects that change size? Does anyone have any suggestions on what to
>> look for?
>
> Alignment _might_ be different, though I think it isn't actually as long
> as we're talking about x86_64 (amd64) only.
>
> If the driver uses wireless extensions (likely), it might have issues
> with that too, since they are not very 32/64-bit compat happy (unless
> you're using 64-bit userspace exclusively obviously)
>
> I can't think of anything else right now.
Thanks. The problem I had with the scan channel was with WEXT. It seems
likely that this problem is somewhere in there.
Larry
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Bob Copeland @ 2010-05-27 18:31 UTC (permalink / raw)
To: Weedy
Cc: Richard Farina, Gábor Stefanik, linux-wireless,
Johannes Berg, John W. Linville
In-Reply-To: <AANLkTilPvGLRhwZBY3q9UXLaq-zbI9U-VhFNx1dfq1mH@mail.gmail.com>
On Thu, May 27, 2010 at 1:40 PM, Weedy <weedy2887@gmail.com> wrote:
>> Weedy, if you want reported-by credit can you give your full name and
>> preferred email address?
> Do I have to? I don't really want to tie my name to this email :/
Honestly I don't know what reported-by policy is (other than I should
get your consent first). I guess John can weigh in whether:
Reported-by: weedy2887@gmail.com
is acceptable. For S-o-b, the rule is no anonymous or pseudonymous
contributions. Of course, you don't have to be credited, but your
bisection was a huge help in pinning it down :)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH]: libertas: fix uninitialized variable warning
From: Prarit Bhargava @ 2010-05-27 18:41 UTC (permalink / raw)
To: linux-wireless, linville; +Cc: Prarit Bhargava
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
Fixes:
drivers/net/wireless/libertas/rx.c: In function ‘process_rxed_802_11_packet’:
drivers/net/wireless/libertas/rx.c:354: error: ‘radiotap_hdr.flags’ may be used uninitialized in this function
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
diff --git a/drivers/net/wireless/libertas/rx.c b/drivers/net/wireless/libertas/rx.c
index e2b8d88..2319bde 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -330,9 +330,8 @@ static int process_rxed_802_11_packet(struct lbs_private *priv,
/* create the exported radio header */
/* radiotap header */
- radiotap_hdr.hdr.it_version = 0;
- /* XXX must check this value for pad */
- radiotap_hdr.hdr.it_pad = 0;
+ memset(&radiotap_hdr, 0, sizeof(radiotap_hdr));
+ /* XXX must check radiotap_hdr.hdr.it_pad for pad */
radiotap_hdr.hdr.it_len = cpu_to_le16 (sizeof(struct rx_radiotap_hdr));
radiotap_hdr.hdr.it_present = cpu_to_le32 (RX_RADIOTAP_PRESENT);
radiotap_hdr.rate = convert_mv_rate_to_radiotap(prxpd->rx_rate);
^ permalink raw reply related
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: John W. Linville @ 2010-05-27 18:41 UTC (permalink / raw)
To: Bob Copeland
Cc: Weedy, Richard Farina, Gábor Stefanik, linux-wireless,
Johannes Berg
In-Reply-To: <AANLkTil5yP2xZ5sBXmDEVCHvD2oim92R-dfHx6f-pLOS@mail.gmail.com>
On Thu, May 27, 2010 at 02:31:12PM -0400, Bob Copeland wrote:
> On Thu, May 27, 2010 at 1:40 PM, Weedy <weedy2887@gmail.com> wrote:
>
> >> Weedy, if you want reported-by credit can you give your full name and
> >> preferred email address?
> > Do I have to? I don't really want to tie my name to this email :/
>
> Honestly I don't know what reported-by policy is (other than I should
> get your consent first). I guess John can weigh in whether:
>
> Reported-by: weedy2887@gmail.com
>
> is acceptable. For S-o-b, the rule is no anonymous or pseudonymous
> contributions. Of course, you don't have to be credited, but your
> bisection was a huge help in pinning it down :)
It isn't necessary, and I suspect that someone that doesn't want his
name attached doesn't wanted the addition of any further unnecessary
evidence in the git changelogs either. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox