* [PATCH v3 0/2] wl12xx: BA Initiator & receiver support
From: Shahar Levi @ 2011-01-23 6:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho
That series gather two patches:
[PATCH v7] wl12xx: BA initiator support
[PATCH v5] wl12xx: BA receiver support
Add 80211n BA initiator & receiver session support wl1271 driver.
BA initiator session management included in FW independently.
Include supported FW version auto detection mechanism.
Limitation:
- For now only one BA per direction is supported
Shahar Levi (2):
wl12xx: BA initiator support
wl12xx: BA receiver support
drivers/net/wireless/wl12xx/acx.c | 85 ++++++++++++++++++++++++++++++++++
drivers/net/wireless/wl12xx/acx.h | 62 ++++++++++++++++++++++++-
drivers/net/wireless/wl12xx/boot.c | 24 ++++++++-
drivers/net/wireless/wl12xx/conf.h | 6 ++
drivers/net/wireless/wl12xx/init.c | 41 ++++++++++++++++
drivers/net/wireless/wl12xx/main.c | 72 +++++++++++++++++++++++++++--
drivers/net/wireless/wl12xx/wl12xx.h | 16 ++++++-
7 files changed, 296 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH 00/83] staging: ath6kl: Style cleanup
From: Joe Perches @ 2011-01-23 0:24 UTC (permalink / raw)
To: Greg KH
Cc: Vipin Mehta, Vipin Mehta, linux-wireless@vger.kernel.org,
devel@driverdev.osuosl.org
In-Reply-To: <20110121211625.GA15966@kroah.com>
On Fri, 2011-01-21 at 13:16 -0800, Greg KH wrote:
> I need this series against the proper branch, if I am going to be able
> to apply them.
I am working on this major style rewrite of ath6kl right now.
Please do not apply new patches to ath6kl this upcoming week
as it takes quite a bit of work to resync and validate 100+
patches.
thanks, Joe
^ permalink raw reply
* [PATCH 1/3] carl9170: update fw/hw headers
From: Christian Lamparter @ 2011-01-22 21:46 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
This patch syncs up the header files with
the project's main firmware carl9170fw.git.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
drivers/net/wireless/ath/carl9170/fwcmd.h | 1 +
drivers/net/wireless/ath/carl9170/fwdesc.h | 28 +++++++++++++++++++++-----
drivers/net/wireless/ath/carl9170/hw.h | 25 ++++++++++++++++++++++++
drivers/net/wireless/ath/carl9170/version.h | 8 +++---
drivers/net/wireless/ath/carl9170/wlan.h | 20 ++++++++++++++++++-
5 files changed, 71 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/fwcmd.h b/drivers/net/wireless/ath/carl9170/fwcmd.h
index 3680dfc7..30449d2 100644
--- a/drivers/net/wireless/ath/carl9170/fwcmd.h
+++ b/drivers/net/wireless/ath/carl9170/fwcmd.h
@@ -167,6 +167,7 @@ struct carl9170_rx_filter_cmd {
#define CARL9170_RX_FILTER_CTL_BACKR 0x20
#define CARL9170_RX_FILTER_MGMT 0x40
#define CARL9170_RX_FILTER_DATA 0x80
+#define CARL9170_RX_FILTER_EVERYTHING (~0)
struct carl9170_bcn_ctrl_cmd {
__le32 vif_id;
diff --git a/drivers/net/wireless/ath/carl9170/fwdesc.h b/drivers/net/wireless/ath/carl9170/fwdesc.h
index 71f3821..9210668 100644
--- a/drivers/net/wireless/ath/carl9170/fwdesc.h
+++ b/drivers/net/wireless/ath/carl9170/fwdesc.h
@@ -69,6 +69,9 @@ enum carl9170fw_feature_list {
/* Firmware RX filter | CARL9170_CMD_RX_FILTER */
CARL9170FW_RX_FILTER,
+ /* Wake up on WLAN */
+ CARL9170FW_WOL,
+
/* KEEP LAST */
__CARL9170FW_FEATURE_NUM
};
@@ -78,6 +81,7 @@ enum carl9170fw_feature_list {
#define FIX_MAGIC "FIX\0"
#define DBG_MAGIC "DBG\0"
#define CHK_MAGIC "CHK\0"
+#define TXSQ_MAGIC "TXSQ"
#define LAST_MAGIC "LAST"
#define CARL9170FW_SET_DAY(d) (((d) - 1) % 31)
@@ -88,8 +92,10 @@ enum carl9170fw_feature_list {
#define CARL9170FW_GET_MONTH(m) ((((m) / 31) % 12) + 1)
#define CARL9170FW_GET_YEAR(y) ((y) / 372 + 10)
+#define CARL9170FW_MAGIC_SIZE 4
+
struct carl9170fw_desc_head {
- u8 magic[4];
+ u8 magic[CARL9170FW_MAGIC_SIZE];
__le16 length;
u8 min_ver;
u8 cur_ver;
@@ -170,6 +176,16 @@ struct carl9170fw_chk_desc {
#define CARL9170FW_CHK_DESC_SIZE \
(sizeof(struct carl9170fw_chk_desc))
+#define CARL9170FW_TXSQ_DESC_MIN_VER 1
+#define CARL9170FW_TXSQ_DESC_CUR_VER 1
+struct carl9170fw_txsq_desc {
+ struct carl9170fw_desc_head head;
+
+ __le32 seq_table_addr;
+} __packed;
+#define CARL9170FW_TXSQ_DESC_SIZE \
+ (sizeof(struct carl9170fw_txsq_desc))
+
#define CARL9170FW_LAST_DESC_MIN_VER 1
#define CARL9170FW_LAST_DESC_CUR_VER 2
struct carl9170fw_last_desc {
@@ -189,8 +205,8 @@ struct carl9170fw_last_desc {
}
static inline void carl9170fw_fill_desc(struct carl9170fw_desc_head *head,
- u8 magic[4], __le16 length,
- u8 min_ver, u8 cur_ver)
+ u8 magic[CARL9170FW_MAGIC_SIZE],
+ __le16 length, u8 min_ver, u8 cur_ver)
{
head->magic[0] = magic[0];
head->magic[1] = magic[1];
@@ -204,7 +220,7 @@ static inline void carl9170fw_fill_desc(struct carl9170fw_desc_head *head,
#define carl9170fw_for_each_hdr(desc, fw_desc) \
for (desc = fw_desc; \
- memcmp(desc->magic, LAST_MAGIC, 4) && \
+ memcmp(desc->magic, LAST_MAGIC, CARL9170FW_MAGIC_SIZE) && \
le16_to_cpu(desc->length) >= CARL9170FW_DESC_HEAD_SIZE && \
le16_to_cpu(desc->length) < CARL9170FW_DESC_MAX_LENGTH; \
desc = (void *)((unsigned long)desc + le16_to_cpu(desc->length)))
@@ -218,8 +234,8 @@ static inline bool carl9170fw_supports(__le32 list, u8 feature)
}
static inline bool carl9170fw_desc_cmp(const struct carl9170fw_desc_head *head,
- const u8 descid[4], u16 min_len,
- u8 compatible_revision)
+ const u8 descid[CARL9170FW_MAGIC_SIZE],
+ u16 min_len, u8 compatible_revision)
{
if (descid[0] == head->magic[0] && descid[1] == head->magic[1] &&
descid[2] == head->magic[2] && descid[3] == head->magic[3] &&
diff --git a/drivers/net/wireless/ath/carl9170/hw.h b/drivers/net/wireless/ath/carl9170/hw.h
index e85df6e..4e30762 100644
--- a/drivers/net/wireless/ath/carl9170/hw.h
+++ b/drivers/net/wireless/ath/carl9170/hw.h
@@ -463,6 +463,8 @@
#define AR9170_PWR_REG_CHIP_REVISION (AR9170_PWR_REG_BASE + 0x010)
#define AR9170_PWR_REG_PLL_ADDAC (AR9170_PWR_REG_BASE + 0x014)
+#define AR9170_PWR_PLL_ADDAC_DIV_S 2
+#define AR9170_PWR_PLL_ADDAC_DIV 0xffc
#define AR9170_PWR_REG_WATCH_DOG_MAGIC (AR9170_PWR_REG_BASE + 0x020)
/* Faraday USB Controller */
@@ -471,6 +473,9 @@
#define AR9170_USB_REG_MAIN_CTRL (AR9170_USB_REG_BASE + 0x000)
#define AR9170_USB_MAIN_CTRL_REMOTE_WAKEUP BIT(0)
#define AR9170_USB_MAIN_CTRL_ENABLE_GLOBAL_INT BIT(2)
+#define AR9170_USB_MAIN_CTRL_GO_TO_SUSPEND BIT(3)
+#define AR9170_USB_MAIN_CTRL_RESET BIT(4)
+#define AR9170_USB_MAIN_CTRL_CHIP_ENABLE BIT(5)
#define AR9170_USB_MAIN_CTRL_HIGHSPEED BIT(6)
#define AR9170_USB_REG_DEVICE_ADDRESS (AR9170_USB_REG_BASE + 0x001)
@@ -499,6 +504,13 @@
#define AR9170_USB_REG_INTR_GROUP (AR9170_USB_REG_BASE + 0x020)
#define AR9170_USB_REG_INTR_SOURCE_0 (AR9170_USB_REG_BASE + 0x021)
+#define AR9170_USB_INTR_SRC0_SETUP BIT(0)
+#define AR9170_USB_INTR_SRC0_IN BIT(1)
+#define AR9170_USB_INTR_SRC0_OUT BIT(2)
+#define AR9170_USB_INTR_SRC0_FAIL BIT(3) /* ??? */
+#define AR9170_USB_INTR_SRC0_END BIT(4) /* ??? */
+#define AR9170_USB_INTR_SRC0_ABORT BIT(7)
+
#define AR9170_USB_REG_INTR_SOURCE_1 (AR9170_USB_REG_BASE + 0x022)
#define AR9170_USB_REG_INTR_SOURCE_2 (AR9170_USB_REG_BASE + 0x023)
#define AR9170_USB_REG_INTR_SOURCE_3 (AR9170_USB_REG_BASE + 0x024)
@@ -506,6 +518,15 @@
#define AR9170_USB_REG_INTR_SOURCE_5 (AR9170_USB_REG_BASE + 0x026)
#define AR9170_USB_REG_INTR_SOURCE_6 (AR9170_USB_REG_BASE + 0x027)
#define AR9170_USB_REG_INTR_SOURCE_7 (AR9170_USB_REG_BASE + 0x028)
+#define AR9170_USB_INTR_SRC7_USB_RESET BIT(1)
+#define AR9170_USB_INTR_SRC7_USB_SUSPEND BIT(2)
+#define AR9170_USB_INTR_SRC7_USB_RESUME BIT(3)
+#define AR9170_USB_INTR_SRC7_ISO_SEQ_ERR BIT(4)
+#define AR9170_USB_INTR_SRC7_ISO_SEQ_ABORT BIT(5)
+#define AR9170_USB_INTR_SRC7_TX0BYTE BIT(6)
+#define AR9170_USB_INTR_SRC7_RX0BYTE BIT(7)
+
+#define AR9170_USB_REG_IDLE_COUNT (AR9170_USB_REG_BASE + 0x02f)
#define AR9170_USB_REG_EP_MAP (AR9170_USB_REG_BASE + 0x030)
#define AR9170_USB_REG_EP1_MAP (AR9170_USB_REG_BASE + 0x030)
@@ -581,6 +602,10 @@
#define AR9170_USB_REG_MAX_AGG_UPLOAD (AR9170_USB_REG_BASE + 0x110)
#define AR9170_USB_REG_UPLOAD_TIME_CTL (AR9170_USB_REG_BASE + 0x114)
+
+#define AR9170_USB_REG_WAKE_UP (AR9170_USB_REG_BASE + 0x120)
+#define AR9170_USB_WAKE_UP_WAKE BIT(0)
+
#define AR9170_USB_REG_CBUS_CTRL (AR9170_USB_REG_BASE + 0x1f0)
#define AR9170_USB_CBUS_CTRL_BUFFER_END (BIT(1))
diff --git a/drivers/net/wireless/ath/carl9170/version.h b/drivers/net/wireless/ath/carl9170/version.h
index ee0f84f..15095c0 100644
--- a/drivers/net/wireless/ath/carl9170/version.h
+++ b/drivers/net/wireless/ath/carl9170/version.h
@@ -1,7 +1,7 @@
#ifndef __CARL9170_SHARED_VERSION_H
#define __CARL9170_SHARED_VERSION_H
-#define CARL9170FW_VERSION_YEAR 10
-#define CARL9170FW_VERSION_MONTH 10
-#define CARL9170FW_VERSION_DAY 29
-#define CARL9170FW_VERSION_GIT "1.9.0"
+#define CARL9170FW_VERSION_YEAR 11
+#define CARL9170FW_VERSION_MONTH 1
+#define CARL9170FW_VERSION_DAY 22
+#define CARL9170FW_VERSION_GIT "1.9.2"
#endif /* __CARL9170_SHARED_VERSION_H */
diff --git a/drivers/net/wireless/ath/carl9170/wlan.h b/drivers/net/wireless/ath/carl9170/wlan.h
index 24d63b5..9e1324b 100644
--- a/drivers/net/wireless/ath/carl9170/wlan.h
+++ b/drivers/net/wireless/ath/carl9170/wlan.h
@@ -251,7 +251,7 @@ struct carl9170_tx_superdesc {
u8 ampdu_commit_factor:1;
u8 ampdu_unused_bit:1;
u8 queue:2;
- u8 reserved:1;
+ u8 assign_seq:1;
u8 vif_id:3;
u8 fill_in_tsf:1;
u8 cab:1;
@@ -299,6 +299,7 @@ struct _ar9170_tx_hwdesc {
#define CARL9170_TX_SUPER_MISC_QUEUE 0x3
#define CARL9170_TX_SUPER_MISC_QUEUE_S 0
+#define CARL9170_TX_SUPER_MISC_ASSIGN_SEQ 0x4
#define CARL9170_TX_SUPER_MISC_VIF_ID 0x38
#define CARL9170_TX_SUPER_MISC_VIF_ID_S 3
#define CARL9170_TX_SUPER_MISC_FILL_IN_TSF 0x40
@@ -413,6 +414,23 @@ enum ar9170_txq {
__AR9170_NUM_TXQ,
};
+/*
+ * This is an workaround for several undocumented bugs.
+ * Don't mess with the QoS/AC <-> HW Queue map, if you don't
+ * know what you are doing.
+ *
+ * Known problems [hardware]:
+ * * The MAC does not aggregate frames on anything other
+ * than the first HW queue.
+ * * when an AMPDU is placed [in the first hw queue] and
+ * additional frames are already queued on a different
+ * hw queue, the MAC will ALWAYS freeze.
+ *
+ * In a nutshell: The hardware can either do QoS or
+ * Aggregation but not both at the same time. As a
+ * result, this makes the device pretty much useless
+ * for any serious 802.11n setup.
+ */
static const u8 ar9170_qmap[__AR9170_NUM_TXQ] = { 2, 1, 0, 3 };
#define AR9170_TXQ_DEPTH 32
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] carl9170: utilize fw seq counter for mgmt/non-QoS data frames
From: Christian Lamparter @ 2011-01-22 23:18 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <ffb8e21e6d549c2b229e7a4177586b7923805a96.1295740096.git.chunkeey@googlemail.com>
"mac80211 will properly assign sequence numbers to QoS-data
frames but cannot do so correctly for non-QoS-data and
management frames because beacons need them from that counter
as well and mac80211 cannot guarantee proper sequencing."
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
This patch requires a new firmware with
"carl9170 firmware: per-vif tx sequence counter"
---
drivers/net/wireless/ath/carl9170/carl9170.h | 1 +
drivers/net/wireless/ath/carl9170/fw.c | 12 ++++++++++++
drivers/net/wireless/ath/carl9170/main.c | 7 +++++++
drivers/net/wireless/ath/carl9170/tx.c | 3 +++
4 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
index d07ff7f..420d437 100644
--- a/drivers/net/wireless/ath/carl9170/carl9170.h
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
@@ -283,6 +283,7 @@ struct ar9170 {
unsigned int mem_blocks;
unsigned int mem_block_size;
unsigned int rx_size;
+ unsigned int tx_seq_table;
} fw;
/* reset / stuck frames/queue detection */
diff --git a/drivers/net/wireless/ath/carl9170/fw.c b/drivers/net/wireless/ath/carl9170/fw.c
index a4e5b44..9517ede 100644
--- a/drivers/net/wireless/ath/carl9170/fw.c
+++ b/drivers/net/wireless/ath/carl9170/fw.c
@@ -150,6 +150,7 @@ static int carl9170_fw(struct ar9170 *ar, const __u8 *data, size_t len)
const struct carl9170fw_otus_desc *otus_desc;
const struct carl9170fw_chk_desc *chk_desc;
const struct carl9170fw_last_desc *last_desc;
+ const struct carl9170fw_txsq_desc *txsq_desc;
last_desc = carl9170_fw_find_desc(ar, LAST_MAGIC,
sizeof(*last_desc), CARL9170FW_LAST_DESC_CUR_VER);
@@ -299,6 +300,17 @@ static int carl9170_fw(struct ar9170 *ar, const __u8 *data, size_t len)
}
}
+ txsq_desc = carl9170_fw_find_desc(ar, TXSQ_MAGIC,
+ sizeof(*txsq_desc), CARL9170FW_TXSQ_DESC_CUR_VER);
+
+ if (txsq_desc) {
+ ar->fw.tx_seq_table = le32_to_cpu(txsq_desc->seq_table_addr);
+ if (!valid_cpu_addr(ar->fw.tx_seq_table))
+ return -EINVAL;
+ } else {
+ ar->fw.tx_seq_table = 0;
+ }
+
#undef SUPPORTED
return 0;
}
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index ecfb80b..ede3d7e 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -662,6 +662,13 @@ init:
goto unlock;
}
+ if (ar->fw.tx_seq_table) {
+ err = carl9170_write_reg(ar, ar->fw.tx_seq_table + vif_id * 4,
+ 0);
+ if (err)
+ goto unlock;
+ }
+
unlock:
if (err && (vif_id >= 0)) {
vif_priv->active = false;
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index 6cc58e0..6f41e21 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -862,6 +862,9 @@ static int carl9170_tx_prepare(struct ar9170 *ar, struct sk_buff *skb)
if (unlikely(info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM))
txc->s.misc |= CARL9170_TX_SUPER_MISC_CAB;
+ if (unlikely(info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ))
+ txc->s.misc |= CARL9170_TX_SUPER_MISC_ASSIGN_SEQ;
+
if (unlikely(ieee80211_is_probe_resp(hdr->frame_control)))
txc->s.misc |= CARL9170_TX_SUPER_MISC_FILL_IN_TSF;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] carl9170: enable wake-on-lan feature testing
From: Christian Lamparter @ 2011-01-22 23:10 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <2137e711f16faed3f59698cbcb210a1e650dd34c.1295740096.git.chunkeey@googlemail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
drivers/net/wireless/ath/carl9170/fw.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/fw.c b/drivers/net/wireless/ath/carl9170/fw.c
index 546b4e4..a4e5b44 100644
--- a/drivers/net/wireless/ath/carl9170/fw.c
+++ b/drivers/net/wireless/ath/carl9170/fw.c
@@ -264,6 +264,9 @@ static int carl9170_fw(struct ar9170 *ar, const __u8 *data, size_t len)
FIF_PROMISC_IN_BSS;
}
+ if (SUPP(CARL9170FW_WOL))
+ device_set_wakeup_enable(&ar->udev->dev, true);
+
ar->fw.vif_num = otus_desc->vif_num;
ar->fw.cmd_bufs = otus_desc->cmd_bufs;
ar->fw.address = le32_to_cpu(otus_desc->fw_address);
--
1.7.2.3
^ permalink raw reply related
* Re: ath9k prevents CPU from entering C4 state (kernel 2.6.37 regression)
From: Thomas Bächler @ 2011-01-22 23:49 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Richard Schütz, linux-wireless
In-Reply-To: <201101222352.42913.chunkeey@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
Am 22.01.2011 23:52, schrieb Christian Lamparter:
> On Saturday 22 January 2011 21:38:47 Richard Schütz wrote:
>> I noticed that from kernel 2.6.37 on (i've tested 2.6.38-rc2, too) ath9k
>> prevents my CPU (Intel Atom N450) from entering the C4 power state. It
>> only goes down to C2 (there's no C3) instead. In 2.6.36(.3) everything
>> is still fine. The CPU will only go down to C4 with 2.6.37 when the
>> wireless interface is brought down.
>
> "ath9k: Fix a DMA latency issue for Intel Pinetrail platforms."
> http://www.spinics.net/lists/linux-wireless/msg58264.html
I experience the same problem, and I do not have a Pinetrail. I run
Intel Core i5-520M (Arrandale) with an AR9280 Rev 2.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: ath9k prevents CPU from entering C4 state (kernel 2.6.37 regression)
From: Christian Lamparter @ 2011-01-22 22:52 UTC (permalink / raw)
To: Richard Schütz; +Cc: linux-wireless
In-Reply-To: <4D3B4057.5000206@t-online.de>
On Saturday 22 January 2011 21:38:47 Richard Schütz wrote:
> I noticed that from kernel 2.6.37 on (i've tested 2.6.38-rc2, too) ath9k
> prevents my CPU (Intel Atom N450) from entering the C4 power state. It
> only goes down to C2 (there's no C3) instead. In 2.6.36(.3) everything
> is still fine. The CPU will only go down to C4 with 2.6.37 when the
> wireless interface is brought down.
"ath9k: Fix a DMA latency issue for Intel Pinetrail platforms."
http://www.spinics.net/lists/linux-wireless/msg58264.html
the pm_qos value will be configurable with 2.6.38:
"ath9k: Make PM-QOS value as user configurable"
http://www.spinics.net/lists/linux-wireless/msg61259.html
"This will help our customers to configure the pm-qos value according
to the effect in throughput due to the DMA latency problem which was
observed in Intel Pinetrail platforms."
^ permalink raw reply
* ath9k prevents CPU from entering C4 state (kernel 2.6.37 regression)
From: Richard Schütz @ 2011-01-22 20:38 UTC (permalink / raw)
To: linux-wireless
I noticed that from kernel 2.6.37 on (i've tested 2.6.38-rc2, too) ath9k
prevents my CPU (Intel Atom N450) from entering the C4 power state. It
only goes down to C2 (there's no C3) instead. In 2.6.36(.3) everything
is still fine. The CPU will only go down to C4 with 2.6.37 when the
wireless interface is brought down.
used wireless device:
05:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless
Network Adapter (PCI-Express) (rev 01)
--
Regards,
Richard Schütz
^ permalink raw reply
* Compat-wireless release for 2011-01-22 is baked
From: Compat-wireless cronjob account @ 2011-01-22 20:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
782984 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1982 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1955 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110121
compat-wireless release: compat-wireless-2011-01-06-3-g8db1608-pc
^ permalink raw reply
* Re: [RFC/WIP 00/33] ath9k_htc AP mode
From: Sujith @ 2011-01-22 16:58 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath9k-devel, Jouni Malinen
In-Reply-To: <201101221348.57720.chunkeey@googlemail.com>
Christian Lamparter wrote:
> You only have to have a sane tx status if the IEEE80211_TX_CTL_REQ_TX_STATUS
> flag is set. In all other cases, the IEEE80211_TX_STAT_ACK handling is
> *optional*. In fact if you don't set the TX_STAT_ACK flag, mac80211 will
> automatically do the right thing when it sees that a STA has become
> "temporarily" unavailable.
Looking at mac80211, IEEE80211_TX_CTL_REQ_TX_STATUS is set only for mgmt and
a couple of action frames now, but of course this could be fixed for other
use cases too.
> Sure, IEEE80211_HW_REPORTS_TX_ACK_STATUS would be the way to go.
> Especially because IEEE80211_HW_PS_NULLFUNC_STACK also benefits
> from it.
Yeah, agreed.
Well, let's see how things turn out. :)
Sujith
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Arend van Spriel @ 2011-01-22 16:19 UTC (permalink / raw)
To: Jamie Kitson; +Cc: linux-wireless@vger.kernel.org, Brett Rudley
In-Reply-To: <AANLkTikam0zcxe00UCT4BDQMmrJcPKf1Hbt6=PBokpga@mail.gmail.com>
Hi Jamie,
On 01/08/2011 01:37 AM, Jamie Kitson wrote:
> Hello,
>
> I've received the following kernel panic twice in two days since I
> started using the brcm80211 driver:
>
> http://farm6.static.flickr.com/5202/5334637544_a0dacd5edd_b.jpg
>
> I have a Dell M101z with:
>
> 03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n
> Wireless LAN Controller (rev 01)
>
> I am running:
>
> Linux jamie-laptop 2.6.36-ARCH #1 SMP PREEMPT Fri Dec 10 20:32:37 CET
> 2010 x86_64 AMD Athlon(tm) II Neo K325 Dual-Core Processor
> AuthenticAMD GNU/Linux
>
Rereading the whole thread I noticed the PREEMPT in your uname message.
Does this mean you are running with CONFIG_PREEMPT (Preemptible Kernel)?
This may not be supported by this driver.
> Cheers, Jamie
> --
> 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
>
--
Gr. AvS
^ permalink raw reply
* Re: The future of ACX100/ACX111/TNETW1450 support in the kernel?
From: Sedat Dilek @ 2011-01-22 15:44 UTC (permalink / raw)
To: Kassandra Drowner; +Cc: linux-wireless
In-Reply-To: <4D3AEE9C.4060306@googlemail.com>
On Sat, Jan 22, 2011 at 3:50 PM, Kassandra Drowner
<kassandra.drow@googlemail.com> wrote:
> I'm using a AVM Fritz Wlan Stick of the first generation. This USB device
> has the TNETW1450 by Texas Instruments.
> According to the ubuntu-wikipage this is one device that needs to be handled
> with ndiswrapper & the windows driver , because no kernel driver is
> available.
>
> I searched around and came across http://acx100.sourceforge.net/ . This
> driver isnt merged obviously because of legal problems with the developing
> process.
>
> In the LWN Article "Who wrote 2.6.37" ( http://lwn.net/Articles/420658/ )
> i've seen the chipset manufacturer Texas instruments being ranked quite high
> up.
>
> Are there plans to get official support for the chipsets
> ACX100/ACX111/TNETW1450 in the mainline tree one day, now that the
> manufacturer has started to work on linux-support? Will the legal issues be
> dealt with, so the sf-project can be included and the driver being worked on
> by more people than just 2 or 3 ?
>
>
> Kassandra Drowner
>
JFYI: OpenWRT is maintaining acx-mac80211 (could not test on my
Speedport-W701/AR7-router-plattform yet, using freetz).
- Sedat -
[1] https://dev.openwrt.org/browser/trunk/package/acx-mac80211
[2] http://acx100.git.sourceforge.net/git/gitweb.cgi?p=acx100/acx-mac80211;a=summary
^ permalink raw reply
* The future of ACX100/ACX111/TNETW1450 support in the kernel?
From: Kassandra Drowner @ 2011-01-22 14:50 UTC (permalink / raw)
To: linux-wireless
I'm using a AVM Fritz Wlan Stick of the first generation. This USB
device has the TNETW1450 by Texas Instruments.
According to the ubuntu-wikipage this is one device that needs to be
handled with ndiswrapper & the windows driver , because no kernel driver
is available.
I searched around and came across http://acx100.sourceforge.net/ . This
driver isnt merged obviously because of legal problems with the
developing process.
In the LWN Article "Who wrote 2.6.37" ( http://lwn.net/Articles/420658/
) i've seen the chipset manufacturer Texas instruments being ranked
quite high up.
Are there plans to get official support for the chipsets
ACX100/ACX111/TNETW1450 in the mainline tree one day, now that the
manufacturer has started to work on linux-support? Will the legal issues
be dealt with, so the sf-project can be included and the driver being
worked on by more people than just 2 or 3 ?
Kassandra Drowner
^ permalink raw reply
* Re: [RFC/WIP 00/33] ath9k_htc AP mode
From: Christian Lamparter @ 2011-01-22 12:48 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless, ath9k-devel, Jouni Malinen
In-Reply-To: <19770.20402.711305.279934@gargle.gargle.HOWL>
On Saturday 22 January 2011 04:32:02 Sujith wrote:
> Sujith wrote:
> > Sujith wrote:
> > > What about hardware that doesn't report any kind of TX status information at all ?
> > > Currently, there is no way to determine whether the frame has actually gone out,
> > > all that can be known is that it was pushed to the target.
> >
> > Am curious how carl9170 gets the TX status ?
> > Is there a separate endpoint ?
>
> I looked a bit into carl9170 and it looks like the TX status
> is obtained as incoming data through the CMD endpoint, am I correct ?
yes and no ;).
The tx status is obtained from the (RX-) DATA [stream/] endpoint.
The (USB?) CMD endpoint is only being used for fatal 0xc6
watchdog events [which are generated by the bootloader].
> And the cookie is used to match the status information with the approporiate
> packet ?
The driver also gets the used ac queue index from the tx feedback message.
So it knows in which tx_status queue it has to look, but that's only
a minor detail.
> Though for ath9k_htc this would mean changes in both the host and FW,
> the host has to queue up packets in some kind of queue and process them
> on reception of status interrupts. The FW has to be changed to actually
> deliver the TX status information. :)
You only have to have a sane tx status if the IEEE80211_TX_CTL_REQ_TX_STATUS
flag is set. In all other cases, the IEEE80211_TX_STAT_ACK handling is
*optional*. In fact if you don't set the TX_STAT_ACK flag, mac80211 will
automatically do the right thing when it sees that a STA has become
"temporarily" unavailable.
> It does make it a bit neat to have such a mechanism. And for AP mode,
> I would think that it's kinda essential unless someone comes with an
> ingenious way of solving the PS race for drivers that don't set
> IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)
Sure, IEEE80211_HW_REPORTS_TX_ACK_STATUS would be the way to go.
Especially because IEEE80211_HW_PS_NULLFUNC_STACK also benefits
from it.
Best regards,
Chr
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Arend van Spriel @ 2011-01-22 12:33 UTC (permalink / raw)
To: Jamie Kitson; +Cc: Brett Rudley, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimmLbtQUDWZGChH9LzwNwv6ZXihTz4a+mZefm60@mail.gmail.com>
Hi, Jamie
On 01/22/2011 12:12 PM, Jamie Kitson wrote:
> Someone here is suggesting that adding maxcpus=1 to the boot options
> has fixed their crashes. Could this be my issue?
>
What kernel are you using? Could you also provide the panic trace?
> https://bbs.archlinux.org/viewtopic.php?pid=877645
> --
> 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
>
Gr. AvS
^ permalink raw reply
* Re: [PATCH v3] ath5k: Simplify loop when setting up channels
From: me @ 2011-01-22 12:16 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, linux-wireless, ath5k-devel
In-Reply-To: <20110121031952.7059.68911.stgit@localhost6.localdomain6>
On Fri, Jan 21, 2011 at 12:19:52PM +0900, Bruno Randolf wrote:
> Simplify confusing code and get rid of an unnecessary variable.
>
> Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Thanks!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-22 11:13 UTC (permalink / raw)
To: Brett Rudley; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimmLbtQUDWZGChH9LzwNwv6ZXihTz4a+mZefm60@mail.gmail.com>
Further:
https://wiki.archlinux.org/index.php/Wireless_Setup#brcm80211
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-22 11:12 UTC (permalink / raw)
To: Brett Rudley; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTingheCkPNvc+8qM5oQh8NHPAX2h4Z6C1YZEFRBc@mail.gmail.com>
Someone here is suggesting that adding maxcpus=1 to the boot options
has fixed their crashes. Could this be my issue?
https://bbs.archlinux.org/viewtopic.php?pid=877645
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 04/14] iwlagn: 2000 series devices support
From: Gábor Stefanik @ 2011-01-22 3:55 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Wey-Yi Guy, linville, linux-wireless, ipw3945-devel
In-Reply-To: <AANLkTimG1e3UQo9LW42FNh2OewPJ8xAhGvao6-jc2FGF@mail.gmail.com>
2011/1/22 Daniel Halperin <dhalperi@cs.washington.edu>:
> 2011/1/21 Gábor Stefanik <netrolller.3d@gmail.com>:
>> 2011/1/22 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>> about the market, how many 3-stream APs can you buy today?
>>>
>>> Well, there is the Airport Extreme, the D-Link DIR-665 (with a
>>> Marvell-chipped mini-PCI card inside), and also an offering from
>>> Senao
>
> Wow, seriously, thanks for the list! I had no idea Apple added 3
> streams to the Airport Extreme (the first gen and the first dual-band
> one didn't have it); the only place i could find it was in the WFA
> certificate. I also didn't know that D-Link made a plausibly useful
> dual-band AP. That's awesome.
>
> Still, that's 3 out of 325 of the 802.11n APs on the WFA certified
> list. Okay, let's say there's 10 more that neither of us mentioned,
> that's still maximum 3%, or say 5%. And they all cost around $200.
> For one randomly-selected (well, selected from their "Value-priced"
> category) example, D-link's DIR-515 costs $38.
>
> A possibly silly, possibly illuminating question here: is there
> anything *WRONG* with the 6300? Is there a reason you're looking for
> a new iteration? What might be funny is that Wi-Fi, unlike CPU,
> doesn't really get that much better over the years (as long as you
> stick to the standard). And the newest, most exciting stuff -- e.g.,
> Wi-Di -- works with the 6300.
I'm not really referring to the 6300 - I'm talking about what the 6350
would have been, true 3-stream 802.11n + WiMax. The 5350 had only
partial WiMax implementation, and even that is gone now that the 5350
has been discontinued. Also, if they could pull off 3-stream+WiMax,
and they are doing 2-stream+Bluetooth 3.0 now, I'm pretty sure
3-stream+BT3.0 would be doable.
>
> Why might you want a new version? Lower cost? -- the chips already
> cost like $30, that's pretty cheap, say Intel could bring it down to
> $25 would that increase volume enough to make it worth while? I doubt
> it. To save power? -- well, 6300 is a pretty feature-rich chip, it
> probably goes in devices like fancy laptops where it isn't a
> relatively large power drain, and pretty efficient use will come from
> Wi-Fi sleep modes. Power efficiency matters more when Wi-Fi is a
> relatively large contributor to power draw. Oh wait, that's in the
> small devices that only want 1x1 or 1x2, so maybe it IS worth Intel's
> time/money to keep revving those chips every time they can use a
> smaller process.
Well, power efficiency does make sense for higher-end devices too -
expect that instead of lowering consumption, it should go into higher
TX power at the same consumption level. AFAIK both the 5xxx and 6xxx
series are capped @ 15dBm, while regulatory allows at least 20dBm, and
even more than that in some places.
Also, by creating lots of different non-3-stream devices, Intel is
indirectly discouraging OEMs from using 3-stream technology (because
there is only one 3-stream offering, the 6300, while in the 1- and
2-stream category, there are lots of different designs with different
bells and whistles each). While they did innovate in the high-end
range with the 5300 and the 6300, they went *backwards* in the
mainstream - remember how the 4965 was 3x3:2x2 (antennas/streams),
while its mainstream successor, the 5100, was 1x2:1x2 - 50% upstream
performance loss, plus losing all the benefits of extra antenna
diversity. Even the 6200 is only 2x2:2x2, still weaker than the 4965.
>
> I don't know anything about Intel's internal plans, and this is all my
> own speculation, but ... I'd love to hear what it is you'd like the
> new chip to have that the current ones don't. Certainly, no one's
> asking for them to rev the 3945, and I think for good reason. ;).
>
> Dan
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [RFC/WIP 00/33] ath9k_htc AP mode
From: Sujith @ 2011-01-22 3:32 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath9k-devel, Jouni Malinen
In-Reply-To: <19770.18332.859418.283909@gargle.gargle.HOWL>
Sujith wrote:
> Sujith wrote:
> > What about hardware that doesn't report any kind of TX status information at all ?
> > Currently, there is no way to determine whether the frame has actually gone out,
> > all that can be known is that it was pushed to the target.
>
> Am curious how carl9170 gets the TX status ?
> Is there a separate endpoint ?
I looked a bit into carl9170 and it looks like the TX status
is obtained as incoming data through the CMD endpoint, am I correct ?
And the cookie is used to match the status information with the approporiate
packet ?
Though for ath9k_htc this would mean changes in both the host and FW, the host has to queue
up packets in some kind of queue and process them on reception of status interrupts.
The FW has to be changed to actually deliver the TX status information. :)
It does make it a bit neat to have such a mechanism. And for AP mode, I would think
that it's kinda essential unless someone comes with an ingenious way of solving
the PS race for drivers that don't set IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)
Sujith
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 04/14] iwlagn: 2000 series devices support
From: Daniel Halperin @ 2011-01-22 3:07 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Wey-Yi Guy, linville, linux-wireless, ipw3945-devel
In-Reply-To: <AANLkTimqmEYWpV89+cUebvV0Ai-2vobmVY5tiO5R8cOa@mail.gmail.com>
2011/1/21 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2011/1/22 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> about the market, how many 3-stream APs can you buy today?
>>
>> Well, there is the Airport Extreme, the D-Link DIR-665 (with a
>> Marvell-chipped mini-PCI card inside), and also an offering from
>> Senao
Wow, seriously, thanks for the list! I had no idea Apple added 3
streams to the Airport Extreme (the first gen and the first dual-band
one didn't have it); the only place i could find it was in the WFA
certificate. I also didn't know that D-Link made a plausibly useful
dual-band AP. That's awesome.
Still, that's 3 out of 325 of the 802.11n APs on the WFA certified
list. Okay, let's say there's 10 more that neither of us mentioned,
that's still maximum 3%, or say 5%. And they all cost around $200.
For one randomly-selected (well, selected from their "Value-priced"
category) example, D-link's DIR-515 costs $38.
A possibly silly, possibly illuminating question here: is there
anything *WRONG* with the 6300? Is there a reason you're looking for
a new iteration? What might be funny is that Wi-Fi, unlike CPU,
doesn't really get that much better over the years (as long as you
stick to the standard). And the newest, most exciting stuff -- e.g.,
Wi-Di -- works with the 6300.
Why might you want a new version? Lower cost? -- the chips already
cost like $30, that's pretty cheap, say Intel could bring it down to
$25 would that increase volume enough to make it worth while? I doubt
it. To save power? -- well, 6300 is a pretty feature-rich chip, it
probably goes in devices like fancy laptops where it isn't a
relatively large power drain, and pretty efficient use will come from
Wi-Fi sleep modes. Power efficiency matters more when Wi-Fi is a
relatively large contributor to power draw. Oh wait, that's in the
small devices that only want 1x1 or 1x2, so maybe it IS worth Intel's
time/money to keep revving those chips every time they can use a
smaller process.
I don't know anything about Intel's internal plans, and this is all my
own speculation, but ... I'd love to hear what it is you'd like the
new chip to have that the current ones don't. Certainly, no one's
asking for them to rev the 3945, and I think for good reason. ;).
Dan
^ permalink raw reply
* Re: [RFC/WIP 00/33] ath9k_htc AP mode
From: Sujith @ 2011-01-22 2:56 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath9k-devel, Jouni Malinen
In-Reply-To: <201101212226.40435.chunkeey@googlemail.com>
Christian Lamparter wrote:
> But what seems to be strange is the tx feedback...
> Because it looks like ath9k_htc just sets IEEE80211_TX_STAT_ACK
> for every frame, which obviously can't be "true", right? ;)
>
> This might also break mac80211's *unicast buffering*.
>
> Because the code in ieee80211_tx_status - net/mac80211/status.c
> works like this:
>
> 211 acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
> 212 if (!acked && test_sta_flags(sta, WLAN_STA_PS_STA)) {
> 213 /*
> 214 * The STA is in power save mode, so assume
> 215 * that this TX packet failed because of that.
> 216 */
> 217 ieee80211_handle_filtered_frame(local, sta, skb);
> 218 rcu_read_unlock();
> 219 return;
> 220 }
> ...
> 239 if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> 240 ieee80211_handle_filtered_frame(local, sta, skb);
> 241 rcu_read_unlock();
> 242 return;
> 243 } else {
> 244 if (!acked)
> 245 sta->tx_retry_failed++;
> 246 sta->tx_retry_count += retry_count;
> 247 }
>
> so, mac80211 will never know when it needs to resend certain
> frame which could be affected by the race between the "sleepy"
> station sending a frame with a PSM-bit set and mac80211 finally
> updating the WLAN_STA_PS_STA flag.
> [see long comment in mac80211/status.c @ line 73]
What about hardware that doesn't report any kind of TX status information at all ?
Currently, there is no way to determine whether the frame has actually gone out,
all that can be known is that it was pushed to the target.
> unless of course, you don't need it and the firmware can
> buffer those frames until the STA comes back?!
Hm, unfortunately the firmware has no such feature currently.
Sujith
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 04/14] iwlagn: 2000 series devices support
From: Gábor Stefanik @ 2011-01-22 2:37 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Wey-Yi Guy, linville, linux-wireless, ipw3945-devel
In-Reply-To: <AANLkTimf-GodWmUqbJkCiP_BPChAT60oQ0ZVTRq_0p73@mail.gmail.com>
2011/1/22 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2011/1/22 Daniel Halperin <dhalperi@cs.washington.edu>:
>> 2011/1/21 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Sat, Jan 22, 2011 at 1:06 AM, Wey-Yi Guy <wey-yi.w.guy@intel.com> wrote:
>>>> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>>>>
>>>> Adding 2000 series devices supports, the 2000 series devices has
>>>> many different SKUs which includes 1x1 and 2x2 devices,also with
>>>
>>> Is it just me, or is Intel really abandoning 3-stream 802.11n technology?
>>
>> It's just you. They released the 6300 not that long ago! But think
>> about the market, how many 3-stream APs can you buy today?
>
> Well, there is the Airport Extreme, the D-Link DIR-665 (with a
> Marvell-chipped mini-PCI card inside), and also an offering from
my bad... mini-PCIE.
> Senao.
>
>> Atheros
>> still doesn't even have a 3-stream NIC end users can buy (though some
>> companies are getting close!), but Intel's had one for nearly 3 years.
>>
>> There's a lot more room in the market at the low end, and that's where
>> it makes sense to put your efforts towards product diversity.
>> Manufacturers are looking for chips for printers, phones, netbooks,
>> tiny laptops, etc., why would they pay for the silicon for extra
>> processing and the design constraints(!) for extra antennas when it's
>> not going to get used? Heck, a lot of these APs (see, e.g., Apple's
>> airport express) only come with 100 Mbps wired ports!
>>
>> Dan
>>
>
> The problem is that what I currently see is that Intel is updating the
> basic 2x2 half-mini offering (true, they are also releasing Bluetooth
> combos and other new devices, but AFAIK one of the "g2" devices is
> exactly the same feature-wise as the Centrino 6200), while the 6300
> has not received any update ("released not that long ago"? AFAIK it's
> been a year at least since it came out), and the 6350 was cancelled
> before release, leaving 5350 without a successor.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 04/14] iwlagn: 2000 series devices support
From: Gábor Stefanik @ 2011-01-22 2:37 UTC (permalink / raw)
To: Daniel Halperin; +Cc: Wey-Yi Guy, linville, linux-wireless, ipw3945-devel
In-Reply-To: <AANLkTik11iCqMF+pRYX7jvzj03t_cTCZh1ivb1Tt3L01@mail.gmail.com>
2011/1/22 Daniel Halperin <dhalperi@cs.washington.edu>:
> 2011/1/21 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Sat, Jan 22, 2011 at 1:06 AM, Wey-Yi Guy <wey-yi.w.guy@intel.com> wrote:
>>> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>>>
>>> Adding 2000 series devices supports, the 2000 series devices has
>>> many different SKUs which includes 1x1 and 2x2 devices,also with
>>
>> Is it just me, or is Intel really abandoning 3-stream 802.11n technology?
>
> It's just you. They released the 6300 not that long ago! But think
> about the market, how many 3-stream APs can you buy today?
Well, there is the Airport Extreme, the D-Link DIR-665 (with a
Marvell-chipped mini-PCI card inside), and also an offering from
Senao.
> Atheros
> still doesn't even have a 3-stream NIC end users can buy (though some
> companies are getting close!), but Intel's had one for nearly 3 years.
>
> There's a lot more room in the market at the low end, and that's where
> it makes sense to put your efforts towards product diversity.
> Manufacturers are looking for chips for printers, phones, netbooks,
> tiny laptops, etc., why would they pay for the silicon for extra
> processing and the design constraints(!) for extra antennas when it's
> not going to get used? Heck, a lot of these APs (see, e.g., Apple's
> airport express) only come with 100 Mbps wired ports!
>
> Dan
>
The problem is that what I currently see is that Intel is updating the
basic 2x2 half-mini offering (true, they are also releasing Bluetooth
combos and other new devices, but AFAIK one of the "g2" devices is
exactly the same feature-wise as the Centrino 6200), while the 6300
has not received any update ("released not that long ago"? AFAIK it's
been a year at least since it came out), and the 6350 was cancelled
before release, leaving 5350 without a successor.
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 04/14] iwlagn: 2000 series devices support
From: Daniel Halperin @ 2011-01-22 2:12 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Wey-Yi Guy, linville, linux-wireless, ipw3945-devel
In-Reply-To: <AANLkTinqZ-7E943Qd8swN0hS5XFaSeayBm75Lkz768Bv@mail.gmail.com>
2011/1/21 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Sat, Jan 22, 2011 at 1:06 AM, Wey-Yi Guy <wey-yi.w.guy@intel.com> wrote:
>> From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>>
>> Adding 2000 series devices supports, the 2000 series devices has
>> many different SKUs which includes 1x1 and 2x2 devices,also with
>
> Is it just me, or is Intel really abandoning 3-stream 802.11n technology?
It's just you. They released the 6300 not that long ago! But think
about the market, how many 3-stream APs can you buy today? Atheros
still doesn't even have a 3-stream NIC end users can buy (though some
companies are getting close!), but Intel's had one for nearly 3 years.
There's a lot more room in the market at the low end, and that's where
it makes sense to put your efforts towards product diversity.
Manufacturers are looking for chips for printers, phones, netbooks,
tiny laptops, etc., why would they pay for the silicon for extra
processing and the design constraints(!) for extra antennas when it's
not going to get used? Heck, a lot of these APs (see, e.g., Apple's
airport express) only come with 100 Mbps wired ports!
Dan
^ 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