| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
drivers/gpu/drm/bridge/lontium-lt8912b.c
drivers/usb/dwc3/drd.c
|
|
This reverts commit ef4a40953c8076626875ff91c41e210fcee7a6fd.
The commit was applied to make further commits apply cleanly, but the
commit depends on other commits in the same patchset. I.e. the
controlling DSI host would need a change too. Thus one would need to
backport the full patchset changing the DSI hosts and all downstream
DSI device drivers.
Revert the commit and fix up the conflicts with the backported fixes
to the lt8912b driver.
Upstream-Status: Submitted [https://lore.kernel.org/stable/20240228145945.2499754-1-max.oss.09@gmail.com/]
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
drivers/gpu/drm/bridge/lontium-lt8912b.c
|
|
The lcdifv3 video controller has a clock dependency on the HDMI PHY for
the imx8mp. Powering down the HDMI PHY before the drm display pipeline
finishes after a hot-plug monitor disconnection event causes a vblank
timeout error due to the lcdif clock stopping. Likely because of this,
the downstream code doesn't power down the HDMI PHY (it was commented),
leaving the PHY ON even on a disconnection event, resulting in the HDMI
data and clock signals still running. This appears to cause issues when
using HDMI with bridge devices (e.g. HDMI-->eDP) to handle HPD (Hot-Plug Detect)
events from the bridge.
To address the problem, the workaround moves the PHY power-off logic to
the suspend of the lcdifv3 driver. At this position, it guarantees that
the DRM pipeline has finished and disabled and the PHY can be powered off
without problems. Doing this appears to be safe as the PHY is powered on
again on imx8mp_hdmi_phy_init() before starting the DRM pipeline. The PHY
is controlled by the HDMI TX BLK CTRL peripheral, but the downstream driver
for the peripheral is not fully implemented. So, the workaround maps
HDMI TX BLK CTRL register space to the lcdifv3 driver and controls it
directly, similar to the approach used in the imx HDMI driver.
Upstream-Status: Inappropriate [other]
The imx8mp already has a fully working implementation on upstream [1] and
[2]. Nonetheless, attempting to backport it appears impractical, leading
to the adoption of this workaround.
[1] https://lore.kernel.org/lkml/20240210204606.11944-1-aford173@gmail.com/
[2] https://lore.kernel.org/lkml/20240203165307.7806-1-aford173@gmail.com/
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
|
|
This is the 5.15.148 stable release
Conflicts:
drivers/usb/phy/phy-mxs-usb.c
|
|
This is the 5.15.147 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.146 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.145 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.144 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.143 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
arch/arm64/boot/dts/freescale/imx8mq.dtsi
|
|
This is the 5.15.141 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.140 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
drivers/i3c/master/svc-i3c-master.c
|
|
This is the 5.15.139 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
drivers/clk/imx/clk-imx8mq.c
|
|
Revert the following commits in stable before merging, the sources have
been heavely modified by NXP.
d4c8bf5635c4b rpmsg: Fix possible refcount leak in rpmsg_register_device_override()
a82e0fda8a2f8 rpmsg: glink: Release driver_override
bfd4a664ddfbe rpmsg: Fix calling device_lock() on non-initialized device
2e76b4f6218c4 rpmsg: Fix kfree() of static memory on setting driver_override
5c0da71871d3a rpmsg: Constify local variable in field store macro
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Conflicts:
drivers/misc/pci_endpoint_test.c
|
|
This is the 5.15.137 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.136 stable release
Conflicts:
Documentation/security/keys/trusted-encrypted.rst
security/keys/trusted-keys/trusted_core.c
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.135 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.134 stable release
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.133 stable release
Conflicts:
drivers/perf/fsl_imx8_ddr_perf.c
Used the stable fix
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Revert the following commits before merging, the sources have been
heavely modified by NXP.
5a86ca588b3f9 Revert "perf/imx_ddr: don't enable counter0 if none of 4 counters are used"
56ad67babb7fb Revert "usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()"
50b3a42d82f07 Revert "USB: core: Unite old scheme and new scheme descriptor reads"
cdcf46014f5ca Revert "USB: core: Change usb_get_device_descriptor() API"
2f2af6028f201 Revert "USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()"
9e168d3268f89 Revert "USB: core: Fix oversight in SuperSpeed initialization"
7e95107f9b664 Revert "PCI: dwc: Add start_link/stop_link inlines"
d0bec10a7f796 Revert "PCI: layerscape: Add the endpoint linkup notifier support"
aaf9dc6089bc3 Revert "PCI: layerscape: Add workaround for lost link capabilities during reset"
Conflicts:
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/boot/dts/imx6sx.dtsi
Keep stable node name changes
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
Keep stable code change
drivers/media/i2c/ov5640.c
Keep stable code change
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Merge tag lf-5.15.71-2.2.2 with reverted upstream (sound/) commits
339ba37942c9d 6f668d2cbd2e2 d62dd3e291e06 416f4b7624040 1c23070f17c59
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Return EPROBE_DEFER in the probe function if the LDB bridge is missing
some of its child bridges. The current implementation returns
EPROBE_DEFER in the bind function, which is incorrect because the kernel
assumes the driver is fully functional when bind is called.
When both HDMI and LVDS is configured the above actually happens in
about 20% of the boots, resulting in a kernel backtrace and neither of
the two graphical outputs being functional.
drm_mode_config_cleanup tries to cleanup a not instantiated device,
if one fixes that the next hickup occurs...
This commit assures to not take this code path.
[ 7.130956] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 7.142436] Modules linked in: crct10dif_ce snd_soc_imx_spdif snd_soc_imx_hdmi mwifiex panel_lvds cfg80211 rfkill ahci_imx atmel_
mxt_ts flexcan can_dev mxc_jpeg_encdec snd_soc_fsl_audmix v4l2_jpeg imx8_media_dev(C) snd_soc_fsl_spdif snd_soc_fsl_asrc snd_soc_fsl
_sai cdns_mhdp_imx(+) cdns_mhdp_drmcore caam error galcore fuse
[ 7.171161] CPU: 1 PID: 277 Comm: systemd-udevd Tainted: G C 5.15.129-6.5.0-06970-gdc84adb6e1b2-dirty #31
[ 7.182073] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.189932] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.196905] pc : drm_mode_config_cleanup+0x54/0x300
[ 7.201815] lr : drm_mode_config_init_release+0x10/0x20
[ 7.207079] sp : ffff800009ffb710
[ 7.210411] x29: ffff800009ffb770 x28: ffff000003210550 x27: ffff00001af06a00
[ 7.217582] x26: ffff80000812cdd0 x25: dead000000000122 x24: dead000000000100
[ 7.224748] x23: ffff8000094b7250 x22: ffff00001a9c7810 x21: ffff00001a9c7800
[ 7.231907] x20: ffff00001a9c7aa8 x19: fffffffffffffff8 x18: 0000000000000000
[ 7.239065] x17: ffff8000763e6000 x16: ffff800009c18000 x15: 0000000000000000
[ 7.246222] x14: 0000000000000000 x13: 0000000000000010 x12: 0000000000000001
[ 7.253373] x11: 0000000000000001 x10: 00000000000009e0 x9 : ffff800009bda000
[ 7.260531] x8 : ffff00001ae41c80 x7 : ffff00001a9a9e00 x6 : 0000000000000000
[ 7.267690] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 7.274839] x2 : ffff8000087b58e0 x1 : 0000000000000000 x0 : ffff00001b13a120
[ 7.282000] Call trace:
[ 7.284456] drm_mode_config_cleanup+0x54/0x300
[ 7.289008] drm_mode_config_init_release+0x10/0x20
[ 7.293900] drm_managed_release+0xa4/0x13c
[ 7.298097] drm_dev_put.part.0+0x90/0xc0
[ 7.302127] drm_dev_put+0x14/0x2c
[ 7.305541] imx_drm_bind+0xbc/0x200
[ 7.309129] try_to_bring_up_master+0x214/0x2e0
[ 7.313714] __component_add+0xa0/0x18c
...
Upstream-Status: Inappropriate [Other]
The upstream imx8qm-ldb driver is a complete rewrite, the bind() calls
are not present as part of the driver.
Upstream: drivers/gpu/drm/bridge/imx/{imx8qm-ldb-drv.c|imx8qm-ldb.c}
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
When the FW is already loaded and running on the uCPU access to
IRAM/DRAM from the Cortex A core is no longer granted.
Trying to load the FW to IRAM/DRAM results in a asynchronous abort.
Fix this by loading the FW only if the uCPU is still in reset.
If the reset is deasserted assume that the FW is already loaded
and do nothing.
Note that asserting the reset and enabling access to IRAM/DRAM by
writing '7' to APB_CTRL seems to be not enough to allow (re) writing
the FW.
The error was triggered by enabling both LVDS and HDMI. This resulted
in cdns_mhdp_imx_probe being called twice, returning EPROBE_DEFER
on the first invocation and then on the second invocation the FW is
already loaded and the uCPU started.
[ 7.407427] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError
[ 7.407443] CPU: 0 PID: 200 Comm: kworker/u10:4 Tainted: G C O 5.15.129-6.4.0-devel+git.3311382cb124 #1
[ 7.407452] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.407458] Workqueue: events_unbound deferred_probe_work_func
[ 7.407478] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.407486] pc : mutex_unlock+0x44/0x70
[ 7.407498] lr : cdns_mhdp_bus_write+0xa4/0x100 [cdns_mhdp_drmcore]
[ 7.407536] sp : ffff80000b19b910
[ 7.407539] x29: ffff80000b19b910 x28: ffff00000324e550 x27: ffff00001b2df700
[ 7.407549] x26: 0000000000000000 x25: ffff80000109f1c0 x24: ffff000003a2a120
[ 7.407558] x23: ffff000003a28080 x22: 0000000022222211 x21: ffff000003a28d88
[ 7.407567] x20: 0000000000000004 x19: ffff000003a28080 x18: 0000000000000001
[ 7.407576] x17: 3038363236353a32 x16: 3a64706e65673a64 x15: 00007de44ad2f95c
[ 7.407584] x14: 0000000000000008 x13: 0000000000000008 x12: 0000000000000000
[ 7.407593] x11: 0000000000000001 x10: 00000000000009e0 x9 : ffff80000b19b810
[ 7.407601] x8 : ffff000002801880 x7 : ffff00007fb0a440 x6 : 0000000000000000
[ 7.407610] x5 : 0000000000220000 x4 : 0000000000000000 x3 : ffff000003a28d88
[ 7.407618] x2 : 0000000000000000 x1 : ffff000002800e40 x0 : ffff000002800e40
[ 7.407629] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 7.407634] CPU: 0 PID: 200 Comm: kworker/u10:4 Tainted: G C O 5.15.129-6.4.0-devel+git.3311382cb124 #1
[ 7.407641] Hardware name: Toradex Apalis iMX8QP V1.1 on Apalis Evaluation Board (DT)
[ 7.407644] Workqueue: events_unbound deferred_probe_work_func
[ 7.407652] Call trace:
[ 7.407654] dump_backtrace+0x0/0x1e0
[ 7.407667] show_stack+0x18/0x40
[ 7.407674] dump_stack_lvl+0x68/0x84
[ 7.407683] dump_stack+0x18/0x34
[ 7.407690] panic+0x188/0x348
[ 7.407696] add_taint+0x0/0xc0
[ 7.407706] arm64_serror_panic+0x6c/0x7c
[ 7.407711] do_serror+0x58/0x5c
[ 7.407716] el1h_64_error_handler+0x30/0x50
[ 7.407722] el1h_64_error+0x78/0x7c
[ 7.407728] mutex_unlock+0x44/0x70
[ 7.407734] cdns_mhdp_firmware_write_section+0x74/0xa0 [cdns_mhdp_imx]
[ 7.407749] cdns_mhdp_firmware_init_imx8qm+0xac/0x1c0 [cdns_mhdp_imx]
[ 7.407759] __cdns_hdmi_probe+0x174/0x37c [cdns_mhdp_drmcore]
[ 7.407786] cdns_hdmi_bind+0x28/0x90 [cdns_mhdp_drmcore]
[ 7.407810] cdns_mhdp_imx_bind+0xe4/0x170 [cdns_mhdp_imx]
[ 7.407821] component_bind_all+0x124/0x284
[ 7.407829] imx_drm_bind+0x15c/0x20c
[ 7.407837] try_to_bring_up_master+0x228/0x314
[ 7.407843] __component_add+0xa0/0x18c
[ 7.407849] component_add+0x14/0x20
[ 7.407855] cdns_mhdp_imx_probe+0x1c/0x30 [cdns_mhdp_imx]
[ 7.407865] platform_probe+0x68/0xe0
[ 7.407872] really_probe+0xbc/0x46c
[ 7.407877] __driver_probe_device+0x104/0x160
[ 7.407883] driver_probe_device+0x40/0x120
[ 7.407888] __device_attach_driver+0xbc/0x160
[ 7.407894] bus_for_each_drv+0x78/0xd0
[ 7.407903] __device_attach+0xa8/0x1e4
[ 7.407909] device_initial_probe+0x14/0x20
[ 7.407914] bus_probe_device+0x98/0xa0
[ 7.407920] deferred_probe_work_func+0x94/0xe4
[ 7.407925] process_one_work+0x1d0/0x374
[ 7.407932] worker_thread+0x13c/0x490
[ 7.407937] kthread+0x150/0x160
[ 7.407945] ret_from_fork+0x10/0x20
[ 7.407954] SMP: stopping secondary CPUs
[ 7.411611] Kernel Offset: disabled
[ 7.411613] CPU features: 0x4,000820b1,20000846
[ 7.411618] Memory Limit: none
Upstream-Status: Inappropriate [other]
Upstream does not have a driver for the cadence HDMI IP.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Several cadence API functions are missing mutex protection. Adding the
missing mutex calls in cadence API functions to prevent unstable display
behavior.
Signed-off-by: Oliver F. Brown <oliver.brown@oss.nxp.com>
Upstream-Status: Inappropriate [other]
Upstream does not have a driver for the cadence HDMI IP.
Cherry picked from NXP downstream commit ce02e24ef317a3bb24b056cbb650e0e314663ffc.
Neither the missing mutex calls nor the double mutex unlock in an
error path were showing negative effects in our known use cases.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Return EPROBE_DEFER in the probe function if the LDB bridge is missing
some of its child bridges. The current implementation returns
EPROBE_DEFER in the bind function, which is incorrect because the kernel
assumes the driver is fully functional when bind is called. This results
in a deferal loop if native HDMI and the ldb bridge are enabled that
looks as follows:
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)
imx-drm display-subsystem: bound imx-lcdifv3-crtc.1 (ops lcdifv3_crtc_ops)
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
...
Upstream-Status: Inappropriate [Other]
The upstream imx8mp-ldb driver is a complete rewrite of the downstream
one and is most likely not affected because there is no bind:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/bridge/fsl-ldb.c
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
|
|
[ Upstream commit 2f3be3ca779b11c332441b10e00443a2510f4d7b ]
The hwmgr->backend, (i.e. data) allocated by kzalloc is not freed in
the error-handling paths of smu7_get_evv_voltages and
smu7_update_edc_leakage_table. However, it did be freed in the
error-handling of phm_initializa_dynamic_state_adjustment_rule_settings,
by smu7_hwmgr_backend_fini. So the lack of free in smu7_get_evv_voltages
and smu7_update_edc_leakage_table is considered a memleak in this patch.
Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.")
Fixes: 8f0804c6b7d0 ("drm/amd/pm: add edc leakage controller setting")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c2709b2d6a537ca0fa0f1da36fdaf07e48ef447d ]
When radeon_bo_create and radeon_vm_clear_bo fail, the vm->page_tables
allocated before need to be freed. However, neither radeon_vm_init
itself nor its caller have done such deallocation.
Fixes: 6d2f2944e95e ("drm/radeon: use normal BOs for the page tables v4")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 28dd788382c43b330480f57cd34cde0840896743 ]
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev->pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
|-> kv_dpm_init
|-> kv_dpm_sw_init
|-> kv_dpm_fini
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.
Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ac16667237a82e2597e329eb9bc520d1cf9dff30 ]
When the allocation of
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
amdgpu_free_extended_power_table is called to free some fields of adev.
However, when the control flow returns to si_dpm_sw_init, it goes to
label dpm_failed and calls si_dpm_fini, which calls
amdgpu_free_extended_power_table again and free those fields again. Thus
a double-free is triggered.
Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit afe58346d5d3887b3e49ff623d2f2e471f232a8d ]
Should be -EOPNOTSUPP.
Fixes: 5104fdf50d32 ("drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 32bd29b619638256c5b75fb021d6d9f12fc4a984 ]
If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains
0, instead of an error value.
Return -EINVAL instead.
Fixes: f25ee5017e4f ("drm/bridge: tc358767: add IRQ and HPD support")
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-4-c22b2444f5f5@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 155d6fb61270dd297f128731cd155080deee8f3a ]
'ret' could be uninitialized at the end of the function, although it's
not clear if that can happen in practice.
Fixes: 6a3608eae6d3 ("drm: bridge: cdns-mhdp8546: Enable HDCP")
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-3-c22b2444f5f5@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 28c28d7f77c06ac2c0b8f9c82bc04eba22912b3b ]
The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
following error-handling path. However, in the error-handling of
rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
resulting in a memleak in this function.
Fixes: d70229f70447 ("drm/radeon/kms: add dpm support for trinity asics")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0737df9ed0997f5b8addd6e2b9699a8c6edba2e4 ]
The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
following error-handling path. However, in the error-handling of
rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
resulting in a memleak in this function.
Fixes: 80ea2c129c76 ("drm/radeon/kms: add dpm support for sumo asics (v2)")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7a2464fac80d42f6f8819fed97a553e9c2f43310 ]
check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref.
Fixes: fa7f517cb26e ("drm/radeon: rework page flip handling v4")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5f8dec200923a76dc57187965fd59c1136f5d085 ]
In case the drm_modeset_register_all() function fails, its error code
will be ignored. Instead make the drm_dev_register() bail out in case of
such an error.
Fixes: 79190ea2658a ("drm: Add callbacks for late registering")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231202225552.1283638-1-dmitry.baryshkov@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3d07a411b4faaf2b498760ccf12888f8de529de0 ]
This helper has been introduced to avoid programmer errors (missing
_put calls leading to dangling refcnt) when using pm_runtime_get, use it.
While at it, start checking the return value.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 5c8290284402 ("drm/msm/dsi: Split PHY drivers to separate files")
Patchwork: https://patchwork.freedesktop.org/patch/543350/
Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-1-a11a751f34f0@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c6721b3c6423d8a348ae885a0f4c85e14f9bf85c ]
Flush queued events when disabling the crtc. This avoids timeouts when
we come back and wait for dependencies (like the previous frame's
flip_done).
Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/569127/
Link: https://lore.kernel.org/r/20231127215401.4064128-1-dmitry.baryshkov@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 71225e1c930942cb1e042fc08c5cc0c4ef30e95e ]
In the unlikely event of radeon_ring_lock() failing, its errno return
value should be processed. This patch checks said return value and
prints a debug message in case of an error.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 48c0c902e2e6 ("drm/radeon/kms: add support for CP setup on SI")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b5c5baa458faa5430c445acd9a17481274d77ccf ]
It may be possible, albeit unlikely, to encounter integer overflow
during the multiplication of several unsigned int variables, the
result being assigned to a variable 'size' of wider type.
Prevent this potential behaviour by converting one of the multiples
to unsigned long.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 0242f74d29df ("drm/radeon: clean up CS functions in r100.c")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 39c960bbf9d9ea862398759e75736cfb68c3446f ]
While improbable, there may be a chance of hitting integer
overflow when the result of radeon_get_ib_value() gets shifted
left.
Avoid it by casting one of the operands to larger data type (u64).
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 1729dd33d20b ("drm/radeon/kms: r600 CS parser fixes")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 38360bf96d816e175bc602c4ee76953cd303b71d ]
The driver only frees the reserved irq if priv->irq_enabled is set to
true. However, the driver mistakenly sets priv->irq_enabled to false,
instead of true, in tilcdc_irq_install(), and thus the driver never
frees the irq, causing issues on loading the driver a second time.
Fixes: b6366814fa77 ("drm/tilcdc: Convert to Linux IRQ interfaces")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919-lcdc-v1-1-ba60da7421e1@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ce3e112e7ae854249d8755906acc5f27e1542114 ]
With tpd12s015_remove() marked with __exit this function is discarded
when the driver is compiled as a built-in. The result is that when the
driver unbinds there is no cleanup done which results in resource
leakage or worse.
Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20231102165640.3307820-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5f35a624c1e30b5bae5023b3c256e94e0ad4f806 ]
Fix a sparse warning with this message
"warning:dereference of noderef expression". In this context it means we
are dereferencing a __rcu tagged pointer directly.
We should not be directly dereferencing a rcu pointer. To get a normal
(non __rcu tagged pointer) from a __rcu tagged pointer we are using the
function unrcu_pointer(...). The non __rcu tagged pointer then can be
dereferenced just like a normal pointer.
I tested with qemu with this command
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=bullseye.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid \
2>&1 | tee vm.log
with lockdep enabled.
Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231113191303.3277733-1-singhabhinav9051571833@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 03c5b2a5f6c39fe4e090346536cf1c14ee18b61e ]
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends and wakes up, there
are some slight artifacts on the screen that go away over time. If
instead we hold the panel in reset status after it is unprepared,
this does not happen.
Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133 panels")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Link: https://lore.kernel.org/r/20231117194405.1386265-3-macroalpha82@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231117194405.1386265-3-macroalpha82@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451 ]
This reverts commit 250aa22920cd5d956a5d3e9c6a43d671c2bae217.
The DMA-fence annotations cause a lockdep warning (see below). As per
https://patchwork.freedesktop.org/patch/462170/ it sounds like the
annotations don't work correctly.
======================================================
WARNING: possible circular locking dependency detected
6.5.0-rc2+ #2 Not tainted
------------------------------------------------------
kmstest/219 is trying to acquire lock:
c4705838 (&hdmi->lock){+.+.}-{3:3}, at: hdmi5_bridge_mode_set+0x1c/0x50
but task is already holding lock:
c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (dma_fence_map){++++}-{0:0}:
__dma_fence_might_wait+0x48/0xb4
dma_resv_lockdep+0x1b8/0x2bc
do_one_initcall+0x68/0x3b0
kernel_init_freeable+0x260/0x34c
kernel_init+0x14/0x140
ret_from_fork+0x14/0x28
-> #1 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire+0x70/0xa8
__kmem_cache_alloc_node+0x3c/0x368
kmalloc_trace+0x28/0x58
_drm_do_get_edid+0x7c/0x35c
hdmi5_bridge_get_edid+0xc8/0x1ac
drm_bridge_connector_get_modes+0x64/0xc0
drm_helper_probe_single_connector_modes+0x170/0x528
drm_client_modeset_probe+0x208/0x1334
__drm_fb_helper_initial_config_and_unlock+0x30/0x548
omap_fbdev_client_hotplug+0x3c/0x6c
drm_client_register+0x58/0x94
pdev_probe+0x544/0x6b0
platform_probe+0x58/0xbc
really_probe+0xd8/0x3fc
__driver_probe_device+0x94/0x1f4
driver_probe_device+0x2c/0xc4
__device_attach_driver+0xa4/0x11c
bus_for_each_drv+0x84/0xdc
__device_attach+0xac/0x20c
bus_probe_device+0x8c/0x90
device_add+0x588/0x7e0
platform_device_add+0x110/0x24c
platform_device_register_full+0x108/0x15c
dss_bind+0x90/0xc0
try_to_bring_up_aggregate_device+0x1e0/0x2c8
__component_add+0xa4/0x174
hdmi5_probe+0x1c8/0x270
platform_probe+0x58/0xbc
really_probe+0xd8/0x3fc
__driver_probe_device+0x94/0x1f4
driver_probe_device+0x2c/0xc4
__device_attach_driver+0xa4/0x11c
bus_for_each_drv+0x84/0xdc
__device_attach+0xac/0x20c
bus_probe_device+0x8c/0x90
deferred_probe_work_func+0x8c/0xd8
process_one_work+0x2ac/0x6e4
worker_thread+0x30/0x4ec
kthread+0x100/0x124
ret_from_fork+0x14/0x28
-> #0 (&hdmi->lock){+.+.}-{3:3}:
__lock_acquire+0x145c/0x29cc
lock_acquire.part.0+0xb4/0x258
__mutex_lock+0x90/0x950
mutex_lock_nested+0x1c/0x24
hdmi5_bridge_mode_set+0x1c/0x50
drm_bridge_chain_mode_set+0x48/0x5c
crtc_set_mode+0x188/0x1d0
omap_atomic_commit_tail+0x2c/0xbc
commit_tail+0x9c/0x188
drm_atomic_helper_commit+0x158/0x18c
drm_atomic_commit+0xa4/0xe8
drm_mode_atomic_ioctl+0x9a4/0xc38
drm_ioctl+0x210/0x4a8
sys_ioctl+0x138/0xf00
ret_fast_syscall+0x0/0x1c
other info that might help us debug this:
Chain exists of:
&hdmi->lock --> fs_reclaim --> dma_fence_map
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(dma_fence_map);
lock(fs_reclaim);
lock(dma_fence_map);
lock(&hdmi->lock);
*** DEADLOCK ***
3 locks held by kmstest/219:
#0: f1011de4 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_atomic_ioctl+0xf0/0xc38
#1: c47059c8 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xf8/0x230
#2: c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc
stack backtrace:
CPU: 1 PID: 219 Comm: kmstest Not tainted 6.5.0-rc2+ #2
Hardware name: Generic DRA74X (Flattened Device Tree)
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x58/0x70
dump_stack_lvl from check_noncircular+0x164/0x198
check_noncircular from __lock_acquire+0x145c/0x29cc
__lock_acquire from lock_acquire.part.0+0xb4/0x258
lock_acquire.part.0 from __mutex_lock+0x90/0x950
__mutex_lock from mutex_lock_nested+0x1c/0x24
mutex_lock_nested from hdmi5_bridge_mode_set+0x1c/0x50
hdmi5_bridge_mode_set from drm_bridge_chain_mode_set+0x48/0x5c
drm_bridge_chain_mode_set from crtc_set_mode+0x188/0x1d0
crtc_set_mode from omap_atomic_commit_tail+0x2c/0xbc
omap_atomic_commit_tail from commit_tail+0x9c/0x188
commit_tail from drm_atomic_helper_commit+0x158/0x18c
drm_atomic_helper_commit from drm_atomic_commit+0xa4/0xe8
drm_atomic_commit from drm_mode_atomic_ioctl+0x9a4/0xc38
drm_mode_atomic_ioctl from drm_ioctl+0x210/0x4a8
drm_ioctl from sys_ioctl+0x138/0xf00
sys_ioctl from ret_fast_syscall+0x0/0x1c
Exception stack(0xf1011fa8 to 0xf1011ff0)
1fa0: 00466d58 be9ab510 00000003 c03864bc be9ab510 be9ab4e0
1fc0: 00466d58 be9ab510 c03864bc 00000036 00466ef0 00466fc0 00467020 00466f20
1fe0: b6bc7ef4 be9ab4d0 b6bbbb00 b6cb2cc0
Fixes: 250aa22920cd ("drm/omapdrm: Annotate dma-fence critical section in commit path")
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920-dma-fence-annotation-revert-v1-2-7ebf6f7f5bf6@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ca34d816558c3e4c3f8fe037b5a6b16c944693de ]
This reverts commit 4d56a4f08391857ba93465de489707b66adad114.
The DMA-fence annotations cause a lockdep warning (see below). As per
https://patchwork.freedesktop.org/patch/462170/ it sounds like the
annotations don't work correctly.
======================================================
WARNING: possible circular locking dependency detected
6.6.0-rc2+ #1 Not tainted
------------------------------------------------------
kmstest/733 is trying to acquire lock:
ffff8000819377f0 (fs_reclaim){+.+.}-{0:0}, at: __kmem_cache_alloc_node+0x58/0x2d4
but task is already holding lock:
ffff800081a06aa0 (dma_fence_map){++++}-{0:0}, at: tidss_atomic_commit_tail+0x20/0xc0 [tidss]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (dma_fence_map){++++}-{0:0}:
__dma_fence_might_wait+0x5c/0xd0
dma_resv_lockdep+0x1a4/0x32c
do_one_initcall+0x84/0x2fc
kernel_init_freeable+0x28c/0x4c4
kernel_init+0x24/0x1dc
ret_from_fork+0x10/0x20
-> #1 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
fs_reclaim_acquire+0x70/0xe4
__kmem_cache_alloc_node+0x58/0x2d4
kmalloc_trace+0x38/0x78
__kthread_create_worker+0x3c/0x150
kthread_create_worker+0x64/0x8c
workqueue_init+0x1e8/0x2f0
kernel_init_freeable+0x11c/0x4c4
kernel_init+0x24/0x1dc
ret_from_fork+0x10/0x20
-> #0 (fs_reclaim){+.+.}-{0:0}:
__lock_acquire+0x1370/0x20d8
lock_acquire+0x1e8/0x308
fs_reclaim_acquire+0xd0/0xe4
__kmem_cache_alloc_node+0x58/0x2d4
__kmalloc_node_track_caller+0x58/0xf0
kmemdup+0x34/0x60
regmap_bulk_write+0x64/0x2c0
tc358768_bridge_pre_enable+0x8c/0x12d0 [tc358768]
drm_atomic_bridge_call_pre_enable+0x68/0x80 [drm]
drm_atomic_bridge_chain_pre_enable+0x50/0x158 [drm]
drm_atomic_helper_commit_modeset_enables+0x164/0x264 [drm_kms_helper]
tidss_atomic_commit_tail+0x58/0xc0 [tidss]
commit_tail+0xa0/0x188 [drm_kms_helper]
drm_atomic_helper_commit+0x1a8/0x1c0 [drm_kms_helper]
drm_atomic_commit+0xa8/0xe0 [drm]
drm_mode_atomic_ioctl+0x9ec/0xc80 [drm]
drm_ioctl_kernel+0xc4/0x170 [drm]
drm_ioctl+0x234/0x4b0 [drm]
drm_compat_ioctl+0x110/0x12c [drm]
__arm64_compat_sys_ioctl+0x128/0x150
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc_compat+0x1c/0x38
el0_svc_compat+0x48/0xb4
el0t_32_sync_handler+0xb0/0x138
el0t_32_sync+0x194/0x198
other info that might help us debug this:
Chain exists of:
fs_reclaim --> mmu_notifier_invalidate_range_start --> dma_fence_map
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(dma_fence_map);
lock(mmu_notifier_invalidate_range_start);
lock(dma_fence_map);
lock(fs_reclaim);
*** DEADLOCK ***
3 locks held by kmstest/733:
#0: ffff800082e5bba0 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_atomic_ioctl+0x118/0xc80 [drm]
#1: ffff000004224c88 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xdc/0x1a0 [drm]
#2: ffff800081a06aa0 (dma_fence_map){++++}-{0:0}, at: tidss_atomic_commit_tail+0x20/0xc0 [tidss]
stack backtrace:
CPU: 0 PID: 733 Comm: kmstest Not tainted 6.6.0-rc2+ #1
Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
Call trace:
dump_backtrace+0x98/0x118
show_stack+0x18/0x24
dump_stack_lvl+0x60/0xac
dump_stack+0x18/0x24
print_circular_bug+0x288/0x368
check_noncircular+0x168/0x17c
__lock_acquire+0x1370/0x20d8
lock_acquire+0x1e8/0x308
fs_reclaim_acquire+0xd0/0xe4
__kmem_cache_alloc_node+0x58/0x2d4
__kmalloc_node_track_caller+0x58/0xf0
kmemdup+0x34/0x60
regmap_bulk_write+0x64/0x2c0
tc358768_bridge_pre_enable+0x8c/0x12d0 [tc358768]
drm_atomic_bridge_call_pre_enable+0x68/0x80 [drm]
drm_atomic_bridge_chain_pre_enable+0x50/0x158 [drm]
drm_atomic_helper_commit_modeset_enables+0x164/0x264 [drm_kms_helper]
tidss_atomic_commit_tail+0x58/0xc0 [tidss]
commit_tail+0xa0/0x188 [drm_kms_helper]
drm_atomic_helper_commit+0x1a8/0x1c0 [drm_kms_helper]
drm_atomic_commit+0xa8/0xe0 [drm]
drm_mode_atomic_ioctl+0x9ec/0xc80 [drm]
drm_ioctl_kernel+0xc4/0x170 [drm]
drm_ioctl+0x234/0x4b0 [drm]
drm_compat_ioctl+0x110/0x12c [drm]
__arm64_compat_sys_ioctl+0x128/0x150
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc_compat+0x1c/0x38
el0_svc_compat+0x48/0xb4
el0t_32_sync_handler+0xb0/0x138
el0t_32_sync+0x194/0x198
Fixes: 4d56a4f08391 ("drm/tidss: Annotate dma-fence critical section in commit path")
Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920-dma-fence-annotation-revert-v1-1-7ebf6f7f5bf6@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6e455f5dcdd15fa28edf0ffb5b44d3508512dccf ]
Commit 3823119b9c2b ("drm/crtc: Fix uninit-value bug in
drm_mode_setcrtc") was supposed to fix use of an uninitialized variable,
but introduced another.
num_connectors is only initialized if crtc_req->count_connectors > 0,
but it's used regardless. Fix it.
Fixes: 3823119b9c2b ("drm/crtc: Fix uninit-value bug in drm_mode_setcrtc")
Cc: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
Cc: Ziqi Zhao <astrajoan@yahoo.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231208131238.2924571-1-jani.nikula@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
The connector_set contains uninitialized values when allocated with
kmalloc_array. However, in the "out" branch, the logic assumes that any
element in connector_set would be equal to NULL if failed to
initialize, which causes the bug reported by Syzbot. The fix is to use
an extra variable to keep track of how many connectors are initialized
indeed, and use that variable to decrease any refcounts in the "out"
branch.
Reported-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao <astrajoan@yahoo.com>
Reported-and-tested-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Link: https://lore.kernel.org/r/20230721161446.8602-1-astrajoan@yahoo.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]
Fix a wrong error checking in exynos_drm_dma.c module.
In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.
However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.
This issue[1] was reported by Dan.
Changelog v1:
- fix build warning.
[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
Reported-by : Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]
Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()
The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.
Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
