[PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Javier Martinez Canillas]

Hello,

The patches in this series contain mostly changes suggested by Daniel Vetter
Thomas Zimmermann. They aim to fix existing races between the Generic System
Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.

For example, it is currently possible for sysfb to register a platform
device after a real DRM driver was registered and requested to remove the
conflicting framebuffers. Or is possible for a simple{fb,drm} to match with
a device previously registered by sysfb, even after a real driver is present.

A symptom of this issue, was worked around with the commit fb561bf9abde
("fbdev: Prevent probing generic drivers if a FB is already registered")
but that's really a hack and should be reverted instead.

This series attempt to fix it more correctly and revert the mentioned hack.
That will also allow to make the num_registered_fb variable not visible to
drivers anymore, since that's internal to fbdev core.

Pach 1 is just a simple cleanup in preparation for later patches.

Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow
disabling sysfb and attempt to unregister registered devices respectively.

Patch 3 changes how is dealt with conflicting framebuffers unregistering,
rather than having a variable to determine if a lock should be take, it
just drops the lock before unregistering the platform device.

Patch 4 changes the fbdev core to not attempt to unregister devices that
were registered by sysfb, let the same code doing the registration to also
handle the unregistration.

Patch 5 fixes the race that exists between sysfb devices registration and
fbdev framebuffer devices registration, by disabling the sysfb when a DRM
or fbdev driver requests to remove conflicting framebuffers.

Patch 6 is the revert patch that was posted by Daniel before but dropped
from his set and finally patch 7 is the one that makes num_registered_fb
private to fbmem.c, to not allow drivers to use it anymore.

The patches were tested on a rpi4 with the vc4, simpledrm and simplefb
drivers, using different combinations of built-in and as a module.

For example, having simpledrm as a module and loading it after the vc4
driver probed would not register a DRM device, which happens now without
the patches from this series.

Best regards,
Javier

Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
  avoid the need of a DRIVER_FIRMWARE capability flag.
- Add Daniel Vetter's Reviewed-by tag again since reverted to the old
  patch that he already reviewed in v2.
- Drop patches that added a DRM_FIRMWARE capability and use them
  since the case those prevented could be ignored (Daniel Vetter).

Changes in v4:
- Make sysfb_disable() to also attempt to unregister a device.
- Drop call to sysfb_disable() in fbmem since is done in other places now.
- Add patch to make registered_fb[] private.
- Add patches that introduce the DRM_FIRMWARE capability and usage.

Changes in v3:
- Add Thomas Zimmermann's Reviewed-by tag to patch #1.
- Call sysfb_disable() when a DRM dev and a fbdev are registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Call sysfb_disable() when a fbdev framebuffer is registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
- Rebase on top of latest drm-misc-next branch.

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Drop RFC prefix since patches were already reviewed by Daniel Vetter.
- Add Daniel Reviewed-by tags to the patches.

Daniel Vetter (2):
  Revert "fbdev: Prevent probing generic drivers if a FB is already
    registered"
  fbdev: Make registered_fb[] private to fbmem.c

Javier Martinez Canillas (5):
  firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
  firmware: sysfb: Add helpers to unregister a pdev and disable
    registration
  fbdev: Restart conflicting fb removal loop when unregistering devices
  fbdev: Make sysfb to unregister its own registered devices
  fbdev: Disable sysfb device registration when removing conflicting FBs

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c                      | 91 +++++++++++++++++--
 drivers/firmware/sysfb_simplefb.c             | 16 ++--
 drivers/video/fbdev/core/fbmem.c              | 67 +++++++++++---
 drivers/video/fbdev/efifb.c                   | 11 ---
 drivers/video/fbdev/simplefb.c                | 11 ---
 include/linux/fb.h                            |  8 +-
 include/linux/sysfb.h                         | 29 +++++-
 8 files changed, 178 insertions(+), 61 deletions(-)

-- 
2.35.1

[PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Javier Martinez Canillas]

Hello,

The patches in this series contain mostly changes suggested by Daniel Vetter
Thomas Zimmermann. They aim to fix existing races between the Generic System
Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.

For example, it is currently possible for sysfb to register a platform
device after a real DRM driver was registered and requested to remove the
conflicting framebuffers. Or is possible for a simple{fb,drm} to match with
a device previously registered by sysfb, even after a real driver is present.

A symptom of this issue, was worked around with the commit fb561bf9abde
("fbdev: Prevent probing generic drivers if a FB is already registered")
but that's really a hack and should be reverted instead.

This series attempt to fix it more correctly and revert the mentioned hack.
That will also allow to make the num_registered_fb variable not visible to
drivers anymore, since that's internal to fbdev core.

Pach 1 is just a simple cleanup in preparation for later patches.

Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow
disabling sysfb and attempt to unregister registered devices respectively.

Patch 3 changes how is dealt with conflicting framebuffers unregistering,
rather than having a variable to determine if a lock should be take, it
just drops the lock before unregistering the platform device.

Patch 4 changes the fbdev core to not attempt to unregister devices that
were registered by sysfb, let the same code doing the registration to also
handle the unregistration.

Patch 5 fixes the race that exists between sysfb devices registration and
fbdev framebuffer devices registration, by disabling the sysfb when a DRM
or fbdev driver requests to remove conflicting framebuffers.

Patch 6 is the revert patch that was posted by Daniel before but dropped
from his set and finally patch 7 is the one that makes num_registered_fb
private to fbmem.c, to not allow drivers to use it anymore.

The patches were tested on a rpi4 with the vc4, simpledrm and simplefb
drivers, using different combinations of built-in and as a module.

For example, having simpledrm as a module and loading it after the vc4
driver probed would not register a DRM device, which happens now without
the patches from this series.

Best regards,
Javier

Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
  avoid the need of a DRIVER_FIRMWARE capability flag.
- Add Daniel Vetter's Reviewed-by tag again since reverted to the old
  patch that he already reviewed in v2.
- Drop patches that added a DRM_FIRMWARE capability and use them
  since the case those prevented could be ignored (Daniel Vetter).

Changes in v4:
- Make sysfb_disable() to also attempt to unregister a device.
- Drop call to sysfb_disable() in fbmem since is done in other places now.
- Add patch to make registered_fb[] private.
- Add patches that introduce the DRM_FIRMWARE capability and usage.

Changes in v3:
- Add Thomas Zimmermann's Reviewed-by tag to patch #1.
- Call sysfb_disable() when a DRM dev and a fbdev are registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Call sysfb_disable() when a fbdev framebuffer is registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
- Rebase on top of latest drm-misc-next branch.

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Drop RFC prefix since patches were already reviewed by Daniel Vetter.
- Add Daniel Reviewed-by tags to the patches.

Daniel Vetter (2):
  Revert "fbdev: Prevent probing generic drivers if a FB is already
    registered"
  fbdev: Make registered_fb[] private to fbmem.c

Javier Martinez Canillas (5):
  firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
  firmware: sysfb: Add helpers to unregister a pdev and disable
    registration
  fbdev: Restart conflicting fb removal loop when unregistering devices
  fbdev: Make sysfb to unregister its own registered devices
  fbdev: Disable sysfb device registration when removing conflicting FBs

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c                      | 91 +++++++++++++++++--
 drivers/firmware/sysfb_simplefb.c             | 16 ++--
 drivers/video/fbdev/core/fbmem.c              | 67 +++++++++++---
 drivers/video/fbdev/efifb.c                   | 11 ---
 drivers/video/fbdev/simplefb.c                | 11 ---
 include/linux/fb.h                            |  8 +-
 include/linux/sysfb.h                         | 29 +++++-
 8 files changed, 178 insertions(+), 61 deletions(-)

-- 
2.35.1

[PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer

[Javier Martinez Canillas]

This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

---

(no changes since v3)

Changes in v3:
- Add Thomas Zimmermann's Reviewed-by tag to patch #1.

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).

 drivers/firmware/sysfb.c          |  4 ++--
 drivers/firmware/sysfb_simplefb.c | 16 ++++++++--------
 include/linux/sysfb.h             | 10 +++++-----
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 2bfbb05f7d89..b032f40a92de 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -46,8 +46,8 @@ static __init int sysfb_init(void)
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
 	if (compatible) {
-		ret = sysfb_create_simplefb(si, &mode);
-		if (!ret)
+		pd = sysfb_create_simplefb(si, &mode);
+		if (!IS_ERR(pd))
 			return 0;
 	}
 
diff --git a/drivers/firmware/sysfb_simplefb.c b/drivers/firmware/sysfb_simplefb.c
index bda8712bfd8c..a353e27f83f5 100644
--- a/drivers/firmware/sysfb_simplefb.c
+++ b/drivers/firmware/sysfb_simplefb.c
@@ -57,8 +57,8 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
 	return false;
 }
 
-__init int sysfb_create_simplefb(const struct screen_info *si,
-				 const struct simplefb_platform_data *mode)
+__init struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+						     const struct simplefb_platform_data *mode)
 {
 	struct platform_device *pd;
 	struct resource res;
@@ -76,7 +76,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 		base |= (u64)si->ext_lfb_base << 32;
 	if (!base || (u64)(resource_size_t)base != base) {
 		printk(KERN_DEBUG "sysfb: inaccessible VRAM base\n");
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 	}
 
 	/*
@@ -93,7 +93,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	length = mode->height * mode->stride;
 	if (length > size) {
 		printk(KERN_WARNING "sysfb: VRAM smaller than advertised\n");
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 	}
 	length = PAGE_ALIGN(length);
 
@@ -104,11 +104,11 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	res.start = base;
 	res.end = res.start + length - 1;
 	if (res.end <= res.start)
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 
 	pd = platform_device_alloc("simple-framebuffer", 0);
 	if (!pd)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	sysfb_apply_efi_quirks(pd);
 
@@ -124,10 +124,10 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	if (ret)
 		goto err_put_device;
 
-	return 0;
+	return pd;
 
 err_put_device:
 	platform_device_put(pd);
 
-	return ret;
+	return ERR_PTR(ret);
 }
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index b0dcfa26d07b..708152e9037b 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -72,8 +72,8 @@ static inline void sysfb_apply_efi_quirks(struct platform_device *pd)
 
 bool sysfb_parse_mode(const struct screen_info *si,
 		      struct simplefb_platform_data *mode);
-int sysfb_create_simplefb(const struct screen_info *si,
-			  const struct simplefb_platform_data *mode);
+struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+					      const struct simplefb_platform_data *mode);
 
 #else /* CONFIG_SYSFB_SIMPLE */
 
@@ -83,10 +83,10 @@ static inline bool sysfb_parse_mode(const struct screen_info *si,
 	return false;
 }
 
-static inline int sysfb_create_simplefb(const struct screen_info *si,
-					 const struct simplefb_platform_data *mode)
+static inline struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+							    const struct simplefb_platform_data *mode)
 {
-	return -EINVAL;
+	return ERR_PTR(-EINVAL);
 }
 
 #endif /* CONFIG_SYSFB_SIMPLE */
-- 
2.35.1

[PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer

[Javier Martinez Canillas]

This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

---

(no changes since v3)

Changes in v3:
- Add Thomas Zimmermann's Reviewed-by tag to patch #1.

Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).

 drivers/firmware/sysfb.c          |  4 ++--
 drivers/firmware/sysfb_simplefb.c | 16 ++++++++--------
 include/linux/sysfb.h             | 10 +++++-----
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 2bfbb05f7d89..b032f40a92de 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -46,8 +46,8 @@ static __init int sysfb_init(void)
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
 	if (compatible) {
-		ret = sysfb_create_simplefb(si, &mode);
-		if (!ret)
+		pd = sysfb_create_simplefb(si, &mode);
+		if (!IS_ERR(pd))
 			return 0;
 	}
 
diff --git a/drivers/firmware/sysfb_simplefb.c b/drivers/firmware/sysfb_simplefb.c
index bda8712bfd8c..a353e27f83f5 100644
--- a/drivers/firmware/sysfb_simplefb.c
+++ b/drivers/firmware/sysfb_simplefb.c
@@ -57,8 +57,8 @@ __init bool sysfb_parse_mode(const struct screen_info *si,
 	return false;
 }
 
