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] [day] [month] [year] [list]
Message-ID: <d7e06f84-c555-4eb7-b781-b8444eedd625@gmail.com>
Date: Tue, 21 Oct 2025 10:44:12 +0100
From: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
To: Thomas Zimmermann <tzimmermann@...e.de>, lanzano.alex@...il.com,
 maarten.lankhorst@...ux.intel.com, mripard@...nel.org, airlied@...il.com,
 simona@...ll.ch
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 skhan@...uxfoundation.org, david.hunter.linux@...il.com, khalid@...nel.org,
 linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH] drm/tiny: Refactor framebuffer's size calculation

On 10/21/25 9:32 AM, Thomas Zimmermann wrote:
> Hi
> 
> Am 21.10.25 um 10:41 schrieb Mehdi Ben Hadj Khelifa:
>> On 10/21/25 7:51 AM, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 20.10.25 um 13:57 schrieb Mehdi Ben Hadj Khelifa:
>>>> Use drm_format_info_min_pitch() to calculate the framebuffer line pitch
>>>> instead of directly multiplying width and height. This aligns with DRM
>>>> helpers for determining per-line byte size and avoids manual 
>>>> assumptions
>>>> about bytes per pixel.
>>>>
>>>> Suggested-by: Thomas Zimmermann <tzimmermann@...e.de>
>>>> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
>>>> ---
>>>>   drivers/gpu/drm/tiny/repaper.c | 6 +++++-
>>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/ 
>>>> repaper.c
>>>> index 4824f863fdba..aeff49bc6ba7 100644
>>>> --- a/drivers/gpu/drm/tiny/repaper.c
>>>> +++ b/drivers/gpu/drm/tiny/repaper.c
>>>> @@ -517,6 +517,8 @@ static int repaper_fb_dirty(struct 
>>>> drm_framebuffer *fb, const struct iosys_map *
>>>>       unsigned int dst_pitch = 0;
>>>>       struct iosys_map dst;
>>>>       struct drm_rect clip;
>>>> +    const struct drm_format_info *info = fb->format;
>>>
>>> This is the wrong format. You're allocating the output buffer here, 
>>> but you're using the input format. IIUC the output format is 
>>> DRM_FORMAT_R1. The input is _XRGB8888.
>>>
>> Ah. Thanks for clarification.I thought since it had the same output 
>> format. I will send a v3 shortly.> Best regards
> 
> Maybe just don't do it. This is just churn with no clear goal.
> 
Okay,I will abort working on it.Though my goal was to remove the manual 
assumption that height is multiple of 8 and to align with other 
'correct' API used in other drm drivers as you suggested[1].

[1]:https://lore.kernel.org/all/cb0f0a36-0593-4d4c-8450-d086b9c99d87@suse.de/

Best Regards,
Mehdi Ben Hadj Khelifa> Best regards
> Thomas
> 
>>> Thomas
>>>
>>>> +    size_t pitch;
>>>>       int idx, ret = 0;
>>>>       u8 *buf = NULL;
>>>> @@ -534,7 +536,9 @@ static int repaper_fb_dirty(struct 
>>>> drm_framebuffer *fb, const struct iosys_map *
>>>>       DRM_DEBUG("Flushing [FB:%d] st=%ums\n", fb->base.id,
>>>>             epd->factored_stage_time);
>>>> -    buf = kmalloc(fb->width * fb->height / 8, GFP_KERNEL);
>>>> +    pitch = drm_format_info_min_pitch(info, 0, fb->width);
>>>> +
>>>> +    buf = kmalloc_array(fb->height, pitch, GFP_KERNEL);
>>>>       if (!buf) {
>>>>           ret = -ENOMEM;
>>>>           goto out_exit;
>>>
>>
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