- 13 Jul, 2016 40 commits
-
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit d246dcb2 upstream. [ 40.467381] ============================================= [ 40.473013] [ INFO: possible recursive locking detected ] [ 40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted [ 40.483466] --------------------------------------------- [ 40.489098] usb/733 is trying to acquire lock: [ 40.493734] (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs] [ 40.502882] [ 40.502882] but task is already holding lock: [ 40.508967] (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs] [ 40.517811] [ 40.517811] other info that might help us debug this: [ 40.524623] Possible unsafe locking scenario: [ 40.524623] [ 40.530798] CPU0 [ 40.533346] ---- [ 40.535894] lock(&(&dev->lock)->rlock); [ 40.540088] lock(&(&dev->lock)->rlock); [ 40.544284] [ 40.544284] *** DEADLOCK *** [ 40.544284] [ 40.550461] May be due to missing lock nesting notation [ 40.550461] [ 40.557544] 2 locks held by usb/733: [ 40.561271] #0: (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48 [ 40.569219] #1: (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs] [ 40.578523] [ 40.578523] stack backtrace: [ 40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37 [ 40.590246] Hardware name: Generic AM33XX (Flattened Device Tree) [ 40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14) [ 40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4) [ 40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994) [ 40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238) [ 40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c) [ 40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs]) [ 40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc]) [ 40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc]) [ 40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs]) [ 40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110) [ 40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114) [ 40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c) [ 40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c) This is caused by the spinlock bug in ep0_read(). Fix the two other deadlock sources in gadgetfs_setup() too. Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Sudip Mukherjee authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit dcb21ad4 upstream. parport subsystem has introduced parport_del_port() to delete a port when it is going away. Without parport_del_port() the registered port will not be unregistered. To reproduce and verify the error: Command to be used is : ls /sys/bus/parport/devices 1) without the device attached there is no output as there is no registered parport. 2) Attach the device, and the command will show "parport0". 3) Remove the device and the command still shows "parport0". 4) Attach the device again and we get "parport1". With the patch applied: 1) without the device attached there is no output as there is no registered parport. 2) Attach the device, and the command will show "parport0". 3) Remove the device and there is no output as "parport0" is now removed. 4) Attach device again to get "parport0" again. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Mathias Nyman authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 3425aa03 upstream. If commands timeout we mark them for abortion, then stop the command ring, and turn the commands to no-ops and finally restart the command ring. If the host is working properly the no-op commands will finish and pending completions are called. If we notice the host is failing, driver clears the command ring and completes, deletes and frees all pending commands. There are two separate cases reported where host is believed to work properly but is not. In the first case we successfully stop the ring but no abort or stop command ring event is ever sent and host locks up. The second case is if a host is removed, command times out and driver believes the ring is stopped, and assumes it will be restarted, but actually ends up timing out on the same command forever. If one of the pending commands has the xhci->mutex held it will block xhci_stop() in the remove codepath which otherwise would cleanup pending commands. Add a check that clears all pending commands in case host is removed, or we are stuck timing out on the same command. Also restart the command timeout timer when stopping the command ring to ensure we recive an ring stop/abort event. Tested-by:
Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit d95815ba upstream. I got one of these cards for testing uas with, it seems that with streams it dma-s all over the place, corrupting memory. On my first tests it managed to dma over the BIOS of the motherboard somehow and completely bricked it. Tests on another motherboard show that it does work with streams disabled. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Thomas Petazzoni authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit de95c40d upstream. On some platforms, the clocks might be registered by a platform driver. When this is the case, the clock platform driver may very well be probed after xhci-plat, in which case the first probe() invocation of xhci-plat will receive -EPROBE_DEFER as the return value of devm_clk_get(). The current code handles that as a normal error, and simply assumes that this means that the system doesn't have a clock for the XHCI controller, and continues probing without calling clk_prepare_enable(). Unfortunately, this doesn't work on systems where the XHCI controller does have a clock, but that clock is provided by another platform driver. In order to fix this situation, we handle the -EPROBE_DEFER error condition specially, and abort the XHCI controller probe(). It will be retried later automatically, the clock will be available, devm_clk_get() will succeed, and the probe() will continue with the clock prepared and enabled as expected. In practice, such issue is seen on the ARM64 Marvell 7K/8K platform, where the clocks are registered by a platform driver. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 04471eb8 upstream. Incorrect cppi dma channel is referenced in musb_rx_dma_iso_cppi41(), which causes kernel NULL pointer reference oops later when calling cppi41_dma_channel_program(). Fixes: 069a3fd1 (usb: musb: Remove ifdefs for musb_host_rx in musb_host.c part1) Reported-by:
Matwey V. Kornilov <matwey@sai.msu.ru> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Andrew Goodbody authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit f3eec0cf upstream. shared_fifo endpoints would only get a previous tx state cleared out, the rx state was only cleared for non shared_fifo endpoints Change this so that the rx state is cleared for all endpoints. This addresses an issue that resulted in rx packets being dropped silently. Signed-off-by:
Andrew Goodbody <andrew.goodbody@cambrionix.com> Signed-off-by:
-
Andrew Goodbody authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 7b2c17f8 upstream. Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was reprogrammed resulting in a warning about such data from musb_rx_reinit before it was thrown away. The data thrown away was a valid packet that had been correctly ACKed which meant the host and device got out of sync. Signed-off-by:
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 84ac5d11 upstream. If the session bit was not set in the backup of devctl register, restoring devctl would clear the session bit. Therefor, only restore devctl register when the session bit was set in the backup. This solves the device enumeration failure in otg mode exposed by commit 56f487c7 (PM / Runtime: Update last_busy in rpm_resume). Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 32cb0b37 upstream. The Acer C120 LED Projector is a USB-3 connected pico projector which takes both its power and video data from USB-3. In combination with some hubs this device does not play well with lpm, so disable lpm for it. Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 81099f97 upstream. Properly sort all the entries by vendor id. Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 593224ea upstream. Commit 198de51d ("USB: uas: Limit qdepth at the scsi-host level") removed the scsi_change_queue_depth() call from uas_slave_configure() assuming that the slave would inherit the host's queue_depth, which that commit sets to the same value. This is incorrect, without the scsi_change_queue_depth() call the slave's queue_depth defaults to 1, introducing a performance regression. This commit restores the call, fixing the performance regression. Fixes: 198de51d ("USB: uas: Limit qdepth at the scsi-host level") Reported-by:
Tom Yan <tom.ty89@gmail.com> Signed-off-by:
-
Mathias Krause authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 055ddaac upstream. Commit 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG") accidentally removed the minimum size check for CRYPTO_MSG_GETALG netlink messages. This allows userland to send a truncated CRYPTO_MSG_GETALG message as short as a netlink header only making crypto_report() operate on uninitialized memory by accessing data beyond the end of the netlink message. Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG messages to the crypto_msg_min[] array. Fixes: 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1601952 commit 19ced623 upstream. The hash buffer is really HASH_BLOCK_SIZE bytes, someone must have thought that memmove takes n*u32 words by mistake. Tests work as good/bad as before after this patch. Cc: Joakim Bech <joakim.bech@linaro.org> Reported-by:
David Binderman <linuxdev.baldrick@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Basil Gunn authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 4a7d99ea ] A socket connection made in ax.25 is not closed when session is completed. The heartbeat timer is stopped prematurely and this is where the socket gets closed. Allow heatbeat timer to run to close socket. Symptom occurs in kernels >= 4.2.0 Originally sent 6/15/2016. Resend with distribution list matching scripts/maintainer.pl output. Signed-off-by:
Basil Gunn <basil@pacabunga.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Daniel Borkmann authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 3697649f ] When we're dealing with clones and the area is not writeable, try harder and get a copy via pskb_expand_head(). Replace also other occurences in tc actions with the new skb_try_make_writable(). Reported-by:
Ashhad Sheikh <ashhadsheikh394@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Feng Tang authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 881d0327 ] Note: This is a verified backported patch for stable 4.4 kernel, and it could also be applied to 4.3/4.2/4.1/3.18/3.16 There is a problem with alx devices, that the network link will be lost in 1-5 minutes after the device is up. >From debugging without datasheet, we found the error always happen when the DMA RX address is set to 0x....fc0, which is very likely to be a HW/silicon problem. This patch will apply rx skb with 64 bytes longer space, and if the allocated skb has a 0x...fc0 address, it will use skb_resever(skb, 64) to advance the address, so that the RX overflow can be avoided. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761Signed-off-by:
Feng Tang <feng.tang@intel.com> Suggested-by:
Eric Dumazet <edumazet@google.com> Tested-by:
Ole Lukoie <olelukoie@mail.ru> Signed-off-by:
-
Nicolas Ferre authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 6bdaa5e9 ] On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the "Reduced" or "Traditional" version of the Media Independent Interface (RMII vs. MII or RGMII vs. GMII). As on the older EMAC version, on GMAC, this switch is set by default to the non-reduced type of interface, so use the existing capability and extend it to GMII as well. We then keep the current logic in the macb_init() function. The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in the macb_config structure to be able to properly enable them with a traditional interface (GMII or MII). Reported-by:
Romain HENRIET <romain.henriet@l-acoustics.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by:
-
David Barroso authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit b560f03d ] neigh_xmit() expects to be called inside an RCU-bh read side critical section, and while one of its two current callers gets this right, the other one doesn't. More specifically, neigh_xmit() has two callers, mpls_forward() and mpls_output(), and while both callers call neigh_xmit() under rcu_read_lock(), this provides sufficient protection for neigh_xmit() only in the case of mpls_forward(), as that is always called from softirq context and therefore doesn't need explicit BH protection, while mpls_output() can be called from process context with softirqs enabled. When mpls_output() is called from process context, with softirqs enabled, we can be preempted by a softirq at any time, and RCU-bh considers the completion of a softirq as signaling the end of any pending read-side critical sections, so if we do get a softirq while we are in the part of neigh_xmit() that expects to be run inside an RCU-bh read side critical section, we can end up with an unexpected RCU grace period running right in the middle of that critical section, making things go boom. This patch fixes this impedance mismatch in the callee, by making neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that expects to be treated as an RCU-bh read side critical section, as this seems a safer option than fixing it in the callers. Fixes: 4fd3d7d9 ("neigh: Add helper function neigh_xmit") Signed-off-by:
David Barroso <dbarroso@fastly.com> Signed-off-by:
Lennert Buytenhek <lbuytenhek@fastly.com> Acked-by:
David Ahern <dsa@cumulusnetworks.com> Acked-by:
Robert Shearman <rshearma@brocade.com> Signed-off-by:
-
Daniel Borkmann authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit ceb56070 ] Commit dead9f29 ("perf: Fix race in BPF program unregister") moved destruction of BPF program from free_event_rcu() callback to __free_event(), which is problematic if used with tail calls: if prog A is attached as trace event directly, but at the same time present in a tail call map used by another trace event program elsewhere, then we need to delay destruction via RCU grace period since it can still be in use by the program doing the tail call (the prog first needs to be dropped from the tail call map, then trace event with prog A attached destroyed, so we get immediate destruction). Fixes: dead9f29 ("perf: Fix race in BPF program unregister") Signed-off-by:
-
Willem de Bruijn authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 9a0fee2b ] Diag intends to broadcast tcp_sk and udp_sk socket destruction. Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not sufficient for this. Raw sockets can have the same type. Add a test for sk->sk_type. Fixes: eb4cb008 ("sock_diag: define destruction multicast groups") Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
daniel authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 0888d5f3 ] The bridge is falsly dropping ipv6 mulitcast packets if there is: 1. No ipv6 address assigned on the brigde. 2. No external mld querier present. 3. The internal querier enabled. When the bridge fails to build mld queries, because it has no ipv6 address, it slilently returns, but keeps the local querier enabled. This specific case causes confusing packet loss. Ipv6 multicast snooping can only work if: a) An external querier is present OR b) The bridge has an ipv6 address an is capable of sending own queries Otherwise it has to forward/flood the ipv6 multicast traffic, because snooping cannot work. This patch fixes the issue by adding a flag to the bridge struct that indicates that there is currently no ipv6 address assinged to the bridge and returns a false state for the local querier in __br_multicast_querier_exists(). Special thanks to Linus Lüssing. Fixes: d1d81d4c ("bridge: check return value of ipv6_dev_get_saddr()") Signed-off-by:
Daniel Danzberger <daniel@dd-wrt.com> Acked-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
-
Tom Goff authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 70a0dec4 ] This fixes wrong-interface signaling on 32-bit platforms for entries created when jiffies > 2^31 + MFC_ASSERT_THRESH. Signed-off-by:
Tom Goff <thomas.goff@ll.mit.edu> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 21de12ee ] If the packet was dropped by lower qdisc, then we must not access it later. Save qdisc_pkt_len(skb) in a temp variable. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 962fcef3 ] Blair Steven noticed that ESN in conjunction with UDP encapsulation is broken because we set the temporary ESP header to the wrong spot. This patch fixes this by first of all using the right spot, i.e., 4 bytes off the real ESP header, and then saving this information so that after encryption we can restore it properly. Fixes: 7021b2e1 ("esp4: Switch to new AEAD interface") Reported-by:
Blair Steven <Blair.Steven@alliedtelesis.co.nz> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Simon Horman authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit d5d8760b ] Since 32b8a8e5 ("sit: add IPv4 over IPv4 support") ipip6_err() may be called for packets whose IP protocol is IPPROTO_IPIP as well as those whose IP protocol is IPPROTO_IPV6. In the case of IPPROTO_IPIP packets the correct protocol value is not passed to ipv4_update_pmtu() or ipv4_redirect(). This patch resolves this problem by using the IP protocol of the packet rather than a hard-coded value. This appears to be consistent with the usage of the protocol of a packet by icmp_socket_deliver() the caller of ipip6_err(). I was able to exercise the redirect case by using a setup where an ICMP redirect was received for the destination of the encapsulated packet. However, it appears that although incorrect the protocol field is not used in this case and thus no problem manifests. On inspection it does not appear that a problem will manifest in the fragmentation needed/update pmtu case either. In short I believe this is a cosmetic fix. None the less, the use of IPPROTO_IPV6 seems wrong and confusing. Reviewed-by:
Dinan Gunawardena <dinan.gunawardena@netronome.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Acked-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Jason A. Donenfeld authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit daddef76 ] The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG case was added with 2c94b537 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the usual definition of the dynamic_pr_debug macro, but alter it by adding a call to "net_ratelimit()" in the if statement. This is, in fact, the correct approach. However, while doing this, the author of the commit forgot to surround fmt by pr_fmt, resulting in unprefixed log messages appearing in the console. So, this commit adds back the pr_fmt(fmt) invocation, making net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and DYNAMIC_DEBUG cases, and bringing parity with the behavior of dynamic_pr_debug as well. Fixes: 2c94b537 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Cc: Tim Bingham <tbingham@akamai.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1601952 [ Upstream commit 6c0d54f1 ] When the qdisc is full, we drop a packet at the head of the queue, queue the current skb and return NET_XMIT_CN Now we track backlog on upper qdiscs, we need to call qdisc_tree_reduce_backlog(), even if the qlen did not change. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Ursula Braun authored
BugLink: http://bugs.launchpad.net/bugs/1601831 A qeth_card contains a napi_struct linked to the net_device during device probing. This struct must be deleted when removing the qeth device, otherwise Panic on oops can occur when qeth devices are repeatedly removed and added. Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline") Cc: stable@vger.kernel.org # v2.6.37+ Signed-off-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Tested-by:
Alexander Klein <ALKL@de.ibm.com> Signed-off-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Rodrigo Vivi authored
BugLink: http://bugs.launchpad.net/bugs/1600124 This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them before they become used in any other future platform. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466718636-19675-2-git-send-email-rodrigo.vivi@intel.com (cherry picked from drm-intel-next-queued commit a922eb8d) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by:
-
Rodrigo Vivi authored
BugLink: http://bugs.launchpad.net/bugs/1600124 The spec has been updated adding new PCI IDs. Signed-off-by:
-
Rodrigo Vivi authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Some Kabylake SKUs are going to use Kabypoint PCH. It is mainly for Halo and DT ones. From our specs it doesn't seem that KBP brings any change on the display south engine. So let's consider this as a continuation of SunrisePoint, i.e., SPT+. Since it is easy to get confused by a letter change: KBL = Kabylake - CPU/GPU codename. KBP = Kabypoint - PCH codename. Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1599109 This commit has been reported to cause some flicker issues on a specific Skylake machine https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html So revert this for now until a proper fix for the issue is provided: commit a0562819 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Apr 11 10:23:51 2016 +0300 drm/i915: Get panel_type from OpRegion panel details Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1599109 This commit squashes together the following commits backported from drm-intel-next-queued so that they apply on top of v4.7: d1b4eefd drm/i915/gen9: Add WaFbcHighMemBwCorruptionAvoidance 031cd8c8 drm/i195/fbc: Add WaFbcNukeOnHostModify 303d4ea5 drm/i915/gen9: Add WaFbcWakeMemOn 0f78dee6 drm/i915/gen9: Add WaFbcTurnOffFbcWatermark 066d4628 drm/i915/kbl: Add WaClearSlmSpaceAtContextSwitch 71dce58c drm/i915/skl: Extend WaDisableChickenBitTSGBarrierAckForFFSliceCS 590e8ff0 drm/i915/gen9: Add WaEnableChickenDCPR 954337aa drm/i915/kbl: Add WaDisableSbeCacheDispatchPortSharing 4de5d7cc drm/i915/kbl: Add WaDisableGafsUnitClkGating 0b2d0934 drm/i915/kbl: Add WaForGAMHang 44fff99f drm/i915/skl: Add WAC6entrylatency 6fc29133 drm/i915/gen9: Add WaDisableSkipCaching ad2bdb44 drm/i915: Add WaInsertDummyPushConstP for bxt and kbl c0b730d5 drm/i915/kbl: Add WaDisableDynamicCreditSharing 8aeb7f62 drm/i915/kbl: Add WaDisableGamClockGating b033bb6d drm/i915/gen9: Enable must set chicken bits in config0 reg fe905819 drm/i915/kbl: Add WaDisableLSQCROPERFforOCL 17e0adf0 drm/i915/edp: Add WaKVMNotificationOnConfigChange:bdw 9498dba7 drm/i915/kbl: Add WaDisableSDEUnitClockGating 8401d42f drm/i915/kbl: Add WaDisableFenceDestinationToSLM for A0 e587f6cb drm/i915/kbl: Add WaEnableGapsTsvCreditFix bbaefe72 drm/i915: Mimic skl with WaForceEnableNonCoherent 5b0e3659 drm/i915/gen9: Always apply WaForceContextSaveRestoreNonCohe 6e4f10c3 drm/i915/kbl: Add WaSkipStolenMemoryFirstPage for A0 c033a37c drm/i915/kbl: Add REVID macro e5f81d65 drm/i915/kbl: Init gen9 workarounds eee8efb0 drm/i915/skl: Add WaDisableGafsUnitClkGating 6bb62855 drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Sync i915_bpo with v4.7-rc6. Revert a bunch of commits from it to let it build without pulling a ton of core drm changes. 3ed605bc kernel.h: add u64_to_user_ptr() 2347aa7c drm: i915: Explicitly apply PWM config extracted from pwm_args 0552f765 drm/i915/mst: use reference counted connectors. (v3) 8863dc7f drm/i915: Correctly refcount connectors in hw state readou" ec2dc6a0 drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state 80a89a5e drm/i915: make i915_gem_mmap_ioctl wait for mmap_sem killable e87666b5 drm/i915/shrinker: Hook up vmap allocation failure notifier 168cf367 drm/i915/shrinker: Refactor common uninterruptible locking eae2c43b drm/i915/shrinker: Restrict vmap purge to objects with vmaps 1768d455 drm/i915/shrinker: Report "unevictable" pages 1bec9b0b drm/i915/shrinker: Only shmemfs objects are backed by swap 747a598f drm/mode: introduce wrapper to read framebuffer refcount. 1d2ac403 drm: Protect dev->filelist with its own mutex cab10327 drm/i915: Fix missing unlock on error in i915_ppgtt_info() a8ad0bd8 drm: Remove unused drm_device from drm_gem_object_lookup() Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Backport header bits of commit f2a85e19 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Apr 8 12:11:13 2016 +0100 drm,i915: Introduce drm_malloc_gfp() Signed-off-by:
-
Liu Ying authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Add a helper that can be used to obtain the number of bits per pixel corresponding to a given MIPI DSI pixel format. This is useful in bandwidth calculations, for example. Signed-off-by:
Liu Ying <Ying.Liu@freescale.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Chris Zhong <zyw@rock-chips.com> [treding@nvidia.com: add kerneldoc comment and commit message] Signed-off-by:
-
Lionel Landwerlin authored
BugLink: http://bugs.launchpad.net/bugs/1599109 When extracting the value at full precision (16 bits), no need to round the value. This was spotted by Jani when running sparse. Unfortunately this fix doesn't get rid of the warning. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reported-by:
Jani Nikula <jani.nikula@intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: dri-devel@lists.freedesktop.org Fixes: 5488dc16 ("drm: introduce pipe color correction properties") Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458655833-19547-1-git-send-email-lionel.g.landwerlin@intel.com (cherry picked from commit 644a8050) Signed-off-by:
-
Lionel Landwerlin authored
BugLink: http://bugs.launchpad.net/bugs/1599109 562c5b4d didn't quite fix the issue of dealing with an error pointer. We can't free/unref an error pointer so reset it to NULL. Many thanks to Dan Carpenter for pointing this out again. Signed-off-by:
-
Lionel Landwerlin authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Check properly that the allocated blob's pointer is valid. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Daniel Stone <daniels@collabora.com> Fixes: 5488dc16 ("drm: introduce pipe color correction properties") Signed-off-by:
-
