* [PATCH v2 01/13] fbdev: Declare src parameter of fb_pad_ helpers as constant
From: Thomas Zimmermann @ 2026-03-02 14:08 UTC (permalink / raw)
To: gregkh, deller, sam
Cc: linux-fbdev, dri-devel, linux-kernel, Thomas Zimmermann
In-Reply-To: <20260302141255.518657-1-tzimmermann@suse.de>
Fbdev's padding helpers do not modify the source buffer. Declare the
parameter as 'const'.
Fbcon's font-rendering code calls these helpers with the font data.
Declaring src as const will allow for making the font data constant
as well.
While at it, also remove the extern qualifier from the function
declarations in the header file.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
include/linux/fb.h | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index cf199038f069..30f2b59c47bf 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -91,14 +91,14 @@ EXPORT_SYMBOL(fb_get_color_depth);
/*
* Data padding functions.
*/
-void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height)
+void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 s_pitch, u32 height)
{
__fb_pad_aligned_buffer(dst, d_pitch, src, s_pitch, height);
}
EXPORT_SYMBOL(fb_pad_aligned_buffer);
-void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx, u32 height,
- u32 shift_high, u32 shift_low, u32 mod)
+void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 idx, u32 height,
+ u32 shift_high, u32 shift_low, u32 mod)
{
u8 mask = (u8) (0xff << shift_high), tmp;
int i, j;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 6d4a58084fd5..324b0fd5f617 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -605,9 +605,9 @@ extern int register_framebuffer(struct fb_info *fb_info);
extern void unregister_framebuffer(struct fb_info *fb_info);
extern int devm_register_framebuffer(struct device *dev, struct fb_info *fb_info);
extern char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size);
-extern void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx,
- u32 height, u32 shift_high, u32 shift_low, u32 mod);
-extern void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height);
+void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 idx, u32 height,
+ u32 shift_high, u32 shift_low, u32 mod);
+void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 s_pitch, u32 height);
extern void fb_set_suspend(struct fb_info *info, int state);
extern int fb_get_color_depth(struct fb_var_screeninfo *var,
struct fb_fix_screeninfo *fix);
@@ -633,8 +633,8 @@ static inline struct device *dev_of_fbinfo(const struct fb_info *info)
#endif
}
-static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
- u8 *src, u32 s_pitch, u32 height)
+static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, const u8 *src, u32 s_pitch,
+ u32 height)
{
u32 i, j;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 05/13] lib/fonts: Remove trailing whitespaces
From: Thomas Zimmermann @ 2026-03-02 14:08 UTC (permalink / raw)
To: gregkh, deller, sam
Cc: linux-fbdev, dri-devel, linux-kernel, Thomas Zimmermann
In-Reply-To: <20260302141255.518657-1-tzimmermann@suse.de>
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
lib/fonts/font_acorn_8x8.c | 2 +-
lib/fonts/font_mini_4x6.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
index 18755c33d249..af5fa72aa8b7 100644
--- a/lib/fonts/font_acorn_8x8.c
+++ b/lib/fonts/font_acorn_8x8.c
@@ -68,7 +68,7 @@ static const struct font_data acorndata_8x8 = {
/* 3A */ 0x00, 0x00, 0x18, 0x18, 0x00, 0x18, 0x18, 0x00, /* : */
/* 3B */ 0x00, 0x00, 0x18, 0x18, 0x00, 0x18, 0x18, 0x30, /* ; */
/* 3C */ 0x0C, 0x18, 0x30, 0x60, 0x30, 0x18, 0x0C, 0x00, /* < */
-/* 3D */ 0x00, 0x00, 0x7E, 0x00, 0x7E, 0x00, 0x00, 0x00, /* = */
+/* 3D */ 0x00, 0x00, 0x7E, 0x00, 0x7E, 0x00, 0x00, 0x00, /* = */
/* 3E */ 0x30, 0x18, 0x0C, 0x06, 0x0C, 0x18, 0x30, 0x00, /* > */
/* 3F */ 0x3C, 0x66, 0x0C, 0x18, 0x18, 0x00, 0x18, 0x00, /* ? */
/* 40 */ 0x3C, 0x66, 0x6E, 0x6A, 0x6E, 0x60, 0x3C, 0x00, /* @ */
diff --git a/lib/fonts/font_mini_4x6.c b/lib/fonts/font_mini_4x6.c
index 8d39fd447952..cc21dc70cfd1 100644
--- a/lib/fonts/font_mini_4x6.c
+++ b/lib/fonts/font_mini_4x6.c
@@ -18,15 +18,15 @@
s{((0x)?[0-9a-fA-F]+)(.*\[([\*\ ]{4})\])}{
($num,$pat,$bits) = ($1,$3,$4);
-
+
$bits =~ s/([^\s0])|(.)/ defined($1) + 0 /ge;
-
+
$num = ord(pack("B8", $bits));
$num |= $num >> 4;
$num = sprintf("0x%.2x", $num);
-
+
#print "$num,$pat,$bits\n";
-
+
$num . $pat;
}ge;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 02/13] vt: Remove trailing whitespaces
From: Thomas Zimmermann @ 2026-03-02 14:08 UTC (permalink / raw)
To: gregkh, deller, sam
Cc: linux-fbdev, dri-devel, linux-kernel, Thomas Zimmermann
In-Reply-To: <20260302141255.518657-1-tzimmermann@suse.de>
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
include/linux/console_struct.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 13b35637bd5a..ebdb9750d348 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -120,7 +120,7 @@ struct vc_data {
unsigned short vc_complement_mask; /* [#] Xor mask for mouse pointer */
unsigned short vc_s_complement_mask; /* Saved mouse pointer mask */
unsigned long vc_pos; /* Cursor address */
- /* fonts */
+ /* fonts */
unsigned short vc_hi_font_mask; /* [#] Attribute set for upper 256 chars of font or 0 if not supported */
struct console_font vc_font; /* Current VC font set */
unsigned short vc_video_erase_char; /* Background erase character */
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/13] vc,fbcon,fonts: Proper handling of font data
From: Thomas Zimmermann @ 2026-03-02 14:08 UTC (permalink / raw)
To: gregkh, deller, sam
Cc: linux-fbdev, dri-devel, linux-kernel, Thomas Zimmermann
Provide helpers for handling console font data. Update consoles and VT.
VT's vc_state stores font data as a plain byte array of glphys. Fbcon,
newport_con and the kernel's internal fonts store the glyph data as an
array of plain bytes plus a hidden header for reference counting, check
sums and buffer sizes. The reference counting only works for user-space
fonts but not for internal fonts. Font-data handling is duplicated in
several places. Most of the font handling is open-coded and mixed up with
VT's plain glyph arrays.
To address these issues, add proper handling of font data to all involved
components: struct vc_font for font state in VC; a font data type for the
consoles. Then implement interfaces for handling font data one by one.
Patch 1 prepares the fbdev interface.
Patches 2 to 4 prepare VT's font handling.
Patches 5 to 13 refactor fbcon and newport_con to use clean interfaces for
their fonts.
Fbcon has long been a source of problems and bug reports. [1] With its
confusing implementation, it is hard to find the cause of these bugs.
Cleaning up the fbcon code will hopefully help with resolving bug reports
in the future.
The series has been tested with fbcon under DRM's bochs driver by changing
fonts at runtime using the setfont utility. [2] The changes to newport_con
have only been tested to compile.
v2:
- keep declaring the internal fonts in the public header file (Helge)
- rebase and clean up
[1] https://lore.kernel.org/all/6992c84c.a70a0220.2c38d7.00e8.GAE@google.com/
[2] https://www.man7.org/linux/man-pages/man8/setfont.8.html
Thomas Zimmermann (13):
fbdev: Declare src parameter of fb_pad_ helpers as constant
vt: Remove trailing whitespaces
vt: Store font in struct vc_font
vt: Calculate font-buffer size with vc_font_size()
lib/fonts: Remove trailing whitespaces
lib/fonts: Remove FNTCHARCNT()
lib/fonts: Store font data as font_data_t; update consoles
lib/fonts: Read font size with font_data_size()
lib/fonts: Compare font data for equality with font_data_is_equal()
lib/fonts: Manage font-data lifetime with font_data_get/_put()
lib/fonts: Create font_data_t from struct console_font with
font_data_import()
lib/fonts: Store font data for user space with font_data_export()
lib/fonts: Remove internal symbols and macros from public header file
drivers/video/console/newport_con.c | 61 +++----
drivers/video/fbdev/core/bitblit.c | 11 +-
drivers/video/fbdev/core/fbcon.c | 194 +++++++----------------
drivers/video/fbdev/core/fbcon.h | 8 +-
drivers/video/fbdev/core/fbmem.c | 6 +-
include/linux/console_struct.h | 59 ++++++-
include/linux/fb.h | 10 +-
include/linux/font.h | 115 +++++++++-----
lib/fonts/font.h | 38 +++++
lib/fonts/font_10x18.c | 2 +-
lib/fonts/font_6x10.c | 3 +-
lib/fonts/font_6x11.c | 2 +-
lib/fonts/font_6x8.c | 3 +-
lib/fonts/font_7x14.c | 2 +-
lib/fonts/font_8x16.c | 3 +-
lib/fonts/font_8x8.c | 2 +-
lib/fonts/font_acorn_8x8.c | 4 +-
lib/fonts/font_mini_4x6.c | 10 +-
lib/fonts/font_pearl_8x8.c | 2 +-
lib/fonts/font_sun12x22.c | 3 +-
lib/fonts/font_sun8x16.c | 3 +-
lib/fonts/font_ter10x18.c | 4 +-
lib/fonts/font_ter16x32.c | 4 +-
lib/fonts/fonts.c | 236 +++++++++++++++++++++++++++-
24 files changed, 518 insertions(+), 267 deletions(-)
create mode 100644 lib/fonts/font.h
base-commit: e57ac53f3ef90826a0b5b7cdf7f1e742a2aa1e9b
--
2.53.0
^ permalink raw reply
* Re: [PATCH 13/13] lib/fonts: Remove internal symbols and macros from public header file
From: Thomas Zimmermann @ 2026-03-02 13:45 UTC (permalink / raw)
To: Helge Deller, gregkh, sam; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <d8633caa-c01c-433c-8dd3-f300dac53a0b@gmx.de>
Am 23.02.26 um 16:05 schrieb Helge Deller:
> On 2/18/26 09:16, Thomas Zimmermann wrote:
>> diff --git a/include/linux/font.h b/include/linux/font.h
>> index 4ff956a1cd0a..6e9a4c93b47b 100644
>> --- a/include/linux/font.h
>> +++ b/include/linux/font.h
>> @@ -92,20 +92,12 @@ struct font_desc {
>> #define FONT6x8_IDX 12
>> #define TER10x18_IDX 13
>> -extern const struct font_desc font_vga_8x8,
>> - font_vga_8x16,
>> - font_pearl_8x8,
>> - font_vga_6x11,
>> - font_7x14,
>> - font_10x18,
>> - font_sun_8x16,
>> - font_sun_12x22,
>> - font_acorn_8x8,
>> - font_mini_4x6,
>> - font_6x10,
>> - font_ter_16x32,
>> - font_6x8,
>> - font_ter_10x18;
>> +#if defined(CONFIG_FONT_8x8)
>> +extern const struct font_desc font_vga_8x8;
>> +#endif
>> +#if defined(CONFIG_FONT_8x16)
>> +extern const struct font_desc font_vga_8x16;
>> +#endif
>
> I suggest not to use all those #ifdef(CONFIG_XXX) in the header files.
> They are not necessary, and trigger a rebuild of a whole lot C-files
> in case one single CONFIG option is changed.
> Instead use it in the C-files only.
> That way (re-)compilation is faster and you still get a link/build error
> when a symbol is used although the config option is not set.
Ok. I'll send out an update in a bit.
>
>> diff --git a/lib/fonts/font.h b/lib/fonts/font.h
>> new file mode 100644
>> index 000000000000..00f65a3da5c2
>> --- /dev/null
>> +++ b/lib/fonts/font.h
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>> +#ifndef _LIB_FONTS_FONT_H
>> +#define _LIB_FONTS_FONT_H
>> +
>> +#include <linux/font.h>
>> +
>> +#if defined(CONFIG_FONT_PEARL_8x8)
>> +extern const struct font_desc font_pearl_8x8;
>> +#endif
>> +#if defined(CONFIG_FONT_6x11)
>> +extern const struct font_desc font_vga_6x11;
>> +#endif
> ...
> same here...
>
> Helge
>
--
--
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 v8 06/25] gpu: nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Alexandre Courbot @ 2026-03-02 12:23 UTC (permalink / raw)
To: Joel Fernandes, Zhi Wang, Danilo Krummrich, Gary Guo
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-7-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
> PRAMIN apertures are a crucial mechanism to direct read/write to VRAM.
> Add support for the same.
A few design thoughts that are not immediately actionable, but might
become this cycle if we get a tag with the new `Io` work.
Basically this feature is a prime candidate for an `Io` implementation.
It maps onto the BAR, has a fixed 1MB size, and needs to be accessed
using various sizes. It is also used to fill structured values, which
the I/O projection work will also allow us to do.
The current design doesn't allow the user to explicitly set the start of
the sliding window - this results in a sub-optimal usage of the hardware
and more complex code in this module. At this level, we just want
something that exposes the hardware as it is, i.e. "give me a view of
the 1MB of VRAM starting from this 64K-aligned address".
Then on top of that we can implement another type that handles the
window automatically if we want, but I don't think we will actually need
it. The page table code will most likely want to set the window to the
start of its structure, project it, and access it using compile-time
checked offsets.
If that turns out to be insufficient, we can always compose something
more complex from this basic piece - but the base `Pramin` should stay
simple and truthful to the underlying hardware IMHO.
^ permalink raw reply
* Re: [PATCH v8 25/25] gpu: nova-core: mm: Add PRAMIN aperture self-tests
From: Alexandre Courbot @ 2026-03-02 12:04 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-26-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
<snip>
> diff --git a/drivers/gpu/nova-core/mm/pramin.rs b/drivers/gpu/nova-core/mm/pramin.rs
> index 04b652d3ee4f..30b1dba0c305 100644
> --- a/drivers/gpu/nova-core/mm/pramin.rs
> +++ b/drivers/gpu/nova-core/mm/pramin.rs
> @@ -290,3 +290,164 @@ fn drop(&mut self) {
> // MutexGuard drops automatically, releasing the lock.
> }
> }
> +
> +/// Run PRAMIN self-tests during boot if self-tests are enabled.
> +#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
> +pub(crate) fn run_self_test(
> + dev: &kernel::device::Device,
> + bar: Arc<Devres<Bar0>>,
> + mmu_version: super::pagetable::MmuVersion,
> +) -> Result {
> + use super::pagetable::MmuVersion;
> +
> + // PRAMIN support is only for MMU v2 for now (Turing/Ampere/Ada).
> + if mmu_version != MmuVersion::V2 {
Why is that? I thought PRAMIN was also working on Hopper+. Isn't it
orthogonal to the kind of MMU used?
> + dev_info!(
> + dev,
> + "PRAMIN: Skipping self-tests for MMU {:?} (only V2 supported)\n",
> + mmu_version
> + );
> + return Ok(());
> + }
> +
> + dev_info!(dev, "PRAMIN: Starting self-test...\n");
> +
> + let pramin = Arc::pin_init(Pramin::new(bar)?, GFP_KERNEL)?;
> + let mut win = pramin.window()?;
> +
> + // Use offset 0x1000 as test area.
> + let base: usize = 0x1000;
> +
> + // Test 1: Read/write at byte-aligned locations.
Let's split each test into its own function for readability.
^ permalink raw reply
* Re: [PATCH v8 07/25] docs: gpu: nova-core: Document the PRAMIN aperture mechanism
From: Alexandre Courbot @ 2026-03-02 12:02 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-8-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
> Add documentation for the PRAMIN aperture mechanism used by nova-core
> for direct VRAM access.
>
> Nova only uses TARGET=VID_MEM for VRAM access. The SYS_MEM target values
> are documented for completeness but not used by the driver.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> Documentation/gpu/nova/core/pramin.rst | 125 +++++++++++++++++++++++++
> Documentation/gpu/nova/index.rst | 1 +
> 2 files changed, 126 insertions(+)
> create mode 100644 Documentation/gpu/nova/core/pramin.rst
>
> diff --git a/Documentation/gpu/nova/core/pramin.rst b/Documentation/gpu/nova/core/pramin.rst
> new file mode 100644
> index 000000000000..55ec9d920629
> --- /dev/null
> +++ b/Documentation/gpu/nova/core/pramin.rst
> @@ -0,0 +1,125 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=========================
> +PRAMIN aperture mechanism
> +=========================
> +
> +.. note::
> + The following description is approximate and current as of the Ampere family.
> + It may change for future generations and is intended to assist in understanding
> + the driver code.
> +
> +Introduction
> +============
> +
> +PRAMIN is a hardware aperture mechanism that provides CPU access to GPU Video RAM (VRAM) before
> +the GPU's Memory Management Unit (MMU) and page tables are initialized. This 1MB sliding window,
> +located at a fixed offset within BAR0, is essential for setting up page tables and other critical
> +GPU data structures without relying on the GPU's MMU.
> +
> +Architecture Overview
> +=====================
> +
> +The PRAMIN aperture mechanism is logically implemented by the GPU's PBUS (PCIe Bus Controller Unit)
> +and provides a CPU-accessible window into VRAM through the PCIe interface::
> +
> + +-----------------+ PCIe +------------------------------+
> + | CPU |<----------->| GPU |
> + +-----------------+ | |
> + | +----------------------+ |
> + | | PBUS | |
> + | | (Bus Controller) | |
> + | | | |
> + | | +--------------+<------------ (window starts at
> + | | | PRAMIN | | | BAR0 + 0x700000)
> + | | | Window | | |
> + | | | (1MB) | | |
> + | | +--------------+ | |
> + | | | | |
> + | +---------|------------+ |
> + | | |
> + | v |
> + | +----------------------+<------------ (Program PRAMIN to any
> + | | VRAM | | 64KB-aligned VRAM boundary)
> + | | (Several GBs) | |
> + | | | |
> + | | FB[0x000000000000] | |
> + | | ... | |
> + | | FB[0x7FFFFFFFFFF] | |
> + | +----------------------+ |
> + +------------------------------+
> +
> +PBUS (PCIe Bus Controller) is responsible for, among other things, handling MMIO
> +accesses to the BAR registers.
> +
> +PRAMIN Window Operation
> +=======================
> +
> +The PRAMIN window provides a 1MB sliding aperture that can be repositioned over
> +the entire VRAM address space using the ``NV_PBUS_BAR0_WINDOW`` register.
> +
> +Window Control Mechanism
> +-------------------------
> +
> +The window position is controlled via the PBUS ``BAR0_WINDOW`` register::
This repeats the sentence of `PRAMIN Window Operation`. Let's remove
that sentence.
> +
> + NV_PBUS_BAR0_WINDOW Register (0x1700):
> + +-------+--------+--------------------------------------+
> + | 31:26 | 25:24 | 23:0 |
> + | RSVD | TARGET | BASE_ADDR |
> + | | | (bits 39:16 of VRAM address) |
> + +-------+--------+--------------------------------------+
> +
> + BASE_ADDR field (bits 23:0):
> + - Contains bits [39:16] of the target VRAM address
> + - Provides 40-bit (1TB) address space coverage
> + - Must be programmed with 64KB-aligned addresses
This reads a bit like filler - let's turn this into a single sentence,
of just keep the first point - the other two are deducible from it.
^ permalink raw reply
* Re: [PATCH v8 06/25] gpu: nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Alexandre Courbot @ 2026-03-02 11:58 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-7-joelagnelf@nvidia.com>
Hi Joel,
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
> PRAMIN apertures are a crucial mechanism to direct read/write to VRAM.
> Add support for the same.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
I have two sets of comments for this patch - one that is immediately
actionable, the other that depends on the availability of the new `Io`
interface. Let's start with the actionable items, I'll do the discussion
about `Io` in another email.
> ---
> drivers/gpu/nova-core/mm.rs | 5 +
> drivers/gpu/nova-core/mm/pramin.rs | 292 +++++++++++++++++++++++++++++
> drivers/gpu/nova-core/nova_core.rs | 1 +
> drivers/gpu/nova-core/regs.rs | 5 +
> 4 files changed, 303 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm.rs
> create mode 100644 drivers/gpu/nova-core/mm/pramin.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> new file mode 100644
> index 000000000000..7a5dd4220c67
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Memory management subsystems for nova-core.
> +
> +pub(crate) mod pramin;
> diff --git a/drivers/gpu/nova-core/mm/pramin.rs b/drivers/gpu/nova-core/mm/pramin.rs
> new file mode 100644
> index 000000000000..04b652d3ee4f
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/pramin.rs
> @@ -0,0 +1,292 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Direct VRAM access through the PRAMIN aperture.
> +//!
> +//! PRAMIN provides a 1MB sliding window into VRAM through BAR0, allowing the CPU to access
> +//! video memory directly. Access is managed through a two-level API:
> +//!
> +//! - [`Pramin`]: The parent object that owns the BAR0 reference and synchronization lock.
> +//! - [`PraminWindow`]: A guard object that holds exclusive PRAMIN access for its lifetime.
> +//!
> +//! The PRAMIN aperture is a 1MB region at BAR0 + 0x700000 for all GPUs. The window base is
> +//! controlled by the `NV_PBUS_BAR0_WINDOW` register and must be 64KB aligned.
s/must be/is - it's not like that hardware is giving us a choice anyway
since we cannot even express a non-aligned value in the window register.
> +//!
> +//! # Examples
> +//!
> +//! ## Basic read/write
> +//!
> +//! ```no_run
> +//! use crate::driver::Bar0;
> +//! use crate::mm::pramin;
> +//! use kernel::devres::Devres;
> +//! use kernel::prelude::*;
> +//! use kernel::sync::Arc;
> +//!
> +//! fn example(devres_bar: Arc<Devres<Bar0>>) -> Result<()> {
> +//! let pramin = Arc::pin_init(pramin::Pramin::new(devres_bar)?, GFP_KERNEL)?;
> +//! let mut window = pramin.window()?;
> +//!
> +//! // Write and read back.
> +//! window.try_write32(0x100, 0xDEADBEEF)?;
> +//! let val = window.try_read32(0x100)?;
> +//! assert_eq!(val, 0xDEADBEEF);
> +//!
> +//! Ok(())
> +//! // Original window position restored on drop.
> +//! }
> +//! ```
> +//!
> +//! ## Auto-repositioning across VRAM regions
> +//!
> +//! ```no_run
> +//! use crate::driver::Bar0;
> +//! use crate::mm::pramin;
> +//! use kernel::devres::Devres;
> +//! use kernel::prelude::*;
> +//! use kernel::sync::Arc;
> +//!
> +//! fn example(devres_bar: Arc<Devres<Bar0>>) -> Result<()> {
> +//! let pramin = Arc::pin_init(pramin::Pramin::new(devres_bar)?, GFP_KERNEL)?;
> +//! let mut window = pramin.window()?;
> +//!
> +//! // Access first 1MB region.
> +//! window.try_write32(0x100, 0x11111111)?;
> +//!
> +//! // Access at 2MB - window auto-repositions.
> +//! window.try_write32(0x200000, 0x22222222)?;
> +//!
> +//! // Back to first region - window repositions again.
> +//! let val = window.try_read32(0x100)?;
> +//! assert_eq!(val, 0x11111111);
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +
> +#![expect(unused)]
> +
> +use crate::{
> + driver::Bar0,
> + num::u64_as_usize,
> + regs, //
> +};
> +
> +use kernel::bits::genmask_u64;
> +use kernel::devres::Devres;
> +use kernel::io::Io;
> +use kernel::new_mutex;
> +use kernel::prelude::*;
> +use kernel::ptr::{
> + Alignable,
> + Alignment, //
> +};
> +use kernel::sizes::{
> + SZ_1M,
> + SZ_64K, //
> +};
> +use kernel::sync::{
> + lock::mutex::MutexGuard,
> + Arc,
> + Mutex, //
> +};
> +
> +/// PRAMIN aperture base offset in BAR0.
> +const PRAMIN_BASE: usize = 0x700000;
> +
> +/// PRAMIN aperture size (1MB).
> +const PRAMIN_SIZE: usize = SZ_1M;
> +
> +/// 64KB alignment for window base.
> +const WINDOW_ALIGN: Alignment = Alignment::new::<SZ_64K>();
> +
> +/// Maximum addressable VRAM offset (40-bit address space).
> +///
> +/// The `NV_PBUS_BAR0_WINDOW` register has a 24-bit `window_base` field (bits 23:0) that stores
> +/// bits [39:16] of the target VRAM address. This limits the addressable space to 2^40 bytes.
> +const MAX_VRAM_OFFSET: usize = u64_as_usize(genmask_u64(0..=39));
> +
> +/// Generate a PRAMIN read accessor.
> +macro_rules! define_pramin_read {
> + ($name:ident, $ty:ty) => {
> + #[doc = concat!("Read a `", stringify!($ty), "` from VRAM at the given offset.")]
> + pub(crate) fn $name(&mut self, vram_offset: usize) -> Result<$ty> {
> + // Compute window parameters without bar reference.
> + let (bar_offset, new_base) =
> + self.compute_window(vram_offset, ::core::mem::size_of::<$ty>())?;
> +
> + // Update window base if needed and perform read.
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
Ouch, we are calling `try_access` for every single read or write
operation. Thankfully we can do without this - see my comments on
`PraminWindow` a bit later.
> + if let Some(base) = new_base {
> + Self::write_window_base(&bar, base);
> + self.state.current_base = base;
> + }
> + bar.$name(bar_offset)
> + }
> + };
> +}
> +
> +/// Generate a PRAMIN write accessor.
> +macro_rules! define_pramin_write {
> + ($name:ident, $ty:ty) => {
> + #[doc = concat!("Write a `", stringify!($ty), "` to VRAM at the given offset.")]
> + pub(crate) fn $name(&mut self, vram_offset: usize, value: $ty) -> Result {
> + // Compute window parameters without bar reference.
> + let (bar_offset, new_base) =
> + self.compute_window(vram_offset, ::core::mem::size_of::<$ty>())?;
> +
> + // Update window base if needed and perform write.
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
> + if let Some(base) = new_base {
> + Self::write_window_base(&bar, base);
> + self.state.current_base = base;
> + }
> + bar.$name(value, bar_offset)
> + }
> + };
> +}
> +
> +/// PRAMIN state protected by mutex.
> +struct PraminState {
> + current_base: usize,
> +}
This has only one member and no impl block of its own - shall we inline
it?
> +
> +/// PRAMIN aperture manager.
> +///
> +/// Call [`Pramin::window()`] to acquire exclusive PRAMIN access.
> +#[pin_data]
> +pub(crate) struct Pramin {
> + bar: Arc<Devres<Bar0>>,
> + /// PRAMIN aperture state, protected by a mutex.
> + ///
> + /// # Safety
> + ///
> + /// This lock is acquired during the DMA fence signalling critical path.
nit: s/signalling/signaling
> + /// It must NEVER be held across any reclaimable CPU memory / allocations
> + /// (`GFP_KERNEL`), because the memory reclaim path can call
> + /// `dma_fence_wait()`, which would deadlock with this lock held.
> + #[pin]
> + state: Mutex<PraminState>,
> +}
> +
> +impl Pramin {
> + /// Create a pin-initializer for PRAMIN.
> + pub(crate) fn new(bar: Arc<Devres<Bar0>>) -> Result<impl PinInit<Self>> {
> + let bar_access = bar.try_access().ok_or(ENODEV)?;
> + let current_base = Self::try_read_window_base(&bar_access)?;
> +
> + Ok(pin_init!(Self {
> + bar,
> + state <- new_mutex!(PraminState { current_base }, "pramin_state"),
> + }))
> + }
> +
> + /// Acquire exclusive PRAMIN access.
> + ///
> + /// Returns a [`PraminWindow`] guard that provides VRAM read/write accessors.
> + /// The [`PraminWindow`] is exclusive and only one can exist at a time.
> + pub(crate) fn window(&self) -> Result<PraminWindow<'_>> {
The name of this method is strange - we don't pass the base of any
window area. It looks more like it is actually acquiring the `Pramin`
for exclusive access.
Also fun question: what happens if we try to access an area above (or
below) the available VRAM?
> + let state = self.state.lock();
> + let saved_base = state.current_base;
> + Ok(PraminWindow {
> + bar: self.bar.clone(),
> + state,
> + saved_base,
> + })
> + }
> +
> + /// Read the current window base from the BAR0_WINDOW register.
> + fn try_read_window_base(bar: &Bar0) -> Result<usize> {
> + let reg = regs::NV_PBUS_BAR0_WINDOW::read(bar);
> + let base = u64::from(reg.window_base());
> + let shifted = base.checked_shl(16).ok_or(EOVERFLOW)?;
> + shifted.try_into().map_err(|_| EOVERFLOW)
This function is actually infallible.
The `checked_shl` cannot fail because we are shifting a `u32` by 16,
which will always fit into a `u64`. There is some `Bounded` code
incoming that will allow us to prove that safely, but it is not
available in `drm-rust-next` yet. For now can you use a regular shift
operation with a TODO to convert to `Bounded`?
The last line could use `num::u64_as_size` to do the conversion
infallibly. But actually the window base is native to the GPU, not the
host CPU architecture - so it should really be a u64 anyway.
> + }
> +}
> +
> +/// PRAMIN window guard for direct VRAM access.
> +///
> +/// This guard holds exclusive access to the PRAMIN aperture. The window auto-repositions
> +/// when accessing VRAM offsets outside the current 1MB range. Original window position
> +/// is saved on creation and restored on drop.
> +///
> +/// Only one [`PraminWindow`] can exist at a time per [`Pramin`] instance (enforced by the
> +/// internal `MutexGuard`).
> +pub(crate) struct PraminWindow<'a> {
> + bar: Arc<Devres<Bar0>>,
Cloning the `Arc` is what forces us to do a `try_access` on every
read/write operation. Needless to say this is overkill and not
efficient.
The `PraminWindow` already holds a reference to its `Pramin`, so you can
just call `try_access` in `window` and store that. This turns `bar` into
this:
bar: RevocableGuard<'a, Bar0>,
And now you can perform operations on `bar` directly without needing to
acquire it every time.
> + state: MutexGuard<'a, PraminState>,
I'm wondering whether we should remove the `Mutex` from `Pramin` and
make its methods take `&mut self` (and this would thus become a `&mut
PraminState`).
The rationale for this is that `Pramin` will be owned by `GpuMm`, which
can implement its own locking policy (including across several of the
items it owns) as it needs. That way `Pramin` also stays "pure" in that
it only needs to care about abstracting the hardware.
> + saved_base: usize,
What is the point of saving and restoring the original position?
`Pramin` gets exclusive access to the PRAMIN area, and whenever we make
an access through the window the base address can be reprogrammed. So
it's not as if the original value has some particular meaning or
constitutes state that deserves to be preserved. Getting rid of this
behavior also lets us remove the `Drop` implementation.
> +}
> +
> +impl PraminWindow<'_> {
> + /// Write a new window base to the BAR0_WINDOW register.
> + fn write_window_base(bar: &Bar0, base: usize) {
`base` should be the native type of the GPU, i.e. `u64`.
> + // CAST:
> + // - We have guaranteed that the base is within the addressable range (40-bits).
> + // - After >> 16, a 40-bit aligned base becomes 24 bits, which fits in u32.
This function does not guarantee anything of the sort - even the caller
doesn't, this actually relies on the behavior of `compute_window`,
another method.
You can enforce this limit by using a `Bounded<u64, 40>` as the type for
base addresses. There is even staging code (not yet in drm-rust-next
unfortunately) that will lets you turn it into a `Bounded<u32, 32>`
safely to be written into the register.
> + regs::NV_PBUS_BAR0_WINDOW::default()
> + .set_window_base((base >> 16) as u32)
> + .write(bar);
> + }
> +
> + /// Compute window parameters for a VRAM access.
> + ///
> + /// Returns (`bar_offset`, `new_base`) where:
> + /// - `bar_offset`: The BAR0 offset to use for the access.
> + /// - `new_base`: `Some(base)` if window needs repositioning, `None` otherwise.
> + fn compute_window(
> + &self,
> + vram_offset: usize,
> + access_size: usize,
> + ) -> Result<(usize, Option<usize>)> {
> + // Validate VRAM offset is within addressable range (40-bit address space).
> + let end_offset = vram_offset.checked_add(access_size).ok_or(EINVAL)?;
> + if end_offset > MAX_VRAM_OFFSET + 1 {
If we are going to use `MAX_VRAM_OFFSET` like this, let's define it as
`1 << 40` and turn this into `if end_offset > MAX_VRAM_OFFSET`.
> + return Err(EINVAL);
> + }
> +
> + // Calculate which 64KB-aligned base we need.
> + let needed_base = vram_offset.align_down(WINDOW_ALIGN);
> +
> + // Calculate offset within the window.
> + let offset_in_window = vram_offset - needed_base;
> +
> + // Check if access fits in 1MB window from this base.
> + if offset_in_window + access_size > PRAMIN_SIZE {
> + return Err(EINVAL);
> + }
Here `offset_in_window` cannot be larger than 64K because of the line
before - this check is effectively dead code.
> +
> + // Return bar offset and whether window needs repositioning.
> + let new_base = if self.state.current_base != needed_base {
> + Some(needed_base)
> + } else {
> + None
> + };
So maybe I am missing something, but aren't we writing a new base if the
requested offset doesn't fit within [current_base..current_base+64K],
despite the fact that the PRAMIN window is 1MB? This looks like a bug.
Also what happens if we access PRAMIN with decreasing addresses? Won't
we be doing more window resets than we need?
> +
> + Ok((PRAMIN_BASE + offset_in_window, new_base))
> + }
> +
> + define_pramin_read!(try_read8, u8);
> + define_pramin_read!(try_read16, u16);
> + define_pramin_read!(try_read32, u32);
> + define_pramin_read!(try_read64, u64);
> +
> + define_pramin_write!(try_write8, u8);
> + define_pramin_write!(try_write16, u16);
> + define_pramin_write!(try_write32, u32);
> + define_pramin_write!(try_write64, u64);
> +}
> +
> +impl Drop for PraminWindow<'_> {
> + fn drop(&mut self) {
> + // Restore the original window base if it changed.
> + if self.state.current_base != self.saved_base {
> + if let Some(bar) = self.bar.try_access() {
> + Self::write_window_base(&bar, self.saved_base);
> +
> + // Update state to reflect the restored base.
> + self.state.current_base = self.saved_base;
> + }
> + }
> + // MutexGuard drops automatically, releasing the lock.
> + }
> +}
Let's drop this alongside the original window base restoration, which
doesn't serve any purpose.
> diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
> index c1121e7c64c5..3de00db3279e 100644
> --- a/drivers/gpu/nova-core/nova_core.rs
> +++ b/drivers/gpu/nova-core/nova_core.rs
> @@ -13,6 +13,7 @@
> mod gfw;
> mod gpu;
> mod gsp;
> +mod mm;
> mod num;
> mod regs;
> mod sbuffer;
> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
> index ea0d32f5396c..d0982e346f74 100644
> --- a/drivers/gpu/nova-core/regs.rs
> +++ b/drivers/gpu/nova-core/regs.rs
> @@ -102,6 +102,11 @@ fn fmt(&self, f: &mut kernel::fmt::Formatter<'_>) -> kernel::fmt::Result {
> 31:16 frts_err_code as u16;
> });
>
> +register!(NV_PBUS_BAR0_WINDOW @ 0x00001700, "BAR0 window control for PRAMIN access" {
> + 25:24 target as u8, "Target memory (0=VRAM, 1=SYS_MEM_COH, 2=SYS_MEM_NONCOH)";
This should be converted to an enum. I understand that we only ever want
to use `Vram` as Hopper+ don't support the other types of memories - a
single-variant enum will document that fact and force us to set the
correct value.
^ permalink raw reply
* Re: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: Thomas Zimmermann @ 2026-03-02 11:33 UTC (permalink / raw)
To: chenjun (AM), simona@ffwll.ch, deller@gmx.de,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: linruifeng (A)
In-Reply-To: <e8e3b8182e124ac08cc33700d45772ce@huawei.com>
Hi
Am 02.03.26 um 12:24 schrieb chenjun (AM):
> 在 2026/3/2 18:19, Thomas Zimmermann 写道:
>>
>> 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.
>>>
>>> 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>
>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Hi Thomas,
>
> Thanks for your review.
>
> I'm not familiar with the fbcon module. Is there a better way to fix this?
Not really, I think. The whole module first needs a redesign to be
easier to understand.
Best regards
Thomas
>
>>> ---
>>> 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: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: chenjun (AM) @ 2026-03-02 11:24 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: <1c078618-7236-4ccb-ae99-376276369f36@suse.de>
在 2026/3/2 18:19, Thomas Zimmermann 写道:
>
>
> 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.
>>
>> 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>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Hi Thomas,
Thanks for your review.
I'm not familiar with the fbcon module. Is there a better way to fix this?
>> ---
>> 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: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: Thomas Zimmermann @ 2026-03-02 10:19 UTC (permalink / raw)
To: Chen Jun, simona, deller, linux-fbdev, linux-kernel; +Cc: linruifeng4
In-Reply-To: <20260227144358.101173-1-chenjun102@huawei.com>
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.
>
> 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>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> 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: [RFC PATCH] fbcon: Fix out-of-bounds memory in fbcon_putcs
From: Thomas Zimmermann @ 2026-03-02 10:18 UTC (permalink / raw)
To: chenjun (AM), simona@ffwll.ch, deller@gmx.de,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: linruifeng (A)
In-Reply-To: <031a9e0b2f5346bbb6875c985fac149b@huawei.com>
Hi
Am 28.02.26 um 02:53 schrieb chenjun (AM):
> 在 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
Thanks. Somehow I made a wrong turn in redraw_screen()
Best regards
Thomas
>
> [ 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;
>
--
--
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] staging: sm750fb: use proper error codes instead of -1
From: Dan Carpenter @ 2026-03-02 9:09 UTC (permalink / raw)
To: Soham Kute
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260301051434.28187-1-officialsohamkute@gmail.com>
On Sun, Mar 01, 2026 at 10:44:34AM +0530, Soham Kute wrote:
> diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
> index 0ef8d4ff2ef9..d90a93ab8fdc 100644
> --- a/drivers/staging/sm750fb/ddk750_swi2c.c
> +++ b/drivers/staging/sm750fb/ddk750_swi2c.c
> @@ -294,7 +294,7 @@ static long sw_i2c_write_byte(unsigned char data)
> if (i < 0xff)
> return 0;
> else
> - return -1;
> + return -ETIMEDOUT;
The comment still says this returns -1.
Actually could you do this one function at a time, and in each commit
message please say "The callers propogate the error code back" or "
None of the callers check the error code" or "The callers treat all
non-zero error codes as failure and return -EINVAL" or whatever.
> @@ -264,7 +264,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
> (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
>
> if (accel->de_wait() != 0)
Did you consider propagating the error code from accel->de_wait()
instead? That feels like a better solution but I haven't looked at
it at all.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v8 11/25] gpu: nova-core: mm: Use usable VRAM region for buddy allocator
From: Alexandre Courbot @ 2026-03-02 3: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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <DGRGNLACDJI2.1JFEXE1GL1ZVM@nvidia.com>
On Sun Mar 1, 2026 at 9:56 PM JST, Alexandre Courbot wrote:
<snip>
> This is all the better as `usable_vram` is added as an `Option` in
> `FbLayout`, not because `None` is a valid state but because `FbLayout`
> is already constructed by the time we obtain `usable_vram`. So `None` is
> just a value that tells the caller "please return an error". Now we can
> remove the option altogether, drop patch 5, and have `boot` return the
> error for us if `usable_vram` cannot be obtained.
Correction: patches 3 and 5 won't be needed anymore and can be dropped,
it seems.
^ permalink raw reply
* Re: [PATCH v8 16/25] gpu: nova-core: mm: Add page table walker for MMU v2/v3
From: Gary Guo @ 2026-03-01 13:15 UTC (permalink / raw)
To: Joel Fernandes, Gary Guo
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, 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, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher, Christian Koenig,
Jani Nikula, Joonas Lahtinen, Vivi Rodrigo, Tvrtko Ursulin,
Rui Huang, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellstrom, 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: <1772028959.538096.8539@nvidia.com>
On Wed Feb 25, 2026 at 2:26 PM GMT, Joel Fernandes wrote:
> On 2026-02-25, Gary Guo <gary@garyguo.net> wrote:
>> On 2026-02-24 22:53, Joel Fernandes wrote:
>>> +//! ## MMU v2 (Turing/Ampere/Ada) - 5 levels
>>> [...]
>>> +//! ## MMU v3 (Hopper+) - 6 levels
>>
>> I think this is called "4 levels" and "5 levels" in kernel MM rather than
>> "5 levels" and "6 levels".
>
> Actually, I think "5 levels" and "6 levels" is correct even by x86 kernel MM
> convention. In x86 "4-level paging", the 4 levels are PGD, PUD, PMD, PTE -
> the root page directory (PGD) IS counted as one of the 4 levels. Similarly,
> for the GPU MMU, counting the root PDB (L0) as a level gives us 5 levels for
> v2 (PDB/L0 through L4/PTE) and 6 levels for v3 (PDB/L0 through L5/PTE).
>
> This is also consistent with NVIDIA's own hardware definitions in the OpenRM
> headers (dev_mmu.h for Turing and Hopper) which define the page table entries
> for each of these levels. The virtual address bitfield spans L0 (bits 56:48)
> through L4 (bits 20:12) for v2, giving 5 distinct page table levels.
>
> FWIW, the existing nouveau driver also uses this convention - NVKM_VMM_LEVELS_MAX
> is defined as 6 in nvkm/subdev/mmu/vmm.c, and the GH100 page table descriptors
> in vmmgh100.c list all 6 levels.
So PDB is not just a single address, but a list of page table entries? If that's
the case, then the number of levels is indeed correct, but reading the code
gives me an impression otherwise.
Best,
Gary
^ permalink raw reply
* Re: [PATCH v8 11/25] gpu: nova-core: mm: Use usable VRAM region for buddy allocator
From: Alexandre Courbot @ 2026-03-01 12:56 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-12-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
<snip>
> @@ -295,18 +309,42 @@ pub(crate) fn new<'a>(
>
> sec2_falcon: Falcon::new(pdev.as_ref(), spec.chipset)?,
>
> - // Create GPU memory manager owning memory management resources.
> - // This will be initialized with the usable VRAM region from GSP in a later
> - // patch. For now, we use a placeholder of 1MB.
> - mm <- GpuMm::new(devres_bar.clone(), GpuBuddyParams {
> - base_offset_bytes: 0,
> - physical_memory_size_bytes: SZ_1M as u64,
> - chunk_size_bytes: SZ_4K as u64,
> - })?,
> -
> gsp <- Gsp::new(pdev),
>
> - gsp_static_info: { gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?.0 },
> + // Boot GSP and extract usable VRAM region for buddy allocator.
> + gsp_static_info: {
> + let (info, fb_layout) = gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?;
> +
> + let usable_vram = fb_layout.usable_vram.as_ref().ok_or_else(|| {
> + dev_err!(pdev.as_ref(), "No usable FB regions found from GSP\n");
> + ENODEV
> + })?;
The chain through which we obtain `usable_vram` is very inefficient and
much more complex than it needs to be.
`fb_layout` is used as a transport for `usable_vram`, but `usable_vram`
is the only member of it that we ever use. In that case, why not return
`usable_vram` directly?
This is all the better as `usable_vram` is added as an `Option` in
`FbLayout`, not because `None` is a valid state but because `FbLayout`
is already constructed by the time we obtain `usable_vram`. So `None` is
just a value that tells the caller "please return an error". Now we can
remove the option altogether, drop patch 5, and have `boot` return the
error for us if `usable_vram` cannot be obtained.
But let's not stop here. `usable_vram` is first obtained as part of the
`GetGspStaticInfo` reply. It starts its life as `(u64, u64)` before
being morphed into a `Range<u64>` when stored in `FbLayout`. Since its
tuple state is never useful, let's store it as a `Range<u64>` in
`GetGspStaticInfoReply` to begin with and, since we cannot continue
without it anyway, let's make `commands::get_gsp_info()` fail if it
cannot build it. That way we don't even need to store it as an `Option`.
And now, since `boot` already returns the `GetGspStaticInfoReply`, we
can directly access it just by making `usable_vram` public - no need for
`boot` to return a tuple anymore.
Once you have that, something interesting happens: you don't need to
change the `gsp_static_info` arm at all in this patch. All the new code
can be moved to the `mm` arm, which is where it is actually useful
anyway.
The subsequent patches that make use of `boot_params` in other arms can
also access the exact same data using `gsp_static_info`:
- `bar1_pde_base` is also accessible from `gsp_static_info` (let's also
make it public instead of adding an accessor method),
- The other `boot_params` used to build the `GpuMM` can be reconstructed
from `usable_vram`.
Which means `boot_params` and `BootParams` can be removed (and the
`Cell` import), and we have something simpler and more direct that takes
~60 less LoCs.
In other words, this arm remains as it was:
gsp_static_info: gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?,
> + // Create GPU memory manager owning memory management resources.
> + // Uses the usable VRAM region from GSP for buddy allocator.
> + mm <- {
this arm can now be:
let usable_vram = &gsp_static_info.usable_fb_region;
dev_info!(
pdev.as_ref(),
"Using FB region: {:#x}..{:#x}\n",
usable_vram.start,
usable_vram.end
);
GpuMm::new(devres_bar.clone(), GpuBuddyParams {
base_offset_bytes: usable_vram.start,
physical_memory_size_bytes: usable_vram.end - usable_vram.start,
chunk_size_bytes: SZ_4K.into_safe_cast(),
})?
> + let params = boot_params.get();
> + GpuMm::new(devres_bar.clone(), GpuBuddyParams {
> + base_offset_bytes: params.usable_vram_start,
> + physical_memory_size_bytes: params.usable_vram_size,
> + chunk_size_bytes: SZ_4K.into_safe_cast(),
> + })?
> + },
>
> bar: devres_bar,
> })
> diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs
> index 7a4a0c759267..bc4446282613 100644
> --- a/drivers/gpu/nova-core/gsp/boot.rs
> +++ b/drivers/gpu/nova-core/gsp/boot.rs
> @@ -150,7 +150,7 @@ pub(crate) fn boot(
>
> let gsp_fw = KBox::pin_init(GspFirmware::new(dev, chipset, FIRMWARE_VERSION), GFP_KERNEL)?;
>
> - let fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?;
> + let mut fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?;
> dev_dbg!(dev, "{:#x?}\n", fb_layout);
>
> Self::run_fwsec_frts(dev, gsp_falcon, bar, &bios, &fb_layout)?;
> @@ -252,6 +252,11 @@ pub(crate) fn boot(
> Err(e) => dev_warn!(pdev.as_ref(), "GPU name unavailable: {:?}\n", e),
> }
>
> + // Populate usable VRAM from GSP response.
> + if let Some((base, size)) = info.usable_fb_region() {
> + fb_layout.set_usable_vram(base, size);
> + }
> +
And this change is not needed anymore.
^ permalink raw reply
* Re: [PATCH v8 04/25] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Alexandre Courbot @ 2026-03-01 12:43 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-5-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
> + /// Extract the first usable FB region from GSP firmware data.
> + ///
> + /// Returns the first region suitable for driver memory allocation as a `(base, size)` tuple.
> + /// Usable regions are those that:
> + /// - Are not reserved for firmware internal use.
> + /// - Are not protected (hardware-enforced access restrictions).
> + /// - Support compression (can use GPU memory compression for bandwidth).
> + /// - Support ISO (isochronous memory for display requiring guaranteed bandwidth).
> + pub(crate) fn first_usable_fb_region(&self) -> Option<(u64, u64)> {
> + let fb_info = &self.0.fbRegionInfoParams;
> + for i in 0..fb_info.numFBRegions.into_safe_cast() {
> + if let Some(reg) = fb_info.fbRegion.get(i) {
> + // Skip malformed regions where limit < base.
> + if reg.limit < reg.base {
> + continue;
> + }
> +
> + // Filter: not reserved, not protected, supports compression and ISO.
> + if reg.reserved == 0
> + && reg.bProtected == 0
> + && reg.supportCompressed != 0
> + && reg.supportISO != 0
> + {
> + let size = reg.limit - reg.base + 1;
> + return Some((reg.base, size));
> + }
> + }
> + }
> + None
> + }
No need for an explicit index and two blocks here, and we have iterator
methods designed just to do just this:
fb_info
.fbRegion
.iter()
.take(fb_info.numFBRegions.into_safe_cast())
// Skip malformed regions where limit < base.
.filter(|reg| reg.limit >= reg.base)
.find_map(|reg| {
// Filter: not reserved, not protected, supports compression and ISO.
if reg.reserved == 0
&& reg.bProtected == 0
&& reg.supportCompressed != 0
&& reg.supportISO != 0
{
let size = reg.limit - reg.base + 1;
Some(reg.base..reg.base.saturating_add(size))
} else {
None
}
})
Another thing, although not too important for now: we only take
advantage of the first available region in this series. This is ok for
now, but Nouveau for instance does collect all regions - so we should at
least have a TODO to align Nova to at least the same capability.
But this doesn't need to be done for this series; actually I'd prefer if
we start simple and get the buddy allocator in place before thinking
about this.
^ permalink raw reply
* Re: [PATCH v8 01/25] gpu: nova-core: Select GPU_BUDDY for VRAM allocation
From: Alexandre Courbot @ 2026-03-01 12:41 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-2-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:52 AM JST, Joel Fernandes wrote:
> nova-core will use the GPU buddy allocator for physical VRAM management.
> Enable it in Kconfig.
Let's merge this one-liner with the first patch of this series that
actually requires GPU_BUDDY.
^ permalink raw reply
* Re: [PATCH v8 02/25] gpu: nova-core: Kconfig: Sort select statements alphabetically
From: Alexandre Courbot @ 2026-03-01 12:40 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, 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 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, Alistair Popple,
Andrea Righi, Zhi Wang, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260224225323.3312204-3-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
> Reorder the select statements in NOVA_CORE Kconfig to be in
> alphabetical order.
Nit: please do the sorting *before* adding a new dependency - it is
more logical to fix the order before adding new stuff.
Not need to do it here, I'll apply this first as it is obviously
correct - please just rebase the series on `drm-rust-next` and resolve
the minor conflict in Kconfig.
^ permalink raw reply
* [PATCH] staging: sm750fb: use proper error codes instead of -1
From: Soham Kute @ 2026-03-01 5:14 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Soham Kute
Replace magic return value -1 with proper kernel error
codes -EBUSY, -ETIMEDOUT and -EINVAL.
Signed-off-by: Soham Kute <officialsohamkute@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 4 ++--
drivers/staging/sm750fb/sm750_accel.c | 6 +++---
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2ef9..d90a93ab8fdc 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -294,7 +294,7 @@ static long sw_i2c_write_byte(unsigned char data)
if (i < 0xff)
return 0;
else
- return -1;
+ return -ETIMEDOUT;
}
/*
@@ -394,7 +394,7 @@ long sm750_sw_i2c_init(unsigned char clk_gpio, unsigned char data_gpio)
* range is only from [0..63]
*/
if ((clk_gpio > 31) || (data_gpio > 31))
- return -1;
+ return -EINVAL;
if (sm750_get_chip_type() == SM750LE)
return sm750le_i2c_init(clk_gpio, data_gpio);
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 046b9282b24a..fa593d4f31fe 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -97,7 +97,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* got something error
*/
pr_debug("De engine always busy\n");
- return -1;
+ return -EBUSY;
}
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
@@ -264,7 +264,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
(sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
- return -1;
+ return -EBUSY;
write_dpr(accel, DE_SOURCE,
((sx << DE_SOURCE_X_K1_SHIFT) & DE_SOURCE_X_K1_MASK) |
@@ -333,7 +333,7 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
ulBytesRemain = ulBytesPerScan & 3;
if (accel->de_wait() != 0)
- return -1;
+ return -EBUSY;
/*
* 2D Source Base.
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index ce46f240cbaf..e4b6b254335e 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -518,7 +518,7 @@ int hw_sm750le_de_wait(void)
return 0;
}
/* timeout error */
- return -1;
+ return -ETIMEDOUT;
}
int hw_sm750_de_wait(void)
@@ -536,7 +536,7 @@ int hw_sm750_de_wait(void)
return 0;
}
/* timeout error */
- return -1;
+ return -ETIMEDOUT;
}
int hw_sm750_pan_display(struct lynxfb_crtc *crtc,
--
2.34.1
^ permalink raw reply related
* FAILED: Patch "fbdev: vt8500lcdfb: fix missing dma_free_coherent()" failed to apply to 5.10-stable tree
From: Sasha Levin @ 2026-03-01 2:05 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 5.10-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: Remove struct fbcon_display.inverse" failed to apply to 5.10-stable tree
From: Sasha Levin @ 2026-03-01 2:05 UTC (permalink / raw)
To: stable, tzimmermann; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 5.10-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 "fbcon: check return value of con2fb_acquire_newinfo()" failed to apply to 5.10-stable tree
From: Sasha Levin @ 2026-03-01 2:05 UTC (permalink / raw)
To: stable, a.vatoropin; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 5.10-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: of: display_timing: fix refcount leak in of_get_display_timings()" failed to apply to 5.10-stable tree
From: Sasha Levin @ 2026-03-01 2:05 UTC (permalink / raw)
To: stable, geoffreyhe2; +Cc: Helge Deller, linux-fbdev, dri-devel
The patch below does not apply to the 5.10-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
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