-__init int sysfb_create_simplefb(const struct screen_info *si,
-				 const struct simplefb_platform_data *mode)
+__init struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+						     const struct simplefb_platform_data *mode)
 {
 	struct platform_device *pd;
 	struct resource res;
@@ -76,7 +76,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 		base |= (u64)si->ext_lfb_base << 32;
 	if (!base || (u64)(resource_size_t)base != base) {
 		printk(KERN_DEBUG "sysfb: inaccessible VRAM base\n");
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 	}
 
 	/*
@@ -93,7 +93,7 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	length = mode->height * mode->stride;
 	if (length > size) {
 		printk(KERN_WARNING "sysfb: VRAM smaller than advertised\n");
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 	}
 	length = PAGE_ALIGN(length);
 
@@ -104,11 +104,11 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	res.start = base;
 	res.end = res.start + length - 1;
 	if (res.end <= res.start)
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 
 	pd = platform_device_alloc("simple-framebuffer", 0);
 	if (!pd)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	sysfb_apply_efi_quirks(pd);
 
@@ -124,10 +124,10 @@ __init int sysfb_create_simplefb(const struct screen_info *si,
 	if (ret)
 		goto err_put_device;
 
-	return 0;
+	return pd;
 
 err_put_device:
 	platform_device_put(pd);
 
-	return ret;
+	return ERR_PTR(ret);
 }
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index b0dcfa26d07b..708152e9037b 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -72,8 +72,8 @@ static inline void sysfb_apply_efi_quirks(struct platform_device *pd)
 
 bool sysfb_parse_mode(const struct screen_info *si,
 		      struct simplefb_platform_data *mode);
-int sysfb_create_simplefb(const struct screen_info *si,
-			  const struct simplefb_platform_data *mode);
+struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+					      const struct simplefb_platform_data *mode);
 
 #else /* CONFIG_SYSFB_SIMPLE */
 
@@ -83,10 +83,10 @@ static inline bool sysfb_parse_mode(const struct screen_info *si,
 	return false;
 }
 
-static inline int sysfb_create_simplefb(const struct screen_info *si,
-					 const struct simplefb_platform_data *mode)
+static inline struct platform_device *sysfb_create_simplefb(const struct screen_info *si,
+							    const struct simplefb_platform_data *mode)
 {
-	return -EINVAL;
+	return ERR_PTR(-EINVAL);
 }
 
 #endif /* CONFIG_SYSFB_SIMPLE */
-- 
2.35.1

[PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

(no changes since v4)

Changes in v4:
- Make sysfb_disable() to also attempt to unregister a device.

Changes in v2:
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
 include/linux/sysfb.h                         | 19 ++++
 3 files changed, 106 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
index b81794e0cfbb..06ac89adaafb 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -13,6 +13,12 @@ EDD Interfaces
 .. kernel-doc:: drivers/firmware/edd.c
    :internal:
 
+Generic System Framebuffers Interface
+-------------------------------------
+
+.. kernel-doc:: drivers/firmware/sysfb.c
+   :export:
+
 Intel Stratix10 SoC Service Layer
 ---------------------------------
 Some features of the Intel Stratix10 SoC require a level of privilege
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index b032f40a92de..6768968949e6 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -34,21 +34,92 @@
 #include <linux/screen_info.h>
 #include <linux/sysfb.h>
 
+static struct platform_device *pd;
+static DEFINE_MUTEX(disable_lock);
+static bool disabled;
+
+static bool sysfb_unregister(void)
+{
+	if (IS_ERR_OR_NULL(pd))
+		return false;
+
+	platform_device_unregister(pd);
+	pd = NULL;
+
+	return true;
+}
+
+/**
+ * sysfb_disable() - disable the Generic System Framebuffers support
+ *
+ * This disables the registration of system framebuffer devices that match the
+ * generic drivers that make use of the system framebuffer set up by firmware.
+ *
+ * It also unregisters a device if this was already registered by sysfb_init().
+ *
+ * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
+ *          against sysfb_init(), that registers a system framebuffer device and
+ *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
+ */
+void sysfb_disable(void)
+{
+	mutex_lock(&disable_lock);
+	sysfb_unregister();
+	disabled = true;
+	mutex_unlock(&disable_lock);
+}
+EXPORT_SYMBOL_GPL(sysfb_disable);
+
+/**
+ * sysfb_try_unregister() - attempt to unregister a system framebuffer device
+ * @dev: device to unregister
+ *
+ * This tries to unregister a system framebuffer device if this was registered
+ * by the Generic System Framebuffers. The device will only be unregistered if
+ * it was registered by sysfb_init(), otherwise it will not be unregistered.
+ *
+ * Context: The function can sleep. a @load_lock mutex is acquired to serialize
+ *          against sysfb_init(), that registers a simple framebuffer device and
+ *          sysfb_disable(), that disables the Generic System Framebuffers support.
+ *
+ * Return:
+ * * true          - the device was unregistered successfully
+ * * false         - the device was not unregistered
+ */
+bool sysfb_try_unregister(struct device *dev)
+{
+	bool ret = false;
+
+	mutex_lock(&disable_lock);
+	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
+		goto unlock_mutex;
+
+	ret = sysfb_unregister();
+
+unlock_mutex:
+	mutex_unlock(&disable_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(sysfb_try_unregister);
+
 static __init int sysfb_init(void)
 {
 	struct screen_info *si = &screen_info;
 	struct simplefb_platform_data mode;
-	struct platform_device *pd;
 	const char *name;
 	bool compatible;
-	int ret;
+	int ret = 0;
+
+	mutex_lock(&disable_lock);
+	if (disabled)
+		goto unlock_mutex;
 
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
 	if (compatible) {
 		pd = sysfb_create_simplefb(si, &mode);
 		if (!IS_ERR(pd))
-			return 0;
+			goto unlock_mutex;
 	}
 
 	/* if the FB is incompatible, create a legacy framebuffer device */
@@ -60,8 +131,10 @@ static __init int sysfb_init(void)
 		name = "platform-framebuffer";
 
 	pd = platform_device_alloc(name, 0);
-	if (!pd)
-		return -ENOMEM;
+	if (!pd) {
+		ret = -ENOMEM;
+		goto unlock_mutex;
+	}
 
 	sysfb_apply_efi_quirks(pd);
 
@@ -73,9 +146,11 @@ static __init int sysfb_init(void)
 	if (ret)
 		goto err;
 
-	return 0;
+	goto unlock_mutex;
 err:
 	platform_device_put(pd);
+unlock_mutex:
+	mutex_unlock(&disable_lock);
 	return ret;
 }
 
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index 708152e9037b..e8c0313fac8f 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -55,6 +55,25 @@ struct efifb_dmi_info {
 	int flags;
 };
 
+#ifdef CONFIG_SYSFB
+
+void sysfb_disable(void);
+bool sysfb_try_unregister(struct device *dev);
+
+#else /* CONFIG_SYSFB */
+
+static inline void sysfb_disable(void)
+{
+
+}
+
+static inline bool sysfb_try_unregister(struct device *dev)
+{
+	return false;
+}
+
+#endif /* CONFIG_SYSFB */
+
 #ifdef CONFIG_EFI
 
 extern struct efifb_dmi_info efifb_dmi_list[];
-- 
2.35.1

[PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

(no changes since v4)

Changes in v4:
- Make sysfb_disable() to also attempt to unregister a device.

Changes in v2:
- Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).

 .../driver-api/firmware/other_interfaces.rst  |  6 ++
 drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
 include/linux/sysfb.h                         | 19 ++++
 3 files changed, 106 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
index b81794e0cfbb..06ac89adaafb 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -13,6 +13,12 @@ EDD Interfaces
 .. kernel-doc:: drivers/firmware/edd.c
    :internal:
 
+Generic System Framebuffers Interface
+-------------------------------------
+
+.. kernel-doc:: drivers/firmware/sysfb.c
+   :export:
+
 Intel Stratix10 SoC Service Layer
 ---------------------------------
 Some features of the Intel Stratix10 SoC require a level of privilege
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index b032f40a92de..6768968949e6 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -34,21 +34,92 @@
 #include <linux/screen_info.h>
 #include <linux/sysfb.h>
 
+static struct platform_device *pd;
+static DEFINE_MUTEX(disable_lock);
+static bool disabled;
+
+static bool sysfb_unregister(void)
+{
+	if (IS_ERR_OR_NULL(pd))
+		return false;
+
+	platform_device_unregister(pd);
+	pd = NULL;
+
+	return true;
+}
+
+/**
+ * sysfb_disable() - disable the Generic System Framebuffers support
+ *
+ * This disables the registration of system framebuffer devices that match the
+ * generic drivers that make use of the system framebuffer set up by firmware.
+ *
+ * It also unregisters a device if this was already registered by sysfb_init().
+ *
+ * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
+ *          against sysfb_init(), that registers a system framebuffer device and
+ *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
+ */
+void sysfb_disable(void)
+{
+	mutex_lock(&disable_lock);
+	sysfb_unregister();
+	disabled = true;
+	mutex_unlock(&disable_lock);
+}
+EXPORT_SYMBOL_GPL(sysfb_disable);
+
+/**
+ * sysfb_try_unregister() - attempt to unregister a system framebuffer device
+ * @dev: device to unregister
+ *
+ * This tries to unregister a system framebuffer device if this was registered
+ * by the Generic System Framebuffers. The device will only be unregistered if
+ * it was registered by sysfb_init(), otherwise it will not be unregistered.
+ *
+ * Context: The function can sleep. a @load_lock mutex is acquired to serialize
+ *          against sysfb_init(), that registers a simple framebuffer device and
+ *          sysfb_disable(), that disables the Generic System Framebuffers support.
+ *
+ * Return:
+ * * true          - the device was unregistered successfully
+ * * false         - the device was not unregistered
+ */
+bool sysfb_try_unregister(struct device *dev)
+{
+	bool ret = false;
+
+	mutex_lock(&disable_lock);
+	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
+		goto unlock_mutex;
+
+	ret = sysfb_unregister();
+
+unlock_mutex:
+	mutex_unlock(&disable_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(sysfb_try_unregister);
+
 static __init int sysfb_init(void)
 {
 	struct screen_info *si = &screen_info;
 	struct simplefb_platform_data mode;
-	struct platform_device *pd;
 	const char *name;
 	bool compatible;
-	int ret;
+	int ret = 0;
+
+	mutex_lock(&disable_lock);
+	if (disabled)
+		goto unlock_mutex;
 
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
 	if (compatible) {
 		pd = sysfb_create_simplefb(si, &mode);
 		if (!IS_ERR(pd))
-			return 0;
+			goto unlock_mutex;
 	}
 
 	/* if the FB is incompatible, create a legacy framebuffer device */
@@ -60,8 +131,10 @@ static __init int sysfb_init(void)
 		name = "platform-framebuffer";
 
 	pd = platform_device_alloc(name, 0);
-	if (!pd)
-		return -ENOMEM;
+	if (!pd) {
+		ret = -ENOMEM;
+		goto unlock_mutex;
+	}
 
 	sysfb_apply_efi_quirks(pd);
 
@@ -73,9 +146,11 @@ static __init int sysfb_init(void)
 	if (ret)
 		goto err;
 
-	return 0;
+	goto unlock_mutex;
 err:
 	platform_device_put(pd);
+unlock_mutex:
+	mutex_unlock(&disable_lock);
 	return ret;
 }
 
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index 708152e9037b..e8c0313fac8f 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -55,6 +55,25 @@ struct efifb_dmi_info {
 	int flags;
 };
 
+#ifdef CONFIG_SYSFB
+
+void sysfb_disable(void);
+bool sysfb_try_unregister(struct device *dev);
+
+#else /* CONFIG_SYSFB */
+
+static inline void sysfb_disable(void)
+{
+
+}
+
+static inline bool sysfb_try_unregister(struct device *dev)
+{
+	return false;
+}
+
+#endif /* CONFIG_SYSFB */
+
 #ifdef CONFIG_EFI
 
 extern struct efifb_dmi_info efifb_dmi_list[];
-- 
2.35.1

[PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, calls remove_conflicting_framebuffers().

This function takes the registration_lock mutex, to prevent a races when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called, which in
turn will call to the unregister_framebuffer() that takes the same lock.

To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.

A cleaner solution is to drop the lock before platform_device_unregister()
so unregister_framebuffer() can take it when called from the fbdev driver,
and just grab the lock again after the device has been registered and do
a removal loop restart.

Since the framebuffer devices will already be removed, the loop would just
finish when no more conflicting framebuffers are found.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

(no changes since v1)

 drivers/video/fbdev/core/fbmem.c | 22 +++++++++++++++-------
 include/linux/fb.h               |  1 -
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index b445a7a00def..2fda5917c212 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1555,6 +1555,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 {
 	int i;
 
+restart_removal:
 	/* check all firmware fbs and kick off if the base addr overlaps */
 	for_each_registered_fb(i) {
 		struct apertures_struct *gen_aper;
@@ -1587,12 +1588,23 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 				pr_warn("fb%d: no device set\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
 			} else if (dev_is_platform(device)) {
-				registered_fb[i]->forced_out = true;
+				/*
+				 * Drop the lock because if the device is unregistered, its
+				 * driver will call to unregister_framebuffer(), that takes
+				 * this lock.
+				 */
+				mutex_unlock(&registration_lock);
 				platform_device_unregister(to_platform_device(device));
+				mutex_lock(&registration_lock);
 			} else {
 				pr_warn("fb%d: cannot remove device\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
 			}
+			/*
+			 * Restart the removal loop now that the device has been
+			 * unregistered and its associated framebuffer gone.
+			 */
+			goto restart_removal;
 		}
 	}
 }
@@ -1899,13 +1911,9 @@ EXPORT_SYMBOL(register_framebuffer);
 void
 unregister_framebuffer(struct fb_info *fb_info)
 {
-	bool forced_out = fb_info->forced_out;
-
-	if (!forced_out)
-		mutex_lock(&registration_lock);
+	mutex_lock(&registration_lock);
 	do_unregister_framebuffer(fb_info);
-	if (!forced_out)
-		mutex_unlock(&registration_lock);
+	mutex_unlock(&registration_lock);
 }
 EXPORT_SYMBOL(unregister_framebuffer);
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 69c67c70fa78..bbe1e4571899 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -511,7 +511,6 @@ struct fb_info {
 	} *apertures;
 
 	bool skip_vt_switch; /* no VT switch on suspend/resume required */
-	bool forced_out; /* set when being removed by another driver */
 };
 
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
-- 
2.35.1

[PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, calls remove_conflicting_framebuffers().

This function takes the registration_lock mutex, to prevent a races when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called, which in
turn will call to the unregister_framebuffer() that takes the same lock.

To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.

A cleaner solution is to drop the lock before platform_device_unregister()
so unregister_framebuffer() can take it when called from the fbdev driver,
and just grab the lock again after the device has been registered and do
a removal loop restart.

Since the framebuffer devices will already be removed, the loop would just
finish when no more conflicting framebuffers are found.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

(no changes since v1)

 drivers/video/fbdev/core/fbmem.c | 22 +++++++++++++++-------
 include/linux/fb.h               |  1 -
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index b445a7a00def..2fda5917c212 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1555,6 +1555,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 {
 	int i;
 
+restart_removal:
 	/* check all firmware fbs and kick off if the base addr overlaps */
 	for_each_registered_fb(i) {
 		struct apertures_struct *gen_aper;
@@ -1587,12 +1588,23 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 				pr_warn("fb%d: no device set\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
 			} else if (dev_is_platform(device)) {
-				registered_fb[i]->forced_out = true;
+				/*
+				 * Drop the lock because if the device is unregistered, its
+				 * driver will call to unregister_framebuffer(), that takes
+				 * this lock.
+				 */
+				mutex_unlock(&registration_lock);
 				platform_device_unregister(to_platform_device(device));
+				mutex_lock(&registration_lock);
 			} else {
 				pr_warn("fb%d: cannot remove device\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
 			}
+			/*
+			 * Restart the removal loop now that the device has been
+			 * unregistered and its associated framebuffer gone.
+			 */
+			goto restart_removal;
 		}
 	}
 }
@@ -1899,13 +1911,9 @@ EXPORT_SYMBOL(register_framebuffer);
 void
 unregister_framebuffer(struct fb_info *fb_info)
 {
-	bool forced_out = fb_info->forced_out;
-
-	if (!forced_out)
-		mutex_lock(&registration_lock);
+	mutex_lock(&registration_lock);
 	do_unregister_framebuffer(fb_info);
-	if (!forced_out)
-		mutex_unlock(&registration_lock);
+	mutex_unlock(&registration_lock);
 }
 EXPORT_SYMBOL(unregister_framebuffer);
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 69c67c70fa78..bbe1e4571899 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -511,7 +511,6 @@ struct fb_info {
 	} *apertures;
 
 	bool skip_vt_switch; /* no VT switch on suspend/resume required */
-	bool forced_out; /* set when being removed by another driver */
 };
 
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
-- 
2.35.1

[PATCH v5 4/7] fbdev: Make sysfb to unregister its own registered devices

[Javier Martinez Canillas]

The platform devices registered in sysfb match with a firmware-based fbdev
or DRM driver, that are used to have early graphics using framebuffers set
up by the system firmware.

Real DRM drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.

But the current solution has the problem that sysfb doesn't know when the
device that registered is unregistered. This means that is not able to do
any cleanup if needed since the device pointer may not be valid anymore.

Not all platforms use sysfb to register the simple framebuffer devices,
so an unregistration has to be forced by fbmem if sysfb_try_unregister()
does not succeed at unregister the device.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

---

(no changes since v4)

Changes in v4:
- Drop call to sysfb_disable() in fbmem since is done in other places now.

Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).

 drivers/video/fbdev/core/fbmem.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 2fda5917c212..9b035ef4d552 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -19,6 +19,7 @@
 #include <linux/kernel.h>
 #include <linux/major.h>
 #include <linux/slab.h>
+#include <linux/sysfb.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <linux/vt.h>
@@ -1587,18 +1588,35 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 			if (!device) {
 				pr_warn("fb%d: no device set\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
-			} else if (dev_is_platform(device)) {
+			} else {
 				/*
 				 * Drop the lock because if the device is unregistered, its
 				 * driver will call to unregister_framebuffer(), that takes
 				 * this lock.
 				 */
 				mutex_unlock(&registration_lock);
-				platform_device_unregister(to_platform_device(device));
+				/*
+				 * First attempt the device to be unregistered by sysfb.
+				 */
+				if (!sysfb_try_unregister(device)) {
+					if (dev_is_platform(device)) {
+						/*
+						 * FIXME: sysfb didn't register this device, the platform
+						 * device was registered in other platform code.
+						 */
+						platform_device_unregister(to_platform_device(device));
+					} else {
+						/*
+						 * If is not a platform device, at least print a warning. A
+						 * fix would add to make the code that registered the device
+						 * to also unregister it.
+						 */
+						pr_warn("fb%d: cannot remove device\n", i);
+						/* call unregister_framebuffer() since the lock was dropped */
+						unregister_framebuffer(registered_fb[i]);
+					}
+				}
 				mutex_lock(&registration_lock);
-			} else {
-				pr_warn("fb%d: cannot remove device\n", i);
-				do_unregister_framebuffer(registered_fb[i]);
 			}
 			/*
 			 * Restart the removal loop now that the device has been
-- 
2.35.1

[PATCH v5 4/7] fbdev: Make sysfb to unregister its own registered devices

[Javier Martinez Canillas]

The platform devices registered in sysfb match with a firmware-based fbdev
or DRM driver, that are used to have early graphics using framebuffers set
up by the system firmware.

Real DRM drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.

But the current solution has the problem that sysfb doesn't know when the
device that registered is unregistered. This means that is not able to do
any cleanup if needed since the device pointer may not be valid anymore.

Not all platforms use sysfb to register the simple framebuffer devices,
so an unregistration has to be forced by fbmem if sysfb_try_unregister()
does not succeed at unregister the device.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

---

(no changes since v4)

Changes in v4:
- Drop call to sysfb_disable() in fbmem since is done in other places now.

Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).

 drivers/video/fbdev/core/fbmem.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 2fda5917c212..9b035ef4d552 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -19,6 +19,7 @@
 #include <linux/kernel.h>
 #include <linux/major.h>
 #include <linux/slab.h>
+#include <linux/sysfb.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <linux/vt.h>
@@ -1587,18 +1588,35 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
 			if (!device) {
 				pr_warn("fb%d: no device set\n", i);
 				do_unregister_framebuffer(registered_fb[i]);
-			} else if (dev_is_platform(device)) {
+			} else {
 				/*
 				 * Drop the lock because if the device is unregistered, its
 				 * driver will call to unregister_framebuffer(), that takes
 				 * this lock.
 				 */
 				mutex_unlock(&registration_lock);
-				platform_device_unregister(to_platform_device(device));
+				/*
+				 * First attempt the device to be unregistered by sysfb.
+				 */
+				if (!sysfb_try_unregister(device)) {
+					if (dev_is_platform(device)) {
+						/*
+						 * FIXME: sysfb didn't register this device, the platform
+						 * device was registered in other platform code.
+						 */
+						platform_device_unregister(to_platform_device(device));
+					} else {
+						/*
+						 * If is not a platform device, at least print a warning. A
+						 * fix would add to make the code that registered the device
+						 * to also unregister it.
+						 */
+						pr_warn("fb%d: cannot remove device\n", i);
+						/* call unregister_framebuffer() since the lock was dropped */
+						unregister_framebuffer(registered_fb[i]);
+					}
+				}
 				mutex_lock(&registration_lock);
-			} else {
-				pr_warn("fb%d: cannot remove device\n", i);
-				do_unregister_framebuffer(registered_fb[i]);
 			}
 			/*
 			 * Restart the removal loop now that the device has been
-- 
2.35.1

[PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs

[Javier Martinez Canillas]

The platform devices registered by sysfb match with firmware-based DRM or
fbdev drivers, that are used to have early graphics using a framebuffer
provided by the system firmware.

DRM or fbdev drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.

But the current solution has a race, since the sysfb_init() function could
be called after a DRM or fbdev driver is probed and request to unregister
the devices for drivers with conflicting framebuffes.

To prevent this, disable any future sysfb platform device registration by
calling sysfb_disable(), if a driver requests to remove the conflicting
framebuffers.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
  avoid the need of a DRIVER_FIRMWARE capability flag.
- Add Daniel Vetter's Reviewed-by tag again since reverted to the old
  patch that he already reviewed in v2.

Changes in v3:
- Call sysfb_disable() when a DRM dev and a fbdev are registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Call sysfb_disable() when a fbdev framebuffer is registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.

Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).

 drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 9b035ef4d552..265efa189bcc 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
 	if (do_free)
 		kfree(a);
 
+	/*
+	 * If a driver asked to unregister a platform device registered by
+	 * sysfb, then can be assumed that this is a driver for a display
+	 * that is set up by the system firmware and has a generic driver.
+	 *
+	 * Drivers for devices that don't have a generic driver will never
+	 * ask for this, so let's assume that a real driver for the display
+	 * was already probed and prevent sysfb to register devices later.
+	 */
+	sysfb_disable();
+
 	return 0;
 }
 EXPORT_SYMBOL(remove_conflicting_framebuffers);
-- 
2.35.1

[PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs

[Javier Martinez Canillas]

The platform devices registered by sysfb match with firmware-based DRM or
fbdev drivers, that are used to have early graphics using a framebuffer
provided by the system firmware.

DRM or fbdev drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic drivers to be unregistered.

But the current solution has a race, since the sysfb_init() function could
be called after a DRM or fbdev driver is probed and request to unregister
the devices for drivers with conflicting framebuffes.

To prevent this, disable any future sysfb platform device registration by
calling sysfb_disable(), if a driver requests to remove the conflicting
framebuffers.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
  avoid the need of a DRIVER_FIRMWARE capability flag.
- Add Daniel Vetter's Reviewed-by tag again since reverted to the old
  patch that he already reviewed in v2.

Changes in v3:
- Call sysfb_disable() when a DRM dev and a fbdev are registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Call sysfb_disable() when a fbdev framebuffer is registered rather
  than when conflicting framebuffers are removed (Thomas Zimmermann).
- Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.

Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
  as fallback if a driver registered the device itself (Daniel Vetter).
- Also explain that fallback in a comment in the code (Daniel Vetter).
- Don't encode in fbmem the assumption that sysfb will always register
  platform devices (Daniel Vetter).
- Add a FIXME comment about drivers registering devices (Daniel Vetter).

 drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 9b035ef4d552..265efa189bcc 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
 	if (do_free)
 		kfree(a);
 
+	/*
+	 * If a driver asked to unregister a platform device registered by
+	 * sysfb, then can be assumed that this is a driver for a display
+	 * that is set up by the system firmware and has a generic driver.
+	 *
+	 * Drivers for devices that don't have a generic driver will never
+	 * ask for this, so let's assume that a real driver for the display
+	 * was already probed and prevent sysfb to register devices later.
+	 */
+	sysfb_disable();
+
 	return 0;
 }
 EXPORT_SYMBOL(remove_conflicting_framebuffers);
-- 
2.35.1

[PATCH v5 6/7] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Javier Martinez Canillas]

From: Daniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.

With

commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jan 25 10:12:18 2022 +0100

    fbdev: Hot-unplug firmware fb devices on forced removal

this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).

Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

(no changes since v1)

 drivers/video/fbdev/efifb.c    | 11 -----------
 drivers/video/fbdev/simplefb.c | 11 -----------
 2 files changed, 22 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
 	char *option = NULL;
 	efi_memory_desc_t md;
 
-	/*
-	 * Generic drivers must not be registered if a framebuffer exists.
-	 * If a native driver was probed, the display hardware was already
-	 * taken and attempting to use the system framebuffer is dangerous.
-	 */
-	if (num_registered_fb > 0) {
-		dev_err(&dev->dev,
-			"efifb: a framebuffer is already registered\n");
-		return -EINVAL;
-	}
-
 	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
 		return -ENODEV;
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 94fc9c6d0411..0ef41173325a 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -413,17 +413,6 @@ static int simplefb_probe(struct platform_device *pdev)
 	struct simplefb_par *par;
 	struct resource *res, *mem;
 
-	/*
-	 * Generic drivers must not be registered if a framebuffer exists.
-	 * If a native driver was probed, the display hardware was already
-	 * taken and attempting to use the system framebuffer is dangerous.
-	 */
-	if (num_registered_fb > 0) {
-		dev_err(&pdev->dev,
-			"simplefb: a framebuffer is already registered\n");
-		return -EINVAL;
-	}
-
 	if (fb_get_options("simplefb", NULL))
 		return -ENODEV;
 
-- 
2.35.1

[PATCH v5 6/7] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Javier Martinez Canillas]

From: Daniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.

With

commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jan 25 10:12:18 2022 +0100

    fbdev: Hot-unplug firmware fb devices on forced removal

this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).

Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

