- 19 Feb, 2015 40 commits
-
-
Srihari Vijayaraghavan authored
commit 148e9a71 upstream. On some laptops, keyboard needs to be reset in order to successfully detect touchpad (e.g., some Gigabyte laptop models with Elantech touchpads). Without resettin keyboard touchpad pretends to be completely dead. Based on the original patch by Mateusz Jończyk this version has been expanded to include DMI based detection & application of the fix automatically on the affected models of laptops. This has been confirmed to fix problem by three users already on three different models of laptops. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331Signed-off-by:
Srihari Vijayaraghavan <linux.bug.reporting@gmail.com> Acked-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Tested-by:
Guillaum Bouchard <guillaum.bouchard@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Sasha Levin authored
commit 6ada1fc0 upstream. An unvalidated user input is multiplied by a constant, which can result in an undefined behaviour for large values. While this is validated later, we should avoid triggering undefined behaviour. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> [jstultz: include trivial milisecond->microsecond correction noticed by Andy] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Tobias Jakobi authored
commit 8c38d28b upstream. EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask produces a number outside the range 0x00 to 0xff, which always results in execution of the default switch statement. Obviously this is wrong and git history shows that the bitmask inversion was incorrectly set during a refactoring of the MCT code. Fix this by putting the inversion at the correct position again. Acked-by:
Kukjin Kim <kgene.kim@samsung.com> Reported-by:
GP Orcullo <kinsamanka@gmail.com> Reviewed-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 237d28db upstream. If the function graph tracer traces a jprobe callback, the system will crash. This can easily be demonstrated by compiling the jprobe sample module that is in the kernel tree, loading it and running the function graph tracer. # modprobe jprobe_example.ko # echo function_graph > /sys/kernel/debug/tracing/current_tracer # ls The first two commands end up in a nice crash after the first fork. (do_fork has a jprobe attached to it, so "ls" just triggers that fork) The problem is caused by the jprobe_return() that all jprobe callbacks must end with. The way jprobes works is that the function a jprobe is attached to has a breakpoint placed at the start of it (or it uses ftrace if fentry is supported). The breakpoint handler (or ftrace callback) will copy the stack frame and change the ip address to return to the jprobe handler instead of the function. The jprobe handler must end with jprobe_return() which swaps the stack and does an int3 (breakpoint). This breakpoint handler will then put back the saved stack frame, simulate the instruction at the beginning of the function it added a breakpoint to, and then continue on. For function tracing to work, it hijakes the return address from the stack frame, and replaces it with a hook function that will trace the end of the call. This hook function will restore the return address of the function call. If the function tracer traces the jprobe handler, the hook function for that handler will not be called, and its saved return address will be used for the next function. This will result in a kernel crash. To solve this, pause function tracing before the jprobe handler is called and unpause it before it returns back to the function it probed. Some other updates: Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the code look a bit cleaner and easier to understand (various tries to fix this bug required this change). Note, if fentry is being used, jprobes will change the ip address before the function graph tracer runs and it will not be able to trace the function that the jprobe is probing. Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.orgAcked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Amit Virdi authored
commit 39e60635 upstream. DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This means, the max TRBs that can be submitted for an EP is fixed to 32. Since the request queue for an EP is a linked list, any number of requests can be queued to it by the gadget layer. However, the dwc3 driver must not submit TRBs more than the pool it has created for. This limit wasn't respected when SG was used resulting in submitting more than the max TRBs, eventually leading to non-transfer of the TRBs submitted over the max limit. Root cause: When SG is used, there are two loops iterating to prepare TRBs: - Outer loop over the request_list - Inner loop over the SG list The code was missing break to get out of the outer loop. Fixes: eeb720fb (usb: dwc3: gadget: add support for SG lists) Signed-off-by:
Amit Virdi <amit.virdi@st.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Amit Virdi authored
commit ec512fb8 upstream. When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3 request (dwc3_request). So while preparing TRBs, the 'last' flag should be set only when it is the last TRB being prepared from the last dwc3_request entry. The current implementation uses list_is_last to check if the dwc3_request is the last entry from the request_list. However, list_is_last returns false for the last entry too. This is because, while preparing the first TRB from a request, the function dwc3_prepare_one_trb modifies the request's next and prev pointers while moving the URB to req_queued. Hence, list_is_last always returns false no matter what. The correct way is not to access the modified pointers of dwc3_request but to use list_empty macro instead. Fixes: e5ba5ec8 (usb: dwc3: gadget: fix scatter gather implementation) Signed-off-by:
-
Krzysztof Kozlowski authored
commit 2836766a upstream. Sleep in atomic context happened on Trats2 board after inserting or removing SD card because mmc_gpio_get_cd() was called under spin lock. Fix this by moving card detection earlier, before acquiring spin lock. The mmc_gpio_get_cd() call does not have to be protected by spin lock because it does not access any sdhci internal data. The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After moving it out side of spin lock it could theoretically race with driver removal but still there is no actual protection against manual card eject. Dmesg after inserting SD card: [ 41.663414] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1511 [ 41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1 [ 41.677580] INFO: lockdep is turned off. [ 41.681486] irq event stamp: 61972 [ 41.684872] hardirqs last enabled at (61971): [<c0490ee0>] _raw_spin_unlock_irq+0x24/0x5c [ 41.693118] hardirqs last disabled at (61972): [<c04907ac>] _raw_spin_lock_irq+0x18/0x54 [ 41.701190] softirqs last enabled at (61648): [<c0026fd4>] __do_softirq+0x234/0x2c8 [ 41.708914] softirqs last disabled at (61631): [<c00273a0>] irq_exit+0xd0/0x114 [ 41.716206] Preemption disabled at:[< (null)>] (null) [ 41.721500] [ 41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: G W 3.18.0-rc5-next-20141121 #883 [ 41.732111] Workqueue: kmmcd mmc_rescan [ 41.735945] [<c0014d2c>] (unwind_backtrace) from [<c0011c80>] (show_stack+0x10/0x14) [ 41.743661] [<c0011c80>] (show_stack) from [<c0489d14>] (dump_stack+0x70/0xbc) [ 41.750867] [<c0489d14>] (dump_stack) from [<c0228b74>] (gpiod_get_raw_value_cansleep+0x18/0x30) [ 41.759628] [<c0228b74>] (gpiod_get_raw_value_cansleep) from [<c03646e8>] (mmc_gpio_get_cd+0x38/0x58) [ 41.768821] [<c03646e8>] (mmc_gpio_get_cd) from [<c036d378>] (sdhci_request+0x50/0x1a4) [ 41.776808] [<c036d378>] (sdhci_request) from [<c0357934>] (mmc_start_request+0x138/0x268) [ 41.785051] [<c0357934>] (mmc_start_request) from [<c0357cc8>] (mmc_wait_for_req+0x58/0x1a0) [ 41.793469] [<c0357cc8>] (mmc_wait_for_req) from [<c0357e68>] (mmc_wait_for_cmd+0x58/0x78) [ 41.801714] [<c0357e68>] (mmc_wait_for_cmd) from [<c0361c00>] (mmc_io_rw_direct_host+0x98/0x124) [ 41.810480] [<c0361c00>] (mmc_io_rw_direct_host) from [<c03620f8>] (sdio_reset+0x2c/0x64) [ 41.818641] [<c03620f8>] (sdio_reset) from [<c035a3d8>] (mmc_rescan+0x254/0x2e4) [ 41.826028] [<c035a3d8>] (mmc_rescan) from [<c003a0e0>] (process_one_work+0x180/0x3f4) [ 41.833920] [<c003a0e0>] (process_one_work) from [<c003a3bc>] (worker_thread+0x34/0x4b0) [ 41.841991] [<c003a3bc>] (worker_thread) from [<c003fed8>] (kthread+0xe4/0x104) [ 41.849285] [<c003fed8>] (kthread) from [<c000f268>] (ret_from_fork+0x14/0x2c) [ 42.038276] mmc0: new high speed SDHC card at address 1234 Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 94144a46 ("mmc: sdhci: add get_cd() implementation") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Johan Hovold authored
commit 32a4bf2e upstream. Use tty kref to release the fake tty in usb_console_setup to avoid use after free if the underlying serial driver has acquired a reference. Note that using the tty destructor release_one_tty requires some more state to be initialised. Fixes: 4a90f09b ("tty: usb-serial krefs") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit d269d443 upstream. The USB console currently allocates a temporary fake tty which is used to pass terminal settings to the underlying serial driver. The tty struct is not fully initialised, something which can lead to a lockdep warning (or worse) if a serial driver tries to acquire a line-discipline reference: usbserial: USB Serial support registered for pl2303 pl2303 1-2.1:1.0: pl2303 converter detected usb 1-2.1: pl2303 converter now attached to ttyUSB0 INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 68 Comm: udevd Tainted: G W 3.18.0-rc5 #10 [<c0016f04>] (unwind_backtrace) from [<c0013978>] (show_stack+0x20/0x24) [<c0013978>] (show_stack) from [<c0449794>] (dump_stack+0x24/0x28) [<c0449794>] (dump_stack) from [<c006f730>] (__lock_acquire+0x1e50/0x2004) [<c006f730>] (__lock_acquire) from [<c0070128>] (lock_acquire+0xe4/0x18c) [<c0070128>] (lock_acquire) from [<c027c6f8>] (ldsem_down_read_trylock+0x78/0x90) [<c027c6f8>] (ldsem_down_read_trylock) from [<c027a1cc>] (tty_ldisc_ref+0x24/0x58) [<c027a1cc>] (tty_ldisc_ref) from [<c0340760>] (usb_serial_handle_dcd_change+0x48/0xe8) [<c0340760>] (usb_serial_handle_dcd_change) from [<bf000484>] (pl2303_read_int_callback+0x210/0x220 [pl2303]) [<bf000484>] (pl2303_read_int_callback [pl2303]) from [<c031624c>] (__usb_hcd_giveback_urb+0x80/0x140) [<c031624c>] (__usb_hcd_giveback_urb) from [<c0316fc0>] (usb_giveback_urb_bh+0x98/0xd4) [<c0316fc0>] (usb_giveback_urb_bh) from [<c0042e44>] (tasklet_hi_action+0x9c/0x108) [<c0042e44>] (tasklet_hi_action) from [<c0042380>] (__do_softirq+0x148/0x42c) [<c0042380>] (__do_softirq) from [<c00429cc>] (irq_exit+0xd8/0x114) [<c00429cc>] (irq_exit) from [<c007ae58>] (__handle_domain_irq+0x84/0xdc) [<c007ae58>] (__handle_domain_irq) from [<c000879c>] (omap_intc_handle_irq+0xd8/0xe0) [<c000879c>] (omap_intc_handle_irq) from [<c0014544>] (__irq_svc+0x44/0x7c) Exception stack(0xdf4e7f08 to 0xdf4e7f50) 7f00: debc0b80 df4e7f5c 00000000 00000000 debc0b80 be8da96c 7f20: 00000000 00000128 c000fc84 df4e6000 00000000 df4e7f94 00000004 df4e7f50 7f40: c038ebc0 c038d74c 600f0013 ffffffff [<c0014544>] (__irq_svc) from [<c038d74c>] (___sys_sendmsg.part.29+0x0/0x2e0) [<c038d74c>] (___sys_sendmsg.part.29) from [<c038ec08>] (SyS_sendmsg+0x18/0x1c) [<c038ec08>] (SyS_sendmsg) from [<c000fa00>] (ret_fast_syscall+0x0/0x48) console [ttyUSB0] enabled Fixes: 36697529 ("tty: Replace ldisc locking with ldisc_sem") Signed-off-by:
-
Songjun Wu authored
commit 5fb694f9 upstream. When unloading the module 'g_hid.ko', the urb request will be dequeued and the completion routine will be excuted. If there is no urb packet, the urb request will not be added to the endpoint queue and the completion routine pointer in urb request is NULL. Accessing to this NULL function pointer will cause the Oops issue reported below. Add the code to check if the urb request is in the endpoint queue or not. If the urb request is not in the endpoint queue, a negative error code will be returned. Here is the Oops log: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = dedf0000 [00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000 Internal error: Oops: 80000007 [#1] ARM Modules linked in: g_hid(-) usb_f_hid libcomposite CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2 Hardware name: Atmel SAMA5 (Device Tree) task: df6b1100 ti: dedf6000 task.ti: dedf6000 PC is at 0x0 LR is at usb_gadget_giveback_request+0xc/0x10 pc : [<00000000>] lr : [<c02ace88>] psr: 60000093 sp : dedf7eb0 ip : df572634 fp : 00000000 r10: 00000000 r9 : df52e210 r8 : 60000013 r7 : df6a9858 r6 : df52e210 r5 : df6a9858 r4 : df572600 r3 : 00000000 r2 : ffffff98 r1 : df572600 r0 : df6a9868 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3edf0059 DAC: 00000015 Process rmmod (pid: 923, stack limit = 0xdedf6230) Stack: (0xdedf7eb0 to 0xdedf8000) 7ea0: 00000000 c02adbbc df572580 deced608 7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c 7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00 7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0 [..] [<c02ace88>] (usb_gadget_giveback_request) from [<c02adbbc>] (request_complete+0x64/0x88) [<c02adbbc>] (request_complete) from [<c02aed3c>] (usba_ep_dequeue+0x70/0x128) [<c02aed3c>] (usba_ep_dequeue) from [<bf010c00>] (hidg_unbind+0x50/0x7c [usb_f_hid]) [<bf010c00>] (hidg_unbind [usb_f_hid]) from [<bf00159c>] (remove_config.isra.6+0x98/0x9c [libcomposite]) [<bf00159c>] (remove_config.isra.6 [libcomposite]) from [<bf0031d0>] (__composite_unbind+0x34/0x98 [libcomposite]) [<bf0031d0>] (__composite_unbind [libcomposite]) from [<c02acee0>] (usb_gadget_remove_driver+0x50/0x78) [<c02acee0>] (usb_gadget_remove_driver) from [<c02ad570>] (usb_gadget_unregister_driver+0x64/0x94) [<c02ad570>] (usb_gadget_unregister_driver) from [<bf0160c0>] (hidg_cleanup+0x10/0x34 [g_hid]) [<bf0160c0>] (hidg_cleanup [g_hid]) from [<c0056748>] (SyS_delete_module+0x118/0x19c) [<c0056748>] (SyS_delete_module) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30) Code: bad PC value Signed-off-by:
Songjun Wu <songjun.wu@atmel.com> [nicolas.ferre@atmel.com: reworked the commit message] Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 914a3f3b ("USB: add atmel_usba_udc driver") Signed-off-by:
-
Nicholas Bellinger authored
commit 046ba642 upstream. This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(), which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512 byte sector devices), and for hw_max_sectors is a backend driver dependent value. This limit is problematic because Linux initiators have only recently started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger than 4 MB in size. Currently when this happens, the following message will appear on the target resulting in I/Os being returned with non recoverable status: SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192 Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(), and convert the existing hw_max_sectors into a purely informational attribute used to represent the granuality that backend driver and/or subsystem code is splitting I/Os upon. Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw() to deal with the one special iovec limitiation case. v2 changes: - Drop hw_max_sectors check in sbc_parse_cdb() Reported-by:
Lance Gropper <lance.gropper@qosserver.com> Reported-by:
Stefan Priebe <s.priebe@profihost.ag> Cc: Christoph Hellwig <hch@lst.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> [ kamal: backport to 3.13-stable: context ] Signed-off-by:
-
Alexander Usyskin authored
commit b13a65ef upstream. H_RST bit in H_CSR register may be found lit before reset is started, for example if preceding reset flow hasn't completed. In that case asserting H_RST will be ignored, therefore we need to clean H_RST bit to start a successful reset sequence. 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> [ kamal: backport to 3.13-stable: dev member access ] Signed-off-by:
-
Arseny Solokha authored
commit 56abcab8 upstream. Commit 8dccddbc ("OHCI: final fix for NVIDIA problems (I hope)") introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development board. The code path that was previously specific to NVIDIA controllers had then become taken for all chips. However, the M5237 installed on the board wedges solid when accessing its base+OHCI_FMINTERVAL register, making it impossible to boot any kernel newer than 3.1.8 on this particular and apparently other similar machines. Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237. The patch is suitable for the -next tree as well as all maintained kernels up to 3.2 inclusive. Signed-off-by:
Arseny Solokha <asolokha@kb.kras.ru> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 6d89252a upstream. Commit c3ee9b76 (EHCI: improved logic for isochronous scheduling) introduced the idea of using ehci->last_iso_frame as the origin (or base) for the circular calculations involved in modifying the isochronous schedule. However, the new code it added used ehci->last_iso_frame before the value was properly initialized. This patch rectifies the mistake by moving the initialization lines earlier in iso_stream_schedule(). This fixes Bugzilla #72891. Signed-off-by:
Joe Bryant <tenminjoe@yahoo.com> Tested-by:
Martin Long <martin@longhome.co.uk> Signed-off-by:
-
Reinhard Speyerer authored
commit d80c0d14 upstream. As has been discussed in the thread starting with https://lkml.kernel.org/g/549748e9.d+SiJzqu50f1r4lSAL043YSc@arcor.de Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the option_send_setup() code to be used on the USB interface for the AT port to make unsolicited response codes work correctly. Move these devices from the qcserial driver where they have been added by commit 70a3615f ("usb: qcserial: add Sierra Wireless MC73xx") to the option driver and add a MC73xx-specific blacklist to ensure that 1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces 2. the option driver does not attach to the QMI/network interfaces Signed-off-by:
Reinhard Speyerer <rspmn@arcor.de> Signed-off-by:
-
David Peterson authored
commit 1ae78a48 upstream. Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks devices. Signed-off-by:
David Peterson <david.peterson@cel.com> Signed-off-by:
-
Trond Myklebust authored
commit 1fc0703a upstream. Currently, our trunking code will check for session trunking, but will fail to detect client id trunking. This is a problem, because it means that the client will fail to recognise that the two connections represent shared state, even if they do not permit a shared session. By removing the check for the server minor id, and only checking the major id, we will end up doing the right thing in both cases: we close down the new nfs_client and fall back to using the existing one. Fixes: 05f4c350 ("NFS: Discover NFSv4 server trunking when mounting") Cc: Chuck Lever <chuck.lever@oracle.com> Tested-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 06bed7d1 upstream. This commit fixes a race whereby nlmclnt_init() first starts the lockd daemon, and then calls nlm_bind_host() with the expectation that nlmsvc_timeout has already been initialised. Unfortunately, there is no no synchronisation between lockd() and lockd_up() to guarantee that this is the case. Fix is to move the initialisation of nlmsvc_timeout into lockd_create_svc Fixes: 9a1b6bf8 ("LOCKD: Don't call utsname()->nodename...") Cc: Bruce Fields <bfields@fieldses.org> Signed-off-by:
-
Lennart Sorensen authored
commit 572b24e6 upstream. The switch statement of the possible list of SYSCLK1 frequencies is missing a 0 in 4 out of the 7 frequencies. Fixes: fa6d79d2 ("ARM: OMAP: Add initialisation for the real-time counter") Signed-off-by:
Len Sorensen <lsorense@csclub.uwaterloo.ca> Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Johan Hovold authored
commit b5122236 upstream. Fix null-pointer dereference during probe if the interface-status completion handler is called before the individual ports have been set up. Fixes: f79b2d0f ("USB: keyspan: fix NULL-pointer dereferences and memory leaks") Reported-by:
Richard <richjunk@pacbell.net> Tested-by:
-
Preston Fick authored
commit 90441b4d upstream. Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in production and is not needed. Instead it has been changed to the official production PID (0x8857). Signed-off-by:
Preston Fick <pffick@gmail.com> Signed-off-by:
-
Fabio Estevam authored
commit 7a87e9cb upstream. From Documentation/devicetree/bindings/clock/imx25-clock.txt: cspi1_ipg 78 cspi2_ipg 79 cspi3_ipg 80 , so fix the SPI1 clocks accordingly to avoid a kernel hang when trying to access SPI1. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Gary Bisson authored
commit 81ef4479 upstream. The post dividers do not work on i.MX6Q rev T0 1.0 so they must be fixed to 1. As the table index was wrong, a divider a of 4 could still be requested which implied the clock not to be set properly. This is the root cause of the HDMI not working at high resolution on rev T0 1.0 of the SoC. Signed-off-by:
Gary Bisson <bisson.gary@gmail.com> Signed-off-by:
-
Bo Shen authored
commit 6785a103 upstream. When receive data, the RXRDY in status register set by hardware after a new packet has been stored in the endpoint FIFO. When it is copied from FIFO, this bit is cleared which make the FIFO can be accessed again. In the receive_data() function, this bit RXRDY has been cleared. So, after the receive_data() function return, this bit should not be cleared again, or else it may cause the accessing FIFO corrupt, which will make the data loss. Fixes: 914a3f3b (USB: add atmel_usba_udc driver) Acked-by:
Bo Shen <voice.shen@atmel.com> Signed-off-by:
-
Bo Shen authored
commit f40afddd upstream. According to the datasheet, when transfer using DMA, the control setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN, while for OUT packet, need more two bits END_TR_EN and END_TR_IE to be configured. Fixes: 914a3f3b (USB: add atmel_usba_udc driver) Acked-by:
-
Sebastian Andrzej Siewior authored
commit 68693b8e upstream. since the split of host+gadget mode in commit 74c2e936 ("usb: musb: factor out hcd initalization") we leak the usb_hcd struct. We call now musb_host_cleanup() which does basically usb_remove_hcd() and also sets the hcd variable to NULL. Doing so makes the finall call to musb_host_free() basically a nop and the usb_hcd remains around for ever without anowner. This patch drops that NULL assignment for that reason. Fixes: 74c2e936 ("usb: musb: factor out hcd initalization") Cc: Daniel Mack <zonque@gmail.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Konstantin Khlebnikov authored
commit b800c91a upstream. Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas() ("kernel BUG at mm/rmap.c:399!") caused by commit 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy") Anon_vma_clone() is usually called for a copy of source vma in destination argument. If source vma has anon_vma it should be already in dst->anon_vma. NULL in dst->anon_vma is used as a sign that it's called from anon_vma_fork(). In this case anon_vma_clone() finds anon_vma for reusing. Vma_adjust() calls it differently and this breaks anon_vma reusing logic: anon_vma_clone() links vma to old anon_vma and updates degree counters but vma_adjust() overrides vma->anon_vma right after that. As a result final unlink_anon_vmas() decrements degree for wrong anon_vma. This patch assigns ->anon_vma before calling anon_vma_clone(). Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Reported-and-tested-by:
Chris Clayton <chris2553@googlemail.com> Reported-and-tested-by:
Oded Gabbay <oded.gabbay@amd.com> Reported-and-tested-by:
Chih-Wei Huang <cwhuang@android-x86.org> Acked-by:
Rik van Riel <riel@redhat.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Daniel Forrest <dan.forrest@ssec.wisc.edu> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
commit 690eac53 upstream. Commit fee7e49d ("mm: propagate error from stack expansion even for guard page") made sure that we return the error properly for stack growth conditions. It also theorized that counting the guard page towards the stack limit might break something, but also said "Let's see if anybody notices". Somebody did notice. Apparently android-x86 sets the stack limit very close to the limit indeed, and including the guard page in the rlimit check causes the android 'zygote' process problems. So this adds the (fairly trivial) code to make the stack rlimit check be against the actual real stack size, rather than the size of the vma that includes the guard page. Reported-and-tested-by:
-
Dan Carpenter authored
commit 606185b2 upstream. This is a static checker fix. We write some binary settings to the sysfs file. One of the settings is the "->startup_profile". There isn't any checking to make sure it fits into the pyra->profile_settings[] array in the profile_activated() function. I added a check to pyra_sysfs_write_settings() in both places because I wasn't positive that the other callers were correct. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Vlastimil Babka authored
commit 9e5e3661 upstream. Charles Shirron and Paul Cassella from Cray Inc have reported kswapd stuck in a busy loop with nothing left to balance, but kswapd_try_to_sleep() failing to sleep. Their analysis found the cause to be a combination of several factors: 1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait 2. The process has been killed (by OOM in this case), but has not yet been scheduled to remove itself from the waitqueue and die. 3. kswapd checks for throttled processes in prepare_kswapd_sleep(): if (waitqueue_active(&pgdat->pfmemalloc_wait)) { wake_up(&pgdat->pfmemalloc_wait); return false; // kswapd will not go to sleep } However, for a process that was already killed, wake_up() does not remove the process from the waitqueue, since try_to_wake_up() checks its state first and returns false when the process is no longer waiting. 4. kswapd is running on the same CPU as the only CPU that the process is allowed to run on (through cpus_allowed, or possibly single-cpu system). 5. CONFIG_PREEMPT_NONE=y kernel is used. If there's nothing to balance, kswapd encounters no voluntary preemption points and repeatedly fails prepare_kswapd_sleep(), blocking the process from running and removing itself from the waitqueue, which would let kswapd sleep. So, the source of the problem is that we prevent kswapd from going to sleep until there are processes waiting on the pfmemalloc_wait queue, and a process waiting on a queue is guaranteed to be removed from the queue only when it gets scheduled. This was done to make sure that no process is left sleeping on pfmemalloc_wait when kswapd itself goes to sleep. However, it isn't necessary to postpone kswapd sleep until the pfmemalloc_wait queue actually empties. To prevent processes from being left sleeping, it's actually enough to guarantee that all processes waiting on pfmemalloc_wait queue have been woken up by the time we put kswapd to sleep. This patch therefore fixes this issue by substituting 'wake_up' with 'wake_up_all' and removing 'return false' in the code snippet from prepare_kswapd_sleep() above. Note that if any process puts itself in the queue after this waitqueue_active() check, or after the wake up itself, it means that the process will also wake up kswapd - and since we are under prepare_to_wait(), the wake up won't be missed. Also we update the comment prepare_kswapd_sleep() to hopefully more clearly describe the races it is preventing. Fixes: 5515061d ("mm: throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage") Signed-off-by:
Vladimir Davydov <vdavydov@parallels.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Johannes Weiner authored
commit 2d6d7f98 upstream. Tejun, while reviewing the code, spotted the following race condition between the dirtying and truncation of a page: __set_page_dirty_nobuffers() __delete_from_page_cache() if (TestSetPageDirty(page)) page->mapping = NULL if (PageDirty()) dec_zone_page_state(page, NR_FILE_DIRTY); dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); if (page->mapping) account_page_dirtied(page) __inc_zone_page_state(page, NR_FILE_DIRTY); __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE. Dirtiers usually lock out truncation, either by holding the page lock directly, or in case of zap_pte_range(), by pinning the mapcount with the page table lock held. The notable exception to this rule, though, is do_wp_page(), for which this race exists. However, do_wp_page() already waits for a locked page to unlock before setting the dirty bit, in order to prevent a race where clear_page_dirty() misses the page bit in the presence of dirty ptes. Upgrade that wait to a fully locked set_page_dirty() to also cover the situation explained above. Afterwards, the code in set_page_dirty() dealing with a truncation race is no longer needed. Remove it. Reported-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 7a3ef208 upstream. Constantly forking task causes unlimited grow of anon_vma chain. Each next child allocates new level of anon_vmas and links vma to all previous levels because pages might be inherited from any level. This patch adds heuristic which decides to reuse existing anon_vma instead of forking new one. It adds counter anon_vma->degree which counts linked vmas and directly descending anon_vmas and reuses anon_vma if counter is lower than two. As a result each anon_vma has either vma or at least two descending anon_vmas. In such trees half of nodes are leafs with alive vmas, thus count of anon_vmas is no more than two times bigger than count of vmas. This heuristic reuses anon_vmas as few as possible because each reuse adds false aliasing among vmas and rmap walker ought to scan more ptes when it searches where page is might be mapped. Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu Fixes: 5beb4930 ("mm: change anon_vma linking to fix multi-process server scalability issue") [akpm@linux-foundation.org: fix typo, per Rik] Signed-off-by:
Daniel Forrest <dan.forrest@ssec.wisc.edu> Tested-by:
Jerome Marchand <jmarchan@redhat.com> Reviewed-by:
-
Wei Yang authored
commit 7c2e211f upstream. Current vfio-pci just supports normal pci device, so vfio_pci_probe() will return if the pci device is not a normal device. While current code makes a mistake. PCI_HEADER_TYPE is the offset in configuration space of the device type, but we use this value to mask the type value. This patch fixs this by do the check directly on the pci_dev->hdr_type. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Aaron Plattner authored
commit 60834b73 upstream. Vendor ID 0x10de0072 is used by a yet-to-be-named GPU chip. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Aaron Plattner authored
commit 91947d8c upstream. Vendor ID 0x10de0070 is used by a yet-to-be-named GPU chip. Signed-off-by:
-
Aaron Plattner authored
commit ec5fe988 upstream. Vendor ID 0x10de0071 is used by a yet-to-be-named GPU chip. Signed-off-by:
-
Linus Torvalds authored
commit fee7e49d upstream. Jay Foad reports that the address sanitizer test (asan) sometimes gets confused by a stack pointer that ends up being outside the stack vma that is reported by /proc/maps. This happens due to an interaction between RLIMIT_STACK and the guard page: when we do the guard page check, we ignore the potential error from the stack expansion, which effectively results in a missing guard page, since the expected stack expansion won't have been done. And since /proc/maps explicitly ignores the guard page (commit d7824370: "mm: fix up some user-visible effects of the stack guard page"), the stack pointer ends up being outside the reported stack area. This is the minimal patch: it just propagates the error. It also effectively makes the guard page part of the stack limit, which in turn measn that the actual real stack is one page less than the stack limit. Let's see if anybody notices. We could teach acct_stack_growth() to allow an extra page for a grow-up/grow-down stack in the rlimit test, but I don't want to add more complexity if it isn't needed. Reported-and-tested-by:
Jay Foad <jay.foad@gmail.com> Signed-off-by:
-
Michael S. Tsirkin authored
commit a1eb03f5 upstream. The reason we defer kfree until release function is because it's a general rule for kobjects: kfree of the reference counter itself is only legal in the release function. Previous patch didn't make this clear, document this in code. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Sasha Levin authored
commit 63bd62a0 upstream. A struct device which has just been unregistered can live on past the point at which a driver decides to drop it's initial reference to the kobject gained on allocation. This implies that when releasing a virtio device, we can't free a struct virtio_device until the underlying struct device has been released, which might not happen immediately on device_unregister(). Unfortunately, this is exactly what virtio pci does: it has an empty release callback, and frees memory immediately after unregistering the device. This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE it enabled. To fix, free the memory only once we know the device is gone in the release callback. Signed-off-by:
-
Alex Deucher authored
commit 410cce2a upstream. The check was already in place in the dp mode_valid check, but radeon_dp_get_dp_link_clock() never returned the high clock mode_valid was checking for because that function clipped the clock based on the hw capabilities. Add an explicit check in the mode_valid function. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87172Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
