summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-09-29tcp: use tcp_flags in tcp_data_queue()Peter Pan(潘卫平)1-3/+2
This patch is a cleanup which follows the idea in commit e11ecddf5128 (tcp: use TCP_SKB_CB(skb)->tcp_flags in input path), and it may reduce register pressure since skb->cb[] access is fast, bacause skb is probably in a register. v2: remove variable th v3: reword the changelog Signed-off-by: Weiping Pan <panweiping3@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29tcp: change tcp_skb_pcount() locationEric Dumazet4-11/+33
Our goal is to access no more than one cache line access per skb in a write or receive queue when doing the various walks. After recent TCP_SKB_CB() reorganizations, it is almost done. Last part is tcp_skb_pcount() which currently uses skb_shinfo(skb)->gso_segs, which is a terrible choice, because it needs 3 cache lines in current kernel (skb->head, skb->end, and shinfo->gso_segs are all in 3 different cache lines, far from skb->cb) This very simple patch reuses space currently taken by tcp_tw_isn only in input path, as tcp_skb_pcount is only needed for skb stored in write queue. This considerably speeds up tcp_ack(), granted we avoid shinfo->tx_flags to get SKBTX_ACK_TSTAMP, which seems possible. This also speeds up all sack processing in general. This speeds up tcp_sendmsg() because it no longer has to access/dirty shinfo. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29Merge branch 'tcp_skb_cb'David S. Miller11-34/+64
Eric Dumazet says: ==================== tcp: better TCP_SKB_CB layout TCP had the assumption that IPCB and IP6CB are first members of skb->cb[] This is fine, except that IPCB/IP6CB are used in TCP for a very short time in input path. What really matters for TCP stack is to get skb->next, TCP_SKB_CB(skb)->seq, and TCP_SKB_CB(skb)->end_seq in the same cache line. skb that are immediately consumed do not care because whole skb->cb[] is hot in cpu cache, while skb that sit in wocket write queue or receive queues do not need TCP_SKB_CB(skb)->header at all. This patch set implements the prereq for IPv4, IPv6, and TCP to make this possible. This makes TCP more efficient. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29tcp: better TCP_SKB_CB layout to reduce cache line missesEric Dumazet4-13/+30
TCP maintains lists of skb in write queue, and in receive queues (in order and out of order queues) Scanning these lists both in input and output path usually requires access to skb->next, TCP_SKB_CB(skb)->seq, and TCP_SKB_CB(skb)->end_seq These fields are currently in two different cache lines, meaning we waste lot of memory bandwidth when these queues are big and flows have either packet drops or packet reorders. We can move TCP_SKB_CB(skb)->header at the end of TCP_SKB_CB, because this header is not used in fast path. This allows TCP to search much faster in the skb lists. Even with regular flows, we save one cache line miss in fast path. Thanks to Christoph Paasch for noticing we need to cleanup skb->cb[] (IPCB/IP6CB) before entering IP stack in tx path, and that I forgot IPCB use in tcp_v4_hnd_req() and tcp_v4_save_options(). Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ipv6: add a struct inet6_skb_parm param to ipv6_opt_accepted()Eric Dumazet5-7/+9
ipv6_opt_accepted() assumes IP6CB(skb) holds the struct inet6_skb_parm that it needs. Lets not assume this, as TCP stack might use a different place. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ipv4: rename ip_options_echo to __ip_options_echo()Eric Dumazet4-14/+25
ip_options_echo() assumes struct ip_options is provided in &IPCB(skb)->opt Lets break this assumption, but provide a helper to not change all call points. ip_send_unicast_reply() gets a new struct ip_options pointer. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29Merge branch 'ipv6_tunnel'David S. Miller3-2/+12
Steffen Klassert says: ==================== ipv6: Return an error when adding an already existing tunnel The ipv6 tunnel locate functions should not return an existing tunnel if create is true. Otherwise it is possible to add the same tunnel multiple times without getting an error. All our ipv6 tunnels have this bug from the very beginning. Only the sit tunnel was fixed some years ago with: commit 8db99e57175 ("sit: Fail to create tunnel, if it already exists"). This patchset fixes the remaining ipv6 tunnels. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ip6_gre: Return an error when adding an existing tunnel.Steffen Klassert1-0/+2
ip6gre_tunnel_locate() should not return an existing tunnel if create is true. Otherwise it is possible to add the same tunnel multiple times without getting an error. So return NULL if the tunnel that should be created already exists. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ip6_vti: Return an error when adding an existing tunnel.Steffen Klassert1-1/+5
vti6_locate() should not return an existing tunnel if create is true. Otherwise it is possible to add the same tunnel multiple times without getting an error. So return NULL if the tunnel that should be created already exists. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ip6_tunnel: Return an error when adding an existing tunnel.Steffen Klassert1-1/+5
ip6_tnl_locate() should not return an existing tunnel if create is true. Otherwise it is possible to add the same tunnel multiple times without getting an error. So return NULL if the tunnel that should be created already exists. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-28Merge branch 'for-linus' of ↵Linus Torvalds8-85/+60
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro: "Assorted fixes + unifying __d_move() and __d_materialise_dentry() + minimal regression fix for d_path() of victims of overwriting rename() ported on top of that" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: vfs: Don't exchange "short" filenames unconditionally. fold swapping ->d_name.hash into switch_names() fold unlocking the children into dentry_unlock_parents_for_move() kill __d_materialise_dentry() __d_materialise_dentry(): flip the order of arguments __d_move(): fold manipulations with ->d_child/->d_subdirs don't open-code d_rehash() in d_materialise_unique() pull rehashing and unlocking the target dentry into __d_materialise_dentry() ufs: deal with nfsd/iget races fuse: honour max_read and max_write in direct_io mode shmem: fix nlink for rename overwrite directory
2014-09-28Merge branch 'for-3.17-fixes' of ↵Linus Torvalds6-24/+43
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "This is quite late but these need to be backported anyway. This is the fix for a long-standing cpuset bug which existed from 2009. cpuset makes use of PF_SPREAD_{PAGE|SLAB} flags to modify the task's memory allocation behavior according to the settings of the cpuset it belongs to; unfortunately, when those flags have to be changed, cpuset did so directly even whlie the target task is running, which is obviously racy as task->flags may be modified by the task itself at any time. This obscure bug manifested as corrupt PF_USED_MATH flag leading to a weird crash. The bug is fixed by moving the flag to task->atomic_flags. The first two are prepatory ones to help defining atomic_flags accessors and the third one is the actual fix" * 'for-3.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags sched: add macros to define bitops for task atomic flags sched: fix confusing PFA_NO_NEW_PRIVS constant
2014-09-28Merge tag 'fixes-for-linus' of ↵Linus Torvalds13-77/+139
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Here's our last set of fixes for 3.17. Most of these are for TI platforms, fixing some noisy Kconfig issues, runtime clock and power issues on several platforms and NAND timings on DRA7. There are also a couple of bug fixes for i.MX, one for QCOM and a small fix to avoid section mismatch noise on PXA. Diffstat looks large, partially due to some tables being updated and thus touching many lines. The qcom gsbi change also restructures clock management a bit and thus touches a bunch of lines. All in all, a bit more changes than we'd like at this point, but nothing stands out as risky either so it seems like the right thing to send it up now instead of holding it to the merge window" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: drivers/soc: qcom: do not disable the iface clock in probe ARM: imx: fix .is_enabled() of shared gate clock ARM: OMAP3: Fix I/O chain clock line assertion timed out error ARM: keystone: dts: fix bindings for pcie and usb clock nodes bus: omap_l3_noc: Fix connID for OMAP4 ARM: DT: imx53: fix lvds channel 1 port ARM: dts: cm-t54: fix serial console power supply. ARM: dts: dra7-evm: Fix NAND GPMC timings ARM: pxa: fix section mismatch warning for pxa_timer_nodt_init ARM: OMAP: Fix Kconfig warning for omap1
2014-09-28Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds2-3/+15
Pull MIPS fixes from Ralf Baechle: "The final round of fixes. One corner case in the math emulator and another one in the mcount function for ftrace" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: mcount: Adjust stack pointer for static trace in MIPS32 MIPS: Fix MFC1 & MFHC1 emulation for 64-bit MIPS systems
2014-09-28Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds7-48/+62
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "This has: - EFI revert to fix a boot regression - early_ioremap() fix for boot failure - KASLR fix for possible boot failures - EFI fix for corrupted string printing - remove a misleading EFI bootup 'failed!' error message Unfortunately it's all rather close to the merge window" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Truncate 64-bit values when calling 32-bit OutputString() x86/efi: Delete misleading efi_printk() error message Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" x86/kaslr: Avoid the setup_data area when picking location x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8
2014-09-27vfs: Don't exchange "short" filenames unconditionally.Mikhail Efremov1-9/+18
Only exchange source and destination filenames if flags contain RENAME_EXCHANGE. In case if executable file was running and replaced by other file /proc/PID/exe should still show correct file name, not the old name of the file by which it was replaced. The scenario when this bug manifests itself was like this: * ALT Linux uses rpm and start-stop-daemon; * during a package upgrade rpm creates a temporary file for an executable to rename it upon successful unpacking; * start-stop-daemon is run subsequently and it obtains the (nonexistant) temporary filename via /proc/PID/exe thus failing to identify the running process. Note that "long" filenames (> DNAiME_INLINE_LEN) are still exchanged without RENAME_EXCHANGE and this behaviour exists long enough (should be fixed too apparently). So this patch is just an interim workaround that restores behavior for "short" names as it was before changes introduced by commit da1ce0670c14 ("vfs: add cross-rename"). See https://lkml.org/lkml/2014/9/7/6 for details. AV: the comments about being more careful with ->d_name.hash than with ->d_name.name are from back in 2.3.40s; they became obsolete by 2.3.60s, when we started to unhash the target instead of swapping hash chain positions followed by d_delete() as we used to do when dcache was first introduced. Acked-by: Miklos Szeredi <mszeredi@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: da1ce0670c14 "vfs: add cross-rename" Signed-off-by: Mikhail Efremov <sem@altlinux.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27fold swapping ->d_name.hash into switch_names()Linus Torvalds1-2/+1
and do it along with ->d_name.len there Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27fold unlocking the children into dentry_unlock_parents_for_move()Al Viro1-5/+4
... renaming it into dentry_unlock_for_move() and making it more symmetric with dentry_lock_for_move(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27kill __d_materialise_dentry()Al Viro1-44/+10
it folds into __d_move() now Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27__d_materialise_dentry(): flip the order of argumentsAl Viro1-24/+20
... thus making it much closer to (now unreachable, BTW) IS_ROOT(dentry) case in __d_move(). A bit more and it'll fold in. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27__d_move(): fold manipulations with ->d_child/->d_subdirsAl Viro1-5/+3
list_del() + list_add() is a slightly pessimised list_move() list_del() + INIT_LIST_HEAD() is a slightly pessimised list_del_init() Interleaving those makes the resulting code even worse. And harder to follow... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27don't open-code d_rehash() in d_materialise_unique()Al Viro1-5/+1
... and get rid of duplicate BUG_ON() there Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27pull rehashing and unlocking the target dentry into __d_materialise_dentry()Al Viro1-7/+4
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27ufs: deal with nfsd/iget racesAl Viro2-1/+9
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27fuse: honour max_read and max_write in direct_io modeMiklos Szeredi4-7/+12
The third argument of fuse_get_user_pages() "nbytesp" refers to the number of bytes a caller asked to pack into fuse request. This value may be lesser than capacity of fuse request or iov_iter. So fuse_get_user_pages() must ensure that *nbytesp won't grow. Now, when helper iov_iter_get_pages() performs all hard work of extracting pages from iov_iter, it can be done by passing properly calculated "maxsize" to the helper. The other caller of iov_iter_get_pages() (dio_refill_pages()) doesn't need this capability, so pass LONG_MAX as the maxsize argument here. Fixes: c9c37e2e6378 ("fuse: switch to iov_iter_get_pages()") Reported-by: Werner Baumann <werner.baumann@onlinehome.de> Tested-by: Maxim Patlasov <mpatlasov@parallels.com> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27shmem: fix nlink for rename overwrite directoryMiklos Szeredi1-1/+3
If overwriting an empty directory with rename, then need to drop the extra nlink. Test prog: #include <stdio.h> #include <fcntl.h> #include <err.h> #include <sys/stat.h> int main(void) { const char *test_dir1 = "test-dir1"; const char *test_dir2 = "test-dir2"; int res; int fd; struct stat statbuf; res = mkdir(test_dir1, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir1); res = mkdir(test_dir2, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir2); fd = open(test_dir2, O_RDONLY); if (fd == -1) err(1, "open(\"%s\")", test_dir2); res = rename(test_dir1, test_dir2); if (res == -1) err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2); res = fstat(fd, &statbuf); if (res == -1) err(1, "fstat(%i)", fd); if (statbuf.st_nlink != 0) { fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink); return 1; } return 0; } Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-09-27rtlwifi: Fix problems with building an allyesconfigLarry Finger20-833/+223
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl8821ae: Move driver from staging to regular treeLarry Finger28-6/+26865
This driver was entered into staging a few cycles ago because there was not time to integrate the Realtek version into the support routines in the kernel. Now that there is an effort to converg the code base from Linux and the Realtek repo, it is time to move this driver. In addition, all the updates included in the 06/28/2014 version of the Realtek drivers are included here. With this change, it will be necessary to delete the staging driver. That will be handled in a separate patch. As it impacts the staging tree, such a patch is sent to a different destination. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl8188ee: Update driver to match Realtek release of 06282014Larry Finger25-4248/+4863
Not only does this patch update the driver to match the latest Realtek release, it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Finish modifying core routines for new driversLarry Finger9-133/+174
Addition of the new drivers and the update to a new version for the others lead to changes in all the core routines. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Update power-save routines for 062814 driverLarry Finger13-253/+162
Realtek released a new version of the drivers on 06/28/2014. This patch implements the new power-save code. These changes also force corresponding changes in the drivers. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify cam.{c,h} and efuse.{c,h} for new driversLarry Finger4-156/+156
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify base.{c,h} for new driversLarry Finger3-252/+463
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify core.c for new driversLarry Finger4-234/+602
Each of the routines in the rtlwifi common driver needs to be modified for the coming changes. This patch prepares core.c, but also touches other files. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl_pci: Start modification for new driversLarry Finger5-334/+605
Future patches will move the drivers for RTL8192EE and RTL8821AE from staging to the regular wireless tree. Here, the necessary features are added to the PCI driver. Other files are touched due to changes in the various data structs. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Remove extra workqueue for enter/leave power stateLarry Finger1-5/+2
When the rtlwifi family of drivers was converted to use a workqueue when entering or leaving power save mode (commits a269913c52, a5ffbe0a19, 41affd5286, b9116b9a2b, and 6539306b2c), the code began scheduling work from the callback routine of a different workqueue with a resulting increase in overhead. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: btcoexist: Fix Smatch warningLarry Finger3-3/+3
The capability for 802.11ac will soon be added to these drivers. Once that is done, a bitmask will be too large for the data storage. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ip6gre: add a rtnl link alias for ip6gretapNicolas Dichtel1-0/+1
With this alias, we don't need to load manually the module before adding an ip6gretap interface with iproute2. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-27ath9k: Fix offchannel queuingSujith Manoharan1-3/+3
Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame that is not in the current context doesn't seem right. Instead make sure that we don't add such frames to the UAPSD queue by using a local variable. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Use normal queues for offchannel framesSujith Manoharan1-2/+1
There is no reason why frames marked with IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using the UAPSD queue. Since mac80211 makes sure that RoC is done before pushing an offchannel frame to the driver, we can use the normal TX queues for transmission. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Fix queue managementSujith Manoharan1-7/+3
Since we use IEEE80211_HW_QUEUE_CONTROL now, the CAB/Offchannel queues are registered as the last two queues. There is no need to check and reassign the queues in the TX start()/done() routines. CAB frames will not reach the tx() callback since we set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING and pull the buffered frames during beacon transmission. We also don't have a special HW queue for handling off-channel frames. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rt2800: correct BBP1_TX_POWER_CTRL maskStanislaw Gruszka1-1/+1
Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27wil6210: ethtool opsVladimir Kondratiev6-12/+138
Provide ethtool support; with support for interrupt coalescing through get_coalesce/set_coalesce. Placeholders for begin/complete will be used by runtime PM to make sure target is powered up while performing ethtool operations Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27bcma: gpio: use ChipCommon GPIO IRQ on BCM47XX arch onlyRafał Miłecki1-2/+2
GPIOs can be also used on bcm53xx, however this arch requires different implementation of IRQ support. It uses different IRQ number (117) and different masks & acking. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtl818x_pci: add RSSI information for rtl8187SEandrea.merello1-5/+23
This patch makes the driver to report signal strength information to mac80211 for rtl8187se boards. It differs from my previous RFT patch: http://marc.info/?l=linux-wireless&m=140155388332534&w=2 because: - I have now a working rtl8187se card, so I could serve my RFT by myself. :) - CCK measurement code has changed a bit, but it does basically the same things. - OFDM measurement method is changed because the older method reported incorrect measures, at least for signals stronger than -40dBm). CCK measurement seems quite good. OFDM seems less accurate, but this is the same as the "reference" staging driver dose. I wanted not to change things just to make measures of _one_ (my) card a bit more close to what _I_ (in my setup) expected.. IMHO results are still good enough to justify reporting signal in dBm rather than in "unspecified" units, so this is what this patch actually does. Results of my tests with a working rtl8187se card connected with coaxes and various RF attenuators to my AP are: Input (approx) | CCK meas | OFDM meas -------------------------------------- -30dBm | -32dBm | -31dBm -40dBm | -40dBm | -41dBm -50dBm | -50dBm | -55dBm -60dBm | -59dBm | -63dBm -70dBm | -69dBm | -73dBm -80dBm | -79dBm | -83dBm Also some real-field tests has been done (no coax, packets in the air) for the CCK measure method, and they resulted in reasonable values. Thanks-to: Bernhard Schiffner <bernhard@schiffner-limbach.de> [ for real-field tests] Signed-off-by: andrea.merello <andrea.merello@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Fix p2p address managementSujith Manoharan2-0/+37
When multiple channel contexts are enabled, a p2p interface that is assigned to a context will have an address that is different from the device mac address, which is used by wpa_s as the p2p device ID. Certain frames like provision requests use the device address and these get dropped since ath9k_calculate_summary_state() iterates over only the active interfaces in a context and the device address is not used. Fix this by adding the device mac address to the bssid mask. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27bcma: print chip ID in a more user-friendly formRafał Miłecki1-2/+6
Some chip IDs are easier to read/understand when printed in a decimal form. For example on my bcm53xx arch router this patch replaces: Found chip with id 0xCF12, rev 0x00 and package 0x02 with a: Found chip with id 53010, rev 0x00 and package 0x02 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27mwifiex: ensure user_scan_in not NULL while setting scan channel gapAvinash Patil1-16/+17
Check for scan channel gap only when user_scan_in is not NULL. user_scan_in is NULL for internal scans and if we check scan channel gap at this place, it may result into crash. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Cache BSS informationSujith Manoharan3-7/+17
Using the BSS information stored in mac80211 directly is racy in certain conditions. For example, in a MCC setup, if the scheduler is switching channels when a local deauth is issued, calculation of the opmode/bssid etc. is incorrect. To avoid this, store the bss params in the driver and use it. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27net : optimize skb_release_data()Eric Dumazet1-21/+22
Cache skb_shinfo(skb) in a variable to avoid computing it multiple times. Reorganize the tests to remove one indentation level. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>