The .force() connector callback is invoked by
drm_helper_probe_single_connector_modes() while the modeset acquire
context it created is live, but the hook signature provides no way to
pass it down, e.g. to support implementations needing to lock further
objects.
Add a .force_ctx() variant to drm_connector_helper_funcs, taking the
acquire context and returning an error code, so that -EDEADLK propagates
into the existing retry path. When provided, it takes precedence over
drm_connector_funcs' .force(), which is kept for existing users.
This is a prerequisite for SCDC status synchronization in the HDMI
connector framework.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-6-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Switch drm_bridge_connector to the new drmm_connector_hdmi_init()
signature. The vendor, product, supported_formats and max_bpc values
now live in struct drm_connector_hdmi_funcs instead of being passed as
separate arguments. This allows future HDMI 2.x capabilities to be
plumbed without growing the function's argument list.
Introduce the supported_hdmi_ver field in struct drm_bridge to let
bridges declare the HDMI specification version they comply with,
as well as max_tmds_char_rate to allow them to override the limit
inferred from that version. This is particularly useful when handling
chip variants with different capabilities.
Additionally, add a warning in drm_bridge_add() if an HDMI bridge leaves
supported_hdmi_ver unset. This alerts bridge drivers setting the
DRM_BRIDGE_OP_HDMI flag that they must also declare their supported HDMI
version.
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-5-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
In preparation for providing HDMI 2.x source capabilities, move the
vendor, product, supported_formats and max_bpc parameters out of the
init function into struct drm_connector_hdmi_funcs, and add new
supported_hdmi_ver and supported_tmds_char_rate fields there as well.
Appending more HDMI-specific arguments to that function would not scale
well, hence introduce drmm_connector_hdmi_init() with the reduced
signature.
Additionally, add the max_tmds_char_rate field to struct
drm_connector_hdmi and use the supported HDMI version to determinate the
maximum TMDS character rate allowed by the specification. Some
controllers, however, may support a lower rate than that version would
imply. A non-zero supported_tmds_char_rate lets drivers override this
default with the actual controller capability. A value of zero keeps
the limit inferred from supported_hdmi_ver.
Callers are converted in the following patches, while the old and now
renamed *_ini2() helper is removed at the end of the series.
No functional changes expected for existing callers.
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-4-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
In preparation for changing the signature of drmm_connector_hdmi_init(),
i.e. dropping the vendor, product, supported_formats and max_bpc
arguments, which are being moved into struct drm_connector_hdmi_funcs,
temporarily rename the helper to drmm_connector_hdmi_ini2().
This lets the new signature be introduced under the original name while
callers are converted incrementally. The final patch removes *_ini2()
once no callers remain.
This is a mechanical, same-length rename performed with sed:
$ git grep -l 'drmm_connector_hdmi_init' -- '*.[ch]' \
| xargs sed -i 's/drmm_connector_hdmi_init/drmm_connector_hdmi_ini2/g'
The transitional name matches the original's length so continuation-line
arguments stay aligned to the opening parenthesis, keeping the diff to
the identifier itself and avoiding re-alignment churn here and in the
later conversions.
No functional change intended.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS, Rock 5B
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-3-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
In drmm_connector_hdmi_init(), if the reset callback fails to allocate
memory, e.g. inside drm_atomic_helper_connector_reset(),
connector->state will remain NULL. This is unconditionally passed to
drm_connector_attach_max_bpc_property(), leading to a NULL pointer
dereference.
Bail out with -ENOMEM if the reset callback leaves connector->state
unset.
Fixes: aadb3e16b8 ("drm/connector: hdmi: Add output BPC to the connector state")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260723015306.C94241F000E9@smtp.kernel.org/
Link: https://lore.kernel.org/all/20260723015306.C94241F000E9@smtp.kernel.org/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-2-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Add an enum to represent HDMI specification versions. This will be used
by upcoming changes to associate HDMI connectors and bridges with a
maximum supported version and to simplify handling of version-dependent
features.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-1-bc12954a0688@collabora.com
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
The PM block exposes a reset line for the V3D block, which the vc4 driver
uses to reset the GPU when recovering from a hang instead of forcing its
power domain down. Wire it up in the shared V3D node, covering BCM2835,
BCM2836 and BCM2837.
BCM2711 already describes the same reset line for its V3D node.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Link: https://patch.msgid.link/20260915-vc4-reset-control-v2-4-cb3a25b07822@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
vc4_reset() recovers a hung GPU by dropping the runtime PM usage count to
zero so that the power domain goes down, and then taking it again. Such an
unconventional approach only works if the driver knows exactly how many
references it holds, which is why vc4 wrapped every pm_runtime_get_sync()
call in a private refcount and mutex.
Commit 670c672608 ("soc: bcm: bcm2835-pm: Add support for power domains
under a new binding.") exposed a V3D reset line for exactly this reason,
so that the block can be reset without power-cycling its domain, but the
vc4 driver never picked it up. Use it now, which removes the need for the
private refcount and leaves vc4_v3d_pm_get/put() as plain runtime PM
wrappers.
The reset line is optional, to accommodate older device trees. Device
trees that do not describe one still get the driver-side recovery in
vc4_irq_reset(), but the hardware is left untouched. Two in-tree platforms
use the VC4 V3D block: BCM2835 gains the resets property in the next
commit, and Cygnus is no worse off than it was, as its V3D node has no
power domain and the power-cycle only ever gated its clock.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260915-vc4-reset-control-v2-3-cb3a25b07822@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
The BCM2835 power management block drives a reset line for the V3D block
that is independent of the graphics power domain, allowing the GPU to be
reset without power-cycling the domain. Expose this reset line in the V3D
binding.
Keep the property optional, as devices like the Broadcom Cygnus don't have
a reset line.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-vc4-reset-control-v2-2-cb3a25b07822@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
"brcm,vc4-v3d" is the compatible string V3D support originally shipped
with in commit d3f5168a08 ("drm/vc4: Bind and initialize the V3D
engine."). Commit 90d7116061 ("drm/vc4: Recognize a more specific
compatible string for V3D.") added "brcm,bcm2835-v3d" in v4.6 and kept
the original one around, because the Raspberry Pi firmware was shipping
device trees that used it.
That string was never part of the binding: the documentation added in
commit 4653f22e9a ("dt-bindings: Add binding docs for V3D.") describes
only "brcm,bcm2835-v3d", and no upstream device tree has ever used
"brcm,vc4-v3d": the first in-tree V3D node, from commit 49ac67e0c3
("ARM: bcm2835: Add VC4 to the device tree."), already carried the
specific name. The firmware device trees the compatible was kept for
predate v4.6, released in 2016.
Drop it from both match tables.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-vc4-reset-control-v2-1-cb3a25b07822@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260801191002.1383835-8-Julia.Lawall@inria.fr
amdxdna_drm_sync_bo_ioctl() calls amdxdna_hwctx_sync_debug_bo() for every
FROM_DEVICE sync, which answers -EINVAL when the BO's assigned_hwctx names
no context. Only a BO attached with ATTACH_DEBUG_BO is ever given one, so
an ordinary read-back sync reports failure after its flush has already run.
Ask for the debug sync only when the BO has a context. An unattached BO
carries AMDXDNA_INVALID_CTX_HANDLE and hwctx ids are allocated above it, so
the test is exact, -EINVAL keeps meaning that the named context is gone,
and the handle is not resolved twice. The field is written under dev_lock
and read here without it; the context is still resolved under that lock, so
a racing attach only decides whether this sync sees the buffer.
Fixes: 7ea0468380 ("accel/amdxdna: Support firmware debug buffer")
Suggested-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260819224458.257346-6-taimuraz@kaitmazov.com
amdxdna_drm_sync_bo_ioctl() answers a failed amdxdna_flush_bo() with
drm_WARN(). Both of that function's error returns are decided by the
ioctl's arguments, so SYNC_BO with an offset past the end of the BO
splats and taints the kernel from an unprivileged caller.
Log it at debug level, since the same caller can repeat it.
Fixes: dbc8fd7a03 ("accel/amdxdna: Add expandable device heap support")
Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260819224458.257346-4-taimuraz@kaitmazov.com
aie2_create_context() allocates a mailbox channel, starts it, and on a
failed start frees it again:
hwctx->priv->mbox_chann = xdna_mailbox_alloc_channel(ndev->mbox);
...
ret = xdna_mailbox_start_channel(hwctx->priv->mbox_chann, ...);
if (ret)
goto free_channel;
...
free_channel:
xdna_mailbox_free_channel(hwctx->priv->mbox_chann);
hwctx->priv->mbox_chann keeps pointing at the freed channel. That
pointer is the driver's own test for whether a hardware context has a
usable channel: aie2_destroy_context() returns early on NULL,
aie2_sched_job_run() refuses to run a job on NULL, and the message
helpers return -ENODEV on NULL. A stale pointer passes all of them.
It matters on the restart path. aie2_hwctx_restart() calls
aie2_create_context() again on a hardware context that is already live,
after aie2_hwctx_stop() has torn its channel down, and the context
survives a failure there: aie2_sched_job_timedout() discards the return
value entirely, and aie2_hwctx_resume() only propagates it. What is
left is a live hardware context holding a freed channel, and every
later user of it takes the non-NULL branch:
- the next job submitted reaches xdna_mailbox_send_msg() on the freed
channel, via the !mbox_chann guard in aie2_sched_job_run(),
- a second command timeout reaches aie2_hwctx_stop() ->
aie2_destroy_context(),
- closing the device reaches aie2_hwctx_fini() ->
aie2_release_resource() -> xrs_release_resource() ->
aie2_xrs_unload() -> aie2_destroy_context(),
and aie2_destroy_context() then calls xdna_mailbox_stop_channel()
followed by xdna_mailbox_free_channel() on memory that was already
freed: a use-after-free, and a second free of the same channel.
The AIE4 management channel already does this correctly -
aie4_mailbox_start() clears ndev->aie.mgmt_chann right after freeing
it. Do the same here.
The create path itself is not affected: when aie2_xrs_load() fails,
xrs_allocate_resource() removes the solver node without calling
->unload, and aie2_hwctx_init() frees hwctx->priv, so the stale pointer
never outlives the structure holding it.
Starting a channel can fail today without this patch: the ring buffer
sizes firmware reports are rejected unless both are powers of two, and
request_irq() can fail.
Fixes: d5b8b0347f ("accel/amdxdna: Split mailbox channel create function")
Cc: stable@vger.kernel.org
Signed-off-by: Eva Crystal <0xiviel@gmail.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/2fcf0eca215090dbbd95cb86e1bf5076056d3818.1789334558.git.0xiviel@gmail.com
When aie2_populate_range() faults in pages, it only sets
HMM_PFN_REQ_FAULT. Without HMM_PFN_REQ_WRITE, handle_mm_fault() does not
request write permissions and may populate the CPU page tables with
read-only PTEs.
Check the VMA flags and set HMM_PFN_REQ_WRITE when the VMA has VM_WRITE.
Fixes: e486147c91 ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260917171952.1883974-1-lizhi.hou@amd.com
A userspace process can concurrently trigger an unmap, which queues
hmm_unreg_work, and free BO. If amdxdna_hmm_unreg_work() executes
list_del(&mapp->node) and is preempted before calling amdxdna_umap_put(),
amdxdna_hmm_unregister_all() can fail to find the mapping in the list
and return without calling cancel_work_sync(). This allows object
destruction to proceed while the worker still holds a pointer to the BO
in the umap structure.
Moving the work item from struct amdxdna_umap to struct amdxdna_gem_obj.
The worker no longer holds a pointer to an individual mapping, so there
is no longer a window where the umap has been unlinked from umap_list but
work is still pending against it. The work item now lives in the BO
itself, so use a single cancel_work_sync() in the free path to drain the
work.
Fixes: 445d209104 ("accel/amdxdna: Fix unexpected wait when flushing notifier_wq")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260917154824.1872220-1-lizhi.hou@amd.com
The map structure is currently only partially initialized when the
notifier is registered. Although holding mmap_write_lock() prevents
the notifier callback from running before the remaining initialization
is complete, the ordering can be confusing during code review.
Fully initialize the map structure before registering the notifier so
that the structure is completely constructed before it is published.
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260911163907.1193852-1-lizhi.hou@amd.com
Analogous to what was added in Commit d41c79838c ("drm/panfrost:
Display list of device JM contexts over debugfs") for panfrost, add
similar debugfs information for panthor.
The group priority does not change over the lifetime of the group, so no
effort to synchronise with the scheduler lock is being made.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260904-panthor-sched-group-prio-v3-1-678afcca08b8@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Use the vdev->timeout structure for register poll timeouts. This allows
adjusting those timeouts depending on the platform type.
For FPGA set MMU timeouts to 10x.
Register poll timeouts are expressed in microseconds and are passed to
read_poll_timeout(), which disables a timeout when it is 0, unlike the
millisecond timeouts that are disabled with a negative value.
Also initialize state_dump_msg in the IVPU_TEST_MODE_DISABLE_TIMEOUTS
branch, which was missed when the field was added. Unlike the other
fields, it is a fixed delay passed to msleep() rather than a timeout, so
it has to keep a finite value. It is only reachable with this debug test
mode enabled, so there is no need for backporting.
Signed-off-by: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com>
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260915083651.950890-1-karol.wachowski@linux.intel.com
Acquire pm->reset_lock in ivpu_context_abort_work_fn() to prevent it
from running concurrently with a device reset. If the lock cannot be
acquired immediately, skip the abort work to avoid racing with reset.
The device power management is disabled during reset.
Signed-off-by: Jozef Wludzik <jozef.wludzik@intel.com>
Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260914083006.892645-1-karol.wachowski@linux.intel.com
Fix dependency of the panic-helper KUnit tests on CONFIG_DRM_KUNIT_TEST=y
and make them build as a module. Export the necessary interfaces from the
panic helpers iff the KUnit framework has been enabled.
Select DRM_PANIC_HELPER from DRM_KUNIT_TEST to meet the dependencies of
the panic-helper tests.
It is now possible to run the tests by modprobe-ing drm_panic_helper_test
at runtime.
v5:
- clear test description with drm_panic_helper_clear_description() (Sashiko)
v3:
- clean up after each test case (Sashiko)
v2:
- fix parameter order in decl of drm_panic_helper_draw_screen_qr()
(Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-15-tzimmermann@suse.de
Move drm_plane_helper_display_panic_screen() and the existing panic-
display code into drm_panic_helper.c. Rename symbols accordingly.
Also update the QR-related code and the bindings accordingly.
Link the rsp. object file into drm_kms_helper.ko. Eventually the code
will become a DRM drawing library, together with DRM's format and draw
helpers. This requires more preparation. until then, KMS helpers serve
as a module. All DRM drivers link it anyway.
Add a new section about drawing helpers to the documentation of the KMS
helpers. List format and panic helpers there.
v2:
- fix dependencies on other DRM modules (Randy, Sashiko)
- provide placeholders for drm_panic_helper_{init,exit}() (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-14-tzimmermann@suse.de
None of the DRM drivers handles panic locking. Declare the interfaces
in an internal header file. Move the trylock required during the panic
into the DRM core's sources.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-13-tzimmermann@suse.de
Add display_panic_screen to struct drm_plane_funcs. If set on a plane,
register a panic handler for the plane from the DRM core's panic
handling. Invoke this helper from the core to display a panic screen.
The new callback replaces get_scanout_buffer as signal for panic
support in a plane. Using get_scanout_buffer is now merely a detail
of the implementation. This will also free struct drm_scanout_buffer
for use cases besides panic handling.
With display_panic_screen in place, rename draw_panic_plane() to
drm_plane_helper_display_panic_screen() and make it available to DRM
drivers via drm_panic_helper.h. Do not change the implementation or
functionality of this code. drm_plane_helper_display_panic_screen()
still supports kernel messages, user messages and QR codes on various
color formats.
Then update all drivers that implement panic support. Provide the
initializer macro DRM_PANIC_PLANE_FUNCS that sets display_panic_screen
to drm_plane_helper_display_panic_screen(). If panic handling has
been disabled, it instead clears the callback. There's again no change
in functionality.
This logically splits panic handling into a set of entry points in the
DRM code and a set of helper functions provided by drivers. The core
invokes the driver's helper via callback, while the driver can tailor
the implementation to its needs. Panic handling now works like most
other interfaces in the DRM framework.
Locking and state-handling happens in the DRM core or helpers. Drivers
that receive a call to display_panic_screen can assume that no concurrent
modeset takes place on the plane or its CRTC.
Also update the documentation. Move information about locking and state
guarantees from drm_panic_trylock() to display_panic_screen, where
drivers authors can find it easily. Move information about the features
of the current implementation to drm_panic_helper_display_panic_screen().
v4:
- remove obsolete comment about fbcon interference (Jocelyn)
v2:
- only consider planes with get_scanout_buffer (Sashiko)
- set callback for planes create with drm_crtc_init() (Sashiko)
- return errno code from display_panic_screen
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-12-tzimmermann@suse.de
Restrict panic handling to primary displays. Overlays and cursors
should not display panic output. If there are exceptions, they can
be registered by the driver itself.
v3:
- also update drm_panic_is_enabled() (Sashiko)
- still do some testing when unregistering (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-11-tzimmermann@suse.de
Move locking and parameters from draw_panic_plane() into the new
helper drm_panic_display_panic_screen(). Call draw_panic_plane() from
there.
The new helper drm_panic_display_panic_screen() is now the DRM core's
interface for displaying a panic screen. The code remaining in
draw_panic_plane() still does all the heavy lifting. It will become a
plane helper for DRM drivers.
v2:
- use panic_type argument in draw_panic_plane() (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-10-tzimmermann@suse.de
On failed output of QR codes and kmsg buffers, fall back to a user
message. QR-code output already did this internally, but now formally
support it in drm_panic_dispatch(). Streamlines the existing logic.
With the implicit fallback removed from QR-code support, the tests
cases fail for thr smallest output size (300x200). This is because the
QR code requires a minimal output size. Increase the size to 494x494,
which is the minimum supported size for QR output.
v3:
- update outdated commit description (Sashiko)
v2:
- fix minimum test size (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-9-tzimmermann@suse.de
Return an error if the display is too small to display at least a
single character. If the panic handler cannot display any message
it does at least not destroy the current output, which might help
with identifying the problem.
v4:
- also check font height against scanout buffer (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-8-tzimmermann@suse.de
Set the panic type and QR version in draw_panic_plane() as a single
point of truth. Pass the values into the individual drawing functions.
In the test case, always create a QR code with version 40 (i.e., the
highest supported version).
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-7-tzimmermann@suse.de
Set the panic-screen colors in draw_panic_plane() as a single point
of truth. Pass the values into the individual drawing functions.
In the test cases, replace the Kconfig-defined colors with white and
black. Allows for removal of the tests' limitations and dependency on
the exact values. All tests now always verify the generated output.
Hardcoding the test colors will later also allow for building the
test case without having DRM panic handling enabled.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-6-tzimmermann@suse.de
Return errno codes from the panic output helpers to detect invalid
panic handling. Avoid flushing the display if an error ocured. The
unflushed display output might be helpful in debugging.
For now, test the result values in the panic test cases. A later patch
will add support for retrying failed panic output.
v2:
- forward return value of draw_panic_screen_user() (Sashiko)
- forward errno code from drm_panic_get_qr_code
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-5-tzimmermann@suse.de
Font lookup does not allocate memory. Hence reporting ENOMEM on
failed lookups is misleading. Report EINVAL instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-4-tzimmermann@suse.de
Do nothing if kmap_local_page_try_from_panic() returns NULL. This is
not likely to hapen, as the previous page from the same memory area
has been mapped successfully.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 23437509a6 ("drm/panic: Fix 24bit pixel crossing page boundaries")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.18+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-3-tzimmermann@suse.de
Replace the direct use of DRM_PANIC_SCREEN_QR_CODE_URL in snprintf()
with a %s conversion specifier. Avoids a possible vulnerabilty from
a crafted URL string.
As the attacker needs to control the kernel at the Kconfig level, the
potential for an exploit is likely low.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Fixes: cb5164ac43 ("drm/panic: Add a QR code panic screen")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.12+
Link: https://patch.msgid.link/20260911124540.279841-2-tzimmermann@suse.de
All plane drivers now implement the atomic_create_state hook instead of
the reset hook for initial state creation. The reset hook conflated
initial state allocation at probe time with hardware and software reset
during suspend/resume, making error handling difficult since it is not
fallible.
Remove the reset hook from struct drm_plane_funcs and the associated
call in drm_mode_config_reset().
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-9-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The xen plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-6-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tve200 plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-5-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The pl111 plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-4-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The mcde plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-3-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The aspeed plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-2-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The arcgpu plane implementation uses the deprecated
drm_atomic_helper_plane_reset() as its reset hook.
Switch to drm_atomic_helper_plane_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260916-drm-no-more-plane-reset-v5-1-f590d2003f2c@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
All crtc drivers now implement the atomic_create_state hook instead of
the reset hook for initial state creation. The reset hook conflated
initial state allocation at probe time with hardware and software reset
during suspend/resume, making error handling difficult since it is not
fallible.
Remove the reset hook from struct drm_crtc_funcs and the associated
call in drm_mode_config_reset().
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-11-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
All users of __drm_atomic_helper_crtc_reset() have been converted to use
__drm_atomic_helper_crtc_state_init() and atomic_create_state.
Remove the now unused helper.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-10-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
All users of drm_atomic_helper_crtc_reset() have been converted to
drm_atomic_helper_crtc_create_state().
Remove the now unused helper.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-9-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The xen crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook.
Switch to drm_atomic_helper_crtc_create_state() instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260915-drm-no-more-crtc-reset-v5-8-bda007735748@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
