* [PATCH] wireless: remove unnecessary reg_same_country_ie_hint
From: John W. Linville @ 2010-07-20 19:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
In-Reply-To: <AANLkTinPnjtbDM8AE7gKMA9lBnIJDqG-KXc04ynZ6wLg@mail.gmail.com>
"Might as well remove reg_same_country_ie_hint() completely since we
already dealt with suspend/resume through the regulatory hint
disconnect." -- Luis
Reported-by: Luis R. Rodriguez <mcgrof@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/reg.c | 45 ---------------------------------------------
1 files changed, 0 insertions(+), 45 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 678d0bd..48baf28 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1483,39 +1483,6 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
}
EXPORT_SYMBOL(regulatory_hint);
-/* Caller must hold reg_mutex */
-static bool reg_same_country_ie_hint(struct wiphy *wiphy,
- char *alpha2, enum environment_cap env)
-{
- struct wiphy *request_wiphy;
-
- assert_reg_lock();
-
- if (unlikely(last_request->initiator !=
- NL80211_REGDOM_SET_BY_COUNTRY_IE))
- return false;
-
- request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
-
- if (!request_wiphy)
- return false;
-
- if (likely(request_wiphy != wiphy))
- return (last_request->alpha2[0] == alpha2[0] &&
- last_request->alpha2[1] == alpha2[1] &&
- last_request->country_ie_env == env);
- /*
- * We should not have let these through at this point, they
- * should have been picked up earlier by the first alpha2 check
- * on the device
- */
- if (WARN_ON((last_request->alpha2[0] == alpha2[0] &&
- last_request->alpha2[1] == alpha2[1] &&
- last_request->country_ie_env == env )))
- return true;
- return false;
-}
-
/*
* We hold wdev_lock() here so we cannot hold cfg80211_mutex() and
* therefore cannot iterate over the rdev list here.
@@ -1560,18 +1527,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
wiphy_idx_valid(last_request->wiphy_idx)))
goto out;
- /*
- * This will not happen right now but we leave it here for the
- * the future when we want to add suspend/resume support and having
- * the user move to another country after doing so, or having the user
- * move to another AP. Right now we just trust the first AP.
- *
- * If we hit this before we add this support we want to be informed of
- * it as it would indicate a mistake in the current design
- */
- if (WARN_ON(reg_same_country_ie_hint(wiphy, alpha2, env)))
- goto free_rd_out;
-
request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
if (!request)
goto free_rd_out;
--
1.7.1.1
^ permalink raw reply related
* Compat-wireless release for 2010-07-20 is baked
From: Compat-wireless cronjob account @ 2010-07-20 19:06 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
7b8245a..8444e0f master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
c6d612697..ce38023 history -> origin/history
+ 058395f...d8d58e7 master -> origin/master (forced update)
a9f7f2e..d0c6f62 stable -> origin/stable
* [new tag] next-20100720 -> next-20100720
compat-wireless code metrics
494339 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4587 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2464 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100720
compat-wireless release: compat-wireless-2010-07-13-3-g1a05138
^ permalink raw reply
* Re: [PATCH v3] mac80211: remove wep dependency
From: John W. Linville @ 2010-07-20 18:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279623588.3706.17.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 12:59:48PM +0200, Johannes Berg wrote:
> On Wed, 2010-07-07 at 15:07 -0400, John W. Linville wrote:
> > The current mac80211 code assumes that WEP is always available. If WEP
> > fails to initialize, ieee80211_register_hw will always fail.
> >
> > In some cases (e.g. FIPS certification), the cryptography used by WEP is
> > unavailable. However, in such cases there is no good reason why CCMP
> > encryption (or even no link level encryption) cannot be used. So, this
> > patch removes mac80211's assumption that WEP (and TKIP) will always be
> > available for use.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > v3 -> actually post changed patch...
> > v2 -> make it safe to call ieee80211_wep_free even if ieee80211_wep_init
> > had failed
>
> I think this is missing a change like this:
>
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1228,6 +1228,10 @@ static int ieee80211_scan(struct wiphy *wiphy,
> static int ieee80211_auth(struct wiphy *wiphy, struct net_device *dev,
> struct cfg80211_auth_request *req)
> {
> + if (req->auth_type == NL80211_AUTHTYPE_SHARED_KEY &&
> + IS_ERR(sdata->local->wep_tx_tfm))
> + return -EINVAL;
> +
> return ieee80211_mgd_auth(IEEE80211_DEV_TO_SUB_IF(dev), req);
> }
>
>
> since otherwise you could end up trying to encrypt the auth frame with
> the uninitialised WEP TFM?
Yes, I think that makes sense. The check in ieee80211_wep_encrypt_data
will make it safe either way, but that will trigger a warning
in ieee80211_send_auth and leave us unable to return an error to
the ieee80211_auth caller. Also, it will send the auth request
unencrypted...
Care to send that as a "real" patch? :-)
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: [PATCH v2] mwl8k: correct/silence sparse warnings
From: Lennert Buytenhek @ 2010-07-20 18:53 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279651154-11985-1-git-send-email-linville@tuxdriver.com>
On Tue, Jul 20, 2010 at 02:39:14PM -0400, John W. Linville wrote:
> drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
> drivers/net/wireless/mwl8k.c:1541:21: got int
> drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
> drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
>
> At least the last one looks like a real bug...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Looks good!
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
^ permalink raw reply
* [PATCH v2] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Lennert Buytenhek, John W. Linville
In-Reply-To: <1279650123.3706.45.camel@jlt3.sipsolutions.net>
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/mwl8k.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index cd37b2a..e3f130c 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -314,13 +314,15 @@ static const struct ieee80211_rate mwl8k_rates_50[] = {
#define MWL8K_CMD_SET_NEW_STN 0x1111 /* per-vif */
#define MWL8K_CMD_UPDATE_STADB 0x1123
-static const char *mwl8k_cmd_name(u16 cmd, char *buf, int bufsize)
+static const char *mwl8k_cmd_name(__le16 cmd, char *buf, int bufsize)
{
+ u16 command = le16_to_cpu(cmd);
+
#define MWL8K_CMDNAME(x) case MWL8K_CMD_##x: do {\
snprintf(buf, bufsize, "%s", #x);\
return buf;\
} while (0)
- switch (cmd & ~0x8000) {
+ switch (command & ~0x8000) {
MWL8K_CMDNAME(CODE_DNLD);
MWL8K_CMDNAME(GET_HW_SPEC);
MWL8K_CMDNAME(SET_HW_SPEC);
@@ -1538,7 +1540,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
unsigned long timeout = 0;
u8 buf[32];
- cmd->result = 0xffff;
+ cmd->result = (__force __le16) 0xffff;
dma_size = le16_to_cpu(cmd->length);
dma_addr = pci_map_single(priv->pdev, cmd, dma_size,
PCI_DMA_BIDIRECTIONAL);
@@ -1842,22 +1844,22 @@ static int mwl8k_cmd_get_hw_spec_ap(struct ieee80211_hw *hw)
priv->sta_macids_supported = 0x00000000;
off = le32_to_cpu(cmd->wcbbase0) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[0].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[0].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32(priv->rxq[0].rxd_dma, priv->sram + off);
off = le32_to_cpu(cmd->rxrdptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32(priv->rxq[0].rxd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase1) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[1].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[1].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase2) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[2].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[2].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase3) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[3].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[3].txd_dma, priv->sram + off);
}
kfree(cmd);
@@ -3052,7 +3054,7 @@ static int mwl8k_cmd_update_stadb_add(struct ieee80211_hw *hw,
p->peer_type = MWL8K_PEER_TYPE_ACCESSPOINT;
p->basic_caps = cpu_to_le16(vif->bss_conf.assoc_capability);
p->ht_support = sta->ht_cap.ht_supported;
- p->ht_caps = sta->ht_cap.cap;
+ p->ht_caps = cpu_to_le16(sta->ht_cap.cap);
p->extended_ht_caps = (sta->ht_cap.ampdu_factor & 3) |
((sta->ht_cap.ampdu_density & 7) << 2);
if (hw->conf.channel->band == IEEE80211_BAND_2GHZ)
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: correct sparse warning in rt2x00debug.c
From: Ivo Van Doorn @ 2010-07-20 18:32 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, gwingerde
In-Reply-To: <1279650227-11089-1-git-send-email-linville@tuxdriver.com>
On Tue, Jul 20, 2010 at 8:23 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> CHECK drivers/net/wireless/rt2x00/rt2x00debug.c
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: expected restricted __le32 [usertype] chip_rev
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: got restricted __le16 [usertype] <noident>
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thanks.
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dump.h b/drivers/net/wireless/rt2x00/rt2x00dump.h
> index 6df2e0b..5d6e0b8 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dump.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00dump.h
> @@ -116,7 +116,7 @@ struct rt2x00dump_hdr {
>
> __le16 chip_rt;
> __le16 chip_rf;
> - __le32 chip_rev;
> + __le16 chip_rev;
>
> __le16 type;
> __u8 queue_index;
> --
> 1.7.1.1
>
>
^ permalink raw reply
* [PATCH] libipw: correct sparse warnings and mark some variables static
From: John W. Linville @ 2010-07-20 18:17 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/ipw2x00/libipw_module.c
drivers/net/wireless/ipw2x00/libipw_module.c:65:21: warning: symbol 'libipw_config_ops' was not declared. Should it be static?
drivers/net/wireless/ipw2x00/libipw_module.c:66:6: warning: symbol 'libipw_wiphy_privid' was not declared. Should it be static?
CHECK drivers/net/wireless/ipw2x00/libipw_wx.c
drivers/net/wireless/ipw2x00/libipw_wx.c:415:17: warning: symbol 'ssid' shadows an earlier one
drivers/net/wireless/ipw2x00/libipw_wx.c:324:9: originally declared here
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/libipw_module.c | 4 ++--
drivers/net/wireless/ipw2x00/libipw_wx.c | 4 ----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/libipw_module.c b/drivers/net/wireless/ipw2x00/libipw_module.c
index 5596540..32dee2c 100644
--- a/drivers/net/wireless/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/ipw2x00/libipw_module.c
@@ -62,8 +62,8 @@ MODULE_DESCRIPTION(DRV_DESCRIPTION);
MODULE_AUTHOR(DRV_COPYRIGHT);
MODULE_LICENSE("GPL");
-struct cfg80211_ops libipw_config_ops = { };
-void *libipw_wiphy_privid = &libipw_wiphy_privid;
+static struct cfg80211_ops libipw_config_ops = { };
+static void *libipw_wiphy_privid = &libipw_wiphy_privid;
static int libipw_networks_allocate(struct libipw_device *ieee)
{
diff --git a/drivers/net/wireless/ipw2x00/libipw_wx.c b/drivers/net/wireless/ipw2x00/libipw_wx.c
index 3633c66..8a4bae4 100644
--- a/drivers/net/wireless/ipw2x00/libipw_wx.c
+++ b/drivers/net/wireless/ipw2x00/libipw_wx.c
@@ -411,10 +411,6 @@ int libipw_wx_set_encode(struct libipw_device *ieee,
/* If a new key was provided, set it up */
if (erq->length > 0) {
-#ifdef CONFIG_LIBIPW_DEBUG
- DECLARE_SSID_BUF(ssid);
-#endif
-
len = erq->length <= 5 ? 5 : 13;
memcpy(sec.keys[key], keybuf, erq->length);
if (len > erq->length)
--
1.7.1.1
^ permalink raw reply related
* [PATCH] rt2x00: correct sparse warning in rt2x00debug.c
From: John W. Linville @ 2010-07-20 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: ivdoorn, gwingerde, John W. Linville
CHECK drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: expected restricted __le32 [usertype] chip_rev
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dump.h b/drivers/net/wireless/rt2x00/rt2x00dump.h
index 6df2e0b..5d6e0b8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dump.h
+++ b/drivers/net/wireless/rt2x00/rt2x00dump.h
@@ -116,7 +116,7 @@ struct rt2x00dump_hdr {
__le16 chip_rt;
__le16 chip_rf;
- __le32 chip_rev;
+ __le16 chip_rev;
__le16 type;
__u8 queue_index;
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Lennert Buytenhek
In-Reply-To: <1279650123.3706.45.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 08:22:03PM +0200, Johannes Berg wrote:
> On Tue, 2010-07-20 at 14:07 -0400, John W. Linville wrote:
>
> > off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
> > - iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
> > + iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
> > + priv->sram + off);
>
> Those don't seem right, it looks more like somebody thought they needed
> to byteswap the iowrite because PCI(e) is little endian, and were wrong?
Yeah, I agree. I was going with the thought that "it's working, so
I guess it is right". But then, development was probably done on an
LE system...
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: [RFC] wireless: only use alpha2 regulatory information from country IE
From: Luis R. Rodriguez @ 2010-07-20 18:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, kyle
In-Reply-To: <1279220807-18245-1-git-send-email-linville@tuxdriver.com>
On Thu, Jul 15, 2010 at 12:06 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> The meaning and/or usage of the country IE is somewhat poorly defined.
> In practice, this means that regulatory rulesets in a country IE are
> often incomplete and might be untrustworthy. This removes the code
> associated with interpreting those rulesets while preserving respect
> for country "alpha2" codes also contained in the country IE.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> @@ -2026,13 +1501,17 @@ static bool reg_same_country_ie_hint(struct wiphy *wiphy,
> return false;
>
> if (likely(request_wiphy != wiphy))
> - return !country_ie_integrity_changes(country_ie_checksum);
> + return (last_request->alpha2[0] == alpha2[0] &&
> + last_request->alpha2[1] == alpha2[1] &&
> + last_request->country_ie_env == env);
> /*
> * We should not have let these through at this point, they
> * should have been picked up earlier by the first alpha2 check
> * on the device
> */
> - if (WARN_ON(!country_ie_integrity_changes(country_ie_checksum)))
> + if (WARN_ON((last_request->alpha2[0] == alpha2[0] &&
> + last_request->alpha2[1] == alpha2[1] &&
> + last_request->country_ie_env == env )))
> return true;
> return false;
> }
Might as well remove reg_same_country_ie_hint() completely since we
already dealt with suspend/resume through the regulatory hint
disconnect. But this can technically be done through a secondary patch
to clarify this particular removal. Other than that this looks good.
Luis
^ permalink raw reply
* Re: [PATCH] mwl8k: correct/silence sparse warnings
From: Johannes Berg @ 2010-07-20 18:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Lennert Buytenhek
In-Reply-To: <1279649222-3042-1-git-send-email-linville@tuxdriver.com>
On Tue, 2010-07-20 at 14:07 -0400, John W. Linville wrote:
> off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
> - iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
> + iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
> + priv->sram + off);
Those don't seem right, it looks more like somebody thought they needed
to byteswap the iowrite because PCI(e) is little endian, and were wrong?
johannes
^ permalink raw reply
* [PATCH] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Lennert Buytenhek, John W. Linville
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/mwl8k.c | 28 ++++++++++++++++++----------
1 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index cd37b2a..3576071 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -314,13 +314,15 @@ static const struct ieee80211_rate mwl8k_rates_50[] = {
#define MWL8K_CMD_SET_NEW_STN 0x1111 /* per-vif */
#define MWL8K_CMD_UPDATE_STADB 0x1123
-static const char *mwl8k_cmd_name(u16 cmd, char *buf, int bufsize)
+static const char *mwl8k_cmd_name(__le16 cmd, char *buf, int bufsize)
{
+ u16 command = le16_to_cpu(cmd);
+
#define MWL8K_CMDNAME(x) case MWL8K_CMD_##x: do {\
snprintf(buf, bufsize, "%s", #x);\
return buf;\
} while (0)
- switch (cmd & ~0x8000) {
+ switch (command & ~0x8000) {
MWL8K_CMDNAME(CODE_DNLD);
MWL8K_CMDNAME(GET_HW_SPEC);
MWL8K_CMDNAME(SET_HW_SPEC);
@@ -1538,7 +1540,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
unsigned long timeout = 0;
u8 buf[32];
- cmd->result = 0xffff;
+ cmd->result = (__force __le16) 0xffff;
dma_size = le16_to_cpu(cmd->length);
dma_addr = pci_map_single(priv->pdev, cmd, dma_size,
PCI_DMA_BIDIRECTIONAL);
@@ -1842,22 +1844,28 @@ static int mwl8k_cmd_get_hw_spec_ap(struct ieee80211_hw *hw)
priv->sta_macids_supported = 0x00000000;
off = le32_to_cpu(cmd->wcbbase0) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[0].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[0].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->rxrdptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase1) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[1].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[1].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase2) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[2].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[2].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase3) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[3].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[3].txd_dma),
+ priv->sram + off);
}
kfree(cmd);
@@ -3052,7 +3060,7 @@ static int mwl8k_cmd_update_stadb_add(struct ieee80211_hw *hw,
p->peer_type = MWL8K_PEER_TYPE_ACCESSPOINT;
p->basic_caps = cpu_to_le16(vif->bss_conf.assoc_capability);
p->ht_support = sta->ht_cap.ht_supported;
- p->ht_caps = sta->ht_cap.cap;
+ p->ht_caps = cpu_to_le16(sta->ht_cap.cap);
p->extended_ht_caps = (sta->ht_cap.ampdu_factor & 3) |
((sta->ht_cap.ampdu_density & 7) << 2);
if (hw->conf.channel->band == IEEE80211_BAND_2GHZ)
--
1.7.1.1
^ permalink raw reply related
* [PATCH] ipw2100: mark ipw2100_pm_qos_req static
From: John W. Linville @ 2010-07-20 18:12 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index 18ebd60..5165db9 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -174,7 +174,7 @@ that only one external action is invoked at a time.
#define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2100 Network Driver"
#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"
-struct pm_qos_request_list *ipw2100_pm_qos_req;
+static struct pm_qos_request_list *ipw2100_pm_qos_req;
/* Debugging stuff */
#ifdef CONFIG_IPW2100_DEBUG
--
1.7.1.1
^ permalink raw reply related
* [PATCH] ath9k: correct sparse identified endian bug in ath_paprd_calibrate
From: John W. Linville @ 2010-07-20 17:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26: expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26: got int
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index d45cf0b..6cf0410 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -279,7 +279,7 @@ void ath_paprd_calibrate(struct work_struct *work)
hdr = (struct ieee80211_hdr *)skb->data;
ftype = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_NULLFUNC;
hdr->frame_control = cpu_to_le16(ftype);
- hdr->duration_id = 10;
+ hdr->duration_id = cpu_to_le16(10);
memcpy(hdr->addr1, hw->wiphy->perm_addr, ETH_ALEN);
memcpy(hdr->addr2, hw->wiphy->perm_addr, ETH_ALEN);
memcpy(hdr->addr3, hw->wiphy->perm_addr, ETH_ALEN);
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Gábor Stefanik @ 2010-07-20 16:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Gnedt, linux-wireless, John W. Linville
In-Reply-To: <1279631096.3706.33.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 3:04 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-07-20 at 01:28 +0200, David Gnedt wrote:
>> Am 2010-07-19 23:06, schrieb Gábor Stefanik:
>> > (BTW, I say that a GIWFREQ on a monitor interface should always return
>> > the channel the PHY is tuned to at the moment when it is issued. Most
>> > tools seem to expect this behavior.)
>>
>> I agree, that would be the expected behaviour.
>>
>> I am not very familar with the entire wireless subsystem yet, but wouldn't that
>> imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
>
> Yes, I think so.
>
>> Because if the card is hopping channels (e.g. because of 2 station interfaces on
>> different channels), only the driver itself can tell what's really the current
>> channel.
>
> Right. Although in that case I'm not sure we should be telling userspace
> what channel the monitor interface is on, since there's no single
> channel it is on, and I certainly hope userspace won't be requesting the
> channel many times per second!
Well, there is no reason why channel-hopping due to multiple virtual
PHYs and channel-hopping by userspace control (see Kismet) should
behave differently GIWFREQ-wise. Also, userspace (apart from maybe
hostapd - I haven't looked into that at all) seems to expect GIWFREQ
on a monitor interface to unconditionally return the channel the radio
is tuned to at the moment.
>
>> Nevertheless a default implementation for this new "get_channel" can be written
>> at mac80211 level (or even cfg80211?), which tries to find the current channel
>> by looking at all virtual interfaces, so only mac80211 drivers which allow
>> multiple channels (and non-mac80211 drivers) need to implement it.
>
> Indeed, but I think mac80211 would be more appropriate than cfg80211
> since the latter won't really have all the information unless it makes a
> whole bunch of assumptions that we'll eventually have to reconsider.
>
> johannes
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] wireless: mark cfg80211_is_all_idle as static
From: John W. Linville @ 2010-07-20 16:33 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/sme.c
net/wireless/sme.c:38:6: warning: symbol 'cfg80211_is_all_idle' was not declared. Should it be static?
It is not used elsewhere, so mark it static.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/sme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 72222f0..a8c2d6b 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -35,7 +35,7 @@ struct cfg80211_conn {
bool auto_auth, prev_bssid_valid;
};
-bool cfg80211_is_all_idle(void)
+static bool cfg80211_is_all_idle(void)
{
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
--
1.7.1.1
^ permalink raw reply related
* [PATCH] wireless: correct sparse warning in generated regdb.c
From: John W. Linville @ 2010-07-20 16:30 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/regdb.c
net/wireless/regdb.c:8:34: warning: symbol 'reg_regdb' was not declared. Should it be static?
net/wireless/regdb.c:11:5: warning: symbol 'reg_regdb_size' was not declared. Should it be static?
Simply include the also generated regdb.h.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/genregdb.awk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/wireless/genregdb.awk b/net/wireless/genregdb.awk
index 3cc9e69..53c143f 100644
--- a/net/wireless/genregdb.awk
+++ b/net/wireless/genregdb.awk
@@ -21,6 +21,7 @@ BEGIN {
print ""
print "#include <linux/nl80211.h>"
print "#include <net/cfg80211.h>"
+ print "#include \"regdb.h\""
print ""
regdb = "const struct ieee80211_regdomain *reg_regdb[] = {\n"
}
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] wireless: correct sparse warning in wext-compat.c
From: Johannes Berg @ 2010-07-20 16:39 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279643215-13498-1-git-send-email-linville@tuxdriver.com>
On Tue, 2010-07-20 at 12:26 -0400, John W. Linville wrote:
> CHECK net/wireless/wext-compat.c
> net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?
>
> Add declaration in cfg80211.h. Also add an EXPORT_SYMBOL_GPL, since all
> the peer functions have it.
Or it could just be static, since it seems unlikely somebody wants to
use it for orinoco or a similar half-converted driver? Anyway I don't
mind this patch either.
johannes
^ permalink raw reply
* [PATCH] wireless: correct sparse warning in wext-compat.c
From: John W. Linville @ 2010-07-20 16:26 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/wext-compat.c
net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?
Add declaration in cfg80211.h. Also add an EXPORT_SYMBOL_GPL, since all
the peer functions have it.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
include/net/cfg80211.h | 4 ++++
net/wireless/wext-compat.c | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9b8b3f4..f68ae54 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1963,6 +1963,10 @@ int cfg80211_wext_giwap(struct net_device *dev,
struct iw_request_info *info,
struct sockaddr *ap_addr, char *extra);
+int cfg80211_wext_siwpmksa(struct net_device *dev,
+ struct iw_request_info *info,
+ struct iw_point *data, char *extra);
+
/*
* callbacks for asynchronous cfg80211 methods, notification
* functions and BSS handling helpers
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 1ff1e9f..bb5e0a5 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -1471,6 +1471,7 @@ int cfg80211_wext_siwpmksa(struct net_device *dev,
return -EOPNOTSUPP;
}
}
+EXPORT_SYMBOL_GPL(cfg80211_wext_siwpmksa);
static const iw_handler cfg80211_handlers[] = {
[IW_IOCTL_IDX(SIOCGIWNAME)] = (iw_handler) cfg80211_wext_giwname,
--
1.7.1.1
^ permalink raw reply related
* [PATCH] wireless: correct sparse warning in lib80211_crypt_tkip.c
From: John W. Linville @ 2010-07-20 16:11 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/lib80211_crypt_tkip.c
net/wireless/lib80211_crypt_tkip.c:581:27: warning: cast to restricted __le16
Caused by dereferencing a "u8 *" and passing it to le16_to_cpu...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/lib80211_crypt_tkip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/lib80211_crypt_tkip.c b/net/wireless/lib80211_crypt_tkip.c
index 8cbdb32..a7f9956 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -578,7 +578,7 @@ static void michael_mic_hdr(struct sk_buff *skb, u8 * hdr)
}
if (ieee80211_is_data_qos(hdr11->frame_control)) {
- hdr[12] = le16_to_cpu(*ieee80211_get_qos_ctl(hdr11))
+ hdr[12] = le16_to_cpu(*((__le16 *)ieee80211_get_qos_ctl(hdr11)))
& IEEE80211_QOS_CTL_TID_MASK;
} else
hdr[12] = 0; /* priority */
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bob Copeland @ 2010-07-20 14:52 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <201007201420.49305.br1@einfach.org>
On Tue, Jul 20, 2010 at 02:20:49PM +0900, Bruno Randolf wrote:
> > @@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
> > void
> > ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> > {
> > +#if 0
(The above, by the way, is a mistake I'll fix; I forgot to remove it after
doing patch 1/3.)
> again, here my same concerns: printing the reasons for resets is something
> which is useful on embedded boards and production setups which can't have
> tracing enabled. which is why i want to object against this change!
What Johannes said wrt performance: during tracing, only the binary
representations of the data are written to the trace ring buffer, so
unlike the current debug code, we aren't doing printk formatting until
the trace buffer is read. You can save the raw binary data from the
trace and do formatting on another machine.
Another advantage is better granularity: if you only care about watching
tx on the cab queue, you can dynamically filter based on the tracepoint
arguments, something like:
# echo "qnum == 6" > /debug/tracing/events/ath5k/ath5k_tx/filter
With the debug printks, you have to hack the driver or grep and hope
the printk buffer didn't overflow and spill what you were looking for.
One thing I do need to look into is reducing the size, right now
text size went up by about 4k when adding these tracepoints.
> also adding a reason argument to the reset function just for tracing seems to
> be... umm... not so nice... couldn't you add the tracepoints before?
Yeah, it's kind of hacky, but not without precedent; ieee80211_wake_queues
does something similar. But I'm not tied to it, adding another tracepoint
for when and why the reset was scheduled would be OK, or maybe we just
drop the reason and plan on using ftrace to figure that out. It's still
worth keeping tracepoints when reset actually runs and finishes since that
is the most useful information for tracking down race conditions.
> and: didn't we want to split channel change out of reset anyhow?
Of course. When we do so we probably won't need the frequency argument,
but I think that's otherwise orthogonal to this...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Johannes Berg @ 2010-07-20 13:04 UTC (permalink / raw)
To: David Gnedt; +Cc: Gábor Stefanik, linux-wireless, John W. Linville
In-Reply-To: <4C44DFBB.6070604@davizone.at>
On Tue, 2010-07-20 at 01:28 +0200, David Gnedt wrote:
> Am 2010-07-19 23:06, schrieb Gábor Stefanik:
> > (BTW, I say that a GIWFREQ on a monitor interface should always return
> > the channel the PHY is tuned to at the moment when it is issued. Most
> > tools seem to expect this behavior.)
>
> I agree, that would be the expected behaviour.
>
> I am not very familar with the entire wireless subsystem yet, but wouldn't that
> imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
Yes, I think so.
> Because if the card is hopping channels (e.g. because of 2 station interfaces on
> different channels), only the driver itself can tell what's really the current
> channel.
Right. Although in that case I'm not sure we should be telling userspace
what channel the monitor interface is on, since there's no single
channel it is on, and I certainly hope userspace won't be requesting the
channel many times per second!
> Nevertheless a default implementation for this new "get_channel" can be written
> at mac80211 level (or even cfg80211?), which tries to find the current channel
> by looking at all virtual interfaces, so only mac80211 drivers which allow
> multiple channels (and non-mac80211 drivers) need to implement it.
Indeed, but I think mac80211 would be more appropriate than cfg80211
since the latter won't really have all the information unless it makes a
whole bunch of assumptions that we'll eventually have to reconsider.
johannes
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 12:05 UTC (permalink / raw)
To: Holger Schurig; +Cc: Bob Copeland, linux-wireless, ath5k-devel
In-Reply-To: <201007201350.48923.holgerschurig@gmail.com>
I understand that it's not the way I'm supposed to do it. What I'm
saying is that it's not working, whereas the other way is! :(
I will play around some more with it tomorrow. It's still baffling as
to why the driver is not beaconing until there is another node tho...
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 9:50 PM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
>> iw phy phy0 interface add wlan0 type adhoc
>> iw wlan0 set channel 36
>> iwconfig wlan0 channel 36
>> iwconfig wlan0 essid txctest
>
> I can't think of ANY reason why you do that. Use "iw", not "iwconfig".
>
> All the last three commands should be replaced with one single "iw dev wlan0
> ibss join myibss XXXX", where XXXX is the frequency for channel 36. If in
> doubt what this is, just do "iw list" and you'll see it.
>
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Holger Schurig @ 2010-07-20 11:50 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: Bob Copeland, linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
> iw phy phy0 interface add wlan0 type adhoc
> iw wlan0 set channel 36
> iwconfig wlan0 channel 36
> iwconfig wlan0 essid txctest
I can't think of ANY reason why you do that. Use "iw", not "iwconfig".
All the last three commands should be replaced with one single "iw dev wlan0
ibss join myibss XXXX", where XXXX is the frequency for channel 36. If in
doubt what this is, just do "iw list" and you'll see it.
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Bob Copeland @ 2010-07-20 11:20 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
[please don't top post]
On Tue, Jul 20, 2010 at 04:39:29PM +1000, Jonathan Guerin wrote:
> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
> the commands you mentioned, but no luck. If I monitor the interface
> from another station, the ath5k drive never appears to beacon.
What does "iw phy phy0 info" show?
--
Bob Copeland %% www.bobcopeland.com
^ 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