* [PATCH 0/2] ath10k: implement checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset adds tx and rx checksum offloading
to ath10k driver.
I don't have any hard numbers but I did observe a
consistently sligthly better performance on AP135
+ ath10k. Nothing ground breaking though.
Michal Kazior (2):
ath10k: implement rx checksum offloading
ath10k: implement tx checksum offloading
drivers/net/wireless/ath/ath10k/htt_rx.c | 40 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
3 files changed, 44 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] ath10k: implement rx checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260477-17030-1-git-send-email-michal.kazior@tieto.com>
HW supports L3/L4 rx checksum offloading.
This should reduce CPU load and improve
performance on slow host machines.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 40 ++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 04f08d9..e784c40 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -804,6 +804,37 @@ static bool ath10k_htt_rx_has_fcs_err(struct sk_buff *skb)
return false;
}
+static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb)
+{
+ struct htt_rx_desc *rxd;
+ u32 flags, info;
+ bool is_ip4, is_ip6;
+ bool is_tcp, is_udp;
+ bool ip_csum_ok, tcpudp_csum_ok;
+
+ rxd = (void *)skb->data - sizeof(*rxd);
+ flags = __le32_to_cpu(rxd->attention.flags);
+ info = __le32_to_cpu(rxd->msdu_start.info1);
+
+ is_ip4 = !!(info & RX_MSDU_START_INFO1_IPV4_PROTO);
+ is_ip6 = !!(info & RX_MSDU_START_INFO1_IPV6_PROTO);
+ is_tcp = !!(info & RX_MSDU_START_INFO1_TCP_PROTO);
+ is_udp = !!(info & RX_MSDU_START_INFO1_UDP_PROTO);
+ ip_csum_ok = !(flags & RX_ATTENTION_FLAGS_IP_CHKSUM_FAIL);
+ tcpudp_csum_ok = !(flags & RX_ATTENTION_FLAGS_TCP_UDP_CHKSUM_FAIL);
+
+ if (!is_ip4 && !is_ip6)
+ return CHECKSUM_NONE;
+ if (!is_tcp && !is_udp)
+ return CHECKSUM_NONE;
+ if (!ip_csum_ok)
+ return CHECKSUM_NONE;
+ if (!tcpudp_csum_ok)
+ return CHECKSUM_NONE;
+
+ return CHECKSUM_UNNECESSARY;
+}
+
static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
struct htt_rx_indication *rx)
{
@@ -815,6 +846,7 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
u8 *fw_desc;
int i, j;
int ret;
+ int ip_summed;
memset(&info, 0, sizeof(info));
@@ -889,6 +921,11 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
continue;
}
+ /* The skb is not yet processed and it may be
+ * reallocated. Since the offload is in the original
+ * skb extract the checksum now and assign it later */
+ ip_summed = ath10k_htt_rx_get_csum_state(msdu_head);
+
info.skb = msdu_head;
info.fcs_err = ath10k_htt_rx_has_fcs_err(msdu_head);
info.signal = ATH10K_DEFAULT_NOISE_FLOOR;
@@ -914,6 +951,8 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
if (ath10k_htt_rx_hdr_is_amsdu((void *)info.skb->data))
ath10k_dbg(ATH10K_DBG_HTT, "htt mpdu is amsdu\n");
+ info.skb->ip_summed = ip_summed;
+
ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "htt mpdu: ",
info.skb->data, info.skb->len);
ath10k_process_rx(htt->ar, &info);
@@ -980,6 +1019,7 @@ static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt,
info.status = HTT_RX_IND_MPDU_STATUS_OK;
info.encrypt_type = MS(__le32_to_cpu(rxd->mpdu_start.info0),
RX_MPDU_START_INFO0_ENCRYPT_TYPE);
+ info.skb->ip_summed = ath10k_htt_rx_get_csum_state(info.skb);
if (tkip_mic_err) {
ath10k_warn("tkip mic error\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ath10k: implement tx checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260477-17030-1-git-send-email-michal.kazior@tieto.com>
HW supports L3/L4 tx checksum offloading.
This should reduce CPU load and improve
performance on slow host machines.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index dc3f3e8..656c254 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -465,6 +465,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
flags1 = 0;
flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID);
+ flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
+ flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD;
frags_paddr = ATH10K_SKB_CB(txfrag)->paddr;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 344ad27..5784337 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3309,6 +3309,8 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
ar->hw->wiphy->n_iface_combinations = 1;
+ ar->hw->netdev_features = NETIF_F_HW_CSUM;
+
ret = ath_regd_init(&ar->ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
--
1.7.9.5
^ permalink raw reply related
* Re: AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Johannes Berg @ 2013-07-31 8:50 UTC (permalink / raw)
To: Arkadiusz Miskiewicz, Andy Isaacson; +Cc: linux-wireless, ilw
In-Reply-To: <201307310855.28080.a.miskiewicz@gmail.com>
On Wed, 2013-07-31 at 08:55 +0200, Arkadiusz Miskiewicz wrote:
> It basically reports:
> [79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
> [79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
>
> (note I have two wrt160nl here and problem happens with both)
>
> Any hints on why "we can't support" configuration issued by this (common) AP?
As far as I can tell, it seems to be an AP bug, but I had no idea this
was so common.
Testing with hostapd, I can switch bandwidth between 20 and 40 MHz just
fine, and it only prints "new config is ..." and then carries on.
Since you seem to be able to reproduce this easily, can you run tcpdump
with the beacon info?
sudo iw wlan0 interface add moni0 type monitor flags none
sudo ip link set moni0 up
sudo tcpdump -i moni0 -s0 -w /tmp/dump
and then wait for the problem to occur and send me (privately) the dump
file (best compressed)?
There's also a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=981445
johannes
^ permalink raw reply
* [PATCH 0/5] ath10k: fixes
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This is a batch up of a few fixes for ath10k
driver I had in my queue for some time now.
Michal Kazior (5):
ath10k: prevent using invalid ringbuffer indexes
ath10k: make sure to use passive scan when n_ssids is 0
ath10k: advertise more conservative intf combinations
ath10k: zero arvif memory on add_interface()
ath10k: fix failpath in MSI-X setup
drivers/net/wireless/ath/ath10k/ce.c | 5 +++++
drivers/net/wireless/ath/ath10k/mac.c | 16 +++++++++++++---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++++++-
3 files changed, 24 insertions(+), 4 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/5] ath10k: make sure to use passive scan when n_ssids is 0
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
Normally user specifies broadcast ssid for
scanning. If the user wants to do a passive scan
it does not pass any ssids.
The patch makes sure we ath10k tells firmware to
not send anything at all in case it decides no
ssids equals broadcast ssid.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 344ad27..1ea386e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2338,6 +2338,8 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
arg.ssids[i].len = req->ssids[i].ssid_len;
arg.ssids[i].ssid = req->ssids[i].ssid;
}
+ } else {
+ arg.scan_ctrl_flags |= WMI_SCAN_FLAG_PASSIVE;
}
if (req->n_channels) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/5] ath10k: prevent using invalid ringbuffer indexes
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
If the device is removed and hotplug fails
ioread32() will return 0xFFFFFFFF. In that case
reading ringbuffer during device bringup led to
out-of-bounds addressing of a ringbuffer array
that in turn led to a paging failure.
This could be reproduced by the following:
* boot without acpi/prevent hotplug from working
* insert and manually detect (pci rescan) the device
* remove the device physically
* load ath10k driver
* kernel crashed
Ringbuffer index reading is now protected by using
an appropriate mask to prevent addressing an
invalid array index.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index b407929..f8b969f 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -637,6 +637,7 @@ static int ath10k_ce_completed_send_next_nolock(struct ce_state *ce_state,
ath10k_pci_wake(ar);
src_ring->hw_index =
ath10k_ce_src_ring_read_index_get(ar, ctrl_addr);
+ src_ring->hw_index &= nentries_mask;
ath10k_pci_sleep(ar);
}
read_index = src_ring->hw_index;
@@ -950,10 +951,12 @@ static int ath10k_ce_init_src_ring(struct ath10k *ar,
ath10k_pci_wake(ar);
src_ring->sw_index = ath10k_ce_src_ring_read_index_get(ar, ctrl_addr);
+ src_ring->sw_index &= src_ring->nentries_mask;
src_ring->hw_index = src_ring->sw_index;
src_ring->write_index =
ath10k_ce_src_ring_write_index_get(ar, ctrl_addr);
+ src_ring->write_index &= src_ring->nentries_mask;
ath10k_pci_sleep(ar);
src_ring->per_transfer_context = (void **)ptr;
@@ -1035,8 +1038,10 @@ static int ath10k_ce_init_dest_ring(struct ath10k *ar,
ath10k_pci_wake(ar);
dest_ring->sw_index = ath10k_ce_dest_ring_read_index_get(ar, ctrl_addr);
+ dest_ring->sw_index &= dest_ring->nentries_mask;
dest_ring->write_index =
ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr);
+ dest_ring->write_index &= dest_ring->nentries_mask;
ath10k_pci_sleep(ar);
dest_ring->per_transfer_context = (void **)ptr;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] ath10k: advertise more conservative intf combinations
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
Apparently the available firmware has a limit of
handling 7 APs, 3 GOs or 8 STAs. This is based on
empirical tests and it is still possible some
combinations may crash the firmware.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1ea386e..6a130c5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3078,9 +3078,15 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = {
.max = 8,
.types = BIT(NL80211_IFTYPE_STATION)
| BIT(NL80211_IFTYPE_P2P_CLIENT)
- | BIT(NL80211_IFTYPE_P2P_GO)
- | BIT(NL80211_IFTYPE_AP)
- }
+ },
+ {
+ .max = 3,
+ .types = BIT(NL80211_IFTYPE_P2P_GO)
+ },
+ {
+ .max = 7,
+ .types = BIT(NL80211_IFTYPE_AP)
+ },
};
static const struct ieee80211_iface_combination ath10k_if_comb = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] ath10k: zero arvif memory on add_interface()
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
The private memory area in vif provided by
mac80211 isn't guaranteed to be zeroed.
This patch should fix issues when switching
between STA and AP interface types.
The tim_bitmap could become polluted by STA bssid
field (since it's a union), wep_keys array
could also become polluted with invalid pointers
and probably much more.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6a130c5..1aa5a39 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1925,6 +1925,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
mutex_lock(&ar->conf_mutex);
+ memset(arvif, 0, sizeof(*arvif));
+
arvif->ar = ar;
arvif->vif = vif;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] ath10k: fix failpath in MSI-X setup
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
pci_disable_msi() must be called if the initial
request_irq() fails.
Also add a warning message so it's possible to
distinguish request_irq() failure and
pci_enable_msi() failure.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index c71b488..d95439b 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1990,8 +1990,13 @@ static int ath10k_pci_start_intr_msix(struct ath10k *ar, int num)
ret = request_irq(ar_pci->pdev->irq + MSI_ASSIGN_FW,
ath10k_pci_msi_fw_handler,
IRQF_SHARED, "ath10k_pci", ar);
- if (ret)
+ if (ret) {
+ ath10k_warn("request_irq(%d) failed %d\n",
+ ar_pci->pdev->irq + MSI_ASSIGN_FW, ret);
+
+ pci_disable_msi(ar_pci->pdev);
return ret;
+ }
for (i = MSI_ASSIGN_CE_INITIAL; i <= MSI_ASSIGN_CE_MAX; i++) {
ret = request_irq(ar_pci->pdev->irq + i,
--
1.7.9.5
^ permalink raw reply related
* Re: 3.10, iwlwifi 6200AGN: AP changed bandwidth in a way we can't support - disconnect
From: Stanislaw Gruszka @ 2013-07-31 8:59 UTC (permalink / raw)
To: Andy Isaacson; +Cc: Johannes Berg, linux-wireless, netdev, Arkadiusz Miskiewicz
In-Reply-To: <20130729163452.GA454@hexapodia.org>
On Mon, Jul 29, 2013 at 09:34:52AM -0700, Andy Isaacson wrote:
> After upgrading to 3.10.4 and traveling to Europe I'm often suffering
> from failures to associate with the following in dmesg:
>
> [ 37.351621] wlan0: authenticate with 64:70:02:e6:a6:ba
> [ 37.364701] wlan0: send auth to 64:70:02:e6:a6:ba (try 1/3)
> [ 37.366358] wlan0: authenticated
> [ 37.368543] wlan0: associate with 64:70:02:e6:a6:ba (try 1/3)
> [ 37.372765] wlan0: RX AssocResp from 64:70:02:e6:a6:ba (capab=0x431 status=0 aid=8)
> [ 37.380190] wlan0: associated
> [ 37.438935] wlan0: AP 64:70:02:e6:a6:ba changed bandwidth, new config is 2447 MHz, width 1 (2447/0 MHz)
> [ 37.438941] wlan0: AP 64:70:02:e6:a6:ba changed bandwidth in a way we can't support - disconnect
>
> I hacked the driver to do
>
> - "AP %pM changed bandwidth, new config is %d MHz, width %d (%d/%d MHz)\n",
> + "AP %pM changed bandwidth, new config is %d MHz, width %d (%d/%d MHz) flags %x/%x\n",
> ifmgd->bssid, chandef.chan->center_freq, chandef.width,
> - chandef.center_freq1, chandef.center_freq2);
> + chandef.center_freq1, chandef.center_freq2, flags, ifmgd->flags);
>
> and
>
> - if (flags != (ifmgd->flags & (IEEE80211_STA_DISABLE_HT |
> + if ((flags != 0x810 && ifmgd->flags != 0x804) && (
> + flags != (ifmgd->flags & (IEEE80211_STA_DISABLE_HT |
>
> and the result is a working link with
We have few reports about this. Johannes, proposed this patch
http://p.sipsolutions.net/9d1dd0734d2c3a7a.txt
Could you check if it fixes the problem for you?
Stanislaw
^ permalink raw reply
* Re: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Felix Fietkau @ 2013-07-31 9:09 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8CD45.6060108@broadcom.com>
On 2013-07-31 10:39 AM, Arend van Spriel wrote:
> Hi Felix,
>
> How are things in OpenWRT. I wanted to ask you something regarding a
> defect I am looking at. Since kernel 3.9 several reports have been made
> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
3.9 was the first kernel to support CCK rates in minstrel_ht as
fallback (in case the link gets very bad). Not sure if that triggers
anything weird in brcmsmac.
> Debugging the issue shows we end up with a rate with MCS index 110,
> which is, well, impossible.
Did you verify that it comes directly from minstrel_ht, or does it show
up somewhere further down the chain in brcmsmac?
> As brcmsmac gets the rate info from
> minstrel_ht I was wondering if we have an intergration issue here. I saw
> around April patches about new API which may have been in the 3.9 time
> frame and something subtly changed things for brcmsmac.
The new rate API was added in 3.10, not 3.9. It did add bug that caused
bogus MCS rates. I've sent a patch for this a while back (shortly
before 3.10 was released), but it was too late to make it into the
release. I guess we have to wait for it to be applied through stable -
no idea why that hasn't happened yet.
Here is the fix:
commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
Author: Felix Fietkau <nbd@openwrt.org>
Date: Fri Jun 28 21:04:35 2013 +0200
mac80211/minstrel_ht: fix cck rate sampling
The CCK group needs special treatment to set the right flags and rate
index. Add this missing check to prevent setting broken rates for tx
packets.
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 5b2d301..f5aed96 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
+ rate->count = 1;
+
+ if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
+ int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
+ rate->idx = mp->cck_rates[idx];
+ rate->flags = 0;
+ return;
+ }
+
rate->idx = sample_idx % MCS_GROUP_RATES +
(sample_group->streams - 1) * MCS_GROUP_RATES;
rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
- rate->count = 1;
}
static void
^ permalink raw reply related
* Re: AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Arkadiusz Miskiewicz @ 2013-07-31 9:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andy Isaacson, linux-wireless, ilw
In-Reply-To: <1375260632.8289.10.camel@jlt4.sipsolutions.net>
On Wednesday 31 of July 2013, Johannes Berg wrote:
> On Wed, 2013-07-31 at 08:55 +0200, Arkadiusz Miskiewicz wrote:
> > It basically reports:
> > [79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config
> > is 2422 MHz, width 1 (2422/0 MHz) [79477.496072] eth1: AP
> > 68:7f:74:06:b3:1b changed bandwidth in a way we can't support -
> > disconnect
> >
> > (note I have two wrt160nl here and problem happens with both)
> >
> > Any hints on why "we can't support" configuration issued by this (common)
> > AP?
>
> As far as I can tell, it seems to be an AP bug, but I had no idea this
> was so common.
>
> Testing with hostapd, I can switch bandwidth between 20 and 40 MHz just
> fine, and it only prints "new config is ..." and then carries on.
>
> Since you seem to be able to reproduce this easily, can you run tcpdump
> with the beacon info?
Will do. Unfortunately the problem doesn't always happen. Sometimes things
work fine with this AP, sometimes they don't (and right now can't reproduce,
so waiting for thing to happen again).
btw. full dmesg
http://pastebin.com/zTfR5rTK
> johannes
--
Arkadiusz Miśkiewicz, arekm / maven.pl
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Arend van Spriel @ 2013-07-31 9:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau,
Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On 07/31/2013 02:53 AM, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead? We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest. Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
>
> If we are to embark on a new journey towards an open testing
> infrastructure what should be used? Ben, you have some stuff, and I
> know you also report some interesting bugs with insane amount of
> stations. Is any of it open?
>
> AFAICT mac80211_hwism should and likely already is used for a slew of
> core API changes / tests. Addressing testing using that shoud
> hopefully address tons of testings and find a lot of issues. We'd then
> just need vendors to replicate behaviour on top of their drivers. The
> core test stuff though still needs to be available.
>
> What do we have, anyone have any lofty plans?
We have a large testing infrastructure consisting of shielded boxes,
attenuators, etc. It is all exercised using tcl scripts and none of it
is open today. Who knows what tomorrow will bring. The brcm80211
open-source drivers are tested limited but nightly using it.
I am considering coming up with a new test framework for the brcm80211
drivers using python scripting, which is why I started py80211
experiment (available on github), but your mentioning of autotest makes
me want to revisit that.
Regards,
Arend
> [0] http://wireless.kernel.org/en/developers/Testing/wifi-test
> [1] http://wireless.kernel.org/en/developers/Summits/SanFranciscoBayArea-2010
> [2] http://wireless.kernel.org/en/users/Drivers/mac80211_hwsim
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 9:39 UTC (permalink / raw)
To: linux-wireless
Hi,
I hope this is the right place to ask for a little bit of help as I'm
currently beyond stuck on a challenge I'm trying to accomplish. I'm
trying to write a "simple" LKM that properly uses a ieee80211 header
to print information about the mac addresses (addr1->addr4) and later
down the road try to send my own data.
I only need to get L2 working, no need for TCP/IP, just a proper
ieee80211 based on input from skb would be huge for me.
So my issue: when placing the ieee80211 on my mac_header after I hook
my skb from my wireless device (wlan0 on android - I9100) I get a huge
amount of zero's and random(?) numbers when trying to print the
addresses. This leads me to the first conclusion that mac_header is
placed wrong when using 80211. After that I saw a lot of people just
using the skb->data pointer. Now this gives even weirder issues for me
and actually totally crashes my kernel.
So I went back to starting with printing as much info as possible.
This is a sample output after I hook my packet type:
Skb->dev->name: wlan0
Skb->head: 0xe1d37040
Skb->mac_header: 0xe1d372a9
Skb->data: 0x510 (!!!)
Skb->tail: 0xe1d37460
Skb->len: 617
Skb->hdr_len: 0
When trying to just capture this and only print a certain message when
one of the addresses maches my dev->dev_addr I never get any data
while the phone is connected and actively browsing the internet.
I'm aware that before I throw my hook some data is being changed
around already in net/core/dev.c and in net/mac80211/rx.c The weird
part is that these seem to be putting on ethernet headers
(skb->protocol = eth_type_trans(skb, dev); AND kb_pull_inline(skb,
ETH_HLEN);
eth = eth_hdr(skb); ) on items that should be ieee80211 headers.
Any insights as to why my data header is in such a weird spot (nowhere
between my head and my tail) or where I should call the
ieee80211_header on? I have tried working my way back from tail with
len and adding another ETH_HLEN but while I get data, it never really
matches my own mac addr so I'm assuming the data is still pretty
wrong.
Added links:
https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c
(my own program)
https://github.com/mathieudevos/linux_kernel_3.2.48 (used to get all
the .c files from to acquire information)
If possible I'd like to write a small guide after these issues have
been fixes for people who like me would like to get started with a
basic LKM in the ieee80211 part of linux.
If this is not the place to ask these questions, please disregard me
(hopefully it is) but all help would be welcome.
Kind regards,
Mathieu Devos
^ permalink raw reply
* Re: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Arend van Spriel @ 2013-07-31 9:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8D438.7020304@openwrt.org>
On 07/31/2013 11:09 AM, Felix Fietkau wrote:
> On 2013-07-31 10:39 AM, Arend van Spriel wrote:
>> Hi Felix,
>>
>> How are things in OpenWRT. I wanted to ask you something regarding a
>> defect I am looking at. Since kernel 3.9 several reports have been made
>> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
> 3.9 was the first kernel to support CCK rates in minstrel_ht as
> fallback (in case the link gets very bad). Not sure if that triggers
> anything weird in brcmsmac.
It just might reading this in brcmsmac:
/*
* Currently only support same setting for primary and
* fallback rates. Unify flags for each rate into a
* single value for the frame
*/
use_rts |= txrate[k]->flags & IEEE80211_TX_RC_USE_RTS_CTS
? true : false;
use_cts |= txrate[k]->flags & IEEE80211_TX_RC_USE_CTS_PROTECT
? true : false;
Although this is not directly
>> Debugging the issue shows we end up with a rate with MCS index 110,
>> which is, well, impossible.
> Did you verify that it comes directly from minstrel_ht, or does it show
> up somewhere further down the chain in brcmsmac?
I am pretty sure it is not minstrel_ht. brcmsmac converts the
information from minstrel_ht into a so-called ratespec format. The
strange MCS is what I see in the ratespec leading up to the
divide-by-zero. Next thing to look at is the conversion step. As said
above the CCK fallback might be the culprit. I mean how brcmsmac deals
with it is.
>> As brcmsmac gets the rate info from
>> minstrel_ht I was wondering if we have an intergration issue here. I saw
>> around April patches about new API which may have been in the 3.9 time
>> frame and something subtly changed things for brcmsmac.
> The new rate API was added in 3.10, not 3.9. It did add bug that caused
> bogus MCS rates. I've sent a patch for this a while back (shortly
> before 3.10 was released), but it was too late to make it into the
> release. I guess we have to wait for it to be applied through stable -
> no idea why that hasn't happened yet.
Ping Greg? I will give it a try.
Thanks,
Arend
> Here is the fix:
>
> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Fri Jun 28 21:04:35 2013 +0200
>
> mac80211/minstrel_ht: fix cck rate sampling
>
> The CCK group needs special treatment to set the right flags and rate
> index. Add this missing check to prevent setting broken rates for tx
> packets.
>
> Cc: stable@vger.kernel.org # 3.10
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 5b2d301..f5aed96 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
>
> sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
> info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
> + rate->count = 1;
> +
> + if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
> + int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
> + rate->idx = mp->cck_rates[idx];
> + rate->flags = 0;
> + return;
> + }
> +
> rate->idx = sample_idx % MCS_GROUP_RATES +
> (sample_group->streams - 1) * MCS_GROUP_RATES;
> rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
> - rate->count = 1;
> }
>
> static void
>
>
^ permalink raw reply
* Re: Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Sedat Dilek @ 2013-07-31 9:46 UTC (permalink / raw)
To: Felix Fietkau
Cc: Arend van Spriel, linux-wireless, John W. Linville, John Greene
In-Reply-To: <51F8D438.7020304@openwrt.org>
On Wed, Jul 31, 2013 at 11:09 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2013-07-31 10:39 AM, Arend van Spriel wrote:
>> Hi Felix,
>>
>> How are things in OpenWRT. I wanted to ask you something regarding a
>> defect I am looking at. Since kernel 3.9 several reports have been made
>> about a kernel panic in brcmsmac, ie. a divide-by-zero error.
> 3.9 was the first kernel to support CCK rates in minstrel_ht as
> fallback (in case the link gets very bad). Not sure if that triggers
> anything weird in brcmsmac.
>
>> Debugging the issue shows we end up with a rate with MCS index 110,
>> which is, well, impossible.
> Did you verify that it comes directly from minstrel_ht, or does it show
> up somewhere further down the chain in brcmsmac?
>
>> As brcmsmac gets the rate info from
>> minstrel_ht I was wondering if we have an intergration issue here. I saw
>> around April patches about new API which may have been in the 3.9 time
>> frame and something subtly changed things for brcmsmac.
> The new rate API was added in 3.10, not 3.9. It did add bug that caused
> bogus MCS rates. I've sent a patch for this a while back (shortly
> before 3.10 was released), but it was too late to make it into the
> release. I guess we have to wait for it to be applied through stable -
> no idea why that hasn't happened yet.
>
> Here is the fix:
>
> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Fri Jun 28 21:04:35 2013 +0200
>
> mac80211/minstrel_ht: fix cck rate sampling
>
That patch is not in Linus tree yet, so it won't get into stable.
- Sedat -
> The CCK group needs special treatment to set the right flags and rate
> index. Add this missing check to prevent setting broken rates for tx
> packets.
>
> Cc: stable@vger.kernel.org # 3.10
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 5b2d301..f5aed96 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
>
> sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
> info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
> + rate->count = 1;
> +
> + if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
> + int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
> + rate->idx = mp->cck_rates[idx];
> + rate->flags = 0;
> + return;
> + }
> +
> rate->idx = sample_idx % MCS_GROUP_RATES +
> (sample_group->streams - 1) * MCS_GROUP_RATES;
> rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
> - rate->count = 1;
> }
>
> static void
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3.11] mac80211: ignore HT primary channel while connected
From: Johannes Berg @ 2013-07-31 9:50 UTC (permalink / raw)
To: linux-wireless
Cc: Arkadiusz Miskiewicz, Andy Isaacson, Stanislaw Gruszka,
Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
While we're connected, the AP shouldn't change the primary channel
in the HT information. We checked this, and dropped the connection
if it did change it.
Unfortunately, this is causing problems on some APs, e.g. on the
Netgear WRT610NL: the beacons seem to always contain a bad channel
and if we made a connection using a probe response (correct data)
we drop the connection immediately and can basically not connect
properly at all.
Work around this by ignoring the HT primary channel information in
beacons if we're already connected.
Also print out more verbose messages in the other situations to
help diagnose similar bugs quicker in the future.
Cc: stable@vger.kernel.org [3.10]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 383a961..77e7796 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -211,8 +211,9 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel *channel,
const struct ieee80211_ht_operation *ht_oper,
const struct ieee80211_vht_operation *vht_oper,
- struct cfg80211_chan_def *chandef, bool verbose)
+ struct cfg80211_chan_def *chandef, bool tracking)
{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct cfg80211_chan_def vht_chandef;
u32 ht_cfreq, ret;
@@ -231,7 +232,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
ht_cfreq = ieee80211_channel_to_frequency(ht_oper->primary_chan,
channel->band);
/* check that channel matches the right operating channel */
- if (channel->center_freq != ht_cfreq) {
+ if (!tracking && channel->center_freq != ht_cfreq) {
/*
* It's possible that some APs are confused here;
* Netgear WNDR3700 sometimes reports 4 higher than
@@ -239,11 +240,10 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
* since we look at probe response/beacon data here
* it should be OK.
*/
- if (verbose)
- sdata_info(sdata,
- "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
- channel->center_freq, ht_cfreq,
- ht_oper->primary_chan, channel->band);
+ sdata_info(sdata,
+ "Wrong control channel: center-freq: %d ht-cfreq: %d ht->primary_chan: %d band: %d - Disabling HT\n",
+ channel->center_freq, ht_cfreq,
+ ht_oper->primary_chan, channel->band);
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
goto out;
}
@@ -297,7 +297,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
channel->band);
break;
default:
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT operation IE has invalid channel width (%d), disable VHT\n",
vht_oper->chan_width);
@@ -306,7 +306,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_valid(&vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information is invalid, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -319,7 +319,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data *sdata,
}
if (!cfg80211_chandef_compatible(chandef, &vht_chandef)) {
- if (verbose)
+ if (!(ifmgd->flags & IEEE80211_STA_DISABLE_VHT))
sdata_info(sdata,
"AP VHT information doesn't match HT, disable VHT\n");
ret = IEEE80211_STA_DISABLE_VHT;
@@ -346,7 +346,7 @@ out:
ret |= chandef_downgrade(chandef);
}
- if (chandef->width != vht_chandef.width && verbose)
+ if (chandef->width != vht_chandef.width && !tracking)
sdata_info(sdata,
"capabilities/regulatory prevented using AP HT/VHT configuration, downgraded\n");
@@ -386,7 +386,7 @@ static int ieee80211_config_bw(struct ieee80211_sub_if_data *sdata,
/* calculate new channel (type) based on HT/VHT operation IEs */
flags = ieee80211_determine_chantype(sdata, sband, chan, ht_oper,
- vht_oper, &chandef, false);
+ vht_oper, &chandef, true);
/*
* Downgrade the new channel if we associated with restricted
@@ -3838,7 +3838,7 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
ifmgd->flags |= ieee80211_determine_chantype(sdata, sband,
cbss->channel,
ht_oper, vht_oper,
- &chandef, true);
+ &chandef, false);
sdata->needed_rx_chains = min(ieee80211_ht_vht_rx_chains(sdata, cbss),
local->rx_chains);
--
1.8.0
^ permalink raw reply related
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-07-31 10:08 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+Soy5=MfUUahaP3Ka2onp+jP9aupbhGu_QHco=CP7Y9sqhQ@mail.gmail.com>
On 07/31/2013 11:39 AM, Mathieu Devos wrote:
> Hi,
>
> I hope this is the right place to ask for a little bit of help as I'm
> currently beyond stuck on a challenge I'm trying to accomplish. I'm
> trying to write a "simple" LKM that properly uses a ieee80211 header
> to print information about the mac addresses (addr1->addr4) and later
> down the road try to send my own data.
>
> I only need to get L2 working, no need for TCP/IP, just a proper
> ieee80211 based on input from skb would be huge for me.
>
> So my issue: when placing the ieee80211 on my mac_header after I hook
> my skb from my wireless device (wlan0 on android - I9100)
Not sure what you goal is, but what wireless device is that? You may
just get 802.3 packets from the device.
Gr. AvS
> I get a huge
> amount of zero's and random(?) numbers when trying to print the
> addresses. This leads me to the first conclusion that mac_header is
> placed wrong when using 80211. After that I saw a lot of people just
> using the skb->data pointer. Now this gives even weirder issues for me
> and actually totally crashes my kernel.
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 10:28 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F8E228.9080600@broadcom.com>
Hi,
It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
have a normal ethernet 802.3 input even. I check before selecting the
device that it's wireless (through ieee80211_ptr) and this properly
returns the wlan0 device which should be on the 80211 standard.
My goal is to get the ieee80211_header properly on the skb with this
device, but some of the pointers and original data in the skb seem
totally off. This leaves me clueless as to where to put this
ieee80211_header.
I've tried putting it right on skb->head (wrong I know, but I was
getting desperate), on skb->mac_header (also wrong, no idea why
though), I went back from skb->tail with len and even added ETH_HLEN
to that as well because you can see that before my hook gets
activated: skb_pull_inline(skb, ETH_HLEN);
In the end I'm left with a header that is forced onto data but with a
wrong origin pointer thus basically leaving me with all wrong data in
the header.
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>
>> Hi,
>>
>> I hope this is the right place to ask for a little bit of help as I'm
>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>> trying to write a "simple" LKM that properly uses a ieee80211 header
>> to print information about the mac addresses (addr1->addr4) and later
>> down the road try to send my own data.
>>
>> I only need to get L2 working, no need for TCP/IP, just a proper
>> ieee80211 based on input from skb would be huge for me.
>>
>> So my issue: when placing the ieee80211 on my mac_header after I hook
>> my skb from my wireless device (wlan0 on android - I9100)
>
>
> Not sure what you goal is, but what wireless device is that? You may just
> get 802.3 packets from the device.
>
> Gr. AvS
>
>
>> I get a huge
>> amount of zero's and random(?) numbers when trying to print the
>> addresses. This leads me to the first conclusion that mac_header is
>> placed wrong when using 80211. After that I saw a lot of people just
>> using the skb->data pointer. Now this gives even weirder issues for me
>> and actually totally crashes my kernel.
>
>
>
>
^ permalink raw reply
* Re: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
From: Laurent Pinchart @ 2013-07-31 10:36 UTC (permalink / raw)
To: Luciano Coelho
Cc: devicetree, linux-doc, mturquette, mark.rutland, balbi,
grant.likely, rob.herring, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel, tony, nm
In-Reply-To: <1375215668-29171-1-git-send-email-coelho@ti.com>
Hi Luciano,
On Tuesday 30 July 2013 23:21:08 Luciano Coelho wrote:
> Add device tree bindings documentation for the TI WiLink modules.
> Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> modules is supported.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>
> In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
>
> .../devicetree/bindings/net/wireless/ti-wilink.txt | 68
> ++++++++++++++++++++++ 1 file changed, 68 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file
> mode 100644
> index 0000000..aafebb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> @@ -0,0 +1,68 @@
> +TI WiLink Wireless Modules Device Tree Bindings
> +===============================================
> +
> +The WiLink modules provide wireless connectivity, such as WLAN,
> +Bluetooth, FM and NFC.
> +
> +There are several different modules available, which can be grouped by
> +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
> +currently supported with device tree.
> +
> +Currently, only the WLAN portion of the modules is supported with
> +device tree.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
> +- interrupt-parent: the interrupt controller
> +- interrupts: out-of-band WLAN interrupt
> + See the interrupt controller's bindings documentation for
> + detailed definition.
> +
> +Optional properties:
> +--------------------
> +
> +- clocks: list of clocks needed by the chip as follows:
> +
> + refclock: the internal WLAN reference clock frequency (required for
> + WiLink6 and WiLink7; not used for WiLink8).
> +
> + tcxoclock: the internal WLAN TCXO clock frequency (required for
> + WiLink7 not used for WiLink6 and WiLink8).
> +
> + The clocks must be defined and named accordingly. For example:
> +
> + clocks = <&refclock>
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +
> + Some modules that contain the WiLink chip provide clocks in the
> + module itself. In this case, we define a "ti,wilink-clock" as shown
> + above. But any other clock could in theory be used, so the proper
> + clock definition should be used.
> +
> +
> +Example:
> +--------
> +
> +Example definition that can be used in OMAP4 Panda:
> +
> +wlan {
> + compatible = "ti,wilink6";
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
> + clocks = <&refclock>;
> + clock-names = "refclock";
> +
> + refclock: refclock {
> + compatible = "ti,wilink-clock";
> + #clock-cells = <0>;
> + clock-frequency = <38400000>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ath10k: move irq setup
From: Michal Kazior @ 2013-07-31 10:50 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQn-VF-Ehio4Az6GenGb5cBTm2t2a9bQFAuALFhx+MQ+cw@mail.gmail.com>
On 31 July 2013 07:50, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 30 July 2013 20:35, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> There was a slight race during PCI shutdown. Since
>>> interrupts weren't really stopped (only Copy
>>> Engine interrupts were disabled through device hw
>>> registers) it was possible for a firmware
>>> indication (crash) interrupt to come in after
>>> tasklets were synced/killed. This would cause
>>> memory corruption and a panic in most cases. It
>>> was also possible for interrupt to come before CE
>>> was initialized during device probing.
>>>
>>> Interrupts are required for BMI phase so they are enabled as soon as
>>> power_up() is called but are freed upon both power_down() and stop()
>>> so there's asymmetry here. As by design stop() cannot be followed by
>>> start() it is okay. Both power_down() and stop() should be merged
>>> later on to avoid confusion.
>>
>> Why are the interrupts freed both in power_down() and stop()? I don't
>> get that.
>>
>> What if we call disable_irq() in power_down() instead?
>
> power_down() must call free_irq(), because power_up() calls
> request_irq() (if you want the symmetry). If anything, the stop()
> should call disable_irq(), but wouldn't that mean start() should call
> enable_irq()? But than, irqs are needed before start()..
>
> I did think about disable_irq() but AFAIR you need to enable_irq()
> later on (so either way you need to keep track of the irq state or
> you'll get a ton of WARN_ONs from the system). I'll double check that
> and report back later
enable/disable_irq must be balanced as well.
There are two cases of power cycle:
* power_up, power_down
* power_up, start, stop, power_down
If irq setup is moved from pci_probe/remove to power_up/power_down,
then stop() still needs irqs to be halted - either disable_irq, or
free_irq. In the latter case power_down must be prepared and not issue
free_irq again.
If irq setup remains in pci_probe/remove then both stop() and
power_down() need irqs to be halted too. Same issue applies.
If stop/power_down is merged than the whole problem is solved. This
seems like the sane solution to the whole problem but requires some
refactoring to be done first.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-07-31 11:05 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless
In-Reply-To: <CAE_+Soyxz-RfyVeg-Z4Fv5tmUtH=9wutxgM0CGjHEne9zJq+Kg@mail.gmail.com>
On 07/31/2013 12:28 PM, Mathieu Devos wrote:
> Hi,
>
> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
> have a normal ethernet 802.3 input even. I check before selecting the
> device that it's wireless (through ieee80211_ptr) and this properly
> returns the wlan0 device which should be on the 80211 standard.
*sigh* Welcome in the world of protocol stacks, wireless, networking
(choose your poison). Let me draw the picture.
o user-space
|
----------------------
| kernel
+-----------+
| NET | networking subsystem, ie. TCP/IP stack
+-----------+
| 802.3
+----------------+
| | driver |
| +------------+ |
| |802.11 stack| |
| +------------+ |
| | 802.11 |
+----------------+
|
o RF
The device hooks up to the networking subsystem as an ethernet device
and as such it receives 802.3 packets. These are converted to 802.11
packets by the 802.11 stack. Now depending on your device that happens
in the device driver or on the device itself. Another option is that
this is done by mac80211 (kernel provided 802.11 stack), but that is
probably not the case, but to be sure I ask again: what wireless device
do you have in your galaxy S2?
Gr. AvS
> My goal is to get the ieee80211_header properly on the skb with this
> device, but some of the pointers and original data in the skb seem
> totally off. This leaves me clueless as to where to put this
> ieee80211_header.
> I've tried putting it right on skb->head (wrong I know, but I was
> getting desperate), on skb->mac_header (also wrong, no idea why
> though), I went back from skb->tail with len and even added ETH_HLEN
> to that as well because you can see that before my hook gets
> activated: skb_pull_inline(skb, ETH_HLEN);
> In the end I'm left with a header that is forced onto data but with a
> wrong origin pointer thus basically leaving me with all wrong data in
> the header.
>
> Kind regards,
> Mathieu Devos
>
> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>
>>> Hi,
>>>
>>> I hope this is the right place to ask for a little bit of help as I'm
>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>> to print information about the mac addresses (addr1->addr4) and later
>>> down the road try to send my own data.
>>>
>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>> ieee80211 based on input from skb would be huge for me.
>>>
>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>> my skb from my wireless device (wlan0 on android - I9100)
>>
>>
>> Not sure what you goal is, but what wireless device is that? You may just
>> get 802.3 packets from the device.
>>
>> Gr. AvS
>>
>>
>>> I get a huge
>>> amount of zero's and random(?) numbers when trying to print the
>>> addresses. This leads me to the first conclusion that mac_header is
>>> placed wrong when using 80211. After that I saw a lot of people just
>>> using the skb->data pointer. Now this gives even weirder issues for me
>>> and actually totally crashes my kernel.
>>
>>
>>
>>
>
^ permalink raw reply
* Re: Power saving features for iwl4965
From: Stanislaw Gruszka @ 2013-07-31 12:08 UTC (permalink / raw)
To: Pedro Francisco; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <CAJZjf_y9fnkHLp4YPdYY2sVo4r4+hKJcZAebJmjVKCBh-0EUtA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On Wed, Jul 17, 2013 at 12:48:30PM +0100, Pedro Francisco wrote:
> On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >> I seem only to be able to trigger it with disable_hw_scan=0, I need
> >> further testing with disable_hw_scan=1 (I use disable_hw_scan=0
> >> because it prevents me from getting disconnected from eduroam Cisco
> >> APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
> >> scanning patch, however).
> >>
> >> Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
> >> disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
> >> know if it matters).
> >
> > As this is not causing troubles with default disable_hw_scan option,
> > I'll post that patch.
>
> My mistake, I can trigger error conditions _independently_ of
> disable_hw_scan option being enabled or disabled, as long as powersave
> is enabled.
>
> I'll send you a private email with the logs.
I think I found bug which couse this firmware crash. We have only 5
queues so updating write_ptr for txq[5] can cause random value write
to HBUS_TARG_WRPTR register. I also added spin_lock to do not abuse
writes we do in tx skb.
Please test attached patch (with powersave on :-)
Stanislaw
[-- Attachment #2: iwlegacy_fix_wakeup_interrupt.patch --]
[-- Type: text/plain, Size: 818 bytes --]
diff --git a/drivers/net/wireless/iwlegacy/3945-mac.c b/drivers/net/wireless/iwlegacy/3945-mac.c
index b37a582..afa5c6e 100644
--- a/drivers/net/wireless/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/iwlegacy/3945-mac.c
@@ -1495,12 +1495,14 @@ il3945_irq_tasklet(struct il_priv *il)
if (inta & CSR_INT_BIT_WAKEUP) {
D_ISR("Wakeup interrupt\n");
il_rx_queue_update_write_ptr(il, &il->rxq);
+
+ spin_lock_irqsave(&il->lock, flags);
il_txq_update_write_ptr(il, &il->txq[0]);
il_txq_update_write_ptr(il, &il->txq[1]);
il_txq_update_write_ptr(il, &il->txq[2]);
il_txq_update_write_ptr(il, &il->txq[3]);
il_txq_update_write_ptr(il, &il->txq[4]);
- il_txq_update_write_ptr(il, &il->txq[5]);
+ spin_unlock_irqrestore(&il->lock, flags);
il->isr_stats.wakeup++;
handled |= CSR_INT_BIT_WAKEUP;
^ permalink raw reply related
* Re: Skb and ieee80211 headers
From: Mathieu Devos @ 2013-07-31 12:39 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51F8EF8F.90109@broadcom.com>
Hi,
The wireless chip is a Broadcast BCM4330 chip. After looking around a
bit I found that this is a fullMAC and links to the driver on
wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
and also links directly to android itself:
https://android.googlesource.com/platform/hardware/broadcom/wlan
Still trying to learn a lot in this tightly packed world of protocol
stacks, wireless and all the other poisons. Seems like I still have a
long way to go. Thank you already for helping me out with these issues
and taking the time to explain these things to me.
Kind regards,
Mathieu Devos
On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>
>> Hi,
>>
>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>> have a normal ethernet 802.3 input even. I check before selecting the
>> device that it's wireless (through ieee80211_ptr) and this properly
>> returns the wlan0 device which should be on the 80211 standard.
>
>
> *sigh* Welcome in the world of protocol stacks, wireless, networking (choose
> your poison). Let me draw the picture.
>
> o user-space
> |
> ----------------------
> | kernel
> +-----------+
> | NET | networking subsystem, ie. TCP/IP stack
> +-----------+
> | 802.3
> +----------------+
> | | driver |
> | +------------+ |
> | |802.11 stack| |
> | +------------+ |
> | | 802.11 |
> +----------------+
> |
> o RF
>
> The device hooks up to the networking subsystem as an ethernet device and as
> such it receives 802.3 packets. These are converted to 802.11 packets by the
> 802.11 stack. Now depending on your device that happens in the device driver
> or on the device itself. Another option is that this is done by mac80211
> (kernel provided 802.11 stack), but that is probably not the case, but to be
> sure I ask again: what wireless device do you have in your galaxy S2?
>
> Gr. AvS
>
>
>> My goal is to get the ieee80211_header properly on the skb with this
>> device, but some of the pointers and original data in the skb seem
>> totally off. This leaves me clueless as to where to put this
>> ieee80211_header.
>> I've tried putting it right on skb->head (wrong I know, but I was
>> getting desperate), on skb->mac_header (also wrong, no idea why
>> though), I went back from skb->tail with len and even added ETH_HLEN
>> to that as well because you can see that before my hook gets
>> activated: skb_pull_inline(skb, ETH_HLEN);
>> In the end I'm left with a header that is forced onto data but with a
>> wrong origin pointer thus basically leaving me with all wrong data in
>> the header.
>>
>> Kind regards,
>> Mathieu Devos
>>
>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel <arend@broadcom.com>
>> wrote:
>>>
>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I hope this is the right place to ask for a little bit of help as I'm
>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>> to print information about the mac addresses (addr1->addr4) and later
>>>> down the road try to send my own data.
>>>>
>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>> ieee80211 based on input from skb would be huge for me.
>>>>
>>>> So my issue: when placing the ieee80211 on my mac_header after I hook
>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>
>>>
>>>
>>> Not sure what you goal is, but what wireless device is that? You may just
>>> get 802.3 packets from the device.
>>>
>>> Gr. AvS
>>>
>>>
>>>> I get a huge
>>>> amount of zero's and random(?) numbers when trying to print the
>>>> addresses. This leads me to the first conclusion that mac_header is
>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>> using the skb->data pointer. Now this gives even weirder issues for me
>>>> and actually totally crashes my kernel.
>>>
>>>
>>>
>>>
>>>
>>
>
>
^ 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