(no changes since v1)

 drivers/video/fbdev/efifb.c    | 11 -----------
 drivers/video/fbdev/simplefb.c | 11 -----------
 2 files changed, 22 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
 	char *option = NULL;
 	efi_memory_desc_t md;
 
-	/*
-	 * Generic drivers must not be registered if a framebuffer exists.
-	 * If a native driver was probed, the display hardware was already
-	 * taken and attempting to use the system framebuffer is dangerous.
-	 */
-	if (num_registered_fb > 0) {
-		dev_err(&dev->dev,
-			"efifb: a framebuffer is already registered\n");
-		return -EINVAL;
-	}
-
 	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
 		return -ENODEV;
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 94fc9c6d0411..0ef41173325a 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -413,17 +413,6 @@ static int simplefb_probe(struct platform_device *pdev)
 	struct simplefb_par *par;
 	struct resource *res, *mem;
 
-	/*
-	 * Generic drivers must not be registered if a framebuffer exists.
-	 * If a native driver was probed, the display hardware was already
-	 * taken and attempting to use the system framebuffer is dangerous.
-	 */
-	if (num_registered_fb > 0) {
-		dev_err(&pdev->dev,
-			"simplefb: a framebuffer is already registered\n");
-		return -EINVAL;
-	}
-
 	if (fb_get_options("simplefb", NULL))
 		return -ENODEV;
 
-- 
2.35.1

[PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Javier Martinez Canillas]

From: Daniel Vetter <daniel.vetter@ffwll.ch>

Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.

Cc oldc_dcon maintainers as fyi.

v2: I typoed the config name (0day)

Cc: kernel test robot <lkp@intel.com>
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

(no changes since v1)

 drivers/video/fbdev/core/fbmem.c | 8 ++++++--
 include/linux/fb.h               | 7 +++----
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 265efa189bcc..6cab5f4c1fb3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -50,10 +50,14 @@
 static DEFINE_MUTEX(registration_lock);
 
 struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
 int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
 EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i)		\
+	for (i = 0; i < FB_MAX; i++)		\
+		if (!registered_fb[i]) {} else
 
 bool fb_center_logo __read_mostly;
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index bbe1e4571899..c563e24b6293 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -632,16 +632,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
 extern int fb_get_options(const char *name, char **option);
 extern int fb_new_modelist(struct fb_info *info);
 
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
 extern struct fb_info *registered_fb[FB_MAX];
+
 extern int num_registered_fb;
+#endif
 extern bool fb_center_logo;
 extern int fb_logo_count;
 extern struct class *fb_class;
 
-#define for_each_registered_fb(i)		\
-	for (i = 0; i < FB_MAX; i++)		\
-		if (!registered_fb[i]) {} else
-
 static inline void lock_fb_info(struct fb_info *info)
 {
 	mutex_lock(&info->lock);
-- 
2.35.1

[PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Javier Martinez Canillas]

From: Daniel Vetter <daniel.vetter@ffwll.ch>

Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.

Cc oldc_dcon maintainers as fyi.

v2: I typoed the config name (0day)

Cc: kernel test robot <lkp@intel.com>
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---

(no changes since v1)

 drivers/video/fbdev/core/fbmem.c | 8 ++++++--
 include/linux/fb.h               | 7 +++----
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 265efa189bcc..6cab5f4c1fb3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -50,10 +50,14 @@
 static DEFINE_MUTEX(registration_lock);
 
 struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
 int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
 EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i)		\
+	for (i = 0; i < FB_MAX; i++)		\
+		if (!registered_fb[i]) {} else
 
 bool fb_center_logo __read_mostly;
 
diff --git a/include/linux/fb.h b/include/linux/fb.h
index bbe1e4571899..c563e24b6293 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -632,16 +632,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
 extern int fb_get_options(const char *name, char **option);
 extern int fb_new_modelist(struct fb_info *info);
 
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
 extern struct fb_info *registered_fb[FB_MAX];
+
 extern int num_registered_fb;
+#endif
 extern bool fb_center_logo;
 extern int fb_logo_count;
 extern struct class *fb_class;
 
-#define for_each_registered_fb(i)		\
-	for (i = 0; i < FB_MAX; i++)		\
-		if (!registered_fb[i]) {} else
-
 static inline void lock_fb_info(struct fb_info *info)
 {
 	mutex_lock(&info->lock);
-- 
2.35.1

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 4254 bytes --]

Hi Javier

Am 11.05.22 um 13:30 schrieb Javier Martinez Canillas:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
> 
> This function takes the registration_lock mutex, to prevent a races when
> drivers register framebuffer devices. But if a conflicting framebuffer
> device is found, the underlaying platform device is unregistered and this
> will lead to the platform driver .remove callback to be called, which in
> turn will call to the unregister_framebuffer() that takes the same lock.
> 
> To prevent this, a struct fb_info.forced_out field was used as indication
> to unregister_framebuffer() whether the mutex has to be grabbed or not.
> 
> A cleaner solution is to drop the lock before platform_device_unregister()
> so unregister_framebuffer() can take it when called from the fbdev driver,
> and just grab the lock again after the device has been registered and do
> a removal loop restart.
> 
> Since the framebuffer devices will already be removed, the loop would just
> finish when no more conflicting framebuffers are found.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I'd like to shrink this patchset. This looks like it can be merged 
immediately?

Best regards
Thomas

> ---
> 
> (no changes since v1)
> 
>   drivers/video/fbdev/core/fbmem.c | 22 +++++++++++++++-------
>   include/linux/fb.h               |  1 -
>   2 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index b445a7a00def..2fda5917c212 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1555,6 +1555,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
>   {
>   	int i;
>   
> +restart_removal:
>   	/* check all firmware fbs and kick off if the base addr overlaps */
>   	for_each_registered_fb(i) {
>   		struct apertures_struct *gen_aper;
> @@ -1587,12 +1588,23 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
>   				pr_warn("fb%d: no device set\n", i);
>   				do_unregister_framebuffer(registered_fb[i]);
>   			} else if (dev_is_platform(device)) {
> -				registered_fb[i]->forced_out = true;
> +				/*
> +				 * Drop the lock because if the device is unregistered, its
> +				 * driver will call to unregister_framebuffer(), that takes
> +				 * this lock.
> +				 */
> +				mutex_unlock(&registration_lock);
>   				platform_device_unregister(to_platform_device(device));
> +				mutex_lock(&registration_lock);
>   			} else {
>   				pr_warn("fb%d: cannot remove device\n", i);
>   				do_unregister_framebuffer(registered_fb[i]);
>   			}
> +			/*
> +			 * Restart the removal loop now that the device has been
> +			 * unregistered and its associated framebuffer gone.
> +			 */
> +			goto restart_removal;
>   		}
>   	}
>   }
> @@ -1899,13 +1911,9 @@ EXPORT_SYMBOL(register_framebuffer);
>   void
>   unregister_framebuffer(struct fb_info *fb_info)
>   {
> -	bool forced_out = fb_info->forced_out;
> -
> -	if (!forced_out)
> -		mutex_lock(&registration_lock);
> +	mutex_lock(&registration_lock);
>   	do_unregister_framebuffer(fb_info);
> -	if (!forced_out)
> -		mutex_unlock(&registration_lock);
> +	mutex_unlock(&registration_lock);
>   }
>   EXPORT_SYMBOL(unregister_framebuffer);
>   
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 69c67c70fa78..bbe1e4571899 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -511,7 +511,6 @@ struct fb_info {
>   	} *apertures;
>   
>   	bool skip_vt_switch; /* no VT switch on suspend/resume required */
> -	bool forced_out; /* set when being removed by another driver */
>   };
>   
>   static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 4254 bytes --]

Hi Javier

Am 11.05.22 um 13:30 schrieb Javier Martinez Canillas:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
> 
> This function takes the registration_lock mutex, to prevent a races when
> drivers register framebuffer devices. But if a conflicting framebuffer
> device is found, the underlaying platform device is unregistered and this
> will lead to the platform driver .remove callback to be called, which in
> turn will call to the unregister_framebuffer() that takes the same lock.
> 
> To prevent this, a struct fb_info.forced_out field was used as indication
> to unregister_framebuffer() whether the mutex has to be grabbed or not.
> 
> A cleaner solution is to drop the lock before platform_device_unregister()
> so unregister_framebuffer() can take it when called from the fbdev driver,
> and just grab the lock again after the device has been registered and do
> a removal loop restart.
> 
> Since the framebuffer devices will already be removed, the loop would just
> finish when no more conflicting framebuffers are found.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I'd like to shrink this patchset. This looks like it can be merged 
immediately?

