summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-02-22block: add cond_resched() to potentially long running ioctl discard loopJens Axboe
commit c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream. When mkfs issues a full device discard and the device only supports discards of a smallish size, we can loop in blkdev_issue_discard() for a long time. If preempt isn't enabled, this can turn into a softlock situation and the kernel will start complaining. Add an explicit cond_resched() at the end of the loop to avoid that. Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22block: Fix nr_vecs for inline integrity vectorsMartin K. Petersen
commit 087787959ce851d7bbb19f10f6e9241b7f85a3ca upstream. Commit 9f060e2231ca changed the way we handle allocations for the integrity vectors. When the vectors are inline there is no associated slab and consequently bvec_nr_vecs() returns 0. Ensure that we check against BIP_INLINE_VECS in that case. Reported-by: David Milburn <dmilburn@redhat.com> Tested-by: David Milburn <dmilburn@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Jens Axboe <axboe@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22block: __elv_next_request() shouldn't call into the elevator if bypassingTejun Heo
commit 556ee818c06f37b2e583af0363e6b16d0e0270de upstream. request_queue bypassing is used to suppress higher-level function of a request_queue so that they can be switched, reconfigured and shut down. A request_queue does the followings while bypassing. * bypasses elevator and io_cq association and queues requests directly to the FIFO dispatch queue. * bypasses block cgroup request_list lookup and always uses the root request_list. Once confirmed to be bypassing, specific elevator and block cgroup policy implementations can assume that nothing is in flight for them and perform various operations which would be dangerous otherwise. Such confirmation is acheived by short-circuiting all new requests directly to the dispatch queue and waiting for all the requests which were issued before to finish. Unfortunately, while the request allocating and draining sides were properly handled, we forgot to actually plug the request dispatch path. Even after bypassing mode is confirmed, if the attached driver tries to fetch a request and the dispatch queue is empty, __elv_next_request() would invoke the current elevator's elevator_dispatch_fn() callback. As all in-flight requests were drained, the elevator wouldn't contain any request but once bypass is confirmed we don't even know whether the elevator is even there. It might be in the process of being switched and half torn down. Frank Mayhar reports that this actually happened while switching elevators, leading to an oops. Let's fix it by making __elv_next_request() avoid invoking the elevator_dispatch_fn() callback if the queue is bypassing. It already avoids invoking the callback if the queue is dying. As a dying queue is guaranteed to be bypassing, we can simply replace blk_queue_dying() check with blk_queue_bypass(). Reported-by: Frank Mayhar <fmayhar@google.com> References: http://lkml.kernel.org/g/1390319905.20232.38.camel@bobble.lax.corp.google.com Tested-by: Frank Mayhar <fmayhar@google.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Modpost: fixed USB alias generation for ranges including 0x9 and 0xAJan Moskyto Matejka
commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc upstream. Commit afe2dab4f6 ("USB: add hex/bcd detection to usb modalias generation") changed the routine that generates alias ranges. Before that change, only digits 0-9 were supported; the commit tried to fix the case when the range includes higher values than 0x9. Unfortunately, the commit didn't fix the case when the range includes both 0x9 and 0xA, meaning that the final range must look like [x-9A-y] where x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced. Modprobe doesn't complain as it sees no difference between no-match and bad-pattern results of fnmatch(). Fixing this simple bug to fix the aliases. Also changing the hardcoded beginning of the range to uppercase as all the other letters are also uppercase in the device version numbers. Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK. Signed-off-by: Jan Moskyto Matejka <mq@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Revert "usbcore: set lpm_capable field for LPM capable root hubs"Sarah Sharp
commit 140e3026a57ab7d830dab2f2c57796c222db0ea9 upstream. Commit 9df89d85b407690afa46ddfbccc80bec6869971d "usbcore: set lpm_capable field for LPM capable root hubs" was created under the assumption that all USB host controllers should have USB 3.0 Link PM enabled for all devices under the hosts. Unfortunately, that's not the case. The xHCI driver relies on knowledge of the host hardware scheduler to calculate the LPM U1/U2 timeout values, and it only sets lpm_capable to one for Intel host controllers (that have the XHCI_LPM_SUPPORT quirk set). When LPM is enabled for some Fresco Logic hosts, it causes failures with a AgeStar 3UBT USB 3.0 hard drive dock: Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed. Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed. Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device detected Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1" Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP device Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0 Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed. Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed. Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver usb-storage Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71 Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110 Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready after error recovery Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2 lspci for the affected host: 04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI]) Subsystem: 1043:1039 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at dd200000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd The commit was backported to stable kernels, and will need to be reverted there as well. Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com> Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Revert "usb: xhci: Link TRB must not occur within a USB payload burst"Sarah Sharp
commit 3d4b81eda2211f32886e2978daf6f39885042fc4 upstream. This reverts commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e. It's a hack that caused regressions in the usb-storage and userspace USB drivers that use usbfs and libusb. Commit 70cabb7d992f "xhci 1.0: Limit arbitrarily-aligned scatter gather." should fix the issues seen with the ax88179_178a driver on xHCI 1.0 hosts, without causing regressions. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Revert "xhci: Avoid infinite loop when sg urb requires too many trbs"Sarah Sharp
commit 9cf00d91708221ff2d8a11143315f7ebab8d5da8 upstream. This reverts commit d6c9ea9069af684358efedcaf2f2f687f51c58ee. We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" because it's a hack that caused regressions in the usb-storage and userspace USB drivers that use usbfs and libusb. This commit attempted to fix the issues with that patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Revert "xhci: Set scatter-gather limit to avoid failed block writes."Sarah Sharp
commit 1386ff75797a187df324062fb4e929152392da88 upstream. This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee. We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" because it's a hack that caused regressions in the usb-storage and userspace USB drivers that use usbfs and libusb. This commit attempted to fix the issues with that patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22xhci 1.0: Limit arbitrarily-aligned scatter gather.Sarah Sharp
commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called "TD fragment" rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma", it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Mark Lord <mlord@pobox.com> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Bjørn Mork <bjorn@mork.no> Cc: Freddy Xin <freddy@asix.com.tw> Cc: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22USB: simple: add Dynastream ANT USB-m Stick device supportKristóf Ralovich
commit 2240c365108adbc4100a55654a5707e8e877a401 upstream. Add support for ANT USB-m Stick from Dynastream Innovations, by listing USB pid [34366.944805] usb 6-1: New USB device found, idVendor=0fcf, idProduct=1009 [34366.944817] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [34366.944824] usb 6-1: Product: ANT USB-m Stick [34366.944831] usb 6-1: Manufacturer: Dynastream Innovations Device reported (https://code.google.com/p/antpm/issues/detail?id=5) to work through: $ modprobe usbserial vendor=0x0fcf product=0x1009 Signed-off-by: Kristóf Ralovich <kristof.ralovich@gmail.com> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb: option: blacklist ZTE MF667 net interfaceRaymond Wanyoike
commit 3635c7e2d59f7861afa6fa5e87e2a58860ff514d upstream. Interface #5 of 19d2:1270 is a net interface which has been submitted to the qmi_wwan driver so consequently remove it from the option driver. Signed-off-by: Raymond Wanyoike <raymond.wanyoike@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: enable multi-LUN scanning when neededAlan Stern
commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream. People sometimes create their own custom-configured kernels and forget to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug in a USB storage device (such as a card reader) with more than one LUN. Fortunately, we can tell fairly easily when a storage device claims to have more than one LUN. When that happens, this patch asks the SCSI layer to probe all the LUNs automatically, regardless of the config setting. The patch also updates the Kconfig help text for usb-storage, explaining that CONFIG_SCSI_MULTI_LUN may be necessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Thomas Raschbacher <lordvan@lordvan.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: restrict bcdDevice range for Super Top in Cypress ATACBAlan Stern
commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream. The Cypress ATACB unusual-devs entry for the Super Top SATA bridge causes problems. Although it was originally reported only for bcdDevice = 0x160, its range was much larger. This resulted in a bug report for bcdDevice 0x220, so the range was capped at 0x219. Now Milan reports errors with bcdDevice 0x150. Therefore this patch restricts the range to just 0x160. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: add unusual-devs entry for BlackBerry 9000Alan Stern
commit c5637e5119c43452a00e27c274356b072263ecbb upstream. This patch adds an unusual-devs entry for the BlackBerry 9000. This fixes Bugzilla #22442. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22USB: ftdi_sio: add Tagsys RFID Reader IDsUlrich Hahn
commit 76f24e3f39a1a94bab0d54e98899d64abcd9f69c upstream. Adding two more IDs to the ftdi_sio usb serial driver. It now connects Tagsys RFID readers. There might be more IDs out there for other Tagsys models. Signed-off-by: Ulrich Hahn <uhahn@eanco.de> Cc: Johan Hovold <johan@hovold.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb: ftdi_sio: add Mindstorms EV3 console adapterBjørn Mork
commit 67847baee056892dc35efb9c3fd05ae7f075588c upstream. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22Drivers: hv: vmbus: Don't timeout during the initial connection with hostK. Y. Srinivasan
commit 269f979467cf49f2ea8132316c1f00f8c9678f7c upstream. When the guest attempts to connect with the host when there may already be a connection with the host (as would be the case during the kdump/kexec path), it is difficult to guarantee timely response from the host. Starting with WS2012 R2, the host supports this ability to re-connect with the host (explicitly to support kexec). Prior to responding to the guest, the host needs to ensure that device states based on the previous connection to the host have been properly torn down. This may introduce unbounded delays. To deal with this issue, don't do a timed wait during the initial connect with the host. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22VME: Correct read/write alignment algorithmMartyn Welch
commit f0342e66b397947ed8c3eef8c37b5ca2d5b1bb50 upstream. In order to ensure the correct width cycles on the VME bus, the VME bridge drivers implement an algorithm to utilise the largest possible width reads and writes whilst maintaining natural alignment constraints. The algorithm currently looks at the start address rather than the current read/write address when determining whether a 16-bit width cycle is required to get to 32-bit alignment. This results in incorrect alignment, Reported-by: Jim Strouth <james.strouth@ge.com> Tested-by: Jim Strouth <james.strouth@ge.com> Signed-off-by: Martyn Welch <martyn.welch@ge.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22mei: don't unset read cb ptr on resetAlexander Usyskin
commit 5cb906c7035f03a3a44fecece9d3ff8fcc75d6e0 upstream. Don't set read callback to NULL during reset as this leads to memory leak of both cb and its buffer. The memory is correctly freed during mei_release. The memory leak is detectable by kmemleak if application has open read call while system is going through suspend/resume. unreferenced object 0xecead780 (size 64): comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s) hex dump (first 32 bytes): 00 01 10 00 00 02 20 00 00 bf 30 f1 00 00 00 00 ...... ...0..... 00 00 00 00 00 00 00 00 36 01 00 00 00 70 da e2 ........6....p.. backtrace: [<c1a60aec>] kmemleak_alloc+0x3c/0xa0 [<c131ed56>] kmem_cache_alloc_trace+0xc6/0x190 [<c16243c9>] mei_io_cb_init+0x29/0x50 [<c1625722>] mei_cl_read_start+0x102/0x360 [<c16268f3>] mei_read+0x103/0x4e0 [<c1324b09>] vfs_read+0x89/0x160 [<c1324d5f>] SyS_read+0x4f/0x80 [<c1a7b318>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff unreferenced object 0xe2da7000 (size 512): comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s) hex dump (first 32 bytes): 00 6c da e2 7c 00 00 00 00 00 00 00 c0 eb 0c 59 .l..|..........Y 1b 00 00 00 01 00 00 00 02 10 00 00 01 00 00 00 ................ backtrace: [<c1a60aec>] kmemleak_alloc+0x3c/0xa0 [<c131f127>] __kmalloc+0xe7/0x1d0 [<c162447e>] mei_io_cb_alloc_resp_buf+0x2e/0x60 [<c162574c>] mei_cl_read_start+0x12c/0x360 [<c16268f3>] mei_read+0x103/0x4e0 [<c1324b09>] vfs_read+0x89/0x160 [<c1324d5f>] SyS_read+0x4f/0x80 [<c1a7b318>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22mei: clear write cb from waiting list on resetAlexander Usyskin
commit 30c54df7cb9b15b222529a028390b9c9582dd65e upstream. Clear write callbacks sitting in write_waiting list on reset. Otherwise these callbacks are left dangling and cause memory leak. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22ALSA: hda - Fix mic capture on Sony VAIO Pro 11Takashi Iwai
commit f88abaa0d0dc0d1f1a9ae21f8e822918e5aadfdf upstream. The very same fixup is needed to make the mic on Sony VAIO Pro 11 working as well as VAIO Pro 13 model. Reported-and-tested-by: Hendrik-Jan Heins <hjheins@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22ftrace/x86: Use breakpoints for converting function graph callerSteven Rostedt (Red Hat)
commit 87fbb2ac6073a7039303517546a76074feb14c84 upstream. When the conversion was made to remove stop machine and use the breakpoint logic instead, the modification of the function graph caller is still done directly as though it was being done under stop machine. As it is not converted via stop machine anymore, there is a possibility that the code could be layed across cache lines and if another CPU is accessing that function graph call when it is being updated, it could cause a General Protection Fault. Convert the update of the function graph caller to use the breakpoint method as well. Cc: H. Peter Anvin <hpa@zytor.com> Fixes: 08d636b6d4fb "ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine" Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22x86, smap: smap_violation() is bogus if CONFIG_X86_SMAP is offH. Peter Anvin
commit 4640c7ee9b8953237d05a61ea3ea93981d1bc961 upstream. If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions which are incorrect (as the AC flag doesn't matter), causing spurious faults. The dynamic disabling of SMAP (nosmap on the command line) is fine because it disables X86_FEATURE_SMAP, therefore causing the static_cpu_has() to return false. Found by Fengguang Wu's test system. [ v3: move all predicates into smap_violation() ] [ v2: use IS_ENABLED() instead of #ifdef ] Reported-by: Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22x86, smap: Don't enable SMAP if CONFIG_X86_SMAP is disabledH. Peter Anvin
commit 03bbd596ac04fef47ce93a730b8f086d797c3021 upstream. If SMAP support is not compiled into the kernel, don't enable SMAP in CR4 -- in fact, we should clear it, because the kernel doesn't contain the proper STAC/CLAC instructions for SMAP support. Found by Fengguang Wu's test system. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iio: ak8975: Fix calculation formula for convert micro tesla to gauss unitBeomho Seo
commit bef44abccb2677e8d16e50b75316d4fd1061be81 upstream. This effects the reported scale of the raw values, and thus userspace applications that use this value. One micro tesla equal 0.01 gauss. So I have fixed calculation formula And add RAW_TO_GAUSS macro. ASA is in the range of 0 to 255. If multiply 0.003, calculation result(in_magn_[*]_scale) is always 0. So multiply 3000 and return and IIO_VAL_INT_PLUS_MICRO. As a result, read_raw call back function return accurate scale value. Signed-off-by: Beomho Seo <beomho.seo@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iio: adis16400: Set timestamp as the last element in chan_specMarcus Folkesson
commit c76782d151dab7ecfdcdf9a01561c2d61d9b490f upstream. This is necessary since timestamp is calculated as the last element in iio_compute_scan_bytes(). Without this fix any userspace code reading the layout of the buffer via sysfs will incorrectly interpret the data leading some nasty corruption. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iio: max1363: Use devm_regulator_get_optional for optional regulatorGuenter Roeck
commit 55b40d37311807a6bb2acdae0df904f54a0da3ae upstream. In kernel version 3.13, devm_regulator_get() may return no error if a regulator is undeclared. regulator_get_voltage() will return -EINVAL if this happens. This causes the driver to fail loading if the vref regulator is not declared. Since vref is optional, call devm_regulator_get_optional instead. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22staging:iio:ad799x fix error_free_irq which was freeing an irq that may not ↵Hartmut Knaack
have been requested commit 38408d056188be29a6c4e17f3703c796551bb330 upstream. Only free an IRQ in error_free_irq, if it has been requested previously. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22staging: comedi: adv_pci1710: fix analog output readback valueH Hartley Sweeten
commit 1e85c1ea1ff2a60659e790ef8ec76c7339445841 upstream. The last value written to a analog output channel is cached in the private data of this driver for readback. Currently, the wrong value is cached in the (*insn_write) functions. The current code stores the data[n] value for readback afer the loop has written all the values. At this time 'n' points past the end of the data array. Fix the functions by using a local variable to hold the data being written to the analog output channel. This variable is then used after the loop is complete to store the readback value. The current value is retrieved before the loop in case no values are actually written.. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22staging: r8188eu: Fix typo in USB_DEVICE listLarry Finger
commit 08951f10ae146d0c4114ac508310ad316b6f8798 upstream. There is a typo in the device list that interchanges the vendor and product codes for one of the entries. This exchange was determined by noticing that the vendor code is 0x07b8 for Abocom at http://www.linux-usb.org/usb.ids. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22staging: lustre: fix quotactl permission denied (LU-4530)Cédric Dufour
commit 8b9e418c013e8b671fc10108ab14243f0657bffd upstream. The changes introduced in commit 4b1a25f06b30b203 ("fix build when CONFIG_UIDGID_STRICT_TYPE_CHECKS is on") got the UID check the wrong way around, leading to "Permission denied" when a regular user attempts to retrieve his quota (lfs quota -u ...) but allowing him to retrieve other users quota. Full details at: https://jira.hpdd.intel.com/browse/LU-4530 Cc: Peng Tao <tao.peng@emc.com> Signed-off-by: Cédric Dufour <cedric.dufour@idiap.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb: qcserial: add Netgear Aircard 340UBjørn Mork
commit f948dcf9e9973c05d957bc65b3185682f45feda3 upstream. This device was mentioned in an OpenWRT forum. Seems to have a "standard" Sierra Wireless ifnumber to function layout: 0: qcdm 2: nmea 3: modem 8: qmi 9: storage Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22vt: Fix secure clear screenPetr Písař
commit 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream. \E[3J console code (secure clear screen) needs to update_screen(vc) in order to write-through blanks into off-screen video memory. This has been removed accidentally in 3.6 by: commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c Author: Jean-François Moine <moinejf@free.fr> Date: Thu Sep 6 19:24:13 2012 +0200 tty vt: Fix line garbage in virtual console on command line edition Signed-off-by: Petr Písař <petr.pisar@atlas.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22drm/i915: Pair va_copy with va_end in i915_error_vprintfMika Kuoppala
commit 1d2cb9a54abc6e1d239f28f07661366d5662a94a upstream. Each invocation of va_copy() must be matched by a corresponding invocation of va_end() in the same function. This regression has been introduced in commit e29bb4ebbf000ff9ac081d29784a3331618f012e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Sep 20 10:20:59 2013 +0100 drm/i915: Use a temporary va_list for two-pass string handling Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22drm/radeon: fix UVD IRQ support on SIChristian König
commit b927e1c20462c1ad9caf4c4fa3a30e838a2d4037 upstream. Otherwise decoding isn't really useable. bug: https://bugs.freedesktop.org/show_bug.cgi?id=71448 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22drm/radeon: fix UVD IRQ support on 7xxAlex Deucher
commit 858a41c853cef2cb01de34dae334c19c1c15b237 upstream. Otherwise decoding isn't really useable. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22tty: n_gsm: Fix for modems with brk in modem status controlLars Poeschel
commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream. 3GPP TS 07.10 states in section 5.4.6.3.7: "The length byte contains the value 2 or 3 ... depending on the break signal." The break byte is optional and if it is sent, the length is 3. In fact the driver was not able to work with modems that send this break byte in their modem status control message. If the modem just sends the break byte if it is really set, then weird things might happen. The code for deconding the modem status to the internal linux presentation in gsm_process_modem has already a big comment about this 2 or 3 byte length thing and it is already able to decode the brk, but the code calling the gsm_process_modem function in gsm_control_modem does not encode it and hand it over the right way. This patch fixes this. Without this fix if the modem sends the brk byte in it's modem status control message the driver will hang when opening a muxed channel. Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22lockd: send correct lock when granting a delayed lock.NeilBrown
commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream. If an NFS client attempts to get a lock (using NLM) and the lock is not available, the server will remember the request and when the lock becomes available it will send a GRANT request to the client to provide the lock. If the client already held an adjacent lock, the GRANT callback will report the union of the existing and new locks, which can confuse the client. This happens because __posix_lock_file (called by vfs_lock_file) updates the passed-in file_lock structure when adjacent or over-lapping locks are found. To avoid this problem we take a copy of the two fields that can be changed (fl_start and fl_end) before the call and restore them afterwards. An alternate would be to allocate a 'struct file_lock', initialise it, use locks_copy_lock() to take a copy, then locks_release_private() after the vfs_lock_file() call. But that is a lot more work. Reported-by: Olaf Kirch <okir@suse.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -- v1 had a couple of issues (large on-stack struct and didn't really work properly). This version is much better tested. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2014-02-22hwmon: (ntc_thermistor) Avoid math overflowDoug Anderson
commit d3d89c468ceebbcf9423d1a3d66c5bf91f569570 upstream. The ntc thermistor code was doing math whose temporary result might have overflowed 32-bits. We need some casts in there to make it safe. In one example I found: - pullup_uV: 1800000 - result of iio_read_channel_raw: 3226 - 1800000 * 3226 => 0x15a1cbc80 Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22raw: test against runtime value of max_raw_minorsPaul Bolle
commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream. bind_get() checks the device number it is called with. It uses MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile time while the actual number of raw devices can be set at runtime. This means the test can either be too strict or too lenient. And if the test ends up being too lenient bind_get() might try to access memory beyond what was allocated for "raw_devices". So check against the runtime value (max_raw_minors) in this function. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22serial: sirf: fix kernel panic caused by unpaired spinlockQipan Li
commit fb78b811422cd2d8c8605949cc4cc13618347ad5 upstream. commit 8b9ade9f74f8a279 coming from Viresh Kumar "tty: serial: sirfsoc: drop uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart driver by knic: [ 5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331 [ 5.132554] lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1 [ 5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G W O 3.10.16 #3 [ 5.148866] [<c0013528>] (unwind_backtrace+0x0/0xe0) from [<c0010e70>] (show_stack+0x10/0x14) [ 5.157362] [<c0010e70>] (show_stack+0x10/0x14) from [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) [ 5.166125] [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) from [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) [ 5.175322] [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) from [<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0) [ 5.185120] [<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from [<c0204fb8>] (sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) [ 5.195875] [<c0204fb8>] (sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from [<c0024b50>] (tasklet_action+0x8c/0xec) [ 5.205673] [<c0024b50>] (tasklet_action+0x8c/0xec) from [<c00242a8>] (__do_softirq+0xec/0x1d4) [ 5.214347] [<c00242a8>] (__do_softirq+0xec/0x1d4) from [<c0024428>] (do_softirq+0x48/0x54) [ 5.222674] [<c0024428>] (do_softirq+0x48/0x54) from [<c0024690>] (irq_exit+0x74/0xc0) [ 5.230573] [<c0024690>] (irq_exit+0x74/0xc0) from [<c000e1e8>] (handle_IRQ+0x6c/0x90) [ 5.238465] [<c000e1e8>] (handle_IRQ+0x6c/0x90) from [<c000d500>] (__irq_svc+0x40/0x70) [ 5.246446] [<c000d500>] (__irq_svc+0x40/0x70) from [<c0092e7c>] (mark_page_accessed+0xc/0x68) [ 5.255034] [<c0092e7c>] (mark_page_accessed+0xc/0x68) from [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) [ 5.264402] [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) from [<c00a3b4c>] (unmap_vmas+0x44/0x54) [ 5.273164] [<c00a3b4c>] (unmap_vmas+0x44/0x54) from [<c00a81a8>] (exit_mmap+0xc4/0x1e0) [ 5.281233] [<c00a81a8>] (exit_mmap+0xc4/0x1e0) from [<c001bb78>] (mmput+0x3c/0xdc) [ 5.288868] [<c001bb78>] (mmput+0x3c/0xdc) from [<c0021b0c>] (do_exit+0x30c/0x828) [ 5.296413] [<c0021b0c>] (do_exit+0x30c/0x828) from [<c0022dac>] (do_group_exit+0x4c/0xb0) [ 5.304653] [<c0022dac>] (do_group_exit+0x4c/0xb0) from [<c0022e20>] (__wake_up_parent+0x0/0x18) Root cause: the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart, sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock has not been taken yet. so that caused unpaired lock/unlock. Solution: This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair. Signed-off-by: Qipan Li <Qipan.Li@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22spi: nuc900: Set SPI_LSB_FIRST for master->mode_bits if hw->pdata->lsb is trueAxel Lin
commit f7db1588d6028c97c098bb6445eaabc56a25fed8 upstream. Otherwise, spi_setup() fails with unsupported mode bits message. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22of: fix PCI bus match for PCIe slotsKleber Sacilotto de Souza
commit 14e2abb732e485ee57d9d5b2cb8884652238e5c1 upstream. On IBM pseries systems the device_type device-tree property of a PCIe bridge contains the string "pciex". The of_bus_pci_match() function was looking only for "pci" on this property, so in such cases the bus matching code was falling back to the default bus, causing problems on functions that should be using "assigned-addresses" for region address translation. This patch fixes the problem by also looking for "pciex" on the PCI bus match function. v2: added comment Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: BT Coex - disable BT when TXing probe request in scanEmmanuel Grumbach
commit 8e2a866ef214af4e104ec8d593e3269d8fe66d19 upstream. Not doing so will let BT kill our probe requests leading to failures in scan. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: print the version of the firmware when it assertsEmmanuel Grumbach
commit b900a87b2eb90c0b9586496c82a323a1b8832d73 upstream. This can be useful to be able to spot the firmware version from the error reports without needing to fetch it from another place. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: don't allow A band if SKU forbids itEmmanuel Grumbach
commit c512865446e6dd5b6e91e81187e75b734ad7cfc7 upstream. The driver wasn't reading the NVM properly. While this didn't lead to any issue until now, it seems that there is an old version of the NVM in the wild. In this version, the A band channels appear to be valid but the SKU capabilities (another field of the NVM) says that A band isn't supported at all. With this specific version of the NVM, the driver would think that A band is supported while the HW / firmware don't. This leads to asserts. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22spi: Fix crash with double message finalisation on error handlingGeert Uytterhoeven
commit 1f802f8249a0da536877842c43c7204064c4de8b upstream. This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d. It causes a NULL pointer dereference with drivers using the generic spi_transfer_one_message(), which always calls spi_finalize_current_message(), which zeroes master->cur_msg. Drivers implementing transfer_one_message() theirselves must always call spi_finalize_current_message(), even if the transfer failed: * @transfer_one_message: the subsystem calls the driver to transfer a single * message while queuing transfers that arrive in the meantime. When the * driver is finished with this message, it must call * spi_finalize_current_message() so the subsystem can issue the next * transfer Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22nl80211: Reset split_start when netlink skb is exhaustedPontus Fuchs
commit f12cb2893069495726c21a4b0178705dacfecfe0 upstream. When the netlink skb is exhausted split_start is left set. In the subsequent retry, with a larger buffer, the dump is continued from the failing point instead of from the beginning. This was causing my rt28xx based USB dongle to now show up when running "iw list" with an old iw version without split dump support. Fixes: 3713b4e364ef ("nl80211: allow splitting wiphy information in dumps") Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> [avoid the entire workaround when state->split is set] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22s390: fix kernel crash due to linkage stack instructionsMartin Schwidefsky
commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream. The kernel currently crashes with a low-address-protection exception if a user space process executes an instruction that tries to use the linkage stack. Set the base-ASTE origin and the subspace-ASTE origin of the dispatchable-unit-control-table to point to a dummy ASTE. Set up control register 15 to point to an empty linkage stack with no room left. A user space process with a linkage stack instruction will still crash but with a different exception which is correctly translated to a segmentation fault instead of a kernel oops. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22s390/dump: Fix dump memory detectionMichael Holzheu
commit d7736ff5be31edaa4fe5ab62810c64529a24b149 upstream. Dumps created by kdump or zfcpdump can contain invalid memory holes when dumping z/VM systems that have memory pressure. For example: # zgetdump -i /proc/vmcore. Memory map: 0000000000000000 - 0000000000bfffff (12 MB) 0000000000e00000 - 00000000014fffff (7 MB) 000000000bd00000 - 00000000f3bfffff (3711 MB) The memory detection function find_memory_chunks() issues tprot to find valid memory chunks. In case of CMM it can happen that pages are marked as unstable via set_page_unstable() in arch_free_page(). If z/VM has released that pages, tprot returns -EFAULT and indicates a memory hole. So fix this and switch off CMM in case of kdump or zfcpdump. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v0.10.2 at 2024-07-01 13:00:42 (GMT)