summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915: Fix memory leaks in i915 selftestsCong Liu2023-05-111-1/+3
| | | | | | | | | | | | | | | | [ Upstream commit 803033c148f754f32da1b93926c49c22731ec485 ] This patch fixes memory leaks on error escapes in function fake_get_pages Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation") Signed-off-by: Cong Liu <liucong2@kylinos.cn> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230414224109.1051922-1-andi.shyti@linux.intel.com (cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Make intel_get_crtc_new_encoder() less oopsyVille Syrjälä2023-05-111-1/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 631420b06597a33c72b6dcef78d1c2dea17f452d ] The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413200602.6037-2-ville.syrjala@linux.intel.com Fixes: 3a47ae201e07 ("drm/i915/display: Make WARN* drm specific where encoder ptr is available") Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: add remove function for decoder platform driverYunfei Dong2023-05-111-0/+8
| | | | | | | | | | | | | [ Upstream commit e2a10b3801061d05d3e3415b9b824251451cfd6c ] Need to disable decoder power when remove decoder hardware driver, adding remove callback function in the definition of platform driver. Fixes: c05bada35f01 ("media: mtk-vcodec: Add to support multi hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: fix decoder disable pm crashYunfei Dong2023-05-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9d2f13fb47dcab6d094f34ecfd6a879a409722b3 ] Can't call pm_runtime_disable when the architecture support sub device for 'dev->pm.dev' is NUll, or will get below crash log. [ 10.771551] pc : _raw_spin_lock_irq+0x4c/0xa0 [ 10.771556] lr : __pm_runtime_disable+0x30/0x130 [ 10.771558] sp : ffffffc01e4cb800 [ 10.771559] x29: ffffffc01e4cb800 x28: ffffffdf082108a8 [ 10.771563] x27: ffffffc01e4cbd70 x26: ffffff8605df55f0 [ 10.771567] x25: 0000000000000002 x24: 0000000000000002 [ 10.771570] x23: ffffff85c0dc9c00 x22: 0000000000000001 [ 10.771573] x21: 0000000000000001 x20: 0000000000000000 [ 10.771577] x19: 00000000000000f4 x18: ffffffdf2e9fbe18 [ 10.771580] x17: 0000000000000000 x16: ffffffdf2df13c74 [ 10.771583] x15: 00000000000002ea x14: 0000000000000058 [ 10.771587] x13: ffffffdf2de1b62c x12: ffffffdf2e9e30e4 [ 10.771590] x11: 0000000000000000 x10: 0000000000000001 [ 10.771593] x9 : 0000000000000000 x8 : 00000000000000f4 [ 10.771596] x7 : 6bff6264632c6264 x6 : 0000000000008000 [ 10.771600] x5 : 0080000000000000 x4 : 0000000000000001 [ 10.771603] x3 : 0000000000000008 x2 : 0000000000000001 [ 10.771608] x1 : 0000000000000000 x0 : 00000000000000f4 [ 10.771613] Call trace: [ 10.771617] _raw_spin_lock_irq+0x4c/0xa0 [ 10.771620] __pm_runtime_disable+0x30/0x130 [ 10.771657] mtk_vcodec_probe+0x69c/0x728 [mtk_vcodec_dec 800cc929d6631f79f9b273254c8db94d0d3500dc] [ 10.771662] platform_drv_probe+0x9c/0xbc [ 10.771665] really_probe+0x13c/0x3a0 [ 10.771668] driver_probe_device+0x84/0xc0 [ 10.771671] device_driver_attach+0x54/0x78 Fixes: ba31a5b39400 ("media: mtk-vcodec: Remove mtk_vcodec_release_dec_pm") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* perf/arm-cmn: Fix port detection for CMN-700Robin Murphy2023-05-111-27/+30
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2ad91e44e6b0c7ef1ed151b3bb2242a2144e6085 ] When the "extra device ports" configuration was first added, the additional mxp_device_port_connect_info registers were added around the existing mxp_mesh_port_connect_info registers. What I missed about CMN-700 is that it shuffled them around to remove this discontinuity. As such, tweak the definitions and factor out a helper for reading these registers so we can deal with this discrepancy easily, which does at least allow nicely tidying up the callsites. With this we can then also do the nice thing and skip accesses completely rather than relying on RES0 behaviour where we know the extra registers aren't defined. Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support") Reported-by: Jing Zhang <renyu.zj@linux.alibaba.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/71d129241d4d7923cde72a0e5b4c8d2f6084525f.1681295193.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: stm32-pwr: fix of_iomap leakYAN SHI2023-05-111-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c4a413e56d16a2ae84e6d8992f215c4dcc7fac20 ] Smatch reports: drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn: 'base' from of_iomap() not released on lines: 151,166. In stm32_pwr_regulator_probe(), base is not released when devm_kzalloc() fails to allocate memory or devm_regulator_register() fails to register a new regulator device, which may cause a leak. To fix this issue, replace of_iomap() with devm_platform_ioremap_resource(). devm_platform_ioremap_resource() is a specialized function for platform devices. It allows 'base' to be automatically released whether the probe function succeeds or fails. Besides, use IS_ERR(base) instead of !base as the return value of devm_platform_ioremap_resource() can either be a pointer to the remapped memory or an ERR_PTR() encoded error code if the operation fails. Fixes: dc62f951a6a8 ("regulator: stm32-pwr: Fix return value check in stm32_pwr_regulator_probe()") Signed-off-by: YAN SHI <m202071378@hust.edu.cn> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304111750.o2643eJN-lkp@intel.com/ Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Link: https://lore.kernel.org/r/20230412033529.18890-1-m202071378@hust.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: venus: dec: Fix capture formats enumeration orderJavier Martinez Canillas2023-05-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a9d45ec74c8e68aaafe90191928eddbf79f4644f ] Commit 9593126dae3e ("media: venus: Add a handling of QC08C compressed format") and commit cef92b14e653 ("media: venus: Add a handling of QC10C compressed format") added support for the QC08C and QC10C compressed formats respectively. But these also caused a regression, because the new formats where added at the beginning of the vdec_formats[] array and the vdec_inst_init() function sets the default format output and capture using fixed indexes of that array: static void vdec_inst_init(struct venus_inst *inst) { ... inst->fmt_out = &vdec_formats[8]; inst->fmt_cap = &vdec_formats[0]; ... } Since now V4L2_PIX_FMT_NV12 is not the first entry in the array anymore, the default capture format is not set to that as it was done before. Both commits changed the first index to keep inst->fmt_out default format set to V4L2_PIX_FMT_H264, but did not update the latter to keep .fmt_out default format set to V4L2_PIX_FMT_NV12. Rather than updating the index to the current V4L2_PIX_FMT_NV12 position, let's reorder the entries so that this format is the first entry again. This would also make VIDIOC_ENUM_FMT report the V4L2_PIX_FMT_NV12 format with an index 0 as it did before the QC08C and QC10C formats were added. Fixes: 9593126dae3e ("media: venus: Add a handling of QC08C compressed format") Fixes: cef92b14e653 ("media: venus: Add a handling of QC10C compressed format") Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: venus: dec: Fix handling of the start cmdMichał Krawczyk2023-05-111-0/+8
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 50248ad9f190d527cbd578190ca769729518b703 ] The decoder driver should clear the last_buffer_dequeued flag of the capture queue upon receiving V4L2_DEC_CMD_START. The last_buffer_dequeued flag is set upon receiving EOS (which always happens upon receiving V4L2_DEC_CMD_STOP). Without this patch, after issuing the V4L2_DEC_CMD_STOP and V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if the buffers are completed by the hardware. Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API") Signed-off-by: Michał Krawczyk <mk@semihalf.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: rc: gpio-ir-recv: Fix support for wake-upFlorian Fainelli2023-05-111-0/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit 9c592f8ab114875fdb3b2040f01818e53de44991 ] The driver was intended from the start to be a wake-up source for the system, however due to the absence of a suitable call to device_set_wakeup_capable(), the device_may_wakeup() call used to decide whether to enable the GPIO interrupt as a wake-up source would never happen. Lookup the DT standard "wakeup-source" property and call device_init_wakeup() to ensure the device is flagged as being wakeup capable. Reported-by: Matthew Lear <matthew.lear@broadcom.com> Fixes: fd0f6851eb46 ("[media] rc: Add support for GPIO based IR Receiver driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: Fix potential null dereferenceIgor Artemiev2023-05-111-1/+2
| | | | | | | | | | | | | | | | | [ Upstream commit 52f1783ff4146344342422c1cd94fcb4ce39b6fe ] The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini() without checking. Add a NULL pointer check before calling dc_dmub_srv_destroy(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9a71c7d31734 ("drm/amd/display: Register DMUB service with DC") Signed-off-by: Igor Artemiev <Igor.A.Artemiev@mcst.ru> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: hi846: Fix memleak in hi846_init_controls()Wei Chen2023-05-111-3/+8
| | | | | | | | | | | | | | | [ Upstream commit 2649c1a20e8e399ee955d0e22192f9992662c3d2 ] hi846_init_controls doesn't clean the allocated ctrl_hdlr in case there is a failure, which causes memleak. Add v4l2_ctrl_handler_free to free the resource properly. Fixes: e8c0882685f9 ("media: i2c: add driver for the SK Hynix Hi-846 8M pixel camera") Signed-off-by: Wei Chen <harperchen1110@gmail.com> Reviewed-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: v4l: async: Return async sub-devices to subnotifier listSakari Ailus2023-05-111-5/+8
| | | | | | | | | | | | | | | [ Upstream commit 5276c9df9c2ab9a43b534bfb56bdb10899cd3a22 ] When an async notifier is unregistered, the async sub-devices in the notifier's done list will disappear with the notifier. However this is currently also done to the sub-notifiers that remain registered. Their sub-devices only need to be unbound while the async sub-devices themselves need to be returned to the sub-notifier's waiting list. Do this now. Fixes: 2cab00bb076b ("media: v4l: async: Allow binding notifiers to sub-devices") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: rcar_fdp1: Fix refcount leak in probe and remove functionMiaoqian Lin2023-05-111-3/+8
| | | | | | | | | | | | | | | | [ Upstream commit c766c90faf93897b77c9c5daa603cffab85ba907 ] rcar_fcp_get() take reference, which should be balanced with rcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove and the error paths of fdp1_probe() to fix this. Fixes: 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [hverkuil: resolve merge conflict, remove() is now void] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: rcar_fdp1: Convert to platform remove callback returning voidUwe Kleine-König2023-05-111-4/+2
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0e82d3715fd208de567b8e4307fbf91ae5e57db4 ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Stable-dep-of: c766c90faf93 ("media: rcar_fdp1: Fix refcount leak in probe and remove function") Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: vsp1: Replace vb2_is_streaming() with vb2_start_streaming_called()Laurent Pinchart2023-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 52d8caca3d533cc499f1255be25576ffd936ec95 ] The vsp1 driver uses the vb2_is_streaming() function in its .buf_queue() handler to check if the .start_streaming() operation has been called, and decide whether to just add the buffer to an internal queue, or also trigger a hardware run. vb2_is_streaming() relies on the vb2_queue structure's streaming field, which used to be set only after calling the .start_streaming() operation. Commit a10b21532574 ("media: vb2: add (un)prepare_streaming queue ops") changed this, setting the .streaming field in vb2_core_streamon() before enqueuing buffers to the driver and calling .start_streaming(). This broke the vsp1 driver which now believes that .start_streaming() has been called when it hasn't, leading to a crash: [ 881.058705] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 881.067495] Mem abort info: [ 881.070290] ESR = 0x0000000096000006 [ 881.074042] EC = 0x25: DABT (current EL), IL = 32 bits [ 881.079358] SET = 0, FnV = 0 [ 881.082414] EA = 0, S1PTW = 0 [ 881.085558] FSC = 0x06: level 2 translation fault [ 881.090439] Data abort info: [ 881.093320] ISV = 0, ISS = 0x00000006 [ 881.097157] CM = 0, WnR = 0 [ 881.100126] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004fa51000 [ 881.106573] [0000000000000020] pgd=080000004f36e003, p4d=080000004f36e003, pud=080000004f7ec003, pmd=0000000000000000 [ 881.117217] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ 881.123494] Modules linked in: rcar_fdp1 v4l2_mem2mem [ 881.128572] CPU: 0 PID: 1271 Comm: yavta Tainted: G B 6.2.0-rc1-00023-g6c94e2e99343 #556 [ 881.138061] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 881.145981] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 881.152951] pc : vsp1_dl_list_add_body+0xa8/0xe0 [ 881.157580] lr : vsp1_dl_list_add_body+0x34/0xe0 [ 881.162206] sp : ffff80000c267710 [ 881.165522] x29: ffff80000c267710 x28: ffff000010938ae8 x27: ffff000013a8dd98 [ 881.172683] x26: ffff000010938098 x25: ffff000013a8dc00 x24: ffff000010ed6ba8 [ 881.179841] x23: ffff00000faa4000 x22: 0000000000000000 x21: 0000000000000020 [ 881.186998] x20: ffff00000faa4000 x19: 0000000000000000 x18: 0000000000000000 [ 881.194154] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 881.201309] x14: 0000000000000000 x13: 746e696174206c65 x12: ffff70000157043d [ 881.208465] x11: 1ffff0000157043c x10: ffff70000157043c x9 : dfff800000000000 [ 881.215622] x8 : ffff80000ab821e7 x7 : 00008ffffea8fbc4 x6 : 0000000000000001 [ 881.222779] x5 : ffff80000ab821e0 x4 : ffff70000157043d x3 : 0000000000000020 [ 881.229936] x2 : 0000000000000020 x1 : ffff00000e4f6400 x0 : 0000000000000000 [ 881.237092] Call trace: [ 881.239542] vsp1_dl_list_add_body+0xa8/0xe0 [ 881.243822] vsp1_video_pipeline_run+0x270/0x2a0 [ 881.248449] vsp1_video_buffer_queue+0x1c0/0x1d0 [ 881.253076] __enqueue_in_driver+0xbc/0x260 [ 881.257269] vb2_start_streaming+0x48/0x200 [ 881.261461] vb2_core_streamon+0x13c/0x280 [ 881.265565] vb2_streamon+0x3c/0x90 [ 881.269064] vsp1_video_streamon+0x2fc/0x3e0 [ 881.273344] v4l_streamon+0x50/0x70 [ 881.276844] __video_do_ioctl+0x2bc/0x5d0 [ 881.280861] video_usercopy+0x2a8/0xc80 [ 881.284704] video_ioctl2+0x20/0x40 [ 881.288201] v4l2_ioctl+0xa4/0xc0 [ 881.291525] __arm64_sys_ioctl+0xe8/0x110 [ 881.295543] invoke_syscall+0x68/0x190 [ 881.299303] el0_svc_common.constprop.0+0x88/0x170 [ 881.304105] do_el0_svc+0x4c/0xf0 [ 881.307430] el0_svc+0x4c/0xa0 [ 881.310494] el0t_64_sync_handler+0xbc/0x140 [ 881.314773] el0t_64_sync+0x190/0x194 [ 881.318450] Code: d50323bf d65f03c0 91008263 f9800071 (885f7c60) [ 881.324551] ---[ end trace 0000000000000000 ]--- [ 881.329173] note: yavta[1271] exited with preempt_count 1 A different regression report sent to the linux-media mailing list ([1]) was answered with a claim that the vb2_is_streaming() function has never been meant for this purpose. The document of the function, as well as of the struct vb2_queue streaming field, is sparse, so this claim may be hard to verify. The information needed by the vsp1 driver to decide how to process queued buffers is also available from the vb2_start_streaming_called() function. Use it instead of vb2_is_streaming() to fix the problem. [1] https://lore.kernel.org/linux-media/545610e7-3446-2b82-60dc-7385fea3774f@redhat.com/ Fixes: a10b21532574 ("media: vb2: add (un)prepare_streaming queue ops") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: platform: mtk-mdp3: fix potential frame size overflow in ↵Moudy Ho2023-05-111-4/+6
| | | | | | | | | | | | | | | | | | mdp_try_fmt_mplane() [ Upstream commit 4168720753ce6c14c5d3a35302fc2e1841383443 ] Fix overflow risk when setting certain formats whose frame size exceeds a RGB24 with 7723x7723 resolution. For example, a 7723x7724 RGB24 frame: 1. bpl (byte per line) = 7723 * 3. 2. Overflow occurs when bpl * 7724 * depth. Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Signed-off-by: Moudy Ho <moudy.ho@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: saa7134: fix use after free bug in saa7134_finidev due to race conditionZheng Wang2023-05-113-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 30cf57da176cca80f11df0d9b7f71581fe601389 ] In saa7134_initdev, it will call saa7134_hwinit1. There are three function invoking here: saa7134_video_init1, saa7134_ts_init1 and saa7134_vbi_init1. All of them will init a timer with same function. Take saa7134_video_init1 as an example. It'll bound &dev->video_q.timeout with saa7134_buffer_timeout. In buffer_activate, the timer funtcion is started. If we remove the module or device which will call saa7134_finidev to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the timer works accordingly before cleanup in saa7134_finidev. CPU0 CPU1 |saa7134_buffer_timeout saa7134_finidev | kfree(dev); | | | saa7134_buffer_next | //use dev Fixes: 1e7126b4a86a ("media: saa7134: Convert timers to use timer_setup()") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: dm1105: Fix use after free bug in dm1105_remove due to race conditionZheng Wang2023-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5abda7a16698d4d1f47af1168d8fa2c640116b4a ] In dm1105_probe, it called dm1105_ir_init and bound &dm1105->ir.work with dm1105_emit_key. When it handles IRQ request with dm1105_irq, it may call schedule_work to start the work. When we call dm1105_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in dm1105_remove CPU0 CPU1 |dm1105_emit_key dm1105_remove | dm1105_ir_exit | rc_unregister_device | rc_free_device | rc_dev_release | kfree(dev); | | | rc_keydown | //use Fixes: 34d2f9bf189c ("V4L/DVB: dm1105: use dm1105_dev & dev instead of dm1105dvb") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Move out of BIOS SMN pair for STB initShyam Sundar S K2023-05-111-22/+4
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8d99129eef8f42377b41c1bacee9f8ce806e9f44 ] The current SMN index used for the driver probe seems to be meant for the BIOS pair and there are potential concurrency problems that can occur with an inopportune SMI. It is been advised to use SMN_INDEX_0 instead of SMN_INDEX_6, which is what amd_nb.c provides and this function has protections to ensure that only one caller can use it at a time. Fixes: 426c0ff27b83 ("platform/x86: amd-pmc: Add support for AMD Smart Trace Buffer") Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-7-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Utilize SMN index 0 for driver probeShyam Sundar S K2023-05-112-19/+6
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 310e782a99c7f16fb533a45d8f9c16defefa5aab ] The current SMN index used for the driver probe seems to be meant for the BIOS pair and there are potential concurrency problems that can occur with an inopportune SMI. It is been advised to use SMN_INDEX_0 instead of SMN_INDEX_2, which is what amd_nb.c provides and this function has protections to ensure that only one caller can use it at a time. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-6-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Move idlemask check into `amd_pmc_idlemask_read`Mario Limonciello2023-05-111-41/+33
| | | | | | | | | | | | | | | | | | [ Upstream commit 9217bd1d7699f34a01b26ba14ff38c1714ce1185 ] The version check requirement for idle mask support actually only applies to RN/CZN/BRC platforms. So far no issues have happened because the PMFW version string is bigger on other supported systems. This can be reset for any new platform so move the check to only RN/CZN/BRC case. Fixes: f6045de1f532 ("platform/x86: amd-pmc: Export Idlemask values based on the APU") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-5-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Don't dump data after resume from s0i3 on picassoMario Limonciello2023-05-111-1/+9
| | | | | | | | | | | | | | | [ Upstream commit 7abc3618b65304d409d9489d77e4a8f047842fb7 ] This command isn't supported on Picasso, so guard against running it to avoid errors like `SMU cmd unknown. err: 0xfe` in the logs. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449 Fixes: 766205674962 ("platform/x86: amd-pmc: Add support for logging SMU metrics") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-4-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Hide SMU version and program attributes for PicassoMario Limonciello2023-05-111-1/+20
| | | | | | | | | | | | | | | [ Upstream commit 5ec9ee0d464750d72972d5685edf675824e259a1 ] As the command to get version isn't supported on Picasso, we shouldn't be exposing this into sysfs either. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449 Fixes: 7f1ea75d499a ("platform/x86/amd: pmc: Add sysfs files for SMU") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-3-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd: pmc: Don't try to read SMU version on PicassoMario Limonciello2023-05-111-0/+3
| | | | | | | | | | | | | | | [ Upstream commit b845772677ea19b8e4c032bc07393ef32de4ee39 ] Picasso doesn't support the command in the uPEP mailbox to try to read the SMU version. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449 Fixes: f6045de1f532 ("platform/x86: amd-pmc: Export Idlemask values based on the APU") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230409185348.556161-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86/amd/pmf: Move out of BIOS SMN pair for driver probeShyam Sundar S K2023-05-112-17/+6
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit aec8298c093f052fc8a86f9411b69b23953b0edb ] The current SMN index used for the driver probe seems to be meant for the BIOS pair and there are potential concurrency problems that can occur with an inopportune SMI. It is been advised to use SMN_INDEX_0 instead of SMN_INDEX_2, which is what amd_nb.c provides and this function has protections to ensure that only one caller can use it at a time. Fixes: da5ce22df5fe ("platform/x86/amd/pmf: Add support for PMF core layer") Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230406164807.50969-4-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: rkvdec: fix use after free bug in rkvdec_removeZheng Wang2023-05-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3228cec23b8b29215e18090c6ba635840190993d ] In rkvdec_probe, rkvdec->watchdog_work is bound with rkvdec_watchdog_func. Then rkvdec_vp9_run may be called to start the work. If we remove the module which will call rkvdec_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in rkvdec_remove. CPU0 CPU1 |rkvdec_watchdog_func rkvdec_remove | rkvdec_v4l2_cleanup| v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: cedrus: fix use after free bug in cedrus_remove due to race conditionZheng Wang2023-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 50d0a7aea4809cef87979d4669911276aa23b71f ] In cedrus_probe, dev->watchdog_work is bound with cedrus_watchdog function. In cedrus_device_run, it will started by schedule_delayed_work. If there is an unfinished work in cedrus_remove, there may be a race condition and trigger UAF bug. CPU0 CPU1 |cedrus_watchdog cedrus_remove | v4l2_m2m_release | kfree(m2m_dev) | | | v4l2_m2m_get_curr_priv | m2m_dev //use Fix it by canceling the worker in cedrus_remove. Fixes: 7c38a551bda1 ("media: cedrus: Add watchdog for job completion") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: change lat thread decode error conditionYunfei Dong2023-05-113-4/+6
| | | | | | | | | | | | | | [ Upstream commit 960badda95f10fb0c60f6f64978b19eafa9507a7 ] If lat thread can't get lat buffer, it should be that current instance don't be schedulded, the driver can't free the src buffer directly. Fixes: 7b182b8d9c85 ("media: mediatek: vcodec: Refactor get and put capture buffer flow") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: making sure queue_work successfullyYunfei Dong2023-05-112-8/+25
| | | | | | | | | | | | | | | [ Upstream commit 2e0ef56d81cb2569624d288b7e95a8a2734a7c74 ] Putting core work to work queue using queue_work maybe fail, call queue_work again when the count of core work in work queue is less than core_list_cnt, making sure all the buffer in core list can be scheduled. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: remove unused lat_bufYunfei Dong2023-05-111-3/+15
| | | | | | | | | | | | | | [ Upstream commit af50b13dd3d7d5dbc1f08add1c462398e926a053 ] Remove unused lat_buf from core list, or leading to core list access NULL point. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: add core decode done eventYunfei Dong2023-05-112-1/+5
| | | | | | | | | | | | | [ Upstream commit d227af847ac2d7d90350124a1b2451e4fc1f050c ] Need to make sure core decode done before current instance is free. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: move lat_buf to the top of core listYunfei Dong2023-05-112-1/+22
| | | | | | | | | | | | | | | [ Upstream commit 2cfca6c1bf8074175ea7a3b6b47f77ebdef8f701 ] Current instance will decode done when begin to wait lat buf full, move the lat_buf of current instance to the top of core list to make sure current instance's lat_buf will be used firstly. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: using each instance lat_buf count replace core ↵Yunfei Dong2023-05-111-1/+1
| | | | | | | | | | | | | | | | | ready list [ Upstream commit f7a3780cf96925670736582b9a623a2c9ffb4166 ] Core Hardware decoder depends on each instance lat_buf count, calling queue_work decode again when the lat_buf count of each instance isn't zero. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: add params to record lat and core lat_buf countYunfei Dong2023-05-112-1/+28
| | | | | | | | | | | | | | [ Upstream commit 5bbb6e2ca67477ab41163b32e6b3444faea74a5e ] Using lat_buf to share decoder information between lat and core work queue, adding params to record the buf count. Fixes: 365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: Force capture queue format to MM21Yunfei Dong2023-05-111-21/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 68c7df527657a9e962da7b5b9c0308557357d8dc ] While the decoder can produce frames in both MM21 and MT21C formats, only MM21 is currently supported by userspace tools (like gstreamer and libyuv). In order to ensure userspace keeps working after the SCP firmware is updated to support both MM21 and MT21C formats, force the MM21 format for the capture queue. This is meant as a stopgap solution while dynamic format switching between MM21 and MT21C isn't implemented in the driver. Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: Make MM21 the default capture formatYunfei Dong2023-05-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6d020d81b91af80a977061e82de25cafa4456af5 ] Given that only the MM21 capture format is supported by userspace tools (like gstreamer and libyuv), make it the default capture format. This allows us to force the MM21 format even when a MM21 and MT21C capable firmware is available (which is needed while dynamic format switching isn't implemented in the driver), without causing the following regressions on v4l2-compliance: fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_G_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_S_FMT: FAIL Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nicolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mediatek: vcodec: Use 4K frame size when supported by stateful decoderPin-yen Lin2023-05-111-1/+11
| | | | | | | | | | | | | | | | | | | [ Upstream commit e25528e1dbe52784ac250071653104a8adc848e2 ] After commit b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability"), the stateful video decoder driver never really sets its output frame size to 4K. Parse the decoder capability reported by the firmware, and update the output frame size in mtk_init_vdec_params to enable 4K frame size when available. Fixes: b018be06f3c7 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mtk-jpeg: Fixes jpeg enc&dec worker sw flowkyrie wu2023-05-112-11/+7
| | | | | | | | | | | | | | | | | | | [ Upstream commit 86379bd9d399e2c5fd638a869af223d4910725c3 ] 1. Move removing buffer after sw setting and before hw setting in enc&dec worker to prevents the operation of removing the buffer twice if the sw setting fails. 2. Remove the redundant operation of queue work in the jpegenc irq handler because the jpegenc worker has called v4l2_m2m_job_finish to do it. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface") Signed-off-by: kyrie wu <kyrie.wu@mediatek.com> Signed-off-by: irui wang <irui.wang@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: mtk-jpeg: Fixes jpeghw multi-core judgementkyrie wu2023-05-112-1/+6
| | | | | | | | | | | | | | | [ Upstream commit 75c38caf66a10983acc5a59069bfc9492c43d682 ] some chips have multi-hw, but others have only one, modify the condition of multi-hw judgement Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware") Signed-off-by: kyrie wu <kyrie.wu@mediatek.com> Signed-off-by: irui wang <irui.wang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* soc: qcom: rpmh-rsc: Support RSC v3 minor versionsTushar Nimkar2023-05-111-1/+1
| | | | | | | | | | | | | [ Upstream commit 88704a0cd71909c3107561261412a5d5beb23358 ] RSC v3 register offsets are same for all minor versions of v3. Fix a minor version check to pick correct offsets for all v3 minor versions. Fixes: 40482e4f7364 ("soc: qcom: rpmh-rsc: Add support for RSC v3 register offsets") Signed-off-by: Tushar Nimkar <quic_tnimkar@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230406115732.9293-1-quic_tnimkar@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* thermal/drivers/mediatek/lvts_thermal: Fix sensor 1 interrupt status bitmaskChen-Yu Tsai2023-05-111-3/+3
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 13f03bcd02e4b0498c8ccb066b4eddf61dee6681 ] The binary representation for sensor 1 interrupt status was incorrectly assembled, when compared to the full table given in the same comment section. The conversion into hex was also incorrect, leading to incorrect interrupt status bitmask for sensor 1. This would cause the driver to incorrectly identify changes for sensor 1, when in fact it was sensor 0, or a sensor access time out. Fix the binary and hex representations in the comments, and the actual bitmask macro. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20230328031017.1360976-1-wenst@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/msm/dpu: Fix bit-shifting UB in DPU_HW_VER() macroGeert Uytterhoeven2023-05-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4760be481dc075cd13f95f4650f5d5b53b4b336d ] With gcc-5 and CONFIG_UBSAN_SHIFT=y: drivers/gpu/drm/msm/msm_mdss.c: In function 'msm_mdss_enable': drivers/gpu/drm/msm/msm_mdss.c:296:2: error: case label does not reduce to an integer constant case DPU_HW_VER_800: ^ drivers/gpu/drm/msm/msm_mdss.c:299:2: error: case label does not reduce to an integer constant case DPU_HW_VER_810: ^ drivers/gpu/drm/msm/msm_mdss.c:300:2: error: case label does not reduce to an integer constant case DPU_HW_VER_900: ^ This happens because for major revisions 8 or greather, the non-sign bit of the major revision number is shifted into bit 31 of a signed integer, which is undefined behavior. Fix this by casting the major revision number to unsigned int. Fixes: efcd0107727c4f04 ("drm/msm/dpu: add support for SM8550") Fixes: 4a352c2fc15aec1e ("drm/msm/dpu: Introduce SC8280XP") Fixes: 100d7ef6995d1f86 ("drm/msm/dpu: add support for SM8450") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/525152/ Link: https://lore.kernel.org/r/20230306090633.65918-1-geert+renesas@glider.be Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Revert "drm/msm: Fix failure paths in msm_drm_init()"Johan Hovold2023-05-112-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 652eadfde81031c7b3d8b21bdbcfdd6eb217dec8 ] This reverts commit 8636500300a01740d92b345c680b036b94555b1b. A recent commit tried to address a drm device leak in the early msm_drm_uninit() error paths but ended up making things worse. Specifically, it moved the drm device reference put in msm_drm_uninit() to msm_drm_init() which means that the drm would now be leaked on normal unbind. For reasons that were never spelled out, it also added kms NULL pointer checks to a couple of helper functions that had nothing to do with the paths modified by the patch. Instead of trying to salvage this incrementally, let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 8636500300a0 ("drm/msm: Fix failure paths in msm_drm_init()") Cc: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/525092/ Link: https://lore.kernel.org/r/20230306100722.28485-3-johan+linaro@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Revert "drm/msm: Add missing check and destroy for alloc_ordered_workqueue"Johan Hovold2023-05-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dfa70344d1b5f5ff08525a8c872c8dd5e82fc5d9 ] This reverts commit 643b7d0869cc7f1f7a5ac7ca6bd25d88f54e31d0. A recent patch that tried to fix up the msm_drm_init() paths with respect to the workqueue but only ended up making things worse: First, the newly added calls to msm_drm_uninit() on early errors would trigger NULL-pointer dereferences, for example, as the kms pointer would not have been initialised. (Note that these paths were also modified by a second broken error handling patch which in effect cancelled out this part when merged.) Second, the newly added allocation sanity check would still leak the previously allocated drm device. Instead of trying to salvage what was badly broken (and clearly not tested), let's revert the bad commit so that clean and backportable fixes can be added in its place. Fixes: 643b7d0869cc ("drm/msm: Add missing check and destroy for alloc_ordered_workqueue") Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/525107/ Link: https://lore.kernel.org/r/20230306100722.28485-2-johan+linaro@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: Avoid lockdep reports when resolving suppliesDouglas Anderson2023-05-111-8/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cba6cfdc7c3f1516f0d08ddfb24e689af0932573 ] An automated bot told me that there was a potential lockdep problem with regulators. This was on the chromeos-5.15 kernel, but I see nothing that would be different downstream compared to upstream. The bot said: ============================================ WARNING: possible recursive locking detected 5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted -------------------------------------------- kworker/u16:4/115 is trying to acquire lock: ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec but task is already holding lock: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(regulator_ww_class_mutex); lock(regulator_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by kworker/u16:4/115: #0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348 #1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348 #2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4 #3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8 stack backtrace: CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da Hardware name: Google Quackingstick (rev0+) (DT) Workqueue: events_unbound async_run_entry_fn Call trace: dump_backtrace+0x0/0x4ec show_stack+0x34/0x50 dump_stack_lvl+0xdc/0x11c dump_stack+0x1c/0x48 __lock_acquire+0x16d4/0x6c74 lock_acquire+0x208/0x750 __mutex_lock_common+0x11c/0x11f8 ww_mutex_lock+0xc0/0x440 create_regulator+0x398/0x7ec regulator_resolve_supply+0x654/0x7c4 regulator_register_resolve_supply+0x30/0x120 class_for_each_device+0x1b8/0x230 regulator_register+0x17a4/0x1f40 devm_regulator_register+0x60/0xd0 reg_fixed_voltage_probe+0x728/0xaec platform_probe+0x150/0x1c8 really_probe+0x274/0xa20 __driver_probe_device+0x1dc/0x3f4 driver_probe_device+0x78/0x1c0 __device_attach_driver+0x1ac/0x2c8 bus_for_each_drv+0x11c/0x190 __device_attach_async_helper+0x1e4/0x2a4 async_run_entry_fn+0xa0/0x3ac process_one_work+0x638/0x1348 worker_thread+0x4a8/0x9c4 kthread+0x2e4/0x3a0 ret_from_fork+0x10/0x20 The problem was first reported soon after we made many of the regulators probe asynchronously, though nothing I've seen implies that the problems couldn't have also happened even without that. I haven't personally been able to reproduce the lockdep issue, but the issue does look somewhat legitimate. Specifically, it looks like in regulator_resolve_supply() we are holding a "rdev" lock while calling set_supply() -> create_regulator() which grabs the lock of a _different_ "rdev" (the one for our supply). This is not necessarily safe from a lockdep perspective since there is no documented ordering between these two locks. In reality, we should always be locking a regulator before the supplying regulator, so I don't expect there to be any real deadlocks in practice. However, the regulator framework in general doesn't express this to lockdep. Let's fix the issue by simply grabbing the two locks involved in the same way we grab multiple locks elsewhere in the regulator framework: using the "wound/wait" mechanisms. Fixes: eaa7995c529b ("regulator: core: avoid regulator_resolve_supply() race condition") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeid Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* regulator: core: Consistently set mutex_owner when using ww_mutex_lock_slow()Douglas Anderson2023-05-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b83a1772be854f87602de14726737d3e5b06e1f4 ] When a codepath locks a rdev using ww_mutex_lock_slow() directly then that codepath is responsible for incrementing the "ref_cnt" and also setting the "mutex_owner" to "current". The regulator core consistently got that right for "ref_cnt" but didn't always get it right for "mutex_owner". Let's fix this. It's unlikely that this truly matters because the "mutex_owner" is only needed if we're going to do subsequent locking of the same rdev. However, even though it's not truly needed it seems less surprising if we consistently set "mutex_owner" properly. Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeid Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/ttm/pool: Fix ttm_pool_alloc error pathThomas Hellström2023-05-111-30/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 379989e7cbdc7aa7496a00ee286ec146c7599cf0 ] When hitting an error, the error path forgot to unmap dma mappings and could call set_pages_wb() on already uncached pages. Fix this by introducing a common ttm_pool_free_range() function that does the right thing. v2: - Simplify that common function (Christian König) v3: - Rename that common function to ttm_pool_free_range() (Christian König) Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3") Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404200650.11043-2-thomas.hellstrom@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915/pxp: limit drm-errors or warning on firmware API failuresAlan Previn2023-05-113-15/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 69e6dd149212cdd681201352a79e6634665004e8 ] MESA driver is creating protected context on every driver handle creation to query caps bits for app. So when running CI tests, they are observing hundreds of drm_errors when enabling PXP in .config but using SOC fusing or BIOS configuration that cannot support PXP sessions. The fixes tag referenced below was to resolve a related issue where we wanted to silence error messages, but that case was due to outdated IFWI (firmware) that definitely needed an upgrade and was, at that point, considered a one-off case as opposed to today's realization that default CI was enabling PXP in kernel config for all testing. So with this patch, let's strike a balance between issues that is critical but are root-caused from HW/platform gaps (louder drm-warn but just ONCE) vs other cases where it could also come from session state machine (which cannot be a WARN_ONCE since it can be triggered due to runtime operation events). Let's use helpers for these so as more functions are added in future features / HW (or as FW designers continue to bless upstreaming of the error codes and meanings), we only need to update the helpers. NOTE: Don't completely remove FW errors (via drm_debug) or else cusomer apps that really needs to know that content protection failed won't be aware of it. v2: - Add fixes tag (Trvtko) v3: - Break multi-line drm_dbg strings into separate drm_dbg (Daniele) - Fix couple of typecasting nits (Daniele) v4: - Unsuccessful PXP FW cmd due to platform configuration shouldn't use drm_WARN_once (Tvrtko), Switched to use drm_info_once. v5: - Added "reported-and-tested" by Eero. Reported-and-tested-by: Eero Tamminen <eero.t.tamminen@intel.com> Fixes: b762787bf767 ("drm/i915/pxp: Use drm_dbg if arb session failed due to fw version") Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323184156.4140659-1-alan.previn.teres.alexis@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915/pxp: Invalidate all PXP fw sessions during teardownAlan Previn2023-05-115-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d374c047b38e9f1130308aae207dc44045cd5cac ] A gap was recently discovered where if an application did not invalidate all of the stream keys (intentionally or not), and the driver did a full PXP global teardown on the GT subsystem, we find that future session creation would fail on the security firmware's side of the equation. i915 is the entity that needs ensure the sessions' state across both iGT and security firmware are at a known clean point when performing a full global teardown. Architecturally speaking, i915 should inspect all active sessions and submit the invalidate-stream-key PXP command to the security firmware for each of them. However, for the upstream i915 driver we only support the arbitration session that can be created so that will be the only session we will cleanup. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Juston Li <justonli@chromium.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-5-alan.previn.teres.alexis@intel.com Stable-dep-of: 69e6dd149212 ("drm/i915/pxp: limit drm-errors or warning on firmware API failures") Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpu: host1x: Fix memory leak of device namesYang Yingliang2023-05-111-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 55879dad0f3ae8468444b42f785ad79eac05fe5b ] The device names allocated by dev_set_name() need be freed before module unloading, but they can not be freed because the kobject's refcount which was set in device_initialize() has not be decreased to 0. As comment of device_add() says, if it fails, use only put_device() drop the refcount, then the name will be freed in kobejct_cleanup(). device_del() and put_device() can be replaced with device_unregister(), so call it to unregister the added successfully devices, and just call put_device() to the not added device. Add a release() function to device to avoid null release() function WARNING in device_release(), it's empty, because the context devices are freed together in host1x_memory_context_list_free(). Fixes: 8aa5bcb61612 ("gpu: host1x: Add context device management code") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-19 05:23:24 +0000