Messages in this thread | | | Date | Wed, 11 May 2022 13:57:49 +0200 | Subject | Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices | From | 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
| |