- 16 Sep, 2019 40 commits
-
-
Ville Syrjälä authored
[ Upstream commit ed20151a ] On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to configure the per-crtc value before calling drm_vblank_on(). Also looks like there was some discussion about exynos needing similar treatment. v2: Drop the extra max_vblank_count!=0 check for the WARN(last!=current), will take care of it in i915 code (Daniel) WARN_ON(!inmodeset) (Daniel) WARN_ON(dev->max_vblank_count) Pimp up the docs (Daniel) Cc: stable@vger.kernel.org Cc: Inki Dae <inki.dae@samsung.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127182004.28885-1-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Gilad Ben-Yossef authored
[ Upstream commit f1071c3e ] Commit 1358c13a ("crypto: ccree - fix resume race condition on init") was missing a "inline" qualifier for stub function used when CONFIG_PM is not set causing a build warning. Fixes: 1358c13a ("crypto: ccree - fix resume race condition on init") Cc: stable@kernel.org # v4.20 Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Gilad Ben-Yossef authored
[ Upstream commit 1358c13a ] We were enabling autosuspend, which is using data set by the hash module, prior to the hash module being inited, casuing a crash on resume as part of the startup sequence if the race was lost. This was never a real problem because the PM infra was using low res timers so we were always winning the race, until commit 8234f673 ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-) Fix this by seperating the PM setup and enablement and doing the latter only at the end of the init sequence. Signed-off-by:
-
Yishai Hadas authored
[ Upstream commit 425784aa ] The async_file might be freed before the disassociation has been ended, causing qp shutdown to use after free on it. Since uverbs_destroy_ufile_hw is not a fence, it returns if a disassociation is ongoing in another thread. It has to be written this way to avoid deadlock. However this means that the ufile FD close cannot destroy anything that may still be used by an active kref, such as the the async_file. To fix that move the kref_put() to be in ib_uverbs_release_file(). BUG: unable to handle kernel paging request at ffffffffba682787 PGD bc80e067 P4D bc80e067 PUD bc80f063 PMD 1313df163 PTE 80000000bc682061 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 32410 Comm: bash Tainted: G OE 4.20.0-rc6+ #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_lock_slowpath+0x1b3/0x2a0 Code: 98 83 e2 60 49 89 df 48 8b 04 c5 80 18 72 ba 48 8d ba 80 32 02 00 ba 00 80 00 00 4c 8d 65 14 41 bd 01 00 00 00 48 01 c7 85 d2 <48> 89 2f 48 89 fb 74 14 8b 45 08 85 c0 75 42 84 d2 74 6b f3 90 83 RSP: 0018:ffffc1bbc064fb58 EFLAGS: 00010006 RAX: ffffffffba65f4e7 RBX: ffff9f209c656c00 RCX: 0000000000000001 RDX: 0000000000008000 RSI: 0000000000000000 RDI: ffffffffba682787 RBP: ffff9f217bb23280 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9f209d2c7800 R11: ffffffffffffffe8 R12: ffff9f217bb23294 R13: 0000000000000001 R14: 0000000000000000 R15: ffff9f209c656c00 FS: 00007fac55aad740(0000) GS:ffff9f217bb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffba682787 CR3: 000000012f8e0000 CR4: 00000000000006e0 Call Trace: _raw_spin_lock_irq+0x27/0x30 ib_uverbs_release_uevent+0x1e/0xa0 [ib_uverbs] uverbs_free_qp+0x7e/0x90 [ib_uverbs] destroy_hw_idr_uobject+0x1c/0x50 [ib_uverbs] uverbs_destroy_uobject+0x2e/0x180 [ib_uverbs] __uverbs_cleanup_ufile+0x73/0x90 [ib_uverbs] uverbs_destroy_ufile_hw+0x5d/0x120 [ib_uverbs] ib_uverbs_remove_one+0xea/0x240 [ib_uverbs] ib_unregister_device+0xfb/0x200 [ib_core] mlx5_ib_remove+0x51/0xe0 [mlx5_ib] mlx5_remove_device+0xc1/0xd0 [mlx5_core] mlx5_unregister_device+0x3d/0xb0 [mlx5_core] remove_one+0x2a/0x90 [mlx5_core] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x16d/0x240 unbind_store+0xb2/0x100 kernfs_fop_write+0x102/0x180 __vfs_write+0x36/0x1a0 ? __alloc_fd+0xa9/0x170 ? set_close_on_exec+0x49/0x70 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fac551aac60 Cc: <stable@vger.kernel.org> # 4.2 Fixes: 036b1063 ("IB/uverbs: Enable device removal when there are active user space applications") Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 4d447455 ] do_page_fault() forgot to relinquish mmap_sem if a signal came while handling handle_mm_fault() - due to say a ctl+c or oom etc. This would later cause a deadlock by acquiring it twice. This came to light when running libc testsuite tst-tls3-malloc test but is likely also the cause for prior seen LTP failures. Using lockdep clearly showed what the issue was. | # while true; do ./tst-tls3-malloc ; done | Didn't expect signal from child: got `Segmentation fault' | ^C | ============================================ | WARNING: possible recursive locking detected | 4.17.0+ #25 Not tainted | -------------------------------------------- | tst-tls3-malloc/510 is trying to acquire lock: | 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c | |but task is already holding lock: |606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0 | | other info that might help us debug this: | Possible unsafe locking scenario: | | CPU0 | ---- | lock(&mm->mmap_sem); | lock(&mm->mmap_sem); | | *** DEADLOCK *** | ------------------------------------------------------------ What the change does is not obvious (note to myself) prior code was | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_ERROR | up_read | if user_mode | return <-- lock still held, this was the BUG New code | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_RETRY | return <-- not same case as above, but still OK since | core mm already relinq lock for FAULT_RETRY | ... | | < Now falls through for bug case above > | | up_read() <-- lock relinquished Cc: stable@vger.kernel.org Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit f731a8e8 ] signal handling core calls show_regs() with preemption disabled which on ARC takes mmap_sem for mm/vma access, causing lockdep splat. | [ARCLinux]# ./segv-null-ptr | potentially unexpected fatal signal 11. | BUG: sleeping function called from invalid context at kernel/fork.c:1011 | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr | no locks held by segv-null-ptr/70. | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69 | | Stack Trace: | arc_unwind_core+0xcc/0x100 | ___might_sleep+0x17a/0x190 | mmput+0x16/0xb8 | show_regs+0x52/0x310 | get_signal+0x5ee/0x610 | do_signal+0x2c/0x218 | resume_user_mode_begin+0x90/0xd8 Workaround by re-enabling preemption temporarily. Note that the preemption disabling in core code around show_regs() was introduced by commit 3a9f84d3 ("signals, debug: fix BUG: using smp_processor_id() in preemptible code in print_fatal_signal()") to silence a differnt lockdep seen on x86 bakc in 2009. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 240809ef ] cancel_delayed_work_sync() was called for any queue, but it should only be called for the queue that is associated with the currently running job. Otherwise, if two filehandles are streaming at the same time, then closing the first will cancel the work which might still be running for a job from the second filehandle. As a result the second filehandle will never be able to finish the job and an attempt to stop streaming on that second filehandle will stall. Fixes: 52117be6 ("media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work") Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.20 and up Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit 1b3922a8 ] [BUG] Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel message: BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len 8388608 is beyond device boundary 0 BTRFS error (device dm-6): failed to verify dev extents against chunks: -117 BTRFS error (device dm-6): open_ctree failed [CAUSE] Commit cf90d884 ("btrfs: Introduce mount time chunk <-> dev extent mapping check") introduced strict check on dev extents. We use btrfs_find_device() with dev uuid and fs uuid set to NULL, and only dependent on @devid to find the real device. For seed devices, we call clone_fs_devices() in open_seed_devices() to allow us search seed devices directly. However clone_fs_devices() just populates devices with devid and dev uuid, without populating other essential members, like disk_total_bytes. This makes any device returned by btrfs_find_device(fs_info, devid, NULL, NULL) is just a dummy, with 0 disk_total_bytes, and any dev extents on the seed device will not pass the device boundary check. [FIX] This patch will try to verify the device returned by btrfs_find_device() and if it's a dummy then re-search in seed devices. Fixes: cf90d884 ("btrfs: Introduce mount time chunk <-> dev extent mapping check") CC: stable@vger.kernel.org # 4.19+ Reported-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
Qu Wenruo <wqu@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit 05a37c48 ] Add extra dev extent end check against device boundary. Signed-off-by:
-
Ram Pai authored
[ Upstream commit 2cd4bd19 ] Protection key tracking information is not copied over to the mm_struct of the child during fork(). This can cause the child to erroneously allocate keys that were already allocated. Any allocated execute-only key is lost aswell. Add code; called by dup_mmap(), to copy the pkey state from parent to child explicitly. This problem was originally found by Dave Hansen on x86, which turns out to be a problem on powerpc aswell. Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem") Cc: stable@vger.kernel.org # v4.16+ Reviewed-by:
Thiago Jung Bauermann <bauerman@linux.ibm.com> Signed-off-by:
Ram Pai <linuxram@us.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Shivasharan S authored
[ Upstream commit 894169db ] Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Cc: stable@vger.kernel.org Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Shivasharan S authored
[ Upstream commit de93b40d ] For SAS3 and later controllers, FW sets the reset adapter bit indicating the driver to perform a controller reset. Driver needs to check if this bit is set before doing a reset. This reduces the driver probe failure time to 180seconds in case there is a faulty controller connected. Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Shivasharan S authored
[ Upstream commit e29c3221 ] For Invader series, if FW supports more than 8 MSI-x vectors, driver needs to enable combined reply queue mode. For Ventura series, driver enables combined reply queue mode in case of more than 16 MSI-x vectors. Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit d1051d6e ] Running btrfs/124 in a loop hung up on me sporadically with the following call trace: btrfs D 0 5760 5324 0x00000000 Call Trace: ? __schedule+0x243/0x800 schedule+0x33/0x90 btrfs_start_ordered_extent+0x10c/0x1b0 [btrfs] ? wait_woken+0xa0/0xa0 btrfs_wait_ordered_range+0xbb/0x100 [btrfs] btrfs_relocate_block_group+0x1ff/0x230 [btrfs] btrfs_relocate_chunk+0x49/0x100 [btrfs] btrfs_balance+0xbeb/0x1740 [btrfs] btrfs_ioctl_balance+0x2ee/0x380 [btrfs] btrfs_ioctl+0x1691/0x3110 [btrfs] ? lockdep_hardirqs_on+0xed/0x180 ? __handle_mm_fault+0x8e7/0xfb0 ? _raw_spin_unlock+0x24/0x30 ? __handle_mm_fault+0x8e7/0xfb0 ? do_vfs_ioctl+0xa5/0x6e0 ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] do_vfs_ioctl+0xa5/0x6e0 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ksys_ioctl+0x3a/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This happens because during page writeback it's valid for writepage_delalloc to instantiate a delalloc range which doesn't belong to the page currently being written back. The reason this case is valid is due to find_lock_delalloc_range returning any available range after the passed delalloc_start and ignoring whether the page under writeback is within that range. In turn ordered extents (OE) are always created for the returned range from find_lock_delalloc_range. If, however, a failure occurs while OE are being created then the clean up code in btrfs_cleanup_ordered_extents will be called. Unfortunately the code in btrfs_cleanup_ordered_extents doesn't consider the case of such 'foreign' range being processed and instead it always assumes that the range OE are created for belongs to the page. This leads to the first page of such foregin range to not be cleaned up since it's deliberately missed and skipped by the current cleaning up code. Fix this by correctly checking whether the current page belongs to the range being instantiated and if so adjsut the range parameters passed for cleaning up. If it doesn't, then just clean the whole OE range directly. Fixes: 52427260 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang") CC: stable@vger.kernel.org # 4.14+ Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit 5eaad97a ] This callback is called only from writepage_delalloc which in turn is guaranteed to be called from the data page writeout path. In the end there is no reason to have the call to this function to be indrected via the extent_io_ops structure. This patch removes the callback definition, exports the function and calls it directly. No functional changes. Reviewed-by:
-
Filipe Manana authored
[ Upstream commit a5fb1142 ] When a transaction commit starts, it attempts to pause scrub and it blocks until the scrub is paused. So while the transaction is blocked waiting for scrub to pause, we can not do memory allocation with GFP_KERNEL from scrub, otherwise we risk getting into a deadlock with reclaim. Checking for scrub pause requests is done early at the beginning of the while loop of scrub_stripe() and later in the loop, scrub_extent() and scrub_raid56_parity() are called, which in turn call scrub_pages() and scrub_pages_for_parity() respectively. These last two functions do memory allocations using GFP_KERNEL. Same problem could happen while scrubbing the super blocks, since it calls scrub_pages(). We also can not have any of the worker tasks, created by the scrub task, doing GFP_KERNEL allocations, because before pausing, the scrub task waits for all the worker tasks to complete (also done at scrub_stripe()). So make sure GFP_NOFS is used for the memory allocations because at any time a scrub pause request can happen from another task that started to commit a transaction. Fixes: 58c4e173 ("btrfs: scrub: use GFP_KERNEL on the submission path") CC: stable@vger.kernel.org # 4.6+ Reviewed-by:
-
Omar Sandoval authored
[ Upstream commit 32934280 ] struct scrub_ctx has an ->is_dev_replace member, so there's no point in passing around is_dev_replace where sctx is available. Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
-
Paul Mackerras authored
[ Upstream commit 234ff0b7 ] Testing has revealed an occasional crash which appears to be caused by a race between kvmppc_switch_mmu_to_hpt and kvm_unmap_hva_range_hv. The symptom is a NULL pointer dereference in __find_linux_pte() called from kvm_unmap_radix() with kvm->arch.pgtable == NULL. Looking at kvmppc_switch_mmu_to_hpt(), it does indeed clear kvm->arch.pgtable (via kvmppc_free_radix()) before setting kvm->arch.radix to NULL, and there is nothing to prevent kvm_unmap_hva_range_hv() or the other MMU callback functions from being called concurrently with kvmppc_switch_mmu_to_hpt() or kvmppc_switch_mmu_to_radix(). This patch therefore adds calls to spin_lock/unlock on the kvm->mmu_lock around the assignments to kvm->arch.radix, and makes sure that the partition-scoped radix tree or HPT is only freed after changing kvm->arch.radix. This also takes the kvm->mmu_lock in kvmppc_rmap_reset() to make sure that the clearing of each rmap array (one per memslot) doesn't happen concurrently with use of the array in the kvm_unmap_hva_range_hv() or the other MMU callbacks. Fixes: 18c3640c ("KVM: PPC: Book3S HV: Add infrastructure for running HPT guests on radix host") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 30b71084 ] Since the gt powerstate is allocated by i915_gem_init, clean it from i915_gem_fini for symmetry and to correct the imbalance on error. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180812223642.24865-1-chris@chris-wilson.co.ukSigned-off-by:
-
Chris Wilson authored
[ Upstream commit 7ed43df7 ] If we fail during GEM initialisation, we scrub the HW state by performing a device level GPU resuet. However, we want to leave the system in a usable state (with functioning KMS but no GEM) so after scrubbing the HW state, we need to restore some sane defaults and re-enable the low-level common parts of the GPU (such as the GMCH). v2: Restore GTT entries. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 52117be6 ] The use of flush_schedule_work() made no sense and caused a syzkaller error. Replace with the correct cancel_delayed_work_sync(). Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 144bd0ee ] v4l2_ctrl uses mutexes, so we can't setup a ctrl_handler in interrupt context. Switch to a workqueue instead and drop the timer. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by:
-
Harald Freudenberger authored
[ Upstream commit 104f708f ] Until the vfio-ap driver came into live there was a well known agreement about the way how ap devices are initialized and their states when the driver's probe function is called. However, the vfio device driver when receiving an ap queue device does additional resets thereby removing the registration for interrupts for the ap device done by the ap bus core code. So when later the vfio driver releases the device and one of the default zcrypt drivers takes care of the device the interrupt registration needs to get renewed. The current code does no renew and result is that requests send into such a queue will never see a reply processed - the application hangs. This patch adds a function which resets the aq queue state machine for the ap queue device and triggers the walk through the initial states (which are reset and registration for interrupts). This function is now called before the driver's probe function is invoked. When the association between driver and device is released, the driver's remove function is called. The current implementation calls a ap queue function ap_queue_remove(). This invokation has been moved to the ap bus function to make the probe / remove pair for ap bus and drivers more symmetric. Fixes: 7e0bdbe5 ("s390/zcrypt: AP bus support for alternate driver(s)") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Reviewd-by:
Tony Krowiak <akrowiak@linux.ibm.com> Reviewd-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit adcf60ce ] Since commit eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 27db7baa ] Since commit eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 2c9c8349 ] Since commit eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 193c0437 ] Since commit eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 58a0afbf ] Since commit eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range. Fixes: eb3744a2 ("gpio: davinci: Do not assume continuous IRQ numbering") Cc: stable@vger.kernel.org Signed-off-by:
-
Lyude Paul authored
[ Upstream commit 04ac4b0e ] Path property is used for userspace to know what MST connector goes to what actual DRM DisplayPort connector, the tiling property is for tiling configurations. Not sure what else there is to figure out. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Rex Zhu authored
[ Upstream commit 4d454e9f ] the clk value should be tranferred to MHz first and then transfer to uint16. otherwise, the clock value will be truncated. Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
David Francis authored
[ Upstream commit f191415b ] In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit e670de54 ] In kvp_send_key(), we do need call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out the userland hv_kvp_daemon needs the info of operation, adapter_id and addr_family. With the incorrect fc62c3b1, the host can't get the VM's IP via KVP. And, fc62c3b1 added a "break;", but actually forgot to initialize the key_size/value in the case of KVP_OP_SET, so the default key_size of 0 is passed to the kvp daemon, and the pool files /var/lib/hyperv/.kvp_pool_* can't be updated. This patch effectively rolls back the previous fc62c3b1, and correctly fixes the "this statement may fall through" warnings. This patch is tested on WS 2012 R2 and 2016. Fixes: fc62c3b1 ("Drivers: hv: kvp: Fix two "this statement may fall through" warnings") Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit d544c22d ] No functional change. Signed-off-by:
-
Lyude Paul authored
[ Upstream commit 4d802739 ] With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by:
-
Imre Deak authored
[ Upstream commit 914a4fd8 ] If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console. The problem was bisected to commit 011f22eb ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue. Kudos to Ville who suspected a missing fence looking at the corruption on the screen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: <ronald@innovation.ch> Cc: <stable@vger.kernel.org> Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: <ronald@innovation.ch> Tested-by: <ronald@innovation.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dff ("drm/i915/skl: Provide a Skylake version of get_plane_config()") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
[ Upstream commit 53867b46 ] Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Lyude Paul authored
[ Upstream commit a9f9ca33 ] Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit a7c42bb6 ] vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any order. Values match, however, kvm_lapic_enable_pv_eoi() uses different length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM native case it is 8. In case we restore KVM-native MSR last cache will be reinitialized with len=8 so trying to access VP assist page beyond 8 bytes with kvm_read_guest_cached() will fail. Check if we re-initializing cache for the same address and preserve length in case it was greater. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ladi Prosek authored
[ Upstream commit 72bbf935 ] The state related to the VP assist page is still managed by the LAPIC code in the pv_eoi field. Signed-off-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
Liran Alon <liran.alon@oracle.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 87ee613d ] In most common cases VP index of a vcpu matches its vcpu index. Userspace is, however, free to set any mapping it wishes and we need to account for that when we need to find a vCPU with a particular VP index. To keep search algorithms optimal in both cases introduce 'num_mismatched_vp_indexes' counter showing how many vCPUs with mismatching VP index we have. In case the counter is zero we can assume vp_index == vcpu_idx. Signed-off-by:
Roman Kagan <rkagan@virtuozzo.com> Signed-off-by:
-
