- 10 Jun, 2016 25 commits
-
-
Serge E. Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1584163 Our caller expects 0 on success, not >0. This fixes a bug in the patch cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces where /sys does not show up in mountinfo, breaking criu. Thanks for catching this, Andrei. Reported-by:
Andrei Vagin <avagin@gmail.com> Signed-off-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
Tejun Heo <tj@kernel.org> (cherry picked from commit 3cc9b23c) Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Serge E. Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1584163 Patch summary: When showing a cgroupfs entry in mountinfo, show the path of the mount root dentry relative to the reader's cgroup namespace root. Short explanation (courtesy of mkerrisk): If we create a new cgroup namespace, then we want both /proc/self/cgroup and /proc/self/mountinfo to show cgroup paths that are correctly virtualized with respect to the cgroup mount point. Previous to this patch, /proc/self/cgroup shows the right info, but /proc/self/mountinfo does not. Long version: When a uid 0 task which is in freezer cgroup /a/b, unshares a new cgroup namespace, and then mounts a new instance of the freezer cgroup, the new mount will be rooted at /a/b. The root dentry field of the mountinfo entry will show '/a/b'. cat > /tmp/do1 << EOF mount -t cgroup -o freezer freezer /mnt grep freezer /proc/self/mountinfo EOF unshare -Gm bash /tmp/do1 > 330 160 0:34 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer > 355 133 0:34 /a/b /mnt rw,relatime - cgroup freezer rw,freezer The task's freezer cgroup entry in /proc/self/cgroup will simply show '/': grep freezer /proc/self/cgroup 9:freezer:/ If instead the same task simply bind mounts the /a/b cgroup directory, the resulting mountinfo entry will again show /a/b for the dentry root. However in this case the task will find its own cgroup at /mnt/a/b, not at /mnt: mount --bind /sys/fs/cgroup/freezer/a/b /mnt 130 25 0:34 /a/b /mnt rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,freezer In other words, there is no way for the task to know, based on what is in mountinfo, which cgroup directory is its own. Example (by mkerrisk): First, a little script to save some typing and verbiage: echo -e "\t/proc/self/cgroup:\t$(cat /proc/self/cgroup | grep freezer)" cat /proc/self/mountinfo | grep freezer | awk '{print "\tmountinfo:\t\t" $4 "\t" $5}' Create cgroup, place this shell into the cgroup, and look at the state of the /proc files: 2653 2653 # Our shell 14254 # cat(1) /proc/self/cgroup: 10:freezer:/a/b mountinfo: / /sys/fs/cgroup/freezer Create a shell in new cgroup and mount namespaces. The act of creating a new cgroup namespace causes the process's current cgroups directories to become its cgroup root directories. (Here, I'm using my own version of the "unshare" utility, which takes the same options as the util-linux version): Look at the state of the /proc files: /proc/self/cgroup: 10:freezer:/ mountinfo: / /sys/fs/cgroup/freezer The third entry in /proc/self/cgroup (the pathname of the cgroup inside the hierarchy) is correctly virtualized w.r.t. the cgroup namespace, which is rooted at /a/b in the outer namespace. However, the info in /proc/self/mountinfo is not for this cgroup namespace, since we are seeing a duplicate of the mount from the old mount namespace, and the info there does not correspond to the new cgroup namespace. However, trying to create a new mount still doesn't show us the right information in mountinfo: # propagating to other mountns /proc/self/cgroup: 7:freezer:/ mountinfo: /a/b /mnt/freezer The act of creating a new cgroup namespace caused the process's current freezer directory, "/a/b", to become its cgroup freezer root directory. In other words, the pathname directory of the directory within the newly mounted cgroup filesystem should be "/", but mountinfo wrongly shows us "/a/b". The consequence of this is that the process in the cgroup namespace cannot correctly construct the pathname of its cgroup root directory from the information in /proc/PID/mountinfo. With this patch, the dentry root field in mountinfo is shown relative to the reader's cgroup namespace. So the same steps as above: /proc/self/cgroup: 10:freezer:/a/b mountinfo: / /sys/fs/cgroup/freezer /proc/self/cgroup: 10:freezer:/ mountinfo: /../.. /sys/fs/cgroup/freezer /proc/self/cgroup: 10:freezer:/ mountinfo: / /mnt/freezer cgroup.clone_children freezer.parent_freezing freezer.state tasks cgroup.procs freezer.self_freezing notify_on_release 3164 2653 # First shell that placed in this cgroup 3164 # Shell started by 'unshare' 14197 # cat(1) Signed-off-by:
Michael Kerrisk <mtk.manpages@gmail.com> Acked-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1584163 This reverts commit d5e333e3. Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1584163 This reverts commit f7d70a0c. Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1248289Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1582328 The current code path is capable of grossly overestimating the number of descriptors needed to transmit a new frame. This specifically occurs if the skb contains a number of 4K pages. The issue is that the logic for determining the descriptors needed is ((S) >> (X)) + 1. When X is 12 it means that we were indicating that we required 2 descriptors for each 4K page when we only needed one. This change corrects this by instead adding (1 << (X)) - 1 to the S value instead of adding 1 after the fact. This way we get an accurate descriptor needed count as we are essentially doing a DIV_ROUNDUP(). Reported-by:
Ivan Suzdal <isuzdal@mirantis.com> Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 847a1d67) Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1582328 The 82544 has code that adds one additional descriptor per data buffer. However we weren't taking that into account when determining the descriptors needed for the next transmit at the end of the xmit_frame path. This change takes that into account by doubling the number of descriptors needed for the 82544 so that we can avoid a potential issue where we could hang the Tx ring by loading frames with xmit_more enabled and then stopping the ring without writing the tail. In addition it adds a few more descriptors to account for some additional workarounds that have been added over time. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1582378 s_user_ns for an mqueue super block needs to be set to the user ns which owns the ipc ns, otherwise it will not be mountable in that user ns. This is not currently the case for an unshare(CLONE_NEWIPC|CLONE_NEWUSER) as the internal mount of the super block for the new ipc ns is done before the new user namespace is installed. Since s_user_ns = ipc_ns->user_ns is the only arrangement that makes sense for mqueue, the initial kernel mount can simply pass that namespace to sget_userns(). In addition we should do the same for userspace mounts to preserve the behavior that allows a user privileged towards ipc_ns->user_ns to mount mqueue from a different user ns. The existing checks already ensure that the user has sufficient privileges for the mount. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit 56fc3502 upstream. Fixes the following scenario: 1. Page table bo allocated in vram and linked to man->lru. tbo->list_kref.refcount=2 2. Page table bo is swapped out and removed from man->lru. tbo->list_kref.refcount=1 3. Command submission from userspace. Page table bo is moved to vram. ttm_bo_move_to_lru_tail() link it to man->lru and don't increase the kref count. Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Alberto Milone <alberto.milone@canonical.com> Acked-by:
-
Rex Zhu authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit f9e9c08e upstream. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
-
Eric Huang authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit 60123300 upstream. Set the UVD and VCE DPM flags otherwise UVD and VCE DPM won't get enabled. Reviewed-by:
Eric Huang <JinHuiEric.Huang@amd.com> Signed-off-by:
-
Dave Airlie authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit b36f7d26 upstream. The function this used changed in 092c96a8 drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit e5f243bd upstream. Move all the logic to radeon_fb.c and add checks to functions called frome elsewhere. bug: https://bugzilla.kernel.org/show_bug.cgi?id=112781Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1121699Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1580355Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 We should validate the port setting that we got from the user and check if it's what we've set it to (PORT_OTHER), also add explanation that ignoring advertising is good as long as we don't have autonegotiation. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 0cf3ace9) Signed-off-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 This patch allows the user to set and retrieve speed and duplex of the virtio_net device via ethtool. Having this functionality is very helpful for simulating different environments and also enables the virtio_net device to participate in operations where proper speed and duplex are required (e.g. currently bonding lacp mode requires full duplex). Custom speed and duplex are not allowed, the user-supplied settings are validated before applying. Example: $ ethtool eth1 Settings for eth1: ... Speed: Unknown! Duplex: Unknown! (255) $ ethtool -s eth1 speed 1000 duplex full $ ethtool eth1 Settings for eth1: ... Speed: 1000Mb/s Duplex: Full Based on a patch by Roopa Prabhu. Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 Devices these days can have any speed and as was recently pointed out any speed from 0 to INT_MAX is valid so adjust speed validation to accept such values. Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 Add functions which check if the speed/duplex are defined. Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1578211 Power8 supports a large number of events in each susbystem so when a user runs: perf stat -e branch-instructions sleep 1 perf stat -e L1-dcache-loads sleep 1 it is not clear as to which PMU events were monitored. Export the generic hardware and cache perf events for Power8 to sysfs, so users can precisely determine the PMU event monitored by the generic event. Eg: cat /sys/bus/event_source/devices/cpu/events/branch-instructions event=0x10068 $ cat /sys/bus/event_source/devices/cpu/events/L1-dcache-loads event=0x100ee Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit e0728b50) Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1578211 We used the PME_ prefix earlier to avoid some macro/variable name collisions. We have since changed the way we define/use the event macros so we no longer need the prefix. By dropping the prefix, we keep the the event macros consistent with their official names. Reported-by:
Michael Ellerman <ellerman@au1.ibm.com> Signed-off-by:
-
Saeed Mahameed authored
BugLink: http://bugs.launchpad.net/bugs/1528466 Minimum MTU that can be set in Connectx4 device is 68. This fixes the case where a user wants to set invalid MTU, the driver will fail to satisfy this request and the interface will stay down. It is better to report an error and continue working with old mtu. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
BugLink: http://bugs.launchpad.net/bugs/1528466 For set/query MTU port firmware commands the MTU field is 16 bits, here I changed all the "int mtu" parameters of the functions wrapping those firmware commands to be u16. Signed-off-by:
-
Achiad Shochat authored
BugLink: http://bugs.launchpad.net/bugs/1528466 All the device physical port access functions are implemented in the port.c file. We just extract the exposure of these functions from driver.h into a dedicated header file called port.h. Signed-off-by:
Achiad Shochat <achiad@mellanox.com> Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 08 Jun, 2016 5 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1588871 Until now, hitting this BUG_ON caused a recursive oops (because oops handling involves do_exit(), which calls into the scheduler, which in turn raises an oops), which caused stuff below the stack to be overwritten until a panic happened (e.g. via an oops in interrupt context, caused by the overwritten CPU index in the thread_info). Just panic directly. Signed-off-by:
Jann Horn <jannh@google.com> CVE-2016-1583 Acked-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1588871 This prevents users from triggering an exploitable stack overflow through a recursive invocation of pagefault handling on systems that allow unprivileged users to mount ecryptfs. More precisely: When a file in ecryptfs is mmap()ed, ecryptfs only uses the VFS read and write methods of the lower filesystem (using kernel_read() and kernel_write()) to interact with the lower file. This means that it is possible to mmap() the decrypted view of a lower file that normally couldn't be mmap()ed. One such file is /proc/$pid/environ. If an encrypted ecryptfs file is placed in the environment area of a process with PID $pid and /proc/$pid is mounted to /tmp/foo, /tmp/foo/environ can then be opened and mmap()ed. A pagefault in the memory area to which /tmp/foo/environ is mapped will cause a kernel_read() on /proc/$pid/environ, which in turn will cause a pagefault in the context of the process with PID $pid. By using a chain of processes in which each process has the decrypted view of the next process' environment mapped into its environment area, where the environment of the last process in the chain is an "ecryptfs matroska" (the result of encrypting some data using ecryptfs, then encrypting the result of that and so on), and then triggering a pagefault in the environment of the first process in the chain, it is possible to cause a recursive pagefault that ends up overflowing the stack. Fix it by disallowing opening anything without an mmap handler through ecryptfs. CVE-2016-1583 Signed-off-by:
-
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1588871 This prevents stacking filesystems (ecryptfs and overlayfs) from using procfs as lower filesystem. There is too much magic going on inside procfs, and there is no good reason to stack stuff on top of procfs. (For example, procfs does access checks in VFS open handlers, and ecryptfs by design calls open handlers from a kernel thread that doesn't drop privileges or so.) Signed-off-by:
-
Al Viro authored
First of all, trying to open them r/w is idiocy; it's guaranteed to fail. Moreover, assigning ->f_pos and assuming that everything will work is blatantly broken - try that with e.g. tmpfs as underlying layer and watch the fireworks. There may be a non-trivial amount of state associated with current IO position, well beyond the numeric offset. Using the single struct file associated with underlying inode is really not a good idea; we ought to open one for each ecryptfs directory struct file. Additionally, file_operations both for directories and non-directories are full of pointless methods; non-directories should *not* have ->iterate(), directories should not have ->flush(), ->fasync() and ->splice_read(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit 6a480a78) Acked-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
- 03 Jun, 2016 1 commit
-
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1583738Signed-off-by:
dann frazier <dann.frazier@canonical.com> Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
- 19 May, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 16 May, 2016 8 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Andy Whitcroft authored
When we cross-compile we have to turn off the inbuilt zfs modules. When doing this we also need to allow the modules so produced to go missing in this build while still checking the remainder of the modules. BugLink: http://bugs.launchpad.net/bugs/1581127Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1580754Signed-off-by:
-
Mat Martineau authored
BugLink: http://bugs.launchpad.net/bugs/1580754 commit a41c8882 upstream. The driver does not load firmware for unknown steppings, so these new steppings must be added to the list. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1580754 commit 72676bb5 upstream. Recently added commit 564b026f ("string_helpers: fix precision loss for some inputs") fixed precision issues for string_get_size() and broke tests. Fix and improve them: test both STRING_UNITS_2 and STRING_UNITS_10 at a time, better failure reporting, test small an huge values. Fixes: 564b026f ("string_helpers: fix precision loss for some inputs") Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Bottomley <JBottomley@Odin.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Shashank Sharma authored
BugLink: http://bugs.launchpad.net/bugs/1580754 commit 60b3143c upstream. This patch does the following: - Fakes live status of HDMI as connected (even if that's not). While testing certain (monitor + cable) combinations with various intel platforms, it seems that live status register doesn't work reliably on some older devices. So limit the live_status check for HDMI detection, only for platforms from gen7 onwards. V2: restrict faking live_status to certain platforms V3: (Ville) - keep the debug message for !live_status case - fix indentation of comment - remove "warning" from the debug message (Jani) - Change format of fix details in the commit message Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Suggested-by:
Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1580754 commit 4ea39590 upstream. Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around GPU hangs if the RPS EI/thresholds aren't suitably aligned. It seems like scheduling/timer interupts stop working somehow and things get stuck eg. in usleep_range(). I bisected the problem down to commit 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") I observed that before all the values were at least multiples of 25, but afterwards they are not. And rounding things up to the next multiple of 25 does seem to help, so lets' do that. I also tried roundup(..., 5) but that wasn't sufficient. Also I have no idea if we might need this sort of thing on gen9+ as well. These are the original EI/thresholds: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10250 GEN6_RP_UP_THRESHOLD 9225 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 8000 GEN6_RP_UP_THRESHOLD 6800 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 These are after 8a586437: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10156 GEN6_RP_UP_THRESHOLD 9140 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7812 GEN6_RP_UP_THRESHOLD 6640 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 And these are what we have after this patch: LOW_POWER GEN6_RP_UP_EI 12500 GEN6_RP_UP_THRESHOLD 11875 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 21250 BETWEEN GEN6_RP_UP_EI 10175 GEN6_RP_UP_THRESHOLD 9150 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 18750 HIGH_POWER GEN6_RP_UP_EI 7825 GEN6_RP_UP_THRESHOLD 6650 GEN6_RP_DOWN_EI 25000 GEN6_RP_DOWN_THRESHOLD 15000 Cc: Akash Goel <akash.goel@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B Fixes: 8a586437 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> (cherry picked from commit 8a292d01) Signed-off-by:
-
Mika Kahola authored
BugLink: http://bugs.launchpad.net/bugs/1580754 commit 992e7a41 upstream. It was noticed on bug #94087 that module parameter i915.edp_vswing=2 that should override the VBT setting to use default voltage swing (400 mV) was not applied for Broadwell. This patch provides a fix for this by checking if default i.e. higher voltage swing is requested to be used and applies the DDI translations table for DP instead of eDP (low vswing) table. v2: Combine two if statements into one (Jani) v3: Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461155942-7749-1-git-send-email-mika.kahola@intel.comSigned-off-by:
-
