* FAILED: Patch "fbcon: check return value of con2fb_acquire_newinfo()" failed to apply to 6.1-stable tree
From: Sasha Levin @ 2026-03-01 1:47 UTC (permalink / raw)
To: stable, a.vatoropin; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 011a0502801c8536f64141a2b61362c14f456544 Mon Sep 17 00:00:00 2001
From: Andrey Vatoropin <a.vatoropin@crpt.ru>
Date: Wed, 17 Dec 2025 09:11:05 +0000
Subject: [PATCH] fbcon: check return value of con2fb_acquire_newinfo()
If fbcon_open() fails when called from con2fb_acquire_newinfo() then
info->fbcon_par pointer remains NULL which is later dereferenced.
Add check for return value of the function con2fb_acquire_newinfo() to
avoid it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 34ea14412ace1..36e380797a9e4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1068,7 +1068,8 @@ static void fbcon_init(struct vc_data *vc, bool init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num);
+ if (con2fb_acquire_newinfo(vc, info, vc->vc_num))
+ return;
/* If we are not the first console on this
fb, copy the font from that console */
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: ffb: fix corrupted video output on Sun FFB1" failed to apply to 6.1-stable tree
From: Sasha Levin @ 2026-03-01 1:47 UTC (permalink / raw)
To: stable, rene; +Cc: stable, Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From b28da0d092461ac239ff034a8ac3129320177ba3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ren=C3=A9=20Rebe?= <rene@exactco.de>
Date: Thu, 5 Feb 2026 16:49:58 +0100
Subject: [PATCH] fbdev: ffb: fix corrupted video output on Sun FFB1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and
initializing window mode to a known state. The issue never appeared on
my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM
version.
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4]
X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered.
X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control)
X (II) /dev/fb0: Detected Creator/Creator3D
[1] https://www.instagram.com/p/DUTcSmSjSem/
[2] https://chaos.social/@ReneRebe/116023241660154102
Signed-off-by: René Rebe <rene@exactco.de>
Cc: stable@kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/ffb.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c
index 34b6abff9493e..da531b4cb4513 100644
--- a/drivers/video/fbdev/ffb.c
+++ b/drivers/video/fbdev/ffb.c
@@ -335,6 +335,9 @@ struct ffb_dac {
};
#define FFB_DAC_UCTRL 0x1001 /* User Control */
+#define FFB_DAC_UCTRL_OVENAB 0x00000008 /* Overlay Enable */
+#define FFB_DAC_UCTRL_WMODE 0x00000030 /* Window Mode */
+#define FFB_DAC_UCTRL_WM_COMB 0x00000000 /* Window Mode = Combined */
#define FFB_DAC_UCTRL_MANREV 0x00000f00 /* 4-bit Manufacturing Revision */
#define FFB_DAC_UCTRL_MANREV_SHIFT 8
#define FFB_DAC_TGEN 0x6000 /* Timing Generator */
@@ -425,7 +428,7 @@ static void ffb_switch_from_graph(struct ffb_par *par)
{
struct ffb_fbc __iomem *fbc = par->fbc;
struct ffb_dac __iomem *dac = par->dac;
- unsigned long flags;
+ unsigned long flags, uctrl;
spin_lock_irqsave(&par->lock, flags);
FFBWait(par);
@@ -450,6 +453,15 @@ static void ffb_switch_from_graph(struct ffb_par *par)
upa_writel((FFB_DAC_CUR_CTRL_P0 |
FFB_DAC_CUR_CTRL_P1), &dac->value2);
+ /* Disable overlay and window modes. */
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ uctrl = upa_readl(&dac->value);
+ uctrl &= ~FFB_DAC_UCTRL_WMODE;
+ uctrl |= FFB_DAC_UCTRL_WM_COMB;
+ uctrl &= ~FFB_DAC_UCTRL_OVENAB;
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ upa_writel(uctrl, &dac->value);
+
spin_unlock_irqrestore(&par->lock, flags);
}
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: of: display_timing: fix refcount leak in of_get_display_timings()" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:39 UTC (permalink / raw)
To: stable, geoffreyhe2; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 Mon Sep 17 00:00:00 2001
From: Weigang He <geoffreyhe2@gmail.com>
Date: Fri, 16 Jan 2026 09:57:51 +0000
Subject: [PATCH] fbdev: of: display_timing: fix refcount leak in
of_get_display_timings()
of_parse_phandle() returns a device_node with refcount incremented,
which is stored in 'entry' and then copied to 'native_mode'. When the
error paths at lines 184 or 192 jump to 'entryfail', native_mode's
refcount is not decremented, causing a refcount leak.
Fix this by changing the goto target from 'entryfail' to 'timingfail',
which properly calls of_node_put(native_mode) before cleanup.
Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode")
Cc: stable@vger.kernel.org
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/of_display_timing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index bebd371c6b93e..1940c9505dd3b 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -181,7 +181,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
if (disp->num_timings == 0) {
/* should never happen, as entry was already found above */
pr_err("%pOF: no timings specified\n", np);
- goto entryfail;
+ goto timingfail;
}
disp->timings = kcalloc(disp->num_timings,
@@ -189,7 +189,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
GFP_KERNEL);
if (!disp->timings) {
pr_err("%pOF: could not allocate timings array\n", np);
- goto entryfail;
+ goto timingfail;
}
disp->num_timings = 0;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: vt8500lcdfb: fix missing dma_free_coherent()" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:39 UTC (permalink / raw)
To: stable, fourier.thomas
Cc: Helge Deller, linux-arm-kernel, linux-fbdev, dri-devel
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 88b3b9924337336a31cefbe99a22ed09401be74a Mon Sep 17 00:00:00 2001
From: Thomas Fourier <fourier.thomas@gmail.com>
Date: Mon, 12 Jan 2026 15:00:27 +0100
Subject: [PATCH] fbdev: vt8500lcdfb: fix missing dma_free_coherent()
fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not
freed if the error path is reached.
Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/vt8500lcdfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
index b08a6fdc53fd2..85c7a99a7d648 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
if (fbi->palette_cpu == NULL) {
dev_err(&pdev->dev, "Failed to allocate palette buffer\n");
ret = -ENOMEM;
- goto failed_free_io;
+ goto failed_free_mem_virt;
}
irq = platform_get_irq(pdev, 0);
@@ -432,6 +432,9 @@ static int vt8500lcd_probe(struct platform_device *pdev)
failed_free_palette:
dma_free_coherent(&pdev->dev, fbi->palette_size,
fbi->palette_cpu, fbi->palette_phys);
+failed_free_mem_virt:
+ dma_free_coherent(&pdev->dev, fbi->fb.fix.smem_len,
+ fbi->fb.screen_buffer, fbi->fb.fix.smem_start);
failed_free_io:
iounmap(fbi->regbase);
failed_free_res:
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbcon: check return value of con2fb_acquire_newinfo()" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:39 UTC (permalink / raw)
To: stable, a.vatoropin; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 011a0502801c8536f64141a2b61362c14f456544 Mon Sep 17 00:00:00 2001
From: Andrey Vatoropin <a.vatoropin@crpt.ru>
Date: Wed, 17 Dec 2025 09:11:05 +0000
Subject: [PATCH] fbcon: check return value of con2fb_acquire_newinfo()
If fbcon_open() fails when called from con2fb_acquire_newinfo() then
info->fbcon_par pointer remains NULL which is later dereferenced.
Add check for return value of the function con2fb_acquire_newinfo() to
avoid it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 34ea14412ace1..36e380797a9e4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1068,7 +1068,8 @@ static void fbcon_init(struct vc_data *vc, bool init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num);
+ if (con2fb_acquire_newinfo(vc, info, vc->vc_num))
+ return;
/* If we are not the first console on this
fb, copy the font from that console */
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbcon: Remove struct fbcon_display.inverse" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:38 UTC (permalink / raw)
To: stable, tzimmermann; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 30baedeeeab524172abc0b58cb101e8df86b5be8 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 9 Feb 2026 17:15:43 +0100
Subject: [PATCH] fbcon: Remove struct fbcon_display.inverse
The field inverse in struct fbcon_display is unused. Remove it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v6.0+
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/core/fbcon.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 1cd10a7faab0f..fca14e9b729b9 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -30,7 +30,6 @@ struct fbcon_display {
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
u_short scrollmode; /* Scroll Method, use fb_scrollmode() */
#endif
- u_short inverse; /* != 0 text black on white as default */
short yscroll; /* Hardware scrolling */
int vrows; /* number of virtual rows */
int cursor_shape;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: ffb: fix corrupted video output on Sun FFB1" failed to apply to 6.6-stable tree
From: Sasha Levin @ 2026-03-01 1:38 UTC (permalink / raw)
To: stable, rene; +Cc: stable, Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From b28da0d092461ac239ff034a8ac3129320177ba3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ren=C3=A9=20Rebe?= <rene@exactco.de>
Date: Thu, 5 Feb 2026 16:49:58 +0100
Subject: [PATCH] fbdev: ffb: fix corrupted video output on Sun FFB1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and
initializing window mode to a known state. The issue never appeared on
my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM
version.
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4]
X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered.
X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control)
X (II) /dev/fb0: Detected Creator/Creator3D
[1] https://www.instagram.com/p/DUTcSmSjSem/
[2] https://chaos.social/@ReneRebe/116023241660154102
Signed-off-by: René Rebe <rene@exactco.de>
Cc: stable@kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/ffb.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c
index 34b6abff9493e..da531b4cb4513 100644
--- a/drivers/video/fbdev/ffb.c
+++ b/drivers/video/fbdev/ffb.c
@@ -335,6 +335,9 @@ struct ffb_dac {
};
#define FFB_DAC_UCTRL 0x1001 /* User Control */
+#define FFB_DAC_UCTRL_OVENAB 0x00000008 /* Overlay Enable */
+#define FFB_DAC_UCTRL_WMODE 0x00000030 /* Window Mode */
+#define FFB_DAC_UCTRL_WM_COMB 0x00000000 /* Window Mode = Combined */
#define FFB_DAC_UCTRL_MANREV 0x00000f00 /* 4-bit Manufacturing Revision */
#define FFB_DAC_UCTRL_MANREV_SHIFT 8
#define FFB_DAC_TGEN 0x6000 /* Timing Generator */
@@ -425,7 +428,7 @@ static void ffb_switch_from_graph(struct ffb_par *par)
{
struct ffb_fbc __iomem *fbc = par->fbc;
struct ffb_dac __iomem *dac = par->dac;
- unsigned long flags;
+ unsigned long flags, uctrl;
spin_lock_irqsave(&par->lock, flags);
FFBWait(par);
@@ -450,6 +453,15 @@ static void ffb_switch_from_graph(struct ffb_par *par)
upa_writel((FFB_DAC_CUR_CTRL_P0 |
FFB_DAC_CUR_CTRL_P1), &dac->value2);
+ /* Disable overlay and window modes. */
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ uctrl = upa_readl(&dac->value);
+ uctrl &= ~FFB_DAC_UCTRL_WMODE;
+ uctrl |= FFB_DAC_UCTRL_WM_COMB;
+ uctrl &= ~FFB_DAC_UCTRL_OVENAB;
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ upa_writel(uctrl, &dac->value);
+
spin_unlock_irqrestore(&par->lock, flags);
}
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: of: display_timing: fix refcount leak in of_get_display_timings()" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, geoffreyhe2; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From eacf9840ae1285a1ef47eb0ce16d786e542bd4d7 Mon Sep 17 00:00:00 2001
From: Weigang He <geoffreyhe2@gmail.com>
Date: Fri, 16 Jan 2026 09:57:51 +0000
Subject: [PATCH] fbdev: of: display_timing: fix refcount leak in
of_get_display_timings()
of_parse_phandle() returns a device_node with refcount incremented,
which is stored in 'entry' and then copied to 'native_mode'. When the
error paths at lines 184 or 192 jump to 'entryfail', native_mode's
refcount is not decremented, causing a refcount leak.
Fix this by changing the goto target from 'entryfail' to 'timingfail',
which properly calls of_node_put(native_mode) before cleanup.
Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode")
Cc: stable@vger.kernel.org
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/of_display_timing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index bebd371c6b93e..1940c9505dd3b 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -181,7 +181,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
if (disp->num_timings == 0) {
/* should never happen, as entry was already found above */
pr_err("%pOF: no timings specified\n", np);
- goto entryfail;
+ goto timingfail;
}
disp->timings = kcalloc(disp->num_timings,
@@ -189,7 +189,7 @@ struct display_timings *of_get_display_timings(const struct device_node *np)
GFP_KERNEL);
if (!disp->timings) {
pr_err("%pOF: could not allocate timings array\n", np);
- goto entryfail;
+ goto timingfail;
}
disp->num_timings = 0;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: vt8500lcdfb: fix missing dma_free_coherent()" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, fourier.thomas
Cc: Helge Deller, linux-arm-kernel, linux-fbdev, dri-devel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 88b3b9924337336a31cefbe99a22ed09401be74a Mon Sep 17 00:00:00 2001
From: Thomas Fourier <fourier.thomas@gmail.com>
Date: Mon, 12 Jan 2026 15:00:27 +0100
Subject: [PATCH] fbdev: vt8500lcdfb: fix missing dma_free_coherent()
fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not
freed if the error path is reached.
Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/vt8500lcdfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
index b08a6fdc53fd2..85c7a99a7d648 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
if (fbi->palette_cpu == NULL) {
dev_err(&pdev->dev, "Failed to allocate palette buffer\n");
ret = -ENOMEM;
- goto failed_free_io;
+ goto failed_free_mem_virt;
}
irq = platform_get_irq(pdev, 0);
@@ -432,6 +432,9 @@ static int vt8500lcd_probe(struct platform_device *pdev)
failed_free_palette:
dma_free_coherent(&pdev->dev, fbi->palette_size,
fbi->palette_cpu, fbi->palette_phys);
+failed_free_mem_virt:
+ dma_free_coherent(&pdev->dev, fbi->fb.fix.smem_len,
+ fbi->fb.screen_buffer, fbi->fb.fix.smem_start);
failed_free_io:
iounmap(fbi->regbase);
failed_free_res:
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbcon: check return value of con2fb_acquire_newinfo()" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, a.vatoropin; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 011a0502801c8536f64141a2b61362c14f456544 Mon Sep 17 00:00:00 2001
From: Andrey Vatoropin <a.vatoropin@crpt.ru>
Date: Wed, 17 Dec 2025 09:11:05 +0000
Subject: [PATCH] fbcon: check return value of con2fb_acquire_newinfo()
If fbcon_open() fails when called from con2fb_acquire_newinfo() then
info->fbcon_par pointer remains NULL which is later dereferenced.
Add check for return value of the function con2fb_acquire_newinfo() to
avoid it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d1baa4ffa677 ("fbcon: set_con2fb_map fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru>
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 34ea14412ace1..36e380797a9e4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1068,7 +1068,8 @@ static void fbcon_init(struct vc_data *vc, bool init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num);
+ if (con2fb_acquire_newinfo(vc, info, vc->vc_num))
+ return;
/* If we are not the first console on this
fb, copy the font from that console */
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbcon: Remove struct fbcon_display.inverse" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, tzimmermann; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 30baedeeeab524172abc0b58cb101e8df86b5be8 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 9 Feb 2026 17:15:43 +0100
Subject: [PATCH] fbcon: Remove struct fbcon_display.inverse
The field inverse in struct fbcon_display is unused. Remove it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org> # v6.0+
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/core/fbcon.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 1cd10a7faab0f..fca14e9b729b9 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -30,7 +30,6 @@ struct fbcon_display {
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
u_short scrollmode; /* Scroll Method, use fb_scrollmode() */
#endif
- u_short inverse; /* != 0 text black on white as default */
short yscroll; /* Hardware scrolling */
int vrows; /* number of virtual rows */
int cursor_shape;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "fbdev: ffb: fix corrupted video output on Sun FFB1" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, rene; +Cc: stable, Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From b28da0d092461ac239ff034a8ac3129320177ba3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ren=C3=A9=20Rebe?= <rene@exactco.de>
Date: Thu, 5 Feb 2026 16:49:58 +0100
Subject: [PATCH] fbdev: ffb: fix corrupted video output on Sun FFB1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fix Sun FFB1 corrupted video out ([1] and [2]) by disabling overlay and
initializing window mode to a known state. The issue never appeared on
my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM
version.
/SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4]
X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered.
X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control)
X (II) /dev/fb0: Detected Creator/Creator3D
[1] https://www.instagram.com/p/DUTcSmSjSem/
[2] https://chaos.social/@ReneRebe/116023241660154102
Signed-off-by: René Rebe <rene@exactco.de>
Cc: stable@kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
---
drivers/video/fbdev/ffb.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c
index 34b6abff9493e..da531b4cb4513 100644
--- a/drivers/video/fbdev/ffb.c
+++ b/drivers/video/fbdev/ffb.c
@@ -335,6 +335,9 @@ struct ffb_dac {
};
#define FFB_DAC_UCTRL 0x1001 /* User Control */
+#define FFB_DAC_UCTRL_OVENAB 0x00000008 /* Overlay Enable */
+#define FFB_DAC_UCTRL_WMODE 0x00000030 /* Window Mode */
+#define FFB_DAC_UCTRL_WM_COMB 0x00000000 /* Window Mode = Combined */
#define FFB_DAC_UCTRL_MANREV 0x00000f00 /* 4-bit Manufacturing Revision */
#define FFB_DAC_UCTRL_MANREV_SHIFT 8
#define FFB_DAC_TGEN 0x6000 /* Timing Generator */
@@ -425,7 +428,7 @@ static void ffb_switch_from_graph(struct ffb_par *par)
{
struct ffb_fbc __iomem *fbc = par->fbc;
struct ffb_dac __iomem *dac = par->dac;
- unsigned long flags;
+ unsigned long flags, uctrl;
spin_lock_irqsave(&par->lock, flags);
FFBWait(par);
@@ -450,6 +453,15 @@ static void ffb_switch_from_graph(struct ffb_par *par)
upa_writel((FFB_DAC_CUR_CTRL_P0 |
FFB_DAC_CUR_CTRL_P1), &dac->value2);
+ /* Disable overlay and window modes. */
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ uctrl = upa_readl(&dac->value);
+ uctrl &= ~FFB_DAC_UCTRL_WMODE;
+ uctrl |= FFB_DAC_UCTRL_WM_COMB;
+ uctrl &= ~FFB_DAC_UCTRL_OVENAB;
+ upa_writel(FFB_DAC_UCTRL, &dac->type);
+ upa_writel(uctrl, &dac->value);
+
spin_unlock_irqrestore(&par->lock, flags);
}
--
2.51.0
^ permalink raw reply related
* [PATCH] staging: fbtft: replace -1 with proper error codes
From: Soham Kute @ 2026-02-28 20:27 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel, Soham Kute
Replace return -1 with proper kernel error codes:
- -ENODEV when SPI device is NULL
- -EINVAL when display size or buffer is invalid
- -EOPNOTSUPP for unimplemented functions
Signed-off-by: Soham Kute <officialsohamkute@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 4 ++--
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
drivers/staging/fbtft/fbtft-io.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de6647d0..c2e5c6276415 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -29,7 +29,7 @@ static int write_spi(struct fbtft_par *par, void *buf, size_t len)
if (!par->spi) {
dev_err(par->info->device,
"%s: par->spi is unexpectedly NULL\n", __func__);
- return -1;
+ return -ENODEV;
}
spi_message_init(&m);
@@ -144,7 +144,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x1F, 0x01);
} else {
dev_err(par->info->device, "display size is not supported!!");
- return -1;
+ return -EINVAL;
}
/* PWM clock */
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..9a87bddd7d19 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -181,7 +181,7 @@ int fbtft_write_vmem16_bus9(struct fbtft_par *par, size_t offset, size_t len)
if (!par->txbuf.buf) {
dev_err(par->info->device, "%s: txbuf.buf is NULL\n", __func__);
- return -1;
+ return -EINVAL;
}
remain = len;
@@ -217,7 +217,7 @@ EXPORT_SYMBOL(fbtft_write_vmem16_bus9);
int fbtft_write_vmem8_bus8(struct fbtft_par *par, size_t offset, size_t len)
{
dev_err(par->info->device, "%s: function not implemented\n", __func__);
- return -1;
+ return -EOPNOTSUPP;
}
EXPORT_SYMBOL(fbtft_write_vmem8_bus8);
diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c
index de1904a443c2..2144f5257fa9 100644
--- a/drivers/staging/fbtft/fbtft-io.c
+++ b/drivers/staging/fbtft/fbtft-io.c
@@ -19,7 +19,7 @@ int fbtft_write_spi(struct fbtft_par *par, void *buf, size_t len)
if (!par->spi) {
dev_err(par->info->device,
"%s: par->spi is unexpectedly NULL\n", __func__);
- return -1;
+ return -ENODEV;
}
spi_message_init(&m);
@@ -231,6 +231,6 @@ EXPORT_SYMBOL(fbtft_write_gpio16_wr);
int fbtft_write_gpio16_wr_latched(struct fbtft_par *par, void *buf, size_t len)
{
dev_err(par->info->device, "%s: function not implemented\n", __func__);
- return -1;
+ return -EOPNOTSUPP;
}
EXPORT_SYMBOL(fbtft_write_gpio16_wr_latched);
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: chenjun (AM) @ 2026-02-28 1:53 UTC (permalink / raw)
To: Thomas Zimmermann, simona@ffwll.ch, deller@gmx.de,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: linruifeng (A)
In-Reply-To: <bc9a37ac-43d2-451b-81b7-e0b23827006f@suse.de>
在 2026/2/27 23:56, Thomas Zimmermann 写道:
> Hi,
>
> thanks for the patch.
>
> Am 27.02.26 um 15:43 schrieb Chen Jun:
>> When a font is set on an invisible console, the screen will not update.
>> However, the fontbuffer is not updated to match the new font dimensions.
>
> I looked through vc_resize() but cannot quite find the logic that calls
> fbcon_rotate_font(). Can you please point to correct place?
>
> Best regards
> Thomas
>
Hi, fbcon_rouate_font is called in fbcon_switch
[ 64.669554] CPU: 3 UID: 0 PID: 978 Comm: a.out Not tainted
7.0.0-rc1-00021-gd9d32e5bd5a4-dirty #10 PREEMPT(lazy)
[ 64.669576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/4
[ 64.669584] Call Trace:
[ 64.669589] <TASK>
[ 64.669595] dump_stack_lvl+0x53/0x70
[ 64.669615] fbcon_rotate_font+0x2d6/0xe90
[ 64.669636] ? kfree+0x159/0x3b0
[ 64.669650] ? ud_cursor+0x830/0x1d80
[ 64.669661] ? __kmalloc_noprof+0x198/0x4a0
[ 64.669674] fbcon_switch+0x67b/0x10f0
[ 64.669689] ? __pfx_fbcon_switch+0x10/0x10
[ 64.669708] ? con_is_visible+0xb0/0x130
[ 64.669723] redraw_screen+0x258/0x690
[ 64.669736] ? mutex_unlock+0x7d/0xd0
[ 64.669751] ? __pfx_redraw_screen+0x10/0x10
[ 64.669764] ? tty_get_pgrp+0x73/0xb0
[ 64.669784] vc_do_resize+0x9a5/0xec0
[ 64.669803] ? __pfx_vc_do_resize+0x10/0x10
[ 64.669815] ? kernel_fpu_begin_mask+0x1c5/0x210
[ 64.669832] ? __pfx_kernel_fpu_begin_mask+0x10/0x10
[ 64.669843] ? fbcon_set_font+0x2cb/0x8c0
[ 64.669853] ? __kasan_kmalloc_large+0x81/0xa0
[ 64.669863] ? __kmalloc_large_node_noprof+0x18/0xb0
[ 64.669874] fbcon_do_set_font+0x390/0xa70
[ 64.669890] ? __pfx_fbcon_set_font+0x10/0x10
[ 64.669900] con_font_op+0x7d5/0xc30
[ 64.669910] ? arch_stack_walk+0x9f/0xf0
[ 64.669924] ? __pfx_con_font_op+0x10/0x10
[ 64.669940] vt_ioctl+0x8ee/0x2480
[ 64.669953] ? __pfx_vt_ioctl+0x10/0x10
[ 64.669964] ? __x64_sys_open+0x79/0xc0
[ 64.669976] ? do_syscall_64+0xfa/0x570
[ 64.669986] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 64.669996] ? __pfx_path_openat+0x10/0x10
[ 64.670006] ? __pfx_avc_has_extended_perms+0x10/0x10
[ 64.670022] ? _raw_spin_lock+0x7f/0xd0
[ 64.670040] ? do_file_open+0x22f/0x2b0
[ 64.670048] ? pte_offset_map_lock+0xe2/0x1e0
[ 64.670070] ? __pfx_do_file_open+0x10/0x10
[ 64.670082] tty_ioctl+0x3e7/0x1190
[ 64.670098] ? __pfx_tty_ioctl+0x10/0x10
[ 64.670109] ? __pfx_do_vfs_ioctl+0x10/0x10
[ 64.670124] ? ioctl_has_perm.constprop.74+0x2e1/0x4f0
[ 64.670137] ? __pfx_ioctl_has_perm.constprop.74+0x10/0x10
[ 64.670148] ? __pfx_do_sys_openat2+0x10/0x10
[ 64.670191] __x64_sys_ioctl+0x130/0x1a0
[ 64.670204] do_syscall_64+0xfa/0x570
[ 64.670214] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 64.670223] RIP: 0033:0x7ff56cb0c577
[ 64.670233] Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 8
[ 64.670242] RSP: 002b:00007fff94ab6a48 EFLAGS: 00000206 ORIG_RAX:
0000000000000010
[ 64.670256] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007ff56cb0c577
[ 64.670263] RDX: 00007fff94ab6a60 RSI: 0000000000004b72 RDI:
0000000000000003
[ 64.670269] RBP: 00007fff94ab6af0 R08: 000055bf68e008d0 R09:
00007ff56cdec090
[ 64.670275] R10: 0000000000000000 R11: 0000000000000206 R12:
000055bf68e00630
[ 64.670281] R13: 00007fff94ab6be0 R14: 0000000000000000 R15:
0000000000000000
[ 64.670293] </TASK>
>>
>> This inconsistency leads to out-of-bounds memory access when writing to
>> the tty bound to fbcon, as demonstrated by the following KASAN report:
>>
>> BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0xdf/0x140
>> Read of size 1 at addr ffff8881195a2280 by task a.out/971
>> Call Trace:
>> <TASK>
>> fb_pad_aligned_buffer+0xdf/0x140
>> ud_putcs+0x88a/0xde0
>> fbcon_putcs+0x319/0x430
>> do_update_region+0x23c/0x3b0
>> do_con_write+0x225c/0x67f0
>> con_write+0xe/0x30
>> n_tty_write+0x4b5/0xff0
>> file_tty_write.isra.41+0x46c/0x880
>> vfs_write+0x868/0xd60
>> ksys_write+0xf2/0x1d0
>> do_syscall_64+0xfa/0x570
>>
>> Fix this by calling fbcon_rotate_font() if vc is invisible in
>> fbcon_do_set_font().
>>
>> Signed-off-by: Chen Jun <chenjun102@huawei.com>
>> ---
>> drivers/video/fbdev/core/fbcon.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 666261ae59d8..d76100188bee 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -2444,6 +2444,11 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
>> rows = FBCON_SWAP(par->rotate, info->var.yres, info->var.xres);
>> cols /= w;
>> rows /= h;
>> + if (!con_is_visible(vc)) {
>> + ret = fbcon_rotate_font(info, vc);
>> + if (ret)
>> + goto err_out;
>> + }
>> ret = vc_resize(vc, cols, rows);
>> if (ret)
>> goto err_out;
>
^ permalink raw reply
* Re: [PATCH v5] Fonts: Adding all Terminus fronts from 12 to 32 in bold, and normal versions
From: Helge Deller @ 2026-02-27 20:59 UTC (permalink / raw)
To: Pavel Nikulin, linux-fbdev, dri-devel; +Cc: Helge Deller, linux-kernel
In-Reply-To: <20260226073404.13511-1-pavel@noa-labs.com>
Hi Pavel,
please include the graphics mailing lists (fbdev, dri-devel).
* Pavel Nikulin <pavel@noa-labs.com>:
> This patch adds an option to compile-in all terminus fonts, and removed the old bold only terminus version
>
> These fonts were converted from Terminus psf files with the help of psftools and a script.
>
> This patch is non-intrusive, no options are enabled by default so most users won't notice a thing.
Sure, but you add a whole lot of fonts.
Why are both bold and non-bold fonts needed?
Why do we need all in-kernel?
They may be loaded after bootup via userspace too.
What does other people think?
Helge
> I am placing my changes under the GPL 2.0 just as source Terminus font.
>
> Signed-off-by: Pavel Nikulin <pavel@noa-labs.com>
> ---
> V4 -> V5: Added changed font.h to the patch
>
> include/linux/font.h | 42 +-
> lib/fonts/Kconfig | 142 +-
> lib/fonts/Makefile | 15 +
> lib/fonts/font_ter10x18.c | 6412 ++++++++----------------------------
> lib/fonts/font_ter10x18b.c | 1305 ++++++++
> lib/fonts/font_ter10x20.c | 1305 ++++++++
> lib/fonts/font_ter10x20b.c | 1305 ++++++++
> lib/fonts/font_ter11x22.c | 1561 +++++++++
> lib/fonts/font_ter11x22b.c | 1561 +++++++++
> lib/fonts/font_ter12x24.c | 1561 +++++++++
> lib/fonts/font_ter12x24b.c | 1561 +++++++++
> lib/fonts/font_ter14x28.c | 1817 ++++++++++
> lib/fonts/font_ter14x28b.c | 1817 ++++++++++
> lib/fonts/font_ter16x32.c | 4107 +++++++++++------------
> lib/fonts/font_ter16x32b.c | 2073 ++++++++++++
> lib/fonts/font_ter6x12.c | 537 +++
> lib/fonts/font_ter8x14.c | 537 +++
> lib/fonts/font_ter8x14b.c | 537 +++
> lib/fonts/font_ter8x16.c | 537 +++
> lib/fonts/font_ter8x16b.c | 537 +++
> lib/fonts/fonts.c | 45 +
> 21 files changed, 22124 insertions(+), 7190 deletions(-)
> create mode 100644 lib/fonts/font_ter10x18b.c
> create mode 100644 lib/fonts/font_ter10x20.c
> create mode 100644 lib/fonts/font_ter10x20b.c
> create mode 100644 lib/fonts/font_ter11x22.c
> create mode 100644 lib/fonts/font_ter11x22b.c
> create mode 100644 lib/fonts/font_ter12x24.c
> create mode 100644 lib/fonts/font_ter12x24b.c
> create mode 100644 lib/fonts/font_ter14x28.c
> create mode 100644 lib/fonts/font_ter14x28b.c
> create mode 100644 lib/fonts/font_ter16x32b.c
> create mode 100644 lib/fonts/font_ter6x12.c
> create mode 100644 lib/fonts/font_ter8x14.c
> create mode 100644 lib/fonts/font_ter8x14b.c
> create mode 100644 lib/fonts/font_ter8x16.c
> create mode 100644 lib/fonts/font_ter8x16b.c
^ permalink raw reply
* Re: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: Thomas Zimmermann @ 2026-02-27 15:56 UTC (permalink / raw)
To: Chen Jun, simona, deller, linux-fbdev, linux-kernel; +Cc: linruifeng4
In-Reply-To: <20260227144358.101173-1-chenjun102@huawei.com>
Hi,
thanks for the patch.
Am 27.02.26 um 15:43 schrieb Chen Jun:
> When a font is set on an invisible console, the screen will not update.
> However, the fontbuffer is not updated to match the new font dimensions.
I looked through vc_resize() but cannot quite find the logic that calls
fbcon_rotate_font(). Can you please point to correct place?
Best regards
Thomas
>
> This inconsistency leads to out-of-bounds memory access when writing to
> the tty bound to fbcon, as demonstrated by the following KASAN report:
>
> BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0xdf/0x140
> Read of size 1 at addr ffff8881195a2280 by task a.out/971
> Call Trace:
> <TASK>
> fb_pad_aligned_buffer+0xdf/0x140
> ud_putcs+0x88a/0xde0
> fbcon_putcs+0x319/0x430
> do_update_region+0x23c/0x3b0
> do_con_write+0x225c/0x67f0
> con_write+0xe/0x30
> n_tty_write+0x4b5/0xff0
> file_tty_write.isra.41+0x46c/0x880
> vfs_write+0x868/0xd60
> ksys_write+0xf2/0x1d0
> do_syscall_64+0xfa/0x570
>
> Fix this by calling fbcon_rotate_font() if vc is invisible in
> fbcon_do_set_font().
>
> Signed-off-by: Chen Jun <chenjun102@huawei.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 666261ae59d8..d76100188bee 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2444,6 +2444,11 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
> rows = FBCON_SWAP(par->rotate, info->var.yres, info->var.xres);
> cols /= w;
> rows /= h;
> + if (!con_is_visible(vc)) {
> + ret = fbcon_rotate_font(info, vc);
> + if (ret)
> + goto err_out;
> + }
> ret = vc_resize(vc, cols, rows);
> if (ret)
> goto err_out;
--
--
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 v11 2/2] rust: clist: Add support to interface with C linked lists
From: Alvin Sun @ 2026-02-27 15:50 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Alex Gaynor, Danilo Krummrich, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh, alexeyi,
Eliot Courtney, dri-devel, nouveau, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260226193442.GA4077409@joelbox2>
On 2/27/26 03:34, Joel Fernandes wrote:
> On Fri, 27 Feb 2026, Alvin Sun wrote:
>> Thanks for the clist abstraction. The Tyr debugfs [1] I'm implementing
>> needs to iterate over a GpuVm's VA list, and I'd like to switch that to
>> a CList-based implementation.
> Thanks for looking into using CList for this!
>
>> Could you make CListHeadIter public and expose a public constructor?
>> Or do you have a better suggestion?
> I think this can be handled without exposing CListHeadIter. See below.
>
>> The VA list mixes two node types in one list — GpuVa (with driver-specific
>> data) and KernelGpuVa — so we have to filter/skip nodes and can't use
>> CList as-is. With a public CListHeadIter and new(), we can implement a
>> custom iterator (like our current GpuVaIter) on top of CListHeadIter and
>> then migrate that code to clist instead of hand-rolled list traversal.
> Looking at the Tyr code, both GpuVa and KernelGpuVa are
> #[repr(transparent)] wrappers over the same C struct (drm_gpuva), linked
> through the same list_head field at the same offset. The "two types" are
> a Rust-level modeling choice for safety, not a structural difference in
> the list — every node in that list is a drm_gpuva.
>
> So CList's typed iteration already works here. You can iterate over all
> nodes using a common Rust wrapper type (like a #[repr(transparent)]
> wrapper over drm_gpuva), and then skip the kernel-reserved node by
> pointer identity — since drm_gpuvm has its kernel_alloc_node as a named
> field, its address is known. Something like:
>
> // Iterate all nodes as a common base type.
> let list = clist_create!(unsafe { head, RawGpuVa, drm_gpuva, rb.entry });
> let kernel_ptr = unsafe { &raw mut (*gpuvm_raw).kernel_alloc_node };
>
> for va in list.iter() {
> if va.as_raw() == kernel_ptr {
> continue; // skip
> }
>
> // Cast to &GpuVa
> let gpu_va = unsafe { GpuVa::from_raw(va.as_raw()) };
> ...
> }
>
> If you need a named iterator type (e.g. for returning from a method),
> you can wrap CListIter in your own GpuVaIter struct that stores the
> kernel node pointer and filters in its Iterator::next() impl. That would
> probably also be cleaner.
That's a good idea! I will try to implement GpuVaIter based on CListIter.
Thanks,
Alvin Sun
>
> OTOH, with CListHeadIter you'd need to do container_of manually on each node,
> which might be more erroneous code, whereas CListIter handles that for you.
> And anyway, the pointer comparison needed to skip the kernel node is the same
> in both approaches.
>
> Would this work for the Tyr debugfs use case?
>
> --
> Joel Fernandes
>
^ permalink raw reply
* Re: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: chenjun (AM) @ 2026-02-27 14:53 UTC (permalink / raw)
To: simona@ffwll.ch, deller@gmx.de, tzimmermann@suse.de,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: linruifeng (A)
In-Reply-To: <20260227144358.101173-1-chenjun102@huawei.com>
在 2026/2/27 22:50, chenjun (AM) 写道:
> When a font is set on an invisible console, the screen will not update.
> However, the fontbuffer is not updated to match the new font dimensions.
>
> This inconsistency leads to out-of-bounds memory access when writing to
> the tty bound to fbcon, as demonstrated by the following KASAN report:
>
> BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0xdf/0x140
> Read of size 1 at addr ffff8881195a2280 by task a.out/971
> Call Trace:
> <TASK>
> fb_pad_aligned_buffer+0xdf/0x140
> ud_putcs+0x88a/0xde0
> fbcon_putcs+0x319/0x430
> do_update_region+0x23c/0x3b0
> do_con_write+0x225c/0x67f0
> con_write+0xe/0x30
> n_tty_write+0x4b5/0xff0
> file_tty_write.isra.41+0x46c/0x880
> vfs_write+0x868/0xd60
> ksys_write+0xf2/0x1d0
> do_syscall_64+0xfa/0x570
>
> Fix this by calling fbcon_rotate_font() if vc is invisible in
> fbcon_do_set_font().
>
> Signed-off-by: Chen Jun <chenjun102@huawei.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 666261ae59d8..d76100188bee 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2444,6 +2444,11 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
> rows = FBCON_SWAP(par->rotate, info->var.yres, info->var.xres);
> cols /= w;
> rows /= h;
> + if (!con_is_visible(vc)) {
> + ret = fbcon_rotate_font(info, vc);
> + if (ret)
> + goto err_out;
> + }
> ret = vc_resize(vc, cols, rows);
> if (ret)
> goto err_out;
>
There is a poc:
```
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/ioctl.h>
#include <linux/capability.h>
char my_font_data[512 * 1 * 32 * 32];
struct console_font_op {
unsigned int op;
unsigned int flags;
unsigned int width, height;
unsigned int charcount;
unsigned char *data;
};
void execute_one(void)
{
int tty = open("/dev/tty2", O_APPEND|O_RDWR, 0);
char buf[100] = {27, '#', '8', 0xa, 0x5, 0x5, 0x5, 0x5};
struct console_font_op op = {
.op = 0,
.width = 32,
.height = 32,
.charcount = 512,
.data = my_font_data,
};
ioctl(tty, 0x4B72, &op);
write(tty, buf, 100);
}
int main(void)
{
execute_one();
return 0;
}
```
echo 2 > /sys/class/graphics/fbcon/rotate_all
./poc
^ permalink raw reply
* [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: Chen Jun @ 2026-02-27 14:43 UTC (permalink / raw)
To: simona, deller, tzimmermann, linux-fbdev, linux-kernel
Cc: chenjun102, linruifeng4
When a font is set on an invisible console, the screen will not update.
However, the fontbuffer is not updated to match the new font dimensions.
This inconsistency leads to out-of-bounds memory access when writing to
the tty bound to fbcon, as demonstrated by the following KASAN report:
BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0xdf/0x140
Read of size 1 at addr ffff8881195a2280 by task a.out/971
Call Trace:
<TASK>
fb_pad_aligned_buffer+0xdf/0x140
ud_putcs+0x88a/0xde0
fbcon_putcs+0x319/0x430
do_update_region+0x23c/0x3b0
do_con_write+0x225c/0x67f0
con_write+0xe/0x30
n_tty_write+0x4b5/0xff0
file_tty_write.isra.41+0x46c/0x880
vfs_write+0x868/0xd60
ksys_write+0xf2/0x1d0
do_syscall_64+0xfa/0x570
Fix this by calling fbcon_rotate_font() if vc is invisible in
fbcon_do_set_font().
Signed-off-by: Chen Jun <chenjun102@huawei.com>
---
drivers/video/fbdev/core/fbcon.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 666261ae59d8..d76100188bee 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2444,6 +2444,11 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
rows = FBCON_SWAP(par->rotate, info->var.yres, info->var.xres);
cols /= w;
rows /= h;
+ if (!con_is_visible(vc)) {
+ ret = fbcon_rotate_font(info, vc);
+ if (ret)
+ goto err_out;
+ }
ret = vc_resize(vc, cols, rows);
if (ret)
goto err_out;
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] fbdev/tdfxfb: Make the VGA register initialisation a bit more obvious
From: Helge Deller @ 2026-02-27 14:27 UTC (permalink / raw)
To: Daniel Palmer, linux-fbdev; +Cc: dri-devel, linux-kernel
In-Reply-To: <20260227122500.3885069-1-daniel@thingy.jp>
On 2/27/26 13:25, Daniel Palmer wrote:
> For a while I was trying to get this working on m68k, for some reason
> the card doesn't display anything if it's own video BIOS didn't run..
>
> Anyhow, I spent a long time looking up what each of these offsets
> were to work out what the code is configuring and eventually
> replaced them with the human readable defines in video/vga.h.
>
> Functionally there is no change but maybe it makes it a bit easier to
> look at for the next person that finds themselves in here.
>
> Tested on a real voodoo 3 on x86_64.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
> drivers/video/fbdev/tdfxfb.c | 109 ++++++++++++++++++-----------------
> 1 file changed, 55 insertions(+), 54 deletions(-)
applied to fbdev git tree.
Thanks for the cleanup!
Helge
^ permalink raw reply
* [PATCH] fbdev/tdfxfb: Make the VGA register initialisation a bit more obvious
From: Daniel Palmer @ 2026-02-27 12:25 UTC (permalink / raw)
To: deller, linux-fbdev; +Cc: dri-devel, linux-kernel, Daniel Palmer
For a while I was trying to get this working on m68k, for some reason
the card doesn't display anything if it's own video BIOS didn't run..
Anyhow, I spent a long time looking up what each of these offsets
were to work out what the code is configuring and eventually
replaced them with the human readable defines in video/vga.h.
Functionally there is no change but maybe it makes it a bit easier to
look at for the next person that finds themselves in here.
Tested on a real voodoo 3 on x86_64.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
drivers/video/fbdev/tdfxfb.c | 109 ++++++++++++++++++-----------------
1 file changed, 55 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index 51ebe78359ec..7606e024fa3f 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -77,6 +77,7 @@
#include <asm/io.h>
#include <video/tdfx.h>
+#include <video/vga.h>
#define DPRINTK(a, b...) pr_debug("fb: %s: " a, __func__ , ## b)
@@ -591,7 +592,7 @@ static int tdfxfb_set_par(struct fb_info *info)
vt = ve + (info->var.upper_margin << 1) - 1;
reg.screensize = info->var.xres | (info->var.yres << 13);
reg.vidcfg |= VIDCFG_HALF_MODE;
- reg.crt[0x09] = 0x80;
+ reg.crt[VGA_CRTC_MAX_SCAN] = 0x80;
} else {
vd = info->var.yres - 1;
vs = vd + info->var.lower_margin;
@@ -609,59 +610,59 @@ static int tdfxfb_set_par(struct fb_info *info)
info->var.xres < 480 ? 0x60 :
info->var.xres < 768 ? 0xe0 : 0x20);
- reg.gra[0x05] = 0x40;
- reg.gra[0x06] = 0x05;
- reg.gra[0x07] = 0x0f;
- reg.gra[0x08] = 0xff;
-
- reg.att[0x00] = 0x00;
- reg.att[0x01] = 0x01;
- reg.att[0x02] = 0x02;
- reg.att[0x03] = 0x03;
- reg.att[0x04] = 0x04;
- reg.att[0x05] = 0x05;
- reg.att[0x06] = 0x06;
- reg.att[0x07] = 0x07;
- reg.att[0x08] = 0x08;
- reg.att[0x09] = 0x09;
- reg.att[0x0a] = 0x0a;
- reg.att[0x0b] = 0x0b;
- reg.att[0x0c] = 0x0c;
- reg.att[0x0d] = 0x0d;
- reg.att[0x0e] = 0x0e;
- reg.att[0x0f] = 0x0f;
- reg.att[0x10] = 0x41;
- reg.att[0x12] = 0x0f;
-
- reg.seq[0x00] = 0x03;
- reg.seq[0x01] = 0x01; /* fixme: clkdiv2? */
- reg.seq[0x02] = 0x0f;
- reg.seq[0x03] = 0x00;
- reg.seq[0x04] = 0x0e;
-
- reg.crt[0x00] = ht - 4;
- reg.crt[0x01] = hd;
- reg.crt[0x02] = hbs;
- reg.crt[0x03] = 0x80 | (hbe & 0x1f);
- reg.crt[0x04] = hs;
- reg.crt[0x05] = ((hbe & 0x20) << 2) | (he & 0x1f);
- reg.crt[0x06] = vt;
- reg.crt[0x07] = ((vs & 0x200) >> 2) |
- ((vd & 0x200) >> 3) |
- ((vt & 0x200) >> 4) | 0x10 |
- ((vbs & 0x100) >> 5) |
- ((vs & 0x100) >> 6) |
- ((vd & 0x100) >> 7) |
- ((vt & 0x100) >> 8);
- reg.crt[0x09] |= 0x40 | ((vbs & 0x200) >> 4);
- reg.crt[0x10] = vs;
- reg.crt[0x11] = (ve & 0x0f) | 0x20;
- reg.crt[0x12] = vd;
- reg.crt[0x13] = wd;
- reg.crt[0x15] = vbs;
- reg.crt[0x16] = vbe + 1;
- reg.crt[0x17] = 0xc3;
- reg.crt[0x18] = 0xff;
+ reg.gra[VGA_GFX_MODE] = 0x40;
+ reg.gra[VGA_GFX_MISC] = 0x05;
+ reg.gra[VGA_GFX_COMPARE_MASK] = 0x0f;
+ reg.gra[VGA_GFX_BIT_MASK] = 0xff;
+
+ reg.att[VGA_ATC_PALETTE0] = 0x00;
+ reg.att[VGA_ATC_PALETTE1] = 0x01;
+ reg.att[VGA_ATC_PALETTE2] = 0x02;
+ reg.att[VGA_ATC_PALETTE3] = 0x03;
+ reg.att[VGA_ATC_PALETTE4] = 0x04;
+ reg.att[VGA_ATC_PALETTE5] = 0x05;
+ reg.att[VGA_ATC_PALETTE6] = 0x06;
+ reg.att[VGA_ATC_PALETTE7] = 0x07;
+ reg.att[VGA_ATC_PALETTE8] = 0x08;
+ reg.att[VGA_ATC_PALETTE9] = 0x09;
+ reg.att[VGA_ATC_PALETTEA] = 0x0a;
+ reg.att[VGA_ATC_PALETTEB] = 0x0b;
+ reg.att[VGA_ATC_PALETTEC] = 0x0c;
+ reg.att[VGA_ATC_PALETTED] = 0x0d;
+ reg.att[VGA_ATC_PALETTEE] = 0x0e;
+ reg.att[VGA_ATC_PALETTEF] = 0x0f;
+ reg.att[VGA_ATC_MODE] = 0x41;
+ reg.att[VGA_ATC_PLANE_ENABLE] = 0x0f;
+
+ reg.seq[VGA_SEQ_RESET] = 0x03;
+ reg.seq[VGA_SEQ_CLOCK_MODE] = 0x01; /* fixme: clkdiv2? */
+ reg.seq[VGA_SEQ_PLANE_WRITE] = 0x0f;
+ reg.seq[VGA_SEQ_CHARACTER_MAP] = 0x00;
+ reg.seq[VGA_SEQ_MEMORY_MODE] = 0x0e;
+
+ reg.crt[VGA_CRTC_H_TOTAL] = ht - 4;
+ reg.crt[VGA_CRTC_H_DISP] = hd;
+ reg.crt[VGA_CRTC_H_BLANK_START] = hbs;
+ reg.crt[VGA_CRTC_H_BLANK_END] = 0x80 | (hbe & 0x1f);
+ reg.crt[VGA_CRTC_H_SYNC_START] = hs;
+ reg.crt[VGA_CRTC_H_SYNC_END] = ((hbe & 0x20) << 2) | (he & 0x1f);
+ reg.crt[VGA_CRTC_V_TOTAL] = vt;
+ reg.crt[VGA_CRTC_OVERFLOW] = ((vs & 0x200) >> 2) |
+ ((vd & 0x200) >> 3) |
+ ((vt & 0x200) >> 4) | 0x10 |
+ ((vbs & 0x100) >> 5) |
+ ((vs & 0x100) >> 6) |
+ ((vd & 0x100) >> 7) |
+ ((vt & 0x100) >> 8);
+ reg.crt[VGA_CRTC_MAX_SCAN] |= 0x40 | ((vbs & 0x200) >> 4);
+ reg.crt[VGA_CRTC_V_SYNC_START] = vs;
+ reg.crt[VGA_CRTC_V_SYNC_END] = (ve & 0x0f) | 0x20;
+ reg.crt[VGA_CRTC_V_DISP_END] = vd;
+ reg.crt[VGA_CRTC_OFFSET] = wd;
+ reg.crt[VGA_CRTC_V_BLANK_START] = vbs;
+ reg.crt[VGA_CRTC_V_BLANK_END] = vbe + 1;
+ reg.crt[VGA_CRTC_MODE] = 0xc3;
+ reg.crt[VGA_CRTC_LINE_COMPARE] = 0xff;
/* Banshee's nonvga stuff */
reg.ext[0x00] = (((ht & 0x100) >> 8) |
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v11 4/4] rust: gpu: Add GPU buddy allocator bindings
From: Danilo Krummrich @ 2026-02-27 12:08 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
nouveau, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Alex Gaynor, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224224005.3232841-5-joelagnelf@nvidia.com>
On Tue Feb 24, 2026 at 11:40 PM CET, Joel Fernandes wrote:
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 58dbb02c5197..b8287601f464 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -97,6 +97,8 @@
> pub mod firmware;
> pub mod fmt;
> pub mod fs;
> +#[cfg(CONFIG_GPU_BUDDY)]
Has to be #[cfg(CONFIG_GPU_BUDDY = "y")] for now.
> +pub mod gpu;
> #[cfg(CONFIG_I2C = "y")]
> pub mod i2c;
> pub mod id_pool;
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH v11 4/4] rust: gpu: Add GPU buddy allocator bindings
From: Alexandre Courbot @ 2026-02-27 12:00 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Andrea Righi, Zhi Wang,
Philipp Stanner, Elle Rhumsaa, alexeyi, Eliot Courtney, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <3161a017-a9f8-465c-b4dd-fef085d75b98@nvidia.com>
On Fri Feb 27, 2026 at 6:42 AM JST, Joel Fernandes wrote:
<snip>
>>
>> And the job of `alloc_blocks` is also simplified:
>>
>> let (start, end) = match mode {
>> GpuBuddyAllocMode::Range { start, end } => (start, end),
>> _ => (0, 0),
>> };
>> let flags = mode.into_flags() | u32::from(flags) as usize;
>> // ... and just invoke the C API with these parameters.
>>
>>> if the C allocator evolves its flag semantics (new combinations become
>>> valid, or existing constraints change), an enum on the Rust side would
>>> break. It's simpler and more maintainable to pass combinable flags and
>>> let the C allocator validate -- which it already does. The switch to
>>> `impl_flags!` will work for us without over-constraining.
>>
>> The evolution you describe is speculative and unlikely to happen as it
>> would break all C users just the same. And if the C API adds new flags
>> or allocation modes, we will have to update the Rust abstraction either
>> way.
>
> How/why would it break C users? Currently top down + range is silently ignored,
> implementing it is unlikely to break them.
>
> I also wouldn't call it speculative: top-down within a range is a natural
> feature the C allocator could add right? By modeling modes as a mutually
> exclusive enum, we're disallowing a flag combination that could become
> valid in the future. That's fine for now, but something to keep in mind as we
> choose this design. We could add a new RangeTopDown mode variant in the future,
> though. That said, I've made the switch to the enum as
> you suggested since it is cleaner code! And is more Rust-like as you pointed.
Ah, I thought you were talking about new flags - the case you are
quoting is different, and indeed more concerning. I guess if things were
to change in that direction we would have to move top-down into its own
flag and update our users. But for now we should try to support the
existing actual semantics as closely as possible, and without any
surprise if possible - what you get is exactly what you get, without
anything swept under the rug (the silent masking done on the C side
freaks me out a little bit tbh ^_^;).
Should top-down become a flag, our current API also wouldn't become
incorrect - it would just be incomplete in that it doesn't support the
new use-case until we update it, so thankfully that wouldn't be a
critical issue.
^ permalink raw reply
* Re: [PATCH v11 4/4] rust: gpu: Add GPU buddy allocator bindings
From: Danilo Krummrich @ 2026-02-27 11:30 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
nouveau, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Alex Gaynor, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, arunpravin.paneerselvam
In-Reply-To: <20260224224005.3232841-5-joelagnelf@nvidia.com>
(Cc: Arun)
On Tue Feb 24, 2026 at 11:40 PM CET, Joel Fernandes wrote:
> +RUST [GPU BUDDY]
> +M: Joel Fernandes <joelagnelf@nvidia.com>
> +L: dri-devel@lists.freedesktop.org
> +L: rust-for-linux@vger.kernel.org
> +S: Maintained
> +F: rust/helpers/gpu.c
> +F: rust/kernel/gpu/
What about adding this to the existing GPU BUDDY ALLOCATOR entry? Maybe you can
offer Matthew and Arun your help.
Also, this wouldn't be a subentry of "RUST", but the rust version of GPU BUDDY,
so it would be "GPU BUDDY [RUST]".
Also, please add rust/kernel/gpu/ to the "DRM DRIVERS AND COMMON INFRASTRUCTURE
[RUST]" entry.
> +/// Inner structure holding the actual buddy allocator.
> +///
> +/// # Synchronization
> +///
> +/// The C `gpu_buddy` API requires synchronization (see `include/linux/gpu_buddy.h`).
> +/// The internal [`GpuBuddyGuard`] ensures that the lock is held for all
> +/// allocator and free operations, preventing races between concurrent allocations
> +/// and the freeing that occurs when [`AllocatedBlocks`] is dropped.
> +///
> +/// # Invariants
> +///
> +/// The inner [`Opaque`] contains a valid, initialized buddy allocator.
The invariant should be justified in the constructor. Also, where is it used?
> +// SAFETY: GpuBuddyInner is `Sync` because the internal GpuBuddyGuard
I think it's more precise to refer to GpuBuddyInner::lock.
> +// serializes all access to the C allocator, preventing data races.
> +unsafe impl Sync for GpuBuddyInner {}
> +
> +/// Guard that proves the lock is held, enabling access to the allocator.
> +///
> +/// # Invariants
> +///
> +/// The inner `_guard` holds the lock for the duration of this guard's lifetime.
> +pub(crate) struct GpuBuddyGuard<'a> {
> + inner: &'a GpuBuddyInner,
> + _guard: MutexGuard<'a, ()>,
> +}
> +
> +impl GpuBuddyGuard<'_> {
> + /// Get a raw pointer to the underlying C `gpu_buddy` structure.
> + fn as_raw(&self) -> *mut bindings::gpu_buddy {
> + self.inner.inner.get()
> + }
> +}
> +
> +/// GPU buddy allocator instance.
> +///
> +/// This structure wraps the C `gpu_buddy` allocator using reference counting.
> +/// The allocator is automatically cleaned up when all references are dropped.
> +///
> +/// # Invariants
> +///
> +/// The inner [`Arc`] points to a valid, initialized GPU buddy allocator.
Do we need this invariant? Isn't this implied by the GpuBuddyInner type?
> + /// Iterate over allocated blocks.
> + ///
> + /// Returns an iterator yielding [`AllocatedBlock`] values. Each [`AllocatedBlock`]
> + /// borrows `self` and is only valid for the duration of that borrow.
> + pub fn iter(&self) -> impl Iterator<Item = AllocatedBlock<'_>> + '_ {
> + // SAFETY: list contains gpu_buddy_block items linked via __bindgen_anon_1.link.
> + let clist = clist_create!(unsafe {
This macro has three separate safety requirements, please justify all of them.
Also, please also use markdown in safety comments. Personally, I don't care too
much, but it would be good to keep things consistent.
> + self.list.as_raw(),
> + Block,
> + bindings::gpu_buddy_block,
> + __bindgen_anon_1.link
> + });
> +
> + clist
> + .iter()
> + .map(|block| AllocatedBlock { block, alloc: self })
> + }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for AllocatedBlocks {
> + fn drop(self: Pin<&mut Self>) {
> + let guard = self.buddy.lock();
> +
> + // SAFETY:
> + // - list is valid per the type's invariants.
> + // - guard provides exclusive access to the allocator.
> + // CAST: BuddyFlags were validated to fit in u32 at construction.
> + unsafe {
> + bindings::gpu_buddy_free_list(
> + guard.as_raw(),
> + self.list.as_raw(),
> + self.flags.as_raw() as u32,
> + );
> + }
> + }
> +}
> +
> +/// A GPU buddy block.
> +///
> +/// Transparent wrapper over C `gpu_buddy_block` structure. This type is returned
> +/// as references during iteration over [`AllocatedBlocks`].
> +///
> +/// # Invariants
> +///
> +/// The inner [`Opaque`] contains a valid, allocated `gpu_buddy_block`.
> +#[repr(transparent)]
> +pub struct Block(Opaque<bindings::gpu_buddy_block>);
Does this need to be public? I don't see it being exposed by any API.
> +
> +impl Block {
> + /// Get a raw pointer to the underlying C block.
> + fn as_raw(&self) -> *mut bindings::gpu_buddy_block {
> + self.0.get()
> + }
> +
> + /// Get the block's offset in the address space.
> + pub(crate) fn offset(&self) -> u64 {
> + // SAFETY: self.as_raw() is valid per the type's invariants.
> + unsafe { bindings::gpu_buddy_block_offset(self.as_raw()) }
> + }
> +
> + /// Get the block order.
> + pub(crate) fn order(&self) -> u32 {
> + // SAFETY: self.as_raw() is valid per the type's invariants.
> + unsafe { bindings::gpu_buddy_block_order(self.as_raw()) }
> + }
> +}
> +
> +// SAFETY: `Block` is not modified after allocation for the lifetime
> +// of `AllocatedBlock`.
> +unsafe impl Send for Block {}
> +
> +// SAFETY: `Block` is not modified after allocation for the lifetime
> +// of `AllocatedBlock`.
> +unsafe impl Sync for Block {}
> +
> +/// An allocated block with access to the GPU buddy allocator.
This needs a better description, i.e. what makes an `AllocatedBlock different
compared to a "normal" Block.
> +///
> +/// It is returned by [`AllocatedBlocks::iter()`] and provides access to the
> +/// GPU buddy allocator required for some accessors.
> +///
> +/// # Invariants
> +///
> +/// - `block` is a valid reference to an allocated [`Block`].
> +/// - `alloc` is a valid reference to the [`AllocatedBlocks`] that owns this block.
References should always be valid, no need to mention that.
> +pub struct AllocatedBlock<'a> {
> + block: &'a Block,
NIT: What about just naming it "this" and
> + alloc: &'a AllocatedBlocks,
"blocks"?
> +}
> +
> +impl AllocatedBlock<'_> {
> + /// Get the block's offset in the address space.
> + ///
> + /// Returns the absolute offset including the allocator's base offset.
> + /// This is the actual address to use for accessing the allocated memory.
> + pub fn offset(&self) -> u64 {
> + self.alloc.buddy.base_offset + self.block.offset()
> + }
> +
> + /// Get the block order (size = chunk_size << order).
> + pub fn order(&self) -> u32 {
> + self.block.order()
> + }
> +
> + /// Get the block's size in bytes.
> + pub fn size(&self) -> u64 {
> + self.alloc.buddy.chunk_size << self.block.order()
> + }
> +}
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix macro whitespace errors
From: Dhyan K Prajapati @ 2026-02-27 4:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, Greg Kroah-Hartman, Jason Donenfeld, dri-devel,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <aaCIqUXPB75vR6rK@smile.fi.intel.com>
On Thu, Feb 26, 2026 at 07:53:45PM +0200, Andy Shevchenko wrote:
>On Thu, Feb 26, 2026 at 10:55:31PM +0530, dhyan19022009@gmail.com wrote:
>>
>> Remove prohibited spaces before closing parentheses in macro calls in
>> fbtft-bus.c, reported by checkpatch.pl
>
>You haven't compiled this, have you?
>
>
>--
>With Best Regards,
>Andy Shevchenko
>
>
Hey, sorry I atleast should've checked the definition, i'll keep in mind
not to trust checkpatch.pl blindly
^ 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