Best regards
Thomas

> ---
> 
> (no changes since v1)
> 
>   drivers/video/fbdev/core/fbmem.c | 22 +++++++++++++++-------
>   include/linux/fb.h               |  1 -
>   2 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index b445a7a00def..2fda5917c212 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1555,6 +1555,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
>   {
>   	int i;
>   
> +restart_removal:
>   	/* check all firmware fbs and kick off if the base addr overlaps */
>   	for_each_registered_fb(i) {
>   		struct apertures_struct *gen_aper;
> @@ -1587,12 +1588,23 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
>   				pr_warn("fb%d: no device set\n", i);
>   				do_unregister_framebuffer(registered_fb[i]);
>   			} else if (dev_is_platform(device)) {
> -				registered_fb[i]->forced_out = true;
> +				/*
> +				 * Drop the lock because if the device is unregistered, its
> +				 * driver will call to unregister_framebuffer(), that takes
> +				 * this lock.
> +				 */
> +				mutex_unlock(&registration_lock);
>   				platform_device_unregister(to_platform_device(device));
> +				mutex_lock(&registration_lock);
>   			} else {
>   				pr_warn("fb%d: cannot remove device\n", i);
>   				do_unregister_framebuffer(registered_fb[i]);
>   			}
> +			/*
> +			 * Restart the removal loop now that the device has been
> +			 * unregistered and its associated framebuffer gone.
> +			 */
> +			goto restart_removal;
>   		}
>   	}
>   }
> @@ -1899,13 +1911,9 @@ EXPORT_SYMBOL(register_framebuffer);
>   void
>   unregister_framebuffer(struct fb_info *fb_info)
>   {
> -	bool forced_out = fb_info->forced_out;
> -
> -	if (!forced_out)
> -		mutex_lock(&registration_lock);
> +	mutex_lock(&registration_lock);
>   	do_unregister_framebuffer(fb_info);
> -	if (!forced_out)
> -		mutex_unlock(&registration_lock);
> +	mutex_unlock(&registration_lock);
>   }
>   EXPORT_SYMBOL(unregister_framebuffer);
>   
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 69c67c70fa78..bbe1e4571899 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -511,7 +511,6 @@ struct fb_info {
>   	} *apertures;
>   
>   	bool skip_vt_switch; /* no VT switch on suspend/resume required */
> -	bool forced_out; /* set when being removed by another driver */
>   };
>   
>   static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 6439 bytes --]

Hi

Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> These can be used by subsystems to unregister a platform device registered
> by sysfb and also to disable future platform device registration in sysfb.
>

I find it very hard to review these patches, as related things are put 
into separate patches.

I suggest to put the sysfb_disable() stuff into patch 5 and the rest 
into patch 4.

Best regards
Thomas


> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> (no changes since v4)
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> 
> Changes in v2:
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
>   include/linux/sysfb.h                         | 19 ++++
>   3 files changed, 106 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
> index b81794e0cfbb..06ac89adaafb 100644
> --- a/Documentation/driver-api/firmware/other_interfaces.rst
> +++ b/Documentation/driver-api/firmware/other_interfaces.rst
> @@ -13,6 +13,12 @@ EDD Interfaces
>   .. kernel-doc:: drivers/firmware/edd.c
>      :internal:
>   
> +Generic System Framebuffers Interface
> +-------------------------------------
> +
> +.. kernel-doc:: drivers/firmware/sysfb.c
> +   :export:
> +
>   Intel Stratix10 SoC Service Layer
>   ---------------------------------
>   Some features of the Intel Stratix10 SoC require a level of privilege
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index b032f40a92de..6768968949e6 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -34,21 +34,92 @@
>   #include <linux/screen_info.h>
>   #include <linux/sysfb.h>
>   
> +static struct platform_device *pd;
> +static DEFINE_MUTEX(disable_lock);
> +static bool disabled;
> +
> +static bool sysfb_unregister(void)
> +{
> +	if (IS_ERR_OR_NULL(pd))
> +		return false;
> +
> +	platform_device_unregister(pd);
> +	pd = NULL;
> +
> +	return true;
> +}
> +
> +/**
> + * sysfb_disable() - disable the Generic System Framebuffers support
> + *
> + * This disables the registration of system framebuffer devices that match the
> + * generic drivers that make use of the system framebuffer set up by firmware.
> + *
> + * It also unregisters a device if this was already registered by sysfb_init().
> + *
> + * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a system framebuffer device and
> + *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
> + */
> +void sysfb_disable(void)
> +{
> +	mutex_lock(&disable_lock);
> +	sysfb_unregister();
> +	disabled = true;
> +	mutex_unlock(&disable_lock);
> +}
> +EXPORT_SYMBOL_GPL(sysfb_disable);
> +
> +/**
> + * sysfb_try_unregister() - attempt to unregister a system framebuffer device
> + * @dev: device to unregister
> + *
> + * This tries to unregister a system framebuffer device if this was registered
> + * by the Generic System Framebuffers. The device will only be unregistered if
> + * it was registered by sysfb_init(), otherwise it will not be unregistered.
> + *
> + * Context: The function can sleep. a @load_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a simple framebuffer device and
> + *          sysfb_disable(), that disables the Generic System Framebuffers support.
> + *
> + * Return:
> + * * true          - the device was unregistered successfully
> + * * false         - the device was not unregistered
> + */
> +bool sysfb_try_unregister(struct device *dev)
> +{
> +	bool ret = false;
> +
> +	mutex_lock(&disable_lock);
> +	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
> +		goto unlock_mutex;
> +
> +	ret = sysfb_unregister();
> +
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(sysfb_try_unregister);
> +
>   static __init int sysfb_init(void)
>   {
>   	struct screen_info *si = &screen_info;
>   	struct simplefb_platform_data mode;
> -	struct platform_device *pd;
>   	const char *name;
>   	bool compatible;
> -	int ret;
> +	int ret = 0;
> +
> +	mutex_lock(&disable_lock);
> +	if (disabled)
> +		goto unlock_mutex;
>   
>   	/* try to create a simple-framebuffer device */
>   	compatible = sysfb_parse_mode(si, &mode);
>   	if (compatible) {
>   		pd = sysfb_create_simplefb(si, &mode);
>   		if (!IS_ERR(pd))
> -			return 0;
> +			goto unlock_mutex;
>   	}
>   
>   	/* if the FB is incompatible, create a legacy framebuffer device */
> @@ -60,8 +131,10 @@ static __init int sysfb_init(void)
>   		name = "platform-framebuffer";
>   
>   	pd = platform_device_alloc(name, 0);
> -	if (!pd)
> -		return -ENOMEM;
> +	if (!pd) {
> +		ret = -ENOMEM;
> +		goto unlock_mutex;
> +	}
>   
>   	sysfb_apply_efi_quirks(pd);
>   
> @@ -73,9 +146,11 @@ static __init int sysfb_init(void)
>   	if (ret)
>   		goto err;
>   
> -	return 0;
> +	goto unlock_mutex;
>   err:
>   	platform_device_put(pd);
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
>   	return ret;
>   }
>   
> diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
> index 708152e9037b..e8c0313fac8f 100644
> --- a/include/linux/sysfb.h
> +++ b/include/linux/sysfb.h
> @@ -55,6 +55,25 @@ struct efifb_dmi_info {
>   	int flags;
>   };
>   
> +#ifdef CONFIG_SYSFB
> +
> +void sysfb_disable(void);
> +bool sysfb_try_unregister(struct device *dev);
> +
> +#else /* CONFIG_SYSFB */
> +
> +static inline void sysfb_disable(void)
> +{
> +
> +}
> +
> +static inline bool sysfb_try_unregister(struct device *dev)
> +{
> +	return false;
> +}
> +
> +#endif /* CONFIG_SYSFB */
> +
>   #ifdef CONFIG_EFI
>   
>   extern struct efifb_dmi_info efifb_dmi_list[];

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 6439 bytes --]

Hi

Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> These can be used by subsystems to unregister a platform device registered
> by sysfb and also to disable future platform device registration in sysfb.
>

I find it very hard to review these patches, as related things are put 
into separate patches.

I suggest to put the sysfb_disable() stuff into patch 5 and the rest 
into patch 4.

Best regards
Thomas


> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> (no changes since v4)
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> 
> Changes in v2:
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
>   include/linux/sysfb.h                         | 19 ++++
>   3 files changed, 106 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
> index b81794e0cfbb..06ac89adaafb 100644
> --- a/Documentation/driver-api/firmware/other_interfaces.rst
> +++ b/Documentation/driver-api/firmware/other_interfaces.rst
> @@ -13,6 +13,12 @@ EDD Interfaces
>   .. kernel-doc:: drivers/firmware/edd.c
>      :internal:
>   
> +Generic System Framebuffers Interface
> +-------------------------------------
> +
> +.. kernel-doc:: drivers/firmware/sysfb.c
> +   :export:
> +
>   Intel Stratix10 SoC Service Layer
>   ---------------------------------
>   Some features of the Intel Stratix10 SoC require a level of privilege
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index b032f40a92de..6768968949e6 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -34,21 +34,92 @@
>   #include <linux/screen_info.h>
>   #include <linux/sysfb.h>
>   
> +static struct platform_device *pd;
> +static DEFINE_MUTEX(disable_lock);
> +static bool disabled;
> +
> +static bool sysfb_unregister(void)
> +{
> +	if (IS_ERR_OR_NULL(pd))
> +		return false;
> +
> +	platform_device_unregister(pd);
> +	pd = NULL;
> +
> +	return true;
> +}
> +
> +/**
> + * sysfb_disable() - disable the Generic System Framebuffers support
> + *
> + * This disables the registration of system framebuffer devices that match the
> + * generic drivers that make use of the system framebuffer set up by firmware.
> + *
> + * It also unregisters a device if this was already registered by sysfb_init().
> + *
> + * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a system framebuffer device and
> + *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
> + */
> +void sysfb_disable(void)
> +{
> +	mutex_lock(&disable_lock);
> +	sysfb_unregister();
> +	disabled = true;
> +	mutex_unlock(&disable_lock);
> +}
> +EXPORT_SYMBOL_GPL(sysfb_disable);
> +
> +/**
> + * sysfb_try_unregister() - attempt to unregister a system framebuffer device
> + * @dev: device to unregister
> + *
> + * This tries to unregister a system framebuffer device if this was registered
> + * by the Generic System Framebuffers. The device will only be unregistered if
> + * it was registered by sysfb_init(), otherwise it will not be unregistered.
> + *
> + * Context: The function can sleep. a @load_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a simple framebuffer device and
> + *          sysfb_disable(), that disables the Generic System Framebuffers support.
> + *
> + * Return:
> + * * true          - the device was unregistered successfully
> + * * false         - the device was not unregistered
> + */
> +bool sysfb_try_unregister(struct device *dev)
> +{
> +	bool ret = false;
> +
> +	mutex_lock(&disable_lock);
> +	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
> +		goto unlock_mutex;
> +
> +	ret = sysfb_unregister();
> +
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(sysfb_try_unregister);
> +
>   static __init int sysfb_init(void)
>   {
>   	struct screen_info *si = &screen_info;
>   	struct simplefb_platform_data mode;
> -	struct platform_device *pd;
>   	const char *name;
>   	bool compatible;
> -	int ret;
> +	int ret = 0;
> +
> +	mutex_lock(&disable_lock);
> +	if (disabled)
> +		goto unlock_mutex;
>   
>   	/* try to create a simple-framebuffer device */
>   	compatible = sysfb_parse_mode(si, &mode);
>   	if (compatible) {
>   		pd = sysfb_create_simplefb(si, &mode);
>   		if (!IS_ERR(pd))
> -			return 0;
> +			goto unlock_mutex;
>   	}
>   
>   	/* if the FB is incompatible, create a legacy framebuffer device */
> @@ -60,8 +131,10 @@ static __init int sysfb_init(void)
>   		name = "platform-framebuffer";
>   
>   	pd = platform_device_alloc(name, 0);
> -	if (!pd)
> -		return -ENOMEM;
> +	if (!pd) {
> +		ret = -ENOMEM;
> +		goto unlock_mutex;
> +	}
>   
>   	sysfb_apply_efi_quirks(pd);
>   
> @@ -73,9 +146,11 @@ static __init int sysfb_init(void)
>   	if (ret)
>   		goto err;
>   
> -	return 0;
> +	goto unlock_mutex;
>   err:
>   	platform_device_put(pd);
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
>   	return ret;
>   }
>   
> diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
> index 708152e9037b..e8c0313fac8f 100644
> --- a/include/linux/sysfb.h
> +++ b/include/linux/sysfb.h
> @@ -55,6 +55,25 @@ struct efifb_dmi_info {
>   	int flags;
>   };
>   
> +#ifdef CONFIG_SYSFB
> +
> +void sysfb_disable(void);
> +bool sysfb_try_unregister(struct device *dev);
> +
> +#else /* CONFIG_SYSFB */
> +
> +static inline void sysfb_disable(void)
> +{
> +
> +}
> +
> +static inline bool sysfb_try_unregister(struct device *dev)
> +{
> +	return false;
> +}
> +
> +#endif /* CONFIG_SYSFB */
> +
>   #ifdef CONFIG_EFI
>   
>   extern struct efifb_dmi_info efifb_dmi_list[];

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 13:47, Thomas Zimmermann wrote:
> Hi Javier
> 
> Am 11.05.22 um 13:30 schrieb Javier Martinez Canillas:
>> Drivers that want to remove registered conflicting framebuffers prior to
>> register their own framebuffer, calls remove_conflicting_framebuffers().
>>
>> This function takes the registration_lock mutex, to prevent a races when
>> drivers register framebuffer devices. But if a conflicting framebuffer
>> device is found, the underlaying platform device is unregistered and this
>> will lead to the platform driver .remove callback to be called, which in
>> turn will call to the unregister_framebuffer() that takes the same lock.
>>
>> To prevent this, a struct fb_info.forced_out field was used as indication
>> to unregister_framebuffer() whether the mutex has to be grabbed or not.
>>
>> A cleaner solution is to drop the lock before platform_device_unregister()
>> so unregister_framebuffer() can take it when called from the fbdev driver,
>> and just grab the lock again after the device has been registered and do
>> a removal loop restart.
>>
>> Since the framebuffer devices will already be removed, the loop would just
>> finish when no more conflicting framebuffers are found.
>>
>> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> I'd like to shrink this patchset. This looks like it can be merged 

Same. At least this version dropped a few patches that we had in v4
(related to DRM_FIRMWARE capability flag).

> immediately?
>

Yes, this one is independent of the others and could be merged already.

> Best regards
> Thomas
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 13:47, Thomas Zimmermann wrote:
> Hi Javier
> 
> Am 11.05.22 um 13:30 schrieb Javier Martinez Canillas:
>> Drivers that want to remove registered conflicting framebuffers prior to
>> register their own framebuffer, calls remove_conflicting_framebuffers().
>>
>> This function takes the registration_lock mutex, to prevent a races when
>> drivers register framebuffer devices. But if a conflicting framebuffer
>> device is found, the underlaying platform device is unregistered and this
>> will lead to the platform driver .remove callback to be called, which in
>> turn will call to the unregister_framebuffer() that takes the same lock.
>>
>> To prevent this, a struct fb_info.forced_out field was used as indication
>> to unregister_framebuffer() whether the mutex has to be grabbed or not.
>>
>> A cleaner solution is to drop the lock before platform_device_unregister()
>> so unregister_framebuffer() can take it when called from the fbdev driver,
>> and just grab the lock again after the device has been registered and do
>> a removal loop restart.
>>
>> Since the framebuffer devices will already be removed, the loop would just
>> finish when no more conflicting framebuffers are found.
>>
>> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> I'd like to shrink this patchset. This looks like it can be merged 

Same. At least this version dropped a few patches that we had in v4
(related to DRM_FIRMWARE capability flag).

> immediately?
>

Yes, this one is independent of the others and could be merged already.

> Best regards
> Thomas
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 13:54, Thomas Zimmermann wrote:
> Hi
> 
> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>> These can be used by subsystems to unregister a platform device registered
>> by sysfb and also to disable future platform device registration in sysfb.
>>
> 
> I find it very hard to review these patches, as related things are put 
> into separate patches.
> 
> I suggest to put the sysfb_disable() stuff into patch 5 and the rest 
> into patch 4.
>

Ok, you then want in the same patch to have both the helper definition
and first usage.

Other subsystems ask you to do the opposite, to split the definition and
usage in separate patches. But I'm fine with merging those if you prefer.
 
> Best regards
> Thomas
> 
> 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 13:54, Thomas Zimmermann wrote:
> Hi
> 
> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>> These can be used by subsystems to unregister a platform device registered
>> by sysfb and also to disable future platform device registration in sysfb.
>>
> 
> I find it very hard to review these patches, as related things are put 
> into separate patches.
> 
> I suggest to put the sysfb_disable() stuff into patch 5 and the rest 
> into patch 4.
>

Ok, you then want in the same patch to have both the helper definition
and first usage.

Other subsystems ask you to do the opposite, to split the definition and
usage in separate patches. But I'm fine with merging those if you prefer.
 
> Best regards
> Thomas
> 
> 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 6615 bytes --]



Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> These can be used by subsystems to unregister a platform device registered
> by sysfb and also to disable future platform device registration in sysfb.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> (no changes since v4)
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> 
> Changes in v2:
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
>   include/linux/sysfb.h                         | 19 ++++
>   3 files changed, 106 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
> index b81794e0cfbb..06ac89adaafb 100644
> --- a/Documentation/driver-api/firmware/other_interfaces.rst
> +++ b/Documentation/driver-api/firmware/other_interfaces.rst
> @@ -13,6 +13,12 @@ EDD Interfaces
>   .. kernel-doc:: drivers/firmware/edd.c
>      :internal:
>   
> +Generic System Framebuffers Interface
> +-------------------------------------
> +
> +.. kernel-doc:: drivers/firmware/sysfb.c
> +   :export:
> +
>   Intel Stratix10 SoC Service Layer
>   ---------------------------------
>   Some features of the Intel Stratix10 SoC require a level of privilege
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index b032f40a92de..6768968949e6 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -34,21 +34,92 @@
>   #include <linux/screen_info.h>
>   #include <linux/sysfb.h>
>   
> +static struct platform_device *pd;
> +static DEFINE_MUTEX(disable_lock);
> +static bool disabled;
> +
> +static bool sysfb_unregister(void)
> +{
> +	if (IS_ERR_OR_NULL(pd))
> +		return false;
> +
> +	platform_device_unregister(pd);
> +	pd = NULL;
> +
> +	return true;
> +}
> +
> +/**
> + * sysfb_disable() - disable the Generic System Framebuffers support
> + *
> + * This disables the registration of system framebuffer devices that match the
> + * generic drivers that make use of the system framebuffer set up by firmware.
> + *
> + * It also unregisters a device if this was already registered by sysfb_init().

Why? I still cannot wrap my mind around, why we need to store *pd at all 
and use sysfb_try_unregister() for unregistering.

> + *
> + * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a system framebuffer device and
> + *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
> + */
> +void sysfb_disable(void)
> +{
> +	mutex_lock(&disable_lock);
> +	sysfb_unregister();
> +	disabled = true;
> +	mutex_unlock(&disable_lock);
> +}
> +EXPORT_SYMBOL_GPL(sysfb_disable);
> +
> +/**
> + * sysfb_try_unregister() - attempt to unregister a system framebuffer device
> + * @dev: device to unregister
> + *
> + * This tries to unregister a system framebuffer device if this was registered
> + * by the Generic System Framebuffers. The device will only be unregistered if
> + * it was registered by sysfb_init(), otherwise it will not be unregistered.
> + *
> + * Context: The function can sleep. a @load_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a simple framebuffer device and
> + *          sysfb_disable(), that disables the Generic System Framebuffers support.
> + *
> + * Return:
> + * * true          - the device was unregistered successfully
> + * * false         - the device was not unregistered
> + */
> +bool sysfb_try_unregister(struct device *dev)

