Re: [PATCH v3 13/13] Documentation/gpu: document the Vino driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Sleeping functions (GFP_KERNEL allocations and Mutex locks) are called from atomic KMS callbacks.
- [Low] Sphinx build warning due to title overline and underline being shorter than the title text.
--

commit fb3eb13f9dac446a54542b31ed570e00753ca4c1
Author: Mike Lothian <mike@fireburn.co.uk>

Documentation/gpu: document the Vino driver

Describe how a dock is identified and placed by family rather than by
product ID, what the driver implements in-kernel in place of EVDI and
DisplayLinkManager, and the module parameters an unfamiliar dock or a
converter with broken DDC may need.

> diff --git a/Documentation/gpu/vino.rst b/Documentation/gpu/vino.rst
> new file mode 100644
> index 0000000000000..98e82297a82a9
> --- /dev/null
> +++ b/Documentation/gpu/vino.rst
> @@ -0,0 +1,254 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +==========================
> +Vino DisplayLink DL3 driver
> +==========================

[Severity: Low]
Does this title formatting violate reStructuredText syntax requirements?

The overline and underline are 26 characters long, but the title text is 27
characters long, which can cause a Sphinx build warning.

[Severity: High]
Can these sleeping functions be called from an atomic context?

In read_cursor_bgra(), a GFP_KERNEL allocation is made, which can sleep:

drivers/gpu/drm/vino/drm_sink/scanout.rs:read_cursor_bgra() {
    ...
    out.resize(len, 0, GFP_KERNEL)?;
    ...
}

It appears this is called from the atomic VinoPlane::atomic_update callback.

Similarly, do these code paths acquire a sleepable kernel Mutex during atomic
contexts?

drivers/gpu/drm/vino/drm_sink/dispatch.rs:queue_scanout() {
    ...
    let pending = self.pending_scanout.lock();
    ...
    let mut pool = self.shadow[connector].lock();
    ...
}

This appears to be called in an atomic plane update context.

drivers/gpu/drm/vino/drm_sink/dispatch.rs:queue_cmd() {
    ...
    let mut pending = self.pending_kms.lock();
    ...
}

This seems to be called from the atomic_enable and atomic_disable callbacks.

drivers/gpu/drm/vino/drm_sink.rs:update_color() {
    ...
    let changed = if let Some(slot) = self.color.lock().get_mut(connector) {
    ...
}

This also appears to be called from VinoCrtc::atomic_enable and atomic_disable.

Calling sleeping functions like GFP_KERNEL allocations and Mutex locks from
atomic context can lead to might_sleep kernel warnings, system instability,
and deadlocks.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826163913.7052-1-mike@fireburn.co.uk?part=13