Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] `smem_start` is incorrectly populated with a virtual address instead of a physical address, which breaks user-space mmap. -- --- Patch [3]: [PATCH 03/03] fbdev: maxine: fix 64-bit build error --- commit 4b24e26365b585612a868800c1d954fcade38bb4 Author: Randy Dunlap <[email protected]> fbdev: maxine: fix 64-bit build error This commit resolves a 64-bit build error in the maxinefb driver by replacing the KSEG1ADDR() macro, which is only defined for non-64BIT builds, with the CKSEG1ADDR() macro. > diff --git a/include/video/maxinefb.h b/include/video/maxinefb.h > index 6aeb4acca2bdb..2b66b32f355cf 100644 > --- a/include/video/maxinefb.h > +++ b/include/video/maxinefb.h [ ... ] > @@ -19,7 +19,7 @@ > /* > * Begin of DECstation 5000/xx onboard framebuffer memory, default resolution > * is 1024x768x8 > */ > -#define DS5000_xx_ONBOARD_FBMEM_START KSEG1ADDR(0x0a000000) > +#define DS5000_xx_ONBOARD_FBMEM_START CKSEG1ADDR(0x0a000000) [Severity: High] This is a pre-existing issue, but does assigning this virtual address to the framebuffer's fix.smem_start break user-space mmap? When user-space applications call mmap() on the framebuffer device, fb_mmap calculates the physical frame number by shifting info->fix.smem_start. Since this macro defines a virtual CKSEG1 address instead of a physical address (0x0a000000), the resulting physical frame number maps to invalid physical memory space. Looking at drivers/video/fbdev/maxinefb.c in maxinefb_init(): fb_start = DS5000_xx_ONBOARD_FBMEM_START; ... maxinefb_fix.smem_start = fb_start; Should smem_start be populated with the actual physical address rather than the CKSEG1-mapped virtual address to prevent bus errors or unintended physical memory access during user-space mappings? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