As it stands, I strongly object the use of this function as still don't 
really get the purpose. It looks like a glorified wrapper around 
platform_device_unregister(). Do we need disable_lock to serialize with 
something else?

Best regards
Thomas


> +{
> +	bool ret = false;
> +
> +	mutex_lock(&disable_lock);
> +	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
> +		goto unlock_mutex;
> +
> +	ret = sysfb_unregister();
> +
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(sysfb_try_unregister);
> +
>   static __init int sysfb_init(void)
>   {
>   	struct screen_info *si = &screen_info;
>   	struct simplefb_platform_data mode;
> -	struct platform_device *pd;
>   	const char *name;
>   	bool compatible;
> -	int ret;
> +	int ret = 0;
> +
> +	mutex_lock(&disable_lock);
> +	if (disabled)
> +		goto unlock_mutex;
>   
>   	/* try to create a simple-framebuffer device */
>   	compatible = sysfb_parse_mode(si, &mode);
>   	if (compatible) {
>   		pd = sysfb_create_simplefb(si, &mode);
>   		if (!IS_ERR(pd))
> -			return 0;
> +			goto unlock_mutex;
>   	}
>   
>   	/* if the FB is incompatible, create a legacy framebuffer device */
> @@ -60,8 +131,10 @@ static __init int sysfb_init(void)
>   		name = "platform-framebuffer";
>   
>   	pd = platform_device_alloc(name, 0);
> -	if (!pd)
> -		return -ENOMEM;
> +	if (!pd) {
> +		ret = -ENOMEM;
> +		goto unlock_mutex;
> +	}
>   
>   	sysfb_apply_efi_quirks(pd);
>   
> @@ -73,9 +146,11 @@ static __init int sysfb_init(void)
>   	if (ret)
>   		goto err;
>   
> -	return 0;
> +	goto unlock_mutex;
>   err:
>   	platform_device_put(pd);
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
>   	return ret;
>   }
>   
> diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
> index 708152e9037b..e8c0313fac8f 100644
> --- a/include/linux/sysfb.h
> +++ b/include/linux/sysfb.h
> @@ -55,6 +55,25 @@ struct efifb_dmi_info {
>   	int flags;
>   };
>   
> +#ifdef CONFIG_SYSFB
> +
> +void sysfb_disable(void);
> +bool sysfb_try_unregister(struct device *dev);
> +
> +#else /* CONFIG_SYSFB */
> +
> +static inline void sysfb_disable(void)
> +{
> +
> +}
> +
> +static inline bool sysfb_try_unregister(struct device *dev)
> +{
> +	return false;
> +}
> +
> +#endif /* CONFIG_SYSFB */
> +
>   #ifdef CONFIG_EFI
>   
>   extern struct efifb_dmi_info efifb_dmi_list[];

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 6615 bytes --]



Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> These can be used by subsystems to unregister a platform device registered
> by sysfb and also to disable future platform device registration in sysfb.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> (no changes since v4)
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> 
> Changes in v2:
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 87 +++++++++++++++++--
>   include/linux/sysfb.h                         | 19 ++++
>   3 files changed, 106 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
> index b81794e0cfbb..06ac89adaafb 100644
> --- a/Documentation/driver-api/firmware/other_interfaces.rst
> +++ b/Documentation/driver-api/firmware/other_interfaces.rst
> @@ -13,6 +13,12 @@ EDD Interfaces
>   .. kernel-doc:: drivers/firmware/edd.c
>      :internal:
>   
> +Generic System Framebuffers Interface
> +-------------------------------------
> +
> +.. kernel-doc:: drivers/firmware/sysfb.c
> +   :export:
> +
>   Intel Stratix10 SoC Service Layer
>   ---------------------------------
>   Some features of the Intel Stratix10 SoC require a level of privilege
> diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
> index b032f40a92de..6768968949e6 100644
> --- a/drivers/firmware/sysfb.c
> +++ b/drivers/firmware/sysfb.c
> @@ -34,21 +34,92 @@
>   #include <linux/screen_info.h>
>   #include <linux/sysfb.h>
>   
> +static struct platform_device *pd;
> +static DEFINE_MUTEX(disable_lock);
> +static bool disabled;
> +
> +static bool sysfb_unregister(void)
> +{
> +	if (IS_ERR_OR_NULL(pd))
> +		return false;
> +
> +	platform_device_unregister(pd);
> +	pd = NULL;
> +
> +	return true;
> +}
> +
> +/**
> + * sysfb_disable() - disable the Generic System Framebuffers support
> + *
> + * This disables the registration of system framebuffer devices that match the
> + * generic drivers that make use of the system framebuffer set up by firmware.
> + *
> + * It also unregisters a device if this was already registered by sysfb_init().

Why? I still cannot wrap my mind around, why we need to store *pd at all 
and use sysfb_try_unregister() for unregistering.

> + *
> + * Context: The function can sleep. A @disable_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a system framebuffer device and
> + *          sysfb_try_unregister(), that tries to unregister a framebuffer device.
> + */
> +void sysfb_disable(void)
> +{
> +	mutex_lock(&disable_lock);
> +	sysfb_unregister();
> +	disabled = true;
> +	mutex_unlock(&disable_lock);
> +}
> +EXPORT_SYMBOL_GPL(sysfb_disable);
> +
> +/**
> + * sysfb_try_unregister() - attempt to unregister a system framebuffer device
> + * @dev: device to unregister
> + *
> + * This tries to unregister a system framebuffer device if this was registered
> + * by the Generic System Framebuffers. The device will only be unregistered if
> + * it was registered by sysfb_init(), otherwise it will not be unregistered.
> + *
> + * Context: The function can sleep. a @load_lock mutex is acquired to serialize
> + *          against sysfb_init(), that registers a simple framebuffer device and
> + *          sysfb_disable(), that disables the Generic System Framebuffers support.
> + *
> + * Return:
> + * * true          - the device was unregistered successfully
> + * * false         - the device was not unregistered
> + */
> +bool sysfb_try_unregister(struct device *dev)

As it stands, I strongly object the use of this function as still don't 
really get the purpose. It looks like a glorified wrapper around 
platform_device_unregister(). Do we need disable_lock to serialize with 
something else?

Best regards
Thomas


