* Re: [PATCH] fbdev/arm: Export acorndata_8x8 font symbol for bootloader
From: Russell King (Oracle) @ 2026-06-09 9:46 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, dri-devel, Ethan Nelson-Moore, Thomas Zimmermann,
linux-arm-kernel
In-Reply-To: <20260609091056.265794-1-deller@gmx.de>
On Tue, Jun 09, 2026 at 11:10:56AM +0200, Helge Deller wrote:
> The text display code used in the Risc PC kernel image decompression
> code uses arch/arm/boot/compressed/font.c, which includes
> lib/fonts/font_acorn_8x8.c, which further includes <linux/font.h>.
>
> Since commit 97df8960240a ("lib/fonts: Provide helpers for calculating
> glyph pitch and size") <linux/font.h> contains inline functions that
> require __do_div64, which is not linked into the ARM kernel
> decompressor. This makes Risc PC zImages fail to build.
>
> Resolve this issue by defining the BOOTLOADER symbol and use it to avoid
> a static declaration of the acorndata_8x8 symbol. That way it can be
> referenced by the arm bootloader, and other static math functions and
> symbols (like __do_div64) stay static and don't get unneccesary included
> in the ARM kernel bootloader decompressor object file.
The decompressor font support has actually been broken since:
commit 6735b4632def0640dbdf4eb9f99816aca18c4f16
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date: Thu Sep 24 09:42:22 2020 -0400
Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
which added extra data to the beginning of the array of font
information:
ENTRY(ll_write_char)
stmfd sp!, {r4 - r7, lr}
...
/*
* calculate offset into character table
*/
mov r1, r1, lsl #3
r1 is the character, this multiplies the character value by 8.
adr ip, LC0
ldmia ip, {r3, r4, r5, r6, lr}
sub ip, ip, r3
add r6, r6, ip
in conjunction with the data table:
LC0: .word LC0
.word bytes_per_char_h
.word video_size_row
.word acorndata_8x8
.word con_charconvtable
results in r6 pointing at acorndata_8x8. We then index this using the
modified character value above:
orr r1, r1, #7
ldrb r7, [r6, r1]
This breaks if extra data is added to the start, and thus has been
broken since the above commit.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/1] video, sm501: Fix buffer errors in OF binding code
From: Helge Deller @ 2026-06-09 14:00 UTC (permalink / raw)
To: David Laight, Heiko Schocher, linux-fbdev, devicetree-discuss,
Ben Dooks, Vincent Sanders, Samuel Ortiz, linux-kernel,
Randy Dunlap, Paul Mundt, Danila Chernetsov, Kees Cook
In-Reply-To: <20260608124242.13164-1-david.laight.linux@gmail.com>
On 6/8/26 14:42, David Laight wrote:
> The code that gets the frame buffer mode from OF has 'use after free',
> 'buffer overrun' and memory leaks.
>
> info->edid_data isn't free if the probe functions fail or if
> pd->def_mode is set.
>
> If both the CRT and PANEL are enabled info->edid_data is used after
> being freed and is freed twice.
>
> The string returned by of_get_property(np, "mode", &len) is just
> written over either the static "640x480-16@60" or the module parameter
> string without any regard for the length (which is most likely longer).
>
> Use kstrump() for the OF mode and free everything before freeing 'info.
>
> Fixes: 4295f9bf74a88 ("video, sm501: add OF binding to support SM501")
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
> ---
> drivers/video/fbdev/sm501fb.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH next] drivers/video/fbdev/s3fb: Use strscpy() to copy strings into arrays
From: Helge Deller @ 2026-06-09 14:07 UTC (permalink / raw)
To: david.laight.linux, Kees Cook, linux-hardening, dri-devel,
linux-fbdev, linux-kernel
Cc: Arnd Bergmann
In-Reply-To: <20260608095523.2606-11-david.laight.linux@gmail.com>
On 6/8/26 11:54, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> Replacing strcpy() with strscpy() ensures that overflow of the target
> buffer cannot happen.
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
>
> drivers/video/fbdev/s3fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] video: fbdev: remove skeletonfb example driver with no remaining purpose
From: Helge Deller @ 2026-06-09 14:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Ethan Nelson-Moore; +Cc: linux-fbdev
In-Reply-To: <CAMuHMdXiToNLeQqW54+tOm6-eh9Xefxe3QaMC2Zg7r-3pBOx8A@mail.gmail.com>
On 6/8/26 10:03, Geert Uytterhoeven wrote:
> On Sun, 7 Jun 2026 at 03:58, Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
>> The skeletonfb driver is intended to serve as an example for writing
>> new framebuffer drivers. However, new framebuffer drivers are no longer
>> accepted into the kernel because DRM has obsoleted fbdev, so it no
>> longer has a purpose. In spite of this, it continues to be updated to
>> reflect fbdev API changes, wasting maintainers' time.
I don't want to argue, but the last update was 3 years ago, so
I don't see that much wasted time.
> Remove it.
>>
>> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>
> Thanks for your patch!
>
> Makes sense, as we still have vfb.c, which can actually be built.
> Perhaps some of the comments and/or kerneldoc should be moved
> elsewhere, so it is preserved?
That's what I'm mostly concerned about.
It has so much (still) useful info, that it would be sad to loose that.
Looking up the info in an already deleted file isn't a good alternative.
So, either someone should move comments/info over, or I'd like to keep it
for some more time as it's not actually hurting anybody.
Helge
^ permalink raw reply
page: | 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