- 15 Apr, 2024 23 commits
-
-
Jocelyn Falempe authored
Add a debugfs file, so you can test drm_panic without freezing your machine. This is unsafe, and should be enabled only for developer or tester. To display the drm_panic screen on the device 0: echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0 v9: * Create a debugfs file for each plane in the device's debugfs directory. This allows to test for each plane of each GPU independently. Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163432.352518-5-jfalempe@redhat.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jocelyn Falempe authored
Add support for the following formats: DRM_FORMAT_RGB565 DRM_FORMAT_RGBA5551 DRM_FORMAT_XRGB1555 DRM_FORMAT_ARGB1555 DRM_FORMAT_RGB888 DRM_FORMAT_XRGB8888 DRM_FORMAT_ARGB8888 DRM_FORMAT_XBGR8888 DRM_FORMAT_XRGB2101010 DRM_FORMAT_ARGB2101010 v10: * move and simplify the functions from the drm format helper to drm_panic v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
This module displays a user friendly message when a kernel panic occurs. It currently doesn't contain any debug information, but that can be added later. v2 * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) * Add the panic reason to the panic message (Nerdopolis) * Add an exclamation mark (Nerdopolis) v3 * Rework the drawing functions, to write the pixels line by line and to use the drm conversion helper to support other formats. (Thomas Zimmermann) v4 * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann) * Remove the default y to DRM_PANIC config option (Thomas Zimmermann) * Add foreground/background color config option * Fix the bottom lines not painted if the framebuffer height is not a multiple of the font height. * Automatically register the device to drm_panic, if the function get_scanout_buffer exists. (Thomas Zimmermann) v5 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font. * Also add drm_fb_fill() to fill area with background color. * Add draw_pixel_xy() API for drivers that can't provide a linear buffer. * Add a flush() callback for drivers that needs to synchronize the buffer. * Add a void *private field, so drivers can pass private data to draw_pixel_xy() and flush(). v6 * Fix sparse warning for panic_msg and logo. v7 * Add select DRM_KMS_HELPER for the color conversion functions. v8 * Register directly each plane to the panic notifier (Sima) * Add raw_spinlock to properly handle concurrency (Sima) * Register plane instead of device, to avoid looping through plane list, and simplify code. * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) * Removed the draw_pixel_xy() API, will see later if it can be added back. v9 * Revert to using get_scanout_buffer() (Sima) * Move get_scanout_buffer() and panic_flush() to the plane helper functions (Thomas Zimmermann) * Register all planes with get_scanout_buffer() to the panic notifier * Use drm_panic_lock() to protect against race (Sima) v10 * Move blit and fill functions back in drm_panic (Thomas Zimmermann). * Simplify the text drawing functions. * Use kmsg_dumper instead of panic_notifier (Sima). v12 * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) * Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann) Signed-off-by:
-
Daniel Vetter authored
Rough sketch for the locking of drm panic printing code. The upshot of this approach is that we can pretty much entirely rely on the atomic commit flow, with the pair of raw_spin_lock/unlock providing any barriers we need, without having to create really big critical sections in code. This also avoids the need that drivers must explicitly update the panic handler state, which they might forget to do, or not do consistently, and then we blow up in the worst possible times. It is somewhat racy against a concurrent atomic update, and we might write into a buffer which the hardware will never display. But there's fundamentally no way to avoid that - if we do the panic state update explicitly after writing to the hardware, we might instead write to an old buffer that the user will barely ever see. Note that an rcu protected deference of plane->state would give us the the same guarantees, but it has the downside that we then need to protect the plane state freeing functions with call_rcu too. Which would very widely impact a lot of code and therefore doesn't seem worth the complexity compared to a raw spinlock with very tiny critical sections. Plus rcu cannot be used to protect access to peek/poke registers anyway, so we'd still need it for those cases. Peek/poke registers for vram access (or a gart pte reserved just for panic code) are also the reason I've gone with a per-device and not per-plane spinlock, since usually these things are global for the entire display. Going with per-plane locks would mean drivers for such hardware would need additional locks, which we don't want, since it deviates from the per-console takeoverlocks design. Longer term it might be useful if the panic notifiers grow a bit more structure than just the absolute bare EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console drivers with proper register/unregister interfaces we could perhaps reuse the very fancy console lock with all it's check and takeover semantics that John Ogness is developing to fix the console_lock mess. But for the initial cut of a drm panic printing support I don't think we need that, because the critical sections are extremely small and only happen once per display refresh. So generally just 60 tiny locked sections per second, which is nothing compared to a serial console running a 115kbaud doing really slow mmio writes for each byte. So for now the raw spintrylock in drm panic notifier callback should be good enough. Another benefit of making panic notifiers more like full blown consoles (that are used in panics only) would be that we get the two stage design, where first all the safe outputs are used. And then the dangerous takeover tricks are deployed (where for display drivers we also might try to intercept any in-flight display buffer flips, which if we race and misprogram fifos and watermarks can hang the memory controller on some hw). For context the actual implementation on the drm side is by Jocelyn and this patch is meant to be combined with the overall approach in v7 (v8 is a bit less flexible, which I think is the wrong direction): https://lore.kernel.org/dri-devel/20240104160301.185915-1-jfalempe@redhat.com/ Note that the locking is very much not correct there, hence this separate rfc. Starting from v10, I (Jocelyn) have included this patch in the drm_panic series, and done the corresponding changes. v2: - fix authorship, this was all my typing - some typo oopsies - link to the drm panic work by Jocelyn for context v10: - Use spinlock_irqsave/restore (John Ogness) v11: - Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness) Signed-off-by:
-
Jani Nikula authored
We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug printing of modes in any printk-formatted logging. Prefer them over drm_mode_debug_printmodeline(). This allows drm device specific logging of modes, in the right drm debug category, and inline with the rest of the logging instead of split to multiple lines. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/6df18588dfa17c5d0a1501f5af9ff21f25a1981b.1712568037.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
Prefer drm device based drm_dbg_kms(), drm_err(), drm_WARN_ON() over DRM_DEBUG_KMS(), DRM_ERROR(), and WARN_ON(). Also update encoder, connector, and crtc logging to include the object id and name, where possible. Reviewed-by:
-
Jani Nikula authored
Prefer drm device based drm_dbg_kms() over DRM_DEBUG_KMS(). Reviewed-by:
-
Jani Nikula authored
Switch to drm device based logging and WARNs, and unify connector and crtc logging formats. Pass drm device around a bit more to be able to do this. Drop logging for -ENOMEM. Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms() and drm_dbg_lease() over DRM_DEBUG_KMS() and DRM_DEBUG() to debug log the drm device info. Fix some debug categories and unify connector logging while at it. v2: Drop superfluous newline Reviewed-by:
-
Jani Nikula authored
Prefer drm_err() and drm_dbg_kms() over DRM_ERROR() and DRM_DEBUG_KMS(). Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms() over DRM_DEBUG_KMS() to debug log the drm device info. v2: Drop changes to mode printing (Ville) Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/8b6a83edd1c3896b9d652b5368702eba5f382a1c.1712568037.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Use a more suitable type to avoid the cast. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
-
Jani Nikula authored
To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch to the struct drm_edid based function to extract product id, and use the drm printer function to debug log it. The underlying assumption is that struct drm_edid_product_id and struct lvds_pnp_id describe identical data, albeit with slightly different member definitions. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Jani Nikula authored
Add a function to print a decoded EDID vendor and product id to a drm printer, optionally with the raw data. v2: - refactor date printing - use seq_buf to avoid kasprintf() (Ville) - handle week == 0 (Ville) - use be16_to_cpu() on manufacturer_name Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Melissa Wen <mwen@igalia.com> # v1 Reviewed-by:
-
Jani Nikula authored
Add a struct drm_edid based function to get the vendor and product ID from an EDID. Add a separate struct for defining this part of the EDID, with defined byte order for manufacturer name, product code and serial number. v2: Define manufacturer_name as __be16 instead of u8[2] (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Arnd Bergmann authored
After my fix yesterday, I ran into another problem of the same kind: aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_readb': analogix_dp_core.c:(.text+0x194): undefined reference to `drm_dp_dpcd_read' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_writeb': analogix_dp_core.c:(.text+0x214): undefined reference to `drm_dp_dpcd_write' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_stop_crc': analogix_dp_core.c:(.text+0x4b0): undefined reference to `drm_dp_stop_crc' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_start_crc': analogix_dp_core.c:(.text+0xbe8): undefined reference to `drm_dp_start_crc' Add the same dependency again to ROCKCHIP_ANALOGIX_DP after checking that nothing else selects the analogix driver. Also add a dependency to DRM_ANALOGIX_DP to make it easier to identifier future problems of this type when they get introduced. Fixes: 0323287d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Fixes: d1ef8fc1 ("drm: fix DRM_DISPLAY_DP_HELPER dependencies") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240405143531.925589-1-arnd@kernel.org
-
Aleksandr Mishin authored
In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Signed-off-by:
Aleksandr Mishin <amishin@t-argos.ru> Signed-off-by:
-
Sebastian Wick authored
When extending support for a driver-specific KMS property to additional drivers, we should apply all the requirements for new properties and make sure the semantics are the same and documented. v2: devs of the driver which introduced property shall help and ack Signed-off-by:
Sebastian Wick <sebastian.wick@redhat.com> Acked-by:
-
Erico Nunes authored
Create a simple data struct to hold compatible data so that we don't have to do the casts to void pointer to hold data. Fixes the following warning: drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer type 'enum lima_gpu_id' from 'const void *' Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240401224329.1228468-3-nunes.erico@gmail.com
-
Erico Nunes authored
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. Signed-off-by:
-
Erico Nunes authored
There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. Signed-off-by:
-
Erico Nunes authored
In commit 53cb55b2 ("drm/lima: handle spurious timeouts due to high irq latency") a check was added to detect an unexpectedly high interrupt latency timeout. With further investigation it was noted that on Mali-450 the pp bcast irq may also be a trigger of race conditions against the timeout handler, so add it to this check too. Signed-off-by:
-
Erico Nunes authored
This is needed because we want to reset those devices in device-agnostic code such as lima_sched. In particular, masking irqs will be useful before a hard reset to prevent race conditions. Signed-off-by:
-
- 12 Apr, 2024 3 commits
-
-
Arnd Bergmann authored
The alternative stub functions are listed as global, which produces a build failure in some configs: In file included from drivers/accel/qaic/qaic_drv.c:31: drivers/accel/qaic/qaic_debugfs.h:16:5: error: no previous prototype for 'qaic_bootlog_register' [-Werror=missing-prototypes] 16 | int qaic_bootlog_register(void) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~ drivers/accel/qaic/qaic_debugfs.h:17:6: error: no previous prototype for 'qaic_bootlog_unregister' [-Werror=missing-prototypes] 17 | void qaic_bootlog_unregister(void) {} | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/accel/qaic/qaic_debugfs.h:18:6: error: no previous prototype for 'qaic_debugfs_init' [-Werror=missing-prototypes] 18 | void qaic_debugfs_init(struct qaic_drm_device *qddev) {} | ^~~~~~~~~~~~~~~~~ Make them static inline as intended. Fixes: 5f8df5c6 ("accel/qaic: Add bootlog debugfs") Signed-off-by:Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
-
Jeffrey Hugo authored
The AIC100 secondary bootloader uses the Sahara protocol for two purposes - loading the runtime firmware images from the host, and offloading crashdumps to the host. The crashdump functionality is only invoked when the AIC100 device encounters a crash and dumps are enabled. Also the collection of the dump is optional - the host can reject collecting the dump. The Sahara protocol contains many features and modes including firmware upload, crashdump download, and client commands. For simplicity, implement the parts of the protocol needed for loading firmware to the device. Fundamentally, the Sahara protocol is an embedded file transfer protocol. Both sides negotiate a connection through a simple exchange of hello messages. After handshaking through a hello message, the device either sends a message requesting images, or a message advertising the memory dump available for the host. For image transfer, the remote device issues a read data request that provides an image (by ID), an offset, and a length. The host has an internal mapping of image IDs to filenames. The host is expected to access the image and transfer the requested chunk to the device. The device can issue additional read requests, or signal that it has consumed enough data from this image with an end of image message. The host confirms the end of image, and the device can proceed with another image by starting over with the hello exchange again. Some images may be optional, and only provided as part of a provisioning flow. The host is not aware of this information, and thus should report an error to the device when an image is not available. The device will evaluate if the image is required or not, and take the appropriate action. Signed-off-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322034917.3522388-1-quic_jhugo@quicinc.com
-
Huai-Yuan Liu authored
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf ("drm: mali-dp: Add writeback connector") Signed-off-by:
Huai-Yuan Liu <qq810974084@gmail.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq810974084@gmail.com
-
- 11 Apr, 2024 6 commits
-
-
Ville Syrjälä authored
Advertize more suitable cursor sizes via the new SIZE_HINTS plane property. We can't really enumerate all supported cursor sizes on the platforms where the cursor height can vary freely, so for simplicity we'll just expose all square+POT sizes between each platform's min and max cursor limits. Depending on the platform this will give us one of three results: - 64x64,128x128,256x256,512x512 - 64x64,128x128,256x256 - 64x64 Cc: Simon Ser <contact@emersion.fr> Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare a one size fits all limit for the whole device. Currently eg. amdgpu/i915/nouveau just advertize the max cursor size via the cursor size caps. But always using the max sized cursor can waste a surprising amount of power, so a better strategy is desirable. Most other drivers don't specify any cursor size at all, in which case the ioctl code just claims that 64x64 is a great choice. Whether that is actually true is debatable. A poll of various compositor developers informs us that blindly probing with setcursor/atomic ioctl to determine suitable cursor sizes is not acceptable, thus the introduction of the new property to supplant the cursor size caps. The compositor will now be free to select a more optimal cursor size from the short list of options. Note that the reported sizes (either via the property or the caps) make no claims about things such as plane scaling. So these things should only really be consulted for simple "cursor like" use cases. Userspace consumer in the form of mutter seems ready: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 v2: Try to add some docs v3: Specify that value 0 is reserved for future use (basic idea from Jonas) Drop the note about typical hardware (Pekka) v4: Update the docs to indicate the list is "in order of preference" Add a a link to the mutter MR v5: Limit to cursors only for now (Simon) Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Acked-by:
Daniel Stone <daniels@collabora.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
-
Jesse Zhang authored
remove the unsed the paramter in the function ttm_bo_bounce_temp_buffer and ttm_bo_add_move_fence. V2:rebase the patch on top of drm-misc-next (Christian) Signed-off-by:
Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240401030443.3384494-1-jesse.zhang@amd.comSigned-off-by:
-
Thomas Zimmermann authored
Move the definition of struct ast_ddc to ast_ddc.c and return the i2c adapter from ast_ddc_create(). Update callers accordingly. Avoids including Linux i2c header files, except where required. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Reorder the code to set up the DDC channel by data structure, so that each data structure's init is in a separate block: first the bit algo then the i2c adapter. Makes the code more readable. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Compute the i2c timeout in jiffies from a value in milliseconds. The original values of 2 jiffies equals 2 milliseconds if HZ has been configured to a value of 1000. This corresponds to 2.2 milliseconds used by most other DRM drivers. Update ast accordingly. Signed-off-by:
-
- 10 Apr, 2024 8 commits
-
-
Lyude Paul authored
I didn't pay close enough attention the last time I tried to fix this problem - while we currently do correctly take care to make sure we don't probe a connected eDP port more then once, we don't do the same thing for eDP ports we found to be disconnected. So, fix this and make sure we only ever probe eDP ports once and then leave them at that connector state forever (since without HPD, it's not going to change on its own anyway). This should get rid of the last few GSP errors getting spit out during runtime suspend and resume on some machines, as we tried to reprobe eDP ports in response to ACPI hotplug probe events. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404233736.7946-3-lyude@redhat.com
-
Lyude Paul authored
GSP has its own state for keeping track of whether or not a given display connector is plugged in or not, and enforces this state on the driver. In particular, AUX transactions on a DisplayPort connector which GSP says is disconnected can never succeed - and can in some cases even cause unexpected timeouts, which can trickle up to cause other problems. A good example of this is runtime power management: where we can actually get stuck trying to resume the GPU if a userspace application like fwupd tries accessing a drm_aux_dev for a disconnected port. This was an issue I hit a few times with my Slimbook Executive 16 - where trying to offload something to the discrete GPU would wake it up, and then potentially cause it to timeout as fwupd tried to immediately access the dp_aux_dev nodes for nouveau. Likewise: we don't really have any cases I know of where we'd want to ignore this state and try an aux transaction anyway - and failing pointless aux transactions immediately can even speed things up. So - let's start enabling/disabling the aux bus in nouveau_dp_detect() to fix this. We enable the aux bus during connector probing, and leave it enabled if we discover something is actually on the connector. Otherwise, we just shut it off. This should fix some people's runtime PM issues (like myself), and also get rid of quite of a lot of GSP error spam in dmesg. 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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). 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> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240304091005.717012-2-u.kleine-koenig@pengutronix.de
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Wolfram Sang authored
Since commit ab78029e ("drivers/pinctrl: grab default handles from device core"), we can rely on device core for setting the default pins. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230922073714.6164-1-wsa+renesas@sang-engineering.com
-
Krzysztof Kozlowski authored
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Dan Carpenter authored
Free "dp" before returning. Fixes: be318d01 ("drm: xlnx: dp: Reset DisplayPort IP") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Tomi Valkeinen authored
Add myself as a co-maintainer for Xilinx DRM drivers to help Laurent. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