> +{
> +	bool ret = false;
> +
> +	mutex_lock(&disable_lock);
> +	if (IS_ERR_OR_NULL(pd) || pd != to_platform_device(dev))
> +		goto unlock_mutex;
> +
> +	ret = sysfb_unregister();
> +
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(sysfb_try_unregister);
> +
>   static __init int sysfb_init(void)
>   {
>   	struct screen_info *si = &screen_info;
>   	struct simplefb_platform_data mode;
> -	struct platform_device *pd;
>   	const char *name;
>   	bool compatible;
> -	int ret;
> +	int ret = 0;
> +
> +	mutex_lock(&disable_lock);
> +	if (disabled)
> +		goto unlock_mutex;
>   
>   	/* try to create a simple-framebuffer device */
>   	compatible = sysfb_parse_mode(si, &mode);
>   	if (compatible) {
>   		pd = sysfb_create_simplefb(si, &mode);
>   		if (!IS_ERR(pd))
> -			return 0;
> +			goto unlock_mutex;
>   	}
>   
>   	/* if the FB is incompatible, create a legacy framebuffer device */
> @@ -60,8 +131,10 @@ static __init int sysfb_init(void)
>   		name = "platform-framebuffer";
>   
>   	pd = platform_device_alloc(name, 0);
> -	if (!pd)
> -		return -ENOMEM;
> +	if (!pd) {
> +		ret = -ENOMEM;
> +		goto unlock_mutex;
> +	}
>   
>   	sysfb_apply_efi_quirks(pd);
>   
> @@ -73,9 +146,11 @@ static __init int sysfb_init(void)
>   	if (ret)
>   		goto err;
>   
> -	return 0;
> +	goto unlock_mutex;
>   err:
>   	platform_device_put(pd);
> +unlock_mutex:
> +	mutex_unlock(&disable_lock);
>   	return ret;
>   }
>   
> diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
> index 708152e9037b..e8c0313fac8f 100644
> --- a/include/linux/sysfb.h
> +++ b/include/linux/sysfb.h
> @@ -55,6 +55,25 @@ struct efifb_dmi_info {
>   	int flags;
>   };
>   
> +#ifdef CONFIG_SYSFB
> +
> +void sysfb_disable(void);
> +bool sysfb_try_unregister(struct device *dev);
> +
> +#else /* CONFIG_SYSFB */
> +
> +static inline void sysfb_disable(void)
> +{
> +
> +}
> +
> +static inline bool sysfb_try_unregister(struct device *dev)
> +{
> +	return false;
> +}
> +
> +#endif /* CONFIG_SYSFB */
> +
>   #ifdef CONFIG_EFI
>   
>   extern struct efifb_dmi_info efifb_dmi_list[];

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer

[Javier Martinez Canillas]

On 5/11/22 13:24, Javier Martinez Canillas wrote:
> This function just returned 0 on success or an errno code on error, but it
> could be useful for sysfb_init() callers to have a pointer to the device.
> 
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> 

Thomas,

This patch can also be merged already if you want to shrink the set
more. Even though no caller would use the new return value yet, it
is a standalone change and already reviewed by Daniel and you.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer

[Javier Martinez Canillas]

On 5/11/22 13:24, Javier Martinez Canillas wrote:
> This function just returned 0 on success or an errno code on error, but it
> could be useful for sysfb_init() callers to have a pointer to the device.
> 
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> 

Thomas,

This patch can also be merged already if you want to shrink the set
more. Even though no caller would use the new return value yet, it
is a standalone change and already reviewed by Daniel and you.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

Hi

Am 11.05.22 um 14:01 schrieb Javier Martinez Canillas:
> Hello Thomas,
> 
> On 5/11/22 13:54, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>>> These can be used by subsystems to unregister a platform device registered
>>> by sysfb and also to disable future platform device registration in sysfb.
>>>
>>
>> I find it very hard to review these patches, as related things are put
>> into separate patches.
>>
>> I suggest to put the sysfb_disable() stuff into patch 5 and the rest
>> into patch 4.
>>
> 
> Ok, you then want in the same patch to have both the helper definition
> and first usage.
> 
> Other subsystems ask you to do the opposite, to split the definition and
> usage in separate patches. But I'm fine with merging those if you prefer.

Usually, I have no strong opinion on this. But in the case of this 
specific patchset, I have the feeling that I'm missing some important 
point because call and implementation are separate.  See my other 
replies for that.  Putting them next to each other will hopefully help. 
Sorry for the inconvenience.

Best regards
Thomas

>   
>> Best regards
>> Thomas
>>
>>

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

Hi

Am 11.05.22 um 14:01 schrieb Javier Martinez Canillas:
> Hello Thomas,
> 
> On 5/11/22 13:54, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>>> These can be used by subsystems to unregister a platform device registered
>>> by sysfb and also to disable future platform device registration in sysfb.
>>>
>>
>> I find it very hard to review these patches, as related things are put
>> into separate patches.
>>
>> I suggest to put the sysfb_disable() stuff into patch 5 and the rest
>> into patch 4.
>>
> 
> Ok, you then want in the same patch to have both the helper definition
> and first usage.
> 
> Other subsystems ask you to do the opposite, to split the definition and
> usage in separate patches. But I'm fine with merging those if you prefer.

Usually, I have no strong opinion on this. But in the case of this 
specific patchset, I have the feeling that I'm missing some important 
point because call and implementation are separate.  See my other 
replies for that.  Putting them next to each other will hopefully help. 
Sorry for the inconvenience.

Best regards
Thomas

>   
>> Best regards
>> Thomas
>>
>>

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 14:02, Thomas Zimmermann wrote:

[snip]

>> +
>> +/**
>> + * sysfb_disable() - disable the Generic System Framebuffers support
>> + *
>> + * This disables the registration of system framebuffer devices that match the
>> + * generic drivers that make use of the system framebuffer set up by firmware.
>> + *
>> + * It also unregisters a device if this was already registered by sysfb_init().
> 
> Why? I still cannot wrap my mind around, why we need to store *pd at all 
> and use sysfb_try_unregister() for unregistering.
>

Because on sysfb_disable(), the registered platform device has to unregistered.

And sysfb has no way to know if it was unregistered already or not unless that
stage is maintained in sysfb itself.

Let's have some examples assuming that we don't have this helper in sysfb
(will use the vc4 DRM driver just to avoid typing "a real DRM driver).

a) simplefb probed and then vc4

   1) "simple-framebuffer" pdev is registered by sysfb
   2) simplefb is registered and matches "simple-framebuffer"
   3) a vc4 device is registered by OF when parsing the DTB
   4) vc4 driver is registered, matches vc4 and probes
   5) vc4 requests the conflicting framebuffers to be removed
      and fbmem unregisters "simple-framebuffer"
   6) fbmem calls sysfb_disable()
   7) sysfb_disable() should unregister the pdev but can't
      because has no way to know that fbmem already did that.
 
b) vc4 probed and then simplefb.ko module is loaded

   1) "simple-framebuffer" pdev is registered by sysfb
   2) a vc4 device is registered by OF when parsing the DTB
   3) vc4 driver is registered, matches vc4 and probes
   4) vc4 requests the conflicting framebuffers to be removed
      and fbmem unregisters "simple-framebuffer"
   5) fbmem calls sysfb_disable()
   6) sysfb_disable() should unregister the pdev but can't
      because has no way to know that fbmem already did that.
   7) simplefb.ko is loaded and simplefb driver registered
   8) simplefb matches the registered "simple-framebuffer"
      and will wrongly probe and register a DRM device.

In option (a), making sysfb_disable() to attempt to unregister the device
that register in sysfb_init() will lead to a use-after-free if this was
already unregistered by fbmem in remove_conflicting_framebuffers(), so
it can't attempt to do that.

Same for option (b), but sysfb_disable() can't rely on fbmem to do the
unregistration because it only does for devices that are associated with
an already registered fbdev.

[snip]

>> + * Return:
>> + * * true          - the device was unregistered successfully
>> + * * false         - the device was not unregistered
>> + */
>> +bool sysfb_try_unregister(struct device *dev)
> 
> As it stands, I strongly object the use of this function as still don't 

No worries, it's my bad since I clearly failed to explain the rationale in
the commit message and comments.

> really get the purpose. It looks like a glorified wrapper around 
> platform_device_unregister(). Do we need disable_lock to serialize with 
> something else?
>

Yes, it has to serialize with sysfb_init() and sysfb_disable().
 
> Best regards
> Thomas
> 
> 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 14:02, Thomas Zimmermann wrote:

[snip]

>> +
>> +/**
>> + * sysfb_disable() - disable the Generic System Framebuffers support
>> + *
>> + * This disables the registration of system framebuffer devices that match the
>> + * generic drivers that make use of the system framebuffer set up by firmware.
>> + *
>> + * It also unregisters a device if this was already registered by sysfb_init().
> 
> Why? I still cannot wrap my mind around, why we need to store *pd at all 
> and use sysfb_try_unregister() for unregistering.
>

Because on sysfb_disable(), the registered platform device has to unregistered.

And sysfb has no way to know if it was unregistered already or not unless that
stage is maintained in sysfb itself.

Let's have some examples assuming that we don't have this helper in sysfb
(will use the vc4 DRM driver just to avoid typing "a real DRM driver).

a) simplefb probed and then vc4

   1) "simple-framebuffer" pdev is registered by sysfb
   2) simplefb is registered and matches "simple-framebuffer"
   3) a vc4 device is registered by OF when parsing the DTB
   4) vc4 driver is registered, matches vc4 and probes
   5) vc4 requests the conflicting framebuffers to be removed
      and fbmem unregisters "simple-framebuffer"
   6) fbmem calls sysfb_disable()
   7) sysfb_disable() should unregister the pdev but can't
      because has no way to know that fbmem already did that.
 
b) vc4 probed and then simplefb.ko module is loaded

   1) "simple-framebuffer" pdev is registered by sysfb
   2) a vc4 device is registered by OF when parsing the DTB
   3) vc4 driver is registered, matches vc4 and probes
   4) vc4 requests the conflicting framebuffers to be removed
      and fbmem unregisters "simple-framebuffer"
   5) fbmem calls sysfb_disable()
   6) sysfb_disable() should unregister the pdev but can't
      because has no way to know that fbmem already did that.
   7) simplefb.ko is loaded and simplefb driver registered
   8) simplefb matches the registered "simple-framebuffer"
      and will wrongly probe and register a DRM device.

In option (a), making sysfb_disable() to attempt to unregister the device
that register in sysfb_init() will lead to a use-after-free if this was
already unregistered by fbmem in remove_conflicting_framebuffers(), so
it can't attempt to do that.

Same for option (b), but sysfb_disable() can't rely on fbmem to do the
unregistration because it only does for devices that are associated with
an already registered fbdev.

[snip]

>> + * Return:
>> + * * true          - the device was unregistered successfully
>> + * * false         - the device was not unregistered
>> + */
>> +bool sysfb_try_unregister(struct device *dev)
> 
> As it stands, I strongly object the use of this function as still don't 

No worries, it's my bad since I clearly failed to explain the rationale in
the commit message and comments.

> really get the purpose. It looks like a glorified wrapper around 
> platform_device_unregister(). Do we need disable_lock to serialize with 
> something else?
>

Yes, it has to serialize with sysfb_init() and sysfb_disable().
 
> Best regards
> Thomas
> 
> 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 14:05, Thomas Zimmermann wrote:

[snip]

>>
>> Other subsystems ask you to do the opposite, to split the definition and
>> usage in separate patches. But I'm fine with merging those if you prefer.
> 
> Usually, I have no strong opinion on this. But in the case of this 
> specific patchset, I have the feeling that I'm missing some important 
> point because call and implementation are separate.  See my other 
> replies for that.  Putting them next to each other will hopefully help. 
> Sorry for the inconvenience.
>

No worries at all. Happy to do that change if the patches are easy to
understand. It took me some time as well to wrap my head around all
the race conditions and needed locking.

Same for patch 3/7, but I'm convinced that dropping the lock is the
correct thing to do than calling to drivers' .remove callbacks with
a lock held.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration

[Javier Martinez Canillas]

Hello Thomas,

On 5/11/22 14:05, Thomas Zimmermann wrote:

[snip]

>>
>> Other subsystems ask you to do the opposite, to split the definition and
>> usage in separate patches. But I'm fine with merging those if you prefer.
> 
> Usually, I have no strong opinion on this. But in the case of this 
> specific patchset, I have the feeling that I'm missing some important 
> point because call and implementation are separate.  See my other 
> replies for that.  Putting them next to each other will hopefully help. 
> Sorry for the inconvenience.
>

No worries at all. Happy to do that change if the patches are easy to
understand. It took me some time as well to wrap my head around all
the race conditions and needed locking.

Same for patch 3/7, but I'm convinced that dropping the lock is the
correct thing to do than calling to drivers' .remove callbacks with
a lock held.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Sam Ravnborg]

Hi Javier.

On Wed, May 11, 2022 at 01:32:30PM +0200, Javier Martinez Canillas wrote:
> From: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
> 
> Cc oldc_dcon maintainers as fyi.

Another way to fix this is to mark FB_OLPC_DCON and add a TODO entry to
fix this. We are really not supposed to carry such special code around
to keep staging working.

I know this may not be a popular viewpoint, but just look at the ugly
workarounds required here.

	Sam


> 
> v2: I typoed the config name (0day)
> 
> Cc: kernel test robot <lkp@intel.com>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-staging@lists.linux.dev
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> ---
> 
> (no changes since v1)
> 
>  drivers/video/fbdev/core/fbmem.c | 8 ++++++--
>  include/linux/fb.h               | 7 +++----
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 265efa189bcc..6cab5f4c1fb3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -50,10 +50,14 @@
>  static DEFINE_MUTEX(registration_lock);
>  
>  struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
>  int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
>  EXPORT_SYMBOL(num_registered_fb);
> +#endif

It is stuff like this I refer to as "ugly" in the comment above.

	Sam

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Sam Ravnborg]

Hi Javier.

On Wed, May 11, 2022 at 01:32:30PM +0200, Javier Martinez Canillas wrote:
> From: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
> 
> Cc oldc_dcon maintainers as fyi.

Another way to fix this is to mark FB_OLPC_DCON and add a TODO entry to
fix this. We are really not supposed to carry such special code around
to keep staging working.

I know this may not be a popular viewpoint, but just look at the ugly
workarounds required here.

	Sam


> 
> v2: I typoed the config name (0day)
> 
> Cc: kernel test robot <lkp@intel.com>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-staging@lists.linux.dev
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> ---
> 
> (no changes since v1)
> 
>  drivers/video/fbdev/core/fbmem.c | 8 ++++++--
>  include/linux/fb.h               | 7 +++----
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 265efa189bcc..6cab5f4c1fb3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -50,10 +50,14 @@
>  static DEFINE_MUTEX(registration_lock);
>  
>  struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
>  int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
>  EXPORT_SYMBOL(num_registered_fb);
> +#endif

It is stuff like this I refer to as "ugly" in the comment above.

	Sam

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Guenter Roeck]

On 5/11/22 10:00, Sam Ravnborg wrote:
> Hi Javier.
> 
> On Wed, May 11, 2022 at 01:32:30PM +0200, Javier Martinez Canillas wrote:
>> From: Daniel Vetter <daniel.vetter@ffwll.ch>
>>
>> Well except when the olpc dcon fbdev driver is enabled, that thing
>> digs around in there in rather unfixable ways.
>>
>> Cc oldc_dcon maintainers as fyi.
> 
> Another way to fix this is to mark FB_OLPC_DCON and add a TODO entry to
> fix this. We are really not supposed to carry such special code around
> to keep staging working.
> 
> I know this may not be a popular viewpoint, but just look at the ugly
> workarounds required here.
> 
> 	Sam
> 
> 
>>
>> v2: I typoed the config name (0day)
>>
>> Cc: kernel test robot <lkp@intel.com>
>> Cc: Jens Frederich <jfrederich@gmail.com>
>> Cc: Jon Nettleton <jon.nettleton@gmail.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: linux-staging@lists.linux.dev
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Helge Deller <deller@gmx.de>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
>> Cc: Zhen Lei <thunder.leizhen@huawei.com>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
>> Cc: linux-fbdev@vger.kernel.org
>> Cc: Zheyu Ma <zheyuma97@gmail.com>
>> Cc: Guenter Roeck <linux@roeck-us.net>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> ---
>>
>> (no changes since v1)
>>
>>   drivers/video/fbdev/core/fbmem.c | 8 ++++++--
>>   include/linux/fb.h               | 7 +++----
>>   2 files changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index 265efa189bcc..6cab5f4c1fb3 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -50,10 +50,14 @@
>>   static DEFINE_MUTEX(registration_lock);
>>   
>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
>> -EXPORT_SYMBOL(registered_fb);
>> -
>>   int num_registered_fb __read_mostly;
>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
>> +EXPORT_SYMBOL(registered_fb);
>>   EXPORT_SYMBOL(num_registered_fb);
>> +#endif
> 
> It is stuff like this I refer to as "ugly" in the comment above.
> 

My "solution" for that kind of thing is to use a namespace,
such as

EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);

and import it from the offending code. That avoids ifdefs
while at the same time limiting the use of the symbols
to the expected scope. Of course that could be abused but
that abuse would be obvious.

Guenter

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Guenter Roeck]

On 5/11/22 10:00, Sam Ravnborg wrote:
> Hi Javier.
> 
> On Wed, May 11, 2022 at 01:32:30PM +0200, Javier Martinez Canillas wrote:
>> From: Daniel Vetter <daniel.vetter@ffwll.ch>
>>
>> Well except when the olpc dcon fbdev driver is enabled, that thing
>> digs around in there in rather unfixable ways.
>>
>> Cc oldc_dcon maintainers as fyi.
> 
> Another way to fix this is to mark FB_OLPC_DCON and add a TODO entry to
> fix this. We are really not supposed to carry such special code around
> to keep staging working.
> 
> I know this may not be a popular viewpoint, but just look at the ugly
> workarounds required here.
> 
> 	Sam
> 
> 
>>
>> v2: I typoed the config name (0day)
>>
>> Cc: kernel test robot <lkp@intel.com>
>> Cc: Jens Frederich <jfrederich@gmail.com>
>> Cc: Jon Nettleton <jon.nettleton@gmail.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: linux-staging@lists.linux.dev
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Helge Deller <deller@gmx.de>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
>> Cc: Zhen Lei <thunder.leizhen@huawei.com>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
>> Cc: linux-fbdev@vger.kernel.org
>> Cc: Zheyu Ma <zheyuma97@gmail.com>
>> Cc: Guenter Roeck <linux@roeck-us.net>
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> ---
>>
>> (no changes since v1)
>>
>>   drivers/video/fbdev/core/fbmem.c | 8 ++++++--
>>   include/linux/fb.h               | 7 +++----
>>   2 files changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index 265efa189bcc..6cab5f4c1fb3 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -50,10 +50,14 @@
>>   static DEFINE_MUTEX(registration_lock);
>>   
>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
>> -EXPORT_SYMBOL(registered_fb);
>> -
>>   int num_registered_fb __read_mostly;
>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
>> +EXPORT_SYMBOL(registered_fb);
>>   EXPORT_SYMBOL(num_registered_fb);
>> +#endif
> 
> It is stuff like this I refer to as "ugly" in the comment above.
> 

My "solution" for that kind of thing is to use a namespace,
such as

EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);

and import it from the offending code. That avoids ifdefs
while at the same time limiting the use of the symbols
to the expected scope. Of course that could be abused but
that abuse would be obvious.

Guenter

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Javier Martinez Canillas]

Hello Guenter,

On 5/11/22 19:17, Guenter Roeck wrote:
> On 5/11/22 10:00, Sam Ravnborg wrote:

[snip]

>>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
>>> -EXPORT_SYMBOL(registered_fb);
>>> -
>>>   int num_registered_fb __read_mostly;
>>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
>>> +EXPORT_SYMBOL(registered_fb);
>>>   EXPORT_SYMBOL(num_registered_fb);
>>> +#endif
>>
>> It is stuff like this I refer to as "ugly" in the comment above.
>>
> 
> My "solution" for that kind of thing is to use a namespace,
> such as
> 
> EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
> EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);
>

Using a namespace in this case is indeed a great idea I think.

I've used in the past to limit the export of a symbol for within a driver
that could be scattered across different compilations units, but it never
occurred to me using it to limit symbols exported by core code.
 
> and import it from the offending code. That avoids ifdefs
> while at the same time limiting the use of the symbols
> to the expected scope. Of course that could be abused but
> that abuse would be obvious.
>

Agreed. For the next revision, besides using an namespaced export symbol
as you suggested, I'll include a comment to make clear that it shouldn't
by any other driver and FB_OLPC_DCON fixed instead.


-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Javier Martinez Canillas]

