lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260206-angelic-crimson-bug-aaab40@houat>
Date: Fri, 6 Feb 2026 15:08:46 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>, 
	Rodrigo Siqueira <siqueira@...lia.com>, Alex Deucher <alexander.deucher@....com>, 
	Christian König <christian.koenig@....com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Sandy Huang <hjc@...k-chips.com>, 
	Heiko Stübner <heiko@...ech.de>, Andy Yan <andy.yan@...k-chips.com>, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, 
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin <tursulin@...ulin.net>, 
	Dmitry Baryshkov <lumag@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
	Rob Herring <robh@...nel.org>, Jonathan Corbet <corbet@....net>, kernel@...labora.com, 
	amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, linux-doc@...r.kernel.org, 
	Marius Vlad <marius.vlad@...labora.com>
Subject: Re: [PATCH v7 03/22] drm: Add enum conversions between
 DRM_COLOR_FORMAT and HDMI_COLORSPACE

On Wed, Jan 21, 2026 at 03:45:10PM +0100, Nicolas Frattaroli wrote:
> While the two enums have similar values, they're not identical, and
> HDMI's enum is defined as per the HDMI standard.
> 
> Add a simple conversion function from DRM to HDMI. Unexpected inputs
> aren't handled in any clever way, DRM_COLOR_FORMAT_AUTO and any other
> value that doesn't cleanly map to HDMI just gets returned as
> HDMI_COLORSPACE_RGB.
> 
> Add a second conversion function that gets a DRM_COLOR_FORMAT from an
> HDMI_COLORSPACE as well. In this case, reserved HDMI values that can't
> be converted will result in an -EINVAL return value.
> 
> Co-developed-by: Marius Vlad <marius.vlad@...labora.com>
> Signed-off-by: Marius Vlad <marius.vlad@...labora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> ---
>  include/drm/drm_connector.h | 54 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 54 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b5604dca728a..ffeb42f3b4a3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -2612,6 +2612,60 @@ int drm_connector_attach_color_format_property(struct drm_connector *connector);
>  
>  const char *drm_get_color_format_name(enum drm_color_format color_fmt);
>  
> +/**
> + * drm_color_format_to_hdmi_colorspace - convert DRM color format to HDMI
> + * @fmt: the &enum drm_color_format to convert
> + *
> + * Convert a given &enum drm_color_format to an equivalent
> + * &enum hdmi_colorspace. For non-representable values and
> + * %DRM_COLOR_FORMAT_AUTO, the value %HDMI_COLORSPACE_RGB is returned.
> + *
> + * Returns: the corresponding &enum hdmi_colorspace value
> + */
> +static inline enum hdmi_colorspace __pure
> +drm_color_format_to_hdmi_colorspace(enum drm_color_format fmt)
> +{
> +	switch (fmt) {
> +	default:
> +	case DRM_COLOR_FORMAT_AUTO:
> +	case DRM_COLOR_FORMAT_RGB444:
> +		return HDMI_COLORSPACE_RGB;

I don't think that's correct. What auto ends up as totally depends on
the atomic state it comes with.

At the very least, you should output a warning there, because that case
should never happen.

> +	case DRM_COLOR_FORMAT_YCBCR444:
> +		return HDMI_COLORSPACE_YUV444;
> +	case DRM_COLOR_FORMAT_YCBCR422:
> +		return HDMI_COLORSPACE_YUV422;
> +	case DRM_COLOR_FORMAT_YCBCR420:
> +		return HDMI_COLORSPACE_YUV420;
> +	}
> +}
> +
> +/**
> + * drm_color_format_from_hdmi_colorspace - convert HDMI color format to DRM
> + * @fmt: the &enum hdmi_colorspace to convert
> + *
> + * Convert a given &enum hdmi_colorspace to an equivalent
> + * &enum drm_color_format. For non-representable values,
> + * %-EINVAL is returned.
> + *
> + * Returns: the corresponding &enum drm_color_format value, or %-EINVAL
> + */
> +static inline enum drm_color_format __pure
> +drm_color_format_from_hdmi_colorspace(enum hdmi_colorspace fmt)
> +{
> +	switch (fmt) {
> +	default:
> +		return -EINVAL;

Wait, what?

-EINVAL is not a valid value for your enum.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