linux-kernel - Re: [PATCH v4 1/2] drm/format-helper: Add conversion from XRGB8888 to BGR888

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: <7D98DED5-5B18-4AAE-A347-C880232530B7@live.com>
Date: Mon, 24 Feb 2025 14:54:07 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
CC: "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"simona@...ll.ch" <simona@...ll.ch>, Kerem Karabay <kekrby@...il.com>,
	Atharva Tiwari <evepolonium@...il.com>, Aun-Ali Zaidi <admin@...eit.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v4 1/2] drm/format-helper: Add conversion from XRGB8888 to
 BGR888

This conversion helper mimics the existing drm_fb_xrgb8888_to_rgb888 helper

> On 24 Feb 2025, at 7:59 PM, andriy.shevchenko@...ux.intel.com wrote:
> 
> On Mon, Feb 24, 2025 at 01:38:32PM +0000, Aditya Garg wrote:
>> From: Kerem Karabay <kekrby@...il.com>
>> 
>> Add XRGB8888 emulation helper for devices that only support BGR888.
> 
> ...
> 
>> +static void drm_fb_xrgb8888_to_bgr888_line(void *dbuf, const void *sbuf, unsigned int pixels)
> 
> Okay the xrgb8888 is the actual pixel format independently on
> the CPU endianess.
> 
>> +{
>> + u8 *dbuf8 = dbuf;
>> + const __le32 *sbuf32 = sbuf;
> 
> But here we assume that sbuf is __le32.
> And I think we may benefit from the __be32 there.

So, like drm_fb_xrgb8888_to_rgb888, we are using __le32

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_format_helper.c?h=v6.14-rc4#n657


> 
>> + unsigned int x;
>> + u32 pix;
>> +
>> + for (x = 0; x < pixels; x++) {
>> + pix = le32_to_cpu(sbuf32[x]);
>> + /* write red-green-blue to output in little endianness */
>> + *dbuf8++ = (pix & 0x00ff0000) >> 16;
>> + *dbuf8++ = (pix & 0x0000ff00) >> 8;
>> + *dbuf8++ = (pix & 0x000000ff) >> 0;
> 
> pix = be32_to_cpu(sbuf[4 * x]) >> 8;
> put_unaligned_le24(pix, &dbuf[3 * x]);

Again, 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_format_helper.c?h=v6.14-rc4#n664
> 
>> + }
> 
> Or, after all, this __le32 magic might be not needed at all. Wouldn't the below
> be the equivalent
> 
> static void drm_fb_xrgb8888_to_bgr888_line(void *dbuf, const void *sbuf, unsigned int pixels)
> {
> unsigned int x;
> u32 pix;
> 
> for (x = 0; x < pixels; x++) {
> /* Read red-green-blue from input in big endianess and... */
> pix = get_unaligned_be24(sbuf + x * 4 + 1);
> /* ...write it to output in little endianness. */
> put_unaligned_le24(pix, dbuf + x * 3);
> }
> }
> 
> The comments can even be dropped as the code quite clear about what's going on.

These comments are literally rewritten :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_format_helper.c?h=v6.14-rc4#n663

> 
>> +}
> 
> But it's up to you. I don't know which solution gives better code generation
> either.

I don't really mind any code change tbh, but I’d prefer that as an improvement to existing code, and not a part of this patchset.