- 18 Sep, 2023 2 commits
-
-
Imre Deak authored
Fix the NULL dereference leading to the following stack trace: [ 129.687181] i915 0000:00:02.0: [drm:drm_dp_add_payload_part1 [drm_display_helper]] VCPI 1 for port 000000005be4423e not in topology, not creating a payload to remote [ 129.687257] BUG: kernel NULL pointer dereference, address: 0000000000000560 [ 129.694276] #PF: supervisor read access in kernel mode [ 129.699459] #PF: error_code(0x0000) - not-present page [ 129.704612] PGD 0 P4D 0 [ 129.707178] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 129.711556] CPU: 2 PID: 1623 Comm: Xorg Tainted: G U 6.6.0-rc1-imre+ #985 [ 129.719744] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [ 129.732509] RIP: 0010:drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper] [ 129.740111] Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 87 60 05 00 00 44 8b 0f 48 8b 70 58 41 83 e9 01 48 85 f6 74 [ 129.758842] RSP: 0018:ffffc90001daf900 EFLAGS: 00010286 [ 129.764104] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 [ 129.771246] RDX: 0000000000000000 RSI: ffffffff9e73d613 RDI: 0000000000000000 [ 129.778394] RBP: ffffc90001daf930 R08: 0000000000000000 R09: 0000000000000020 [ 129.785533] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff888116c65e40 [ 129.792680] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 129.799822] FS: 00007f39f74b1a80(0000) GS:ffff88840f680000(0000) knlGS:0000000000000000 [ 129.807913] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 129.813670] CR2: 0000000000000560 CR3: 0000000138b88000 CR4: 0000000000750ee0 [ 129.820815] PKRU: 55555554 [ 129.823551] Call Trace: [ 129.826022] <TASK> [ 129.828154] ? show_regs+0x65/0x70 [ 129.831599] ? __die+0x24/0x70 [ 129.834683] ? page_fault_oops+0x160/0x480 [ 129.838824] ? dev_printk_emit+0x83/0xb0 [ 129.842797] ? do_user_addr_fault+0x2e2/0x680 [ 129.847175] ? exc_page_fault+0x78/0x180 [ 129.851143] ? asm_exc_page_fault+0x27/0x30 [ 129.855353] ? drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper] [ 129.862354] drm_dp_add_payload_part1+0x85/0x100 [drm_display_helper] [ 129.868832] intel_mst_pre_enable_dp+0x1ef/0x240 [i915] [ 129.874170] intel_encoders_pre_enable+0x83/0xa0 [i915] [ 129.879524] hsw_crtc_enable+0xbe/0x750 [i915] [ 129.884095] intel_enable_crtc+0x68/0xa0 [i915] [ 129.888752] skl_commit_modeset_enables+0x2c4/0x5d0 [i915] [ 129.894365] intel_atomic_commit_tail+0x765/0x1070 [i915] [ 129.899885] intel_atomic_commit+0x3ba/0x400 [i915] [ 129.904892] drm_atomic_commit+0x96/0xd0 [drm] [ 129.909405] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 129.914698] drm_atomic_helper_set_config+0x7e/0xc0 [drm_kms_helper] [ 129.921102] drm_mode_setcrtc+0x5af/0x8d0 [drm] [ 129.925695] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] [ 129.930810] drm_ioctl_kernel+0xc4/0x170 [drm] [ 129.935317] drm_ioctl+0x2a4/0x520 [drm] [ 129.939305] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm] [ 129.944415] ? __fget_light+0xa5/0x110 [ 129.948212] __x64_sys_ioctl+0x98/0xd0 [ 129.951985] do_syscall_64+0x37/0x90 [ 129.955581] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-1-imre.deak@intel.com
-
Jernej Skrabec authored
Add handling of arbitration lost event. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
- 15 Sep, 2023 8 commits
-
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. There is likely no bug in the current implementation due to the safeguard: | cname[sizeof(cname) - 1] = '\0'; ... however we can provide simpler and easier to understand code using the newer (and recommended) `strscpy` api. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
Justin Stitt authored
`strncpy` is deprecated and as such we should prefer more robust and less ambiguous string interfaces. A suitable replacement is `strscpy_pad` due to the fact that it guarantees NUL-termination on the destination buffer whilst also maintaining the NUL-padding behavior that `strncpy` provides. I am not sure whether NUL-padding is strictly needed but I see in `nvif_object_ctor()` args is memcpy'd elsewhere so I figured we'd keep the same functionality. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
baozhu.liu authored
When testing the d71 writeback layer function, the output format is set to NV12, and the following error message is displayed: [drm:komeda_fb_is_layer_supported] Layer TYPE: 4 doesn't support fb FMT: NV12 little-endian (0x3231564e) with modifier: 0x0.. Check the d71 data manual, writeback layer output formats includes NV12 format. Signed-off-by:
baozhu.liu <lucas.liu@siengine.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829093004.22860-1-lucas.liu@siengine.com
-
Jani Nikula authored
Clearly this should be under bridge chips. Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Acked-by:
-
Pranjal Ramajor Asha Kanojiya authored
Since drm_dev_alloc() is deprecated it is recommended to use devm_drm_dev_alloc() instead. Update the driver to start using devm_drm_dev_alloc(). Signed-off-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901161236.8371-1-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
As qaic drivers base device is connected to host via PCI framework, it makes sense to register in PCI framework at the beginning of module init. Signed-off-by:
-
Jani Nikula authored
The drm stack does not expect error valued pointers for EDID anywhere. Fixes: e6685650 ("drm: bridge: it66121: Set DDC preamble only once before reading EDID") Cc: Paul Cercueil <paul@crapouillou.net> Cc: Robert Foss <robert.foss@linaro.org> Cc: Phong LE <ple@baylibre.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131159.2472513-1-jani.nikula@intel.com
-
- 14 Sep, 2023 2 commits
-
-
Javier Martinez Canillas authored
The commit 45b58669 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") moved the allocation of the intermediate and HW buffers from the encoder's .atomic_enable callback, to the plane's .atomic_check callback. This was suggested by Maxime Ripard, because drivers aren't allowed to fail after the drm_atomic_helper_swap_state() function has been called. And the encoder's .atomic_enable happens after the new atomic state has been swapped, so allocations (that can fail) shouldn't be done there. But the HW buffer isn't really tied to the plane's state. It has a fixed size that only depends on the (also fixed) display resolution defined in the Device Tree Blob. That buffer can be considered part of the CRTC state, and for this reason makes more sense to do its allocation in the CRTC .atomic_check callback. The other allocated buffer (used to store a conversion from the emulated XR24 format to the native R1 format) is part of the plane's state, since it will be optional once the driver supports R1 and allows user-space to set that pixel format. So let's keep the allocation for it in the plane's .atomic_check callback, this can't be moved to the CRTC's .atomic_check because changing a format does not trigger a CRTC mode set. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icNxumZcZOPwT9Q_QiogNQ@mail.gmail.com/Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230913052938.1114651-1-javierm@redhat.com
-
Nathan Chancellor authored
When building without CONFIG_DEBUG_FS: drivers/gpu/drm/tegra/dc.c:1757:59: error: too many arguments to function call, expected 3, have 4 1757 | drm_debugfs_remove_files(dc->debugfs_files, count, root, minor); | ~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~ include/drm/drm_debugfs.h:162:19: note: 'drm_debugfs_remove_files' declared here 162 | static inline int drm_debugfs_remove_files(const struct drm_info_list *files, | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 163 | int count, struct drm_minor *minor) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Update the stub to include the root parameter. Fixes: 8e455145 ("drm/debugfs: rework drm_debugfs_create_files implementation v2") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913-fix-drm_debugfs_remove_files-stub-v1-1-6b952ac559f3@kernel.orgSigned-off-by:
-
- 13 Sep, 2023 8 commits
-
-
Nathan Chancellor authored
When building with clang, there is a warning (or error when CONFIG_WERROR is set): drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21: error: variable 'old_payload' is uninitialized when used here [-Werror,-Wuninitialized] 368 | new_payload, old_payload); | ^~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61: note: initialize the variable 'old_payload' to silence this warning 344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload; | ^ | = NULL 1 error generated. This variable is not required outside of this function so allocate old_payload on the stack and pass it by reference to dm_helpers_construct_old_payload(), resolving the warning. Closes: https://github.com/ClangBuiltLinux/linux/issues/1931 Fixes: 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") Reviewed-by:Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-v1-1-2d1b0a3ef16c@kernel.org
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Since this driver uses the component model and shutdown happens at the base driver, we communicate whether we have to call drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL. Suggested-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901164111.RFT.3.Iea742f06d8bec41598aa40378fc625fbd7e8a3d6@changeid
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by:Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Douglas Anderson authored
As with other places in the Linux kernel--kfree(NULL) being the most famous example--it's convenient to treat being passed a NULL argument as a noop in cleanup functions. Let's make drm_atomic_helper_shutdown() work like this. This is convenient for DRM devices that use the "component" model. On these devices we want shutdown to be a noop if the bind() call of the component hasn't been called yet. As long as drivers are careful to make sure the drvdata is NULL whenever the driver is not bound then we can just do a simple call to drm_atomic_helper_shutdown() with the drvdata at shutdown time. Acked-by:
-
Douglas Anderson authored
As per the discussion on the lists [1], changes to this driver generally flow through drm-misc. If they need to be coordinated with v4l2 they sometimes go through Philipp Zabel's tree instead. List both trees in MAINTAINERS. Also update the title of this driver to specify that it's just for IMX 5/6 since, as per Philipp "There are a lot more i.MX that do not use IPUv3 than those that do." [1] https://lore.kernel.org/r/d56dfb568711b4b932edc9601010feda020c2c22.camel@pengutronix.deAcked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. For the "otm8009a" driver we fully remove the storing of the "enabled" state and we remove the double-checking, but we still keep the storing of the "prepared" state since the backlight code in the driver checks it. This backlight code may not be perfectly safe since there doesn't appear to be sufficient synchronization between the backlight driver (which userspace can call into directly) and the code that's unpreparing the panel. However, this lack of safety is not new and can be addressed in a future patch. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. For the s6e63m0 panel driver, this actually fixes a subtle/minor error handling bug in s6e63m0_prepare(). In one error case s6e63m0_prepare() called s6e63m0_unprepare() directly if there was an error. This call to s6e63m0_unprepare() would have been a no-op since ctx->prepared wasn't set yet. Reviewed-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. This pile of panel drivers appears to be simple to handle. Based on code inspection they seemed to be using the prepared/enabled state simply for double-checking that nothing else in the kernel called them inconsistently. Now that the core drm_panel is doing the double checking (and warning) it should be very clear that these devices don't need their own double-check. Reviewed-by:
-
- 11 Sep, 2023 10 commits
-
-
Arunpravin Paneer Selvam authored
- Move roundup_power_of_two() to drm buddy file to support the new try harder mechanism for contiguous allocation. - Move trim function call to drm_buddy_alloc_blocks() function. Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230909160902.15644-2-Arunpravin.PaneerSelvam@amd.comReviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Arunpravin Paneer Selvam authored
- Move roundup_power_of_two() and IS_ALIGNED() computations to drm buddy file to support the new try harder mechanism for contiguous allocation. - Move trim function call to drm_buddy_alloc_blocks() function. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Problem statement: The current method roundup_power_of_two() to allocate contiguous address triggers -ENOSPC in some cases even though we have enough free spaces and so to help with that we introduce a try harder mechanism. In case of -ENOSPC, the new try harder mechanism rounddown the original size to power of 2 and iterating over the round down sized freelist blocks to allocate the required size traversing RHS and LHS. As part of the above new method implementation we moved contiguous/alignment size computation part and trim function to the drm buddy file. v2: Modify the alloc_range() function to return total allocated size on -ENOSPC err and traverse RHS/LHS to allocate the required size (Matthew). Signed-off-by: -
Thomas Zimmermann authored
Remove all unnecessary include statements from fbmem.c. Most of them were for functionality that has meanwhile been moved into other files. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
-
Thomas Zimmermann authored
Remove the two empty helpers for the case the CONFIG_FB_LOGO_EXTRA has not been set. They are internal functions and only called once. Providing empty replacements seems like overkill. Instead protect the call sites with a test for CONFIG_FB_LOGO_EXTRA. Signed-off-by:
-
Thomas Zimmermann authored
Move the fbdev function for displaying boot-up logos into their own file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has been selected. No functional changes. v2: * include fb_internal.h (kernel test robot) * simplify option-parsing ifdefs * build fb_logo.o iff CONFIG_LOGO has been set Signed-off-by:
-
Thomas Zimmermann authored
The interfaces for the fbdev logo are not used outside of the fbdev module. Hence declare the fbdev logo functions in the internal header file and remove their symbol exports. Only build the functions if CONFIG_LOGO has been selected. Signed-off-by:
-
Thomas Zimmermann authored
Fix a number of warnings from checkpatch.pl in this code before moving it into a separate file. This includes * Prefer 'unsigned int' to bare use of 'unsigned' * space required after that ',' (ctx:VxV) * space prohibited after that open parenthesis '(' * suspect code indent for conditional statements (16, 32) * braces {} are not necessary for single statement blocks No functional changes. Signed-off-by: -
Thomas Zimmermann authored
The fbcon module takes care of displaying the logo, if any. Remove the code form mmpfb. It is probably no tworking as expected, as it interferes with the framebuffer console. If we want to display the logo without fbcon, we should implement this in the fbdev core code. v2: * add a note on fbcon interference (Javier) Signed-off-by:
-
Thomas Zimmermann authored
The fbcon module takes care of displaying the logo, if any. Remove the code form au1200fb. If we want to display the logo without fbcon, we should implement this in the fbdev core code. Signed-off-by:
-
- 10 Sep, 2023 2 commits
-
-
Geert Uytterhoeven authored
The .need_pwm and .need_chargepump fields in struct ssd130x_deviceinfo are flags that can have only two possible values: 0 and 1. Reduce kernel size by changing their types from int to bool. Signed-off-by:
-
Geert Uytterhoeven authored
Due to the reuse of buffers, ssd130x_clear_screen() no longers clears the screen, but merely redraws the last image that is residing in the intermediate buffer. As there is no point in clearing the intermediate buffer and transposing an all-black image, fix this by just clearing the HW format buffer, and writing it to the panel. Fixes: 49d7d581 ("drm/ssd130x: Don't allocate buffers on each plane update") Signed-off-by:
-
- 09 Sep, 2023 7 commits
-
-
Uwe Kleine-König authored
struct pwm_device::pwm is a write-only variable in the pwm core and used nowhere apart from this and another dev_dbg. So it isn't useful to identify the used PWM. Emit the PWM's label instead in the debug message. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Uwe Kleine-König authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Uwe Kleine-König authored
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 the msm drm drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
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 the mediatek drm drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Uwe Kleine-König authored
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 authored
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 the ingenic drm drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
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 the ipuv3 imx drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
- 08 Sep, 2023 1 commit
-
-
Wayne Lin authored
[Why] Today, the allocation/deallocation steps and status is a bit unclear. For instance, payload->vc_start_slot = -1 stands for "the failure of updating DPCD payload ID table" and can also represent as "payload is not allocated yet". These two cases should be handled differently and hence better to distinguish them for better understanding. [How] Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and ALLOCATION_REMOTE to distinguish different allocation status. Adjust the code to handle different status accordingly for better understanding the sequence of payload allocation and payload removement. For payload creation, the procedure should look like this: DRM part 1: * step 1 - update sw mst mgr variables to add a new payload * step 2 - add payload at immediate DFP DPCD payload table Driver: * Add new payload in HW and sync up with DFP by sending ACT DRM Part 2: * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth along the virtual channel. And as for payload removement, the procedure should look like this: DRM part 1: * step 1 - Send ALLOCATE_PAYLOAD sideband message to release bandwidth along the virtual channel * step 2 - Clear payload allocation at immediate DFP DPCD payload table Driver: * Remove the payload in HW and sync up with DFP by sending ACT DRM part 2: * update sw mst mgr variables to remove the payload Note that it's fine to fail when communicate with the branch device connected at immediate downstrean-facing port, but updating variables of SW mst mgr and HW configuration should be conducted anyway. That's because it's under commit_tail and we need to complete the HW programming. Changes since v1: * Remove the set but not use variable 'old_payload' in function 'nv50_msto_prepare'. Catched by kernel test robot <lkp@intel.com> Signed-off-by:Wayne Lin <Wayne.Lin@amd.com> Signed-off-by:
-
