From: sashiko-bot@kernel.org
To: "Louis Chauvet" <louis.chauvet@bootlin.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 25/38] drm/vkms: Introduce config for plane zpos property
Date: Sat, 27 Jun 2026 03:41:39 +0000 [thread overview]
Message-ID: <20260627034140.513991F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260627-vkms-all-config-v5-25-854aa0840926@bootlin.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The return values of `drm_plane_create_zpos_property()` and `drm_plane_create_zpos_immutable_property()` are ignored.
- [Low] Missing newline character `\n` at the end of the `drm_info` format string.
- [Low] Using signed format specifiers (`%d`) for unsigned integer variables in debugfs output.
--
commit 332270a595e6e9b34ad7075f21dc26e1c7579078
Author: Louis Chauvet <louis.chauvet@bootlin.com>
drm/vkms: Introduce config for plane zpos property
VKMS can render plane in any order. Introduce the appropriate
configuration.
> diff --git a/drivers/gpu/drm/vkms/vkms_config.c b/drivers/gpu/drm/vkms/vkms_config.c
> index c7de3e3073674..5bc8248f99353 100644
> --- a/drivers/gpu/drm/vkms/vkms_config.c
> +++ b/drivers/gpu/drm/vkms/vkms_config.c
[ ... ]
> @@ -429,6 +462,19 @@ bool vkms_config_is_valid(const struct vkms_config *config)
> "Both supported color encodings and color ranges must be set, or none\n");
> return false;
> }
> +
> + if (!vkms_config_valid_plane_zpos(config, plane_cfg))
> + return false;
> +
> + if (vkms_config_plane_get_zpos_enabled(plane_cfg))
> + has_zpos_enabled = true;
> + else
> + has_zpos_disabled = true;
> + }
> +
> + if (has_zpos_enabled && has_zpos_disabled) {
> + drm_info(dev, "In the same device, all planes must have zpos enabled or none of them");
[Severity: Low]
Is this missing a newline character? Log messages without a trailing \n
can cause formatting issues by buffering and attaching to the next message.
> + return false;
> }
>
> if (!valid_plane_number(config))
[ ... ]
> @@ -527,6 +573,16 @@ static int vkms_config_show(struct seq_file *m, void *data)
> show_formats(m, vkms_config_plane_get_supported_formats(plane_cfg),
> vkms_config_plane_get_supported_formats_count(plane_cfg));
> seq_puts(m, "\n");
> + seq_printf(m, "\tzpos_enabled=%s\n",
> + str_true_false(vkms_config_plane_get_zpos_enabled(plane_cfg)));
> + seq_printf(m, "\tzpos_mutable=%s\n",
> + str_true_false(vkms_config_plane_get_zpos_mutable(plane_cfg)));
> + seq_printf(m, "\tzpos_min=%d\n",
> + vkms_config_plane_get_zpos_min(plane_cfg));
> + seq_printf(m, "\tzpos_initial=%d\n",
> + vkms_config_plane_get_zpos_initial(plane_cfg));
> + seq_printf(m, "\tzpos_max=%d\n",
> + vkms_config_plane_get_zpos_max(plane_cfg));
[Severity: Low]
Should these use the %u format specifier instead of %d? The getter
functions (like vkms_config_plane_get_zpos_min) return unsigned int,
so %d might display large values as negative numbers.
> }
>
> vkms_config_for_each_crtc(vkmsdev->config, crtc_cfg) {
[ ... ]
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c
> index 6e767cdf81942..d600a6167042b 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
[ ... ]
> @@ -214,6 +214,17 @@ struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
>
> if (vkms_config_plane_get_default_pipeline(plane_cfg))
> vkms_initialize_colorops(&plane->base);
> + if (vkms_config_plane_get_zpos_enabled(plane_cfg)) {
> + if (vkms_config_plane_get_zpos_mutable(plane_cfg)) {
> + drm_plane_create_zpos_property(&plane->base,
> + vkms_config_plane_get_zpos_initial(plane_cfg),
> + vkms_config_plane_get_zpos_min(plane_cfg),
> + vkms_config_plane_get_zpos_max(plane_cfg));
> + } else {
> + drm_plane_create_zpos_immutable_property(&plane->base,
> + vkms_config_plane_get_zpos_initial(plane_cfg));
> + }
> + }
[Severity: Medium]
Is it safe to ignore the return values of drm_plane_create_zpos_property()
and drm_plane_create_zpos_immutable_property() here?
These functions can return -ENOMEM on allocation failure. If that happens,
the plane is partially initialized without the expected zpos property,
which might confuse userspace applications. Should we propagate the error
up through vkms_plane_init()?
>
> return plane;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260627-vkms-all-config-v5-0-854aa0840926@bootlin.com?part=25
next prev parent reply other threads:[~2026-06-27 3:41 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 3:30 [PATCH v5 00/38] VKMS: Introduce multiple configFS attributes Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 01/38] drm/drm_mode_config: Add helper to get plane type name Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 02/38] drm/blend: Get a rotation name from it's bitfield Louis Chauvet
2026-06-27 3:41 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 03/38] drm/drm_color_mgmt: Expose drm_get_color_encoding_name Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 04/38] drm/drm_color_mgmt: Expose drm_get_color_range_name Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 05/38] drm/connector: Export drm_get_colorspace_name Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 06/38] drm/drm_atomic_state_helper: Properly load default value for rotation Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 07/38] Documentation: ABI: vkms: Add current VKMS ABI documentation Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 08/38] drm/vkms: Add error handling in plane config creation Louis Chauvet
2026-06-27 3:41 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 09/38] drm/vkms: Simplify plane_release code Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 10/38] drm/vkms: Explicitly display plane type Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 11/38] drm/vkms: Use enabled/disabled instead of 1/0 for debug Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 12/38] drm/vkms: Explicitly display connector status Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 13/38] drm/vkms: Introduce config for plane name Louis Chauvet
2026-06-27 3:46 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 14/38] drm/vkms: Use plane folder name as " Louis Chauvet
2026-06-27 3:43 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 15/38] drm/vkms: Introduce config for plane rotation Louis Chauvet
2026-06-27 3:42 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 16/38] drm/vkms: Use DRM_ROTATION_FMT macros for rotation display Louis Chauvet
2026-06-27 3:39 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 17/38] drm/vkms: Introduce configfs for plane rotation Louis Chauvet
2026-06-27 3:46 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 18/38] drm/vkms: Introduce config for plane color encoding Louis Chauvet
2026-06-27 3:43 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 19/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:49 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 20/38] drm/vkms: Introduce config for plane color range Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 21/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:45 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 22/38] drm/vkms: Introduce config for plane format Louis Chauvet
2026-06-27 3:46 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 23/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:45 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 24/38] drm/vkms: Properly render plane using their zpos Louis Chauvet
2026-06-27 3:44 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 25/38] drm/vkms: Introduce config for plane zpos property Louis Chauvet
2026-06-27 3:41 ` sashiko-bot [this message]
2026-06-27 3:30 ` [PATCH v5 26/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:46 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 27/38] drm/vkms: Introduce config for connector type Louis Chauvet
2026-06-27 3:45 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 28/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:45 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 29/38] drm/vkms: Rename vkms_connector_init to vkms_connector_init_static Louis Chauvet
2026-06-27 3:30 ` [PATCH v5 30/38] drm/vkms: Introduce config for connector supported colorspace Louis Chauvet
2026-06-27 3:58 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 31/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:48 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 32/38] drm/vkms: Introduce config for connector EDID Louis Chauvet
2026-06-27 3:48 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 33/38] drm/vkms: Introduce configfs " Louis Chauvet
2026-06-27 3:50 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 34/38] drm/vkms: Store the enabled/disabled status for connector Louis Chauvet
2026-06-27 3:48 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 35/38] drm/vkms: Allow to hot-add connectors Louis Chauvet
2026-06-27 3:50 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 36/38] drm/vkms: Introduce configfs for dynamic connector creation Louis Chauvet
2026-06-27 3:55 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 37/38] drm/vkms: Add connector parent configuration in vkms_config Louis Chauvet
2026-06-27 3:57 ` sashiko-bot
2026-06-27 3:30 ` [PATCH v5 38/38] drm/vkms: Add ConfigFS interface for connector parent and port_id Louis Chauvet
2026-06-27 3:45 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260627034140.513991F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=louis.chauvet@bootlin.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.