summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-02-06drm/omap: dsi: Fix crash in DSI debug dumpsTomi Valkeinen
Reading any of the DSI debugfs files results in a crash, as wrong pointer is passed to the dump functions, and the dump functions use a wrong pointer. This patch fixes DSI debug dumps. Fixes: f3ed97f9ae7d ("drm/omap: dsi: Simplify debugfs implementation") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111035120.20668-3-laurent.pinchart@ideasonboard.com
2019-02-06drm/i915/pmu: Fix enable count array size and bounds checkingTvrtko Ursulin
Enable count array is supposed to have one counter for each possible engine sampler. As such, array sizing and bounds checking is not correct and would blow up the asserts if more samplers were added. No ill-effect in the current code base but lets fix it for correctness. At the same time tidy the assert for readability and robustness. v2: * One check per assert. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190205130353.21105-1-tvrtko.ursulin@linux.intel.com
2019-02-06cfg80211: pmsr: fix abort lockingJohannes Berg
When we destroy the interface we already hold the wdev->mtx while calling cfg80211_pmsr_wdev_down(), which assumes this isn't true and flushes the worker that takes the lock, thus leading to a deadlock. Fix this by refactoring the worker and calling its code in cfg80211_pmsr_wdev_down() directly. We still need to flush the work later to make sure it's not still running and will crash, but it will not do anything. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-06cfg80211: pmsr: fix MAC address settingJohannes Berg
When we *don't* have a MAC address attribute, we shouldn't try to use this - this was intended to copy the local MAC address instead, so fix it. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-06mtd: rawnand: gpmi: fix MX28 bus master lockup problemMartin Kepplinger
Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft reset may cause bus master lock up") for MX28 too. It has the same problem. Observed problem: once per 100,000+ MX28 reboots NAND read failed on DMA timeout errors: [ 1.770823] UBI: attaching mtd3 to ubi0 [ 2.768088] gpmi_nand: DMA timeout, last DMA :1 [ 3.958087] gpmi_nand: BCH timeout, last DMA :1 [ 4.156033] gpmi_nand: Error in ECC-based read: -110 [ 4.161136] UBI warning: ubi_io_read: error -110 while reading 64 bytes from PEB 0:0, read only 0 bytes, retry [ 4.171283] step 1 error [ 4.173846] gpmi_nand: Chip: 0, Error -1 Without BCH soft reset we successfully executed 1,000,000 MX28 reboots. I have a quote from NXP regarding this problem, from July 18th 2016: "As the i.MX23 and i.MX28 are of the same generation, they share many characteristics. Unfortunately, also the erratas may be shared. In case of the documented erratas and the workarounds, you can also apply the workaround solution of one device on the other one. This have been reported, but I’m afraid that there are not an estimated date for updating the Errata documents. Please accept our apologies for any inconveniences this may cause." Fixes: 6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems") Cc: stable@vger.kernel.org Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Han Xu <han.xu@nxp.com> Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
2019-02-06drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSenVille Syrjälä
Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205141846.6053-1-ville.syrjala@linux.intel.com
2019-02-06ALSA: hda/ca0132 - Fix build error without CONFIG_PCITakashi Iwai
A call of pci_iounmap() call without CONFIG_PCI leads to a build error on some architectures. We tried to address this and add a check of IS_ENABLED(CONFIG_PCI), but this still doesn't seem enough for sh. Ideally we should fix it globally, it's really a corner case, so let's paper over it with a simpler ifdef. Fixes: 1e73359a24fa ("ALSA: hda/ca0132 - make pci_iounmap() call conditional") Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-05drm/amd/display: Disconnect mpcc when changing tgNicholas Kazlauskas
[Why] This fixes an mpc programming error for the following sequence of atomic commits when pipe split is enabled: Commit 1: CRTC0 (plane 4, plane 3) Pipe 0: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 1: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Pipe 2: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 3: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Commit 2: CRTC0 (plane 3), CRTC1 (plane 2) Pipe 0: old_plane_state = A1, new_plane_state = A2, new_tg = T0 Pipe 1: old_plane_state = B1, new_plane_state = B2, new_tg = T1 Pipe 2: old_plane_state = A1, new_plane_state = NULL, new_tg = NULL Pipe 3: old_plane_state = B1, new_plane_state = NULL, new_tg = NULL In the second commit the assertion for mpcc in use is hit because mpcc disconnect never occurs for pipe 1. This is because the stream changes for pipe 1 and the opp_list is empty. This sequence occurs when running the "igt@kms_plane_multiple@atomic-pipe-A-tiling-none" test with two displays connected. [How] Expand the reset condition to include: "old_pipe_ctx->stream_res.tg != new_pipe_ctx->stream_res.tg" ...but only when the plane state is non-NULL for both old and new. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Apply fake sink back to MST sequenceJerry (Fangzhi) Zuo
[Why] It fixes the failure to create stream for sink in the scenario when hotplug SST and MST in sequence, and disconnect MST. [How] Add the fake sink back after the majority of MST rework is done. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: add a debug flag to force odm combineDmytro Laktyushkin
Adding a bit vector to allow forcing odm on specific otgs Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: store timing sync info in dc_stream_statusSu Sung Chung
in program_timing_sync, after all the pipes are grouped, store timing sync info in dc_stream_status Signed-off-by: Su Sung Chung <Su.Chung@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Modify ABM 2.2 Max ReductionJosip Pavic
[Why] Reduced backlight for ABM 2.2 at levels 1 and 2 is desired for power savings. [How] Reduce the max reduction parameters for ABM 2.2 Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Josip Pavic <Josip.Pavic@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: pass vline_config parameter by reference.Yongqiang Sun
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: add gpio lock/unlockChiawen Huang
[Why] When querying HPD via GPIO flow, it will create a new gpio object then free in the end of query. There is a irql issue for HPD querying at ISR level. [How] Therefore, creating the HPD gpio object in dc_link and set it as unlcok in default. 1. reducing unnecessary malloc/free when HPD querying. 2. reducing init GPIO flow. 3. add lock/unlock to prevent multi gpio service running. Signed-off-by: Chiawen Huang <chiawen.huang@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: 3.2.16Steven Chiu
Signed-off-by: Steven Chiu <steven.chiu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: determine if a pipe is synced by plane stateWenjing Liu
[why] is_blanked is not a general indicator of if a pipe is synced for all asics. plane state is more accurate and applicable for all asics. [how] Remove is_blanked call and add checking plane_state against NULL instead. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: DGAM enabled for HDRKrunoslav Kovac
[Why] On HW that doesn't have input LUT, we may combine degamma with OS ramp Problem here is that it assumes DGAM is inverse of PQ or SRGB. It doesn't handle linear case, it would default to sRGB and always enable DGAM.. [How] Add handling for linear case. Also check for null ramp and instead of blowing up, assume it's identity. Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Check that vrefresh is in freesync rangeIlya Bakoulin
[Why] Setting monitor refresh rate below freesync range would cause the monitor to go blank indefinitely with freesync enabled [How] Set vrr_supported and ignore_msa_timing_param according to whether the refresh rate is above or below the minimum freesync frequency. Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: dmcu is blocking due to wrong disable ABM commandPaul Hsieh
[Why] Second screen to clone/extend mode, driver will send ABM pipe command to DMCU. Change mode from clone/extend to second screen only, driver send ABM level command to disable ABM but this command will not clear ABM pipe data. At this time, change second screen to PC screen only, driver will send first command "ABM_LEVEL", it will turn on ABM with incorrect ABM pile so that DMCU is blocking. [How] When driver try to disable ABM, change command from "ABM LEVEL" to "ABM PIPE" so that it will clear ABM pile data. Signed-off-by: Paul Hsieh <Paul.Hsieh@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: fix issue with DC brightness low with VBAnthony Koo
[Why] The problem is that we accidentally stopped loading some of the IRAM bytes used for the backlight ramping mechanism. This happened when we started reserving some region of IRAM as DMCU FW write only. [How] This change will define a start+end region for the IRAM read only region. So the parameters needed for the backlight operation will be loaded since it will be defined outside of the read only region. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Add monitor patch for backlight offXiaodong Yan
[Why] Different panel need different time from backlight disable to end of valid video data, if the time is too short, panel will flash when dpms off [How] Add monitor patch to control the time from backlight disable to end of valid video data, Signed-off-by: Xiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Remove FreeSync timing changed debug outputNicholas Kazlauskas
[Why] This provides little debug value and creates a lot of dmesg noise. [How] Remove it. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Initialize stream_update to zeroNicholas Kazlauskas
[Why] The stream_update struct is left unitialized but DC will access its fields. This usually results in global state validation occur during any atomic commit with state->allow_modeset = true. [How] Initialize the struct to zero for every stream we check. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Reformat dm_determine_update_type_for_commitNicholas Kazlauskas
[Why] The indenting for this function is a few levels too deep and can be simplified a fair bit. This patch is in preparation for functional changes that fix update type determination to occur less frequently and more accurately. [How] Place checks early and exit/continue when possible. This isn't a functional change. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use the right surface for flip and FreeSyncNicholas Kazlauskas
[Why] We were always passing the first surface on the stream status for flip updates when we should be using the surface associated with the plane. [How] Use the dc_plane_state from the plane that's being updated. FreeSync should also only keep track of updates from the primary plane, so the check needed to be updated. The acrtc->stream state doesn't need to be checked for NULL before updating FreeSync either since there needs to be a stream to be inside this function as a prerequisite. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Apply all surface updates onto surfacesNicholas Kazlauskas
[Why] Most surface updates weren't propagated onto the surface during dc_commit_updates_for_stream. This makes it more difficult for DC to determine the actual surface update type required. [How] Use copy_surface_update_to_plane to propagate the changes. The FreeSync surface timing information update for BTR has been moved out of amdgpu_dm.c into this function as well. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use udelay when waiting between aux retriesJohn Barberiz
[Why] "IRQ_HPD Pulse Length Test" DP compliance test fails. Test complains that certain DPCD registers are not read within 100 ms. [How] msleep is inaccurate for small values. Used udelay instead for accuracy. Signed-off-by: John Barberiz <John.Barberiz@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: cleanup VM dw estimation a bitChristian König
No functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: fix waiting for BO moves with CPU based PD/PT updatesChristian König
Otherwise we open up the possibility to use uninitialized memory. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use context parameters to enable FBCShirish S
[What] FBC fails to get enabled when switched between LINEAR(console/VT) and non-LINEAR(GUI) based rendering due to default value of tiling info stored in the current_state which is used for deciding whether or not to turn FBC on or off. [How] Use context structure's tiling information which is coherant with the screen updates. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Don't re-enable CRC when CONFIG_DEBUG_FS isn't definedNicholas Kazlauskas
[Why] When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source is NULL. This causes a compilation error since it's being called unconditionally. [How] Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't supported without this. Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Fixes: 43a6a02eb355 ("drm/amd/display: Re-enable CRC capture following modeset") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: add a workaround for GDS ordered append hangs with compute queuesMarek Olšák
I'm not increasing the DRM version because GDS isn't totally without bugs yet. v2: update emit_ib_size Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIESAndrey Grodzovsky
New chunk for dependency on start of job's execution instead on the end. This is used for GPU deadlock prevention when userspace uses mid-IB fences to wait for mid-IB work on other rings. v2: Fix typo in AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES v3: Bump KMS version v4: put old fence AFTER acquiring the scheduled fence. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Suggested-by: Christian Koenig <Christian.Koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/powerplay: update soc boot and max level on vega10Kenneth Feng
update soc boot and max level,then uclk isn't stuck at minimum. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109462 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variables in fill_plane_dcc_attributesNathan Chancellor
Clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2314:38: warning: suggest braces around initialization of subobject [-Wmissing-braces] struct dc_surface_dcc_cap output = {0}; ^ {} Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 7df7e505e82a ("drm/amd/display: Set requested plane state DCC params for GFX9") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variables in ↵Nathan Chancellor
amdgpu_dm_atomic_commit_tail Clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5089:60: warning: suggest braces around initialization of subobject [-Wmissing-braces] struct dc_surface_update dummy_updates[MAX_SURFACES] = { 0 }; ^ {} Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 02d6a6fcdf68 ("drm/amd/display: Simplify underscan and ABM commit") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/display: Use memset to initialize variable in ↵Nathan Chancellor
wait_for_training_aux_rd_interval Clang warns: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:50:57: warning: suggest braces around initialization of subobject [-Wmissing-braces] union training_aux_rd_interval training_rd_interval = {0}; ^ {} 1 warning generated. Previous efforts to fix this type of warning by adding or removing braces have been met with some pushback in favor of using memset [1][2]. Do that here, mirroring commit 05794eff1aa6 ("drm/amdgpu/gmc: fix compiler errors [-Werror,-Wmissing-braces] (V2)") in this tree. [1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/ [2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/ Fixes: 3cec41769d21 ("drm/amd/display: Fix use of uninitialized union") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amd/amdgpu: fix spelling mistake "matech" -> "match"Colin Ian King
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05mISDN: fix a race in dev_expire_timer()Eric Dumazet
Since mISDN_close() uses dev->pending to iterate over active timers, there is a chance that one timer got removed from the ->pending list in dev_expire_timer() but that the thread has not called yet wake_up_interruptible() So mISDN_close() could miss this and free dev before completion of at least one dev_expire_timer() syzbot was able to catch this race : BUG: KASAN: use-after-free in register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827 Write of size 8 at addr ffff88809fc18948 by task syz-executor1/24769 CPU: 1 PID: 24769 Comm: syz-executor1 Not tainted 5.0.0-rc5 #60 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:140 register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827 __lock_acquire+0x11f/0x4700 kernel/locking/lockdep.c:3224 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152 __wake_up_common_lock+0xc7/0x190 kernel/sched/wait.c:120 __wake_up+0xe/0x10 kernel/sched/wait.c:145 dev_expire_timer+0xe4/0x3b0 drivers/isdn/mISDN/timerdev.c:174 call_timer_fn+0x190/0x720 kernel/time/timer.c:1325 protocol 88fb is buggy, dev hsr_slave_0 protocol 88fb is buggy, dev hsr_slave_1 expire_timers kernel/time/timer.c:1362 [inline] __run_timers kernel/time/timer.c:1681 [inline] __run_timers kernel/time/timer.c:1649 [inline] run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694 __do_softirq+0x266/0x95a kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x180/0x1d0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 </IRQ> RIP: 0010:__sanitizer_cov_trace_pc+0x26/0x50 kernel/kcov.c:101 Code: 90 90 90 90 55 48 89 e5 48 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 98 12 92 7e 81 e2 00 01 1f 00 75 2b 8b 90 d8 12 00 00 <83> fa 02 75 20 48 8b 88 e0 12 00 00 8b 80 dc 12 00 00 48 8b 11 48 RSP: 0018:ffff8880589b7a60 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: ffff888087ce25c0 RBX: 0000000000000001 RCX: ffffffff818f8ca3 RDX: 0000000000000000 RSI: ffffffff818f8b48 RDI: 0000000000000001 RBP: ffff8880589b7a60 R08: ffff888087ce25c0 R09: ffffed1015d25bd0 R10: ffffed1015d25bcf R11: ffff8880ae92de7b R12: ffffea0001ae4680 R13: ffffea0001ae4688 R14: 0000000000000000 R15: ffffea0001b41648 PageIdle include/linux/page-flags.h:398 [inline] page_is_idle include/linux/page_idle.h:29 [inline] mark_page_accessed+0x618/0x1140 mm/swap.c:398 touch_buffer fs/buffer.c:59 [inline] __find_get_block+0x312/0xcc0 fs/buffer.c:1298 sb_find_get_block include/linux/buffer_head.h:338 [inline] recently_deleted fs/ext4/ialloc.c:682 [inline] find_inode_bit.isra.0+0x202/0x510 fs/ext4/ialloc.c:722 __ext4_new_inode+0x14ad/0x52c0 fs/ext4/ialloc.c:914 ext4_symlink+0x3f8/0xbe0 fs/ext4/namei.c:3096 vfs_symlink fs/namei.c:4126 [inline] vfs_symlink+0x378/0x5d0 fs/namei.c:4112 do_symlinkat+0x22b/0x290 fs/namei.c:4153 __do_sys_symlink fs/namei.c:4172 [inline] __se_sys_symlink fs/namei.c:4170 [inline] __x64_sys_symlink+0x59/0x80 fs/namei.c:4170 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457b67 Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 6d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 4d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fff045ce0f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000058 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 0000000000457b67 RDX: 00007fff045ce173 RSI: 00000000004bd63f RDI: 00007fff045ce160 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000075 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000001 R14: 000000000000029b R15: 0000000000000001 Allocated by task 24763: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_kmalloc mm/kasan/common.c:496 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504 kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609 kmalloc include/linux/slab.h:545 [inline] mISDN_open+0x9a/0x270 drivers/isdn/mISDN/timerdev.c:59 misc_open+0x398/0x4c0 drivers/char/misc.c:141 chrdev_open+0x247/0x6b0 fs/char_dev.c:417 do_dentry_open+0x47d/0x1130 fs/open.c:771 vfs_open+0xa0/0xd0 fs/open.c:880 do_last fs/namei.c:3418 [inline] path_openat+0x10d7/0x4690 fs/namei.c:3534 do_filp_open+0x1a1/0x280 fs/namei.c:3564 do_sys_open+0x3fe/0x5d0 fs/open.c:1063 __do_sys_openat fs/open.c:1090 [inline] __se_sys_openat fs/open.c:1084 [inline] __x64_sys_openat+0x9d/0x100 fs/open.c:1084 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 24762: save_stack+0x45/0xd0 mm/kasan/common.c:73 set_track mm/kasan/common.c:85 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458 kasan_slab_free+0xe/0x10 mm/kasan/common.c:466 __cache_free mm/slab.c:3487 [inline] kfree+0xcf/0x230 mm/slab.c:3806 mISDN_close+0x2a1/0x390 drivers/isdn/mISDN/timerdev.c:97 __fput+0x2df/0x8d0 fs/file_table.c:278 ____fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88809fc18900 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 72 bytes inside of 192-byte region [ffff88809fc18900, ffff88809fc189c0) The buggy address belongs to the page: page:ffffea00027f0600 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0xffff88809fc18000 flags: 0x1fffc0000000200(slab) raw: 01fffc0000000200 ffffea000269f648 ffffea00029f7408 ffff88812c3f0040 raw: ffff88809fc18000 ffff88809fc18000 000000010000000b 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809fc18800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809fc18880: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88809fc18900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88809fc18980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88809fc18a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Karsten Keil <isdn@linux-pingi.de> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05net: dsa: mv88e6xxx: Fix counting of ATU violationsAndrew Lunn
The ATU port vector contains a bit per port of the switch. The code wrongly used it as a port number, and incremented a port counter. This resulted in the wrong interfaces counter being incremented, and potentially going off the end of the array of ports. Fix this by using the source port ID for the violation, which really is a port number. Reported-by: Chris Healy <Chris.Healy@zii.aero> Tested-by: Chris Healy <Chris.Healy@zii.aero> Fixes: 65f60e4582bd ("net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-05thermal: cpu_cooling: Clarify error messageAmit Kucheria
Make it clear that it is a failure if the cpufreq driver was unable to register as a cooling device. Makes it easier to find in logs and grepping for words like fail, err, warn. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-02-05thermal: of-thermal: Print name of device node with errorAmit Kucheria
Make it easier to debug devicetree definition in case of errors. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2019-02-05drm/nouveau: Move PBN and VCPI allocation into nv50_head_atomLyude Paul
Atomic checks should never modify anything outside of the state that they're passed in. Unfortunately this appears to be exactly what we're doing in nv50_msto_atomic_check() where we update mstc->pbn every time the function is called. This hasn't caused any bugs yet, but it needs to be fixed in order to ensure that when committing an artificially duplicated state (like during system resume), that we reuse the PBN of that state to perform VCPI allocations and don't recalculate a different value from the drm connector's reported bpc. Also, move the VCPI slot allocations while we're at it as well. With this, removing a topology in suspend while using nouveau no longer causes the new atomic VCPI helpers to complain. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190202002023.29665-5-lyude@redhat.com
2019-02-05drm/atomic: Add drm_atomic_state->duplicatedLyude Paul
Since commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered connectors harder") We've been failing atomic checks if they try to enable new displays on unregistered connectors. This is fine except for the one situation that breaks atomic assumptions: suspend/resume. If a connector is unregistered before we attempt to restore the atomic state, something we end up failing the atomic check that happens when trying to restore the state during resume. Normally this would be OK: we try our best to make sure that the atomic state pre-suspend can be restored post-suspend, but failures at that point usually don't cause problems. That is of course, until we introduced the new atomic MST VCPI helpers: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active changed [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:123:DP-5] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling [CONNECTOR:123:DP-5] [drm:drm_atomic_get_private_obj_state [drm]] Added new private object 0000000025844636 state 000000009fd2899a to 000000003a13d7b8 WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper] Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci nvme_core xhci_hcd CPU: 6 PID: 1070 Comm: gnome-shell Tainted: G W O 5.0.0-rc2Lyude-Test+ #1 Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018 RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper] Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea RSP: 0018:ffff88841235f268 EFLAGS: 00010246 RAX: ffff88841bf12ab0 RBX: ffff88841bf12aa8 RCX: 1ffff110837e2557 RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffffed108246bde0 RBP: ffff88841bf12ab8 R08: ffffed1083db3c93 R09: ffffed1083db3c92 R10: ffffed1083db3c92 R11: ffff88841ed9e497 R12: ffff888419555d80 R13: ffff8883bc499100 R14: ffff88841bf12ab8 R15: 0000000000000000 FS: 00007f16fbd4cd00(0000) GS:ffff88841ed80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1687c9f000 CR3: 00000003ba3cc003 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper] ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper] ? __printk_safe_exit+0x10/0x10 ? save_stack+0x8c/0xb0 ? vprintk_func+0x96/0x1bf ? __printk_safe_exit+0x10/0x10 intel_atomic_check+0x234/0x4750 [i915] ? printk+0x9f/0xc5 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? _raw_spin_lock_irqsave+0xa4/0x140 ? drm_atomic_check_only+0xb1/0x28b0 [drm] ? drm_dbg+0x186/0x1b0 [drm] ? drm_dev_dbg+0x200/0x200 [drm] ? intel_link_compute_m_n+0xb0/0xb0 [i915] ? drm_mode_put_tile_group+0x20/0x20 [drm] ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915] ? drm_plane_check_pixel_format+0x14a/0x310 [drm] drm_atomic_check_only+0x13c4/0x28b0 [drm] ? drm_state_info+0x220/0x220 [drm] ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper] ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper] ? kasan_unpoison_shadow+0x35/0x40 drm_atomic_commit+0x3b/0x100 [drm] drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper] drm_mode_setcrtc+0x636/0x1660 [drm] ? vprintk_func+0x96/0x1bf ? drm_dev_dbg+0x200/0x200 [drm] ? drm_mode_getcrtc+0x790/0x790 [drm] ? printk+0x9f/0xc5 ? mutex_unlock+0x1d/0x40 ? drm_mode_addfb2+0x2e9/0x3a0 [drm] ? rcu_sync_dtor+0x2e0/0x2e0 ? drm_dbg+0x186/0x1b0 [drm] ? set_page_dirty+0x271/0x4d0 drm_ioctl_kernel+0x203/0x290 [drm] ? drm_mode_getcrtc+0x790/0x790 [drm] ? drm_setversion+0x7f0/0x7f0 [drm] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x34/0x70 drm_ioctl+0x445/0x950 [drm] ? drm_mode_getcrtc+0x790/0x790 [drm] ? drm_getunique+0x220/0x220 [drm] ? expand_files.part.10+0x920/0x920 do_vfs_ioctl+0x1a1/0x13d0 ? ioctl_preallocate+0x2b0/0x2b0 ? __fget_light+0x2d6/0x390 ? schedule+0xd7/0x2e0 ? fget_raw+0x10/0x10 ? apic_timer_interrupt+0xa/0x20 ? apic_timer_interrupt+0xa/0x20 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x6f/0xb0 do_syscall_64+0x136/0x440 ? syscall_return_slowpath+0x2d0/0x2d0 ? do_page_fault+0x89/0x330 ? __do_page_fault+0x9c0/0x9c0 ? prepare_exit_to_usermode+0x188/0x200 ? perf_trace_sys_enter+0x1090/0x1090 ? __x64_sys_sigaltstack+0x280/0x280 ? __put_user_4+0x1c/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f16ff89a09b Code: 0f 1e fa 48 8b 05 ed bd 0c 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 bd bd 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff001232b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fff001232f0 RCX: 00007f16ff89a09b RDX: 00007fff001232f0 RSI: 00000000c06864a2 RDI: 000000000000000b RBP: 00007fff001232f0 R08: 0000000000000000 R09: 000055a79d484460 R10: 000055a79d44e770 R11: 0000000000000246 R12: 00000000c06864a2 R13: 000000000000000b R14: 0000000000000000 R15: 000055a79d44e770 WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper] ---[ end trace d536c05c13c83be2 ]--- [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000f9e2b143] found in mst state 000000009fd2899a This appears to be happening because we destroy the VCPI allocations when disabling all connected displays while suspending, and those VCPI allocations don't get restored on resume due to failing to restore the atomic state. So, fix this by introducing the suspending option to drm_atomic_helper_duplicate_state() and use that to indicate in the atomic state that it's being used for suspending or resuming the system, and thus needs to be fixed up by the driver. We can then use the new state->duplicated hook to tell update_connector_routing() in drm_atomic_check_modeset() to allow for modesets on unregistered connectors, which allows us to restore atomic states that contain MST topologies that were removed after the state was duplicated and thus: mostly fixing suspend and resume. This just leaves some issues that were introduced with nouveau, that will be addressed next. Changes since v3: * Remove ->duplicated hunks that I left in the VCPI helpers by accident. These don't need to be here, that was the supposed to be the purpose of the last revision Changes since v2: * Remove the changes in this patch to the VCPI helpers, they aren't needed anymore Changes since v1: * Rename suspend_or_resume to duplicated Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202002023.29665-4-lyude@redhat.com
2019-02-05drm/amd/display: Attach VRR properties for eDP connectorsNicholas Kazlauskas
[Why] eDP was missing in the checks for supported VRR connectors. [How] Attach the properties for eDP connectors too. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202449 Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpuNathan Chancellor
Clang warns: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: warning: 'CONFIG_X86_64' is not defined, evaluates to 0 [-Wundef] ^ 1 warning generated. Fixes: d1c234e2cd10 ("drm/amdkfd: Allow building KFD on ARM64 (v2)") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/amdgpu: use spin_lock_irqsave to protect vm_manager.pasid_idrPhilip Yang
amdgpu_vm_get_task_info is called from interrupt handler and sched timeout workqueue, we should use irq version spin_lock to avoid deadlock. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-05drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()Lyude Paul
Since we now have an easy way of refcounting drm_dp_mst_port structs and safely accessing their contents, there isn't any good reason to keep validating ports here. It doesn't prevent us from performing modesets on branch devices that have been removed either, and we already disallow enabling new displays on unregistered connectors in update_connector_routing() in drm_atomic_check_modeset(). All it does is cause us to have to make weird special exceptions in our atomic modesetting code. So, get rid of it entirely. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202002023.29665-3-lyude@redhat.com
2019-02-05drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()Lyude Paul
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we never successfully allocated VCPI to it. This is contrary to what we do in drm_dp_mst_allocate_vcpi(), where we only call drm_dp_mst_get_port_malloc() on the passed port if we successfully allocated VCPI to it. As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and another successive modeset calls drm_dp_mst_deallocate_vcpi() we will end up dropping someone else's malloc reference to the port. Example: [ 962.309260] ================================================================== [ 962.309290] BUG: KASAN: use-after-free in drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309296] Read of size 4 at addr ffff888416c30004 by task kworker/0:1H/500 [ 962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: G W O 5.0.0-rc2Lyude-Test+ #1 [ 962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018 [ 962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915] [ 962.309434] Call Trace: [ 962.309452] dump_stack+0xad/0x150 [ 962.309462] ? dump_stack_print_info.cold.0+0x1b/0x1b [ 962.309472] ? kmsg_dump_rewind_nolock+0xd9/0xd9 [ 962.309504] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309515] print_address_description+0x6c/0x23c [ 962.309542] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309568] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309577] kasan_report.cold.3+0x1a/0x32 [ 962.309605] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309631] drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309658] ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper] [ 962.309687] drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper] [ 962.309745] drm_atomic_state_default_clear+0x6ee/0xcc0 [drm] [ 962.309864] intel_atomic_state_clear+0xe/0x80 [i915] [ 962.309928] __drm_atomic_state_free+0x35/0xd0 [drm] [ 962.310044] intel_atomic_cleanup_work+0x56/0x70 [i915] [ 962.310057] process_one_work+0x884/0x1400 [ 962.310067] ? drain_workqueue+0x5a0/0x5a0 [ 962.310075] ? __schedule+0x87f/0x1e80 [ 962.310086] ? __sched_text_start+0x8/0x8 [ 962.310095] ? run_rebalance_domains+0x400/0x400 [ 962.310110] ? deref_stack_reg+0xb4/0x120 [ 962.310117] ? __read_once_size_nocheck.constprop.7+0x10/0x10 [ 962.310124] ? worker_enter_idle+0x47f/0x6a0 [ 962.310134] ? schedule+0xd7/0x2e0 [ 962.310141] ? __schedule+0x1e80/0x1e80 [ 962.310148] ? _raw_spin_lock_irq+0x9f/0x130 [ 962.310155] ? _raw_write_unlock_irqrestore+0x110/0x110 [ 962.310164] worker_thread+0x196/0x11e0 [ 962.310175] ? set_load_weight+0x2e0/0x2e0 [ 962.310181] ? __switch_to_asm+0x34/0x70 [ 962.310187] ? __switch_to_asm+0x40/0x70 [ 962.310194] ? process_one_work+0x1400/0x1400 [ 962.310199] ? __switch_to_asm+0x40/0x70 [ 962.310205] ? __switch_to_asm+0x34/0x70 [ 962.310211] ? __switch_to_asm+0x34/0x70 [ 962.310216] ? __switch_to_asm+0x40/0x70 [ 962.310221] ? __switch_to_asm+0x34/0x70 [ 962.310226] ? __switch_to_asm+0x40/0x70 [ 962.310231] ? __switch_to_asm+0x34/0x70 [ 962.310236] ? __switch_to_asm+0x40/0x70 [ 962.310242] ? syscall_return_via_sysret+0xf/0x7f [ 962.310248] ? __switch_to_asm+0x34/0x70 [ 962.310253] ? __switch_to_asm+0x40/0x70 [ 962.310258] ? __switch_to_asm+0x34/0x70 [ 962.310263] ? __switch_to_asm+0x40/0x70 [ 962.310268] ? __switch_to_asm+0x34/0x70 [ 962.310273] ? __switch_to_asm+0x40/0x70 [ 962.310281] ? __schedule+0x87f/0x1e80 [ 962.310292] ? __sched_text_start+0x8/0x8 [ 962.310300] ? save_stack+0x8c/0xb0 [ 962.310308] ? __kasan_kmalloc.constprop.6+0xc6/0xd0 [ 962.310313] ? kthread+0x98/0x3a0 [ 962.310318] ? ret_from_fork+0x35/0x40 [ 962.310334] ? __wake_up_common+0x178/0x6f0 [ 962.310343] ? _raw_spin_lock_irqsave+0xa4/0x140 [ 962.310349] ? __lock_text_start+0x8/0x8 [ 962.310355] ? _raw_write_lock_irqsave+0x70/0x130 [ 962.310360] ? __lock_text_start+0x8/0x8 [ 962.310371] ? process_one_work+0x1400/0x1400 [ 962.310376] kthread+0x2e2/0x3a0 [ 962.310383] ? kthread_create_on_node+0xc0/0xc0 [ 962.310389] ret_from_fork+0x35/0x40 [ 962.310401] Allocated by task 1462: [ 962.310410] __kasan_kmalloc.constprop.6+0xc6/0xd0 [ 962.310437] drm_dp_add_port+0xd60/0x1960 [drm_kms_helper] [ 962.310464] drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper] [ 962.310491] drm_dp_check_and_send_link_address+0x197/0x1f0 [drm_kms_helper] [ 962.310515] drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper] [ 962.310522] process_one_work+0x884/0x1400 [ 962.310529] worker_thread+0x196/0x11e0 [ 962.310533] kthread+0x2e2/0x3a0 [ 962.310538] ret_from_fork+0x35/0x40 [ 962.310543] Freed by task 500: [ 962.310550] __kasan_slab_free+0x133/0x180 [ 962.310555] kfree+0x92/0x1a0 [ 962.310581] drm_dp_mst_put_port_malloc+0x14d/0x180 [drm_kms_helper] [ 962.310693] intel_connector_destroy+0xb2/0xe0 [i915] [ 962.310747] drm_mode_object_put.part.0+0x12b/0x1a0 [drm] [ 962.310802] drm_atomic_state_default_clear+0x1f2/0xcc0 [drm] [ 962.310916] intel_atomic_state_clear+0xe/0x80 [i915] [ 962.310972] __drm_atomic_state_free+0x35/0xd0 [drm] [ 962.311083] intel_atomic_cleanup_work+0x56/0x70 [i915] [ 962.311092] process_one_work+0x884/0x1400 [ 962.311098] worker_thread+0x196/0x11e0 [ 962.311103] kthread+0x2e2/0x3a0 [ 962.311108] ret_from_fork+0x35/0x40 [ 962.311116] The buggy address belongs to the object at ffff888416c30000 which belongs to the cache kmalloc-2k of size 2048 [ 962.311122] The buggy address is located 4 bytes inside of 2048-byte region [ffff888416c30000, ffff888416c30800) [ 962.311124] The buggy address belongs to the page: [ 962.311132] page:ffffea00105b0c00 count:1 mapcount:0 mapping:ffff88841d003040 index:0x0 compound_mapcount: 0 [ 962.311142] flags: 0x8000000000010200(slab|head) [ 962.311152] raw: 8000000000010200 dead000000000100 dead000000000200 ffff88841d003040 [ 962.311159] raw: 0000000000000000 00000000000f000f 00000001ffffffff 0000000000000000 [ 962.311162] page dumped because: kasan: bad access detected So, bail early if drm_dp_mst_deallocate_vcpi() is called on a port with no VCPI allocation. Additionally, clean up the surrounding kerneldoc while we're at it since the port is assumed to be kept around because the DRM driver is expected to hold a malloc reference to it, not just us. Changes since v1: * Doc changes - danvet Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190202002023.29665-2-lyude@redhat.com
2019-02-06mtd: Make sure mtd->erasesize is valid even if the partition is of size 0Boris Brezillon
Commit 33f45c44d68b ("mtd: Do not allow MTD devices with inconsistent erase properties") introduced a check to make sure ->erasesize and ->_erase values are consistent with the MTD_NO_ERASE flag. This patch did not take the 0 bytes partition case into account which can happen when the defined partition is outside the flash device memory range. Fix that by setting the partition erasesize to the parent erasesize. Fixes: 33f45c44d68b ("mtd: Do not allow MTD devices with inconsistent erase properties") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: <stable@vger.kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
generated by cgit (git 2.34.1) at 2025-09-15 07:58:38 +0000