aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-11-14drm/i915/gen8+: Add RC6 CTX corruption WAImre Deak7-2/+86
In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: - Rebased on latest upstream gt_pm refactoring. v6: - s/i915_rc6_/intel_rc6_/ - Don't return a value from i915_rc6_ctx_wa_check(). v7: - Rebased on latest gt rc6 refactoring. Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> [airlied: pull this later version of this patch into drm-next to make resolving the conflict mess easier.] Signed-off-by: Dave Airlie <[email protected]>
2019-11-14Merge tag 'arcpgu-updates-2019.07.18' of github.com:abrodkin/linux into drm-nextDave Airlie1-3/+13
This is a pretty simple improvement that allows to find encoder as the one and only (ARC PGU doesn't support more than one) endpoint instead of using non-standard "encoder-slave" property. Signed-off-by: Dave Airlie <[email protected]> From: Alexey Brodkin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CY4PR1201MB0120FDB10A777345F9C27720A1C90@CY4PR1201MB0120.namprd12.prod.outlook.com
2019-11-14Merge tag 'drm-misc-next-fixes-2019-11-13' of ↵Dave Airlie1-5/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-next - Fix memory leak in gpu debugfs node's release (Johan) Cc: Johan Hovold <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20191113211056.GA78440@art_vandelay
2019-11-14Merge tag 'drm-next-5.5-2019-11-08' of ↵Dave Airlie28-62/+368
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.5-2019-11-08: amdgpu: - Enable VCN dynamic powergating on RV/RV2 - Fixes for Navi14 - Misc Navi fixes - Fix MSI-X tear down - Misc Arturus fixes - Fix xgmi powerstate handling - Documenation fixes scheduler: - Fix static code checker warning - Fix possible thread reactivation while thread is stopped - Avoid cleanup if thread is parked radeon: - SI dpm fix ported from amdgpu Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-13drm/msm: fix memleak on releaseJohan Hovold1-5/+1
If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable <[email protected]> # 4.18 Cc: Jordan Crouse <[email protected]> Cc: Rob Clark <[email protected]> Reviewed-by: Rob Clark <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-13drm/amdgpu/vcn: finish delay work before release resourcesAlex Deucher1-0/+2
flush/cancel delayed works before doing finalization to avoid concurrently requests. Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-13drm/amd/powerplay: read pcie speed/width info (v2)Kenneth Feng4-9/+69
sysfs interface to read pcie speed&width info on navi1x. v2: fix warning (trivial) Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-14Merge v5.4-rc7 into drm-nextDave Airlie399-2398/+7044
We have the i915 security fixes to backmerge, but first let's clear the decks for other drivers to avoid a bigger mess. Signed-off-by: Dave Airlie <[email protected]>
2019-11-13drm/i915: Split a setting of MSA to MST and SSTGwan-gyeong Mun2-4/+8
The setting of MSA is done by the DDI .pre_enable() hook. And when we are using MST, the MSA is only set to first mst stream by calling of DDI .pre_eanble() hook. It raies issues to non-first mst streams. Wrong MSA or missed MSA packets might show scrambled screen or wrong screen. This splits a setting of MSA to MST and SST cases. And In the MST case it will call a setting of MSA after an allocating of Virtual Channel from MST encoder pre_enable callback. Cc: Ville Syrjälä <[email protected]> Cc: Stanislav Lisovskiy <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212 Fixes: 0c06fa156006 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Fixes: d4a415dcda35 ("drm/i915: Fix MST oops due to MSA changes") Signed-off-by: Gwan-gyeong Mun <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lucas De Marchi <[email protected]> [vsyrjala: nuke spurious newline] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit bd8c9cca88765caee0dfa93967c6d8f16b4cbfb9) Signed-off-by: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-13drm/i915/execlists: Move reset_active() from schedule-out to schedule-inChris Wilson1-56/+62
The gem_ctx_persistence/smoketest was detecting an odd coherency issue inside the LRC context image; that the address of the ring buffer did not match our associated struct intel_ring. As we set the address into the context image when we pin the ring buffer into place before the context is active, that leaves the question of where did it get overwritten. Either the HW context save occurred after our pin which would imply that our idle barriers are broken, or we overwrote the context image ourselves. It is only in reset_active() where we dabble inside the context image outside of a serialised path from schedule-out; but we could equally perform the operation inside schedule-in which is then fully serialised with the context pin -- and remains serialised by the engine pulse with kill_context(). (The only downside, aside from doing more work inside the engine->active.lock, was the plan to merge all the reset paths into doing their context scrubbing on schedule-out needs more thought.) Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on schedule-out") Testcase: igt/gem_ctx_persistence/smoketest 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] (cherry picked from commit 31b61f0ef9af62b6404d8df5dcd2cf58f80c9f53) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-12drm/i915/userptr: Try to acquire the page lock around set_page_dirty()Chris Wilson1-1/+21
set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: cb6d7c7dc7ff ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: 505a8ec7e11a ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"") References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers") Signed-off-by: Chris Wilson <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: [email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0d4bbe3d407f79438dc4f87943db21f7134cfc65) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-12drm/i915/pmu: "Frequency" is reported as accumulated cyclesChris Wilson1-2/+2
We report "frequencies" (actual-frequency, requested-frequency) as the number of accumulated cycles so that the average frequency over that period may be determined by the user. This means the units we report to the user are Mcycles (or just M), not MHz. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: [email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e88866ef02851c88fe95a4bb97820b94b4d46f36) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-12drm/i915: Protect context while grabbing its name for the requestChris Wilson1-0/+2
Inside print_request(), we query the context/timeline name. Nothing immediately protects the context from being freed if the request is complete -- we rely on serialisation by the caller to keep the name valid until they finish using it. Inside intel_engine_dump(), we generally only print the requests in the execution queue protected by the engine->active.lock, but we also show the pending execlists ports which are not protected and so require a rcu_read_lock to keep the pointer valid. [ 1695.700883] BUG: KASAN: use-after-free in i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.700981] Read of size 8 at addr ffff8887344f4d50 by task gem_ctx_persist/2968 [ 1695.701068] [ 1695.701156] CPU: 1 PID: 2968 Comm: gem_ctx_persist Tainted: G U 5.4.0-rc6+ #331 [ 1695.701246] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 1695.701334] Call Trace: [ 1695.701424] dump_stack+0x5b/0x90 [ 1695.701870] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.701964] print_address_description.constprop.7+0x36/0x50 [ 1695.702408] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.702856] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.702947] __kasan_report.cold.10+0x1a/0x3a [ 1695.703390] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.703836] i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.704241] print_request+0x82/0x2e0 [i915] [ 1695.704638] ? fwtable_read32+0x133/0x360 [i915] [ 1695.705042] ? write_timestamp+0x110/0x110 [i915] [ 1695.705133] ? _raw_spin_lock_irqsave+0x79/0xc0 [ 1695.705221] ? refcount_inc_not_zero_checked+0x91/0x110 [ 1695.705306] ? refcount_dec_and_mutex_lock+0x50/0x50 [ 1695.705709] ? intel_engine_find_active_request+0x202/0x230 [i915] [ 1695.706115] intel_engine_dump+0x2c9/0x900 [i915] Fixes: c36eebd9ba5d ("drm/i915/gt: execlists->active is serialised by the tasklet") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit fecffa4668cf62e679aeea8caa9d0f241f822578) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-12drm/i915/perf: always consider holding preemption a privileged opLionel Landwerlin1-10/+10
The ordering of the checks in the existing code can lead to holding preemption not being considered as privileged op. Signed-off-by: Lionel Landwerlin <[email protected]> Fixes: 9cd20ef7803c ("drm/i915/perf: allow holding preemption on filtered ctx") Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0b0120d4c7b013eba59b33254febc0a6e4049e13) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/amdgpu/smu_v11: Unify and fix power limitsMatt Coffin8-28/+78
[Why] On Navi10, and presumably arcterus, updating pp_table via sysfs would not re-scale the maximum possible power limit one can set. On navi10, the SMU code ignored the power percentage overdrive setting entirely, and would not allow you to exceed the default power limit at all. [How] Adding a function to the SMU interface to get the pptable version of the default power limit allows ASIC-specific code to provide the correct maximum-settable power limit for the current pptable. v3: fix spelling (Alex) Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Matt Coffin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amdgpu/navi10: Implement od clk printingMatt Coffin1-5/+51
[Why] Before this patch, navi10 overdrive settings could not be printed via pp_od_clk_voltage [How] Implement printing for the overdrive settings for the following clocks in navi10's ppt print_clk_levels implementation: * SMU_OD_SCLK * SMU_OD_MCLK * SMU_OD_VDDC_CURVE Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Matt Coffin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amdgpu/navi10: implement GFXCLK_CURVE overdriveMatt Coffin2-2/+60
[Why] Before this patch, there was no way to set the gfxclk voltage curve in the overdrive settings for navi10 through pp_od_clk_voltage [How] Add the required implementation to navi10's ppt dpm table editing implementation, similar to the vega20 implementation and interface. Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Matt Coffin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amdgpu/navi10: implement sclk/mclk OD via pp_od_clk_voltageMatt Coffin3-0/+209
[Why] Before this patch, there was no way to use pp_od_clk_voltage on navi [How] Similar to the vega20 implementation, but using the common smc_v11_0 headers, implemented the pp_od_clk_voltage API for navi10's pptable implementation Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Matt Coffin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amd/amdgpu: finish delay works before release resourcesJesse Zhang3-0/+5
flush/cancel delayed works before doing finalization to avoid concurrently requests. Signed-off-by: Jesse Zhang <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/radeon: Clean up code in radeon_pci_shutdown()KyleMahlkuch1-6/+3
This fixes the formatting on one comment and consolidates the pci_get_drvdata() into the radeon_suspend_kms(). Signed-off-by: Kyle Mahlkuch <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amdgpu/powerplay/smu7: fix AVFS handling with custom powerplay tableAlex Deucher1-0/+7
When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/amdgpu: avoid upload corrupted ta ucode to pspHawking Zhang1-1/+21
xgmi, ras, hdcp and dtm ta are actually separated ucode and need to handled case by case to upload to psp. We support the case that ta binary have one or multiple of them built-in. As a result, the driver should check each ta binariy's availablity before decide to upload them to psp. In the terminate (unload) case, the driver will check the context readiness before perform unload activity. It's fine to keep it as is. Signed-off-by: Hawking Zhang <[email protected]> Reviewed-by: Le Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-11drm/i915/cmdparser: Fix jump whitelist clearingBen Hutchings1-3/+2
When a jump_whitelist bitmap is reused, it needs to be cleared. Currently this is done with memset() and the size calculation assumes bitmaps are made of 32-bit words, not longs. So on 64-bit architectures, only the first half of the bitmap is cleared. If some whitelist bits are carried over between successive batches submitted on the same context, this will presumably allow embedding the rogue instructions that we're trying to reject. Use bitmap_zero() instead, which gets the calculation right. Fixes: f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps") Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Jon Bloomfield <[email protected]>
2019-11-11drm/i915: Preload LUTs if the hw isn't currently using themVille Syrjälä4-0/+69
The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for that at the moment so we just defer loading them after the vblank waits have happened. That is not quite sufficient (especially when committing multiple pipes whose vblanks don't line up) so the LUT load will often leak into the following frame causing tearing. However in case the hardware wasn't previously using the LUT we can preload it before setting the enable bit (which is double buffered so won't tear). Let's determine if we can do such preloading and make it happen. Slight variation between the hardware requires some platforms specifics in the checks. Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win and Asus T100HA) when the gamma LUT gets loaded for the first time as the BIOS has left some junk in the LUT memory. v2: Deal with uapi vs. hw crtc state split s/GCM/CGM/ typo fix Cc: Hans de Goede <[email protected]> Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank waits") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Hans de Goede <[email protected]> Reviewed-by: Hans de Goede <[email protected]> (cherry picked from commit 0ccc42a2fd5107a7f58e62c8b35b61de9a70ce82) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/i915: Don't oops in dumb_create ioctl if we have no crtcsVille Syrjälä1-0/+3
Make sure we have a crtc before probing its primary plane's max stride. Initially I thought we can't get this far without crtcs, but looks like we can via the dumb_create ioctl. Not sure if we shouldn't disable dumb buffer support entirely when we have no crtcs, but that would require some amount of work as the only thing currently being checked is dev->driver->dumb_create which we'd have to convert to some device specific dynamic thing. Cc: [email protected] Reported-by: Mika Kuoppala <[email protected]> Fixes: aa5ca8b7421c ("drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit baea9ffe64200033499a4955f431e315bb807899) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/i915: Leave the aliasing-ppgtt size aloneChris Wilson1-2/+0
The hidden aliasing-ppgtt's size is never revealed, as we only inspect the front GTT when engaged. However, we were "fixing" the hidden ppgtt to match, with the net result that we ended up leaking the unused portion on Braswell were we preallocated the entire set of top level PDP, see gen8_preallocate_top_level_pdp(). [ 26.025364] DMA-API: pci 0000:00:02.0: device driver has pending DMA allocations while released from device [count=2] [ 26.025364] One of leaked entries details: [device address=0x0000000230778000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as single] [ 26.025683] WARNING: CPU: 0 PID: 415 at kernel/dma/debug.c:894 dma_debug_device_change+0x1a4/0x1f0 [ 26.025905] Modules linked in: i915(E-) intel_powerclamp(E) nls_ascii(E) nls_cp437(E) crct10dif_pclmul(E) crc32_pclmul(E) vfat(E) crc32c_intel(E) fat(E) ghash_clmulni_intel(E) prime_numbers(E) intel_gtt(E) i2c_algo_bit(E) efi_pstore(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) evdev(E) drm(E) aesni_intel(E) glue_helper(E) crypto_simd(E) cryptd(E) intel_cstate(E) sg(E) efivars(E) pcspkr(E) video(E) button(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) sd_mod(E) lpc_ich(E) ahci(E) mfd_core(E) i2c_i801(E) libahci(E) i2c_designware_pci(E) i2c_designware_core(E) [ 26.026613] CPU: 0 PID: 415 Comm: rmmod Tainted: G E 5.4.0-rc6+ #25 [ 26.026837] Hardware name: /, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 26.027080] RIP: 0010:dma_debug_device_change+0x1a4/0x1f0 [ 26.027319] Code: 89 54 24 08 e8 ad 60 62 00 48 8b 54 24 08 48 89 c6 41 57 4d 89 e9 49 89 d8 44 89 f1 41 54 48 c7 c7 e0 61 06 82 e8 c1 aa f5 ff <0f> 0b 5a 59 48 83 3c 24 00 0f 85 97 26 00 00 8b 05 77 47 92 01 85 [ 26.027600] RSP: 0018:ffff888228d2fcc8 EFLAGS: 00010282 [ 26.027831] RAX: 0000000000000000 RBX: 0000000230778000 RCX: 0000000000000000 [ 26.028053] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffed10451a5f8f [ 26.028279] RBP: ffff88823480c0b0 R08: 0000000000000001 R09: ffffed1046e83eb1 [ 26.028500] R10: ffffed1046e83eb0 R11: ffff88823741f587 R12: ffffffff82067340 [ 26.028725] R13: 0000000000001000 R14: 0000000000000002 R15: ffffffff82067480 [ 26.028952] FS: 00007fdf3ed174c0(0000) GS:ffff888237400000(0000) knlGS:0000000000000000 [ 26.029185] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.029405] CR2: 000055e211109030 CR3: 0000000230139000 CR4: 00000000001006f0 [ 26.029622] Call Trace: [ 26.029846] notifier_call_chain+0x67/0xa0 [ 26.030076] blocking_notifier_call_chain+0x5a/0x80 [ 26.030305] device_release_driver_internal+0x20d/0x260 [ 26.030535] driver_detach+0x7b/0xe1 [ 26.030761] bus_remove_driver+0x8c/0x153 [ 26.030993] pci_unregister_driver+0x2d/0xf0 [ 26.032603] i915_exit+0x16/0x1c [i915] Reported-by: Ville Syrjälä <[email protected]> Fixes: 1eda701eace2 ("drm/i915/gtt: Recursive cleanup for gen8") References: c082afac86cb ("drm/i915: Move aliasing_ppgtt underneath its i915_ggtt") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2b0a4fc25ad8e3da4a156995a513dca6abf247de) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/i915/display: only include intel_dp_link_training.h where neededJani Nikula2-1/+1
The intel_dp_link_training.h include has no need or place in intel_display.h. Include it in intel_display.c instead. Cc: Manasi Navare <[email protected]> Fixes: eadf6f9170d5 ("drm/i915/display/icl: Enable master-slaves in trans port sync") Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3c954c418eb363343ff515756e440aa1dc216e0b) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/i915/gem: Fix error path to unlock if the GEM context is closedChris Wilson1-1/+1
When inside the lock, remember to unlock even if you want to leave early. Reported-by: Dan Carpenter <[email protected]> Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM") 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] (cherry picked from commit feba2b8146633390f8df44946eceb4274f7377ed) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-11drm/i915/gt: Only drop heartbeat.systole if the sole ownerChris Wilson1-2/+2
Mika spotted that only using cancel_delayed_work() could mean that we attempted to clear the heartbeat.systole while the worker was still running. Rectify the situation by only touching the systole from outside the worker if we suceeded in cancelling the worker before it could run. The worker is expected to clean up by itself upon idling. Reported-by: Mika Kuoppala <[email protected]> Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 841e86728615baa77b0ea9d8b357e66052c75fe5) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-10Merge tag 'armsoc-fixes' of ↵Linus Torvalds2-6/+7
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A set of fixes that have trickled in over the last couple of weeks: - MAINTAINER update for Cavium/Marvell ThunderX2 - stm32 tweaks to pinmux for Joystick/Camera, and RAM allocation for CAN interfaces - i.MX fixes for voltage regulator GPIO mappings, fixes voltage scaling issues - More i.MX fixes for various issues on i.MX eval boards: interrupt storm due to u-boot leaving pins in new states, fixing power button config, a couple of compatible-string corrections. - Powerdown and Suspend/Resume fixes for Allwinner A83-based tablets - A few documentation tweaks and a fix of a memory leak in the reset subsystem" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: MAINTAINERS: update Cavium ThunderX2 maintainers ARM: dts: stm32: change joystick pinctrl definition on stm32mp157c-ev1 ARM: dts: stm32: remove OV5640 pinctrl definition on stm32mp157c-ev1 ARM: dts: stm32: Fix CAN RAM mapping on stm32mp157c ARM: dts: stm32: relax qspi pins slew-rate for stm32mp157 arm64: dts: zii-ultra: fix ARM regulator GPIO handle ARM: sunxi: Fix CPU powerdown on A83T ARM: dts: sun8i-a83t-tbs-a711: Fix WiFi resume from suspend arm64: dts: imx8mn: fix compatible string for sdma arm64: dts: imx8mm: fix compatible string for sdma reset: fix reset_control_ops kerneldoc comment ARM: dts: imx6-logicpd: Re-enable SNVS power key soc: imx: gpc: fix initialiser format ARM: dts: imx6qdl-sabreauto: Fix storm of accelerometer interrupts arm64: dts: ls1028a: fix a compatible issue reset: fix reset_control_get_exclusive kerneldoc comment reset: fix reset_control_lookup kerneldoc comment reset: fix of_reset_control_get_count kerneldoc comment reset: fix of_reset_simple_xlate kerneldoc comment reset: Fix memory leak in reset_control_array_put()
2019-11-10Merge tag 'staging-5.4-rc7' of ↵Linus Torvalds18-20/+3318
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull IIO fixes and staging driver from Greg KH: "Here is a mix of a number of IIO driver fixes for 5.4-rc7, and a whole new staging driver. The IIO fixes resolve some reported issues, all are tiny. The staging driver addition is the vboxsf filesystem, which is the VirtualBox guest shared folder code. Hans has been trying to get filesystem reviewers to review the code for many months now, and Christoph finally said to just merge it in staging now as it is stand-alone and the filesystem people can review it easier over time that way. I know it's late for this big of an addition, but it is stand-alone. The code has been in linux-next for a while, long enough to pick up a few tiny fixes for it already so people are looking at it. All of these have been in linux-next with no reported issues" * tag 'staging-5.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: Fix error return code in vboxsf_fill_super() staging: vboxsf: fix dereference of pointer dentry before it is null checked staging: vboxsf: Remove unused including <linux/version.h> staging: Add VirtualBox guest shared folder (vboxsf) support iio: adc: stm32-adc: fix stopping dma iio: imu: inv_mpu6050: fix no data on MPU6050 iio: srf04: fix wrong limitation in distance measuring iio: imu: adis16480: make sure provided frequency is positive
2019-11-10Merge tag 'char-misc-5.4-rc7' of ↵Linus Torvalds11-26/+45
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are a number of late-arrival driver fixes for issues reported for some char/misc drivers for 5.4-rc7 These all come from the different subsystem/driver maintainers as things that they had reports for and wanted to see fixed. All of these have been in linux-next with no reported issues" * tag 'char-misc-5.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: intel_th: pci: Add Jasper Lake PCH support intel_th: pci: Add Comet Lake PCH support intel_th: msu: Fix possible memory leak in mode_store() intel_th: msu: Fix overflow in shift of an unsigned int intel_th: msu: Fix missing allocation failure check on a kstrndup intel_th: msu: Fix an uninitialized mutex intel_th: gth: Fix the window switching sequence soundwire: slave: fix scanf format soundwire: intel: fix intel_register_dai PDI offsets and numbers interconnect: Add locking in icc_set_tag() interconnect: qcom: Fix icc_onecell_data allocation soundwire: depend on ACPI || OF soundwire: depend on ACPI thunderbolt: Drop unnecessary read when writing LC command in Ice Lake thunderbolt: Fix lockdep circular locking depedency warning thunderbolt: Read DP IN adapter first two dwords in one go
2019-11-10Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2-13/+13
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Thomas Gleixner: "A small set of fixes for timekeepoing and clocksource drivers: - VDSO data was updated conditional on the availability of a VDSO capable clocksource. This causes the VDSO functions which do not depend on a VDSO capable clocksource to operate on stale data. Always update unconditionally. - Prevent a double free in the mediatek driver - Use the proper helper in the sh_mtu2 driver so it won't attempt to initialize non-existing interrupts" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping/vsyscall: Update VDSO data unconditionally clocksource/drivers/sh_mtu2: Do not loop using platform_get_irq_by_name() clocksource/drivers/mediatek: Fix error handling
2019-11-09Merge tag 'pinctrl-v5.4-3' of ↵Linus Torvalds3-28/+33
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Fix glitch risks in the Intel GPIO - Fix the Intel Cherryview valid irq mask calculation. - Allocate the Intel Cherryview irqchip dynamically. - Fix the valid mask init sequency on the ST STMFX driver. * tag 'pinctrl-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: stmfx: fix valid_mask init sequence pinctrl: cherryview: Allocate IRQ chip dynamic pinctrl: cherryview: Fix irq_valid_mask calculation pinctrl: intel: Avoid potential glitches if pin is in GPIO mode
2019-11-09Merge tag 'linux-watchdog-5.4-rc7' of ↵Linus Torvalds5-8/+28
git://www.linux-watchdog.org/linux-watchdog Pull watchdog fixes from Wim Van Sebroeck: - cpwd: fix build regression - pm8916_wdt: fix pretimeout registration flow - meson: Fix the wrong value of left time - imx_sc_wdt: Pretimeout should follow SCU firmware format - bd70528: Add MODULE_ALIAS to allow module auto loading * tag 'linux-watchdog-5.4-rc7' of git://www.linux-watchdog.org/linux-watchdog: watchdog: bd70528: Add MODULE_ALIAS to allow module auto loading watchdog: imx_sc_wdt: Pretimeout should follow SCU firmware format watchdog: meson: Fix the wrong value of left time watchdog: pm8916_wdt: fix pretimeout registration flow watchdog: cpwd: fix build regression
2019-11-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds60-376/+690
Pull networking fixes from David Miller: 1) BPF sample build fixes from Björn Töpel 2) Fix powerpc bpf tail call implementation, from Eric Dumazet. 3) DCCP leaks jiffies on the wire, fix also from Eric Dumazet. 4) Fix crash in ebtables when using dnat target, from Florian Westphal. 5) Fix port disable handling whne removing bcm_sf2 driver, from Florian Fainelli. 6) Fix kTLS sk_msg trim on fallback to copy mode, from Jakub Kicinski. 7) Various KCSAN fixes all over the networking, from Eric Dumazet. 8) Memory leaks in mlx5 driver, from Alex Vesker. 9) SMC interface refcounting fix, from Ursula Braun. 10) TSO descriptor handling fixes in stmmac driver, from Jose Abreu. 11) Add a TX lock to synchonize the kTLS TX path properly with crypto operations. From Jakub Kicinski. 12) Sock refcount during shutdown fix in vsock/virtio code, from Stefano Garzarella. 13) Infinite loop in Intel ice driver, from Colin Ian King. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (108 commits) ixgbe: need_wakeup flag might not be set for Tx i40e: need_wakeup flag might not be set for Tx igb/igc: use ktime accessors for skb->tstamp i40e: Fix for ethtool -m issue on X722 NIC iavf: initialize ITRN registers with correct values ice: fix potential infinite loop because loop counter being too small qede: fix NULL pointer deref in __qede_remove() net: fix data-race in neigh_event_send() vsock/virtio: fix sock refcnt holding during the shutdown net: ethernet: octeon_mgmt: Account for second possible VLAN header mac80211: fix station inactive_time shortly after boot net/fq_impl: Switch to kvmalloc() for memory allocation mac80211: fix ieee80211_txq_setup_flows() failure path ipv4: Fix table id reference in fib_sync_down_addr ipv6: fixes rt6_probe() and fib6_nh->last_probe init net: hns: Fix the stray netpoll locks causing deadlock in NAPI path net: usb: qmi_wwan: add support for DW5821e with eSIM support CDC-NCM: handle incomplete transfer of MTU nfc: netlink: fix double device reference drop NFC: st21nfca: fix double free ...
2019-11-08Merge tag 'for-linus-2019-11-08' of git://git.kernel.dk/linux-blockLinus Torvalds3-1/+10
Pull block fixes from Jens Axboe: - Two NVMe device removal crash fixes, and a compat fixup for for an ioctl that was introduced in this release (Anton, Charles, Max - via Keith) - Missing error path mutex unlock for drbd (Dan) - cgroup writeback fixup on dead memcg (Tejun) - blkcg online stats print fix (Tejun) * tag 'for-linus-2019-11-08' of git://git.kernel.dk/linux-block: cgroup,writeback: don't switch wbs immediately on dead wbs if the memcg is dead block: drbd: remove a stray unlock in __drbd_send_protocol() blkcg: make blkcg_print_stat() print stats only for online blkgs nvme: change nvme_passthru_cmd64 to explicitly mark rsvd nvme-multipath: fix crash in nvme_mpath_clear_ctrl_paths nvme-rdma: fix a segmentation fault during module unload
2019-11-08Merge branch '40GbE' of ↵David S. Miller8-24/+15
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue Jeff Kirsher says: ==================== Intel Wired LAN Driver Fixes 2019-11-08 This series contains fixes to igb, igc, ixgbe, i40e, iavf and ice drivers. Colin Ian King fixes a potentially wrap-around counter in a for-loop. Nick fixes the default ITR values for the iavf driver to 50 usecs interval. Arkadiusz fixes 'ethtool -m' for X722 devices where the correct value cannot be obtained from the firmware, so add X722 to the check to ensure the wrong value is not returned. Jake fixes igb and igc drivers in their implementation of launch time support by declaring skb->tstamp value as ktime_t instead of s64. Magnus fixes ixgbe and i40e where the need_wakeup flag for transmit may not be set for AF_XDP sockets that are only used to send packets. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-08ixgbe: need_wakeup flag might not be set for TxMagnus Karlsson1-8/+2
The need_wakeup flag for Tx might not be set for AF_XDP sockets that are only used to send packets. This happens if there is at least one outstanding packet that has not been completed by the hardware and we get that corresponding completion (which will not generate an interrupt since interrupts are disabled in the napi poll loop) between the time we stopped processing the Tx completions and interrupts are enabled again. In this case, the need_wakeup flag will have been cleared at the end of the Tx completion processing as we believe we will get an interrupt from the outstanding completion at a later point in time. But if this completion interrupt occurs before interrupts are enable, we lose it and should at that point really have set the need_wakeup flag since there are no more outstanding completions that can generate an interrupt to continue the processing. When this happens, user space will see a Tx queue need_wakeup of 0 and skip issuing a syscall, which means will never get into the Tx processing again and we have a deadlock. This patch introduces a quick fix for this issue by just setting the need_wakeup flag for Tx to 1 all the time. I am working on a proper fix for this that will toggle the flag appropriately, but it is more challenging than I anticipated and I am afraid that this patch will not be completed before the merge window closes, therefore this easier fix for now. This fix has a negative performance impact in the range of 0% to 4%. Towards the higher end of the scale if you have driver and application on the same core and issue a lot of packets, and towards no negative impact if you use two cores, lower transmission speeds and/or a workload that also receives packets. Signed-off-by: Magnus Karlsson <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08i40e: need_wakeup flag might not be set for TxMagnus Karlsson1-8/+2
The need_wakeup flag for Tx might not be set for AF_XDP sockets that are only used to send packets. This happens if there is at least one outstanding packet that has not been completed by the hardware and we get that corresponding completion (which will not generate an interrupt since interrupts are disabled in the napi poll loop) between the time we stopped processing the Tx completions and interrupts are enabled again. In this case, the need_wakeup flag will have been cleared at the end of the Tx completion processing as we believe we will get an interrupt from the outstanding completion at a later point in time. But if this completion interrupt occurs before interrupts are enable, we lose it and should at that point really have set the need_wakeup flag since there are no more outstanding completions that can generate an interrupt to continue the processing. When this happens, user space will see a Tx queue need_wakeup of 0 and skip issuing a syscall, which means will never get into the Tx processing again and we have a deadlock. This patch introduces a quick fix for this issue by just setting the need_wakeup flag for Tx to 1 all the time. I am working on a proper fix for this that will toggle the flag appropriately, but it is more challenging than I anticipated and I am afraid that this patch will not be completed before the merge window closes, therefore this easier fix for now. This fix has a negative performance impact in the range of 0% to 4%. Towards the higher end of the scale if you have driver and application on the same core and issue a lot of packets, and towards no negative impact if you use two cores, lower transmission speeds and/or a workload that also receives packets. Signed-off-by: Magnus Karlsson <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08igb/igc: use ktime accessors for skb->tstampJacob Keller3-4/+6
When implementing launch time support in the igb and igc drivers, the skb->tstamp value is assumed to be a s64, but it's declared as a ktime_t value. Although ktime_t is typedef'd to s64 it wasn't always, and the kernel provides accessors for ktime_t values. Use the ktime_to_timespec64 and ktime_set accessors instead of directly assuming that the variable is always an s64. This improves portability if the code is ever moved to another kernel version, or if the definition of ktime_t ever changes again in the future. Signed-off-by: Jacob Keller <[email protected]> Acked-by: Vinicius Costa Gomes <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08i40e: Fix for ethtool -m issue on X722 NICArkadiusz Kubalewski1-1/+2
This patch contains fix for a problem with command: 'ethtool -m <dev>' which breaks functionality of: 'ethtool <dev>' when called on X722 NIC Disallowed update of link phy_types on X722 NIC Currently correct value cannot be obtained from FW Previously wrong value returned by FW was used and was a root cause for incorrect output of 'ethtool <dev>' command Signed-off-by: Arkadiusz Kubalewski <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08iavf: initialize ITRN registers with correct valuesNicholas Nunley1-2/+2
Since commit 92418fb14750 ("i40e/i40evf: Use usec value instead of reg value for ITR defines") the driver tracks the interrupt throttling intervals in single usec units, although the actual ITRN registers are programmed in 2 usec units. Most register programming flows in the driver correctly handle the conversion, although it is currently not applied when the registers are initialized to their default values. Most of the time this doesn't present a problem since the default values are usually immediately overwritten through the standard adaptive throttling mechanism, or updated manually by the user, but if adaptive throttling is disabled and the interval values are left alone then the incorrect value will persist. Since the intended default interval of 50 usecs (vs. 100 usecs as programmed) performs better for most traffic workloads, this can lead to performance regressions. This patch adds the correct conversion when writing the initial values to the ITRN registers. Signed-off-by: Nicholas Nunley <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08ice: fix potential infinite loop because loop counter being too smallColin Ian King1-1/+1
Currently the for-loop counter i is a u8 however it is being checked against a maximum value hw->num_tx_sched_layers which is a u16. Hence there is a potential wrap-around of counter i back to zero if hw->num_tx_sched_layers is greater than 255. Fix this by making i a u16. Addresses-Coverity: ("Infinite loop") Fixes: b36c598c999c ("ice: Updates to Tx scheduler code") Signed-off-by: Colin Ian King <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-11-08qede: fix NULL pointer deref in __qede_remove()Manish Chopra1-2/+10
While rebooting the system with SR-IOV vfs enabled leads to below crash due to recurrence of __qede_remove() on the VF devices (first from .shutdown() flow of the VF itself and another from PF's .shutdown() flow executing pci_disable_sriov()) This patch adds a safeguard in __qede_remove() flow to fix this, so that driver doesn't attempt to remove "already removed" devices. [ 194.360134] BUG: unable to handle kernel NULL pointer dereference at 00000000000008dc [ 194.360227] IP: [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede] [ 194.360304] PGD 0 [ 194.360325] Oops: 0000 [#1] SMP [ 194.360360] Modules linked in: tcp_lp fuse tun bridge stp llc devlink bonding ip_set nfnetlink ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_umad rpcrdma sunrpc rdma_ucm ib_uverbs ib_iser rdma_cm iw_cm ib_cm libiscsi scsi_transport_iscsi dell_smbios iTCO_wdt iTCO_vendor_support dell_wmi_descriptor dcdbas vfat fat pcc_cpufreq skx_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd qedr ib_core pcspkr ses enclosure joydev ipmi_ssif sg i2c_i801 lpc_ich mei_me mei wmi ipmi_si ipmi_devintf ipmi_msghandler tpm_crb acpi_pad acpi_power_meter xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel mgag200 [ 194.361044] qede i2c_algo_bit drm_kms_helper qed syscopyarea sysfillrect nvme sysimgblt fb_sys_fops ttm nvme_core mpt3sas crc8 ptp drm pps_core ahci raid_class scsi_transport_sas libahci libata drm_panel_orientation_quirks nfit libnvdimm dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables] [ 194.361297] CPU: 51 PID: 7996 Comm: reboot Kdump: loaded Not tainted 3.10.0-1062.el7.x86_64 #1 [ 194.361359] Hardware name: Dell Inc. PowerEdge MX840c/0740HW, BIOS 2.4.6 10/15/2019 [ 194.361412] task: ffff9cea9b360000 ti: ffff9ceabebdc000 task.ti: ffff9ceabebdc000 [ 194.361463] RIP: 0010:[<ffffffffc03553c4>] [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede] [ 194.361534] RSP: 0018:ffff9ceabebdfac0 EFLAGS: 00010282 [ 194.361570] RAX: 0000000000000000 RBX: ffff9cd013846098 RCX: 0000000000000000 [ 194.361621] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9cd013846098 [ 194.361668] RBP: ffff9ceabebdfae8 R08: 0000000000000000 R09: 0000000000000000 [ 194.361715] R10: 00000000bfe14201 R11: ffff9ceabfe141e0 R12: 0000000000000000 [ 194.361762] R13: ffff9cd013846098 R14: 0000000000000000 R15: ffff9ceab5e48000 [ 194.361810] FS: 00007f799c02d880(0000) GS:ffff9ceacb0c0000(0000) knlGS:0000000000000000 [ 194.361865] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 194.361903] CR2: 00000000000008dc CR3: 0000001bdac76000 CR4: 00000000007607e0 [ 194.361953] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 194.362002] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 194.362051] PKRU: 55555554 [ 194.362073] Call Trace: [ 194.362109] [<ffffffffc0355500>] qede_remove+0x10/0x20 [qede] [ 194.362180] [<ffffffffb97d0f3e>] pci_device_remove+0x3e/0xc0 [ 194.362240] [<ffffffffb98b3c52>] __device_release_driver+0x82/0xf0 [ 194.362285] [<ffffffffb98b3ce3>] device_release_driver+0x23/0x30 [ 194.362343] [<ffffffffb97c86d4>] pci_stop_bus_device+0x84/0xa0 [ 194.362388] [<ffffffffb97c87e2>] pci_stop_and_remove_bus_device+0x12/0x20 [ 194.362450] [<ffffffffb97f153f>] pci_iov_remove_virtfn+0xaf/0x160 [ 194.362496] [<ffffffffb97f1aec>] sriov_disable+0x3c/0xf0 [ 194.362534] [<ffffffffb97f1bc3>] pci_disable_sriov+0x23/0x30 [ 194.362599] [<ffffffffc02f83c3>] qed_sriov_disable+0x5e3/0x650 [qed] [ 194.362658] [<ffffffffb9622df6>] ? kfree+0x106/0x140 [ 194.362709] [<ffffffffc02cc0c0>] ? qed_free_stream_mem+0x70/0x90 [qed] [ 194.362754] [<ffffffffb9622df6>] ? kfree+0x106/0x140 [ 194.362803] [<ffffffffc02cd659>] qed_slowpath_stop+0x1a9/0x1d0 [qed] [ 194.362854] [<ffffffffc035544e>] __qede_remove+0xae/0x130 [qede] [ 194.362904] [<ffffffffc03554e0>] qede_shutdown+0x10/0x20 [qede] [ 194.362956] [<ffffffffb97cf90a>] pci_device_shutdown+0x3a/0x60 [ 194.363010] [<ffffffffb98b180b>] device_shutdown+0xfb/0x1f0 [ 194.363066] [<ffffffffb94b66c6>] kernel_restart_prepare+0x36/0x40 [ 194.363107] [<ffffffffb94b66e2>] kernel_restart+0x12/0x60 [ 194.363146] [<ffffffffb94b6959>] SYSC_reboot+0x229/0x260 [ 194.363196] [<ffffffffb95f200d>] ? handle_mm_fault+0x39d/0x9b0 [ 194.363253] [<ffffffffb942b621>] ? __switch_to+0x151/0x580 [ 194.363304] [<ffffffffb9b7ec28>] ? __schedule+0x448/0x9c0 [ 194.363343] [<ffffffffb94b69fe>] SyS_reboot+0xe/0x10 [ 194.363387] [<ffffffffb9b8bede>] system_call_fastpath+0x25/0x2a [ 194.363430] Code: f9 e9 37 ff ff ff 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 4c 8d af 98 00 00 00 41 54 4c 89 ef 41 89 f4 53 e8 4c e4 55 f9 <80> b8 dc 08 00 00 01 48 89 c3 4c 8d b8 c0 08 00 00 4c 8b b0 c0 [ 194.363712] RIP [<ffffffffc03553c4>] __qede_remove+0x24/0x130 [qede] [ 194.363764] RSP <ffff9ceabebdfac0> [ 194.363791] CR2: 00000000000008dc Signed-off-by: Manish Chopra <[email protected]> Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Sudarsana Kalluru <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-08Merge tag 'pwm/for-5.4-rc7' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm fix from Thierry Reding: "One more fix to keep a reference to the driver's module as long as there are users of the PWM exposed by the driver" * tag 'pwm/for-5.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: bcm-iproc: Prevent unloading the driver module while in use
2019-11-08net: ethernet: octeon_mgmt: Account for second possible VLAN headerAlexander Sverdlin1-1/+1
Octeon's input ring-buffer entry has 14 bits-wide size field, so to account for second possible VLAN header max_mtu must be further reduced. Fixes: 109cc16526c6d ("ethernet/cavium: use core min/max MTU checking") Signed-off-by: Alexander Sverdlin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-08pwm: bcm-iproc: Prevent unloading the driver module while in useUwe Kleine-König1-0/+1
The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-11-08drm/amdgpu/powerplay: fix AVFS handling with custom powerplay tableAlex Deucher1-0/+7
When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-08drm/amd/powerplay: dynamically disable ds and ulv for computeKenneth Feng3-0/+65
This is to improve the performance in the compute mode for vega10. For example, the original performance for a rocm bandwidth test: 2G internal GPU copy, is about 99GB/s. With the idle power features disabled dynamically, the porformance is promoted to about 215GB/s. Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Evan Quan <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.