user/sven/linux.git, branch v4.2.7

Linux 4.2.7

2015-12-09T19:31:40Z

tile: fix build failure

2015-12-09T19:31:26Z

commit 3a48d13d76c0088a988a2e4f5b4d94872bdf58f3 upstream. When building with allmodconfig the build was failing with the error: arch/tile/kernel/usb.c:70:1: warning: data definition has no type or storage class [enabled by default] arch/tile/kernel/usb.c:70:1: error: type defaults to 'int' in declaration of 'arch_initcall' [-Werror=implicit-int] arch/tile/kernel/usb.c:70:1: warning: parameter names (without types) in function declaration [enabled by default] arch/tile/kernel/usb.c:63:19: warning: 'tilegx_usb_init' defined but not used [-Wunused-function] Include linux/module.h to resolve the build failure. Signed-off-by: Sudip Mukherjee Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman

KVM: s390: enable SIMD only when no VCPUs were created

2015-12-09T19:31:26Z

commit 5967c17b118a2bd1dd1d554cc4eee16233e52bec upstream. We should never allow to enable/disable any facilities for the guest when other VCPUs were already created. kvm_arch_vcpu_(load|put) relies on SIMD not changing during runtime. If somebody would create and run VCPUs and then decides to enable SIMD, undefined behaviour could be possible (e.g. vector save area not being set up). Acked-by: Christian Borntraeger Acked-by: Cornelia Huck Signed-off-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman

xen/events: Always allocate legacy interrupts on PV guests

2015-12-09T19:31:26Z

commit b4ff8389ed14b849354b59ce9b360bdefcdbf99c upstream. After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interrupts if PIC does not exist, which is the case for Xen PV guests. Therefore we may need to allocate those descriptors ourselves. Signed-off-by: Boris Ostrovsky Suggested-by: Thomas Gleixner Signed-off-by: David Vrabel Cc: Vitaly Kuznetsov Signed-off-by: Greg Kroah-Hartman

staging/lustre: use jiffies for lp_last_query times

2015-12-09T19:31:26Z

commit 9f088dba3cc267ea11ec0da318cd0175575b5f9b upstream. The recently introduced lnet_peer_set_alive() function uses get_seconds() to read the current time into a shared variable, but all other uses of that variable compare it to jiffies values. This changes the current use to jiffies as well for consistency. Signed-off-by: Arnd Bergmann Fixes: af3fa7c71bf ("staging/lustre/lnet: peer aliveness status and NI status") Cc: Liang Zhen Cc: James Simmons Cc: Isaac Huang Signed-off-by: Oleg Drokin Signed-off-by: Greg Kroah-Hartman

xhci: Workaround to get Intel xHCI reset working more reliably

2015-12-09T19:31:26Z

commit a5964396190d0c40dd549c23848c282fffa5d1f2 upstream. Existing Intel xHCI controllers require a delay of 1 mS, after setting the CMD_RESET bit in command register, before accessing any HC registers. This allows the HC to complete the reset operation and be ready for HC register access. Without this delay, the subsequent HC register access, may result in a system hang, very rarely. Verified CherryView / Braswell platforms go through over 5000 warm reboot cycles (which was not possible without this patch), without any xHCI reset hang. Signed-off-by: Rajmohan Mani Tested-by: Joe Lawrence Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

tty: Fix tty_send_xchar() lock order inversion

2015-12-09T19:31:25Z

commit ee0c1a65cf95230d5eb3d9de94fd2ead9a428c67 upstream. The correct lock order is atomic_write_lock => termios_rwsem, as established by tty_write() => n_tty_write(). Fixes: c274f6ef1c666 ("tty: Hold termios_rwsem for tcflow(TCIxxx)") Reported-and-Tested-by: Dmitry Vyukov Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: audit: Fix audit source

2015-12-09T19:31:25Z

commit 6b2a3d628aa752f0ab825fc6d4d07b09e274d1c1 upstream. The data to audit/record is in the 'from' buffer (ie., the input read buffer). Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode") Cc: Miloslav Trmač Signed-off-by: Peter Hurley Acked-by: Laura Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

ttyFDC: Fix build problems due to use of module_{init,exit}

2015-12-09T19:31:25Z

commit 3e8137a185240fa6da0ff91cd9c604716371903b upstream. Commit 0fd972a7d91d (module: relocate module_init from init.h to module.h) broke the build of ttyFDC driver due to that driver's (mis)use of module_mips_cdmm_driver() without first including module.h, for example: In file included from ./arch/mips/include/asm/cdmm.h +11 :0, from drivers/tty/mips_ejtag_fdc.c +34 : include/linux/device.h +1295 :1: warning: data definition has no type or storage class ./arch/mips/include/asm/cdmm.h +84 :2: note: in expansion of macro ‘module_driver’ drivers/tty/mips_ejtag_fdc.c +1157 :1: note: in expansion of macro ‘module_mips_cdmm_driver’ include/linux/device.h +1295 :1: error: type defaults to ‘int’ in declaration of ‘module_init’ [-Werror=implicit-int] ./arch/mips/include/asm/cdmm.h +84 :2: note: in expansion of macro ‘module_driver’ drivers/tty/mips_ejtag_fdc.c +1157 :1: note: in expansion of macro ‘module_mips_cdmm_driver’ drivers/tty/mips_ejtag_fdc.c +1157 :1: warning: parameter names (without types) in function declaration Instead of just adding the module.h include, switch to using the new builtin_mips_cdmm_driver() helper macro and drop the remove callback, since it isn't needed. If module support is added later, the code can always be resurrected. Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Paul Gortmaker Cc: linux-mips@linux-mips.org Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: work around CH345 input SysEx corruption

2015-12-09T19:31:25Z

commit a91e627e3f0ed820b11d86cdc04df38f65f33a70 upstream. One of the many faults of the QinHeng CH345 USB MIDI interface chip is that it does not handle received SysEx messages correctly -- every second event packet has a wrong code index number, which is the one from the last seen message, instead of 4. For example, the two messages "FE F0 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event packets: correct: CH345: 0F FE 00 00 0F FE 00 00 04 F0 01 02 04 F0 01 02 04 03 04 05 0F 03 04 05 04 06 07 08 04 06 07 08 04 09 0A 0B 0F 09 0A 0B 04 0C 0D 0E 04 0C 0D 0E 05 F7 00 00 05 F7 00 00 A class-compliant driver must interpret an event packet with CIN 15 as having a single data byte, so the other two bytes would be ignored. The message received by the host would then be missing two bytes out of six; in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7". These corrupted SysEx event packages contain only data bytes, while the CH345 uses event packets with a correct CIN value only for messages with a status byte, so it is possible to distinguish between these two cases by checking for the presence of this status byte. (Other bugs in the CH345's input handling, such as the corruption resulting from running status, cannot be worked around.) Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman