Re: [PATCH] atafb: avoid cast when assigning buffer address pointer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] fbdev: incorrect sparse warning suppression via union alias
--

commit d3053bb9def82e951de5b1b68d5beb85bd502468
Author: Helge Deller <deller@gmx.de>

atafb: avoid cast when assigning buffer address pointer

This commit attempts to resolve a sparse warning about an __iomem address
space cast by switching to the screen_buffer alias from the fb_info union.

Closes: https://lore.kernel.org/oe-kbuild-all/202609261313.kgFtkz2t-lkp@intel.com/

> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
> index 5c3e5861543a2..c32576cb17202 100644
> --- a/drivers/video/fbdev/atafb.c
> +++ b/drivers/video/fbdev/atafb.c
> @@ -2454,7 +2454,7 @@ static void svblit_fillrect(struct fb_info *info,
>  		((u32 *)info->pseudo_palette)[rect->color] : rect->color;
>  
>  	/* draw the first line with the CPU ... */
> -	line = (u8 *)info->screen_base + rect->dy * pitch +
> +	line = info->screen_buffer + rect->dy * pitch +
>  	       rect->dx * bytespp;

[Severity: Low]
This isn't a runtime bug, but does this improperly suppress the sparse warning
by type-punning through the union alias?

By switching to screen_buffer in svblit_fillrect(), the code bypasses the
__iomem static analysis checks without making the memory access structurally
correct. 

Shouldn't this use an explicit (__force) cast or proper I/O accessors rather
than hiding the access through a non-__iomem union member?

>  	switch (bytespp) {
>  	case 1:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929061223.55435-1-deller@gmx.de?part=1