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@xxxxxxxx> >> Signed-off-by: Javier Martinez Canillas <javierm@xxxxxxxxxx> >> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > 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
