linux-staging.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [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(&registration_lock);
+
+	return (*pos < FB_MAX) ? pos : NULL;
+}
+
+static void fb_seq_stop(struct seq_file *m, void *v)
+{
+	mutex_unlock(&registration_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(&registration_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(&registration_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(&registration_lock);
> +
> +	return (*pos < FB_MAX) ? pos : NULL;
> +}
> +
> +static void fb_seq_stop(struct seq_file *m, void *v)
> +{
> +	mutex_unlock(&registration_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(&registration_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(&registration_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).