* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 8:55 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linville, simon.wunderlich, linux-wireless
In-Reply-To: <1380545557-25103-1-git-send-email-lorenzo.bianconi83@gmail.com>
On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
> Allow management frame injection on DFS channels if the channel has been CAC
> checked and is available
> +++ b/net/mac80211/tx.c
> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
> * radar detection by itself. We can do that later by adding a
> * monitor flag interfaces used for AP support.
> */
> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
> - IEEE80211_CHAN_PASSIVE_SCAN)))
> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
> + IEEE80211_CHAN_NO_IBSS))) ||
> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
> + chan->dfs_state != NL80211_DFS_AVAILABLE))
This would be the only place where mac80211 is accessing
chan->dfs_state, does that make sense? Why is it not needed elsewhere?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel
From: Johannes Berg @ 2013-10-02 9:00 UTC (permalink / raw)
To: Sunil Dutt; +Cc: linux-wireless, j
In-Reply-To: <1377582278-3768-1-git-send-email-c_duttus@qti.qualcomm.com>
On Tue, 2013-08-27 at 11:14 +0530, Sunil Dutt wrote:
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]) {
> + params->supported_channels =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
> + params->supported_channels_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
It seems you should validate that the length is even, and at least 2?
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]) {
> + params->supported_oper_classes =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
> + params->supported_oper_classes_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
Similarly here (with different rules)
Does this even make sense in set_station() rather than only
new_station()?
johannes
^ permalink raw reply
* [PATCH v2 0/4] ath10k: clean ups
From: Michal Kazior @ 2013-10-02 9:03 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380292706-3609-1-git-send-email-michal.kazior@tieto.com>
Hi,
First two patches are non-functional changes.
The latter two should remove some overhead from TX
path and CE processing. Nothing extraordinary.
PATCH v2:
* add commit messages for patch #1 and #2 (Kalle)
Michal Kazior (4):
ath10k: split tid calculation from tx function
ath10k: split vdev_id calculation from tx function
ath10k: remove ce_sendlist_send
ath10k: remove num_sends_allowed
drivers/net/wireless/ath/ath10k/ce.c | 35 ++++++------------------
drivers/net/wireless/ath/ath10k/ce.h | 16 +----------
drivers/net/wireless/ath/ath10k/mac.c | 48 ++++++++++++++++++++-------------
drivers/net/wireless/ath/ath10k/pci.c | 25 +++--------------
drivers/net/wireless/ath/ath10k/pci.h | 3 ---
5 files changed, 42 insertions(+), 85 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/4] ath10k: split tid calculation from tx function
From: Michal Kazior @ 2013-10-02 9:03 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380704621-4670-1-git-send-email-michal.kazior@tieto.com>
Tidy up ath10k_tx().
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8684e03..7415a60 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1407,6 +1407,20 @@ static void ath10k_reg_notifier(struct wiphy *wiphy,
/* TX handlers */
/***************/
+static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
+{
+ if (ieee80211_is_mgmt(hdr->frame_control))
+ return HTT_DATA_TX_EXT_TID_MGMT;
+
+ if (!ieee80211_is_data_qos(hdr->frame_control))
+ return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
+
+ if (!is_unicast_ether_addr(ieee80211_get_DA(hdr)))
+ return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
+
+ return ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK;
+}
+
/*
* Frames sent to the FW have to be in "Native Wifi" format.
* Strip the QoS field from the 802.11 header.
@@ -1788,14 +1802,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
/* we must calculate tid before we apply qos workaround
* as we'd lose the qos control field */
- tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
- if (ieee80211_is_mgmt(hdr->frame_control)) {
- tid = HTT_DATA_TX_EXT_TID_MGMT;
- } else if (ieee80211_is_data_qos(hdr->frame_control) &&
- is_unicast_ether_addr(ieee80211_get_DA(hdr))) {
- u8 *qc = ieee80211_get_qos_ctl(hdr);
- tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
- }
+ tid = ath10k_tx_h_get_tid(hdr);
/* it makes no sense to process injected frames like that */
if (info->control.vif &&
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/4] ath10k: split vdev_id calculation from tx function
From: Michal Kazior @ 2013-10-02 9:03 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380704621-4670-1-git-send-email-michal.kazior@tieto.com>
Tidy up ath10k_tx().
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7415a60..4b7c949 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1421,6 +1421,19 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
return ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK;
}
+static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
+ struct ieee80211_tx_info *info)
+{
+ if (info->control.vif)
+ return ath10k_vif_to_arvif(info->control.vif)->vdev_id;
+
+ if (ar->monitor_enabled)
+ return ar->monitor_vdev_id;
+
+ ath10k_warn("could not resolve vdev id\n");
+ return 0;
+}
+
/*
* Frames sent to the FW have to be in "Native Wifi" format.
* Strip the QoS field from the 802.11 header.
@@ -1785,16 +1798,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct ath10k *ar = hw->priv;
- struct ath10k_vif *arvif = NULL;
- u32 vdev_id = 0;
- u8 tid;
-
- if (info->control.vif) {
- arvif = ath10k_vif_to_arvif(info->control.vif);
- vdev_id = arvif->vdev_id;
- } else if (ar->monitor_enabled) {
- vdev_id = ar->monitor_vdev_id;
- }
+ u8 tid, vdev_id;
/* We should disable CCK RATE due to P2P */
if (info->flags & IEEE80211_TX_CTL_NO_CCK_RATE)
@@ -1803,6 +1807,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
/* we must calculate tid before we apply qos workaround
* as we'd lose the qos control field */
tid = ath10k_tx_h_get_tid(hdr);
+ vdev_id = ath10k_tx_h_get_vdev_id(ar, info);
/* it makes no sense to process injected frames like that */
if (info->control.vif &&
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] ath10k: remove ce_sendlist_send
From: Michal Kazior @ 2013-10-02 9:03 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380704621-4670-1-git-send-email-michal.kazior@tieto.com>
It is completely pointless to keep this function
around. It doesn't do anything different than
ce_send except it introduces more overhead.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 34 ---------------------------------
drivers/net/wireless/ath/ath10k/ce.h | 15 ---------------
drivers/net/wireless/ath/ath10k/pci.c | 4 ++--
3 files changed, 2 insertions(+), 51 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 834e29e..9e6daa9 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -338,40 +338,6 @@ int ath10k_ce_send(struct ath10k_ce_pipe *ce_state,
return ret;
}
-int ath10k_ce_sendlist_send(struct ath10k_ce_pipe *ce_state,
- void *per_transfer_context,
- unsigned int transfer_id,
- u32 paddr, unsigned int nbytes,
- u32 flags)
-{
- struct ath10k_ce_ring *src_ring = ce_state->src_ring;
- struct ath10k *ar = ce_state->ar;
- struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
- unsigned int nentries_mask = src_ring->nentries_mask;
- unsigned int sw_index;
- unsigned int write_index;
- int delta, ret = -ENOMEM;
-
- spin_lock_bh(&ar_pci->ce_lock);
-
- sw_index = src_ring->sw_index;
- write_index = src_ring->write_index;
-
- delta = CE_RING_DELTA(nentries_mask, write_index, sw_index - 1);
-
- if (delta >= 1) {
- ret = ath10k_ce_send_nolock(ce_state, per_transfer_context,
- paddr, nbytes,
- transfer_id, flags);
- if (ret)
- ath10k_warn("CE send failed: %d\n", ret);
- }
-
- spin_unlock_bh(&ar_pci->ce_lock);
-
- return ret;
-}
-
int ath10k_ce_recv_buf_enqueue(struct ath10k_ce_pipe *ce_state,
void *per_recv_context,
u32 buffer)
diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
index aec8028..949b174 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -156,21 +156,6 @@ void ath10k_ce_send_cb_register(struct ath10k_ce_pipe *ce_state,
void (*send_cb)(struct ath10k_ce_pipe *),
int disable_interrupts);
-/*
- * Queue a "sendlist" of buffers to be sent using gather to a single
- * anonymous destination buffer
- * ce - which copy engine to use
- * sendlist - list of simple buffers to send using gather
- * transfer_id - arbitrary ID; reflected to destination
- * Returns 0 on success; otherwise an error status.
- *
- * Implemenation note: Pushes multiple buffers with Gather to Source ring.
- */
-int ath10k_ce_sendlist_send(struct ath10k_ce_pipe *ce_state,
- void *per_transfer_context,
- unsigned int transfer_id,
- u32 paddr, unsigned int nbytes,
- u32 flags);
/*==================Recv=======================*/
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index dff23d9..4f6a978 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -730,8 +730,8 @@ static int ath10k_pci_hif_send_head(struct ath10k *ar, u8 pipe_id,
pipe_info->num_sends_allowed--;
spin_unlock_bh(&pipe_info->pipe_lock);
- ret = ath10k_ce_sendlist_send(ce_hdl, nbuf, transfer_id,
- skb_cb->paddr, len, flags);
+ ret = ath10k_ce_send(ce_hdl, nbuf, skb_cb->paddr, len, transfer_id,
+ flags);
if (ret)
ath10k_warn("CE send failed: %p\n", nbuf);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/4] ath10k: remove num_sends_allowed
From: Michal Kazior @ 2013-10-02 9:03 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380704621-4670-1-git-send-email-michal.kazior@tieto.com>
The value provided by num_sends_allowed is now
derived from CE source ringbuffer state.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 17 ++++++++++++++++-
drivers/net/wireless/ath/ath10k/ce.h | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 21 +--------------------
drivers/net/wireless/ath/ath10k/pci.h | 3 ---
4 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 9e6daa9..e46951b 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -283,7 +283,7 @@ static int ath10k_ce_send_nolock(struct ath10k_ce_pipe *ce_state,
if (unlikely(CE_RING_DELTA(nentries_mask,
write_index, sw_index - 1) <= 0)) {
- ret = -EIO;
+ ret = -ENOSR;
goto exit;
}
@@ -338,6 +338,21 @@ int ath10k_ce_send(struct ath10k_ce_pipe *ce_state,
return ret;
}
+int ath10k_ce_num_free_src_entries(struct ath10k_ce_pipe *pipe)
+{
+ struct ath10k *ar = pipe->ar;
+ struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+ int delta;
+
+ spin_lock_bh(&ar_pci->ce_lock);
+ delta = CE_RING_DELTA(pipe->src_ring->nentries_mask,
+ pipe->src_ring->write_index,
+ pipe->src_ring->sw_index - 1);
+ spin_unlock_bh(&ar_pci->ce_lock);
+
+ return delta;
+}
+
int ath10k_ce_recv_buf_enqueue(struct ath10k_ce_pipe *ce_state,
void *per_recv_context,
u32 buffer)
diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
index 949b174..15d45b5 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -156,6 +156,7 @@ void ath10k_ce_send_cb_register(struct ath10k_ce_pipe *ce_state,
void (*send_cb)(struct ath10k_ce_pipe *),
int disable_interrupts);
+int ath10k_ce_num_free_src_entries(struct ath10k_ce_pipe *pipe);
/*==================Recv=======================*/
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 4f6a978..f8d59c7 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -720,16 +720,6 @@ static int ath10k_pci_hif_send_head(struct ath10k *ar, u8 pipe_id,
"ath10k tx: data: ",
nbuf->data, nbuf->len);
- /* Make sure we have resources to handle this request */
- spin_lock_bh(&pipe_info->pipe_lock);
- if (!pipe_info->num_sends_allowed) {
- ath10k_warn("Pipe: %d is full\n", pipe_id);
- spin_unlock_bh(&pipe_info->pipe_lock);
- return -ENOSR;
- }
- pipe_info->num_sends_allowed--;
- spin_unlock_bh(&pipe_info->pipe_lock);
-
ret = ath10k_ce_send(ce_hdl, nbuf, skb_cb->paddr, len, transfer_id,
flags);
if (ret)
@@ -741,14 +731,7 @@ static int ath10k_pci_hif_send_head(struct ath10k *ar, u8 pipe_id,
static u16 ath10k_pci_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
- struct ath10k_pci_pipe *pipe_info = &(ar_pci->pipe_info[pipe]);
- int ret;
-
- spin_lock_bh(&pipe_info->pipe_lock);
- ret = pipe_info->num_sends_allowed;
- spin_unlock_bh(&pipe_info->pipe_lock);
-
- return ret;
+ return ath10k_ce_num_free_src_entries(ar_pci->pipe_info[pipe].ce_hdl);
}
static void ath10k_pci_hif_dump_area(struct ath10k *ar)
@@ -863,7 +846,6 @@ static int ath10k_pci_start_ce(struct ath10k *ar)
ath10k_pci_ce_send_done,
disable_interrupts);
completions += attr->src_nentries;
- pipe_info->num_sends_allowed = attr->src_nentries - 1;
}
if (attr->dest_nentries) {
@@ -1033,7 +1015,6 @@ static void ath10k_pci_process_ce(struct ath10k *ar)
*/
spin_lock_bh(&compl->pipe_info->pipe_lock);
list_add_tail(&compl->list, &compl->pipe_info->compl_free);
- compl->pipe_info->num_sends_allowed += send_done;
spin_unlock_bh(&compl->pipe_info->pipe_lock);
}
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 7c49f6f..52fb7b9 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -178,9 +178,6 @@ struct ath10k_pci_pipe {
/* List of free CE completion slots */
struct list_head compl_free;
- /* Limit the number of outstanding send requests. */
- int num_sends_allowed;
-
struct ath10k_pci *ar_pci;
struct tasklet_struct intr;
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] nl80211: Provide per channel maximum regulatory transmit power
From: Helmut Schaa @ 2013-10-02 9:04 UTC (permalink / raw)
To: Johannes Berg, Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <1380703470.13329.1.camel@jlt4.sipsolutions.net>
On Wed, Oct 2, 2013 at 10:44 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2013-10-02 at 09:43 +0200, Helmut Schaa wrote:
>> In some cases its not only required to know the maximum transmit power
>> the hw is capable of. Instead, userspace (hostapd) might want to know
>> the maximum transmit power as defined in the current regulatory domain
>> (for example for 802.11d country IEs).
>
> Why wouldn't it use (the equivalent of) "iw reg get" for that?
Might be the more sane approach.
I noticed that hostapd generates 11d IEs based on the channel list it
reads from the kernel.
Thus restricting STAs to the max tx power the hw is capable of. Just
adding the max regulatory
tx power looked like an easy solution :)
Jouni, would you be ok with using the kernels regulatory domain for
11d IEs in hostapd?
Thanks,
Helmut
^ permalink raw reply
* Re: [PATCH V4] cfg80211: vlan priority handling in WMM
From: Johannes Berg @ 2013-10-02 9:05 UTC (permalink / raw)
To: cedric.voncken; +Cc: linux-wireless
In-Reply-To: <1377518692-30084-1-git-send-email-cedric.voncken@acksys.fr>
On Mon, 2013-08-26 at 14:04 +0200, cedric.voncken@acksys.fr wrote:
> From: cedric Voncken <cedric.voncken@acksys.fr>
>
> If the VLAN tci is set in skb->vlan_tci use the priority field to determine the WMM priority.
Applied, with a linebreak in that commit log. Your (unnecessary) resend
of this also didn't even apply because it was line-wrapped in the patch.
johannes
^ permalink raw reply
* cfg80211/mac80211 merging done
From: Johannes Berg @ 2013-10-02 9:06 UTC (permalink / raw)
To: linux-wireless
Since I was travelling and then got sick during/after, it took me a
quite a while to get through my email.
I believe I've now gone through everything and merged or replied to
everything. If you expected a reply on a patch something and I haven't
gotten to it until now, I probably lost it so you should resend or ping
me.
johannes
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-02 9:08 UTC (permalink / raw)
To: Detlev Casanova; +Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <3913713.WUui18VufC@naboo>
On Sun, 2013-09-29 at 21:29 +0200, Detlev Casanova wrote:
> > So I'm not sure what's going on here, but I don't think NetworkManager
> > is the issue; it's likely in the supplicant's scanning code or in the
> > driver itself. NetworkManager asks the supplicant to scan with both the
> > wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
> > ensure that all available APs are found.
>
> Yes and the problem is most likely to be in the driver because it doesn't
> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211: use
> DS or HT operation IEs to determine BSS channel")
Does it work on a newer kernel if you revert that commit? I really see
nothing wrong with that commit ...
Failing all else, since I can't reproduce the issue, can you please
compare the output of "iw list" before and after the failure (on the
failing kernel)? Maybe all channels are marked disabled or something?
But that really should've been the same behaviour before the patch too.
Also, tracing would be good (trace-cmd record -e cfg80211 -e mac80211,
compress trace.dat and send it to me)
johannes
^ permalink raw reply
* Re: [PATCH] rt2x00_pci: Fix interrupt handler name (visible at /proc/interrupts)
From: Stanislaw Gruszka @ 2013-10-02 9:16 UTC (permalink / raw)
To: Kirill Tkhai; +Cc: linux-wireless, ivdoorn, gwingerde, helmut.schaa
In-Reply-To: <459361380660046@web2g.yandex.ru>
On Wed, Oct 02, 2013 at 12:40:46AM +0400, Kirill Tkhai wrote:
> Currently driver name is wrong. PCI device address is visible at
> /proc/interrupts instead of the name:
>
> 43: 124 0 0 0 PCI-MSI-edge rtsx_pci
> 44: 384 0 0 0 PCI-MSI-edge snd_hda_intel
> 45: 25096 0 0 0 PCI-MSI-edge 0000:01:00.0
> ^^^^^^^^^^^^
>
> So, pass the right name. rt2x00_ops->name contains KBUILD_MODNAME
> and good for that, so pass it.
>
> Handler names will be "rt2500pci", "rt2500pci" etc.
Looks sane. I was afraid that is not possible to have two or more
interrupts with the same name, but that's not true.
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Stanislaw
^ permalink raw reply
* Re: iwlegacy: iwl4965 reload firmware issue.
From: Stanislaw Gruszka @ 2013-10-02 9:19 UTC (permalink / raw)
To: Matt Chen; +Cc: linux-wireless, kvoz123
In-Reply-To: <CALx5=V_voRtb_e=9BFhNmt7rLO4v5iQKdZ0NCyZATtYCOUh7JA@mail.gmail.com>
On Tue, Oct 01, 2013 at 04:17:44PM +0800, Matt Chen wrote:
> The restart path is through il_irq_handle_error(il). My question is if
> this is a firmware issue, driver issue or hardware issue ?
Most likely driver issue, microcode error usually mean that driver provide
wrong values to the firmware or differently abuse firmware work.
Stanislaw
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-10-02 9:41 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <1380531766-15384-1-git-send-email-johannes@sipsolutions.net>
On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> The merge b35c8097 seems to have lost commit eabc4ac5d,
> put the code back.
I'm rebasing my tree on -rc1, which actually includes the merge commit,
so it still makes sense for me to include this commit - I've done that
now. Sorry for the confusion.
johannes
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: fix RF registers for RT5390/RT5392
From: Kevin Lo @ 2013-10-02 9:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
Update rf registers to use the same values that the MediaTek/Ralink
reference driver DPO_RT5572_LinuxSTA_2.6.1.3_20121022 uses.
References:
RF5390RegTable in chips/rt5390.c
RF5392RegTable in chips/rt5390.c
Tested on TP-Link TL-WN727N and D-Link DWA-140 Rev.b3 usb wifi dongles.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index f414978..0bbd1b5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6449,7 +6449,7 @@ static void rt2800_init_rfcsr_5390(struct
rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 28, 0x00);
rt2800_rfcsr_write(rt2x00dev, 29, 0x10);
- rt2800_rfcsr_write(rt2x00dev, 30, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 30, 0x10);
rt2800_rfcsr_write(rt2x00dev, 31, 0x80);
rt2800_rfcsr_write(rt2x00dev, 32, 0x80);
rt2800_rfcsr_write(rt2x00dev, 33, 0x00);
@@ -6487,7 +6487,7 @@ static void rt2800_init_rfcsr_5390(struct
rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 56, 0x22);
rt2800_rfcsr_write(rt2x00dev, 57, 0x80);
rt2800_rfcsr_write(rt2x00dev, 58, 0x7f);
- rt2800_rfcsr_write(rt2x00dev, 59, 0x63);
+ rt2800_rfcsr_write(rt2x00dev, 59, 0x8f);
rt2800_rfcsr_write(rt2x00dev, 60, 0x45);
if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F))
@@ -6507,7 +6507,6 @@ static void rt2800_init_rfcsr_5392(struct
rt2x00_dev *rt2x00dev)
rt2800_rf_init_calibration(rt2x00dev, 2);
rt2800_rfcsr_write(rt2x00dev, 1, 0x17);
- rt2800_rfcsr_write(rt2x00dev, 2, 0x80);
rt2800_rfcsr_write(rt2x00dev, 3, 0x88);
rt2800_rfcsr_write(rt2x00dev, 5, 0x10);
rt2800_rfcsr_write(rt2x00dev, 6, 0xe0);
^ permalink raw reply related
* [PATCH] ath10k: fix scheduling while atomic bug on config
From: Michal Kazior @ 2013-10-02 9:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Recent WMI/HTC changes introduces this bug because
now WMI commands can sleep.
Use appropriate interface iteration function.
Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8684e03..b65df84 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1935,9 +1935,8 @@ static void ath10k_config_ps(struct ath10k *ar)
memset(&ar_iter, 0, sizeof(struct ath10k_generic_iter));
ar_iter.ar = ar;
- ieee80211_iterate_active_interfaces_atomic(
- ar->hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_ps_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(ar->hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_ps_iter, &ar_iter);
if (ar_iter.ret)
ath10k_warn("failed to set ps config (%d)\n", ar_iter.ret);
@@ -2840,9 +2839,8 @@ static int ath10k_set_rts_threshold(struct ieee80211_hw *hw, u32 value)
ar_iter.ar = ar;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_rts_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_set_rts_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
return ar_iter.ret;
@@ -2881,9 +2879,8 @@ static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
ar_iter.ar = ar;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_frag_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_set_frag_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
return ar_iter.ret;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380704100.13329.6.camel@jlt4.sipsolutions.net>
Before start beaconing cfg80211_reg_can_beacon() verifies the channel
is CAC checked and available calling cfg80211_secondary_chans_ok().
Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
frames on DFS channels causing association failures.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
>> Allow management frame injection on DFS channels if the channel has been CAC
>> checked and is available
>
>> +++ b/net/mac80211/tx.c
>> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>> * radar detection by itself. We can do that later by adding a
>> * monitor flag interfaces used for AP support.
>> */
>> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
>> - IEEE80211_CHAN_PASSIVE_SCAN)))
>> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
>> + IEEE80211_CHAN_NO_IBSS))) ||
>> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
>> + chan->dfs_state != NL80211_DFS_AVAILABLE))
>
> This would be the only place where mac80211 is accessing
> chan->dfs_state, does that make sense? Why is it not needed elsewhere?
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 10:11 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <CAA2SeN+nhLU7vGDNLJCD=UrNRSFm5hT6HGEEhUqr1kAcMF3O-A@mail.gmail.com>
On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
> is CAC checked and available calling cfg80211_secondary_chans_ok().
> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
> frames on DFS channels causing association failures.
I don't see how this can cause association failures? Please explain.
DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
more.
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Michal Kazior @ 2013-10-02 11:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380707467-30387-1-git-send-email-michal.kazior@tieto.com>
On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
> Recent WMI/HTC changes introduces this bug because
> now WMI commands can sleep.
>
> Use appropriate interface iteration function.
>
> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Self NACK.
I've posted this too soon. This patch can lead to deadlocks on
iflist_mtx in some cases.
Michał
^ permalink raw reply
* Re: [PATCH v2] mac80211: implement STA CSA for drivers using channel contexts
From: Arik Nemtsov @ 2013-10-02 11:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfdy2VdnTa55YJMQHTc+bj-oBUuSb1rT0nKbLKK7BZrSjQ@mail.gmail.com>
On Sun, Sep 29, 2013 at 10:06 AM, Arik Nemtsov <arik@wizery.com> wrote:
> On Sun, Sep 1, 2013 at 5:15 PM, Arik Nemtsov <arik@wizery.com> wrote:
>> Limit the current implementation to a single channel context used by
>> a single vif, thereby avoiding multi-vif/channel complexities.
>>
>> Reuse the main function from AP CSA code, but move a portion out in
>> order to fit the STA scenario.
>>
>> Add a new mac80211 HW flag so we don't break devices that don't support
>> channel switch with channel-contexts. The new behavior will be opt-in.
>>
>> Signed-off-by: Arik Nemtsov <arik@wizery.com>
>
> Ping?
Ping 2 :)
(Just saw your email on the list urging pings)
Arik
^ permalink raw reply
* Re: [PATCH for-3.12 2/3] bcma: make bcma_core_pci_{up,down}() callable from atomic context
From: Hauke Mehrtens @ 2013-10-02 11:53 UTC (permalink / raw)
To: Arend van Spriel, John W. Linville
Cc: linux-wireless, stable, Tod Jackson, Joe Perches, Rafal Milecki
In-Reply-To: <1380103864-10447-3-git-send-email-arend@broadcom.com>
On 09/25/2013 12:11 PM, Arend van Spriel wrote:
> This patch removes the bcma_core_pci_power_save() call from
> the bcma_core_pci_{up,down}() functions as it tries to schedule
> thus requiring to call them from non-atomic context. The function
> bcma_core_pci_power_save() is now exported so the calling module
> can explicitly use it in non-atomic context. This fixes the
> 'scheduling while atomic' issue reported by Tod Jackson and
> Joe Perches.
>
> [ 13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
> [ 13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
> [ 13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
> [ 13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
> [ 13.210767] ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b 0000000000000007
> [ 13.210777] ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2 ffff880170fd19d8
> [ 13.210785] ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
> [ 13.210794] Call Trace:
> [ 13.210813] [<ffffffff8169af5b>] dump_stack+0x4f/0x84
> [ 13.210826] [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
> [ 13.210837] [<ffffffff816a19f5>] __schedule+0x6e5/0x810
> [ 13.210845] [<ffffffff816a1c34>] schedule+0x24/0x70
> [ 13.210855] [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
> [ 13.210867] [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
> [ 13.210877] [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
> [ 13.210887] [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
> [ 13.210897] [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
> [ 13.210910] [<ffffffffa00371af>] bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
> [ 13.210921] [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0 [bcma]
> [ 13.210932] [<ffffffffa0037498>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
> [ 13.210942] [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80 [bcma]
> [ 13.210953] [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
> [ 13.210975] [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
> [ 13.210989] [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
> [ 13.211003] [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
> [ 13.211020] [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
> [ 13.211030] [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
> [ 13.211064] [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
> [ 13.211076] [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
> [ 13.211086] [<ffffffff81657b41>] ieee80211_open+0x71/0x80
> [ 13.211101] [<ffffffff81526267>] __dev_open+0x87/0xe0
> [ 13.211109] [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
> [ 13.211117] [<ffffffff815266a3>] dev_change_flags+0x23/0x70
> [ 13.211127] [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
> [ 13.211136] [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
> [ 13.211147] [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
> [ 13.211155] [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
> [ 13.211169] [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
> [ 13.211180] [<ffffffff8113f159>] ? ____fput+0x9/0x10
> [ 13.211198] [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
> [ 13.211202] [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
> [ 13.211208] [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
> [ 13.211217] NOHZ: local_softirq_pending 202
>
> The issue was introduced in v3.11 kernel by following commit:
>
> commit aa51e598d04c6acf5477934cd6383f5a17ce9029
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Sat Aug 24 00:32:31 2013 +0200
>
> brcmsmac: use bcma PCIe up and down functions
>
> replace the calls to bcma_core_pci_extend_L1timer() by calls to the
> newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> This fix has been discussed with Hauke Mehrtens [1] selection
> option 3) and is intended for v3.12.
>
> Ref:
> [1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de
>
> Cc: <stable@vger.kernel.org> # 3.11.x
> Cc: Tod Jackson <tod.jackson@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Rafal Milecki <zajec5@gmail.com>
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
> Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Hi,
This is a little late but I am ok with the brcmsmac patch and the bcma
patch, feel free to add my Acked-by. This should go into 3.12 and 3.13+.
Hauke
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Simon Wunderlich @ 2013-10-02 12:40 UTC (permalink / raw)
To: Johannes Berg
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1380625757.14430.22.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Tue, Oct 01, 2013 at 01:09:17PM +0200, Johannes Berg wrote:
> On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote:
> > To use DFS in IBSS mode, userspace is required to react to radar events.
> > It can inform nl80211 that it is capable of doing so by adding a
> > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
>
> I don't like that name, it makes no sense. This has nothing to do with
> the port control (802.1X-style) at all.
>
How about NL80211_ATTR_DFS_CAPABLE instead?
> > If this attribute is supplied, DFS channels may be used if the driver
> > supports it. Support will be checked even if a channel without DFS will
> > be joined, as the channel might change later due to scan activity or
> > channel switch announcements.
>
> You also really should document *what* is required of userspace here.
> You're kinda saying this needs to be implemented, but not saying what
> needs to be done. I can't even tell - what does it really have to do?
Yeah, I should document this a little more: Userspace should react to
radar events and apprioately switch the channel when this happens. As
non-capable tools (like wpa_supplicant in it's current state) do not
react on radar events but might select DFS channels when available, there
might be non-conforming behaviour. Therefore I'm introducing this flag.
Userspace programs are supposed to set this flag when they have channel
management and radar avoidance/channel change functionality is implemented
to unlock DFS channels.
> Don't you implement most of it in patches 3 and 4 anyway in the kernel?
Nope, I don't.
I can resend the patchset with some more documentation on this.
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 12:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380708715.13329.16.camel@jlt4.sipsolutions.net>
I am not using latest mac80211/hostapd (in particular
compat-wireless-2013-04-16/hostapd-20130807) because I have to port
some personal stuff. In this scenario I was not able to establish an
AP/STA connection on DFS channel. Anyway I will update these packages.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
>> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
>> is CAC checked and available calling cfg80211_secondary_chans_ok().
>> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
>> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
>> frames on DFS channels causing association failures.
>
> I don't see how this can cause association failures? Please explain.
> DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
> more.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* [GIT PULL] firmware: wl1251 firmware binary
From: Felipe Balbi @ 2013-10-02 12:55 UTC (permalink / raw)
To: Felipe Balbi, dwmw2, ben
Cc: Luca Coelho, ben, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <20130925135943.GI10746@radagast>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Hi,
here's a pull request for wl4 firmware. I'll send a patch for wl1251
driver updating firmware load path.
The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db:
linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 04:53:32 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git wilink4
for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c:
ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500)
----------------------------------------------------------------
Felipe Balbi (1):
ti-connectivity: add wl1251 firmware and license
LICENCE.wl1251 | 59 +++++++++++++++++++++++++++++++++++++++++
WHENCE | 18 +++++++++++++
ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes
ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes
4 files changed, 77 insertions(+)
create mode 100644 LICENCE.wl1251
create mode 100644 ti-connectivity/wl1251-fw.bin
create mode 100644 ti-connectivity/wl1251-nvs.bin
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Kalle Valo @ 2013-10-02 13:00 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQnQVE_YUrrtfFCeQSj4tmccbA9cG_ZMdHisx4C-mJfqkg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
>> Recent WMI/HTC changes introduces this bug because
>> now WMI commands can sleep.
>>
>> Use appropriate interface iteration function.
>>
>> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Self NACK.
>
> I've posted this too soon. This patch can lead to deadlocks on
> iflist_mtx in some cases.
Ok, thanks for letting me know. I'll drop the patch from my queue.
--
Kalle Valo
^ 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