* [PATCH 0/1] staging: sm750fb: convert CamelCase function names to snake_case
From: khalid.datamax @ 2025-05-31 21:11 UTC (permalink / raw)
To: sudipm.mukherjee
Cc: teddy.wang, gregkh, linux-fbdev, linux-staging, linux-kernel,
Khalid Faisal
This patch cleans up the staging driver sm750fb by converting function names
that are currently in CamelCase to the preferred snake_case style, following
Linux kernel coding guidelines.
Specifically, it renames the following functions for consistency and readability:
- sii164GetDeviceID -> sii164_get_device_id
- sii164ResetChip -> sii164_reset_chip
- sii164GetChipString -> sii164_get_chip_string
- sii164SetPower -> sii164_set_power
- sii164EnableHotPlugDetection -> sii164_enable_hot_plug_detection
- sii164IsConnected -> sii164_is_connected
- sii164CheckInterrupt -> sii164_check_interrupt
- sii164ClearInterrupt -> sii164_clear_interrupt
This helps maintain uniformity with the rest of the kernel codebase and
improves maintainability.
Signed-off-by: Khalid Faisal <khalid.datamax@gmail.com>
^ permalink raw reply
* [GIT PULL] fbdev updates for v6.16-rc1
From: Helge Deller @ 2025-05-31 17:13 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
Hi Linus,
please pull the fbdev fixes and updates for 6.16-rc1:
Many small but important fixes for special cases in the fbdev, fbcon and vgacon
code, some smaller code cleanups in the nvidiafb, arkfb, atyfb and viafb drivers
and two spelling fixes.
Thanks!
Helge
PS: All patches have been sitting in for-next for at least two days (the
majority of patches since weeks). I did a rebase because fast-forward merging
with head didn't work.
----------------------------------------------------------------
The following changes since commit 0f70f5b08a47a3bc1a252e5f451a137cde7c98ce:
Merge tag 'pull-automount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2025-05-30 15:38:29 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.16-rc1
for you to fetch changes up to 05f6e183879d9785a3cdf2f08a498bc31b7a20aa:
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var (2025-05-31 10:24:02 +0200)
----------------------------------------------------------------
fbdev fixes and updates for 6.16-rc1:
Various bug fixes for corner cases which were found with Syzkaller,
Svace and other tools by various people and teams (e.g. Linux Verification Center):
fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var [Murad Masimov]
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var [Murad Masimov]
fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() [Sergey Shtylyov]
fbcon: Make sure modelist not set on unregistered console [Kees Cook]
vgacon: Add check for vc_origin address range in vgacon_scroll() [GONG Ruiqi]
Minor coding fixes in:
nvidiafb, arkfb, atyfb, viafb.
Spelling fixes in:
sstfb.rst and carminefb.
----------------------------------------------------------------
Andy Shevchenko (1):
fbdev: atyfb: Remove unused PCI vendor ID
Bartosz Golaszewski (1):
fbdev: via: use new GPIO line value setter callbacks
Colin Ian King (1):
fbdev: carminefb: Fix spelling mistake of CARMINE_TOTAL_DIPLAY_MEM
GONG Ruiqi (1):
vgacon: Add check for vc_origin address range in vgacon_scroll()
Kees Cook (2):
fbdev: arkfb: Cast ics5342_init() allocation type
fbcon: Make sure modelist not set on unregistered console
Murad Masimov (2):
fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var
Rujra Bhatt (1):
fbdev: sstfb.rst: Fix spelling mistake
Sergey Shtylyov (1):
fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
Zijun Hu (1):
fbdev: nvidiafb: Correct const string length in nvidiafb_setup()
Documentation/fb/sstfb.rst | 2 +-
drivers/video/console/vgacon.c | 2 +-
drivers/video/fbdev/arkfb.c | 5 +++--
drivers/video/fbdev/carminefb.c | 8 ++++----
drivers/video/fbdev/carminefb.h | 2 +-
drivers/video/fbdev/core/fbcon.c | 7 ++++++-
drivers/video/fbdev/core/fbcvt.c | 2 +-
drivers/video/fbdev/core/fbmem.c | 22 ++++++++++++++--------
drivers/video/fbdev/nvidia/nvidia.c | 2 +-
drivers/video/fbdev/via/via-gpio.c | 10 +++++-----
include/video/mach64.h | 3 ---
11 files changed, 37 insertions(+), 28 deletions(-)
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Geert Uytterhoeven @ 2025-05-30 7:59 UTC (permalink / raw)
To: Eero Tamminen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <65b78057-c490-46a3-92a7-350d314d604e@helsinkinet.fi>
Hi Eero,
On Thu, 29 May 2025 at 02:06, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 28.5.2025 11.57, Geert Uytterhoeven wrote:
> > On Wed, 28 May 2025 at 00:47, Eero Tamminen <oak@helsinkinet.fi> wrote:
> >> I did boot testing on Hatari emulator with a minimal kernel config
> >> having atari_drm enabled, atafb disabled, FB & boot logo enabled.
> >>
> >> Under Falcon emulation:
> >> - RGB/VGA => works fine
> >> - Mono monitor => panic
> >> "Kernel panic - not syncing: can't set default video mode"
> >>
> >> Under TT emulation:
> >> - RGB/VGA => boots, but console is black[1] (palette issue?)
> >> - Mono monitor => looks OKish[2], but has constant warnings:
> >> -----------------------------------
> >> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1720
> >> drm_atomic_helper_wait_for_vblanks+0x1a0/0x1ee
> >> [CRTC:35:crtc-0] vblank wait timed out
> >
> > I am not sure this is a bug in atari-drm, or just an issue when using
> > DRM on slow machines.
>
> This does not trigger with -Os built "atafb" kernel, but happens even
> with -O2 built "atari-drm" kernel. Something related to the higher (71)
> HZ of the mono monitors?
>
> (I don't think it relates to TT mono monitor's larger 1280x960
> resolution, because it happens also with ST mono monitor 640x400 one.)
DRM vblank handling is part of DRM, so it is not applicable to atafb.
> > Are these regression in atari-drm, or do they happen with atafb, too?
>
> Only the "can't set default video" issue in Falcon mono mode happens
> also with "atafb".
>
> It has neither the above vblank timeout issue in mono mode, nor
> black-on-black color issue in color mode (on TT and 030 ST).
Unless I made a mistake, color handling should be the same for
atari-drm and atafb. Unfortunately I am no Atari hardware expert.
> >> However, -O2 build has the downside that the resulting kernel Oopses
> >> once it reaches user-space, if 030 data cache emulation is enabled:
> >> ----------------------------------------------------------------
> >> Run /init as init process
> >> ...
> >> Instruction fault at 0x0041a256
> >> BAD KERNEL BUSERR
> >
> > Interesting...
>
> There were some extra config differences between my builds for 6.15
> "atafb" and your "atari-drm-wip-rebasing" branch.
>
> After removing the ones I could:
> --------------------------------
> $ diff -ub .config.old .config | grep '^[-+]C'
> -CONFIG_I2C_HELPER_AUTO=y
> -CONFIG_LOGO=y
> -CONFIG_LOGO_LINUX_MONO=y
> -CONFIG_LOGO_LINUX_VGA16=y
> -------------------------------
>
> Bus error issue went away.
>
> => Could there be some issue with how logo and "atari-drm" code
> interact, which could manifest when reaching user-space?
>
> Note: I haven't tried enabling logo with "atafb" + -O2 build. I could
> try that later on.
Logo shouldn't matter.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Eero Tamminen @ 2025-05-29 19:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <65b78057-c490-46a3-92a7-350d314d604e@helsinkinet.fi>
Hi,
On 29.5.2025 3.06, Eero Tamminen wrote:
> On 28.5.2025 11.57, Geert Uytterhoeven wrote:
> There were some extra config differences between my builds for 6.15
> "atafb" and your "atari-drm-wip-rebasing" branch.
>
> After removing the ones I could:
> --------------------------------
> $ diff -ub .config.old .config | grep '^[-+]C'
> -CONFIG_I2C_HELPER_AUTO=y
> -CONFIG_LOGO=y
> -CONFIG_LOGO_LINUX_MONO=y
> -CONFIG_LOGO_LINUX_VGA16=y
> -------------------------------
>
> Bus error issue went away.
>
> => Could there be some issue with how logo and "atari-drm" code
> interact, which could manifest when reaching user-space?
>
> Note: I haven't tried enabling logo with "atafb" + -O2 build. I could
> try that later on.
Tried that now. Enabling logo config options for "atafb" kernel did not
cause bus error with -O2. It did not show logo though, the area where
the logo was shown with "atari-drm", was just black.
=> No conclusive result on whether logo triggers the bus error.
As to boot time with minimal kernel booting on (emulated) 32Mhz Falcon,
according to /proc/uptime...
"-Os" kernel build:
- atafb: 11.87s
- atari-drm: 21.04s
=> Nearly 80% slower.
"-O2" kernel build:
- atafb: 10.35s
- atari-drm: 11.42s
=> Only 10% slower.
I.e. difference in -Os / -O2 boot time is clearly due to "atari-drm" driver.
- Eero
^ permalink raw reply
* Re: [PATCH 0/2] fbdev: Prevent null-ptr-deref in fb_videomode_to_var
From: Helge Deller @ 2025-05-29 8:19 UTC (permalink / raw)
To: Murad Masimov; +Cc: linux-fbdev, dri-devel, linux-kernel, lvc-project
In-Reply-To: <20250428153407.3743416-1-m.masimov@mt-integration.ru>
On 4/28/25 17:34, Murad Masimov wrote:
> These patches fix the bug that leads to a null-ptr-deref if
> fb_videomode_to_var() fails to allocate memory. This bug is present in
> do_register_framebuffer() and fb_ser_var().
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Murad Masimov (2):
> fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in
> fb_videomode_to_var
> fbdev: Fix fb_ser_var to prevent null-ptr-deref in fb_videomode_to_var
I've added both patches to fbdev git tree (after fixing two small typos in commit message).
Thanks!
Helge
> drivers/video/fbdev/core/fbmem.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> --
> 2.39.2
>
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Eero Tamminen @ 2025-05-29 0:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdXDdrMewGgeghr3cwtaBvieguYOC4GZ-EXZmA+w5S4bpw@mail.gmail.com>
Hi Geert,
On 28.5.2025 11.57, Geert Uytterhoeven wrote:
> On Wed, 28 May 2025 at 00:47, Eero Tamminen <oak@helsinkinet.fi> wrote:
>> I did boot testing on Hatari emulator with a minimal kernel config
>> having atari_drm enabled, atafb disabled, FB & boot logo enabled.
>>
>> Under Falcon emulation:
>> - RGB/VGA => works fine
>> - Mono monitor => panic
>> "Kernel panic - not syncing: can't set default video mode"
>>
>> Under TT emulation:
>> - RGB/VGA => boots, but console is black[1] (palette issue?)
>> - Mono monitor => looks OKish[2], but has constant warnings:
>> -----------------------------------
>> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1720
>> drm_atomic_helper_wait_for_vblanks+0x1a0/0x1ee
>> [CRTC:35:crtc-0] vblank wait timed out
>
> I am not sure this is a bug in atari-drm, or just an issue when using
> DRM on slow machines.
This does not trigger with -Os built "atafb" kernel, but happens even
with -O2 built "atari-drm" kernel. Something related to the higher (71)
HZ of the mono monitors?
(I don't think it relates to TT mono monitor's larger 1280x960
resolution, because it happens also with ST mono monitor 640x400 one.)
Btw. both kernels include:
$ grep ^CONFIG.*WATCH .config
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
CONFIG_WATCHDOG_OPEN_TIMEOUT=0
CONFIG_SOFT_WATCHDOG=y
CONFIG_WQ_WATCHDOG=y
>> -----------------------------------
>>
>> Under 030 ST/STe emulation:
>> - RGB/VGA => boots, but console is black (palette issue?)
>> - Mono monitor => looks OK, but has constant slowpath warnings with:
>> "[CRTC:35:crtc-0] vblank wait timed out"
>>
>> => Any advice on the issues?
>
> Are these regression in atari-drm, or do they happen with atafb, too?
Only the "can't set default video" issue in Falcon mono mode happens
also with "atafb".
It has neither the above vblank timeout issue in mono mode, nor
black-on-black color issue in color mode (on TT and 030 ST).
...
>> However, -O2 build has the downside that the resulting kernel Oopses
>> once it reaches user-space, if 030 data cache emulation is enabled:
>> ----------------------------------------------------------------
>> Run /init as init process
>> ...
>> Instruction fault at 0x0041a256
>> BAD KERNEL BUSERR
>
> Interesting...
There were some extra config differences between my builds for 6.15
"atafb" and your "atari-drm-wip-rebasing" branch.
After removing the ones I could:
--------------------------------
$ diff -ub .config.old .config | grep '^[-+]C'
-CONFIG_I2C_HELPER_AUTO=y
-CONFIG_LOGO=y
-CONFIG_LOGO_LINUX_MONO=y
-CONFIG_LOGO_LINUX_VGA16=y
-------------------------------
Bus error issue went away.
=> Could there be some issue with how logo and "atari-drm" code
interact, which could manifest when reaching user-space?
Note: I haven't tried enabling logo with "atafb" + -O2 build. I could
try that later on.
- Eero
^ permalink raw reply
* Re: [PATCH] staging: fbtft: add invert display parameter
From: Nam Cao @ 2025-05-28 20:25 UTC (permalink / raw)
To: Bram Vlerick
Cc: Greg Kroah-Hartman, dri-devel, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20250528-ili9341-invert-dtb-v1-1-080202809332@openpixelsystems.org>
On Wed, May 28, 2025 at 05:42:30PM +0200, Bram Vlerick wrote:
> Add devicetree parameter to enable or disable the invert feature of the
> ili9341 display
Can't/shouldn't this be done by userspace application? Why would someone
want to invert the color by default.
Also, this driver is built on top of the deprecated framebuffer, it will
never get out of staging/. For new feature, you probably want to send it to
drivers/gpu/drm/panel/panel-ilitek-ili9341.c instead.
> Signed-off-by: Bram Vlerick <bram.vlerick@openpixelsystems.org>
> ---
> drivers/staging/fbtft/fb_ili9341.c | 3 +++
> drivers/staging/fbtft/fbtft-core.c | 2 ++
> drivers/staging/fbtft/fbtft.h | 3 +++
> 3 files changed, 8 insertions(+)
>
> diff --git a/drivers/staging/fbtft/fb_ili9341.c b/drivers/staging/fbtft/fb_ili9341.c
> index 47e72b87d76d996111aaadcf5e56dfdfc1c331ab..a184f57df12b5ad6612a2e83b664a8911c7c79be 100644
> --- a/drivers/staging/fbtft/fb_ili9341.c
> +++ b/drivers/staging/fbtft/fb_ili9341.c
> @@ -103,6 +103,9 @@ static int set_var(struct fbtft_par *par)
> break;
> }
>
> + if (par->invert)
> + write_reg(par, 0x21);
Use MIPI_DCS_ENTER_INVERT_MODE instead of the magic number.
Best regards,
Nam
^ permalink raw reply
* Re: [PATCH] staging: fbtft: add invert display parameter
From: Dan Carpenter @ 2025-05-28 19:38 UTC (permalink / raw)
To: Bram Vlerick
Cc: Greg Kroah-Hartman, dri-devel, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20250528-ili9341-invert-dtb-v1-1-080202809332@openpixelsystems.org>
On Wed, May 28, 2025 at 05:42:30PM +0200, Bram Vlerick wrote:
> Add devicetree parameter to enable or disable the invert feature of the
> ili9341 display
>
This commit message is so unclear. The parameter doesn't let you
--and this is a direct quote. LOL-- "disable the invert feature". It
would be better to say "Add devicetree parameter to invert the display
on a ili9341 device."
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: fbtft: add invert display parameter
From: Bram Vlerick @ 2025-05-28 15:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel, Bram Vlerick
Add devicetree parameter to enable or disable the invert feature of the
ili9341 display
Signed-off-by: Bram Vlerick <bram.vlerick@openpixelsystems.org>
---
drivers/staging/fbtft/fb_ili9341.c | 3 +++
drivers/staging/fbtft/fbtft-core.c | 2 ++
drivers/staging/fbtft/fbtft.h | 3 +++
3 files changed, 8 insertions(+)
diff --git a/drivers/staging/fbtft/fb_ili9341.c b/drivers/staging/fbtft/fb_ili9341.c
index 47e72b87d76d996111aaadcf5e56dfdfc1c331ab..a184f57df12b5ad6612a2e83b664a8911c7c79be 100644
--- a/drivers/staging/fbtft/fb_ili9341.c
+++ b/drivers/staging/fbtft/fb_ili9341.c
@@ -103,6 +103,9 @@ static int set_var(struct fbtft_par *par)
break;
}
+ if (par->invert)
+ write_reg(par, 0x21);
+
return 0;
}
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index da9c64152a606dc4a176f5a37fa59f6a7d3a2af3..4e827e9899e32313f2e4a9bf12ff49283a63fed3 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -641,6 +641,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
par->buf = buf;
spin_lock_init(&par->dirty_lock);
par->bgr = pdata->bgr;
+ par->invert = pdata->invert;
par->startbyte = pdata->startbyte;
par->init_sequence = init_sequence;
par->gamma.curves = gamma_curves;
@@ -1107,6 +1108,7 @@ static struct fbtft_platform_data *fbtft_properties_read(struct device *dev)
pdata->display.bpp = fbtft_property_value(dev, "bpp");
pdata->display.debug = fbtft_property_value(dev, "debug");
pdata->rotate = fbtft_property_value(dev, "rotate");
+ pdata->invert = device_property_read_bool(dev, "invert");
pdata->bgr = device_property_read_bool(dev, "bgr");
pdata->fps = fbtft_property_value(dev, "fps");
pdata->txbuflen = fbtft_property_value(dev, "txbuflen");
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 317be17b95c1672404fc6aecda24d0a1f563685d..71c9c35e7548de314088ac3aeb160d6c6aaf75c9 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -125,6 +125,7 @@ struct fbtft_display {
* @display: Display properties
* @gpios: Pointer to an array of pinname to gpio mappings
* @rotate: Display rotation angle
+ * @invert: Invert display colors
* @bgr: LCD Controller BGR bit
* @fps: Frames per second (this will go away, use @fps in @fbtft_display)
* @txbuflen: Size of transmit buffer
@@ -135,6 +136,7 @@ struct fbtft_display {
struct fbtft_platform_data {
struct fbtft_display display;
unsigned int rotate;
+ bool invert;
bool bgr;
unsigned int fps;
int txbuflen;
@@ -229,6 +231,7 @@ struct fbtft_par {
bool first_update_done;
ktime_t update_time;
bool bgr;
+ bool invert;
void *extra;
bool polarity;
};
---
base-commit: 914873bc7df913db988284876c16257e6ab772c6
change-id: 20250528-ili9341-invert-dtb-07a5656e6dfd
Best regards,
--
Bram Vlerick <bram.vlerick@openpixelsystems.org>
^ permalink raw reply related
* [syzbot] [fbdev?] KASAN: vmalloc-out-of-bounds Write in fillrect
From: syzbot @ 2025-05-28 9:22 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, simona, soci,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: a5806cd506af Linux 6.15-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12afde70580000
kernel config: https://syzkaller.appspot.com/x/.config?x=87b7b87abbf1a67f
dashboard link: https://syzkaller.appspot.com/bug?extid=7a63ce155648954e749b
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d0398ca67d9a/disk-a5806cd5.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dccdb3c5ff14/vmlinux-a5806cd5.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3d94cf3493b5/bzImage-a5806cd5.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7a63ce155648954e749b@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in fb_write_offset drivers/video/fbdev/core/sysmem.h:30 [inline]
BUG: KASAN: vmalloc-out-of-bounds in bitfill drivers/video/fbdev/core/fb_fillrect.h:134 [inline]
BUG: KASAN: vmalloc-out-of-bounds in fb_fillrect_static drivers/video/fbdev/core/fb_fillrect.h:220 [inline]
BUG: KASAN: vmalloc-out-of-bounds in fb_fillrect drivers/video/fbdev/core/fb_fillrect.h:279 [inline]
BUG: KASAN: vmalloc-out-of-bounds in sys_fillrect+0x15d4/0x17b0 drivers/video/fbdev/core/sysfillrect.c:22
Write of size 8 at addr ffffc90003849000 by task syz.1.1552/13525
CPU: 1 UID: 0 PID: 13525 Comm: syz.1.1552 Tainted: G U 6.15.0-rc7-syzkaller #0 PREEMPT(full)
Tainted: [U]=USER
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
fb_write_offset drivers/video/fbdev/core/sysmem.h:30 [inline]
bitfill drivers/video/fbdev/core/fb_fillrect.h:134 [inline]
fb_fillrect_static drivers/video/fbdev/core/fb_fillrect.h:220 [inline]
fb_fillrect drivers/video/fbdev/core/fb_fillrect.h:279 [inline]
sys_fillrect+0x15d4/0x17b0 drivers/video/fbdev/core/sysfillrect.c:22
drm_fbdev_shmem_defio_fillrect+0x22/0x140 drivers/gpu/drm/drm_fbdev_shmem.c:37
bit_clear+0x17a/0x220 drivers/video/fbdev/core/bitblit.c:73
__fbcon_clear+0x600/0x780 drivers/video/fbdev/core/fbcon.c:1292
fbcon_scroll+0x48b/0x690 drivers/video/fbdev/core/fbcon.c:1851
con_scroll+0x45c/0x690 drivers/tty/vt/vt.c:579
csi_M drivers/tty/vt/vt.c:2072 [inline]
csi_ECMA drivers/tty/vt/vt.c:2483 [inline]
do_con_trol drivers/tty/vt/vt.c:2657 [inline]
do_con_write+0x6869/0x7c90 drivers/tty/vt/vt.c:3092
con_write+0x23/0xb0 drivers/tty/vt/vt.c:3432
process_output_block drivers/tty/n_tty.c:561 [inline]
n_tty_write+0x40f/0x1160 drivers/tty/n_tty.c:2377
iterate_tty_write drivers/tty/tty_io.c:1015 [inline]
file_tty_write.constprop.0+0x502/0x9b0 drivers/tty/tty_io.c:1090
tty_write drivers/tty/tty_io.c:1111 [inline]
redirected_tty_write drivers/tty/tty_io.c:1134 [inline]
redirected_tty_write+0xd4/0x150 drivers/tty/tty_io.c:1114
new_sync_write fs/read_write.c:591 [inline]
vfs_write+0x5ba/0x1180 fs/read_write.c:684
ksys_write+0x12a/0x240 fs/read_write.c:736
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f457158e969
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f457244f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f45717b5fa0 RCX: 00007f457158e969
RDX: 0000000000000013 RSI: 0000200000000000 RDI: 0000000000000005
RBP: 00007f4571610ab1 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f45717b5fa0 R15: 00007ffddb9e8a38
</TASK>
The buggy address ffffc90003849000 belongs to a vmalloc virtual mapping
Memory state around the buggy address:
ffffc90003848f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90003848f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90003849000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90003849080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90003849100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
---
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
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Geert Uytterhoeven @ 2025-05-28 8:57 UTC (permalink / raw)
To: Eero Tamminen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <72078ec9-25a0-42d5-b7da-b0a974033f86@helsinkinet.fi>
Hi Eero,
On Wed, 28 May 2025 at 00:47, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 25.5.2025 15.05, Geert Uytterhoeven wrote:
> > On Thu, 22 May 2025 at 00:56, Eero Tamminen <oak@helsinkinet.fi> wrote:
> >> On 21.5.2025 10.06, Geert Uytterhoeven wrote:
> >>> I do keep it up-to-date locally, so I could provide these changes,
> >>> if you are interested.
> >>
> >> Yes, please! (see below)
> >
> > Sorry for taking so long:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=atari-drm-wip-rebasing
>
> Thanks!
>
> I did boot testing on Hatari emulator with a minimal kernel config
> having atari_drm enabled, atafb disabled, FB & boot logo enabled.
>
> Under Falcon emulation:
> - RGB/VGA => works fine
> - Mono monitor => panic
> "Kernel panic - not syncing: can't set default video mode"
> Under TT emulation:
> - RGB/VGA => boots, but console is black[1] (palette issue?)
> - Mono monitor => looks OKish[2], but has constant warnings:
> -----------------------------------
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1720
> drm_atomic_helper_wait_for_vblanks+0x1a0/0x1ee
> [CRTC:35:crtc-0] vblank wait timed out
I am not sure this is a bug in atari-drm, or just an issue when using
DRM on slow machines.
> -----------------------------------
>
> Under 030 ST/STe emulation:
> - RGB/VGA => boots, but console is black (palette issue?)
> - Mono monitor => looks OK, but has constant slowpath warnings with:
> "[CRTC:35:crtc-0] vblank wait timed out"
>
> => Any advice on the issues?
Are these regression in atari-drm, or do they happen with atafb, too?
> PS. I also profiled where most of time goes from "atari-drm" probing,
> until boot reaches user space. On a minimal -Os built kernel, running
> on (emulated) 32Mhz 030 Falcon, in the default 640x480@4 resolution:
> ----------------------------------------------------------------
> Time spent in profile = 15.29712s.
> ...
> Used cycles:
> 22.37% 22.42% 25.35% _transp
> 19.15% 19.19% 46.82% atari_drm_fb_blit_rect.isra.0
> 8.09% 8.09% 13.80% sys_copyarea
> 3.94% 3.95% 6.23% sys_imageblit
> 3.69% 3.69% 3.69% fb_copy_offset.isra.0
> 2.12% 2.13% 2.41% atari_scsi_falcon_reg_read
> 2.03% 2.03% 2.03% fb_address_forward
> 1.85% 1.85% 17.98% fbcon_redraw_blit.constprop.0
> 1.81% 1.81% 2.04% atari_keyb_init
> 1.78% 1.78% 1.98% fb_reverse_long
> 1.58% 1.58% 1.90% arch_cpu_idle
> 1.05% memcpy
> 0.95% memset
> ...
> ----------------------------------------------------------------
>
> => atari-drm blitting takes half the time during boot.
Yeah, conversion from chunky to planar is expensive.
Would be great to have a text console that operates directly on the
buffer used by the hardware...
> Building kernel with -O2, changes above rather radically, both
> time-wise, and where that time goes:
> ----------------------------------------------------------------
> Time spent in profile = 6.54049s.
> ...
> Used cycles:
> 17.61% 17.61% 17.61% sys_copyarea
> 11.18% 11.18% 13.11% arch_cpu_idle
> 7.53% 7.55% 8.45% atari_drm_fb_blit_rect.isra.0
> 4.26% 4.27% 4.76% atari_keyb_init
> 2.70% 2.70% 2.93% atari_scsi_falcon_reg_read
> 2.45% 2.45% 23.81% fbcon_redraw_blit.constprop.0
> 2.35% 2.35% 2.48% sys_imageblit
> 2.12% 2.12% 5.89% atari_floppy_init
> 1.97% memset
> 1.31% memcpy
> ...
> Instruction cache misses:
> 27.14% 27.14% 27.14% sys_copyarea
> 3.77% 3.77% 4.05% atari_scsi_falcon_reg_read
> ...
> Data cache hits:
> 63.55% 63.55% 63.67% atari_keyb_init
> 7.61% 7.62% 7.84% atari_drm_fb_blit_rect.isra.0
> 3.86% 3.86% 3.86% sys_copyarea <= not much hits for copying
> ...
> ----------------------------------------------------------------
So it would be worthwhile to factor out the code that is most
performance-critical into its own file, and use CFLAGS_foo.o += -O2
(or even -O3? or other options?) in the Makefile to build it with a
better optimization level.
> However, -O2 build has the downside that the resulting kernel Oopses
> once it reaches user-space, if 030 data cache emulation is enabled:
> ----------------------------------------------------------------
> Run /init as init process
> ...
> Instruction fault at 0x0041a256
> BAD KERNEL BUSERR
Interesting...
Thanks a lot for testing, and for your analysis!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Eero Tamminen @ 2025-05-27 22:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdUSADF51tBbGV=_nsxqyXgfNZcgDNGxuZ4F+tvYs9Q2aw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6319 bytes --]
Hi Geert,
On 25.5.2025 15.05, Geert Uytterhoeven wrote:
> On Thu, 22 May 2025 at 00:56, Eero Tamminen <oak@helsinkinet.fi> wrote:
>> On 21.5.2025 10.06, Geert Uytterhoeven wrote:
>>> I do keep it up-to-date locally, so I could provide these changes,
>>> if you are interested.
>>
>> Yes, please! (see below)
>
> Sorry for taking so long:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=atari-drm-wip-rebasing
Thanks!
I did boot testing on Hatari emulator with a minimal kernel config
having atari_drm enabled, atafb disabled, FB & boot logo enabled.
Under Falcon emulation:
- RGB/VGA => works fine
- Mono monitor => panic
"Kernel panic - not syncing: can't set default video mode"
Under TT emulation:
- RGB/VGA => boots, but console is black[1] (palette issue?)
- Mono monitor => looks OKish[2], but has constant warnings:
-----------------------------------
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1720
drm_atomic_helper_wait_for_vblanks+0x1a0/0x1ee
[CRTC:35:crtc-0] vblank wait timed out
-----------------------------------
Under 030 ST/STe emulation:
- RGB/VGA => boots, but console is black (palette issue?)
- Mono monitor => looks OK, but has constant slowpath warnings with:
"[CRTC:35:crtc-0] vblank wait timed out"
=> Any advice on the issues?
[1] Black when booted with (Hatari) LILO, all white when booted with
"bootstra.prg", meaning from TOS.
[2] Mono colors are black on white instead of vice verse, e.g. boot logo
colors are obviously inversed.
Note: the functional differences between ST, STE, TT and Falcon are all
accurately emulated in Hatari.
- Eero
PS. I also profiled where most of time goes from "atari-drm" probing,
until boot reaches user space. On a minimal -Os built kernel, running
on (emulated) 32Mhz 030 Falcon, in the default 640x480@4 resolution:
----------------------------------------------------------------
Time spent in profile = 15.29712s.
...
Used cycles:
22.37% 22.42% 25.35% _transp
19.15% 19.19% 46.82% atari_drm_fb_blit_rect.isra.0
8.09% 8.09% 13.80% sys_copyarea
3.94% 3.95% 6.23% sys_imageblit
3.69% 3.69% 3.69% fb_copy_offset.isra.0
2.12% 2.13% 2.41% atari_scsi_falcon_reg_read
2.03% 2.03% 2.03% fb_address_forward
1.85% 1.85% 17.98% fbcon_redraw_blit.constprop.0
1.81% 1.81% 2.04% atari_keyb_init
1.78% 1.78% 1.98% fb_reverse_long
1.58% 1.58% 1.90% arch_cpu_idle
1.05% memcpy
0.95% memset
...
----------------------------------------------------------------
=> atari-drm blitting takes half the time during boot.
Building kernel with -O2, changes above rather radically, both
time-wise, and where that time goes:
----------------------------------------------------------------
Time spent in profile = 6.54049s.
...
Used cycles:
17.61% 17.61% 17.61% sys_copyarea
11.18% 11.18% 13.11% arch_cpu_idle
7.53% 7.55% 8.45% atari_drm_fb_blit_rect.isra.0
4.26% 4.27% 4.76% atari_keyb_init
2.70% 2.70% 2.93% atari_scsi_falcon_reg_read
2.45% 2.45% 23.81% fbcon_redraw_blit.constprop.0
2.35% 2.35% 2.48% sys_imageblit
2.12% 2.12% 5.89% atari_floppy_init
1.97% memset
1.31% memcpy
...
Instruction cache misses:
27.14% 27.14% 27.14% sys_copyarea
3.77% 3.77% 4.05% atari_scsi_falcon_reg_read
...
Data cache hits:
63.55% 63.55% 63.67% atari_keyb_init
7.61% 7.62% 7.84% atari_drm_fb_blit_rect.isra.0
3.86% 3.86% 3.86% sys_copyarea <= not much hits for copying
...
----------------------------------------------------------------
However, -O2 build has the downside that the resulting kernel Oopses
once it reaches user-space, if 030 data cache emulation is enabled:
----------------------------------------------------------------
Run /init as init process
...
Instruction fault at 0x0041a256
BAD KERNEL BUSERR
Oops: 00000000
PC: [<0041a256>] __generic_copy_from_user+0x1e/0x46
SR: 2200 SP: (ptrval) a2: 011fe590
d0: 00000005 d1: 00000000 d2: 00000003 d3: 00000003
d4: 00000008 d5: 00000000 a0: eff70720 a1: 01225f9c
Process init (pid: 32, task=(ptrval))
Frame format=B ssw=5066 isc=5380 isb=66f6 daddr=eff7071c dobuf=00000000
baddr=eff7071c dibuf=eff7071c ver=0
Stack from 01225f78:
...
Call Trace: [<000409b0>] sys_rt_sigaction+0x32/0xc8
[<00005062>] req_need_defer+0x2a/0x3a
[<0000a4ca>] syscall+0x8/0xc
Code: 7403 c282 206e 000c 226e 0008 4a80 670a <0e98> 2000 22c2 5380 66f6
0801 0001 6706 0e58 2000 32c2 0801 0000 6706 0e18 2000
Disabling lock debugging due to kernel taint
Instruction fault at 0x00088ada
BAD KERNEL BUSERR
Oops: 00000000
PC: [<00088ada>] exit_robust_list+0x12/0xee
SR: 2200 SP: (ptrval) a2: 011fe590
d0: 00000000 d1: 00000000 d2: 011fe94e d3: 000000ff
d4: 00000000 d5: 00000000 a0: 011fe590 a1: 011e2b90
Process init (pid: 32, task=(ptrval))
Frame format=B ssw=5066 isc=660a isb=0eab daddr=801a206c dobuf=011fe94e
baddr=801a206c dibuf=801a206c ver=0
Stack from 01225dc8:
....
Call Trace: [<00003730>] _printk+0x0/0x16
[<000896ce>] futex_exit_release+0x9e/0xb8
[<00030186>] exit_mm_release+0x12/0x28
[<00034612>] do_exit+0x178/0x96e
[<00002200>] show_stack+0xce/0xf4
[<000691da>] vprintk+0x12/0x16
[<00034e84>] make_task_dead+0x7c/0x172
[<00005066>] req_need_defer+0x2e/0x3a
[<00003730>] _printk+0x0/0x16
[<0000d514>] die_if_kernel+0x0/0x22
[<0000d536>] trap_c+0x0/0x24c
[<0000ddaa>] buserr_c+0x628/0x756
[<0000a3f0>] buserr+0x20/0x28
[<00005066>] req_need_defer+0x2e/0x3a
[<0004097e>] sys_rt_sigaction+0x0/0xc8
[<00020007>] _FP_CALL_TOP+0x48e5/0xd512
[<00002000>] _start+0x0/0x6
[<000409b0>] sys_rt_sigaction+0x32/0xc8
[<00005062>] req_need_defer+0x2a/0x3a
[<0000a4ca>] syscall+0x8/0xc
----------------------------------------------------------------
My GCC is 12.2 in Debian bookworm, and "/init" is shell script run with
static Debian Busybox, to mount virtual file systems:
https://github.com/hatari/hatari/blob/main/tools/linux/init.sh
On an small system image built and used as documented here:
https://github.com/hatari/hatari/blob/main/doc/m68k-linux.txt
[-- Attachment #2: atari-drm-callgraph.png --]
[-- Type: image/png, Size: 46420 bytes --]
^ permalink raw reply
* [PATCH 6/6] staging: sm750fb: Rename local var `nDirection`
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename local variable `nDirection` to `n_direction` in
`sm750_hw_copyarea` to conform with kernel style guidelines as reported
by checkpatch.pl
CHECK: Avoid CamelCase: <nDirection>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index a34d8f6a033d..b9f90c934b7d 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -153,9 +153,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int width, unsigned int height,
unsigned int rop2)
{
- unsigned int nDirection, de_ctrl;
+ unsigned int n_direction, de_ctrl;
- nDirection = LEFT_TO_RIGHT;
+ n_direction = LEFT_TO_RIGHT;
/* Direction of ROP2 operation: 1 = Left to Right, (-1) = Right to Left */
de_ctrl = 0;
@@ -173,7 +173,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +----------+
*/
- nDirection = BOTTOM_TO_TOP;
+ n_direction = BOTTOM_TO_TOP;
} else if (sy > dy) {
/* +----------+
* |D |
@@ -185,7 +185,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +----------+
*/
- nDirection = TOP_TO_BOTTOM;
+ n_direction = TOP_TO_BOTTOM;
} else {
/* sy == dy */
@@ -198,7 +198,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +------+---+------+
*/
- nDirection = RIGHT_TO_LEFT;
+ n_direction = RIGHT_TO_LEFT;
} else {
/* sx > dx */
@@ -210,12 +210,12 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +------+---+------+
*/
- nDirection = LEFT_TO_RIGHT;
+ n_direction = LEFT_TO_RIGHT;
}
}
}
- if ((nDirection == BOTTOM_TO_TOP) || (nDirection == RIGHT_TO_LEFT)) {
+ if ((n_direction == BOTTOM_TO_TOP) || (n_direction == RIGHT_TO_LEFT)) {
sx += width - 1;
sy += height - 1;
dx += width - 1;
@@ -277,7 +277,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
(height & DE_DIMENSION_Y_ET_MASK)); /* dpr08 */
de_ctrl = (rop2 & DE_CONTROL_ROP_MASK) | DE_CONTROL_ROP_SELECT |
- ((nDirection == RIGHT_TO_LEFT) ? DE_CONTROL_DIRECTION : 0) |
+ ((n_direction == RIGHT_TO_LEFT) ? DE_CONTROL_DIRECTION : 0) |
DE_CONTROL_COMMAND_BITBLT | DE_CONTROL_STATUS;
write_dpr(accel, DE_CONTROL, de_ctrl); /* dpr0c */
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 5/6] staging: sm750fb: rename `Bpp` parameter
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename `Bpp` to `bpp` in `sm750_hw_copyarea` to conform with kernel
style guidelines.
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index ea64e10d4814..a34d8f6a033d 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @d_base: Address of destination: offset in frame buffer
* @d_pitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
unsigned int d_base, unsigned int d_pitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((d_pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((d_pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (s_pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (s_pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((d_pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((d_pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (s_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (s_pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 4/6] staging: sm750fb: rename `dPitch` parameter
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename `dPitch` to `d_pitch` in `sm750_hw_copyarea` to conform with
kernel style guidelines as reported by checkpatch.pl
CHECK: Avoid CamelCase: <dPitch>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index e5f1f021768b..ea64e10d4814 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -137,7 +137,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
* @d_base: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
+ * @d_pitch: Pitch value of destination surface in BYTE
* @Bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
@@ -148,7 +148,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
- unsigned int d_base, unsigned int dPitch,
+ unsigned int d_base, unsigned int d_pitch,
unsigned int Bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
@@ -160,7 +160,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
de_ctrl = 0;
/* If source and destination are the same surface, need to check for overlay cases */
- if (s_base == d_base && s_pitch == dPitch) {
+ if (s_base == d_base && s_pitch == d_pitch) {
/* Determine direction of operation */
if (sy < dy) {
/* +----------+
@@ -249,7 +249,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((d_pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
(s_pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
@@ -259,7 +259,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((d_pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
(s_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 3/6] staging: sm750fb: rename `dBase` parameter
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename `dBase` to `d_base` in `sm750_hw_copyarea` to conform with kernel
style guidelines as reported by checkpatch.pl
CHECK: Avoid CamelCase: <dBase>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 029f5c013d91..e5f1f021768b 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -136,7 +136,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @s_pitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
- * @dBase: Address of destination: offset in frame buffer
+ * @d_base: Address of destination: offset in frame buffer
* @dPitch: Pitch value of destination surface in BYTE
* @Bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
@@ -148,7 +148,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
+ unsigned int d_base, unsigned int dPitch,
unsigned int Bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
@@ -160,7 +160,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
de_ctrl = 0;
/* If source and destination are the same surface, need to check for overlay cases */
- if (s_base == dBase && s_pitch == dPitch) {
+ if (s_base == d_base && s_pitch == dPitch) {
/* Determine direction of operation */
if (sy < dy) {
/* +----------+
@@ -241,7 +241,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* It is an address offset (128 bit aligned)
* from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase); /* dpr44 */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, d_base); /* dpr44 */
/*
* Program pitch (distance between the 1st points of two adjacent lines).
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 2/6] staging: sm750fb: rename `sPitch` parameter
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename `sPitch` to `s_pitch` in `sm750_hw_copyarea` to conform with
kernel style guidelines as reported by checkpatch.pl
CHECK: Avoid CamelCase: <sPitch>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 74e4be8103ac..029f5c013d91 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -133,7 +133,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* sm750_hw_copyarea
* @accel: Acceleration device data
* @s_base: Address of source: offset in frame buffer
- * @sPitch: Pitch value of source surface in BYTE
+ * @s_pitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
* @dBase: Address of destination: offset in frame buffer
@@ -146,7 +146,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int s_base, unsigned int sPitch,
+ unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
unsigned int Bpp, unsigned int dx, unsigned int dy,
@@ -160,7 +160,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
de_ctrl = 0;
/* If source and destination are the same surface, need to check for overlay cases */
- if (s_base == dBase && sPitch == dPitch) {
+ if (s_base == dBase && s_pitch == dPitch) {
/* Determine direction of operation */
if (sy < dy) {
/* +----------+
@@ -251,7 +251,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
write_dpr(accel, DE_PITCH,
((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (s_pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -261,7 +261,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_WIDTH,
((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (s_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 1/6] staging: sm750fb: rename `sBase` parameter
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
In-Reply-To: <cover.1748365488.git.ericflorin@google.com>
Rename `sBase` to `s_base` in `sm750_hw_copyarea` to conform with style
guidelines as reported by checkpatch.pl
CHECK: Avoid CamelCase: <sBase>
Signed-off-by: Eric Florin <ericflorin@google.com>
---
drivers/staging/sm750fb/sm750_accel.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 44b9e3fe3a41..74e4be8103ac 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -132,7 +132,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
/**
* sm750_hw_copyarea
* @accel: Acceleration device data
- * @sBase: Address of source: offset in frame buffer
+ * @s_base: Address of source: offset in frame buffer
* @sPitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
@@ -146,7 +146,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int sBase, unsigned int sPitch,
+ unsigned int s_base, unsigned int sPitch,
unsigned int sx, unsigned int sy,
unsigned int dBase, unsigned int dPitch,
unsigned int Bpp, unsigned int dx, unsigned int dy,
@@ -160,7 +160,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
de_ctrl = 0;
/* If source and destination are the same surface, need to check for overlay cases */
- if (sBase == dBase && sPitch == dPitch) {
+ if (s_base == dBase && sPitch == dPitch) {
/* Determine direction of operation */
if (sy < dy) {
/* +----------+
@@ -234,7 +234,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* It is an address offset (128 bit aligned)
* from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase); /* dpr40 */
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, s_base); /* dpr40 */
/*
* 2D Destination Base.
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply related
* [PATCH 0/6] staging: sm750fb: cleanup `sm750_hw_copyarea`
From: Eric Florin @ 2025-05-27 17:11 UTC (permalink / raw)
To: teddy.wang
Cc: sudipm.mukherjee, gregkh, linux-fbdev, linux-staging,
linux-kernel, Eric Florin
This patchset covers style cleanups in `sm750_hw_copyarea` defined in
`drivers/staging/sm750fb/sm750_accel.c`
PATCH #1: staging: sm750fb: rename `sBase` parameter
PATCH #2: staging: sm750fb: rename `sPitch` parameter
PATCH #3: staging: sm750fb: rename `dBase` parameter
PATCH #4: staging: sm750fb: rename `dPitch` parameter
PATCH #5: staging: sm750fb: rename `Bpp` parameter
PATCH #6: staging: sm750fb: Rename local var `nDirection`
Eric Florin (6):
staging: sm750fb: rename `sBase` parameter
staging: sm750fb: rename `sPitch` parameter
staging: sm750fb: rename `dBase` parameter
staging: sm750fb: rename `dPitch` parameter
staging: sm750fb: rename `Bpp` parameter
staging: sm750fb: Rename local var `nDirection`
drivers/staging/sm750fb/sm750_accel.c | 46 +++++++++++++--------------
1 file changed, 23 insertions(+), 23 deletions(-)
--
2.49.0.1151.ga128411c76-goog
^ permalink raw reply
* Re: [PATCH] Documentation : fb : sstfb.rst : Fixed spelling mistake.
From: Helge Deller @ 2025-05-27 8:00 UTC (permalink / raw)
To: rujra, Jonathan Corbet; +Cc: linux-fbdev, dri-devel, linux-doc, linux-kernel
In-Reply-To: <CAG+54DaA4ni5g26AFKGe76-AgFeMy4GUVopgMQukeaJ_bPWDRQ@mail.gmail.com>
On 5/19/25 16:38, rujra wrote:
> fixed document with spelling mistake
> changes made :
> 1. "tweeks" to "tweaks"
>
> Signed-off-by: Rujra Bhatt <braker.noob.kernel@gmail.com>
applied to fbdev tree with small changes...
Thanks!
Helge
> Documentation/fb/sstfb.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
> index 88d5a52b1..6cefa974a 100644
> --- a/Documentation/fb/sstfb.rst
> +++ b/Documentation/fb/sstfb.rst
> @@ -192,7 +192,7 @@ Todo
> - Get rid of the previous paragraph.
> - Buy more coffee.
> - test/port to other arch.
> -- try to add panning using tweeks with front and back buffer .
> +- try to add panning using tweaks with front and back buffer .
> - try to implement accel on voodoo2, this board can actually do a
> lot in 2D even if it was sold as a 3D only board ...
>
> --
> 2.43.0
^ permalink raw reply
* Re: [RFC PATCH 1/2] backlight: Rename duplicated devices to support dual-backlight setups
From: Jani Nikula @ 2025-05-26 8:53 UTC (permalink / raw)
To: Pengyu Luo, Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
Cc: dri-devel, linux-fbdev, linux-kernel, Pengyu Luo
In-Reply-To: <20250525104022.1326997-1-mitltlatltl@gmail.com>
On Sun, 25 May 2025, Pengyu Luo <mitltlatltl@gmail.com> wrote:
> When registering a backlight device, if a device with the same name
> already exists, append "-secondary" to the new device's name. This is
> useful for platforms with dual backlight drivers (e.g. some panels use
> dual ktz8866), where both instances need to coexist.
>
> For now, only one secondary instance is supported. If more instances
> are needed, this logic can be extended with auto-increment or a more
> flexible naming scheme.
I think for both patches you should consider adding a new interface for
creating dual backlight scenarios.
For example, this patch turns a driver error (registering two or more
backlights with the same name) into a special use case, patch 2
magically connecting the two, and hiding the problem.
With i915, you could have multiple devices, each with multiple
independent panels with independent backlights. I think accidentally
trying to register more than one backlight with the same name should
remain an error, *unless* you want the special case of combined
backlights.
Similarly, what if you encounter a device with two panels, and two
*independent* ktz8866?
Please be explicit rather than implicit.
BR,
Jani.
>
> Suggested-by: Daniel Thompson <danielt@kernel.org>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
> drivers/video/backlight/backlight.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 9dc93c5e4..991702f5d 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -365,7 +365,8 @@ struct backlight_device *backlight_device_register(const char *name,
> struct device *parent, void *devdata, const struct backlight_ops *ops,
> const struct backlight_properties *props)
> {
> - struct backlight_device *new_bd;
> + struct backlight_device *new_bd, *prev_bd;
> + const char *new_name = NULL;
> int rc;
>
> pr_debug("backlight_device_register: name=%s\n", name);
> @@ -377,10 +378,23 @@ struct backlight_device *backlight_device_register(const char *name,
> mutex_init(&new_bd->update_lock);
> mutex_init(&new_bd->ops_lock);
>
> + /*
> + * If there is an instance with the same name already, then rename it.
> + * We also can use an auto-increment field, but it seems that there is
> + * no triple or quad case.
> + */
> + prev_bd = backlight_device_get_by_name(name);
> + if (!IS_ERR_OR_NULL(prev_bd)) {
> + new_name = kasprintf(GFP_KERNEL, "%s-secondary", name);
> + if (!new_name)
> + return ERR_PTR(-ENOMEM);
> + put_device(&prev_bd->dev);
> + }
> +
> new_bd->dev.class = &backlight_class;
> new_bd->dev.parent = parent;
> new_bd->dev.release = bl_device_release;
> - dev_set_name(&new_bd->dev, "%s", name);
> + dev_set_name(&new_bd->dev, "%s", new_name ? new_name : name);
> dev_set_drvdata(&new_bd->dev, devdata);
>
> /* Set default properties */
> @@ -414,6 +428,8 @@ struct backlight_device *backlight_device_register(const char *name,
> list_add(&new_bd->entry, &backlight_dev_list);
> mutex_unlock(&backlight_dev_list_mutex);
>
> + kfree(new_name);
> +
> return new_bd;
> }
> EXPORT_SYMBOL(backlight_device_register);
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Christoph Hellwig @ 2025-05-26 6:54 UTC (permalink / raw)
To: mhklinux
Cc: simona, deller, haiyangz, kys, wei.liu, decui, akpm, weh,
tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250523161522.409504-4-mhklinux@outlook.com>
On Fri, May 23, 2025 at 09:15:21AM -0700, mhkelley58@gmail.com wrote:
> Commit 37b4837959cb ("video: deferred io with physically contiguous
> memory") from the year 2008 purported to add support for contiguous
> kernel memory framebuffers. The motivating device, sh_mobile_lcdcfb, uses
> dma_alloc_coherent() to allocate framebuffer memory, which is likely to
> use alloc_pages(). It's unclear to me how this commit actually worked at
> the time, unless dma_alloc_coherent() was pulling from a CMA pool instead
> of alloc_pages(). Or perhaps alloc_pages() worked differently or on the
> arm32 architecture on which sh_mobile_lcdcfb is used.
>
> In any case, for x86 and arm64 today, commit 37b4837959cb9 is not
> sufficient to support contiguous kernel memory framebuffers. The problem
> can be seen with the hyperv_fb driver, which may allocate the framebuffer
> memory using vmalloc() or alloc_pages(), depending on the configuration
> of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer.
That langugage is far too nice. The existing users of fb_defio are
all gravely broken because they violate the dma API restriction to
not poke into the memory. You can't speculate what you get from
dma_alloc_coherent and it can change behind you all the time.
> Fix this limitation by adding defio support for contiguous kernel memory
> framebuffers. A driver with a framebuffer allocated from contiguous
> kernel memory must set the FBINFO_KMEMFB flag to indicate such.
Honestly, the right thing is to invert the flag. What hypervs is doing
here - take kernel memory in the direct mapping or from vmalloc is fine.
What others drivers do it completely broken crap. So add a flag
FBINFO_BROKEN_CRAP to maybe keep the guessing. Or just disable it
because it's dangerous.
^ permalink raw reply
* Re: [PATCH/RFC 0/3] Atari DRM driver
From: Geert Uytterhoeven @ 2025-05-25 12:05 UTC (permalink / raw)
To: Eero Tamminen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Helge Deller, Michael Schmitz, dri-devel,
linux-fbdev, linux-m68k, John Paul Adrian Glaubitz
In-Reply-To: <beed53f4-b0d6-4d1d-b5ec-2694d2b5d47a@helsinkinet.fi>
Hi Eero,
On Thu, 22 May 2025 at 00:56, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 21.5.2025 10.06, Geert Uytterhoeven wrote:
> > On Wed, 21 May 2025 at 01:59, Eero Tamminen <oak@helsinkinet.fi> wrote:
> >> I tried your "atari-drm-wip-v1" branch commits on top of 6.14.
> >
> > Thanks for testing!
> >
> >> After some minor changes those applied. Getting it to build required
> >> adding "&shadow_plane_state->fmtcnv_state" (struct drm_format_conv_state
> >> *) argument to *_blit() functions in atari_drm.c, and changing:
> >> drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
> >> in its probe function to:
> >> struct drm_format_info *format = NULL;
> >> drm_client_setup(dev, format);
> >
> > I do keep it up-to-date locally, so I could provide these changes,
> > if you are interested.
>
> Yes, please! (see below)
Sorry for taking so long:
https://web.git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=atari-drm-wip-rebasing
Enjoy!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RFC PATCH 2/2] backlight: Improve support for dual backlight with primary/secondary linkage
From: Pengyu Luo @ 2025-05-25 10:40 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
Cc: dri-devel, linux-fbdev, linux-kernel, Pengyu Luo
In-Reply-To: <20250525104022.1326997-1-mitltlatltl@gmail.com>
This patch enhances dual-backlight handling by explicitly linking
primary and secondary backlight devices using new fields:
- `is_secondary`: Marks if a device is secondary in a pair
- `secondary`: Points to the associated secondary device (if any)
- `primary`: Points to the primary device (for secondary devices)
It also update `backlight_update_status()` to ensure that both primary
and secondary devices are updated together during brightness changes.
This provides a consistent update mechanism in dual-backlight case.
Suggested-by: Daniel Thompson <danielt@kernel.org>
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
drivers/video/backlight/backlight.c | 9 +++++-
include/linux/backlight.h | 50 +++++++++++++++++++++++++++--
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 991702f5d..2e7b179bc 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -388,7 +388,6 @@ struct backlight_device *backlight_device_register(const char *name,
new_name = kasprintf(GFP_KERNEL, "%s-secondary", name);
if (!new_name)
return ERR_PTR(-ENOMEM);
- put_device(&prev_bd->dev);
}
new_bd->dev.class = &backlight_class;
@@ -428,6 +427,14 @@ struct backlight_device *backlight_device_register(const char *name,
list_add(&new_bd->entry, &backlight_dev_list);
mutex_unlock(&backlight_dev_list_mutex);
+ /* set them until the secondary device is available */
+ if (prev_bd) {
+ prev_bd->secondary = new_bd;
+ new_bd->primary = prev_bd;
+ new_bd->is_secondary = true;
+ put_device(&prev_bd->dev);
+ }
+
kfree(new_name);
return new_bd;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 10e626db7..cde992e10 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -291,13 +291,42 @@ struct backlight_device {
* @use_count: The number of unblanked displays.
*/
int use_count;
+
+ /**
+ * @is_secondary: Indicates whether this backlight device is secondary.
+ */
+ bool is_secondary;
+
+ /**
+ * @secondary: Pointer to the secondary backlight device.
+ */
+ struct backlight_device *secondary;
+
+ /**
+ * @primary: Pointer to the primary backlight device.
+ *
+ * Non-NULL only for secondary devices.
+ */
+ struct backlight_device *primary;
};
+static inline struct backlight_device *
+to_primary_backlight_device(struct backlight_device *bd)
+{
+ return bd->is_secondary ? bd->primary : bd;
+}
+
+static inline struct backlight_device *
+to_secondary_backlight_device(struct backlight_device *bd)
+{
+ return bd->is_secondary ? bd : bd->secondary;
+}
+
/**
- * backlight_update_status - force an update of the backlight device status
+ * backlight_update_status_single - force an update of the backlight device status
* @bd: the backlight device
*/
-static inline int backlight_update_status(struct backlight_device *bd)
+static inline int backlight_update_status_single(struct backlight_device *bd)
{
int ret = -ENOENT;
@@ -309,6 +338,23 @@ static inline int backlight_update_status(struct backlight_device *bd)
return ret;
}
+/**
+ * backlight_update_status - update primary and secondary backlight devices
+ * @bd: the backlight device
+ */
+static inline int backlight_update_status(struct backlight_device *bd)
+{
+ struct backlight_device *primary = to_primary_backlight_device(bd);
+ struct backlight_device *secondary = to_secondary_backlight_device(bd);
+ int ret;
+
+ ret = backlight_update_status_single(primary);
+ if (!secondary || ret)
+ return ret;
+
+ return backlight_update_status_single(secondary);
+}
+
/**
* backlight_enable - Enable backlight
* @bd: the backlight device to enable
--
2.49.0
^ permalink raw reply related
* [RFC PATCH 1/2] backlight: Rename duplicated devices to support dual-backlight setups
From: Pengyu Luo @ 2025-05-25 10:40 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
Cc: dri-devel, linux-fbdev, linux-kernel, Pengyu Luo
When registering a backlight device, if a device with the same name
already exists, append "-secondary" to the new device's name. This is
useful for platforms with dual backlight drivers (e.g. some panels use
dual ktz8866), where both instances need to coexist.
For now, only one secondary instance is supported. If more instances
are needed, this logic can be extended with auto-increment or a more
flexible naming scheme.
Suggested-by: Daniel Thompson <danielt@kernel.org>
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
---
drivers/video/backlight/backlight.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 9dc93c5e4..991702f5d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -365,7 +365,8 @@ struct backlight_device *backlight_device_register(const char *name,
struct device *parent, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props)
{
- struct backlight_device *new_bd;
+ struct backlight_device *new_bd, *prev_bd;
+ const char *new_name = NULL;
int rc;
pr_debug("backlight_device_register: name=%s\n", name);
@@ -377,10 +378,23 @@ struct backlight_device *backlight_device_register(const char *name,
mutex_init(&new_bd->update_lock);
mutex_init(&new_bd->ops_lock);
+ /*
+ * If there is an instance with the same name already, then rename it.
+ * We also can use an auto-increment field, but it seems that there is
+ * no triple or quad case.
+ */
+ prev_bd = backlight_device_get_by_name(name);
+ if (!IS_ERR_OR_NULL(prev_bd)) {
+ new_name = kasprintf(GFP_KERNEL, "%s-secondary", name);
+ if (!new_name)
+ return ERR_PTR(-ENOMEM);
+ put_device(&prev_bd->dev);
+ }
+
new_bd->dev.class = &backlight_class;
new_bd->dev.parent = parent;
new_bd->dev.release = bl_device_release;
- dev_set_name(&new_bd->dev, "%s", name);
+ dev_set_name(&new_bd->dev, "%s", new_name ? new_name : name);
dev_set_drvdata(&new_bd->dev, devdata);
/* Set default properties */
@@ -414,6 +428,8 @@ struct backlight_device *backlight_device_register(const char *name,
list_add(&new_bd->entry, &backlight_dev_list);
mutex_unlock(&backlight_dev_list_mutex);
+ kfree(new_name);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
--
2.49.0
^ permalink raw reply related
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