* Re: [PATCH v2 01/12] firmware: google: framebuffer: Do not unregister platform device
From: Tzung-Bi Shih @ 2026-01-26 8:28 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: briannorris, jwerner, javierm, samuel, maarten.lankhorst, mripard,
airlied, simona, chrome-platform, dri-devel, Hans de Goede,
linux-fbdev, stable
In-Reply-To: <20260115082128.12460-2-tzimmermann@suse.de>
On Thu, Jan 15, 2026 at 08:57:11AM +0100, Thomas Zimmermann wrote:
> The native driver takes over the framebuffer aperture by removing the
> system- framebuffer platform device. Afterwards the pointer in drvdata
> is dangling. Remove the entire logic around drvdata and let the kernel's
> aperture helpers handle this. The platform device depends on the native
> hardware device instead of the coreboot device anyway.
>
> When commit 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer
> driver") added the coreboot framebuffer code, the kernel did not support
> device-based aperture management. Instead native driviers only removed
> the conflicting fbdev device. At that point, unregistering the framebuffer
> device most likely worked correctly. It was definitely broken after
> commit d9702b2a2171 ("fbdev/simplefb: Do not use struct
> fb_info.apertures"). So take this commit for the Fixes tag. Earlier
> releases might work depending on the native hardware driver.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures")
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Thomas Zimmermann @ 2026-01-26 10:01 UTC (permalink / raw)
To: pengfuyuan, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Lee Jones, Sam Ravnborg, Zsolt Kajtar,
Ville Syrjälä, rust-for-linux, linux-kernel, dri-devel,
linux-fbdev
In-Reply-To: <20260126081744.781392-1-pengfuyuan@kylinos.cn>
Hi
Am 26.01.26 um 09:17 schrieb pengfuyuan:
> This patch series adds Rust bindings and safe abstractions for the Linux
> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
The framebuffer subsystem is obsolete and has been deprecated for a
decade. No new drivers accepted. Anything that really wants fbdev
already has a driver. Can we please let it die?
Best regards
Thomas
>
> The series consists of 4 patches:
>
> 1. rust: io: mem: add ioremap_wc support
> Adds write-combining memory mapping support to the Rust iomem abstraction,
> which is essential for framebuffer memory regions that benefit from
> write-combining semantics.
>
> 2. rust: device: add platdata accessors
> Implements generic accessors for platform data, enabling drivers to access
> platform-provided configuration. This is needed for framebuffer drivers
> that use platform data for configuration.
>
> 3. rust: fb: add framebuffer driver support
> Adds the core framebuffer framework abstraction, including:
> - Device abstraction (`fb::Device`) with reference counting via `AlwaysRefCounted`
> - Driver and Operations traits (`fb::Driver`, `fb::Operations`)
> - Screen information wrappers (`fb::FixScreenInfo`, `fb::VarScreenInfo`)
> - I/O operation helpers (`fb_io_read`, `fb_io_write`, `fb_io_mmap`)
> - Blit operation helpers (`cfb_fillrect`, `cfb_copyarea`, `cfb_imageblit`)
>
> 4. rust: fb: add simplefb test driver
> Adds a test driver that validates the framebuffer framework by porting
> the C simplefb driver to Rust. This driver serves as both a validation
> tool and a reference implementation for future Rust framebuffer drivers.
>
> The implementation follows the same patterns established in the DRM subsystem
> and maintains full compatibility with the existing C framebuffer subsystem.
> All C callbacks are properly bridged to Rust trait methods via the `Operations`
> trait, memory safety is ensured through proper use of `Opaque<fb_info>`, `ARef`,
> and `AlwaysRefCounted` for reference counting, type invariants are documented
> and enforced through the type system, and resource cleanup is handled via RAII
> with proper cleanup order.
>
> Testing:
> --------
> This series has been tested on:
> - ARM64 platforms with various display configurations
> - AMD RX550 graphics card
> - Moore Threads S30 graphics card
> - Multiple other graphics cards
>
> All tested configurations show normal display functionality with proper
> framebuffer initialization, rendering operations (including I/O, color register
> management, and blitting), memory mapping, and resource cleanup. The simplefb
> test driver successfully demonstrates the usage of all framebuffer framework
> APIs and validates the abstraction's correctness.
>
> The simplefb test driver serves as both a validation tool and a reference
> implementation for future Rust framebuffer drivers.
>
>
> pengfuyuan (4):
> rust: io: mem: add ioremap_wc support
> rust: device: add platdata accessors
> rust: fb: add framebuffer driver support
> rust: fb: add simplefb test driver
>
> drivers/video/fbdev/Kconfig | 21 +
> drivers/video/fbdev/Makefile | 1 +
> drivers/video/fbdev/simplefb_rust.rs | 653 +++++++++++++++++++++++++++
> rust/bindings/bindings_helper.h | 2 +
> rust/helpers/device.c | 5 +
> rust/helpers/io.c | 5 +
> rust/kernel/device.rs | 31 ++
> rust/kernel/fb/blit.rs | 106 +++++
> rust/kernel/fb/device.rs | 463 +++++++++++++++++++
> rust/kernel/fb/driver.rs | 169 +++++++
> rust/kernel/fb/io.rs | 76 ++++
> rust/kernel/fb/mod.rs | 23 +
> rust/kernel/fb/screeninfo.rs | 318 +++++++++++++
> rust/kernel/io/mem.rs | 71 +++
> rust/kernel/lib.rs | 2 +
> 15 files changed, 1946 insertions(+)
> create mode 100644 drivers/video/fbdev/simplefb_rust.rs
> create mode 100644 rust/kernel/fb/blit.rs
> create mode 100644 rust/kernel/fb/device.rs
> create mode 100644 rust/kernel/fb/driver.rs
> create mode 100644 rust/kernel/fb/io.rs
> create mode 100644 rust/kernel/fb/mod.rs
> create mode 100644 rust/kernel/fb/screeninfo.rs
>
--
--
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 v1 v1 0/4] [RUST] Framebuffer driver support
From: Alexandre Courbot @ 2026-01-26 10:28 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: pengfuyuan, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Lee Jones, Sam Ravnborg, Zsolt Kajtar,
Ville Syrjälä, rust-for-linux, linux-kernel, dri-devel,
linux-fbdev
In-Reply-To: <ed48e82a-cb94-477f-83c4-b2d87ae3cde6@suse.de>
On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>> This patch series adds Rust bindings and safe abstractions for the Linux
>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>
> The framebuffer subsystem is obsolete and has been deprecated for a
> decade. No new drivers accepted. Anything that really wants fbdev
> already has a driver. Can we please let it die?
This, and the patchset is also obviously AI-generated.
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Greg Kroah-Hartman @ 2026-01-26 10:32 UTC (permalink / raw)
To: pengfuyuan
Cc: Danilo Krummrich, Alice Ryhl, Daniel Almeida, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Rafael J . Wysocki, David Airlie,
Simona Vetter, Helge Deller, Hans de Goede, Thomas Zimmermann,
Lee Jones, Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20260126081744.781392-1-pengfuyuan@kylinos.cn>
On Mon, Jan 26, 2026 at 04:17:40PM +0800, pengfuyuan wrote:
> This series has been tested on:
> - ARM64 platforms with various display configurations
> - AMD RX550 graphics card
> - Moore Threads S30 graphics card
> - Multiple other graphics cards
How? If there is no rust framebuffer drivers for those hardware
platforms, how exactly were these new codepaths tested?
> All tested configurations show normal display functionality with proper
> framebuffer initialization, rendering operations (including I/O, color register
> management, and blitting), memory mapping, and resource cleanup. The simplefb
> test driver successfully demonstrates the usage of all framebuffer framework
> APIs and validates the abstraction's correctness.
Really? Where are the drivers for this? Or did simplefb really work
for all of them?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Miguel Ojeda @ 2026-01-26 11:46 UTC (permalink / raw)
To: Alexandre Courbot, pengfuyuan
Cc: Thomas Zimmermann, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Lee Jones, Sam Ravnborg, Zsolt Kajtar,
Ville Syrjälä, rust-for-linux, linux-kernel, dri-devel,
linux-fbdev
In-Reply-To: <DFYG7MT5JINY.1T8ZZ4ASIWXU@nvidia.com>
On Mon, Jan 26, 2026 at 11:28 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> This, and the patchset is also obviously AI-generated.
pengfuyuan: the generated content guidelines I mentioned earlier this
month in another of your patches have been merged now, please read:
https://docs.kernel.org/next/process/generated-content.html
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Miguel Ojeda @ 2026-01-26 12:15 UTC (permalink / raw)
To: pengfuyuan
Cc: Danilo Krummrich, Alice Ryhl, Daniel Almeida, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Thomas Zimmermann, Lee Jones, Sam Ravnborg,
Zsolt Kajtar, Ville Syrjälä, rust-for-linux,
linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20260126081744.781392-1-pengfuyuan@kylinos.cn>
On Mon, Jan 26, 2026 at 9:18 AM pengfuyuan <pengfuyuan@kylinos.cn> wrote:
>
> rust: io: mem: add ioremap_wc support
> rust: device: add platdata accessors
For future reference / others, these are essentially the same as:
https://lore.kernel.org/rust-for-linux/tencent_63DD850B43CC086844717B73C574B8358F05@qq.com/
https://lore.kernel.org/rust-for-linux/20260109080528.478731-2-pengfuyuan@kylinos.cn/
In general, please try to mention if a patch was already somewhere
else and add a changelog to understand if feedback was addressed.
Otherwise, others will have to do a manual comparison.
For instance, I may guess you sent this as a sample user due to what
Greg said back then. But that is just a guess, since you didn't reply
to the feedback nor mention it here.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Helge Deller @ 2026-01-26 12:27 UTC (permalink / raw)
To: Thomas Zimmermann, pengfuyuan, Danilo Krummrich, Alice Ryhl,
Daniel Almeida, Miguel Ojeda
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Hans de Goede,
Lee Jones, Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <ed48e82a-cb94-477f-83c4-b2d87ae3cde6@suse.de>
On 1/26/26 11:01, Thomas Zimmermann wrote:
> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>> This patch series adds Rust bindings and safe abstractions for the Linux
>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>
> The framebuffer subsystem is obsolete and has been deprecated for a
> decade. No new drivers accepted. Anything that really wants fbdev
> already has a driver. Can we please let it die?
Agreed. Adding rust bindings for fbdev doesn't make sense. Existing fbdev
drivers are often used on architectures, where rust isn't even available
(alpha, hppa, m68k, sh4, ..), so even the idea to "port" existing drivers
to rust is useless.
Helge
^ permalink raw reply
* [PATCH] printk, vt, fbcon: Remove console_conditional_schedule()
From: Sebastian Andrzej Siewior @ 2026-01-26 18:08 UTC (permalink / raw)
To: linux-kernel, linux-serial, linux-fbdev, dri-devel,
linux-rt-devel
Cc: Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Greg Kroah-Hartman, Jiri Slaby, Simona Vetter, Helge Deller
do_con_write(), fbcon_redraw.*() invoke console_conditional_schedule()
which is a conditional scheduling point based on printk's internal
variables console_may_schedule. It may only be used if the console lock
is acquired for instance via console_lock() or console_trylock().
Prinkt sets the internal variable to 1 (and allows to schedule)
if the console lock has been acquired via console_lock(). The trylock
does not allow it.
The console_conditional_schedule() invocation in do_con_write() is
invoked shortly before console_unlock().
The console_conditional_schedule() invocation in fbcon_redraw.*()
original from fbcon_scroll() / vt's con_scroll() which originate from a
line feed.
In console_unlock() the variable is set to 0 (forbids to schedule) and
it tries to schedule while making progress printing. This is brand new
compared to when console_conditional_schedule() was added in v2.4.9.11.
In v2.6.38-rc3, console_unlock() (started its existence) iterated over
all consoles and flushed them with disabled interrupts. A scheduling
attempt here was not possible, it relied that a long print scheduled
before console_unlock().
Since commit 8d91f8b15361d ("printk: do cond_resched() between lines
while outputting to consoles"), which appeared in v4.5-rc1,
console_unlock() attempts to schedule if it was allowed to schedule
while during console_lock(). Each record is idealy one line so after
every line feed.
This console_conditional_schedule() is also only relevant on
PREEMPT_NONE and PREEMPT_VOLUNTARY builds. In other configurations
cond_resched() becomes a nop and has no impact.
I'm bringing this all up just proof that it is not required anymore. It
becomes a problem on a PREEMPT_RT build with debug code enabled because
that might_sleep() in cond_resched() remains and triggers a warnings.
This is due to
legacy_kthread_func-> console_flush_one_record -> vt_console_print-> lf
-> con_scroll -> fbcon_scroll
and vt_console_print() acquires a spinlock_t which does not allow a
voluntary schedule. There is no need to fb_scroll() to schedule since
console_flush_one_record() attempts to schedule after each line.
!PREEMPT_RT is not affected because the legacy printing thread is only
enabled on PREEMPT_RT builds.
Therefore I suggest to remove console_conditional_schedule().
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Fixes: 5f53ca3ff83b4 ("printk: Implement legacy printer kthread for PREEMPT_RT")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
A follow-up to
https://lore.kernel.org/all/20260114145955.d924Z-zu@linutronix.de/
drivers/tty/vt/vt.c | 1 -
drivers/video/fbdev/core/fbcon.c | 6 ------
include/linux/console.h | 1 -
kernel/printk/printk.c | 16 ----------------
4 files changed, 24 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..53daf7614b1af 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3236,7 +3236,6 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
goto rescan_last_byte;
}
con_flush(vc, &draw);
- console_conditional_schedule();
notify_update(vc);
return n;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7be9e865325d9..36dd9d4a46ae0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1607,12 +1607,10 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
start = s;
}
}
- console_conditional_schedule();
s++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, dy, x);
- console_conditional_schedule();
dy++;
}
}
@@ -1648,14 +1646,12 @@ static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
par->bitops->bmove(vc, info, line + ycount, x, line, x, 1,
s - start);
- console_conditional_schedule();
if (ycount > 0)
line++;
else {
@@ -1703,13 +1699,11 @@ static void fbcon_redraw(struct vc_data *vc, int line, int count, int offset)
}
}
scr_writew(c, d);
- console_conditional_schedule();
s++;
d++;
} while (s < le);
if (s > start)
fbcon_putcs(vc, start, s - start, line, x);
- console_conditional_schedule();
if (offset > 0)
line++;
else {
diff --git a/include/linux/console.h b/include/linux/console.h
index fc9f5c5c1b04c..ec506d3501965 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -697,7 +697,6 @@ extern int unregister_console(struct console *);
extern void console_lock(void);
extern int console_trylock(void);
extern void console_unlock(void);
-extern void console_conditional_schedule(void);
extern void console_unblank(void);
extern void console_flush_on_panic(enum con_flush_mode mode);
extern struct tty_driver *console_device(int *);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1d765ad242b82..9296bf41aa49d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3362,22 +3362,6 @@ void console_unlock(void)
}
EXPORT_SYMBOL(console_unlock);
-/**
- * console_conditional_schedule - yield the CPU if required
- *
- * If the console code is currently allowed to sleep, and
- * if this CPU should yield the CPU to another task, do
- * so here.
- *
- * Must be called within console_lock();.
- */
-void __sched console_conditional_schedule(void)
-{
- if (console_may_schedule)
- cond_resched();
-}
-EXPORT_SYMBOL(console_conditional_schedule);
-
void console_unblank(void)
{
bool found_unblank = false;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v1 v1 3/4] rust: fb: add framebuffer driver support
From: kernel test robot @ 2026-01-26 22:29 UTC (permalink / raw)
To: pengfuyuan, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda
Cc: llvm, oe-kbuild-all, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Thomas Zimmermann, Lee Jones, Sam Ravnborg,
Zsolt Kajtar, Ville Syrjälä, rust-for-linux,
linux-kernel, dri-devel, linux-fbdev, pengfuyuan
In-Reply-To: <20260126081744.781392-4-pengfuyuan@kylinos.cn>
Hi pengfuyuan,
kernel test robot noticed the following build errors:
[auto build test ERROR on rust/rust-next]
[also build test ERROR on driver-core/driver-core-linus linus/master v6.19-rc7]
[cannot apply to driver-core/driver-core-testing driver-core/driver-core-next next-20260123]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/pengfuyuan/rust-io-mem-add-ioremap_wc-support/20260126-162117
base: https://github.com/Rust-for-Linux/linux rust-next
patch link: https://lore.kernel.org/r/20260126081744.781392-4-pengfuyuan%40kylinos.cn
patch subject: [PATCH v1 v1 3/4] rust: fb: add framebuffer driver support
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260127/202601270630.FHzCSbVv-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260127/202601270630.FHzCSbVv-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601270630.FHzCSbVv-lkp@intel.com/
All errors (new ones prefixed by >>):
>> error[E0308]: mismatched types
--> rust/kernel/fb/device.rs:307:23
|
307 | fb_read: Some(Self::read_callback),
| ---- ^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item
| |
| arguments to this enum variant are incorrect
|
= note: expected fn pointer `unsafe extern "C" fn(_, *mut u8, _, _) -> _`
found fn item `extern "C" fn(_, *mut i8, _, _) -> _ {fb::device::Device::<T>::read_callback}`
help: the type constructed contains `extern "C" fn(*mut fb_info, *mut i8, usize, *mut i64) -> isize {fb::device::Device::<T>::read_callback}` due to the type of the argument passed
--> rust/kernel/fb/device.rs:307:18
|
307 | fb_read: Some(Self::read_callback),
| ^^^^^-------------------^
| |
| this argument influences the type of `Some`
note: tuple variant defined here
--> /opt/cross/rustc-1.88.0-bindgen-0.72.1/rustup/toolchains/1.88.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:597:5
|
597 | Some(#[stable(feature = "rust1", since = "1.0.0")] T),
| ^^^^
--
>> error[E0308]: mismatched types
--> rust/kernel/fb/device.rs:308:24
|
308 | fb_write: Some(Self::write_callback),
| ---- ^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item
| |
| arguments to this enum variant are incorrect
|
= note: expected fn pointer `unsafe extern "C" fn(_, *const u8, _, _) -> _`
found fn item `extern "C" fn(_, *const i8, _, _) -> _ {fb::device::Device::<T>::write_callback}`
help: the type constructed contains `extern "C" fn(*mut fb_info, *const i8, usize, *mut i64) -> isize {fb::device::Device::<T>::write_callback}` due to the type of the argument passed
--> rust/kernel/fb/device.rs:308:19
|
308 | fb_write: Some(Self::write_callback),
| ^^^^^--------------------^
| |
| this argument influences the type of `Some`
note: tuple variant defined here
--> /opt/cross/rustc-1.88.0-bindgen-0.72.1/rustup/toolchains/1.88.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:597:5
|
597 | Some(#[stable(feature = "rust1", since = "1.0.0")] T),
| ^^^^
--
>> error[E0308]: mismatched types
--> rust/kernel/fb/io.rs:32:13
|
30 | bindings::fb_io_read(
| -------------------- arguments to this function are incorrect
31 | device.as_raw(),
32 | buf.as_mut_ptr() as *mut core::ffi::c_char,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*mut u8`, found `*mut i8`
|
= note: expected raw pointer `*mut u8`
found raw pointer `*mut i8`
note: function defined here
--> rust/bindings/bindings_generated.rs:123562:12
|
123562 | pub fn fb_io_read(
| ^^^^^^^^^^
--
>> error[E0308]: mismatched types
--> rust/kernel/fb/io.rs:58:13
|
56 | bindings::fb_io_write(
| --------------------- arguments to this function are incorrect
57 | device.as_raw(),
58 | buf.as_ptr() as *const core::ffi::c_char,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*const u8`, found `*const i8`
|
= note: expected raw pointer `*const u8`
found raw pointer `*const i8`
note: function defined here
--> rust/bindings/bindings_generated.rs:123570:12
|
123570 | pub fn fb_io_write(
| ^^^^^^^^^^^
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: pengfuyuan @ 2026-01-27 8:04 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thomas Zimmermann, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Helge Deller,
Hans de Goede, Lee Jones, Sam Ravnborg, Zsolt Kajtar,
Ville Syrjälä, rust-for-linux, linux-kernel, dri-devel,
linux-fbdev
In-Reply-To: <DFYG7MT5JINY.1T8ZZ4ASIWXU@nvidia.com>
On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 26.01.26 um 09:17 schrieb pengfuyuan:
> >> This patch series adds Rust bindings and safe abstractions for the Linux
> >> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
> >
> > The framebuffer subsystem is obsolete and has been deprecated for a
> > decade. No new drivers accepted. Anything that really wants fbdev
> > already has a driver. Can we please let it die?
>
> This, and the patchset is also obviously AI-generated.
Hi,
Thank you for the feedback.
I’d like to be clear about how I used AI in this work:
1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
2.Comments in the code – Some comments were written or refined with AI assistance.
3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
4.Writing the code – The implementation was not fully generated by AI. I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”) while I was coding.
So: AI was used for summaries, comments, learning, and looking things up; the logic and structure of the code are mine, and I take responsibility for them.
If you have concerns about specific parts (e.g. wording, style, or design), I’m happy to rework those patches or to adjust how I describe tool use in future submissions.
Thanks,
pengfuyuan
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Helge Deller @ 2026-01-27 8:16 UTC (permalink / raw)
To: pengfuyuan, Alexandre Courbot
Cc: Thomas Zimmermann, Danilo Krummrich, Alice Ryhl, Daniel Almeida,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Greg Kroah-Hartman,
Rafael J . Wysocki, David Airlie, Simona Vetter, Hans de Goede,
Lee Jones, Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20260127080419.GA965382@peng>
On 1/27/26 09:04, pengfuyuan wrote:
> On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
>> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>>>> This patch series adds Rust bindings and safe abstractions for the Linux
>>>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>>>
>>> The framebuffer subsystem is obsolete and has been deprecated for a
>>> decade. No new drivers accepted. Anything that really wants fbdev
>>> already has a driver. Can we please let it die?
>>
>> This, and the patchset is also obviously AI-generated.
>
> Hi,
> Thank you for the feedback.
> I’d like to be clear about how I used AI in this work:
>
> 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
> 2.Comments in the code – Some comments were written or refined with AI assistance.
> 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
> 4.Writing the code – The implementation was not fully generated by AI. I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”) while I was coding.
>
> So: AI was used for summaries, comments, learning, and looking
> things up; the logic and structure of the code are mine, and I take
> responsibility for them.
> If you have concerns about specific parts (e.g. wording, style, or
> design), I’m happy to rework those patches or to adjust how I
> describe tool use in future submissions.
No.
Please don't resend any patches for the fbdev layer.
There is no need to provide rust bindings for fbdev, as new
graphics drivers should use DRM.
Helge
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: pengfuyuan @ 2026-01-27 8:30 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Alexandre Courbot, Thomas Zimmermann, Danilo Krummrich,
Alice Ryhl, Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Greg Kroah-Hartman, Rafael J . Wysocki,
David Airlie, Simona Vetter, Helge Deller, Hans de Goede,
Lee Jones, Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <CANiq72kRhkLKcc279CacJ8CnQ18JEZ4A9-vkcg_k4Jw88O4EDw@mail.gmail.com>
On Mon, Jan 26, 2026 at 12:46:41PM +0100, Miguel Ojeda wrote:
> On Mon, Jan 26, 2026 at 11:28 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >
> > This, and the patchset is also obviously AI-generated.
>
> pengfuyuan: the generated content guidelines I mentioned earlier this
> month in another of your patches have been merged now, please read:
>
> https://docs.kernel.org/next/process/generated-content.html
>
> Thanks!
>
> Cheers,
> Miguel
Hi Miguel,
Thank you for the pointer. I've read the generated content guidelines at
https://docs.kernel.org/next/process/generated-content.html and will follow
them.
For transparency, here is the disclosure for my contribution:
Tools used:
- Cursor (IDE) with Claude Sonnet 4.5
Parts affected by tool use:
- Cover letter: The cover letter text was summarized/written with AI assistance.
- Code comments: Comments in the code were written with AI assistance.
- Learning and development: I used AI to help analyze existing Rust for Linux
framework code (e.g. rust/kernel/drm and similar abstractions) and to look
up existing traits/abstractions while writing the code. The code itself was
not fully AI-generated; I wrote it with AI used as an aid for querying
existing abstractions and patterns.
Testing:
- I tested on a real ARM64 machine, manually swapping six different
graphics cards to verify the changes.
I understand and can explain the code I submit, and I'm prepared to respond
to review comments.
Thanks,
pengfuyuan
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: pengfuyuan @ 2026-01-27 8:58 UTC (permalink / raw)
To: Helge Deller
Cc: Alexandre Courbot, Thomas Zimmermann, Danilo Krummrich,
Alice Ryhl, Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Greg Kroah-Hartman, Rafael J . Wysocki,
David Airlie, Simona Vetter, Hans de Goede, Lee Jones,
Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <578209b5-6d22-4255-a2e6-256d3f5afa72@gmx.de>
On Tue, Jan 27, 2026 at 09:16:35AM +0100, Helge Deller wrote:
> On 1/27/26 09:04, pengfuyuan wrote:
> > On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
> > > On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am 26.01.26 um 09:17 schrieb pengfuyuan:
> > > > > This patch series adds Rust bindings and safe abstractions for the Linux
> > > > > framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
> > > >
> > > > The framebuffer subsystem is obsolete and has been deprecated for a
> > > > decade. No new drivers accepted. Anything that really wants fbdev
> > > > already has a driver. Can we please let it die?
> > >
> > > This, and the patchset is also obviously AI-generated.
> >
> > Hi,
> > Thank you for the feedback.
> > I’d like to be clear about how I used AI in this work:
> >
> > 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
> > 2.Comments in the code – Some comments were written or refined with AI assistance.
> > 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
> > 4.Writing the code – The implementation was not fully generated by AI. I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”) while I was coding.
> >
> > So: AI was used for summaries, comments, learning, and looking
> > things up; the logic and structure of the code are mine, and I take
> > responsibility for them.
> > If you have concerns about specific parts (e.g. wording, style, or
> > design), I’m happy to rework those patches or to adjust how I
> > describe tool use in future submissions.
>
> No.
> Please don't resend any patches for the fbdev layer.
> There is no need to provide rust bindings for fbdev, as new
> graphics drivers should use DRM.
>
> Helge
Hi Helge,
Thank you for the clarification, I understand. I will not resend any fbdev
patches.
Just to give some background on why I started with Rust framebuffer bindings:
our company has a new graphics card, and the plan is to gradually implement
the display controller (DC) driver using the Rust-for-Linux DRM framework.
My goal is to bring up the display step by step on an ARM64 system with this
new GPU.
Since it looks like the current Rust DRM support does not yet include KMS
abstractions (CRTC/plane/connector etc.), my initial idea was to first use a
simple framebuffer-based approach to light up the display, and then later
migrate the DC driver to DRM and eventually to KMS abstractions in Rust.
Given your feedback, I will drop the fbdev approach and focus on DRM instead.
I would like to ask about the current status and plans for Rust DRM KMS
support:
- Is there any active work or a design for KMS abstractions in Rust?
- Is there a WIP tree or an RFC that I could look at?
- Are there specific areas where I could help (e.g. prototyping KMS bindings,
writing tests, or working on smaller pieces under guidance)?
My goal is to eventually run the DC driver for this new GPU using the Rust
DRM stack on that ARM64 system, so I would be happy to help where it is most
useful for the project.
Thank you again for your time and guidance.
Best regards,
pengfuyuan
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Greg Kroah-Hartman @ 2026-01-27 9:35 UTC (permalink / raw)
To: pengfuyuan
Cc: Helge Deller, Alexandre Courbot, Thomas Zimmermann,
Danilo Krummrich, Alice Ryhl, Daniel Almeida, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Rafael J . Wysocki, David Airlie,
Simona Vetter, Hans de Goede, Lee Jones, Sam Ravnborg,
Zsolt Kajtar, Ville Syrjälä, rust-for-linux,
linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20260127085826.GA970322@peng>
On Tue, Jan 27, 2026 at 04:58:26PM +0800, pengfuyuan wrote:
> I would like to ask about the current status and plans for Rust DRM KMS
> support:
>
> - Is there any active work or a design for KMS abstractions in Rust?
Very much so, look at the patches on the rust mailing list for them!
> - Is there a WIP tree or an RFC that I could look at?
Again, look at the list, there are loads of patches there.
> - Are there specific areas where I could help (e.g. prototyping KMS bindings,
> writing tests, or working on smaller pieces under guidance)?
Build on the patches that have been submitted and work from there?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 v1 0/4] [RUST] Framebuffer driver support
From: Helge Deller @ 2026-01-27 9:38 UTC (permalink / raw)
To: pengfuyuan
Cc: Alexandre Courbot, Thomas Zimmermann, Danilo Krummrich,
Alice Ryhl, Daniel Almeida, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Greg Kroah-Hartman, Rafael J . Wysocki,
David Airlie, Simona Vetter, Hans de Goede, Lee Jones,
Sam Ravnborg, Zsolt Kajtar, Ville Syrjälä,
rust-for-linux, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20260127085826.GA970322@peng>
On 1/27/26 09:58, pengfuyuan wrote:
> On Tue, Jan 27, 2026 at 09:16:35AM +0100, Helge Deller wrote:
>> On 1/27/26 09:04, pengfuyuan wrote:
>>> On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
>>>> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
>>>>> Hi
>>>>>
>>>>> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>>>>>> This patch series adds Rust bindings and safe abstractions for the Linux
>>>>>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>>>>>
>>>>> The framebuffer subsystem is obsolete and has been deprecated for a
>>>>> decade. No new drivers accepted. Anything that really wants fbdev
>>>>> already has a driver. Can we please let it die?
>>>>
>>>> This, and the patchset is also obviously AI-generated.
>>>
>>> Hi,
>>> Thank you for the feedback.
>>> I’d like to be clear about how I used AI in this work:
>>>
>>> 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
>>> 2.Comments in the code – Some comments were written or refined with AI assistance.
>>> 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
>>> 4.Writing the code – The implementation was not fully generated by AI. I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”) while I was coding.
>>>
>>> So: AI was used for summaries, comments, learning, and looking
>>> things up; the logic and structure of the code are mine, and I take
>>> responsibility for them.
>>> If you have concerns about specific parts (e.g. wording, style, or
>>> design), I’m happy to rework those patches or to adjust how I
>>> describe tool use in future submissions.
>>
>> No.
>> Please don't resend any patches for the fbdev layer.
>> There is no need to provide rust bindings for fbdev, as new
>> graphics drivers should use DRM.
>>
>> Helge
>
> Hi Helge,
>
> Thank you for the clarification, I understand. I will not resend any fbdev
> patches.
>
> Just to give some background on why I started with Rust framebuffer bindings:
> our company has a new graphics card, and the plan is to gradually implement
> the display controller (DC) driver using the Rust-for-Linux DRM framework.
> My goal is to bring up the display step by step on an ARM64 system with this
> new GPU.
>
> Since it looks like the current Rust DRM support does not yet include KMS
> abstractions (CRTC/plane/connector etc.), my initial idea was to first use a
> simple framebuffer-based approach to light up the display, and then later
> migrate the DC driver to DRM and eventually to KMS abstractions in Rust.
>
> Given your feedback, I will drop the fbdev approach and focus on DRM instead.
>
> I would like to ask about the current status and plans for Rust DRM KMS
> support:
>
> - Is there any active work or a design for KMS abstractions in Rust?
> - Is there a WIP tree or an RFC that I could look at?
> - Are there specific areas where I could help (e.g. prototyping KMS bindings,
> writing tests, or working on smaller pieces under guidance)?
>
> My goal is to eventually run the DC driver for this new GPU using the Rust
> DRM stack on that ARM64 system, so I would be happy to help where it is most
> useful for the project.
>
> Thank you again for your time and guidance.
Since you asked me directly, here is my very personal opinion:
Rust might be the best and most secure programming language on earth.
Nevertheless, *I* would write a standard DRM driver in C, based on
existing C APIs and drivers, as this seems to be the most fastest and
easiest way to get a functional driver that behaves as existing drivers.
I'm sure someone here on this list will provide you with
better answers to your Rust and DRM questions above.
Helge
^ permalink raw reply
* [PATCH] staging: sm750fb: make fixId array const
From: Madhumitha Sundar @ 2026-01-27 11:42 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Madhumitha Sundar
The fixId array contains constant string literals, but the array itself is
currently mutable.
Make the array const so that the compiler can place it in the read-only
data section (.rodata) instead of writable memory.
This fixes a warning detected by checkpatch.pl:
WARNING: static const char * array should probably be static const char * const
Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index fecd7457e..ff590061c 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -740,7 +740,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
"kernel HELPERS prepared vesa_modes",
};
- static const char *fixId[2] = {
+ static const char * const fixId[2] = {
"sm750_fb1", "sm750_fb2",
};
--
2.43.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: rename initParm to init_parm
From: Madhumitha Sundar @ 2026-01-27 12:11 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Madhumitha Sundar
The Linux kernel coding style prefers snake_case over CamelCase for
variable names.
Rename the 'initParm' member to 'init_parm' to comply with this
standard.
Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 12 ++++++------
drivers/staging/sm750fb/sm750.h | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index fecd7457e..6f15131ee 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -918,12 +918,12 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
swap = 0;
- sm750_dev->initParm.chip_clk = 0;
- sm750_dev->initParm.mem_clk = 0;
- sm750_dev->initParm.master_clk = 0;
- sm750_dev->initParm.powerMode = 0;
- sm750_dev->initParm.setAllEngOff = 0;
- sm750_dev->initParm.resetMemory = 1;
+ sm750_dev->init_parm.chip_clk = 0;
+ sm750_dev->init_parm.mem_clk = 0;
+ sm750_dev->init_parm.master_clk = 0;
+ sm750_dev->init_parm.powerMode = 0;
+ sm750_dev->init_parm.setAllEngOff = 0;
+ sm750_dev->init_parm.resetMemory = 1;
/* defaultly turn g_hwcursor on for both view */
g_hwcursor = 3;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index fcb7d586e..67b9bfa23 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -102,7 +102,7 @@ struct sm750_dev {
/* locks*/
spinlock_t slock;
- struct init_status initParm;
+ struct init_status init_parm;
enum sm750_pnltype pnltype;
enum sm750_dataflow dataflow;
int nocrt;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index ce46f240c..a29faee91 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -93,7 +93,7 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
{
struct init_status *parm;
- parm = &sm750_dev->initParm;
+ parm = &sm750_dev->init_parm;
if (parm->chip_clk == 0)
parm->chip_clk = (sm750_get_chip_type() == SM750LE) ?
DEFAULT_SM750LE_CHIP_CLOCK :
@@ -104,7 +104,7 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
if (parm->master_clk == 0)
parm->master_clk = parm->chip_clk / 3;
- ddk750_init_hw((struct initchip_param *)&sm750_dev->initParm);
+ ddk750_init_hw((struct initchip_param *)&sm750_dev->init_parm);
/* for sm718, open pci burst */
if (sm750_dev->devid == 0x718) {
poke32(SYSTEM_CTRL,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: backlight: gpio-backlight: allow multiple GPIOs
From: tessolveupstream @ 2026-01-27 12:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, lee, danielt, jingoohan1
Cc: deller, pavel, robh, krzk+dt, conor+dt, dri-devel, linux-fbdev,
linux-leds, devicetree, linux-kernel
In-Reply-To: <54d156ba-e177-4059-a808-2505983b4e2e@gmail.com>
On 23-01-2026 16:41, tessolveupstream@gmail.com wrote:
>
>
> On 20-01-2026 20:01, Krzysztof Kozlowski wrote:
>> On 20/01/2026 13:50, Sudarshan Shetty wrote:
>>> Update the gpio-backlight binding to support configurations that require
>>> more than one GPIO for enabling/disabling the backlight.
>>
>>
>> Why? Which devices need it? How a backlight would have three enable
>> GPIOs? I really do not believe, so you need to write proper hardware
>> justification.
>>
>
> To clarify our hardware setup:
> the panel requires one GPIO for the backlight enable signal, and it
> also has a PWM input. Since the QCS615 does not provide a PWM controller
> for this use case, the PWM input is connected to a GPIO that is driven
> high to provide a constant 100% duty cycle, as explained in the link
> below.
> https://lore.kernel.org/all/20251028061636.724667-1-tessolveupstream@gmail.com/T/#m93ca4e5c7bf055715ed13316d91f0cd544244cf5
>
>>>
>>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
>>> ---
>>> .../leds/backlight/gpio-backlight.yaml | 24 +++++++++++++++++--
>>> 1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>>> index 584030b6b0b9..4e4a856cbcd7 100644
>>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>>> @@ -16,8 +16,18 @@ properties:
>>> const: gpio-backlight
>>>
>>> gpios:
>>> - description: The gpio that is used for enabling/disabling the backlight.
>>> - maxItems: 1
>>> + description: |
>>> + The gpio that is used for enabling/disabling the backlight.
>>> + Multiple GPIOs can be specified for panels that require several
>>> + enable signals. All GPIOs are controlled together.
>>> + type: array
>>
>> There is no such syntax in the bindings, from where did you get it? Type
>> is already defined.
>>
>> items:
>> minItems: 1
>> maxItems: 3
>>
>>
>>> + minItems: 1
>>> + items:
>>> + type: array
>>> + minItems: 3
>>> + maxItems: 3
>>> + items:
>>> + type: integer
>>
>> All this is some odd stuff - just to be clear, don't send us LLM output.
>> I don't want to waste my time to review microslop.
>>
>> Was it done with help of Microslop?
>>
>
> I understand now that the schema changes I proposed were not correct,
> and I will address this in the next patch series. My intention was to
> check whether the gpio-backlight binding could support more than one
> enable-type GPIO.
> Could you please advise what would be an appropriate maximum number of
> GPIOs for gpio-backlight in such a scenario? For example, would allowing
> 2 GPIOs be acceptable, or should this case be handled in a different way?
>
In line with Daniel’s suggestion, I am planning to adopt a fixed upper
limit for the number of backlight GPIOs. The current hardware only
requires two GPIOs, so the maxItems can be set to 2.
If future platforms or customers require support for a higher number
of GPIOs, this limit can be increased and the driver can be
updated accordingly.
Kindly advise if this solution aligns with your expectations, or if
you prefer an alternative maximum value.
>> Best regards,
>> Krzysztof
>
^ permalink raw reply
* [PATCH] staging: sm750fb: replace magic number with defined constant
From: Madhumitha Sundar @ 2026-01-27 13:27 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Madhumitha Sundar
The hardware wait loop in hw_sm750_de_wait uses a hardcoded magic
number (0x10000000) for the timeout counter.
Define a constant SM750_MAX_LOOP in sm750.h and use it to improve
code readability and maintainability.
Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
---
drivers/staging/sm750fb/sm750.h | 2 ++
drivers/staging/sm750fb/sm750_hw.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index fcb7d586e..ae07ceec1 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -12,6 +12,8 @@
#define SM750LE_REVISION_ID ((unsigned char)0xfe)
#endif
+#define SM750_MAX_LOOP 0x10000000
+
enum sm750_pnltype {
sm750_24TFT = 0, /* 24bit tft */
sm750_dualTFT = 2, /* dual 18 bit tft */
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index ce46f240c..f051bd75f 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -523,7 +523,7 @@ int hw_sm750le_de_wait(void)
int hw_sm750_de_wait(void)
{
- int i = 0x10000000;
+ int i = SM750_MAX_LOOP;
unsigned int mask = SYSTEM_CTRL_DE_STATUS_BUSY |
SYSTEM_CTRL_DE_FIFO_EMPTY |
SYSTEM_CTRL_DE_MEM_FIFO_EMPTY;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: replace magic number with defined constant
From: Greg KH @ 2026-01-27 13:32 UTC (permalink / raw)
To: Madhumitha Sundar
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260127132758.49650-1-madhuananda18@gmail.com>
On Tue, Jan 27, 2026 at 01:27:58PM +0000, Madhumitha Sundar wrote:
> The hardware wait loop in hw_sm750_de_wait uses a hardcoded magic
> number (0x10000000) for the timeout counter.
>
> Define a constant SM750_MAX_LOOP in sm750.h and use it to improve
> code readability and maintainability.
>
> Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.h | 2 ++
> drivers/staging/sm750fb/sm750_hw.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index fcb7d586e..ae07ceec1 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -12,6 +12,8 @@
> #define SM750LE_REVISION_ID ((unsigned char)0xfe)
> #endif
>
> +#define SM750_MAX_LOOP 0x10000000
> +
> enum sm750_pnltype {
> sm750_24TFT = 0, /* 24bit tft */
> sm750_dualTFT = 2, /* dual 18 bit tft */
> diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
> index ce46f240c..f051bd75f 100644
> --- a/drivers/staging/sm750fb/sm750_hw.c
> +++ b/drivers/staging/sm750fb/sm750_hw.c
> @@ -523,7 +523,7 @@ int hw_sm750le_de_wait(void)
>
> int hw_sm750_de_wait(void)
> {
> - int i = 0x10000000;
> + int i = SM750_MAX_LOOP;
> unsigned int mask = SYSTEM_CTRL_DE_STATUS_BUSY |
> SYSTEM_CTRL_DE_FIFO_EMPTY |
> SYSTEM_CTRL_DE_MEM_FIFO_EMPTY;
This type of "loop delay" does not work at all. Can you try to fix this
up to use a proper timing check instead of just relying on how fast the
CPU can process instructions?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] printk, vt, fbcon: Remove console_conditional_schedule()
From: Greg Kroah-Hartman @ 2026-01-27 14:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-serial, linux-fbdev, dri-devel,
linux-rt-devel, Petr Mladek, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Jiri Slaby, Simona Vetter, Helge Deller
In-Reply-To: <20260126180836.SNCdMW2f@linutronix.de>
On Mon, Jan 26, 2026 at 07:08:36PM +0100, Sebastian Andrzej Siewior wrote:
> do_con_write(), fbcon_redraw.*() invoke console_conditional_schedule()
> which is a conditional scheduling point based on printk's internal
> variables console_may_schedule. It may only be used if the console lock
> is acquired for instance via console_lock() or console_trylock().
>
> Prinkt sets the internal variable to 1 (and allows to schedule)
> if the console lock has been acquired via console_lock(). The trylock
> does not allow it.
>
> The console_conditional_schedule() invocation in do_con_write() is
> invoked shortly before console_unlock().
> The console_conditional_schedule() invocation in fbcon_redraw.*()
> original from fbcon_scroll() / vt's con_scroll() which originate from a
> line feed.
>
> In console_unlock() the variable is set to 0 (forbids to schedule) and
> it tries to schedule while making progress printing. This is brand new
> compared to when console_conditional_schedule() was added in v2.4.9.11.
>
> In v2.6.38-rc3, console_unlock() (started its existence) iterated over
> all consoles and flushed them with disabled interrupts. A scheduling
> attempt here was not possible, it relied that a long print scheduled
> before console_unlock().
>
> Since commit 8d91f8b15361d ("printk: do cond_resched() between lines
> while outputting to consoles"), which appeared in v4.5-rc1,
> console_unlock() attempts to schedule if it was allowed to schedule
> while during console_lock(). Each record is idealy one line so after
> every line feed.
>
> This console_conditional_schedule() is also only relevant on
> PREEMPT_NONE and PREEMPT_VOLUNTARY builds. In other configurations
> cond_resched() becomes a nop and has no impact.
>
> I'm bringing this all up just proof that it is not required anymore. It
> becomes a problem on a PREEMPT_RT build with debug code enabled because
> that might_sleep() in cond_resched() remains and triggers a warnings.
> This is due to
>
> legacy_kthread_func-> console_flush_one_record -> vt_console_print-> lf
> -> con_scroll -> fbcon_scroll
>
> and vt_console_print() acquires a spinlock_t which does not allow a
> voluntary schedule. There is no need to fb_scroll() to schedule since
> console_flush_one_record() attempts to schedule after each line.
> !PREEMPT_RT is not affected because the legacy printing thread is only
> enabled on PREEMPT_RT builds.
>
> Therefore I suggest to remove console_conditional_schedule().
>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Fixes: 5f53ca3ff83b4 ("printk: Implement legacy printer kthread for PREEMPT_RT")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>
> A follow-up to
> https://lore.kernel.org/all/20260114145955.d924Z-zu@linutronix.de/
>
> drivers/tty/vt/vt.c | 1 -
> drivers/video/fbdev/core/fbcon.c | 6 ------
> include/linux/console.h | 1 -
> kernel/printk/printk.c | 16 ----------------
> 4 files changed, 24 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 59b4b5e126ba1..53daf7614b1af 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3236,7 +3236,6 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
> goto rescan_last_byte;
> }
> con_flush(vc, &draw);
> - console_conditional_schedule();
> notify_update(vc);
>
> return n;
No objection from me about removing this if it's not needed anymore!
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: make fixId array const
From: Greg KH @ 2026-01-27 14:49 UTC (permalink / raw)
To: Madhumitha Sundar
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260127114232.29504-1-madhuananda18@gmail.com>
On Tue, Jan 27, 2026 at 11:42:32AM +0000, Madhumitha Sundar wrote:
> The fixId array contains constant string literals, but the array itself is
> currently mutable.
>
> Make the array const so that the compiler can place it in the read-only
> data section (.rodata) instead of writable memory.
>
> This fixes a warning detected by checkpatch.pl:
> WARNING: static const char * array should probably be static const char * const
>
> Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index fecd7457e..ff590061c 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -740,7 +740,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
> "kernel HELPERS prepared vesa_modes",
> };
>
> - static const char *fixId[2] = {
> + static const char * const fixId[2] = {
> "sm750_fb1", "sm750_fb2",
> };
>
> --
> 2.43.0
>
>
Does not apply to my tree at all, please rebase and resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] staging: sm750fb: replace magic number with jiffies timeout
From: Madhumitha Sundar @ 2026-01-27 15:40 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Madhumitha Sundar
The hardware wait loop in hw_sm750_de_wait used a hardcoded loop
counter (0x10000000), which depends on CPU speed and is unreliable.
Replace the loop counter with a jiffies-based timeout (1 second)
using time_before(). This ensures consistent delays across architectures.
Signed-off-by: Madhumitha Sundar <madhuananda18@gmail.com>
---
Changes in v2:
- Switched from loop counter to jiffies + cpu_relax() as requested by Greg KH.
---
drivers/staging/sm750fb/sm750_hw.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index ce46f240c..b24d27a77 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -523,19 +523,32 @@ int hw_sm750le_de_wait(void)
int hw_sm750_de_wait(void)
{
- int i = 0x10000000;
+ /* Wait for 1 second (HZ) */
+ unsigned long timeout = jiffies + HZ;
unsigned int mask = SYSTEM_CTRL_DE_STATUS_BUSY |
SYSTEM_CTRL_DE_FIFO_EMPTY |
SYSTEM_CTRL_DE_MEM_FIFO_EMPTY;
+ unsigned int val;
- while (i--) {
- unsigned int val = peek32(SYSTEM_CTRL);
+ /* Run while Current Time is BEFORE the Deadline */
+ while (time_before(jiffies, timeout)) {
+ val = peek32(SYSTEM_CTRL);
+ /* If Not Busy (0) AND Buffers Empty (1), we are good */
if ((val & mask) ==
(SYSTEM_CTRL_DE_FIFO_EMPTY | SYSTEM_CTRL_DE_MEM_FIFO_EMPTY))
return 0;
+
+ /* Polite pause to save power */
+ cpu_relax();
}
- /* timeout error */
+
+ /* Final check in case we succeeded at the last millisecond */
+ val = peek32(SYSTEM_CTRL);
+ if ((val & mask) ==
+ (SYSTEM_CTRL_DE_FIFO_EMPTY | SYSTEM_CTRL_DE_MEM_FIFO_EMPTY))
+ return 0;
+
return -1;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] fbdev: vt8500lcdfb: fix missing dma_free_coherent()
From: Helge Deller @ 2026-01-27 17:17 UTC (permalink / raw)
To: Thomas Fourier; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260112140031.63594-2-fourier.thomas@gmail.com>
On 1/12/26 15:00, Thomas Fourier wrote:
> fbi->fb.screen_buffer is alloced with dma_free_coherent() but is not
I've corrected this to "dma_alloc_coherent()", as pointed out by Mr. Elfring,
and applied it to the fbdev tree.
Thanks!
Helge
> 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>
> ---
> drivers/video/fbdev/vt8500lcdfb.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH] video: of_display_timing: fix refcount leak in of_get_display_timings()
From: Helge Deller @ 2026-01-27 17:32 UTC (permalink / raw)
To: Weigang He; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260116095751.177055-1-geoffreyhe2@gmail.com>
On 1/16/26 10:57, Weigang He wrote:
> 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>
> ---
> drivers/video/of_display_timing.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied.
Thanks!
Helge
^ 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