Hello Guenter,

On 5/11/22 19:17, Guenter Roeck wrote:
> On 5/11/22 10:00, Sam Ravnborg wrote:

[snip]

>>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
>>> -EXPORT_SYMBOL(registered_fb);
>>> -
>>>   int num_registered_fb __read_mostly;
>>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
>>> +EXPORT_SYMBOL(registered_fb);
>>>   EXPORT_SYMBOL(num_registered_fb);
>>> +#endif
>>
>> It is stuff like this I refer to as "ugly" in the comment above.
>>
> 
> My "solution" for that kind of thing is to use a namespace,
> such as
> 
> EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
> EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);
>

Using a namespace in this case is indeed a great idea I think.

I've used in the past to limit the export of a symbol for within a driver
that could be scattered across different compilations units, but it never
occurred to me using it to limit symbols exported by core code.
 
> and import it from the offending code. That avoids ifdefs
> while at the same time limiting the use of the symbols
> to the expected scope. Of course that could be abused but
> that abuse would be obvious.
>

Agreed. For the next revision, besides using an namespaced export symbol
as you suggested, I'll include a comment to make clear that it shouldn't
by any other driver and FB_OLPC_DCON fixed instead.


-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Sam Ravnborg]

On Wed, May 11, 2022 at 07:34:38PM +0200, Javier Martinez Canillas wrote:
> Hello Guenter,
> 
> On 5/11/22 19:17, Guenter Roeck wrote:
> > On 5/11/22 10:00, Sam Ravnborg wrote:
> 
> [snip]
> 
> >>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
> >>> -EXPORT_SYMBOL(registered_fb);
> >>> -
> >>>   int num_registered_fb __read_mostly;
> >>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
> >>> +EXPORT_SYMBOL(registered_fb);
> >>>   EXPORT_SYMBOL(num_registered_fb);
> >>> +#endif
> >>
> >> It is stuff like this I refer to as "ugly" in the comment above.
> >>
> > 
> > My "solution" for that kind of thing is to use a namespace,
> > such as
> > 
> > EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
> > EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);
> >
> 
> Using a namespace in this case is indeed a great idea I think.
> 
> I've used in the past to limit the export of a symbol for within a driver
> that could be scattered across different compilations units, but it never
> occurred to me using it to limit symbols exported by core code.
>  
> > and import it from the offending code. That avoids ifdefs
> > while at the same time limiting the use of the symbols
> > to the expected scope. Of course that could be abused but
> > that abuse would be obvious.
> >
> 
> Agreed. For the next revision, besides using an namespaced export symbol
> as you suggested, I'll include a comment to make clear that it shouldn't
> by any other driver and FB_OLPC_DCON fixed instead.
A very nice compromise, thanks Guenter and Javier.

	Sam

Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c

[Sam Ravnborg]

On Wed, May 11, 2022 at 07:34:38PM +0200, Javier Martinez Canillas wrote:
> Hello Guenter,
> 
> On 5/11/22 19:17, Guenter Roeck wrote:
> > On 5/11/22 10:00, Sam Ravnborg wrote:
> 
> [snip]
> 
> >>>   struct fb_info *registered_fb[FB_MAX] __read_mostly;
> >>> -EXPORT_SYMBOL(registered_fb);
> >>> -
> >>>   int num_registered_fb __read_mostly;
> >>> +#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
> >>> +EXPORT_SYMBOL(registered_fb);
> >>>   EXPORT_SYMBOL(num_registered_fb);
> >>> +#endif
> >>
> >> It is stuff like this I refer to as "ugly" in the comment above.
> >>
> > 
> > My "solution" for that kind of thing is to use a namespace,
> > such as
> > 
> > EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
> > EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);
> >
> 
> Using a namespace in this case is indeed a great idea I think.
> 
> I've used in the past to limit the export of a symbol for within a driver
> that could be scattered across different compilations units, but it never
> occurred to me using it to limit symbols exported by core code.
>  
> > and import it from the offending code. That avoids ifdefs
> > while at the same time limiting the use of the symbols
> > to the expected scope. Of course that could be abused but
> > that abuse would be obvious.
> >
> 
> Agreed. For the next revision, besides using an namespaced export symbol
> as you suggested, I'll include a comment to make clear that it shouldn't
> by any other driver and FB_OLPC_DCON fixed instead.
A very nice compromise, thanks Guenter and Javier.

	Sam

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 7952 bytes --]

Hi Javier,

thanks again for providing the examples. I think I now better get what 
you're trying to solve.

First of all let's merge patch 3, as it seems unrelated.

For the other patches, I'd like to take a step back and try to solve the 
broader problem. IIRC we talked about this briefly already.

 From my understanding, the problem of the current code is that removal 
of the firmware device is build around drivers (either DRM or fbdev). 
Everything works fine if a driver is bound to the firmware device and 
the native driver can remove it.  In other case, we have to manually 
disable sysfb and force-remove unbound firmware devices.  And the 
patchset doesn't even cover firmware devices that come from DT nodes.

But what we really want is to track resource ownership based on devices. 
When we add a firmware device (via sysfb or DT), we immediately add it 
to a list of firmware devices. When the native driver arrives, it can 
remove the firmware device even if no driver has been bound.

We can also operate in the other way if the native drivers implicitly 
reserves the framebuffer range. If sysfb would try to register a 
firmware device in that range, he can let it fail. No more need to fully 
disable sysfb on the first arriving native device.

We already track the memory ranges in drm aperture helpers. We'd need to 
move the code to a more prominent location (e.g., <linux/aperture.h>) 
and change fbdev to use it. Sysfb and DT code needs to insert platform 
devices upon creation. We can then implement the more fancy stuff, such 
as tracking native-device memory.  (And if we ever get to fix all usage 
of Linux' request-mem-region, we can even move all the functionality there).

Best regards
Thomas


Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> Hello,
> 
> The patches in this series contain mostly changes suggested by Daniel Vetter
> Thomas Zimmermann. They aim to fix existing races between the Generic System
> Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.
> 
> For example, it is currently possible for sysfb to register a platform
> device after a real DRM driver was registered and requested to remove the
> conflicting framebuffers. Or is possible for a simple{fb,drm} to match with
> a device previously registered by sysfb, even after a real driver is present.
> 
> A symptom of this issue, was worked around with the commit fb561bf9abde
> ("fbdev: Prevent probing generic drivers if a FB is already registered")
> but that's really a hack and should be reverted instead.
> 
> This series attempt to fix it more correctly and revert the mentioned hack.
> That will also allow to make the num_registered_fb variable not visible to
> drivers anymore, since that's internal to fbdev core.
> 
> Pach 1 is just a simple cleanup in preparation for later patches.
> 
> Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow
> disabling sysfb and attempt to unregister registered devices respectively.
> 
> Patch 3 changes how is dealt with conflicting framebuffers unregistering,
> rather than having a variable to determine if a lock should be take, it
> just drops the lock before unregistering the platform device.
> 
> Patch 4 changes the fbdev core to not attempt to unregister devices that
> were registered by sysfb, let the same code doing the registration to also
> handle the unregistration.
> 
> Patch 5 fixes the race that exists between sysfb devices registration and
> fbdev framebuffer devices registration, by disabling the sysfb when a DRM
> or fbdev driver requests to remove conflicting framebuffers.
> 
> Patch 6 is the revert patch that was posted by Daniel before but dropped
> from his set and finally patch 7 is the one that makes num_registered_fb
> private to fbmem.c, to not allow drivers to use it anymore.
> 
> The patches were tested on a rpi4 with the vc4, simpledrm and simplefb
> drivers, using different combinations of built-in and as a module.
> 
> For example, having simpledrm as a module and loading it after the vc4
> driver probed would not register a DRM device, which happens now without
> the patches from this series.
> 
> Best regards,
> Javier
> 
> Changes in v5:
> - Move the sysfb_disable() call at conflicting framebuffers again to
>    avoid the need of a DRIVER_FIRMWARE capability flag.
> - Add Daniel Vetter's Reviewed-by tag again since reverted to the old
>    patch that he already reviewed in v2.
> - Drop patches that added a DRM_FIRMWARE capability and use them
>    since the case those prevented could be ignored (Daniel Vetter).
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> - Drop call to sysfb_disable() in fbmem since is done in other places now.
> - Add patch to make registered_fb[] private.
> - Add patches that introduce the DRM_FIRMWARE capability and usage.
> 
> Changes in v3:
> - Add Thomas Zimmermann's Reviewed-by tag to patch #1.
> - Call sysfb_disable() when a DRM dev and a fbdev are registered rather
>    than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Call sysfb_disable() when a fbdev framebuffer is registered rather
>    than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
> - Rebase on top of latest drm-misc-next branch.
> 
> Changes in v2:
> - Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> - Explain in the commit message that fbmem has to unregister the device
>    as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>    platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> - Explain in the commit message that fbmem has to unregister the device
>    as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>    platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> - Drop RFC prefix since patches were already reviewed by Daniel Vetter.
> - Add Daniel Reviewed-by tags to the patches.
> 
> Daniel Vetter (2):
>    Revert "fbdev: Prevent probing generic drivers if a FB is already
>      registered"
>    fbdev: Make registered_fb[] private to fbmem.c
> 
> Javier Martinez Canillas (5):
>    firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
>    firmware: sysfb: Add helpers to unregister a pdev and disable
>      registration
>    fbdev: Restart conflicting fb removal loop when unregistering devices
>    fbdev: Make sysfb to unregister its own registered devices
>    fbdev: Disable sysfb device registration when removing conflicting FBs
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 91 +++++++++++++++++--
>   drivers/firmware/sysfb_simplefb.c             | 16 ++--
>   drivers/video/fbdev/core/fbmem.c              | 67 +++++++++++---
>   drivers/video/fbdev/efifb.c                   | 11 ---
>   drivers/video/fbdev/simplefb.c                | 11 ---
>   include/linux/fb.h                            |  8 +-
>   include/linux/sysfb.h                         | 29 +++++-
>   8 files changed, 178 insertions(+), 61 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 7952 bytes --]

Hi Javier,

thanks again for providing the examples. I think I now better get what 
you're trying to solve.

First of all let's merge patch 3, as it seems unrelated.

For the other patches, I'd like to take a step back and try to solve the 
broader problem. IIRC we talked about this briefly already.

 From my understanding, the problem of the current code is that removal 
of the firmware device is build around drivers (either DRM or fbdev). 
Everything works fine if a driver is bound to the firmware device and 
the native driver can remove it.  In other case, we have to manually 
disable sysfb and force-remove unbound firmware devices.  And the 
patchset doesn't even cover firmware devices that come from DT nodes.

But what we really want is to track resource ownership based on devices. 
When we add a firmware device (via sysfb or DT), we immediately add it 
to a list of firmware devices. When the native driver arrives, it can 
remove the firmware device even if no driver has been bound.

We can also operate in the other way if the native drivers implicitly 
reserves the framebuffer range. If sysfb would try to register a 
firmware device in that range, he can let it fail. No more need to fully 
disable sysfb on the first arriving native device.

We already track the memory ranges in drm aperture helpers. We'd need to 
move the code to a more prominent location (e.g., <linux/aperture.h>) 
and change fbdev to use it. Sysfb and DT code needs to insert platform 
devices upon creation. We can then implement the more fancy stuff, such 
as tracking native-device memory.  (And if we ever get to fix all usage 
of Linux' request-mem-region, we can even move all the functionality there).

Best regards
Thomas


Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
> Hello,
> 
> The patches in this series contain mostly changes suggested by Daniel Vetter
> Thomas Zimmermann. They aim to fix existing races between the Generic System
> Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.
> 
> For example, it is currently possible for sysfb to register a platform
> device after a real DRM driver was registered and requested to remove the
> conflicting framebuffers. Or is possible for a simple{fb,drm} to match with
> a device previously registered by sysfb, even after a real driver is present.
> 
> A symptom of this issue, was worked around with the commit fb561bf9abde
> ("fbdev: Prevent probing generic drivers if a FB is already registered")
> but that's really a hack and should be reverted instead.
> 
> This series attempt to fix it more correctly and revert the mentioned hack.
> That will also allow to make the num_registered_fb variable not visible to
> drivers anymore, since that's internal to fbdev core.
> 
> Pach 1 is just a simple cleanup in preparation for later patches.
> 
> Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow
> disabling sysfb and attempt to unregister registered devices respectively.
> 
> Patch 3 changes how is dealt with conflicting framebuffers unregistering,
> rather than having a variable to determine if a lock should be take, it
> just drops the lock before unregistering the platform device.
> 
> Patch 4 changes the fbdev core to not attempt to unregister devices that
> were registered by sysfb, let the same code doing the registration to also
> handle the unregistration.
> 
> Patch 5 fixes the race that exists between sysfb devices registration and
> fbdev framebuffer devices registration, by disabling the sysfb when a DRM
> or fbdev driver requests to remove conflicting framebuffers.
> 
> Patch 6 is the revert patch that was posted by Daniel before but dropped
> from his set and finally patch 7 is the one that makes num_registered_fb
> private to fbmem.c, to not allow drivers to use it anymore.
> 
> The patches were tested on a rpi4 with the vc4, simpledrm and simplefb
> drivers, using different combinations of built-in and as a module.
> 
> For example, having simpledrm as a module and loading it after the vc4
> driver probed would not register a DRM device, which happens now without
> the patches from this series.
> 
> Best regards,
> Javier
> 
> Changes in v5:
> - Move the sysfb_disable() call at conflicting framebuffers again to
>    avoid the need of a DRIVER_FIRMWARE capability flag.
> - Add Daniel Vetter's Reviewed-by tag again since reverted to the old
>    patch that he already reviewed in v2.
> - Drop patches that added a DRM_FIRMWARE capability and use them
>    since the case those prevented could be ignored (Daniel Vetter).
> 
> Changes in v4:
> - Make sysfb_disable() to also attempt to unregister a device.
> - Drop call to sysfb_disable() in fbmem since is done in other places now.
> - Add patch to make registered_fb[] private.
> - Add patches that introduce the DRM_FIRMWARE capability and usage.
> 
> Changes in v3:
> - Add Thomas Zimmermann's Reviewed-by tag to patch #1.
> - Call sysfb_disable() when a DRM dev and a fbdev are registered rather
>    than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Call sysfb_disable() when a fbdev framebuffer is registered rather
>    than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
> - Rebase on top of latest drm-misc-next branch.
> 
> Changes in v2:
> - Rebase on top of latest drm-misc-next and fix conflicts (Daniel Vetter).
> - Add kernel-doc comments and include in other_interfaces.rst (Daniel Vetter).
> - Explain in the commit message that fbmem has to unregister the device
>    as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>    platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> - Explain in the commit message that fbmem has to unregister the device
>    as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>    platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> - Drop RFC prefix since patches were already reviewed by Daniel Vetter.
> - Add Daniel Reviewed-by tags to the patches.
> 
> Daniel Vetter (2):
>    Revert "fbdev: Prevent probing generic drivers if a FB is already
>      registered"
>    fbdev: Make registered_fb[] private to fbmem.c
> 
> Javier Martinez Canillas (5):
>    firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
>    firmware: sysfb: Add helpers to unregister a pdev and disable
>      registration
>    fbdev: Restart conflicting fb removal loop when unregistering devices
>    fbdev: Make sysfb to unregister its own registered devices
>    fbdev: Disable sysfb device registration when removing conflicting FBs
> 
>   .../driver-api/firmware/other_interfaces.rst  |  6 ++
>   drivers/firmware/sysfb.c                      | 91 +++++++++++++++++--
>   drivers/firmware/sysfb_simplefb.c             | 16 ++--
>   drivers/video/fbdev/core/fbmem.c              | 67 +++++++++++---
>   drivers/video/fbdev/efifb.c                   | 11 ---
>   drivers/video/fbdev/simplefb.c                | 11 ---
>   include/linux/fb.h                            |  8 +-
>   include/linux/sysfb.h                         | 29 +++++-
>   8 files changed, 178 insertions(+), 61 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Javier Martinez Canillas]

Hello Thomas,

Thanks for your feedback and comments.

On 5/13/22 12:48, Thomas Zimmermann wrote:
> Hi Javier,
> 
> thanks again for providing the examples. I think I now better get what 
> you're trying to solve.
>

You are welcome.
 
> First of all let's merge patch 3, as it seems unrelated.
>

Agreed. I can push it to drm-misc-next.
 
> For the other patches, I'd like to take a step back and try to solve the 
> broader problem. IIRC we talked about this briefly already.
> 

Yes, that's what we discussed on IRC some time ago.

>  From my understanding, the problem of the current code is that removal 
> of the firmware device is build around drivers (either DRM or fbdev). 
> Everything works fine if a driver is bound to the firmware device and 
> the native driver can remove it.  In other case, we have to manually 

And this is the common case, since most kernels will have some driver
that binds to a platform device registered to provide the firmware FB.

> disable sysfb and force-remove unbound firmware devices.  And the 
> patchset doesn't even cover firmware devices that come from DT nodes.
>

Indeed.
 
> But what we really want is to track resource ownership based on devices. 
> When we add a firmware device (via sysfb or DT), we immediately add it 
> to a list of firmware devices. When the native driver arrives, it can 
> remove the firmware device even if no driver has been bound.
> 
> We can also operate in the other way if the native drivers implicitly 
> reserves the framebuffer range. If sysfb would try to register a 
> firmware device in that range, he can let it fail. No more need to fully 
> disable sysfb on the first arriving native device.
> 
> We already track the memory ranges in drm aperture helpers. We'd need to 
> move the code to a more prominent location (e.g., <linux/aperture.h>) 
> and change fbdev to use it. Sysfb and DT code needs to insert platform 
> devices upon creation. We can then implement the more fancy stuff, such 
> as tracking native-device memory.  (And if we ever get to fix all usage 
> of Linux' request-mem-region, we can even move all the functionality there).
>

Agreed. And as mentioned, the race that these patches attempt to fix are for
the less common case when a native driver probes but either no generic driver
registered a framebuffer yet or the platform device wasn't registered yet.

But this can only happen if for example a native driver is built-in but the
generic driver is build as a module, which is not the common configuration.

What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.

So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Javier Martinez Canillas]

Hello Thomas,

Thanks for your feedback and comments.

On 5/13/22 12:48, Thomas Zimmermann wrote:
> Hi Javier,
> 
> thanks again for providing the examples. I think I now better get what 
> you're trying to solve.
>

You are welcome.
 
> First of all let's merge patch 3, as it seems unrelated.
>

Agreed. I can push it to drm-misc-next.
 
> For the other patches, I'd like to take a step back and try to solve the 
> broader problem. IIRC we talked about this briefly already.
> 

Yes, that's what we discussed on IRC some time ago.

>  From my understanding, the problem of the current code is that removal 
> of the firmware device is build around drivers (either DRM or fbdev). 
> Everything works fine if a driver is bound to the firmware device and 
> the native driver can remove it.  In other case, we have to manually 

And this is the common case, since most kernels will have some driver
that binds to a platform device registered to provide the firmware FB.

> disable sysfb and force-remove unbound firmware devices.  And the 
> patchset doesn't even cover firmware devices that come from DT nodes.
>

Indeed.
 
> But what we really want is to track resource ownership based on devices. 
> When we add a firmware device (via sysfb or DT), we immediately add it 
> to a list of firmware devices. When the native driver arrives, it can 
> remove the firmware device even if no driver has been bound.
> 
> We can also operate in the other way if the native drivers implicitly 
> reserves the framebuffer range. If sysfb would try to register a 
> firmware device in that range, he can let it fail. No more need to fully 
> disable sysfb on the first arriving native device.
> 
> We already track the memory ranges in drm aperture helpers. We'd need to 
> move the code to a more prominent location (e.g., <linux/aperture.h>) 
> and change fbdev to use it. Sysfb and DT code needs to insert platform 
> devices upon creation. We can then implement the more fancy stuff, such 
> as tracking native-device memory.  (And if we ever get to fix all usage 
> of Linux' request-mem-region, we can even move all the functionality there).
>

Agreed. And as mentioned, the race that these patches attempt to fix are for
the less common case when a native driver probes but either no generic driver
registered a framebuffer yet or the platform device wasn't registered yet.

But this can only happen if for example a native driver is built-in but the
generic driver is build as a module, which is not the common configuration.

What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.

So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2235 bytes --]

Hi Javier

Am 13.05.22 um 13:10 schrieb Javier Martinez Canillas:
...
>> We already track the memory ranges in drm aperture helpers. We'd need to
>> move the code to a more prominent location (e.g., <linux/aperture.h>)
>> and change fbdev to use it. Sysfb and DT code needs to insert platform
>> devices upon creation. We can then implement the more fancy stuff, such
>> as tracking native-device memory.  (And if we ever get to fix all usage
>> of Linux' request-mem-region, we can even move all the functionality there).
>>
> 
> Agreed. And as mentioned, the race that these patches attempt to fix are for
> the less common case when a native driver probes but either no generic driver
> registered a framebuffer yet or the platform device wasn't registered yet.
> 
> But this can only happen if for example a native driver is built-in but the
> generic driver is build as a module, which is not the common configuration.
> 
> What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
> simpledrm built-in and the native drivers built as modules.
> 
> So there's no rush to fix this by piling more hacks on top of the ones we
> already have and instead try to fix it more properly as you suggested.
>   

A first step would be to use DRM's aperture helpers in fbdev. That would 
be a good idea anyway, as it would simplify both. You already mentioned 
some API changes to make aperture helpers DRM-independent.

The affected fbdev drivers use platform devices, so this should be easy.

Aperture helpers have something like the registration_lock. [1] I don't 
know if we need to recreate patch 3 for this as well.

If we absolutely need some special detachment handling for fbdev, we can 
make devm_aperture_aquire() a public interface. The detach helper is 
provided by the caller.

Best regards
Thomas


[1] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L254
[2] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L159

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2235 bytes --]

Hi Javier

Am 13.05.22 um 13:10 schrieb Javier Martinez Canillas:
...
>> We already track the memory ranges in drm aperture helpers. We'd need to
>> move the code to a more prominent location (e.g., <linux/aperture.h>)
>> and change fbdev to use it. Sysfb and DT code needs to insert platform
>> devices upon creation. We can then implement the more fancy stuff, such
>> as tracking native-device memory.  (And if we ever get to fix all usage
>> of Linux' request-mem-region, we can even move all the functionality there).
>>
> 
> Agreed. And as mentioned, the race that these patches attempt to fix are for
> the less common case when a native driver probes but either no generic driver
> registered a framebuffer yet or the platform device wasn't registered yet.
> 
> But this can only happen if for example a native driver is built-in but the
> generic driver is build as a module, which is not the common configuration.
> 
> What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
> simpledrm built-in and the native drivers built as modules.
> 
> So there's no rush to fix this by piling more hacks on top of the ones we
> already have and instead try to fix it more properly as you suggested.
>   

A first step would be to use DRM's aperture helpers in fbdev. That would 
be a good idea anyway, as it would simplify both. You already mentioned 
some API changes to make aperture helpers DRM-independent.

The affected fbdev drivers use platform devices, so this should be easy.

Aperture helpers have something like the registration_lock. [1] I don't 
know if we need to recreate patch 3 for this as well.

If we absolutely need some special detachment handling for fbdev, we can 
make devm_aperture_aquire() a public interface. The detach helper is 
provided by the caller.

Best regards
Thomas


[1] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L254
[2] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L159

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

On 5/11/22 13:30, Javier Martinez Canillas wrote:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
> 
> This function takes the registration_lock mutex, to prevent a races when
> drivers register framebuffer devices. But if a conflicting framebuffer
> device is found, the underlaying platform device is unregistered and this
> will lead to the platform driver .remove callback to be called, which in
> turn will call to the unregister_framebuffer() that takes the same lock.
> 
> To prevent this, a struct fb_info.forced_out field was used as indication
> to unregister_framebuffer() whether the mutex has to be grabbed or not.
> 
> A cleaner solution is to drop the lock before platform_device_unregister()
> so unregister_framebuffer() can take it when called from the fbdev driver,
> and just grab the lock again after the device has been registered and do
> a removal loop restart.
> 
> Since the framebuffer devices will already be removed, the loop would just
> finish when no more conflicting framebuffers are found.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
Pushed this to drm-misc (drm-misc-next). Thanks all!

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

On 5/11/22 13:30, Javier Martinez Canillas wrote:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
> 
> This function takes the registration_lock mutex, to prevent a races when
> drivers register framebuffer devices. But if a conflicting framebuffer
> device is found, the underlaying platform device is unregistered and this
> will lead to the platform driver .remove callback to be called, which in
> turn will call to the unregister_framebuffer() that takes the same lock.
> 
> To prevent this, a struct fb_info.forced_out field was used as indication
> to unregister_framebuffer() whether the mutex has to be grabbed or not.
> 
> A cleaner solution is to drop the lock before platform_device_unregister()
> so unregister_framebuffer() can take it when called from the fbdev driver,
> and just grab the lock again after the device has been registered and do
> a removal loop restart.
> 
> Since the framebuffer devices will already be removed, the loop would just
> finish when no more conflicting framebuffers are found.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
Pushed this to drm-misc (drm-misc-next). Thanks all!

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs

[Daniel Vetter]

On Wed, May 11, 2022 at 01:31:44PM +0200, Javier Martinez Canillas wrote:
> The platform devices registered by sysfb match with firmware-based DRM or
> fbdev drivers, that are used to have early graphics using a framebuffer
> provided by the system firmware.
> 
> DRM or fbdev drivers later are probed and remove all conflicting framebuffers,
> leading to these platform devices for generic drivers to be unregistered.
> 
> But the current solution has a race, since the sysfb_init() function could
> be called after a DRM or fbdev driver is probed and request to unregister
> the devices for drivers with conflicting framebuffes.
> 
> To prevent this, disable any future sysfb platform device registration by
> calling sysfb_disable(), if a driver requests to remove the conflicting
> framebuffers.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> Changes in v5:
> - Move the sysfb_disable() call at conflicting framebuffers again to
>   avoid the need of a DRIVER_FIRMWARE capability flag.
> - Add Daniel Vetter's Reviewed-by tag again since reverted to the old
>   patch that he already reviewed in v2.
> 
> Changes in v3:
> - Call sysfb_disable() when a DRM dev and a fbdev are registered rather
>   than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Call sysfb_disable() when a fbdev framebuffer is registered rather
>   than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
> 
> Changes in v2:
> - Explain in the commit message that fbmem has to unregister the device
>   as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>   platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> 
>  drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 9b035ef4d552..265efa189bcc 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
>  	if (do_free)
>  		kfree(a);
>  
> +	/*
> +	 * If a driver asked to unregister a platform device registered by
> +	 * sysfb, then can be assumed that this is a driver for a display
> +	 * that is set up by the system firmware and has a generic driver.
> +	 *
> +	 * Drivers for devices that don't have a generic driver will never
> +	 * ask for this, so let's assume that a real driver for the display
> +	 * was already probed and prevent sysfb to register devices later.
> +	 */
> +	sysfb_disable();

So the og version had (or should have had at least) the sysfb_disable()
call before we go through the loop and try to unregister stuff. I think
this needs to be done before we call do_remove_conflicting_framebuffer()
instead. With that:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(remove_conflicting_framebuffers);
> -- 
> 2.35.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs

[Daniel Vetter]

On Wed, May 11, 2022 at 01:31:44PM +0200, Javier Martinez Canillas wrote:
> The platform devices registered by sysfb match with firmware-based DRM or
> fbdev drivers, that are used to have early graphics using a framebuffer
> provided by the system firmware.
> 
> DRM or fbdev drivers later are probed and remove all conflicting framebuffers,
> leading to these platform devices for generic drivers to be unregistered.
> 
> But the current solution has a race, since the sysfb_init() function could
> be called after a DRM or fbdev driver is probed and request to unregister
> the devices for drivers with conflicting framebuffes.
> 
> To prevent this, disable any future sysfb platform device registration by
> calling sysfb_disable(), if a driver requests to remove the conflicting
> framebuffers.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 
> Changes in v5:
> - Move the sysfb_disable() call at conflicting framebuffers again to
>   avoid the need of a DRIVER_FIRMWARE capability flag.
> - Add Daniel Vetter's Reviewed-by tag again since reverted to the old
>   patch that he already reviewed in v2.
> 
> Changes in v3:
> - Call sysfb_disable() when a DRM dev and a fbdev are registered rather
>   than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Call sysfb_disable() when a fbdev framebuffer is registered rather
>   than when conflicting framebuffers are removed (Thomas Zimmermann).
> - Drop Daniel Vetter's Reviewed-by tag since patch changed a lot.
> 
> Changes in v2:
> - Explain in the commit message that fbmem has to unregister the device
>   as fallback if a driver registered the device itself (Daniel Vetter).
> - Also explain that fallback in a comment in the code (Daniel Vetter).
> - Don't encode in fbmem the assumption that sysfb will always register
>   platform devices (Daniel Vetter).
> - Add a FIXME comment about drivers registering devices (Daniel Vetter).
> 
>  drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 9b035ef4d552..265efa189bcc 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
>  	if (do_free)
>  		kfree(a);
>  
> +	/*
> +	 * If a driver asked to unregister a platform device registered by
> +	 * sysfb, then can be assumed that this is a driver for a display
> +	 * that is set up by the system firmware and has a generic driver.
> +	 *
> +	 * Drivers for devices that don't have a generic driver will never
> +	 * ask for this, so let's assume that a real driver for the display
> +	 * was already probed and prevent sysfb to register devices later.
> +	 */
> +	sysfb_disable();

So the og version had (or should have had at least) the sysfb_disable()
call before we go through the loop and try to unregister stuff. I think
this needs to be done before we call do_remove_conflicting_framebuffer()
instead. With that:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(remove_conflicting_framebuffers);
> -- 
> 2.35.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs

[Javier Martinez Canillas]

Hello Daniel,

On 6/7/22 17:01, Daniel Vetter wrote:

[snip]

>>
>>  drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index 9b035ef4d552..265efa189bcc 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
>>  	if (do_free)
>>  		kfree(a);
>>  
>> +	/*
>> +	 * If a driver asked to unregister a platform device registered by
>> +	 * sysfb, then can be assumed that this is a driver for a display
>> +	 * that is set up by the system firmware and has a generic driver.
>> +	 *
>> +	 * Drivers for devices that don't have a generic driver will never
>> +	 * ask for this, so let's assume that a real driver for the display
>> +	 * was already probed and prevent sysfb to register devices later.
>> +	 */
>> +	sysfb_disable();
> 
> So the og version had (or should have had at least) the sysfb_disable()
> call before we go through the loop and try to unregister stuff. I think
> this needs to be done before we call do_remove_conflicting_framebuffer()
> instead. With that:
>

Yes, the original version did that but also the original version didn't
attempt to remove the devices registered by sysfb on sysfb_disable().

I was going to answer that this has to be done after the loop because
that way fbmem could first ask sysfb to remove the devices, but then I
realized that you are correct That this wouldn't be needed if sysfb does
the disable (and unregistration) before the loop.

So by doing it before the loop, we should be able to drop [PATCH v5 4/7]
fbdev: Make sysfb to unregister its own registered devices:

https://lists.freedesktop.org/archives/dri-devel/2022-May/355201.html

Since by the time the loop is executed, no registered_fb associated with
a device that was registered by sysfb should be present in that array.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat