- 19 Feb, 2015 39 commits
-
-
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:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
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:
Johan Hovold <johan@kernel.org> [ kamal: backport to 3.13-stable: context ] 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:
Sasha Levin <sasha.levin@oracle.com> 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:
-
Alex Deucher authored
commit fbedf1c3 upstream. Enable all three in the driver. Early documentation indicated the 3rd one was used for something else, but that is not the case. v2: handle disable as well Signed-off-by:
-
Takashi Iwai authored
commit c507de88 upstream. stac_store_hints() does utterly wrong for masking the values for gpio_dir and gpio_data, likely due to copy&paste errors. Fortunately, this feature is used very rarely, so the impact must be really small. Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Felipe Balbi authored
commit 7ce67a38 upstream. The CPSW IP implements pulse-signaled interrupts. Due to that we must write a correct, pre-defined value to the CPDMA_MACEOIVECTOR register so the controller generates a pulse on the correct IRQ line to signal the End Of Interrupt. The way the driver is written today, all four IRQ lines are requested using the same IRQ handler and, because of that, we could fall into situations where a TX IRQ fires but we tell the controller that we ended an RX IRQ (or vice-versa). This situation triggers an IRQ storm on the reserved IRQ 127 of INTC which will in turn call ack_bad_irq() which will, then, print a ton of: unexpected IRQ trap at vector 00 In order to fix the problem, we are moving all calls to cpdma_ctlr_eoi() inside the IRQ handler and making sure we *always* write the correct value to the CPDMA_MACEOIVECTOR register. Note that the algorithm assumes that IRQ numbers and value-to-be-written-to-EOI are proportional, meaning that a write of value 0 would trigger an EOI pulse for the RX_THRESHOLD Interrupt and that's the IRQ number sitting in the 0-th index of our irqs_table array. This, however, is safe at least for current implementations of CPSW so we will refrain from making the check smarter (and, as a side-effect, slower) until we actually have a platform where IRQ lines are swapped. This patch has been tested for several days with AM335x- and AM437x-based platforms. AM57x was left out because there are still pending patches to enable ethernet in mainline for that platform. A read of the TRM confirms the statement on previous paragraph. Reported-by:
Yegor Yefremov <yegorslists@googlemail.com> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly) Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Mugunthan V N authored
commit f63a975e upstream. When the Ethernet interface is put down and up with heavy Ethernet traffic, then there is prossibility of an interrupt waiting in irq controller to be processed, so when the interface is brought up again just after enable interrupt, it goes to ISR due to the previous unhandled interrutp and in ISR napi is not scheduled as the napi is not enabled in ndo_open which results in disabled interrupt for CPSW and no packets are received in cpsw. So this patch moves enabling of interupts after napi_enable and clearing CPDMA interrupts. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Andy Lutomirski authored
commit 1ddf0b1b upstream. In Linux 3.18 and below, GCC hoists the lsl instructions in the pvclock code all the way to the beginning of __vdso_clock_gettime, slowing the non-paravirt case significantly. For unknown reasons, presumably related to the removal of a branch, the performance issue is gone as of e76b027e x86,vdso: Use LSL unconditionally for vgetcpu but I don't trust GCC enough to expect the problem to stay fixed. There should be no correctness issue, because the __getcpu calls in __vdso_vlock_gettime were never necessary in the first place. Note to stable maintainers: In 3.18 and below, depending on configuration, gcc 4.9.2 generates code like this: 9c3: 44 0f 03 e8 lsl %ax,%r13d 9c7: 45 89 eb mov %r13d,%r11d 9ca: 0f 03 d8 lsl %ax,%ebx This patch won't apply as is to any released kernel, but I'll send a trivial backported version if needed. [ Backported by Andy Lutomirski. Should apply to all affected versions. This fixes a functionality bug as well as a performance bug: buggy kernels can infinite loop in __vdso_clock_gettime on affected compilers. See, for exammple: https://bugzilla.redhat.com/show_bug.cgi?id=1178975 ] Fixes: 51c19b4f x86: vdso: pvclock gettime support Cc: Marcelo Tosatti <mtosatti@redhat.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> [ luis: backported to 3.16: used Andy's backport for stable kernels ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7d47559e upstream. The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 38af6096 upstream. Looks like 830M doesn't quite like it when you try to move a plane from one pipe to another. It seems that the plane's old pipe has to be active even if the plane is already disabled, otherwise the relevant register just won't accept new values. The following commit: commit 1f1c2e24 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Nov 28 17:30:01 2013 +0200 drm/i915: Swap primary planes on gen2 for FBC caused a regression on 830M. It will attempt to swap the planes when the driver is loaded, but at that time only pipe A might be active, so plane A gets disabled, but plane B won't get enabled since pipe B is not active when we try to move the plane over to pipe A. There's no reason to swap planes on 830M since it doesn't support FBC. Change the logic a bit to limit the plane swapping to platforms which actually support FBC. This should avoid getting a black screen on 830M. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
commit 1f1c2e24 upstream. Only plane A is FBC capable on gen2 (like gen3), but the panel fitter is hooked up to pipe B, so we want to prefer pipe B + plane A. Signed-off-by:
-
- 18 Feb, 2015 1 commit
-
-
Steev Klimaszewski authored
commit 007487f1 upstream. Currently we enable Exynos devices in the multi v7 defconfig, however, when testing on my ODROID-U3, I noticed that USB was not working. Enabling this option causes USB to work, which enables networking support as well since the ODROID-U3 has networking on the USB bus. [arnd] Support for odroid-u3 was added in 3.10, so it would be nice to backport this fix at least that far. Signed-off-by:
Steev Klimaszewski <steev@gentoo.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
