* [PATCH next] drivers/video/fbdev/atmel_lcdfb: Use strscpy() to copy device name
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
Cc: Alexandre Belloni, Claudiu Beznea, Helge Deller, Nicolas Ferre,
David Laight
From: David Laight <david.laight.linux@gmail.com>
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/atmel_lcdfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index 9dfbc5310210..da3eb5f1b337 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1062,7 +1062,7 @@ static int atmel_lcdfb_probe(struct platform_device *pdev)
info->fbops = &atmel_lcdfb_ops;
info->fix = atmel_lcdfb_fix;
- strcpy(info->fix.id, sinfo->pdev->name);
+ strscpy(info->fix.id, sinfo->pdev->name);
/* Enable LCDC Clocks */
sinfo->bus_clk = clk_get(dev, "hclk");
--
2.39.5
^ permalink raw reply related
* [PATCH next] drivers/video/fbdev/cyber2000fb: Use strscpy() to copy device name
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
Cc: Helge Deller, Russell King, David Laight
From: David Laight <david.laight.linux@gmail.com>
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/cyber2000fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c b/drivers/video/fbdev/cyber2000fb.c
index 2d12f8e96c7e..8fb26e85270e 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -1384,7 +1384,7 @@ static struct cfb_info *cyberpro_alloc_fb_info(unsigned int id, char *name)
else
cfb->divisors[3] = 6;
- strcpy(cfb->fb.fix.id, name);
+ strscpy(cfb->fb.fix.id, name);
cfb->fb.fix.type = FB_TYPE_PACKED_PIXELS;
cfb->fb.fix.type_aux = 0;
--
2.39.5
^ permalink raw reply related
* [PATCH next] drivers/video/fbdev/riva: Use strscpy() to copy device name
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
Cc: Antonino Daplas, Helge Deller, David Laight
From: David Laight <david.laight.linux@gmail.com>
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/riva/rivafb-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/riva/rivafb-i2c.c b/drivers/video/fbdev/riva/rivafb-i2c.c
index 6a183375ced1..5ee59be01850 100644
--- a/drivers/video/fbdev/riva/rivafb-i2c.c
+++ b/drivers/video/fbdev/riva/rivafb-i2c.c
@@ -91,7 +91,7 @@ static int riva_setup_i2c_bus(struct riva_i2c_chan *chan, const char *name,
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
--
2.39.5
^ permalink raw reply related
* [PATCH next] drivers/video/fbdev/mmp/fb: Use strscpy() to copy device name
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
Cc: Helge Deller, David Laight
From: David Laight <david.laight.linux@gmail.com>
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/mmp/fb/mmpfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/mmp/fb/mmpfb.c b/drivers/video/fbdev/mmp/fb/mmpfb.c
index 694587256e06..fc09d3ec3487 100644
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@ -502,7 +502,7 @@ static int fb_info_setup(struct fb_info *info,
info->flags = FBINFO_PARTIAL_PAN_OK |
FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
info->node = -1;
- strcpy(info->fix.id, fbi->name);
+ strscpy(info->fix.id, fbi->name);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
info->fix.xpanstep = 0;
--
2.39.5
^ permalink raw reply related
* [PATCH next] drivers/video/fbdev/sis: Replace strlen() strcpy() pair with strscpy()
From: david.laight.linux @ 2026-06-06 20:27 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
Cc: Helge Deller, David Laight
From: David Laight <david.laight.linux@gmail.com>
Use the result of strscpy() for the overflow check.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/sis/sis_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
index 84567d67f71d..95f976b49143 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -204,8 +204,7 @@ static void sisfb_search_mode(char *name, bool quiet)
return;
}
- if(strlen(name) <= 19) {
- strcpy(strbuf1, name);
+ if (strscpy(strbuf1, name) > 0) {
for(i = 0; i < strlen(strbuf1); i++) {
if(strbuf1[i] < '0' || strbuf1[i] > '9') strbuf1[i] = ' ';
}
--
2.39.5
^ permalink raw reply related
* [PATCH] video: fbdev: remove skeletonfb example driver with no remaining purpose
From: Ethan Nelson-Moore @ 2026-06-07 1:58 UTC (permalink / raw)
To: linux-fbdev; +Cc: Ethan Nelson-Moore, Helge Deller
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. Remove it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
drivers/video/fbdev/skeletonfb.c | 1032 ------------------------------
1 file changed, 1032 deletions(-)
delete mode 100644 drivers/video/fbdev/skeletonfb.c
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
deleted file mode 100644
index 7e98850d9bde..000000000000
--- a/drivers/video/fbdev/skeletonfb.c
+++ /dev/null
@@ -1,1032 +0,0 @@
-/*
- * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
- *
- * Modified to new api Jan 2001 by James Simmons (jsimmons@transvirtual.com)
- *
- * Created 28 Dec 1997 by Geert Uytterhoeven
- *
- *
- * I have started rewriting this driver as a example of the upcoming new API
- * The primary goal is to remove the console code from fbdev and place it
- * into fbcon.c. This reduces the code and makes writing a new fbdev driver
- * easy since the author doesn't need to worry about console internals. It
- * also allows the ability to run fbdev without a console/tty system on top
- * of it.
- *
- * First the roles of struct fb_info and struct display have changed. Struct
- * display will go away. The way the new framebuffer console code will
- * work is that it will act to translate data about the tty/console in
- * struct vc_data to data in a device independent way in struct fb_info. Then
- * various functions in struct fb_ops will be called to store the device
- * dependent state in the par field in struct fb_info and to change the
- * hardware to that state. This allows a very clean separation of the fbdev
- * layer from the console layer. It also allows one to use fbdev on its own
- * which is a bounus for embedded devices. The reason this approach works is
- * for each framebuffer device when used as a tty/console device is allocated
- * a set of virtual terminals to it. Only one virtual terminal can be active
- * per framebuffer device. We already have all the data we need in struct
- * vc_data so why store a bunch of colormaps and other fbdev specific data
- * per virtual terminal.
- *
- * As you can see doing this makes the con parameter pretty much useless
- * for struct fb_ops functions, as it should be. Also having struct
- * fb_var_screeninfo and other data in fb_info pretty much eliminates the
- * need for get_fix and get_var. Once all drivers use the fix, var, and cmap
- * fbcon can be written around these fields. This will also eliminate the
- * need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
- * struct fb_cmap every time get_var, get_fix, get_cmap functions are called
- * as many drivers do now.
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive for
- * more details.
- */
-
-#include <linux/aperture.h>
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/string.h>
-#include <linux/mm.h>
-#include <linux/slab.h>
-#include <linux/delay.h>
-#include <linux/fb.h>
-#include <linux/init.h>
-#include <linux/pci.h>
-
- /*
- * This is just simple sample code.
- *
- * No warranty that it actually compiles.
- * Even less warranty that it actually works :-)
- */
-
-/*
- * Driver data
- */
-static char *mode_option;
-
-/*
- * If your driver supports multiple boards, you should make the
- * below data types arrays, or allocate them dynamically (using kmalloc()).
- */
-
-/*
- * This structure defines the hardware state of the graphics card. Normally
- * you place this in a header file in linux/include/video. This file usually
- * also includes register information. That allows other driver subsystems
- * and userland applications the ability to use the same header file to
- * avoid duplicate work and easy porting of software.
- */
-struct xxx_par;
-
-/*
- * Here we define the default structs fb_fix_screeninfo and fb_var_screeninfo
- * if we don't use modedb. If we do use modedb see xxxfb_init how to use it
- * to get a fb_var_screeninfo. Otherwise define a default var as well.
- */
-static const struct fb_fix_screeninfo xxxfb_fix = {
- .id = "FB's name",
- .type = FB_TYPE_PACKED_PIXELS,
- .visual = FB_VISUAL_PSEUDOCOLOR,
- .xpanstep = 1,
- .ypanstep = 1,
- .ywrapstep = 1,
- .accel = FB_ACCEL_NONE,
-};
-
- /*
- * Modern graphical hardware not only supports pipelines but some
- * also support multiple monitors where each display can have
- * its own unique data. In this case each display could be
- * represented by a separate framebuffer device thus a separate
- * struct fb_info. Now the struct xxx_par represents the graphics
- * hardware state thus only one exist per card. In this case the
- * struct xxx_par for each graphics card would be shared between
- * every struct fb_info that represents a framebuffer on that card.
- * This allows when one display changes it video resolution (info->var)
- * the other displays know instantly. Each display can always be
- * aware of the entire hardware state that affects it because they share
- * the same xxx_par struct. The other side of the coin is multiple
- * graphics cards that pass data around until it is finally displayed
- * on one monitor. Such examples are the voodoo 1 cards and high end
- * NUMA graphics servers. For this case we have a bunch of pars, each
- * one that represents a graphics state, that belong to one struct
- * fb_info. Their you would want to have *par point to a array of device
- * states and have each struct fb_ops function deal with all those
- * states. I hope this covers every possible hardware design. If not
- * feel free to send your ideas at jsimmons@users.sf.net
- */
-
- /*
- * If your driver supports multiple boards or it supports multiple
- * framebuffers, you should make these arrays, or allocate them
- * dynamically using framebuffer_alloc() and free them with
- * framebuffer_release().
- */
-static struct fb_info info;
-
- /*
- * Each one represents the state of the hardware. Most hardware have
- * just one hardware state. These here represent the default state(s).
- */
-static struct xxx_par __initdata current_par;
-
-/**
- * xxxfb_open - Optional function. Called when the framebuffer is
- * first accessed.
- * @info: frame buffer structure that represents a single frame buffer
- * @user: tell us if the userland (value=1) or the console is accessing
- * the framebuffer.
- *
- * This function is the first function called in the framebuffer api.
- * Usually you don't need to provide this function. The case where it
- * is used is to change from a text mode hardware state to a graphics
- * mode state.
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_open(struct fb_info *info, int user)
-{
- return 0;
-}
-
-/**
- * xxxfb_release - Optional function. Called when the framebuffer
- * device is closed.
- * @info: frame buffer structure that represents a single frame buffer
- * @user: tell us if the userland (value=1) or the console is accessing
- * the framebuffer.
- *
- * Thus function is called when we close /dev/fb or the framebuffer
- * console system is released. Usually you don't need this function.
- * The case where it is usually used is to go from a graphics state
- * to a text mode state.
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_release(struct fb_info *info, int user)
-{
- return 0;
-}
-
-/**
- * xxxfb_check_var - Optional function. Validates a var passed in.
- * @var: frame buffer variable screen structure
- * @info: frame buffer structure that represents a single frame buffer
- *
- * Checks to see if the hardware supports the state requested by
- * var passed in. This function does not alter the hardware state!!!
- * This means the data stored in struct fb_info and struct xxx_par do
- * not change. This includes the var inside of struct fb_info.
- * Do NOT change these. This function can be called on its own if we
- * intent to only test a mode and not actually set it. The stuff in
- * modedb.c is a example of this. If the var passed in is slightly
- * off by what the hardware can support then we alter the var PASSED in
- * to what we can do.
- *
- * For values that are off, this function must round them _up_ to the
- * next value that is supported by the hardware. If the value is
- * greater than the highest value supported by the hardware, then this
- * function must return -EINVAL.
- *
- * Exception to the above rule: Some drivers have a fixed mode, ie,
- * the hardware is already set at boot up, and cannot be changed. In
- * this case, it is more acceptable that this function just return
- * a copy of the currently working var (info->var). Better is to not
- * implement this function, as the upper layer will do the copying
- * of the current var for you.
- *
- * Note: This is the only function where the contents of var can be
- * freely adjusted after the driver has been registered. If you find
- * that you have code outside of this function that alters the content
- * of var, then you are doing something wrong. Note also that the
- * contents of info->var must be left untouched at all times after
- * driver registration.
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
-{
- /* ... */
- return 0;
-}
-
-/**
- * xxxfb_set_par - Optional function. Alters the hardware state.
- * @info: frame buffer structure that represents a single frame buffer
- *
- * Using the fb_var_screeninfo in fb_info we set the resolution of the
- * this particular framebuffer. This function alters the par AND the
- * fb_fix_screeninfo stored in fb_info. It doesn't not alter var in
- * fb_info since we are using that data. This means we depend on the
- * data in var inside fb_info to be supported by the hardware.
- *
- * This function is also used to recover/restore the hardware to a
- * known working state.
- *
- * xxxfb_check_var is always called before xxxfb_set_par to ensure that
- * the contents of var is always valid.
- *
- * Again if you can't change the resolution you don't need this function.
- *
- * However, even if your hardware does not support mode changing,
- * a set_par might be needed to at least initialize the hardware to
- * a known working state, especially if it came back from another
- * process that also modifies the same hardware, such as X.
- *
- * If this is the case, a combination such as the following should work:
- *
- * static int xxxfb_check_var(struct fb_var_screeninfo *var,
- * struct fb_info *info)
- * {
- * *var = info->var;
- * return 0;
- * }
- *
- * static int xxxfb_set_par(struct fb_info *info)
- * {
- * init your hardware here
- * }
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_set_par(struct fb_info *info)
-{
- struct xxx_par *par = info->par;
- /* ... */
- return 0;
-}
-
-/**
- * xxxfb_setcolreg - Optional function. Sets a color register.
- * @regno: Which register in the CLUT we are programming
- * @red: The red value which can be up to 16 bits wide
- * @green: The green value which can be up to 16 bits wide
- * @blue: The blue value which can be up to 16 bits wide.
- * @transp: If supported, the alpha value which can be up to 16 bits wide.
- * @info: frame buffer info structure
- *
- * Set a single color register. The values supplied have a 16 bit
- * magnitude which needs to be scaled in this function for the hardware.
- * Things to take into consideration are how many color registers, if
- * any, are supported with the current color visual. With truecolor mode
- * no color palettes are supported. Here a pseudo palette is created
- * which we store the value in pseudo_palette in struct fb_info. For
- * pseudocolor mode we have a limited color palette. To deal with this
- * we can program what color is displayed for a particular pixel value.
- * DirectColor is similar in that we can program each color field. If
- * we have a static colormap we don't need to implement this function.
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
- unsigned blue, unsigned transp,
- struct fb_info *info)
-{
- if (regno >= 256) /* no. of hw registers */
- return -EINVAL;
- /*
- * Program hardware... do anything you want with transp
- */
-
- /* grayscale works only partially under directcolor */
- if (info->var.grayscale) {
- /* grayscale = 0.30*R + 0.59*G + 0.11*B */
- red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
- }
-
- /* Directcolor:
- * var->{color}.offset contains start of bitfield
- * var->{color}.length contains length of bitfield
- * {hardwarespecific} contains width of DAC
- * pseudo_palette[X] is programmed to (X << red.offset) |
- * (X << green.offset) |
- * (X << blue.offset)
- * RAMDAC[X] is programmed to (red, green, blue)
- * color depth = SUM(var->{color}.length)
- *
- * Pseudocolor:
- * var->{color}.offset is 0 unless the palette index takes less than
- * bits_per_pixel bits and is stored in the upper
- * bits of the pixel value
- * var->{color}.length is set so that 1 << length is the number of
- * available palette entries
- * pseudo_palette is not used
- * RAMDAC[X] is programmed to (red, green, blue)
- * color depth = var->{color}.length
- *
- * Static pseudocolor:
- * same as Pseudocolor, but the RAMDAC is not programmed (read-only)
- *
- * Mono01/Mono10:
- * Has only 2 values, black on white or white on black (fg on bg),
- * var->{color}.offset is 0
- * white = (1 << var->{color}.length) - 1, black = 0
- * pseudo_palette is not used
- * RAMDAC does not exist
- * color depth is always 2
- *
- * Truecolor:
- * does not use RAMDAC (usually has 3 of them).
- * var->{color}.offset contains start of bitfield
- * var->{color}.length contains length of bitfield
- * pseudo_palette is programmed to (red << red.offset) |
- * (green << green.offset) |
- * (blue << blue.offset) |
- * (transp << transp.offset)
- * RAMDAC does not exist
- * color depth = SUM(var->{color}.length})
- *
- * The color depth is used by fbcon for choosing the logo and also
- * for color palette transformation if color depth < 4
- *
- * As can be seen from the above, the field bits_per_pixel is _NOT_
- * a criteria for describing the color visual.
- *
- * A common mistake is assuming that bits_per_pixel <= 8 is pseudocolor,
- * and higher than that, true/directcolor. This is incorrect, one needs
- * to look at the fix->visual.
- *
- * Another common mistake is using bits_per_pixel to calculate the color
- * depth. The bits_per_pixel field does not directly translate to color
- * depth. You have to compute for the color depth (using the color
- * bitfields) and fix->visual as seen above.
- */
-
- /*
- * This is the point where the color is converted to something that
- * is acceptable by the hardware.
- */
-#define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
- red = CNVT_TOHW(red, info->var.red.length);
- green = CNVT_TOHW(green, info->var.green.length);
- blue = CNVT_TOHW(blue, info->var.blue.length);
- transp = CNVT_TOHW(transp, info->var.transp.length);
-#undef CNVT_TOHW
- /*
- * This is the point where the function feeds the color to the hardware
- * palette after converting the colors to something acceptable by
- * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and
- * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette.
- * If you have code that writes to the hardware CLUT, and it's not
- * any of the above visuals, then you are doing something wrong.
- */
- if (info->fix.visual == FB_VISUAL_DIRECTCOLOR ||
- info->fix.visual == FB_VISUAL_TRUECOLOR)
- write_{red|green|blue|transp}_to_clut();
-
- /* This is the point were you need to fill up the contents of
- * info->pseudo_palette. This structure is used _only_ by fbcon, thus
- * it only contains 16 entries to match the number of colors supported
- * by the console. The pseudo_palette is used only if the visual is
- * in directcolor or truecolor mode. With other visuals, the
- * pseudo_palette is not used. (This might change in the future.)
- *
- * The contents of the pseudo_palette is in raw pixel format. Ie, each
- * entry can be written directly to the framebuffer without any conversion.
- * The pseudo_palette is (void *). However, if using the generic
- * drawing functions (cfb_imageblit, cfb_fillrect), the pseudo_palette
- * must be casted to (u32 *) _regardless_ of the bits per pixel. If the
- * driver is using its own drawing functions, then it can use whatever
- * size it wants.
- */
- if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
- info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
- u32 v;
-
- if (regno >= 16)
- return -EINVAL;
-
- v = (red << info->var.red.offset) |
- (green << info->var.green.offset) |
- (blue << info->var.blue.offset) |
- (transp << info->var.transp.offset);
-
- ((u32*)(info->pseudo_palette))[regno] = v;
- }
-
- /* ... */
- return 0;
-}
-
-/**
- * xxxfb_pan_display - NOT a required function. Pans the display.
- * @var: frame buffer variable screen structure
- * @info: frame buffer structure that represents a single frame buffer
- *
- * Pan (or wrap, depending on the `vmode' field) the display using the
- * `xoffset' and `yoffset' fields of the `var' structure.
- * If the values don't fit, return -EINVAL.
- *
- * Returns negative errno on error, or zero on success.
- */
-static int xxxfb_pan_display(struct fb_var_screeninfo *var,
- struct fb_info *info)
-{
- /*
- * If your hardware does not support panning, _do_ _not_ implement this
- * function. Creating a dummy function will just confuse user apps.
- */
-
- /*
- * Note that even if this function is fully functional, a setting of
- * 0 in both xpanstep and ypanstep means that this function will never
- * get called.
- */
-
- /* ... */
- return 0;
-}
-
-/**
- * xxxfb_blank - NOT a required function. Blanks the display.
- * @blank_mode: the blank mode we want.
- * @info: frame buffer structure that represents a single frame buffer
- *
- * Blank the screen if blank_mode != FB_BLANK_UNBLANK, else unblank.
- * Return 0 if blanking succeeded, != 0 if un-/blanking failed due to
- * e.g. a video mode which doesn't support it.
- *
- * Implements VESA suspend and powerdown modes on hardware that supports
- * disabling hsync/vsync:
- *
- * FB_BLANK_NORMAL = display is blanked, syncs are on.
- * FB_BLANK_HSYNC_SUSPEND = hsync off
- * FB_BLANK_VSYNC_SUSPEND = vsync off
- * FB_BLANK_POWERDOWN = hsync and vsync off
- *
- * If implementing this function, at least support FB_BLANK_UNBLANK.
- * Return !0 for any modes that are unimplemented.
- *
- */
-static int xxxfb_blank(int blank_mode, struct fb_info *info)
-{
- /* ... */
- return 0;
-}
-
-/* ------------ Accelerated Functions --------------------- */
-
-/*
- * We provide our own functions if we have hardware acceleration
- * or non packed pixel format layouts. If we have no hardware
- * acceleration, we can use a generic unaccelerated function. If using
- * a pack pixel format just use the functions in cfb_*.c. Each file
- * has one of the three different accel functions we support.
- */
-
-/**
- * xxxfb_fillrect - REQUIRED function. Can use generic routines if
- * non acclerated hardware and packed pixel based.
- * Draws a rectangle on the screen.
- *
- * @info: frame buffer structure that represents a single frame buffer
- * @region: The structure representing the rectangular region we
- * wish to draw to.
- *
- * This drawing operation places/removes a retangle on the screen
- * depending on the rastering operation with the value of color which
- * is in the current color depth format.
- */
-void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
-{
-/* Meaning of struct fb_fillrect
- *
- * @dx: The x and y corrdinates of the upper left hand corner of the
- * @dy: area we want to draw to.
- * @width: How wide the rectangle is we want to draw.
- * @height: How tall the rectangle is we want to draw.
- * @color: The color to fill in the rectangle with.
- * @rop: The raster operation. We can draw the rectangle with a COPY
- * of XOR which provides erasing effect.
- */
-}
-
-/**
- * xxxfb_copyarea - REQUIRED function. Can use generic routines if
- * non acclerated hardware and packed pixel based.
- * Copies one area of the screen to another area.
- *
- * @info: frame buffer structure that represents a single frame buffer
- * @area: Structure providing the data to copy the framebuffer contents
- * from one region to another.
- *
- * This drawing operation copies a rectangular area from one area of the
- * screen to another area.
- */
-void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
-{
-/*
- * @dx: The x and y coordinates of the upper left hand corner of the
- * @dy: destination area on the screen.
- * @width: How wide the rectangle is we want to copy.
- * @height: How tall the rectangle is we want to copy.
- * @sx: The x and y coordinates of the upper left hand corner of the
- * @sy: source area on the screen.
- */
-}
-
-
-/**
- * xxxfb_imageblit - REQUIRED function. Can use generic routines if
- * non acclerated hardware and packed pixel based.
- * Copies a image from system memory to the screen.
- *
- * @info: frame buffer structure that represents a single frame buffer
- * @image: structure defining the image.
- *
- * This drawing operation draws a image on the screen. It can be a
- * mono image (needed for font handling) or a color image (needed for
- * tux).
- */
-void xxxfb_imageblit(struct fb_info *p, const struct fb_image *image)
-{
-/*
- * @dx: The x and y coordinates of the upper left hand corner of the
- * @dy: destination area to place the image on the screen.
- * @width: How wide the image is we want to copy.
- * @height: How tall the image is we want to copy.
- * @fg_color: For mono bitmap images this is color data for
- * @bg_color: the foreground and background of the image to
- * write directly to the frmaebuffer.
- * @depth: How many bits represent a single pixel for this image.
- * @data: The actual data used to construct the image on the display.
- * @cmap: The colormap used for color images.
- */
-
-/*
- * The generic function, cfb_imageblit, expects that the bitmap scanlines are
- * padded to the next byte. Most hardware accelerators may require padding to
- * the next u16 or the next u32. If that is the case, the driver can specify
- * this by setting info->pixmap.scan_align = 2 or 4. See a more
- * comprehensive description of the pixmap below.
- */
-}
-
-/**
- * xxxfb_cursor - OPTIONAL. If your hardware lacks support
- * for a cursor, leave this field NULL.
- *
- * @info: frame buffer structure that represents a single frame buffer
- * @cursor: structure defining the cursor to draw.
- *
- * This operation is used to set or alter the properities of the
- * cursor.
- *
- * Returns negative errno on error, or zero on success.
- */
-int xxxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
-{
-/*
- * @set: Which fields we are altering in struct fb_cursor
- * @enable: Disable or enable the cursor
- * @rop: The bit operation we want to do.
- * @mask: This is the cursor mask bitmap.
- * @dest: A image of the area we are going to display the cursor.
- * Used internally by the driver.
- * @hot: The hot spot.
- * @image: The actual data for the cursor image.
- *
- * NOTES ON FLAGS (cursor->set):
- *
- * FB_CUR_SETIMAGE - the cursor image has changed (cursor->image.data)
- * FB_CUR_SETPOS - the cursor position has changed (cursor->image.dx|dy)
- * FB_CUR_SETHOT - the cursor hot spot has changed (cursor->hot.dx|dy)
- * FB_CUR_SETCMAP - the cursor colors has changed (cursor->fg_color|bg_color)
- * FB_CUR_SETSHAPE - the cursor bitmask has changed (cursor->mask)
- * FB_CUR_SETSIZE - the cursor size has changed (cursor->width|height)
- * FB_CUR_SETALL - everything has changed
- *
- * NOTES ON ROPs (cursor->rop, Raster Operation)
- *
- * ROP_XOR - cursor->image.data XOR cursor->mask
- * ROP_COPY - curosr->image.data AND cursor->mask
- *
- * OTHER NOTES:
- *
- * - fbcon only supports a 2-color cursor (cursor->image.depth = 1)
- * - The fb_cursor structure, @cursor, _will_ always contain valid
- * fields, whether any particular bitfields in cursor->set is set
- * or not.
- */
-}
-
-/**
- * xxxfb_sync - NOT a required function. Normally the accel engine
- * for a graphics card take a specific amount of time.
- * Often we have to wait for the accelerator to finish
- * its operation before we can write to the framebuffer
- * so we can have consistent display output.
- *
- * @info: frame buffer structure that represents a single frame buffer
- *
- * If the driver has implemented its own hardware-based drawing function,
- * implementing this function is highly recommended.
- */
-int xxxfb_sync(struct fb_info *info)
-{
- return 0;
-}
-
- /*
- * Frame buffer operations
- */
-
-static const struct fb_ops xxxfb_ops = {
- .owner = THIS_MODULE,
- .fb_open = xxxfb_open,
- .fb_read = xxxfb_read,
- .fb_write = xxxfb_write,
- .fb_release = xxxfb_release,
- .fb_check_var = xxxfb_check_var,
- .fb_set_par = xxxfb_set_par,
- .fb_setcolreg = xxxfb_setcolreg,
- .fb_blank = xxxfb_blank,
- .fb_pan_display = xxxfb_pan_display,
- .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
- .fb_copyarea = xxxfb_copyarea, /* Needed !!! */
- .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
- .fb_cursor = xxxfb_cursor, /* Optional !!! */
- .fb_sync = xxxfb_sync,
- .fb_ioctl = xxxfb_ioctl,
- .fb_mmap = xxxfb_mmap,
-};
-
-/* ------------------------------------------------------------------------- */
-
- /*
- * Initialization
- */
-
-/* static int __init xxfb_probe (struct platform_device *pdev) -- for platform devs */
-static int xxxfb_probe(struct pci_dev *dev, const struct pci_device_id *ent)
-{
- struct fb_info *info;
- struct xxx_par *par;
- struct device *device = &dev->dev; /* or &pdev->dev */
- int cmap_len, retval;
-
- /*
- * Remove firmware-based drivers that create resource conflicts.
- */
- retval = aperture_remove_conflicting_pci_devices(pdev, "xxxfb");
- if (retval)
- return retval;
-
- /*
- * Dynamically allocate info and par
- */
- info = framebuffer_alloc(sizeof(struct xxx_par), device);
-
- if (!info) {
- /* goto error path */
- }
-
- par = info->par;
-
- /*
- * Here we set the screen_base to the virtual memory address
- * for the framebuffer. Usually we obtain the resource address
- * from the bus layer and then translate it to virtual memory
- * space via ioremap. Consult ioport.h.
- */
- info->screen_base = framebuffer_virtual_memory;
- info->fbops = &xxxfb_ops;
- info->fix = xxxfb_fix;
- info->pseudo_palette = pseudo_palette; /* The pseudopalette is an
- * 16-member array
- */
- /*
- * Set up flags to indicate what sort of acceleration your
- * driver can provide (pan/wrap/copyarea/etc.) and whether it
- * is a module -- see FBINFO_* in include/linux/fb.h
- *
- * If your hardware can support any of the hardware accelerated functions
- * fbcon performance will improve if info->flags is set properly.
- *
- * FBINFO_HWACCEL_COPYAREA - hardware moves
- * FBINFO_HWACCEL_FILLRECT - hardware fills
- * FBINFO_HWACCEL_IMAGEBLIT - hardware mono->color expansion
- * FBINFO_HWACCEL_YPAN - hardware can pan display in y-axis
- * FBINFO_HWACCEL_YWRAP - hardware can wrap display in y-axis
- * FBINFO_HWACCEL_DISABLED - supports hardware accels, but disabled
- * FBINFO_READS_FAST - if set, prefer moves over mono->color expansion
- * FBINFO_MISC_TILEBLITTING - hardware can do tile blits
- *
- * NOTE: These are for fbcon use only.
- */
- info->flags = 0;
-
-/********************* This stage is optional ******************************/
- /*
- * The struct pixmap is a scratch pad for the drawing functions. This
- * is where the monochrome bitmap is constructed by the higher layers
- * and then passed to the accelerator. For drivers that uses
- * cfb_imageblit, you can skip this part. For those that have a more
- * rigorous requirement, this stage is needed
- */
-
- /* PIXMAP_SIZE should be small enough to optimize drawing, but not
- * large enough that memory is wasted. A safe size is
- * (max_xres * max_font_height/8). max_xres is driver dependent,
- * max_font_height is 32.
- */
- info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
- if (!info->pixmap.addr) {
- /* goto error */
- }
-
- info->pixmap.size = PIXMAP_SIZE;
-
- /*
- * FB_PIXMAP_SYSTEM - memory is in system ram
- * FB_PIXMAP_IO - memory is iomapped
- * FB_PIXMAP_SYNC - if set, will call fb_sync() per access to pixmap,
- * usually if FB_PIXMAP_IO is set.
- *
- * Currently, FB_PIXMAP_IO is unimplemented.
- */
- info->pixmap.flags = FB_PIXMAP_SYSTEM;
-
- /*
- * scan_align is the number of padding for each scanline. It is in bytes.
- * Thus for accelerators that need padding to the next u32, put 4 here.
- */
- info->pixmap.scan_align = 4;
-
- /*
- * buf_align is the amount to be padded for the buffer. For example,
- * the i810fb needs a scan_align of 2 but expects it to be fed with
- * dwords, so a buf_align = 4 is required.
- */
- info->pixmap.buf_align = 4;
-
- /* access_align is how many bits can be accessed from the framebuffer
- * ie. some epson cards allow 16-bit access only. Most drivers will
- * be safe with u32 here.
- *
- * NOTE: This field is currently unused.
- */
- info->pixmap.access_align = 32;
-/***************************** End optional stage ***************************/
-
- /*
- * This should give a reasonable default video mode. The following is
- * done when we can set a video mode.
- */
- if (!mode_option)
- mode_option = "640x480@60";
-
- retval = fb_find_mode(&info->var, info, mode_option, NULL, 0, NULL, 8);
-
- if (!retval || retval == 4)
- return -EINVAL;
-
- /* This has to be done! */
- if (fb_alloc_cmap(&info->cmap, cmap_len, 0))
- return -ENOMEM;
-
- /*
- * The following is done in the case of having hardware with a static
- * mode. If we are setting the mode ourselves we don't call this.
- */
- info->var = xxxfb_var;
-
- /*
- * For drivers that can...
- */
- xxxfb_check_var(&info->var, info);
-
- /*
- * Does a call to fb_set_par() before register_framebuffer needed? This
- * will depend on you and the hardware. If you are sure that your driver
- * is the only device in the system, a call to fb_set_par() is safe.
- *
- * Hardware in x86 systems has a VGA core. Calling set_par() at this
- * point will corrupt the VGA console, so it might be safer to skip a
- * call to set_par here and just allow fbcon to do it for you.
- */
- /* xxxfb_set_par(info); */
-
- if (register_framebuffer(info) < 0) {
- fb_dealloc_cmap(&info->cmap);
- return -EINVAL;
- }
- fb_info(info, "%s frame buffer device\n", info->fix.id);
- pci_set_drvdata(dev, info); /* or platform_set_drvdata(pdev, info) */
- return 0;
-}
-
- /*
- * Cleanup
- */
-/* static void xxxfb_remove(struct platform_device *pdev) */
-static void xxxfb_remove(struct pci_dev *dev)
-{
- struct fb_info *info = pci_get_drvdata(dev);
- /* or platform_get_drvdata(pdev); */
-
- if (info) {
- unregister_framebuffer(info);
- fb_dealloc_cmap(&info->cmap);
- /* ... */
- framebuffer_release(info);
- }
-}
-
-#ifdef CONFIG_PCI
-#ifdef CONFIG_PM
-/**
- * xxxfb_suspend - Optional but recommended function. Suspend the device.
- * @dev: PCI device
- * @msg: the suspend event code.
- *
- * See Documentation/driver-api/pm/devices.rst for more information
- */
-static int xxxfb_suspend(struct device *dev)
-{
- struct fb_info *info = dev_get_drvdata(dev);
- struct xxxfb_par *par = info->par;
-
- /* suspend here */
- return 0;
-}
-
-/**
- * xxxfb_resume - Optional but recommended function. Resume the device.
- * @dev: PCI device
- *
- * See Documentation/driver-api/pm/devices.rst for more information
- */
-static int xxxfb_resume(struct device *dev)
-{
- struct fb_info *info = dev_get_drvdata(dev);
- struct xxxfb_par *par = info->par;
-
- /* resume here */
- return 0;
-}
-#else
-#define xxxfb_suspend NULL
-#define xxxfb_resume NULL
-#endif /* CONFIG_PM */
-
-static const struct pci_device_id xxxfb_id_table[] = {
- { PCI_VENDOR_ID_XXX, PCI_DEVICE_ID_XXX,
- PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY << 16,
- PCI_CLASS_MASK, 0 },
- { 0, }
-};
-
-static SIMPLE_DEV_PM_OPS(xxxfb_pm_ops, xxxfb_suspend, xxxfb_resume);
-
-/* For PCI drivers */
-static struct pci_driver xxxfb_driver = {
- .name = "xxxfb",
- .id_table = xxxfb_id_table,
- .probe = xxxfb_probe,
- .remove = xxxfb_remove,
- .driver.pm = xxxfb_pm_ops, /* optional but recommended */
-};
-
-MODULE_DEVICE_TABLE(pci, xxxfb_id_table);
-
-static int __init xxxfb_init(void)
-{
- /*
- * For kernel boot options (in 'video=xxxfb:<options>' format)
- */
-#ifndef MODULE
- char *option = NULL;
-
- if (fb_get_options("xxxfb", &option))
- return -ENODEV;
- xxxfb_setup(option);
-#endif
-
- return pci_register_driver(&xxxfb_driver);
-}
-
-static void __exit xxxfb_exit(void)
-{
- pci_unregister_driver(&xxxfb_driver);
-}
-#else /* non PCI, platform drivers */
-#include <linux/platform_device.h>
-/* for platform devices */
-
-#ifdef CONFIG_PM
-/**
- * xxxfb_suspend - Optional but recommended function. Suspend the device.
- * @dev: platform device
- * @msg: the suspend event code.
- *
- * See Documentation/driver-api/pm/devices.rst for more information
- */
-static int xxxfb_suspend(struct platform_device *dev, pm_message_t msg)
-{
- struct fb_info *info = platform_get_drvdata(dev);
- struct xxxfb_par *par = info->par;
-
- /* suspend here */
- return 0;
-}
-
-/**
- * xxxfb_resume - Optional but recommended function. Resume the device.
- * @dev: platform device
- *
- * See Documentation/driver-api/pm/devices.rst for more information
- */
-static int xxxfb_resume(struct platform_dev *dev)
-{
- struct fb_info *info = platform_get_drvdata(dev);
- struct xxxfb_par *par = info->par;
-
- /* resume here */
- return 0;
-}
-#else
-#define xxxfb_suspend NULL
-#define xxxfb_resume NULL
-#endif /* CONFIG_PM */
-
-static struct platform_device_driver xxxfb_driver = {
- .probe = xxxfb_probe,
- .remove = xxxfb_remove,
- .suspend = xxxfb_suspend, /* optional but recommended */
- .resume = xxxfb_resume, /* optional but recommended */
- .driver = {
- .name = "xxxfb",
- },
-};
-
-static struct platform_device *xxxfb_device;
-
-#ifndef MODULE
- /*
- * Setup
- */
-
-/*
- * Only necessary if your driver takes special options,
- * otherwise we fall back on the generic fb_setup().
- */
-static int __init xxxfb_setup(char *options)
-{
- /* Parse user specified options (`video=xxxfb:') */
-}
-#endif /* MODULE */
-
-static int __init xxxfb_init(void)
-{
- int ret;
- /*
- * For kernel boot options (in 'video=xxxfb:<options>' format)
- */
-#ifndef MODULE
- char *option = NULL;
-#endif
-
- if (fb_modesetting_disabled("xxxfb"))
- return -ENODEV;
-
-#ifndef MODULE
- if (fb_get_options("xxxfb", &option))
- return -ENODEV;
- xxxfb_setup(option);
-#endif
- ret = platform_driver_register(&xxxfb_driver);
-
- if (!ret) {
- xxxfb_device = platform_device_register_simple("xxxfb", 0,
- NULL, 0);
-
- if (IS_ERR(xxxfb_device)) {
- platform_driver_unregister(&xxxfb_driver);
- ret = PTR_ERR(xxxfb_device);
- }
- }
-
- return ret;
-}
-
-static void __exit xxxfb_exit(void)
-{
- platform_device_unregister(xxxfb_device);
- platform_driver_unregister(&xxxfb_driver);
-}
-#endif /* CONFIG_PCI */
-
-/* ------------------------------------------------------------------------- */
-
-
- /*
- * Modularization
- */
-
-module_init(xxxfb_init);
-module_exit(xxxfb_exit);
-
-MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1] docs: omap/dss: Fix stale modedb.c path
From: Helge Deller @ 2026-06-07 15:10 UTC (permalink / raw)
To: Costa Shulyupin, Jonathan Corbet, Shuah Khan, Randy Dunlap,
linux-omap, linux-fbdev, linux-doc, linux-kernel
In-Reply-To: <20260531140325.4115024-1-costa.shul@redhat.com>
On 5/31/26 16:03, Costa Shulyupin wrote:
> The modedb.c file was moved from drivers/video/ to
> drivers/video/fbdev/core/. Update the reference.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/arch/arm/omap/dss.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2] fbdev: omap2: fix use-after-free in omapfb_mmap
From: Helge Deller @ 2026-06-07 15:17 UTC (permalink / raw)
To: Hongling Zeng, kees, Helge Deller
Cc: linux-omap, linux-fbdev, dri-devel, linux-kernel, zhongling0719
In-Reply-To: <20260602085421.194325-1-zenghongling@kylinos.cn>
On 6/2/26 10:54, Hongling Zeng wrote:
> omapfb_mmap() has a race condition with OMAPFB_SETUP_PLANE ioctl that
> can lead to use-after-free:
>
> The fb_mmap() entry point holds mm_lock but not lock (fb_info->lock),
> while ioctl handlers like OMAPFB_SETUP_PLANE hold lock but not mm_lock.
> This allows concurrent execution.
>
> In omapfb_mmap():
> 1. rg = omapfb_get_mem_region(ofbi->region); // Get old region ref
> 2. start = omapfb_get_region_paddr(ofbi); // Read from NEW region
> 3. len = fix->smem_len; // Read from NEW region
> 4. vm_iomap_memory(vma, start, len); // Map NEW region memory
> 5. atomic_inc(&rg->map_count); // Increment OLD region!
>
> Concurrently, OMAPFB_SETUP_PLANE can:
> - Reassign ofbi->region = new_rg
> - Update fix->smem_len
> - OMAPFB_SETUP_MEM then checks NEW region's map_count (0!) and frees it
>
> This leaves userspace with a mapping to freed physical memory.
>
> The fix is to read all required values (start, len) from the same
> region reference (rg) that will have its map_count incremented,
> preventing the region from being freed while still mapped.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>
> ---
> Change in V2:
> -Restore fix->smem_len to maintain VRFB sparse mapping.
> -Increment map_count before mapping to prevent use-after-free
> on driver unload
> -Add proper error handling for map_count
> ---
> drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> index d70deb6a9150..046892682fc6 100644
> --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> @@ -1099,7 +1099,11 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
>
> rg = omapfb_get_mem_region(ofbi->region);
>
> - start = omapfb_get_region_paddr(ofbi);
> + if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> + start = rg->vrfb.paddr[0];
> + else
> + start = rg->paddr;
> +
> len = fix->smem_len;
>
> DBG("user mmap region start %lx, len %d, off %lx\n", start, len,
> @@ -1109,6 +1113,8 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
> vma->vm_ops = &mmap_user_ops;
> vma->vm_private_data = rg;
>
> + atomic_inc(&rg->map_count);
> +
> r = vm_iomap_memory(vma, start, len);
> if (r)
> goto error;
In the code there is another atomic_inc() here....
With your patch, map_count is incremented twice.
Is this right?
Helge
^ permalink raw reply
* Re: [PATCH v3 0/4] fbdev: Internalize fbcon
From: Helge Deller @ 2026-06-07 15:31 UTC (permalink / raw)
To: Thomas Zimmermann, geert, simona, airlied, lukas, maddy, mpe,
npiggin, chleroy
Cc: dri-devel, linux-fbdev, linuxppc-dev
In-Reply-To: <20260527151551.258659-1-tzimmermann@suse.de>
On 5/27/26 17:14, Thomas Zimmermann wrote:
> Turn fbcon into an internal client of fbdev. Manage all interactions
> with graphics drivers within fbdev. Add helpers for these tasks and
> convert drivers.
>
> Fbdev's PS3 and SH-Mobile drivers update fbcon as part of user-invoked
> mode changes. Call the new helpers, which also fix inconsistencies
> among the various code paths.
>
> Vga-switcheroo remaps the fbcon terminals when switching physical
> outputs. For now, hide this in another helper. The call will later
> move into DRM's fbdev emulation.
>
> With all refactoring in place, fbdev manages fbcon interactions by
> itself. Remove the public interfaces.
>
> v3:
> - resolve vga-switcheroo dependencies wrt fbcon (Geert)
> v2:
> - use '#if defined' (Helge)
>
> Thomas Zimmermann (4):
> fbdev: Wrap user-invoked calls to fb_set_var() in helper
> fbdev: Wrap user-invoked calls to fb_blank() in helper
> fbdev: Wrap fbcon updates from vga-switcheroo in helper
> fbdev: Do not export fbcon from fbdev
The v2 series is now dropped, and instead the v3 series is applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH next] drivers/video/fbdev/sis: Replace strlen() strcpy() pair with strscpy()
From: Helge Deller @ 2026-06-07 15:50 UTC (permalink / raw)
To: david.laight.linux, Kees Cook, linux-hardening, Arnd Bergmann,
dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260606202744.5113-2-david.laight.linux@gmail.com>
On 6/6/26 22:27, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> Use the result of strscpy() for the overflow check.
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
Hi David,
I've applied your 5 patches to the fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev:modedb: fix a possible UAF in fb_find_mode()
From: Helge Deller @ 2026-06-07 16:12 UTC (permalink / raw)
To: Tuo Li, simona, kees, tzimmermann; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260526091507.421730-1-islituo@gmail.com>
On 5/26/26 11:15, Tuo Li wrote:
> If mode_option is NULL, it is assigned from mode_option_buf:
>
> if (!mode_option) {
> fb_get_options(NULL, &mode_option_buf);
> mode_option = mode_option_buf;
> }
>
> Later, name is assigned from mode_option:
>
> const char *name = mode_option;
>
> However, mode_option_buf is freed before name is no longer used:
>
> kfree(mode_option_buf);
>
> while name is still accessed by:
>
> if ((name_matches(db[i], name, namelen) ||
>
> Since name aliases mode_option_buf, this may result in a
> use-after-free.
>
> Fix this by moving the kfree(mode_option_buf) call behind the access, and
> add corresponding cleanup before early returns.
I wonder if this isn't a typical good use-case for the new "Scope-based
resource management for the kernel" [1] feature.
Instead of adding kfree() at various places, we could do:
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 703d0b7aec32..b6926764a99c 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -626,7 +626,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
const struct fb_videomode *default_mode,
unsigned int default_bpp)
{
- char *mode_option_buf = NULL;
+ char *mode_option_buf __free(kfree) = NULL;
int i;
/* Set up defaults */
@@ -724,7 +724,6 @@ int fb_find_mode(struct fb_var_screeninfo *var,
res_specified = 1;
}
done:
- kfree(mode_option_buf);
if (cvt) {
struct fb_videomode cvt_mode;
int ret;
[1] https://lwn.net/Articles/934679/
Do you want to check if that's correct, and if yes resend a patch?
Helge
^ permalink raw reply related
* Re: [PATCH next] drivers/video/fbdev/sis: Replace strlen() strcpy() pair with strscpy()
From: David Laight @ 2026-06-07 17:19 UTC (permalink / raw)
To: Helge Deller
Cc: Kees Cook, linux-hardening, Arnd Bergmann, dri-devel, linux-fbdev,
linux-kernel
In-Reply-To: <a2ed1741-f49c-4a16-8d4c-e6698bd3dd8b@gmx.de>
On Sun, 7 Jun 2026 17:50:00 +0200
Helge Deller <deller@gmx.de> wrote:
> On 6/6/26 22:27, david.laight.linux@gmail.com wrote:
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > Use the result of strscpy() for the overflow check.
> >
> > Signed-off-by: David Laight <david.laight.linux@gmail.com>
>
> Hi David,
>
> I've applied your 5 patches to the fbdev git tree.
>
> Thanks!
> Helge
Thanks, that'll be 5 that don't come around when I try the same test
in a couple of months time :-)
David
^ permalink raw reply
* [PATCH 1/2] staging: fbtft: fb_ra8875: prefer usleep_range over udelay
From: Georgii Druzhinin @ 2026-06-07 20:17 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel,
Georgii Druzhinin
Replace udelay(100) with usleep_range(100, 120) to avoid busy-waiting
and allow the scheduler to utilize the CPU during the delay.
Signed-off-by: Georgii Druzhinin <ilovelinuxgames@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de6647d0..6058934e2ca2 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -210,7 +210,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
}
len--;
- udelay(100);
+ usleep_range(100, 120);
if (len) {
buf = (u8 *)par->buf;
@@ -231,7 +231,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
/* restore user spi-speed */
par->fbtftops.write = fbtft_write_spi;
- udelay(100);
+ usleep_range(100, 120);
}
static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] staging: fbtft: fbtft-bus: remove prohibited space before close parenthesis
From: Georgii Druzhinin @ 2026-06-07 20:17 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel,
Georgii Druzhinin
In-Reply-To: <20260607201708.88644-1-ilovelinuxgames@gmail.com>
Fix checkpatch.pl error: "space prohibited before that close
parenthesis ')'" by removing the empty argument and comma
in define_fbtft_write_reg macro calls.
Signed-off-by: Georgii Druzhinin <ilovelinuxgames@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..409770891c54 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -62,9 +62,9 @@ out: \
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.54.0
^ permalink raw reply related
* [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Helge Deller @ 2026-06-07 21:02 UTC (permalink / raw)
To: linux-fbdev, dri-devel; +Cc: Ethan Nelson-Moore
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.
There is no need to use 64-bit division code here, so resolve this issue
by using plain standard addition and shift maths.
Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size")
Reported-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
---
include/linux/font.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/font.h b/include/linux/font.h
index 6845f02d739a..67d32268989d 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -11,7 +11,6 @@
#ifndef _VIDEO_FONT_H
#define _VIDEO_FONT_H
-#include <linux/math.h>
#include <linux/types.h>
struct console_font;
@@ -35,7 +34,7 @@ struct console_font;
*/
static inline unsigned int font_glyph_pitch(unsigned int width)
{
- return DIV_ROUND_UP(width, 8);
+ return (width + 7) >> 3;
}
/**
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Ethan Nelson-Moore @ 2026-06-08 4:50 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev, dri-devel
In-Reply-To: <20260607210203.229613-1-deller@gmx.de>
On Sun, Jun 7, 2026 at 2:02 PM Helge Deller <deller@gmx.de> 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.
>
> There is no need to use 64-bit division code here, so resolve this issue
> by using plain standard addition and shift maths.
Hi, Helge,
I can confirm that this patch fixes the issue. Thank you for your
thorough investigation.
Ethan
^ permalink raw reply
* Re: [PATCH 1/2] staging: fbtft: fb_ra8875: prefer usleep_range over udelay
From: Andy Shevchenko @ 2026-06-08 6:07 UTC (permalink / raw)
To: Georgii Druzhinin
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260607201708.88644-1-ilovelinuxgames@gmail.com>
On Sun, Jun 7, 2026 at 11:17 PM Georgii Druzhinin
<ilovelinuxgames@gmail.com> wrote:
>
> Replace udelay(100) with usleep_range(100, 120) to avoid busy-waiting
> and allow the scheduler to utilize the CPU during the delay.
Nice, now go to the lore.kernel.org mailing list archives and check
what was done previously on this and why none of the similar patches
have been applied so far. Also read README in the driver's folder.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] staging: fbtft: fbtft-bus: remove prohibited space before close parenthesis
From: Andy Shevchenko @ 2026-06-08 6:08 UTC (permalink / raw)
To: Georgii Druzhinin
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260607201708.88644-2-ilovelinuxgames@gmail.com>
On Sun, Jun 7, 2026 at 11:17 PM Georgii Druzhinin
<ilovelinuxgames@gmail.com> wrote:
>
> Fix checkpatch.pl error: "space prohibited before that close
> parenthesis ')'" by removing the empty argument and comma
> in define_fbtft_write_reg macro calls.
Please, learn C preprocessor and compile your stuff before submitting.
Also since you have a series of the patches it should have had a cover letter.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] video: fbdev: remove skeletonfb example driver with no remaining purpose
From: Geert Uytterhoeven @ 2026-06-08 8:03 UTC (permalink / raw)
To: Ethan Nelson-Moore; +Cc: linux-fbdev, Helge Deller
In-Reply-To: <20260607015840.11006-1-enelsonmoore@gmail.com>
Hi Ethan,
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. 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?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH next] drivers/video/fbdev/s3fb: Use strscpy() to copy strings into arrays
From: david.laight.linux @ 2026-06-08 9:54 UTC (permalink / raw)
To: Kees Cook, linux-hardening, dri-devel, linux-fbdev, linux-kernel
Cc: Arnd Bergmann, Helge Deller, David Laight
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>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
drivers/video/fbdev/s3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index ba30e5568cab..b679ccdb38e2 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -1333,7 +1333,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_wcrt(par->state.vgabase, 0x38, cr38);
vga_wcrt(par->state.vgabase, 0x39, cr39);
- strcpy(info->fix.id, s3_names [par->chip]);
+ strscpy(info->fix.id, s3_names[par->chip]);
info->fix.mmio_start = 0;
info->fix.mmio_len = 0;
info->fix.type = FB_TYPE_PACKED_PIXELS;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Thomas Zimmermann @ 2026-06-08 11:25 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel; +Cc: Ethan Nelson-Moore
In-Reply-To: <20260607210203.229613-1-deller@gmx.de>
Hi
Am 07.06.26 um 23:02 schrieb Helge Deller:
> 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.
>
> There is no need to use 64-bit division code here, so resolve this issue
> by using plain standard addition and shift maths.
Why is there a 64-bit division at all?
>
> Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size")
> Reported-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> Signed-off-by: Helge Deller <deller@gmx.de>
> ---
> include/linux/font.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/linux/font.h b/include/linux/font.h
> index 6845f02d739a..67d32268989d 100644
> --- a/include/linux/font.h
> +++ b/include/linux/font.h
> @@ -11,7 +11,6 @@
> #ifndef _VIDEO_FONT_H
> #define _VIDEO_FONT_H
>
> -#include <linux/math.h>
> #include <linux/types.h>
>
> struct console_font;
> @@ -35,7 +34,7 @@ struct console_font;
> */
> static inline unsigned int font_glyph_pitch(unsigned int width)
> {
> - return DIV_ROUND_UP(width, 8);
> + return (width + 7) >> 3;
Ok by me, if that's what's necessary. But can we try to keep a
documented macro for the division to make the code explain itself? Does
it work with DIV_ROUND_UP_POW2() ?
Best regards
Thomas
> }
>
> /**
--
--
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
* [PATCH 1/1] video, sm501: Fix buffer errors in OF binding code
From: David Laight @ 2026-06-08 12:42 UTC (permalink / raw)
To: Heiko Schocher, linux-fbdev, devicetree-discuss, Ben Dooks,
Vincent Sanders, Samuel Ortiz, linux-kernel, Randy Dunlap,
Paul Mundt, Helge Deller, Danila Chernetsov, Kees Cook
Cc: David Laight
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(-)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index fee4b9f84592..ea5375ed4ea6 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -96,6 +96,7 @@ struct sm501fb_info {
void __iomem *fbmem; /* remapped framebuffer */
size_t fbmem_len; /* length of remapped region */
u8 *edid_data;
+ char *fb_mode;
};
/* per-framebuffer private data */
@@ -1793,12 +1794,11 @@ static int sm501fb_init_fb(struct fb_info *fb, enum sm501_controller head,
fb->var.yres_virtual = fb->var.yres;
} else {
if (info->edid_data) {
- ret = fb_find_mode(&fb->var, fb, fb_mode,
+ ret = fb_find_mode(&fb->var, fb,
+ info->fb_mode ?: fb_mode,
fb->monspecs.modedb,
fb->monspecs.modedb_len,
&sm501_default_mode, default_bpp);
- /* edid_data is no longer needed, free it */
- kfree(info->edid_data);
} else {
ret = fb_find_mode(&fb->var, fb,
NULL, NULL, 0, NULL, 8);
@@ -1974,7 +1974,7 @@ static int sm501fb_probe(struct platform_device *pdev)
/* Get EDID */
cp = of_get_property(np, "mode", &len);
if (cp)
- strcpy(fb_mode, cp);
+ info->fb_mode = kstrdup(cp, GFP_KERNEL);
prop = of_get_property(np, "edid", &len);
if (prop && len == EDID_LENGTH) {
info->edid_data = kmemdup(prop, EDID_LENGTH,
@@ -2031,6 +2031,12 @@ static int sm501fb_probe(struct platform_device *pdev)
goto err_started_crt;
}
+ /* These aren't needed any more */
+ kfree(info->edid_data);
+ kfree(info->fb_mode);
+ info->edid_data = NULL;
+ info->fb_mode = NULL;
+
/* we registered, return ok */
return 0;
@@ -2048,6 +2054,8 @@ static int sm501fb_probe(struct platform_device *pdev)
framebuffer_release(info->fb[HEAD_CRT]);
err_alloc:
+ kfree(info->edid_data);
+ kfree(info->fb_mode);
kfree(info);
return ret;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Helge Deller @ 2026-06-08 19:57 UTC (permalink / raw)
To: Thomas Zimmermann, linux-fbdev, dri-devel; +Cc: Ethan Nelson-Moore
In-Reply-To: <b80a379d-87e4-45c4-a078-09e84a840895@suse.de>
On 6/8/26 13:25, Thomas Zimmermann wrote:
> Hi
>
> Am 07.06.26 um 23:02 schrieb Helge Deller:
>> 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.
>>
>> There is no need to use 64-bit division code here, so resolve this issue
>> by using plain standard addition and shift maths.
>
> Why is there a 64-bit division at all?
Not sure. Might be platform specific.
Maybe, because you add two integers and divide by an integer, that the
compiler then chooses to use 64-bit integer division by 32-bit integer.
>> Fixes: 97df8960240a ("lib/fonts: Provide helpers for calculating glyph pitch and size")
>> Reported-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>> ---
>> include/linux/font.h | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/include/linux/font.h b/include/linux/font.h
>> index 6845f02d739a..67d32268989d 100644
>> --- a/include/linux/font.h
>> +++ b/include/linux/font.h
>> @@ -11,7 +11,6 @@
>> #ifndef _VIDEO_FONT_H
>> #define _VIDEO_FONT_H
>> -#include <linux/math.h>
>> #include <linux/types.h>
>> struct console_font;
>> @@ -35,7 +34,7 @@ struct console_font;
>> */
>> static inline unsigned int font_glyph_pitch(unsigned int width)
>> {
>> - return DIV_ROUND_UP(width, 8);
>> + return (width + 7) >> 3;
>
> Ok by me, if that's what's necessary.
> But can we try to keep a documented macro for the division to make the code explain itself?
I'd expect everyone who messes with this kind of low-level graphics and bitmaps
to understand this math addition and bit shift, and as such I think it should
be self-explained.
> Does it work with DIV_ROUND_UP_POW2() ?
IMHO that's even worse than DIV_ROUND_UP().
Heleg
^ permalink raw reply
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Ethan Nelson-Moore @ 2026-06-08 20:14 UTC (permalink / raw)
To: Helge Deller; +Cc: Thomas Zimmermann, linux-fbdev, dri-devel
In-Reply-To: <1492766a-c349-4cca-932e-bf608b922b6b@gmx.de>
Hi, Helge and Thomas,
On Mon, Jun 8, 2026 at 12:58 PM Helge Deller <deller@gmx.de> wrote:
>
> On 6/8/26 13:25, Thomas Zimmermann wrote:
> > Why is there a 64-bit division at all?
>
> Not sure. Might be platform specific.
> Maybe, because you add two integers and divide by an integer, that the
> compiler then chooses to use 64-bit integer division by 32-bit integer.
Actually, I think the real issue is that
arch/arm/boot/compressed/Makefile defines "static" to nothing when
compiling its copy of lib/fonts/font_acorn_8x8.c (via font.c), so that
the font array is available outside of the object file. I assume that
this causes various unused static inline functions in the headers it
includes (such as <linux/math.h>) to be included in the object file
because they become normal inline functions.
Ethan
^ permalink raw reply
* Re: [PATCH] lib/fonts: Avoid unncessary 64-bit math in font code
From: Helge Deller @ 2026-06-08 20:26 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Helge Deller, Thomas Zimmermann, linux-fbdev, dri-devel
In-Reply-To: <CADkSEUg948W-XT3_ODe_6p4i5Y8AKEcP=rmJ+7qJq30Uq0d_EQ@mail.gmail.com>
* Ethan Nelson-Moore <enelsonmoore@gmail.com>:
> Hi, Helge and Thomas,
>
> On Mon, Jun 8, 2026 at 12:58 PM Helge Deller <deller@gmx.de> wrote:
> >
> > On 6/8/26 13:25, Thomas Zimmermann wrote:
> > > Why is there a 64-bit division at all?
> >
> > Not sure. Might be platform specific.
> > Maybe, because you add two integers and divide by an integer, that the
> > compiler then chooses to use 64-bit integer division by 32-bit integer.
>
> Actually, I think the real issue is that
> arch/arm/boot/compressed/Makefile defines "static" to nothing when
> compiling its copy of lib/fonts/font_acorn_8x8.c (via font.c), so that
> the font array is available outside of the object file. I assume that
> this causes various unused static inline functions in the headers it
> includes (such as <linux/math.h>) to be included in the object file
> because they become normal inline functions.
Does this patch fix the issue then?
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index a159120d1e42..e3f550d62857 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -157,4 +157,4 @@ $(obj)/piggy_data: $(obj)/../Image FORCE
$(obj)/piggy.o: $(obj)/piggy_data
-CFLAGS_font.o := -Dstatic=
+CFLAGS_font.o := -DBOOTLOADER
diff --git a/lib/fonts/font_acorn_8x8.c b/lib/fonts/font_acorn_8x8.c
index 36c51016769d..3327aa6d161d 100644
--- a/lib/fonts/font_acorn_8x8.c
+++ b/lib/fonts/font_acorn_8x8.c
@@ -5,7 +5,11 @@
#define FONTDATAMAX 2048
+#ifndef BOOTLOADER
static const struct font_data acorndata_8x8 = {
+#else
+const struct font_data acorndata_8x8 = {
+#endif
{ 0, 0, FONTDATAMAX, 0 }, {
/* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* ^@ */
/* 01 */ 0x7e, 0x81, 0xa5, 0x81, 0xbd, 0x99, 0x81, 0x7e, /* ^A */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox