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: <0886f178-1935-4f37-8d0b-48274245f57e@bootlin.com>
Date: Mon, 29 Dec 2025 16:29:24 +0100
From: Louis Chauvet <louis.chauvet@...tlin.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Haneen Mohammed <hamohammed.sa@...il.com>, Simona Vetter <simona@...ll.ch>,
 Melissa Wen <melissa.srw@...il.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, jose.exposito89@...il.com,
 Jonathan Corbet <corbet@....net>
Cc: victoria@...tem76.com, sebastian.wick@...hat.com,
 thomas.petazzoni@...tlin.com, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 17/33] drm/vkms: Introduce config for plane format



On 12/23/25 14:58, Luca Ceresoli wrote:
> On Mon Dec 22, 2025 at 11:11 AM CET, Louis Chauvet wrote:
>> VKMS driver supports all the pixel formats for planes, but for testing it
>> can be useful to only advertise few of them. This new configuration
>> interface will allow configuring the pixel format per planes.
>>
>> Signed-off-by: Louis Chauvet <louis.chauvet@...tlin.com>
> 
>> --- a/drivers/gpu/drm/vkms/vkms_config.c
>> +++ b/drivers/gpu/drm/vkms/vkms_config.c
> 
>> +void vkms_config_plane_remove_all_formats(struct vkms_config_plane *plane_cfg)
>> +{
>> +	plane_cfg->supported_formats_count = 0;
> 
> Why not kfree(plane_cfg->supported_formats) too? You will be (re)allocating
> anyway if adding one or all formats later on, so the buffer you're not
> freeing won't be reused anyway.

IIRC realloc reuse the existing allocated buffer if it is big enough to fit the new
size. But I think this is probably an oversight here and I will add the free to clarify the situation :-)

>> +}
>> +
>> +void vkms_config_plane_remove_format(struct vkms_config_plane *plane_cfg, u32 drm_format)
>> +{
>> +	for (unsigned int i = 0; i < plane_cfg->supported_formats_count; i++) {
>> +		if (plane_cfg->supported_formats[i] == drm_format) {
>> +			plane_cfg->supported_formats[i] = plane_cfg->supported_formats[plane_cfg->supported_formats_count - 1];
> 
> I doubt these are less than 100 chars. ;-)

yes, 127, but I don't know how to format it so it is readable.

I tried

plane_cfg->supported_formats[i] =
	plane_cfg->supported_formats[plane_cfg->supported_formats_count - 1];

But the second line is 101 chars...

Checkpatch don't complain if I do:

plane_cfg->supported_formats[i] =
	plane_cfg->supported_formats[
		plane_cfg->supported_formats_count - 1];

or

plane_cfg->supported_formats[i] =
	plane_cfg->supported_formats[plane_cfg->supported_formats_count-
		1];

But that very ugly and not readable...

>> --- a/drivers/gpu/drm/vkms/vkms_config.h
>> +++ b/drivers/gpu/drm/vkms/vkms_config.h
>> @@ -49,6 +49,8 @@ struct vkms_config {
>>    * @supported_color_encodings: Color encodings that this plane will support
>>    * @default_color_range: Default color range that should be used by this plane
>>    * @supported_color_ranges: Color ranges that this plane will support
>> + * @supported_formats: List of supported formats
>> + * @supported_formats_count: Length of @supported_formats
> 
> Nitpick: this description is not adding much. "Number of elements in
> @supported_formats" would be more useful, as it would clarify it's number
> of (4-bytes) elements and not size in bytes.
> 
>> +int __must_check vkms_config_plane_add_format(struct vkms_config_plane *plane_cfg, u32 drm_format);
>> +
>> +/**
>> + * vkms_config_plane_add_all_formats - Helper to quickly add all the supported formats
>> + * @plane_cfg: Plane to add the formats to
>> + *
>> + * Returns: 0 on success, -ENOMEM if array allocation fails, -EINVAL if the format is not supported
>> + * by VKMS
> 
> The "-EINVAL ... VKMS" part of the sentence does not apply here.

True!

>> +/**
>> + * vkms_config_plane_remove_format - Remove a specific format from a plane
>> + * @plane_cfg: Plane to remove the format to
>                                               ^^ from
> 
> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