From: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
To: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de
Cc: airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org
Subject: follow-up: Clarification on color parameter in drm_draw_fill24 function
Date: Thu, 19 Dec 2024 15:55:13 +0530 [thread overview]
Message-ID: <Z2P0iY+EyIr7u7DM@HOME-PC> (raw)
In-Reply-To: <Z1rLpV+Rx7U0h2J/@HOME-PC>
On Thu, Dec 12, 2024 at 05:10:21PM +0530, Dheeraj Reddy Jonnalagadda wrote:
> Dear Maintainers,
>
> I am writing to seek clarification regarding the implementation of the
> drm_draw_fill24 function in the DRM subsystem. Specifically, Coverity has
> flagged (CID 1602416) the issue in the following line in drm/drm_draw.c
>
> --> iosys_map_wr(dmap, off + 2, u8, (color & 0x00FF0000) >> 16);
>
> I have some questions about handling of the color parameter in the function.
>
> The function currently accepts a u16 value as the color parameter and uses
> bitwise operations to extract the RGB components. However, the mask 0x00FF0000
> refers to bits 16–23, which are always zero for a u16 value. Therefore, the
> expression (color & 0x00FF0000) will always result in 0.
>
> Could you please confirm:
>
> 1. Is the truncation of 32-bit color value to 16 bits the intended behavior?
> 2. Alternatively, should the function be updated to accept 32-bit values
> as input as the function is called with 32 bit values elsewhere?
>
> Thank you for your time. Please let me know if further information or context
> is required.
>
> -Dheeraj
Dear Maintainers,
I am following up on my earlier query regarding the potential issue flagged by
Coverity (CID 1602416) in the drm_draw_fill24 function in drm/drm_draw.c.
Link to the Coverity issue:
https://scan7.scan.coverity.com/#/project-view/52348/11354?selectedIssue=1602416
The action field on Coverity has also been changed to "Fix required" for
this issue.
To summarize:
1. The color parameter is declared as a u16, but the bitwise operation
(color & 0x00FF0000) targets bits that do not exist within a u16
range, effectively always resulting in 0.
2. My query is whether this truncation is intentional or if the
function should be updated to accept a 32-bit color value, aligning
with its usage elsewhere.
I wanted to kindly ask if there has been any decision or additional insight
regarding this issue. If needed, I can provide a proposed patch to address the
problem once the intended behavior is clarified.
Thank you again for your time.
-Dheeraj
prev parent reply other threads:[~2024-12-20 8:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 11:40 Clarification on color parameter in drm_draw_fill24 function Dheeraj Reddy Jonnalagadda
2024-12-19 10:25 ` Dheeraj Reddy Jonnalagadda [this message]
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=Z2P0iY+EyIr7u7DM@HOME-PC \
--to=dheeraj.linuxdev@gmail.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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.