summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-03-08pinctrl: samsung: Validate alias coming from DTKrzysztof Kozlowski
Driver uses alias from Device Tree as an index of pin controller data array. In case of a wrong DTB or an out-of-tree DTB, the alias could be outside of this data array leading to out-of-bounds access. Depending on binary and memory layout, this could be handled properly (showing error like "samsung-pinctrl 3860000.pinctrl: driver data not available") or could lead to exceptions. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: <stable@vger.kernel.org> Fixes: 30574f0db1b1 ("pinctrl: add samsung pinctrl and gpiolib driver") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-03-08pinctrl: sh-pfc: r8a7795: remove duplicate of CLKOUT pin in pinmux_pins[]Niklas Söderlund
When adding GP-1-28 port pin support it was forgotten to remove the CLKOUT pin from the list of pins that are not associated with a GPIO port in pinmux_pins[]. This results in a warning when reading the pinctrl files in sysfs as the CLKOUT pin is still added as a none GPIO pin. Fix this by removing the duplicated entry which is no longer needed. ~ # cat /sys/kernel/debug/pinctrl/e6060000.pin-controller/pinconf-pins [ 89.432081] ------------[ cut here ]------------ [ 89.436904] Pin 496 is not in bias info list [ 89.441252] WARNING: CPU: 1 PID: 456 at drivers/pinctrl/sh-pfc/core.c:408 sh_pfc_pin_to_bias_reg+0xb0/0xb8 [ 89.451002] CPU: 1 PID: 456 Comm: cat Not tainted 4.16.0-rc1-arm64-renesas-00048-gdfafc344a4f24dde #12 [ 89.460394] Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT) [ 89.468910] pstate: 80000085 (Nzcv daIf -PAN -UAO) [ 89.473747] pc : sh_pfc_pin_to_bias_reg+0xb0/0xb8 [ 89.478495] lr : sh_pfc_pin_to_bias_reg+0xb0/0xb8 [ 89.483241] sp : ffff00000aff3ab0 [ 89.486587] x29: ffff00000aff3ab0 x28: ffff00000893c698 [ 89.491955] x27: ffff000008ad7d98 x26: 0000000000000000 [ 89.497323] x25: ffff8006fb3f5028 x24: ffff8006fb3f5018 [ 89.502690] x23: 0000000000000001 x22: 00000000000001f0 [ 89.508057] x21: ffff8006fb3f5018 x20: ffff000008bef000 [ 89.513423] x19: 0000000000000000 x18: ffffffffffffffff [ 89.518790] x17: 0000000000006c4a x16: ffff000008d67c98 [ 89.524157] x15: 0000000000000001 x14: ffff00000896ca98 [ 89.529524] x13: 00000000cce5f611 x12: ffff8006f8d3b5a8 [ 89.534891] x11: ffff00000981e000 x10: ffff000008befa08 [ 89.540258] x9 : ffff8006f9b987a0 x8 : ffff000008befa08 [ 89.545625] x7 : ffff000008137094 x6 : 0000000000000000 [ 89.550991] x5 : 0000000000000000 x4 : 0000000000000001 [ 89.556357] x3 : 0000000000000007 x2 : 0000000000000007 [ 89.561723] x1 : 1ff24f80f1818600 x0 : 0000000000000000 [ 89.567091] Call trace: [ 89.569561] sh_pfc_pin_to_bias_reg+0xb0/0xb8 [ 89.573960] r8a7795_pinmux_get_bias+0x30/0xc0 [ 89.578445] sh_pfc_pinconf_get+0x1e0/0x2d8 [ 89.582669] pin_config_get_for_pin+0x20/0x30 [ 89.587067] pinconf_generic_dump_one+0x180/0x1c8 [ 89.591815] pinconf_generic_dump_pins+0x84/0xd8 [ 89.596476] pinconf_pins_show+0xc8/0x130 [ 89.600528] seq_read+0xe4/0x510 [ 89.603789] full_proxy_read+0x60/0x90 [ 89.607576] __vfs_read+0x30/0x140 [ 89.611010] vfs_read+0x90/0x170 [ 89.614269] SyS_read+0x60/0xd8 [ 89.617443] __sys_trace_return+0x0/0x4 [ 89.621314] ---[ end trace 99c8d0d39c13e794 ]--- Fixes: 82d2de5a4f646f72 ("pinctrl: sh-pfc: r8a7795: Add GP-1-28 port pin support") Reviewed-and-tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-03-08x86/pti: Fix a comment typoSeunghun Han
s/visinble/visible/ Signed-off-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/1520397135-132809-1-git-send-email-kkamagui@gmail.com
2018-03-08ALSA: seq: Remove superfluous snd_seq_queue_client_leave_cells() callTakashi Iwai
With the previous two fixes for the write / ioctl races: ALSA: seq: Don't allow resizing pool in use ALSA: seq: More protection for concurrent write and ioctl races the cells aren't any longer in queues at the point calling snd_seq_pool_done() in snd_seq_ioctl_set_client_pool(). Hence the function call snd_seq_queue_client_leave_cells() can be dropped safely from there. Suggested-by: Nicolai Stange <nstange@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-03-08ALSA: seq: More protection for concurrent write and ioctl racesTakashi Iwai
This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: 范龙飞 <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-03-08clk: ti: am43xx: add set-rate-parent support for display clkctrl clockTero Kristo
Display driver assumes it can use clk_set_rate for the display clock via set-rate-parent mechanism, so add the flag for this to id. Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2018-03-08clk: ti: am33xx: add set-rate-parent support for display clkctrl clockTero Kristo
Display driver assumes it can use clk_set_rate for the display clock via set-rate-parent mechanism, so add the flag for this to it. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Jyri Sarha <jsarha@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Jyri Sarha <jsarha@ti.com>
2018-03-08clk: ti: clkctrl: add support for CLK_SET_RATE_PARENT flagTero Kristo
Certain clkctrl clocks, notably the display ones, use the CLK_SET_RATE_PARENT feature extensively. Add support for this flag to the clkctrl clocks. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Jyri Sarha <jsarha@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Jyri Sarha <jsarha@ti.com>
2018-03-08x86/microcode: Synchronize late microcode loadingAshok Raj
Original idea by Ashok, completely rewritten by Borislav. Before you read any further: the early loading method is still the preferred one and you should always do that. The following patch is improving the late loading mechanism for long running jobs and cloud use cases. Gather all cores and serialize the microcode update on them by doing it one-by-one to make the late update process as reliable as possible and avoid potential issues caused by the microcode update. [ Borislav: Rewrite completely. ] Co-developed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: https://lkml.kernel.org/r/20180228102846.13447-8-bp@alien8.de
2018-03-08x86/microcode: Request microcode on the BSPBorislav Petkov
... so that any newer version can land in the cache and can later be fished out by the application functions. Do that before grabbing the hotplug lock. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: https://lkml.kernel.org/r/20180228102846.13447-7-bp@alien8.de
2018-03-08x86/microcode/intel: Look into the patch cache firstBorislav Petkov
The cache might contain a newer patch - look in there first. A follow-on change will make sure newest patches are loaded into the cache of microcode patches. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: https://lkml.kernel.org/r/20180228102846.13447-6-bp@alien8.de
2018-03-08x86/microcode: Do not upload microcode if CPUs are offlineAshok Raj
Avoid loading microcode if any of the CPUs are offline, and issue a warning. Having different microcode revisions on the system at any time is outright dangerous. [ Borislav: Massage changelog. ] Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: http://lkml.kernel.org/r/1519352533-15992-4-git-send-email-ashok.raj@intel.com Link: https://lkml.kernel.org/r/20180228102846.13447-5-bp@alien8.de
2018-03-08x86/microcode/intel: Writeback and invalidate caches before updating microcodeAshok Raj
Updating microcode is less error prone when caches have been flushed and depending on what exactly the microcode is updating. For example, some of the issues around certain Broadwell parts can be addressed by doing a full cache flush. [ Borislav: Massage it and use native_wbinvd() in both cases. ] Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: http://lkml.kernel.org/r/1519352533-15992-3-git-send-email-ashok.raj@intel.com Link: https://lkml.kernel.org/r/20180228102846.13447-4-bp@alien8.de
2018-03-08x86/microcode/intel: Check microcode revision before updating sibling threadsAshok Raj
After updating microcode on one of the threads of a core, the other thread sibling automatically gets the update since the microcode resources on a hyperthreaded core are shared between the two threads. Check the microcode revision on the CPU before performing a microcode update and thus save us the WRMSR 0x79 because it is a particularly expensive operation. [ Borislav: Massage changelog and coding style. ] Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: http://lkml.kernel.org/r/1519352533-15992-2-git-send-email-ashok.raj@intel.com Link: https://lkml.kernel.org/r/20180228102846.13447-3-bp@alien8.de
2018-03-08x86/microcode: Get rid of struct apply_microcode_ctxBorislav Petkov
It is a useless remnant from earlier times. Use the ucode_state enum directly. No functional change. Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Ashok Raj <ashok.raj@intel.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Link: https://lkml.kernel.org/r/20180228102846.13447-2-bp@alien8.de
2018-03-08x86/spectre_v2: Don't check microcode versions when running under hypervisorsKonrad Rzeszutek Wilk
As: 1) It's known that hypervisors lie about the environment anyhow (host mismatch) 2) Even if the hypervisor (Xen, KVM, VMWare, etc) provided a valid "correct" value, it all gets to be very murky when migration happens (do you provide the "new" microcode of the machine?). And in reality the cloud vendors are the ones that should make sure that the microcode that is running is correct and we should just sing lalalala and trust them. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Wanpeng Li <kernellwp@gmail.com> Cc: kvm <kvm@vger.kernel.org> Cc: Krčmář <rkrcmar@redhat.com> Cc: Borislav Petkov <bp@alien8.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180226213019.GE9497@char.us.oracle.com
2018-03-08ALSA: seq: Don't allow resizing pool in useTakashi Iwai
This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: 范龙飞 <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-03-08x86/vsyscall/64: Drop "native" vsyscallsAndy Lutomirski
Since Linux v3.2, vsyscalls have been deprecated and slow. From v3.2 on, Linux had three vsyscall modes: "native", "emulate", and "none". "emulate" is the default. All known user programs work correctly in emulate mode, but vsyscalls turn into page faults and are emulated. This is very slow. In "native" mode, the vsyscall page is easily usable as an exploit gadget, but vsyscalls are a bit faster -- they turn into normal syscalls. (This is in contrast to vDSO functions, which can be much faster than syscalls.) In "none" mode, there are no vsyscalls. For all practical purposes, "native" was really just a chicken bit in case something went wrong with the emulation. It's been over six years, and nothing has gone wrong. Delete it. Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/519fee5268faea09ae550776ce969fa6e88668b0.1520449896.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-07Revert "platform/chrome: chromeos_laptop: make chromeos_laptop const"Dmitry Torokhov
This reverts commit a376cd91606365609d8fbd57247618bd51da1fc6 because chromeos_laptop instances should not be marked as "const" (at this time), since i2c_peripheral is being modified (we change "state" and "tries") when we instantiate devices. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2018-03-07Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull virtio bugfix from Michael Tsirkin: "A bugfix for error handling in virtio" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio_ring: fix num_free handling in error case
2018-03-07Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - we are reverting patch that was switched touchpad on Lenovo T460P over to native RMI because on these boxes BIOS messes up with SMBus controller state. We might re-enable it later once SMBus issue is resolved - disabling interrupts in matrix_keypad driver was racy - mms114 now has SPDX header and matching MODULE_LICENSE * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Revert "Input: synaptics - Lenovo Thinkpad T460p devices should use RMI" Input: matrix_keypad - fix race when disabling interrupts Input: mms114 - add SPDX identifier Input: mms114 - fix license module information
2018-03-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Daniel Borkmann says: ==================== pull-request: bpf 2018-03-08 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix various BPF helpers which adjust the skb and its GSO information with regards to SCTP GSO. The latter is a special case where gso_size is of value GSO_BY_FRAGS, so mangling that will end up corrupting the skb, thus bail out when seeing SCTP GSO packets, from Daniel(s). 2) Fix a compilation error in bpftool where BPF_FS_MAGIC is not defined due to too old kernel headers in the system, from Jiri. 3) Increase the number of x64 JIT passes in order to allow larger images to converge instead of punting them to interpreter or having them rejected when the interpreter is not built into the kernel, from Daniel. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-07Revert "Input: synaptics - Lenovo Thinkpad T460p devices should use RMI"Arkadiusz Hiler
This reverts commit 48282969826b3d3c76e908182f69724d86d995fe which caused the following issues: 1. On T460p with BIOS version 2.22 touchpad and trackpoint stop working after suspend-resume cycle. Due to strange state of the device another suspend is impossible. The following dmesg errors can be observed: thinkpad_acpi: EC reports that Thermal Table has changed rmi4_smbus 7-002c: failed to get SMBus version number! rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16. rmi4_f01 rmi4-00.fn01: Resume failed with code -16. rmi4_physical rmi4-00: Failed to suspend functions: -16 rmi4_smbus 7-002c: Failed to resume device: -16 PM: resume devices took 0.640 seconds rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16). rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts! rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! psmouse: probe of serio3 failed with error -1 2. On another T460p with BIOS version 2.15 two finger scrolling gesture on the touchpad stops working after suspend-resume cycle (about 75% reproducibility, when it still works, the scrolling gesture becomes laggy). Nothing suspicious appears in the dmesg. Analysis form Richard Schütz: "RMI is unreliable on the ThinkPad T460p because the device is affected by the firmware behavior addressed in a7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR")." The affected devices often show: i801_smbus 0000:00:1f.4: BIOS is accessing SMBus registers i801_smbus 0000:00:1f.4: Driver SMBus register access inhibited Reported-by: Richard Schütz <rschuetz@uni-koblenz.de> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Tested-by: Martin Peres <martin.peres@linux.intel.com> Tested-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2018-03-07bpf, x64: increase number of passesDaniel Borkmann
In Cilium some of the main programs we run today are hitting 9 passes on x64's JIT compiler, and we've had cases already where we surpassed the limit where the JIT then punts the program to the interpreter instead, leading to insertion failures due to CONFIG_BPF_JIT_ALWAYS_ON or insertion failures due to the prog array owner being JITed but the program to insert not (both must have the same JITed/non-JITed property). One concrete case the program image shrunk from 12,767 bytes down to 10,288 bytes where the image converged after 16 steps. I've measured that this took 340us in the JIT until it converges on my i7-6600U. Thus, increase the original limit we had from day one where the JIT covered cBPF only back then before we run into the case (as similar with the complexity limit) where we trip over this and hit program rejections. Also add a cond_resched() into the compilation loop, the JIT process runs without any locks and may sleep anyway. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-03-07libnvdimm, {btt, blk}: do integrity setup before add_disk()Vishal Verma
Prior to 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk") we needed to temporarily add a zero-capacity disk before registering for blk-integrity. But adding a zero-capacity disk caused the partition table scanning to bail early, and this resulted in partitions not coming up after a probe of the BTT or blk namespaces. We can now register for integrity before the disk has been added, and this fixes the rescan problems. Fixes: 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk") Reported-by: Dariusz Dokupil <dariusz.dokupil@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-07drm/amd/display: validate plane format on primary planeShirish S
In dce110, the plane configuration is such that plane 0 or the primary plane should be rendered with only RGB data. This patch adds the validation to ensure that no video data is rendered on plane 0. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amdgpu:Always save uvd vcpu_bo in VM ModeJames Zhu
When UVD is in VM mode, there is not uvd handle exchanged, uvd.handles are always 0. So vcpu_bo always need save, Otherwise amdgpu driver will fail during suspend/resume. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105021 Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-03-07drm/amdgpu:Correct max uvd handlesJames Zhu
Max uvd handles should use adev->uvd.max_handles instead of AMDGPU_MAX_UVD_HANDLES here. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-03-07drm/amd/display: early return if not in vga mode in disable_vgaEric Yang
The work around for hw bug causes S3 resume failure. Don't execute disable vga logic if not in vga mode. Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Fix takover from VGA modeBhawanpreet Lakha
HW Engineer's Notes: During switch from vga->extended, if we set the VGA_TEST_ENABLE and then hit the VGA_TEST_RENDER_START, then the DCHUBP timing gets updated correctly. Then vBIOS will have it poll for the VGA_TEST_RENDER_DONE and unset VGA_TEST_ENABLE, to leave it in the same state as before. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Fix memleaks when atomic check fails.Leo (Sunpeng) Li
While checking plane states for updates during atomic check, we create dc_plane_states in preparation. These dc states should be freed if something errors. Although the input transfer function is also freed by dc_plane_state_release(), we should free it (on error) under the same scope as where it is created. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Return success when enabling interruptHarry Wentland
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Use crtc enable/disable_vblank hooksHarry Wentland
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: update infoframe after dig fe is turned onEric Yang
Before dig fe is enabled, infoframe can't be programmed. So in suspend resume case our infoframe programmming was not going through. This change changes the sequence so that infoframe is programmed after. Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: fix boot-up on vega10Roman Li
Fixing null-deref on Vega10 due to regression after 'fix cursor related Pstate hang' change. Added null checks in setting cursor position. Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: fix cursor related Pstate hangEric Yang
Move cursor programming to inside the OTG_MASTER_UPDATE_LOCK If graphics plane go from 1 pipe to hsplit, the cursor updates after mpc programming and unlock. Which means there is a window of time where cursor is enabled on the wrong pipe if it's on the right side of the screen (i.e. case where cursor need to move from pipe 0 to pipe 3 post split). This will cause pstate hang. Solution is to program the cursor while still locked. Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Set irq state only on existing crtcsMikita Lipski
Because AMDGPU_CRTC_IRQ_VLINE1 = 6, it expected 6 more crtcs to be programed with disabled irq state in amdgpu_irq_disable_all. That caused errors and accessed the wrong memory location. Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Fixed non-native modes not lighting upJerry (Fangzhi) Zuo
There is no need to call drm_mode_set_crtcinfo() again once crtc timing is decided. Otherwise non-native/unsupported timing might get overwritten. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Call update_stream_signal directly from amdgpu_dmHarry Wentland
There's no good place in DC to cover all place where stream signal should be updated. update_stream_signal depends on timing which comes from DM. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Make create_stream_for_sink more consistentHarry Wentland
We've got a helper function to call dc_create_stream_for_sink and one other place that calls it directly. Make sure we call the helper functions always since we need to update a bunch of things in stream and don't want to miss that. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Don't block dual-link DVI modesHarry Wentland
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Don't allow dual-link DVI on all ASICs.Harry Wentland
Our APUs (Carrizo, Stoney, Raven) don't support it. v2: Don't use is_apu as other ASICs might also not support it Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Pass signal directly to enable_tmds_outputHarry Wentland
This makes the check for HDMI and dual-link DVI a bit more straightforward. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Remove unnecessary fail labels in create_stream_for_sinkHarry Wentland
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Move MAX_TMDS_CLOCK define to headerHarry Wentland
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Fix FBC topology changeRoman Li
With FBC enabled there was a potential null-deref on topology change due to hardcorded pipe index. Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Fix topology change issue in MST rehookJerry (Fangzhi) Zuo
When topology changed and rehook up MST display to the same DP connector, need to take care of drm_dp_mst_port object. Due to the topology is changed, drm_dp_mst_port and corresponding i2c_algorithm object could be NULL in such situation. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2)Shirish S
The below commit "drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2" introduces a slight behavioral change to rmfb. Instead of disabling a crtc when the primary plane is disabled, it now preserves it. This change leads to BUG hit while performing atomic commit on amd driver. As a fix this patch ensures that we disable the CRTC's with NULL FB by returning -EINVAL and hence triggering fall back to the old behavior and turning off the crtc in atomic_remove_fb(). V2: Added error check for plane_state and removed sanity check for crtc. Signed-off-by: Shirish S <shirish.s@amd.com> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ infoMichel Dänzer
For consistency with other DCE generations. HPD IRQs appear to be working fine. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-07drm/amd/display: Default HDMI6G support to true. Log VBIOS table error.Harry Wentland
There have been many reports of Ellesmere and Baffin systems not being able to drive HDMI 4k60 due to the fact that we check the HDMI_6GB_EN bit from VBIOS table. Windows seems to not have this issue. On some systems we fail to the encoder cap info from VBIOS. In that case we should default to enabling HDMI6G support. This was tested by dwagner on https://bugs.freedesktop.org/show_bug.cgi?id=102820 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-14 23:48:05 +0000