summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-12-22befs: remove trailing whitespacesLuis de Bethencourt
Removing all trailing whitespaces in befs. I was skeptic about tainting the history with this, but whitespace changes can be ignored by using 'git blame -w' and 'git log -w'. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: remove signatures from commentsLuis de Bethencourt
No idea why some comments have signatures. These predate git. Removing them since they add noise and no information. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix style issues in header filesLuis de Bethencourt
Fixing checkpatch.pl issues in befs header files: WARNING: Missing a blank line after declarations + befs_inode_addr iaddr; + iaddr.allocation_group = blockno >> BEFS_SB(sb)->ag_shift; WARNING: space prohibited between function name and open parenthesis '(' + return BEFS_SB(sb)->block_size / sizeof (befs_disk_inode_addr); ERROR: "foo * bar" should be "foo *bar" + const char *key, befs_off_t * value); ERROR: Macros with complex values should be enclosed in parentheses +#define PACKED __attribute__ ((__packed__)) Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix style issues in linuxvfs.cLuis de Bethencourt
Fix the following type of checkpatch.pl issues: WARNING: line over 80 characters +static struct dentry *befs_lookup(struct inode *, struct dentry *, unsigned int); ERROR: code indent should use tabs where possible + if (!bi)$ WARNING: please, no spaces at the start of a line + if (!bi)$ WARNING: labels should not be indented + unacquire_bh: WARNING: space prohibited between function name and open parenthesis '(' + sizeof (struct befs_inode_info), WARNING: braces {} are not necessary for single statement blocks + if (!*out) { + return -ENOMEM; + } WARNING: Block comments use a trailing */ on a separate line + * in special cases */ WARNING: Missing a blank line after declarations + int token; + if (!*p) ERROR: do not use assignment in if condition + if (!(bh = sb_bread(sb, sb_block))) { ERROR: space prohibited after that open parenthesis '(' + if( befs_sb->num_blocks > ~((sector_t)0) ) { ERROR: space prohibited before that close parenthesis ')' + if( befs_sb->num_blocks > ~((sector_t)0) ) { ERROR: space required before the open parenthesis '(' + if( befs_sb->num_blocks > ~((sector_t)0) ) { Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix typos in linuxvfs.cLuis de Bethencourt
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix style issues in io.cLuis de Bethencourt
Fixing the two following checkpatch.pl issues: ERROR: trailing whitespace + * Based on portions of file.c and inode.c $ WARNING: labels should not be indented + error: Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix style issues in inode.cLuis de Bethencourt
Fixing the following checkpatch.pl errors and warning: ERROR: trailing whitespace + * $ WARNING: Block comments use * on subsequent lines +/* + Validates the correctness of the befs inode ERROR: "foo * bar" should be "foo *bar" +befs_check_inode(struct super_block *sb, befs_inode * raw_inode, Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-22befs: fix style issues in debug.cLuis de Bethencourt
Fix all checkpatch.pl errors and warnings in debug.c: ERROR: trailing whitespace + * $ WARNING: Missing a blank line after declarations + va_list args; + va_start(args, fmt); ERROR: "foo * bar" should be "foo *bar" +befs_dump_inode(const struct super_block *sb, befs_inode * inode) ERROR: "foo * bar" should be "foo *bar" +befs_dump_super_block(const struct super_block *sb, befs_super_block * sup) ERROR: "foo * bar" should be "foo *bar" +befs_dump_small_data(const struct super_block *sb, befs_small_data * sd) WARNING: line over 80 characters +befs_dump_index_entry(const struct super_block *sb, befs_disk_btree_super * super) ERROR: "foo * bar" should be "foo *bar" +befs_dump_index_entry(const struct super_block *sb, befs_disk_btree_super * super) ERROR: "foo * bar" should be "foo *bar" +befs_dump_index_node(const struct super_block *sb, befs_btree_nodehead * node) Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
2016-12-21CREDITS: Remove outdated address informationGertjan van Wingerde
This address hasn't been accurate for several years now. Simply remove it. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-21net: fddi: skfp: use %p format specifier for addresses rather than %xColin Ian King
Trivial fix: Addresses should be printed using the %p format specifier rather than using %x. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-21tcp: add a missing barrier in tcp_tasklet_func()Eric Dumazet
Madalin reported crashes happening in tcp_tasklet_func() on powerpc64 Before TSQ_QUEUED bit is cleared, we must ensure the changes done by list_del(&tp->tsq_node); are committed to memory, otherwise corruption might happen, as an other cpu could catch TSQ_QUEUED clearance too soon. We can notice that old kernels were immune to this bug, because TSQ_QUEUED was cleared after a bh_lock_sock(sk)/bh_unlock_sock(sk) section, but they could have missed a kick to write additional bytes, when NIC interrupts for a given flow are spread to multiple cpus. Affected TCP flows would need an incoming ACK or RTO timer to add more packets to the pipe. So overall situation should be better now. Fixes: b223feb9de2a ("tcp: tsq: add shortcut in tcp_tasklet_func()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Madalin Bucur <madalin.bucur@nxp.com> Tested-by: Madalin Bucur <madalin.bucur@nxp.com> Tested-by: Xing Lei <xing.lei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-21splice: reinstate SIGPIPE/EPIPE handlingLinus Torvalds
Commit 8924feff66f3 ("splice: lift pipe_lock out of splice_to_pipe()") caused a regression when there were no more readers left on a pipe that was being spliced into: rather than the expected SIGPIPE and -EPIPE return value, the writer would end up waiting forever for space to free up (which obviously was not going to happen with no readers around). Fixes: 8924feff66f3 ("splice: lift pipe_lock out of splice_to_pipe()") Reported-and-tested-by: Andreas Schwab <schwab@linux-m68k.org> Debugged-by: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@kernel.org # v4.9 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-21Merge branch 'parisc-4.10-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc updates from Helge Deller: - add Kernel address space layout randomization support - re-enable interrupts earlier now that we have a working IRQ stack - optimize the timer interrupt function to better cope with missed timer irqs - fix error return code in parisc perf code (by Dan Carpenter) - fix PAT debug code * 'parisc-4.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Optimize timer interrupt function parisc: perf: return -EFAULT on error parisc: Enhance CPU detection code on PAT machines parisc: Re-enable interrupts early parisc: Enable KASLR
2016-12-21Merge tag 'nfs-for-4.10-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds
Pull more NFS client updates from Trond Myklebust: "Highlights include: - further attribute cache improvements to make revalidation more fine grained - NFSv4 locking improvements Bugfixes: - nfs4_fl_prepare_ds must be careful about reporting success in files layout - pNFS/flexfiles: Instead of marking a device inactive, remove it from the cache" * tag 'nfs-for-4.10-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Retry the DELEGRETURN if the embedded GETATTR is rejected with EACCES NFS: Retry the CLOSE if the embedded GETATTR is rejected with EACCES NFSv4: Place the GETATTR operation before the CLOSE NFSv4: Also ask for attributes when downgrading to a READ-only state NFS: Don't abuse NFS_INO_REVAL_FORCED in nfs_post_op_update_inode_locked() pNFS: Return RW layouts on OPEN_DOWNGRADE NFSv4: Add encode/decode of the layoutreturn op in OPEN_DOWNGRADE NFS: Don't disconnect open-owner on NFS4ERR_BAD_SEQID NFSv4: ensure __nfs4_find_lock_state returns consistent result. NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success. pNFS/flexfiles: delete deviceid, don't mark inactive NFS: Clean up nfs_attribute_timeout() NFS: Remove unused function nfs_revalidate_inode_rcu() NFS: Fix and clean up the access cache validity checking NFS: Only look at the change attribute cache state in nfs_weak_revalidate() NFS: Clean up cache validity checking NFS: Don't revalidate the file on close if we hold a delegation NFSv4: Don't discard the attributes returned by asynchronous DELEGRETURN NFSv4: Update the attribute cache info in update_changeattr
2016-12-21net: mvpp2: fix dma unmapping of TX buffers for fragmentsThomas Petazzoni
Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping"), we are not correctly DMA unmapping TX buffers for fragments. Indeed, the mvpp2_txq_inc_put() function only stores in the txq_cpu->tx_buffs[] array the physical address of the buffer to be DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use skb_headlen(skb) to get the size to be unmapped. Both of this works fine for TX descriptors that are associated directly to a SKB, but not the ones that are used for fragments, with a NULL pointer as skb: - We have a NULL physical address when calling DMA unmap - skb_headlen(skb) crashes because skb is NULL This causes random crashes when fragments are used. To solve this problem, we need to: - Store the physical address of the buffer to be unmapped unconditionally, regardless of whether it is tied to a SKB or not. - Store the length of the buffer to be unmapped, which requires a new field. Instead of adding a third array to store the length of the buffer to be unmapped, and as suggested by David Miller, this commit refactors the tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is added. Therefore, instead of having three arrays to allocate/free, we have a single one, which also improve data locality, reducing the impact on the CPU cache. Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping") Reported-by: Raphael G <raphael.glon@corp.ovh.com> Cc: Raphael G <raphael.glon@corp.ovh.com> Cc: stable@vger.kernel.org Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-21net: ethernet: stmmac: dwmac-rk: make clk enablement first in powerupHeiko Stübner
Right now the dwmac-rk tries to set up the GRF-specific speed and link options before enabling clocks, phys etc and on previous socs this works because the GRF is supplied on the whole by one clock. On the rk3399 however the GRF (General Register Files) clock-supply has been split into multiple clocks and while there is no specific grf-gmac clock like for other sub-blocks, it seems the mac-specific portions are actually supplied by the general mac clock. This results in hangs on rk3399 boards if the driver is build as module. When built in te problem of course doesn't surface, as the clocks are of course still on at the stage before clock_disable_unused. To solve this, simply move the clock enablement to the first position in the powerup callback. This is also a good idea in general to enable clocks before everything else. Tested on rk3288, rk3368 and rk3399 the dwmac still works on all of them. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-21be2net: Increase skb headroom size to 256 bytesKalesh A P
The driver currently allocates 128 bytes of skb headroom. This was found to be insufficient with some configurations like Geneve tunnels, which resulted in skb head reallocations. Increase the headroom to 256 bytes to fix this. Signed-off-by: Kalesh A P <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-21Merge branch 'scsi-target-for-v4.10' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/bvanassche/linux Pull scsi target cleanups from Bart Van Assche: "The changes here are: - a few small bug fixes for the iSCSI and user space target drivers. - minimize the target build time by about 30% by rearranging #include directives - fix the second argument passed to percpu_ida_alloc() - reduce the number of false positive warnings reported by sparse These patches pass Wu Fengguang's build bot tests and also the linux-next tests" * 'scsi-target-for-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/bvanassche/linux: iscsi-target: Return error if unable to add network portal target: Fix spelling mistake and unwrap multi-line text target/iscsi: Fix double free in lio_target_tiqn_addtpg() target/user: Fix use-after-free of tcmu_cmds if they are expired target: Minimize #include directives target/user: Add an #include directive cxgbit: Add an #include directive ibmvscsi_tgt: Add two #include directives sbp-target: Add an #include directive qla2xxx: Add an #include directive configfs: Minimize #include directives usb: gadget: Fix second argument of percpu_ida_alloc() sbp-target: Fix second argument of percpu_ida_alloc() target/user: Fix a data type in tcmu_queue_cmd() target: Use NULL instead of 0 to represent a pointer
2016-12-21Revert "ALSA: usb-audio: Fix race at stopping the stream"Takashi Iwai
This reverts commit 16200948d8353fe29a473a394d7d26790deae0e7. The commit was intended to cover the race condition, but it introduced yet another regression for devices with the implicit feedback, leading to a kernel panic due to NULL-dereference in an irq context. As the race condition that was addressed by the commit is very rare and the regression is much worse, let's revert the commit for rc1, and fix the issue properly in a later patch. Fixes: 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream") Reported-by: Ioan-Adrian Ratiu <adi@adirat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-21selinux: use the kernel headers when building scripts/selinuxPaul Moore
Commit 3322d0d64f4e ("selinux: keep SELinux in sync with new capability definitions") added a check on the defined capabilities without explicitly including the capability header file which caused problems when building genheaders for users of clang/llvm. Resolve this by using the kernel headers when building genheaders, which is arguably the right thing to do regardless, and explicitly including the kernel's capability.h header file in classmap.h. We also update the mdp build, even though it wasn't causing an error we really should be using the headers from the kernel we are building. Reported-by: Nicolas Iooss <nicolas.iooss@m4x.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2016-12-21rtlwifi: Fix kernel oops introduced with commit e49656147359Larry Finger
With commit e49656147359 {"rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb"), the method used to free an skb was changed because the kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb() guards against a NULL value for the argument. Routine dev_kfree_skb_irq() does not, and a test is needed to prevent kernel panics. Fixes: e49656147359 ("rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> # 4.9+ Cc: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-12-21ath9k: do not return early to fix rcu unlockingTobias Klausmann
Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls and suspicious RCU usage: =============================== [ INFO: suspicious RCU usage. ] 4.9.0-rc8 #11 Not tainted ------------------------------- kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! 1 lock held by swapper/7/0: #0: ( rcu_read_lock ){......} , at: [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k] stack backtrace: CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013 ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001 ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8 ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4 Call Trace: <IRQ> [<ffffffff8132b1e5>] dump_stack+0x68/0x93 [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110 [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200 [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0 [<ffffffff81058631>] irq_exit+0x61/0xd0 [<ffffffff81018d25>] do_IRQ+0x65/0x110 [<ffffffff81672189>] common_interrupt+0x89/0x89 <EOI> [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200 [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20 [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40 [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220 [<ffffffff810336f8>] start_secondary+0x148/0x170 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") Cc: <stable@vger.kernel.org> # v4.9 Acked-by: Felix Fietkau <nbd@nbd.name> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
2016-12-21x86/microcode/AMD: Reload proper initrd start addressBorislav Petkov
When we switch to virtual addresses and, especially after reserve_initrd()->relocate_initrd() have run, we have the updated initrd address in initrd_start. Use initrd_start then instead of the address which has been passed to us through boot params. (That still gets used when we're running the very early routines on the BSP). Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20161220144012.lc4cwrg6dphqbyqu@pd.tnic Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-12-21[media] s5k4ecgx: select CRC32 helperArnd Bergmann
A rare randconfig build failure shows up in this driver when the CRC32 helper is not there: drivers/media/built-in.o: In function `s5k4ecgx_s_power': s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le' This adds the 'select' that all other users of this function have. Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] dvb: avoid warning in dvb_netArnd Bergmann
With gcc-5 or higher on x86, we can get a bogus warning in the dvb-net code: drivers/media/dvb-core/dvb_net.c: In function 'dvb_net_ule': arch/x86/include/asm/string_32.h:78:22: error: '*((void *)&dest_addr+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized] The problem here is that gcc doesn't track all of the conditions to prove it can't end up copying uninitialized data. This changes the logic around so we zero out the destination address earlier when we determine that it is not set here. This allows the compiler to figure it out. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] v4l: tvp5150: Don't override output pinmuxing at stream on/off timeLaurent Pinchart
The s_stream() handler incorrectly writes the whole MISC_CTL register to enable or disable the outputs, overriding the output pinmuxing configuration. Fix it to only touch the output enable bits. The CONF_SHARED_PIN register is also written by the same function, resulting in muxing the INTREQ signal instead of the VBLK/GPCL signal on the INTREQ/GPCL/VBLK pin. As the driver doesn't support interrupts this is obviously incorrect, and breaks operation on other devices. Fix it by removing the write. Cc: stable@vger.kernel.org # For Kernel 4.5 and upper Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] v4l: tvp5150: Fix comment regarding output pin muxingLaurent Pinchart
The FID/GLCO/VLK/HVLK and INTREQ/GPCL/VBLK pins are muxed differently depending on whether the input is an S-Video or composite signal. The comment that explains the logic doesn't reflect the code. It appears that the comment is incorrect, as disabling the output data bus in composite mode makes no sense. Update the comment to match the code. While at it define macros for the MISC_CTL register bits, the code is too confusing with numerical values. Cc: stable@vger.kernel.org # For Kernel 4.5 and upper Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] v4l: tvp5150: Reset device at probe time, not in get/set format handlersLaurent Pinchart
The tvp5150 doesn't support format setting through the subdev pad API and thus implements the set format handler as a get format operation. The single handler, tvp5150_fill_fmt(), resets the device by calling tvp5150_reset(). This causes malfunction as the device can be reset at will, possibly from userspace when the subdev userspace API is enabled. The reset call was added in commit ec2c4f3f93cb ("[media] media: tvp5150: Add mbus_fmt callbacks"), probably as an attempt to set the device to a known state before detecting the current TV standard. However, the get format handler doesn't access the hardware to get the TV standard since commit 963ddc63e20d ("[media] media: tvp5150: Add cropping support"). There is thus no need to reset the device when getting the format. However, removing the tvp5150_reset() from the get/set format handlers results in the function not being called at all if the bridge driver doesn't use the .reset() operation. The operation is nowadays abused and shouldn't be used, so shouldn't expect bridge drivers to call it. To make sure the device is properly initialize, move the reset call from the format handlers to the probe function. Cc: stable@vger.kernel.org # For Kernel 4.5 and upper Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] pctv452e: move buffer to heap, no mutexMax Kellermann
commit 73d5c5c864f4 ("[media] pctv452e: don't do DMA on stack") caused a NULL pointer dereference which occurs when dvb_usb_init() calls dvb_usb_device_power_ctrl() for the first time, before the frontend has been attached. It also caused a recursive deadlock because tt3650_ci_msg_locked() has already locked the mutex. So, partially revert it, but move the buffer to the heap (DMA capable), not to the stack (may not be DMA capable). Instead of sharing one buffer which needs mutex protection, do a new heap allocation for each call. Fixes: commit 73d5c5c864f4 ("[media] pctv452e: don't do DMA on stack") Cc: stable@vger.kernel.org # For Kernel 4.9 Signed-off-by: Max Kellermann <max.kellermann@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] media/cobalt: use pci_irq_allocate_vectorsChristoph Hellwig
Simply the interrupt setup by using the new PCI layer helpers. Despite using pci_enable_msi_range, this driver was only requesting a single MSI vector anyway. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: fix race between configuring and unconfiguringHans Verkuil
This race was discovered by running cec-compliance -A with the cec module debug parameter set to 2: suddenly the test would fail. It turns out that this happens when the test configures the adapter in non-blocking mode, then it waits for the CEC_EVENT_STATE_CHANGE event and once the event is received it unconfigures the adapter. What happened was that the unconfigure was executed while the configure was still transmitting the Report Features and Report Physical Address messages. This messed up the internal state of the cec_adapter. The fix is to transmit those messages with the adap->lock mutex held (this will just queue them up in the internal transmit queue, and not actually transmit anything yet). Only unlock the mutex once everything is done. The main thread will dequeue the messages from the internal transmit queue and transmit them one by one, unless an unconfigure was done, and in that case any messages are just dropped. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: move cec_report_phys_addr into cec_config_thread_funcHans Verkuil
It's only a small function and this makes it easier to switch to transmitting the message with adap->lock held in the next patch. Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: replace cec_report_features by cec_fill_msg_report_featuresHans Verkuil
The fill function just fills in the cec_msg struct, it doesn't transmit the message. This is now done explicitly. This makes it possible to switch to transmitting this message with adap->lock held. Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: update log_addr[] before finishing configurationHans Verkuil
The loop that sets the unused logical addresses to INVALID should be done before 'configured' is set to true. This ensures that cec_log_addrs is consistent before it will be used. Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2Hans Verkuil
This is a 2.0 only message, so it should return Feature Abort if the adapter is configured for CEC version 1.4. Right now it does nothing, which means that the sender will time out. Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: when canceling a message, don't overwrite old status infoHans Verkuil
When a pending message was canceled (e.g. due to a timeout), then the old tx_status info was overwritten instead of ORed. The same happened with the tx_error_cnt field. So just modify them instead of overwriting them. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] cec: fix report_current_latencyHans Verkuil
In the (very) small print of the REPORT_CURRENT_LATENCY message there is a line that says that the last byte of the message (audio out delay) is only present if the 'audio out compensated' value is 3. I missed this, and so if this message was sent with a total length of 6 (i.e. without the audio out delay byte), then it was rejected by the framework since a minimum length of 7 was expected. Fix this minimum length check and update the wrappers in cec-funcs.h to do the right thing based on the message length. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] smiapp: Make suspend and resume functions __maybe_unusedSakari Ailus
The smiapp_suspend() and smiapp_resume() functions will end up being unused if CONFIG_PM is enabled but CONFIG_PM_SLEEP is disabled, causing a compiler warning from both of the function definitions. Fix this by marking the functions with __maybe_unused. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21[media] smiapp: Implement power-on and power-off sequences without runtime PMSakari Ailus
Power on the sensor when the module is loaded and power it off when it is removed. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-12-21mmc: sd: Meet alignment requirements for raw_ssr DMAPaul Burton
The mmc_read_ssr() function results in DMA to the raw_ssr member of struct mmc_card, which is not guaranteed to be cache line aligned & thus might not meet the requirements set out in Documentation/DMA-API.txt: Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Since the cache line size may not be known at compile time, the API will not enforce this requirement. Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). On some systems where DMA is non-coherent this can lead to us losing data that shares cache lines with the raw_ssr array. Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc will ensure the buffer is suitably aligned, allowing the DMA to be performed without any loss of data. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-12-21cpufreq: s3c64xx: remove incorrect __init annotationArnd Bergmann
s3c64xx_cpufreq_config_regulator is incorrectly annotated as __init, since the caller is also not init: WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator() With modern gcc versions, the function gets inline, so we don't see the warning, this only happens with gcc-4.6 and older. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21cpufreq: Remove CPU hotplug callbacks only if they were initializedBoris Ostrovsky
Since CPU hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state, successful callback initialization will result in cpuhp_setup_state() returning a positive value. Therefore acpi_cpufreq_online being zero indicates that callbacks have not been installed. This means that acpi_cpufreq_boost_exit() should only remove them if acpi_cpufreq_online is positive. Trying to call cpuhp_remove_state_nocalls(0) will cause a BUG(). Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21CPU/hotplug: Clarify description of __cpuhp_setup_state() return valueBoris Ostrovsky
When ivoked with CPUHP_AP_ONLINE_DYN state __cpuhp_setup_state() is expected to return positive value which is the hotplug state that the routine assigns. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21ACPI / osl: Remove deprecated ↵Lv Zheng
acpi_get_table_with_size()/early_acpi_os_unmap_memory() Since all users are cleaned up, remove the 2 deprecated APIs due to no users. As a Linux variable rather than an ACPICA variable, acpi_gbl_permanent_mmap is renamed to acpi_permanent_mmap to have a consistent coding style across entire Linux ACPI subsystem. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() usersLv Zheng
This patch removes the users of the deprectated APIs: acpi_get_table_with_size() early_acpi_os_unmap_memory() The following APIs should be used instead of: acpi_get_table() acpi_put_table() The deprecated APIs are invented to be a replacement of acpi_get_table() during the early stage so that the early mapped pointer will not be stored in ACPICA core and thus the late stage acpi_get_table() won't return a wrong pointer. The mapping size is returned just because it is required by early_acpi_os_unmap_memory() to unmap the pointer during early stage. But as the mapping size equals to the acpi_table_header.length (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when such a convenient result is returned, driver code will start to use it instead of accessing acpi_table_header to obtain the length. Thus this patch cleans up the drivers by replacing returned table size with acpi_table_header.length, and should be a no-op. Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21ACPICA: Tables: Allow FADT to be customized with virtual addressLv Zheng
ACPICA commit d98de9ca14891130efc5dcdc871b97eb27b4b0f5 FADT parsing code requires FADT to be installed as ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL, using new acpi_tb_get_table()/acpi_tb_put_table(), other address types can also be allowed, thus facilitates FADT customization with virtual address. Lv Zheng. Link: https://github.com/acpica/acpica/commit/d98de9ca Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-21ACPICA: Tables: Back port acpi_get_table_with_size() and ↵Lv Zheng
early_acpi_os_unmap_memory() from Linux kernel ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07 This patch back ports Linux acpi_get_table_with_size() and early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences. The 2 APIs are used by Linux as table management APIs for long time, it contains a hidden logic that during the early stage, the mapped tables should be unmapped before the early stage ends. During the early stage, tables are handled by the following sequence: acpi_get_table_with_size(); parse the table early_acpi_os_unmap_memory(); During the late stage, tables are handled by the following sequence: acpi_get_table(); parse the table Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the late stage. The reasoning of introducing acpi_get_table_with_size() is: ACPICA will remember the early mapped pointer in acpi_get_table() and Linux isn't able to prevent ACPICA from using the wrong early mapped pointer during the late stage as there is no API provided from ACPICA to be an inverse of acpi_get_table() to forget the early mapped pointer. But how ACPICA can work with the early/late stage requirement? Inside of ACPICA, tables are ensured to be remained in "INSTALLED" state during the early stage, and they are carefully not transitioned to "VALIDATED" state until the late stage. So the same logic is in fact implemented inside of ACPICA in a different way. The gap is only that the feature is not provided to the OSPMs in an accessible external API style. It then is possible to fix the gap by providing an inverse of acpi_get_table() from ACPICA, so that the two Linux sequences can be combined: acpi_get_table(); parse the table acpi_put_table(); In order to work easier with the current Linux code, acpi_get_table() and acpi_put_table() is implemented in a usage counting based style: 1. When the usage count of the table is increased from 0 to 1, table is mapped and .Pointer is set with the mapping address (VALIDATED); 2. When the usage count of the table is decreased from 1 to 0, .Pointer is unset and the mapping address is unmapped (INVALIDATED). So that we can deploy the new APIs to Linux with minimal effort by just invoking acpi_get_table() in acpi_get_table_with_size() and invoking acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/cac67909 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-20drm/amdgpu: update tile table for oland/hainanFlora Cui
Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-12-20drm/amdgpu: update tile table for verdeFlora Cui
Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-12-20drm/amdgpu: update rev id for verdeFlora Cui
Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org