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
