* Re: wireless tree rebased (from 5/28), Broadcom bits dropped
From: Gustavo Padovan @ 2013-06-05 16:49 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Samuel Ortiz, Luciano Coelho
In-Reply-To: <20130605143700.GA2271@tuxdriver.com>
* John W. Linville <linville@tuxdriver.com> [2013-06-05 10:37:01 -0400]:
> On Wed, Jun 05, 2013 at 08:59:46AM +0200, Johannes Berg wrote:
> > On Tue, 2013-06-04 at 17:53 -0400, John W. Linville wrote:
> > > I messed this up too -- bad day...
> > >
> > > If you pulled in between the earlier message and this one, please
> > > do so again. If you saw this message before taking any action to
> > > clean-up my mess, then you are OK.
> >
> > This was confusing, I think you rebased around some merges instead of
> > redoing the merges? My patches are in, but suddenly got new commit IDs,
> > e.g. fa331699d05ce1d0d4896eb4a137cfae50d7afde (new) vs.
> > c2c15e215e860c99b86ddfc4be4bb25cf180fed0 for "mac80211: work around
> > broken APs not including HT info".
> >
> > This will cause git to pull them in again when I send a new pull
> > request, so it would have been nicer to redo the merges, but anyway ...
> > just a heads-up for everyone that here it's a bit confusing now.
> >
> > johannes
>
> You are right, I could have done it better with regard to your tree.
> I probably should redo that part.
>
> The Bluetooth tree had pulled the wireless tree and applied their
> patches on top of the brcmfmac/brcmsmac series that I removed. So,
> their pull couldn't be redone.
The Bluetooth commit IDs have changed too, but I just did a rebase on top
your tree and it is all set here now. I'll wait for your rebase today and see
how things goes.
Gustavo
^ permalink raw reply
* Re: wireless tree rebased (from 5/28), Broadcom bits dropped
From: Samuel Ortiz @ 2013-06-05 16:40 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Gustavo Padovan, Luciano Coelho
In-Reply-To: <20130605143700.GA2271@tuxdriver.com>
Hi John,
On Wed, Jun 05, 2013 at 10:37:01AM -0400, John W. Linville wrote:
> On Wed, Jun 05, 2013 at 08:59:46AM +0200, Johannes Berg wrote:
> > On Tue, 2013-06-04 at 17:53 -0400, John W. Linville wrote:
> > > I messed this up too -- bad day...
> > >
> > > If you pulled in between the earlier message and this one, please
> > > do so again. If you saw this message before taking any action to
> > > clean-up my mess, then you are OK.
> >
> > This was confusing, I think you rebased around some merges instead of
> > redoing the merges? My patches are in, but suddenly got new commit IDs,
> > e.g. fa331699d05ce1d0d4896eb4a137cfae50d7afde (new) vs.
> > c2c15e215e860c99b86ddfc4be4bb25cf180fed0 for "mac80211: work around
> > broken APs not including HT info".
> >
> > This will cause git to pull them in again when I send a new pull
> > request, so it would have been nicer to redo the merges, but anyway ...
> > just a heads-up for everyone that here it's a bit confusing now.
> >
> > johannes
>
> You are right, I could have done it better with regard to your tree.
> I probably should redo that part.
>
> The Bluetooth tree had pulled the wireless tree and applied their
> patches on top of the brcmfmac/brcmsmac series that I removed. So,
> their pull couldn't be redone.
>
> I think I can fix the wireless tree and preserve the original mac80211
> tree commits. Everyone please hold off on doing anything else here, as
> I'm a bit busy and won't be able to get to this before this afternoon
> (Eastern USA time).
>
> Anyone object to one more wireless tree rebase today?
I was about to send you a pull request against your 2nd rebase. I'll wait
until the new one is done, please keep us posted.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Vladimir Kondratiev @ 2013-06-05 16:26 UTC (permalink / raw)
To: Arend van Spriel
Cc: Johannes Berg, Malinen, Jouni, Peer, Ilan,
linux-wireless@vger.kernel.org, Rodriguez, Luis,
John W . Linville
In-Reply-To: <51AEF8F4.2020809@broadcom.com>
On Wednesday, June 05, 2013 10:38:12 AM Arend van Spriel wrote:
> >
> > The next step would be P2P-listen offload, which is more interesting for
> > being discoverable, and should also have probe request offload similar
> > to what we're discussing here.
>
>
> Ah, I thought that was included. The WFA spec is a bit confusing using
> terms 'phases' and 'states'. There is a SCAN phase and a FIND phase.
> During the FIND phase a device can be in SEARCH or LISTEN state. I know
> it is all terminology, but I was confused. At least the commit message
> seems to imply both states are offloaded.
>
Arend,
you are correct. Briefly, P2P flow consists of the following phases:
1) scan - just regular scan, to find infrastructure ESS as well
2) find - in this phase, device toggles between states:
2.1) search - similar to scan on social channels, but not exactly. On 60g, search is _NOT_ scan
2.2) listen - similar to ROC on listen channel, but again, on 60g, listen is _NOT_ ROC
Then, this follows by GO negotiation etc.
Thanks, Vladimir
^ permalink raw reply
* Re: [PATCH 2/7] ath9k: Enable WoW only for AR9462
From: Sujith Manoharan @ 2013-06-05 16:13 UTC (permalink / raw)
To: Mohammed Shafi
Cc: Stanislaw Gruszka, John Linville, linux-wireless Mailing List
In-Reply-To: <CAD2nsn0=W+KU4S7cOzAQ1C5mt_GUzAYDNjtwhjvw-C7NM_4eQQ@mail.gmail.com>
Mohammed Shafi wrote:
> i remember i tested wow with AR9462, AR9485, AR9280, AR9287, though quirky
> with AR9002 families. Does it really makes sense to remove them ? Its bit
> painful to find the bugs in HAL code when we do it later, thoughts ?
WoW has to be tested quite a bit for it to be fully operational and it's largely
affected by the platform/chip quirks. Our internal test cycles cover various aspects
of WoW to make sure it doesn't affect normal usage and we never covered
the AR9002 family. Keeping untested, possibly incomplete code is not really useful...
Stanislaw raised a concern about a potential RH customer - if that happens, the patch
can be reverted (though, AR9462 would be a much better choice).
Sujith
^ permalink raw reply
* Re: [PATCHv4 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Johannes Berg @ 2013-06-05 15:40 UTC (permalink / raw)
To: Arend van Spriel
Cc: Antonio Quartulli, linux-wireless, Antonio Quartulli,
brcm80211-dev-list
In-Reply-To: <51AF5AB7.2070703@broadcom.com>
On Wed, 2013-06-05 at 17:35 +0200, Arend van Spriel wrote:
> On 06/05/2013 05:34 PM, Arend van Spriel wrote:
> > On 06/05/2013 05:09 PM, Antonio Quartulli wrote:
> >> From: Antonio Quartulli <antonio@open-mesh.com>
> >>
> >> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> >> to be sent on the one currently in use by the device.
> >> Make the implementation of mgmt_tx correctly handle this
> >> case
> >>
> >> Cc: Arend van Spriel <arend@broadcom.com>
> >> Cc: brcm80211-dev-list@broadcom.com
> >> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> >> ---
> >
> > For my name above you (or Johannes) can change 'Cc:' to 'Acked-by:'
>
> Or John?
I think I'll take the whole series if that's ok with everyone, otherwise
we get synchronisation issues between John and myself :)
johannes
^ permalink raw reply
* Re: [PATCHv4 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Arend van Spriel @ 2013-06-05 15:35 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Johannes Berg, linux-wireless, Antonio Quartulli,
brcm80211-dev-list
In-Reply-To: <51AF5A92.9050906@broadcom.com>
On 06/05/2013 05:34 PM, Arend van Spriel wrote:
> On 06/05/2013 05:09 PM, Antonio Quartulli wrote:
>> From: Antonio Quartulli <antonio@open-mesh.com>
>>
>> cfg80211 passes a NULL channel to mgmt_tx if the frame has
>> to be sent on the one currently in use by the device.
>> Make the implementation of mgmt_tx correctly handle this
>> case
>>
>> Cc: Arend van Spriel <arend@broadcom.com>
>> Cc: brcm80211-dev-list@broadcom.com
>> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
>> ---
>
> For my name above you (or Johannes) can change 'Cc:' to 'Acked-by:'
Or John?
> Gr. AvS
>
>> v3:
>> - read current freq from the firmware via BRCMF_C_GET_CHANNEL
>>
>> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 15
>> ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>
^ permalink raw reply
* Re: [PATCHv4 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Arend van Spriel @ 2013-06-05 15:34 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Johannes Berg, linux-wireless, Antonio Quartulli,
brcm80211-dev-list
In-Reply-To: <1370444989-2095-2-git-send-email-ordex@autistici.org>
On 06/05/2013 05:09 PM, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> to be sent on the one currently in use by the device.
> Make the implementation of mgmt_tx correctly handle this
> case
>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
For my name above you (or Johannes) can change 'Cc:' to 'Acked-by:'
Gr. AvS
> v3:
> - read current freq from the firmware via BRCMF_C_GET_CHANNEL
>
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* Re: [PATCHv4 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Kalle Valo @ 2013-06-05 15:16 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Johannes Berg, linux-wireless, Antonio Quartulli,
Nicolas Cavallari, ath6kl-devel
In-Reply-To: <1370444989-2095-3-git-send-email-ordex@autistici.org>
Antonio Quartulli <ordex@autistici.org> writes:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> to be sent on the one currently in use by the device.
> Make the implementation of mgmt_tx correctly handle this
> case
>
> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Thanks.
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
^ permalink raw reply
* [PATCHv4 4/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-05 15:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370444989-2095-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
Users may want to send a frame on the current channel
without specifying it.
This is particularly useful for the correct implementation
of the IBSS/RSN support in wpa_supplicant which requires to
receive and send AUTH frames.
Make mgmt_tx pass a NULL channel to the driver if none has
been specified by the user.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
v3:
- moved from 1/4 to 4/4
net/wireless/nl80211.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 88e820b..06af395 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7139,6 +7139,9 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
return -EOPNOTSUPP;
switch (wdev->iftype) {
+ case NL80211_IFTYPE_P2P_DEVICE:
+ if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
+ return -EINVAL;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_P2P_CLIENT:
@@ -7146,7 +7149,6 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_P2P_GO:
- case NL80211_IFTYPE_P2P_DEVICE:
break;
default:
return -EOPNOTSUPP;
@@ -7174,9 +7176,15 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
no_cck = nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- err = nl80211_parse_chandef(rdev, info, &chandef);
- if (err)
- return err;
+ /* get the channel if any has been specified, otherwise pass NULL to
+ * the driver. The latter will use the current one
+ */
+ chandef.chan = NULL;
+ if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
+ err = nl80211_parse_chandef(rdev, info, &chandef);
+ if (err)
+ return err;
+ }
if (!dont_wait_for_ack) {
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
--
1.8.1.5
^ permalink raw reply related
* [PATCHv4 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 15:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Kalle Valo, Nicolas Cavallari
In-Reply-To: <1370444989-2095-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
v4:
- ensure to never send freq zero to the firmware
drivers/net/wireless/ath/ath6kl/cfg80211.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f7995b2..2437ad2 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3175,10 +3175,21 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
{
struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
struct ath6kl *ar = ath6kl_priv(vif->ndev);
- u32 id;
+ u32 id, freq;
const struct ieee80211_mgmt *mgmt;
bool more_data, queued;
+ /* default to the current channel, but use the one specified as argument
+ * if any
+ */
+ freq = vif->ch_hint;
+ if (chan)
+ freq = chan->center_freq;
+
+ /* never send freq zero to the firmware */
+ if (WARN_ON(freq == 0))
+ return -EINVAL;
+
mgmt = (const struct ieee80211_mgmt *) buf;
if (vif->nw_type == AP_NETWORK && test_bit(CONNECTED, &vif->flags) &&
ieee80211_is_probe_resp(mgmt->frame_control) &&
@@ -3188,8 +3199,7 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
* command to allow the target to fill in the generic IEs.
*/
*cookie = 0; /* TX status not supported */
- return ath6kl_send_go_probe_resp(vif, buf, len,
- chan->center_freq);
+ return ath6kl_send_go_probe_resp(vif, buf, len, freq);
}
id = vif->send_action_id++;
@@ -3205,17 +3215,14 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
/* AP mode Power saving processing */
if (vif->nw_type == AP_NETWORK) {
- queued = ath6kl_mgmt_powersave_ap(vif,
- id, chan->center_freq,
- wait, buf,
- len, &more_data, no_cck);
+ queued = ath6kl_mgmt_powersave_ap(vif, id, freq, wait, buf, len,
+ &more_data, no_cck);
if (queued)
return 0;
}
- return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id,
- chan->center_freq, wait,
- buf, len, no_cck);
+ return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id, freq,
+ wait, buf, len, no_cck);
}
static void ath6kl_mgmt_frame_register(struct wiphy *wiphy,
--
1.8.1.5
^ permalink raw reply related
* [PATCHv4 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 15:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Arend van Spriel,
brcm80211-dev-list
In-Reply-To: <1370444989-2095-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Arend van Spriel <arend@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
v3:
- read current freq from the firmware via BRCMF_C_GET_CHANNEL
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 6d758f2..8bd256b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -3917,6 +3917,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct brcmf_fil_af_params_le *af_params;
bool ack;
s32 chan_nr;
+ u32 freq;
brcmf_dbg(TRACE, "Enter\n");
@@ -3929,6 +3930,8 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EPERM;
}
+ vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
+
if (ieee80211_is_probe_resp(mgmt->frame_control)) {
/* Right now the only reason to get a probe response */
/* is for p2p listen response or for p2p GO from */
@@ -3944,7 +3947,6 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
ie_offset = DOT11_MGMT_HDR_LEN +
DOT11_BCN_PRB_FIXED_LEN;
ie_len = len - ie_offset;
- vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif;
err = brcmf_vif_set_mgmt_ie(vif,
@@ -3968,8 +3970,15 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
memcpy(&af_params->bssid[0], &mgmt->bssid[0], ETH_ALEN);
/* Add the length exepted for 802.11 header */
action_frame->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN);
- /* Add the channel */
- chan_nr = ieee80211_frequency_to_channel(chan->center_freq);
+ /* Add the channel. Use the one specified as parameter if any or
+ * the current one (got from the firmware) otherwise
+ */
+ if (chan)
+ freq = chan->center_freq;
+ else
+ brcmf_fil_cmd_int_get(vif->ifp, BRCMF_C_GET_CHANNEL,
+ &freq);
+ chan_nr = ieee80211_frequency_to_channel(freq);
af_params->channel = cpu_to_le32(chan_nr);
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
--
1.8.1.5
^ permalink raw reply related
* [PATCHv4 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 15:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case. Fail if offchan is required.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/mac80211/cfg.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..617c5c8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2838,6 +2838,12 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EOPNOTSUPP;
}
+ /* configurations requiring offchan cannot work if no channel has been
+ * specified
+ */
+ if (need_offchan && !chan)
+ return -EINVAL;
+
mutex_lock(&local->mtx);
/* Check if the operating channel is the requested channel */
@@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (chanctx_conf)
- need_offchan = chan != chanctx_conf->def.chan;
- else
+ if (chanctx_conf) {
+ need_offchan = chan && (chan != chanctx_conf->def.chan);
+ } else if (!chan) {
+ ret = -EINVAL;
+ goto out_unlock;
+ } else {
need_offchan = true;
+ }
rcu_read_unlock();
}
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCHv3 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Kalle Valo @ 2013-06-05 15:07 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org,
Nicolas Cavallari, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <20130605145157.GH2349@open-mesh.com>
Antonio Quartulli <antonio@open-mesh.com> writes:
> On Wed, Jun 05, 2013 at 07:48:15AM -0700, Kalle Valo wrote:
>> Antonio Quartulli <ordex@autistici.org> writes:
>>
>> > From: Antonio Quartulli <antonio@open-mesh.com>
>> >
>> > cfg80211 passes a NULL channel to mgmt_tx if the frame has
>> > to be sent on the one currently in use by the device.
>> > Make the implementation of mgmt_tx correctly handle this
>> > case
>> >
>> > Cc: Kalle Valo <kvalo@qca.qualcomm.com>
>> > Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
>> > Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
>>
>> [...]
>>
>> > @@ -3175,10 +3175,17 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
>> > {
>> > struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
>> > struct ath6kl *ar = ath6kl_priv(vif->ndev);
>> > - u32 id;
>> > + u32 id, freq;
>> > const struct ieee80211_mgmt *mgmt;
>> > bool more_data, queued;
>> >
>> > + /* default to the current channel, but use the one specified as argument
>> > + * if any
>> > + */
>> > + freq = vif->ch_hint;
>> > + if (chan)
>> > + freq = chan->center_freq;
>>
>> Can you please add a check here:
>>
>> if (WARN_ON(chan == 0))
>> return -EINVAL;
>
> I think you meant (freq == 0) ?
Yes, thanks for catching that :)
>> Just like Arend, I want to be sure that we don't submit value 0 to the
>> firmware.
>
> Yeah ok. In ath6kl, are you aware of any "firmware command" to get the channel
> from the device like I did for brcmfmac ?
>
> I couldn't find any define matching *GET*CHAN*
I don't recall seeing anything like that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: limit multicast buffer hardware queue depth
From: Felix Fietkau @ 2013-06-05 15:00 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, linville
In-Reply-To: <20130605140932.GA8918@w1.fi>
On 2013-06-05 4:09 PM, Jouni Malinen wrote:
> On Mon, Jun 03, 2013 at 07:31:54PM +0200, Felix Fietkau wrote:
>> The CAB (Content after Beacon) queue is used for beacon-triggered
>> transmission of buffered multicast frames. If lots of multicast frames
>> were buffered and this queue fills up, it drowns out all regular
>> traffic. To limit the damage that buffered traffic can do, try to limit
>> the queued data to becaon_interval / 8.
>
> I'm not sure this would be compliant with the standard, but I guess
> something along these lines could be reasonable in some cases. However,
> it could be useful to take into account different DTIM Period parameters
> in the limit and instead of hardcoding this to one eight of the Beacon
> interval, the limit could be set based on Beacon interval * DTIM Period.
> Especially with large DTIM Period values, one eight of a Beacon interval
> may not be sufficient to handle even reasonable amount of group
> addressed frames.
Makes sense.
> Does this commit address More Data field updates when the driver decides
> to stop getting more frames without notifying mac80211 of this? The
> associated STAs would need to know when they can go back to sleep after
> the DTIM Beacon and the More Data field needs to be set to zero in the
> last frame the AP is sending out in the case this new limit is hit.
I'll make a new version of this patch that takes care of the More Data
field.
- Felix
^ permalink raw reply
* Re: [PATCHv3 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 14:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org,
Nicolas Cavallari, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <87r4ggy5ow.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
On Wed, Jun 05, 2013 at 07:48:15AM -0700, Kalle Valo wrote:
> Antonio Quartulli <ordex@autistici.org> writes:
>
> > From: Antonio Quartulli <antonio@open-mesh.com>
> >
> > cfg80211 passes a NULL channel to mgmt_tx if the frame has
> > to be sent on the one currently in use by the device.
> > Make the implementation of mgmt_tx correctly handle this
> > case
> >
> > Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> > Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
> > Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
>
> [...]
>
> > @@ -3175,10 +3175,17 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> > {
> > struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
> > struct ath6kl *ar = ath6kl_priv(vif->ndev);
> > - u32 id;
> > + u32 id, freq;
> > const struct ieee80211_mgmt *mgmt;
> > bool more_data, queued;
> >
> > + /* default to the current channel, but use the one specified as argument
> > + * if any
> > + */
> > + freq = vif->ch_hint;
> > + if (chan)
> > + freq = chan->center_freq;
>
> Can you please add a check here:
>
> if (WARN_ON(chan == 0))
> return -EINVAL;
I think you meant (freq == 0) ?
>
> Just like Arend, I want to be sure that we don't submit value 0 to the
> firmware.
Yeah ok. In ath6kl, are you aware of any "firmware command" to get the channel
from the device like I did for brcmfmac ?
I couldn't find any define matching *GET*CHAN*
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv3 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Kalle Valo @ 2013-06-05 14:48 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Johannes Berg, linux-wireless, Antonio Quartulli,
Nicolas Cavallari, ath6kl-devel
In-Reply-To: <1370442893-1687-3-git-send-email-ordex@autistici.org>
Antonio Quartulli <ordex@autistici.org> writes:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> to be sent on the one currently in use by the device.
> Make the implementation of mgmt_tx correctly handle this
> case
>
> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
[...]
> @@ -3175,10 +3175,17 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> {
> struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
> struct ath6kl *ar = ath6kl_priv(vif->ndev);
> - u32 id;
> + u32 id, freq;
> const struct ieee80211_mgmt *mgmt;
> bool more_data, queued;
>
> + /* default to the current channel, but use the one specified as argument
> + * if any
> + */
> + freq = vif->ch_hint;
> + if (chan)
> + freq = chan->center_freq;
Can you please add a check here:
if (WARN_ON(chan == 0))
return -EINVAL;
Just like Arend, I want to be sure that we don't submit value 0 to the
firmware.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Oleksij Rempel @ 2013-06-05 14:46 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Helmut Schaa, linux-wireless, ath9k-devel
In-Reply-To: <51AF4AA7.6050005@blackshift.org>
Am 05.06.2013 16:26, schrieb Marc Kleine-Budde:
> On 06/05/2013 04:24 PM, Helmut Schaa wrote:
>> On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>> This error seems to be really rare, and we do not know real couse of it.
>>> But, in any case, we should check size of head before reducing it.
>>
>> Mind to try the (completely untested) patch against wireless-testing instead?
>> Helmut
>
> I will do, however I'm not in range of that USB wireless adapter for
> about 1,5 weeks.
Helmut, thank you for patch!
i'll do regression test, but not week long test. So i probably won't
reproduce this issue.
--
Regards,
Oleksij
^ permalink raw reply
* Re: wireless tree rebased (from 5/28), Broadcom bits dropped
From: John W. Linville @ 2013-06-05 14:37 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Samuel Ortiz, Gustavo Padovan, Luciano Coelho
In-Reply-To: <1370415586.8920.4.camel@jlt4.sipsolutions.net>
On Wed, Jun 05, 2013 at 08:59:46AM +0200, Johannes Berg wrote:
> On Tue, 2013-06-04 at 17:53 -0400, John W. Linville wrote:
> > I messed this up too -- bad day...
> >
> > If you pulled in between the earlier message and this one, please
> > do so again. If you saw this message before taking any action to
> > clean-up my mess, then you are OK.
>
> This was confusing, I think you rebased around some merges instead of
> redoing the merges? My patches are in, but suddenly got new commit IDs,
> e.g. fa331699d05ce1d0d4896eb4a137cfae50d7afde (new) vs.
> c2c15e215e860c99b86ddfc4be4bb25cf180fed0 for "mac80211: work around
> broken APs not including HT info".
>
> This will cause git to pull them in again when I send a new pull
> request, so it would have been nicer to redo the merges, but anyway ...
> just a heads-up for everyone that here it's a bit confusing now.
>
> johannes
You are right, I could have done it better with regard to your tree.
I probably should redo that part.
The Bluetooth tree had pulled the wireless tree and applied their
patches on top of the brcmfmac/brcmsmac series that I removed. So,
their pull couldn't be redone.
I think I can fix the wireless tree and preserve the original mac80211
tree commits. Everyone please hold off on doing anything else here, as
I'm a bit busy and won't be able to get to this before this afternoon
(Eastern USA time).
Anyone object to one more wireless tree rebase today?
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: Incorrect resolution of merge conflict in net/mac80211/iface.c
From: Helmut Schaa @ 2013-06-05 14:37 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: John W. Linville, linux-wireless, Felix Fietkau
In-Reply-To: <20130605161445.309a2942@north>
On Wed, Jun 5, 2013 at 4:14 PM, Jakub Kicinski <kubakici@wp.pl> wrote:
> Hi John,
>
> I'm afraid merge in commit 84e46e17c8 of wireless-testing is
> not correct. I don't know how would you like to resolve this
> technical error, I attach my fixup patch in case it will help
> you. You may also want to take a look at commit a0f5d4b3a3
> of linux-next, I believe Stephen have merged two offending
> patches correctly there.
>
> BTW I think the way MAC addresses of active monitors are
> handled for devices that use address masks need some work
> on its own I hope to send a fix for that later this week.
Indeed, good catch. Stephens merge looks correct to me.
Helmut
^ permalink raw reply
* [PATCHv3 4/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-05 14:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370442893-1687-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
Users may want to send a frame on the current channel
without specifying it.
This is particularly useful for the correct implementation
of the IBSS/RSN support in wpa_supplicant which requires to
receive and send AUTH frames.
Make mgmt_tx pass a NULL channel to the driver if none has
been specified by the user.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
v3:
- moved from 1/4 to 4/4
net/wireless/nl80211.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 88e820b..06af395 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7139,6 +7139,9 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
return -EOPNOTSUPP;
switch (wdev->iftype) {
+ case NL80211_IFTYPE_P2P_DEVICE:
+ if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
+ return -EINVAL;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_P2P_CLIENT:
@@ -7146,7 +7149,6 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_P2P_GO:
- case NL80211_IFTYPE_P2P_DEVICE:
break;
default:
return -EOPNOTSUPP;
@@ -7174,9 +7176,15 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
no_cck = nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- err = nl80211_parse_chandef(rdev, info, &chandef);
- if (err)
- return err;
+ /* get the channel if any has been specified, otherwise pass NULL to
+ * the driver. The latter will use the current one
+ */
+ chandef.chan = NULL;
+ if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
+ err = nl80211_parse_chandef(rdev, info, &chandef);
+ if (err)
+ return err;
+ }
if (!dont_wait_for_ack) {
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
--
1.8.1.5
^ permalink raw reply related
* [PATCHv3 3/4] ath6kl: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 14:34 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Kalle Valo, Nicolas Cavallari
In-Reply-To: <1370442893-1687-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f7995b2..b542203 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3175,10 +3175,17 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
{
struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
struct ath6kl *ar = ath6kl_priv(vif->ndev);
- u32 id;
+ u32 id, freq;
const struct ieee80211_mgmt *mgmt;
bool more_data, queued;
+ /* default to the current channel, but use the one specified as argument
+ * if any
+ */
+ freq = vif->ch_hint;
+ if (chan)
+ freq = chan->center_freq;
+
mgmt = (const struct ieee80211_mgmt *) buf;
if (vif->nw_type == AP_NETWORK && test_bit(CONNECTED, &vif->flags) &&
ieee80211_is_probe_resp(mgmt->frame_control) &&
@@ -3188,8 +3195,7 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
* command to allow the target to fill in the generic IEs.
*/
*cookie = 0; /* TX status not supported */
- return ath6kl_send_go_probe_resp(vif, buf, len,
- chan->center_freq);
+ return ath6kl_send_go_probe_resp(vif, buf, len, freq);
}
id = vif->send_action_id++;
@@ -3205,17 +3211,14 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
/* AP mode Power saving processing */
if (vif->nw_type == AP_NETWORK) {
- queued = ath6kl_mgmt_powersave_ap(vif,
- id, chan->center_freq,
- wait, buf,
- len, &more_data, no_cck);
+ queued = ath6kl_mgmt_powersave_ap(vif, id, freq, wait, buf, len,
+ &more_data, no_cck);
if (queued)
return 0;
}
- return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id,
- chan->center_freq, wait,
- buf, len, no_cck);
+ return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id, freq,
+ wait, buf, len, no_cck);
}
static void ath6kl_mgmt_frame_register(struct wiphy *wiphy,
--
1.8.1.5
^ permalink raw reply related
* [PATCHv3 2/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 14:34 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Arend van Spriel,
brcm80211-dev-list
In-Reply-To: <1370442893-1687-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Arend van Spriel <arend@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
v3:
- read current freq from the firmware via BRCMF_C_GET_CHANNEL
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 6d758f2..8bd256b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -3917,6 +3917,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct brcmf_fil_af_params_le *af_params;
bool ack;
s32 chan_nr;
+ u32 freq;
brcmf_dbg(TRACE, "Enter\n");
@@ -3929,6 +3930,8 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EPERM;
}
+ vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
+
if (ieee80211_is_probe_resp(mgmt->frame_control)) {
/* Right now the only reason to get a probe response */
/* is for p2p listen response or for p2p GO from */
@@ -3944,7 +3947,6 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
ie_offset = DOT11_MGMT_HDR_LEN +
DOT11_BCN_PRB_FIXED_LEN;
ie_len = len - ie_offset;
- vif = container_of(wdev, struct brcmf_cfg80211_vif, wdev);
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif;
err = brcmf_vif_set_mgmt_ie(vif,
@@ -3968,8 +3970,15 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
memcpy(&af_params->bssid[0], &mgmt->bssid[0], ETH_ALEN);
/* Add the length exepted for 802.11 header */
action_frame->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN);
- /* Add the channel */
- chan_nr = ieee80211_frequency_to_channel(chan->center_freq);
+ /* Add the channel. Use the one specified as parameter if any or
+ * the current one (got from the firmware) otherwise
+ */
+ if (chan)
+ freq = chan->center_freq;
+ else
+ brcmf_fil_cmd_int_get(vif->ifp, BRCMF_C_GET_CHANNEL,
+ &freq);
+ chan_nr = ieee80211_frequency_to_channel(freq);
af_params->channel = cpu_to_le32(chan_nr);
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
--
1.8.1.5
^ permalink raw reply related
* [PATCHv3 1/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 14:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case. Fail if offchan is required.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/mac80211/cfg.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..617c5c8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2838,6 +2838,12 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EOPNOTSUPP;
}
+ /* configurations requiring offchan cannot work if no channel has been
+ * specified
+ */
+ if (need_offchan && !chan)
+ return -EINVAL;
+
mutex_lock(&local->mtx);
/* Check if the operating channel is the requested channel */
@@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (chanctx_conf)
- need_offchan = chan != chanctx_conf->def.chan;
- else
+ if (chanctx_conf) {
+ need_offchan = chan && (chan != chanctx_conf->def.chan);
+ } else if (!chan) {
+ ret = -EINVAL;
+ goto out_unlock;
+ } else {
need_offchan = true;
+ }
rcu_read_unlock();
}
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Marc Kleine-Budde @ 2013-06-05 14:26 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Oleksij Rempel, linux-wireless, ath9k-devel
In-Reply-To: <CAGXE3d9p7zkwfNJBJvPMc8XaKnb009pHpCXYweDjK4tv6PCkuA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
On 06/05/2013 04:24 PM, Helmut Schaa wrote:
> On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> This error seems to be really rare, and we do not know real couse of it.
>> But, in any case, we should check size of head before reducing it.
>
> Mind to try the (completely untested) patch against wireless-testing instead?
> Helmut
I will do, however I'm not in range of that USB wireless adapter for
about 1,5 weeks.
Marc
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Helmut Schaa @ 2013-06-05 14:24 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel, Marc Kleine-Budde
In-Reply-To: <1370371064-6903-1-git-send-email-linux@rempel-privat.de>
On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> This error seems to be really rare, and we do not know real couse of it.
> But, in any case, we should check size of head before reducing it.
Mind to try the (completely untested) patch against wireless-testing instead?
Helmut
---
Subject: [PATCH] ath9k_htc: Restore skb headroom when returning skb to mac80211
ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.
Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index e602c95..666cfb6 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,6 +448,8 @@ static void ath9k_htc_tx_process(struct
ath9k_htc_priv *priv,
struct ieee80211_conf *cur_conf = &priv->hw->conf;
bool txok;
int slot;
+ struct ieee80211_hdr *hdr;
+ int padpos, padsize;
slot = strip_drv_header(priv, skb);
if (slot < 0) {
@@ -504,6 +506,15 @@ send_mac80211:
ath9k_htc_tx_clear_slot(priv, slot);
+ /* Remove padding before handing frame back to mac80211 */
+ hdr = (struct ieee80211_hdr *) skb->data;
+ padpos = ieee80211_hdrlen(hdr->frame_control);
+ padsize = padpos & 3;
+ if (padsize && skb->len > padpos + padsize) {
+ memmove(skb->data + padsize, skb->data, padpos);
+ skb_pull(skb, padsize);
+ }
+
/* Send status to mac80211 */
ieee80211_tx_status(priv->hw, skb);
}
--
1.7.10.4
^ permalink raw reply related
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