* Re: linux-next: Tree for Aug 7
From: Eric Dumazet @ 2013-08-07 16:17 UTC (permalink / raw)
To: Johannes Berg
Cc: Phil Sutter, Sedat Dilek, Stephen Rothwell, linux-next,
linux-kernel, netdev, David Miller, Hannes Frederic Sowa,
wireless, John Linville
In-Reply-To: <1375891974.8154.1.camel@jlt4.sipsolutions.net>
On Wed, 2013-08-07 at 18:12 +0200, Johannes Berg wrote:
> On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
>
> > The idea behind this patch is that users setting the protocol to
> > something else probably do know better and so should be left alone.
>
> Regardless of that, I think that still the skb pointers would be changed
> by this patch which would confuse the receiver of the SKB (device
> driver), no? Has anyone verified that theory? :)
Maybe receivers made wrong assumptions about some headers being set or
not set ?
A patch can uncover prior bugs.
commit 76fe45812a3b134c3917 is an example of a fix we had to do because
of another fix ;)
^ permalink raw reply
* Re: linux-next: Tree for Aug 7
From: Johannes Berg @ 2013-08-07 16:12 UTC (permalink / raw)
To: Phil Sutter
Cc: Sedat Dilek, Stephen Rothwell, linux-next, linux-kernel, netdev,
David Miller, Hannes Frederic Sowa, wireless, John Linville
In-Reply-To: <20130807155918.GA16263@orbit.nwl.cc>
On Wed, 2013-08-07 at 17:59 +0200, Phil Sutter wrote:
> The idea behind this patch is that users setting the protocol to
> something else probably do know better and so should be left alone.
Regardless of that, I think that still the skb pointers would be changed
by this patch which would confuse the receiver of the SKB (device
driver), no? Has anyone verified that theory? :)
johannes
^ permalink raw reply
* Re: linux-next: Tree for Aug 7
From: Phil Sutter @ 2013-08-07 15:59 UTC (permalink / raw)
To: Sedat Dilek
Cc: Stephen Rothwell, linux-next, linux-kernel, netdev, David Miller,
Hannes Frederic Sowa, wireless, John Linville, Johannes Berg
In-Reply-To: <CA+icZUW+uxCsvPYcY2RRvMxRVzaBLuH9u8M4ziQNWXv=nk4b2w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Wed, Aug 07, 2013 at 10:29:18AM +0200, Sedat Dilek wrote:
> On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > Changes since 20130806:
> >
> > The ext4 tree lost its build failure.
> >
> > The mvebu tree gained a build failure so I used the version from
> > next-20130806.
> >
> > The akpm tree gained conflicts against the ext4 tree.
> >
> > ----------------------------------------------------------------------------
> >
>
> [ CC some netdev and wireless folks ]
>
> Yesterday, I discovered an issue with net-next.
> The patch in [1] fixed the problems in my network/wifi environment.
> Hannes confirmed that virtio_net are solved, too.
> Today's next-20130807 still needs it for affected people.
>
> - Sedat -
>
> [1] http://marc.info/?l=linux-netdev&m=137582524017840&w=2
> [2] http://marc.info/?l=linux-netdev&m=137583048219416&w=2
> [3] http://marc.info/?t=137579712800008&r=1&w=2
Could you please try the attached patch. It limits parsing the ethernet
header (by calling eth_type_trans()) to cases when the configured
protocol is ETH_P_ALL, so at least for 802.1X this should fix the
problem.
The idea behind this patch is that users setting the protocol to
something else probably do know better and so should be left alone.
Best wishes, Phil
[-- Attachment #2: af_packet_fixup.diff --]
[-- Type: text/plain, Size: 1606 bytes --]
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index bbe1ece..66bc79c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1932,8 +1932,6 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
ph.raw = frame;
- skb->protocol = proto;
- skb->dev = dev;
skb->priority = po->sk.sk_priority;
skb->mark = po->sk.sk_mark;
sock_tx_timestamp(&po->sk, &skb_shinfo(skb)->tx_flags);
@@ -2002,13 +2000,18 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
if (unlikely(err))
return err;
- if (dev->type == ARPHRD_ETHER)
- skb->protocol = eth_type_trans(skb, dev);
-
data += dev->hard_header_len;
to_write -= dev->hard_header_len;
}
+ if (dev->type == ARPHRD_ETHER &&
+ proto = htons(ETH_P_ALL)) {
+ skb->protocol = eth_type_trans(skb, dev);
+ } else {
+ skb->protocol = proto;
+ skb->dev = dev;
+ }
+
max_frame_len = dev->mtu + dev->hard_header_len;
if (skb->protocol == htons(ETH_P_8021Q))
max_frame_len += VLAN_HLEN;
@@ -2331,15 +2334,17 @@ static int packet_snd(struct socket *sock,
sock_tx_timestamp(sk, &skb_shinfo(skb)->tx_flags);
- if (dev->type == ARPHRD_ETHER) {
+ if (dev->type == ARPHRD_ETHER &&
+ proto == htons(ETH_P_ALL)) {
skb->protocol = eth_type_trans(skb, dev);
- if (skb->protocol == htons(ETH_P_8021Q))
- reserve += VLAN_HLEN;
} else {
skb->protocol = proto;
skb->dev = dev;
}
+ if (skb->protocol == htons(ETH_P_8021Q))
+ reserve += VLAN_HLEN;
+
if (!gso_type && (len > dev->mtu + reserve + extra_len)) {
err = -EMSGSIZE;
goto out_free;
^ permalink raw reply related
* [PATCH 2/2] ath10k: update supported FW build version
From: Bartosz Markowski @ 2013-08-07 13:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1375881466-30090-1-git-send-email-bartosz.markowski@tieto.com>
The latest supported and available FW build is 1.0.0.636.
Reflect this in ath10k code.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 373c2ef..9868705 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -24,7 +24,7 @@
#define SUPPORTED_FW_MAJOR 1
#define SUPPORTED_FW_MINOR 0
#define SUPPORTED_FW_RELEASE 0
-#define SUPPORTED_FW_BUILD 629
+#define SUPPORTED_FW_BUILD 636
/* QCA988X 2.0 definitions */
#define QCA988X_HW_2_0_VERSION 0x4100016c
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] ath10k: Remove qca98xx hw1.0 support
From: Bartosz Markowski @ 2013-08-07 13:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
Since the firmware support is no longer available for hw1.0,
drop all code (especially workarounds) for those units.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 31 +------------------------------
drivers/net/wireless/ath/ath10k/core.c | 11 -----------
drivers/net/wireless/ath/ath10k/hw.h | 8 --------
drivers/net/wireless/ath/ath10k/pci.c | 15 ---------------
drivers/net/wireless/ath/ath10k/pci.h | 23 ++---------------------
5 files changed, 3 insertions(+), 85 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index f8b969f..9c9f081 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -76,36 +76,7 @@ static inline void ath10k_ce_src_ring_write_index_set(struct ath10k *ar,
u32 ce_ctrl_addr,
unsigned int n)
{
- struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
- void __iomem *indicator_addr;
-
- if (!test_bit(ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND, ar_pci->features)) {
- ath10k_pci_write32(ar, ce_ctrl_addr + SR_WR_INDEX_ADDRESS, n);
- return;
- }
-
- /* workaround for QCA988x_1.0 HW CE */
- indicator_addr = ar_pci->mem + ce_ctrl_addr + DST_WATERMARK_ADDRESS;
-
- if (ce_ctrl_addr == ath10k_ce_base_address(CDC_WAR_DATA_CE)) {
- iowrite32((CDC_WAR_MAGIC_STR | n), indicator_addr);
- } else {
- unsigned long irq_flags;
- local_irq_save(irq_flags);
- iowrite32(1, indicator_addr);
-
- /*
- * PCIE write waits for ACK in IPQ8K, there is no
- * need to read back value.
- */
- (void)ioread32(indicator_addr);
- (void)ioread32(indicator_addr); /* conservative */
-
- ath10k_pci_write32(ar, ce_ctrl_addr + SR_WR_INDEX_ADDRESS, n);
-
- iowrite32(0, indicator_addr);
- local_irq_restore(irq_flags);
- }
+ ath10k_pci_write32(ar, ce_ctrl_addr + SR_WR_INDEX_ADDRESS, n);
}
static inline u32 ath10k_ce_src_ring_write_index_get(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7226c23..04c132e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -39,17 +39,6 @@ MODULE_PARM_DESC(p2p, "Enable ath10k P2P support");
static const struct ath10k_hw_params ath10k_hw_params_list[] = {
{
- .id = QCA988X_HW_1_0_VERSION,
- .name = "qca988x hw1.0",
- .patch_load_addr = QCA988X_HW_1_0_PATCH_LOAD_ADDR,
- .fw = {
- .dir = QCA988X_HW_1_0_FW_DIR,
- .fw = QCA988X_HW_1_0_FW_FILE,
- .otp = QCA988X_HW_1_0_OTP_FILE,
- .board = QCA988X_HW_1_0_BOARD_DATA_FILE,
- },
- },
- {
.id = QCA988X_HW_2_0_VERSION,
.name = "qca988x hw2.0",
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 44ed5af..373c2ef 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -26,14 +26,6 @@
#define SUPPORTED_FW_RELEASE 0
#define SUPPORTED_FW_BUILD 629
-/* QCA988X 1.0 definitions */
-#define QCA988X_HW_1_0_VERSION 0x4000002c
-#define QCA988X_HW_1_0_FW_DIR "ath10k/QCA988X/hw1.0"
-#define QCA988X_HW_1_0_FW_FILE "firmware.bin"
-#define QCA988X_HW_1_0_OTP_FILE "otp.bin"
-#define QCA988X_HW_1_0_BOARD_DATA_FILE "board.bin"
-#define QCA988X_HW_1_0_PATCH_LOAD_ADDR 0x1234
-
/* QCA988X 2.0 definitions */
#define QCA988X_HW_2_0_VERSION 0x4100016c
#define QCA988X_HW_2_0_FW_DIR "ath10k/QCA988X/hw2.0"
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e2f9ef5..4c94add 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -36,11 +36,9 @@ static unsigned int ath10k_target_ps;
module_param(ath10k_target_ps, uint, 0644);
MODULE_PARM_DESC(ath10k_target_ps, "Enable ath10k Target (SoC) PS option");
-#define QCA988X_1_0_DEVICE_ID (0xabcd)
#define QCA988X_2_0_DEVICE_ID (0x003c)
static DEFINE_PCI_DEVICE_TABLE(ath10k_pci_id_table) = {
- { PCI_VDEVICE(ATHEROS, QCA988X_1_0_DEVICE_ID) }, /* PCI-E QCA988X V1 */
{ PCI_VDEVICE(ATHEROS, QCA988X_2_0_DEVICE_ID) }, /* PCI-E QCA988X V2 */
{0}
};
@@ -2269,9 +2267,6 @@ static void ath10k_pci_dump_features(struct ath10k_pci *ar_pci)
case ATH10K_PCI_FEATURE_MSI_X:
ath10k_dbg(ATH10K_DBG_PCI, "device supports MSI-X\n");
break;
- case ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND:
- ath10k_dbg(ATH10K_DBG_PCI, "QCA988X_1.0 workaround enabled\n");
- break;
case ATH10K_PCI_FEATURE_SOC_POWER_SAVE:
ath10k_dbg(ATH10K_DBG_PCI, "QCA98XX SoC power save enabled\n");
break;
@@ -2298,9 +2293,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci->dev = &pdev->dev;
switch (pci_dev->device) {
- case QCA988X_1_0_DEVICE_ID:
- set_bit(ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND, ar_pci->features);
- break;
case QCA988X_2_0_DEVICE_ID:
set_bit(ATH10K_PCI_FEATURE_MSI_X, ar_pci->features);
break;
@@ -2322,10 +2314,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_ar_pci;
}
- /* Enable QCA988X_1.0 HW workarounds */
- if (test_bit(ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND, ar_pci->features))
- spin_lock_init(&ar_pci->hw_v1_workaround_lock);
-
ar_pci->ar = ar;
ar_pci->fw_indicator_address = FW_INDICATOR_ADDRESS;
atomic_set(&ar_pci->keep_awake_count, 0);
@@ -2483,9 +2471,6 @@ module_exit(ath10k_pci_exit);
MODULE_AUTHOR("Qualcomm Atheros");
MODULE_DESCRIPTION("Driver support for Atheros QCA988X PCIe devices");
MODULE_LICENSE("Dual BSD/GPL");
-MODULE_FIRMWARE(QCA988X_HW_1_0_FW_DIR "/" QCA988X_HW_1_0_FW_FILE);
-MODULE_FIRMWARE(QCA988X_HW_1_0_FW_DIR "/" QCA988X_HW_1_0_OTP_FILE);
-MODULE_FIRMWARE(QCA988X_HW_1_0_FW_DIR "/" QCA988X_HW_1_0_BOARD_DATA_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" QCA988X_HW_2_0_FW_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" QCA988X_HW_2_0_OTP_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" QCA988X_HW_2_0_BOARD_DATA_FILE);
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index 871bb33..b2439f5 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -152,8 +152,7 @@ struct service_to_pipe {
enum ath10k_pci_features {
ATH10K_PCI_FEATURE_MSI_X = 0,
- ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND = 1,
- ATH10K_PCI_FEATURE_SOC_POWER_SAVE = 2,
+ ATH10K_PCI_FEATURE_SOC_POWER_SAVE = 1,
/* keep last */
ATH10K_PCI_FEATURE_COUNT
@@ -234,9 +233,6 @@ struct ath10k_pci {
/* Map CE id to ce_state */
struct ce_state *ce_id_to_state[CE_COUNT_MAX];
-
- /* makes sure that dummy reads are atomic */
- spinlock_t hw_v1_workaround_lock;
};
static inline struct ath10k_pci *ath10k_pci_priv(struct ath10k *ar)
@@ -310,23 +306,8 @@ static inline void ath10k_pci_write32(struct ath10k *ar, u32 offset,
u32 value)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
- void __iomem *addr = ar_pci->mem;
-
- if (test_bit(ATH10K_PCI_FEATURE_HW_1_0_WORKAROUND, ar_pci->features)) {
- unsigned long irq_flags;
-
- spin_lock_irqsave(&ar_pci->hw_v1_workaround_lock, irq_flags);
-
- ioread32(addr+offset+4); /* 3rd read prior to write */
- ioread32(addr+offset+4); /* 2nd read prior to write */
- ioread32(addr+offset+4); /* 1st read prior to write */
- iowrite32(value, addr+offset);
- spin_unlock_irqrestore(&ar_pci->hw_v1_workaround_lock,
- irq_flags);
- } else {
- iowrite32(value, addr+offset);
- }
+ iowrite32(value, ar_pci->mem + offset);
}
static inline u32 ath10k_pci_read32(struct ath10k *ar, u32 offset)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3.11] genetlink: fix family dump race
From: Johannes Berg @ 2013-08-07 12:39 UTC (permalink / raw)
To: linux-wireless, netdev, Thomas Graf
Cc: Andrei Otcheretianski, Ilan Peer, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.
BUG: unable to handle kernel paging request at f8467360
IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
EIP is at ctrl_dumpfamily+0x6b/0xe0
EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
Call Trace:
[<c14c20bc>] netlink_dump+0x5c/0x200
[<c14c3450>] __netlink_dump_start+0x140/0x160
[<c14c5172>] genl_rcv_msg+0x102/0x270
[<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
[<c14c505c>] genl_rcv+0x1c/0x30
[<c14c456b>] netlink_unicast+0x17b/0x1c0
[<c14c47d4>] netlink_sendmsg+0x224/0x370
[<c1485adf>] sock_sendmsg+0xff/0x120
[<c1486b0a>] __sys_sendmsg+0x24a/0x260
[<c1487fdb>] sys_sendmsg+0x3b/0x60
[<c1488683>] sys_socketcall+0x283/0x2e0
[<c15b7c1f>] sysenter_do_call+0x12/0x38
Code: 8d 3c c5 c0 7c 07 c2 8b 04 c5 c0 7c 07 c2 39 c7 8d 58 c8 75 16 eb 71 90 81 7d ec 00 1f 86 c1 74 10 8b 43 38 39 c7 8d 58 c8 74 5d <80> 7b 20 00 74 e7 83 c6 01 3b 75 f0 7c e8 8b 55 e8 8b 42 04 8b
Cc: stable@vger.kernel.org
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/netlink/genetlink.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 2fd6dbe..6b6a03a 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -789,6 +789,10 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
struct net *net = sock_net(skb->sk);
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
+ bool need_locking = chains_to_skip || fams_to_skip;
+
+ if (need_locking)
+ genl_lock();
for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -810,6 +814,9 @@ errout:
cb->args[0] = i;
cb->args[1] = n;
+ if (need_locking)
+ genl_unlock();
+
return skb->len;
}
--
1.8.0
^ permalink raw reply related
* [PATCH 3.11] genetlink: fix family dump race
From: Johannes Berg @ 2013-08-07 12:34 UTC (permalink / raw)
To: linux-wireless, netdev, Thomas Graf
Cc: Andrei Otcheretianski, Ilan Peer, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.
BUG: unable to handle kernel paging request at f8467360
IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
EIP is at ctrl_dumpfamily+0x6b/0xe0
EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
Call Trace:
[<c14c20bc>] netlink_dump+0x5c/0x200
[<c14c3450>] __netlink_dump_start+0x140/0x160
[<c14c5172>] genl_rcv_msg+0x102/0x270
[<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
[<c14c505c>] genl_rcv+0x1c/0x30
[<c14c456b>] netlink_unicast+0x17b/0x1c0
[<c14c47d4>] netlink_sendmsg+0x224/0x370
[<c1485adf>] sock_sendmsg+0xff/0x120
[<c1486b0a>] __sys_sendmsg+0x24a/0x260
[<c1487fdb>] sys_sendmsg+0x3b/0x60
[<c1488683>] sys_socketcall+0x283/0x2e0
[<c15b7c1f>] sysenter_do_call+0x12/0x38
Code: 8d 3c c5 c0 7c 07 c2 8b 04 c5 c0 7c 07 c2 39 c7 8d 58 c8 75 16 eb 71 90 81 7d ec 00 1f 86 c1 74 10 8b 43 38 39 c7 8d 58 c8 74 5d <80> 7b 20 00 74 e7 83 c6 01 3b 75 f0 7c e8 8b 55 e8 8b 42 04 8b
Cc: stable@vger.kernel.org
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/netlink/genetlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 2fd6dbe..07a0b18 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -790,6 +790,9 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
+ if (chains_to_skip)
+ genl_lock();
+
for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
n = 0;
list_for_each_entry(rt, genl_family_chain(i), family_list) {
@@ -810,6 +813,9 @@ errout:
cb->args[0] = i;
cb->args[1] = n;
+ if (chains_to_skip)
+ genl_unlock();
+
return skb->len;
}
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] brcmfmac: use CFG80211_TESTMODE_CMD
From: Arend van Spriel @ 2013-08-07 10:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1375780399-1120-1-git-send-email-johannes@sipsolutions.net>
On 08/06/2013 11:13 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This is essentially the same, but written shorter.
I would have expected the macro to be called NL80211.. but no real
preference. So you can add
Acked-by: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index b7d8850..f393828 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -4163,9 +4163,7 @@ static struct cfg80211_ops wl_cfg80211_ops = {
> .stop_p2p_device = brcmf_p2p_stop_device,
> .crit_proto_start = brcmf_cfg80211_crit_proto_start,
> .crit_proto_stop = brcmf_cfg80211_crit_proto_stop,
> -#ifdef CONFIG_NL80211_TESTMODE
> - .testmode_cmd = brcmf_cfg80211_testmode
> -#endif
> + CFG80211_TESTMODE_CMD(brcmf_cfg80211_testmode)
> };
>
> static s32 brcmf_nl80211_iftype_to_mode(enum nl80211_iftype type)
>
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Arend van Spriel @ 2013-08-07 10:39 UTC (permalink / raw)
To: Kalle Valo
Cc: Luis R. Rodriguez, linux-wireless, Ben Greear, Paul Stewart,
Felix Fietkau, Jouni Malinen
In-Reply-To: <87li4gwosw.fsf@purkki.adurom.net>
On 08/05/2013 09:59 AM, Kalle Valo wrote:
> "Arend van Spriel" <arend@broadcom.com> writes:
>
>> I am considering coming up with a new test framework for the brcm80211
>> drivers using python scripting, which is why I started py80211
>> experiment (available on github), but your mentioning of autotest
>> makes me want to revisit that.
>
> No no, please forget anything your heard about autotest and just focus
> on py80211 ;)
>
> More seriously, my experience with the autotest and any other test
> frameworks are that they are so freaking huge and difficult to maintain
> that eventually they just die. Small is beautiful and I have been
> dreaming about a lean and mean python based nl80211 test harness for
> drivers, but never found the time to do anything (my usual story). So
> I'm eagerly waiting how your py80211 will workout.
I am on vacation now so I may end up working on it. Although, I do have
an almost 5yr old son claiming most of my time :-)
Anyway, there have been a few patches applied to libnl itself to support
genl in python. So I can send and receive netlink messages and
notifications as a python dictionary of netlink attributes. Now need to
determine the level of abstraction I want to provide to users of
py80211. Suggestions are more than welcome.
Regards,
Arend
^ permalink raw reply
* Re: Skb and ieee80211 headers
From: Arend van Spriel @ 2013-08-07 10:27 UTC (permalink / raw)
To: Mathieu Devos; +Cc: linux-wireless, David S. Miller, Eric Dumazet
In-Reply-To: <CAE_+SoyLKkzkjHLdf6rO1m2+KJaF7ZuG6GQBWpFWRScrgWmWWQ@mail.gmail.com>
+ networking experts
On 08/02/2013 09:49 AM, Mathieu Devos wrote:
> Hi,
>
> An update is in order here I believe (and an apology because I
> resorted to asking my questions on IRC and not sticking to the mailing
> list, for that: sorry).
> Let's start things off quickly with my main goal with this: the code
> that I'm trying to write is supposed to be an adapter for a new type
> of internet (RINA), this is in function of my master thesis (I'm new
> to Linux Kernel itself). So what exactly does this mean? I'd like to
> be able to hook packets (skb) in the kernel with an LKM and just use
> one layer (datalink layer) with the hardware layer being handled by
> the drivers and the hardware itself. Everything on top of that should
> be RINA specific code.
So basically you want to be able to use RINA stack as a drop-in
replacement for the TCP/IP stack keeping the netdev api unchanged so
device drivers do not have to change.
> The specifics about the master thesis is that this all should be done
> on android, thus using the wireless stack.
I can not follow your line of thinking here. The android requirement (a
stupid one if you ask me) does not restrict you to the wireless stack.
There are android platforms with ethernet connectivity.
> I believed that in an
> skbuff you had the formed 802.3 header through drivers but you still
> also had the original 802.11 header, this however, is now proven
> wrong, the 802.11 header is thrown out after the drivers are done with
> it thus it's impossible for me to map RINA to the 802.11 header. After
> resuming testing with this news I'm still left with a couple of
> questions however:
An sk_buff is just a structure that makes it convenient to add or remove
layer specific header (or tail) data moving from one layer to the other.
An ethernet device with get an 802.3 packet, which is straightforward. A
wireless device also gets an 802.3 packet so from the networking stacks'
perspective there is no difference between a ethernet or a wireless device.
Looking at architecture shown in [1], I think RINA does not need to care
about 802.11 either as the device drivers have their own 802.11 stack,
which takes care of converting 802.3 to 802.11 packets and vice versa
(or use the kernel provided 802.11 stack, ie. mac80211 to take care of
that).
> - Can I still use the added functionality of 802.11 as compared to
> 802.3 by talking directly to the device and setting it's fields? I'm
> thinking of using "struct wireless_device" and/or "struct wiphy" and
> the functions that come with it.
As said I do not think you should care about 802.11. The structures
mentioned are data structures for configuration purposes on respectively
wireless interface and wireless device level.
> - Is it possible to find a general form of skb frame with correctly
> set headers? I have currently tested my code
> (https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c)
> and on one android device (galaxy S2 I9100, BCM4330 wireless chip) I
> had my 802.3 header by at my skb->head. On my own htc one X (htc
> endeavoru, wireless chip unknown still) I had my 802.3 header at my
> skb->mac_header and on my notebook (wireless 5100 AGN) this header was
> present on skb->data. Is it coincidence that these 3 are totally
> different and is there a function (that perhaps calls the drivers) to
> set these skb's in the correct prepared form? And if so, will this
> break when I void the layers on top of the mac layer.
How generic do you want it to be? As said the sk_buff is a pretty dumb
struct which is mostly protocol/stack independent. General advice here
is to avoid dealing with the pointers directly and use skb function api.
The hook mechanism dev_add_pack() you are using in [2] is new to me, but
it seems you are doing it while the packet is being processed in the
network stack so the state of the sk_buff can be pretty unpredictable.
Just remember you are probably not the only one handling this packet.
The stack internals are something I tend to stay clear off. Maybe one of
the networking experts can elaborate.
> While I know that a part of this still needs to be researched, for
> instance say it's possible to set certain fields of the device to use
> added 802.11 functionality I won't be setting the channel manually,
> that's still left to the driver, but other added functions might be
> more useful for RINA.
Examples of useful wireless specific functions? As I see it RINA is an
IPC based network stack on top of some physical layer, ie. ethernet. The
architectural picture in [1] even shows it can run on top of a TCP/IP
stack using sockets.
> What I'm hoping to achieve before really heading off into this new
> linux adventure is to be able to properly receive an SKB that has the
> same format on my devices and later down the road try to send set up
> an SKB and send that one myself.
It seems to me that you should familiarize yourself with linux
networking artifacts. Maybe [3] is a good read although it may be pretty
outdated.
Regards,
Arend
[1]
http://irati.eu/irati-first-phase-report-on-use-cases-requirements-analysis-updated-rina-specifications-and-high-level-software-architecture-available/
[2]
https://github.com/mathieudevos/wifi_kernelmodules/blob/master/ethernet_test.c
[3] http://shop.oreilly.com/product/9780596002558.do
> On Wed, Jul 31, 2013 at 5:11 PM, Mathieu Devos <mathieu.devos@ugent.be> wrote:
>> This is my hook: it gets called after I set dev to wlan0. I used a
>> guide for this and it seems to work for my notebook where I'm able to
>> find the 802.3 header but still no 802.11.
>>
>> static int ptype_function(struct sk_buff *skb, struct net_device *dev,
>> struct packet_type *ptype, struct net_device *dev2);
>>
>> static void throw_hook(struct net_device *dev){
>> ptype.type = htons(ETH_P_ALL);
>> ptype.func = &ptype_function;
>> ptype.dev = dev;
>> dev_add_pack(&ptype);
>> printk(KERN_CRIT "Done setting up packet type");
>> }
>>
>> All code can be found here:
>> android: https://github.com/mathieudevos/kernelmodules/blob/master/ethernet_test.c
>> notebook: https://github.com/mathieudevos/wifi_kernelmodules/blob/master/ethernet_test.c
>>
>> Kind regards,
>> Mathieu Devos
>>
>> On Wed, Jul 31, 2013 at 5:04 PM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 07/31/2013 03:45 PM, Mathieu Devos wrote:
>>>>
>>>> Alright,
>>>>
>>>> Seems like I have fixed some issues while added some others. Since I
>>>> assume that when my hook gets activated the data pointer should be at
>>>> the start of the 802.3 header I casted an ethhdr (8023) on top of that
>>>> and it seems that on my notebook this is handled correctly (I can
>>>> actually check on my own mac addr and see that these frames are
>>>> for/from me).
>>>
>>>
>>> How does your hook work? Are you intercepting packets?
>>>
>>> Regards,
>>> Arend
>>>
>>>
>>>> On Wed, Jul 31, 2013 at 2:55 PM, Arend van Spriel <arend@broadcom.com>
>>>> wrote:
>>>>>
>>>>> On 07/31/2013 02:39 PM, Mathieu Devos wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The wireless chip is a Broadcast BCM4330 chip. After looking around a
>>>>>> bit I found that this is a fullMAC and links to the driver on
>>>>>> wireless.kernel: http://wireless.kernel.org/en/users/Drivers/brcm80211
>>>>>> and also links directly to android itself:
>>>>>> https://android.googlesource.com/platform/hardware/broadcom/wlan
>>>>>
>>>>>
>>>>>
>>>>> I suspected. The bcm4330 is indeed a fullmac device, which means the
>>>>> 802.11
>>>>> stack is running on the device. The driver on Android is located under:
>>>>>
>>>>>
>>>>> https://android.googlesource.com/kernel/samsung/+/android-samsung-3.0-ics-mr1/drivers/net/wireless/bcmdhd/
>>>>>
>>>>> Not sure which android version you have.
>>>>>
>>>>> The brcm80211 on wireless.kernel.org is the upstream linux driver.
>>>>>
>>>>> Gr. AvS
>>>>>
>>>>>
>>>>>> Still trying to learn a lot in this tightly packed world of protocol
>>>>>> stacks, wireless and all the other poisons. Seems like I still have a
>>>>>> long way to go. Thank you already for helping me out with these issues
>>>>>> and taking the time to explain these things to me.
>>>>>>
>>>>>> Kind regards,
>>>>>> Mathieu Devos
>>>>>>
>>>>>> On Wed, Jul 31, 2013 at 1:05 PM, Arend van Spriel <arend@broadcom.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 07/31/2013 12:28 PM, Mathieu Devos wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It's an android smartphone (I 9100 - Samsung galaxy S2) so it does not
>>>>>>>> have a normal ethernet 802.3 input even. I check before selecting the
>>>>>>>> device that it's wireless (through ieee80211_ptr) and this properly
>>>>>>>> returns the wlan0 device which should be on the 80211 standard.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *sigh* Welcome in the world of protocol stacks, wireless, networking
>>>>>>> (choose
>>>>>>> your poison). Let me draw the picture.
>>>>>>>
>>>>>>> o user-space
>>>>>>> |
>>>>>>> ----------------------
>>>>>>> | kernel
>>>>>>> +-----------+
>>>>>>> | NET | networking subsystem, ie. TCP/IP stack
>>>>>>> +-----------+
>>>>>>> | 802.3
>>>>>>> +----------------+
>>>>>>> | | driver |
>>>>>>> | +------------+ |
>>>>>>> | |802.11 stack| |
>>>>>>> | +------------+ |
>>>>>>> | | 802.11 |
>>>>>>> +----------------+
>>>>>>> |
>>>>>>> o RF
>>>>>>>
>>>>>>> The device hooks up to the networking subsystem as an ethernet device
>>>>>>> and
>>>>>>> as
>>>>>>> such it receives 802.3 packets. These are converted to 802.11 packets
>>>>>>> by
>>>>>>> the
>>>>>>> 802.11 stack. Now depending on your device that happens in the device
>>>>>>> driver
>>>>>>> or on the device itself. Another option is that this is done by
>>>>>>> mac80211
>>>>>>> (kernel provided 802.11 stack), but that is probably not the case, but
>>>>>>> to
>>>>>>> be
>>>>>>> sure I ask again: what wireless device do you have in your galaxy S2?
>>>>>>>
>>>>>>> Gr. AvS
>>>>>>>
>>>>>>>
>>>>>>>> My goal is to get the ieee80211_header properly on the skb with this
>>>>>>>> device, but some of the pointers and original data in the skb seem
>>>>>>>> totally off. This leaves me clueless as to where to put this
>>>>>>>> ieee80211_header.
>>>>>>>> I've tried putting it right on skb->head (wrong I know, but I was
>>>>>>>> getting desperate), on skb->mac_header (also wrong, no idea why
>>>>>>>> though), I went back from skb->tail with len and even added ETH_HLEN
>>>>>>>> to that as well because you can see that before my hook gets
>>>>>>>> activated: skb_pull_inline(skb, ETH_HLEN);
>>>>>>>> In the end I'm left with a header that is forced onto data but with a
>>>>>>>> wrong origin pointer thus basically leaving me with all wrong data in
>>>>>>>> the header.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Mathieu Devos
>>>>>>>>
>>>>>>>> On Wed, Jul 31, 2013 at 12:08 PM, Arend van Spriel
>>>>>>>> <arend@broadcom.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/31/2013 11:39 AM, Mathieu Devos wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I hope this is the right place to ask for a little bit of help as
>>>>>>>>>> I'm
>>>>>>>>>> currently beyond stuck on a challenge I'm trying to accomplish. I'm
>>>>>>>>>> trying to write a "simple" LKM that properly uses a ieee80211 header
>>>>>>>>>> to print information about the mac addresses (addr1->addr4) and
>>>>>>>>>> later
>>>>>>>>>> down the road try to send my own data.
>>>>>>>>>>
>>>>>>>>>> I only need to get L2 working, no need for TCP/IP, just a proper
>>>>>>>>>> ieee80211 based on input from skb would be huge for me.
>>>>>>>>>>
>>>>>>>>>> So my issue: when placing the ieee80211 on my mac_header after I
>>>>>>>>>> hook
>>>>>>>>>> my skb from my wireless device (wlan0 on android - I9100)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure what you goal is, but what wireless device is that? You may
>>>>>>>>> just
>>>>>>>>> get 802.3 packets from the device.
>>>>>>>>>
>>>>>>>>> Gr. AvS
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I get a huge
>>>>>>>>>> amount of zero's and random(?) numbers when trying to print the
>>>>>>>>>> addresses. This leads me to the first conclusion that mac_header is
>>>>>>>>>> placed wrong when using 80211. After that I saw a lot of people just
>>>>>>>>>> using the skb->data pointer. Now this gives even weirder issues for
>>>>>>>>>> me
>>>>>>>>>> and actually totally crashes my kernel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
^ permalink raw reply
* [PATCH v2] ath10k: setup peer UAPSD flag correctly
From: Janusz Dziedzic @ 2013-08-07 10:10 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Janusz Dziedzic
Setup UAPSD peer/peer rate flags correctly.
WMI_RC_UAPSD_FLAG is a peer rate capabilities flag
and should not be set as a peer flag.
Found during code review, doesn't fix a known
issues.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cf2ba4d..505be82 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -973,7 +973,7 @@ static void ath10k_peer_assoc_h_qos_ap(struct ath10k *ar,
sta->uapsd_queues, sta->max_sp);
arg->peer_flags |= WMI_PEER_APSD;
- arg->peer_flags |= WMI_RC_UAPSD_FLAG;
+ arg->peer_rate_caps |= WMI_RC_UAPSD_FLAG;
if (sta->uapsd_queues & IEEE80211_WMM_IE_STA_QOSINFO_AC_VO)
uapsd |= WMI_AP_PS_UAPSD_AC3_DELIVERY_EN |
--
1.7.9.5
^ permalink raw reply related
* [PATCH] backports: rename some mem functions to not break custom kernels
From: Arik Nemtsov @ 2013-08-07 8:52 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Arik Nemtsov
When custom patches are cherry-picked to a kernel, some symbols exported
by backports may clash with the built-in ones. Rename the backports
symbols using the standard backport_ prefix to prevent that. Backported
drivers will resolve to the correct function via a define.
The offending symbols were exported by the patch below:
commit 2ce5c22448bb45998318267c00b5d6ef9cff3170
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Thu Jun 6 13:48:04 2013 +0200
backports: backport some memory functions
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
backport/backport-include/asm/mtrr.h | 7 +++++--
backport/backport-include/linux/io.h | 14 +++++++-------
backport/compat/backport-3.11.c | 16 ++++++++--------
3 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/backport/backport-include/asm/mtrr.h b/backport/backport-include/asm/mtrr.h
index cf0f6fd..c5760b4 100644
--- a/backport/backport-include/asm/mtrr.h
+++ b/backport/backport-include/asm/mtrr.h
@@ -7,14 +7,17 @@
* The following functions are for use by other drivers that cannot use
* arch_phys_wc_add and arch_phys_wc_del.
*/
+#ifndef phys_wc_to_mtrr_index
#ifdef CONFIG_MTRR
-extern int phys_wc_to_mtrr_index(int handle);
+extern int backport_phys_wc_to_mtrr_index(int handle);
#else
-static inline int phys_wc_to_mtrr_index(int handle)
+static inline int backport_phys_wc_to_mtrr_index(int handle)
{
return -1;
}
#endif /* CONFIG_MTRR */
+#define phys_wc_to_mtrr_index LINUX_BACKPORT(phys_wc_to_mtrr_index)
+#endif
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,11,0)) */
#endif /* __BACKPORT_ASM_MTRR_H */
diff --git a/backport/backport-include/linux/io.h b/backport/backport-include/linux/io.h
index 9a5b308..5f62c62 100644
--- a/backport/backport-include/linux/io.h
+++ b/backport/backport-include/linux/io.h
@@ -15,22 +15,22 @@
*/
#ifndef arch_phys_wc_add
#ifdef CONFIG_MTRR
-extern int __must_check arch_phys_wc_add(unsigned long base,
- unsigned long size);
-extern void arch_phys_wc_del(int handle);
+extern int __must_check backport_arch_phys_wc_add(unsigned long base,
+ unsigned long size);
+extern void backport_arch_phys_wc_del(int handle);
#else
-static inline int __must_check arch_phys_wc_add(unsigned long base,
- unsigned long size)
+static inline int __must_check backport_arch_phys_wc_add(unsigned long base,
+ unsigned long size)
{
return 0; /* It worked (i.e. did nothing). */
}
-static inline void arch_phys_wc_del(int handle)
+static inline void backport_arch_phys_wc_del(int handle)
{
}
#endif /* CONFIG_MTRR */
-#define arch_phys_wc_add arch_phys_wc_add
+#define arch_phys_wc_add LINUX_BACKPORT(arch_phys_wc_add)
#endif
#endif /* __BACKPORT_LINUX_IO_H */
diff --git a/backport/compat/backport-3.11.c b/backport/compat/backport-3.11.c
index c6d5a02..5ff17d1 100644
--- a/backport/compat/backport-3.11.c
+++ b/backport/compat/backport-3.11.c
@@ -21,7 +21,7 @@
#define MTRR_TO_PHYS_WC_OFFSET 1000
/**
- * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
+ * backport_arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
* @base: Physical base address
* @size: Size of region
*
@@ -32,7 +32,7 @@
* Drivers must store the return value to pass to mtrr_del_wc_if_needed,
* but drivers should not try to interpret that return value.
*/
-int arch_phys_wc_add(unsigned long base, unsigned long size)
+int backport_arch_phys_wc_add(unsigned long base, unsigned long size)
{
int ret;
@@ -49,7 +49,7 @@ int arch_phys_wc_add(unsigned long base, unsigned long size)
}
return ret + MTRR_TO_PHYS_WC_OFFSET;
}
-EXPORT_SYMBOL_GPL(arch_phys_wc_add);
+EXPORT_SYMBOL_GPL(backport_arch_phys_wc_add);
/*
* arch_phys_wc_del - undoes arch_phys_wc_add
@@ -60,17 +60,17 @@ EXPORT_SYMBOL_GPL(arch_phys_wc_add);
* The API guarantees that mtrr_del_wc_if_needed(error code) and
* mtrr_del_wc_if_needed(0) do nothing.
*/
-void arch_phys_wc_del(int handle)
+void backport_arch_phys_wc_del(int handle)
{
if (handle >= 1) {
WARN_ON(handle < MTRR_TO_PHYS_WC_OFFSET);
mtrr_del(handle - MTRR_TO_PHYS_WC_OFFSET, 0, 0);
}
}
-EXPORT_SYMBOL_GPL(arch_phys_wc_del);
+EXPORT_SYMBOL_GPL(backport_arch_phys_wc_del);
/*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * backport_phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
* @handle: Return value from arch_phys_wc_add
*
* This will turn the return value from arch_phys_wc_add into an mtrr
@@ -80,13 +80,13 @@ EXPORT_SYMBOL_GPL(arch_phys_wc_del);
* in printk line. Alas there is an illegitimate use in some ancient
* drm ioctls.
*/
-int phys_wc_to_mtrr_index(int handle)
+int backport_phys_wc_to_mtrr_index(int handle)
{
if (handle < MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
}
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(backport_phys_wc_to_mtrr_index);
#endif /* CONFIG_MTRR */
--
1.8.1.2
^ permalink raw reply related
* [PATCH] mac80211: ibss - immediately create a cell if bssid and freq have been provided
From: Antonio Quartulli @ 2013-08-07 8:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
The current behaviour when not finding the cbss in the local
list is to always scan before creating the IBSS. However if
bssid and freq have been provided (and fixed_freq is set) it
is possible to immediately create the cell and avoid wasting
time with the scan operation.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/mac80211/ibss.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index e08387c..811207a 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -891,6 +891,17 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
return;
}
+ /* if a fixed bssid and a fixed freq have been provided create the IBSS
+ * directly and do not waste time scanning
+ */
+ if (!cbss && ifibss->fixed_bssid && ifibss->fixed_channel) {
+ sdata_info(sdata, "Created IBSS using preconfigured BSSID %pM\n",
+ bssid);
+ ieee80211_sta_create_ibss(sdata);
+ return;
+ }
+
+
ibss_dbg(sdata, "sta_find_ibss: did not try to join ibss\n");
/* Selected IBSS not found in current scan results - try to scan */
--
1.8.1.5
^ permalink raw reply related
* Re: linux-next: Tree for Aug 7
From: Sedat Dilek @ 2013-08-07 8:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, netdev, David Miller, Phil Sutter,
Hannes Frederic Sowa, wireless, John Linville, Johannes Berg
In-Reply-To: <20130807155443.a0355d0429f3e0b4ccbed261@canb.auug.org.au>
On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Changes since 20130806:
>
> The ext4 tree lost its build failure.
>
> The mvebu tree gained a build failure so I used the version from
> next-20130806.
>
> The akpm tree gained conflicts against the ext4 tree.
>
> ----------------------------------------------------------------------------
>
[ CC some netdev and wireless folks ]
Yesterday, I discovered an issue with net-next.
The patch in [1] fixed the problems in my network/wifi environment.
Hannes confirmed that virtio_net are solved, too.
Today's next-20130807 still needs it for affected people.
- Sedat -
[1] http://marc.info/?l=linux-netdev&m=137582524017840&w=2
[2] http://marc.info/?l=linux-netdev&m=137583048219416&w=2
[3] http://marc.info/?t=137579712800008&r=1&w=2
^ permalink raw reply
* Re: [PATCH] ath10k: setup peer UAPSD flag correctly
From: Kalle Valo @ 2013-08-07 8:04 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: ath10k, linux-wireless
In-Reply-To: <CALhHN=pP32Vw6UMvS93cReWr6WHz3p_3d8mn0FNJtSQGvuGJ9w@mail.gmail.com>
Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
> Setup UAPSD peer/peer rate flags correctly.
> WMI_RC_UAPSD_FLAG is a peer rate capabilities flag
> and should not be set as a peer flag.
>
> BTW this don't fix any known bug yet, just found during UAPSD check.
OK. If a bug has been during a code review and doesn't fix a known
issue, please mention that in the commit log as well.
I added this also to the wiki.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath6kl : Fix invalid pointer access on fuzz testing with AP mode
From: Kalle Valo @ 2013-08-07 7:59 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan; +Cc: linux-wireless, ath6kl-devel
In-Reply-To: <1375678162-3190-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
>
> In our Fuz testing, reference client corrupts the dest mac to "00:00:00:00:00:00"
> in the WPA2 handshake no 2. During driver init the sta_list entries mac
> addresses are by default "00:00:00:00:00:00". Driver returns an invalid
> pointer (conn) and the drver shall crash, if rxtids (aggr_conn)
> skb queues are accessed, since they would not be initialized.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Thanks, applied.
I just did s/ath6kl :/ath6kl:/ in the subject.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath6kl: Fix race in heart beat polling
From: Kalle Valo @ 2013-08-07 7:55 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: linux-wireless, Vasanthakumar Thiagarajan, ath6kl-devel
In-Reply-To: <1371712640-12834-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> writes:
> From: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
>
> Make sure to cancel heart beat timer before
> freeing wmi to avoid potential NULL pointer
> dereference.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* [PATCH] udev: fail firmware loading immediately if no search path is defined
From: Maarten Lankhorst @ 2013-08-07 7:52 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Tom Gundersen, Bryan Kadzban, systemd Mailing List,
Linux Wireless List, Johannes Berg, Intel Linux Wireless,
linux-hotplug, Kay Sievers, linux-kernel
In-Reply-To: <CALCETrU-CWuefE5XUpC=xFuCXaL56Cox95nL35Bm9jMi_B+6_A@mail.gmail.com>
Op 07-08-13 02:26, Andy Lutomirski schreef:
> On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen <teg@jklm.no> wrote:
>> On 6 Aug 2013 18:32, "Bryan Kadzban" <bryan@kadzban.is-a-geek.net> wrote:
>>> On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote:
>>>> On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen <teg@jklm.no> wrote:
>>>>> On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst
>>>>> <m.b.lankhorst@gmail.com> wrote:
>>>>>> Op 05-08-13 18:29, Andy Lutomirski schreef:
>>>>>>> The systemd commit below can delay firmware loading by multiple
>>>>>>> minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one
>>>>>>> noticed that the systemd-udev change would break new kernels as well
>>>>>>> as old kernels.
>>>>>>>
>>>>>>> Since the kernel apparently can't count on reasonable userspace
>>>>>>> support, turn this thing off by default.
>>>>>>>
>>>>>>> commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
>>>>>>> Author: Tom Gundersen <teg@jklm.no>
>>>>>>> Date: Mon Mar 18 15:12:18 2013 +0100
>>>>>>>
>>>>>>> udev: make firmware loading optional and disable by default
>>>>>>>
>>>>>>> Distros that whish to support old kernels should set
>>>>>>>
>>>>>>> --with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
>>>>>>> to retain the old behaviour.
>>>>>>>
>>>>>> methinks this patch should be reverted then,
>>>>> Well, all the code is still there, so it can be enabled if anyone
>>>>> wants it.
>>>>>
>>>>>> or a stub should be added to udev to always fail firmware loading so
>>>>>> timeouts don't occur.
>>>>> I think the only use (if any) of a userspace firmware loader would be
>>>>> for anyone who wants a custom one (i.e., not udev), so we shouldn't
>>>>> just fail the loading from udev unconditionally.
>>>>>
>>>>> How about we just improve the udev documentation a bit, similar to
>>>>> Andy's kernel patch?
>>>> Sorry, I should first have checked. We already document this in the
>>>> README:
>>>>
>>>>> Userspace firmware loading is deprecated, will go away, and
>>>>> sometimes causes problems:
>>>>> CONFIG_FW_LOADER_USER_HELPER=n
>>> ...And this patch is making the kernel default to the correct behavior,
>>> instead of the now-broken-by-udev behavior.
>>>
>>> I'm not sure I see the issue with it? :-)
>> Oh yeah this patch is totally the right thing to do, I was just arguing that
>> there is nothing to be done on the udev side.
>>
>>> (Add me to the list of people that think udev is broken too, fwiw. But
>>> let's at least not leave *both* sides in a broken-by-default state.)
>> Well I don't think it is too much to ask that the kernel and udev should be
>> configured in a consistent way. Especially as thing still work even if you
>> get it wrong, albeit with a delay.
> Except that the current defaults are inconsistent and there is no
> explanation anywhere in the logs when this is screwed up.
>
So what is wrong with my 'fail in udev immediately if not configured' idea? In that case it
doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not.
You could even print a useful message for the user in udev to the log, so they have an idea of what
happened. Breaking udev on older still supported kernels by default without printing any debug info
is silly, and the only cost is a small increase in disk space when unused. I did so in below patch.
~Maarten
I converted < ELEMENTSOF to != ELEMENTSOF in the loop to work correctly when the array is empty.
Most code in udev-builtin-firmware is eliminated at -O2 optimization level when FIRMWARE_PATH
is not explicitly set.
8<----
diff --git a/Makefile.am b/Makefile.am
index b8b8d06..2097629 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2235,6 +2235,7 @@ libudev_core_la_SOURCES = \
src/udev/udev-ctrl.c \
src/udev/udev-builtin.c \
src/udev/udev-builtin-btrfs.c \
+ src/udev/udev-builtin-firmware.c \
src/udev/udev-builtin-hwdb.c \
src/udev/udev-builtin-input_id.c \
src/udev/udev-builtin-keyboard.c \
@@ -2271,14 +2272,6 @@ libudev_core_la_CPPFLAGS = \
$(AM_CPPFLAGS) \
-DFIRMWARE_PATH="$(FIRMWARE_PATH)"
-if ENABLE_FIRMWARE
-libudev_core_la_SOURCES += \
- src/udev/udev-builtin-firmware.c
-
-dist_udevrules_DATA += \
- rules/50-firmware.rules
-endif
-
if HAVE_KMOD
libudev_core_la_SOURCES += \
src/udev/udev-builtin-kmod.c
diff --git a/configure.ac b/configure.ac
index 0ecc716..dc7a3e3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -823,8 +823,6 @@ for i in $with_firmware_path; do
done
IFS=$OLD_IFS
AC_SUBST(FIRMWARE_PATH)
-AS_IF([test "x${FIRMWARE_PATH}" != "x"], [ AC_DEFINE(HAVE_FIRMWARE, 1, [Define if FIRMWARE is available]) ])
-AM_CONDITIONAL(ENABLE_FIRMWARE, [test "x${FIRMWARE_PATH}" != "x"])
# ------------------------------------------------------------------------------
AC_ARG_ENABLE([gudev],
diff --git a/rules/50-firmware.rules b/rules/50-firmware.rules
deleted file mode 100644
index f0ae684..0000000
--- a/rules/50-firmware.rules
+++ /dev/null
@@ -1,3 +0,0 @@
-# do not edit this file, it will be overwritten on update
-
-SUBSYSTEM=="firmware", ACTION=="add", RUN{builtin}="firmware"
diff --git a/rules/50-udev-default.rules b/rules/50-udev-default.rules
index f764789..645830e 100644
--- a/rules/50-udev-default.rules
+++ b/rules/50-udev-default.rules
@@ -8,6 +8,7 @@ SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
+SUBSYSTEM=="firmware", ACTION=="add", IMPORT{builtin}="firmware"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
ACTION!="add", GOTO="default_permissions_end"
diff --git a/shell-completion/bash/udevadm b/shell-completion/bash/udevadm
index 8ad8550..c22a3e2 100644
--- a/shell-completion/bash/udevadm
+++ b/shell-completion/bash/udevadm
@@ -83,7 +83,7 @@ _udevadm() {
fi
;;
'test-builtin')
- comps='blkid btrfs hwdb input_id keyboard kmod net_id path_id usb_id uaccess'
+ comps='blkid btrfs firmware hwdb input_id keyboard kmod net_id path_id usb_id uaccess'
;;
*)
comps=${VERBS[*]}
diff --git a/src/udev/udev-builtin-firmware.c b/src/udev/udev-builtin-firmware.c
index b80940b..e678545 100644
--- a/src/udev/udev-builtin-firmware.c
+++ b/src/udev/udev-builtin-firmware.c
@@ -97,7 +97,7 @@ static int builtin_firmware(struct udev_device *dev, int argc, char *argv[], boo
/* lookup firmware file */
uname(&kernel);
- for (i = 0; i < ELEMENTSOF(searchpath); i++) {
+ for (i = 0; i != ELEMENTSOF(searchpath); i++) {
strscpyl(fwpath, sizeof(fwpath), searchpath[i], kernel.release, "/", firmware, NULL);
fwfile = fopen(fwpath, "re");
if (fwfile != NULL)
@@ -112,7 +112,10 @@ static int builtin_firmware(struct udev_device *dev, int argc, char *argv[], boo
strscpyl(loadpath, sizeof(loadpath), udev_device_get_syspath(dev), "/loading", NULL);
if (fwfile == NULL) {
- log_debug("did not find firmware file '%s'\n", firmware);
+ if (ELEMENTSOF(searchpath))
+ log_debug("did not find firmware file '%s'\n", firmware);
+ else
+ log_error("could not load firmware file '%s', firmware loading not enabled\n", firmware);
rc = EXIT_FAILURE;
/*
* Do not cancel the request in the initrd, the real root might have
diff --git a/src/udev/udev-builtin.c b/src/udev/udev-builtin.c
index 6b3a518..5a5cb30 100644
--- a/src/udev/udev-builtin.c
+++ b/src/udev/udev-builtin.c
@@ -34,9 +34,7 @@ static const struct udev_builtin *builtins[] = {
[UDEV_BUILTIN_BLKID] = &udev_builtin_blkid,
#endif
[UDEV_BUILTIN_BTRFS] = &udev_builtin_btrfs,
-#ifdef HAVE_FIRMWARE
[UDEV_BUILTIN_FIRMWARE] = &udev_builtin_firmware,
-#endif
[UDEV_BUILTIN_HWDB] = &udev_builtin_hwdb,
[UDEV_BUILTIN_INPUT_ID] = &udev_builtin_input_id,
[UDEV_BUILTIN_KEYBOARD] = &udev_builtin_keyboard,
diff --git a/src/udev/udev.h b/src/udev/udev.h
index 8395926..31fa606 100644
--- a/src/udev/udev.h
+++ b/src/udev/udev.h
@@ -140,9 +140,7 @@ enum udev_builtin_cmd {
UDEV_BUILTIN_BLKID,
#endif
UDEV_BUILTIN_BTRFS,
-#ifdef HAVE_FIRMWARE
UDEV_BUILTIN_FIRMWARE,
-#endif
UDEV_BUILTIN_HWDB,
UDEV_BUILTIN_INPUT_ID,
UDEV_BUILTIN_KEYBOARD,
@@ -170,9 +168,7 @@ struct udev_builtin {
extern const struct udev_builtin udev_builtin_blkid;
#endif
extern const struct udev_builtin udev_builtin_btrfs;
-#ifdef HAVE_FIRMWARE
extern const struct udev_builtin udev_builtin_firmware;
-#endif
extern const struct udev_builtin udev_builtin_hwdb;
extern const struct udev_builtin udev_builtin_input_id;
extern const struct udev_builtin udev_builtin_keyboard;
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 45ec3d6..e27a33a 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -98,9 +98,7 @@ struct event {
dev_t devnum;
int ifindex;
bool is_block;
-#ifdef HAVE_FIRMWARE
bool nodelay;
-#endif
};
static inline struct event *node_to_event(struct udev_list_node *node)
@@ -444,10 +442,8 @@ static int event_queue_insert(struct udev_device *dev)
event->devnum = udev_device_get_devnum(dev);
event->is_block = streq("block", udev_device_get_subsystem(dev));
event->ifindex = udev_device_get_ifindex(dev);
-#ifdef HAVE_FIRMWARE
if (streq(udev_device_get_subsystem(dev), "firmware"))
event->nodelay = true;
-#endif
udev_queue_export_device_queued(udev_queue_export, dev);
log_debug("seq %llu queued, '%s' '%s'\n", udev_device_get_seqnum(dev),
@@ -527,11 +523,9 @@ static bool is_devpath_busy(struct event *event)
return true;
}
-#ifdef HAVE_FIRMWARE
/* allow to bypass the dependency tracking */
if (event->nodelay)
continue;
-#endif
/* parent device event found */
if (event->devpath[common] == '/') {
^ permalink raw reply related
* Re: [PATCH] ath10k: setup peer UAPSD flag correctly
From: Janusz Dziedzic @ 2013-08-07 7:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87li4e6l67.fsf@kamboji.qca.qualcomm.com>
On 7 August 2013 08:59, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
>
>> Setup UAPSD peer rate control (FW flag)
>> correctly.
>>
>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
>
> This doesn't answer the question "Why?". I have now added a section in
> the wiki about what the commit log should contain. Hopefully that helps.
>
> Submitting patches
>
> Send patches to the mailing lists below. Kalle Valo reviews the patches
> within the next few days and, if they are ok, commits them to ath.git.
>
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
>
> Preferably use ath.git master as the baseline for patches. Other trees
> can be used as well, but then the chances of conflicts are higher.
>
> Guidelines for patches:
>
> * MUST be compiler warning free.
>
> * MUST be sparse warning free.
>
> * Commit log MUST not be empty.
>
> * The commit log MUST answer the question "Why?":
>
> * Describe the motivation behind the bug.
>
> * How does it change the functionality from user's point of view?
>
> * Does it fix a bug? If it does, please describe the bug (doesn't need
> to be long). Also if there's a public bug report add a link to the
> bug report.
>
> * If others have reported the issue commit log SHOULD use Reported-by:
> and Tested-by: tags.
>
> * SHOULD be checkpatch clean:
>
> * FIXME: add checkpatch example with correct arguments
>
> * Patches SHOULD be sent with git send-email tool.
>
> * Patchsets SHOULD contain no more than 12 patches.
>
> The terminology is from http://www.ietf.org/rfc/rfc2119.txt
>
> http://wireless.kernel.org/en/users/Drivers/ath10k#Submitting_patches
>
> Please comment.
>
Setup UAPSD peer/peer rate flags correctly.
WMI_RC_UAPSD_FLAG is a peer rate capabilities flag
and should not be set as a peer flag.
BTW this don't fix any known bug yet, just found during UAPSD check.
BR
Janusz
^ permalink raw reply
* [PATCH v2 2/2] ath9k: Run the LNA combining algorithm properly
From: Sujith Manoharan @ 2013-08-07 7:24 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-3-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The LNA combining algorithm has to be run for cards
that support the required diversity features, make
sure that that correct conditions are met before
enabing this algorithm.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
v2 : Fix a misplaced semicolon
drivers/net/wireless/ath/ath9k/recv.c | 44 ++++++++++++++++++++++-------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 865e043..62dff97 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1157,6 +1157,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
struct ieee80211_rx_status *rxs;
struct ath_hw *ah = sc->sc_ah;
+ struct ath9k_hw_capabilities *pCap = &ah->caps;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_hdr *hdr;
@@ -1328,11 +1329,30 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
skb = hdr_skb;
}
+ if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
+ skb_trim(skb, skb->len - 8);
- if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
+ spin_lock_irqsave(&sc->sc_pm_lock, flags);
+ if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
+ PS_WAIT_FOR_CAB |
+ PS_WAIT_FOR_PSPOLL_DATA)) ||
+ ath9k_check_auto_sleep(sc))
+ ath_rx_ps(sc, skb, rs.is_mybeacon);
+ spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+ /*
+ * Run the LNA combining algorithm only in these cases:
+ *
+ * Standalone WLAN cards with both LNA/Antenna diversity
+ * enabled in the EEPROM.
+ *
+ * WLAN+BT cards which are in the supported card list
+ * in ath_pci_id_table and the user has loaded the
+ * driver with "bt_ant_diversity" set to true.
+ */
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) {
/*
- * change the default rx antenna if rx diversity
+ * Change the default rx antenna if rx diversity
* chooses the other antenna 3 times in a row.
*/
if (sc->rx.defant != rs.rs_antenna) {
@@ -1342,22 +1362,14 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
sc->rx.rxotherant = 0;
}
+ if (pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV) {
+ if (common->bt_ant_diversity)
+ ath_ant_comb_scan(sc, &rs);
+ } else {
+ ath_ant_comb_scan(sc, &rs);
+ }
}
- if (rxs->flag & RX_FLAG_MMIC_STRIPPED)
- skb_trim(skb, skb->len - 8);
-
- spin_lock_irqsave(&sc->sc_pm_lock, flags);
- if ((sc->ps_flags & (PS_WAIT_FOR_BEACON |
- PS_WAIT_FOR_CAB |
- PS_WAIT_FOR_PSPOLL_DATA)) ||
- ath9k_check_auto_sleep(sc))
- ath_rx_ps(sc, skb, rs.is_mybeacon);
- spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
-
- if ((ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB) && sc->ant_rx == 3)
- ath_ant_comb_scan(sc, &rs);
-
ath9k_apply_ampdu_details(sc, &rs, rxs);
ieee80211_rx(hw, skb);
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: Run the LNA combining algorithm properly
From: Sujith Manoharan @ 2013-08-07 7:18 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John Linville, linux-wireless, ath9k-devel
In-Reply-To: <5201F4B9.1080109@openwrt.org>
Felix Fietkau wrote:
> > - struct ath_hw *ah = sc->sc_ah;
> > + struct ath_hw *ah = sc->sc_ah
> > +; struct ath9k_hw_capabilities *pCap = &ah->caps;
> > struct ath_common *common = ath9k_hw_common(ah);
> > struct ieee80211_hw *hw = sc->hw;
> > struct ieee80211_hdr *hdr;
> Misplaced semicolon
Thanks, I'll send v2.
Sujith
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Run the LNA combining algorithm properly
From: Felix Fietkau @ 2013-08-07 7:18 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: John Linville, linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-3-git-send-email-sujith@msujith.org>
On 2013-08-07 8:59 AM, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> The LNA combining algorithm has to be run for cards
> that support the required diversity features, make
> sure that that correct conditions are met before
> enabing this algorithm.
>
> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath9k/recv.c | 46 ++++++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index 865e043..e359557 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -1156,7 +1156,8 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
> struct ath_buf *bf;
> struct sk_buff *skb = NULL, *requeue_skb, *hdr_skb;
> struct ieee80211_rx_status *rxs;
> - struct ath_hw *ah = sc->sc_ah;
> + struct ath_hw *ah = sc->sc_ah
> +; struct ath9k_hw_capabilities *pCap = &ah->caps;
> struct ath_common *common = ath9k_hw_common(ah);
> struct ieee80211_hw *hw = sc->hw;
> struct ieee80211_hdr *hdr;
Misplaced semicolon
^ permalink raw reply
* Re: [PATCH v2] ath10k: add SoC power save option to PCI features map
From: Kalle Valo @ 2013-08-07 7:07 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1375430329-23352-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> Unify the PCI options location.
>
> By default the SoC PS option is disabled to boost the
> performance and due to poor stability on early HW revisions.
> In future we can remove the module parameter and turn on/off
> the PS for given hardware.
>
> This change also makes the pci module parameter for SoC PS static.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Thanks, applied. But there were conflicts, please double check that I
didn't break anything.
--
Kalle Valo
^ permalink raw reply
* [PATCH 0/2] Antenna diversity fixes
From: Sujith Manoharan @ 2013-08-07 6:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Hi,
Antenna diversity support for WLAN/BT combo cards WB195 and WB225
is fairly complete. WB335, which is based on AR9565 requires more
fixes.
More information is here:
http://wireless.kernel.org/en/users/Drivers/ath9k/antennadiversity
Sujith
Sujith Manoharan (2):
ath9k: Fix BTCOEX usage for RX diversity
ath9k: Run the LNA combining algorithm properly
drivers/net/wireless/ath/ath9k/init.c | 4 +--
drivers/net/wireless/ath/ath9k/recv.c | 46 ++++++++++++++++++++++-------------
2 files changed, 31 insertions(+), 19 deletions(-)
--
1.8.3.4
^ permalink raw reply
* [PATCH 1/2] ath9k: Fix BTCOEX usage for RX diversity
From: Sujith Manoharan @ 2013-08-07 6:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1375858768-24655-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
BTCOEX has to be *disabled* for WLAN RX diversity to
work on combo cards.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 4afe30e..3b56c2e 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -645,11 +645,11 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
/*
* Enable WLAN/BT RX Antenna diversity only when:
*
- * - BTCOEX is enabled
+ * - BTCOEX is disabled.
* - the user manually requests the feature.
* - the HW cap is set using the platform data.
*/
- if (common->btcoex_enabled && ath9k_bt_ant_diversity &&
+ if (!common->btcoex_enabled && ath9k_bt_ant_diversity &&
(pCap->hw_caps & ATH9K_HW_CAP_BT_ANT_DIV))
common->bt_ant_diversity = 1;
--
1.8.3.4
^ permalink raw reply related
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