* [PATCH] fbdev: au1100fb: Add missing check for clk_enable
From: Chen Ni @ 2026-01-28 9:10 UTC (permalink / raw)
To: deller, u.kleine-koenig, elfring
Cc: linux-fbdev, dri-devel, linux-kernel, Chen Ni
Add check for the return value of clk_enable() andreturn the error
if it fails in order to catch the error.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
drivers/video/fbdev/au1100fb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index 6251a6b07b3a..5e7a8f018b7b 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -567,13 +567,16 @@ int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state)
int au1100fb_drv_resume(struct platform_device *dev)
{
struct au1100fb_device *fbdev = platform_get_drvdata(dev);
+ int ret;
if (!fbdev)
return 0;
memcpy(fbdev->regs, &fbregs, sizeof(struct au1100fb_regs));
- clk_enable(fbdev->lcdclk);
+ ret = clk_enable(fbdev->lcdclk);
+ if (ret)
+ return ret;
/* Unblank the LCD */
au1100fb_fb_blank(VESA_NO_BLANKING, &fbdev->info);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] fbtft: Improve damage_range to mark only changed rows
From: Greg KH @ 2026-01-28 9:03 UTC (permalink / raw)
To: Waffle0823; +Cc: andy, dri-devel, linux-fbdev, linux-staging
In-Reply-To: <20260128085720.862399-1-csshin9928@gmail.com>
On Wed, Jan 28, 2026 at 05:57:20PM +0900, Waffle0823 wrote:
> Instead of marking the entire display as dirty, calculate
> start_row and end_row based on off/len and mark only those rows.
> This improves performance for partial framebuffer updates.
>
> Signed-off-by: Waffle0283 csshin9928@gmail.com
> ---
> drivers/staging/fbtft/fbtft-core.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index 8a5ccc8ae0a1..0fbdfdaaa94d 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -415,8 +415,11 @@ static void fbtft_ops_damage_range(struct fb_info *info, off_t off, size_t len)
> {
> struct fbtft_par *par = info->par;
>
> - /* TODO: only mark changed area update all for now */
> - par->fbtftops.mkdirty(info, -1, 0);
> + __u32 width = info->var.xres;
> + __u32 start_row = off / width;
> + __u32 end_row = (off + len - 1) / width;
> +
> + par->fbtftops.mkdirty(info, start_row, end_row);
> }
>
> static void fbtft_ops_damage_area(struct fb_info *info, u32 x, u32 y, u32 width, u32 height)
> --
> 2.52.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file,
Documentation/process/submitting-patches.rst for how to do this
correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH] printk, vt, fbcon: Remove console_conditional_schedule()
From: Petr Mladek @ 2026-01-28 9:02 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-serial, linux-fbdev, dri-devel,
linux-rt-devel, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Greg Kroah-Hartman, Jiri Slaby, Simona Vetter, Helge Deller
In-Reply-To: <20260126180836.SNCdMW2f@linutronix.de>
On Mon 2026-01-26 19:08:36, 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>
Just for record. This change looks OK from printk() POV.
printk() does console_trylock() and calls console_unlock()
with preemption disabled anyway, see vprintk_emit().
VT code still synchronizes some operations using console_lock().
It is possible that some non-printk related operations rely
on this. But it is hard to say. It might actually be a good
idea to find it out.
Also I have seen many printk-related softlockups. But they
were always caused by slow serial consoles. I can't remember
any in VT code.
Feel free to use:
Acked-by: Petr Mladek <pmladek@suse.com> # from printk() POV
Best Regards,
Petr
^ permalink raw reply
* [PATCH] fbtft: Improve damage_range to mark only changed rows
From: Waffle0823 @ 2026-01-28 8:57 UTC (permalink / raw)
To: andy; +Cc: gregkh, dri-devel, linux-fbdev, linux-staging, Waffle0823
Instead of marking the entire display as dirty, calculate
start_row and end_row based on off/len and mark only those rows.
This improves performance for partial framebuffer updates.
Signed-off-by: Waffle0283 csshin9928@gmail.com
---
drivers/staging/fbtft/fbtft-core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 8a5ccc8ae0a1..0fbdfdaaa94d 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -415,8 +415,11 @@ static void fbtft_ops_damage_range(struct fb_info *info, off_t off, size_t len)
{
struct fbtft_par *par = info->par;
- /* TODO: only mark changed area update all for now */
- par->fbtftops.mkdirty(info, -1, 0);
+ __u32 width = info->var.xres;
+ __u32 start_row = off / width;
+ __u32 end_row = (off + len - 1) / width;
+
+ par->fbtftops.mkdirty(info, start_row, end_row);
}
static void fbtft_ops_damage_area(struct fb_info *info, u32 x, u32 y, u32 width, u32 height)
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] fbdev: fix fb_pad_unaligned_buffer mask
From: Helge Deller @ 2026-01-27 20:47 UTC (permalink / raw)
To: Osama Abdelkader, Simona Vetter, Thomas Zimmermann, Lee Jones,
Murad Masimov, Yongzhen Zhang, Quanmin Yan, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <20260127193101.12343-1-osama.abdelkader@gmail.com>
On 1/27/26 20:30, Osama Abdelkader wrote:
> mask is u8, so it should use 0xff instead of 0xfff
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
> drivers/video/fbdev/core/fbmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2] fbdev: avoid out-of-bounds read in fb_pad_unaligned_buffer()
From: Osama Abdelkader @ 2026-01-27 19:40 UTC (permalink / raw)
To: Helge Deller
Cc: Simona Vetter, Thomas Zimmermann, Lee Jones,
Daniel Thompson (RISCstar), Murad Masimov, Quanmin Yan,
Yongzhen Zhang, linux-fbdev, dri-devel, linux-kernel,
syzbot+55e03490a0175b8dd81d
In-Reply-To: <889fd11b-80ea-4c23-b47f-4e6b17536b0f@gmx.de>
On Tue, Jan 27, 2026 at 06:57:32PM +0100, Helge Deller wrote:
> On 1/24/26 17:46, Osama Abdelkader wrote:
> > fb_pad_unaligned_buffer() unconditionally reads and advances the source
> > pointer for the final byte of each row, even when no bits from that byte
> > are actually consumed.
> >
> > When shift_high >= mod, the remaining bits do not cross a byte boundary,
> > but the code still accesses the next source byte. This can lead to
> > out-of-bounds reads under malformed geometry, as reported by syzbot.
> >
> > Fix this by only accessing and consuming the final source byte when it
> > contributes bits (shift_high < mod).
> >
> > This fixes the KASAN slab-out-of-bounds read reported by syzkaller:
> > https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d
> >
> > Reported-by: syzbot+55e03490a0175b8dd81d@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d
> > Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> > ---
> > v2: address the real issue (shift_high >= mod) condition.
> > ---
> > drivers/video/fbdev/core/fbmem.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index eff757ebbed1..d125c3db37a1 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -100,7 +100,7 @@ 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)
> > {
> > - u8 mask = (u8) (0xfff << shift_high), tmp;
> > + u8 mask = (u8) (0xff << shift_high), tmp;
>
> This part is correct, but shouldn't be part of this patch.
I just sent a seperate patch for that, and going to remove it in next version of this one.
>
>
> > int i, j;
> > for (i = height; i--; ) {
> > @@ -113,15 +113,18 @@ void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx, u32 height,
> > dst[j+1] = tmp;
> > src++;
> > }
> > - tmp = dst[idx];
> > - tmp &= mask;
> > - tmp |= *src >> shift_low;
> > - dst[idx] = tmp;
> > +
> > + /* Only consume another source byte if it contributes bits */
> > if (shift_high < mod) {
> > + tmp = dst[idx];
> > + tmp &= mask;
> > + tmp |= *src >> shift_low;
> > + dst[idx] = tmp;
> > tmp = *src << shift_high;
> > dst[idx+1] = tmp;
> > + src++;
> > }
> > - src++;
>
> Above you moved the src pointer inside the if(), so every line
> processed may miss a ptr increment. This means the source would need to
> be different too, but it hasn't changed, as it's still used from
> bit_putcs_unaligned() which prints a char from the character fonts.
>
> So, I believe this part at least is wrong.
> Did you test it?
>
I couldn't find syzbot's ReproC, so I did minimal one, I will re-test it and write you.
> Helge
BR,
Osama
^ permalink raw reply
* [PATCH] fbdev: fix fb_pad_unaligned_buffer mask
From: Osama Abdelkader @ 2026-01-27 19:30 UTC (permalink / raw)
To: Simona Vetter, Helge Deller, Thomas Zimmermann, Lee Jones,
Murad Masimov, Osama Abdelkader, Yongzhen Zhang, Quanmin Yan,
linux-fbdev, dri-devel, linux-kernel
mask is u8, so it should use 0xff instead of 0xfff
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
drivers/video/fbdev/core/fbmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index eff757ebbed1..cf199038f069 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -100,7 +100,7 @@ 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)
{
- u8 mask = (u8) (0xfff << shift_high), tmp;
+ u8 mask = (u8) (0xff << shift_high), tmp;
int i, j;
for (i = height; i--; ) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] printk, vt, fbcon: Remove console_conditional_schedule()
From: Helge Deller @ 2026-01-27 18:05 UTC (permalink / raw)
To: Greg Kroah-Hartman, 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
In-Reply-To: <2026012757-voting-griminess-ca35@gregkh>
On 1/27/26 15:24, Greg Kroah-Hartman wrote:
> 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
>> [....]
>
> No objection from me about removing this if it's not needed anymore!
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I've added it to the fbdev git tree to get some testing....
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2] fbdev: avoid out-of-bounds read in fb_pad_unaligned_buffer()
From: Helge Deller @ 2026-01-27 17:57 UTC (permalink / raw)
To: Osama Abdelkader, Simona Vetter, Thomas Zimmermann, Lee Jones,
Daniel Thompson (RISCstar), Murad Masimov, Quanmin Yan,
Yongzhen Zhang, linux-fbdev, dri-devel, linux-kernel
Cc: syzbot+55e03490a0175b8dd81d
In-Reply-To: <20260124164633.20444-1-osama.abdelkader@gmail.com>
On 1/24/26 17:46, Osama Abdelkader wrote:
> fb_pad_unaligned_buffer() unconditionally reads and advances the source
> pointer for the final byte of each row, even when no bits from that byte
> are actually consumed.
>
> When shift_high >= mod, the remaining bits do not cross a byte boundary,
> but the code still accesses the next source byte. This can lead to
> out-of-bounds reads under malformed geometry, as reported by syzbot.
>
> Fix this by only accessing and consuming the final source byte when it
> contributes bits (shift_high < mod).
>
> This fixes the KASAN slab-out-of-bounds read reported by syzkaller:
> https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d
>
> Reported-by: syzbot+55e03490a0175b8dd81d@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=55e03490a0175b8dd81d
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
> v2: address the real issue (shift_high >= mod) condition.
> ---
> drivers/video/fbdev/core/fbmem.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index eff757ebbed1..d125c3db37a1 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -100,7 +100,7 @@ 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)
> {
> - u8 mask = (u8) (0xfff << shift_high), tmp;
> + u8 mask = (u8) (0xff << shift_high), tmp;
This part is correct, but shouldn't be part of this patch.
> int i, j;
>
> for (i = height; i--; ) {
> @@ -113,15 +113,18 @@ void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx, u32 height,
> dst[j+1] = tmp;
> src++;
> }
> - tmp = dst[idx];
> - tmp &= mask;
> - tmp |= *src >> shift_low;
> - dst[idx] = tmp;
> +
> + /* Only consume another source byte if it contributes bits */
> if (shift_high < mod) {
> + tmp = dst[idx];
> + tmp &= mask;
> + tmp |= *src >> shift_low;
> + dst[idx] = tmp;
> tmp = *src << shift_high;
> dst[idx+1] = tmp;
> + src++;
> }
> - src++;
Above you moved the src pointer inside the if(), so every line
processed may miss a ptr increment. This means the source would need to
be different too, but it hasn't changed, as it's still used from
bit_putcs_unaligned() which prints a char from the character fonts.
So, I believe this part at least is wrong.
Did you test it?
Helge
^ 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
* 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
* [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] 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
* 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: 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
* [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 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: 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
* [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
* 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
* 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: 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: 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: 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: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
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