- 13 Jul, 2016 40 commits
-
-
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:
David S. Miller <davem@davemloft.net> 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>
-
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:
Eric Dumazet <edumazet@google.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Acked-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:
-
Lionel Landwerlin authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix and finally another lookup into a gamma table. The following properties can be added to a pipe : - DEGAMMA_LUT : blob containing degamma LUT - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT - CTM : transformation matrix applied after the degamma LUT - GAMMA_LUT : blob containing gamma LUT - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by the driver to tell userspace applications what sizes should be the lookup tables in DEGAMMA_LUT and GAMMA_LUT. A helper is also provided so legacy gamma correction is redirected through these new properties. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used v4: Update contributors v5: Rename CTM_MATRIX property to CTM (Doh!) Add legacy gamma_set atomic helper Describe CTM/LUT acronyms in the kernel doc v6: Fix missing blob unref in drm_atomic_helper_crtc_reset Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by:
Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Acked-by:
Rob Bradford <robert.bradford@intel.com> [danvet: CrOS maintainers are also happy with the userspacde side: https://codereview.chromium.org/1182063002/ ] Reviewed-by:
-
Markus Elfring authored
BugLink: http://bugs.launchpad.net/bugs/1599109 The drm_property_unreference_blob() function tests whether its argument is NULL and then returns immediately. Thus the tests around the calls are not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Link: http://patchwork.freedesktop.org/patch/msgid/563C8B3E.405@users.sourceforge.netSigned-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1599109 Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit ede53344) Signed-off-by:
-
Rafael Antognolli authored
BugLink: http://bugs.launchpad.net/bugs/1599109 The module_init and module_exit functions will start here, and call the subsequent init's and exit's. v10: - Keep __init on drm_fb_helper init function. - Move MODULE_* macros to the common file. Signed-off-by:
Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1599379 Apparently some CHV boards failed to hook up the port presence straps for HDMI ports as well (earlier we assumed this problem only affected eDP ports). So let's check the VBT in addition to the strap, and if either one claims that the port is present go ahead and register the relevant connector. While at it, change port D to register DP before HDMI as we do for ports B and C since commit 457c52d8 ("drm/i915: Only ignore eDP ports that are connected") Also print a debug message when we register a HDMI connector to aid in diagnosing missing/incorrect ports. We already had such a print for DP/eDP. v2: Improve the comment in the code a bit, note the port D change in the commit message Cc: Radoslav Duda <radosd@radosd.com> Tested-by:
Radoslav Duda <radosd@radosd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96321Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 22f35042) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1599379 If the VBT says that a certain port should be eDP (and hence fused off from HDMI), but in reality it isn't, we need to try and acquire the HDMI connection instead. So only trust the VBT edp setting if we can connect to an eDP device on that port. Fixes: d2182a66 (drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV) References: https://bugs.freedesktop.org/show_bug.cgi?id=96288Signed-off-by:
-
Cathy Avery authored
BugLink: http://bugs.launchpad.net/bugs/1590655Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Gavin Shan authored
BugLink: http://bugs.launchpad.net/bugs/1599250 In commit 8445a87f "powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism", the PE address was replaced with the PCI config address in order to remove dependency on EEH. According to PAPR spec, firmware (pHyp or QEMU) should accept "xxBBSSxx" format PCI config address, not "xxxxBBSS" provided by the patch. Note that "BB" is PCI bus number and "SS" is the combination of slot and function number. This fixes the PCI address passed to DDW RTAS calls. Fixes: 8445a87f ("powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism") Cc: stable@vger.kernel.org # v3.4+ Reported-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Tested-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 8a934efe) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1599250 Commit 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn") changed the pci_dn struct by removing its EEH-related members. As part of this clean-up, DDW mechanism was modified to read the device configuration address from eeh_dev struct. As a consequence, now if we disable EEH mechanism on kernel command-line for example, the DDW mechanism will fail, generating a kernel oops by dereferencing a NULL pointer (which turns to be the eeh_dev pointer). This patch just changes the configuration address calculation on DDW functions to a manual calculation based on pci_dn members instead of using eeh_dev-based address. No functional changes were made. This was tested on pSeries, both in PHyp and qemu guest. Fixes: 39baadbf ("powerpc/eeh: Remove eeh information from pci_dn") Cc: stable@vger.kernel.org # v3.4+ Reviewed-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1599250 This reverts commit 89a51df5. The function eeh_add_device_early() is used to perform EEH initialization in devices added later on the system, like in hotplug/DLPAR scenarios. Since the commit 89a51df5 ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell") a new check was introduced in this function - Cell has no EEH capabilities which led to kernel oops if hotplug was performed, so checking for eeh_enabled() was introduced to avoid the issue. However, in architectures that EEH is present like pSeries or PowerNV, we might reach a case in which no PCI devices are present on boot time and so EEH is not initialized. Then, if a device is added via DLPAR for example, eeh_add_device_early() fails because eeh_enabled() is false, and EEH end up not being enabled at all. This reverts the aforementioned patch since a new verification was introduced by the commit d91dafc0 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore. Cc: stable@vger.kernel.org # v4.1+ Reviewed-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1599250 This reverts commit 623aabd5. Signed-off-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1597971 The test_fp_ctl function is used to test if a given value is a valid floating-point control. The inline assembly in test_fp_ctl uses an incorrect constraint for the 'orig_fpc' variable. If the compiler chooses the same register for 'fpc' and 'orig_fpc' the test_fp_ctl() function always returns true. This allows user space to trigger kernel oopses with invalid floating-point control values on the signal stack. This problem has been introduced with git commit 4725c860 "s390: fix save and restore of the floating-point-control register" Cc: stable@vger.kernel.org # v3.13+ Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit bcf4dd5f) Signed-off-by:
-
Joseph Salisbury authored
BugLink: http://bugs.launchpad.net/bugs/1498667 As reported in BugLink, this device has an issue with Linux Power Management so adding a quirk. This quirk was reccomended by Alan Stern: http://lkml.iu.edu/hypermail/linux/kernel/1606.2/05590.htmlSigned-off-by:
-
Manoj Iyer authored
BugLink: http://bugs.launchpad.net/bugs/1599347 Add echi_msm to usb-modules to enable DI to detect USB on Qualcomm EHCI host controller. Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Acked-by:
-
Libin Yang authored
BugLink: http://bugs.launchpad.net/bugs/1596871 Defer to register acomp eld notifier until hdmi audio driver is fully ready. After registering eld notifier, gfx driver can use this callback function to notify audio driver the monitor connection event. However this action may happen when audio driver is adding the pins or doing other initialization. This is not always safe, however. For example, using per_pin->lock before the lock is initialized. Let's register the eld notifier after the initialization is done. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (backport from commit 790b415c) Signed-off-by:
Hui Wang <hui.wang@canonical.com> Acked-by:
-
Libin Yang authored
BugLink: http://bugs.launchpad.net/bugs/1596871 To make sure audio_ptr is set before intel_audio_codec_enable() or intel_audio_codec_disable() calling pin_eld_notify(), this patch adds wmb barrier to prevent optimizing. Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1596871 The ELD notification can be received asynchronously from the graphics side, and this may happen just at the moment the sound driver is processing the suspend or the resume, and it would confuse the whole procedure. Since the ELD and connection states are updated in anyway at the end of the resume, we can skip it when received during PM process. Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1599257 Sync kernel with changes in spl 0.6.5.6-0ubuntu4 This delta just updates the spl splat test module (which is just used for regression testing), no core spl functionality is changed. The sync also pulls in some redhat spec files that landed in spl since the last sync, this are not used either but are included by the automated sync scripts. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Ricardo Salveti authored
BugLink: http://bugs.launchpad.net/bugs/1597574Signed-off-by:
Ricardo Salveti <rsalveti@rsalveti.net> Signed-off-by:
-
Ricardo Salveti authored
BugLink: http://bugs.launchpad.net/bugs/1597573Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1586418 An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null pointer dereference in devpts_kill_index because tty->link->driver_data is NULL. The oops was triggered with the pty stressor in stress-ng when in a low memory condition. tty_init_dev tries to clean up a tty_ldisc_setup ENOMEM error by calling release_tty, however, this ultimately tries to clean up the NULL pair'd tty in pty_unix98_remove, triggering the Oops. Add check to pty_unix98_remove to only clean up fsi if it is not NULL. Ooops: ops: 0000 [#1] SMP [ 23.020976] Modules linked in: ppdev snd_hda_codec_generic snd_hda_intel snd_hda_codec parport_pc snd_hda_core snd_hwdep parport snd_pcm input_leds joydev snd_timer serio_raw snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel qxl aes_x86_64 ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect psmouse sysimgblt floppy fb_sys_fops drm pata_acpi jitterentropy_rng drbg ansi_cprng [ 23.020978] CPU: 0 PID: 1452 Comm: stress-ng-pty Not tainted 4.7.0-rc4+ #2 [ 23.020978] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 23.020979] task: ffff88007ba30000 ti: ffff880078ea8000 task.ti: ffff880078ea8000 [ 23.020981] RIP: 0010:[<ffffffff813f11ff>] [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.020981] RSP: 0018:ffff880078eabb60 EFLAGS: 00010a03 [ 23.020982] RAX: 4444444444444567 RBX: 0000000000000000 RCX: 000000000000001f [ 23.020982] RDX: 000000000000014c RSI: 000000000000026f RDI: 0000000000000000 [ 23.020982] RBP: ffff880078eabb70 R08: 0000000000000004 R09: 0000000000000036 [ 23.020983] R10: 000000000000026f R11: 0000000000000000 R12: 000000000000026f [ 23.020983] R13: 000000000000026f R14: ffff88007c944b40 R15: 000000000000026f [ 23.020984] FS: 00007f9a2f3cc700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 23.020984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.020985] CR2: 0000000000000010 CR3: 000000006c81b000 CR4: 00000000001406f0 [ 23.020988] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 23.020988] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 23.020988] Stack: [ 23.020989] 0000000000000000 000000000000026f ffff880078eabb90 ffffffff812a5a99 [ 23.020990] 0000000000000000 00000000fffffff4 ffff880078eabba8 ffffffff814f9cbe [ 23.020991] ffff88007965c800 ffff880078eabbc8 ffffffff814eef43 fffffffffffffff4 [ 23.020991] Call Trace: [ 23.021000] [<ffffffff812a5a99>] devpts_kill_index+0x29/0x50 [ 23.021002] [<ffffffff814f9cbe>] pty_unix98_remove+0x2e/0x50 [ 23.021006] [<ffffffff814eef43>] release_tty+0xb3/0x1b0 [ 23.021007] [<ffffffff814f18d4>] tty_init_dev+0xd4/0x1c0 [ 23.021011] [<ffffffff814f9fae>] ptmx_open+0xae/0x190 [ 23.021013] [<ffffffff812254ef>] chrdev_open+0xbf/0x1b0 [ 23.021015] [<ffffffff8121d973>] do_dentry_open+0x203/0x310 [ 23.021016] [<ffffffff81225430>] ? cdev_put+0x30/0x30 [ 23.021017] [<ffffffff8121ee44>] vfs_open+0x54/0x80 [ 23.021018] [<ffffffff8122b8fc>] ? may_open+0x8c/0x100 [ 23.021019] [<ffffffff8122f26b>] path_openat+0x2eb/0x1440 [ 23.021020] [<ffffffff81230534>] ? putname+0x54/0x60 [ 23.021022] [<ffffffff814f6f97>] ? n_tty_ioctl_helper+0x27/0x100 [ 23.021023] [<ffffffff81231651>] do_filp_open+0x91/0x100 [ 23.021024] [<ffffffff81230596>] ? getname_flags+0x56/0x1f0 [ 23.021026] [<ffffffff8123fc66>] ? __alloc_fd+0x46/0x190 [ 23.021027] [<ffffffff8121f1e4>] do_sys_open+0x124/0x210 [ 23.021028] [<ffffffff8121f2ee>] SyS_open+0x1e/0x20 [ 23.021035] [<ffffffff81845576>] entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 23.021044] Code: 63 28 45 31 e4 eb dd 0f 1f 44 00 00 55 4c 63 d6 48 ba 89 88 88 88 88 88 88 88 4c 89 d0 b9 1f 00 00 00 48 f7 e2 48 89 e5 41 54 53 <8b> 47 10 48 89 fb 8d 3c c5 00 00 00 00 48 c1 ea 09 b8 01 00 00 [ 23.021045] RIP [<ffffffff813f11ff>] ida_remove+0x1f/0x120 [ 23.021045] RSP <ffff880078eabb60> [ 23.021046] CR2: 0000000000000010 Signed-off-by:
-
Pavel Rojtberg authored
BugLink: http://bugs.launchpad.net/bugs/1574102 otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27Signed-off-by:
Pavel Rojtberg <rojtberg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit 4efc6939) Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1597867 Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults with everything fine at SPU. This patch tries to reinitialize LMAC to fix it. Also fixed LMAC disable sequence to properly bring down link. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
Tao Wang <tao.wang@cavium.com> Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1596575Signed-off-by:
-
Maarten Lankhorst authored
BugLink: http://bugs.launchpad.net/bugs/1596575 commit f2d580b9 upstream. It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impossible. There is no way to remove the framebuffer from the lists and active planes without introducing a race because of the different locking requirements. Instead call drm_framebuffer_remove from a workqueue, which is unaffected by signals. Changes since v1: - Add comment. Changes since v2: - Add fastpath for refcount = 1. (danvet) Changes since v3: - Rebased. - Restore lastclose framebuffer removal too. Fixes: 13803132 ("drm/core: Preserve the framebuffer after removing it.") Testcase: kms_rmfb_basic References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
