From: Javier Martinez Canillas <javierm@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Javier Martinez Canillas <javierm@redhat.com>,
Alex Deucher <alexander.deucher@amd.com>,
Changcheng Deng <deng.changcheng@zte.com.cn>,
Daniel Vetter <daniel@ffwll.ch>, Helge Deller <deller@gmx.de>,
Sam Ravnborg <sam@ravnborg.org>,
Zhen Lei <thunder.leizhen@huawei.com>,
linux-fbdev@vger.kernel.org
Subject: [RFC PATCH v4 07/11] fbdev: Make sysfb to unregister its own registered devices
Date: Fri, 29 Apr 2022 10:42:49 +0200 [thread overview]
Message-ID: <20220429084253.1085911-8-javierm@redhat.com> (raw)
In-Reply-To: <20220429084253.1085911-1-javierm@redhat.com>
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>
---
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 | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0bb459258df3..d6ae33990f40 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1585,18 +1585,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(®istration_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(®istration_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
next prev parent reply other threads:[~2022-04-29 8:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 8:42 [RFC PATCH v4 00/11] Fix some race between sysfb device registration and drivers probe Javier Martinez Canillas
2022-04-29 8:42 ` [RFC PATCH v4 06/11] fbdev: Restart conflicting fb removal loop when unregistering devices Javier Martinez Canillas
2022-04-29 8:42 ` Javier Martinez Canillas [this message]
2022-04-29 8:42 ` [RFC PATCH v4 08/11] fbdev: Fix race between sysfb and framebuffer devices registration Javier Martinez Canillas
2022-04-29 8:42 ` [RFC PATCH v4 10/11] Revert "fbdev: Prevent probing generic drivers if a FB is already registered" Javier Martinez Canillas
2022-04-29 8:42 ` [RFC PATCH v4 11/11] fbdev: Make registered_fb[] private to fbmem.c Javier Martinez Canillas
2022-04-29 15:02 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220429084253.1085911-8-javierm@redhat.com \
--to=javierm@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=deng.changcheng@zte.com.cn \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=thunder.leizhen@huawei.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).