- 06 Feb, 2014 40 commits
-
-
Emmanuel Grumbach authored
commit 6960a059 upstream. We changed the timeout for the interrupt coealescing for calibration, but that wasn't effective since we changed that value back before loading the firmware. Since calibrations are notification from firmware and not Rx packets, this doesn't change anyway - the firmware will fire an interrupt straight away regardless of the interrupt coalescing value. Also, a HW issue has been discovered in 7000 devices series. The work around is to disable the new interrupt coalescing timeout feature - do this by setting bit 31 in CSR_INT_COALESCING. This has been fixed in 7265 which means that we can't rely on the device family and must have a hint in the iwl_cfg structure. Fixes: 99cd4714 ("iwlwifi: add 7000 series device configuration") Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Warren authored
(This is upstream 75fae117 "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and later can take the original patch.) Commit 384a48d7 "ALSA: hda: HDMI: Support codecs with fewer cvts than pins" dynamically enabled each pin widget's PIN_OUT only when the pin was actively in use. This was required on certain NVIDIA CODECs for correct operation. Specifically, if multiple pin widgets each had their mux input select the same audio converter widget and each pin widget had PIN_OUT enabled, then only one of the pin widgets would actually receive the audio, and often not the one the user wanted! However, this apparently broke some Intel systems, and commit 6169b673 "ALSA: hda - Always turn on pins for HDMI/DP" reverted the dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA CODECs. This change supports either dynamic or static handling of PIN_OUT, selected by a flag set up during CODEC initialization. This flag is enabled for all recent NVIDIA GPUs. Reported-by:
Uosis <uosisl@gmail.com> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Anssi Hannula authored
(This is a backport of *part* of upstream 611885bc "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" to stable 3.10 through 3.12. Later stable already contain all of the original patch.) Mainline commit 611885bc "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" introduces function patch_nvhdmi(). That function is edited by 75fae117 "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled". In order to backport the PIN_OUT patch, I am first back-porting just the addition of function patch_nvhdmi(), so that the conflicts applying the PIN_OUT patch are simplified. Ideally, one might backport all of 611885bc. However, that commit doesn't apply to stable kernels, since it relies on a chain of other patches which implement new features. Signed-off-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
Takashi Iwai <tiwai@suse.de> [swarren, extracted just a small part of the original patch] Signed-off-by:
-
Mihai Caraman authored
commit 70713fe3 upstream. Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss(). Signed-off-by:
Mihai Caraman <mihai.caraman@freescale.com> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Andreas Schwab authored
commit 48eaef05 upstream. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
-
Helge Deller authored
commit 57737c49 upstream. This commit: f8dae006: parisc: Ensure full cache coherency for kmap/kunmap caused negative caching side-effects, e.g. hanging processes with expect and too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems. This patch now partly reverts it and has been in production use on our debian buildd makeservers since a week without any major problems. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
-
Emmanuel Grumbach authored
commit 2d93aee1 upstream. Enabling the oscillator consumes slightly more power (100uA) but allows to make sure that we exit from L1 on time. Not doing so might lead to a PCIe specification violation since we might wake up from L1 at the wrong time. This issue has been identified on 3160 and 7260 only. On older NICs L1 off is not enabled, on newer NICs (7265), the issue is fixed. When the bug occurs the user sees that the NIC has disappeared from the PCI bridge, any access to the device returns 0xff. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=64541 and has been extensively discussed here: http://markmail.org/thread/mfmpzqt3r333n4bo Fixes: 99cd4714 ("iwlwifi: add 7000 series device configuration") Reported-and-tested-by:
wzyboy <wzyboy@wzyboy.org> Reviewed-by:
-
Nicolas Dichtel authored
[ No relevant upstream commit. ] This problem was fixed upstream by commit 1e9f3d6f ("ip6tnl: fix use after free of fb_tnl_dev"). The upstream patch depends on upstream commit 0bd87628 ("ip6tnl: add x-netns support"), which was not backported into 3.10 branch. First, explain the problem: when the ip6_tunnel module is unloaded, ip6_tunnel_cleanup() is called. rmmod ip6_tunnel => ip6_tunnel_cleanup() => rtnl_link_unregister() => __rtnl_kill_links() => for_each_netdev(net, dev) { if (dev->rtnl_link_ops == ops) ops->dellink(dev, &list_kill); } At this point, the FB device is deleted (and all ip6tnl tunnels). => unregister_pernet_device() => unregister_pernet_operations() => ops_exit_list() => ip6_tnl_exit_net() => ip6_tnl_destroy_tunnels() => t = rtnl_dereference(ip6n->tnls_wc[0]); unregister_netdevice_queue(t->dev, &list); We delete the FB device a second time here! The previous fix removes these lines, which fix this double free. But the patch introduces a memory leak when a netns is destroyed, because the FB device is never deleted. By adding an rtnl ops which delete all ip6tnl device excepting the FB device, we can keep this exlicit removal in ip6_tnl_destroy_tunnels(). CC: Steven Rostedt <rostedt@goodmis.org> CC: Willem de Bruijn <willemb@google.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Reported-by:
Steven Rostedt <srostedt@redhat.com> Tested-by: Steven Rostedt <srostedt@redhat.com> (and our entire MRG team) Tested-by:
"Luis Claudio R. Goncalves" <lgoncalv@redhat.com> Tested-by:
John Kacur <jkacur@redhat.com> Signed-off-by:
-
Nicolas Dichtel authored
[ No relevant upstream commit. ] This reverts commit 22c3ec55. This patch is not the right fix, it introduces a memory leak when a netns is destroyed (the FB device is never deleted). Signed-off-by:
-
Nicolas Dichtel authored
[ No relevant upstream commit. ] This problem was fixed upstream by commit 9434266f ("sit: fix use after free of fb_tunnel_dev"). The upstream patch depends on upstream commit 5e6700b3 ("sit: add support of x-netns"), which was not backported into 3.10 branch. First, explain the problem: when the sit module is unloaded, sit_cleanup() is called. rmmod sit => sit_cleanup() => rtnl_link_unregister() => __rtnl_kill_links() => for_each_netdev(net, dev) { if (dev->rtnl_link_ops == ops) ops->dellink(dev, &list_kill); } At this point, the FB device is deleted (and all sit tunnels). => unregister_pernet_device() => unregister_pernet_operations() => ops_exit_list() => sit_exit_net() => sit_destroy_tunnels() In this function, no tunnel is found. => unregister_netdevice_queue(sitn->fb_tunnel_dev, &list); We delete the FB device a second time here! Because we cannot simply remove the second deletion (sit_exit_net() must remove the FB device when a netns is deleted), we add an rtnl ops which delete all sit device excepting the FB device and thus we can keep the explicit deletion in sit_exit_net(). CC: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Willem de Bruijn <willemb@google.com> Reported-by:
-
Annie Li authored
[ Upstream commit cefe0078 ] This patch removes grant transfer releasing code from netfront, and uses gnttab_end_foreign_access to end grant access since gnttab_end_foreign_access_ref may fail when the grant entry is currently used for reading or writing. * clean up grant transfer code kept from old netfront(2.6.18) which grants pages for access/map and transfer. But grant transfer is deprecated in current netfront, so remove corresponding release code for transfer. * fix resource leak, release grant access (through gnttab_end_foreign_access) and skb for tx/rx path, use get_page to ensure page is released when grant access is completed successfully. Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches for them will be created separately. V6: Correct subject line and commit message. V5: Remove unecessary change in xennet_end_access. V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in single patch. V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill grant acess is ended. V2: Improve patch comments. Signed-off-by:
Annie Li <annie.li@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Holger Eitzenberger authored
[ Upstream commit a452ce34 ] I see a memory leak when using a transparent HTTP proxy using TPROXY together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable): unreferenced object 0xffff88008cba4a40 (size 1696): comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s) hex dump (first 32 bytes): 0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2..... 02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9 [<ffffffff81270185>] sk_prot_alloc+0x29/0xc5 [<ffffffff812702cf>] sk_clone_lock+0x14/0x283 [<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b [<ffffffff8129a893>] netlink_broadcast+0x14/0x16 [<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3 [<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d [<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0 [<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e [<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55 [<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725 [<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154 [<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514 [<ffffffff8127aa77>] process_backlog+0xee/0x1c5 [<ffffffff8127c949>] net_rx_action+0xa7/0x200 [<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157 But there are many more, resulting in the machine going OOM after some days. From looking at the TPROXY code, and with help from Florian, I see that the memory leak is introduced in tcp_v4_early_demux(): void tcp_v4_early_demux(struct sk_buff *skb) { /* ... */ iph = ip_hdr(skb); th = tcp_hdr(skb); if (th->doff < sizeof(struct tcphdr) / 4) return; sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif); if (sk) { skb->sk = sk; where the socket is assigned unconditionally to skb->sk, also bumping the refcnt on it. This is problematic, because in our case the skb has already a socket assigned in the TPROXY target. This then results in the leak I see. The very same issue seems to be with IPv6, but haven't tested. Reviewed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Holger Eitzenberger <holger@eitzenberger.org> Signed-off-by:
-
Oliver Hartkopp authored
[ Upstream commit a0065f26 ] The two commits 0115e8e3 (net: remove delay at device dismantle) and 748e2d93 (net: reinstate rtnl in call_netdevice_notifiers()) silently removed a NULL pointer check for in_dev since Linux 3.7. This patch re-introduces this check as it causes crashing the kernel when setting small mtu values on non-ip capable netdevices. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Duan Jiong authored
[ Upstream commit 11c21a30 ] commit a6222602("ip_tunnel: fix kernel panic with icmp_dest_unreach") clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from GSO segmentation layer. But commit 0e6fbc5b("ip_tunnels: extend iptunnel_xmit()") refactor codes, and it clear IPCB behind the dst_link_failure(). So clear IPCB in ip_tunnel_xmit() just like commti a6222602("ip_tunnel: fix kernel panic with icmp_dest_unreach"). Signed-off-by:
Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by:
-
Heiko Carstens authored
[ Upstream commit 3af57f78 ] The s390 bpf jit compiler emits the signed divide instructions "dr" and "d" for unsigned divisions. This can cause problems: the dividend will be zero extended to a 64 bit value and the divisor is the 32 bit signed value as specified A or X accumulator, even though A and X are supposed to be treated as unsigned values. The divide instrunctions will generate an exception if the result cannot be expressed with a 32 bit signed value. This is the case if e.g. the dividend is 0xffffffff and the divisor either 1 or also 0xffffffff (signed: -1). To avoid all these issues simply use unsigned divide instructions. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit aee636c4 ] At first Jakub Zawadzki noticed that some divisions by reciprocal_divide were not correct. (off by one in some cases) http://www.wireshark.org/~darkjames/reciprocal-buggy.c He could also show this with BPF: http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c The reciprocal divide in linux kernel is not generic enough, lets remove its use in BPF, as it is not worth the pain with current cpus. Signed-off-by:
Jakub Zawadzki <darkjames-ws@darkjames.pl> Cc: Mircea Gherzan <mgherzan@gmail.com> Cc: Daniel Borkmann <dxchgb@gmail.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Matt Evans <matt@ozlabs.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Christoph Paasch authored
[ Upstream commit 77f99ad1 ] Because the tcp-metrics is an RCU-list, it may be that two soft-interrupts are inside __tcp_get_metrics() for the same destination-IP at the same time. If this destination-IP is not yet part of the tcp-metrics, both soft-interrupts will end up in tcpm_new and create a new entry for this IP. So, we will have two tcp-metrics with the same destination-IP in the list. This patch checks twice __tcp_get_metrics(). First without holding the lock, then while holding the lock. The second one is there to confirm that the entry has not been added by another soft-irq while waiting for the spin-lock. Fixes: 51c5d0c4 (tcp: Maintain dynamic metrics in local cache.) Signed-off-by:
Christoph Paasch <christoph.paasch@uclouvain.be> Reviewed-by:
-
Gerald Schaefer authored
[ Upstream commit c196403b ] commit ae4b46e9 "net: rds: use this_cpu_* per-cpu helper" broke per-cpu handling for rds. chpfirst is the result of __this_cpu_read(), so it is an absolute pointer and not __percpu. Therefore, __this_cpu_write() should not operate on chpfirst, but rather on cache->percpu->first, just like __this_cpu_read() did before. Signed-off-byd Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Richard Weinberger authored
[ Upstream commit a926592f ] rhine_reset_task() misses to disable the tx scheduler upon reset, this can lead to a crash if work is still scheduled while we're resetting the tx queue. Fixes: [ 93.591707] BUG: unable to handle kernel NULL pointer dereference at 0000004c [ 93.595514] IP: [<c119d10d>] rhine_napipoll+0x491/0x6 Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Hannes Frederic Sowa authored
[ Upstream commit 95f4a45d ] Bob Falken reported that after 4G packets, multicast forwarding stopped working. This was because of a rule reference counter overflow which freed the rule as soon as the overflow happend. This patch solves this by adding the FIB_LOOKUP_NOREF flag to fib_rules_lookup calls. This is safe even from non-rcu locked sections as in this case the flag only implies not taking a reference to the rule, which we don't need at all. Rules only hold references to the namespace, which are guaranteed to be available during the call of the non-rcu protected function reg_vif_xmit because of the interface reference which itself holds a reference to the net namespace. Fixes: f0ad0860 ("ipv4: ipmr: support multiple tables") Fixes: d1db275d ("ipv6: ip6mr: support multiple tables") Reported-by:
Bob Falken <NetFestivalHaveFun@gmx.com> Cc: Patrick McHardy <kaber@trash.net> Cc: Thomas Graf <tgraf@suug.ch> Cc: Julian Anastasov <ja@ssi.bg> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
-
Christian Engelmayer authored
[ Upstream commit 267d29a6 ] Fix a memory leak in the ieee802154_add_iface() error handling path. Detected by Coverity: CID 710490. Signed-off-by:
Christian Engelmayer <cengelma@gmx.at> Signed-off-by:
-
Neal Cardwell authored
[ Based upon upstream commit 70315d22 ] Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and FIN_WAIT2 connections are represented by inet_timewait_sock (not just TIME_WAIT). Thus: (a) We need to iterate through the time_wait buckets if the user wants either TIME_WAIT or FIN_WAIT2. (Before fixing this, "ss -nemoi state fin-wait-2" would not return any sockets, even if there were some in FIN_WAIT2.) (b) We need to check tw_substate to see if the user wants to dump sockets in the particular substate (TIME_WAIT or FIN_WAIT2) that a given connection is in. (Before fixing this, "ss -nemoi state time-wait" would actually return sockets in state FIN_WAIT2.) An analogous fix is in v3.13: 70315d22 ("inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets") but that patch is quite different because 3.13 code is very different in this area due to the unification of TCP hash tables in 05dbc7b5 ("tcp/dccp: remove twchain") in v3.13-rc1. I tested that this applies cleanly between v3.3 and v3.12, and tested that it works in both 3.3 and 3.12. It does not apply cleanly to 3.2 and earlier (though it makes semantic sense), and semantically is not the right fix for 3.13 and beyond (as mentioned above). Signed-off-by:
Neal Cardwell <ncardwell@google.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by:
-
Michal Schmidt authored
[ Upstream commit 95e92fd4 ] bnx2x triggers warnings with CONFIG_DMA_API_DEBUG=y: WARNING: CPU: 0 PID: 2253 at lib/dma-debug.c:887 check_unmap+0xf8/0x920() bnx2x 0000:28:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x00000000da2b389e] [map size=1490 bytes] [unmap size=66 bytes] The reason is that bnx2x splits a TSO BD into two BDs (headers + data) using one DMA mapping for both, but it uses only the length of the first BD when unmapping. This patch fixes the bug by unmapping the whole length of the two BDs. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Reviewed-by:
Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by:
-
Takashi Iwai authored
commit b0ad4ff3 upstream. The DriveGuard chips on the new HP laptops are with a new PnP ID "HPQ6007". It should be compatible with older chips. Acked-by:
Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Kent Overstreet authored
commit ef71ec00 upstream. The code that handles overlapping extents that we've just read back in from disk was depending on the behaviour of the code that handles overlapping extents as we're inserting into a btree node in the case of an insert that forced an existing extent to be split: on insert, if we had to split we'd also insert a new extent to represent the top part of the old extent - and then that new extent would get written out. The code that read the extents back in thus not bother with splitting extents - if it saw an extent that ovelapped in the middle of an older extent, it would trim the old extent to only represent the bottom part, assuming that the original insert would've inserted a new extent to represent the top part. I still haven't figured out _how_ it can happen, but I'm now pretty convinced (and testing has confirmed) that there's some kind of an obscure corner case (probably involving extent merging, and multiple overwrites in different sets) that breaks this. The fix is to change the mergesort fixup code to split extents itself when required. Signed-off-by:
Kent Overstreet <kmo@daterainc.com> Signed-off-by:
-
Eric W. Biederman authored
commit 260a459d upstream. A bug was introduced with the is_mounted helper function in commit f7a99c5b Author: Al Viro <viro@zeniv.linux.org.uk> Date: Sat Jun 9 00:59:08 2012 -0400 get rid of ->mnt_longterm it's enough to set ->mnt_ns of internal vfsmounts to something distinct from all struct mnt_namespace out there; then we can just use the check for ->mnt_ns != NULL in the fast path of mntput_no_expire() Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> The intent was to test if the real_mount(vfsmount)->mnt_ns was NULL_OR_ERR but the code is actually testing real_mount(vfsmount) and always returning true. The result is d_absolute_path returning paths it should be hiding. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Theodore Ts'o authored
commit 09c455aa upstream. A missing cast means that when we are truncating a file which is less than 60 bytes, we don't clear the correct area of memory, and in fact we can end up truncating the next inode in the inode table, or worse yet, some other kernel data structure. Addresses-Coverity-Id: #751987 Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Tejun Heo authored
commit ecd75ad5 upstream. For some reason, some early WD drives spin up and down drives erratically when the link is put into slumber mode which can reduce the life expectancy of the device significantly. Unfortunately, we don't have full list of devices and given the nature of the issue it'd be better to err on the side of false positives than the other way around. Let's disable LPM on all WD devices which match one of the known problematic model prefixes and are SATA-I. As horkage list doesn't support matching SATA capabilities, this is implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is set for the known prefixes and sets the latter if the matched device is SATA-I. Note that this isn't optimal as this disables all LPM operations and partial link power state reportedly works fine on these; however, the way LPM is implemented in libata makes it difficult to precisely map libata LPM setting to specific link power state. Well, these devices are already fairly outdated. Let's just disable whole LPM for now. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-and-tested-by:
Nikos Barkas <levelwol@gmail.com> Reported-and-tested-by:
Ioannis Barkas <risc4all@yahoo.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=57211Signed-off-by:
-
Lior Amsalem authored
commit 9013d64e upstream. On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the re-plug events are not detected by the sata_mv driver. This patch fixes the issue by updating the PHY speed in the LP_PHY_CTL register (0x58) according to the SControl speed. Note that this fix is only applied if the compatible string "marvell,armada-370-sata" is found in the SATA DT node. Fixes: 9ae6f740 ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT") Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Nadav Haklai <nadavh@marvell.com> Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Simon Guinot authored
commit b1f5c73b upstream. The sata_mv driver supports the SATA IP found in several Marvell SoCs. As some new SATA registers have been introduced with the Armada 370/XP SoCs, a way to identify them is needed. This patch introduces a new compatible string for the SATA IP found in Armada 370/XP SoCs. Signed-off-by:
-
Peter Huewe authored
commit 747d35bd upstream. Depending on the implementation strcmp might return the difference between two strings not only -1,0,1 consequently if (strcmp (a,b) == -1) might lead to taking the wrong branch -> compare with < 0 instead, which in any case is more canonical. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Peter Huewe authored
commit 85c5e0d4 upstream. The 'get_burstcount' function can in some circumstances 'return -EBUSY' which in tpm_stm_i2c_send is stored in an 'u32 burstcnt' thus converting the signed value into an unsigned value, resulting in 'burstcnt' being huge. Changing the type to u32 only does not solve the problem as the signed value is converted to an unsigned in I2C_WRITE_DATA, resulting in the same effect. Thus -> Change type of burstcnt to u32 (the return type of get_burstcount) -> Add a check for the return value of 'get_burstcount' and propagate a potential error. This makes also sense in the 'I2C_READ_DATA' case, where the there is no signed/unsigned conversion. found by coverity Signed-off-by:
-
Adrien Vergé authored
commit e7729a41 upstream. Similarly to other Apple products, MBA 1,1 needs a specific quirk. Pin 0x18 must be set to VREF_50 to have sound output. This was no longer done since commit 1a97b7f2, resulting in a mute built-in speaker. This patch corrects the regression by creating a fixup for the MBA 1,1. Fixes: 1a97b7f2 ("ALSA: hda/realtek - Remove the last static quirks for ALC882") Tested-by:
Adrien Vergé <adrienverge@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 80ab8eae upstream. The PCI devices with DMA masks smaller than 32bit should enable CONFIG_ZONE_DMA. Since the recent change of page allocator, page allocations via dma_alloc_coherent() with the limited DMA mask bits may fail more frequently, ended up with no available buffers, when CONFIG_ZONE_DMA isn't enabled. With CONFIG_ZONE_DMA, the system has much more chance to obtain such pages. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221Signed-off-by:
-
Takashi Iwai authored
commit 43a8e50a upstream. AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling the loopback volume/mute, but the generic parser didn't check it. This ended up with the duplicated controls for the same effect. This patch adds the check of the duplication for avoiding it. After this fix, there will be only one control although it affects both paths; this remaining issue should be fixed later in a different patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621Signed-off-by:
-
Takashi Iwai authored
commit 770bd4bf upstream. The lack of comma leads to the wrong channel for an SPDIF channel. Unfortunately this wasn't caught by compiler because it's still a valid expression. Reported-by:
Alexander Aristov <aristov.alexander@gmail.com> Signed-off-by:
-
Charles Keepax authored
commit 34354792 upstream. Latest evaluation of the the device has given some patch file additions for improved performance. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit e20970ad upstream. The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10, so 0x2. This patch fixes it. Reported-by:
Magnus Reftel <magnus.reftel@lockless.no> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 74142ffc upstream. The regmap used by max77686 MFD driver was not freed with regmap_exit() on driver exit. This lead to leak of resources. Replace regmap_init_i2c() call in driver probe with initialization of managed register map so the regmap will be properly freed by the device management code. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dongsheng Yang authored
commit ad85ace0 upstream. Currently, if we use perf kvm --guestkallsyms --guestmodules report, we can not get the perf information from perf data file. All sample are shown as unknown. Reproducing steps: # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 samples) ] # perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules report |grep % 100.00% [guest/6471] [unknown] [g] 0xffffffff8164f330 This bug was introduced by 207b5792 (perf kvm: Fix regression with guest machine creation). In original code, it uses perf_session__find_machine(), it means we deliver symbol to machine which has the same pid, if no machine found, deliver it to *default* guest. But if we use perf_session__findnew_machine() here, if no machine was found, new machine with pid will be built and added. Then the default guest which with pid == 0 will never get a symbol. And because the new machine initialized here has no kernel map created, the symbol delivered to it will be marked as "unknown". This patch here is to revert commit 207b5792 and fix the SEGFAULT bug in another way. Verification steps: # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 samples) ] # ./perf kvm --guestkallsyms /home/kallsyms --guestmodules /home/modules report |grep % 22.64% :6471 [guest.kernel.kallsyms] [g] update_rq_clock.part.70 19.99% :6471 [guest.kernel.kallsyms] [g] d_free 18.46% :6471 [guest.kernel.kallsyms] [g] bio_phys_segments 16.25% :6471 [guest.kernel.kallsyms] [g] dequeue_task 12.78% :6471 [guest.kernel.kallsyms] [g] __switch_to 7.91% :6471 [guest.kernel.kallsyms] [g] scheduler_tick 1.75% :6471 [guest.kernel.kallsyms] [g] native_apic_mem_write 0.21% :6471 [guest.kernel.kallsyms] [g] apic_timer_interrupt Signed-off-by:
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Acked-by:
David Ahern <dsahern@gmail.com> Cc: David Ahern <dsahern@gmail.com> Link: http://lkml.kernel.org/r/1387564907-3045-1-git-send-email-yangds.fnst@cn.fujitsu.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
