summaryrefslogtreecommitdiffstats
path: root/drivers/power/ds2782_battery.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2014-10-04init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menuJosh Triplett1-0/+1
commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test") added the HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in the middle of the options for the EXPERT menu. However, HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops placing items in the EXPERT menu, and displays the remaining several EXPERT items (starting with EPOLL) directly in the General Setup menu. Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the subsequent items display as part of the EXPERT menu again; the EMBEDDED menu now appears as the next top-level item in the General Setup menu, which makes General Setup much shorter and more usable. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: stable <stable@vger.kernel.org>
2014-10-04init/Kconfig: Hide printk log config if CONFIG_PRINTK=nJosh Triplett1-0/+2
The buffers sized by CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't ask about their size at all. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: stable <stable@vger.kernel.org>
2014-10-03[SCSI] uas: disable use of blk-mq I/O pathChristoph Hellwig1-0/+7
The uas driver uses the block layer tag for USB3 stream IDs. With blk-mq we can get larger tag numbers that the queue depth, which breaks this assumption. A fix is under way for 3.18, but sits on top of large changes so can't easily be backported. Set the disable_blk_mq path so that a uas device can't easily crash the system when using blk-mq for SCSI. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2014-10-03i2c: qup: Fix order of runtime pm initializationAndy Gross1-4/+8
The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by: Andy Gross <agross@codeaurora.org> Reviewed-by: Felipe Balbi <balbi@ti.com> Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2014-10-03i2c: rk3x: fix 0 length write transfersAlexandru M Stan1-1/+1
i2cdetect -q was broken (everything was a false positive, and no transfers were actually being sent over i2c). The way it works is by sending a 0 length write request and checking for NACK. This patch fixes the 0 length writes and actually sends them. Reported-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Tested-by: Max Schwarz <max.schwarz@online.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2014-10-03mm: page_alloc: fix zone allocation fairness on UPJohannes Weiner1-4/+3
The zone allocation batches can easily underflow due to higher-order allocations or spills to remote nodes. On SMP that's fine, because underflows are expected from concurrency and dealt with by returning 0. But on UP, zone_page_state will just return a wrapped unsigned long, which will get past the <= 0 check and then consider the zone eligible until its watermarks are hit. Commit 3a025760fc15 ("mm: page_alloc: spill to remote nodes before waking kswapd") already made the counter-resetting use atomic_long_read() to accomodate underflows from remote spills, but it didn't go all the way with it. Make it clear that these batches are expected to go negative regardless of concurrency, and use atomic_long_read() everywhere. Fixes: 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy") Reported-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Leon Romanovsky <leon@leon.nu> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-03perf: fix perf bug in fork()Peter Zijlstra2-3/+6
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-03MAINTAINERS: change git URL for mpc5xxx treeAnatolij Gustschin1-1/+1
The repository for mpc5xxx has been moved, update git URL to new location. Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-03mm: memcontrol: do not iterate uninitialized memcgsJohannes Weiner1-5/+31
The cgroup iterators yield css objects that have not yet gone through css_online(), but they are not complete memcgs at this point and so the memcg iterators should not return them. Commit d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized") set out to implement exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does not meet the ordering requirements for memcg, and so the iterator may skip over initialized groups, or return partially initialized memcgs. The cgroup core can not reasonably provide a clear answer on whether the object around the css has been fully initialized, as that depends on controller-specific locking and lifetime rules. Thus, introduce a memcg-specific flag that is set after the memcg has been initialized in css_online(), and read before mem_cgroup_iter() callers access the memcg members. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Acked-by: Michal Hocko <mhocko@suse.cz> Cc: Hugh Dickins <hughd@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-03ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handleralex chen1-0/+4
In dlm_assert_master_handler, the mle is get in dlm_find_mle, should be put when goto kill, otherwise, this mle will never be released. Signed-off-by: Alex Chen <alex.chen@huawei.com> Reviewed-by: Joseph Qi <joseph.qi@huawei.com> Reviewed-by: joyce.xue <xuejiufei@huawei.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-02ring-buffer: Fix infinite spin in reading bufferSteven Rostedt (Red Hat)1-1/+1
Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page" fixed one bug but in the process caused another one. The reset is to update the header page, but that fix also changed the way the cached reads were updated. The cache reads are used to test if an iterator needs to be updated or not. A ring buffer iterator, when created, disables writes to the ring buffer but does not stop other readers or consuming reads from happening. Although all readers are synchronized via a lock, they are only synchronized when in the ring buffer functions. Those functions may be called by any number of readers. The iterator continues down when its not interrupted by a consuming reader. If a consuming read occurs, the iterator starts from the beginning of the buffer. The way the iterator sees that a consuming read has happened since its last read is by checking the reader "cache". The cache holds the last counts of the read and the reader page itself. Commit 651e22f2701b changed what was saved by the cache_read when the rb_iter_reset() occurred, making the iterator never match the cache. Then if the iterator calls rb_iter_reset(), it will go into an infinite loop by checking if the cache doesn't match, doing the reset and retrying, just to see that the cache still doesn't match! Which should never happen as the reset is suppose to set the cache to the current value and there's locks that keep a consuming reader from having access to the data. Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-10-02CIFS: Fix readpages retrying on reconnectsPavel Shilovsky1-7/+1
If we got a reconnect error from async readv we re-add pages back to page_list and continue loop. That is wrong because these pages have been already added to the pagecache but page_list has pages that have not been added to the pagecache yet. This ends up with a general protection fault in put_pages after readpages. Fix it by not retrying the read of these pages and falling back to readpage instead. Fixes debian bug 762306 Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com> Tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
2014-10-02Fix problem recognizing symlinksSteve French2-1/+3
Changeset eb85d94bd introduced a problem where if a cifs open fails during query info of a file we will still try to close the file (happens with certain types of reparse points) even though the file handle is not valid. In addition for SMB2/SMB3 we were not mapping the return code returned by Windows when trying to open a file (like a Windows NFS symlink) which is a reparse point. Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Pavel Shilovsky <pshilovsky@samba.org> CC: stable <stable@vger.kernel.org> #v3.13+
2014-10-02mm: numa: Do not mark PTEs pte_numa when splitting huge pagesMel Gorman1-2/+5
This patch reverts 1ba6e0b50b ("mm: numa: split_huge_page: transfer the NUMA type from the pmd to the pte"). If a huge page is being split due a protection change and the tail will be in a PROT_NONE vma then NUMA hinting PTEs are temporarily created in the protected VMA. VM_RW|VM_PROTNONE |-----------------| ^ split here In the specific case above, it should get fixed up by change_pte_range() but there is a window of opportunity for weirdness to happen. Similarly, if a huge page is shrunk and split during a protection update but before pmd_numa is cleared then a pte_numa can be left behind. Instead of adding complexity trying to deal with the case, this patch will not mark PTEs NUMA when splitting a huge page. NUMA hinting faults will not be triggered which is marginal in comparison to the complexity in dealing with the corner cases during THP split. Cc: stable@vger.kernel.org Signed-off-by: Mel Gorman <mgorman@suse.de> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-02mm: migrate: Close race between migration completion and mprotectMel Gorman1-1/+4
A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Cc: stable@vger.kernel.org Signed-off-by: Mel Gorman <mgorman@suse.de> Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-02md/raid5: disable 'DISCARD' by default due to safety concerns.NeilBrown1-1/+17
It has come to my attention (thanks Martin) that 'discard_zeroes_data' is only a hint. Some devices in some cases don't do what it says on the label. The use of DISCARD in RAID5 depends on reads from discarded regions being predictably zero. If a write to a previously discarded region performs a read-modify-write cycle it assumes that the parity block was consistent with the data blocks. If all were zero, this would be the case. If some are and some aren't this would not be the case. This could lead to data corruption after a device failure when data needs to be reconstructed from the parity. As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y As this is a data-safety issue, I believe this patch is suitable for -stable. DISCARD support for RAID456 was added in 3.7 Cc: Shaohua Li <shli@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Heinz Mauelshagen <heinzm@redhat.com> Cc: stable@vger.kernel.org (3.7+) Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Mike Snitzer <snitzer@redhat.com> Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637 Signed-off-by: NeilBrown <neilb@suse.de>
2014-10-02drm/nouveau: make sure display hardware is reinitialised on runtime resumeBen Skeggs3-53/+26
Linus commit 05c63c2ff23a80b654d6c088ac3ba21628db0173 modified the runtime suspend/resume paths to skip over display-related tasks to avoid locking issues on resume. Unfortunately, this resulted in the display hardware being left in a partially initialised state, preventing subsequent modesets from completing. This commit unifies the (many) suspend/resume paths, bringing back display (and fbcon) handling in the runtime paths. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nouveau: punt fbcon resume out to a workqueueBen Skeggs2-6/+18
Preparation for some runtime pm fixes. Currently we skip over fbcon suspend/resume in the runtime path, which causes issues on resume if fbcon tries to write to the framebuffer before the BAR subdev has been resumed to restore the BAR1 VM setup. As we might be woken up via a sysfs connector, we are unable to call fb_set_suspend() in the resume path as it could make its way down to a modeset and cause all sorts of locking hilarity. To solve this, we'll just delay the fbcon resume to a workqueue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nouveau: fix regression on original nv50 boardBen Skeggs1-1/+6
Xorg (and any non-DRM client really) doesn't have permission to directly touch VRAM on nv50 and up, which the fence code prior to g84 depends on. It's less invasive to temporarily grant it premission to do so, as it previously did, than it is to rework fencenv50 to use the VM. That will come later on. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nv50/disp: fix dpms regression on certain boardsBen Skeggs1-1/+2
Reported in fdo#82527 comment #2. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02bna: Update Maintainer EmailRasesh Mody1-1/+1
Update the maintainer email for BNA driver. Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8152: disable power cut for RTL8153hayeswang1-1/+1
The firmware would be clear when the power cut is enabled for RTL8153. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01r8152: remove clearing bphayeswang1-27/+1
The xxx_clear_bp() is used to halt the firmware. It only necessary for updating the new firmware. Besides, depend on the version of the current firmware, it may have problem to halt the firmware directly. Finally, halt the firmware would let the firmware code useless, and the bugs which are fixed by the firmware would occur. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01bnx2: Correctly receive full sized 802.1ad fragmesVlad Yasevich1-2/+3
This driver, similar to tg3, has a check that will cause full sized 802.1ad frames to be dropped. The frame will be larger then the standard mtu due to the presense of vlan header that has not been stripped. The driver should not drop this frame and should process it just like it does for 802.1q. CC: Sony Chacko <sony.chacko@qlogic.com> CC: Dept-HSGLinuxNICDev@qlogic.com Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01tg3: Allow for recieve of full-size 8021AD framesVlad Yasevich1-1/+2
When receiving a vlan-tagged frame that still contains a vlan header, the length of the packet will be greater then MTU+ETH_HLEN since it will account of the extra vlan header. TG3 checks this for the case for 802.1Q, but not for 802.1ad. As a result, full sized 802.1ad frames get dropped by the card. Add a check for 802.1ad protocol when receving full sized frames. Suggested-by: Prashant Sreedharan <prashant@broadcom.com> CC: Prashant Sreedharan <prashant@broadcom.com> CC: Michael Chan <mchan@broadcom.com> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-01parisc: Fix serial console for machines with serial port on superio chipHelge Deller1-1/+2
Fix the serial console on machines where the serial port is located on the SuperIO chip. Signed-off-by: Helge Deller <deller@gmx.de> Cc: Peter Hurley <peter@hurleysoftware.com>
2014-10-01[SCSI] cxgb4i: avoid holding mutex in interrupt contextAnish Bhatt3-7/+55
cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu protected list while finding netdev. This is observed as a scheduling in atomic oops when running over ipv6. Fixes: fc8d0590d914 ("libcxgbi: Add ipv6 api to driver") Fixes: 759a0cc5a3e1 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api") Signed-off-by: Anish Bhatt <anish@chelsio.com> Signed-off-by: Karen Xie <kxie@chelsio.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2014-09-30r8152: fix setting RTL8152_UNPLUGhayeswang1-1/+5
The flag of RTL8152_UNPLUG should only be set when the device is unplugged, not each time the rtl8152_disconnect() is called. Otherwise, the device wouldn't be stopped normally. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30netxen: Fix bug in Tx completion path.Manish Chopra1-2/+2
o Driver is not updating sw_consumer while processing Tx completion when interface is going down. Due to this interface down path gets stuck forever waiting for NAPI to complete. Signed-off-by: Manish Chopra <manish.chopra@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30netxen: Fix BUG "sleeping function called from invalid context"Manish Chopra2-2/+2
o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock). Acquire this lock for only releasing TX buffers instead of taking it for whole down path. Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30nfsd4: fix corruption of NFSv4 read dataJ. Bruce Fields1-1/+2
The calculation of page_ptr here is wrong in the case the read doesn't start at an offset that is a multiple of a page. The result is that nfs4svc_encode_compoundres sets rq_next_page to a value one too small, and then the loop in svc_free_res_pages may incorrectly fail to clear a page pointer in rq_respages[]. Pages left in rq_respages[] are available for the next rpc request to use, so xdr data may be written to that page, which may hold data still waiting to be transmitted to the client or data in the page cache. The observed result was silent data corruption seen on an NFSv4 client. We tag this as "fixing" 05638dc73af2 because that commit exposed this bug, though the incorrect calculation predates it. Particular thanks to Andrea Arcangeli and David Gilbert for analysis and testing. Fixes: 05638dc73af2 "nfsd4: simplify server xdr->next_page use" Cc: stable@vger.kernel.org Reported-by: Andrea Arcangeli <aarcange@redhat.com> Tested-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2014-09-30cpufreq: update 'cpufreq_suspended' after stopping governorsViresh Kumar1-3/+4
Commit 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate") introduced a bug where the governors wouldn't be stopped anymore for ->target{_index}() drivers during suspend. This happens because 'cpufreq_suspended' is updated before stopping the governors during suspend and due to this __cpufreq_governor() would return early due to this check: /* Don't start any governor operations if we are entering suspend */ if (cpufreq_suspended) return 0; Fixes: 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate") Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 8e30444e1530 "cpufreq: fix cpufreq suspend/resume for intel_pstate" Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-30ipv6: remove rt6i_genidHannes Frederic Sowa6-26/+33
Eric Dumazet noticed that all no-nonexthop or no-gateway routes which are already marked DST_HOST (e.g. input routes routes) will always be invalidated during sk_dst_check. Thus per-socket dst caching absolutely had no effect and early demuxing had no effect. Thus this patch removes rt6i_genid: fn_sernum already gets modified during add operations, so we only must ensure we mutate fn_sernum during ipv6 address remove operations. This is a fairly cost extensive operations, but address removal should not happen that often. Also our mtu update functions do the same and we heard no complains so far. xfrm policy changes also cause a call into fib6_flush_trees. Also plug a hole in rt6_info (no cacheline changes). I verified via tracing that this change has effect. Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: YOSHIFUJI Hideaki <hideaki@yoshifuji.org> Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: Martin Lau <kafai@fb.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset"Jon Medhurst2-8/+13
When compiling kprobes-test-arm.c the following error has been observed /tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168) This is caused by the compiler spilling it's literal pool too far away from the site which is trying to reference it with a PC relative load. This arises because the compiler is underestimating the size of the inline assembler code present, which apparently it approximates as 4 bytes per line or instruction. We fix this problem by moving the operations which generate more than 4 bytes out of the text section. Specifically, moving the .ascii directives to the .rodata section. Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-09-30ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERSNathan Lynch1-0/+2
Joachim Eastwood reports that commit fbfb872f5f41 "ARM: 8148/1: flush TLS and thumbee register state during exec" causes a boot-time crash on a Cortex-M4 nommu system: Freeing unused kernel memory: 68K (281e5000 - 281f6000) Unhandled exception: IPSR = 00000005 LR = fffffff1 CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 task: 29834000 ti: 29832000 task.ti: 29832000 PC is at flush_thread+0x2e/0x40 LR is at flush_thread+0x21/0x40 pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b sp : 29833d60 ip : 00000000 fp : 00000001 r10: 00003cf8 r9 : 29b1f000 r8 : 00000000 r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000 r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0 xPSR: 4100000b CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc) [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c) The problem is that set_tls is attempting to clear the TLS location in the kernel-user helper page, which isn't set up on V7M. Fix this by guarding the write to the kuser helper page with a CONFIG_KUSER_HELPERS ifdef. Fixes: fbfb872f5f41 ARM: 8148/1: flush TLS and thumbee register state during exec Reported-by: Joachim Eastwood <manabian@gmail.com> Tested-by: Joachim Eastwood <manabian@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-09-30ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage ↵Krzysztof Kozlowski1-0/+1
on ARMv6 This fixes build breakage of platsmp.c if ARMv6 was chosen for compile time options (e.g. by building allmodconfig): $ make allmodconfig $ make CC arch/arm/mach-exynos/platsmp.o /tmp/ccdQM0Eg.s: Assembler messages: /tmp/ccdQM0Eg.s:432: Error: selected processor does not support ARM mode `isb ' /tmp/ccdQM0Eg.s:437: Error: selected processor does not support ARM mode `isb ' /tmp/ccdQM0Eg.s:438: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-exynos/platsmp.o] Error 1 The error was introduced in commit "ARM: EXYNOS: Move code from hotplug.c to platsmp.c". Previously code using v7_exit_coherency_flush() macro was built with '-march=armv7-a' flag but this flag dissapeared during the movement. Fix this by annotating the v7_exit_coherency_flush() asm code with armv7-a architecture. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: Mark Brown <broonie@kernel.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-09-30ASoC: ssm2602: do not hardcode type to SSM2602Stefan Kristiansson1-1/+1
The correct type (SSM2602/SSM2603/SSM2604) is passed down from the ssm2602_spi_probe()/ssm2602_spi_probe() functions, so use that instead of hardcoding it to SSM2602 in ssm2602_probe(). Fixes: c924dc68f737 ("ASoC: ssm2602: Split SPI and I2C code into different modules") Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Cc: stable@vger.kernel.org
2014-09-30hyperv: Fix a bug in netvsc_start_xmit()KY Srinivasan1-1/+2
After the packet is successfully sent, we should not touch the skb as it may have been freed. This patch is based on the work done by Long Li <longli@microsoft.com>. In this version of the patch I have fixed issues pointed out by David. David, please queue this up for stable. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Tested-by: Long Li <longli@microsoft.com> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-30ACPI / i915: Update the condition to ignore firmware backlight change requestAaron Lu1-5/+11
Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-29net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selectedKweh, Hock Leong1-2/+9
When the CONFIG_HAVE_CLK is selected for the system, the stmmac_pci_probe will fail with dmesg: [ 2.167225] stmmaceth 0000:00:14.6: enabling device (0000 -> 0002) [ 2.178267] stmmaceth 0000:00:14.6: enabling bus mastering [ 2.178436] stmmaceth 0000:00:14.6: irq 24 for MSI/MSI-X [ 2.178703] stmmaceth 0000:00:14.6: stmmac_dvr_probe: warning: cannot get CSR clock [ 2.186503] stmmac_pci_probe: main driver probe failed [ 2.194003] stmmaceth 0000:00:14.6: disabling bus mastering [ 2.196473] stmmaceth: probe of 0000:00:14.6 failed with error -2 This patch fix the issue by breaking the dependency to devm_clk_get() as the CSR clock can be obtained at priv->plat->clk_csr from pci driver. Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29ematch: Fix matching of inverted containers.Ignacy Gawędzki1-2/+4
Negated expressions and sub-expressions need to have their flags checked for TCF_EM_INVERT and their result negated accordingly. Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29gro: fix aggregation for skb using frag_listEric Dumazet1-0/+3
In commit 8a29111c7ca6 ("net: gro: allow to build full sized skb") I added a regression for linear skb that traditionally force GRO to use the frag_list fallback. Erez Shitrit found that at most two segments were aggregated and the "if (skb_gro_len(p) != pinfo->gso_size)" test was failing. This is because pinfo at this spot still points to the last skb in the chain, instead of the first one, where we find the correct gso_size information. Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb") Reported-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-29drm/i915: Flush the PTEs after updating them before suspendChris Wilson1-1/+13
As we use WC updates of the PTE, we are responsible for notifying the hardware when to flush its TLBs. Do so after we zap all the PTEs before suspend (and the BIOS tries to read our GTT). Fixes a regression from commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend that survived and continue to cause harm even after commit e568af1c626031925465a5caaab7cca1303d55c7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 26 20:08:20 2014 +0100 drm/i915: Undo gtt scratch pte unmapping again v2: Trivial rebase. v3: Fixes requires pointer dances. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 Tested-by: ming.yao@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-29cpufreq: integrator: fix integrator_cpufreq_remove return typeArnd Bergmann1-2/+2
When building this driver as a module, we get a helpful warning about the return type: drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type .remove = __exit_p(integrator_cpufreq_remove), If the remove callback returns void, the caller gets an undefined value as it expects an integer to be returned. This fixes the problem by passing down the value from cpufreq_unregister_driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-29cpufreq: pcc-cpufreq: Fix wait_event() under spinlockRafael J. Wysocki1-1/+1
Fix the following bug introduced by commit 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) that forgot to move the spin_lock() in pcc_cpufreq_target() past cpufreq_freq_transition_begin() which calls wait_event(): BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] [ 51.025044] CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7 Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00 Call Trace: [<ffffffff81589dbd>] dump_stack+0x4d/0x90 [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180 [<ffffffff8108e298>] __might_sleep+0x48/0xd0 [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0 [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0 [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170 [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0 [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0 [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720 [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0 [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210 [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0 [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110 [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10 [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0 [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0 [<ffffffff811a731d>] ? __vunmap+0x9d/0x100 [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0 [<ffffffff810edfa6>] load_module+0x686/0x710 [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0 [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0 [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com> Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-29Revert "[media] media: em28xx - remove reset_resume interface"Mauro Carvalho Chehab1-0/+1
The reset_resume call is needed, otherwise it will break resume on some conditions, depending on the usb ehci/xhci controller. This reverts commit b89193e0b06f44f48e3bf897a5b5cb4a7aff3359. Reported-by: Johannes Stezenbach <js@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2014-09-28Linux 3.17-rc7v3.17-rc7Linus Torvalds1-1/+1
2014-09-28neigh: check error pointer instead of NULL for ipv4_neigh_lookup()WANG Cong1-1/+1
Fixes: commit f187bc6efb7250afee0e2009b6106 ("ipv4: No need to set generic neighbour pointer") Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-09-28ip6_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-28ip6_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>