user/sven/linux.git, branch v3.16.50

Linux 3.16.50

2017-11-11T13:34:06Z

i2c: ismt: Separate I2C block read from SMBus block read

2017-11-11T13:34:04Z

commit c6ebcedbab7ca78984959386012a17b21183e1a3 upstream. Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads") broke I2C block reads. It aimed to fix normal SMBus block read, but changed the correct behavior of I2C block read in the process. According to Documentation/i2c/smbus-protocol, one vital difference between normal SMBus block read and I2C block read is that there is no byte count prefixed in the data sent on the wire: SMBus Block Read: i2c_smbus_read_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P I2C Block Read: i2c_smbus_read_i2c_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Therefore the two transaction types need to be processed differently in the driver by copying of the dma_buffer as done previously for the I2C_SMBUS_I2C_BLOCK_DATA case. Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads") Signed-off-by: Pontus Andersson Tested-by: Stephen Douthit Signed-off-by: Wolfram Sang Signed-off-by: Ben Hutchings

net/xen-netback: disable on 64KB page granularity

2017-11-11T13:34:03Z

Building the linux-3.16 stable branch, I ran into this warning that shows a serious problem in the xen-netback driver: drivers/net/xen-netback/netback.c: In function 'xenvif_dealloc_kthread': drivers/net/xen-netback/netback.c:2002:1: error: the frame size of 16384 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] The bug was fixed in linux-4.4, but for any older stable kernel we either need to backport that fix, or not use the driver when the page size is set to 64KB. As the proper fix is way bigger than the usual limit for stable backport patches, this adds a Kconfig dependency. Fixes: d0089e8a0e4c ("net/xen-netback: Make it running on 64KB page granularity") Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

MIPS: Fix a warning for virt_to_page

2017-11-11T13:34:03Z

commit 4d5b3bdc0ecb0cf5b1e1598eeaaac4b5cb33868d upstream. Compiling mm/highmem.c gives a warning: passing argument 1 of 'virt_to_phys' makes pointer from integer without a cast Fixed by casting to void* Signed-off-by: Zubair Lutfullah Kakakhel Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7337/ Signed-off-by: Ralf Baechle Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

e1000e: fix call to do_div() to use u64 arg

2017-11-11T13:34:03Z

commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream. We were using s64 for lat_ns (latency nano-second value) since in our calculations a negative value could be a resultant. For negative values, we then assign lat_ns to be zero, so the value passed to do_div() was never negative, but do_div() expects the argument type to be u64, so do a cast to resolve a compile warning seen on PowerPC. CC: Yanjiang Jin CC: Yanir Lubetkin Reported-by: Yanjiang Jin Signed-off-by: Jeff Kirsher Tested-by: Aaron Brown Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

net: ti: cpmac: Fix compiler warning due to type confusion

2017-11-11T13:34:03Z

commit 2f5281ba2a8feaf6f0aee93356f350855bb530fc upstream. cpmac_start_xmit() used the max() macro on skb->len (an unsigned int) and ETH_ZLEN (a signed int literal). This led to the following compiler warning: In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from drivers/net/ethernet/ti/cpmac.c:19: drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); \ ^ drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max' len = max(skb->len, ETH_ZLEN); ^ On top of this, it assigned the result of the max() macro to a signed integer whilst all further uses of it result in it being cast to varying widths of unsigned integer. Fix this up by using max_t to ensure the comparison is performed as unsigned integers, and for consistency change the type of the len variable to unsigned int. Signed-off-by: Paul Burton Signed-off-by: David S. Miller Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

MIPS: elf2ecoff: Ignore PT_MIPS_ABIFLAGS program headers.

2017-11-11T13:34:02Z

commit 26f7c4bd05cf34e63a4a794150ab66a40a5a84a9 upstream. These are generated by very recent toolchains and result in an error message when attenpting to convert a kernel from ELF to ECOFF. Signed-off-by: Ralf Baechle Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

MIPS: jz4740: fix build error in irq.h

2017-11-11T13:34:02Z

kernelci found build error on the 3.16 and 3.18 stable trees that don't show up in later versions: arch/mips/jz4740/irq.h:21:38: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] arch/mips/jz4740/irq.h:20:39: error: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] include/linux/irqdesc.h:92:33: error: 'NR_IRQS' undeclared here (not in a function) arch/mips/jz4740/irq.c:91:41: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/irq.c:68:6: error: conflicting types for 'jz4740_irq_resume' arch/mips/jz4740/irq.c:62:6: error: conflicting types for 'jz4740_irq_suspend' arch/mips/jz4740/irq.c:49:39: error: 'JZ4740_IRQ_BASE' undeclared (first use in this function) arch/mips/jz4740/gpio.c:47:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:46:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:45:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:44:32: error: initializer element is not constant arch/mips/jz4740/gpio.c:447:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:446:23: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] arch/mips/jz4740/gpio.c:427:14: error: implicit declaration of function 'JZ4740_IRQ_INTC_GPIO' [-Werror=implicit-function-declaration] arch/mips/jz4740/gpio.c:269:9: error: implicit declaration of function 'JZ4740_IRQ_GPIO' [-Werror=implicit-function-declaration] The problem seems to be caused by commit 83bc76920080 ("MIPS: JZ4740: Use generic irq chip") from linux-3.2, but only showed up in a defconfig build when qi_lb60_defconfig was added in linux-3.13 and that configuration never successfully built. The code has changed in a number of ways before 4.4, which builds fine. While I did not bisect the problem to a specific change, I found a simple fix by including the obviously missing header. Cc: Lars-Peter Clausen Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

perf: Avoid horrible stack usage

2017-11-11T13:34:02Z

commit 86038c5ea81b519a8a1fcfcd5e4599aab0cdd119 upstream. Both Linus (most recent) and Steve (a while ago) reported that perf related callbacks have massive stack bloat. The problem is that software events need a pt_regs in order to properly report the event location and unwind stack. And because we could not assume one was present we allocated one on stack and filled it with minimal bits required for operation. Now, pt_regs is quite large, so this is undesirable. Furthermore it turns out that most sites actually have a pt_regs pointer available, making this even more onerous, as the stack space is pointless waste. This patch addresses the problem by observing that software events have well defined nesting semantics, therefore we can use static per-cpu storage instead of on-stack. Linus made the further observation that all but the scheduler callers of perf_sw_event() have a pt_regs available, so we change the regular perf_sw_event() to require a valid pt_regs (where it used to be optional) and add perf_sw_event_sched() for the scheduler. We have a scheduler specific call instead of a more generic _noregs() like construct because we can assume non-recursion from the scheduler and thereby simplify the code further (_noregs would have to put the recursion context call inline in order to assertain which __perf_regs element to use). One last note on the implementation of perf_trace_buf_prepare(); we allow .regs = NULL for those cases where we already have a pt_regs pointer available and do not need another. Reported-by: Linus Torvalds Reported-by: Steven Rostedt Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Javi Merino Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Oleg Nesterov Cc: Paul Mackerras Cc: Petr Mladek Cc: Steven Rostedt Cc: Tom Zanussi Cc: Vaibhav Nagarnaik Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings

drbd: avoid redefinition of BITS_PER_PAGE

2017-11-11T13:34:02Z

commit 2630628b2dbc3fc320aafaf84836119e4e3d62f1 upstream. Apparently we now implicitly get definitions for BITS_PER_PAGE and BITS_PER_PAGE_MASK from the pid_namespace.h Instead of renaming our defines, I chose to define only if not yet defined, but to double check the value if already defined. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Arnd Bergmann Signed-off-by: Ben Hutchings