Linux wireless drivers development
 help / color / mirror / Atom feed
* [PATCH 0/2] wil6210: Tx path improvements
From: Vladimir Kondratiev @ 2013-06-23  9:59 UTC (permalink / raw)
  To: John W . Linville
  Cc: Kirshenbaum Erez, Vladimir Kondratiev, Johannes Berg,
	linux-wireless, Luis R . Rodriguez, Jouni Malinen

Couple of patches from Erez, addressing Tx path

Kirshenbaum Erez (2):
  wil6210: set vring index for all descriptors
  wil6210: add HW write-back option in TX descriptor

 drivers/net/wireless/ath/wil6210/txrx.c | 12 ++++++------
 drivers/net/wireless/ath/wil6210/txrx.h |  4 ++++
 2 files changed, 10 insertions(+), 6 deletions(-)

-- 
1.8.1.2


^ permalink raw reply

* [PATCH 1/2] wil6210: set vring index for all descriptors
From: Vladimir Kondratiev @ 2013-06-23  9:59 UTC (permalink / raw)
  To: John W . Linville
  Cc: Kirshenbaum Erez, Johannes Berg, linux-wireless,
	Luis R . Rodriguez, Vladimir Kondratiev, Jouni Malinen
In-Reply-To: <1371981575-14395-1-git-send-email-qca_vkondrat@qca.qualcomm.com>

From: Kirshenbaum Erez <erezk@wilocity.com>

The vring index (MAC queue id) must be set in all TX descriptors
otherwise HW will fail to release descriptors for a specific vring
(disconnect or vring switch flows).
This is normally occurs when fragmentation required, if vring index
will not be the same for all SKB descriptors HW will fail to flush
this MAC queue.

Signed-off-by: Kirshenbaum Erez <erezk@wilocity.com>
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
 drivers/net/wireless/ath/wil6210/txrx.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index e1c492b..73d6c2d 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -621,7 +621,8 @@ static struct vring *wil_find_tx_vring(struct wil6210_priv *wil,
 	return NULL;
 }
 
