* [PATCH 00/30] fbdev: Make userspace interfaces optional
@ 2023-06-05 14:47 Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
` (31 more replies)
0 siblings, 32 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Add the new config option FB_DEVICE. If enabled, fbdev provides
traditional userspace interfaces in devfs, sysfs and procfs, such
as /dev/fb0 or /proc/fb.
Modern Linux distrobutions have adopted DRM drivers for graphics
output and use fbdev only for the kernel's framebuffer console.
Userspace has also moved on, with no new fbdev code being written
and existing support being removed.
OTOH, fbdev provides userspace a way of accessing kernel or I/O
memory, which might compromise the system's security. See the recent
commit c8687694bb1f ("drm/fbdev-generic: prohibit potential
out-of-bounds access") for an example. Disabling fbdev userspace
interfaces is therefore a useful feature to limit unecessary
exposure of fbdev code to processes of low privilegues.
Patches 1 to 24 fix various bugs and issues in fbdev-related code.
In most cases the code uses the fbdev device where is should use
the Linux hardware device or someing else. Most of these patches
fix existing problems and should therefore be considered in any case.
Patches 25 to 29 refactor the fbdev core code. The patches move
support for backlights, sysfs, procfs and devfs into separate files
and hide it behind simple interfaces. These changes will allow to
easily build the userspace support conditionally.
Patch 30 introduces the config option FB_DEVICE and adapts the
fbdev core to support it. The field struct fb_info.dev is now also
optional, hence the name of the config option.
Tested on simpledrm and i915, including the device handover.
Future directions: With the support for disabling fbdev userspace
interfaces in place, it will be possible to make mosti fbdev drivers'
file-I/O code optional as well.
Thomas Zimmermann (30):
backlight/bd6107: Compare against struct fb_info.device
backlight/gpio_backlight: Compare against struct fb_info.device
backlight/lv5207lp: Compare against struct fb_info.device
fbdev/atyfb: Reorder backlight and framebuffer init/cleanup
fbdev/atyfb: Use hardware device as backlight parent
fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup
fbdev/aty128fb: Use hardware device as backlight parent
fbdev/broadsheetfb: Call device_remove_file() with hardware device
fbdev/ep93xx-fb: Alloc DMA memory from hardware device
fbdev/ep93xx-fb: Output messages with fb_info() and fb_err()
fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err()
fbdev/metronomefb: Use hardware device for dev_err()
fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup
fbdev/nvidiafb: Use hardware device as backlight parent
fbdev/pxa168fb: Do not assign to struct fb_info.dev
fbdev/radeonfb: Reorder backlight and framebuffer cleanup
fbdev/radeonfb: Use hardware device as backlight parent
fbdev/rivafb: Reorder backlight and framebuffer init/cleanup
fbdev/rivafb: Use hardware device as backlight parent
fbdev/sm501fb: Output message with fb_err()
fbdev/smscufx: Detect registered fb_info from refcount
fbdev/tdfxfb: Set i2c adapter parent to hardware device
fbdev/core: Pass Linux device to pm_vt_switch_*() functions
fbdev/core: Move framebuffer and backlight helpers into separate files
fbdev/core: Add fb_device_{create,destroy}()
fbdev/core: Move procfs code to separate file
fbdev/core: Move file-I/O code into separate file
fbdev/core: Rework fb init code
fbdev: Make support for userspace interfaces configurable
arch/sh/boards/mach-ecovec24/setup.c | 2 +-
arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
drivers/staging/fbtft/Kconfig | 1 +
drivers/video/backlight/bd6107.c | 2 +-
drivers/video/backlight/gpio_backlight.c | 6 +-
drivers/video/backlight/lv5207lp.c | 2 +-
drivers/video/fbdev/Kconfig | 12 +
drivers/video/fbdev/aty/aty128fb.c | 12 +-
drivers/video/fbdev/aty/atyfb_base.c | 18 +-
drivers/video/fbdev/aty/radeon_backlight.c | 2 +-
drivers/video/fbdev/aty/radeon_base.c | 3 +-
drivers/video/fbdev/broadsheetfb.c | 2 +-
drivers/video/fbdev/core/Makefile | 7 +-
drivers/video/fbdev/core/fb_backlight.c | 32 +
drivers/video/fbdev/core/fb_devfs.c | 484 +++++++++++++++
drivers/video/fbdev/core/fb_info.c | 76 +++
drivers/video/fbdev/core/fb_internal.h | 61 ++
drivers/video/fbdev/core/fb_procfs.c | 62 ++
drivers/video/fbdev/core/fbcon.c | 1 +
drivers/video/fbdev/core/fbmem.c | 594 +------------------
drivers/video/fbdev/core/fbsysfs.c | 134 +----
drivers/video/fbdev/ep93xx-fb.c | 21 +-
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 7 +-
drivers/video/fbdev/metronomefb.c | 2 +-
drivers/video/fbdev/nvidia/nv_backlight.c | 2 +-
drivers/video/fbdev/nvidia/nvidia.c | 8 +-
drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
drivers/video/fbdev/pxa168fb.c | 2 +-
drivers/video/fbdev/riva/fbdev.c | 10 +-
drivers/video/fbdev/sm501fb.c | 2 +-
drivers/video/fbdev/smscufx.c | 4 +-
drivers/video/fbdev/tdfxfb.c | 4 +-
include/linux/fb.h | 6 +-
include/linux/platform_data/bd6107.h | 2 +-
include/linux/platform_data/gpio_backlight.h | 2 +-
include/linux/platform_data/lv5207lp.h | 2 +-
36 files changed, 859 insertions(+), 732 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_backlight.c
create mode 100644 drivers/video/fbdev/core/fb_devfs.c
create mode 100644 drivers/video/fbdev/core/fb_info.c
create mode 100644 drivers/video/fbdev/core/fb_internal.h
create mode 100644 drivers/video/fbdev/core/fb_procfs.c
--
2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:30 ` Javier Martinez Canillas
2023-06-07 7:34 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 02/30] backlight/gpio_backlight: " Thomas Zimmermann
` (30 subsequent siblings)
31 siblings, 2 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Struct bd6107_platform_data refers to a platform device within
the Linux device hierarchy. The test in bd6107_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lee Jones <lee@kernel.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
---
drivers/video/backlight/bd6107.c | 2 +-
include/linux/platform_data/bd6107.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
index f4db6c064635..fa3dd45c8f9d 100644
--- a/drivers/video/backlight/bd6107.c
+++ b/drivers/video/backlight/bd6107.c
@@ -104,7 +104,7 @@ static int bd6107_backlight_check_fb(struct backlight_device *backlight,
{
struct bd6107 *bd = bl_get_data(backlight);
- return bd->pdata->fbdev == NULL || bd->pdata->fbdev == info->dev;
+ return !bd->pdata->dev || bd->pdata->dev == info->device;
}
static const struct backlight_ops bd6107_backlight_ops = {
diff --git a/include/linux/platform_data/bd6107.h b/include/linux/platform_data/bd6107.h
index 54a06a4d2618..596ca4f95cfa 100644
--- a/include/linux/platform_data/bd6107.h
+++ b/include/linux/platform_data/bd6107.h
@@ -8,7 +8,7 @@
struct device;
struct bd6107_platform_data {
- struct device *fbdev;
+ struct device *dev;
unsigned int def_value;
};
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-05 20:19 ` Ruhl, Michael J
2023-06-05 14:47 ` [PATCH 03/30] backlight/lv5207lp: " Thomas Zimmermann
` (29 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Rich Felker, John Paul Adrian Glaubitz
Struct gpio_backlight_platform_data refers to a platform device within
the Linux device hierarchy. The test in gpio_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Rich Felker <dalias@libc.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Lee Jones <lee@kernel.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: linux-sh@vger.kernel.org
---
arch/sh/boards/mach-ecovec24/setup.c | 2 +-
drivers/video/backlight/gpio_backlight.c | 6 +++---
include/linux/platform_data/gpio_backlight.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index 674da7ebd8b7..310513646c9b 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -386,7 +386,7 @@ static struct property_entry gpio_backlight_props[] = {
};
static struct gpio_backlight_platform_data gpio_backlight_data = {
- .fbdev = &lcdc_device.dev,
+ .dev = &lcdc_device.dev,
};
static const struct platform_device_info gpio_backlight_device_info = {
diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
index 6f78d928f054..d3bea42407f1 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -17,7 +17,7 @@
#include <linux/slab.h>
struct gpio_backlight {
- struct device *fbdev;
+ struct device *dev;
struct gpio_desc *gpiod;
};
@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct backlight_device *bl,
{
struct gpio_backlight *gbl = bl_get_data(bl);
- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
+ return !gbl->dev || gbl->dev == info->device;
}
static const struct backlight_ops gpio_backlight_ops = {
@@ -59,7 +59,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
return -ENOMEM;
if (pdata)
- gbl->fbdev = pdata->fbdev;
+ gbl->dev = pdata->dev;
def_value = device_property_read_bool(dev, "default-on");
diff --git a/include/linux/platform_data/gpio_backlight.h b/include/linux/platform_data/gpio_backlight.h
index 1a8b5b1946fe..323fbf5f7613 100644
--- a/include/linux/platform_data/gpio_backlight.h
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -8,7 +8,7 @@
struct device;
struct gpio_backlight_platform_data {
- struct device *fbdev;
+ struct device *dev;
};
#endif
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 03/30] backlight/lv5207lp: Compare against struct fb_info.device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 02/30] backlight/gpio_backlight: " Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:35 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
` (28 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz
Struct lv5207lp_platform_data refers to a platform device within
the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
compares it against the fbdev device in struct fb_info.dev, which
is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making
struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Lee Jones <lee@kernel.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: linux-sh@vger.kernel.org
---
arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
drivers/video/backlight/lv5207lp.c | 2 +-
include/linux/platform_data/lv5207lp.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index 20f4db778ed6..a18e80394aed 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -202,7 +202,7 @@ static struct platform_device kfr2r09_sh_lcdc_device = {
};
static struct lv5207lp_platform_data kfr2r09_backlight_data = {
- .fbdev = &kfr2r09_sh_lcdc_device.dev,
+ .dev = &kfr2r09_sh_lcdc_device.dev,
.def_value = 13,
.max_value = 13,
};
diff --git a/drivers/video/backlight/lv5207lp.c b/drivers/video/backlight/lv5207lp.c
index 00673c8b66ac..739f45cd2d38 100644
--- a/drivers/video/backlight/lv5207lp.c
+++ b/drivers/video/backlight/lv5207lp.c
@@ -67,7 +67,7 @@ static int lv5207lp_backlight_check_fb(struct backlight_device *backlight,
{
struct lv5207lp *lv = bl_get_data(backlight);
- return lv->pdata->fbdev == NULL || lv->pdata->fbdev == info->dev;
+ return !lv->pdata->dev || lv->pdata->dev == info->device;
}
static const struct backlight_ops lv5207lp_backlight_ops = {
diff --git a/include/linux/platform_data/lv5207lp.h b/include/linux/platform_data/lv5207lp.h
index c9da8d402750..95d85c1394bc 100644
--- a/include/linux/platform_data/lv5207lp.h
+++ b/include/linux/platform_data/lv5207lp.h
@@ -8,7 +8,7 @@
struct device;
struct lv5207lp_platform_data {
- struct device *fbdev;
+ struct device *dev;
unsigned int max_value;
unsigned int def_value;
};
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (2 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 03/30] backlight/lv5207lp: " Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:36 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent Thomas Zimmermann
` (27 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/aty/atyfb_base.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index cba2b113b28b..51504fe39054 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2654,11 +2654,6 @@ static int aty_init(struct fb_info *info)
USE_F32KHZ | TRISTATE_MEM_EN, par);
} else
#endif
- if (M64_HAS(MOBIL_BUS) && backlight) {
-#ifdef CONFIG_FB_ATY_BACKLIGHT
- aty_bl_init(par);
-#endif
- }
memset(&var, 0, sizeof(var));
#ifdef CONFIG_PPC
@@ -2751,6 +2746,12 @@ static int aty_init(struct fb_info *info)
goto aty_init_exit;
}
+ if (M64_HAS(MOBIL_BUS) && backlight) {
+#ifdef CONFIG_FB_ATY_BACKLIGHT
+ aty_bl_init(par);
+#endif
+ }
+
fb_list = info;
PRINTKI("fb%d: %s frame buffer device on %s\n",
@@ -3716,12 +3717,13 @@ static void atyfb_remove(struct fb_info *info)
aty_set_crtc(par, &par->saved_crtc);
par->pll_ops->set_pll(info, &par->saved_pll);
- unregister_framebuffer(info);
-
#ifdef CONFIG_FB_ATY_BACKLIGHT
if (M64_HAS(MOBIL_BUS))
aty_bl_exit(info->bl_dev);
#endif
+
+ unregister_framebuffer(info);
+
arch_phys_wc_del(par->wc_cookie);
#ifndef __sparc__
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (3 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:41 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
` (26 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/aty/atyfb_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 51504fe39054..e1602e3fbc66 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2255,7 +2255,7 @@ static void aty_bl_init(struct atyfb_par *par)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = FB_BACKLIGHT_LEVELS - 1;
- bd = backlight_device_register(name, info->dev, par, &aty_bl_data,
+ bd = backlight_device_register(name, info->device, par, &aty_bl_data,
&props);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (4 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:42 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent Thomas Zimmermann
` (25 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/aty/aty128fb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c b/drivers/video/fbdev/aty/aty128fb.c
index 36a9ac05a340..b4a49068a522 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -2028,14 +2028,14 @@ static int aty128_init(struct pci_dev *pdev, const struct pci_device_id *ent)
par->asleep = 0;
par->lock_blank = 0;
+ if (register_framebuffer(info) < 0)
+ return 0;
+
#ifdef CONFIG_FB_ATY128_BACKLIGHT
if (backlight)
aty128_bl_init(par);
#endif
- if (register_framebuffer(info) < 0)
- return 0;
-
fb_info(info, "%s frame buffer device on %s\n",
info->fix.id, video_card);
@@ -2167,12 +2167,12 @@ static void aty128_remove(struct pci_dev *pdev)
par = info->par;
- unregister_framebuffer(info);
-
#ifdef CONFIG_FB_ATY128_BACKLIGHT
aty128_bl_exit(info->bl_dev);
#endif
+ unregister_framebuffer(info);
+
arch_phys_wc_del(par->wc_cookie);
iounmap(par->regbase);
iounmap(info->screen_base);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (5 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:55 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device Thomas Zimmermann
` (24 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/aty/aty128fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c b/drivers/video/fbdev/aty/aty128fb.c
index b4a49068a522..2d9320a52e51 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -1846,7 +1846,7 @@ static void aty128_bl_init(struct aty128fb_par *par)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = FB_BACKLIGHT_LEVELS - 1;
- bd = backlight_device_register(name, info->dev, par, &aty128_bl_data,
+ bd = backlight_device_register(name, info->device, par, &aty128_bl_data,
&props);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (6 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 7:55 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from " Thomas Zimmermann
` (23 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Call device_remove_file() with the same device that has been used
for device_create_file(), which is the hardware device stored in
struct fb_info.device. Prepares fbdev for making struct fb_info.dev
optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/broadsheetfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/broadsheetfb.c b/drivers/video/fbdev/broadsheetfb.c
index e9c5d5c04062..72743a3e8772 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -1200,7 +1200,7 @@ static int broadsheetfb_remove(struct platform_device *dev)
if (info) {
struct broadsheetfb_par *par = info->par;
- device_remove_file(info->dev, &dev_attr_loadstore_waveform);
+ device_remove_file(info->device, &dev_attr_loadstore_waveform);
unregister_framebuffer(info);
fb_deferred_io_cleanup(info);
par->board->cleanup(par);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from hardware device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (7 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 8:47 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() Thomas Zimmermann
` (22 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Pass the hardware device to the DMA helpers dma_alloc_wc(), dma_mmap_wc()
and dma_free_coherent(). The fbdev device that is currently being used is
a software device and does not provide DMA memory.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/ep93xx-fb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c
index 94fe52928be2..376ee59e925c 100644
--- a/drivers/video/fbdev/ep93xx-fb.c
+++ b/drivers/video/fbdev/ep93xx-fb.c
@@ -312,7 +312,7 @@ static int ep93xxfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
unsigned int offset = vma->vm_pgoff << PAGE_SHIFT;
if (offset < info->fix.smem_len) {
- return dma_mmap_wc(info->dev, vma, info->screen_base,
+ return dma_mmap_wc(info->device, vma, info->screen_base,
info->fix.smem_start, info->fix.smem_len);
}
@@ -423,7 +423,7 @@ static int ep93xxfb_alloc_videomem(struct fb_info *info)
/* Maximum 16bpp -> used memory is maximum x*y*2 bytes */
fb_size = EP93XXFB_MAX_XRES * EP93XXFB_MAX_YRES * 2;
- virt_addr = dma_alloc_wc(info->dev, fb_size, &phys_addr, GFP_KERNEL);
+ virt_addr = dma_alloc_wc(info->device, fb_size, &phys_addr, GFP_KERNEL);
if (!virt_addr)
return -ENOMEM;
@@ -440,7 +440,7 @@ static int ep93xxfb_alloc_videomem(struct fb_info *info)
"has bit 27 set: cannot init framebuffer\n",
phys_addr);
- dma_free_coherent(info->dev, fb_size, virt_addr, phys_addr);
+ dma_free_coherent(info->device, fb_size, virt_addr, phys_addr);
return -ENOMEM;
}
@@ -454,7 +454,7 @@ static int ep93xxfb_alloc_videomem(struct fb_info *info)
static void ep93xxfb_dealloc_videomem(struct fb_info *info)
{
if (info->screen_base)
- dma_free_coherent(info->dev, info->fix.smem_len,
+ dma_free_coherent(info->device, info->fix.smem_len,
info->screen_base, info->fix.smem_start);
}
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err()
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (8 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from " Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 8:59 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann
` (21 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Fix cases were output helpers are called with struct fb_info.dev.
Use fb_info() and fb_err() instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/ep93xx-fb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c
index 376ee59e925c..f6cd200fe50f 100644
--- a/drivers/video/fbdev/ep93xx-fb.c
+++ b/drivers/video/fbdev/ep93xx-fb.c
@@ -436,9 +436,9 @@ static int ep93xxfb_alloc_videomem(struct fb_info *info)
* least.
*/
if (check_screenpage_bug && phys_addr & (1 << 27)) {
- dev_err(info->dev, "ep93xx framebuffer bug. phys addr (0x%x) "
- "has bit 27 set: cannot init framebuffer\n",
- phys_addr);
+ fb_err(info, "ep93xx framebuffer bug. phys addr (0x%x) "
+ "has bit 27 set: cannot init framebuffer\n",
+ phys_addr);
dma_free_coherent(info->device, fb_size, virt_addr, phys_addr);
return -ENOMEM;
@@ -525,7 +525,7 @@ static int ep93xxfb_probe(struct platform_device *pdev)
err = fb_find_mode(&info->var, info, video_mode,
NULL, 0, NULL, 16);
if (err == 0) {
- dev_err(info->dev, "No suitable video mode found\n");
+ fb_err(info, "No suitable video mode found\n");
err = -EINVAL;
goto failed_resource;
}
@@ -554,8 +554,8 @@ static int ep93xxfb_probe(struct platform_device *pdev)
if (err)
goto failed_framebuffer;
- dev_info(info->dev, "registered. Mode = %dx%d-%d\n",
- info->var.xres, info->var.yres, info->var.bits_per_pixel);
+ fb_info(info, "registered. Mode = %dx%d-%d\n",
+ info->var.xres, info->var.yres, info->var.bits_per_pixel);
return 0;
failed_framebuffer:
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (9 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-06 5:26 ` Dan Carpenter
2023-06-07 9:00 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() Thomas Zimmermann
` (20 subsequent siblings)
31 siblings, 2 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Do not assing the Linux device to struct fb_info.dev. The call to
register_framebuffer() initializes the field to the fbdev device.
Drivers should not override its value.
Fixes a bug where the driver incorrectly decreases the hardware
device's reference counter and leaks the fbdev device.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/ep93xx-fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c
index f6cd200fe50f..37309f9dbe82 100644
--- a/drivers/video/fbdev/ep93xx-fb.c
+++ b/drivers/video/fbdev/ep93xx-fb.c
@@ -474,7 +474,6 @@ static int ep93xxfb_probe(struct platform_device *pdev)
if (!info)
return -ENOMEM;
- info->dev = &pdev->dev;
platform_set_drvdata(pdev, info);
fbi = info->par;
fbi->mach_info = mach_info;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err()
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (10 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:00 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err() Thomas Zimmermann
` (19 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Fix cases were output helpers are called with struct fb_info.dev.
Use fb_dbg() and fb_err() instead. Prepares fbdev for making struct
fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
index b5c8fcab9940..99729611e04d 100644
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -112,8 +112,7 @@ static int mb862xxfb_check_var(struct fb_var_screeninfo *var,
{
unsigned long tmp;
- if (fbi->dev)
- dev_dbg(fbi->dev, "%s\n", __func__);
+ fb_dbg(fbi, "%s\n", __func__);
/* check if these values fit into the registers */
if (var->hsync_len > 255 || var->vsync_len > 255)
@@ -290,7 +289,7 @@ static int mb862xxfb_blank(int mode, struct fb_info *fbi)
struct mb862xxfb_par *par = fbi->par;
unsigned long reg;
- dev_dbg(fbi->dev, "blank mode=%d\n", mode);
+ fb_dbg(fbi, "blank mode=%d\n", mode);
switch (mode) {
case FB_BLANK_POWERDOWN:
@@ -1138,7 +1137,7 @@ static void mb862xx_pci_remove(struct pci_dev *pdev)
struct mb862xxfb_par *par = fbi->par;
unsigned long reg;
- dev_dbg(fbi->dev, "%s release\n", fbi->fix.id);
+ fb_dbg(fbi, "%s release\n", fbi->fix.id);
/* display off */
reg = inreg(disp, GC_DCM1);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err()
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (11 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:01 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
` (18 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Replace the use of the fbdev software device, stored in struct
fb_info.dev, with the hardware device from struct fb_info.device
in load_waveform(). The device is only used for printing errors
with dev_err().
This change aligns load_waveform() with the rest of the driver and
prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/metronomefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/metronomefb.c b/drivers/video/fbdev/metronomefb.c
index bac255c749e7..3e1daca76e11 100644
--- a/drivers/video/fbdev/metronomefb.c
+++ b/drivers/video/fbdev/metronomefb.c
@@ -181,7 +181,7 @@ static int load_waveform(u8 *mem, size_t size, int m, int t,
int mem_idx = 0;
struct waveform_hdr *wfm_hdr;
u8 *metromem = par->metromem_wfm;
- struct device *dev = par->info->dev;
+ struct device *dev = par->info->device;
if (user_wfm_size)
epd_frame_table[par->dt].wfm_size = user_wfm_size;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (12 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err() Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:02 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent Thomas Zimmermann
` (17 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/fbdev/nvidia/nvidia.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nvidia.c b/drivers/video/fbdev/nvidia/nvidia.c
index ea4ba3dfb96b..039e886346fa 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -1400,14 +1400,14 @@ static int nvidiafb_probe(struct pci_dev *pd, const struct pci_device_id *ent)
pci_set_drvdata(pd, info);
- if (backlight)
- nvidia_bl_init(par);
-
if (register_framebuffer(info) < 0) {
printk(KERN_ERR PFX "error registering nVidia framebuffer\n");
goto err_out_iounmap_fb;
}
+ if (backlight)
+ nvidia_bl_init(par);
+
printk(KERN_INFO PFX
"PCI nVidia %s framebuffer (%dMB @ 0x%lX)\n",
info->fix.id,
@@ -1439,9 +1439,9 @@ static void nvidiafb_remove(struct pci_dev *pd)
NVTRACE_ENTER();
+ nvidia_bl_exit(par);
unregister_framebuffer(info);
- nvidia_bl_exit(par);
arch_phys_wc_del(par->wc_cookie);
iounmap(info->screen_base);
fb_destroy_modedb(info->monspecs.modedb);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (13 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:02 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev Thomas Zimmermann
` (16 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/fbdev/nvidia/nv_backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/nvidia/nv_backlight.c b/drivers/video/fbdev/nvidia/nv_backlight.c
index 503a7a683855..160da9c50a52 100644
--- a/drivers/video/fbdev/nvidia/nv_backlight.c
+++ b/drivers/video/fbdev/nvidia/nv_backlight.c
@@ -98,7 +98,7 @@ void nvidia_bl_init(struct nvidia_par *par)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = FB_BACKLIGHT_LEVELS - 1;
- bd = backlight_device_register(name, info->dev, par, &nvidia_bl_ops,
+ bd = backlight_device_register(name, info->device, par, &nvidia_bl_ops,
&props);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (14 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:09 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup Thomas Zimmermann
` (15 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Do not assign the hardware device to struct fb_info.dev. The
field references the fbdev software device, which is unrelated.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/pxa168fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index 79f338463092..82cb9ffe5290 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -629,7 +629,7 @@ static int pxa168fb_probe(struct platform_device *pdev)
fbi = info->par;
fbi->info = info;
fbi->clk = clk;
- fbi->dev = info->dev = &pdev->dev;
+ fbi->dev = &pdev->dev;
fbi->panel_rbswap = mi->panel_rbswap;
fbi->is_blanked = 0;
fbi->active = mi->active;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (15 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev Thomas Zimmermann
@ 2023-06-05 14:47 ` Thomas Zimmermann
2023-06-07 9:09 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann
` (14 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:47 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Benjamin Herrenschmidt
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the cleanup calls for both data
structures. The init calls are already in the correct order.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/fbdev/aty/radeon_base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 972c4bbedfa3..8f2a527c26eb 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2517,9 +2517,8 @@ static void radeonfb_pci_unregister(struct pci_dev *pdev)
del_timer_sync(&rinfo->lvds_timer);
arch_phys_wc_del(rinfo->wc_cookie);
- unregister_framebuffer(info);
-
radeonfb_bl_exit(rinfo);
+ unregister_framebuffer(info);
iounmap(rinfo->mmio_base);
iounmap(rinfo->fb_base);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (16 preceding siblings ...)
2023-06-05 14:47 ` [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-06 5:28 ` Dan Carpenter
2023-06-07 9:10 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
` (13 subsequent siblings)
31 siblings, 2 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/fbdev/aty/radeon_backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/radeon_backlight.c b/drivers/video/fbdev/aty/radeon_backlight.c
index 427adc838f77..23a38c3f3977 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -147,7 +147,7 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = FB_BACKLIGHT_LEVELS - 1;
- bd = backlight_device_register(name, rinfo->info->dev, pdata,
+ bd = backlight_device_register(name, rinfo->info->device, pdata,
&radeon_bl_data, &props);
if (IS_ERR(bd)) {
rinfo->info->bl_dev = NULL;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (17 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 9:11 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent Thomas Zimmermann
` (12 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
The driver's backlight code requires the framebuffer to be
registered. Therefore reorder the init and cleanup calls for
both data structures.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/fbdev/riva/fbdev.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 41edc6e79460..e328b2d39e2b 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -2031,9 +2031,6 @@ static int rivafb_probe(struct pci_dev *pd, const struct pci_device_id *ent)
pci_set_drvdata(pd, info);
- if (backlight)
- riva_bl_init(info->par);
-
ret = register_framebuffer(info);
if (ret < 0) {
printk(KERN_ERR PFX
@@ -2041,6 +2038,9 @@ static int rivafb_probe(struct pci_dev *pd, const struct pci_device_id *ent)
goto err_iounmap_screen_base;
}
+ if (backlight)
+ riva_bl_init(info->par);
+
printk(KERN_INFO PFX
"PCI nVidia %s framebuffer ver %s (%dMB @ 0x%lX)\n",
info->fix.id,
@@ -2084,9 +2084,9 @@ static void rivafb_remove(struct pci_dev *pd)
kfree(par->EDID);
#endif
+ riva_bl_exit(info);
unregister_framebuffer(info);
- riva_bl_exit(info);
arch_phys_wc_del(par->wc_cookie);
iounmap(par->ctrl_base);
iounmap(info->screen_base);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (18 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 9:11 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 21/30] fbdev/sm501fb: Output message with fb_err() Thomas Zimmermann
` (11 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
Use the hardware device in struct fb_info.device as parent of the
backlight device. Aligns the driver with the rest of the codebase
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/fbdev/riva/fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index e328b2d39e2b..6ade8de5df4a 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -333,7 +333,7 @@ static void riva_bl_init(struct riva_par *par)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = FB_BACKLIGHT_LEVELS - 1;
- bd = backlight_device_register(name, info->dev, par, &riva_bl_ops,
+ bd = backlight_device_register(name, info->device, par, &riva_bl_ops,
&props);
if (IS_ERR(bd)) {
info->bl_dev = NULL;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 21/30] fbdev/sm501fb: Output message with fb_err()
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (19 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 9:12 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount Thomas Zimmermann
` (10 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Fix case were dev_err() is being called with struct fb_info.dev.
Use fb_err() instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/sm501fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index e0d29be1565b..46951a095274 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1293,7 +1293,7 @@ static int sm501fb_sync(struct fb_info *info)
count--;
if (count <= 0) {
- dev_err(info->dev, "Timeout waiting for 2d engine sync\n");
+ fb_err(info, "Timeout waiting for 2d engine sync\n");
return 1;
}
return 0;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (20 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 21/30] fbdev/sm501fb: Output message with fb_err() Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 22:22 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device Thomas Zimmermann
` (9 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Steve Glendinning
Detect registered instances of fb_info by reading the reference
counter from struct fb_info.read. Avoids looking at the dev field
and prepares fbdev for making struct fb_info.dev optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/video/fbdev/smscufx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 17cec62cc65d..adb2b1fe8383 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1496,7 +1496,7 @@ static int ufx_setup_modes(struct ufx_data *dev, struct fb_info *info,
u8 *edid;
int i, result = 0, tries = 3;
- if (info->dev) /* only use mutex if info has been registered */
+ if (refcount_read(&info->count)) /* only use mutex if info has been registered */
mutex_lock(&info->lock);
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
@@ -1610,7 +1610,7 @@ static int ufx_setup_modes(struct ufx_data *dev, struct fb_info *info,
if (edid && (dev->edid != edid))
kfree(edid);
- if (info->dev)
+ if (refcount_read(&info->count))
mutex_unlock(&info->lock);
return result;
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (21 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 22:23 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions Thomas Zimmermann
` (8 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Use the 3dfx hardware device from the Linux device hierarchy as
parent device of the i2c adapter. Aligns the driver with the rest
of the codebase and prepares fbdev for making struct fb_info.dev
optional.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/tdfxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index cdf8e9fe9948..dd0fa42eceb9 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -1327,8 +1327,8 @@ static void tdfxfb_create_i2c_busses(struct fb_info *info)
par->chan[0].par = par;
par->chan[1].par = par;
- tdfxfb_setup_ddc_bus(&par->chan[0], "Voodoo3-DDC", info->dev);
- tdfxfb_setup_i2c_bus(&par->chan[1], "Voodoo3-I2C", info->dev);
+ tdfxfb_setup_ddc_bus(&par->chan[0], "Voodoo3-DDC", info->device);
+ tdfxfb_setup_i2c_bus(&par->chan[1], "Voodoo3-I2C", info->device);
}
static void tdfxfb_delete_i2c_busses(struct tdfx_par *par)
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (22 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 19:25 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files Thomas Zimmermann
` (7 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Rafael J. Wysocki, Pavel Machek, linux-pm
Pass the Linux device to pm_vt_switch_*() instead of the virtual
fbdev device. Prepares fbdev for making struct fb_info.dev optional.
The type of device that is passed to the PM functions does not matter
much. It is only a token within the internal list of known devices.
The PM functions do not refer to any of the device's properties or its
type.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: linux-pm@vger.kernel.org
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 329d16e49a90..f91ae7d4c94d 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1478,9 +1478,9 @@ static int do_register_framebuffer(struct fb_info *fb_info)
INIT_LIST_HEAD(&fb_info->modelist);
if (fb_info->skip_vt_switch)
- pm_vt_switch_required(fb_info->dev, false);
+ pm_vt_switch_required(fb_info->device, false);
else
- pm_vt_switch_required(fb_info->dev, true);
+ pm_vt_switch_required(fb_info->device, true);
fb_var_to_videomode(&mode, &fb_info->var);
fb_add_videomode(&mode, &fb_info->modelist);
@@ -1520,7 +1520,7 @@ static void unlink_framebuffer(struct fb_info *fb_info)
device_destroy(fb_class, MKDEV(FB_MAJOR, i));
- pm_vt_switch_unregister(fb_info->dev);
+ pm_vt_switch_unregister(fb_info->device);
unbind_console(fb_info);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (23 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 19:38 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}() Thomas Zimmermann
` (6 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Move framebuffer and backlight helpers into separate files. Leave
fbsysfs.c to sysfs-related code. No functional changes.
The framebuffer helpers are not in fbmem.c because they are under
GPL-2.0-or-later copyright, while fbmem.c is GPL-2.0.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/Makefile | 4 +-
drivers/video/fbdev/core/fb_backlight.c | 32 +++++++
drivers/video/fbdev/core/fb_info.c | 76 ++++++++++++++++
drivers/video/fbdev/core/fbsysfs.c | 110 +-----------------------
4 files changed, 112 insertions(+), 110 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_backlight.c
create mode 100644 drivers/video/fbdev/core/fb_info.c
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 8f0060160ffb..eee3295bc225 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,7 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
obj-$(CONFIG_FB) += fb.o
-fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
+fb-y := fb_backlight.o \
+ fb_info.o \
+ fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
diff --git a/drivers/video/fbdev/core/fb_backlight.c b/drivers/video/fbdev/core/fb_backlight.c
new file mode 100644
index 000000000000..feffe6c68039
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_backlight.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/export.h>
+#include <linux/fb.h>
+
+#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
+/*
+ * This function generates a linear backlight curve
+ *
+ * 0: off
+ * 1-7: min
+ * 8-127: linear from min to max
+ */
+void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
+{
+ unsigned int i, flat, count, range = (max - min);
+
+ mutex_lock(&fb_info->bl_curve_mutex);
+
+ fb_info->bl_curve[0] = off;
+
+ for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
+ fb_info->bl_curve[flat] = min;
+
+ count = FB_BACKLIGHT_LEVELS * 15 / 16;
+ for (i = 0; i < count; ++i)
+ fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
+
+ mutex_unlock(&fb_info->bl_curve_mutex);
+}
+EXPORT_SYMBOL_GPL(fb_bl_default_curve);
+#endif
diff --git a/drivers/video/fbdev/core/fb_info.c b/drivers/video/fbdev/core/fb_info.c
new file mode 100644
index 000000000000..fb5b75009ee7
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_info.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/export.h>
+#include <linux/fb.h>
+
+/**
+ * framebuffer_alloc - creates a new frame buffer info structure
+ *
+ * @size: size of driver private data, can be zero
+ * @dev: pointer to the device for this fb, this can be NULL
+ *
+ * Creates a new frame buffer info structure. Also reserves @size bytes
+ * for driver private data (info->par). info->par (if any) will be
+ * aligned to sizeof(long).
+ *
+ * Returns the new structure, or NULL if an error occurred.
+ *
+ */
+struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
+{
+#define BYTES_PER_LONG (BITS_PER_LONG/8)
+#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
+ int fb_info_size = sizeof(struct fb_info);
+ struct fb_info *info;
+ char *p;
+
+ if (size)
+ fb_info_size += PADDING;
+
+ p = kzalloc(fb_info_size + size, GFP_KERNEL);
+
+ if (!p)
+ return NULL;
+
+ info = (struct fb_info *) p;
+
+ if (size)
+ info->par = p + fb_info_size;
+
+ info->device = dev;
+ info->fbcon_rotate_hint = -1;
+
+#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
+ mutex_init(&info->bl_curve_mutex);
+#endif
+
+ return info;
+#undef PADDING
+#undef BYTES_PER_LONG
+}
+EXPORT_SYMBOL(framebuffer_alloc);
+
+/**
+ * framebuffer_release - marks the structure available for freeing
+ *
+ * @info: frame buffer info structure
+ *
+ * Drop the reference count of the device embedded in the
+ * framebuffer info structure.
+ *
+ */
+void framebuffer_release(struct fb_info *info)
+{
+ if (!info)
+ return;
+
+ if (WARN_ON(refcount_read(&info->count)))
+ return;
+
+#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
+ mutex_destroy(&info->bl_curve_mutex);
+#endif
+
+ kfree(info);
+}
+EXPORT_SYMBOL(framebuffer_release);
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 0c33c4adcd79..849073f1ca06 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -5,93 +5,12 @@
* Copyright (c) 2004 James Simmons <jsimmons@infradead.org>
*/
-/*
- * Note: currently there's only stubs for framebuffer_alloc and
- * framebuffer_release here. The reson for that is that until all drivers
- * are converted to use it a sysfsification will open OOPSable races.
- */
-
-#include <linux/kernel.h>
-#include <linux/slab.h>
+#include <linux/console.h>
#include <linux/fb.h>
#include <linux/fbcon.h>
-#include <linux/console.h>
-#include <linux/module.h>
#define FB_SYSFS_FLAG_ATTR 1
-/**
- * framebuffer_alloc - creates a new frame buffer info structure
- *
- * @size: size of driver private data, can be zero
- * @dev: pointer to the device for this fb, this can be NULL
- *
- * Creates a new frame buffer info structure. Also reserves @size bytes
- * for driver private data (info->par). info->par (if any) will be
- * aligned to sizeof(long).
- *
- * Returns the new structure, or NULL if an error occurred.
- *
- */
-struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
-{
-#define BYTES_PER_LONG (BITS_PER_LONG/8)
-#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
- int fb_info_size = sizeof(struct fb_info);
- struct fb_info *info;
- char *p;
-
- if (size)
- fb_info_size += PADDING;
-
- p = kzalloc(fb_info_size + size, GFP_KERNEL);
-
- if (!p)
- return NULL;
-
- info = (struct fb_info *) p;
-
- if (size)
- info->par = p + fb_info_size;
-
- info->device = dev;
- info->fbcon_rotate_hint = -1;
-
-#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
- mutex_init(&info->bl_curve_mutex);
-#endif
-
- return info;
-#undef PADDING
-#undef BYTES_PER_LONG
-}
-EXPORT_SYMBOL(framebuffer_alloc);
-
-/**
- * framebuffer_release - marks the structure available for freeing
- *
- * @info: frame buffer info structure
- *
- * Drop the reference count of the device embedded in the
- * framebuffer info structure.
- *
- */
-void framebuffer_release(struct fb_info *info)
-{
- if (!info)
- return;
-
- if (WARN_ON(refcount_read(&info->count)))
- return;
-
-#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
- mutex_destroy(&info->bl_curve_mutex);
-#endif
-
- kfree(info);
-}
-EXPORT_SYMBOL(framebuffer_release);
-
static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
{
int err;
@@ -551,30 +470,3 @@ void fb_cleanup_device(struct fb_info *fb_info)
fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
}
}
-
-#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
-/* This function generates a linear backlight curve
- *
- * 0: off
- * 1-7: min
- * 8-127: linear from min to max
- */
-void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
-{
- unsigned int i, flat, count, range = (max - min);
-
- mutex_lock(&fb_info->bl_curve_mutex);
-
- fb_info->bl_curve[0] = off;
-
- for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
- fb_info->bl_curve[flat] = min;
-
- count = FB_BACKLIGHT_LEVELS * 15 / 16;
- for (i = 0; i < count; ++i)
- fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
-
- mutex_unlock(&fb_info->bl_curve_mutex);
-}
-EXPORT_SYMBOL_GPL(fb_bl_default_curve);
-#endif
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}()
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (24 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 19:45 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 27/30] fbdev/core: Move procfs code to separate file Thomas Zimmermann
` (5 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Move the logic to create and destroy fbdev devices into the new
helpers fb_device_create() and fb_device_destroy().
There was a call to fb_cleanup_device() in do_unregister_framebuffer()
that was too late. The device had already been removed at this point.
Move the call into fb_device_destroy().
Declare the helpers in the new internal header file fb_internal.h, as
they are only used within the fbdev core module.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_internal.h | 12 ++++++++
drivers/video/fbdev/core/fbmem.c | 21 +++-----------
drivers/video/fbdev/core/fbsysfs.c | 38 ++++++++++++++++++++++++--
include/linux/fb.h | 3 --
4 files changed, 52 insertions(+), 22 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_internal.h
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
new file mode 100644
index 000000000000..0b9640ae7a3d
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _FB_INTERNAL_H
+#define _FB_INTERNAL_H
+
+struct fb_info;
+
+/* fbsysfs.c */
+int fb_device_create(struct fb_info *fb_info);
+void fb_device_destroy(struct fb_info *fb_info);
+
+#endif
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index f91ae7d4c94d..66532774d351 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -40,6 +40,8 @@
#include <video/nomodeset.h>
#include <video/vga.h>
+#include "fb_internal.h"
+
/*
* Frame buffer device initialization and setup routines
*/
@@ -1447,14 +1449,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
mutex_init(&fb_info->lock);
mutex_init(&fb_info->mm_lock);
- fb_info->dev = device_create(fb_class, fb_info->device,
- MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
- if (IS_ERR(fb_info->dev)) {
- /* Not fatal */
- printk(KERN_WARNING "Unable to create device for framebuffer %d; errno = %ld\n", i, PTR_ERR(fb_info->dev));
- fb_info->dev = NULL;
- } else
- fb_init_device(fb_info);
+ fb_device_create(fb_info);
if (fb_info->pixmap.addr == NULL) {
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
@@ -1515,16 +1510,9 @@ static void unlink_framebuffer(struct fb_info *fb_info)
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
return;
- if (!fb_info->dev)
- return;
-
- device_destroy(fb_class, MKDEV(FB_MAJOR, i));
-
+ fb_device_destroy(fb_info);
pm_vt_switch_unregister(fb_info->device);
-
unbind_console(fb_info);
-
- fb_info->dev = NULL;
}
static void do_unregister_framebuffer(struct fb_info *fb_info)
@@ -1539,7 +1527,6 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
fb_destroy_modelist(&fb_info->modelist);
registered_fb[fb_info->node] = NULL;
num_registered_fb--;
- fb_cleanup_device(fb_info);
#ifdef CONFIG_GUMSTIX_AM200EPD
{
struct fb_event event;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 849073f1ca06..fafe574398b0 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -8,6 +8,9 @@
#include <linux/console.h>
#include <linux/fb.h>
#include <linux/fbcon.h>
+#include <linux/major.h>
+
+#include "fb_internal.h"
#define FB_SYSFS_FLAG_ATTR 1
@@ -435,7 +438,7 @@ static struct device_attribute device_attrs[] = {
#endif
};
-int fb_init_device(struct fb_info *fb_info)
+static int fb_init_device(struct fb_info *fb_info)
{
int i, error = 0;
@@ -459,7 +462,7 @@ int fb_init_device(struct fb_info *fb_info)
return 0;
}
-void fb_cleanup_device(struct fb_info *fb_info)
+static void fb_cleanup_device(struct fb_info *fb_info)
{
unsigned int i;
@@ -470,3 +473,34 @@ void fb_cleanup_device(struct fb_info *fb_info)
fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
}
}
+
+int fb_device_create(struct fb_info *fb_info)
+{
+ int node = fb_info->node;
+ dev_t devt = MKDEV(FB_MAJOR, node);
+ int ret;
+
+ fb_info->dev = device_create(fb_class, fb_info->device, devt, NULL, "fb%d", node);
+ if (IS_ERR(fb_info->dev)) {
+ /* Not fatal */
+ ret = PTR_ERR(fb_info->dev);
+ pr_warn("Unable to create device for framebuffer %d; error %d\n", node, ret);
+ fb_info->dev = NULL;
+ } else {
+ fb_init_device(fb_info);
+ }
+
+ return 0;
+}
+
+void fb_device_destroy(struct fb_info *fb_info)
+{
+ dev_t devt = MKDEV(FB_MAJOR, fb_info->node);
+
+ if (!fb_info->dev)
+ return;
+
+ fb_cleanup_device(fb_info);
+ device_destroy(fb_class, devt);
+ fb_info->dev = NULL;
+}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ce6823e157e6..1988d11f78bc 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -735,11 +735,8 @@ static inline bool fb_be_math(struct fb_info *info)
#endif /* CONFIG_FB_FOREIGN_ENDIAN */
}
-/* drivers/video/fbsysfs.c */
extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
extern void framebuffer_release(struct fb_info *info);
-extern int fb_init_device(struct fb_info *fb_info);
-extern void fb_cleanup_device(struct fb_info *head);
extern void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max);
/* drivers/video/fbmon.c */
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 27/30] fbdev/core: Move procfs code to separate file
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (25 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}() Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 20:33 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
` (4 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Move fbdev's procfs code into a separate file and contain it in
init and cleanup helpers. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/Makefile | 1 +
drivers/video/fbdev/core/fb_internal.h | 12 ++++-
drivers/video/fbdev/core/fb_procfs.c | 62 ++++++++++++++++++++++++++
drivers/video/fbdev/core/fbmem.c | 51 +++------------------
4 files changed, 80 insertions(+), 46 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_procfs.c
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index eee3295bc225..665320160f70 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
obj-$(CONFIG_FB) += fb.o
fb-y := fb_backlight.o \
fb_info.o \
+ fb_procfs.o \
fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
index 0b9640ae7a3d..51f7c9f04e45 100644
--- a/drivers/video/fbdev/core/fb_internal.h
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -3,7 +3,17 @@
#ifndef _FB_INTERNAL_H
#define _FB_INTERNAL_H
-struct fb_info;
+#include <linux/fb.h>
+#include <linux/mutex.h>
+
+/* fbmem.c */
+extern struct mutex registration_lock;
+extern struct fb_info *registered_fb[FB_MAX];
+extern int num_registered_fb;
+
+/* fb_procfs.c */
+int fb_init_procfs(void);
+void fb_cleanup_procfs(void);
/* fbsysfs.c */
int fb_device_create(struct fb_info *fb_info);
diff --git a/drivers/video/fbdev/core/fb_procfs.c b/drivers/video/fbdev/core/fb_procfs.c
new file mode 100644
index 000000000000..59641142f8aa
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_procfs.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/proc_fs.h>
+
+#include "fb_internal.h"
+
+static struct proc_dir_entry *fb_proc_dir_entry;
+
+static void *fb_seq_start(struct seq_file *m, loff_t *pos)
+{
+ mutex_lock(®istration_lock);
+
+ return (*pos < FB_MAX) ? pos : NULL;
+}
+
+static void fb_seq_stop(struct seq_file *m, void *v)
+{
+ mutex_unlock(®istration_lock);
+}
+
+static void *fb_seq_next(struct seq_file *m, void *v, loff_t *pos)
+{
+ (*pos)++;
+
+ return (*pos < FB_MAX) ? pos : NULL;
+}
+
+static int fb_seq_show(struct seq_file *m, void *v)
+{
+ int i = *(loff_t *)v;
+ struct fb_info *fi = registered_fb[i];
+
+ if (fi)
+ seq_printf(m, "%d %s\n", fi->node, fi->fix.id);
+
+ return 0;
+}
+
+static const struct seq_operations __maybe_unused fb_proc_seq_ops = {
+ .start = fb_seq_start,
+ .stop = fb_seq_stop,
+ .next = fb_seq_next,
+ .show = fb_seq_show,
+};
+
+int fb_init_procfs(void)
+{
+ struct proc_dir_entry *proc;
+
+ proc = proc_create_seq("fb", 0, NULL, &fb_proc_seq_ops);
+ if (!proc)
+ return -ENOMEM;
+
+ fb_proc_dir_entry = proc;
+
+ return 0;
+}
+
+void fb_cleanup_procfs(void)
+{
+ proc_remove(fb_proc_dir_entry);
+}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 66532774d351..de1e45240161 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -24,9 +24,7 @@
#include <linux/vt.h>
#include <linux/init.h>
#include <linux/linux_logo.h>
-#include <linux/proc_fs.h>
#include <linux/platform_device.h>
-#include <linux/seq_file.h>
#include <linux/console.h>
#include <linux/kmod.h>
#include <linux/err.h>
@@ -48,13 +46,9 @@
#define FBPIXMAPSIZE (1024 * 8)
-static DEFINE_MUTEX(registration_lock);
-
+DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
int num_registered_fb __read_mostly;
-#define for_each_registered_fb(i) \
- for (i = 0; i < FB_MAX; i++) \
- if (!registered_fb[i]) {} else
bool fb_center_logo __read_mostly;
@@ -705,40 +699,6 @@ int fb_show_logo(struct fb_info *info, int rotate) { return 0; }
EXPORT_SYMBOL(fb_prepare_logo);
EXPORT_SYMBOL(fb_show_logo);
-static void *fb_seq_start(struct seq_file *m, loff_t *pos)
-{
- mutex_lock(®istration_lock);
- return (*pos < FB_MAX) ? pos : NULL;
-}
-
-static void *fb_seq_next(struct seq_file *m, void *v, loff_t *pos)
-{
- (*pos)++;
- return (*pos < FB_MAX) ? pos : NULL;
-}
-
-static void fb_seq_stop(struct seq_file *m, void *v)
-{
- mutex_unlock(®istration_lock);
-}
-
-static int fb_seq_show(struct seq_file *m, void *v)
-{
- int i = *(loff_t *)v;
- struct fb_info *fi = registered_fb[i];
-
- if (fi)
- seq_printf(m, "%d %s\n", fi->node, fi->fix.id);
- return 0;
-}
-
-static const struct seq_operations __maybe_unused proc_fb_seq_ops = {
- .start = fb_seq_start,
- .next = fb_seq_next,
- .stop = fb_seq_stop,
- .show = fb_seq_show,
-};
-
/*
* We hold a reference to the fb_info in file->private_data,
* but if the current registered fb has changed, we don't
@@ -1624,8 +1584,9 @@ fbmem_init(void)
{
int ret;
- if (!proc_create_seq("fb", 0, NULL, &proc_fb_seq_ops))
- return -ENOMEM;
+ ret = fb_init_procfs();
+ if (ret)
+ return ret;
ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
if (ret) {
@@ -1648,7 +1609,7 @@ fbmem_init(void)
err_class:
unregister_chrdev(FB_MAJOR, "fb");
err_chrdev:
- remove_proc_entry("fb", NULL);
+ fb_cleanup_procfs();
return ret;
}
@@ -1659,7 +1620,7 @@ fbmem_exit(void)
{
fb_console_exit();
- remove_proc_entry("fb", NULL);
+ fb_cleanup_procfs();
class_destroy(fb_class);
unregister_chrdev(FB_MAJOR, "fb");
}
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (26 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 27/30] fbdev/core: Move procfs code to separate file Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-05 21:35 ` kernel test robot
` (2 more replies)
2023-06-05 14:48 ` [PATCH 29/30] fbdev/core: Rework fb init code Thomas Zimmermann
` (3 subsequent siblings)
31 siblings, 3 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Move fbdev's file-I/O code into a separate file and contain it in
init and cleanup helpers. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/Makefile | 1 +
drivers/video/fbdev/core/fb_devfs.c | 484 +++++++++++++++++++++++++
drivers/video/fbdev/core/fb_internal.h | 6 +
drivers/video/fbdev/core/fbmem.c | 478 +-----------------------
4 files changed, 497 insertions(+), 472 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_devfs.c
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 665320160f70..125d24f50c36 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
obj-$(CONFIG_FB) += fb.o
fb-y := fb_backlight.o \
+ fb_devfs.o \
fb_info.o \
fb_procfs.o \
fbmem.o fbmon.o fbcmap.o fbsysfs.o \
diff --git a/drivers/video/fbdev/core/fb_devfs.c b/drivers/video/fbdev/core/fb_devfs.c
new file mode 100644
index 000000000000..5ab16cb24524
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_devfs.c
@@ -0,0 +1,484 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/console.h>
+#include <linux/fb.h>
+#include <linux/fbcon.h>
+#include <linux/major.h>
+
+#include "fb_internal.h"
+
+/*
+ * We hold a reference to the fb_info in file->private_data,
+ * but if the current registered fb has changed, we don't
+ * actually want to use it.
+ *
+ * So look up the fb_info using the inode minor number,
+ * and just verify it against the reference we have.
+ */
+static struct fb_info *file_fb_info(struct file *file)
+{
+ struct inode *inode = file_inode(file);
+ int fbidx = iminor(inode);
+ struct fb_info *info = registered_fb[fbidx];
+
+ if (info != file->private_data)
+ info = NULL;
+ return info;
+}
+
+static ssize_t fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
+{
+ struct fb_info *info = file_fb_info(file);
+
+ if (!info)
+ return -ENODEV;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return -EPERM;
+
+ if (info->fbops->fb_read)
+ return info->fbops->fb_read(info, buf, count, ppos);
+
+ return fb_io_read(info, buf, count, ppos);
+}
+
+static ssize_t fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
+{
+ struct fb_info *info = file_fb_info(file);
+
+ if (!info)
+ return -ENODEV;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return -EPERM;
+
+ if (info->fbops->fb_write)
+ return info->fbops->fb_write(info, buf, count, ppos);
+
+ return fb_io_write(info, buf, count, ppos);
+}
+
+static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ const struct fb_ops *fb;
+ struct fb_var_screeninfo var;
+ struct fb_fix_screeninfo fix;
+ struct fb_cmap cmap_from;
+ struct fb_cmap_user cmap;
+ void __user *argp = (void __user *)arg;
+ long ret = 0;
+
+ switch (cmd) {
+ case FBIOGET_VSCREENINFO:
+ lock_fb_info(info);
+ var = info->var;
+ unlock_fb_info(info);
+
+ ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
+ break;
+ case FBIOPUT_VSCREENINFO:
+ if (copy_from_user(&var, argp, sizeof(var)))
+ return -EFAULT;
+ /* only for kernel-internal use */
+ var.activate &= ~FB_ACTIVATE_KD_TEXT;
+ console_lock();
+ lock_fb_info(info);
+ ret = fbcon_modechange_possible(info, &var);
+ if (!ret)
+ ret = fb_set_var(info, &var);
+ if (!ret)
+ fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+ unlock_fb_info(info);
+ console_unlock();
+ if (!ret && copy_to_user(argp, &var, sizeof(var)))
+ ret = -EFAULT;
+ break;
+ case FBIOGET_FSCREENINFO:
+ lock_fb_info(info);
+ memcpy(&fix, &info->fix, sizeof(fix));
+ if (info->flags & FBINFO_HIDE_SMEM_START)
+ fix.smem_start = 0;
+ unlock_fb_info(info);
+
+ ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
+ break;
+ case FBIOPUTCMAP:
+ if (copy_from_user(&cmap, argp, sizeof(cmap)))
+ return -EFAULT;
+ ret = fb_set_user_cmap(&cmap, info);
+ break;
+ case FBIOGETCMAP:
+ if (copy_from_user(&cmap, argp, sizeof(cmap)))
+ return -EFAULT;
+ lock_fb_info(info);
+ cmap_from = info->cmap;
+ unlock_fb_info(info);
+ ret = fb_cmap_to_user(&cmap_from, &cmap);
+ break;
+ case FBIOPAN_DISPLAY:
+ if (copy_from_user(&var, argp, sizeof(var)))
+ return -EFAULT;
+ console_lock();
+ lock_fb_info(info);
+ ret = fb_pan_display(info, &var);
+ unlock_fb_info(info);
+ console_unlock();
+ if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
+ return -EFAULT;
+ break;
+ case FBIO_CURSOR:
+ ret = -EINVAL;
+ break;
+ case FBIOGET_CON2FBMAP:
+ ret = fbcon_get_con2fb_map_ioctl(argp);
+ break;
+ case FBIOPUT_CON2FBMAP:
+ ret = fbcon_set_con2fb_map_ioctl(argp);
+ break;
+ case FBIOBLANK:
+ if (arg > FB_BLANK_POWERDOWN)
+ return -EINVAL;
+ console_lock();
+ lock_fb_info(info);
+ ret = fb_blank(info, arg);
+ /* might again call into fb_blank */
+ fbcon_fb_blanked(info, arg);
+ unlock_fb_info(info);
+ console_unlock();
+ break;
+ default:
+ lock_fb_info(info);
+ fb = info->fbops;
+ if (fb->fb_ioctl)
+ ret = fb->fb_ioctl(info, cmd, arg);
+ else
+ ret = -ENOTTY;
+ unlock_fb_info(info);
+ }
+ return ret;
+}
+
+static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ struct fb_info *info = file_fb_info(file);
+
+ if (!info)
+ return -ENODEV;
+ return do_fb_ioctl(info, cmd, arg);
+}
+
+#ifdef CONFIG_COMPAT
+struct fb_fix_screeninfo32 {
+ char id[16];
+ compat_caddr_t smem_start;
+ u32 smem_len;
+ u32 type;
+ u32 type_aux;
+ u32 visual;
+ u16 xpanstep;
+ u16 ypanstep;
+ u16 ywrapstep;
+ u32 line_length;
+ compat_caddr_t mmio_start;
+ u32 mmio_len;
+ u32 accel;
+ u16 reserved[3];
+};
+
+struct fb_cmap32 {
+ u32 start;
+ u32 len;
+ compat_caddr_t red;
+ compat_caddr_t green;
+ compat_caddr_t blue;
+ compat_caddr_t transp;
+};
+
+static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct fb_cmap32 cmap32;
+ struct fb_cmap cmap_from;
+ struct fb_cmap_user cmap;
+
+ if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
+ return -EFAULT;
+
+ cmap = (struct fb_cmap_user) {
+ .start = cmap32.start,
+ .len = cmap32.len,
+ .red = compat_ptr(cmap32.red),
+ .green = compat_ptr(cmap32.green),
+ .blue = compat_ptr(cmap32.blue),
+ .transp = compat_ptr(cmap32.transp),
+ };
+
+ if (cmd == FBIOPUTCMAP)
+ return fb_set_user_cmap(&cmap, info);
+
+ lock_fb_info(info);
+ cmap_from = info->cmap;
+ unlock_fb_info(info);
+
+ return fb_cmap_to_user(&cmap_from, &cmap);
+}
+
+static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
+ struct fb_fix_screeninfo32 __user *fix32)
+{
+ __u32 data;
+ int err;
+
+ err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
+
+ data = (__u32) (unsigned long) fix->smem_start;
+ err |= put_user(data, &fix32->smem_start);
+
+ err |= put_user(fix->smem_len, &fix32->smem_len);
+ err |= put_user(fix->type, &fix32->type);
+ err |= put_user(fix->type_aux, &fix32->type_aux);
+ err |= put_user(fix->visual, &fix32->visual);
+ err |= put_user(fix->xpanstep, &fix32->xpanstep);
+ err |= put_user(fix->ypanstep, &fix32->ypanstep);
+ err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
+ err |= put_user(fix->line_length, &fix32->line_length);
+
+ data = (__u32) (unsigned long) fix->mmio_start;
+ err |= put_user(data, &fix32->mmio_start);
+
+ err |= put_user(fix->mmio_len, &fix32->mmio_len);
+ err |= put_user(fix->accel, &fix32->accel);
+ err |= copy_to_user(fix32->reserved, fix->reserved,
+ sizeof(fix->reserved));
+
+ if (err)
+ return -EFAULT;
+ return 0;
+}
+
+static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct fb_fix_screeninfo fix;
+
+ lock_fb_info(info);
+ fix = info->fix;
+ if (info->flags & FBINFO_HIDE_SMEM_START)
+ fix.smem_start = 0;
+ unlock_fb_info(info);
+ return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
+}
+
+static long fb_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct fb_info *info = file_fb_info(file);
+ const struct fb_ops *fb;
+ long ret = -ENOIOCTLCMD;
+
+ if (!info)
+ return -ENODEV;
+ fb = info->fbops;
+ switch (cmd) {
+ case FBIOGET_VSCREENINFO:
+ case FBIOPUT_VSCREENINFO:
+ case FBIOPAN_DISPLAY:
+ case FBIOGET_CON2FBMAP:
+ case FBIOPUT_CON2FBMAP:
+ arg = (unsigned long) compat_ptr(arg);
+ fallthrough;
+ case FBIOBLANK:
+ ret = do_fb_ioctl(info, cmd, arg);
+ break;
+
+ case FBIOGET_FSCREENINFO:
+ ret = fb_get_fscreeninfo(info, cmd, arg);
+ break;
+
+ case FBIOGETCMAP:
+ case FBIOPUTCMAP:
+ ret = fb_getput_cmap(info, cmd, arg);
+ break;
+
+ default:
+ if (fb->fb_compat_ioctl)
+ ret = fb->fb_compat_ioctl(info, cmd, arg);
+ break;
+ }
+ return ret;
+}
+#endif
+
+static int fb_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct fb_info *info = file_fb_info(file);
+ unsigned long mmio_pgoff;
+ unsigned long start;
+ u32 len;
+
+ if (!info)
+ return -ENODEV;
+ mutex_lock(&info->mm_lock);
+
+ if (info->fbops->fb_mmap) {
+ int res;
+
+ /*
+ * The framebuffer needs to be accessed decrypted, be sure
+ * SME protection is removed ahead of the call
+ */
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ res = info->fbops->fb_mmap(info, vma);
+ mutex_unlock(&info->mm_lock);
+ return res;
+#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
+ } else if (info->fbdefio) {
+ /*
+ * FB deferred I/O wants you to handle mmap in your drivers. At a
+ * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
+ */
+ dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
+ mutex_unlock(&info->mm_lock);
+ return -ENODEV;
+#endif
+ }
+
+ /*
+ * Ugh. This can be either the frame buffer mapping, or
+ * if pgoff points past it, the mmio mapping.
+ */
+ start = info->fix.smem_start;
+ len = info->fix.smem_len;
+ mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
+ if (vma->vm_pgoff >= mmio_pgoff) {
+ if (info->var.accel_flags) {
+ mutex_unlock(&info->mm_lock);
+ return -EINVAL;
+ }
+
+ vma->vm_pgoff -= mmio_pgoff;
+ start = info->fix.mmio_start;
+ len = info->fix.mmio_len;
+ }
+ mutex_unlock(&info->mm_lock);
+
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ fb_pgprotect(file, vma, start);
+
+ return vm_iomap_memory(vma, start, len);
+}
+
+static int fb_open(struct inode *inode, struct file *file)
+__acquires(&info->lock)
+__releases(&info->lock)
+{
+ int fbidx = iminor(inode);
+ struct fb_info *info;
+ int res = 0;
+
+ info = get_fb_info(fbidx);
+ if (!info) {
+ request_module("fb%d", fbidx);
+ info = get_fb_info(fbidx);
+ if (!info)
+ return -ENODEV;
+ }
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ lock_fb_info(info);
+ if (!try_module_get(info->fbops->owner)) {
+ res = -ENODEV;
+ goto out;
+ }
+ file->private_data = info;
+ if (info->fbops->fb_open) {
+ res = info->fbops->fb_open(info, 1);
+ if (res)
+ module_put(info->fbops->owner);
+ }
+#ifdef CONFIG_FB_DEFERRED_IO
+ if (info->fbdefio)
+ fb_deferred_io_open(info, inode, file);
+#endif
+out:
+ unlock_fb_info(info);
+ if (res)
+ put_fb_info(info);
+ return res;
+}
+
+static int fb_release(struct inode *inode, struct file *file)
+__acquires(&info->lock)
+__releases(&info->lock)
+{
+ struct fb_info * const info = file->private_data;
+
+ lock_fb_info(info);
+#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
+ if (info->fbdefio)
+ fb_deferred_io_release(info);
+#endif
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 1);
+ module_put(info->fbops->owner);
+ unlock_fb_info(info);
+ put_fb_info(info);
+ return 0;
+}
+
+#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
+static unsigned long get_fb_unmapped_area(struct file *filp,
+ unsigned long addr, unsigned long len,
+ unsigned long pgoff, unsigned long flags)
+{
+ struct fb_info * const info = filp->private_data;
+ unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
+
+ if (pgoff > fb_size || len > fb_size - pgoff)
+ return -EINVAL;
+
+ return (unsigned long)info->screen_base + pgoff;
+}
+#endif
+
+static const struct file_operations fb_fops = {
+ .owner = THIS_MODULE,
+ .read = fb_read,
+ .write = fb_write,
+ .unlocked_ioctl = fb_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = fb_compat_ioctl,
+#endif
+ .mmap = fb_mmap,
+ .open = fb_open,
+ .release = fb_release,
+#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
+ (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
+ !defined(CONFIG_MMU))
+ .get_unmapped_area = get_fb_unmapped_area,
+#endif
+#ifdef CONFIG_FB_DEFERRED_IO
+ .fsync = fb_deferred_io_fsync,
+#endif
+ .llseek = default_llseek,
+};
+
+int fb_register_chrdev(void)
+{
+ int ret;
+
+ ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
+ if (ret) {
+ pr_err("Unable to get major %d for fb devs\n", FB_MAJOR);
+ return ret;
+ }
+
+ return ret;
+}
+
+void fb_unregister_chrdev(void)
+{
+ unregister_chrdev(FB_MAJOR, "fb");
+}
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
index 51f7c9f04e45..abe06c9da36e 100644
--- a/drivers/video/fbdev/core/fb_internal.h
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -6,10 +6,16 @@
#include <linux/fb.h>
#include <linux/mutex.h>
+/* fb_devfs.c */
+int fb_register_chrdev(void);
+void fb_unregister_chrdev(void);
+
/* fbmem.c */
extern struct mutex registration_lock;
extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
+struct fb_info *get_fb_info(unsigned int idx);
+void put_fb_info(struct fb_info *fb_info);
/* fb_procfs.c */
int fb_init_procfs(void);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index de1e45240161..2d26ac46337b 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -17,7 +17,6 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/kernel.h>
-#include <linux/major.h>
#include <linux/slab.h>
#include <linux/mm.h>
#include <linux/mman.h>
@@ -54,7 +53,7 @@ bool fb_center_logo __read_mostly;
int fb_logo_count __read_mostly = -1;
-static struct fb_info *get_fb_info(unsigned int idx)
+struct fb_info *get_fb_info(unsigned int idx)
{
struct fb_info *fb_info;
@@ -70,7 +69,7 @@ static struct fb_info *get_fb_info(unsigned int idx)
return fb_info;
}
-static void put_fb_info(struct fb_info *fb_info)
+void put_fb_info(struct fb_info *fb_info)
{
if (!refcount_dec_and_test(&fb_info->count))
return;
@@ -699,59 +698,6 @@ int fb_show_logo(struct fb_info *info, int rotate) { return 0; }
EXPORT_SYMBOL(fb_prepare_logo);
EXPORT_SYMBOL(fb_show_logo);
-/*
- * We hold a reference to the fb_info in file->private_data,
- * but if the current registered fb has changed, we don't
- * actually want to use it.
- *
- * So look up the fb_info using the inode minor number,
- * and just verify it against the reference we have.
- */
-static struct fb_info *file_fb_info(struct file *file)
-{
- struct inode *inode = file_inode(file);
- int fbidx = iminor(inode);
- struct fb_info *info = registered_fb[fbidx];
-
- if (info != file->private_data)
- info = NULL;
- return info;
-}
-
-static ssize_t
-fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
-{
- struct fb_info *info = file_fb_info(file);
-
- if (!info)
- return -ENODEV;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- if (info->fbops->fb_read)
- return info->fbops->fb_read(info, buf, count, ppos);
-
- return fb_io_read(info, buf, count, ppos);
-}
-
-static ssize_t
-fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
-{
- struct fb_info *info = file_fb_info(file);
-
- if (!info)
- return -ENODEV;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- if (info->fbops->fb_write)
- return info->fbops->fb_write(info, buf, count, ppos);
-
- return fb_io_write(info, buf, count, ppos);
-}
-
int
fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var)
{
@@ -951,416 +897,6 @@ fb_blank(struct fb_info *info, int blank)
}
EXPORT_SYMBOL(fb_blank);
-static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
-{
- const struct fb_ops *fb;
- struct fb_var_screeninfo var;
- struct fb_fix_screeninfo fix;
- struct fb_cmap cmap_from;
- struct fb_cmap_user cmap;
- void __user *argp = (void __user *)arg;
- long ret = 0;
-
- switch (cmd) {
- case FBIOGET_VSCREENINFO:
- lock_fb_info(info);
- var = info->var;
- unlock_fb_info(info);
-
- ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
- break;
- case FBIOPUT_VSCREENINFO:
- if (copy_from_user(&var, argp, sizeof(var)))
- return -EFAULT;
- /* only for kernel-internal use */
- var.activate &= ~FB_ACTIVATE_KD_TEXT;
- console_lock();
- lock_fb_info(info);
- ret = fbcon_modechange_possible(info, &var);
- if (!ret)
- ret = fb_set_var(info, &var);
- if (!ret)
- fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
- unlock_fb_info(info);
- console_unlock();
- if (!ret && copy_to_user(argp, &var, sizeof(var)))
- ret = -EFAULT;
- break;
- case FBIOGET_FSCREENINFO:
- lock_fb_info(info);
- memcpy(&fix, &info->fix, sizeof(fix));
- if (info->flags & FBINFO_HIDE_SMEM_START)
- fix.smem_start = 0;
- unlock_fb_info(info);
-
- ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
- break;
- case FBIOPUTCMAP:
- if (copy_from_user(&cmap, argp, sizeof(cmap)))
- return -EFAULT;
- ret = fb_set_user_cmap(&cmap, info);
- break;
- case FBIOGETCMAP:
- if (copy_from_user(&cmap, argp, sizeof(cmap)))
- return -EFAULT;
- lock_fb_info(info);
- cmap_from = info->cmap;
- unlock_fb_info(info);
- ret = fb_cmap_to_user(&cmap_from, &cmap);
- break;
- case FBIOPAN_DISPLAY:
- if (copy_from_user(&var, argp, sizeof(var)))
- return -EFAULT;
- console_lock();
- lock_fb_info(info);
- ret = fb_pan_display(info, &var);
- unlock_fb_info(info);
- console_unlock();
- if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
- return -EFAULT;
- break;
- case FBIO_CURSOR:
- ret = -EINVAL;
- break;
- case FBIOGET_CON2FBMAP:
- ret = fbcon_get_con2fb_map_ioctl(argp);
- break;
- case FBIOPUT_CON2FBMAP:
- ret = fbcon_set_con2fb_map_ioctl(argp);
- break;
- case FBIOBLANK:
- if (arg > FB_BLANK_POWERDOWN)
- return -EINVAL;
- console_lock();
- lock_fb_info(info);
- ret = fb_blank(info, arg);
- /* might again call into fb_blank */
- fbcon_fb_blanked(info, arg);
- unlock_fb_info(info);
- console_unlock();
- break;
- default:
- lock_fb_info(info);
- fb = info->fbops;
- if (fb->fb_ioctl)
- ret = fb->fb_ioctl(info, cmd, arg);
- else
- ret = -ENOTTY;
- unlock_fb_info(info);
- }
- return ret;
-}
-
-static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
- struct fb_info *info = file_fb_info(file);
-
- if (!info)
- return -ENODEV;
- return do_fb_ioctl(info, cmd, arg);
-}
-
-#ifdef CONFIG_COMPAT
-struct fb_fix_screeninfo32 {
- char id[16];
- compat_caddr_t smem_start;
- u32 smem_len;
- u32 type;
- u32 type_aux;
- u32 visual;
- u16 xpanstep;
- u16 ypanstep;
- u16 ywrapstep;
- u32 line_length;
- compat_caddr_t mmio_start;
- u32 mmio_len;
- u32 accel;
- u16 reserved[3];
-};
-
-struct fb_cmap32 {
- u32 start;
- u32 len;
- compat_caddr_t red;
- compat_caddr_t green;
- compat_caddr_t blue;
- compat_caddr_t transp;
-};
-
-static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
-{
- struct fb_cmap32 cmap32;
- struct fb_cmap cmap_from;
- struct fb_cmap_user cmap;
-
- if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
- return -EFAULT;
-
- cmap = (struct fb_cmap_user) {
- .start = cmap32.start,
- .len = cmap32.len,
- .red = compat_ptr(cmap32.red),
- .green = compat_ptr(cmap32.green),
- .blue = compat_ptr(cmap32.blue),
- .transp = compat_ptr(cmap32.transp),
- };
-
- if (cmd == FBIOPUTCMAP)
- return fb_set_user_cmap(&cmap, info);
-
- lock_fb_info(info);
- cmap_from = info->cmap;
- unlock_fb_info(info);
-
- return fb_cmap_to_user(&cmap_from, &cmap);
-}
-
-static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
- struct fb_fix_screeninfo32 __user *fix32)
-{
- __u32 data;
- int err;
-
- err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
-
- data = (__u32) (unsigned long) fix->smem_start;
- err |= put_user(data, &fix32->smem_start);
-
- err |= put_user(fix->smem_len, &fix32->smem_len);
- err |= put_user(fix->type, &fix32->type);
- err |= put_user(fix->type_aux, &fix32->type_aux);
- err |= put_user(fix->visual, &fix32->visual);
- err |= put_user(fix->xpanstep, &fix32->xpanstep);
- err |= put_user(fix->ypanstep, &fix32->ypanstep);
- err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
- err |= put_user(fix->line_length, &fix32->line_length);
-
- data = (__u32) (unsigned long) fix->mmio_start;
- err |= put_user(data, &fix32->mmio_start);
-
- err |= put_user(fix->mmio_len, &fix32->mmio_len);
- err |= put_user(fix->accel, &fix32->accel);
- err |= copy_to_user(fix32->reserved, fix->reserved,
- sizeof(fix->reserved));
-
- if (err)
- return -EFAULT;
- return 0;
-}
-
-static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
-{
- struct fb_fix_screeninfo fix;
-
- lock_fb_info(info);
- fix = info->fix;
- if (info->flags & FBINFO_HIDE_SMEM_START)
- fix.smem_start = 0;
- unlock_fb_info(info);
- return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
-}
-
-static long fb_compat_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
-{
- struct fb_info *info = file_fb_info(file);
- const struct fb_ops *fb;
- long ret = -ENOIOCTLCMD;
-
- if (!info)
- return -ENODEV;
- fb = info->fbops;
- switch(cmd) {
- case FBIOGET_VSCREENINFO:
- case FBIOPUT_VSCREENINFO:
- case FBIOPAN_DISPLAY:
- case FBIOGET_CON2FBMAP:
- case FBIOPUT_CON2FBMAP:
- arg = (unsigned long) compat_ptr(arg);
- fallthrough;
- case FBIOBLANK:
- ret = do_fb_ioctl(info, cmd, arg);
- break;
-
- case FBIOGET_FSCREENINFO:
- ret = fb_get_fscreeninfo(info, cmd, arg);
- break;
-
- case FBIOGETCMAP:
- case FBIOPUTCMAP:
- ret = fb_getput_cmap(info, cmd, arg);
- break;
-
- default:
- if (fb->fb_compat_ioctl)
- ret = fb->fb_compat_ioctl(info, cmd, arg);
- break;
- }
- return ret;
-}
-#endif
-
-static int
-fb_mmap(struct file *file, struct vm_area_struct * vma)
-{
- struct fb_info *info = file_fb_info(file);
- unsigned long mmio_pgoff;
- unsigned long start;
- u32 len;
-
- if (!info)
- return -ENODEV;
- mutex_lock(&info->mm_lock);
-
- if (info->fbops->fb_mmap) {
- int res;
-
- /*
- * The framebuffer needs to be accessed decrypted, be sure
- * SME protection is removed ahead of the call
- */
- vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
- res = info->fbops->fb_mmap(info, vma);
- mutex_unlock(&info->mm_lock);
- return res;
-#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
- } else if (info->fbdefio) {
- /*
- * FB deferred I/O wants you to handle mmap in your drivers. At a
- * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
- */
- dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
- mutex_unlock(&info->mm_lock);
- return -ENODEV;
-#endif
- }
-
- /*
- * Ugh. This can be either the frame buffer mapping, or
- * if pgoff points past it, the mmio mapping.
- */
- start = info->fix.smem_start;
- len = info->fix.smem_len;
- mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
- if (vma->vm_pgoff >= mmio_pgoff) {
- if (info->var.accel_flags) {
- mutex_unlock(&info->mm_lock);
- return -EINVAL;
- }
-
- vma->vm_pgoff -= mmio_pgoff;
- start = info->fix.mmio_start;
- len = info->fix.mmio_len;
- }
- mutex_unlock(&info->mm_lock);
-
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
- fb_pgprotect(file, vma, start);
-
- return vm_iomap_memory(vma, start, len);
-}
-
-static int
-fb_open(struct inode *inode, struct file *file)
-__acquires(&info->lock)
-__releases(&info->lock)
-{
- int fbidx = iminor(inode);
- struct fb_info *info;
- int res = 0;
-
- info = get_fb_info(fbidx);
- if (!info) {
- request_module("fb%d", fbidx);
- info = get_fb_info(fbidx);
- if (!info)
- return -ENODEV;
- }
- if (IS_ERR(info))
- return PTR_ERR(info);
-
- lock_fb_info(info);
- if (!try_module_get(info->fbops->owner)) {
- res = -ENODEV;
- goto out;
- }
- file->private_data = info;
- if (info->fbops->fb_open) {
- res = info->fbops->fb_open(info,1);
- if (res)
- module_put(info->fbops->owner);
- }
-#ifdef CONFIG_FB_DEFERRED_IO
- if (info->fbdefio)
- fb_deferred_io_open(info, inode, file);
-#endif
-out:
- unlock_fb_info(info);
- if (res)
- put_fb_info(info);
- return res;
-}
-
-static int
-fb_release(struct inode *inode, struct file *file)
-__acquires(&info->lock)
-__releases(&info->lock)
-{
- struct fb_info * const info = file->private_data;
-
- lock_fb_info(info);
-#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
- if (info->fbdefio)
- fb_deferred_io_release(info);
-#endif
- if (info->fbops->fb_release)
- info->fbops->fb_release(info,1);
- module_put(info->fbops->owner);
- unlock_fb_info(info);
- put_fb_info(info);
- return 0;
-}
-
-#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
-static unsigned long get_fb_unmapped_area(struct file *filp,
- unsigned long addr, unsigned long len,
- unsigned long pgoff, unsigned long flags)
-{
- struct fb_info * const info = filp->private_data;
- unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
-
- if (pgoff > fb_size || len > fb_size - pgoff)
- return -EINVAL;
-
- return (unsigned long)info->screen_base + pgoff;
-}
-#endif
-
-static const struct file_operations fb_fops = {
- .owner = THIS_MODULE,
- .read = fb_read,
- .write = fb_write,
- .unlocked_ioctl = fb_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = fb_compat_ioctl,
-#endif
- .mmap = fb_mmap,
- .open = fb_open,
- .release = fb_release,
-#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
- (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
- !defined(CONFIG_MMU))
- .get_unmapped_area = get_fb_unmapped_area,
-#endif
-#ifdef CONFIG_FB_DEFERRED_IO
- .fsync = fb_deferred_io_fsync,
-#endif
- .llseek = default_llseek,
-};
-
struct class *fb_class;
EXPORT_SYMBOL(fb_class);
@@ -1588,11 +1124,9 @@ fbmem_init(void)
if (ret)
return ret;
- ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
- if (ret) {
- printk("unable to get major %d for fb devs\n", FB_MAJOR);
+ ret = fb_register_chrdev();
+ if (ret)
goto err_chrdev;
- }
fb_class = class_create("graphics");
if (IS_ERR(fb_class)) {
@@ -1607,7 +1141,7 @@ fbmem_init(void)
return 0;
err_class:
- unregister_chrdev(FB_MAJOR, "fb");
+ fb_unregister_chrdev();
err_chrdev:
fb_cleanup_procfs();
return ret;
@@ -1622,7 +1156,7 @@ fbmem_exit(void)
fb_cleanup_procfs();
class_destroy(fb_class);
- unregister_chrdev(FB_MAJOR, "fb");
+ fb_unregister_chrdev();
}
module_exit(fbmem_exit);
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 29/30] fbdev/core: Rework fb init code
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (27 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-07 20:51 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
` (2 subsequent siblings)
31 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Init the class "graphics" before the rest of fbdev. Later steps, such
as the sysfs code, depend on the class. Also arrange the module's exit
code in reverse order.
Unexport the global variable fb_class, which is only shared internally
within the fbdev core module.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fb_internal.h | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
drivers/video/fbdev/core/fbmem.c | 52 ++++++++++----------------
include/linux/fb.h | 1 -
4 files changed, 22 insertions(+), 33 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
index abe06c9da36e..0b43c0cd5096 100644
--- a/drivers/video/fbdev/core/fb_internal.h
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -11,6 +11,7 @@ int fb_register_chrdev(void);
void fb_unregister_chrdev(void);
/* fbmem.c */
+extern struct class *fb_class;
extern struct mutex registration_lock;
extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c6c9d040bdec..8e76bc246b38 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -78,6 +78,7 @@
#include <asm/irq.h>
#include "fbcon.h"
+#include "fb_internal.h"
/*
* FIXME: Locking
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 2d26ac46337b..b21b66017c01 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -45,6 +45,8 @@
#define FBPIXMAPSIZE (1024 * 8)
+struct class *fb_class;
+
DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
int num_registered_fb __read_mostly;
@@ -897,9 +899,6 @@ fb_blank(struct fb_info *info, int blank)
}
EXPORT_SYMBOL(fb_blank);
-struct class *fb_class;
-EXPORT_SYMBOL(fb_class);
-
static int fb_check_foreignness(struct fb_info *fi)
{
const bool foreign_endian = fi->flags & FBINFO_FOREIGN_ENDIAN;
@@ -1106,59 +1105,48 @@ void fb_set_suspend(struct fb_info *info, int state)
}
EXPORT_SYMBOL(fb_set_suspend);
-/**
- * fbmem_init - init frame buffer subsystem
- *
- * Initialize the frame buffer subsystem.
- *
- * NOTE: This function is _only_ to be called by drivers/char/mem.c.
- *
- */
-
-static int __init
-fbmem_init(void)
+static int __init fbmem_init(void)
{
int ret;
+ fb_class = class_create("graphics");
+ if (IS_ERR(fb_class)) {
+ ret = PTR_ERR(fb_class);
+ pr_err("Unable to create fb class; errno = %d\n", ret);
+ goto err_fb_class;
+ }
+
ret = fb_init_procfs();
if (ret)
- return ret;
+ goto err_class_destroy;
ret = fb_register_chrdev();
if (ret)
- goto err_chrdev;
-
- fb_class = class_create("graphics");
- if (IS_ERR(fb_class)) {
- ret = PTR_ERR(fb_class);
- pr_warn("Unable to create fb class; errno = %d\n", ret);
- fb_class = NULL;
- goto err_class;
- }
+ goto err_fb_cleanup_procfs;
fb_console_init();
return 0;
-err_class:
- fb_unregister_chrdev();
-err_chrdev:
+err_fb_cleanup_procfs:
fb_cleanup_procfs();
+err_class_destroy:
+ class_destroy(fb_class);
+err_fb_class:
+ fb_class = NULL;
return ret;
}
#ifdef MODULE
-module_init(fbmem_init);
-static void __exit
-fbmem_exit(void)
+static void __exit fbmem_exit(void)
{
fb_console_exit();
-
+ fb_unregister_chrdev();
fb_cleanup_procfs();
class_destroy(fb_class);
- fb_unregister_chrdev();
}
+module_init(fbmem_init);
module_exit(fbmem_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Framebuffer base");
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1988d11f78bc..541a0e3ce21f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -609,7 +609,6 @@ extern int fb_new_modelist(struct fb_info *info);
extern bool fb_center_logo;
extern int fb_logo_count;
-extern struct class *fb_class;
static inline void lock_fb_info(struct fb_info *info)
{
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (28 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 29/30] fbdev/core: Rework fb init code Thomas Zimmermann
@ 2023-06-05 14:48 ` Thomas Zimmermann
2023-06-05 15:03 ` Greg KH
` (3 more replies)
2023-06-07 8:35 ` [PATCH 00/30] fbdev: Make userspace interfaces optional Geert Uytterhoeven
2023-06-07 12:06 ` Markus Elfring
31 siblings, 4 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-05 14:48 UTC (permalink / raw)
To: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
device optional. If the new option has not been selected, fbdev
does not create a files in devfs or sysfs.
Most modern Linux systems run a DRM-based graphics stack that uses
the kernel's framebuffer console, but has otherwise deprecated fbdev
support. Yet fbdev userspace interfaces are still present.
The option makes it possible to use the fbdev subsystem as console
implementation without support for userspace. This closes potential
entry points to manipulate kernel or I/O memory via framebuffers. It
also prevents the execution of driver code via ioctl or sysfs, both
of which might allow malicious software to exploit bugs in the fbdev
code.
A small number of fbdev drivers require struct fbinfo.dev to be
initialized, usually for the support of sysfs interface. Make these
drivers depend on FB_DEVICE. They can later be fixed if necessary.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/staging/fbtft/Kconfig | 1 +
drivers/video/fbdev/Kconfig | 12 +++++++++
drivers/video/fbdev/core/Makefile | 7 +++---
drivers/video/fbdev/core/fb_internal.h | 32 ++++++++++++++++++++++++
drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
include/linux/fb.h | 2 ++
6 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
index 4d29e8c1014e..5dda3c65a38e 100644
--- a/drivers/staging/fbtft/Kconfig
+++ b/drivers/staging/fbtft/Kconfig
@@ -2,6 +2,7 @@
menuconfig FB_TFT
tristate "Support for small TFT LCD display modules"
depends on FB && SPI
+ depends on FB_DEVICE
depends on GPIOLIB || COMPILE_TEST
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6df9bd09454a..48d9a14f889c 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -57,6 +57,15 @@ config FIRMWARE_EDID
combination with certain motherboards and monitors are known to
suffer from this problem.
+config FB_DEVICE
+ bool "Provide legacy /dev/fb* device"
+ depends on FB
+ help
+ Say Y here if you want the legacy /dev/fb* device file. It's
+ only required if you have userspace programs that depend on
+ fbdev for graphics output. This does not effect the framebuffer
+ console.
+
config FB_DDC
tristate
depends on FB
@@ -1545,6 +1554,7 @@ config FB_3DFX_I2C
config FB_VOODOO1
tristate "3Dfx Voodoo Graphics (sst1) support"
depends on FB && PCI
+ depends on FB_DEVICE
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1862,6 +1872,7 @@ config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
depends on FB && HAVE_CLK && HAS_IOMEM
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
+ depends on FB_DEVICE
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -1930,6 +1941,7 @@ config FB_SMSCUFX
config FB_UDL
tristate "Displaylink USB Framebuffer support"
depends on FB && USB
+ depends on FB_DEVICE
select FB_MODE_HELPERS
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 125d24f50c36..d5e8772620f8 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -2,12 +2,13 @@
obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
obj-$(CONFIG_FB) += fb.o
fb-y := fb_backlight.o \
- fb_devfs.o \
fb_info.o \
- fb_procfs.o \
- fbmem.o fbmon.o fbcmap.o fbsysfs.o \
+ fbmem.o fbmon.o fbcmap.o \
modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
+fb-$(CONFIG_FB_DEVICE) += fb_devfs.o \
+ fb_procfs.o \
+ fbsysfs.o
ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE),y)
fb-y += fbcon.o bitblit.o softcursor.o
diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
index 0b43c0cd5096..b8a28466db79 100644
--- a/drivers/video/fbdev/core/fb_internal.h
+++ b/drivers/video/fbdev/core/fb_internal.h
@@ -3,12 +3,22 @@
#ifndef _FB_INTERNAL_H
#define _FB_INTERNAL_H
+#include <linux/device.h>
#include <linux/fb.h>
#include <linux/mutex.h>
/* fb_devfs.c */
+#if defined(CONFIG_FB_DEVICE)
int fb_register_chrdev(void);
void fb_unregister_chrdev(void);
+#else
+static inline int fb_register_chrdev(void)
+{
+ return 0;
+}
+static inline void fb_unregister_chrdev(void)
+{ }
+#endif
/* fbmem.c */
extern struct class *fb_class;
@@ -19,11 +29,33 @@ struct fb_info *get_fb_info(unsigned int idx);
void put_fb_info(struct fb_info *fb_info);
/* fb_procfs.c */
+#if defined(CONFIG_FB_DEVICE)
int fb_init_procfs(void);
void fb_cleanup_procfs(void);
+#else
+static inline int fb_init_procfs(void)
+{
+ return 0;
+}
+static inline void fb_cleanup_procfs(void)
+{ }
+#endif
/* fbsysfs.c */
+#if defined(CONFIG_FB_DEVICE)
int fb_device_create(struct fb_info *fb_info);
void fb_device_destroy(struct fb_info *fb_info);
+#else
+static inline int fb_device_create(struct fb_info *fb_info)
+{
+ get_device(fb_info->device); // as in device_add()
+
+ return 0;
+}
+static inline void fb_device_destroy(struct fb_info *fb_info)
+{
+ put_device(fb_info->device); // as in device_del()
+}
+#endif
#endif
diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
index 69f9cb03507e..21069fdb7cc2 100644
--- a/drivers/video/fbdev/omap2/omapfb/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
@@ -5,9 +5,9 @@ config OMAP2_VRFB
menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
+ depends on FB_DEVICE
depends on DRM_OMAP = n
depends on GPIOLIB
-
select FB_OMAP2_DSS
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 541a0e3ce21f..40ed1028160c 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -481,7 +481,9 @@ struct fb_info {
const struct fb_ops *fbops;
struct device *device; /* This is the parent */
+#if defined(CONFIG_FB_DEVICE)
struct device *dev; /* This is this fb device */
+#endif
int class_flag; /* private sysfs flags */
#ifdef CONFIG_FB_TILEBLITTING
struct fb_tile_ops *tileops; /* Tile Blitting */
--
2.40.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
@ 2023-06-05 15:03 ` Greg KH
2023-06-05 21:45 ` kernel test robot
` (2 subsequent siblings)
3 siblings, 0 replies; 99+ messages in thread
From: Greg KH @ 2023-06-05 15:03 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, dri-devel, linux-sh,
linux-omap, linux-staging
On Mon, Jun 05, 2023 at 04:48:12PM +0200, Thomas Zimmermann wrote:
> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
> device optional. If the new option has not been selected, fbdev
> does not create a files in devfs or sysfs.
>
> Most modern Linux systems run a DRM-based graphics stack that uses
> the kernel's framebuffer console, but has otherwise deprecated fbdev
> support. Yet fbdev userspace interfaces are still present.
>
> The option makes it possible to use the fbdev subsystem as console
> implementation without support for userspace. This closes potential
> entry points to manipulate kernel or I/O memory via framebuffers. It
> also prevents the execution of driver code via ioctl or sysfs, both
> of which might allow malicious software to exploit bugs in the fbdev
> code.
>
> A small number of fbdev drivers require struct fbinfo.dev to be
> initialized, usually for the support of sysfs interface. Make these
> drivers depend on FB_DEVICE. They can later be fixed if necessary.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 99+ messages in thread
* RE: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-05 14:47 ` [PATCH 02/30] backlight/gpio_backlight: " Thomas Zimmermann
@ 2023-06-05 20:19 ` Ruhl, Michael J
2023-06-05 20:23 ` Sam Ravnborg
2023-06-06 7:24 ` Thomas Zimmermann
0 siblings, 2 replies; 99+ messages in thread
From: Ruhl, Michael J @ 2023-06-05 20:19 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1
Cc: linux-fbdev, Rich Felker, linux-sh, linux-staging, dri-devel,
John Paul Adrian Glaubitz, linux-omap
>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Thomas Zimmermann
>Sent: Monday, June 5, 2023 10:48 AM
>To: daniel@ffwll.ch; javierm@redhat.com; sam@ravnborg.org;
>deller@gmx.de; geert+renesas@glider.be; lee@kernel.org;
>daniel.thompson@linaro.org; jingoohan1@gmail.com
>Cc: linux-fbdev@vger.kernel.org; Rich Felker <dalias@libc.org>; linux-
>sh@vger.kernel.org; linux-staging@lists.linux.dev; dri-
>devel@lists.freedesktop.org; Thomas Zimmermann
><tzimmermann@suse.de>; John Paul Adrian Glaubitz <glaubitz@physik.fu-
>berlin.de>; linux-omap@vger.kernel.org
>Subject: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>fb_info.device
>
>Struct gpio_backlight_platform_data refers to a platform device within
>the Linux device hierarchy. The test in gpio_backlight_check_fb()
>compares it against the fbdev device in struct fb_info.dev, which
>is different. Fix the test by comparing to struct fb_info.device.
>
>Fixes a bug in the backlight driver and prepares fbdev for making
>struct fb_info.dev optional.
I only see a rename from fbdev to dev...
Is there missing code?
Would a fixes: be useful?
M
>Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>Cc: Rich Felker <dalias@libc.org>
>Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>Cc: Lee Jones <lee@kernel.org>
>Cc: Daniel Thompson <daniel.thompson@linaro.org>
>Cc: Jingoo Han <jingoohan1@gmail.com>
>Cc: linux-sh@vger.kernel.org
>---
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> drivers/video/backlight/gpio_backlight.c | 6 +++---
> include/linux/platform_data/gpio_backlight.h | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-
>ecovec24/setup.c
>index 674da7ebd8b7..310513646c9b 100644
>--- a/arch/sh/boards/mach-ecovec24/setup.c
>+++ b/arch/sh/boards/mach-ecovec24/setup.c
>@@ -386,7 +386,7 @@ static struct property_entry gpio_backlight_props[] = {
> };
>
> static struct gpio_backlight_platform_data gpio_backlight_data = {
>- .fbdev = &lcdc_device.dev,
>+ .dev = &lcdc_device.dev,
> };
>
> static const struct platform_device_info gpio_backlight_device_info = {
>diff --git a/drivers/video/backlight/gpio_backlight.c
>b/drivers/video/backlight/gpio_backlight.c
>index 6f78d928f054..d3bea42407f1 100644
>--- a/drivers/video/backlight/gpio_backlight.c
>+++ b/drivers/video/backlight/gpio_backlight.c
>@@ -17,7 +17,7 @@
> #include <linux/slab.h>
>
> struct gpio_backlight {
>- struct device *fbdev;
>+ struct device *dev;
> struct gpio_desc *gpiod;
> };
>
>@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
>backlight_device *bl,
> {
> struct gpio_backlight *gbl = bl_get_data(bl);
>
>- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
>+ return !gbl->dev || gbl->dev == info->device;
> }
>
> static const struct backlight_ops gpio_backlight_ops = {
>@@ -59,7 +59,7 @@ static int gpio_backlight_probe(struct platform_device
>*pdev)
> return -ENOMEM;
>
> if (pdata)
>- gbl->fbdev = pdata->fbdev;
>+ gbl->dev = pdata->dev;
>
> def_value = device_property_read_bool(dev, "default-on");
>
>diff --git a/include/linux/platform_data/gpio_backlight.h
>b/include/linux/platform_data/gpio_backlight.h
>index 1a8b5b1946fe..323fbf5f7613 100644
>--- a/include/linux/platform_data/gpio_backlight.h
>+++ b/include/linux/platform_data/gpio_backlight.h
>@@ -8,7 +8,7 @@
> struct device;
>
> struct gpio_backlight_platform_data {
>- struct device *fbdev;
>+ struct device *dev;
> };
>
> #endif
>--
>2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-05 20:19 ` Ruhl, Michael J
@ 2023-06-05 20:23 ` Sam Ravnborg
2023-06-05 20:41 ` Ruhl, Michael J
2023-06-06 7:24 ` Thomas Zimmermann
1 sibling, 1 reply; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-05 20:23 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Thomas Zimmermann, daniel, javierm, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, Rich Felker, linux-sh,
linux-staging, dri-devel, John Paul Adrian Glaubitz, linux-omap
Hi Michael.
> >
> >Fixes a bug in the backlight driver and prepares fbdev for making
> >struct fb_info.dev optional.
>
> I only see a rename from fbdev to dev...
>
> Is there missing code?
>
> Would a fixes: be useful?
>
> M
>
> >@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
> >backlight_device *bl,
> > {
> > struct gpio_backlight *gbl = bl_get_data(bl);
> >
> >- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
> >+ return !gbl->dev || gbl->dev == info->device;
> > }
The real change is here where info->dev is replaced by info->device.
Sam
^ permalink raw reply [flat|nested] 99+ messages in thread
* RE: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-05 20:23 ` Sam Ravnborg
@ 2023-06-05 20:41 ` Ruhl, Michael J
0 siblings, 0 replies; 99+ messages in thread
From: Ruhl, Michael J @ 2023-06-05 20:41 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Thomas Zimmermann, daniel, javierm, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, Rich Felker, linux-sh,
linux-staging, dri-devel, John Paul Adrian Glaubitz, linux-omap
>-----Original Message-----
>From: Sam Ravnborg <sam@ravnborg.org>
>Sent: Monday, June 5, 2023 4:23 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: Thomas Zimmermann <tzimmermann@suse.de>; daniel@ffwll.ch;
>javierm@redhat.com; deller@gmx.de; geert+renesas@glider.be;
>lee@kernel.org; daniel.thompson@linaro.org; jingoohan1@gmail.com; linux-
>fbdev@vger.kernel.org; Rich Felker <dalias@libc.org>; linux-
>sh@vger.kernel.org; linux-staging@lists.linux.dev; dri-
>devel@lists.freedesktop.org; John Paul Adrian Glaubitz <glaubitz@physik.fu-
>berlin.de>; linux-omap@vger.kernel.org
>Subject: Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>fb_info.device
>
>Hi Michael.
>
>> >
>> >Fixes a bug in the backlight driver and prepares fbdev for making
>> >struct fb_info.dev optional.
>>
>> I only see a rename from fbdev to dev...
>>
>> Is there missing code?
>>
>> Would a fixes: be useful?
>>
>> M
>>
>> >@@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
>> >backlight_device *bl,
>> > {
>> > struct gpio_backlight *gbl = bl_get_data(bl);
>> >
>> >- return gbl->fbdev == NULL || gbl->fbdev == info->dev;
>> >+ return !gbl->dev || gbl->dev == info->device;
>> > }
>
>The real change is here where info->dev is replaced by info->device.
Yeah, after a few patches, I was getting the idea that the name was the bug. 😊
Thanks,
M
> Sam
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
@ 2023-06-05 21:35 ` kernel test robot
2023-06-07 20:48 ` Sam Ravnborg
2023-06-07 22:28 ` Javier Martinez Canillas
2 siblings, 0 replies; 99+ messages in thread
From: kernel test robot @ 2023-06-05 21:35 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1
Cc: oe-kbuild-all, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging, Thomas Zimmermann
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20230605]
[cannot apply to drm-misc/drm-misc-next lee-backlight/for-backlight-next staging/staging-testing staging/staging-next staging/staging-linus linus/master lee-backlight/for-backlight-fixes v6.4-rc5 v6.4-rc4 v6.4-rc3 v6.4-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/backlight-bd6107-Compare-against-struct-fb_info-device/20230605-225002
base: next-20230605
patch link: https://lore.kernel.org/r/20230605144812.15241-29-tzimmermann%40suse.de
patch subject: [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
config: sparc-allyesconfig (https://download.01.org/0day-ci/archive/20230606/202306060527.syH2D4Is-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 12.3.0
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/34fb1357f6464f1173e12cd241310efa5577dd79
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Thomas-Zimmermann/backlight-bd6107-Compare-against-struct-fb_info-device/20230605-225002
git checkout 34fb1357f6464f1173e12cd241310efa5577dd79
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=sparc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=sparc SHELL=/bin/bash drivers/video/fbdev/core/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306060527.syH2D4Is-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/video/fbdev/core/fb_devfs.c:174:9: error: unknown type name 'compat_caddr_t'
174 | compat_caddr_t smem_start;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:183:9: error: unknown type name 'compat_caddr_t'
183 | compat_caddr_t mmio_start;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:192:9: error: unknown type name 'compat_caddr_t'
192 | compat_caddr_t red;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:193:9: error: unknown type name 'compat_caddr_t'
193 | compat_caddr_t green;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:194:9: error: unknown type name 'compat_caddr_t'
194 | compat_caddr_t blue;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:195:9: error: unknown type name 'compat_caddr_t'
195 | compat_caddr_t transp;
| ^~~~~~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c: In function 'fb_getput_cmap':
drivers/video/fbdev/core/fb_devfs.c:205:37: error: implicit declaration of function 'compat_ptr' [-Werror=implicit-function-declaration]
205 | if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
| ^~~~~~~~~~
>> drivers/video/fbdev/core/fb_devfs.c:205:37: warning: passing argument 2 of 'copy_from_user' makes pointer from integer without a cast [-Wint-conversion]
205 | if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
| ^~~~~~~~~~~~~~~
| |
| int
In file included from include/linux/sched/task.h:11,
from include/linux/sched/signal.h:9,
from include/linux/rcuwait.h:6,
from include/linux/percpu-rwsem.h:7,
from include/linux/fs.h:33,
from include/linux/huge_mm.h:8,
from include/linux/mm.h:989,
from include/linux/kallsyms.h:13,
from include/linux/ftrace.h:13,
from include/linux/kprobes.h:28,
from include/linux/kgdb.h:19,
from include/linux/fb.h:6,
from drivers/video/fbdev/core/fb_devfs.c:4:
include/linux/uaccess.h:180:45: note: expected 'const void *' but argument is of type 'int'
180 | copy_from_user(void *to, const void __user *from, unsigned long n)
| ~~~~~~~~~~~~~~~~~~~^~~~
>> drivers/video/fbdev/core/fb_devfs.c:211:27: warning: initialization of '__u16 *' {aka 'short unsigned int *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
211 | .red = compat_ptr(cmap32.red),
| ^~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:211:27: note: (near initialization for '(anonymous).red')
drivers/video/fbdev/core/fb_devfs.c:212:27: warning: initialization of '__u16 *' {aka 'short unsigned int *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
212 | .green = compat_ptr(cmap32.green),
| ^~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:212:27: note: (near initialization for '(anonymous).green')
drivers/video/fbdev/core/fb_devfs.c:213:27: warning: initialization of '__u16 *' {aka 'short unsigned int *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
213 | .blue = compat_ptr(cmap32.blue),
| ^~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:213:27: note: (near initialization for '(anonymous).blue')
drivers/video/fbdev/core/fb_devfs.c:214:27: warning: initialization of '__u16 *' {aka 'short unsigned int *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
214 | .transp = compat_ptr(cmap32.transp),
| ^~~~~~~~~~
drivers/video/fbdev/core/fb_devfs.c:214:27: note: (near initialization for '(anonymous).transp')
drivers/video/fbdev/core/fb_devfs.c: In function 'fb_get_fscreeninfo':
>> drivers/video/fbdev/core/fb_devfs.c:270:45: warning: passing argument 2 of 'do_fscreeninfo_to_user' makes pointer from integer without a cast [-Wint-conversion]
270 | return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
| ^~~~~~~~~~~~~~~
| |
| int
drivers/video/fbdev/core/fb_devfs.c:228:70: note: expected 'struct fb_fix_screeninfo32 *' but argument is of type 'int'
228 | struct fb_fix_screeninfo32 __user *fix32)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
cc1: some warnings being treated as errors
vim +/copy_from_user +205 drivers/video/fbdev/core/fb_devfs.c
197
198 static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
199 unsigned long arg)
200 {
201 struct fb_cmap32 cmap32;
202 struct fb_cmap cmap_from;
203 struct fb_cmap_user cmap;
204
> 205 if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
206 return -EFAULT;
207
208 cmap = (struct fb_cmap_user) {
209 .start = cmap32.start,
210 .len = cmap32.len,
> 211 .red = compat_ptr(cmap32.red),
212 .green = compat_ptr(cmap32.green),
213 .blue = compat_ptr(cmap32.blue),
214 .transp = compat_ptr(cmap32.transp),
215 };
216
217 if (cmd == FBIOPUTCMAP)
218 return fb_set_user_cmap(&cmap, info);
219
220 lock_fb_info(info);
221 cmap_from = info->cmap;
222 unlock_fb_info(info);
223
224 return fb_cmap_to_user(&cmap_from, &cmap);
225 }
226
227 static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
228 struct fb_fix_screeninfo32 __user *fix32)
229 {
230 __u32 data;
231 int err;
232
233 err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
234
235 data = (__u32) (unsigned long) fix->smem_start;
236 err |= put_user(data, &fix32->smem_start);
237
238 err |= put_user(fix->smem_len, &fix32->smem_len);
239 err |= put_user(fix->type, &fix32->type);
240 err |= put_user(fix->type_aux, &fix32->type_aux);
241 err |= put_user(fix->visual, &fix32->visual);
242 err |= put_user(fix->xpanstep, &fix32->xpanstep);
243 err |= put_user(fix->ypanstep, &fix32->ypanstep);
244 err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
245 err |= put_user(fix->line_length, &fix32->line_length);
246
247 data = (__u32) (unsigned long) fix->mmio_start;
248 err |= put_user(data, &fix32->mmio_start);
249
250 err |= put_user(fix->mmio_len, &fix32->mmio_len);
251 err |= put_user(fix->accel, &fix32->accel);
252 err |= copy_to_user(fix32->reserved, fix->reserved,
253 sizeof(fix->reserved));
254
255 if (err)
256 return -EFAULT;
257 return 0;
258 }
259
260 static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
261 unsigned long arg)
262 {
263 struct fb_fix_screeninfo fix;
264
265 lock_fb_info(info);
266 fix = info->fix;
267 if (info->flags & FBINFO_HIDE_SMEM_START)
268 fix.smem_start = 0;
269 unlock_fb_info(info);
> 270 return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
271 }
272
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
2023-06-05 15:03 ` Greg KH
@ 2023-06-05 21:45 ` kernel test robot
2023-06-07 8:48 ` Geert Uytterhoeven
2023-06-11 16:37 ` Sam Ravnborg
3 siblings, 0 replies; 99+ messages in thread
From: kernel test robot @ 2023-06-05 21:45 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1
Cc: llvm, oe-kbuild-all, linux-fbdev, linux-sh, linux-staging,
dri-devel, Thomas Zimmermann, linux-omap
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20230605]
[cannot apply to drm-misc/drm-misc-next lee-backlight/for-backlight-next staging/staging-testing staging/staging-next staging/staging-linus linus/master lee-backlight/for-backlight-fixes v6.4-rc5 v6.4-rc4 v6.4-rc3 v6.4-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/backlight-bd6107-Compare-against-struct-fb_info-device/20230605-225002
base: next-20230605
patch link: https://lore.kernel.org/r/20230605144812.15241-31-tzimmermann%40suse.de
patch subject: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
config: powerpc-randconfig-r036-20230605 (https://download.01.org/0day-ci/archive/20230606/202306060547.528pADrX-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 4faf3aaf28226a4e950c103a14f6fc1d1fdabb1b)
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# https://github.com/intel-lab-lkp/linux/commit/d309f36af8a1ee56ef56e54287ca6d2bf7d239de
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Thomas-Zimmermann/backlight-bd6107-Compare-against-struct-fb_info-device/20230605-225002
git checkout d309f36af8a1ee56ef56e54287ca6d2bf7d239de
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1 O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/video/fbdev/mb862xx/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306060547.528pADrX-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c:793:15: error: no member named 'dev' in 'struct fb_info'
dev_dbg(fbi->dev, "%s release\n", fbi->fix.id);
~~~ ^
include/linux/dev_printk.h:163:26: note: expanded from macro 'dev_dbg'
dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
^~~
include/linux/dev_printk.h:129:22: note: expanded from macro 'dev_printk'
_dev_printk(level, dev, fmt, ##__VA_ARGS__); \
^~~
1 error generated.
vim +793 drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 785
3a2ab02ddfacb0 drivers/video/fbdev/mb862xx/mb862xxfbdrv.c Uwe Kleine-König 2023-03-19 786 static void of_platform_mb862xx_remove(struct platform_device *ofdev)
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 787 {
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 788 struct fb_info *fbi = dev_get_drvdata(&ofdev->dev);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 789 struct mb862xxfb_par *par = fbi->par;
28f65c11f2ffb3 drivers/video/mb862xx/mb862xxfbdrv.c Joe Perches 2011-06-09 790 resource_size_t res_size = resource_size(par->res);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 791 unsigned long reg;
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 792
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 @793 dev_dbg(fbi->dev, "%s release\n", fbi->fix.id);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 794
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 795 /* display off */
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 796 reg = inreg(disp, GC_DCM1);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 797 reg &= ~(GC_DCM01_DEN | GC_DCM01_L0E);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 798 outreg(disp, GC_DCM1, reg);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 799
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 800 /* disable interrupts */
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 801 outreg(host, GC_IMASK, 0);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 802
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 803 free_irq(par->irq, (void *)par);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 804 irq_dispose_mapping(par->irq);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 805
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 806 device_remove_file(&ofdev->dev, &dev_attr_dispregs);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 807
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 808 unregister_framebuffer(fbi);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 809 fb_dealloc_cmap(&fbi->cmap);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 810
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 811 iounmap(par->mmio_base);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 812 iounmap(par->fb_base);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 813
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 814 release_mem_region(par->res->start, res_size);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 815 framebuffer_release(fbi);
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 816 }
17a1217e12d8c8 drivers/video/mb862xx/mb862xxfb.c Anatolij Gustschin 2008-11-06 817
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann
@ 2023-06-06 5:26 ` Dan Carpenter
2023-06-07 9:00 ` Javier Martinez Canillas
1 sibling, 0 replies; 99+ messages in thread
From: Dan Carpenter @ 2023-06-06 5:26 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, dri-devel, linux-sh,
linux-omap, linux-staging
On Mon, Jun 05, 2023 at 04:47:53PM +0200, Thomas Zimmermann wrote:
> Do not assing the Linux device to struct fb_info.dev. The call to
> register_framebuffer() initializes the field to the fbdev device.
> Drivers should not override its value.
>
> Fixes a bug where the driver incorrectly decreases the hardware
> device's reference counter and leaks the fbdev device.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 88017bda96a5 ("ep93xx video driver")
regards,
dan carpenter
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent
2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-06 5:28 ` Dan Carpenter
2023-06-06 7:30 ` Thomas Zimmermann
2023-06-07 9:10 ` Javier Martinez Canillas
1 sibling, 1 reply; 99+ messages in thread
From: Dan Carpenter @ 2023-06-06 5:28 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, dri-devel, linux-sh,
linux-omap, linux-staging
On Mon, Jun 05, 2023 at 04:48:00PM +0200, Thomas Zimmermann wrote:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Benjamin Herrenschmidt <benh@kernel.crashing.org>
You left out the Cc:
regards,
dan carpenter
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-05 20:19 ` Ruhl, Michael J
2023-06-05 20:23 ` Sam Ravnborg
@ 2023-06-06 7:24 ` Thomas Zimmermann
2023-06-06 7:49 ` Dan Carpenter
1 sibling, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-06 7:24 UTC (permalink / raw)
To: Ruhl, Michael J, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1
Cc: linux-fbdev, Rich Felker, linux-sh, linux-staging, dri-devel,
John Paul Adrian Glaubitz, linux-omap
[-- Attachment #1.1: Type: text/plain, Size: 4549 bytes --]
Hi
Am 05.06.23 um 22:19 schrieb Ruhl, Michael J:
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>> Thomas Zimmermann
>> Sent: Monday, June 5, 2023 10:48 AM
>> To: daniel@ffwll.ch; javierm@redhat.com; sam@ravnborg.org;
>> deller@gmx.de; geert+renesas@glider.be; lee@kernel.org;
>> daniel.thompson@linaro.org; jingoohan1@gmail.com
>> Cc: linux-fbdev@vger.kernel.org; Rich Felker <dalias@libc.org>; linux-
>> sh@vger.kernel.org; linux-staging@lists.linux.dev; dri-
>> devel@lists.freedesktop.org; Thomas Zimmermann
>> <tzimmermann@suse.de>; John Paul Adrian Glaubitz <glaubitz@physik.fu-
>> berlin.de>; linux-omap@vger.kernel.org
>> Subject: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>> fb_info.device
>>
>> Struct gpio_backlight_platform_data refers to a platform device within
>> the Linux device hierarchy. The test in gpio_backlight_check_fb()
>> compares it against the fbdev device in struct fb_info.dev, which
>> is different. Fix the test by comparing to struct fb_info.device.
>>
>> Fixes a bug in the backlight driver and prepares fbdev for making
>> struct fb_info.dev optional.
>
> I only see a rename from fbdev to dev...
>
> Is there missing code?
As Sam said, the compare operation used the wrong device from fb_info.
I also changed the naming of a few fields in these backlight drivers. I
could move these renames into a separate patch if that makes things
easier for reviewers.
>
> Would a fixes: be useful?
That would be commit 8b770e3c9824 ("backlight: Add GPIO-based backlight
driver") from 2013. Maybe a bit old already, but I can surely add it.
Best regards
Thomas
>
> M
>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Rich Felker <dalias@libc.org>
>> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>> Cc: Lee Jones <lee@kernel.org>
>> Cc: Daniel Thompson <daniel.thompson@linaro.org>
>> Cc: Jingoo Han <jingoohan1@gmail.com>
>> Cc: linux-sh@vger.kernel.org
>> ---
>> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
>> drivers/video/backlight/gpio_backlight.c | 6 +++---
>> include/linux/platform_data/gpio_backlight.h | 2 +-
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-
>> ecovec24/setup.c
>> index 674da7ebd8b7..310513646c9b 100644
>> --- a/arch/sh/boards/mach-ecovec24/setup.c
>> +++ b/arch/sh/boards/mach-ecovec24/setup.c
>> @@ -386,7 +386,7 @@ static struct property_entry gpio_backlight_props[] = {
>> };
>>
>> static struct gpio_backlight_platform_data gpio_backlight_data = {
>> - .fbdev = &lcdc_device.dev,
>> + .dev = &lcdc_device.dev,
>> };
>>
>> static const struct platform_device_info gpio_backlight_device_info = {
>> diff --git a/drivers/video/backlight/gpio_backlight.c
>> b/drivers/video/backlight/gpio_backlight.c
>> index 6f78d928f054..d3bea42407f1 100644
>> --- a/drivers/video/backlight/gpio_backlight.c
>> +++ b/drivers/video/backlight/gpio_backlight.c
>> @@ -17,7 +17,7 @@
>> #include <linux/slab.h>
>>
>> struct gpio_backlight {
>> - struct device *fbdev;
>> + struct device *dev;
>> struct gpio_desc *gpiod;
>> };
>>
>> @@ -35,7 +35,7 @@ static int gpio_backlight_check_fb(struct
>> backlight_device *bl,
>> {
>> struct gpio_backlight *gbl = bl_get_data(bl);
>>
>> - return gbl->fbdev == NULL || gbl->fbdev == info->dev;
>> + return !gbl->dev || gbl->dev == info->device;
>> }
>>
>> static const struct backlight_ops gpio_backlight_ops = {
>> @@ -59,7 +59,7 @@ static int gpio_backlight_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>>
>> if (pdata)
>> - gbl->fbdev = pdata->fbdev;
>> + gbl->dev = pdata->dev;
>>
>> def_value = device_property_read_bool(dev, "default-on");
>>
>> diff --git a/include/linux/platform_data/gpio_backlight.h
>> b/include/linux/platform_data/gpio_backlight.h
>> index 1a8b5b1946fe..323fbf5f7613 100644
>> --- a/include/linux/platform_data/gpio_backlight.h
>> +++ b/include/linux/platform_data/gpio_backlight.h
>> @@ -8,7 +8,7 @@
>> struct device;
>>
>> struct gpio_backlight_platform_data {
>> - struct device *fbdev;
>> + struct device *dev;
>> };
>>
>> #endif
>> --
>> 2.40.1
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent
2023-06-06 5:28 ` Dan Carpenter
@ 2023-06-06 7:30 ` Thomas Zimmermann
0 siblings, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-06 7:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: daniel, javierm, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1, linux-fbdev, dri-devel, linux-sh,
linux-omap, linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 886 bytes --]
Hi
Am 06.06.23 um 07:28 schrieb Dan Carpenter:
> On Mon, Jun 05, 2023 at 04:48:00PM +0200, Thomas Zimmermann wrote:
>> Use the hardware device in struct fb_info.device as parent of the
>> backlight device. Aligns the driver with the rest of the codebase
>> and prepares fbdev for making struct fb_info.dev optional.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> You left out the Cc:
Indeed, thanks for reviewing. However I don't remember that checkpatch
warned about it. It's my impression that it should have. :/
Best regards
>
> regards,
> dan carpenter
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-06 7:24 ` Thomas Zimmermann
@ 2023-06-06 7:49 ` Dan Carpenter
2023-06-06 8:05 ` Thomas Zimmermann
0 siblings, 1 reply; 99+ messages in thread
From: Dan Carpenter @ 2023-06-06 7:49 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Ruhl, Michael J, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1, linux-fbdev, Rich Felker,
linux-sh, linux-staging, dri-devel, John Paul Adrian Glaubitz,
linux-omap
On Tue, Jun 06, 2023 at 09:24:48AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.06.23 um 22:19 schrieb Ruhl, Michael J:
> > > -----Original Message-----
> > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> > > Thomas Zimmermann
> > > Sent: Monday, June 5, 2023 10:48 AM
> > > To: daniel@ffwll.ch; javierm@redhat.com; sam@ravnborg.org;
> > > deller@gmx.de; geert+renesas@glider.be; lee@kernel.org;
> > > daniel.thompson@linaro.org; jingoohan1@gmail.com
> > > Cc: linux-fbdev@vger.kernel.org; Rich Felker <dalias@libc.org>; linux-
> > > sh@vger.kernel.org; linux-staging@lists.linux.dev; dri-
> > > devel@lists.freedesktop.org; Thomas Zimmermann
> > > <tzimmermann@suse.de>; John Paul Adrian Glaubitz <glaubitz@physik.fu-
> > > berlin.de>; linux-omap@vger.kernel.org
> > > Subject: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
> > > fb_info.device
> > >
> > > Struct gpio_backlight_platform_data refers to a platform device within
> > > the Linux device hierarchy. The test in gpio_backlight_check_fb()
> > > compares it against the fbdev device in struct fb_info.dev, which
> > > is different. Fix the test by comparing to struct fb_info.device.
> > >
> > > Fixes a bug in the backlight driver and prepares fbdev for making
> > > struct fb_info.dev optional.
> >
> > I only see a rename from fbdev to dev...
> >
> > Is there missing code?
>
> As Sam said, the compare operation used the wrong device from fb_info.
>
> I also changed the naming of a few fields in these backlight drivers. I
> could move these renames into a separate patch if that makes things easier
> for reviewers.
>
> >
> > Would a fixes: be useful?
>
> That would be commit 8b770e3c9824 ("backlight: Add GPIO-based backlight
> driver") from 2013. Maybe a bit old already, but I can surely add it.
Don't add the Fixes tag to this one because it doesn't fix anything, it
just renames stuff. The real fix is later? To be honest, it was kind
of difficult to see where the actual fix was.
Fixes tags for old code is fine... I like to know why bugs are
introduced. Was it adding a feature or part of fix for something else
or a cleanup?
regards,
dan carpenter
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 02/30] backlight/gpio_backlight: Compare against struct fb_info.device
2023-06-06 7:49 ` Dan Carpenter
@ 2023-06-06 8:05 ` Thomas Zimmermann
0 siblings, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-06 8:05 UTC (permalink / raw)
To: Dan Carpenter
Cc: Ruhl, Michael J, daniel, javierm, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1, linux-fbdev, Rich Felker,
linux-sh, linux-staging, dri-devel, John Paul Adrian Glaubitz,
linux-omap
[-- Attachment #1.1: Type: text/plain, Size: 2721 bytes --]
Hi
Am 06.06.23 um 09:49 schrieb Dan Carpenter:
> On Tue, Jun 06, 2023 at 09:24:48AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 05.06.23 um 22:19 schrieb Ruhl, Michael J:
>>>> -----Original Message-----
>>>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>>>> Thomas Zimmermann
>>>> Sent: Monday, June 5, 2023 10:48 AM
>>>> To: daniel@ffwll.ch; javierm@redhat.com; sam@ravnborg.org;
>>>> deller@gmx.de; geert+renesas@glider.be; lee@kernel.org;
>>>> daniel.thompson@linaro.org; jingoohan1@gmail.com
>>>> Cc: linux-fbdev@vger.kernel.org; Rich Felker <dalias@libc.org>; linux-
>>>> sh@vger.kernel.org; linux-staging@lists.linux.dev; dri-
>>>> devel@lists.freedesktop.org; Thomas Zimmermann
>>>> <tzimmermann@suse.de>; John Paul Adrian Glaubitz <glaubitz@physik.fu-
>>>> berlin.de>; linux-omap@vger.kernel.org
>>>> Subject: [PATCH 02/30] backlight/gpio_backlight: Compare against struct
>>>> fb_info.device
>>>>
>>>> Struct gpio_backlight_platform_data refers to a platform device within
>>>> the Linux device hierarchy. The test in gpio_backlight_check_fb()
>>>> compares it against the fbdev device in struct fb_info.dev, which
>>>> is different. Fix the test by comparing to struct fb_info.device.
>>>>
>>>> Fixes a bug in the backlight driver and prepares fbdev for making
>>>> struct fb_info.dev optional.
>>>
>>> I only see a rename from fbdev to dev...
>>>
>>> Is there missing code?
>>
>> As Sam said, the compare operation used the wrong device from fb_info.
>>
>> I also changed the naming of a few fields in these backlight drivers. I
>> could move these renames into a separate patch if that makes things easier
>> for reviewers.
>>
>>>
>>> Would a fixes: be useful?
>>
>> That would be commit 8b770e3c9824 ("backlight: Add GPIO-based backlight
>> driver") from 2013. Maybe a bit old already, but I can surely add it.
>
> Don't add the Fixes tag to this one because it doesn't fix anything, it
> just renames stuff. The real fix is later? To be honest, it was kind
> of difficult to see where the actual fix was.
>
> Fixes tags for old code is fine... I like to know why bugs are
> introduced. Was it adding a feature or part of fix for something else
> or a cleanup?
You're not the first to complain about the renaming. I'll split each
backlight patch into a bug-fix and a rename patch then. The bugfix will
get the Fixes tag.
Best regards
Thomas
>
> regards,
> dan carpenter
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
@ 2023-06-07 7:30 ` Javier Martinez Canillas
2023-06-07 7:34 ` Javier Martinez Canillas
1 sibling, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:30 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Lee Jones <lee@kernel.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
2023-06-07 7:30 ` Javier Martinez Canillas
@ 2023-06-07 7:34 ` Javier Martinez Canillas
1 sibling, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:34 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Lee Jones <lee@kernel.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> ---
I agree with what was discussed in this thread, the check fix and rename
could be split in separate patches to make it easier to understand what
is changed. Regardless, feel free to add:
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 03/30] backlight/lv5207lp: Compare against struct fb_info.device
2023-06-05 14:47 ` [PATCH 03/30] backlight/lv5207lp: " Thomas Zimmermann
@ 2023-06-07 7:35 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:35 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, Rich Felker, Yoshinori Sato, linux-sh,
linux-staging, dri-devel, Thomas Zimmermann,
John Paul Adrian Glaubitz, linux-omap
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Struct lv5207lp_platform_data refers to a platform device within
> the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 ` [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-07 7:36 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:36 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent
2023-06-05 14:47 ` [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-07 7:41 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:41 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 ` [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-07 7:42 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:42 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent
2023-06-05 14:47 ` [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-07 7:55 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:55 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device
2023-06-05 14:47 ` [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device Thomas Zimmermann
@ 2023-06-07 7:55 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 7:55 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, linux-sh, linux-staging, dri-devel,
Thomas Zimmermann, linux-omap
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Call device_remove_file() with the same device that has been used
> for device_create_file(), which is the hardware device stored in
> struct fb_info.device. Prepares fbdev for making struct fb_info.dev
> optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (29 preceding siblings ...)
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
@ 2023-06-07 8:35 ` Geert Uytterhoeven
2023-06-12 10:46 ` Thomas Zimmermann
2023-06-07 12:06 ` Markus Elfring
31 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-07 8:35 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, lee, daniel.thompson, jingoohan1,
linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging
Hi Thomas,
Thanks for your series!
Over the past few days, I have been giving this some thought, that's
why I am replying only now...
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Add the new config option FB_DEVICE. If enabled, fbdev provides
> traditional userspace interfaces in devfs, sysfs and procfs, such
> as /dev/fb0 or /proc/fb.
>
> Modern Linux distrobutions have adopted DRM drivers for graphics
> output and use fbdev only for the kernel's framebuffer console.
> Userspace has also moved on, with no new fbdev code being written
> and existing support being removed.
>
> OTOH, fbdev provides userspace a way of accessing kernel or I/O
> memory, which might compromise the system's security. See the recent
True, in some form...
The amount of "kernel memory" that can be accessed is controlled by
the fbdev driver (or by the DRM fbdev emulation). Nothing unsafe here.
The I/O memory that can be accessed (if any) is controlled by the
fbdev driver, and the full capabilities (e.g. DMA to random addresses)
exported depend on the actual hardware.
> commit c8687694bb1f ("drm/fbdev-generic: prohibit potential
> out-of-bounds access") for an example. Disabling fbdev userspace
IMHO that's not a good example for the point you're trying to make,
but merely bad bounds checking in kernel copying code...
> interfaces is therefore a useful feature to limit unecessary
> exposure of fbdev code to processes of low privilegues.
This actually depends on the permissions on /dev/fb*...
BTW, I am wondering if it would be possible to write a DRM emulation
layer on top of (basic, e.g. no MMIO, just fb) fbdev?
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from hardware device
2023-06-05 14:47 ` [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from " Thomas Zimmermann
@ 2023-06-07 8:47 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 8:47 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Pass the hardware device to the DMA helpers dma_alloc_wc(), dma_mmap_wc()
> and dma_free_coherent(). The fbdev device that is currently being used is
> a software device and does not provide DMA memory.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
2023-06-05 15:03 ` Greg KH
2023-06-05 21:45 ` kernel test robot
@ 2023-06-07 8:48 ` Geert Uytterhoeven
2023-06-07 15:15 ` Thomas Zimmermann
2023-06-11 16:37 ` Sam Ravnborg
3 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-07 8:48 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, lee, daniel.thompson, jingoohan1,
linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging
Hi Thomas,
Thanks for your patch!
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
> device optional. If the new option has not been selected, fbdev
> does not create a files in devfs or sysfs.
>
> Most modern Linux systems run a DRM-based graphics stack that uses
> the kernel's framebuffer console, but has otherwise deprecated fbdev
> support. Yet fbdev userspace interfaces are still present.
>
> The option makes it possible to use the fbdev subsystem as console
> implementation without support for userspace. This closes potential
> entry points to manipulate kernel or I/O memory via framebuffers. It
I'd leave out the part about manipulating kernel memory, as that's a
driver bug, if possible.
> also prevents the execution of driver code via ioctl or sysfs, both
> of which might allow malicious software to exploit bugs in the fbdev
> code.
Of course disabling ioctls reduces the attack surface, and this is not
limited to fbdev... ;-)
I'm wondering if it would be worthwhile to optionally provide a more
limited userspace API for real fbdev drivers:
1. No access to MMIO, only to the mapped frame buffer,
2. No driver-specific ioctls, only the standard ones.
> A small number of fbdev drivers require struct fbinfo.dev to be
> initialized, usually for the support of sysfs interface. Make these
> drivers depend on FB_DEVICE. They can later be fixed if necessary.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> combination with certain motherboards and monitors are known to
> suffer from this problem.
>
> +config FB_DEVICE
> + bool "Provide legacy /dev/fb* device"
Perhaps "default y if !DRM", although that does not help for a
mixed drm/fbdev kernel build?
Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
to be selected by both FB and DRM_FBDEV_EMULATION?
Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
> + depends on FB
> + help
> + Say Y here if you want the legacy /dev/fb* device file. It's
> + only required if you have userspace programs that depend on
> + fbdev for graphics output. This does not effect the framebuffer
affect
> + console.
> +
> config FB_DDC
> tristate
> depends on FB
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err()
2023-06-05 14:47 ` [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() Thomas Zimmermann
@ 2023-06-07 8:59 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 8:59 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_info() and fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann
2023-06-06 5:26 ` Dan Carpenter
@ 2023-06-07 9:00 ` Javier Martinez Canillas
1 sibling, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:00 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Do not assing the Linux device to struct fb_info.dev. The call to
> register_framebuffer() initializes the field to the fbdev device.
> Drivers should not override its value.
>
> Fixes a bug where the driver incorrectly decreases the hardware
> device's reference counter and leaks the fbdev device.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err()
2023-06-05 14:47 ` [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() Thomas Zimmermann
@ 2023-06-07 9:00 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:00 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Fix cases were output helpers are called with struct fb_info.dev.
> Use fb_dbg() and fb_err() instead. Prepares fbdev for making struct
> fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err()
2023-06-05 14:47 ` [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err() Thomas Zimmermann
@ 2023-06-07 9:01 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:01 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Replace the use of the fbdev software device, stored in struct
> fb_info.dev, with the hardware device from struct fb_info.device
> in load_waveform(). The device is only used for printing errors
> with dev_err().
>
> This change aligns load_waveform() with the rest of the driver and
> prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:47 ` [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-07 9:02 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:02 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Antonino Daplas <adaplas@gmail.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent
2023-06-05 14:47 ` [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-07 9:02 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:02 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Antonino Daplas <adaplas@gmail.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev
2023-06-05 14:47 ` [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev Thomas Zimmermann
@ 2023-06-07 9:09 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:09 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Do not assign the hardware device to struct fb_info.dev. The
> field references the fbdev software device, which is unrelated.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup
2023-06-05 14:47 ` [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup Thomas Zimmermann
@ 2023-06-07 9:09 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:09 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Benjamin Herrenschmidt
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the cleanup calls for both data
> structures. The init calls are already in the correct order.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent
2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-06 5:28 ` Dan Carpenter
@ 2023-06-07 9:10 ` Javier Martinez Canillas
1 sibling, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:10 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup
2023-06-05 14:48 ` [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
@ 2023-06-07 9:11 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:11 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, Antonino Daplas, linux-sh, linux-staging, dri-devel,
Thomas Zimmermann, linux-omap
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Antonino Daplas <adaplas@gmail.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent
2023-06-05 14:48 ` [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent Thomas Zimmermann
@ 2023-06-07 9:11 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:11 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Antonino Daplas
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Antonino Daplas <adaplas@gmail.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 21/30] fbdev/sm501fb: Output message with fb_err()
2023-06-05 14:48 ` [PATCH 21/30] fbdev/sm501fb: Output message with fb_err() Thomas Zimmermann
@ 2023-06-07 9:12 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 9:12 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, linux-sh, linux-staging, dri-devel,
Thomas Zimmermann, linux-omap
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Fix case were dev_err() is being called with struct fb_info.dev.
> Use fb_err() instead.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
` (30 preceding siblings ...)
2023-06-07 8:35 ` [PATCH 00/30] fbdev: Make userspace interfaces optional Geert Uytterhoeven
@ 2023-06-07 12:06 ` Markus Elfring
2023-06-07 12:21 ` Thomas Zimmermann
31 siblings, 1 reply; 99+ messages in thread
From: Markus Elfring @ 2023-06-07 12:06 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: dri-devel, linux-fbdev, linux-omap, linux-sh, linux-staging,
Daniel Thompson, Daniel Vetter, Geert Uytterhoeven, Helge Deller,
Javier Martinez Canillas, Jingoo Han, Lee Jones, Sam Ravnborg
> Modern Linux distrobutions have adopted DRM drivers for graphics
> output and use fbdev only for the kernel's framebuffer console.
Would you like to avoid a typo in subsequent cover letters?
Regards,
Markus
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
2023-06-07 12:06 ` Markus Elfring
@ 2023-06-07 12:21 ` Thomas Zimmermann
2023-06-07 14:08 ` Markus Elfring
0 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-07 12:21 UTC (permalink / raw)
To: Markus Elfring
Cc: dri-devel, linux-fbdev, linux-omap, linux-sh, linux-staging,
Daniel Thompson, Daniel Vetter, Geert Uytterhoeven, Helge Deller,
Javier Martinez Canillas, Jingoo Han, Lee Jones, Sam Ravnborg
[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]
Am 07.06.23 um 14:06 schrieb Markus Elfring:
>> Modern Linux distrobutions have adopted DRM drivers for graphics
>> output and use fbdev only for the kernel's framebuffer console.
>
> Would you like to avoid a typo in subsequent cover letters?
Ha! It says 'distrobutions'.
>
> Regards,
> Markus
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
2023-06-07 12:21 ` Thomas Zimmermann
@ 2023-06-07 14:08 ` Markus Elfring
0 siblings, 0 replies; 99+ messages in thread
From: Markus Elfring @ 2023-06-07 14:08 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: dri-devel, linux-fbdev, linux-omap, linux-sh, linux-staging,
Daniel Thompson, Daniel Vetter, Geert Uytterhoeven, Helge Deller,
Javier Martinez Canillas, Jingoo Han, Lee Jones, Sam Ravnborg
> Ha! It says 'distrobutions'.
Do you tend to prefer any distributions?
Regards,
Markus
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-07 8:48 ` Geert Uytterhoeven
@ 2023-06-07 15:15 ` Thomas Zimmermann
2023-06-07 15:24 ` Geert Uytterhoeven
0 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-07 15:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: daniel, javierm, sam, deller, lee, daniel.thompson, jingoohan1,
linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 4429 bytes --]
Hi
Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
> Hi Thomas,
>
> Thanks for your patch!
>
> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
>> device optional. If the new option has not been selected, fbdev
>> does not create a files in devfs or sysfs.
>>
>> Most modern Linux systems run a DRM-based graphics stack that uses
>> the kernel's framebuffer console, but has otherwise deprecated fbdev
>> support. Yet fbdev userspace interfaces are still present.
>>
>> The option makes it possible to use the fbdev subsystem as console
>> implementation without support for userspace. This closes potential
>> entry points to manipulate kernel or I/O memory via framebuffers. It
>
> I'd leave out the part about manipulating kernel memory, as that's a
> driver bug, if possible.
The driver/core distinction is somewhat fuzzy: the recent bug with OOB
access was introduced accidentally in shared helper code within DRM.
And whenever I want to modify the fbdev code, I have to start bugfixing
first. Just look at this patchset. A good number of the patches are
bugfixes. Driver or not, I no longer trust any of the fbdev code to get
anything right.
>
>> also prevents the execution of driver code via ioctl or sysfs, both
>> of which might allow malicious software to exploit bugs in the fbdev
>> code.
>
> Of course disabling ioctls reduces the attack surface, and this is not
> limited to fbdev... ;-)
Other subsystems should do the same where possible. The specific problem
with DRM-plus-fbdev is that the fbdev device doesn't provide any
additional value. It's too limited in functionality (even by fbdev
standards), a possible source for bugs, and today's userspace wants DRM
functionality.
>
> I'm wondering if it would be worthwhile to optionally provide a more
> limited userspace API for real fbdev drivers:
> 1. No access to MMIO, only to the mapped frame buffer,
> 2. No driver-specific ioctls, only the standard ones.
That issue is only relevant to fbdev drivers and would be a separate
patchset. My concern lies with the current distributions, which don't
need the fbdev device and shouldn't provide it for the given reasons.
>
>> A small number of fbdev drivers require struct fbinfo.dev to be
>> initialized, usually for the support of sysfs interface. Make these
>> drivers depend on FB_DEVICE. They can later be fixed if necessary.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>> combination with certain motherboards and monitors are known to
>> suffer from this problem.
>>
>> +config FB_DEVICE
>> + bool "Provide legacy /dev/fb* device"
>
> Perhaps "default y if !DRM", although that does not help for a
> mixed drm/fbdev kernel build?
We could simply set it to "default y". But OTOH is it worth making it a
default? Distributions will set it to the value they need/want. The very
few people that build their own kernels to get certain fbdev drivers
will certainly be able to enable the option by hand as well.
>
> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
> to be selected by both FB and DRM_FBDEV_EMULATION?
> Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
That wouldn't work. In Tumbleweed, we still have efifb and vesafb
enabled under certain conditions; merely for the kernel console. We'd
have to enable CONFIG_FB, which would bring back the device.
Best regards
Thomas
>
>> + depends on FB
>> + help
>> + Say Y here if you want the legacy /dev/fb* device file. It's
>> + only required if you have userspace programs that depend on
>> + fbdev for graphics output. This does not effect the framebuffer
>
> affect
>
>> + console.
>> +
>> config FB_DDC
>> tristate
>> depends on FB
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-07 15:15 ` Thomas Zimmermann
@ 2023-06-07 15:24 ` Geert Uytterhoeven
2023-06-07 23:07 ` Javier Martinez Canillas
0 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-07 15:24 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, sam, deller, lee, daniel.thompson, jingoohan1,
linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging
Hi Thomas,
On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
> > On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >> --- a/drivers/video/fbdev/Kconfig
> >> +++ b/drivers/video/fbdev/Kconfig
> >> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> >> combination with certain motherboards and monitors are known to
> >> suffer from this problem.
> >>
> >> +config FB_DEVICE
> >> + bool "Provide legacy /dev/fb* device"
> >
> > Perhaps "default y if !DRM", although that does not help for a
> > mixed drm/fbdev kernel build?
>
> We could simply set it to "default y". But OTOH is it worth making it a
> default? Distributions will set it to the value they need/want. The very
> few people that build their own kernels to get certain fbdev drivers
> will certainly be able to enable the option by hand as well.
Defaulting to "n" (the default) means causing regressions when these
few people use an existing defconfig.
> > Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
> > to be selected by both FB and DRM_FBDEV_EMULATION?
> > Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
>
> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
> enabled under certain conditions; merely for the kernel console. We'd
> have to enable CONFIG_FB, which would bring back the device.
"Default y" does not mean that you cannot disable FB_DEVICE, so
you are not forced to bring back the device?
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions
2023-06-05 14:48 ` [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions Thomas Zimmermann
@ 2023-06-07 19:25 ` Sam Ravnborg
0 siblings, 0 replies; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 19:25 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging, Rafael J. Wysocki, Pavel Machek, linux-pm
On Mon, Jun 05, 2023 at 04:48:06PM +0200, Thomas Zimmermann wrote:
> Pass the Linux device to pm_vt_switch_*() instead of the virtual
> fbdev device. Prepares fbdev for making struct fb_info.dev optional.
>
> The type of device that is passed to the PM functions does not matter
> much. It is only a token within the internal list of known devices.
> The PM functions do not refer to any of the device's properties or its
> type.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: linux-pm@vger.kernel.org
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbmem.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 329d16e49a90..f91ae7d4c94d 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1478,9 +1478,9 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> INIT_LIST_HEAD(&fb_info->modelist);
>
> if (fb_info->skip_vt_switch)
> - pm_vt_switch_required(fb_info->dev, false);
> + pm_vt_switch_required(fb_info->device, false);
> else
> - pm_vt_switch_required(fb_info->dev, true);
> + pm_vt_switch_required(fb_info->device, true);
>
> fb_var_to_videomode(&mode, &fb_info->var);
> fb_add_videomode(&mode, &fb_info->modelist);
> @@ -1520,7 +1520,7 @@ static void unlink_framebuffer(struct fb_info *fb_info)
>
> device_destroy(fb_class, MKDEV(FB_MAJOR, i));
>
> - pm_vt_switch_unregister(fb_info->dev);
> + pm_vt_switch_unregister(fb_info->device);
>
> unbind_console(fb_info);
>
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files
2023-06-05 14:48 ` [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files Thomas Zimmermann
@ 2023-06-07 19:38 ` Sam Ravnborg
2023-06-09 7:19 ` Thomas Zimmermann
0 siblings, 1 reply; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 19:38 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas,
On Mon, Jun 05, 2023 at 04:48:07PM +0200, Thomas Zimmermann wrote:
> Move framebuffer and backlight helpers into separate files. Leave
> fbsysfs.c to sysfs-related code. No functional changes.
>
> The framebuffer helpers are not in fbmem.c because they are under
> GPL-2.0-or-later copyright, while fbmem.c is GPL-2.0.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Some nits that you decide what to do with.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
I do not get why they are moved out in separate files.
I guess the picture will materialize later.
Sam
> ---
> drivers/video/fbdev/core/Makefile | 4 +-
> drivers/video/fbdev/core/fb_backlight.c | 32 +++++++
> drivers/video/fbdev/core/fb_info.c | 76 ++++++++++++++++
> drivers/video/fbdev/core/fbsysfs.c | 110 +-----------------------
> 4 files changed, 112 insertions(+), 110 deletions(-)
> create mode 100644 drivers/video/fbdev/core/fb_backlight.c
> create mode 100644 drivers/video/fbdev/core/fb_info.c
>
> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
> index 8f0060160ffb..eee3295bc225 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -1,7 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
> obj-$(CONFIG_FB) += fb.o
> -fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> +fb-y := fb_backlight.o \
> + fb_info.o \
> + fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
There is "+=" that can be used in Makefile, but people prefer '\' -
sigh!
> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
>
> diff --git a/drivers/video/fbdev/core/fb_backlight.c b/drivers/video/fbdev/core/fb_backlight.c
> new file mode 100644
> index 000000000000..feffe6c68039
> --- /dev/null
> +++ b/drivers/video/fbdev/core/fb_backlight.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
Hmm, can we change the license from 2.0 to 2.0-or-later without any
concern? I hope so.
> +
> +#include <linux/export.h>
> +#include <linux/fb.h>
#include <linux/mutex.h> - to avoid relying on indirect includes?
> +
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> +/*
> + * This function generates a linear backlight curve
> + *
> + * 0: off
> + * 1-7: min
> + * 8-127: linear from min to max
> + */
> +void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
> +{
> + unsigned int i, flat, count, range = (max - min);
> +
> + mutex_lock(&fb_info->bl_curve_mutex);
> +
> + fb_info->bl_curve[0] = off;
> +
> + for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
> + fb_info->bl_curve[flat] = min;
> +
> + count = FB_BACKLIGHT_LEVELS * 15 / 16;
> + for (i = 0; i < count; ++i)
> + fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
> +
> + mutex_unlock(&fb_info->bl_curve_mutex);
> +}
> +EXPORT_SYMBOL_GPL(fb_bl_default_curve);
> +#endif
> diff --git a/drivers/video/fbdev/core/fb_info.c b/drivers/video/fbdev/core/fb_info.c
> new file mode 100644
> index 000000000000..fb5b75009ee7
> --- /dev/null
> +++ b/drivers/video/fbdev/core/fb_info.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/export.h>
> +#include <linux/fb.h>
Same as above, consider including mutex.h
Also slab.h
> +
> +/**
> + * framebuffer_alloc - creates a new frame buffer info structure
> + *
> + * @size: size of driver private data, can be zero
> + * @dev: pointer to the device for this fb, this can be NULL
> + *
> + * Creates a new frame buffer info structure. Also reserves @size bytes
> + * for driver private data (info->par). info->par (if any) will be
> + * aligned to sizeof(long).
> + *
> + * Returns the new structure, or NULL if an error occurred.
> + *
> + */
> +struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
> +{
> +#define BYTES_PER_LONG (BITS_PER_LONG/8)
> +#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
> + int fb_info_size = sizeof(struct fb_info);
> + struct fb_info *info;
> + char *p;
> +
> + if (size)
> + fb_info_size += PADDING;
> +
> + p = kzalloc(fb_info_size + size, GFP_KERNEL);
> +
> + if (!p)
> + return NULL;
> +
> + info = (struct fb_info *) p;
> +
> + if (size)
> + info->par = p + fb_info_size;
> +
> + info->device = dev;
> + info->fbcon_rotate_hint = -1;
> +
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> + mutex_init(&info->bl_curve_mutex);
> +#endif
> +
> + return info;
> +#undef PADDING
> +#undef BYTES_PER_LONG
> +}
> +EXPORT_SYMBOL(framebuffer_alloc);
> +
> +/**
> + * framebuffer_release - marks the structure available for freeing
> + *
> + * @info: frame buffer info structure
> + *
> + * Drop the reference count of the device embedded in the
> + * framebuffer info structure.
> + *
> + */
> +void framebuffer_release(struct fb_info *info)
> +{
> + if (!info)
> + return;
> +
> + if (WARN_ON(refcount_read(&info->count)))
> + return;
> +
> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> + mutex_destroy(&info->bl_curve_mutex);
> +#endif
> +
> + kfree(info);
> +}
> +EXPORT_SYMBOL(framebuffer_release);
> diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
> index 0c33c4adcd79..849073f1ca06 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -5,93 +5,12 @@
> * Copyright (c) 2004 James Simmons <jsimmons@infradead.org>
> */
>
> -/*
> - * Note: currently there's only stubs for framebuffer_alloc and
> - * framebuffer_release here. The reson for that is that until all drivers
> - * are converted to use it a sysfsification will open OOPSable races.
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/slab.h>
> +#include <linux/console.h>
> #include <linux/fb.h>
> #include <linux/fbcon.h>
> -#include <linux/console.h>
> -#include <linux/module.h>
>
> #define FB_SYSFS_FLAG_ATTR 1
>
> -/**
> - * framebuffer_alloc - creates a new frame buffer info structure
> - *
> - * @size: size of driver private data, can be zero
> - * @dev: pointer to the device for this fb, this can be NULL
> - *
> - * Creates a new frame buffer info structure. Also reserves @size bytes
> - * for driver private data (info->par). info->par (if any) will be
> - * aligned to sizeof(long).
> - *
> - * Returns the new structure, or NULL if an error occurred.
> - *
> - */
> -struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
> -{
> -#define BYTES_PER_LONG (BITS_PER_LONG/8)
> -#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
> - int fb_info_size = sizeof(struct fb_info);
> - struct fb_info *info;
> - char *p;
> -
> - if (size)
> - fb_info_size += PADDING;
> -
> - p = kzalloc(fb_info_size + size, GFP_KERNEL);
> -
> - if (!p)
> - return NULL;
> -
> - info = (struct fb_info *) p;
> -
> - if (size)
> - info->par = p + fb_info_size;
> -
> - info->device = dev;
> - info->fbcon_rotate_hint = -1;
> -
> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> - mutex_init(&info->bl_curve_mutex);
> -#endif
> -
> - return info;
> -#undef PADDING
> -#undef BYTES_PER_LONG
> -}
> -EXPORT_SYMBOL(framebuffer_alloc);
> -
> -/**
> - * framebuffer_release - marks the structure available for freeing
> - *
> - * @info: frame buffer info structure
> - *
> - * Drop the reference count of the device embedded in the
> - * framebuffer info structure.
> - *
> - */
> -void framebuffer_release(struct fb_info *info)
> -{
> - if (!info)
> - return;
> -
> - if (WARN_ON(refcount_read(&info->count)))
> - return;
> -
> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> - mutex_destroy(&info->bl_curve_mutex);
> -#endif
> -
> - kfree(info);
> -}
> -EXPORT_SYMBOL(framebuffer_release);
> -
> static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
> {
> int err;
> @@ -551,30 +470,3 @@ void fb_cleanup_device(struct fb_info *fb_info)
> fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
> }
> }
> -
> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
> -/* This function generates a linear backlight curve
> - *
> - * 0: off
> - * 1-7: min
> - * 8-127: linear from min to max
> - */
> -void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
> -{
> - unsigned int i, flat, count, range = (max - min);
> -
> - mutex_lock(&fb_info->bl_curve_mutex);
> -
> - fb_info->bl_curve[0] = off;
> -
> - for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
> - fb_info->bl_curve[flat] = min;
> -
> - count = FB_BACKLIGHT_LEVELS * 15 / 16;
> - for (i = 0; i < count; ++i)
> - fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
> -
> - mutex_unlock(&fb_info->bl_curve_mutex);
> -}
> -EXPORT_SYMBOL_GPL(fb_bl_default_curve);
> -#endif
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}()
2023-06-05 14:48 ` [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}() Thomas Zimmermann
@ 2023-06-07 19:45 ` Sam Ravnborg
0 siblings, 0 replies; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 19:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas,
On Mon, Jun 05, 2023 at 04:48:08PM +0200, Thomas Zimmermann wrote:
> Move the logic to create and destroy fbdev devices into the new
> helpers fb_device_create() and fb_device_destroy().
>
> There was a call to fb_cleanup_device() in do_unregister_framebuffer()
> that was too late. The device had already been removed at this point.
> Move the call into fb_device_destroy().
>
> Declare the helpers in the new internal header file fb_internal.h, as
s/ / /
> they are only used within the fbdev core module.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fb_internal.h | 12 ++++++++
> drivers/video/fbdev/core/fbmem.c | 21 +++-----------
> drivers/video/fbdev/core/fbsysfs.c | 38 ++++++++++++++++++++++++--
> include/linux/fb.h | 3 --
> 4 files changed, 52 insertions(+), 22 deletions(-)
> create mode 100644 drivers/video/fbdev/core/fb_internal.h
>
> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
> new file mode 100644
> index 000000000000..0b9640ae7a3d
> --- /dev/null
> +++ b/drivers/video/fbdev/core/fb_internal.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _FB_INTERNAL_H
> +#define _FB_INTERNAL_H
> +
> +struct fb_info;
> +
> +/* fbsysfs.c */
> +int fb_device_create(struct fb_info *fb_info);
> +void fb_device_destroy(struct fb_info *fb_info);
> +
> +#endif
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index f91ae7d4c94d..66532774d351 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -40,6 +40,8 @@
> #include <video/nomodeset.h>
> #include <video/vga.h>
>
> +#include "fb_internal.h"
> +
> /*
> * Frame buffer device initialization and setup routines
> */
> @@ -1447,14 +1449,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> mutex_init(&fb_info->lock);
> mutex_init(&fb_info->mm_lock);
>
> - fb_info->dev = device_create(fb_class, fb_info->device,
> - MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
> - if (IS_ERR(fb_info->dev)) {
> - /* Not fatal */
> - printk(KERN_WARNING "Unable to create device for framebuffer %d; errno = %ld\n", i, PTR_ERR(fb_info->dev));
> - fb_info->dev = NULL;
> - } else
> - fb_init_device(fb_info);
> + fb_device_create(fb_info);
The return result is ignored here.
If we do not need it in later patches then drop the return result.
>
> if (fb_info->pixmap.addr == NULL) {
> fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
> @@ -1515,16 +1510,9 @@ static void unlink_framebuffer(struct fb_info *fb_info)
> if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> return;
>
> - if (!fb_info->dev)
> - return;
> -
> - device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> -
> + fb_device_destroy(fb_info);
> pm_vt_switch_unregister(fb_info->device);
> -
> unbind_console(fb_info);
> -
> - fb_info->dev = NULL;
> }
>
> static void do_unregister_framebuffer(struct fb_info *fb_info)
> @@ -1539,7 +1527,6 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> fb_destroy_modelist(&fb_info->modelist);
> registered_fb[fb_info->node] = NULL;
> num_registered_fb--;
> - fb_cleanup_device(fb_info);
> #ifdef CONFIG_GUMSTIX_AM200EPD
> {
> struct fb_event event;
> diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
> index 849073f1ca06..fafe574398b0 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -8,6 +8,9 @@
> #include <linux/console.h>
> #include <linux/fb.h>
> #include <linux/fbcon.h>
> +#include <linux/major.h>
> +
> +#include "fb_internal.h"
>
> #define FB_SYSFS_FLAG_ATTR 1
>
> @@ -435,7 +438,7 @@ static struct device_attribute device_attrs[] = {
> #endif
> };
>
> -int fb_init_device(struct fb_info *fb_info)
> +static int fb_init_device(struct fb_info *fb_info)
> {
> int i, error = 0;
>
> @@ -459,7 +462,7 @@ int fb_init_device(struct fb_info *fb_info)
> return 0;
> }
>
> -void fb_cleanup_device(struct fb_info *fb_info)
> +static void fb_cleanup_device(struct fb_info *fb_info)
> {
> unsigned int i;
>
> @@ -470,3 +473,34 @@ void fb_cleanup_device(struct fb_info *fb_info)
> fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
> }
> }
> +
> +int fb_device_create(struct fb_info *fb_info)
> +{
> + int node = fb_info->node;
> + dev_t devt = MKDEV(FB_MAJOR, node);
> + int ret;
> +
> + fb_info->dev = device_create(fb_class, fb_info->device, devt, NULL, "fb%d", node);
> + if (IS_ERR(fb_info->dev)) {
> + /* Not fatal */
> + ret = PTR_ERR(fb_info->dev);
This error code is lost as we always return 0.
> + pr_warn("Unable to create device for framebuffer %d; error %d\n", node, ret);
> + fb_info->dev = NULL;
> + } else {
> + fb_init_device(fb_info);
> + }
> +
> + return 0;
> +}
> +
> +void fb_device_destroy(struct fb_info *fb_info)
> +{
> + dev_t devt = MKDEV(FB_MAJOR, fb_info->node);
> +
> + if (!fb_info->dev)
> + return;
> +
> + fb_cleanup_device(fb_info);
> + device_destroy(fb_class, devt);
> + fb_info->dev = NULL;
> +}
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ce6823e157e6..1988d11f78bc 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -735,11 +735,8 @@ static inline bool fb_be_math(struct fb_info *info)
> #endif /* CONFIG_FB_FOREIGN_ENDIAN */
> }
>
> -/* drivers/video/fbsysfs.c */
> extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
> extern void framebuffer_release(struct fb_info *info);
> -extern int fb_init_device(struct fb_info *fb_info);
> -extern void fb_cleanup_device(struct fb_info *head);
> extern void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max);
>
> /* drivers/video/fbmon.c */
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 27/30] fbdev/core: Move procfs code to separate file
2023-06-05 14:48 ` [PATCH 27/30] fbdev/core: Move procfs code to separate file Thomas Zimmermann
@ 2023-06-07 20:33 ` Sam Ravnborg
0 siblings, 0 replies; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 20:33 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas,
On Mon, Jun 05, 2023 at 04:48:09PM +0200, Thomas Zimmermann wrote:
> Move fbdev's procfs code into a separate file and contain it in
> init and cleanup helpers. No functional changes.
Maybe add:
Delete the unused for_each_registered_fb while touching the code.
The change to use proc_remove is not really documented.
But code looks ok.
I am not fan that we have introduced a few globals again.
But it looks like the way to go for now.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
With an improved changelog:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/Makefile | 1 +
> drivers/video/fbdev/core/fb_internal.h | 12 ++++-
> drivers/video/fbdev/core/fb_procfs.c | 62 ++++++++++++++++++++++++++
> drivers/video/fbdev/core/fbmem.c | 51 +++------------------
> 4 files changed, 80 insertions(+), 46 deletions(-)
> create mode 100644 drivers/video/fbdev/core/fb_procfs.c
>
> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
> index eee3295bc225..665320160f70 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
> obj-$(CONFIG_FB) += fb.o
> fb-y := fb_backlight.o \
> fb_info.o \
> + fb_procfs.o \
> fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
> index 0b9640ae7a3d..51f7c9f04e45 100644
> --- a/drivers/video/fbdev/core/fb_internal.h
> +++ b/drivers/video/fbdev/core/fb_internal.h
> @@ -3,7 +3,17 @@
> #ifndef _FB_INTERNAL_H
> #define _FB_INTERNAL_H
>
> -struct fb_info;
> +#include <linux/fb.h>
> +#include <linux/mutex.h>
> +
> +/* fbmem.c */
> +extern struct mutex registration_lock;
> +extern struct fb_info *registered_fb[FB_MAX];
> +extern int num_registered_fb;
> +
> +/* fb_procfs.c */
> +int fb_init_procfs(void);
> +void fb_cleanup_procfs(void);
>
> /* fbsysfs.c */
> int fb_device_create(struct fb_info *fb_info);
> diff --git a/drivers/video/fbdev/core/fb_procfs.c b/drivers/video/fbdev/core/fb_procfs.c
> new file mode 100644
> index 000000000000..59641142f8aa
> --- /dev/null
> +++ b/drivers/video/fbdev/core/fb_procfs.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/proc_fs.h>
> +
> +#include "fb_internal.h"
> +
> +static struct proc_dir_entry *fb_proc_dir_entry;
> +
> +static void *fb_seq_start(struct seq_file *m, loff_t *pos)
> +{
> + mutex_lock(®istration_lock);
> +
> + return (*pos < FB_MAX) ? pos : NULL;
> +}
> +
> +static void fb_seq_stop(struct seq_file *m, void *v)
> +{
> + mutex_unlock(®istration_lock);
> +}
> +
> +static void *fb_seq_next(struct seq_file *m, void *v, loff_t *pos)
> +{
> + (*pos)++;
> +
> + return (*pos < FB_MAX) ? pos : NULL;
> +}
> +
> +static int fb_seq_show(struct seq_file *m, void *v)
> +{
> + int i = *(loff_t *)v;
> + struct fb_info *fi = registered_fb[i];
> +
> + if (fi)
> + seq_printf(m, "%d %s\n", fi->node, fi->fix.id);
> +
> + return 0;
> +}
> +
> +static const struct seq_operations __maybe_unused fb_proc_seq_ops = {
> + .start = fb_seq_start,
> + .stop = fb_seq_stop,
> + .next = fb_seq_next,
> + .show = fb_seq_show,
> +};
> +
> +int fb_init_procfs(void)
> +{
> + struct proc_dir_entry *proc;
> +
> + proc = proc_create_seq("fb", 0, NULL, &fb_proc_seq_ops);
> + if (!proc)
> + return -ENOMEM;
> +
> + fb_proc_dir_entry = proc;
> +
> + return 0;
> +}
> +
> +void fb_cleanup_procfs(void)
> +{
> + proc_remove(fb_proc_dir_entry);
> +}
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 66532774d351..de1e45240161 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -24,9 +24,7 @@
> #include <linux/vt.h>
> #include <linux/init.h>
> #include <linux/linux_logo.h>
> -#include <linux/proc_fs.h>
> #include <linux/platform_device.h>
> -#include <linux/seq_file.h>
> #include <linux/console.h>
> #include <linux/kmod.h>
> #include <linux/err.h>
> @@ -48,13 +46,9 @@
>
> #define FBPIXMAPSIZE (1024 * 8)
>
> -static DEFINE_MUTEX(registration_lock);
> -
> +DEFINE_MUTEX(registration_lock);
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> int num_registered_fb __read_mostly;
> -#define for_each_registered_fb(i) \
> - for (i = 0; i < FB_MAX; i++) \
> - if (!registered_fb[i]) {} else
>
> bool fb_center_logo __read_mostly;
>
> @@ -705,40 +699,6 @@ int fb_show_logo(struct fb_info *info, int rotate) { return 0; }
> EXPORT_SYMBOL(fb_prepare_logo);
> EXPORT_SYMBOL(fb_show_logo);
>
> -static void *fb_seq_start(struct seq_file *m, loff_t *pos)
> -{
> - mutex_lock(®istration_lock);
> - return (*pos < FB_MAX) ? pos : NULL;
> -}
> -
> -static void *fb_seq_next(struct seq_file *m, void *v, loff_t *pos)
> -{
> - (*pos)++;
> - return (*pos < FB_MAX) ? pos : NULL;
> -}
> -
> -static void fb_seq_stop(struct seq_file *m, void *v)
> -{
> - mutex_unlock(®istration_lock);
> -}
> -
> -static int fb_seq_show(struct seq_file *m, void *v)
> -{
> - int i = *(loff_t *)v;
> - struct fb_info *fi = registered_fb[i];
> -
> - if (fi)
> - seq_printf(m, "%d %s\n", fi->node, fi->fix.id);
> - return 0;
> -}
> -
> -static const struct seq_operations __maybe_unused proc_fb_seq_ops = {
> - .start = fb_seq_start,
> - .next = fb_seq_next,
> - .stop = fb_seq_stop,
> - .show = fb_seq_show,
> -};
> -
> /*
> * We hold a reference to the fb_info in file->private_data,
> * but if the current registered fb has changed, we don't
> @@ -1624,8 +1584,9 @@ fbmem_init(void)
> {
> int ret;
>
> - if (!proc_create_seq("fb", 0, NULL, &proc_fb_seq_ops))
> - return -ENOMEM;
> + ret = fb_init_procfs();
> + if (ret)
> + return ret;
>
> ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
> if (ret) {
> @@ -1648,7 +1609,7 @@ fbmem_init(void)
> err_class:
> unregister_chrdev(FB_MAJOR, "fb");
> err_chrdev:
> - remove_proc_entry("fb", NULL);
> + fb_cleanup_procfs();
> return ret;
> }
>
> @@ -1659,7 +1620,7 @@ fbmem_exit(void)
> {
> fb_console_exit();
>
> - remove_proc_entry("fb", NULL);
> + fb_cleanup_procfs();
> class_destroy(fb_class);
> unregister_chrdev(FB_MAJOR, "fb");
> }
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
2023-06-05 21:35 ` kernel test robot
@ 2023-06-07 20:48 ` Sam Ravnborg
2023-06-12 10:35 ` Thomas Zimmermann
2023-06-07 22:28 ` Javier Martinez Canillas
2 siblings, 1 reply; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 20:48 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas.
On Mon, Jun 05, 2023 at 04:48:10PM +0200, Thomas Zimmermann wrote:
> Move fbdev's file-I/O code into a separate file and contain it in
> init and cleanup helpers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Consider moving the two helps as noted below.
With or without this move:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/Makefile | 1 +
> drivers/video/fbdev/core/fb_devfs.c | 484 +++++++++++++++++++++++++
> drivers/video/fbdev/core/fb_internal.h | 6 +
> drivers/video/fbdev/core/fbmem.c | 478 +-----------------------
> 4 files changed, 497 insertions(+), 472 deletions(-)
> create mode 100644 drivers/video/fbdev/core/fb_devfs.c
>
> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
> index 665320160f70..125d24f50c36 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
> obj-$(CONFIG_FB) += fb.o
> fb-y := fb_backlight.o \
> + fb_devfs.o \
> fb_info.o \
> fb_procfs.o \
> fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> diff --git a/drivers/video/fbdev/core/fb_devfs.c b/drivers/video/fbdev/core/fb_devfs.c
> new file mode 100644
> index 000000000000..5ab16cb24524
> --- /dev/null
> +++ b/drivers/video/fbdev/core/fb_devfs.c
devfs gives me another understanding of what this file is used for.
fb_ioctl.c?
> @@ -0,0 +1,484 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/console.h>
> +#include <linux/fb.h>
> +#include <linux/fbcon.h>
> +#include <linux/major.h>
> +
> +#include "fb_internal.h"
> +
> +/*
> + * We hold a reference to the fb_info in file->private_data,
> + * but if the current registered fb has changed, we don't
> + * actually want to use it.
> + *
> + * So look up the fb_info using the inode minor number,
> + * and just verify it against the reference we have.
> + */
> +static struct fb_info *file_fb_info(struct file *file)
> +{
> + struct inode *inode = file_inode(file);
> + int fbidx = iminor(inode);
> + struct fb_info *info = registered_fb[fbidx];
> +
> + if (info != file->private_data)
> + info = NULL;
> + return info;
> +}
> +
> +static ssize_t fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> +{
> + struct fb_info *info = file_fb_info(file);
> +
> + if (!info)
> + return -ENODEV;
> +
> + if (info->state != FBINFO_STATE_RUNNING)
> + return -EPERM;
> +
> + if (info->fbops->fb_read)
> + return info->fbops->fb_read(info, buf, count, ppos);
> +
> + return fb_io_read(info, buf, count, ppos);
> +}
> +
> +static ssize_t fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
> +{
> + struct fb_info *info = file_fb_info(file);
> +
> + if (!info)
> + return -ENODEV;
> +
> + if (info->state != FBINFO_STATE_RUNNING)
> + return -EPERM;
> +
> + if (info->fbops->fb_write)
> + return info->fbops->fb_write(info, buf, count, ppos);
> +
> + return fb_io_write(info, buf, count, ppos);
> +}
> +
> +static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
> + unsigned long arg)
> +{
> + const struct fb_ops *fb;
> + struct fb_var_screeninfo var;
> + struct fb_fix_screeninfo fix;
> + struct fb_cmap cmap_from;
> + struct fb_cmap_user cmap;
> + void __user *argp = (void __user *)arg;
> + long ret = 0;
> +
> + switch (cmd) {
> + case FBIOGET_VSCREENINFO:
> + lock_fb_info(info);
> + var = info->var;
> + unlock_fb_info(info);
> +
> + ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
> + break;
> + case FBIOPUT_VSCREENINFO:
> + if (copy_from_user(&var, argp, sizeof(var)))
> + return -EFAULT;
> + /* only for kernel-internal use */
> + var.activate &= ~FB_ACTIVATE_KD_TEXT;
> + console_lock();
> + lock_fb_info(info);
> + ret = fbcon_modechange_possible(info, &var);
> + if (!ret)
> + ret = fb_set_var(info, &var);
> + if (!ret)
> + fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
> + unlock_fb_info(info);
> + console_unlock();
> + if (!ret && copy_to_user(argp, &var, sizeof(var)))
> + ret = -EFAULT;
> + break;
> + case FBIOGET_FSCREENINFO:
> + lock_fb_info(info);
> + memcpy(&fix, &info->fix, sizeof(fix));
> + if (info->flags & FBINFO_HIDE_SMEM_START)
> + fix.smem_start = 0;
> + unlock_fb_info(info);
> +
> + ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
> + break;
> + case FBIOPUTCMAP:
> + if (copy_from_user(&cmap, argp, sizeof(cmap)))
> + return -EFAULT;
> + ret = fb_set_user_cmap(&cmap, info);
> + break;
> + case FBIOGETCMAP:
> + if (copy_from_user(&cmap, argp, sizeof(cmap)))
> + return -EFAULT;
> + lock_fb_info(info);
> + cmap_from = info->cmap;
> + unlock_fb_info(info);
> + ret = fb_cmap_to_user(&cmap_from, &cmap);
> + break;
> + case FBIOPAN_DISPLAY:
> + if (copy_from_user(&var, argp, sizeof(var)))
> + return -EFAULT;
> + console_lock();
> + lock_fb_info(info);
> + ret = fb_pan_display(info, &var);
> + unlock_fb_info(info);
> + console_unlock();
> + if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
> + return -EFAULT;
> + break;
> + case FBIO_CURSOR:
> + ret = -EINVAL;
> + break;
> + case FBIOGET_CON2FBMAP:
> + ret = fbcon_get_con2fb_map_ioctl(argp);
> + break;
> + case FBIOPUT_CON2FBMAP:
> + ret = fbcon_set_con2fb_map_ioctl(argp);
> + break;
> + case FBIOBLANK:
> + if (arg > FB_BLANK_POWERDOWN)
> + return -EINVAL;
> + console_lock();
> + lock_fb_info(info);
> + ret = fb_blank(info, arg);
> + /* might again call into fb_blank */
> + fbcon_fb_blanked(info, arg);
> + unlock_fb_info(info);
> + console_unlock();
> + break;
> + default:
> + lock_fb_info(info);
> + fb = info->fbops;
> + if (fb->fb_ioctl)
> + ret = fb->fb_ioctl(info, cmd, arg);
> + else
> + ret = -ENOTTY;
> + unlock_fb_info(info);
> + }
> + return ret;
> +}
> +
> +static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> + struct fb_info *info = file_fb_info(file);
> +
> + if (!info)
> + return -ENODEV;
> + return do_fb_ioctl(info, cmd, arg);
> +}
> +
> +#ifdef CONFIG_COMPAT
> +struct fb_fix_screeninfo32 {
> + char id[16];
> + compat_caddr_t smem_start;
> + u32 smem_len;
> + u32 type;
> + u32 type_aux;
> + u32 visual;
> + u16 xpanstep;
> + u16 ypanstep;
> + u16 ywrapstep;
> + u32 line_length;
> + compat_caddr_t mmio_start;
> + u32 mmio_len;
> + u32 accel;
> + u16 reserved[3];
> +};
> +
> +struct fb_cmap32 {
> + u32 start;
> + u32 len;
> + compat_caddr_t red;
> + compat_caddr_t green;
> + compat_caddr_t blue;
> + compat_caddr_t transp;
> +};
> +
> +static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct fb_cmap32 cmap32;
> + struct fb_cmap cmap_from;
> + struct fb_cmap_user cmap;
> +
> + if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
> + return -EFAULT;
> +
> + cmap = (struct fb_cmap_user) {
> + .start = cmap32.start,
> + .len = cmap32.len,
> + .red = compat_ptr(cmap32.red),
> + .green = compat_ptr(cmap32.green),
> + .blue = compat_ptr(cmap32.blue),
> + .transp = compat_ptr(cmap32.transp),
> + };
> +
> + if (cmd == FBIOPUTCMAP)
> + return fb_set_user_cmap(&cmap, info);
> +
> + lock_fb_info(info);
> + cmap_from = info->cmap;
> + unlock_fb_info(info);
> +
> + return fb_cmap_to_user(&cmap_from, &cmap);
> +}
> +
> +static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
> + struct fb_fix_screeninfo32 __user *fix32)
> +{
> + __u32 data;
> + int err;
> +
> + err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
> +
> + data = (__u32) (unsigned long) fix->smem_start;
> + err |= put_user(data, &fix32->smem_start);
> +
> + err |= put_user(fix->smem_len, &fix32->smem_len);
> + err |= put_user(fix->type, &fix32->type);
> + err |= put_user(fix->type_aux, &fix32->type_aux);
> + err |= put_user(fix->visual, &fix32->visual);
> + err |= put_user(fix->xpanstep, &fix32->xpanstep);
> + err |= put_user(fix->ypanstep, &fix32->ypanstep);
> + err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
> + err |= put_user(fix->line_length, &fix32->line_length);
> +
> + data = (__u32) (unsigned long) fix->mmio_start;
> + err |= put_user(data, &fix32->mmio_start);
> +
> + err |= put_user(fix->mmio_len, &fix32->mmio_len);
> + err |= put_user(fix->accel, &fix32->accel);
> + err |= copy_to_user(fix32->reserved, fix->reserved,
> + sizeof(fix->reserved));
> +
> + if (err)
> + return -EFAULT;
> + return 0;
> +}
> +
> +static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct fb_fix_screeninfo fix;
> +
> + lock_fb_info(info);
> + fix = info->fix;
> + if (info->flags & FBINFO_HIDE_SMEM_START)
> + fix.smem_start = 0;
> + unlock_fb_info(info);
> + return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
> +}
> +
> +static long fb_compat_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct fb_info *info = file_fb_info(file);
> + const struct fb_ops *fb;
> + long ret = -ENOIOCTLCMD;
> +
> + if (!info)
> + return -ENODEV;
> + fb = info->fbops;
> + switch (cmd) {
> + case FBIOGET_VSCREENINFO:
> + case FBIOPUT_VSCREENINFO:
> + case FBIOPAN_DISPLAY:
> + case FBIOGET_CON2FBMAP:
> + case FBIOPUT_CON2FBMAP:
> + arg = (unsigned long) compat_ptr(arg);
> + fallthrough;
> + case FBIOBLANK:
> + ret = do_fb_ioctl(info, cmd, arg);
> + break;
> +
> + case FBIOGET_FSCREENINFO:
> + ret = fb_get_fscreeninfo(info, cmd, arg);
> + break;
> +
> + case FBIOGETCMAP:
> + case FBIOPUTCMAP:
> + ret = fb_getput_cmap(info, cmd, arg);
> + break;
> +
> + default:
> + if (fb->fb_compat_ioctl)
> + ret = fb->fb_compat_ioctl(info, cmd, arg);
> + break;
> + }
> + return ret;
> +}
> +#endif
> +
> +static int fb_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct fb_info *info = file_fb_info(file);
> + unsigned long mmio_pgoff;
> + unsigned long start;
> + u32 len;
> +
> + if (!info)
> + return -ENODEV;
> + mutex_lock(&info->mm_lock);
> +
> + if (info->fbops->fb_mmap) {
> + int res;
> +
> + /*
> + * The framebuffer needs to be accessed decrypted, be sure
> + * SME protection is removed ahead of the call
> + */
> + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> + res = info->fbops->fb_mmap(info, vma);
> + mutex_unlock(&info->mm_lock);
> + return res;
> +#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
> + } else if (info->fbdefio) {
> + /*
> + * FB deferred I/O wants you to handle mmap in your drivers. At a
> + * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
> + */
> + dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
> + mutex_unlock(&info->mm_lock);
> + return -ENODEV;
> +#endif
> + }
> +
> + /*
> + * Ugh. This can be either the frame buffer mapping, or
> + * if pgoff points past it, the mmio mapping.
> + */
> + start = info->fix.smem_start;
> + len = info->fix.smem_len;
> + mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
> + if (vma->vm_pgoff >= mmio_pgoff) {
> + if (info->var.accel_flags) {
> + mutex_unlock(&info->mm_lock);
> + return -EINVAL;
> + }
> +
> + vma->vm_pgoff -= mmio_pgoff;
> + start = info->fix.mmio_start;
> + len = info->fix.mmio_len;
> + }
> + mutex_unlock(&info->mm_lock);
> +
> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> + fb_pgprotect(file, vma, start);
> +
> + return vm_iomap_memory(vma, start, len);
> +}
> +
> +static int fb_open(struct inode *inode, struct file *file)
> +__acquires(&info->lock)
> +__releases(&info->lock)
> +{
> + int fbidx = iminor(inode);
> + struct fb_info *info;
> + int res = 0;
> +
> + info = get_fb_info(fbidx);
> + if (!info) {
> + request_module("fb%d", fbidx);
> + info = get_fb_info(fbidx);
> + if (!info)
> + return -ENODEV;
> + }
> + if (IS_ERR(info))
> + return PTR_ERR(info);
> +
> + lock_fb_info(info);
> + if (!try_module_get(info->fbops->owner)) {
> + res = -ENODEV;
> + goto out;
> + }
> + file->private_data = info;
> + if (info->fbops->fb_open) {
> + res = info->fbops->fb_open(info, 1);
> + if (res)
> + module_put(info->fbops->owner);
> + }
> +#ifdef CONFIG_FB_DEFERRED_IO
> + if (info->fbdefio)
> + fb_deferred_io_open(info, inode, file);
> +#endif
> +out:
> + unlock_fb_info(info);
> + if (res)
> + put_fb_info(info);
> + return res;
> +}
> +
> +static int fb_release(struct inode *inode, struct file *file)
> +__acquires(&info->lock)
> +__releases(&info->lock)
> +{
> + struct fb_info * const info = file->private_data;
> +
> + lock_fb_info(info);
> +#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
> + if (info->fbdefio)
> + fb_deferred_io_release(info);
> +#endif
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 1);
> + module_put(info->fbops->owner);
> + unlock_fb_info(info);
> + put_fb_info(info);
> + return 0;
> +}
> +
> +#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
> +static unsigned long get_fb_unmapped_area(struct file *filp,
> + unsigned long addr, unsigned long len,
> + unsigned long pgoff, unsigned long flags)
> +{
> + struct fb_info * const info = filp->private_data;
> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> +
> + if (pgoff > fb_size || len > fb_size - pgoff)
> + return -EINVAL;
> +
> + return (unsigned long)info->screen_base + pgoff;
> +}
> +#endif
> +
> +static const struct file_operations fb_fops = {
> + .owner = THIS_MODULE,
> + .read = fb_read,
> + .write = fb_write,
> + .unlocked_ioctl = fb_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = fb_compat_ioctl,
> +#endif
> + .mmap = fb_mmap,
> + .open = fb_open,
> + .release = fb_release,
> +#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
> + (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
> + !defined(CONFIG_MMU))
> + .get_unmapped_area = get_fb_unmapped_area,
> +#endif
> +#ifdef CONFIG_FB_DEFERRED_IO
> + .fsync = fb_deferred_io_fsync,
> +#endif
> + .llseek = default_llseek,
> +};
> +
> +int fb_register_chrdev(void)
> +{
> + int ret;
> +
> + ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
> + if (ret) {
> + pr_err("Unable to get major %d for fb devs\n", FB_MAJOR);
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +void fb_unregister_chrdev(void)
> +{
> + unregister_chrdev(FB_MAJOR, "fb");
> +}
> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
> index 51f7c9f04e45..abe06c9da36e 100644
> --- a/drivers/video/fbdev/core/fb_internal.h
> +++ b/drivers/video/fbdev/core/fb_internal.h
> @@ -6,10 +6,16 @@
> #include <linux/fb.h>
> #include <linux/mutex.h>
>
> +/* fb_devfs.c */
> +int fb_register_chrdev(void);
> +void fb_unregister_chrdev(void);
> +
> /* fbmem.c */
> extern struct mutex registration_lock;
> extern struct fb_info *registered_fb[FB_MAX];
> extern int num_registered_fb;
> +struct fb_info *get_fb_info(unsigned int idx);
> +void put_fb_info(struct fb_info *fb_info);
The only users of get_fb_info() and put_fb_info() are now in fb_devfs.
So consider moving these two helpers too.
>
> /* fb_procfs.c */
> int fb_init_procfs(void);
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index de1e45240161..2d26ac46337b 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -17,7 +17,6 @@
> #include <linux/types.h>
> #include <linux/errno.h>
> #include <linux/kernel.h>
> -#include <linux/major.h>
> #include <linux/slab.h>
> #include <linux/mm.h>
> #include <linux/mman.h>
> @@ -54,7 +53,7 @@ bool fb_center_logo __read_mostly;
>
> int fb_logo_count __read_mostly = -1;
>
> -static struct fb_info *get_fb_info(unsigned int idx)
> +struct fb_info *get_fb_info(unsigned int idx)
> {
> struct fb_info *fb_info;
>
> @@ -70,7 +69,7 @@ static struct fb_info *get_fb_info(unsigned int idx)
> return fb_info;
> }
>
> -static void put_fb_info(struct fb_info *fb_info)
> +void put_fb_info(struct fb_info *fb_info)
> {
> if (!refcount_dec_and_test(&fb_info->count))
> return;
> @@ -699,59 +698,6 @@ int fb_show_logo(struct fb_info *info, int rotate) { return 0; }
> EXPORT_SYMBOL(fb_prepare_logo);
> EXPORT_SYMBOL(fb_show_logo);
Reminds me - consider moving logo stuff to a fb_logo file.
This would reduce fbmem with a lot of lines, and it is separate.
But it is outside the goal of this patchset.
>
> -/*
> - * We hold a reference to the fb_info in file->private_data,
> - * but if the current registered fb has changed, we don't
> - * actually want to use it.
> - *
> - * So look up the fb_info using the inode minor number,
> - * and just verify it against the reference we have.
> - */
> -static struct fb_info *file_fb_info(struct file *file)
> -{
> - struct inode *inode = file_inode(file);
> - int fbidx = iminor(inode);
> - struct fb_info *info = registered_fb[fbidx];
> -
> - if (info != file->private_data)
> - info = NULL;
> - return info;
> -}
> -
> -static ssize_t
> -fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> -{
> - struct fb_info *info = file_fb_info(file);
> -
> - if (!info)
> - return -ENODEV;
> -
> - if (info->state != FBINFO_STATE_RUNNING)
> - return -EPERM;
> -
> - if (info->fbops->fb_read)
> - return info->fbops->fb_read(info, buf, count, ppos);
> -
> - return fb_io_read(info, buf, count, ppos);
> -}
> -
> -static ssize_t
> -fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
> -{
> - struct fb_info *info = file_fb_info(file);
> -
> - if (!info)
> - return -ENODEV;
> -
> - if (info->state != FBINFO_STATE_RUNNING)
> - return -EPERM;
> -
> - if (info->fbops->fb_write)
> - return info->fbops->fb_write(info, buf, count, ppos);
> -
> - return fb_io_write(info, buf, count, ppos);
> -}
> -
> int
> fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var)
> {
> @@ -951,416 +897,6 @@ fb_blank(struct fb_info *info, int blank)
> }
> EXPORT_SYMBOL(fb_blank);
>
> -static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
> - unsigned long arg)
> -{
> - const struct fb_ops *fb;
> - struct fb_var_screeninfo var;
> - struct fb_fix_screeninfo fix;
> - struct fb_cmap cmap_from;
> - struct fb_cmap_user cmap;
> - void __user *argp = (void __user *)arg;
> - long ret = 0;
> -
> - switch (cmd) {
> - case FBIOGET_VSCREENINFO:
> - lock_fb_info(info);
> - var = info->var;
> - unlock_fb_info(info);
> -
> - ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
> - break;
> - case FBIOPUT_VSCREENINFO:
> - if (copy_from_user(&var, argp, sizeof(var)))
> - return -EFAULT;
> - /* only for kernel-internal use */
> - var.activate &= ~FB_ACTIVATE_KD_TEXT;
> - console_lock();
> - lock_fb_info(info);
> - ret = fbcon_modechange_possible(info, &var);
> - if (!ret)
> - ret = fb_set_var(info, &var);
> - if (!ret)
> - fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
> - unlock_fb_info(info);
> - console_unlock();
> - if (!ret && copy_to_user(argp, &var, sizeof(var)))
> - ret = -EFAULT;
> - break;
> - case FBIOGET_FSCREENINFO:
> - lock_fb_info(info);
> - memcpy(&fix, &info->fix, sizeof(fix));
> - if (info->flags & FBINFO_HIDE_SMEM_START)
> - fix.smem_start = 0;
> - unlock_fb_info(info);
> -
> - ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
> - break;
> - case FBIOPUTCMAP:
> - if (copy_from_user(&cmap, argp, sizeof(cmap)))
> - return -EFAULT;
> - ret = fb_set_user_cmap(&cmap, info);
> - break;
> - case FBIOGETCMAP:
> - if (copy_from_user(&cmap, argp, sizeof(cmap)))
> - return -EFAULT;
> - lock_fb_info(info);
> - cmap_from = info->cmap;
> - unlock_fb_info(info);
> - ret = fb_cmap_to_user(&cmap_from, &cmap);
> - break;
> - case FBIOPAN_DISPLAY:
> - if (copy_from_user(&var, argp, sizeof(var)))
> - return -EFAULT;
> - console_lock();
> - lock_fb_info(info);
> - ret = fb_pan_display(info, &var);
> - unlock_fb_info(info);
> - console_unlock();
> - if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
> - return -EFAULT;
> - break;
> - case FBIO_CURSOR:
> - ret = -EINVAL;
> - break;
> - case FBIOGET_CON2FBMAP:
> - ret = fbcon_get_con2fb_map_ioctl(argp);
> - break;
> - case FBIOPUT_CON2FBMAP:
> - ret = fbcon_set_con2fb_map_ioctl(argp);
> - break;
> - case FBIOBLANK:
> - if (arg > FB_BLANK_POWERDOWN)
> - return -EINVAL;
> - console_lock();
> - lock_fb_info(info);
> - ret = fb_blank(info, arg);
> - /* might again call into fb_blank */
> - fbcon_fb_blanked(info, arg);
> - unlock_fb_info(info);
> - console_unlock();
> - break;
> - default:
> - lock_fb_info(info);
> - fb = info->fbops;
> - if (fb->fb_ioctl)
> - ret = fb->fb_ioctl(info, cmd, arg);
> - else
> - ret = -ENOTTY;
> - unlock_fb_info(info);
> - }
> - return ret;
> -}
> -
> -static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> -{
> - struct fb_info *info = file_fb_info(file);
> -
> - if (!info)
> - return -ENODEV;
> - return do_fb_ioctl(info, cmd, arg);
> -}
> -
> -#ifdef CONFIG_COMPAT
> -struct fb_fix_screeninfo32 {
> - char id[16];
> - compat_caddr_t smem_start;
> - u32 smem_len;
> - u32 type;
> - u32 type_aux;
> - u32 visual;
> - u16 xpanstep;
> - u16 ypanstep;
> - u16 ywrapstep;
> - u32 line_length;
> - compat_caddr_t mmio_start;
> - u32 mmio_len;
> - u32 accel;
> - u16 reserved[3];
> -};
> -
> -struct fb_cmap32 {
> - u32 start;
> - u32 len;
> - compat_caddr_t red;
> - compat_caddr_t green;
> - compat_caddr_t blue;
> - compat_caddr_t transp;
> -};
> -
> -static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
> - unsigned long arg)
> -{
> - struct fb_cmap32 cmap32;
> - struct fb_cmap cmap_from;
> - struct fb_cmap_user cmap;
> -
> - if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
> - return -EFAULT;
> -
> - cmap = (struct fb_cmap_user) {
> - .start = cmap32.start,
> - .len = cmap32.len,
> - .red = compat_ptr(cmap32.red),
> - .green = compat_ptr(cmap32.green),
> - .blue = compat_ptr(cmap32.blue),
> - .transp = compat_ptr(cmap32.transp),
> - };
> -
> - if (cmd == FBIOPUTCMAP)
> - return fb_set_user_cmap(&cmap, info);
> -
> - lock_fb_info(info);
> - cmap_from = info->cmap;
> - unlock_fb_info(info);
> -
> - return fb_cmap_to_user(&cmap_from, &cmap);
> -}
> -
> -static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
> - struct fb_fix_screeninfo32 __user *fix32)
> -{
> - __u32 data;
> - int err;
> -
> - err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
> -
> - data = (__u32) (unsigned long) fix->smem_start;
> - err |= put_user(data, &fix32->smem_start);
> -
> - err |= put_user(fix->smem_len, &fix32->smem_len);
> - err |= put_user(fix->type, &fix32->type);
> - err |= put_user(fix->type_aux, &fix32->type_aux);
> - err |= put_user(fix->visual, &fix32->visual);
> - err |= put_user(fix->xpanstep, &fix32->xpanstep);
> - err |= put_user(fix->ypanstep, &fix32->ypanstep);
> - err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
> - err |= put_user(fix->line_length, &fix32->line_length);
> -
> - data = (__u32) (unsigned long) fix->mmio_start;
> - err |= put_user(data, &fix32->mmio_start);
> -
> - err |= put_user(fix->mmio_len, &fix32->mmio_len);
> - err |= put_user(fix->accel, &fix32->accel);
> - err |= copy_to_user(fix32->reserved, fix->reserved,
> - sizeof(fix->reserved));
> -
> - if (err)
> - return -EFAULT;
> - return 0;
> -}
> -
> -static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
> - unsigned long arg)
> -{
> - struct fb_fix_screeninfo fix;
> -
> - lock_fb_info(info);
> - fix = info->fix;
> - if (info->flags & FBINFO_HIDE_SMEM_START)
> - fix.smem_start = 0;
> - unlock_fb_info(info);
> - return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
> -}
> -
> -static long fb_compat_ioctl(struct file *file, unsigned int cmd,
> - unsigned long arg)
> -{
> - struct fb_info *info = file_fb_info(file);
> - const struct fb_ops *fb;
> - long ret = -ENOIOCTLCMD;
> -
> - if (!info)
> - return -ENODEV;
> - fb = info->fbops;
> - switch(cmd) {
> - case FBIOGET_VSCREENINFO:
> - case FBIOPUT_VSCREENINFO:
> - case FBIOPAN_DISPLAY:
> - case FBIOGET_CON2FBMAP:
> - case FBIOPUT_CON2FBMAP:
> - arg = (unsigned long) compat_ptr(arg);
> - fallthrough;
> - case FBIOBLANK:
> - ret = do_fb_ioctl(info, cmd, arg);
> - break;
> -
> - case FBIOGET_FSCREENINFO:
> - ret = fb_get_fscreeninfo(info, cmd, arg);
> - break;
> -
> - case FBIOGETCMAP:
> - case FBIOPUTCMAP:
> - ret = fb_getput_cmap(info, cmd, arg);
> - break;
> -
> - default:
> - if (fb->fb_compat_ioctl)
> - ret = fb->fb_compat_ioctl(info, cmd, arg);
> - break;
> - }
> - return ret;
> -}
> -#endif
> -
> -static int
> -fb_mmap(struct file *file, struct vm_area_struct * vma)
> -{
> - struct fb_info *info = file_fb_info(file);
> - unsigned long mmio_pgoff;
> - unsigned long start;
> - u32 len;
> -
> - if (!info)
> - return -ENODEV;
> - mutex_lock(&info->mm_lock);
> -
> - if (info->fbops->fb_mmap) {
> - int res;
> -
> - /*
> - * The framebuffer needs to be accessed decrypted, be sure
> - * SME protection is removed ahead of the call
> - */
> - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> - res = info->fbops->fb_mmap(info, vma);
> - mutex_unlock(&info->mm_lock);
> - return res;
> -#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
> - } else if (info->fbdefio) {
> - /*
> - * FB deferred I/O wants you to handle mmap in your drivers. At a
> - * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
> - */
> - dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
> - mutex_unlock(&info->mm_lock);
> - return -ENODEV;
> -#endif
> - }
> -
> - /*
> - * Ugh. This can be either the frame buffer mapping, or
> - * if pgoff points past it, the mmio mapping.
> - */
> - start = info->fix.smem_start;
> - len = info->fix.smem_len;
> - mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
> - if (vma->vm_pgoff >= mmio_pgoff) {
> - if (info->var.accel_flags) {
> - mutex_unlock(&info->mm_lock);
> - return -EINVAL;
> - }
> -
> - vma->vm_pgoff -= mmio_pgoff;
> - start = info->fix.mmio_start;
> - len = info->fix.mmio_len;
> - }
> - mutex_unlock(&info->mm_lock);
> -
> - vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> - fb_pgprotect(file, vma, start);
> -
> - return vm_iomap_memory(vma, start, len);
> -}
> -
> -static int
> -fb_open(struct inode *inode, struct file *file)
> -__acquires(&info->lock)
> -__releases(&info->lock)
> -{
> - int fbidx = iminor(inode);
> - struct fb_info *info;
> - int res = 0;
> -
> - info = get_fb_info(fbidx);
> - if (!info) {
> - request_module("fb%d", fbidx);
> - info = get_fb_info(fbidx);
> - if (!info)
> - return -ENODEV;
> - }
> - if (IS_ERR(info))
> - return PTR_ERR(info);
> -
> - lock_fb_info(info);
> - if (!try_module_get(info->fbops->owner)) {
> - res = -ENODEV;
> - goto out;
> - }
> - file->private_data = info;
> - if (info->fbops->fb_open) {
> - res = info->fbops->fb_open(info,1);
> - if (res)
> - module_put(info->fbops->owner);
> - }
> -#ifdef CONFIG_FB_DEFERRED_IO
> - if (info->fbdefio)
> - fb_deferred_io_open(info, inode, file);
> -#endif
> -out:
> - unlock_fb_info(info);
> - if (res)
> - put_fb_info(info);
> - return res;
> -}
> -
> -static int
> -fb_release(struct inode *inode, struct file *file)
> -__acquires(&info->lock)
> -__releases(&info->lock)
> -{
> - struct fb_info * const info = file->private_data;
> -
> - lock_fb_info(info);
> -#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
> - if (info->fbdefio)
> - fb_deferred_io_release(info);
> -#endif
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info,1);
> - module_put(info->fbops->owner);
> - unlock_fb_info(info);
> - put_fb_info(info);
> - return 0;
> -}
> -
> -#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
> -static unsigned long get_fb_unmapped_area(struct file *filp,
> - unsigned long addr, unsigned long len,
> - unsigned long pgoff, unsigned long flags)
> -{
> - struct fb_info * const info = filp->private_data;
> - unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> -
> - if (pgoff > fb_size || len > fb_size - pgoff)
> - return -EINVAL;
> -
> - return (unsigned long)info->screen_base + pgoff;
> -}
> -#endif
> -
> -static const struct file_operations fb_fops = {
> - .owner = THIS_MODULE,
> - .read = fb_read,
> - .write = fb_write,
> - .unlocked_ioctl = fb_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = fb_compat_ioctl,
> -#endif
> - .mmap = fb_mmap,
> - .open = fb_open,
> - .release = fb_release,
> -#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
> - (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
> - !defined(CONFIG_MMU))
> - .get_unmapped_area = get_fb_unmapped_area,
> -#endif
> -#ifdef CONFIG_FB_DEFERRED_IO
> - .fsync = fb_deferred_io_fsync,
> -#endif
> - .llseek = default_llseek,
> -};
> -
> struct class *fb_class;
> EXPORT_SYMBOL(fb_class);
>
> @@ -1588,11 +1124,9 @@ fbmem_init(void)
> if (ret)
> return ret;
>
> - ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
> - if (ret) {
> - printk("unable to get major %d for fb devs\n", FB_MAJOR);
> + ret = fb_register_chrdev();
> + if (ret)
> goto err_chrdev;
> - }
>
> fb_class = class_create("graphics");
> if (IS_ERR(fb_class)) {
> @@ -1607,7 +1141,7 @@ fbmem_init(void)
> return 0;
>
> err_class:
> - unregister_chrdev(FB_MAJOR, "fb");
> + fb_unregister_chrdev();
> err_chrdev:
> fb_cleanup_procfs();
> return ret;
> @@ -1622,7 +1156,7 @@ fbmem_exit(void)
>
> fb_cleanup_procfs();
> class_destroy(fb_class);
> - unregister_chrdev(FB_MAJOR, "fb");
> + fb_unregister_chrdev();
> }
>
> module_exit(fbmem_exit);
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 29/30] fbdev/core: Rework fb init code
2023-06-05 14:48 ` [PATCH 29/30] fbdev/core: Rework fb init code Thomas Zimmermann
@ 2023-06-07 20:51 ` Sam Ravnborg
0 siblings, 0 replies; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-07 20:51 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas.
On Mon, Jun 05, 2023 at 04:48:11PM +0200, Thomas Zimmermann wrote:
> Init the class "graphics" before the rest of fbdev. Later steps, such
> as the sysfs code, depend on the class. Also arrange the module's exit
> code in reverse order.
>
> Unexport the global variable fb_class, which is only shared internally
> within the fbdev core module.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fb_internal.h | 1 +
> drivers/video/fbdev/core/fbcon.c | 1 +
> drivers/video/fbdev/core/fbmem.c | 52 ++++++++++----------------
> include/linux/fb.h | 1 -
> 4 files changed, 22 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
> index abe06c9da36e..0b43c0cd5096 100644
> --- a/drivers/video/fbdev/core/fb_internal.h
> +++ b/drivers/video/fbdev/core/fb_internal.h
> @@ -11,6 +11,7 @@ int fb_register_chrdev(void);
> void fb_unregister_chrdev(void);
>
> /* fbmem.c */
> +extern struct class *fb_class;
> extern struct mutex registration_lock;
> extern struct fb_info *registered_fb[FB_MAX];
> extern int num_registered_fb;
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index c6c9d040bdec..8e76bc246b38 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -78,6 +78,7 @@
> #include <asm/irq.h>
>
> #include "fbcon.h"
> +#include "fb_internal.h"
>
> /*
> * FIXME: Locking
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 2d26ac46337b..b21b66017c01 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -45,6 +45,8 @@
>
> #define FBPIXMAPSIZE (1024 * 8)
>
> +struct class *fb_class;
> +
> DEFINE_MUTEX(registration_lock);
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> int num_registered_fb __read_mostly;
> @@ -897,9 +899,6 @@ fb_blank(struct fb_info *info, int blank)
> }
> EXPORT_SYMBOL(fb_blank);
>
> -struct class *fb_class;
> -EXPORT_SYMBOL(fb_class);
> -
> static int fb_check_foreignness(struct fb_info *fi)
> {
> const bool foreign_endian = fi->flags & FBINFO_FOREIGN_ENDIAN;
> @@ -1106,59 +1105,48 @@ void fb_set_suspend(struct fb_info *info, int state)
> }
> EXPORT_SYMBOL(fb_set_suspend);
>
> -/**
> - * fbmem_init - init frame buffer subsystem
> - *
> - * Initialize the frame buffer subsystem.
> - *
> - * NOTE: This function is _only_ to be called by drivers/char/mem.c.
> - *
> - */
> -
> -static int __init
> -fbmem_init(void)
> +static int __init fbmem_init(void)
> {
> int ret;
>
> + fb_class = class_create("graphics");
> + if (IS_ERR(fb_class)) {
> + ret = PTR_ERR(fb_class);
> + pr_err("Unable to create fb class; errno = %d\n", ret);
> + goto err_fb_class;
> + }
> +
> ret = fb_init_procfs();
> if (ret)
> - return ret;
> + goto err_class_destroy;
>
> ret = fb_register_chrdev();
> if (ret)
> - goto err_chrdev;
> -
> - fb_class = class_create("graphics");
> - if (IS_ERR(fb_class)) {
> - ret = PTR_ERR(fb_class);
> - pr_warn("Unable to create fb class; errno = %d\n", ret);
> - fb_class = NULL;
> - goto err_class;
> - }
> + goto err_fb_cleanup_procfs;
>
> fb_console_init();
>
> return 0;
>
> -err_class:
> - fb_unregister_chrdev();
> -err_chrdev:
> +err_fb_cleanup_procfs:
> fb_cleanup_procfs();
> +err_class_destroy:
> + class_destroy(fb_class);
> +err_fb_class:
> + fb_class = NULL;
> return ret;
> }
>
> #ifdef MODULE
> -module_init(fbmem_init);
> -static void __exit
> -fbmem_exit(void)
> +static void __exit fbmem_exit(void)
> {
> fb_console_exit();
> -
> + fb_unregister_chrdev();
> fb_cleanup_procfs();
> class_destroy(fb_class);
> - fb_unregister_chrdev();
> }
>
> +module_init(fbmem_init);
> module_exit(fbmem_exit);
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("Framebuffer base");
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 1988d11f78bc..541a0e3ce21f 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -609,7 +609,6 @@ extern int fb_new_modelist(struct fb_info *info);
>
> extern bool fb_center_logo;
> extern int fb_logo_count;
> -extern struct class *fb_class;
>
> static inline void lock_fb_info(struct fb_info *info)
> {
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount
2023-06-05 14:48 ` [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount Thomas Zimmermann
@ 2023-06-07 22:22 ` Javier Martinez Canillas
2023-06-12 10:19 ` Thomas Zimmermann
0 siblings, 1 reply; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 22:22 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann, Steve Glendinning
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Detect registered instances of fb_info by reading the reference
> counter from struct fb_info.read. Avoids looking at the dev field
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Steve Glendinning <steve.glendinning@shawell.net>
> ---
> drivers/video/fbdev/smscufx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
> index 17cec62cc65d..adb2b1fe8383 100644
> --- a/drivers/video/fbdev/smscufx.c
> +++ b/drivers/video/fbdev/smscufx.c
> @@ -1496,7 +1496,7 @@ static int ufx_setup_modes(struct ufx_data *dev, struct fb_info *info,
> u8 *edid;
> int i, result = 0, tries = 3;
>
> - if (info->dev) /* only use mutex if info has been registered */
> + if (refcount_read(&info->count)) /* only use mutex if info has been registered */
The struct fb_info .count refcount is protected by the registration_lock
mutex in register_framebuffer(). I think this operation isn't thread safe ?
But that was also the case for info->dev check, so I guess is OK and this
change is for an old fbdev driver anyways.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device
2023-06-05 14:48 ` [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device Thomas Zimmermann
@ 2023-06-07 22:23 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 22:23 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Use the 3dfx hardware device from the Linux device hierarchy as
> parent device of the i2c adapter. Aligns the driver with the rest
> of the codebase and prepares fbdev for making struct fb_info.dev
> optional.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
2023-06-05 21:35 ` kernel test robot
2023-06-07 20:48 ` Sam Ravnborg
@ 2023-06-07 22:28 ` Javier Martinez Canillas
2 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 22:28 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging,
Thomas Zimmermann
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Move fbdev's file-I/O code into a separate file and contain it in
> init and cleanup helpers. No functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
[...]
> +
> +#include <linux/console.h>
#include <linux/compat.h> here, the robot complained about:
drivers/video/fbdev/core/fb_devfs.c:183:9: error: unknown type name 'compat_caddr_t'
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-07 15:24 ` Geert Uytterhoeven
@ 2023-06-07 23:07 ` Javier Martinez Canillas
2023-06-09 7:09 ` Thomas Zimmermann
0 siblings, 1 reply; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-07 23:07 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Zimmermann
Cc: daniel.thompson, linux-staging, linux-sh, jingoohan1, deller,
lee, dri-devel, linux-fbdev, linux-omap, sam
Geert Uytterhoeven <geert@linux-m68k.org> writes:
Hello Geert and Thomas,
> Hi Thomas,
>
> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
>> > On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> >> --- a/drivers/video/fbdev/Kconfig
>> >> +++ b/drivers/video/fbdev/Kconfig
>> >> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>> >> combination with certain motherboards and monitors are known to
>> >> suffer from this problem.
>> >>
>> >> +config FB_DEVICE
>> >> + bool "Provide legacy /dev/fb* device"
>> >
>> > Perhaps "default y if !DRM", although that does not help for a
>> > mixed drm/fbdev kernel build?
>>
>> We could simply set it to "default y". But OTOH is it worth making it a
>> default? Distributions will set it to the value they need/want. The very
>> few people that build their own kernels to get certain fbdev drivers
>> will certainly be able to enable the option by hand as well.
>
> Defaulting to "n" (the default) means causing regressions when these
> few people use an existing defconfig.
>
Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
at least it won't silently be disabled for users that only want fbdev as
Geert mentioned.
I wouldn't call it a regression though, because AFAIK the Kconfig options
are not a stable API ?
>> > Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
>> > to be selected by both FB and DRM_FBDEV_EMULATION?
>> > Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
Funny that you mention because it's exactly what I attempted in the past:
https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u
>>
>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
>> enabled under certain conditions; merely for the kernel console. We'd
>> have to enable CONFIG_FB, which would bring back the device.
>
> "Default y" does not mean that you cannot disable FB_DEVICE, so
> you are not forced to bring back the device?
>
I think we can have both to make the kernel more configurable:
1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
which is what the series is doing with the new FB_DEVICE config symbol.
2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
emulation layer. That's what my series attempted to do with the FB_CORE
Kconfig symbol.
I believe that there are use cases for both, for example as Thomas' said
many distros are disabling all the fbdev drivers and their user-space only
requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.
But may be that other users want the opposite, they have an old user-space
that requires fbdev, but is running on newer hardware that only have a DRM
driver. So they will want DRM fbdev emulation but none fbdev driver at all.
That's why I think that FB_DEVICE and FB_CORE are complementary and we can
support any combination of the two, if you agree there are uses for either.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-07 23:07 ` Javier Martinez Canillas
@ 2023-06-09 7:09 ` Thomas Zimmermann
2023-06-09 7:29 ` Geert Uytterhoeven
0 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-09 7:09 UTC (permalink / raw)
To: Javier Martinez Canillas, Geert Uytterhoeven
Cc: daniel.thompson, linux-staging, linux-sh, jingoohan1, deller,
lee, dri-devel, linux-fbdev, linux-omap, sam
[-- Attachment #1.1: Type: text/plain, Size: 4991 bytes --]
Hi Geert and Javier
Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
> Hello Geert and Thomas,
>
>> Hi Thomas,
>>
>> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
>>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>> --- a/drivers/video/fbdev/Kconfig
>>>>> +++ b/drivers/video/fbdev/Kconfig
>>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>>>>> combination with certain motherboards and monitors are known to
>>>>> suffer from this problem.
>>>>>
>>>>> +config FB_DEVICE
>>>>> + bool "Provide legacy /dev/fb* device"
>>>>
>>>> Perhaps "default y if !DRM", although that does not help for a
>>>> mixed drm/fbdev kernel build?
>>>
>>> We could simply set it to "default y". But OTOH is it worth making it a
>>> default? Distributions will set it to the value they need/want. The very
>>> few people that build their own kernels to get certain fbdev drivers
>>> will certainly be able to enable the option by hand as well.
>>
>> Defaulting to "n" (the default) means causing regressions when these
>> few people use an existing defconfig.
>>
>
> Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
> at least it won't silently be disabled for users that only want fbdev as
> Geert mentioned.
IMHO the rational behind such conditionals are mostly what "we make up
here in the discussion", but not something based on real-world feedback.
So I'd strongly prefer a clear n or y setting here.
>
> I wouldn't call it a regression though, because AFAIK the Kconfig options
> are not a stable API ?
IIRC in the past there have been concerns about changing Kconfig
defaults. If we go with "default n", we'd apparently do something similar.
>
>>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
>>>> to be selected by both FB and DRM_FBDEV_EMULATION?
>>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
>
> Funny that you mention because it's exactly what I attempted in the past:
>
> https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u
>
>>>
>>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
>>> enabled under certain conditions; merely for the kernel console. We'd
>>> have to enable CONFIG_FB, which would bring back the device.
>>
>> "Default y" does not mean that you cannot disable FB_DEVICE, so
>> you are not forced to bring back the device?
>>
>
> I think we can have both to make the kernel more configurable:
>
> 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
> which is what the series is doing with the new FB_DEVICE config symbol.
>
> 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
> emulation layer. That's what my series attempted to do with the FB_CORE
> Kconfig symbol.
>
> I believe that there are use cases for both, for example as Thomas' said
> many distros are disabling all the fbdev drivers and their user-space only
> requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.
>
> But may be that other users want the opposite, they have an old user-space
> that requires fbdev, but is running on newer hardware that only have a DRM
> driver. So they will want DRM fbdev emulation but none fbdev driver at all.
>
> That's why I think that FB_DEVICE and FB_CORE are complementary and we can
> support any combination of the two, if you agree there are uses for either.
I still don't understand the value of such an extra compile-time option?
Either you have fbdev userspace, then you want the device; or you
don't then it's better to disable it entirely. I don't see much of a
difference between DRM and fbdev drivers here.
I'd also question the argument that there's even fbdev userspace out
there. It was never popular in it's heyday and definitely hasn't
improved since then. Even the 3 people who still ask for fbdev support
here only seem to care about the performance of the framebuffer console,
but never about userspace.
So I'd like to propose a different solution: on top of the current
patchset, let's make an fbdev module option that enables the device. If
CONFIG_FB_DEVICE has been enabled, the option would switch the
functionality on and off. A Kconfig option would set the default. With
such a setup, distributions can disable the fbdev device by default.
And the few users with the odd system that has fbdev userspace can still
enable the fbdev device at boot time.
Best regards
Thomas
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files
2023-06-07 19:38 ` Sam Ravnborg
@ 2023-06-09 7:19 ` Thomas Zimmermann
0 siblings, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-09 7:19 UTC (permalink / raw)
To: Sam Ravnborg
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 10244 bytes --]
Hi Sam,
thanks for reviewing.
Am 07.06.23 um 21:38 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Mon, Jun 05, 2023 at 04:48:07PM +0200, Thomas Zimmermann wrote:
>> Move framebuffer and backlight helpers into separate files. Leave
>> fbsysfs.c to sysfs-related code. No functional changes.
>>
>> The framebuffer helpers are not in fbmem.c because they are under
>> GPL-2.0-or-later copyright, while fbmem.c is GPL-2.0.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Some nits that you decide what to do with.
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
> I do not get why they are moved out in separate files.
> I guess the picture will materialize later.
In patch 30/30, sysfs support will be built conditionally. Doing this in
the Makefile is so much nicer than having an ifdef conditional in the
source files.
I'd also argue that the backlight and framebuffer functions don't belong
next to the sysfs code.
>
> Sam
>
>> ---
>> drivers/video/fbdev/core/Makefile | 4 +-
>> drivers/video/fbdev/core/fb_backlight.c | 32 +++++++
>> drivers/video/fbdev/core/fb_info.c | 76 ++++++++++++++++
>> drivers/video/fbdev/core/fbsysfs.c | 110 +-----------------------
>> 4 files changed, 112 insertions(+), 110 deletions(-)
>> create mode 100644 drivers/video/fbdev/core/fb_backlight.c
>> create mode 100644 drivers/video/fbdev/core/fb_info.c
>>
>> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
>> index 8f0060160ffb..eee3295bc225 100644
>> --- a/drivers/video/fbdev/core/Makefile
>> +++ b/drivers/video/fbdev/core/Makefile
>> @@ -1,7 +1,9 @@
>> # SPDX-License-Identifier: GPL-2.0
>> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
>> obj-$(CONFIG_FB) += fb.o
>> -fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>> +fb-y := fb_backlight.o \
>> + fb_info.o \
>> + fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
> There is "+=" that can be used in Makefile, but people prefer '\' -
> sigh!
>
>> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
>>
>> diff --git a/drivers/video/fbdev/core/fb_backlight.c b/drivers/video/fbdev/core/fb_backlight.c
>> new file mode 100644
>> index 000000000000..feffe6c68039
>> --- /dev/null
>> +++ b/drivers/video/fbdev/core/fb_backlight.c
>> @@ -0,0 +1,32 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
> Hmm, can we change the license from 2.0 to 2.0-or-later without any
> concern? I hope so.
No change here. The backlight function comes from fbsysfs.c, which is
also GPL-2.0-or-later.
>
>> +
>> +#include <linux/export.h>
>> +#include <linux/fb.h>
> #include <linux/mutex.h> - to avoid relying on indirect includes?
I can do that.
>
>
>> +
>> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> +/*
>> + * This function generates a linear backlight curve
>> + *
>> + * 0: off
>> + * 1-7: min
>> + * 8-127: linear from min to max
>> + */
>> +void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
>> +{
>> + unsigned int i, flat, count, range = (max - min);
>> +
>> + mutex_lock(&fb_info->bl_curve_mutex);
>> +
>> + fb_info->bl_curve[0] = off;
>> +
>> + for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
>> + fb_info->bl_curve[flat] = min;
>> +
>> + count = FB_BACKLIGHT_LEVELS * 15 / 16;
>> + for (i = 0; i < count; ++i)
>> + fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
>> +
>> + mutex_unlock(&fb_info->bl_curve_mutex);
>> +}
>> +EXPORT_SYMBOL_GPL(fb_bl_default_curve);
>> +#endif
>> diff --git a/drivers/video/fbdev/core/fb_info.c b/drivers/video/fbdev/core/fb_info.c
>> new file mode 100644
>> index 000000000000..fb5b75009ee7
>> --- /dev/null
>> +++ b/drivers/video/fbdev/core/fb_info.c
>> @@ -0,0 +1,76 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +
>> +#include <linux/export.h>
>> +#include <linux/fb.h>
> Same as above, consider including mutex.h
> Also slab.h
Ok.
Best regards
Thomas
>
>> +
>> +/**
>> + * framebuffer_alloc - creates a new frame buffer info structure
>> + *
>> + * @size: size of driver private data, can be zero
>> + * @dev: pointer to the device for this fb, this can be NULL
>> + *
>> + * Creates a new frame buffer info structure. Also reserves @size bytes
>> + * for driver private data (info->par). info->par (if any) will be
>> + * aligned to sizeof(long).
>> + *
>> + * Returns the new structure, or NULL if an error occurred.
>> + *
>> + */
>> +struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
>> +{
>> +#define BYTES_PER_LONG (BITS_PER_LONG/8)
>> +#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
>> + int fb_info_size = sizeof(struct fb_info);
>> + struct fb_info *info;
>> + char *p;
>> +
>> + if (size)
>> + fb_info_size += PADDING;
>> +
>> + p = kzalloc(fb_info_size + size, GFP_KERNEL);
>> +
>> + if (!p)
>> + return NULL;
>> +
>> + info = (struct fb_info *) p;
>> +
>> + if (size)
>> + info->par = p + fb_info_size;
>> +
>> + info->device = dev;
>> + info->fbcon_rotate_hint = -1;
>> +
>> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> + mutex_init(&info->bl_curve_mutex);
>> +#endif
>> +
>> + return info;
>> +#undef PADDING
>> +#undef BYTES_PER_LONG
>> +}
>> +EXPORT_SYMBOL(framebuffer_alloc);
>> +
>> +/**
>> + * framebuffer_release - marks the structure available for freeing
>> + *
>> + * @info: frame buffer info structure
>> + *
>> + * Drop the reference count of the device embedded in the
>> + * framebuffer info structure.
>> + *
>> + */
>> +void framebuffer_release(struct fb_info *info)
>> +{
>> + if (!info)
>> + return;
>> +
>> + if (WARN_ON(refcount_read(&info->count)))
>> + return;
>> +
>> +#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> + mutex_destroy(&info->bl_curve_mutex);
>> +#endif
>> +
>> + kfree(info);
>> +}
>> +EXPORT_SYMBOL(framebuffer_release);
>> diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
>> index 0c33c4adcd79..849073f1ca06 100644
>> --- a/drivers/video/fbdev/core/fbsysfs.c
>> +++ b/drivers/video/fbdev/core/fbsysfs.c
>> @@ -5,93 +5,12 @@
>> * Copyright (c) 2004 James Simmons <jsimmons@infradead.org>
>> */
>>
>> -/*
>> - * Note: currently there's only stubs for framebuffer_alloc and
>> - * framebuffer_release here. The reson for that is that until all drivers
>> - * are converted to use it a sysfsification will open OOPSable races.
>> - */
>> -
>> -#include <linux/kernel.h>
>> -#include <linux/slab.h>
>> +#include <linux/console.h>
>> #include <linux/fb.h>
>> #include <linux/fbcon.h>
>> -#include <linux/console.h>
>> -#include <linux/module.h>
>>
>> #define FB_SYSFS_FLAG_ATTR 1
>>
>> -/**
>> - * framebuffer_alloc - creates a new frame buffer info structure
>> - *
>> - * @size: size of driver private data, can be zero
>> - * @dev: pointer to the device for this fb, this can be NULL
>> - *
>> - * Creates a new frame buffer info structure. Also reserves @size bytes
>> - * for driver private data (info->par). info->par (if any) will be
>> - * aligned to sizeof(long).
>> - *
>> - * Returns the new structure, or NULL if an error occurred.
>> - *
>> - */
>> -struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
>> -{
>> -#define BYTES_PER_LONG (BITS_PER_LONG/8)
>> -#define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
>> - int fb_info_size = sizeof(struct fb_info);
>> - struct fb_info *info;
>> - char *p;
>> -
>> - if (size)
>> - fb_info_size += PADDING;
>> -
>> - p = kzalloc(fb_info_size + size, GFP_KERNEL);
>> -
>> - if (!p)
>> - return NULL;
>> -
>> - info = (struct fb_info *) p;
>> -
>> - if (size)
>> - info->par = p + fb_info_size;
>> -
>> - info->device = dev;
>> - info->fbcon_rotate_hint = -1;
>> -
>> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> - mutex_init(&info->bl_curve_mutex);
>> -#endif
>> -
>> - return info;
>> -#undef PADDING
>> -#undef BYTES_PER_LONG
>> -}
>> -EXPORT_SYMBOL(framebuffer_alloc);
>> -
>> -/**
>> - * framebuffer_release - marks the structure available for freeing
>> - *
>> - * @info: frame buffer info structure
>> - *
>> - * Drop the reference count of the device embedded in the
>> - * framebuffer info structure.
>> - *
>> - */
>> -void framebuffer_release(struct fb_info *info)
>> -{
>> - if (!info)
>> - return;
>> -
>> - if (WARN_ON(refcount_read(&info->count)))
>> - return;
>> -
>> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> - mutex_destroy(&info->bl_curve_mutex);
>> -#endif
>> -
>> - kfree(info);
>> -}
>> -EXPORT_SYMBOL(framebuffer_release);
>> -
>> static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
>> {
>> int err;
>> @@ -551,30 +470,3 @@ void fb_cleanup_device(struct fb_info *fb_info)
>> fb_info->class_flag &= ~FB_SYSFS_FLAG_ATTR;
>> }
>> }
>> -
>> -#if IS_ENABLED(CONFIG_FB_BACKLIGHT)
>> -/* This function generates a linear backlight curve
>> - *
>> - * 0: off
>> - * 1-7: min
>> - * 8-127: linear from min to max
>> - */
>> -void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 max)
>> -{
>> - unsigned int i, flat, count, range = (max - min);
>> -
>> - mutex_lock(&fb_info->bl_curve_mutex);
>> -
>> - fb_info->bl_curve[0] = off;
>> -
>> - for (flat = 1; flat < (FB_BACKLIGHT_LEVELS / 16); ++flat)
>> - fb_info->bl_curve[flat] = min;
>> -
>> - count = FB_BACKLIGHT_LEVELS * 15 / 16;
>> - for (i = 0; i < count; ++i)
>> - fb_info->bl_curve[flat + i] = min + (range * (i + 1) / count);
>> -
>> - mutex_unlock(&fb_info->bl_curve_mutex);
>> -}
>> -EXPORT_SYMBOL_GPL(fb_bl_default_curve);
>> -#endif
>> --
>> 2.40.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 7:09 ` Thomas Zimmermann
@ 2023-06-09 7:29 ` Geert Uytterhoeven
2023-06-09 8:00 ` Thomas Zimmermann
0 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-09 7:29 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Javier Martinez Canillas, daniel.thompson, linux-staging,
linux-sh, jingoohan1, deller, lee, dri-devel, linux-fbdev,
linux-omap, sam
Hi Thomas,
On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
> > Geert Uytterhoeven <geert@linux-m68k.org> writes:
> >> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
> >>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>>> --- a/drivers/video/fbdev/Kconfig
> >>>>> +++ b/drivers/video/fbdev/Kconfig
> >>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> >>>>> combination with certain motherboards and monitors are known to
> >>>>> suffer from this problem.
> >>>>>
> >>>>> +config FB_DEVICE
> >>>>> + bool "Provide legacy /dev/fb* device"
> >>>>
> >>>> Perhaps "default y if !DRM", although that does not help for a
> >>>> mixed drm/fbdev kernel build?
> >>>
> >>> We could simply set it to "default y". But OTOH is it worth making it a
> >>> default? Distributions will set it to the value they need/want. The very
> >>> few people that build their own kernels to get certain fbdev drivers
> >>> will certainly be able to enable the option by hand as well.
> >>
> >> Defaulting to "n" (the default) means causing regressions when these
> >> few people use an existing defconfig.
> >>
> >
> > Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
> > at least it won't silently be disabled for users that only want fbdev as
> > Geert mentioned.
>
> IMHO the rational behind such conditionals are mostly what "we make up
> here in the discussion", but not something based on real-world feedback.
> So I'd strongly prefer a clear n or y setting here.
>
> >
> > I wouldn't call it a regression though, because AFAIK the Kconfig options
> > are not a stable API ?
>
> IIRC in the past there have been concerns about changing Kconfig
> defaults. If we go with "default n", we'd apparently do something similar.
>
> >
> >>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
> >>>> to be selected by both FB and DRM_FBDEV_EMULATION?
> >>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
> >
> > Funny that you mention because it's exactly what I attempted in the past:
> >
> > https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u
> >
> >>>
> >>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
> >>> enabled under certain conditions; merely for the kernel console. We'd
> >>> have to enable CONFIG_FB, which would bring back the device.
> >>
> >> "Default y" does not mean that you cannot disable FB_DEVICE, so
> >> you are not forced to bring back the device?
> >
> > I think we can have both to make the kernel more configurable:
> >
> > 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
> > which is what the series is doing with the new FB_DEVICE config symbol.
> >
> > 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
> > emulation layer. That's what my series attempted to do with the FB_CORE
> > Kconfig symbol.
> >
> > I believe that there are use cases for both, for example as Thomas' said
> > many distros are disabling all the fbdev drivers and their user-space only
> > requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.
> >
> > But may be that other users want the opposite, they have an old user-space
> > that requires fbdev, but is running on newer hardware that only have a DRM
> > driver. So they will want DRM fbdev emulation but none fbdev driver at all.
> >
> > That's why I think that FB_DEVICE and FB_CORE are complementary and we can
> > support any combination of the two, if you agree there are uses for either.
>
> I still don't understand the value of such an extra compile-time option?
> Either you have fbdev userspace, then you want the device; or you
> don't then it's better to disable it entirely. I don't see much of a
> difference between DRM and fbdev drivers here.
If you have DRM and are running a Linux desktop, you are probably
using DRM userspace.
If you have fbdev, and are using graphics, you have no choice but
using an fbdev userspace.
So with FB_CORE, you can have default y if you have a real fbdev driver,
and default n if you have only DRM drivers.
> I'd also question the argument that there's even fbdev userspace out
> there. It was never popular in it's heyday and definitely hasn't
> improved since then. Even the 3 people who still ask for fbdev support
There's X.org, DirectFB, SDL, ...
What do you think low-end embedded devices with an out-of-tree[*]
fbdev driver are using?
[*] There's been a moratorium on new fbdev drivers for about a decade.
> here only seem to care about the performance of the framebuffer console,
> but never about userspace.
Unless you go for heavy graphics and 3D, a simple GUI with some
buttons and text requires less performance than scrolling a full-screen
graphical text console...
> So I'd like to propose a different solution: on top of the current
> patchset, let's make an fbdev module option that enables the device. If
> CONFIG_FB_DEVICE has been enabled, the option would switch the
> functionality on and off. A Kconfig option would set the default. With
> such a setup, distributions can disable the fbdev device by default.
> And the few users with the odd system that has fbdev userspace can still
> enable the fbdev device at boot time.
Hmm... That makes it even more complicated...
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 7:29 ` Geert Uytterhoeven
@ 2023-06-09 8:00 ` Thomas Zimmermann
2023-06-09 9:14 ` Geert Uytterhoeven
` (2 more replies)
0 siblings, 3 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-09 8:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Javier Martinez Canillas, daniel.thompson, linux-staging,
linux-sh, jingoohan1, deller, lee, dri-devel, linux-fbdev,
linux-omap, sam
[-- Attachment #1.1: Type: text/plain, Size: 7148 bytes --]
Hi
Am 09.06.23 um 09:29 schrieb Geert Uytterhoeven:
> Hi Thomas,
>
> On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
>>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>>> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
>>>>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>>>>> --- a/drivers/video/fbdev/Kconfig
>>>>>>> +++ b/drivers/video/fbdev/Kconfig
>>>>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>>>>>>> combination with certain motherboards and monitors are known to
>>>>>>> suffer from this problem.
>>>>>>>
>>>>>>> +config FB_DEVICE
>>>>>>> + bool "Provide legacy /dev/fb* device"
>>>>>>
>>>>>> Perhaps "default y if !DRM", although that does not help for a
>>>>>> mixed drm/fbdev kernel build?
>>>>>
>>>>> We could simply set it to "default y". But OTOH is it worth making it a
>>>>> default? Distributions will set it to the value they need/want. The very
>>>>> few people that build their own kernels to get certain fbdev drivers
>>>>> will certainly be able to enable the option by hand as well.
>>>>
>>>> Defaulting to "n" (the default) means causing regressions when these
>>>> few people use an existing defconfig.
>>>>
>>>
>>> Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
>>> at least it won't silently be disabled for users that only want fbdev as
>>> Geert mentioned.
>>
>> IMHO the rational behind such conditionals are mostly what "we make up
>> here in the discussion", but not something based on real-world feedback.
>> So I'd strongly prefer a clear n or y setting here.
>>
>>>
>>> I wouldn't call it a regression though, because AFAIK the Kconfig options
>>> are not a stable API ?
>>
>> IIRC in the past there have been concerns about changing Kconfig
>> defaults. If we go with "default n", we'd apparently do something similar.
>>
>>>
>>>>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
>>>>>> to be selected by both FB and DRM_FBDEV_EMULATION?
>>>>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
>>>
>>> Funny that you mention because it's exactly what I attempted in the past:
>>>
>>> https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u
>>>
>>>>>
>>>>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
>>>>> enabled under certain conditions; merely for the kernel console. We'd
>>>>> have to enable CONFIG_FB, which would bring back the device.
>>>>
>>>> "Default y" does not mean that you cannot disable FB_DEVICE, so
>>>> you are not forced to bring back the device?
>>>
>>> I think we can have both to make the kernel more configurable:
>>>
>>> 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
>>> which is what the series is doing with the new FB_DEVICE config symbol.
>>>
>>> 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
>>> emulation layer. That's what my series attempted to do with the FB_CORE
>>> Kconfig symbol.
>>>
>>> I believe that there are use cases for both, for example as Thomas' said
>>> many distros are disabling all the fbdev drivers and their user-space only
>>> requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.
>>>
>>> But may be that other users want the opposite, they have an old user-space
>>> that requires fbdev, but is running on newer hardware that only have a DRM
>>> driver. So they will want DRM fbdev emulation but none fbdev driver at all.
>>>
>>> That's why I think that FB_DEVICE and FB_CORE are complementary and we can
>>> support any combination of the two, if you agree there are uses for either.
>>
>> I still don't understand the value of such an extra compile-time option?
>> Either you have fbdev userspace, then you want the device; or you
>> don't then it's better to disable it entirely. I don't see much of a
>> difference between DRM and fbdev drivers here.
>
> If you have DRM and are running a Linux desktop, you are probably
> using DRM userspace.
> If you have fbdev, and are using graphics, you have no choice but
> using an fbdev userspace.
>
> So with FB_CORE, you can have default y if you have a real fbdev driver,
> and default n if you have only DRM drivers.
>
>> I'd also question the argument that there's even fbdev userspace out
>> there. It was never popular in it's heyday and definitely hasn't
>> improved since then. Even the 3 people who still ask for fbdev support
>
> There's X.org, DirectFB, SDL, ...
None of these examples has a dependency on fbdev. They can freely switch
backends and have moved to DRM. Anything program utilizing these
examples has no dependency on fbdev either.
When I say "userspace" in this context, it's the one old program that
supports nothing but fbdev. TBH I'm having problems to come up with
examples.
>
> What do you think low-end embedded devices with an out-of-tree[*]
> fbdev driver are using?
And those do not count either. IIRC Android used to be built on top of
fbdev devices. I'm not sure if they have moved to DRM by now. But
embedded uses dedicated kernels and kernel configs. It's easy for them
to set FB_DEVICE=y. We're not going to take away the fbdev device entirely.
>
> [*] There's been a moratorium on new fbdev drivers for about a decade.
>
>> here only seem to care about the performance of the framebuffer console,
>> but never about userspace.
>
> Unless you go for heavy graphics and 3D, a simple GUI with some
> buttons and text requires less performance than scrolling a full-screen
> graphical text console...
>
>> So I'd like to propose a different solution: on top of the current
>> patchset, let's make an fbdev module option that enables the device. If
>> CONFIG_FB_DEVICE has been enabled, the option would switch the
>> functionality on and off. A Kconfig option would set the default. With
>> such a setup, distributions can disable the fbdev device by default.
>> And the few users with the odd system that has fbdev userspace can still
>> enable the fbdev device at boot time.
>
> Hmm... That makes it even more complicated...
No, that makes things a lot easier for distros. Everyone else (custom
builds, embedded) is not affected by this change. Desktop distros are
really the only affected party I see here. "We" (I'm at Suse) have to
support all kinds of users with just a few generic offerings. And if I
can disable the fbdev device by default and give the very few fbdev
users a workaround, it's a very good tradeoff.
Best regards
Thomas
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 8:00 ` Thomas Zimmermann
@ 2023-06-09 9:14 ` Geert Uytterhoeven
2023-06-09 11:04 ` Thomas Zimmermann
2023-06-09 9:59 ` Javier Martinez Canillas
2023-06-09 11:27 ` Javier Martinez Canillas
2 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-09 9:14 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Javier Martinez Canillas, daniel.thompson, linux-staging,
linux-sh, jingoohan1, deller, lee, dri-devel, linux-fbdev,
linux-omap, sam
Hi Thomas,
On Fri, Jun 9, 2023 at 10:00 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 09.06.23 um 09:29 schrieb Geert Uytterhoeven:
> > On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >> Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
> >>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> >>>> On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>>> Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
> >>>>>> On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>>>>>> --- a/drivers/video/fbdev/Kconfig
> >>>>>>> +++ b/drivers/video/fbdev/Kconfig
> >>>>>>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> >>>>>>> combination with certain motherboards and monitors are known to
> >>>>>>> suffer from this problem.
> >>>>>>>
> >>>>>>> +config FB_DEVICE
> >>>>>>> + bool "Provide legacy /dev/fb* device"
> >>>>>>
> >>>>>> Perhaps "default y if !DRM", although that does not help for a
> >>>>>> mixed drm/fbdev kernel build?
> >>>>>
> >>>>> We could simply set it to "default y". But OTOH is it worth making it a
> >>>>> default? Distributions will set it to the value they need/want. The very
> >>>>> few people that build their own kernels to get certain fbdev drivers
> >>>>> will certainly be able to enable the option by hand as well.
> >>>>
> >>>> Defaulting to "n" (the default) means causing regressions when these
> >>>> few people use an existing defconfig.
> >>>>
> >>>
> >>> Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
> >>> at least it won't silently be disabled for users that only want fbdev as
> >>> Geert mentioned.
> >>
> >> IMHO the rational behind such conditionals are mostly what "we make up
> >> here in the discussion", but not something based on real-world feedback.
> >> So I'd strongly prefer a clear n or y setting here.
> >>
> >>>
> >>> I wouldn't call it a regression though, because AFAIK the Kconfig options
> >>> are not a stable API ?
> >>
> >> IIRC in the past there have been concerns about changing Kconfig
> >> defaults. If we go with "default n", we'd apparently do something similar.
> >>
> >>>
> >>>>>> Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
> >>>>>> to be selected by both FB and DRM_FBDEV_EMULATION?
> >>>>>> Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
> >>>
> >>> Funny that you mention because it's exactly what I attempted in the past:
> >>>
> >>> https://lore.kernel.org/all/20210827100531.1578604-1-javierm@redhat.com/T/#u
> >>>
> >>>>>
> >>>>> That wouldn't work. In Tumbleweed, we still have efifb and vesafb
> >>>>> enabled under certain conditions; merely for the kernel console. We'd
> >>>>> have to enable CONFIG_FB, which would bring back the device.
> >>>>
> >>>> "Default y" does not mean that you cannot disable FB_DEVICE, so
> >>>> you are not forced to bring back the device?
> >>>
> >>> I think we can have both to make the kernel more configurable:
> >>>
> >>> 1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
> >>> which is what the series is doing with the new FB_DEVICE config symbol.
> >>>
> >>> 2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
> >>> emulation layer. That's what my series attempted to do with the FB_CORE
> >>> Kconfig symbol.
> >>>
> >>> I believe that there are use cases for both, for example as Thomas' said
> >>> many distros are disabling all the fbdev drivers and their user-space only
> >>> requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.
> >>>
> >>> But may be that other users want the opposite, they have an old user-space
> >>> that requires fbdev, but is running on newer hardware that only have a DRM
> >>> driver. So they will want DRM fbdev emulation but none fbdev driver at all.
> >>>
> >>> That's why I think that FB_DEVICE and FB_CORE are complementary and we can
> >>> support any combination of the two, if you agree there are uses for either.
> >>
> >> I still don't understand the value of such an extra compile-time option?
> >> Either you have fbdev userspace, then you want the device; or you
> >> don't then it's better to disable it entirely. I don't see much of a
> >> difference between DRM and fbdev drivers here.
> >
> > If you have DRM and are running a Linux desktop, you are probably
> > using DRM userspace.
> > If you have fbdev, and are using graphics, you have no choice but
> > using an fbdev userspace.
> >
> > So with FB_CORE, you can have default y if you have a real fbdev driver,
> > and default n if you have only DRM drivers.
> >
> >> I'd also question the argument that there's even fbdev userspace out
> >> there. It was never popular in it's heyday and definitely hasn't
> >> improved since then. Even the 3 people who still ask for fbdev support
> >
> > There's X.org, DirectFB, SDL, ...
>
> None of these examples has a dependency on fbdev. They can freely switch
> backends and have moved to DRM. Anything program utilizing these
> examples has no dependency on fbdev either.
Indeed, these examples do not depend on fbdev, it's the other way
around. How does it help if your userspace now also supports DRM,
but you are using an fbdev graphics driver? The DRM drivers do not
cover all graphics hardware yet.
> When I say "userspace" in this context, it's the one old program that
> supports nothing but fbdev. TBH I'm having problems to come up with
> examples.
Even if you cannot find such an old program, that doesn't matter much,
if you are using an fbdev graphics driver...
> > What do you think low-end embedded devices with an out-of-tree[*]
> > fbdev driver are using?
>
> And those do not count either. IIRC Android used to be built on top of
> fbdev devices. I'm not sure if they have moved to DRM by now. But
> embedded uses dedicated kernels and kernel configs. It's easy for them
> to set FB_DEVICE=y. We're not going to take away the fbdev device entirely.
The point is that we do not suddenly disable functionality that users
may depend on. While "make oldconfig" will show users the new
FB_DEVICE question, (and hopefully they'll notice), "make olddefconfig"
and "make <foo>_defconfig" won't, possibly causing regressions.
Without a suitable default, you should IMHO at least update all
defconfigs that enable any fbdev drivers.
I guess you do remember the fall-out from f611b1e7624ccdbd ("drm:
Avoid circular dependencies for CONFIG_FB"), after which lots of defconfigs
had to gain CONFIG_FB=y?
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 8:00 ` Thomas Zimmermann
2023-06-09 9:14 ` Geert Uytterhoeven
@ 2023-06-09 9:59 ` Javier Martinez Canillas
2023-06-09 10:10 ` Geert Uytterhoeven
2023-06-09 11:27 ` Javier Martinez Canillas
2 siblings, 1 reply; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-09 9:59 UTC (permalink / raw)
To: Thomas Zimmermann, Geert Uytterhoeven
Cc: daniel.thompson, linux-staging, linux-sh, jingoohan1, deller,
lee, dri-devel, linux-fbdev, linux-omap, sam
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> Hi
>
[...]
>>> I'd also question the argument that there's even fbdev userspace out
>>> there. It was never popular in it's heyday and definitely hasn't
>>> improved since then. Even the 3 people who still ask for fbdev support
>>
>> There's X.org, DirectFB, SDL, ...
>
> None of these examples has a dependency on fbdev. They can freely switch
> backends and have moved to DRM. Anything program utilizing these
> examples has no dependency on fbdev either.
>
> When I say "userspace" in this context, it's the one old program that
> supports nothing but fbdev. TBH I'm having problems to come up with
> examples.
>
I personally have two real world examples that can give to you :)
1) I've a IoT device at home that has a bunch of sensors (temperatury,
humidity, etc) and a SSD1306 display panel to report that. It just
has small fbdev program to print that info. I could probably port
to KMS but didn't feel like it. Found a fbdev program that I could
modify and got the job done.
2) I built a portable retro console for my kids, that uses a ST7735R
LCD panel. The software I use is https://www.retroarch.com/ which
uses fbdev by default (I believe that supports a KMS mode but out
of the box it works with fbdev and that's better tested by them.
So even when I'm not interested and don't want to enable any of the
fbdev drivers, I want to use the ssd130x and st7735r DRM drivers and
the DRM fbdev emulation layer.
In other words, there's real use cases for supporting fbdev programs
with DRM drivers. Now, I agree with this patch-set and probably will
disable the user-space fbdev interface in Fedora, but on my embedded
projects I will probably keep it enabled.
That's why I think that we should support the following combinations:
* fbdev drivers + DRM fbdev emulation + fbdev user-space
* only DRM drivers without fbdev emulation nor fbdev user-space (your series)
* only DRM fbdev emulation + fbdev user-space enabled (FB_CORE)
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 9:59 ` Javier Martinez Canillas
@ 2023-06-09 10:10 ` Geert Uytterhoeven
2023-06-09 10:24 ` Javier Martinez Canillas
0 siblings, 1 reply; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-09 10:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Thomas Zimmermann, daniel.thompson, linux-staging, linux-sh,
jingoohan1, deller, lee, dri-devel, linux-fbdev, linux-omap, sam
Hi Javier,
On Fri, Jun 9, 2023 at 11:59 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
> >>> I'd also question the argument that there's even fbdev userspace out
> >>> there. It was never popular in it's heyday and definitely hasn't
> >>> improved since then. Even the 3 people who still ask for fbdev support
> >>
> >> There's X.org, DirectFB, SDL, ...
> >
> > None of these examples has a dependency on fbdev. They can freely switch
> > backends and have moved to DRM. Anything program utilizing these
> > examples has no dependency on fbdev either.
> >
> > When I say "userspace" in this context, it's the one old program that
> > supports nothing but fbdev. TBH I'm having problems to come up with
> > examples.
> >
>
> I personally have two real world examples that can give to you :)
>
> 1) I've a IoT device at home that has a bunch of sensors (temperatury,
> humidity, etc) and a SSD1306 display panel to report that. It just
> has small fbdev program to print that info. I could probably port
> to KMS but didn't feel like it. Found a fbdev program that I could
> modify and got the job done.
>
> 2) I built a portable retro console for my kids, that uses a ST7735R
> LCD panel. The software I use is https://www.retroarch.com/ which
> uses fbdev by default (I believe that supports a KMS mode but out
> of the box it works with fbdev and that's better tested by them.
>
> So even when I'm not interested and don't want to enable any of the
> fbdev drivers, I want to use the ssd130x and st7735r DRM drivers and
> the DRM fbdev emulation layer.
>
> In other words, there's real use cases for supporting fbdev programs
> with DRM drivers. Now, I agree with this patch-set and probably will
> disable the user-space fbdev interface in Fedora, but on my embedded
> projects I will probably keep it enabled.
>
> That's why I think that we should support the following combinations:
>
> * fbdev drivers + DRM fbdev emulation + fbdev user-space
"fbdev drivers + fbdev user-space", I assume?
> * only DRM drivers without fbdev emulation nor fbdev user-space (your series)
Thomas' series includes fbdev emulation here, for the text console.
> * only DRM fbdev emulation + fbdev user-space enabled (FB_CORE)
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 10:10 ` Geert Uytterhoeven
@ 2023-06-09 10:24 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-09 10:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Zimmermann, daniel.thompson, linux-staging, linux-sh,
jingoohan1, deller, lee, dri-devel, linux-fbdev, linux-omap, sam
Geert Uytterhoeven <geert@linux-m68k.org> writes:
>> * fbdev drivers + DRM fbdev emulation + fbdev user-space
>
> "fbdev drivers + fbdev user-space", I assume?
>
Right, I meant to also include "only fbdev drivers + fbdev user-space"
but forgot :)
>> * only DRM drivers without fbdev emulation nor fbdev user-space (your series)
>
> Thomas' series includes fbdev emulation here, for the text console.
>
Yes, I meant fbdev emulation for user-space. Probably should had included
fbcon in the options too...
But what I tried to say is that we need all combination of DRM drivers,
fbdev drivers, DRM emulation for fbcon and emulation for fbdev user-space.
And I think that Thomas' series + a FB_CORE as you suggested and done in
my old series should be enough to have that.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 9:14 ` Geert Uytterhoeven
@ 2023-06-09 11:04 ` Thomas Zimmermann
2023-06-09 11:22 ` Geert Uytterhoeven
0 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-09 11:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: daniel.thompson, lee, linux-sh, jingoohan1, deller,
linux-staging, Javier Martinez Canillas, dri-devel, linux-fbdev,
linux-omap, sam
[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]
Hi
Am 09.06.23 um 11:14 schrieb Geert Uytterhoeven:
[...]
>
>>> What do you think low-end embedded devices with an out-of-tree[*]
>>> fbdev driver are using?
>>
>> And those do not count either. IIRC Android used to be built on top of
>> fbdev devices. I'm not sure if they have moved to DRM by now. But
>> embedded uses dedicated kernels and kernel configs. It's easy for them
>> to set FB_DEVICE=y. We're not going to take away the fbdev device entirely.
>
> The point is that we do not suddenly disable functionality that users
> may depend on. While "make oldconfig" will show users the new
> FB_DEVICE question, (and hopefully they'll notice), "make olddefconfig"
> and "make <foo>_defconfig" won't, possibly causing regressions.
> Without a suitable default, you should IMHO at least update all
> defconfigs that enable any fbdev drivers.
Didn't I already say that we should make it "default y" if that's
preferable in practice?
Best regards
Thomas
>
> I guess you do remember the fall-out from f611b1e7624ccdbd ("drm:
> Avoid circular dependencies for CONFIG_FB"), after which lots of defconfigs
> had to gain CONFIG_FB=y?
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 11:04 ` Thomas Zimmermann
@ 2023-06-09 11:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 99+ messages in thread
From: Geert Uytterhoeven @ 2023-06-09 11:22 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel.thompson, lee, linux-sh, jingoohan1, deller,
linux-staging, Javier Martinez Canillas, dri-devel, linux-fbdev,
linux-omap, sam
Hi Thomas,
On Fri, Jun 9, 2023 at 1:04 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 09.06.23 um 11:14 schrieb Geert Uytterhoeven:
> [...]
> >
> >>> What do you think low-end embedded devices with an out-of-tree[*]
> >>> fbdev driver are using?
> >>
> >> And those do not count either. IIRC Android used to be built on top of
> >> fbdev devices. I'm not sure if they have moved to DRM by now. But
> >> embedded uses dedicated kernels and kernel configs. It's easy for them
> >> to set FB_DEVICE=y. We're not going to take away the fbdev device entirely.
> >
> > The point is that we do not suddenly disable functionality that users
> > may depend on. While "make oldconfig" will show users the new
> > FB_DEVICE question, (and hopefully they'll notice), "make olddefconfig"
> > and "make <foo>_defconfig" won't, possibly causing regressions.
> > Without a suitable default, you should IMHO at least update all
> > defconfigs that enable any fbdev drivers.
>
> Didn't I already say that we should make it "default y" if that's
> preferable in practice?
OK, sorry, I seem to have missed that part.
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 [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-09 8:00 ` Thomas Zimmermann
2023-06-09 9:14 ` Geert Uytterhoeven
2023-06-09 9:59 ` Javier Martinez Canillas
@ 2023-06-09 11:27 ` Javier Martinez Canillas
2 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-09 11:27 UTC (permalink / raw)
To: Thomas Zimmermann, Geert Uytterhoeven
Cc: daniel.thompson, linux-staging, linux-sh, jingoohan1, deller,
lee, dri-devel, linux-fbdev, linux-omap, sam
Thomas Zimmermann <tzimmermann@suse.de> writes:
[...]
>>
>> So with FB_CORE, you can have default y if you have a real fbdev driver,
>> and default n if you have only DRM drivers.
>>
All this discussion about FB_CORE is unrelated to your series though and
that is covered by enabling CONFIG_FB_DEVICE. I think that there's value
on a FB_CORE option to allow disabling all the fbdev drivers with a single
option but still keep DRM_FBDEV_EMULATION enabled.
But I can repost my old series on top of this patch-set once it lands.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
` (2 preceding siblings ...)
2023-06-07 8:48 ` Geert Uytterhoeven
@ 2023-06-11 16:37 ` Sam Ravnborg
2023-06-12 6:47 ` Thomas Zimmermann
2023-06-12 7:00 ` Thomas Zimmermann
3 siblings, 2 replies; 99+ messages in thread
From: Sam Ravnborg @ 2023-06-11 16:37 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
Hi Thomas,
On Mon, Jun 05, 2023 at 04:48:12PM +0200, Thomas Zimmermann wrote:
> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
> device optional. If the new option has not been selected, fbdev
> does not create a files in devfs or sysfs.
s/ a//
>
> Most modern Linux systems run a DRM-based graphics stack that uses
> the kernel's framebuffer console, but has otherwise deprecated fbdev
> support. Yet fbdev userspace interfaces are still present.
>
> The option makes it possible to use the fbdev subsystem as console
> implementation without support for userspace. This closes potential
> entry points to manipulate kernel or I/O memory via framebuffers. It
> also prevents the execution of driver code via ioctl or sysfs, both
> of which might allow malicious software to exploit bugs in the fbdev
> code.
>
> A small number of fbdev drivers require struct fbinfo.dev to be
> initialized, usually for the support of sysfs interface. Make these
> drivers depend on FB_DEVICE. They can later be fixed if necessary.
Should that be a TODO in gpu/todo.rst?
Otherwise the amount of people knowing about this
is very close to 1.
As an alternative add a TODO to each Kconfig file.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/staging/fbtft/Kconfig | 1 +
> drivers/video/fbdev/Kconfig | 12 +++++++++
> drivers/video/fbdev/core/Makefile | 7 +++---
> drivers/video/fbdev/core/fb_internal.h | 32 ++++++++++++++++++++++++
> drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
> include/linux/fb.h | 2 ++
> 6 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
> index 4d29e8c1014e..5dda3c65a38e 100644
> --- a/drivers/staging/fbtft/Kconfig
> +++ b/drivers/staging/fbtft/Kconfig
> @@ -2,6 +2,7 @@
> menuconfig FB_TFT
> tristate "Support for small TFT LCD display modules"
> depends on FB && SPI
> + depends on FB_DEVICE
> depends on GPIOLIB || COMPILE_TEST
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 6df9bd09454a..48d9a14f889c 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> combination with certain motherboards and monitors are known to
> suffer from this problem.
>
> +config FB_DEVICE
> + bool "Provide legacy /dev/fb* device"
> + depends on FB
> + help
> + Say Y here if you want the legacy /dev/fb* device file. It's
> + only required if you have userspace programs that depend on
> + fbdev for graphics output. This does not effect the framebuffer
> + console.
tabs to spaces to indent the above correct.
> +
> config FB_DDC
> tristate
> depends on FB
> @@ -1545,6 +1554,7 @@ config FB_3DFX_I2C
> config FB_VOODOO1
> tristate "3Dfx Voodoo Graphics (sst1) support"
> depends on FB && PCI
> + depends on FB_DEVICE
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> @@ -1862,6 +1872,7 @@ config FB_SH_MOBILE_LCDC
> tristate "SuperH Mobile LCDC framebuffer support"
> depends on FB && HAVE_CLK && HAS_IOMEM
> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> + depends on FB_DEVICE
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> @@ -1930,6 +1941,7 @@ config FB_SMSCUFX
> config FB_UDL
> tristate "Displaylink USB Framebuffer support"
> depends on FB && USB
> + depends on FB_DEVICE
> select FB_MODE_HELPERS
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
> index 125d24f50c36..d5e8772620f8 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -2,12 +2,13 @@
> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
> obj-$(CONFIG_FB) += fb.o
> fb-y := fb_backlight.o \
> - fb_devfs.o \
> fb_info.o \
> - fb_procfs.o \
> - fbmem.o fbmon.o fbcmap.o fbsysfs.o \
> + fbmem.o fbmon.o fbcmap.o \
> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
> +fb-$(CONFIG_FB_DEVICE) += fb_devfs.o \
> + fb_procfs.o \
> + fbsysfs.o
Maybe change this to one line to avoid '\'?
>
> ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE),y)
> fb-y += fbcon.o bitblit.o softcursor.o
> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
> index 0b43c0cd5096..b8a28466db79 100644
> --- a/drivers/video/fbdev/core/fb_internal.h
> +++ b/drivers/video/fbdev/core/fb_internal.h
> @@ -3,12 +3,22 @@
> #ifndef _FB_INTERNAL_H
> #define _FB_INTERNAL_H
>
> +#include <linux/device.h>
> #include <linux/fb.h>
> #include <linux/mutex.h>
>
> /* fb_devfs.c */
> +#if defined(CONFIG_FB_DEVICE)
> int fb_register_chrdev(void);
> void fb_unregister_chrdev(void);
> +#else
> +static inline int fb_register_chrdev(void)
> +{
> + return 0;
> +}
> +static inline void fb_unregister_chrdev(void)
> +{ }
> +#endif
>
> /* fbmem.c */
> extern struct class *fb_class;
> @@ -19,11 +29,33 @@ struct fb_info *get_fb_info(unsigned int idx);
> void put_fb_info(struct fb_info *fb_info);
>
> /* fb_procfs.c */
> +#if defined(CONFIG_FB_DEVICE)
> int fb_init_procfs(void);
> void fb_cleanup_procfs(void);
> +#else
> +static inline int fb_init_procfs(void)
> +{
> + return 0;
> +}
> +static inline void fb_cleanup_procfs(void)
> +{ }
> +#endif
>
> /* fbsysfs.c */
> +#if defined(CONFIG_FB_DEVICE)
> int fb_device_create(struct fb_info *fb_info);
> void fb_device_destroy(struct fb_info *fb_info);
> +#else
> +static inline int fb_device_create(struct fb_info *fb_info)
> +{
> + get_device(fb_info->device); // as in device_add()
> +
> + return 0;
> +}
> +static inline void fb_device_destroy(struct fb_info *fb_info)
> +{
> + put_device(fb_info->device); // as in device_del()
> +}
> +#endif
I do not see why fb_device_{create,destroy} needs to call
{get,put}_device - and it is not explained.
A short explanation in the commit maybe?
With my comments addressed:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Note: I do not engage in the thread about the best Kconfig
solution - I trust the involved people will find a good solution.
Sam
>
> #endif
> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
> index 69f9cb03507e..21069fdb7cc2 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
> @@ -5,9 +5,9 @@ config OMAP2_VRFB
> menuconfig FB_OMAP2
> tristate "OMAP2+ frame buffer support"
> depends on FB
> + depends on FB_DEVICE
> depends on DRM_OMAP = n
> depends on GPIOLIB
> -
> select FB_OMAP2_DSS
> select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
> select FB_CFB_FILLRECT
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 541a0e3ce21f..40ed1028160c 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -481,7 +481,9 @@ struct fb_info {
>
> const struct fb_ops *fbops;
> struct device *device; /* This is the parent */
> +#if defined(CONFIG_FB_DEVICE)
> struct device *dev; /* This is this fb device */
> +#endif
> int class_flag; /* private sysfs flags */
> #ifdef CONFIG_FB_TILEBLITTING
> struct fb_tile_ops *tileops; /* Tile Blitting */
> --
> 2.40.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-11 16:37 ` Sam Ravnborg
@ 2023-06-12 6:47 ` Thomas Zimmermann
2023-06-12 7:00 ` Thomas Zimmermann
1 sibling, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-12 6:47 UTC (permalink / raw)
To: Sam Ravnborg
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 8660 bytes --]
Hi Sam
Am 11.06.23 um 18:37 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Mon, Jun 05, 2023 at 04:48:12PM +0200, Thomas Zimmermann wrote:
>> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
>> device optional. If the new option has not been selected, fbdev
>> does not create a files in devfs or sysfs.
> s/ a//
>>
>> Most modern Linux systems run a DRM-based graphics stack that uses
>> the kernel's framebuffer console, but has otherwise deprecated fbdev
>> support. Yet fbdev userspace interfaces are still present.
>>
>> The option makes it possible to use the fbdev subsystem as console
>> implementation without support for userspace. This closes potential
>> entry points to manipulate kernel or I/O memory via framebuffers. It
>> also prevents the execution of driver code via ioctl or sysfs, both
>> of which might allow malicious software to exploit bugs in the fbdev
>> code.
>>
>> A small number of fbdev drivers require struct fbinfo.dev to be
>> initialized, usually for the support of sysfs interface. Make these
>> drivers depend on FB_DEVICE. They can later be fixed if necessary.
> Should that be a TODO in gpu/todo.rst?
> Otherwise the amount of people knowing about this
> is very close to 1.
Ha! Yes, I'll add a TODO item. Good idea.
Best regards
Thomas
> As an alternative add a TODO to each Kconfig file.
>
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>> drivers/staging/fbtft/Kconfig | 1 +
>> drivers/video/fbdev/Kconfig | 12 +++++++++
>> drivers/video/fbdev/core/Makefile | 7 +++---
>> drivers/video/fbdev/core/fb_internal.h | 32 ++++++++++++++++++++++++
>> drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
>> include/linux/fb.h | 2 ++
>> 6 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
>> index 4d29e8c1014e..5dda3c65a38e 100644
>> --- a/drivers/staging/fbtft/Kconfig
>> +++ b/drivers/staging/fbtft/Kconfig
>> @@ -2,6 +2,7 @@
>> menuconfig FB_TFT
>> tristate "Support for small TFT LCD display modules"
>> depends on FB && SPI
>> + depends on FB_DEVICE
>> depends on GPIOLIB || COMPILE_TEST
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 6df9bd09454a..48d9a14f889c 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>> combination with certain motherboards and monitors are known to
>> suffer from this problem.
>>
>> +config FB_DEVICE
>> + bool "Provide legacy /dev/fb* device"
>> + depends on FB
>> + help
>> + Say Y here if you want the legacy /dev/fb* device file. It's
>> + only required if you have userspace programs that depend on
>> + fbdev for graphics output. This does not effect the framebuffer
>> + console.
> tabs to spaces to indent the above correct.
>
>> +
>> config FB_DDC
>> tristate
>> depends on FB
>> @@ -1545,6 +1554,7 @@ config FB_3DFX_I2C
>> config FB_VOODOO1
>> tristate "3Dfx Voodoo Graphics (sst1) support"
>> depends on FB && PCI
>> + depends on FB_DEVICE
>> select FB_CFB_FILLRECT
>> select FB_CFB_COPYAREA
>> select FB_CFB_IMAGEBLIT
>> @@ -1862,6 +1872,7 @@ config FB_SH_MOBILE_LCDC
>> tristate "SuperH Mobile LCDC framebuffer support"
>> depends on FB && HAVE_CLK && HAS_IOMEM
>> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
>> + depends on FB_DEVICE
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> select FB_SYS_IMAGEBLIT
>> @@ -1930,6 +1941,7 @@ config FB_SMSCUFX
>> config FB_UDL
>> tristate "Displaylink USB Framebuffer support"
>> depends on FB && USB
>> + depends on FB_DEVICE
>> select FB_MODE_HELPERS
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
>> index 125d24f50c36..d5e8772620f8 100644
>> --- a/drivers/video/fbdev/core/Makefile
>> +++ b/drivers/video/fbdev/core/Makefile
>> @@ -2,12 +2,13 @@
>> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
>> obj-$(CONFIG_FB) += fb.o
>> fb-y := fb_backlight.o \
>> - fb_devfs.o \
>> fb_info.o \
>> - fb_procfs.o \
>> - fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>> + fbmem.o fbmon.o fbcmap.o \
>> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
>> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
>> +fb-$(CONFIG_FB_DEVICE) += fb_devfs.o \
>> + fb_procfs.o \
>> + fbsysfs.o
> Maybe change this to one line to avoid '\'?
>
>>
>> ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE),y)
>> fb-y += fbcon.o bitblit.o softcursor.o
>> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
>> index 0b43c0cd5096..b8a28466db79 100644
>> --- a/drivers/video/fbdev/core/fb_internal.h
>> +++ b/drivers/video/fbdev/core/fb_internal.h
>> @@ -3,12 +3,22 @@
>> #ifndef _FB_INTERNAL_H
>> #define _FB_INTERNAL_H
>>
>> +#include <linux/device.h>
>> #include <linux/fb.h>
>> #include <linux/mutex.h>
>>
>> /* fb_devfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_register_chrdev(void);
>> void fb_unregister_chrdev(void);
>> +#else
>> +static inline int fb_register_chrdev(void)
>> +{
>> + return 0;
>> +}
>> +static inline void fb_unregister_chrdev(void)
>> +{ }
>> +#endif
>>
>> /* fbmem.c */
>> extern struct class *fb_class;
>> @@ -19,11 +29,33 @@ struct fb_info *get_fb_info(unsigned int idx);
>> void put_fb_info(struct fb_info *fb_info);
>>
>> /* fb_procfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_init_procfs(void);
>> void fb_cleanup_procfs(void);
>> +#else
>> +static inline int fb_init_procfs(void)
>> +{
>> + return 0;
>> +}
>> +static inline void fb_cleanup_procfs(void)
>> +{ }
>> +#endif
>>
>> /* fbsysfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_device_create(struct fb_info *fb_info);
>> void fb_device_destroy(struct fb_info *fb_info);
>> +#else
>> +static inline int fb_device_create(struct fb_info *fb_info)
>> +{
>> + get_device(fb_info->device); // as in device_add()
>> +
>> + return 0;
>> +}
>> +static inline void fb_device_destroy(struct fb_info *fb_info)
>> +{
>> + put_device(fb_info->device); // as in device_del()
>> +}
>> +#endif
> I do not see why fb_device_{create,destroy} needs to call
> {get,put}_device - and it is not explained.
> A short explanation in the commit maybe?
>
> With my comments addressed:
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
> Note: I do not engage in the thread about the best Kconfig
> solution - I trust the involved people will find a good solution.
>
> Sam
>
>>
>> #endif
>> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
>> index 69f9cb03507e..21069fdb7cc2 100644
>> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
>> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
>> @@ -5,9 +5,9 @@ config OMAP2_VRFB
>> menuconfig FB_OMAP2
>> tristate "OMAP2+ frame buffer support"
>> depends on FB
>> + depends on FB_DEVICE
>> depends on DRM_OMAP = n
>> depends on GPIOLIB
>> -
>> select FB_OMAP2_DSS
>> select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
>> select FB_CFB_FILLRECT
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 541a0e3ce21f..40ed1028160c 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -481,7 +481,9 @@ struct fb_info {
>>
>> const struct fb_ops *fbops;
>> struct device *device; /* This is the parent */
>> +#if defined(CONFIG_FB_DEVICE)
>> struct device *dev; /* This is this fb device */
>> +#endif
>> int class_flag; /* private sysfs flags */
>> #ifdef CONFIG_FB_TILEBLITTING
>> struct fb_tile_ops *tileops; /* Tile Blitting */
>> --
>> 2.40.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
2023-06-11 16:37 ` Sam Ravnborg
2023-06-12 6:47 ` Thomas Zimmermann
@ 2023-06-12 7:00 ` Thomas Zimmermann
1 sibling, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-12 7:00 UTC (permalink / raw)
To: Sam Ravnborg
Cc: daniel, javierm, deller, geert+renesas, lee, daniel.thompson,
jingoohan1, linux-fbdev, dri-devel, linux-sh, linux-omap,
linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 8924 bytes --]
Hi
Am 11.06.23 um 18:37 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Mon, Jun 05, 2023 at 04:48:12PM +0200, Thomas Zimmermann wrote:
>> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
>> device optional. If the new option has not been selected, fbdev
>> does not create a files in devfs or sysfs.
> s/ a//
>>
>> Most modern Linux systems run a DRM-based graphics stack that uses
>> the kernel's framebuffer console, but has otherwise deprecated fbdev
>> support. Yet fbdev userspace interfaces are still present.
>>
>> The option makes it possible to use the fbdev subsystem as console
>> implementation without support for userspace. This closes potential
>> entry points to manipulate kernel or I/O memory via framebuffers. It
>> also prevents the execution of driver code via ioctl or sysfs, both
>> of which might allow malicious software to exploit bugs in the fbdev
>> code.
>>
>> A small number of fbdev drivers require struct fbinfo.dev to be
>> initialized, usually for the support of sysfs interface. Make these
>> drivers depend on FB_DEVICE. They can later be fixed if necessary.
> Should that be a TODO in gpu/todo.rst?
> Otherwise the amount of people knowing about this
> is very close to 1.
> As an alternative add a TODO to each Kconfig file.
>
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>> drivers/staging/fbtft/Kconfig | 1 +
>> drivers/video/fbdev/Kconfig | 12 +++++++++
>> drivers/video/fbdev/core/Makefile | 7 +++---
>> drivers/video/fbdev/core/fb_internal.h | 32 ++++++++++++++++++++++++
>> drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
>> include/linux/fb.h | 2 ++
>> 6 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
>> index 4d29e8c1014e..5dda3c65a38e 100644
>> --- a/drivers/staging/fbtft/Kconfig
>> +++ b/drivers/staging/fbtft/Kconfig
>> @@ -2,6 +2,7 @@
>> menuconfig FB_TFT
>> tristate "Support for small TFT LCD display modules"
>> depends on FB && SPI
>> + depends on FB_DEVICE
>> depends on GPIOLIB || COMPILE_TEST
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 6df9bd09454a..48d9a14f889c 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
>> combination with certain motherboards and monitors are known to
>> suffer from this problem.
>>
>> +config FB_DEVICE
>> + bool "Provide legacy /dev/fb* device"
>> + depends on FB
>> + help
>> + Say Y here if you want the legacy /dev/fb* device file. It's
>> + only required if you have userspace programs that depend on
>> + fbdev for graphics output. This does not effect the framebuffer
>> + console.
> tabs to spaces to indent the above correct.
>
>> +
>> config FB_DDC
>> tristate
>> depends on FB
>> @@ -1545,6 +1554,7 @@ config FB_3DFX_I2C
>> config FB_VOODOO1
>> tristate "3Dfx Voodoo Graphics (sst1) support"
>> depends on FB && PCI
>> + depends on FB_DEVICE
>> select FB_CFB_FILLRECT
>> select FB_CFB_COPYAREA
>> select FB_CFB_IMAGEBLIT
>> @@ -1862,6 +1872,7 @@ config FB_SH_MOBILE_LCDC
>> tristate "SuperH Mobile LCDC framebuffer support"
>> depends on FB && HAVE_CLK && HAS_IOMEM
>> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
>> + depends on FB_DEVICE
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> select FB_SYS_IMAGEBLIT
>> @@ -1930,6 +1941,7 @@ config FB_SMSCUFX
>> config FB_UDL
>> tristate "Displaylink USB Framebuffer support"
>> depends on FB && USB
>> + depends on FB_DEVICE
>> select FB_MODE_HELPERS
>> select FB_SYS_FILLRECT
>> select FB_SYS_COPYAREA
>> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
>> index 125d24f50c36..d5e8772620f8 100644
>> --- a/drivers/video/fbdev/core/Makefile
>> +++ b/drivers/video/fbdev/core/Makefile
>> @@ -2,12 +2,13 @@
>> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
>> obj-$(CONFIG_FB) += fb.o
>> fb-y := fb_backlight.o \
>> - fb_devfs.o \
>> fb_info.o \
>> - fb_procfs.o \
>> - fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>> + fbmem.o fbmon.o fbcmap.o \
>> modedb.o fbcvt.o fb_cmdline.o fb_io_fops.o
>> fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
>> +fb-$(CONFIG_FB_DEVICE) += fb_devfs.o \
>> + fb_procfs.o \
>> + fbsysfs.o
> Maybe change this to one line to avoid '\'?
>
>>
>> ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE),y)
>> fb-y += fbcon.o bitblit.o softcursor.o
>> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
>> index 0b43c0cd5096..b8a28466db79 100644
>> --- a/drivers/video/fbdev/core/fb_internal.h
>> +++ b/drivers/video/fbdev/core/fb_internal.h
>> @@ -3,12 +3,22 @@
>> #ifndef _FB_INTERNAL_H
>> #define _FB_INTERNAL_H
>>
>> +#include <linux/device.h>
>> #include <linux/fb.h>
>> #include <linux/mutex.h>
>>
>> /* fb_devfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_register_chrdev(void);
>> void fb_unregister_chrdev(void);
>> +#else
>> +static inline int fb_register_chrdev(void)
>> +{
>> + return 0;
>> +}
>> +static inline void fb_unregister_chrdev(void)
>> +{ }
>> +#endif
>>
>> /* fbmem.c */
>> extern struct class *fb_class;
>> @@ -19,11 +29,33 @@ struct fb_info *get_fb_info(unsigned int idx);
>> void put_fb_info(struct fb_info *fb_info);
>>
>> /* fb_procfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_init_procfs(void);
>> void fb_cleanup_procfs(void);
>> +#else
>> +static inline int fb_init_procfs(void)
>> +{
>> + return 0;
>> +}
>> +static inline void fb_cleanup_procfs(void)
>> +{ }
>> +#endif
>>
>> /* fbsysfs.c */
>> +#if defined(CONFIG_FB_DEVICE)
>> int fb_device_create(struct fb_info *fb_info);
>> void fb_device_destroy(struct fb_info *fb_info);
>> +#else
>> +static inline int fb_device_create(struct fb_info *fb_info)
>> +{
>> + get_device(fb_info->device); // as in device_add()
>> +
>> + return 0;
>> +}
>> +static inline void fb_device_destroy(struct fb_info *fb_info)
>> +{
>> + put_device(fb_info->device); // as in device_del()
>> +}
>> +#endif
> I do not see why fb_device_{create,destroy} needs to call
> {get,put}_device - and it is not explained.
> A short explanation in the commit maybe?
Ok, I'll do that.
This get_device() is normally done within device_create() from within
register_framebuffer(). The put is within unregister_frambuffer().
Without, someone could attempt to unplug the Linux hardware device and
our pointer would go stale. So we have to hold the reference within fbdev.
Best regards
Thomas
>
> With my comments addressed:
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
> Note: I do not engage in the thread about the best Kconfig
> solution - I trust the involved people will find a good solution.
>
> Sam
>
>>
>> #endif
>> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
>> index 69f9cb03507e..21069fdb7cc2 100644
>> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
>> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
>> @@ -5,9 +5,9 @@ config OMAP2_VRFB
>> menuconfig FB_OMAP2
>> tristate "OMAP2+ frame buffer support"
>> depends on FB
>> + depends on FB_DEVICE
>> depends on DRM_OMAP = n
>> depends on GPIOLIB
>> -
>> select FB_OMAP2_DSS
>> select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
>> select FB_CFB_FILLRECT
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 541a0e3ce21f..40ed1028160c 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -481,7 +481,9 @@ struct fb_info {
>>
>> const struct fb_ops *fbops;
>> struct device *device; /* This is the parent */
>> +#if defined(CONFIG_FB_DEVICE)
>> struct device *dev; /* This is this fb device */
>> +#endif
>> int class_flag; /* private sysfs flags */
>> #ifdef CONFIG_FB_TILEBLITTING
>> struct fb_tile_ops *tileops; /* Tile Blitting */
>> --
>> 2.40.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount
2023-06-07 22:22 ` Javier Martinez Canillas
@ 2023-06-12 10:19 ` Thomas Zimmermann
2023-06-12 10:40 ` Javier Martinez Canillas
0 siblings, 1 reply; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-12 10:19 UTC (permalink / raw)
To: Javier Martinez Canillas, daniel, sam, deller, geert+renesas,
lee, daniel.thompson, jingoohan1
Cc: Steve Glendinning, linux-fbdev, linux-sh, linux-staging,
dri-devel, linux-omap
[-- Attachment #1.1: Type: text/plain, Size: 2094 bytes --]
Hi Javier
Am 08.06.23 um 00:22 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@suse.de> writes:
>
>> Detect registered instances of fb_info by reading the reference
>> counter from struct fb_info.read. Avoids looking at the dev field
>> and prepares fbdev for making struct fb_info.dev optional.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Steve Glendinning <steve.glendinning@shawell.net>
>> ---
>> drivers/video/fbdev/smscufx.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
>> index 17cec62cc65d..adb2b1fe8383 100644
>> --- a/drivers/video/fbdev/smscufx.c
>> +++ b/drivers/video/fbdev/smscufx.c
>> @@ -1496,7 +1496,7 @@ static int ufx_setup_modes(struct ufx_data *dev, struct fb_info *info,
>> u8 *edid;
>> int i, result = 0, tries = 3;
>>
>> - if (info->dev) /* only use mutex if info has been registered */
>> + if (refcount_read(&info->count)) /* only use mutex if info has been registered */
>
> The struct fb_info .count refcount is protected by the registration_lock
> mutex in register_framebuffer(). I think this operation isn't thread safe ?
It's an atomic read.
https://elixir.bootlin.com/linux/latest/source/include/linux/refcount.h#L147
And that function is only being called from the USB probe callback
before registering the framebuffer. It's not clear to me how the value
could be anything but zero. I'd best leave it as is with the ref counter.
https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/smscufx.c#L1706
Best regards
Thomas.
>
> But that was also the case for info->dev check, so I guess is OK and this
> change is for an old fbdev driver anyways.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 28/30] fbdev/core: Move file-I/O code into separate file
2023-06-07 20:48 ` Sam Ravnborg
@ 2023-06-12 10:35 ` Thomas Zimmermann
0 siblings, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-12 10:35 UTC (permalink / raw)
To: Sam Ravnborg
Cc: daniel.thompson, linux-staging, geert+renesas, linux-sh,
jingoohan1, deller, lee, javierm, dri-devel, linux-fbdev,
linux-omap
[-- Attachment #1.1: Type: text/plain, Size: 32405 bytes --]
Hi
Am 07.06.23 um 22:48 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Mon, Jun 05, 2023 at 04:48:10PM +0200, Thomas Zimmermann wrote:
>> Move fbdev's file-I/O code into a separate file and contain it in
>> init and cleanup helpers. No functional changes.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Consider moving the two helps as noted below.
> With or without this move:
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
>> ---
>> drivers/video/fbdev/core/Makefile | 1 +
>> drivers/video/fbdev/core/fb_devfs.c | 484 +++++++++++++++++++++++++
>> drivers/video/fbdev/core/fb_internal.h | 6 +
>> drivers/video/fbdev/core/fbmem.c | 478 +-----------------------
>> 4 files changed, 497 insertions(+), 472 deletions(-)
>> create mode 100644 drivers/video/fbdev/core/fb_devfs.c
>>
>> diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
>> index 665320160f70..125d24f50c36 100644
>> --- a/drivers/video/fbdev/core/Makefile
>> +++ b/drivers/video/fbdev/core/Makefile
>> @@ -2,6 +2,7 @@
>> obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
>> obj-$(CONFIG_FB) += fb.o
>> fb-y := fb_backlight.o \
>> + fb_devfs.o \
>> fb_info.o \
>> fb_procfs.o \
>> fbmem.o fbmon.o fbcmap.o fbsysfs.o \
>> diff --git a/drivers/video/fbdev/core/fb_devfs.c b/drivers/video/fbdev/core/fb_devfs.c
>> new file mode 100644
>> index 000000000000..5ab16cb24524
>> --- /dev/null
>> +++ b/drivers/video/fbdev/core/fb_devfs.c
> devfs gives me another understanding of what this file is used for.
> fb_ioctl.c?
I think fb_chrdev.c would be appropriate.
Best regards
Thomas
>
>> @@ -0,0 +1,484 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <linux/console.h>
>> +#include <linux/fb.h>
>> +#include <linux/fbcon.h>
>> +#include <linux/major.h>
>> +
>> +#include "fb_internal.h"
>> +
>> +/*
>> + * We hold a reference to the fb_info in file->private_data,
>> + * but if the current registered fb has changed, we don't
>> + * actually want to use it.
>> + *
>> + * So look up the fb_info using the inode minor number,
>> + * and just verify it against the reference we have.
>> + */
>> +static struct fb_info *file_fb_info(struct file *file)
>> +{
>> + struct inode *inode = file_inode(file);
>> + int fbidx = iminor(inode);
>> + struct fb_info *info = registered_fb[fbidx];
>> +
>> + if (info != file->private_data)
>> + info = NULL;
>> + return info;
>> +}
>> +
>> +static ssize_t fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
>> +{
>> + struct fb_info *info = file_fb_info(file);
>> +
>> + if (!info)
>> + return -ENODEV;
>> +
>> + if (info->state != FBINFO_STATE_RUNNING)
>> + return -EPERM;
>> +
>> + if (info->fbops->fb_read)
>> + return info->fbops->fb_read(info, buf, count, ppos);
>> +
>> + return fb_io_read(info, buf, count, ppos);
>> +}
>> +
>> +static ssize_t fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
>> +{
>> + struct fb_info *info = file_fb_info(file);
>> +
>> + if (!info)
>> + return -ENODEV;
>> +
>> + if (info->state != FBINFO_STATE_RUNNING)
>> + return -EPERM;
>> +
>> + if (info->fbops->fb_write)
>> + return info->fbops->fb_write(info, buf, count, ppos);
>> +
>> + return fb_io_write(info, buf, count, ppos);
>> +}
>> +
>> +static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + const struct fb_ops *fb;
>> + struct fb_var_screeninfo var;
>> + struct fb_fix_screeninfo fix;
>> + struct fb_cmap cmap_from;
>> + struct fb_cmap_user cmap;
>> + void __user *argp = (void __user *)arg;
>> + long ret = 0;
>> +
>> + switch (cmd) {
>> + case FBIOGET_VSCREENINFO:
>> + lock_fb_info(info);
>> + var = info->var;
>> + unlock_fb_info(info);
>> +
>> + ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
>> + break;
>> + case FBIOPUT_VSCREENINFO:
>> + if (copy_from_user(&var, argp, sizeof(var)))
>> + return -EFAULT;
>> + /* only for kernel-internal use */
>> + var.activate &= ~FB_ACTIVATE_KD_TEXT;
>> + console_lock();
>> + lock_fb_info(info);
>> + ret = fbcon_modechange_possible(info, &var);
>> + if (!ret)
>> + ret = fb_set_var(info, &var);
>> + if (!ret)
>> + fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
>> + unlock_fb_info(info);
>> + console_unlock();
>> + if (!ret && copy_to_user(argp, &var, sizeof(var)))
>> + ret = -EFAULT;
>> + break;
>> + case FBIOGET_FSCREENINFO:
>> + lock_fb_info(info);
>> + memcpy(&fix, &info->fix, sizeof(fix));
>> + if (info->flags & FBINFO_HIDE_SMEM_START)
>> + fix.smem_start = 0;
>> + unlock_fb_info(info);
>> +
>> + ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
>> + break;
>> + case FBIOPUTCMAP:
>> + if (copy_from_user(&cmap, argp, sizeof(cmap)))
>> + return -EFAULT;
>> + ret = fb_set_user_cmap(&cmap, info);
>> + break;
>> + case FBIOGETCMAP:
>> + if (copy_from_user(&cmap, argp, sizeof(cmap)))
>> + return -EFAULT;
>> + lock_fb_info(info);
>> + cmap_from = info->cmap;
>> + unlock_fb_info(info);
>> + ret = fb_cmap_to_user(&cmap_from, &cmap);
>> + break;
>> + case FBIOPAN_DISPLAY:
>> + if (copy_from_user(&var, argp, sizeof(var)))
>> + return -EFAULT;
>> + console_lock();
>> + lock_fb_info(info);
>> + ret = fb_pan_display(info, &var);
>> + unlock_fb_info(info);
>> + console_unlock();
>> + if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
>> + return -EFAULT;
>> + break;
>> + case FBIO_CURSOR:
>> + ret = -EINVAL;
>> + break;
>> + case FBIOGET_CON2FBMAP:
>> + ret = fbcon_get_con2fb_map_ioctl(argp);
>> + break;
>> + case FBIOPUT_CON2FBMAP:
>> + ret = fbcon_set_con2fb_map_ioctl(argp);
>> + break;
>> + case FBIOBLANK:
>> + if (arg > FB_BLANK_POWERDOWN)
>> + return -EINVAL;
>> + console_lock();
>> + lock_fb_info(info);
>> + ret = fb_blank(info, arg);
>> + /* might again call into fb_blank */
>> + fbcon_fb_blanked(info, arg);
>> + unlock_fb_info(info);
>> + console_unlock();
>> + break;
>> + default:
>> + lock_fb_info(info);
>> + fb = info->fbops;
>> + if (fb->fb_ioctl)
>> + ret = fb->fb_ioctl(info, cmd, arg);
>> + else
>> + ret = -ENOTTY;
>> + unlock_fb_info(info);
>> + }
>> + return ret;
>> +}
>> +
>> +static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>> +{
>> + struct fb_info *info = file_fb_info(file);
>> +
>> + if (!info)
>> + return -ENODEV;
>> + return do_fb_ioctl(info, cmd, arg);
>> +}
>> +
>> +#ifdef CONFIG_COMPAT
>> +struct fb_fix_screeninfo32 {
>> + char id[16];
>> + compat_caddr_t smem_start;
>> + u32 smem_len;
>> + u32 type;
>> + u32 type_aux;
>> + u32 visual;
>> + u16 xpanstep;
>> + u16 ypanstep;
>> + u16 ywrapstep;
>> + u32 line_length;
>> + compat_caddr_t mmio_start;
>> + u32 mmio_len;
>> + u32 accel;
>> + u16 reserved[3];
>> +};
>> +
>> +struct fb_cmap32 {
>> + u32 start;
>> + u32 len;
>> + compat_caddr_t red;
>> + compat_caddr_t green;
>> + compat_caddr_t blue;
>> + compat_caddr_t transp;
>> +};
>> +
>> +static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + struct fb_cmap32 cmap32;
>> + struct fb_cmap cmap_from;
>> + struct fb_cmap_user cmap;
>> +
>> + if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
>> + return -EFAULT;
>> +
>> + cmap = (struct fb_cmap_user) {
>> + .start = cmap32.start,
>> + .len = cmap32.len,
>> + .red = compat_ptr(cmap32.red),
>> + .green = compat_ptr(cmap32.green),
>> + .blue = compat_ptr(cmap32.blue),
>> + .transp = compat_ptr(cmap32.transp),
>> + };
>> +
>> + if (cmd == FBIOPUTCMAP)
>> + return fb_set_user_cmap(&cmap, info);
>> +
>> + lock_fb_info(info);
>> + cmap_from = info->cmap;
>> + unlock_fb_info(info);
>> +
>> + return fb_cmap_to_user(&cmap_from, &cmap);
>> +}
>> +
>> +static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
>> + struct fb_fix_screeninfo32 __user *fix32)
>> +{
>> + __u32 data;
>> + int err;
>> +
>> + err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
>> +
>> + data = (__u32) (unsigned long) fix->smem_start;
>> + err |= put_user(data, &fix32->smem_start);
>> +
>> + err |= put_user(fix->smem_len, &fix32->smem_len);
>> + err |= put_user(fix->type, &fix32->type);
>> + err |= put_user(fix->type_aux, &fix32->type_aux);
>> + err |= put_user(fix->visual, &fix32->visual);
>> + err |= put_user(fix->xpanstep, &fix32->xpanstep);
>> + err |= put_user(fix->ypanstep, &fix32->ypanstep);
>> + err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
>> + err |= put_user(fix->line_length, &fix32->line_length);
>> +
>> + data = (__u32) (unsigned long) fix->mmio_start;
>> + err |= put_user(data, &fix32->mmio_start);
>> +
>> + err |= put_user(fix->mmio_len, &fix32->mmio_len);
>> + err |= put_user(fix->accel, &fix32->accel);
>> + err |= copy_to_user(fix32->reserved, fix->reserved,
>> + sizeof(fix->reserved));
>> +
>> + if (err)
>> + return -EFAULT;
>> + return 0;
>> +}
>> +
>> +static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + struct fb_fix_screeninfo fix;
>> +
>> + lock_fb_info(info);
>> + fix = info->fix;
>> + if (info->flags & FBINFO_HIDE_SMEM_START)
>> + fix.smem_start = 0;
>> + unlock_fb_info(info);
>> + return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
>> +}
>> +
>> +static long fb_compat_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + struct fb_info *info = file_fb_info(file);
>> + const struct fb_ops *fb;
>> + long ret = -ENOIOCTLCMD;
>> +
>> + if (!info)
>> + return -ENODEV;
>> + fb = info->fbops;
>> + switch (cmd) {
>> + case FBIOGET_VSCREENINFO:
>> + case FBIOPUT_VSCREENINFO:
>> + case FBIOPAN_DISPLAY:
>> + case FBIOGET_CON2FBMAP:
>> + case FBIOPUT_CON2FBMAP:
>> + arg = (unsigned long) compat_ptr(arg);
>> + fallthrough;
>> + case FBIOBLANK:
>> + ret = do_fb_ioctl(info, cmd, arg);
>> + break;
>> +
>> + case FBIOGET_FSCREENINFO:
>> + ret = fb_get_fscreeninfo(info, cmd, arg);
>> + break;
>> +
>> + case FBIOGETCMAP:
>> + case FBIOPUTCMAP:
>> + ret = fb_getput_cmap(info, cmd, arg);
>> + break;
>> +
>> + default:
>> + if (fb->fb_compat_ioctl)
>> + ret = fb->fb_compat_ioctl(info, cmd, arg);
>> + break;
>> + }
>> + return ret;
>> +}
>> +#endif
>> +
>> +static int fb_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> + struct fb_info *info = file_fb_info(file);
>> + unsigned long mmio_pgoff;
>> + unsigned long start;
>> + u32 len;
>> +
>> + if (!info)
>> + return -ENODEV;
>> + mutex_lock(&info->mm_lock);
>> +
>> + if (info->fbops->fb_mmap) {
>> + int res;
>> +
>> + /*
>> + * The framebuffer needs to be accessed decrypted, be sure
>> + * SME protection is removed ahead of the call
>> + */
>> + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>> + res = info->fbops->fb_mmap(info, vma);
>> + mutex_unlock(&info->mm_lock);
>> + return res;
>> +#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
>> + } else if (info->fbdefio) {
>> + /*
>> + * FB deferred I/O wants you to handle mmap in your drivers. At a
>> + * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
>> + */
>> + dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
>> + mutex_unlock(&info->mm_lock);
>> + return -ENODEV;
>> +#endif
>> + }
>> +
>> + /*
>> + * Ugh. This can be either the frame buffer mapping, or
>> + * if pgoff points past it, the mmio mapping.
>> + */
>> + start = info->fix.smem_start;
>> + len = info->fix.smem_len;
>> + mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
>> + if (vma->vm_pgoff >= mmio_pgoff) {
>> + if (info->var.accel_flags) {
>> + mutex_unlock(&info->mm_lock);
>> + return -EINVAL;
>> + }
>> +
>> + vma->vm_pgoff -= mmio_pgoff;
>> + start = info->fix.mmio_start;
>> + len = info->fix.mmio_len;
>> + }
>> + mutex_unlock(&info->mm_lock);
>> +
>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>> + fb_pgprotect(file, vma, start);
>> +
>> + return vm_iomap_memory(vma, start, len);
>> +}
>> +
>> +static int fb_open(struct inode *inode, struct file *file)
>> +__acquires(&info->lock)
>> +__releases(&info->lock)
>> +{
>> + int fbidx = iminor(inode);
>> + struct fb_info *info;
>> + int res = 0;
>> +
>> + info = get_fb_info(fbidx);
>> + if (!info) {
>> + request_module("fb%d", fbidx);
>> + info = get_fb_info(fbidx);
>> + if (!info)
>> + return -ENODEV;
>> + }
>> + if (IS_ERR(info))
>> + return PTR_ERR(info);
>> +
>> + lock_fb_info(info);
>> + if (!try_module_get(info->fbops->owner)) {
>> + res = -ENODEV;
>> + goto out;
>> + }
>> + file->private_data = info;
>> + if (info->fbops->fb_open) {
>> + res = info->fbops->fb_open(info, 1);
>> + if (res)
>> + module_put(info->fbops->owner);
>> + }
>> +#ifdef CONFIG_FB_DEFERRED_IO
>> + if (info->fbdefio)
>> + fb_deferred_io_open(info, inode, file);
>> +#endif
>> +out:
>> + unlock_fb_info(info);
>> + if (res)
>> + put_fb_info(info);
>> + return res;
>> +}
>> +
>> +static int fb_release(struct inode *inode, struct file *file)
>> +__acquires(&info->lock)
>> +__releases(&info->lock)
>> +{
>> + struct fb_info * const info = file->private_data;
>> +
>> + lock_fb_info(info);
>> +#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
>> + if (info->fbdefio)
>> + fb_deferred_io_release(info);
>> +#endif
>> + if (info->fbops->fb_release)
>> + info->fbops->fb_release(info, 1);
>> + module_put(info->fbops->owner);
>> + unlock_fb_info(info);
>> + put_fb_info(info);
>> + return 0;
>> +}
>> +
>> +#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
>> +static unsigned long get_fb_unmapped_area(struct file *filp,
>> + unsigned long addr, unsigned long len,
>> + unsigned long pgoff, unsigned long flags)
>> +{
>> + struct fb_info * const info = filp->private_data;
>> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
>> +
>> + if (pgoff > fb_size || len > fb_size - pgoff)
>> + return -EINVAL;
>> +
>> + return (unsigned long)info->screen_base + pgoff;
>> +}
>> +#endif
>> +
>> +static const struct file_operations fb_fops = {
>> + .owner = THIS_MODULE,
>> + .read = fb_read,
>> + .write = fb_write,
>> + .unlocked_ioctl = fb_ioctl,
>> +#ifdef CONFIG_COMPAT
>> + .compat_ioctl = fb_compat_ioctl,
>> +#endif
>> + .mmap = fb_mmap,
>> + .open = fb_open,
>> + .release = fb_release,
>> +#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
>> + (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
>> + !defined(CONFIG_MMU))
>> + .get_unmapped_area = get_fb_unmapped_area,
>> +#endif
>> +#ifdef CONFIG_FB_DEFERRED_IO
>> + .fsync = fb_deferred_io_fsync,
>> +#endif
>> + .llseek = default_llseek,
>> +};
>> +
>> +int fb_register_chrdev(void)
>> +{
>> + int ret;
>> +
>> + ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
>> + if (ret) {
>> + pr_err("Unable to get major %d for fb devs\n", FB_MAJOR);
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +void fb_unregister_chrdev(void)
>> +{
>> + unregister_chrdev(FB_MAJOR, "fb");
>> +}
>> diff --git a/drivers/video/fbdev/core/fb_internal.h b/drivers/video/fbdev/core/fb_internal.h
>> index 51f7c9f04e45..abe06c9da36e 100644
>> --- a/drivers/video/fbdev/core/fb_internal.h
>> +++ b/drivers/video/fbdev/core/fb_internal.h
>> @@ -6,10 +6,16 @@
>> #include <linux/fb.h>
>> #include <linux/mutex.h>
>>
>> +/* fb_devfs.c */
>> +int fb_register_chrdev(void);
>> +void fb_unregister_chrdev(void);
>> +
>> /* fbmem.c */
>> extern struct mutex registration_lock;
>> extern struct fb_info *registered_fb[FB_MAX];
>> extern int num_registered_fb;
>> +struct fb_info *get_fb_info(unsigned int idx);
>> +void put_fb_info(struct fb_info *fb_info);
> The only users of get_fb_info() and put_fb_info() are now in fb_devfs.
> So consider moving these two helpers too.
>
>>
>> /* fb_procfs.c */
>> int fb_init_procfs(void);
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index de1e45240161..2d26ac46337b 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -17,7 +17,6 @@
>> #include <linux/types.h>
>> #include <linux/errno.h>
>> #include <linux/kernel.h>
>> -#include <linux/major.h>
>> #include <linux/slab.h>
>> #include <linux/mm.h>
>> #include <linux/mman.h>
>> @@ -54,7 +53,7 @@ bool fb_center_logo __read_mostly;
>>
>> int fb_logo_count __read_mostly = -1;
>>
>> -static struct fb_info *get_fb_info(unsigned int idx)
>> +struct fb_info *get_fb_info(unsigned int idx)
>> {
>> struct fb_info *fb_info;
>>
>> @@ -70,7 +69,7 @@ static struct fb_info *get_fb_info(unsigned int idx)
>> return fb_info;
>> }
>>
>> -static void put_fb_info(struct fb_info *fb_info)
>> +void put_fb_info(struct fb_info *fb_info)
>> {
>> if (!refcount_dec_and_test(&fb_info->count))
>> return;
>> @@ -699,59 +698,6 @@ int fb_show_logo(struct fb_info *info, int rotate) { return 0; }
>> EXPORT_SYMBOL(fb_prepare_logo);
>> EXPORT_SYMBOL(fb_show_logo);
>
> Reminds me - consider moving logo stuff to a fb_logo file.
> This would reduce fbmem with a lot of lines, and it is separate.
> But it is outside the goal of this patchset.
>
>>
>> -/*
>> - * We hold a reference to the fb_info in file->private_data,
>> - * but if the current registered fb has changed, we don't
>> - * actually want to use it.
>> - *
>> - * So look up the fb_info using the inode minor number,
>> - * and just verify it against the reference we have.
>> - */
>> -static struct fb_info *file_fb_info(struct file *file)
>> -{
>> - struct inode *inode = file_inode(file);
>> - int fbidx = iminor(inode);
>> - struct fb_info *info = registered_fb[fbidx];
>> -
>> - if (info != file->private_data)
>> - info = NULL;
>> - return info;
>> -}
>> -
>> -static ssize_t
>> -fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
>> -{
>> - struct fb_info *info = file_fb_info(file);
>> -
>> - if (!info)
>> - return -ENODEV;
>> -
>> - if (info->state != FBINFO_STATE_RUNNING)
>> - return -EPERM;
>> -
>> - if (info->fbops->fb_read)
>> - return info->fbops->fb_read(info, buf, count, ppos);
>> -
>> - return fb_io_read(info, buf, count, ppos);
>> -}
>> -
>> -static ssize_t
>> -fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
>> -{
>> - struct fb_info *info = file_fb_info(file);
>> -
>> - if (!info)
>> - return -ENODEV;
>> -
>> - if (info->state != FBINFO_STATE_RUNNING)
>> - return -EPERM;
>> -
>> - if (info->fbops->fb_write)
>> - return info->fbops->fb_write(info, buf, count, ppos);
>> -
>> - return fb_io_write(info, buf, count, ppos);
>> -}
>> -
>> int
>> fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var)
>> {
>> @@ -951,416 +897,6 @@ fb_blank(struct fb_info *info, int blank)
>> }
>> EXPORT_SYMBOL(fb_blank);
>>
>> -static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>> - unsigned long arg)
>> -{
>> - const struct fb_ops *fb;
>> - struct fb_var_screeninfo var;
>> - struct fb_fix_screeninfo fix;
>> - struct fb_cmap cmap_from;
>> - struct fb_cmap_user cmap;
>> - void __user *argp = (void __user *)arg;
>> - long ret = 0;
>> -
>> - switch (cmd) {
>> - case FBIOGET_VSCREENINFO:
>> - lock_fb_info(info);
>> - var = info->var;
>> - unlock_fb_info(info);
>> -
>> - ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
>> - break;
>> - case FBIOPUT_VSCREENINFO:
>> - if (copy_from_user(&var, argp, sizeof(var)))
>> - return -EFAULT;
>> - /* only for kernel-internal use */
>> - var.activate &= ~FB_ACTIVATE_KD_TEXT;
>> - console_lock();
>> - lock_fb_info(info);
>> - ret = fbcon_modechange_possible(info, &var);
>> - if (!ret)
>> - ret = fb_set_var(info, &var);
>> - if (!ret)
>> - fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
>> - unlock_fb_info(info);
>> - console_unlock();
>> - if (!ret && copy_to_user(argp, &var, sizeof(var)))
>> - ret = -EFAULT;
>> - break;
>> - case FBIOGET_FSCREENINFO:
>> - lock_fb_info(info);
>> - memcpy(&fix, &info->fix, sizeof(fix));
>> - if (info->flags & FBINFO_HIDE_SMEM_START)
>> - fix.smem_start = 0;
>> - unlock_fb_info(info);
>> -
>> - ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
>> - break;
>> - case FBIOPUTCMAP:
>> - if (copy_from_user(&cmap, argp, sizeof(cmap)))
>> - return -EFAULT;
>> - ret = fb_set_user_cmap(&cmap, info);
>> - break;
>> - case FBIOGETCMAP:
>> - if (copy_from_user(&cmap, argp, sizeof(cmap)))
>> - return -EFAULT;
>> - lock_fb_info(info);
>> - cmap_from = info->cmap;
>> - unlock_fb_info(info);
>> - ret = fb_cmap_to_user(&cmap_from, &cmap);
>> - break;
>> - case FBIOPAN_DISPLAY:
>> - if (copy_from_user(&var, argp, sizeof(var)))
>> - return -EFAULT;
>> - console_lock();
>> - lock_fb_info(info);
>> - ret = fb_pan_display(info, &var);
>> - unlock_fb_info(info);
>> - console_unlock();
>> - if (ret == 0 && copy_to_user(argp, &var, sizeof(var)))
>> - return -EFAULT;
>> - break;
>> - case FBIO_CURSOR:
>> - ret = -EINVAL;
>> - break;
>> - case FBIOGET_CON2FBMAP:
>> - ret = fbcon_get_con2fb_map_ioctl(argp);
>> - break;
>> - case FBIOPUT_CON2FBMAP:
>> - ret = fbcon_set_con2fb_map_ioctl(argp);
>> - break;
>> - case FBIOBLANK:
>> - if (arg > FB_BLANK_POWERDOWN)
>> - return -EINVAL;
>> - console_lock();
>> - lock_fb_info(info);
>> - ret = fb_blank(info, arg);
>> - /* might again call into fb_blank */
>> - fbcon_fb_blanked(info, arg);
>> - unlock_fb_info(info);
>> - console_unlock();
>> - break;
>> - default:
>> - lock_fb_info(info);
>> - fb = info->fbops;
>> - if (fb->fb_ioctl)
>> - ret = fb->fb_ioctl(info, cmd, arg);
>> - else
>> - ret = -ENOTTY;
>> - unlock_fb_info(info);
>> - }
>> - return ret;
>> -}
>> -
>> -static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>> -{
>> - struct fb_info *info = file_fb_info(file);
>> -
>> - if (!info)
>> - return -ENODEV;
>> - return do_fb_ioctl(info, cmd, arg);
>> -}
>> -
>> -#ifdef CONFIG_COMPAT
>> -struct fb_fix_screeninfo32 {
>> - char id[16];
>> - compat_caddr_t smem_start;
>> - u32 smem_len;
>> - u32 type;
>> - u32 type_aux;
>> - u32 visual;
>> - u16 xpanstep;
>> - u16 ypanstep;
>> - u16 ywrapstep;
>> - u32 line_length;
>> - compat_caddr_t mmio_start;
>> - u32 mmio_len;
>> - u32 accel;
>> - u16 reserved[3];
>> -};
>> -
>> -struct fb_cmap32 {
>> - u32 start;
>> - u32 len;
>> - compat_caddr_t red;
>> - compat_caddr_t green;
>> - compat_caddr_t blue;
>> - compat_caddr_t transp;
>> -};
>> -
>> -static int fb_getput_cmap(struct fb_info *info, unsigned int cmd,
>> - unsigned long arg)
>> -{
>> - struct fb_cmap32 cmap32;
>> - struct fb_cmap cmap_from;
>> - struct fb_cmap_user cmap;
>> -
>> - if (copy_from_user(&cmap32, compat_ptr(arg), sizeof(cmap32)))
>> - return -EFAULT;
>> -
>> - cmap = (struct fb_cmap_user) {
>> - .start = cmap32.start,
>> - .len = cmap32.len,
>> - .red = compat_ptr(cmap32.red),
>> - .green = compat_ptr(cmap32.green),
>> - .blue = compat_ptr(cmap32.blue),
>> - .transp = compat_ptr(cmap32.transp),
>> - };
>> -
>> - if (cmd == FBIOPUTCMAP)
>> - return fb_set_user_cmap(&cmap, info);
>> -
>> - lock_fb_info(info);
>> - cmap_from = info->cmap;
>> - unlock_fb_info(info);
>> -
>> - return fb_cmap_to_user(&cmap_from, &cmap);
>> -}
>> -
>> -static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix,
>> - struct fb_fix_screeninfo32 __user *fix32)
>> -{
>> - __u32 data;
>> - int err;
>> -
>> - err = copy_to_user(&fix32->id, &fix->id, sizeof(fix32->id));
>> -
>> - data = (__u32) (unsigned long) fix->smem_start;
>> - err |= put_user(data, &fix32->smem_start);
>> -
>> - err |= put_user(fix->smem_len, &fix32->smem_len);
>> - err |= put_user(fix->type, &fix32->type);
>> - err |= put_user(fix->type_aux, &fix32->type_aux);
>> - err |= put_user(fix->visual, &fix32->visual);
>> - err |= put_user(fix->xpanstep, &fix32->xpanstep);
>> - err |= put_user(fix->ypanstep, &fix32->ypanstep);
>> - err |= put_user(fix->ywrapstep, &fix32->ywrapstep);
>> - err |= put_user(fix->line_length, &fix32->line_length);
>> -
>> - data = (__u32) (unsigned long) fix->mmio_start;
>> - err |= put_user(data, &fix32->mmio_start);
>> -
>> - err |= put_user(fix->mmio_len, &fix32->mmio_len);
>> - err |= put_user(fix->accel, &fix32->accel);
>> - err |= copy_to_user(fix32->reserved, fix->reserved,
>> - sizeof(fix->reserved));
>> -
>> - if (err)
>> - return -EFAULT;
>> - return 0;
>> -}
>> -
>> -static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
>> - unsigned long arg)
>> -{
>> - struct fb_fix_screeninfo fix;
>> -
>> - lock_fb_info(info);
>> - fix = info->fix;
>> - if (info->flags & FBINFO_HIDE_SMEM_START)
>> - fix.smem_start = 0;
>> - unlock_fb_info(info);
>> - return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
>> -}
>> -
>> -static long fb_compat_ioctl(struct file *file, unsigned int cmd,
>> - unsigned long arg)
>> -{
>> - struct fb_info *info = file_fb_info(file);
>> - const struct fb_ops *fb;
>> - long ret = -ENOIOCTLCMD;
>> -
>> - if (!info)
>> - return -ENODEV;
>> - fb = info->fbops;
>> - switch(cmd) {
>> - case FBIOGET_VSCREENINFO:
>> - case FBIOPUT_VSCREENINFO:
>> - case FBIOPAN_DISPLAY:
>> - case FBIOGET_CON2FBMAP:
>> - case FBIOPUT_CON2FBMAP:
>> - arg = (unsigned long) compat_ptr(arg);
>> - fallthrough;
>> - case FBIOBLANK:
>> - ret = do_fb_ioctl(info, cmd, arg);
>> - break;
>> -
>> - case FBIOGET_FSCREENINFO:
>> - ret = fb_get_fscreeninfo(info, cmd, arg);
>> - break;
>> -
>> - case FBIOGETCMAP:
>> - case FBIOPUTCMAP:
>> - ret = fb_getput_cmap(info, cmd, arg);
>> - break;
>> -
>> - default:
>> - if (fb->fb_compat_ioctl)
>> - ret = fb->fb_compat_ioctl(info, cmd, arg);
>> - break;
>> - }
>> - return ret;
>> -}
>> -#endif
>> -
>> -static int
>> -fb_mmap(struct file *file, struct vm_area_struct * vma)
>> -{
>> - struct fb_info *info = file_fb_info(file);
>> - unsigned long mmio_pgoff;
>> - unsigned long start;
>> - u32 len;
>> -
>> - if (!info)
>> - return -ENODEV;
>> - mutex_lock(&info->mm_lock);
>> -
>> - if (info->fbops->fb_mmap) {
>> - int res;
>> -
>> - /*
>> - * The framebuffer needs to be accessed decrypted, be sure
>> - * SME protection is removed ahead of the call
>> - */
>> - vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>> - res = info->fbops->fb_mmap(info, vma);
>> - mutex_unlock(&info->mm_lock);
>> - return res;
>> -#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
>> - } else if (info->fbdefio) {
>> - /*
>> - * FB deferred I/O wants you to handle mmap in your drivers. At a
>> - * minimum, point struct fb_ops.fb_mmap to fb_deferred_io_mmap().
>> - */
>> - dev_warn_once(info->dev, "fbdev mmap not set up for deferred I/O.\n");
>> - mutex_unlock(&info->mm_lock);
>> - return -ENODEV;
>> -#endif
>> - }
>> -
>> - /*
>> - * Ugh. This can be either the frame buffer mapping, or
>> - * if pgoff points past it, the mmio mapping.
>> - */
>> - start = info->fix.smem_start;
>> - len = info->fix.smem_len;
>> - mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
>> - if (vma->vm_pgoff >= mmio_pgoff) {
>> - if (info->var.accel_flags) {
>> - mutex_unlock(&info->mm_lock);
>> - return -EINVAL;
>> - }
>> -
>> - vma->vm_pgoff -= mmio_pgoff;
>> - start = info->fix.mmio_start;
>> - len = info->fix.mmio_len;
>> - }
>> - mutex_unlock(&info->mm_lock);
>> -
>> - vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>> - fb_pgprotect(file, vma, start);
>> -
>> - return vm_iomap_memory(vma, start, len);
>> -}
>> -
>> -static int
>> -fb_open(struct inode *inode, struct file *file)
>> -__acquires(&info->lock)
>> -__releases(&info->lock)
>> -{
>> - int fbidx = iminor(inode);
>> - struct fb_info *info;
>> - int res = 0;
>> -
>> - info = get_fb_info(fbidx);
>> - if (!info) {
>> - request_module("fb%d", fbidx);
>> - info = get_fb_info(fbidx);
>> - if (!info)
>> - return -ENODEV;
>> - }
>> - if (IS_ERR(info))
>> - return PTR_ERR(info);
>> -
>> - lock_fb_info(info);
>> - if (!try_module_get(info->fbops->owner)) {
>> - res = -ENODEV;
>> - goto out;
>> - }
>> - file->private_data = info;
>> - if (info->fbops->fb_open) {
>> - res = info->fbops->fb_open(info,1);
>> - if (res)
>> - module_put(info->fbops->owner);
>> - }
>> -#ifdef CONFIG_FB_DEFERRED_IO
>> - if (info->fbdefio)
>> - fb_deferred_io_open(info, inode, file);
>> -#endif
>> -out:
>> - unlock_fb_info(info);
>> - if (res)
>> - put_fb_info(info);
>> - return res;
>> -}
>> -
>> -static int
>> -fb_release(struct inode *inode, struct file *file)
>> -__acquires(&info->lock)
>> -__releases(&info->lock)
>> -{
>> - struct fb_info * const info = file->private_data;
>> -
>> - lock_fb_info(info);
>> -#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
>> - if (info->fbdefio)
>> - fb_deferred_io_release(info);
>> -#endif
>> - if (info->fbops->fb_release)
>> - info->fbops->fb_release(info,1);
>> - module_put(info->fbops->owner);
>> - unlock_fb_info(info);
>> - put_fb_info(info);
>> - return 0;
>> -}
>> -
>> -#if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
>> -static unsigned long get_fb_unmapped_area(struct file *filp,
>> - unsigned long addr, unsigned long len,
>> - unsigned long pgoff, unsigned long flags)
>> -{
>> - struct fb_info * const info = filp->private_data;
>> - unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
>> -
>> - if (pgoff > fb_size || len > fb_size - pgoff)
>> - return -EINVAL;
>> -
>> - return (unsigned long)info->screen_base + pgoff;
>> -}
>> -#endif
>> -
>> -static const struct file_operations fb_fops = {
>> - .owner = THIS_MODULE,
>> - .read = fb_read,
>> - .write = fb_write,
>> - .unlocked_ioctl = fb_ioctl,
>> -#ifdef CONFIG_COMPAT
>> - .compat_ioctl = fb_compat_ioctl,
>> -#endif
>> - .mmap = fb_mmap,
>> - .open = fb_open,
>> - .release = fb_release,
>> -#if defined(HAVE_ARCH_FB_UNMAPPED_AREA) || \
>> - (defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && \
>> - !defined(CONFIG_MMU))
>> - .get_unmapped_area = get_fb_unmapped_area,
>> -#endif
>> -#ifdef CONFIG_FB_DEFERRED_IO
>> - .fsync = fb_deferred_io_fsync,
>> -#endif
>> - .llseek = default_llseek,
>> -};
>> -
>> struct class *fb_class;
>> EXPORT_SYMBOL(fb_class);
>>
>> @@ -1588,11 +1124,9 @@ fbmem_init(void)
>> if (ret)
>> return ret;
>>
>> - ret = register_chrdev(FB_MAJOR, "fb", &fb_fops);
>> - if (ret) {
>> - printk("unable to get major %d for fb devs\n", FB_MAJOR);
>> + ret = fb_register_chrdev();
>> + if (ret)
>> goto err_chrdev;
>> - }
>>
>> fb_class = class_create("graphics");
>> if (IS_ERR(fb_class)) {
>> @@ -1607,7 +1141,7 @@ fbmem_init(void)
>> return 0;
>>
>> err_class:
>> - unregister_chrdev(FB_MAJOR, "fb");
>> + fb_unregister_chrdev();
>> err_chrdev:
>> fb_cleanup_procfs();
>> return ret;
>> @@ -1622,7 +1156,7 @@ fbmem_exit(void)
>>
>> fb_cleanup_procfs();
>> class_destroy(fb_class);
>> - unregister_chrdev(FB_MAJOR, "fb");
>> + fb_unregister_chrdev();
>> }
>>
>> module_exit(fbmem_exit);
>> --
>> 2.40.1
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount
2023-06-12 10:19 ` Thomas Zimmermann
@ 2023-06-12 10:40 ` Javier Martinez Canillas
0 siblings, 0 replies; 99+ messages in thread
From: Javier Martinez Canillas @ 2023-06-12 10:40 UTC (permalink / raw)
To: Thomas Zimmermann, daniel, sam, deller, geert+renesas, lee,
daniel.thompson, jingoohan1
Cc: Steve Glendinning, linux-fbdev, linux-sh, linux-staging,
dri-devel, linux-omap
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> Hi Javier
>
> Am 08.06.23 um 00:22 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann <tzimmermann@suse.de> writes:
>>
>>> Detect registered instances of fb_info by reading the reference
>>> counter from struct fb_info.read. Avoids looking at the dev field
>>> and prepares fbdev for making struct fb_info.dev optional.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Steve Glendinning <steve.glendinning@shawell.net>
>>> ---
>>> drivers/video/fbdev/smscufx.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
>>> index 17cec62cc65d..adb2b1fe8383 100644
>>> --- a/drivers/video/fbdev/smscufx.c
>>> +++ b/drivers/video/fbdev/smscufx.c
>>> @@ -1496,7 +1496,7 @@ static int ufx_setup_modes(struct ufx_data *dev, struct fb_info *info,
>>> u8 *edid;
>>> int i, result = 0, tries = 3;
>>>
>>> - if (info->dev) /* only use mutex if info has been registered */
>>> + if (refcount_read(&info->count)) /* only use mutex if info has been registered */
>>
>> The struct fb_info .count refcount is protected by the registration_lock
>> mutex in register_framebuffer(). I think this operation isn't thread safe ?
>
> It's an atomic read.
>
> https://elixir.bootlin.com/linux/latest/source/include/linux/refcount.h#L147
>
Yes, is an atomic read but by reading [0] my understanding is that does
not provide memory ordering guarantees. Maybe I misunderstood though...
[0]: https://www.kernel.org/doc/html/latest/core-api/refcount-vs-atomic.html
> And that function is only being called from the USB probe callback
> before registering the framebuffer. It's not clear to me how the value
> could be anything but zero. I'd best leave it as is with the ref counter.
>
Yes, I'm OK with that and as mentioned I don't think that's less safe
than the previous info->dev check with regard to race conditions.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
2023-06-07 8:35 ` [PATCH 00/30] fbdev: Make userspace interfaces optional Geert Uytterhoeven
@ 2023-06-12 10:46 ` Thomas Zimmermann
0 siblings, 0 replies; 99+ messages in thread
From: Thomas Zimmermann @ 2023-06-12 10:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: daniel, javierm, sam, deller, lee, daniel.thompson, jingoohan1,
linux-fbdev, dri-devel, linux-sh, linux-omap, linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 722 bytes --]
Hi
Am 07.06.23 um 10:35 schrieb Geert Uytterhoeven:
[...]
>
> BTW, I am wondering if it would be possible to write a DRM emulation
> layer on top of (basic, e.g. no MMIO, just fb) fbdev?
That exists, sort of. I first posted it here:
https://patchwork.freedesktop.org/series/58569/
and it has later been transformed into these conversion helpers that I
have somewhere on gitlab.
Best regards
Thomas
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 99+ messages in thread
end of thread, other threads:[~2023-06-12 10:46 UTC | newest]
Thread overview: 99+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-05 14:47 [PATCH 00/30] fbdev: Make userspace interfaces optional Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device Thomas Zimmermann
2023-06-07 7:30 ` Javier Martinez Canillas
2023-06-07 7:34 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 02/30] backlight/gpio_backlight: " Thomas Zimmermann
2023-06-05 20:19 ` Ruhl, Michael J
2023-06-05 20:23 ` Sam Ravnborg
2023-06-05 20:41 ` Ruhl, Michael J
2023-06-06 7:24 ` Thomas Zimmermann
2023-06-06 7:49 ` Dan Carpenter
2023-06-06 8:05 ` Thomas Zimmermann
2023-06-05 14:47 ` [PATCH 03/30] backlight/lv5207lp: " Thomas Zimmermann
2023-06-07 7:35 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
2023-06-07 7:36 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-07 7:41 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
2023-06-07 7:42 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-07 7:55 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device Thomas Zimmermann
2023-06-07 7:55 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from " Thomas Zimmermann
2023-06-07 8:47 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err() Thomas Zimmermann
2023-06-07 8:59 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev Thomas Zimmermann
2023-06-06 5:26 ` Dan Carpenter
2023-06-07 9:00 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err() Thomas Zimmermann
2023-06-07 9:00 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err() Thomas Zimmermann
2023-06-07 9:01 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
2023-06-07 9:02 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-07 9:02 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev Thomas Zimmermann
2023-06-07 9:09 ` Javier Martinez Canillas
2023-06-05 14:47 ` [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup Thomas Zimmermann
2023-06-07 9:09 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-06 5:28 ` Dan Carpenter
2023-06-06 7:30 ` Thomas Zimmermann
2023-06-07 9:10 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup Thomas Zimmermann
2023-06-07 9:11 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent Thomas Zimmermann
2023-06-07 9:11 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 21/30] fbdev/sm501fb: Output message with fb_err() Thomas Zimmermann
2023-06-07 9:12 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 22/30] fbdev/smscufx: Detect registered fb_info from refcount Thomas Zimmermann
2023-06-07 22:22 ` Javier Martinez Canillas
2023-06-12 10:19 ` Thomas Zimmermann
2023-06-12 10:40 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 23/30] fbdev/tdfxfb: Set i2c adapter parent to hardware device Thomas Zimmermann
2023-06-07 22:23 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 24/30] fbdev/core: Pass Linux device to pm_vt_switch_*() functions Thomas Zimmermann
2023-06-07 19:25 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 25/30] fbdev/core: Move framebuffer and backlight helpers into separate files Thomas Zimmermann
2023-06-07 19:38 ` Sam Ravnborg
2023-06-09 7:19 ` Thomas Zimmermann
2023-06-05 14:48 ` [PATCH 26/30] fbdev/core: Add fb_device_{create,destroy}() Thomas Zimmermann
2023-06-07 19:45 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 27/30] fbdev/core: Move procfs code to separate file Thomas Zimmermann
2023-06-07 20:33 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 28/30] fbdev/core: Move file-I/O code into " Thomas Zimmermann
2023-06-05 21:35 ` kernel test robot
2023-06-07 20:48 ` Sam Ravnborg
2023-06-12 10:35 ` Thomas Zimmermann
2023-06-07 22:28 ` Javier Martinez Canillas
2023-06-05 14:48 ` [PATCH 29/30] fbdev/core: Rework fb init code Thomas Zimmermann
2023-06-07 20:51 ` Sam Ravnborg
2023-06-05 14:48 ` [PATCH 30/30] fbdev: Make support for userspace interfaces configurable Thomas Zimmermann
2023-06-05 15:03 ` Greg KH
2023-06-05 21:45 ` kernel test robot
2023-06-07 8:48 ` Geert Uytterhoeven
2023-06-07 15:15 ` Thomas Zimmermann
2023-06-07 15:24 ` Geert Uytterhoeven
2023-06-07 23:07 ` Javier Martinez Canillas
2023-06-09 7:09 ` Thomas Zimmermann
2023-06-09 7:29 ` Geert Uytterhoeven
2023-06-09 8:00 ` Thomas Zimmermann
2023-06-09 9:14 ` Geert Uytterhoeven
2023-06-09 11:04 ` Thomas Zimmermann
2023-06-09 11:22 ` Geert Uytterhoeven
2023-06-09 9:59 ` Javier Martinez Canillas
2023-06-09 10:10 ` Geert Uytterhoeven
2023-06-09 10:24 ` Javier Martinez Canillas
2023-06-09 11:27 ` Javier Martinez Canillas
2023-06-11 16:37 ` Sam Ravnborg
2023-06-12 6:47 ` Thomas Zimmermann
2023-06-12 7:00 ` Thomas Zimmermann
2023-06-07 8:35 ` [PATCH 00/30] fbdev: Make userspace interfaces optional Geert Uytterhoeven
2023-06-12 10:46 ` Thomas Zimmermann
2023-06-07 12:06 ` Markus Elfring
2023-06-07 12:21 ` Thomas Zimmermann
2023-06-07 14:08 ` Markus Elfring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).