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

Linux 3.12.27

2014-08-26T12:12:26Z

drivers/rtc/interface.c: fix infinite loop in initializing the alarm

2014-08-26T12:12:25Z

commit ee1d90146815fdc8d653c558b327fff2acba041d upstream. In __rtc_read_alarm(), if the alarm time retrieved by rtc_read_alarm_internal() from the device contains invalid values (e.g. month=2,mday=31) and the year not set (=-1), the initialization will loop infinitely because the year-fixing loop expects the time being invalid due to leap year. Fix reduces the loop to the leap years and adds final validity check. Signed-off-by: Ales Novak Acked-by: Alessandro Zummo Reported-by: Jiri Bohac Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby

drivers/rtc/rtc-efi.c: check for invalid data coming back from UEFI

2014-08-26T12:12:25Z

commit 6e85bab6bc1019f9b87c53b32da3ad7791e7ddf9 upstream. In particular seeing zero in eft->month is problematic, as it results in -1 (converted to unsigned int, i.e. yielding 0xffffffff) getting passed to rtc_year_days(), where the value gets used as an array index (normally resulting in a crash). This was observed with the driver enabled on x86 on some Fujitsu system (with possibly not up to date firmware, but anyway). Perhaps efi_read_alarm() should not fail if neither enabled nor pending are set, but the returned time is invalid? Signed-off-by: Jan Beulich Reported-by: Raymund Will Cc: Alessandro Zummo Cc: Jingoo Han Acked-by: Lee, Chun-Yi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby

drivers/rtc/rtc-efi.c: avoid subtracting day twice when computing year days

2014-08-26T12:12:24Z

commit 809d9627087e1db63b8672c1f264af73b13116fb upstream. Compared source code of rtc-lib.c::rtc_year_days() with efirtc.c::rtc_year_days(), found the code in rtc-efi decreases value of day twice when it computing year days. rtc-lib.c::rtc_year_days() has already decrease days and return the year days from 0 to 365. Signed-off-by: Lee, Chun-Yi Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby

ALSA: hda - load EQ params into IDT codec on HP bNB13 systems

2014-08-26T12:12:23Z

commit d009f3deb788f7d06fe04c52eaf812b657a0ca68 upstream. Adds linear EQ filtering for integrated speaker protection Signed-off-by: Vitaliy Kulikov Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby

HID: logitech-dj: Fix USB 3.0 issue

2014-08-26T12:12:23Z

commit 42c22dbf81ebd1146960875ddfe71630cb2b3ae6 upstream. This fix (not very clean though) should fix the long time USB3 issue that was spotted last year. The rational has been given by Hans de Goede: ---- I think the most likely cause for this is a firmware bug in the unifying receiver, likely a race condition. The most prominent difference between having a USB-2 device plugged into an EHCI (so USB-2 only) port versus an XHCI port will be inter packet timing. Specifically if you send packets (ie hid reports) one at a time, then with the EHCI controller their will be a significant pause between them, where with XHCI they will be very close together in time. The reason for this is the difference in EHCI / XHCI controller OS <-> driver interfaces. For non periodic endpoints (control, bulk) the EHCI uses a circular linked-list of commands in dma-memory, which it follows to execute commands, if the list is empty, it will go into an idle state and re-check periodically. The XHCI uses a ring of commands per endpoint, and if the OS places anything new on the ring it will do an ioport write, waking up the XHCI making it send the new packet immediately. For periodic transfers (isoc, interrupt) the delay between packets when sending one at a time (rather then queuing them up) will be even larger, because they need to be inserted into the EHCI schedule 2 ms in the future so the OS driver can be sure that the EHCI driver does not try to start executing the time slot in question before the insertion has completed. So a possible fix may be to insert a delay between packets being send to the receiver. ---- I tested this on a buggy Haswell USB 3.0 motherboard, and I always get the notification after adding the msleep. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

Input: i8042 - add Acer Aspire 5710 to nomux blacklist

2014-08-26T12:12:23Z

commit 8c947e20cb1f442c704852b2ca24b81981b09493 upstream. Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad misbehaves rather randomly. Signed-off-by: Jiri Kosina Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby

PCI: rphahp: Fix endianess issues

2014-08-26T12:12:22Z

commit 761ce53330a4f02c58768631027d1c1dd0d538f7 upstream. Numerical values stored in the device tree are encoded in Big Endian and should be byte swapped when running in Little Endian. The RPA hotplug module should convert those values as well. Note that in rpaphp_get_drc_props(), the comparison between indexes[i+1] and *index is done using the BE values (whatever is the current endianess). This doesn't matter since we are checking for equality here. This way only the returned value is byte swapped. RPA also made RTAS calls which implies BE values to be used. According to the patch done in RTAS (http://patchwork.ozlabs.org/patch/336865), no additional conversion is required in RPA. Signed-off-by: Laurent Dufour Signed-off-by: Bjorn Helgaas Signed-off-by: Jiri Slaby

tipc: don't use memcpy to copy from user space

2014-08-26T12:12:22Z

commit 5c0a0fc81f4dc786b42c4fc9c7c72ba635406ab5 upstream. tipc_msg_build() calls skb_copy_to_linear_data_offset() to copy data from user space to kernel space. However, the latter function does in its turn call memcpy() to perform the actual copying. This poses an obvious security and robustness risk, since memcpy() never makes any validity check on the pointer it is copying from. To correct this, we the replace the offending function call with a call to memcpy_fromiovecend(), which uses copy_from_user() to perform the copying. Signed-off-by: Ying Xue Reviewed-by: Paul Gortmaker Signed-off-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

tg3: Add support for new 577xx device ids

2014-08-26T12:12:21Z

commit 68273712a19e9107a498a371532b3b3eb6dbb14c upstream. This patch adds support for 57764, 57765, 57787, 57782 and 57786 devices. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby