Re: [RFC PATCH] fbdev: maxinefb: fix build issues
Randy Dunlap <[email protected]>
| Newsgroups | gmane.linux.ports.mips,gmane.comp.video.dri.devel |
|---|---|
| Message-ID | <[email protected]> |
On 8/9/26 5:27 PM, Randy Dunlap wrote: > [adding Cc:s] > > On 8/9/26 5:02 PM, [email protected] wrote: >> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: >> >> Pre-existing issues: >> - [High] Initialization function returns positive value `1` on failure, breaking module load semantics and causing subsequent `registered_fb` array corruption on unload. >> - [High] `maxinefb_fix.smem_start` is initialized with a virtual address (`CKSEG1ADDR`) instead of the hardware physical address, breaking user-space `mmap()`. >> -- >> >> --- Patch [1]: [RFC PATCH] fbdev: maxinefb: fix build issues --- >> commit e391418fa2f21f8c420eccb513c031674ef184c6 >> Author: Randy Dunlap <[email protected]> >> >> fbdev: maxinefb: fix build issues >> >> This commit fixes build errors and warnings for the maxinefb driver on >> 32-bit and 64-bit MACH_DECSTATION. It updates KSEG1ADDR to CKSEG1ADDR and >> adds the static keyword to missing prototypes. >> >>> diff --git a/drivers/video/fbdev/maxinefb.c b/drivers/video/fbdev/maxinefb.c >>> index 52528eb4dfb41..8aa1389e2d4c8 100644 >>> --- a/drivers/video/fbdev/maxinefb.c >>> +++ b/drivers/video/fbdev/maxinefb.c >> [ ... ] >>> @@ -111,7 +98,7 @@ static const struct fb_ops maxinefb_ops = { >>> .fb_setcolreg = maxinefb_setcolreg, >>> }; >>> >>> -int __init maxinefb_init(void) >>> +static int __init maxinefb_init(void) >> >> [Severity: High] >> This is a pre-existing issue, but does returning 1 on failure in this function >> cause issues with module load semantics? >> >> In maxinefb_init(): >> >> if (register_framebuffer(&fb_info) < 0) >> return 1; >> >> If register_framebuffer() fails, returning a positive integer causes the kernel >> to treat the module as successfully loaded because the module init framework >> expects negative error codes for failure. > > Ack. I'll change that. I had this fixed locally and then forgot about it in the 3-patch series. I'll add it as patch 04/04. -- ~Randy