* [syzbot] [fbdev?] KASAN: slab-use-after-free Read in fb_mode_is_equal
From: syzbot @ 2026-06-10 6:19 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, simona,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 9154c4af7829 Merge tag 'mmc-v7.1-rc3' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16022bec580000
kernel config: https://syzkaller.appspot.com/x/.config?x=4e4d2284f2ffa41
dashboard link: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/05514c1c6f79/disk-9154c4af.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2a4514820c96/vmlinux-9154c4af.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a6cfe00f3884/bzImage-9154c4af.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+81c7c6b52649fd07299d@syzkaller.appspotmail.com
input: j\x03J\aǸ-���9�%v���J86�\x1c� as /devices/virtual/input/input23
==================================================================
BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x280/0x2f0 drivers/video/fbdev/core/modedb.c:934
Read of size 4 at addr ffff88802666219c by task syz.6.4102/26504
CPU: 0 UID: 0 PID: 26504 Comm: syz.6.4102 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1d0 mm/kasan/report.c:595
fb_mode_is_equal+0x280/0x2f0 drivers/video/fbdev/core/modedb.c:934
fbcon_mode_deleted+0x146/0x1e0 drivers/video/fbdev/core/fbcon.c:2750
fb_set_var+0xe76/0x11b0 drivers/video/fbdev/core/fbmem.c:248
do_fb_ioctl+0x734/0x7e0 drivers/video/fbdev/core/fb_chrdev.c:90
fb_ioctl+0xe5/0x150 drivers/video/fbdev/core/fb_chrdev.c:169
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x840 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f828819ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f8285fb2028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f8288416270 RCX: 00007f828819ce59
RDX: 0000200000000080 RSI: 0000000000004601 RDI: 0000000000000003
RBP: 00007f8288232d6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8288416308 R14: 00007f8288416270 R15: 00007fffc117b3a8
</TASK>
Allocated by task 19562:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5296 [inline]
__kmalloc_noprof+0x301/0x850 mm/slub.c:5308
kmalloc_noprof include/linux/slab.h:954 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
cfg80211_inform_single_bss_data+0x557/0x1de0 net/wireless/scan.c:2344
cfg80211_inform_bss_data+0x237/0x3a00 net/wireless/scan.c:3229
cfg80211_inform_bss_frame_data+0x247/0x780 net/wireless/scan.c:3320
ieee80211_bss_info_update+0x310/0xab0 net/mac80211/scan.c:230
ieee80211_rx_bss_info net/mac80211/ibss.c:1088 [inline]
ieee80211_rx_mgmt_probe_beacon net/mac80211/ibss.c:1569 [inline]
ieee80211_ibss_rx_queued_mgmt+0x1922/0x2f80 net/mac80211/ibss.c:1596
ieee80211_iface_process_skb net/mac80211/iface.c:1795 [inline]
ieee80211_iface_work+0xbff/0x13e0 net/mac80211/iface.c:1849
cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 15:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
__rcu_free_sheaf_prepare+0x5d/0x2f0 mm/slub.c:2940
rcu_free_sheaf+0x1a/0xe0 mm/slub.c:5850
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x5a2/0x10d0 kernel/rcu/tree.c:2869
handle_softirqs+0x1ea/0xa00 kernel/softirq.c:622
run_ksoftirqd kernel/softirq.c:1076 [inline]
run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068
smpboot_thread_fn+0x3d3/0xaa0 kernel/smpboot.c:160
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff888026662180
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 28 bytes inside of
freed 96-byte region [ffff888026662180, ffff8880266621e0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x26662
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000000 ffff88813fe30280 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800200020 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 2995, tgid 2995 (kworker/u8:8), ts 29285253194, free_ts 29284937714
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1853
prep_new_page mm/page_alloc.c:1861 [inline]
get_page_from_freelist+0x11a6/0x3410 mm/page_alloc.c:3941
__alloc_frozen_pages_noprof+0x27c/0x2bc0 mm/page_alloc.c:5221
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab mm/slub.c:3467 [inline]
new_slab+0xa6/0x6c0 mm/slub.c:3525
refill_objects+0x277/0x420 mm/slub.c:7272
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x375/0x650 mm/slub.c:4652
alloc_from_pcs mm/slub.c:4750 [inline]
slab_alloc_node mm/slub.c:4884 [inline]
__kmalloc_cache_node_noprof+0x5a3/0x770 mm/slub.c:5428
kmalloc_node_noprof include/linux/slab.h:1077 [inline]
__get_vm_area_node+0x101/0x330 mm/vmalloc.c:3215
__vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7ed0 kernel/fork.c:2090
kernel_clone+0x176/0x9e0 kernel/fork.c:2722
user_mode_thread+0xcc/0x110 kernel/fork.c:2798
call_usermodehelper_exec_work kernel/umh.c:171 [inline]
call_usermodehelper_exec_work+0xcb/0x180 kernel/umh.c:157
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
page last free pid 2995 tgid 2995 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1397 [inline]
__free_frozen_pages+0x794/0x10a0 mm/page_alloc.c:2938
___free_pages_bulk mm/kasan/shadow.c:333 [inline]
__kasan_populate_vmalloc_do mm/kasan/shadow.c:385 [inline]
__kasan_populate_vmalloc+0x164/0x210 mm/kasan/shadow.c:424
kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
alloc_vmap_area+0x95d/0x2b70 mm/vmalloc.c:2123
__get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3226
__vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7ed0 kernel/fork.c:2090
kernel_clone+0x176/0x9e0 kernel/fork.c:2722
user_mode_thread+0xcc/0x110 kernel/fork.c:2798
call_usermodehelper_exec_work kernel/umh.c:171 [inline]
call_usermodehelper_exec_work+0xcb/0x180 kernel/umh.c:157
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff888026662080: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888026662100: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
>ffff888026662180: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888026662200: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888026662280: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Patch submission preferences: request_mem_region changes in fbdev drivers
From: Chintan Patel @ 2026-06-10 3:58 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, tzimmermann
Hello Thomas,
I'm preparing patches to add proper memory-region requests across legacy
fbdev drivers (use of
request_mem_region/pci_request_region/devm_request_mem_region where
appropriate) to avoid conflicts between fbdev and DRM drivers. I’ve
started making changes (examples: pvr2fb.c, macfb.c, cyber2000fb.c,
xilinxfb.c).
Before I prepare a patch series, could you please advise:
Preferred format: a single combined patch or a series of smaller
patches? If a series, do you prefer one patch per driver file, per
driver family, or grouped another way?
Any drivers or areas to exclude or treat specially (e.g., vga16fb or
VGA-exclusive ranges)?
Any tests or checks you expect before posting (build, boot smoke tests,
Kconfig options to verify)?
I can prepare an initial series and send it for review; I’ll follow your
preferred format. Thanks for guidance.
Thank you,
Chintan Patel
^ permalink raw reply
* [PATCH v2] fbdev:modedb: fix a possible UAF in fb_find_mode()
From: Tuo Li @ 2026-06-10 2:50 UTC (permalink / raw)
To: simona, deller, tzimmermann, kees
Cc: linux-fbdev, dri-devel, linux-kernel, Tuo Li
If mode_option is NULL, it is assigned from mode_option_buf:
if (!mode_option) {
fb_get_options(NULL, &mode_option_buf);
mode_option = mode_option_buf;
}
Later, name is assigned from mode_option:
const char *name = mode_option;
However, mode_option_buf is freed before name is no longer used:
kfree(mode_option_buf);
while name is still accessed by:
if ((name_matches(db[i], name, namelen) ||
Since name aliases mode_option_buf, this may result in a
use-after-free.
Fix this by extending the lifetime of mode_option_buf until the end of the
function and using scope-based resource management for cleanup.
Signed-off-by: Tuo Li <islituo@gmail.com>
---
v2:
* Use scope-based resource management instead of manual kfree() calls.
Thanks to Helge Deller for the helpful advice.
---
drivers/video/fbdev/core/modedb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 703d0b7aec32..b6926764a99c 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -626,7 +626,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
const struct fb_videomode *default_mode,
unsigned int default_bpp)
{
- char *mode_option_buf = NULL;
+ char *mode_option_buf __free(kfree) = NULL;
int i;
/* Set up defaults */
@@ -724,7 +724,6 @@ int fb_find_mode(struct fb_var_screeninfo *var,
res_specified = 1;
}
done:
- kfree(mode_option_buf);
if (cvt) {
struct fb_videomode cvt_mode;
int ret;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] fbdev:modedb: fix a possible UAF in fb_find_mode()
From: Tuo Li @ 2026-06-10 2:21 UTC (permalink / raw)
To: Helge Deller
Cc: simona, kees, tzimmermann, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <2d96dd04-855f-45d6-8bf1-7b6704181397@gmx.de>
Hi Helge,
On Mon, Jun 8, 2026 at 12:12 AM Helge Deller <deller@gmx.de> wrote:
>
> On 5/26/26 11:15, Tuo Li wrote:
> > If mode_option is NULL, it is assigned from mode_option_buf:
> >
> > if (!mode_option) {
> > fb_get_options(NULL, &mode_option_buf);
> > mode_option = mode_option_buf;
> > }
> >
> > Later, name is assigned from mode_option:
> >
> > const char *name = mode_option;
> >
> > However, mode_option_buf is freed before name is no longer used:
> >
> > kfree(mode_option_buf);
> >
> > while name is still accessed by:
> >
> > if ((name_matches(db[i], name, namelen) ||
> >
> > Since name aliases mode_option_buf, this may result in a
> > use-after-free.
> >
> > Fix this by moving the kfree(mode_option_buf) call behind the access, and
> > add corresponding cleanup before early returns.
>
> I wonder if this isn't a typical good use-case for the new "Scope-based
> resource management for the kernel" [1] feature.
>
> Instead of adding kfree() at various places, we could do:
>
> diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
> index 703d0b7aec32..b6926764a99c 100644
> --- a/drivers/video/fbdev/core/modedb.c
> +++ b/drivers/video/fbdev/core/modedb.c
> @@ -626,7 +626,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> const struct fb_videomode *default_mode,
> unsigned int default_bpp)
> {
> - char *mode_option_buf = NULL;
> + char *mode_option_buf __free(kfree) = NULL;
> int i;
>
> /* Set up defaults */
> @@ -724,7 +724,6 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> res_specified = 1;
> }
> done:
> - kfree(mode_option_buf);
> if (cvt) {
> struct fb_videomode cvt_mode;
> int ret;
>
>
> [1] https://lwn.net/Articles/934679/
>
>
> Do you want to check if that's correct, and if yes resend a patch?
>
> Helge
Thanks for the suggestion. I think that makes sense. Using __free(kfree)
can simplify the cleanup logic and avoid manually managing multiple kfree()
calls on different return paths.
I'll prepare a v2 based on this approach and send it soon.
Sincerely,
Tuo
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: make g_fbmode array const
From: Brock Haftner @ 2026-06-10 0:58 UTC (permalink / raw)
To: Ahmet Sezgin Duran
Cc: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, outreachy,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <0d8d9f38-3cce-4da2-9ba8-f8e99f7b4dee@sezginduran.net>
On 6/8/26, Ahmet Sezgin Duran wrote:
> Did you compile this patch while enabling sm750fb driver in the config?
No, I did not. I apologize for the mistake.
I ran make drivers/staging/sm750fb/ prior to submitting, however I
failed to realize the driver was not enabled in my .config.
Cheers,
Brock
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Andy Shevchenko @ 2026-06-09 19:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260606045738.21050-15-clamor95@gmail.com>
On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> defined in the device tree.
...
> static int lm3533_led_setup(struct lm3533_led *led)
> {
> - int ret;
> + u32 output_cfg_shift = 0;
No need to assign the default to this.
> + u32 output_cfg_val = 0;
> + u32 output_cfg_mask = 0;
> + int ret, i;
No need to add 'i'.
> + if (led->num_leds) {
> + for (i = 0; i < led->num_leds; i++) {
for (unsigned int i = 0; i < led->num_leds; i++) {
> + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> + continue;
> +
> + output_cfg_shift = led->leds[i] * 2;
> + output_cfg_val |= led->id << output_cfg_shift;
> + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> + }
> +
> + /* LVLED1, LVLED2 and LVLED3 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF1,
> + output_cfg_mask << OUTPUT_CONF1_SHIFT,
> + output_cfg_val << OUTPUT_CONF1_SHIFT);
> + if (ret)
> + return ret;
> +
> + /* LVLED4 and LVLED5 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF2,
> + output_cfg_mask >> OUTPUT_CONF2_SHIFT,
> + output_cfg_val >> OUTPUT_CONF2_SHIFT);
> + if (ret)
> + return ret;
> + }
...
> + if (led->num_leds > 0) {
> + ret = device_property_read_u32_array(&pdev->dev, "led-sources",
> + led->leds, led->num_leds);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to get led-sources\n");
> + goto err_deregister;
> + }
> + }
This and other pieces may benefit from local variable
struct device *dev = &pdev->dev;
defined at the top of the function.
...
> static int lm3533_bl_setup(struct lm3533_bl *bl)
As per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 10/14] mfd: lm3533: Set DMA mask
From: Andy Shevchenko @ 2026-06-09 19:17 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260606045738.21050-11-clamor95@gmail.com>
On Sat, Jun 06, 2026 at 07:57:34AM +0300, Svyatoslav Ryhel wrote:
> Missing coherent_dma_mask assigning triggers the following warning in
> dmesg:
>
> [ 3.287872] platform lm3533-backlight.0: DMA mask not set
>
> Since this warning might be elevated to an error in the future, set
> coherent_dma_mask to zero because both the core and cells do not utilize
> DMA.
Hmm... I am not sure about this. The entire kernel has only two drivers that
do that, and thanks to their commit messages one of them pointed out to the
commit from 2018. So, if no other devices suffer from this, I think it has to
be a better way of achieving the same.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 07/14] mfd: lm3533: Switch sysfs_create_group() to device_add_group()
From: Andy Shevchenko @ 2026-06-09 19:13 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260606045738.21050-8-clamor95@gmail.com>
On Sat, Jun 06, 2026 at 07:57:31AM +0300, Svyatoslav Ryhel wrote:
> Switch from sysfs_create_group() to device_add_group() including device
> managed where appropriate.
This should use .dev_groups member of struct device_driver.
...
> + ret = devm_device_add_group(&bd->dev, &lm3533_bl_attribute_group);
This will make Greg KH very grumpy. (For the record, original code as well
but it already is in upstream. So, thanks for trying to address this, just
needs a bit more of work.)
> + if (ret < 0)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to create sysfs attributes\n");
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Andy Shevchenko @ 2026-06-09 19:10 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260606045738.21050-6-clamor95@gmail.com>
On Sat, Jun 06, 2026 at 07:57:29AM +0300, Svyatoslav Ryhel wrote:
> The lm3533_als_set_input_mode and lm3533_als_set_resistor functions are
> used only in lm3533_als_setup. Incorporate their code into
> lm3533_als_setup directly to simplify driver readability.
Use func() when referring to a function in the commit message.
...
> static int lm3533_als_setup(struct lm3533_als *als,
> const struct lm3533_als_platform_data *pdata)
> {
> + struct device *dev = &als->pdev->dev;
> int ret;
>
> - ret = lm3533_als_set_input_mode(als, pdata->pwm_mode);
> + ret = regmap_assign_bits(als->regmap, LM3533_REG_ALS_CONF,
> + LM3533_ALS_INPUT_MODE_MASK, pdata->pwm_mode);
> if (ret)
> - return ret;
> + return dev_err_probe(dev, ret, "failed to set input mode %d\n",
> + pdata->pwm_mode);
>
> /* ALS input is always high impedance in PWM-mode. */
> if (!pdata->pwm_mode) {
> - ret = lm3533_als_set_resistor(als, pdata->r_select);
> + if (pdata->r_select < LM3533_ALS_RESISTOR_MIN ||
> + pdata->r_select > LM3533_ALS_RESISTOR_MAX)
> + return dev_err_probe(dev, -EINVAL,
> + "invalid resistor value\n");
> +
> + ret = regmap_write(als->regmap, LM3533_REG_ALS_RESISTOR_SELECT,
> + pdata->r_select);
> if (ret)
> - return ret;
> + return dev_err_probe(dev, ret, "failed to set resistor\n");
> }
>
> return 0;
Wondering if it would be better to
/* Bail out when in PWM-mode */
if (pdata->pwm_mode)
return 0;
/* ALS input is always high impedance in PWM-mode. */
...
as the above changes almost every line in that conditional.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 04/14] mfd: lm3533: Pass only regmap and light sensor presence to child devices
From: Andy Shevchenko @ 2026-06-09 19:06 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260606045738.21050-5-clamor95@gmail.com>
On Sat, Jun 06, 2026 at 07:57:28AM +0300, Svyatoslav Ryhel wrote:
> Instead of passing the entire lm3533 core data structure, only pass the
> regmap and the light sensor presence flag to child devices.
...
> struct lm3533_als {
> - struct lm3533 *lm3533;
> + struct regmap *regmap;
> struct platform_device *pdev;
And this pdev is probably not needed. But I haven't checked the whole lot of
the patches yet.
> unsigned long flags;
...
> struct lm3533_ctrlbank {
> - struct lm3533 *lm3533;
> + struct regmap *regmap;
> struct device *dev;
Ditto.
> int id;
> };
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Andy Shevchenko @ 2026-06-09 19:02 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n2rdgw8Xr3uxVdQGwrHTNFqK4SKQDFU2FEB8LzLwPhQ_A@mail.gmail.com>
On Sat, Jun 06, 2026 at 10:22:43AM +0300, Svyatoslav Ryhel wrote:
> сб, 6 черв. 2026 р. о 09:53 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Sat, Jun 06, 2026 at 07:57:26AM +0300, Svyatoslav Ryhel wrote:
...
> > > + ret = regmap_assign_bits(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO,
> > > + LM3533_ALS_INT_ENABLE_MASK, enable);
> >
> > In cases like this perhaps leaving mask would be fine and together with
>
> I prefer to remove intermediate variables it the helper allows to
> directly pass needed value.
>
> > struct regmap *map = als->lm3533->regmap;
>
> next patch drops lm3533 so there will be als->regmap which IMHO is
> more logical instead of passing entire lm3533 to child devices.
Still it's longer than map. A local variable may help with making lines
shorter.
> > this be nice one-liner:
> >
> > ret = regmap_assign_bits(map, LM3533_REG_ALS_ZONE_INFO, mask, enable);
> >
> > > if (ret) {
> > > dev_err(&indio_dev->dev, "failed to set int mode %d\n",
> > > enable);
> >
> > In many cases it won't increase LoC count.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] fbdev: modedb: keep mode option buffer until parsing completes
From: Helge Deller @ 2026-06-09 16:07 UTC (permalink / raw)
To: Ruoyu Wang, Simona Vetter, Javier Martinez Canillas,
Thomas Zimmermann
Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260609160028.5-1-ruoyuw560@gmail.com>
On 6/9/26 18:00, Ruoyu Wang wrote:
> When fb_find_mode() obtains the mode option from fb_get_options(),
> mode_option_buf owns the returned string and name points into that
> buffer. The done label frees mode_option_buf before the database
> fallback has finished using name in name_matches(), so the fallback can
> read freed memory.
>
> Move the free to a common exit path and convert the successful returns
> that can use mode_option_buf into jumps to that exit path.
There was another similiar patch already posted:
https://patchwork.kernel.org/project/linux-fbdev/patch/20260526091507.421730-1-islituo@gmail.com/
Do you want to check if the Scope-based kfree can be used here,
as suggested by me in that thread? It's at least much smaller than your patch...
Helge
>
> Fixes: 089d924d03d5 ("fbdev: Read video= option with fb_get_option() in modedb")
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/video/fbdev/core/modedb.c | 41 ++++++++++++++++++++-----------
> 1 file changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
> index 703d0b7aec322..82f6ea38e1fb8 100644
> --- a/drivers/video/fbdev/core/modedb.c
> +++ b/drivers/video/fbdev/core/modedb.c
> @@ -627,7 +627,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> unsigned int default_bpp)
> {
> char *mode_option_buf = NULL;
> - int i;
> + int i, ret;
>
> /* Set up defaults */
> if (!db) {
> @@ -724,10 +724,9 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> res_specified = 1;
> }
> done:
> - kfree(mode_option_buf);
> if (cvt) {
> struct fb_videomode cvt_mode;
> - int ret;
> + int cvt_ret;
>
> DPRINTK("CVT mode %dx%d@%dHz%s%s%s\n", xres, yres,
> (refresh) ? refresh : 60,
> @@ -745,11 +744,12 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> else
> cvt_mode.vmode &= ~FB_VMODE_INTERLACED;
>
> - ret = fb_find_mode_cvt(&cvt_mode, margins, rb);
> + cvt_ret = fb_find_mode_cvt(&cvt_mode, margins, rb);
>
> - if (!ret && !fb_try_mode(var, info, &cvt_mode, bpp)) {
> + if (!cvt_ret && !fb_try_mode(var, info, &cvt_mode, bpp)) {
> DPRINTK("modedb CVT: CVT mode ok\n");
> - return 1;
> + ret = 1;
> + goto out;
> }
>
> DPRINTK("CVT mode invalid, getting mode from database\n");
> @@ -793,8 +793,10 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> if (!interlace_specified ||
> db_interlace == interlace)
> if (refresh_specified &&
> - db[i].refresh == refresh)
> - return 1;
> + db[i].refresh == refresh) {
> + ret = 1;
> + goto out;
> + }
>
> if (score < diff) {
> diff = score;
> @@ -804,7 +806,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> }
> if (best != -1) {
> fb_try_mode(var, info, &db[best], bpp);
> - return (refresh_specified) ? 2 : 1;
> + ret = (refresh_specified) ? 2 : 1;
> + goto out;
> }
>
> diff = 2 * (xres + yres);
> @@ -831,21 +834,29 @@ int fb_find_mode(struct fb_var_screeninfo *var,
> }
> if (best != -1) {
> fb_try_mode(var, info, &db[best], bpp);
> - return 5;
> + ret = 5;
> + goto out;
> }
> }
>
> DPRINTK("Trying default video mode\n");
> - if (!fb_try_mode(var, info, default_mode, default_bpp))
> - return 3;
> + if (!fb_try_mode(var, info, default_mode, default_bpp)) {
> + ret = 3;
> + goto out;
> + }
>
> DPRINTK("Trying all modes\n");
> for (i = 0; i < dbsize; i++)
> - if (!fb_try_mode(var, info, &db[i], default_bpp))
> - return 4;
> + if (!fb_try_mode(var, info, &db[i], default_bpp)) {
> + ret = 4;
> + goto out;
> + }
>
> DPRINTK("No valid mode found\n");
> - return 0;
> + ret = 0;
> +out:
> + kfree(mode_option_buf);
> + return ret;
> }
>
> /**
^ permalink raw reply
* [PATCH] fbdev: modedb: keep mode option buffer until parsing completes
From: Ruoyu Wang @ 2026-06-09 16:00 UTC (permalink / raw)
To: Simona Vetter, Helge Deller, Javier Martinez Canillas,
Thomas Zimmermann
Cc: linux-fbdev, dri-devel, linux-kernel, Ruoyu Wang
When fb_find_mode() obtains the mode option from fb_get_options(),
mode_option_buf owns the returned string and name points into that
buffer. The done label frees mode_option_buf before the database
fallback has finished using name in name_matches(), so the fallback can
read freed memory.
Move the free to a common exit path and convert the successful returns
that can use mode_option_buf into jumps to that exit path.
Fixes: 089d924d03d5 ("fbdev: Read video= option with fb_get_option() in modedb")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/video/fbdev/core/modedb.c | 41 ++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 703d0b7aec322..82f6ea38e1fb8 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -627,7 +627,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int default_bpp)
{
char *mode_option_buf = NULL;
- int i;
+ int i, ret;
/* Set up defaults */
if (!db) {
@@ -724,10 +724,9 @@ int fb_find_mode(struct fb_var_screeninfo *var,
res_specified = 1;
}
done:
- kfree(mode_option_buf);
if (cvt) {
struct fb_videomode cvt_mode;
- int ret;
+ int cvt_ret;
DPRINTK("CVT mode %dx%d@%dHz%s%s%s\n", xres, yres,
(refresh) ? refresh : 60,
@@ -745,11 +744,12 @@ int fb_find_mode(struct fb_var_screeninfo *var,
else
cvt_mode.vmode &= ~FB_VMODE_INTERLACED;
- ret = fb_find_mode_cvt(&cvt_mode, margins, rb);
+ cvt_ret = fb_find_mode_cvt(&cvt_mode, margins, rb);
- if (!ret && !fb_try_mode(var, info, &cvt_mode, bpp)) {
+ if (!cvt_ret && !fb_try_mode(var, info, &cvt_mode, bpp)) {
DPRINTK("modedb CVT: CVT mode ok\n");
- return 1;
+ ret = 1;
+ goto out;
}
DPRINTK("CVT mode invalid, getting mode from database\n");
@@ -793,8 +793,10 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!interlace_specified ||
db_interlace == interlace)
if (refresh_specified &&
- db[i].refresh == refresh)
- return 1;
+ db[i].refresh == refresh) {
+ ret = 1;
+ goto out;
+ }
if (score < diff) {
diff = score;
@@ -804,7 +806,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
}
if (best != -1) {
fb_try_mode(var, info, &db[best], bpp);
- return (refresh_specified) ? 2 : 1;
+ ret = (refresh_specified) ? 2 : 1;
+ goto out;
}
diff = 2 * (xres + yres);
@@ -831,21 +834,29 @@ int fb_find_mode(struct fb_var_screeninfo *var,
}
if (best != -1) {
fb_try_mode(var, info, &db[best], bpp);
- return 5;
+ ret = 5;
+ goto out;
}
}
DPRINTK("Trying default video mode\n");
- if (!fb_try_mode(var, info, default_mode, default_bpp))
- return 3;
+ if (!fb_try_mode(var, info, default_mode, default_bpp)) {
+ ret = 3;
+ goto out;
+ }
DPRINTK("Trying all modes\n");
for (i = 0; i < dbsize; i++)
- if (!fb_try_mode(var, info, &db[i], default_bpp))
- return 4;
+ if (!fb_try_mode(var, info, &db[i], default_bpp)) {
+ ret = 4;
+ goto out;
+ }
DPRINTK("No valid mode found\n");
- return 0;
+ ret = 0;
+out:
+ kfree(mode_option_buf);
+ return ret;
}
/**
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] video: fbdev: remove skeletonfb example driver with no remaining purpose
From: Helge Deller @ 2026-06-09 14:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Ethan Nelson-Moore; +Cc: linux-fbdev
In-Reply-To: <CAMuHMdXiToNLeQqW54+tOm6-eh9Xefxe3QaMC2Zg7r-3pBOx8A@mail.gmail.com>
On 6/8/26 10:03, Geert Uytterhoeven wrote:
> On Sun, 7 Jun 2026 at 03:58, Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
>> The skeletonfb driver is intended to serve as an example for writing
>> new framebuffer drivers. However, new framebuffer drivers are no longer
>> accepted into the kernel because DRM has obsoleted fbdev, so it no
>> longer has a purpose. In spite of this, it continues to be updated to
>> reflect fbdev API changes, wasting maintainers' time.
I don't want to argue, but the last update was 3 years ago, so
I don't see that much wasted time.
> Remove it.
>>
>> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>
> Thanks for your patch!
>
> Makes sense, as we still have vfb.c, which can actually be built.
> Perhaps some of the comments and/or kerneldoc should be moved
> elsewhere, so it is preserved?
That's what I'm mostly concerned about.
It has so much (still) useful info, that it would be sad to loose that.
Looking up the info in an already deleted file isn't a good alternative.
So, either someone should move comments/info over, or I'd like to keep it
for some more time as it's not actually hurting anybody.
Helge
^ permalink raw reply
* Re: [PATCH next] drivers/video/fbdev/s3fb: Use strscpy() to copy strings into arrays
From: Helge Deller @ 2026-06-09 14:07 UTC (permalink / raw)
To: david.laight.linux, Kees Cook, linux-hardening, dri-devel,
linux-fbdev, linux-kernel
Cc: Arnd Bergmann
In-Reply-To: <20260608095523.2606-11-david.laight.linux@gmail.com>
On 6/8/26 11:54, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> Replacing strcpy() with strscpy() ensures that overflow of the target
> buffer cannot happen.
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
>
> drivers/video/fbdev/s3fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH 1/1] video, sm501: Fix buffer errors in OF binding code
From: Helge Deller @ 2026-06-09 14:00 UTC (permalink / raw)
To: David Laight, Heiko Schocher, linux-fbdev, devicetree-discuss,
Ben Dooks, Vincent Sanders, Samuel Ortiz, linux-kernel,
Randy Dunlap, Paul Mundt, Danila Chernetsov, Kees Cook
In-Reply-To: <20260608124242.13164-1-david.laight.linux@gmail.com>
On 6/8/26 14:42, David Laight wrote:
> The code that gets the frame buffer mode from OF has 'use after free',
> 'buffer overrun' and memory leaks.
>
> info->edid_data isn't free if the probe functions fail or if
> pd->def_mode is set.
>
> If both the CRT and PANEL are enabled info->edid_data is used after
> being freed and is freed twice.
>
> The string returned by of_get_property(np, "mode", &len) is just
> written over either the static "640x480-16@60" or the module parameter
> string without any regard for the length (which is most likely longer).
>
> Use kstrump() for the OF mode and free everything before freeing 'info.
>
> Fixes: 4295f9bf74a88 ("video, sm501: add OF binding to support SM501")
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
> ---
> drivers/video/fbdev/sm501fb.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev/arm: Export acorndata_8x8 font symbol for bootloader
From: Russell King (Oracle) @ 2026-06-09 9:46 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, dri-devel, Ethan Nelson-Moore, Thomas Zimmermann,
linux-arm-kernel
In-Reply-To: <20260609091056.265794-1-deller@gmx.de>
On Tue, Jun 09, 2026 at 11:10:56AM +0200, Helge Deller wrote:
> The text display code used in the Risc PC kernel image decompression
> code uses arch/arm/boot/compressed/font.c, which includes
> lib/fonts/font_acorn_8x8.c, which further includes <linux/font.h>.
>
> Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating
> glyph pitch and size") <linux/font.h> contains inline functions that
> require __do_div64, which is not linked into the ARM kernel
> decompressor. This makes Risc PC zImages fail to build.
>
> Resolve this issue by defining the BOOTLOADER symbol and use it to avoid
> a static declaration of the acorndata_8x8 symbol. That way it can be
> referenced by the arm bootloader, and other static math functions and
> symbols (like __do_div64) stay static and don't get unneccesary included
> in the ARM kernel bootloader decompressor object file.
The decompressor font support has actually been broken since:
commit 6735b4632def0640dbdf4eb9f99816aca18c4f16
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date: Thu Sep 24 09:42:22 2020 -0400
Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
which added extra data to the beginning of the array of font
information:
ENTRY(ll_write_char)
stmfd sp!, {r4 - r7, lr}
...
/*
* calculate offset into character table
*/
mov r1, r1, lsl #3
r1 is the character, this multiplies the character value by 8.
adr ip, LC0
ldmia ip, {r3, r4, r5, r6, lr}
sub ip, ip, r3
add r6, r6, ip
in conjunction with the data table:
LC0: .word LC0
.word bytes_per_char_h
.word video_size_row
.word acorndata_8x8
.word con_charconvtable
results in r6 pointing at acorndata_8x8. We then index this using the
modified character value above:
orr r1, r1, #7
ldrb r7, [r6, r1]
This breaks if extra data is added to the start, and thus has been
broken since the above commit.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] fbcon: correct CONFIG_FB_TILEBLITTING macro name in #endif comment
From: Helge Deller @ 2026-06-09 9:13 UTC (permalink / raw)
To: Thomas Zimmermann, Ethan Nelson-Moore, linux-fbdev; +Cc: Simona Vetter
In-Reply-To: <64b807ea-649c-4ee6-9db4-631e310465ff@suse.de>
On 6/9/26 08:16, Thomas Zimmermann wrote:
> Am 09.06.26 um 05:35 schrieb Ethan Nelson-Moore:
>> A comment in drivers/video/fbdev/core/fbcon.c incorrectly refers to
>> CONFIG_MISC_TILEBLITTING instead of CONFIG_FB_TILEBLITTING. Correct it.
>>
>> Discovered while searching for CONFIG_* symbols referenced in code but
>> not defined in any Kconfig file.
>>
>> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH] fbdev/arm: Export acorndata_8x8 font symbol for bootloader
From: Helge Deller @ 2026-06-09 9:10 UTC (permalink / raw)
To: linux-fbdev, dri-devel
Cc: Ethan Nelson-Moore, Thomas Zimmermann, linux-arm-kernel,
Russell King
The text display code used in the Risc PC kernel image decompression
code uses arch/arm/boot/compressed/font.c, which includes
lib/fonts/font_acorn_8x8.c, which further includes <linux/font.h>.
Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating
glyph pitch and size") <linux/font.h> contains inline functions that
require __do_div64, which is not linked into the ARM kernel
decompressor. This makes Risc PC zImages fail to build.
Resolve this issue by defining the BOOTLOADER symbol and use it to avoid
a static declaration of the acorndata_8x8 symbol. That way it can be
referenced by the arm bootloader, and other static math functions and
symbols (like __do_div64) stay static and don't get unneccesary included
in the ARM kernel bootloader decompressor object file.
Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size")
Reported-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Helge Deller <deller@gmx.de>
---
arch/arm/boot/compressed/Makefile | 2 +-
lib/fonts/font_acorn_8x8.c | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index a159120d1e42..e3f550d62857 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -157,4 +157,4 @@ $(obj)/piggy_data: $(obj)/../Image FORCE
$(obj)/piggy.o: $(obj)/piggy_data
-CFLAGS_font.o := -Dstatic=
+CFLAGS_font.o := -DBOOTLOADER
diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
index 36c51016769d..4ff52c79f8c4 100644
--- a/lib/fonts/font_acorn_8x8.c
+++ b/lib/fonts/font_acorn_8x8.c
@@ -5,7 +5,12 @@
#define FONTDATAMAX 2048
+#ifdef BOOTLOADER
+/* The acorndata_8x8 symbol is needed by the ARM bootloader too. */
+const struct font_data acorndata_8x8 = {
+#else
static const struct font_data acorndata_8x8 = {
+#endif
{ 0, 0, FONTDATAMAX, 0 }, {
/* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ^@ */
/* 01 */ 0x7e, 0x81, 0xa5, 0x81, 0xbd, 0x99, 0x81, 0x7e, /* ^A */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Helge Deller @ 2026-06-09 9:03 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Ethan Nelson-Moore
Cc: linux-fbdev, dri-devel
In-Reply-To: <aaf75c58-c9d5-464a-9651-0021e6784e09@suse.de>
On 6/9/26 08:14, Thomas Zimmermann wrote:
> Hi,
>
> thanks for the fix.
>
> Am 08.06.26 um 22:26 schrieb Helge Deller:
>> * Ethan Nelson-Moore <enelsonmoore@gmail.com>:
>>> Hi, Helge and Thomas,
>>>
>>> On Mon, Jun 8, 2026 at 12:58 PM Helge Deller <deller@gmx.de> wrote:
>>>> On 6/8/26 13:25, Thomas Zimmermann wrote:
>>>>> Why is there a 64-bit division at all?
>>>> Not sure. Might be platform specific.
>>>> Maybe, because you add two integers and divide by an integer, that the
>>>> compiler then chooses to use 64-bit integer division by 32-bit integer.
>>> Actually, I think the real issue is that
>>> arch/arm/boot/compressed/Makefile defines "static" to nothing when
>>> compiling its copy of lib/fonts/font_acorn_8x8.c (via font.c), so that
>>> the font array is available outside of the object file. I assume that
>>> this causes various unused static inline functions in the headers it
>>> includes (such as <linux/math.h>) to be included in the object file
>>> because they become normal inline functions.
>> Does this patch fix the issue then?
>>
>> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> index a159120d1e42..e3f550d62857 100644
>> --- a/arch/arm/boot/compressed/Makefile
>> +++ b/arch/arm/boot/compressed/Makefile
>> @@ -157,4 +157,4 @@ $(obj)/piggy_data: $(obj)/../Image FORCE
>> $(obj)/piggy.o: $(obj)/piggy_data
>> -CFLAGS_font.o := -Dstatic=
>> +CFLAGS_font.o := -DBOOTLOADER
>> diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
>> index 36c51016769d..3327aa6d161d 100644
>> --- a/lib/fonts/font_acorn_8x8.c
>> +++ b/lib/fonts/font_acorn_8x8.c
>> @@ -5,7 +5,11 @@
>> #define FONTDATAMAX 2048
>> +#ifndef BOOTLOADER
>> static const struct font_data acorndata_8x8 = {
>> +#else
>> +const struct font_data acorndata_8x8 = {
>> +#endif
>> { 0, 0, FONTDATAMAX, 0 }, {
>> /* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ^@ */
>> /* 01 */ 0x7e, 0x81, 0xa5, 0x81, 0xbd, 0x99, 0x81, 0x7e, /* ^A */
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Thanks for review!
> I do like this better than the other patch.
Yes, I'll drop the other patch and re-send this one properly.
Helge
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: make g_fbmode array const
From: Ahmet Sezgin Duran @ 2026-06-09 6:12 UTC (permalink / raw)
To: Brock Haftner, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
outreachy
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260609011736.17401-1-brockhaftner@gmail.com>
On 6/9/26 4:17 AM, Brock Haftner wrote:
> The g_fbmode array is a static array of constant strings, but the pointer
> array itself is not marked as const. Fix the checkpatch.pl warning by
> adding the const modifier to the array declaration.
>
> Signed-off-by: Brock Haftner <brockhaftner@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 89c811e0806c..8f533f3b1b42 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -21,7 +21,7 @@
> static int g_hwcursor = 1;
> static int g_noaccel __ro_after_init;
> static int g_nomtrr __ro_after_init;
> -static const char *g_fbmode[] = {NULL, NULL};
> +static const char * const g_fbmode[] = {NULL, NULL};
> static const char *g_def_fbmode = "1024x768-32@60";
> static char *g_settings;
> static int g_dualview __ro_after_init;
Did you compile this patch while enabling sm750fb driver in the config?
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: [PATCH] fbcon: correct CONFIG_FB_TILEBLITTING macro name in #endif comment
From: Thomas Zimmermann @ 2026-06-09 6:16 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-fbdev; +Cc: Helge Deller, Simona Vetter
In-Reply-To: <20260609033503.23428-1-enelsonmoore@gmail.com>
Am 09.06.26 um 05:35 schrieb Ethan Nelson-Moore:
> A comment in drivers/video/fbdev/core/fbcon.c incorrectly refers to
> CONFIG_MISC_TILEBLITTING instead of CONFIG_FB_TILEBLITTING. Correct it.
>
> Discovered while searching for CONFIG_* symbols referenced in code but
> not defined in any Kconfig file.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fbcon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index b0e3e765360d..07eab2729895 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -769,7 +769,7 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> return 0;
> }
>
> -#endif /* CONFIG_MISC_TILEBLITTING */
> +#endif /* CONFIG_FB_TILEBLITTING */
>
> static void fbcon_release(struct fb_info *info)
> {
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Thomas Zimmermann @ 2026-06-09 6:14 UTC (permalink / raw)
To: Helge Deller, Ethan Nelson-Moore; +Cc: Helge Deller, linux-fbdev, dri-devel
In-Reply-To: <aiclYUfQvMokMu64@carbonx1>
Hi,
thanks for the fix.
Am 08.06.26 um 22:26 schrieb Helge Deller:
> * Ethan Nelson-Moore <enelsonmoore@gmail.com>:
>> Hi, Helge and Thomas,
>>
>> On Mon, Jun 8, 2026 at 12:58 PM Helge Deller <deller@gmx.de> wrote:
>>> On 6/8/26 13:25, Thomas Zimmermann wrote:
>>>> Why is there a 64-bit division at all?
>>> Not sure. Might be platform specific.
>>> Maybe, because you add two integers and divide by an integer, that the
>>> compiler then chooses to use 64-bit integer division by 32-bit integer.
>> Actually, I think the real issue is that
>> arch/arm/boot/compressed/Makefile defines "static" to nothing when
>> compiling its copy of lib/fonts/font_acorn_8x8.c (via font.c), so that
>> the font array is available outside of the object file. I assume that
>> this causes various unused static inline functions in the headers it
>> includes (such as <linux/math.h>) to be included in the object file
>> because they become normal inline functions.
> Does this patch fix the issue then?
>
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index a159120d1e42..e3f550d62857 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -157,4 +157,4 @@ $(obj)/piggy_data: $(obj)/../Image FORCE
>
> $(obj)/piggy.o: $(obj)/piggy_data
>
> -CFLAGS_font.o := -Dstatic=
> +CFLAGS_font.o := -DBOOTLOADER
> diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
> index 36c51016769d..3327aa6d161d 100644
> --- a/lib/fonts/font_acorn_8x8.c
> +++ b/lib/fonts/font_acorn_8x8.c
> @@ -5,7 +5,11 @@
>
> #define FONTDATAMAX 2048
>
> +#ifndef BOOTLOADER
> static const struct font_data acorndata_8x8 = {
> +#else
> +const struct font_data acorndata_8x8 = {
> +#endif
> { 0, 0, FONTDATAMAX, 0 }, {
> /* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ^@ */
> /* 01 */ 0x7e, 0x81, 0xa5, 0x81, 0xbd, 0x99, 0x81, 0x7e, /* ^A */
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
I do like this better than the other patch.
Best regards
Thomas
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [PATCH] fbcon: correct CONFIG_FB_TILEBLITTING macro name in #endif comment
From: Ethan Nelson-Moore @ 2026-06-09 3:35 UTC (permalink / raw)
To: linux-fbdev
Cc: Ethan Nelson-Moore, Helge Deller, Thomas Zimmermann,
Simona Vetter
A comment in drivers/video/fbdev/core/fbcon.c incorrectly refers to
CONFIG_MISC_TILEBLITTING instead of CONFIG_FB_TILEBLITTING. Correct it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b0e3e765360d..07eab2729895 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -769,7 +769,7 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
return 0;
}
-#endif /* CONFIG_MISC_TILEBLITTING */
+#endif /* CONFIG_FB_TILEBLITTING */
static void fbcon_release(struct fb_info *info)
{
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Ethan Nelson-Moore @ 2026-06-09 1:50 UTC (permalink / raw)
To: Helge Deller; +Cc: Helge Deller, Thomas Zimmermann, linux-fbdev, dri-devel
In-Reply-To: <aiclYUfQvMokMu64@carbonx1>
Hi, Helge,
On Mon, Jun 8, 2026 at 1:26 PM Helge Deller <deller@kernel.org> wrote:
> Does this patch fix the issue then?
Yes, it does. I remember you suggested this solution a while ago. Thank you.
Ethan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox