aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-17drm/cirrus: Remove obsolete header fileThomas Zimmermann1-247/+0
The cirrus driver's header file is left over from a recent rewrite. Remove it. Signed-off-by: Thomas Zimmermann <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2019-10-17drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONSGerd Hoffmann6-38/+5
Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/vram: drop verify_accessGerd Hoffmann1-22/+0
Not needed any more. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/vram: switch vram helper to &drm_gem_object_funcs.mmap()Gerd Hoffmann2-41/+2
Wire up the new drm_gem_ttm_mmap() helper function, use generic drm_gem_mmap for &fops.mmap and delete dead drm_vram_mm_file_operations_mmap(). Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/ttm: add drm_gem_ttm_mmap()Gerd Hoffmann2-0/+19
Add helper function to mmap ttm bo's using &drm_gem_object_funcs.mmap(). Note that with this code path access verification is done by drm_gem_mmap() (which calls drm_vma_node_is_allowed(()). The &ttm_bo_driver.verify_access() callback is is not used. v3: use ttm_bo_mmap_obj instead of ttm_bo_mmap_vma_setup Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/ttm: rename ttm_fbdev_mmapGerd Hoffmann3-13/+10
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj. Move the vm_pgoff sanity check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree). The ttm_bo_mmap_obj function can now be used to map any buffer object. This allows to implement &drm_gem_object_funcs.mmap in gem ttm helpers. v3: patch added to series Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/ttm: factor out ttm_bo_mmap_vma_setupGerd Hoffmann1-22/+24
Factor out ttm vma setup to a new function. Reduces code duplication a bit. v2: don't change vm_flags (moved to separate patch). v4: make ttm_bo_mmap_vma_setup static. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPSGerd Hoffmann6-31/+5
DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now, drop it. Signed-off-by: Gerd Hoffmann <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: drop VM_IOGerd Hoffmann1-1/+1
VM_IO is wrong here, shmem uses normal ram not io memory. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: drop VM_DONTDUMPGerd Hoffmann1-1/+1
Not obvious why this is needed. According to Deniel Vetter this is most likely a historic artefact dating back to the days where drm drivers exposed hardware registers as mmap'able gem objects, to avoid dumping touching those registers. shmem gem objects surely don't need that ... Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmapGerd Hoffmann5-25/+15
Switch gem shmem helper to the new mmap() workflow, from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap. v2: Fix vm_flags and vm_page_prot handling. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm: add mmap() to drm_gem_object_funcsGerd Hoffmann3-9/+41
drm_gem_object_funcs->vm_ops alone can't handle everything which needs to be done for mmap(), tweaking vm_flags for example. So add a new mmap() callback to drm_gem_object_funcs where this code can go to. Note that the vm_ops field is not used in case the mmap callback is present, it is expected that the callback sets vma->vm_ops instead. Also setting vm_flags and vm_page_prot is the job of the new callback. so drivers have more control over these flags. drm_gem_mmap_obj() will use the new callback for object specific mmap setup. With this in place the need for driver-speific fops->mmap callbacks goes away, drm_gem_mmap can be hooked instead. drm_gem_prime_mmap() will use the new callback too to just mmap gem objects directly instead of jumping though loops to make drm_gem_object_lookup() and fops->mmap work. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/i915: Fix MST oops due to MSA changesVille Syrjälä1-1/+3
The MSA MISC computation now depends on the connector state, and we do it from the DDI .pre_enable() hook. All that is fine for DP SST but with MST we don't actually pass the connector state to the dig port's .pre_enable() hook which leads to an oops. Need to think more how to solve this in a cleaner fashion, but for now let's just add a NULL check to stop the oopsing. Cc: Gwan-gyeong Mun <[email protected]> Cc: Uma Shankar <[email protected]> Fixes: 0c06fa156006 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]>
2019-10-17stop_machine: Avoid potential race behaviourMark Rutland1-4/+6
Both multi_cpu_stop() and set_state() access multi_stop_data::state racily using plain accesses. These are subject to compiler transformations which could break the intended behaviour of the code, and this situation is detected by KCSAN on both arm64 and x86 (splats below). Improve matters by using READ_ONCE() and WRITE_ONCE() to ensure that the compiler cannot elide, replay, or tear loads and stores. In multi_cpu_stop() the two loads of multi_stop_data::state are expected to be a consistent value, so snapshot the value into a temporary variable to ensure this. The state transitions are serialized by atomic manipulation of multi_stop_data::num_threads, and other fields in multi_stop_data are not modified while subject to concurrent reads. KCSAN splat on arm64: | BUG: KCSAN: data-race in multi_cpu_stop+0xa8/0x198 and set_state+0x80/0xb0 | | write to 0xffff00001003bd00 of 4 bytes by task 24 on cpu 3: | set_state+0x80/0xb0 | multi_cpu_stop+0x16c/0x198 | cpu_stopper_thread+0x170/0x298 | smpboot_thread_fn+0x40c/0x560 | kthread+0x1a8/0x1b0 | ret_from_fork+0x10/0x18 | | read to 0xffff00001003bd00 of 4 bytes by task 14 on cpu 1: | multi_cpu_stop+0xa8/0x198 | cpu_stopper_thread+0x170/0x298 | smpboot_thread_fn+0x40c/0x560 | kthread+0x1a8/0x1b0 | ret_from_fork+0x10/0x18 | | Reported by Kernel Concurrency Sanitizer on: | CPU: 1 PID: 14 Comm: migration/1 Not tainted 5.3.0-00007-g67ab35a199f4-dirty #3 | Hardware name: linux,dummy-virt (DT) KCSAN splat on x86: | write to 0xffffb0bac0013e18 of 4 bytes by task 19 on cpu 2: | set_state kernel/stop_machine.c:170 [inline] | ack_state kernel/stop_machine.c:177 [inline] | multi_cpu_stop+0x1a4/0x220 kernel/stop_machine.c:227 | cpu_stopper_thread+0x19e/0x280 kernel/stop_machine.c:516 | smpboot_thread_fn+0x1a8/0x300 kernel/smpboot.c:165 | kthread+0x1b5/0x200 kernel/kthread.c:255 | ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:352 | | read to 0xffffb0bac0013e18 of 4 bytes by task 44 on cpu 7: | multi_cpu_stop+0xb4/0x220 kernel/stop_machine.c:213 | cpu_stopper_thread+0x19e/0x280 kernel/stop_machine.c:516 | smpboot_thread_fn+0x1a8/0x300 kernel/smpboot.c:165 | kthread+0x1b5/0x200 kernel/kthread.c:255 | ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:352 | | Reported by Kernel Concurrency Sanitizer on: | CPU: 7 PID: 44 Comm: migration/7 Not tainted 5.3.0+ #1 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Marco Elver <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-10-17drm: Add TODO item for fbdev driver conversionThomas Zimmermann1-0/+27
The DRM TODO list now contains an entry for converting fbdev drivers over to DRM. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/i915/pmu: Support multiple GPUsTvrtko Ursulin2-2/+31
With discrete graphics system can have both integrated and discrete GPU handled by i915. Currently we use a fixed name ("i915") when registering as the uncore PMU provider which stops working in this case. To fix this we add the PCI device name string to non-integrated devices handled by us. Integrated devices keep the legacy name preserving backward compatibility. v2: * Detect IGP and keep legacy name. (Michal) * Use PCI device name as suffix. (Michal, Chris) v3: * Constify the name. (Chris) * Use pci_domain_nr. (Chris) v4: * Fix kfree_const usage. (Chris) v5: * kfree_const does not work for modules. (Chris) * Changed is_igp helper to take i915. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Michal Wajdeczko <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17ALSA: hda/realtek - Enable headset mic on Asus MJ401TADaniel Drake1-0/+11
On Asus MJ401TA (with Realtek ALC256), the headset mic is connected to pin 0x19, with default configuration value 0x411111f0 (indicating no physical connection). Enable this by quirking the pin. Mic jack detection was also tested and found to be working. This enables use of the headset mic on this product. Signed-off-by: Daniel Drake <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-10-17ALSA: usb-audio: Disable quirks for BOSS Katana amplifiersSzabolcs Szőke1-0/+3
BOSS Katana amplifiers cannot be used for recording or playback if quirks are applied BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 Signed-off-by: Szabolcs Szőke <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-10-17kheaders: substituting --sort in archive creationDmitry Goldin1-4/+7
The option --sort=ORDER was only introduced in tar 1.28 (2014), which is rather new and might not be available in some setups. This patch tries to replicate the previous behaviour as closely as possible to fix the kheaders build for older environments. It does not produce identical archives compared to the previous version due to minor sorting differences but produces reproducible results itself in my tests. Reported-by: Andreas Schwab <[email protected]> Signed-off-by: Dmitry Goldin <[email protected]> Tested-by: Andreas Schwab <[email protected]> Tested-by: Quentin Perret <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2019-10-16drm/i915/tgl: Enable DDI/Port GKhaled Almahallawy5-0/+16
In TGL there we are missing the initialization of port G. Do the same as for other ports. Signed-off-by: Khaled Almahallawy <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16net: stmmac: disable/enable ptp_ref_clk in suspend/resume flowBiao Huang1-4/+8
disable ptp_ref_clk in suspend flow, and enable it in resume flow. Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure") Signed-off-by: Biao Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-16net: phy: Fix "link partner" information disappear issueYonglong Liu3-4/+12
Some drivers just call phy_ethtool_ksettings_set() to set the links, for those phy drivers that use genphy_read_status(), if autoneg is on, and the link is up, than execute "ethtool -s ethx autoneg on" will cause "link partner" information disappear. The call trace is phy_ethtool_ksettings_set()->phy_start_aneg() ->linkmode_zero(phydev->lp_advertising)->genphy_read_status(), the link didn't change, so genphy_read_status() just return, and phydev->lp_advertising is zero now. This patch moves the clear operation of lp_advertising from phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and if autoneg on and autoneg not complete, just clear what the generic functions care about. Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") Signed-off-by: Yonglong Liu <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-16drm/i810: Refer to `PREEMPTION' in commentSebastian Andrzej Siewior1-1/+1
The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect this change in the comment. Use `PREEMPTION' in the comment. Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16rxrpc: use rcu protection while reading sk->sk_user_dataEric Dumazet1-4/+8
We need to extend the rcu_read_lock() section in rxrpc_error_report() and use rcu_dereference_sk_user_data() instead of plain access to sk->sk_user_data to make sure all rules are respected. The compiler wont reload sk->sk_user_data at will, and RCU rules prevent memory beeing freed too soon. Fixes: f0308fb07080 ("rxrpc: Fix possible NULL pointer access in ICMP handling") Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: Eric Dumazet <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-16drm/i915: Move swizzle_bit under i915_ggttChris Wilson6-24/+25
The HW performs swizzling as part of its fence tiling inside the Global GTT. We already do the probing of the HW settings from the GGTT setup, complete the picture by storing the information as part of the GGTT. The primary benefit is the consistency of our probe routines do not break the i915_ggtt encapsulation. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Store i915_ggtt as the backpointer on fence registersChris Wilson7-41/+54
Now that i915_ggtt knows everything about its own paths to perform mmio, we can use that as our primary backpointer for individual fence registers. This reduces the amount of pointer dancing we have to perform on the common paths, but more importantly finishes our fence register encapsulation. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Do initial mocs configuration directlyChris Wilson3-220/+66
Now that we record the default "goldenstate" context, we do not need to emit the mocs registers at the start of each context and can simply do mmio before the first context and capture the registers as part of its default image. As a consequence, this means that we repeat the mmio after each engine reset, fixing up any platform and registers that were zapped by the reset (for those platforms with global not context-saved settings). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111723 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111645 Signed-off-by: Chris Wilson <[email protected]> Cc: Prathap Kumar Valsan <[email protected]> Reviewed-by: Prathap Kumar Valsan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Fixup preempt-to-busy vs resubmission of a virtual requestChris Wilson1-6/+26
As preempt-to-busy leaves the request on the HW as the resubmission is processed, that request may complete in the background and even cause a second virtual request to enter queue. This second virtual request breaks our "single request in the virtual pipeline" assumptions. Furthermore, as the virtual request may be completed and retired, we lose the reference the virtual engine assumes is held. Normally, just removing the request from the scheduler queue removes it from the engine, but the virtual engine keeps track of its singleton request via its ve->request. This pointer needs protecting with a reference. v2: Drop unnecessary motion of rq->engine = owner Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit b647c7df01b75761b4c0b1cb6f4841088c0b1121) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-16drm/i915/userptr: Never allow userptr into the mappable GGTTChris Wilson5-1/+19
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to invalidate userptr objects which also happen to be pulled into GGTT mmaps. That is when we unbind the userptr object (on mmu invalidation), we revoke all CPU mmaps, which may then recurse into mmu invalidation. We looked for ways of breaking the cycle, but the revocation on invalidation is required and cannot be avoided. The only solution we could see was to not allow such GGTT bindings of userptr objects in the first place. In practice, no one really wants to use a GGTT mmapping of a CPU pointer... Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got a genuine blip from CI: <4>[ 246.793958] ====================================================== <4>[ 246.793972] WARNING: possible circular locking dependency detected <4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U <4>[ 246.794003] ------------------------------------------------------ <4>[ 246.794017] kswapd0/145 is trying to acquire lock: <4>[ 246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794250] but task is already holding lock: <4>[ 246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0 <4>[ 246.794291] which lock already depends on the new lock. <4>[ 246.794307] the existing dependency chain (in reverse order) is: <4>[ 246.794322] -> #3 (&anon_vma->rwsem){++++}: <4>[ 246.794344] down_write+0x33/0x70 <4>[ 246.794357] __vma_adjust+0x3d9/0x7b0 <4>[ 246.794370] __split_vma+0x16a/0x180 <4>[ 246.794385] mprotect_fixup+0x2a5/0x320 <4>[ 246.794399] do_mprotect_pkey+0x208/0x2e0 <4>[ 246.794413] __x64_sys_mprotect+0x16/0x20 <4>[ 246.794429] do_syscall_64+0x55/0x1c0 <4>[ 246.794443] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794456] -> #2 (&mapping->i_mmap_rwsem){++++}: <4>[ 246.794478] down_write+0x33/0x70 <4>[ 246.794493] unmap_mapping_pages+0x48/0x130 <4>[ 246.794519] i915_vma_revoke_mmap+0x81/0x1b0 [i915] <4>[ 246.794519] i915_vma_unbind+0x11d/0x4a0 [i915] <4>[ 246.794519] i915_vma_destroy+0x31/0x300 [i915] <4>[ 246.794519] __i915_gem_free_objects+0xb8/0x4b0 [i915] <4>[ 246.794519] drm_file_free.part.0+0x1e6/0x290 <4>[ 246.794519] drm_release+0xa6/0xe0 <4>[ 246.794519] __fput+0xc2/0x250 <4>[ 246.794519] task_work_run+0x82/0xb0 <4>[ 246.794519] do_exit+0x35b/0xdb0 <4>[ 246.794519] do_group_exit+0x34/0xb0 <4>[ 246.794519] __x64_sys_exit_group+0xf/0x10 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #1 (&vm->mutex){+.+.}: <4>[ 246.794519] i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915] <4>[ 246.794519] i915_address_space_init+0x9f/0x160 [i915] <4>[ 246.794519] i915_ggtt_init_hw+0x55/0x170 [i915] <4>[ 246.794519] i915_driver_probe+0xc9f/0x1620 [i915] <4>[ 246.794519] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 246.794519] pci_device_probe+0x9e/0x120 <4>[ 246.794519] really_probe+0xea/0x3d0 <4>[ 246.794519] driver_probe_device+0x10b/0x120 <4>[ 246.794519] device_driver_attach+0x4a/0x50 <4>[ 246.794519] __driver_attach+0x97/0x130 <4>[ 246.794519] bus_for_each_dev+0x74/0xc0 <4>[ 246.794519] bus_add_driver+0x13f/0x210 <4>[ 246.794519] driver_register+0x56/0xe0 <4>[ 246.794519] do_one_initcall+0x58/0x300 <4>[ 246.794519] do_init_module+0x56/0x1f6 <4>[ 246.794519] load_module+0x25bd/0x2a40 <4>[ 246.794519] __se_sys_finit_module+0xd3/0xf0 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #0 (&dev->struct_mutex/1){+.+.}: <4>[ 246.794519] __lock_acquire+0x15d8/0x1e90 <4>[ 246.794519] lock_acquire+0xa6/0x1c0 <4>[ 246.794519] __mutex_lock+0x9d/0x9b0 <4>[ 246.794519] userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794519] __mmu_notifier_invalidate_range_start+0x85/0x110 <4>[ 246.794519] try_to_unmap_one+0x76b/0x860 <4>[ 246.794519] rmap_walk_anon+0x104/0x280 <4>[ 246.794519] try_to_unmap+0xc0/0xf0 <4>[ 246.794519] shrink_page_list+0x561/0xc10 <4>[ 246.794519] shrink_inactive_list+0x220/0x440 <4>[ 246.794519] shrink_node_memcg+0x36e/0x740 <4>[ 246.794519] shrink_node+0xcb/0x490 <4>[ 246.794519] balance_pgdat+0x241/0x580 <4>[ 246.794519] kswapd+0x16c/0x530 <4>[ 246.794519] kthread+0x119/0x130 <4>[ 246.794519] ret_from_fork+0x24/0x50 <4>[ 246.794519] other info that might help us debug this: <4>[ 246.794519] Chain exists of: &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem <4>[ 246.794519] Possible unsafe locking scenario: <4>[ 246.794519] CPU0 CPU1 <4>[ 246.794519] ---- ---- <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&mapping->i_mmap_rwsem); <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&dev->struct_mutex/1); <4>[ 246.794519] *** DEADLOCK *** v2: Say no to mmap_ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870 Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a4311745bba9763e3c965643d4531bd5765b0513) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-16drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pinVille Syrjälä1-6/+16
The first come first served apporoach to handling the VBT child device AUX ch conflicts has backfired. We have machines in the wild where the VBT specifies both port A eDP and port E DP (in that order) with port E being the real one. So let's try to flip the preference around and let the last child device win once again. Cc: [email protected] Cc: Jani Nikula <[email protected]> Tested-by: Masami Ichikawa <[email protected]> Tested-by: Torsten <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> (cherry picked from commit 41e35ffb380bde1379e4030bb5b2ac824d5139cf) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-16drm/i915/execlists: Refactor -EIO markup of hung requestsChris Wilson1-14/+17
Pull setting -EIO on the hung requests into its own utility function. Having allowed ourselves to short-circuit submission of completed requests, we can now do the mark_eio() prior to submission and avoid some redundant operations. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0d7cf7bc15e75bf79f2f65d61d19f896609f816a) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-16Revert "blackhole_netdev: fix syzkaller reported issue"Mahesh Bandewar2-12/+10
This reverts commit b0818f80c8c1bc215bba276bd61c216014fab23b. Started seeing weird behavior after this patch especially in the IPv6 code path. Haven't root caused it, but since this was applied to net branch, taking a precautionary measure to revert it and look / analyze those failures Revert this now and I'll send a better fix after analysing / fixing the weirdness observed. CC: Eric Dumazet <[email protected]> CC: Wei Wang <[email protected]> CC: David S. Miller <[email protected]> Signed-off-by: Mahesh Bandewar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-10-16drm/i915/selftests: Teach timelines to take intel_gt as its argumentChris Wilson1-23/+25
The timelines selftests are [mostly] hardware centric and so want to use the gt as its target. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915/selftests: Teach workarounds to take intel_gt as its argumentChris Wilson1-63/+65
The workarounds selftests are hardware centric and so want to use the gt as its target. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915/selftests: Teach guc to take intel_gt as its argumentChris Wilson1-28/+14
The guc selftests are hardware^W firmare centric and so want to use the gt as its target. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915/selftests: Teach execlists to take intel_gt as its argumentChris Wilson1-147/+143
The execlists selftests are hardware centric and so want to use the gt as its target. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16arm64: tags: Preserve tags for addresses translated via TTBR1Will Deacon3-8/+13
Sign-extending TTBR1 addresses when converting to an untagged address breaks the documented POSIX semantics for mlock() in some obscure error cases where we end up returning -EINVAL instead of -ENOMEM as a direct result of rewriting the upper address bits. Rework the untagged_addr() macro to preserve the upper address bits for TTBR1 addresses and only clear the tag bits for user addresses. This matches the behaviour of the 'clear_address_tag' assembly macro, so rename that and align the implementations at the same time so that they use the same instruction sequences for the tag manipulation. Link: https://lore.kernel.org/stable/[email protected]/ Reported-by: Jan Stancek <[email protected]> Tested-by: Jan Stancek <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Tested-by: Catalin Marinas <[email protected]> Reviewed-by: Vincenzo Frascino <[email protected]> Tested-by: Vincenzo Frascino <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-16arm64: mm: fix inverted PAR_EL1.F checkMark Rutland1-1/+5
When detecting a spurious EL1 translation fault, we have the CPU retry the translation using an AT S1E1R instruction, and inspect PAR_EL1 to determine if the fault was spurious. When PAR_EL1.F == 0, the AT instruction successfully translated the address without a fault, which implies the original fault was spurious. However, in this case we return false and treat the original fault as if it was not spurious. Invert the return value so that we treat such a case as spurious. Cc: Catalin Marinas <[email protected]> Fixes: 42f91093b043 ("arm64: mm: Ignore spurious translation faults taken from the kernel") Tested-by: James Morse <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-16arm64: sysreg: fix incorrect definition of SYS_PAR_EL1_FYang Yingliang1-1/+1
The 'F' field of the PAR_EL1 register lives in bit 0, not bit 1. Fix the broken definition in 'sysreg.h'. Fixes: e8620cff9994 ("arm64: sysreg: Add some field definitions for PAR_EL1") Reviewed-by: Mark Rutland <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-16arm64: entry.S: Do not preempt from IRQ before all cpufeatures are enabledJulien Thierry3-1/+20
Preempting from IRQ-return means that the task has its PSTATE saved on the stack, which will get restored when the task is resumed and does the actual IRQ return. However, enabling some CPU features requires modifying the PSTATE. This means that, if a task was scheduled out during an IRQ-return before all CPU features are enabled, the task might restore a PSTATE that does not include the feature enablement changes once scheduled back in. * Task 1: PAN == 0 ---| |--------------- | |<- return from IRQ, PSTATE.PAN = 0 | <- IRQ | +--------+ <- preempt() +-- ^ | reschedule Task 1, PSTATE.PAN == 1 * Init: --------------------+------------------------ ^ | enable_cpu_features set PSTATE.PAN on all CPUs Worse than this, since PSTATE is untouched when task switching is done, a task missing the new bits in PSTATE might affect another task, if both do direct calls to schedule() (outside of IRQ/exception contexts). Fix this by preventing preemption on IRQ-return until features are enabled on all CPUs. This way the only PSTATE values that are saved on the stack are from synchronous exceptions. These are expected to be fatal this early, the exception is BRK for WARN_ON(), but as this uses do_debug_exception() which keeps IRQs masked, it shouldn't call schedule(). Signed-off-by: Julien Thierry <[email protected]> [james: Replaced a really cool hack, with an even simpler static key in C. expanded commit message with Julien's cover-letter ascii art] Signed-off-by: James Morse <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-10-16Merge branch 'md-fixes' of ↵Jens Axboe1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-linus Pull MD fix from Song. * 'md-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: md/raid0: fix warning message for parameter default_layout
2019-10-16md/raid0: fix warning message for parameter default_layoutSong Liu1-1/+1
The message should match the parameter, i.e. raid0.default_layout. Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.") Cc: NeilBrown <[email protected]> Reported-by: Ivan Topolsky <[email protected]> Signed-off-by: Song Liu <[email protected]>
2019-10-16kthread: make __kthread_queue_delayed_work staticBen Dooks1-3/+3
The __kthread_queue_delayed_work is not exported so make it static, to avoid the following sparse warning: kernel/kthread.c:869:6: warning: symbol '__kthread_queue_delayed_work' was not declared. Should it be static? Signed-off-by: Ben Dooks <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-10-16drm/i915: Introduce Jasper Lake PCHMatt Roper3-3/+32
The Jasper Lake PCH follows ICP/TGP's south display behavior and is identical to MCC graphics-wise except that it does not use the unusual (port C -> TC1) pin mapping that MCC does. Also, it turns out the extra PCH ID that we had previously thought was a form of MCC is actually a second ID for JSP (i.e., port C uses the port C pins instead of the TC1 pins). v2: - Also update the port masks (not just the pin table) in mcc_hpd_irq_setup. (Vivek) v3: - Break jsp_hpd_irq_setup out into its own function for clarity. (Vivek) Cc: José Roberto de Souza <[email protected]> Cc: James Ausmus <[email protected]> Cc: Vivek Kasireddy <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Vivek Kasireddy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915/ehl: Don't forget to set TC long detect functionMatt Roper1-0/+1
Since EHL's MCC PCH reuses one of the TC pins we need to supply a TC long detect function when handling the interrupts. Fixes: 53448aed7b80 ("drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits") Reported-by: kbuild test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Cc: Vivek Kasireddy <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Vivek Kasireddy <[email protected]>
2019-10-16drm/i915: Prepare the mode readout for hw vs. uapi state splitVille Syrjälä1-1/+1
Prepare the mode readout for the uapi vs. hw state split. We'll want to do all readout into the hw state. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Prepare the connector/encoder mask readout for hw vs. uapi state splitVille Syrjälä1-5/+9
Prepare the connector/encoder mask readout for the uapi vs. hw state split. We'll want to do all readout into the hw state. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Switch intel_legacy_cursor_update() to intel_ typesVille Syrjälä1-42/+42
Prefer the intel_ types in intel_legacy_cursor_update() over the drm_ types. Should make it easier to adapt this to the uapi vs. hw state split. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915: Refactor timestamping constants updateVille Syrjälä1-7/+11
Once we do the hw vs. uapi split we can no longer use drm_atomic_helper_calc_timestamping_constants() as it'll consult the uapi state instead of the hw state. So let's just update the vblank timestamping constants whenever we update the scanline offset. We use both to convert the hw scanline count to something which matches the software timing values. First I thought to put these into intel_crtc_vblank_on() but we may want to get the scanline counter value before that (eg. from some early tracepoints), so let's stick to updating them a bit earlier than intel_crtc_vblank_on(). Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-16drm/i915/execlist: Trim immediate timeslice expiryChris Wilson3-11/+39
We perform timeslicing immediately upon receipt of a request that may be put into the second ELSP slot. The idea behind this was that since we didn't install the timer if the second ELSP slot was empty, we would not have any idea of how long ELSP[0] had been running and so giving the newcomer a chance on the GPU was fair. However, this causes us extra busy work that we may be able to avoid if we wait a jiffie for the first timeslice as normal. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.