-static int wil_tx_desc_map(struct vring_tx_desc *d, dma_addr_t pa, u32 len)
+static int wil_tx_desc_map(struct vring_tx_desc *d, dma_addr_t pa, u32 len,
+			   int vring_index)
 {
 	wil_desc_addr_set(&d->dma.addr, pa);
 	d->dma.ip_length = 0;
@@ -630,7 +631,7 @@ static int wil_tx_desc_map(struct vring_tx_desc *d, dma_addr_t pa, u32 len)
 	d->dma.error = 0;
 	d->dma.status = 0; /* BIT(0) should be 0 for HW_OWNED */
 	d->dma.length = cpu_to_le16((u16)len);
-	d->dma.d0 = 0;
+	d->dma.d0 = (vring_index << DMA_CFG_DESC_TX_0_QID_POS);
 	d->mac.d[0] = 0;
 	d->mac.d[1] = 0;
 	d->mac.d[2] = 0;
@@ -684,7 +685,7 @@ static int wil_tx_vring(struct wil6210_priv *wil, struct vring *vring,
 	if (unlikely(dma_mapping_error(dev, pa)))
 		return -EINVAL;
 	/* 1-st segment */
-	wil_tx_desc_map(d, pa, skb_headlen(skb));
+	wil_tx_desc_map(d, pa, skb_headlen(skb), vring_index);
 	d->mac.d[2] |= ((nr_frags + 1) <<
 		       MAC_CFG_DESC_TX_2_NUM_OF_DESCRIPTORS_POS);
 	if (nr_frags)
@@ -701,7 +702,7 @@ static int wil_tx_vring(struct wil6210_priv *wil, struct vring *vring,
 				DMA_TO_DEVICE);
 		if (unlikely(dma_mapping_error(dev, pa)))
 			goto dma_error;
-		wil_tx_desc_map(d, pa, len);
+		wil_tx_desc_map(d, pa, len, vring_index);
 		vring->ctx[i] = NULL;
 		*_d = *d;
 	}
@@ -709,7 +710,6 @@ static int wil_tx_vring(struct wil6210_priv *wil, struct vring *vring,
 	d->dma.d0 |= BIT(DMA_CFG_DESC_TX_0_CMD_EOP_POS);
 	d->dma.d0 |= BIT(9); /* BUG: undocumented bit */
 	d->dma.d0 |= BIT(DMA_CFG_DESC_TX_0_CMD_DMA_IT_POS);
-	d->dma.d0 |= (vring_index << DMA_CFG_DESC_TX_0_QID_POS);
 	*_d = *d;
 
 	wil_hex_dump_txrx("Tx ", DUMP_PREFIX_NONE, 32, 4,
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH 2/2] wil6210: add HW write-back option in TX descriptor
From: Vladimir Kondratiev @ 2013-06-23  9:59 UTC (permalink / raw)
  To: John W . Linville
  Cc: Kirshenbaum Erez, Johannes Berg, linux-wireless,
	Luis R . Rodriguez, Vladimir Kondratiev, Jouni Malinen
In-Reply-To: <1371981575-14395-1-git-send-email-qca_vkondrat@qca.qualcomm.com>

From: Kirshenbaum Erez <erezk@wilocity.com>

Map BIT 9 in TX DMA DWARD 0 as HW write back option.
We must turn on this option in the last TX descriptor,
this is required for old HW compatability.
This option indicate to HW that WB is required for this descriptor.

Signed-off-by: Kirshenbaum Erez <erezk@wilocity.com>
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
 drivers/net/wireless/ath/wil6210/txrx.c | 2 +-
 drivers/net/wireless/ath/wil6210/txrx.h | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 73d6c2d..d240b24 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -708,7 +708,7 @@ static int wil_tx_vring(struct wil6210_priv *wil, struct vring *vring,
 	}
 	/* for the last seg only */
 	d->dma.d0 |= BIT(DMA_CFG_DESC_TX_0_CMD_EOP_POS);
-	d->dma.d0 |= BIT(9); /* BUG: undocumented bit */
+	d->dma.d0 |= BIT(DMA_CFG_DESC_TX_0_CMD_MARK_WB_POS);
 	d->dma.d0 |= BIT(DMA_CFG_DESC_TX_0_CMD_DMA_IT_POS);
 	*_d = *d;
 
diff --git a/drivers/net/wireless/ath/wil6210/txrx.h b/drivers/net/wireless/ath/wil6210/txrx.h
index 23c0781..859aea6 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.h
+++ b/drivers/net/wireless/ath/wil6210/txrx.h
@@ -201,6 +201,10 @@ struct vring_tx_mac {
 #define DMA_CFG_DESC_TX_0_CMD_EOP_LEN 1
 #define DMA_CFG_DESC_TX_0_CMD_EOP_MSK 0x100
 
+#define DMA_CFG_DESC_TX_0_CMD_MARK_WB_POS 9
+#define DMA_CFG_DESC_TX_0_CMD_MARK_WB_LEN 1
+#define DMA_CFG_DESC_TX_0_CMD_MARK_WB_MSK 0x200
+
 #define DMA_CFG_DESC_TX_0_CMD_DMA_IT_POS 10
 #define DMA_CFG_DESC_TX_0_CMD_DMA_IT_LEN 1
 #define DMA_CFG_DESC_TX_0_CMD_DMA_IT_MSK 0x400
-- 
1.8.1.2


^ permalink raw reply related

* Re: pull request: bluetooth 2013-06-23
From: Johan Hedberg @ 2013-06-23  7:58 UTC (permalink / raw)
  To: Gustavo Padovan, linville, linux-wireless, linux-bluetooth,
	linux-kernel
In-Reply-To: <20130623021351.GA2327@joana>

Hi,

On Sun, Jun 23, 2013, Gustavo Padovan wrote:
> A important fix to 3.10, this patch fixes an issues that was preventing the 
> l2cap info response command to be handled properly. Please pull. Thanks!

I'd like to add here (since it's not obvious) that this is not just
about failing to parse the L2CAP info response. Once the code gives up
parsing this PDU it also gives up essential parts of the L2CAP
connection creation process, i.e. without this patch the stack will fail
to establish connections properly. So it'd be very good if we can get
this into 3.10 (as well as the stable trees where the patch that
introduced this bug is already on its way).

Johan

^ permalink raw reply

* RE: [RFC] P2P find phase offload
From: Peer, Ilan @ 2013-06-23  7:00 UTC (permalink / raw)
  To: Vladimir Kondratiev, Johannes Berg
  Cc: linux-wireless@vger.kernel.org, Luis R . Rodriguez,
	John W . Linville, Jouni Malinen
In-Reply-To: <62351675.buL3FVoAHm@lx-vladimir>

Hi,

Overall, looks like option 2 is more favorable due to the flexibility, and below is an example for where this flexibility might be useful.

The wpa_supplicant has logic to determine if to respond to a probe request or not based on the local device ID and local device types, and will not respond to probe requests if:

1. The probe request contains a device ID IE and the device ID does not match the local one.
2. The probe request contains specific devices types, and the requested device types do not match the local ones.

Based on the p2p_find offload API you defined, the FW/driver will lack the information of the local Device ID and local device types, so in such cases the FW/driver will not know if it should reply to the response or not. 

Obviously, the lacking information could be added to the API, but in its absence, it would be useful to have the flexibility of the flag.

Hope this help a bit,

Ilan.

> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Vladimir Kondratiev
> Sent: Wednesday, June 19, 2013 18:26
> To: Johannes Berg
> Cc: linux-wireless@vger.kernel.org; Luis R . Rodriguez; John W . Linville; Jouni
> Malinen
> Subject: [RFC] P2P find phase offload
> 
> Hi,
> 
> In discussion about P2P find phase offload, I see one bit that was not cleared,
> and want to discuss it prior to coding: probe replying policy.
> 
> option 1: all or nothing. If device indicates
> NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD, it should answer all matching
> probes, and wpa_s should never answer probes. If device don't indicate offload,
> it never answer probes and wpa_s do answer all matching probes.
> 
> option 2: flexible. If device indicates
> NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD, it may answer some
> matching probes, and wpa_s should answer ones that device missed for some
> reason. To enable this, add 'flags' parameter to cfg80211_rx_mgmt() saying
> whether frame was replied by device/driver.
> 
> Real question here is whether there are devices that can answer probes, but
> not always.
> If such devices are real, option 2 is better. I know that for 60g, I'd like to add
> some more bits to 'flags' from option 2, so I am biased to this option.
> 
> Comments?
> --
> 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

* pull request: bluetooth-next 2013-06-23
From: Gustavo Padovan @ 2013-06-23  2:23 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

Hi John,

Here goes a set of patches to 3.11. The biggest work here is from Andre Guedes
on the move of the Discovery to use the new request framework. Other than that
Johan provided a bunch of fixes to the L2CAP code. The rest are just small
fixes and clean ups. 

Please pull or let me know of any problem! Thanks.

	Gustavo

---
The following changes since commit b887664d882ee4f6a67e0bf05e5f141d32fcc067:

  mwifiex: channel switch handling for station (2013-06-19 15:28:43 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream

for you to fetch changes up to b8f4e068004859eefac7b1ced59ddb67ca6d2d80:

  Bluetooth: Improve comments on the HCI_Delete_Store_Link_Key issue (2013-06-23 03:05:47 +0100)

----------------------------------------------------------------
Andre Guedes (14):
      Bluetooth: Make inquiry_cache_flush non-static
      Bluetooth: Update start_discovery to use HCI request
      Bluetooth: Remove start discovery handling from hci_event.c
      Bluetooth: Make mgmt_start_discovery_failed static
      Bluetooth: Move discovery macros to hci_core.h
      Bluetooth: Use HCI request in interleaved discovery
      Bluetooth: Update stop_discovery to use HCI request
      Bluetooth: Remove stop discovery handling from hci_event.c
      Bluetooth: Make mgmt_stop_discovery_failed static
      Bluetooth: Refactor hci_cc_le_set_scan_enable
      Bluetooth: Remove LE scan helpers
      Bluetooth: Remove inquiry helpers
      Bluetooth: Remove empty event handler
      Bluetooth: Mgmt Device Found Event

Andrei Emeltchenko (2):
      Bluetooth: Use HCI_MGMT instead of HCI_LINK_KEYS flag
      Bluetooth: Remove unneeded flag

Chen Gang (1):
      Bluetooth: hidp: using strlcpy instead of strncpy, also beautify code.

Gustavo Padovan (1):
      Bluetooth: Improve comments on the HCI_Delete_Store_Link_Key issue

Johan Hedberg (12):
      Bluetooth: Handle LE L2CAP signalling in its own function
      Bluetooth: Rename L2CAP_CID_LE_DATA to L2CAP_CID_ATT
      Bluetooth: Fix LE vs BR/EDR selection when connecting
      Bluetooth: Fix EBUSY condition test in l2cap_chan_connect
      Bluetooth: Fix hardcoding ATT CID in __l2cap_chan_add()
      Bluetooth: Add clarifying comment to l2cap_conn_ready()
      Bluetooth: Fix duplicate call to l2cap_chan_ready()
      Bluetooth: Remove useless sk variable in l2cap_le_conn_ready
      Bluetooth: Remove unnecessary L2CAP channel state check
      Bluetooth: Simplify hci_conn_hold/drop logic for L2CAP
      Bluetooth: Remove useless hci_conn disc_timeout setting
      Bluetooth: Fix multiple LE socket handling

Shuah Khan (1):
      Bluetooth: Add missing reset_resume dev_pm_ops

 drivers/bluetooth/btusb.c        |   1 +
 include/net/bluetooth/hci.h      |   1 -
 include/net/bluetooth/hci_core.h |  29 ++----
 include/net/bluetooth/l2cap.h    |   2 +-
 net/bluetooth/hci_core.c         | 192 +++++++++++-----------------------
 net/bluetooth/hci_event.c        |  71 ++-----------
 net/bluetooth/hidp/core.c        |  14 +--
 net/bluetooth/l2cap_core.c       | 121 +++++++++++++++-------
 net/bluetooth/l2cap_sock.c       |   4 +-
 net/bluetooth/mgmt.c             | 229 ++++++++++++++++++++++++++++-------------
 10 files changed, 321 insertions(+), 343 deletions(-)


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* pull request: bluetooth 2013-06-23
From: Gustavo Padovan @ 2013-06-23  2:13 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi John,

A important fix to 3.10, this patch fixes an issues that was preventing the 
l2cap info response command to be handled properly. Please pull. Thanks!

        Gustavo
        
---
The following changes since commit fcb3701849957917a234a61b58ad70ed35c83eda:

  brcmfmac: free primary net_device when brcmf_bus_start() fails (2013-06-13 13:24:12 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master

for you to fetch changes up to 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112:

  Bluetooth: Fix invalid length check in l2cap_information_rsp() (2013-06-23 00:24:58 +0100)

----------------------------------------------------------------
Jaganath Kanakkassery (1):
      Bluetooth: Fix invalid length check in l2cap_information_rsp()

 net/bluetooth/l2cap_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* rtlwifi rtl8192cu: unable to use channels 12 and 13 in Europe
From: Xose Vazquez Perez @ 2013-06-22 23:48 UTC (permalink / raw)
  To: linux-wireless

hi,

kernel 3.9.7-100.fc17.x86_64

- dmesg:

usb 2-1.5: new high-speed USB device number 16 using ehci-pci
usb 2-1.5: New USB device found, idVendor=0bda, idProduct=8176
usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5: Product: 802.11n WLAN Adapter
usb 2-1.5: Manufacturer: Realtek
usb 2-1.5: SerialNumber: 00e04c000001
rtl8192cu: Chip version 0x10
rtl8192cu: MAC address: 00:e0:4c:07:dd:45
rtl8192cu: Board Type 0
rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
ieee80211 phy11: Selected rate control algorithm 'rtl_rc'
rtlwifi: wireless switch is on
cfg80211: Calling CRDA for country: ES
cfg80211: Regulatory domain changed to country: ES
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
cfg80211:   (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
rtl8192cu: MAC auto ON okay!
rtl8192cu: Tx queue select: 0x05
IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready


- iw list:

Wiphy phy2
        Band 1:
                Capabilities: 0x1862
                        HT20/HT40
                        Static SM Power Save
                        RX HT20 SGI
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 7935 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT TX/RX MCS rate indexes supported: 0-7, 32
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps
                        * 5.5 Mbps
                        * 11.0 Mbps
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
        max # scan SSIDs: 4
        max scan IEs length: 2257 bytes
        RTS threshold: 2347
        Coverage class: 0 (up to 0m)
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP (00-0f-ac:4)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
        software interface modes (can always be added):
                 * AP/VLAN
                 * monitor
        interface combinations are not supported
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * new_beacon
                 * new_station
                 * new_mpath
                 * set_mesh_params
                 * set_bss
                 * authenticate
                 * associate
                 * deauthenticate
                 * disassociate
                 * join_ibss
                 * join_mesh
                 * set_tx_bitrate_mask
                 * action
                 * frame_wait_cancel
                 * set_wiphy_netns
                 * set_channel
                 * set_wds_peer
                 * Unknown command (84)
                 * Unknown command (87)
                 * Unknown command (85)
                 * Unknown command (89)
                 * Unknown command (92)
                 * connect
                 * disconnect
        Supported TX frame types:
                 * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
                 * Unknown mode (10): 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0
        Supported RX frame types:
                 * IBSS: 0x0040 0x00b0 0x00c0 0x00d0
                 * managed: 0x0040 0x00d0
                 * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
                 * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
                 * mesh point: 0x00b0 0x00c0 0x00d0
                 * P2P-client: 0x0040 0x00d0
                 * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0
                 * Unknown mode (10): 0x0040 0x00d0
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Device supports TX status socket option.
        Device supports HT-IBSS.


thank you.

^ permalink raw reply

* Re: iwlwifi-7260-6.ucode
From: Emmanuel Grumbach @ 2013-06-22 18:53 UTC (permalink / raw)
  To: Evgeny; +Cc: linux-wireless
In-Reply-To: <51C5A61F.4040503@gmail.com>

> Hi.
> I can't find iwlwifi-7260-6.ucode anywhere. Could you post a link to it?
>

Working on it...

^ permalink raw reply

* [PATCH 0/3] rt2x00: rt2800: prepare for three-chain device support
From: Gabor Juhos @ 2013-06-22 15:42 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos

Gabor Juhos (3):
  rt2x00: rt2800: increase EEPROM_SIZE to 512 bytes
  rt2x00: rt2800lib: turn on secondary PAs/LNAs for 3T/3R devices
  rt2x00: rt2800lib: turn on tertiary PAs/LNAs for 3T/3R devices

 drivers/net/wireless/rt2x00/rt2800.h    |    2 +-
 drivers/net/wireless/rt2x00/rt2800lib.c |   22 ++++++++++++++++++----
 2 files changed, 19 insertions(+), 5 deletions(-)

--
1.7.10


^ permalink raw reply

* [PATCH 2/3] rt2x00: rt2800lib: turn on secondary PAs/LNAs for 3T/3R devices
From: Gabor Juhos @ 2013-06-22 15:42 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1371915734-13966-1-git-send-email-juhosg@openwrt.org>

The secondary PAs/LNAs are turned on only for 2T/2R
devices, however these are used for 3T/3R devices as
well. Always turn those on if the device uses more
than one tx/rx chains.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800lib.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 4072242..f4cd3d8 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2678,16 +2678,16 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
 
 	tx_pin = 0;
 
-	/* Turn on unused PA or LNA when not using 1T or 1R */
-	if (rt2x00dev->default_ant.tx_chain_num == 2) {
+	if (rt2x00dev->default_ant.tx_chain_num > 1) {
+		/* Turn on secondary PAs for 2T adn for 3T devices*/
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_PA_PE_A1_EN,
 				   rf->channel > 14);
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_PA_PE_G1_EN,
 				   rf->channel <= 14);
 	}
 
-	/* Turn on unused PA or LNA when not using 1T or 1R */
-	if (rt2x00dev->default_ant.rx_chain_num == 2) {
+	if (rt2x00dev->default_ant.rx_chain_num > 1) {
+		/* Turn on secondary LNAs for 2R and for 3R devices */
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
 	}
-- 
1.7.10


^ permalink raw reply related

* [PATCH 3/3] rt2x00: rt2800lib: turn on tertiary PAs/LNAs for 3T/3R devices
From: Gabor Juhos @ 2013-06-22 15:42 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1371915734-13966-1-git-send-email-juhosg@openwrt.org>

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800lib.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f4cd3d8..664e9e1 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2684,12 +2684,26 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
 				   rf->channel > 14);
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_PA_PE_G1_EN,
 				   rf->channel <= 14);
+
+		if (rt2x00dev->default_ant.tx_chain_num > 2) {
+			/* Turn on tertiary PAs for 3T devices */
+			rt2x00_set_field32(&tx_pin, TX_PIN_CFG_PA_PE_A2_EN,
+					rf->channel > 14);
+			rt2x00_set_field32(&tx_pin, TX_PIN_CFG_PA_PE_G2_EN,
+					rf->channel <= 14);
+		}
 	}
 
 	if (rt2x00dev->default_ant.rx_chain_num > 1) {
 		/* Turn on secondary LNAs for 2R and for 3R devices */
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
 		rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
+
+		if (rt2x00dev->default_ant.rx_chain_num > 2) {
+			/* Turn on tertiary LNAs for 3R devices */
+			rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A2_EN, 1);
+			rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G2_EN, 1);
+		}
 	}
 
 	rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A0_EN, 1);
-- 
1.7.10


^ permalink raw reply related

* [PATCH 1/3] rt2x00: rt2800: increase EEPROM_SIZE to 512 bytes
From: Gabor Juhos @ 2013-06-22 15:42 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1371915734-13966-1-git-send-email-juhosg@openwrt.org>

Ralink 3T chipsets are using a different EEPROM
layout than the others. The EEPROM on these devices
contain more data than the others which does not fit
into 272 byte which the rt2800 driver actually uses.

The Ralink reference driver defines EEPROM_SIZE to
512/1024 bytes for PCI/USB devices respectively.

Increase the EEPROM_SIZE constant to 512 bytes, in
order to make room for EEPROM data of 3T devices.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index fe43d01..d78c495 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -100,7 +100,7 @@
 #define CSR_REG_BASE			0x1000
 #define CSR_REG_SIZE			0x0800
 #define EEPROM_BASE			0x0000
-#define EEPROM_SIZE			0x0110
+#define EEPROM_SIZE			0x0200
 #define BBP_BASE			0x0000
 #define BBP_SIZE			0x00ff
 #define RF_BASE				0x0004
-- 
1.7.10


^ permalink raw reply related

* Re: [PATCH 1/6] wireless:  Add memory usage debugging.
From: Ben Greear @ 2013-06-22 15:24 UTC (permalink / raw)
  To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87fvwa1qoh.fsf@purkki.adurom.net>

