* [PATCH 08/13] rt2x00: rt73usb: implement queue_init callback
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.
Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt73usb.c | 54 ++++++++++++++++++++-------------
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 377e09b..b2e346a 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2359,26 +2359,40 @@ static const struct rt2x00lib_ops rt73usb_rt2x00_ops = {
.config = rt73usb_config,
};
-static const struct data_queue_desc rt73usb_queue_rx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = RXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+static void rt73usb_queue_init(struct data_queue *queue)
+{
+ switch (queue->qid) {
+ case QID_RX:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = RXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
-static const struct data_queue_desc rt73usb_queue_tx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+ case QID_AC_VO:
+ case QID_AC_VI:
+ case QID_AC_BE:
+ case QID_AC_BK:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
-static const struct data_queue_desc rt73usb_queue_bcn = {
- .entry_num = 4,
- .data_size = MGMT_FRAME_SIZE,
- .desc_size = TXINFO_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+ case QID_BEACON:
+ queue->limit = 4;
+ queue->data_size = MGMT_FRAME_SIZE;
+ queue->desc_size = TXINFO_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
+
+ case QID_ATIM:
+ /* fallthrough */
+ default:
+ BUG();
+ break;
+ }
+}
static const struct rt2x00_ops rt73usb_ops = {
.name = KBUILD_MODNAME,
@@ -2387,9 +2401,7 @@ static const struct rt2x00_ops rt73usb_ops = {
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
.extra_tx_headroom = TXD_DESC_SIZE,
- .rx = &rt73usb_queue_rx,
- .tx = &rt73usb_queue_tx,
- .bcn = &rt73usb_queue_bcn,
+ .queue_init = rt73usb_queue_init,
.lib = &rt73usb_rt2x00_ops,
.hw = &rt73usb_mac80211_ops,
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
--
1.7.10
^ permalink raw reply related
* [PATCH 09/13] rt2x00: rt2400pci: implement queue_init callback
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.
Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2400pci.c | 65 ++++++++++++++++++-------------
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index f714373..e1ec9a4 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1767,33 +1767,45 @@ static const struct rt2x00lib_ops rt2400pci_rt2x00_ops = {
.config = rt2400pci_config,
};
-static const struct data_queue_desc rt2400pci_queue_rx = {
- .entry_num = 24,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = RXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+static void rt2400pci_queue_init(struct data_queue *queue)
+{
+ switch (queue->qid) {
+ case QID_RX:
+ queue->limit = 24;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = RXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2400pci_queue_tx = {
- .entry_num = 24,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_AC_VO:
+ case QID_AC_VI:
+ case QID_AC_BE:
+ case QID_AC_BK:
+ queue->limit = 24;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2400pci_queue_bcn = {
- .entry_num = 1,
- .data_size = MGMT_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_BEACON:
+ queue->limit = 1;
+ queue->data_size = MGMT_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2400pci_queue_atim = {
- .entry_num = 8,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_ATIM:
+ queue->limit = 8;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
+
+ default:
+ BUG();
+ break;
+ }
+}
static const struct rt2x00_ops rt2400pci_ops = {
.name = KBUILD_MODNAME,
@@ -1802,10 +1814,7 @@ static const struct rt2x00_ops rt2400pci_ops = {
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
.extra_tx_headroom = 0,
- .rx = &rt2400pci_queue_rx,
- .tx = &rt2400pci_queue_tx,
- .bcn = &rt2400pci_queue_bcn,
- .atim = &rt2400pci_queue_atim,
+ .queue_init = rt2400pci_queue_init,
.lib = &rt2400pci_rt2x00_ops,
.hw = &rt2400pci_mac80211_ops,
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
--
1.7.10
^ permalink raw reply related
* [PATCH 11/13] rt2x00: rt61pci: implement queue_init callback
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.
Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Tested-by: Jakub Kicinski <kubakici@wp.pl>
---
drivers/net/wireless/rt2x00/rt61pci.c | 54 ++++++++++++++++++++-------------
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 7e1759b3..17507d1 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -3025,26 +3025,40 @@ static const struct rt2x00lib_ops rt61pci_rt2x00_ops = {
.config = rt61pci_config,
};
-static const struct data_queue_desc rt61pci_queue_rx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = RXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+static void rt61pci_queue_init(struct data_queue *queue)
+{
+ switch (queue->qid) {
+ case QID_RX:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = RXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt61pci_queue_tx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_AC_VO:
+ case QID_AC_VI:
+ case QID_AC_BE:
+ case QID_AC_BK:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt61pci_queue_bcn = {
- .entry_num = 4,
- .data_size = 0, /* No DMA required for beacons */
- .desc_size = TXINFO_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_BEACON:
+ queue->limit = 4;
+ queue->data_size = 0; /* No DMA required for beacons */
+ queue->desc_size = TXINFO_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
+
+ case QID_ATIM:
+ /* fallthrough */
+ default:
+ BUG();
+ break;
+ }
+}
static const struct rt2x00_ops rt61pci_ops = {
.name = KBUILD_MODNAME,
@@ -3053,9 +3067,7 @@ static const struct rt2x00_ops rt61pci_ops = {
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
.extra_tx_headroom = 0,
- .rx = &rt61pci_queue_rx,
- .tx = &rt61pci_queue_tx,
- .bcn = &rt61pci_queue_bcn,
+ .queue_init = rt61pci_queue_init,
.lib = &rt61pci_rt2x00_ops,
.hw = &rt61pci_mac80211_ops,
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
--
1.7.10
^ permalink raw reply related
* [PATCH 10/13] rt2x00: rt2500pci: implement queue_init callback
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.
Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2500pci.c | 65 ++++++++++++++++++-------------
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 77e45b2..a1670e8 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -2056,33 +2056,45 @@ static const struct rt2x00lib_ops rt2500pci_rt2x00_ops = {
.config = rt2500pci_config,
};
-static const struct data_queue_desc rt2500pci_queue_rx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = RXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+static void rt2500pci_queue_init(struct data_queue *queue)
+{
+ switch (queue->qid) {
+ case QID_RX:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = RXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2500pci_queue_tx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_AC_VO:
+ case QID_AC_VI:
+ case QID_AC_BE:
+ case QID_AC_BK:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2500pci_queue_bcn = {
- .entry_num = 1,
- .data_size = MGMT_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_BEACON:
+ queue->limit = 1;
+ queue->data_size = MGMT_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
-static const struct data_queue_desc rt2500pci_queue_atim = {
- .entry_num = 8,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_mmio),
-};
+ case QID_ATIM:
+ queue->limit = 8;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_mmio);
+ break;
+
+ default:
+ BUG();
+ break;
+ }
+}
static const struct rt2x00_ops rt2500pci_ops = {
.name = KBUILD_MODNAME,
@@ -2091,10 +2103,7 @@ static const struct rt2x00_ops rt2500pci_ops = {
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
.extra_tx_headroom = 0,
- .rx = &rt2500pci_queue_rx,
- .tx = &rt2500pci_queue_tx,
- .bcn = &rt2500pci_queue_bcn,
- .atim = &rt2500pci_queue_atim,
+ .queue_init = rt2500pci_queue_init,
.lib = &rt2500pci_rt2x00_ops,
.hw = &rt2500pci_mac80211_ops,
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
--
1.7.10
^ permalink raw reply related
* [PATCH 12/13] rt2x00: rt2500usb: implement queue_init callback
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.
Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 65 ++++++++++++++++++-------------
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index a7f7b36..e5e5479 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1867,33 +1867,45 @@ static const struct rt2x00lib_ops rt2500usb_rt2x00_ops = {
.config = rt2500usb_config,
};
-static const struct data_queue_desc rt2500usb_queue_rx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = RXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+static void rt2500usb_queue_init(struct data_queue *queue)
+{
+ switch (queue->qid) {
+ case QID_RX:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = RXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
-static const struct data_queue_desc rt2500usb_queue_tx = {
- .entry_num = 32,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+ case QID_AC_VO:
+ case QID_AC_VI:
+ case QID_AC_BE:
+ case QID_AC_BK:
+ queue->limit = 32;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
-static const struct data_queue_desc rt2500usb_queue_bcn = {
- .entry_num = 1,
- .data_size = MGMT_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb_bcn),
-};
+ case QID_BEACON:
+ queue->limit = 1;
+ queue->data_size = MGMT_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb_bcn);
+ break;
-static const struct data_queue_desc rt2500usb_queue_atim = {
- .entry_num = 8,
- .data_size = DATA_FRAME_SIZE,
- .desc_size = TXD_DESC_SIZE,
- .priv_size = sizeof(struct queue_entry_priv_usb),
-};
+ case QID_ATIM:
+ queue->limit = 8;
+ queue->data_size = DATA_FRAME_SIZE;
+ queue->desc_size = TXD_DESC_SIZE;
+ queue->priv_size = sizeof(struct queue_entry_priv_usb);
+ break;
+
+ default:
+ BUG();
+ break;
+ }
+}
static const struct rt2x00_ops rt2500usb_ops = {
.name = KBUILD_MODNAME,
@@ -1902,10 +1914,7 @@ static const struct rt2x00_ops rt2500usb_ops = {
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
.extra_tx_headroom = TXD_DESC_SIZE,
- .rx = &rt2500usb_queue_rx,
- .tx = &rt2500usb_queue_tx,
- .bcn = &rt2500usb_queue_bcn,
- .atim = &rt2500usb_queue_atim,
+ .queue_init = rt2500usb_queue_init,
.lib = &rt2500usb_rt2x00_ops,
.hw = &rt2500usb_mac80211_ops,
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
--
1.7.10
^ permalink raw reply related
* [PATCH 13/13] rt2x00: remove data_queue_desc struct
From: Gabor Juhos @ 2013-06-04 11:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
If the queue_init callback is implemented
by a driver it gets used instead of the
data_queue_desc based initialization.
The queue_init callback is implemented for
each drivers now, so the old initialization
method is not used anymore. Remove the unused
data_queue_desc structure and all of the
related code.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2x00.h | 4 ---
drivers/net/wireless/rt2x00/rt2x00queue.c | 42 +----------------------------
drivers/net/wireless/rt2x00/rt2x00queue.h | 19 -------------
3 files changed, 1 insertion(+), 64 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 2d2db64..2a17f7e 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -649,10 +649,6 @@ struct rt2x00_ops {
const unsigned int rf_size;
const unsigned int tx_queues;
const unsigned int extra_tx_headroom;
- const struct data_queue_desc *rx;
- const struct data_queue_desc *tx;
- const struct data_queue_desc *bcn;
- const struct data_queue_desc *atim;
void (*queue_init)(struct data_queue *queue);
const struct rt2x00lib_ops *lib;
const void *drv;
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 2a99ff1..c4f1e2b 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -1276,33 +1276,6 @@ void rt2x00queue_uninitialize(struct rt2x00_dev *rt2x00dev)
}
}
-static const struct data_queue_desc *
-rt2x00queue_get_qdesc_by_qid(struct rt2x00_dev *rt2x00dev,
- enum data_queue_qid qid)
-{
- switch (qid) {
- case QID_RX:
- return rt2x00dev->ops->rx;
-
- case QID_AC_BE:
- case QID_AC_BK:
- case QID_AC_VO:
- case QID_AC_VI:
- return rt2x00dev->ops->tx;
-
- case QID_BEACON:
- return rt2x00dev->ops->bcn;
-
- case QID_ATIM:
- return rt2x00dev->ops->atim;
-
- default:
- break;
- }
-
- return NULL;
-}
-
static void rt2x00queue_init(struct rt2x00_dev *rt2x00dev,
struct data_queue *queue, enum data_queue_qid qid)
{
@@ -1317,20 +1290,7 @@ static void rt2x00queue_init(struct rt2x00_dev *rt2x00dev,
queue->cw_min = 5;
queue->cw_max = 10;
- if (rt2x00dev->ops->queue_init) {
- rt2x00dev->ops->queue_init(queue);
- } else {
- const struct data_queue_desc *qdesc;
-
- qdesc = rt2x00queue_get_qdesc_by_qid(rt2x00dev, qid);
- BUG_ON(!qdesc);
-
- queue->limit = qdesc->entry_num;
- queue->data_size = qdesc->data_size;
- queue->desc_size = qdesc->desc_size;
- queue->winfo_size = qdesc->winfo_size;
- queue->priv_size = qdesc->priv_size;
- }
+ rt2x00dev->ops->queue_init(queue);
queue->threshold = DIV_ROUND_UP(queue->limit, 10);
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
index 2cf4903..ebe1172 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
@@ -489,25 +489,6 @@ struct data_queue {
};
/**
- * struct data_queue_desc: Data queue description
- *
- * The information in this structure is used by drivers
- * to inform rt2x00lib about the creation of the data queue.
- *
- * @entry_num: Maximum number of entries for a queue.
- * @data_size: Maximum data size for the frames in this queue.
- * @desc_size: Hardware descriptor size for the data in this queue.
- * @priv_size: Size of per-queue_entry private data.
- */
-struct data_queue_desc {
- unsigned short entry_num;
- unsigned short data_size;
- unsigned char desc_size;
- unsigned char winfo_size;
- unsigned short priv_size;
-};
-
-/**
* queue_end - Return pointer to the last queue (HELPER MACRO).
* @__dev: Pointer to &struct rt2x00_dev
*
--
1.7.10
^ permalink raw reply related
* Re: [PATCH 2/6] ath9k: Fix ANI monitoring
From: Sujith Manoharan @ 2013-06-04 11:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless
In-Reply-To: <51ADD058.5000003@openwrt.org>
Felix Fietkau wrote:
> With this patch, the raise-limit is always 3500, you should change it to
> 1000 when removing the above-/below-INI distinction.
Thanks, I'll fix this and send a v2.
Sujith
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: Fix ANI monitoring
From: Sujith Manoharan @ 2013-06-04 11:56 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless, Rajkumar Manoharan
In-Reply-To: <20909.54201.497575.556986@gargle.gargle.HOWL>
Sujith Manoharan wrote:
> > With this patch, the raise-limit is always 3500, you should change it to
> > 1000 when removing the above-/below-INI distinction.
>
> Thanks, I'll fix this and send a v2.
Actually, the changes appear to have been merged internally, for QCA988x.
So, I am not sure if we can keep the ANI tweaks.
Sujith
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: Fix ANI monitoring
From: Sujith Manoharan @ 2013-06-04 12:04 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless, Rajkumar Manoharan
In-Reply-To: <20909.54790.725704.860717@gargle.gargle.HOWL>
Sujith Manoharan wrote:
> Actually, the changes appear to have been merged internally, for QCA988x.
> So, I am not sure if we can keep the ANI tweaks.
Let's see if there is any improvement in this bug with
these patches: https://bugzilla.kernel.org/show_bug.cgi?id=49201
Sujith
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-04 12:07 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Peer, Ilan, linux-wireless@vger.kernel.org, Luis R . Rodriguez,
John W . Linville, Jouni Malinen
In-Reply-To: <2446389.or6hSZ58yP@lx-vladimir>
> > > +struct cfg80211_p2p_find_params {
> >
> > The parameters are missing the listen channel (which is needed to the listen phase).
>
> There are n_channels and channels that define set of social channels
> to operate on. It applies to both listen and search.
I don't think that's true -- you only respond on the listen channel but
send probe requests on all the channels?
> > > + attr = info->attrs[NL80211_ATTR_IE_PROBE_RESP];
> > > + if (attr) {
> > > + params.probe_resp_ie_len = nla_len(attr);
> > > + params.probe_resp_ie = nla_data(attr);
> > > + }
> >
> > Is it valid to get Probe response IEs even if the driver did not report support for it?
>
> One can't do p2p_find if it does not reply to P2P discovery probes.
> It is unrelated to answering probes in AP mode - driver may leave this
> to supplicant.
I think what Ilan is asking is whether you should reject the probe_resp
attribute if NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD isn't set. I'm fine
with just ignoring it (as is done now) though, might make wpa-s easier.
johannes
^ permalink raw reply
* RE: [PATCH v8] cfg80211: P2P find phase offload
From: Peer, Ilan @ 2013-06-04 12:10 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Luis R . Rodriguez,
John W . Linville, Jouni Malinen
In-Reply-To: <2446389.or6hSZ58yP@lx-vladimir>
Hi Vladimir,
BTW, in case that the probe response offload is enabled, do you think that the corresponding probe requests should be reported to the host? If this is not the case, the wpa_supplicant will not have the full list of p2p_peers.
> > > + * @min_discoverable_interval: and
> > > + * @max_discoverable_interval: min/max for random multiplier of
> 100TU's
> > > + * for the listen state duration
> > > + * @n_channels: number of channels to operate on
> > > + * @channels: channels to operate on */ struct
> > > +cfg80211_p2p_find_params {
> >
> > The parameters are missing the listen channel (which is needed to the listen
> phase).
>
> There are n_channels and channels that define set of social channels to operate
> on. It applies to both listen and search.
>
The wpa_supplicant defines a specific listen channel in wpas_p2p_init() and uses this channel in all the following flows. I think that this setting should be communicated to the driver and it should be distinguished from the channels used in search.
> > > + u32 min_discoverable_interval;
> > > + u32 max_discoverable_interval;
> >
> > I do not see a real value for the max/min_discoverable_interval. Is there a
> use case of specifying these limits and not using the default ones?
>
> Spec says these parameters may be changed.
> Practical use, suggested by spec:
>
> - search-only P2P device may set
> min_discoverable_interval = max_discoverable_interval = 0
> - listen-most P2P device may set min_discoverable_interval >> 0 and
> max_discoverable_interval >= min_discoverable_interval
>
Ok.
> > > + *
> > > + * @start_p2p_find: start P2P find phase
> > > + * Parameters include IEs for probe/probe-resp frames;
> > > + * and channels to operate on.
> > > + * Parameters are not retained after call, driver need to copy data if
> > > + * it need it later.
> > > + * P2P find can't run concurrently with ROC or scan, and driver should
> > > + * check this.
> >
> > It might be good to define the exact semantics of p2p_find with regards to
> ROC/Scan, i.e., when p2p_find is requested during ROC/scan, should the driver
> save the request and handle it when the other operation is done, or should it
> return EBUSY or something similar (and also what are the semantics when
> requesting ROC/scan while p2p_find is in progress).
>
> My opinion is ROC/scan collision with p2p_find is indication of error in the
> supplicant; and proper response would be -EBUSY. Actually, code in nl80211
> check for scan (see below), but ROC is harder to detect.
> I'll add explanation to the comment - anyway Johannes wants me to fix for
> genlmsg_end() never returning negative value.
>
That sound reasonable.
> > > +
> > > + if (rdev->scan_req)
> > > + return -EBUSY;
>
> > > +
> > > + if (attr_freq) {
> > > + n_channels = validate_scan_freqs(attr_freq);
> > > + if (!n_channels)
> > > + return -EINVAL;
> > > +
> > > + channels = kzalloc(n_channels * sizeof(*channels),
> > > GFP_KERNEL);
> > > + if (!channels)
> > > + return -ENOMEM;
> > > +
> > > + /* user specified, bail out if channel not found */
> > > + nla_for_each_nested(attr, attr_freq, tmp) {
> > > + struct ieee80211_channel *chan;
> > > +
> > > + chan = ieee80211_get_channel(wiphy,
> > > nla_get_u32(attr));
> > > +
> > > + if (!chan) {
> > > + err = -EINVAL;
> > > + goto out_free;
> > > + }
> > > +
> > > + /* ignore disabled channels */
> > > + if (chan->flags & IEEE80211_CHAN_DISABLED)
> > > + continue;
> > > +
> > > + params.channels[i] = chan;
> > > + i++;
> > > + }
> > > + if (!i) {
> > > + err = -EINVAL;
> > > + goto out_free;
> > > + }
> > > +
> > > + params.n_channels = i;
> > > + params.channels = channels;
> > > + }
> > > +
> >
> > Do we need to set the default channels if the attribute is not set (or require
> that this attribute will be part of the command).
>
> Logic is the following:
> - supplicant may omit channel list at all, this mean "use all social channels",
> kind of default behavior
> - supplicant may specify channel subset, in this case it should be not
empty.
>
> I'll comment it too.
>
> > > +
> > > + attr = info->attrs[NL80211_ATTR_IE_PROBE_RESP];
> > > + if (attr) {
> > > + params.probe_resp_ie_len = nla_len(attr);
> > > + params.probe_resp_ie = nla_data(attr);
> > > + }
> >
> > Is it valid to get Probe response IEs even if the driver did not report support
> for it?
>
> One can't do p2p_find if it does not reply to P2P discovery probes.
> It is unrelated to answering probes in AP mode - driver may leave this to
> supplicant.
But you got NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD for driver that support probe response offloading. In case that the driver does not report this flag, wpa_supplicant should understand this and not configure the driver with the probe response IEs.
Regards,
Ilan.
^ permalink raw reply
* Inquiry About How to Make Reliable Wireless Injection Using MAC80211
From: Jackson Corson @ 2013-06-04 12:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Craig Chabot
Hi everyone,
My name is Jackson Corson and I work for the University of New Hampshire
Interoperability Lab. I am currently working on a project to implement a
wireless testing tool that can test our MAC 802.11n Conformance test
suite. This tool is designed to send and receive any packet. It
currently uses Lorcon2 to inject packets into mac80211. This has worked
quite well except for the fact that radio tap headers are ignored and
fields get set without me changing them. For example, the Duration/ID
field always has a value even when set to 0. This means the tool only
injects packets at basic rates and does not have reliable packet
creation. My question to you guys is how can I get my tool to send
packets quickly, reliably, and with the correct rates? I have tried
several other methods besides lorcon to inject packets, with no
difference. I have also edited to driver to no use the dynamic rate
selection algorithm but that failed to work either. I am using an Ath9k
card, linux 3.5.0.27-generic as my kernel, and Ubuntu 12.04LTS as my OS.
I have tried several other wireless cards as well with the same result.
Thanks,
--
Jackson Corson
UNH-IOL Wireless Consortium
^ permalink raw reply
* [PATCH 3.10] iwlegacy: fix rate control regression
From: Stanislaw Gruszka @ 2013-06-04 12:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Stanislaw Gruszka
Since driver does not use control.rates[0].count, we have never set that
variable. But currently, after rate control API rewrite, this is required
by mac80211. Otherwise legacy rates control does not work and we transmit
always at 1Mbit/s on pre 11n networks.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/3945-rs.c | 1 +
drivers/net/wireless/iwlegacy/4965-rs.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/3945-rs.c b/drivers/net/wireless/iwlegacy/3945-rs.c
index c9f197d..fe31590 100644
--- a/drivers/net/wireless/iwlegacy/3945-rs.c
+++ b/drivers/net/wireless/iwlegacy/3945-rs.c
@@ -816,6 +816,7 @@ out:
rs_sta->last_txrate_idx = idx;
info->control.rates[0].idx = rs_sta->last_txrate_idx;
}
+ info->control.rates[0].count = 1;
D_RATE("leave: %d\n", idx);
}
diff --git a/drivers/net/wireless/iwlegacy/4965-rs.c b/drivers/net/wireless/iwlegacy/4965-rs.c
index 1fc0b22..ed3c42a 100644
--- a/drivers/net/wireless/iwlegacy/4965-rs.c
+++ b/drivers/net/wireless/iwlegacy/4965-rs.c
@@ -2268,7 +2268,7 @@ il4965_rs_get_rate(void *il_r, struct ieee80211_sta *sta, void *il_sta,
info->control.rates[0].flags = 0;
}
info->control.rates[0].idx = rate_idx;
-
+ info->control.rates[0].count = 1;
}
static void *
--
1.7.11.7
^ permalink raw reply related
* [PATCH] regulatory: use proper enum return value
From: Johannes Berg @ 2013-06-04 12:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
get_reg_request_treatment() returns 0 in one case but is
defined to return an enum, use the proper value REG_REQ_OK.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index e1d6749..5a24c98 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1345,7 +1345,7 @@ get_reg_request_treatment(struct wiphy *wiphy,
return REG_REQ_OK;
return REG_REQ_ALREADY_SET;
}
- return 0;
+ return REG_REQ_OK;
case NL80211_REGDOM_SET_BY_DRIVER:
if (lr->initiator == NL80211_REGDOM_SET_BY_CORE) {
if (regdom_changes(pending_request->alpha2))
--
1.8.0
^ permalink raw reply related
* Re: Regression in 9390ace brcmfmac: free net device when registration fails
From: Arend van Spriel @ 2013-06-04 12:58 UTC (permalink / raw)
To: Stephen Warren
Cc: John W. Linville, Hante Meuleman,
'linux-wireless@vger.kernel.org',
linux-next@vger.kernel.org
In-Reply-To: <51AD1F22.2080004@wwwdotorg.org>
On 06/04/2013 12:56 AM, Stephen Warren wrote:
> (John, note that this commit is part of the pull request you sent to
> Dave today)
>
> Arend,
>
> Commit 9390ace "brcmfmac: free net device when registration fails"
> causes a regression.
>
> I had the BCM4330 firmware present in my root fs, whereas my HW is a
> BCM4329. With this patch applied, I get a kernel panic on boot. With it
> reverted, I see that no issues of that nature. This is true in
> next-20130531 (and also 5/30 and 6/1 but not earlier). A bisect of
> Linus's tree followed by a merge of John's wireless pull request from
> today pointed at this same commit.
Thanks, Stephen
I will look into this.
> Related: Since the two hardware require different firmware, I wonder why
> the driver doesn't use a firmware filename that encodes the HW device ID
> instead of using the same name for all HW. This means that when I move
> my SD card between development systems, I have to copy different
> firmware over the top. That's a little painful...
I agree that for development switching cards it is kinda awkward and I
have been fooled by it as well. We may want to change or if your itch is
annoying enough feel free to send a patch for it ;-)
Regards,
Arend
^ permalink raw reply
* re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Dan Carpenter @ 2013-06-04 13:09 UTC (permalink / raw)
To: pizza; +Cc: linux-wireless
Hello Solomon Peachy,
The patch a910e4a94f69: "cw1200: add driver for the ST-E CW1100 &
CW1200 WLAN chipsets" from May 24, 2013, has poor input validation
so the user could write to arbitrary memory.
Also I think this API looks like things which should be done with
normal ioctls. This driver only lets you load the firmware using a
very ugly custom debugfs interface?
drivers/net/wireless/cw1200/debug.c
454
455 if (!count)
456 goto done;
457
458 if (copy_from_user(etf->buf + etf->written, user_buf + written,
459 count)) {
"count" isn't capped so we could overwrite etf->written on the first
write and then write to arbitrary memery on the second write.
460 pr_err("copy_from_user (payload %zu) failed\n", count);
461 return -EFAULT;
462 }
regards,
dan carpenter
^ permalink raw reply
* carl9170:5/10 MHz Channel Support on carl9170
From: C.B. Wang @ 2013-06-04 13:13 UTC (permalink / raw)
To: linux-wireless
I want to know if the ar9170 chip support 5/10 mhz channels.The
datasheet says it supports
802.11j,but the carl9170 driver does not provide support.
Also the radio chip ar9104 has tuning range from 2.3-2.5ghz and
4.9-6.1ghz,but the driver
does not provide any support for these super channels.Isn't the ar9170
chip doesn't support
super channel,or the driver does not implement these features?
c.b.wang
^ permalink raw reply
* carl9170:5/10 MHz Channel Support on carl9170
From: C.B. Wang @ 2013-06-04 13:20 UTC (permalink / raw)
To: linux-wireless
I want to know if the ar9170 chip support 5/10 mhz channels.The
datasheet says it supports
802.11j,but the carl9170 driver does not provide support.
Also the radio chip ar9104 has tuning range from 2.3-2.5ghz and
4.9-6.1ghz,but the driver
does not provide any support for these super channels.Isn't the ar9170
chip doesn't support
super channel,or the driver does not implement these features?
c.b.wang
^ permalink raw reply
* Re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Solomon Peachy @ 2013-06-04 13:43 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless
In-Reply-To: <20130604130955.GA13788@debian>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Tue, Jun 04, 2013 at 06:09:55AM -0700, Dan Carpenter wrote:
> The patch a910e4a94f69: "cw1200: add driver for the ST-E CW1100 &
> CW1200 WLAN chipsets" from May 24, 2013, has poor input validation
> so the user could write to arbitrary memory.
> Also I think this API looks like things which should be done with
> normal ioctls. This driver only lets you load the firmware using a
> very ugly custom debugfs interface?
No, this is a debugging interface designed to interact with the
vendor-supplied testing tool and the passthrough API it requires. The
vendor tool controls the device init sequence, including special
engineering firmware.
Support for the ETF hooks is optional, and even if compiled in has to be
explicitly enabled with a module parameter.
> drivers/net/wireless/cw1200/debug.c
> 454
> 455 if (!count)
> 456 goto done;
> 457
> 458 if (copy_from_user(etf->buf + etf->written, user_buf + written,
> 459 count)) {
>
> "count" isn't capped so we could overwrite etf->written on the first
> write and then write to arbitrary memery on the second write.
Okay, that's easy enough to fix. Thanks for pointing this out.
I'll try to robustify this rather ugly interface as much as possible.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 00/13] rt2x00: get rid of static data queue descriptors
From: Stanislaw Gruszka @ 2013-06-04 13:57 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1370346050-7047-1-git-send-email-juhosg@openwrt.org>
On Tue, Jun 04, 2013 at 01:40:37PM +0200, Gabor Juhos wrote:
> The patch-set depends on the following patch:
>
> 'rt2x00: rt2x00queue: initialize data_queue fields earlier'
> https://patchwork.kernel.org/patch/2655201/
>
> Gabor Juhos (13):
> rt2x00: rt2x00queue: add priv_size field to struct data_queue
> rt2x00: rt2x00queue: remove qdesc parameter of
> rt2x00queue_alloc_entries
> rt2x00: rt2x00dev: use rt2x00dev->bcn->limit
> rt2x00: rt2x00queue: setup queue->threshold from queue->limit
> rt2x00: add queue_init callback to rt2x00_ops
> rt2x00: rt2800usb: implement queue_init callback
> rt2x00: rt2800pci: implement queue_init callback
> rt2x00: rt73usb: implement queue_init callback
> rt2x00: rt2400pci: implement queue_init callback
> rt2x00: rt2500pci: implement queue_init callback
> rt2x00: rt61pci: implement queue_init callback
> rt2x00: rt2500usb: implement queue_init callback
> rt2x00: remove data_queue_desc struct
Looks good. For set:
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Vladimir Kondratiev @ 2013-06-04 14:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Peer, Ilan, linux-wireless@vger.kernel.org, Luis R . Rodriguez,
John W . Linville, Jouni Malinen
In-Reply-To: <1370347656.8287.15.camel@jlt4.sipsolutions.net>
On Tuesday, June 04, 2013 02:07:36 PM Johannes Berg wrote:
>
> > > > +struct cfg80211_p2p_find_params {
> > >
> > > The parameters are missing the listen channel (which is needed to the listen phase).
> >
> > There are n_channels and channels that define set of social channels
> > to operate on. It applies to both listen and search.
>
> I don't think that's true -- you only respond on the listen channel but
> send probe requests on all the channels?
Yes, you are right - it was my mis-interpretation.
I'll add listen channel as mandatory attribute.
Indeed, spec says:
The Listen Channel shall be chosen at the beginning of the
Device Discovery and shall remain the same until P2P Discovery completes.
>
> > > > + attr = info->attrs[NL80211_ATTR_IE_PROBE_RESP];
> > > > + if (attr) {
> > > > + params.probe_resp_ie_len = nla_len(attr);
> > > > + params.probe_resp_ie = nla_data(attr);
> > > > + }
> > >
> > > Is it valid to get Probe response IEs even if the driver did not report support for it?
> >
> > One can't do p2p_find if it does not reply to P2P discovery probes.
> > It is unrelated to answering probes in AP mode - driver may leave this
> > to supplicant.
>
> I think what Ilan is asking is whether you should reject the probe_resp
> attribute if NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD isn't set. I'm fine
> with just ignoring it (as is done now) though, might make wpa-s easier.
On Tuesday, June 04, 2013 12:10:52 PM Peer, Ilan wrote:
> But you got NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD for driver that support probe response offloading. In case that the driver does not report this flag, wpa_supplicant should understand this and not configure the driver with the probe response IEs.
>
> BTW, in case that the probe response offload is enabled, do you think that the corresponding probe requests should be reported to the host? If this is not the case, the wpa_supplicant will not have the full list of p2p_peers.
>
Agree with Johannes, it is easier for wpa_s if we will not be too strict here.
And, probes must be reported to the host in all cases, for wpa_s to have peer list.
Need to add comment describing this.
Thanks, Vladimir
^ permalink raw reply
* Re: [PATCH] brcmsmac: Reduce log spam in heavy tx, make err print in debug
From: John Greene @ 2013-06-04 14:10 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Joe Perches, linville, linux-wireless
In-Reply-To: <51ACCD0E.10407@broadcom.com>
On 06/03/2013 01:06 PM, Arend van Spriel wrote:
> On 06/03/2013 06:54 PM, Joe Perches wrote:
>> On Mon, 2013-06-03 at 09:47 -0400, John Greene wrote:
>>> Move message to debug mode to reduce log spam under heavy tx (iperf)
>>> load.
>> []
>>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
>>> b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
>> []
>>> @@ -900,7 +900,7 @@ brcms_c_ampdu_dotxstatus_complete(struct
>>> ampdu_info *ampdu, struct scb *scb,
>>> if (supr_status) {
>>> update_rate = false;
>>> if (supr_status == TX_STATUS_SUPR_BADCH) {
>>> - brcms_err(wlc->hw->d11core,
>>> + brcms_dbg_ht(wlc->hw->d11core,
>>> "%s: Pkt tx suppressed, illegal channel
>>> possibly %d\n",
>>> __func__, CHSPEC_CHANNEL(
>>> wlc->default_bss->chanspec));
>>
>> net_ratelimited instead?
>
> Yes and only when driver debug level is set.
>
> Regards,
> Arend
>
>
Thanks for the ACK, Arend. And comments..live and learn.
Certainly they would be reasonable also. Issue (confined to an
annoyance level, hence the workaround) is why this comes up when the
channel being flagged is the same as the one the AP I'm connected with
is on. That is the root of the problem, more work needed on that point
which probably would render this moot.
--
John Greene
^ permalink raw reply
* Re: carl9170:5/10 MHz Channel Support on carl9170
From: Simon Wunderlich @ 2013-06-04 14:15 UTC (permalink / raw)
To: C.B. Wang; +Cc: linux-wireless
In-Reply-To: <CAB-Tk70nqYw8a57suVZdLcfJ+cUPSkYMXw3q1kqaO=r8jv7_hA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Tue, Jun 04, 2013 at 09:13:27PM +0800, C.B. Wang wrote:
> I want to know if the ar9170 chip support 5/10 mhz channels.The
> datasheet says it supports
> 802.11j,but the carl9170 driver does not provide support.
I don't know if the carl9170 or the chip really supports that. Mac80211
currently does not support 5/10 MHz, but there is currently a patchset
pending to add this feature. If you want, you can apply that and play
with it.
It would still require to patch the carl9170 driver, the patchset
currently only adds support for ath5k/ath9k. Also the "super" channels
would have to be added.
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-04 14:29 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Peer, Ilan, linux-wireless@vger.kernel.org, Luis R . Rodriguez,
John W . Linville, Jouni Malinen
In-Reply-To: <2224703.CMJXhTQ6XL@lx-vladimir>
On Tue, 2013-06-04 at 17:03 +0300, Vladimir Kondratiev wrote:
> And, probes must be reported to the host in all cases, for wpa_s to have peer list.
> Need to add comment describing this.
I don't think that's necessarily true. wpa_s will pre-build a list, but
note that it doesn't make those peers as discovered and you can't really
do anything with them. As such, I would argue that reporting probe
requests ("probes") would be harmful and counter to one potential goal
of this patch (powersaving.)
johannes
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Malinen, Jouni @ 2013-06-04 14:35 UTC (permalink / raw)
To: Johannes Berg, qca_vkondrat
Cc: Peer, Ilan, linux-wireless@vger.kernel.org, Rodriguez, Luis,
John W . Linville
In-Reply-To: <1370356174.8287.16.camel@jlt4.sipsolutions.net>
On 6/4/13 5:29 PM, "Johannes Berg" <johannes@sipsolutions.net> wrote:
>On Tue, 2013-06-04 at 17:03 +0300, Vladimir Kondratiev wrote:
>
>> And, probes must be reported to the host in all cases, for wpa_s to
>>have peer list.
>> Need to add comment describing this.
>
>I don't think that's necessarily true. wpa_s will pre-build a list, but
>note that it doesn't make those peers as discovered and you can't really
>do anything with them. As such, I would argue that reporting probe
>requests ("probes") would be harmful and counter to one potential goal
>of this patch (powersaving.)
In general, I'd agree. However, I would like to get information of any
peer device being in active PBC mode. This would require either getting
those Probe Request frames or alternatively that being tracked in
kernel/driver/firmware with some access for wpa_supplicant to fetch
information of all STAs (list of MAC Address + UUID) that have indicated
active PBC mode within last 120 seconds.
- Jouni
^ 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