Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

Pull more drm fixes from Simona Vetter:
 "Another small batch of drm fixes, this time with a different baseline
  and hence separate.

  Drivers:
   - ivpu:
       - dma_resv locking
       - warning fixes
       - reset failure handling
       - improve logging
       - update fw file names
       - fix cmdqueue unregister
   - panel-simple: add Evervision VGG644804

  Core Changes:
   - sysfb: screen_info type check
   - video: screen_info for relocated pci fb
   - drm/sched: signal fence of killed job
   - dummycon: deferred takeover fix"

* tag 'drm-fixes-2025-06-06' of https://gitlab.freedesktop.org/drm/kernel:
  sysfb: Fix screen_info type check for VGA
  video: screen_info: Relocate framebuffers behind PCI bridges
  accel/ivpu: Fix warning in ivpu_gem_bo_free()
  accel/ivpu: Trigger device recovery on engine reset/resume failure
  accel/ivpu: Use dma_resv_lock() instead of a custom mutex
  drm/panel-simple: fix the warnings for the Evervision VGG644804
  accel/ivpu: Reorder Doorbell Unregister and Command Queue Destruction
  accel/ivpu: Use firmware names from upstream repo
  accel/ivpu: Improve buffer object logging
  dummycon: Trigger redraw when switching consoles with deferred takeover
  drm/scheduler: signal scheduled fence when kill job

Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes
invalid access to I/O memory.

Resources behind a PCI host bridge can be relocated by a certain offset
in the kernel's CPU address range used for I/O. The framebuffer memory
range stored in screen_info refers to the CPU addresses as seen during
boot (where the offset is 0). During boot up, firmware may assign a
different memory offset to the PCI host bridge and thereby relocating
the framebuffer address of the PCI graphics device as seen by the kernel.
The information in screen_info must be updated as well.

The helper pcibios_bus_to_resource() performs the relocation of the
screen_info's framebuffer resource (given in PCI bus addresses). The
result matches the I/O-memory resource of the PCI graphics device (given
in CPU addresses). As before, we store away the information necessary to
later update the information in screen_info itself.

Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated
EFI framebuffers") added the code for updating screen_info. It is based
on similar functionality that pre-existed in efifb. Efifb uses a pointer
to the PCI resource, while the newer code does a memcpy of the region.
Hence efifb sees any updates to the PCI resource and avoids the issue.

v3:
- Only use struct pci_bus_region for PCI bus addresses (Bjorn)
- Clarify address semantics in commit messages and comments (Bjorn)
v2:
- Fixed tags (Takashi, Ivan)
- Updated information on efifb

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reported-by: "Ivan T. Ivanov" <iivanov@suse.de>
Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696
Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.9+
Link: https://lore.kernel.org/r/20250528080234.7380-1-tzimmermann@suse.de

Pull backlight updates from Lee Jones:
 "Framebuffer Subsystem (fbdev):
   - The display's blanking status is now tracked in 'struct fb_info'
   - 'framebuffer_alloc()' initializes the blank state to FB_BLANK_UNBLANK
   - 'register_framebuffer()' sets the state to 'FB_BLANK_POWERDOWN' if
     an 'fb_blank' callback exists, ensuring 'FB_EVENT_BLANK' listeners
     correctly see the display being turned on during the first modeset
   - The 'FB_EVENT_BLANK' event data now includes both the new and the
     old blank states
   - 'fb_blank()' has been reworked to return early on errors, without
     functional changes, in preparation for further state tracking
     improvements
   - Fbdev now calls dedicated functions in the backlight subsystems to
     notify them of blank state changes, instead of relying on fbdev
     event notifiers
   - For LCDs, fbdev also calls a dedicated function to notify of mode
     changes
   - Removed the definitions for the unused fbdev event constants
     'FB_EVENT_MODE_CHANGE' and 'FB_EVENT_BLANK' from the header file

  Backlight Subsystem:
   - Implemented fbdev blank state tracking using the (newly enhanced)
     blank state information provided directly by 'FB_EVENT_BLANK'
   - Removed internal blank state tracking fields ('fb_bl_on') from
     'struct backlight_device'
   - Moved the handling of blank-state updates into a separate internal
     helper function, 'backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call interface ('backlight_notify_blank()' and
     'backlight_notify_blank_all()') for display drivers to update
     backlight status

  LCD Subsystem:
   - Moved the handling of display updates (blank events and mode
     changes) from fbdev event notifiers to separate internal helper
     functions ('lcd_notify_blank',
     'lcd_notify_mode_change')
   - Removed support for fbdev events and replaced it with dedicated
     function call interfaces ('lcd_notify_blank_all()',
     'lcd_notify_mode_change_all()')
   - The LCD subsystem now maintains its own internal list of LCD
     devices instead of relying on fbdev notifiers

  LED Backlight Trigger:
   - Moved the handling of blank-state updates into a separate internal
     helper, 'ledtrig_backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call, 'ledtrig_backlight_blank()', for fbdev to notify
     trigger of blank state changes
   - The LED backlight trigger now maintains its own internal list of
     triggers instead of relying on fbdev notifiers

  Qualcomm WLED Backlight:
   - Added a NULL check after 'devm_kasprintf()' in 'wled_configure()'
     to prevent a potential NULL pointer dereference if memory
     allocation fails"

* tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
  backlight: pm8941: Add NULL check in wled_configure()
  fbdev: Remove constants of unused events
  leds: backlight trigger: Replace fb events with a dedicated function call
  leds: backlight trigger: Move blank-state handling into helper
  backlight: lcd: Replace fb events with a dedicated function call
  backlight: lcd: Move event handling into helpers
  backlight: Replace fb events with a dedicated function call
  backlight: Move blank-state handling into helper
  backlight: Implement fbdev tracking with blank state from event
  fbdev: Send old blank state in FB_EVENT_BLANK
  fbdev: Track display blanking state
  fbdev: Rework fb_blank()

If fb_add_videomode() in fb_set_var() fails to allocate memory for
fb_videomode, later it may lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.

================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
 display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
 resize_screen drivers/tty/vt/vt.c:1176 [inline]
 vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================

The reason is that fb_info->var is being modified in fb_set_var(), and
then fb_videomode_to_var() is called. If it fails to add the mode to
fb_info->modelist, fb_set_var() returns error, but does not restore the
old value of fb_info->var. Restore fb_info->var on failure the same way
it is done earlier in the function.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru>
Signed-off-by: Helge Deller <deller@gmx.de>

If fb_add_videomode() in do_register_framebuffer() fails to allocate
memory for fb_videomode, it will later lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.

================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
 display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
 resize_screen drivers/tty/vt/vt.c:1176 [inline]
 vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================

Even though fbcon_init() checks beforehand if fb_match_mode() in
var_to_display() fails, it can not prevent the panic because fbcon_init()
does not return error code. Considering this and the comment in the code
about fb_match_mode() returning NULL - "This should not happen" - it is
better to prevent registering the fb_info if its mode was not set
successfully. Also move fb_add_videomode() closer to the beginning of
do_register_framebuffer() to avoid having to do the cleanup on fail.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru>
Signed-off-by: Helge Deller <deller@gmx.de>

In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
avoid such overflow...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Fixes: 96fe6a2109db ("[PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Helge Deller <deller@gmx.de>

It looks like attempting to write to the "store_modes" sysfs node will
run afoul of unregistered consoles:

UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28
index -1 is out of range for type 'fb_info *[32]'
...
 fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122
 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048
 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673
 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113
 dev_attr_store+0x55/0x80 drivers/base/core.c:2439

static struct fb_info *fbcon_registered_fb[FB_MAX];
...
static signed char con2fb_map[MAX_NR_CONSOLES];
...
static struct fb_info *fbcon_info_from_console(int console)
...
        return fbcon_registered_fb[con2fb_map[console]];

If con2fb_map contains a -1 things go wrong here. Instead, return NULL,
as callers of fbcon_info_from_console() are trying to compare against
existing "info" pointers, so error handling should kick in correctly.

Reported-by: syzbot+a7d4444e7b6e743572f7@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>

Our in-house Syzkaller reported the following BUG (twice), which we
believed was the same issue with [1]:

==================================================================
BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740
Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393
...
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106
 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364
 print_report+0xba/0x280 mm/kasan/report.c:475
 kasan_report+0xa9/0xe0 mm/kasan/report.c:588
 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740
 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline]
 vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690
 vfs_write+0x219/0x960 fs/read_write.c:584
 ksys_write+0x12e/0x260 fs/read_write.c:639
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x78/0xe2
 ...
 </TASK>

Allocated by task 5614:
 kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383
 kasan_kmalloc include/linux/kasan.h:201 [inline]
 __do_kmalloc_node mm/slab_common.c:1007 [inline]
 __kmalloc+0x62/0x140 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 kzalloc include/linux/slab.h:721 [inline]
 vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193
 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007
 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031
 con_font_set drivers/tty/vt/vt.c:4628 [inline]
 con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675
 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474
 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752
 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:871 [inline]
 __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x78/0xe2

Last potentially related work creation:
 kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492
 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713
 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802
 __sock_release+0xb5/0x270 net/socket.c:663
 sock_close+0x1e/0x30 net/socket.c:1425
 __fput+0x408/0xab0 fs/file_table.c:384
 __fput_sync+0x4c/0x60 fs/file_table.c:465
 __do_sys_close fs/open.c:1580 [inline]
 __se_sys_close+0x68/0xd0 fs/open.c:1565
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x78/0xe2

Second to last potentially related work creation:
 kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492
 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713
 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802
 __sock_release+0xb5/0x270 net/socket.c:663
 sock_close+0x1e/0x30 net/socket.c:1425
 __fput+0x408/0xab0 fs/file_table.c:384
 task_work_run+0x154/0x240 kernel/task_work.c:239
 exit_task_work include/linux/task_work.h:45 [inline]
 do_exit+0x8e5/0x1320 kernel/exit.c:874
 do_group_exit+0xcd/0x280 kernel/exit.c:1023
 get_signal+0x1675/0x1850 kernel/signal.c:2905
 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310
 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218
 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87
 entry_SYSCALL_64_after_hwframe+0x78/0xe2

The buggy address belongs to the object at ffff88800f5be000
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 2656 bytes to the right of
 allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500)

...

Memory state around the buggy address:
 ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                       ^
 ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

By analyzing the vmcore, we found that vc->vc_origin was somehow placed
one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and
further writings to /dev/vcs caused out-of-bounds reads (and writes
right after) in vcs_write_buf_noattr().

Our further experiments show that in most cases, vc->vc_origin equals to
vga_vram_base when the console is in KD_TEXT mode, and it's around
vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a
TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around
vc->vc_screenbuf while the console is in KD_TEXT mode, and then by
writing the special 'ESC M' control sequence to the tty certain times
(depends on the value of `vc->state.y - vc->vc_top`), we can eventually
move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on
QEMU:

```
int main() {
	const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top`
	int tty_fd, vcs_fd;
	const char *tty_path = "/dev/tty0";
	const char *vcs_path = "/dev/vcs";
	const char escape_seq[] = "\x1bM";  // ESC + M
	const char trigger_seq[] = "Let's trigger an OOB write.";
	struct vt_sizes vt_size = { 70, 2 };
	int blank = TIOCL_BLANKSCREEN;

	tty_fd = open(tty_path, O_RDWR);

	char vesa_mode[] = { TIOCL_SETVESABLANK, 1 };
	ioctl(tty_fd, TIOCLINUX, vesa_mode);

	ioctl(tty_fd, TIOCLINUX, &blank);
	ioctl(tty_fd, VT_RESIZE, &vt_size);

	for (int i = 0; i < RI_NUM; ++i)
		write(tty_fd, escape_seq, sizeof(escape_seq) - 1);

	vcs_fd = open(vcs_path, O_RDWR);
	write(vcs_fd, trigger_seq, sizeof(trigger_seq));

	close(vcs_fd);
	close(tty_fd);
	return 0;
}
```

To solve this problem, add an address range validation check in
vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf.

Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Co-developed-by: Yi Yang <yiyang13@huawei.com>
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com>
Signed-off-by: Helge Deller <deller@gmx.de>

In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)

The assigned type is "struct dac_info *" but the returned type will be
"struct ics5342_info *", which has a larger allocation size. This is
by design, as struct ics5342_info contains struct dac_info as its first
member.
(patch slightly modified by Helge Deller)

Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>