On 06/22/2013 01:43 AM, Kalle Valo wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> The bss objects are reference counted, and the ies
>> are also tricky to keep track of.  Add option to
>> track allocation and freeing of the ies and bss objects,
>> and add debugfs files to show the current objects.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> [...]
>
>> +config CFG80211_MEM_DEBUGGING
>> +	bool "cfg80211 memory debugging logic"
>> +	default n
>> +	depends on CFG80211_DEBUGFS
>> +	---help---
>> +	  Enable this if you want to debug memory handling for bss and ies
>> +	  objects.  New debugfs files: ieee80211/all_ies and all_bss will
>> +	  be created to display these objects.  This has a moderate CPU cost
>> +	  and uses a bit more memory than normal, but otherwise is not very
>> +	  expensive.
>> +
>> +	  If unsure, say N.
>
> IMHO having a new Kconfig option is overkill. Can we use something more
> generic, like CFG80211_DEVELOPER_WARNINGS, for this?

That would be fine with me.  It does cause some extra list walkings and
memory usage, so I wasn't sure it should go in by default.

Unless we are actually leaking things, the lists should remain relatively
short, and probably not walked all *that* often, so maybe it would be OK....

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* [PATCH 2/2] rt2x00: rt2800: unify [RT]XWI_SIZE defines
From: Gabor Juhos @ 2013-06-22 14:31 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1371911519-13135-1-git-send-email-juhosg@openwrt.org>

