- 10 Feb, 2020 2 commits
-
-
Chris Wilson authored
Take and hold a reference to each of the vma (and their objects) as we process them with the cmdparser. This stops them being freed during the work if the GEM execbuf is interrupted and the request we expected to keep the objects alive is incomplete. Fixes: 686c7c35 ("drm/i915/gem: Asynchronous cmdparser") Closes: https://gitlab.freedesktop.org/drm/intel/issues/970Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200113154555.1909639-1-chris@chris-wilson.co.uk (cherry picked from commit 36c8e356) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Chris Wilson authored
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 and then upon first activity (park/unpark) add in all the rc6 residency since boot. After the first park with the sampler engaged, the sleep/active counters are aligned. v2: With a wakeref to be sure Closes: https://gitlab.freedesktop.org/drm/intel/issues/973 Fixes: df6a4205 ("drm/i915/pmu: Ensure monotonic rc6") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200114105648.2172026-1-chris@chris-wilson.co.uk (cherry picked from commit f4e9894b) Signed-off-by:
-
- 09 Feb, 2020 5 commits
-
-
Zhang Xiaoxu authored
Since commit 742379c0 ("drm/i915: Start chopping up the GPU error capture"), function 'i915_error_state_store' was defined and used with only one parameter. But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined with two parameter. This may lead compile error. This patch fix it. Fixes: 742379c0 ("drm/i915: Start chopping up the GPU error capture") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by:
Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
Vandita Kulkarni authored
Fix htotal and vtotal parameters derived from DTD block of VBT. The values miss the back porch. Fixes: 33ef6d4f ("drm/i915/vbt: Handle generic DTD block") Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Vivek Kasireddy authored
Remove the i2c_bus_num >= 0 check from the adapter lookup function as this would prevent ACPI bus number override. This check was mainly there to return early if the bus number has already been found but we anyway return in the next line if the slave address does not match. Fixes: 8cbf89db ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 05a8e451 ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-1-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit d0eed154) Signed-off-by:
-
Vivek Kasireddy authored
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is enabled in the kernel config. If ACPI is not enabled or if the lookup fails, we'll fallback to using the VBT for identifying the i2c bus. v2: Add fixes tag (Jani) Fixes: 8cbf89db ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reported-by:
-
- 07 Feb, 2020 3 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.6-2020-02-05: amdgpu: - EDC fixes for Arcturus - GDDR6 memory training fixe - Fix for reading gfx clockgating registers while in GFXOFF state - i2c freq fixes - Misc display fixes - TLB invalidation fix when using semaphores - VCN 2.5 instancing fixes - Switch raven1 gfxoff to a blacklist - Coreboot workaround for KV/KB - Root cause dongle fixes for display and revert workaround - Enable GPU reset for renoir and navi - Navi overclocking fixes - Fix up confusing warnings in display clock validation on raven amdkfd: - SDMA fix radeon: - Misc LUT fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206035458.3894-1-alexander.deucher@amd.com
-
git://github.com/skeggsb/linuxDave Airlie authored
Just a couple of fixes to Volta/Turing modesetting on some systems. Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Fixes for v5.6-rc1 These are a couple of quick fixes for regressions that were found during the first two weeks of the merge window. Signed-off-by:
-
- 06 Feb, 2020 3 commits
-
-
Thierry Reding authored
The DMA direction is only used by the DMA API, so there is no use in setting it when a buffer object isn't mapped with the DMA API. Signed-off-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
-
Thierry Reding authored
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10. The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain). Cc: <stable@vger.kernel.org> # v5.5 Reported-by:
-
Thierry Reding authored
Older Tegra devices only allow addressing 32 bits of memory, so whether or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU attachment is only needed on devices that can address memory beyond the 32-bit boundary and where the host1x doesn't support the wide GATHER opcode that allows it to access buffers at higher addresses. Cc: <stable@vger.kernel.org> # v5.5 Signed-off-by:
-
- 05 Feb, 2020 2 commits
-
-
Lyude Paul authored
Disabling a display on MST can potentially happen after the entire MST topology has been removed, which means that we can't communicate with the topology at all in this scenario. Likewise, this also means that we can't properly update payloads on the topology and as such, it's a good idea to ignore payload update failures when disabling displays. Currently, amdgpu makes the mistake of halting the payload update process when any payload update failures occur, resulting in leaving DC's local copies of the payload tables out of date. This ends up causing problems with hotplugging MST topologies, and causes modesets on the second hotplug to fail like so: [drm] Failed to updateMST allocation table forpipe idx:1 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1511 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked in: cdc_ether usbnet fuse xt_conntrack nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched mmc_core i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 mii nvme r8169 nvme_core rtsx_pci pinctrl_amd CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O 5.5.0-rc7Lyude-Test+ #4 Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS R12ET22W(0.22 ) 01/31/2019 RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 RSP: 0018:ffffac428127f5b0 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8d1e166eee80 RCX: 0000000000000000 RDX: ffffac428127f668 RSI: ffff8d1e166eee80 RDI: ffffac428127f610 RBP: ffffac428127f640 R08: ffffffffc03d94a8 R09: 0000000000000000 R10: ffff8d1e24b02000 R11: ffffac428127f5b0 R12: ffff8d1e1b83d000 R13: ffff8d1e1bea0b08 R14: 0000000000000002 R15: 0000000000000002 FS: 00007fab23ffcd80(0000) GS:ffff8d1e28b40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f151f1711e8 CR3: 00000005997c0000 CR4: 00000000003406e0 Call Trace: ? mutex_lock+0xe/0x30 dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] ? dm_read_reg_func+0x39/0xb0 [amdgpu] ? core_link_enable_stream+0x656/0x730 [amdgpu] core_link_enable_stream+0x656/0x730 [amdgpu] dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] ? dcn10_wait_for_mpcc_disconnect+0x3c/0x130 [amdgpu] dc_commit_state+0x292/0x770 [amdgpu] ? add_timer+0x101/0x1f0 ? ttm_bo_put+0x1a1/0x2f0 [ttm] amdgpu_dm_atomic_commit_tail+0xb59/0x1ff0 [amdgpu] ? amdgpu_move_blit.constprop.0+0xb8/0x1f0 [amdgpu] ? amdgpu_bo_move+0x16d/0x2b0 [amdgpu] ? ttm_bo_handle_move_mem+0x118/0x570 [ttm] ? ttm_bo_validate+0x134/0x150 [ttm] ? dm_plane_helper_prepare_fb+0x1b9/0x2a0 [amdgpu] ? _cond_resched+0x15/0x30 ? wait_for_completion_timeout+0x38/0x160 ? _cond_resched+0x15/0x30 ? wait_for_completion_interruptible+0x33/0x190 commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? _cond_resched+0x15/0x30 ? mutex_lock+0xe/0x30 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x458/0x6d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fab2121f87b Code: 0f 1e fa 48 8b 05 0d 96 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 95 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd045f9068 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd045f90a0 RCX: 00007fab2121f87b RDX: 00007ffd045f90a0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007ffd045f90a0 R08: 0000000000000000 R09: 000055dbd2985d10 R10: 000055dbd2196280 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055dbd2196280 ---[ end trace 6ea888c24d2059cd ]--- Note as well, I have only been able to reproduce this on setups with 2 MST displays. Changes since v1: * Don't return false when part 1 or part 2 of updating the payloads fails, we don't want to abort at any step of the process even if things fail Reviewed-by:
Mikita Lipski <Mikita.Lipski@amd.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
It needed to be updated as well so it will show the proper values if you reset to the defaults. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
- 04 Feb, 2020 12 commits
-
-
Alex Deucher authored
Cull out 0 clocks to avoid a warning in DC. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
-
Alex Deucher authored
Only send non-0 clocks to DC for validation. This mirrors what the windows driver does. Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
-
Alex Deucher authored
We might get different numbers of clocks from powerplay depending on what the OEM has populated. v2: add assert for at least one level Bug: https://gitlab.freedesktop.org/drm/amd/issues/963Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Alex Deucher authored
Ask the SMU for the default VDDC curve voltage values. This properly reports the VDDC values in the OD interface. v2: only update if the original values are 0 Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Matt Coffin authored
Previously, the syfs functionality for restoring the default powerplay table was sourcing it's information from the currently-staged powerplay table. This patch adds a step to cache the first overdrive table that we see on boot, so that it can be used later to "restore" the powerplay table v2: sqaush my original with Matt's fix Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Signed-off-by:
Matt Coffin <mcoffin13@gmail.com> Reviewed-by:
-
Alex Deucher authored
So users can see the range of valid values. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Alex Deucher authored
You can only adjust the max mclk, not the min. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020Reviewed-by:
-
Bhawanpreet Lakha authored
[Why] When we disable a connector we don't explicitly remove it from the module so the display is still cached(SW) in the hdcp_module. SST: no issues because we can only have 1 display per link MST: We have x displays per link, now if we disable 1 we don't remove it from the module so the module has x display cached(SW). If we try to enable HDCP, psp verification will fail because we are reporting x displays while the HW only has x-1 display enabled [How] Check the callback for when we disable stream and call remove display. Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Mikita Lipski authored
[why] Remove a backslash symbol accidentally left in increase bpp function when computing mst dsc configuration. Signed-off-by:
Zhan Liu <zhan.liu@amd.com> Signed-off-by:
-
Evan Quan authored
This workaround is needed only for Navi10 12 Gbps SKUs. V2: added SMU firmware version guard Signed-off-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
Yong Zhao authored
The sdma_queue_count increment should be done before execute_queues_cpsch(), which calls pm_calc_rlib_size() where sdma_queue_count is used to calculate whether over_subscription is triggered. With the previous code, when a SDMA queue is created, compute_queue_count in pm_calc_rlib_size() is one more than the actual compute queue number, because the queue_count has been incremented while sdma_queue_count has not. This patch fixes that. Signed-off-by:
Yong Zhao <Yong.Zhao@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] In current code we're essentially drawing the cursor on every pipe that contains it. This only works when the planes have the same scaling for src to dest rect, otherwise we'll get "double cursor" where one cursor is incorrectly filtered and offset from the real position. [How] Without dedicated cursor planes on DCN we require at least one pipe that matches the scaling of the current timing. This is an optimization and workaround for the most common case where the top-most plane is not scaled but the bottom-most plane is scaled. Whenever a pipe has a parent pipe in the blending tree whose recout fully contains the current pipe we can disable the pipe. This only applies when the pipe is actually visible of course. Signed-off-by:
-
- 03 Feb, 2020 3 commits
-
-
Ben Skeggs authored
The OR routing logic in NVKM does not expect to receive supervisor interrupts until the DD has provided consistent information on the ORs it's using and the EVO/NVD assembly state to match. The combination of changing window ownership + core channel update during display init triggered a situation where we'd disconnect an OR from the pad it was meant to still be driving on some systems. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
For various complicated reasons, we need to avoid sending a core update method during display init. Something, which we've been required to do on GV100 and up because we've been assigning windows to heads there and the HW is rather picky about when that's allowed. This moves window assignment into the modesetting path at a point where it's much safer to send our first update methods to NVDisplay. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
- 31 Jan, 2020 4 commits
-
-
Thierry Reding authored
Commit fd67e9c6 ("drm/tegra: Do not implement runtime PM") replaced the generic runtime PM usage by a host1x bus-specific implementation in order to work around some assumptions baked into runtime PM that are in conflict with the requirements in the Tegra DRM driver. Unfortunately the new runtime PM callbacks are not setup yet at the time when the SOR driver first needs to resume the device to register the SOR pad clock, and accesses to register will cause the system to hang. Note that this only happens on Tegra124 and Tegra210 because those are the only SoCs where the SOR pad clock is registered from the SOR driver. Later generations use a SOR pad clock provided by the BPMP. Fix this by moving the registration of the SOR pad clock after the host1x client has been registered. That's somewhat suboptimal because this could potentially, though it's very unlikely, cause the Tegra DRM to be probed if the SOR happens to be the last subdevice to register, only to be immediately removed again if the SOR pad output clock fails to register. That's just a minor annoyance, though, and doesn't justify implementing a workaround. Fixes: fd67e9c6 ("drm/tegra: Do not implement runtime PM") Signed-off-by:
-
Thierry Reding authored
If the driver fails to probe, make sure to disable runtime PM again. While at it, make the cleanup code in ->remove() symmetric. Signed-off-by: -
Thierry Reding authored
Make sure the SOR module is suspenden after we fail to register the SOR pad output clock. Signed-off-by: -
git://people.freedesktop.org/~thomash/linuxDave Airlie authored
A small fix for the long-standing ttm vm page protection hack. Sent as a separate PR as it touches mm, has all acks in place. Signed-off-by:
-
- 30 Jan, 2020 6 commits
-
-
Alex Deucher authored
Doesn't seem to be used, but add it just in case. Reviewed-by:
-
Nathan Chancellor authored
Clang warns: ../drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c:967:35: warning: implicit conversion from enumeration type 'enum amdgpu_ras_block' to different enumeration type 'enum ta_ras_block' [-Wenum-conversion] block_info.block_id = info->head.block; ~ ~~~~~~~~~~~^~~~~ 1 warning generated. Use the function added in commit 828cfa29 ("drm/amdgpu: Fix amdgpu ras to ta enums conversion") that handles this conversion explicitly. Fixes: 4c461d89 ("drm/amdgpu: add RAS support for the gfx block of Arcturus") Link: https://github.com/ClangBuiltLinux/linux/issues/849Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Daniel Vetter authored
This is an oversight from commit 42585395 Author: Peter Rosin <peda@axentia.se> Date: Thu Jul 13 18:25:36 2017 +0200 drm: radeon: remove dead code and pointless local lut storage v2: Also remove leftover local variable. Cc: Peter Rosin <peda@axentia.se> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Zhan Liu authored
[Why] Need to do atomic check first, then validate global state. If not, when connecting both MST and HDMI displays and set a bad mode via xrandr, system will hang. [How] Move drm_dp_mst_atomic_check() to the front of dc_validate_global_state(). Signed-off-by:
-
Daniel Vetter authored
Per at least one tester this is enough magic to recover the regression introduced for some people (but not all) in commit b8e2b019 Author: Peter Rosin <peda@axentia.se> Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette which for radeon had the side-effect of refactoring out a seemingly redudant writing of the color palette. 10ms in a fairly slow modeset path feels like an acceptable form of duct-tape, so maybe worth a shot and see what sticks. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=198123Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake on the struct field name link_integiry_check, fix this by renaming it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