Use common names instead of chip specific ones.
The patch contains no functional changes, but
it makes it easier to add support for further
descriptor sizes.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800.h    |   10 ++++++----
 drivers/net/wireless/rt2x00/rt2800pci.c |    6 +++---
 drivers/net/wireless/rt2x00/rt2800usb.c |    8 ++++----
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index a7630d5..fe43d01 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -2625,11 +2625,13 @@ struct mac_iveiv_entry {
 /*
  * DMA descriptor defines.
  */
-#define TXWI_DESC_SIZE			(4 * sizeof(__le32))
-#define RXWI_DESC_SIZE			(4 * sizeof(__le32))
 
-#define TXWI_DESC_SIZE_5592		(5 * sizeof(__le32))
-#define RXWI_DESC_SIZE_5592		(6 * sizeof(__le32))
+#define TXWI_DESC_SIZE_4WORDS		(4 * sizeof(__le32))
+#define TXWI_DESC_SIZE_5WORDS		(5 * sizeof(__le32))
+
+#define RXWI_DESC_SIZE_4WORDS		(4 * sizeof(__le32))
+#define RXWI_DESC_SIZE_6WORDS		(6 * sizeof(__le32))
+
 /*
  * TX WI structure
  */
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index e664918..0005562 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -1194,7 +1194,7 @@ static void rt2800pci_queue_init(struct data_queue *queue)
 		queue->limit = 128;
 		queue->data_size = AGGREGATION_SIZE;
 		queue->desc_size = RXD_DESC_SIZE;
-		queue->winfo_size = RXWI_DESC_SIZE;
+		queue->winfo_size = RXWI_DESC_SIZE_4WORDS;
 		queue->priv_size = sizeof(struct queue_entry_priv_mmio);
 		break;
 
@@ -1205,7 +1205,7 @@ static void rt2800pci_queue_init(struct data_queue *queue)
 		queue->limit = 64;
 		queue->data_size = AGGREGATION_SIZE;
 		queue->desc_size = TXD_DESC_SIZE;
-		queue->winfo_size = TXWI_DESC_SIZE;
+		queue->winfo_size = TXWI_DESC_SIZE_4WORDS;
 		queue->priv_size = sizeof(struct queue_entry_priv_mmio);
 		break;
 
@@ -1213,7 +1213,7 @@ static void rt2800pci_queue_init(struct data_queue *queue)
 		queue->limit = 8;
 		queue->data_size = 0; /* No DMA required for beacons */
 		queue->desc_size = TXD_DESC_SIZE;
-		queue->winfo_size = TXWI_DESC_SIZE;
+		queue->winfo_size = TXWI_DESC_SIZE_4WORDS;
 		queue->priv_size = sizeof(struct queue_entry_priv_mmio);
 		break;
 
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 7edd903..840833b 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -855,11 +855,11 @@ static void rt2800usb_queue_init(struct data_queue *queue)
 	unsigned short txwi_size, rxwi_size;
 
 	if (rt2x00_rt(rt2x00dev, RT5592)) {
-		txwi_size = TXWI_DESC_SIZE_5592;
-		rxwi_size = RXWI_DESC_SIZE_5592;
+		txwi_size = TXWI_DESC_SIZE_5WORDS;
+		rxwi_size = RXWI_DESC_SIZE_6WORDS;
 	} else {
-		txwi_size = TXWI_DESC_SIZE;
-		rxwi_size = RXWI_DESC_SIZE;
+		txwi_size = TXWI_DESC_SIZE_4WORDS;
+		rxwi_size = RXWI_DESC_SIZE_4WORDS;
 	}
 
 	switch (queue->qid) {
-- 
1.7.10


^ permalink raw reply related

* [PATCH 1/2] rt2x00: rt2800pci: don't use TXWI_DESC_SIZE directly
From: Gabor Juhos @ 2013-06-22 14:31 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos

Different chipsets may use different TXWI descriptor
size. Instead of using a hardcoded value, use the
'queue->winfo_size' which holds the correct value for
a given device.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800pci.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 7c74782..e664918 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -637,6 +637,7 @@ static void rt2800pci_write_tx_desc(struct queue_entry *entry,
 	struct queue_entry_priv_mmio *entry_priv = entry->priv_data;
 	__le32 *txd = entry_priv->desc;
 	u32 word;
+	const unsigned int txwi_size = entry->queue->winfo_size;
 
 	/*
 	 * The buffers pointed by SD_PTR0/SD_LEN0 and SD_PTR1/SD_LEN1
@@ -659,14 +660,14 @@ static void rt2800pci_write_tx_desc(struct queue_entry *entry,
 			   !test_bit(ENTRY_TXD_MORE_FRAG, &txdesc->flags));
 	rt2x00_set_field32(&word, TXD_W1_BURST,
 			   test_bit(ENTRY_TXD_BURST, &txdesc->flags));
-	rt2x00_set_field32(&word, TXD_W1_SD_LEN0, TXWI_DESC_SIZE);
+	rt2x00_set_field32(&word, TXD_W1_SD_LEN0, txwi_size);
 	rt2x00_set_field32(&word, TXD_W1_LAST_SEC0, 0);
 	rt2x00_set_field32(&word, TXD_W1_DMA_DONE, 0);
 	rt2x00_desc_write(txd, 1, word);
 
 	word = 0;
 	rt2x00_set_field32(&word, TXD_W2_SD_PTR1,
-			   skbdesc->skb_dma + TXWI_DESC_SIZE);
+			   skbdesc->skb_dma + txwi_size);
 	rt2x00_desc_write(txd, 2, word);
 
 	word = 0;
-- 
1.7.10


^ permalink raw reply related

* iwlwifi-7260-6.ucode
From: Evgeny @ 2013-06-22 13:26 UTC (permalink / raw)
  To: linux-wireless

Hi.
I can't find iwlwifi-7260-6.ucode anywhere. Could you post a link to it?

Best regards,
Evgeny.

^ permalink raw reply

* [PATCH] rt2x00: read 5GHz TX power values from the correct offset
From: Gabor Juhos @ 2013-06-22 11:13 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users, Gabor Juhos, stable

The current code uses the same index value both
for the channel information array and for the TX
power table. The index starts from 14, however the
index of the TX power table must start from zero.

Fix it, in order to get the correct TX power value
for a given channel.

The changes in rt61pci.c and rt73usb.c are compile
tested only.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: stable@vger.kernel.org
---
John,

If there is any chance for that, this should go
into 3.10. However the code is wrong since a few
years and nobody noticed that so far, so it is
not a big problem if it will be applied only in
3.11.

-Gabor
---
 drivers/net/wireless/rt2x00/rt2800lib.c |    4 ++--
 drivers/net/wireless/rt2x00/rt61pci.c   |    3 ++-
 drivers/net/wireless/rt2x00/rt73usb.c   |    3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 3aa30dd..4072242 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6254,8 +6254,8 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 		default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2);
 
 		for (i = 14; i < spec->num_channels; i++) {
-			info[i].default_power1 = default_power1[i];
-			info[i].default_power2 = default_power2[i];
+			info[i].default_power1 = default_power1[i - 14];
+			info[i].default_power2 = default_power2[i - 14];
 		}
 	}
 
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 53754bc6..54d3ddf 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2825,7 +2825,8 @@ static int rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 		tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START);
 		for (i = 14; i < spec->num_channels; i++) {
 			info[i].max_power = MAX_TXPOWER;
-			info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
+			info[i].default_power1 =
+					TXPOWER_FROM_DEV(tx_power[i - 14]);
 		}
 	}
 
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 1616ed4..1d3880e 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2167,7 +2167,8 @@ static int rt73usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 		tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START);
 		for (i = 14; i < spec->num_channels; i++) {
 			info[i].max_power = MAX_TXPOWER;
-			info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
+			info[i].default_power1 =
+					TXPOWER_FROM_DEV(tx_power[i - 14]);
 		}
 	}
 
-- 
1.7.10


^ permalink raw reply related

* [PATCH 3.10] ath9k: fix an RCU issue in calling ieee80211_get_tx_rates
From: Felix Fietkau @ 2013-06-22 10:39 UTC (permalink / raw)
  To: linux-wireless; +Cc: linville

ath_txq_schedule is called outside of the drv_tx call, so it needs RCU
protection.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index bfb58a5..c59ae43 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1673,6 +1673,8 @@ void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
 	    txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
 		return;
 
+	rcu_read_lock();
+
 	ac = list_first_entry(&txq->axq_acq, struct ath_atx_ac, list);
 	last_ac = list_entry(txq->axq_acq.prev, struct ath_atx_ac, list);
 
@@ -1711,8 +1713,10 @@ void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
 
 		if (ac == last_ac ||
 		    txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
-			return;
+			break;
 	}
+
+	rcu_read_unlock();
 }
 
 /***********/
-- 
1.8.0.2


^ permalink raw reply related

* Re: [PATCH 1/6] wireless:  Add memory usage debugging.
From: Kalle Valo @ 2013-06-22  8:43 UTC (permalink / raw)
  To: greearb; +Cc: linux-wireless
In-Reply-To: <1371593017-10985-1-git-send-email-greearb@candelatech.com>

greearb@candelatech.com writes:

> From: Ben Greear <greearb@candelatech.com>
>
> The bss objects are reference counted, and the ies
> are also tricky to keep track of.  Add option to
> track allocation and freeing of the ies and bss objects,
> and add debugfs files to show the current objects.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>

[...]

> +config CFG80211_MEM_DEBUGGING
> +	bool "cfg80211 memory debugging logic"
> +	default n
> +	depends on CFG80211_DEBUGFS
> +	---help---
> +	  Enable this if you want to debug memory handling for bss and ies
> +	  objects.  New debugfs files: ieee80211/all_ies and all_bss will
> +	  be created to display these objects.  This has a moderate CPU cost
> +	  and uses a bit more memory than normal, but otherwise is not very
> +	  expensive.
> +
> +	  If unsure, say N.

IMHO having a new Kconfig option is overkill. Can we use something more
generic, like CFG80211_DEVELOPER_WARNINGS, for this?

-- 
Kalle Valo

^ permalink raw reply

* regression after, " ath9k_htc: Add support for mesh interfaces"
From: Oleksij Rempel @ 2013-06-22  4:56 UTC (permalink / raw)
  To: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org,
	Javier Cardona

Hi Javier,

i warning after patch "ath9k_htc: Add support for mesh interfaces".
I get this warning only on pc with CONFIG_MAC80211_MESH not set. 
Probably you missed config check some where.

commit 594e65b633e0b76db1d8e7359e4efb2d60fba20d
Author: Javier Cardona <javier@cozybit.com>
Date:   Wed May 8 10:16:46 2013 -0700

     ath9k_htc: Add support for mesh interfaces

     More specifically, enable AP-style beaconing on mesh
     ifaces and change the hw capabilities to reflect mesh
     support.

     Coexistence with a virtual STA interface was tested as
     working fine.

     Signed-off-by: Javier Cardona <javier@cozybit.com>
     [rebase, add iface combinations]
     Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
     Signed-off-by: John W. Linville <linville@tuxdriver.com>
-- 
Regards,
Oleksij

^ permalink raw reply

* Re: [patch] ipw2x00: printing the wrong array in debug code
From: Stanislav Yakovlev @ 2013-06-22  2:45 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: John W. Linville, linux-wireless, kernel-janitors
In-Reply-To: <20130621122620.GC24059@elgon.mountain>

Hi Dan,

On 21 June 2013 05:26, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Smatch complains that this is a read past the end of the array.  It
> turns out we are printing the wrong array here.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>

Looks fine, thanks.

Stanislav.

^ permalink raw reply

* Re: [PATCH] ipw2200: fix error return code in ipw_load()
From: Stanislav Yakovlev @ 2013-06-22  2:41 UTC (permalink / raw)
  To: Wei Yongjun; +Cc: linville, yongjun_wei, linux-wireless
In-Reply-To: <CAPgLHd8BRGbdCOaoy6E4QBVEbZRnKkHwgrWsodJwYLVs+S=KaQ@mail.gmail.com>

Hi Wei,

On 20 June 2013 19:42, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return -ENOMEM in the ipw_rx_queue_alloc() error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---

Looks fine, thanks.

Stanislav.

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Corey Richardson @ 2013-06-21 23:34 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org
In-Reply-To: <51C2A567.2010409@rempel-privat.de>

On Thu, Jun 20, 2013 at 2:47 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Question to Corey,
>
> i assume your old AP was supporting only BG networks. And your new one,
> which is working fine, supports N?
>

Yes, this is true. It was also using TKIP encryption, if that is relevant.

^ permalink raw reply

* Re: [PATCH] nl80211/drivers: change bss channel to chandef
From: Johannes Berg @ 2013-06-21 20:59 UTC (permalink / raw)
  To: Simon Wunderlich; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1371737435-5694-1-git-send-email-siwu@hrz.tu-chemnitz.de>

On Thu, 2013-06-20 at 16:10 +0200, Simon Wunderlich wrote:

> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1402,7 +1402,7 @@ struct cfg80211_bss_ies {
>   * This structure describes a BSS (which may also be a mesh network)
>   * for use in scan results and similar.
>   *
> - * @channel: channel this BSS is on
> + * @chandef: chandef of the channel this BSS is on

I don't think this makes a lot of sense. The chandefs were defined to be
able to capture things like 80+80 MHz, and there's no way that will be
used here. I think it would make more sense to define a separate "scan
width" or so that can only represent the values 5/10/20.

> +++ b/net/mac80211/ibss.c
> @@ -246,7 +246,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>  	mod_timer(&ifibss->timer,
>  		  round_jiffies(jiffies + IEEE80211_IBSS_MERGE_INTERVAL));
>  
> -	bss = cfg80211_inform_bss_frame(local->hw.wiphy, chan,
> +	bss = cfg80211_inform_bss_frame(local->hw.wiphy, &chandef,

In fact I think this might even create a 40 MHz BSS which would be
strange.

> +++ b/net/wireless/nl80211.c
> @@ -5608,7 +5608,8 @@ static int nl80211_send_bss(struct sk_buff *msg, struct netlink_callback *cb,
>  	    nla_put_u16(msg, NL80211_BSS_BEACON_INTERVAL, res->beacon_interval))
>  		goto nla_put_failure;
>  	if (nla_put_u16(msg, NL80211_BSS_CAPABILITY, res->capability) ||
> -	    nla_put_u32(msg, NL80211_BSS_FREQUENCY, res->channel->center_freq) ||
> +	    nla_put_u32(msg, NL80211_BSS_FREQUENCY,
> +			res->chandef.chan->center_freq) ||
>  	    nla_put_u32(msg, NL80211_BSS_SEEN_MS_AGO,
>  			jiffies_to_msecs(jiffies - intbss->ts)))
>  		goto nla_put_failure;

You should also advertise the width to userspace.

> @@ -5887,10 +5888,9 @@ static int nl80211_authenticate(struct sk_buff *skb, struct genl_info *info)
>  		return -EOPNOTSUPP;
>  
>  	bssid = nla_data(info->attrs[NL80211_ATTR_MAC]);
> -	chan = ieee80211_get_channel(&rdev->wiphy,
> -		nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
> -	if (!chan || (chan->flags & IEEE80211_CHAN_DISABLED))
> -		return -EINVAL;
> +	err = nl80211_parse_chandef(rdev, info, &chandef);
> +	if (!err)
> +		return err;

This also doesn't make sense, you'd allow asking for a 40 MHz channel.
That doesn't mean anything though.

Anyway, this is a bit pointless since __cfg80211_mlme_auth() will look
up the BSS entry for the given parameters and pass _it_, so unless you
need to support two APs using the same BSSID on the same channel but
with different channel widths (which seems really unlikely) then nothing
is needed here.

It might also be worthwhile to rename the inform_bss() functions and
provide static inline wrappers for the current behaviour, since the 5/10
MHz support is really something of a special case and not all drivers
really need that.

johannes


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox