[PATCH] simplefb: Disable and release clocks and regulators in destroy callback

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Note this introduces asymmetry in how the resources are claimed and
released.

Signed-off-by: Chen-Yu Tsai <redacted>
---
 drivers/video/fbdev/simplefb.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index e9cf19977285..3620d10a0d00 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c

@@ -74,8 +74,14 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 	return 0;
 }
 
+struct simplefb_par;
+static void simplefb_clocks_destroy(struct simplefb_par *par);
+static void simplefb_regulators_destroy(struct simplefb_par *par);
+
 static void simplefb_destroy(struct fb_info *info)
 {
+	simplefb_regulators_destroy(info->par);
+	simplefb_clocks_destroy(info->par);
 	if (info->screen_base)
 		iounmap(info->screen_base);
 }

@@ -487,11 +493,8 @@ error_fb_release:
 static int simplefb_remove(struct platform_device *pdev)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
-	struct simplefb_par *par = info->par;
 
 	unregister_framebuffer(info);
-	simplefb_regulators_destroy(par);
-	simplefb_clocks_destroy(par);
 	framebuffer_release(info);
 
 	return 0;

-- 
2.9.3

Hi,

On 07-09-16 11:09, Chen-Yu Tsai wrote:

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Note this introduces asymmetry in how the resources are claimed and
released.

Signed-off-by: Chen-Yu Tsai <redacted>

Good catch, patch LGTM:

Reviewed-by: Hans de Goede <redacted>

Regards,

Hans

On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai [off-list ref] wrote:

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Is this called before or after the new proper framebuffer driver kicks in?
If before, it may cause glitches.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Hi,

On 07-09-16 13:12, Geert Uytterhoeven wrote:

On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai [off-list ref] wrote:

quoted

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Is this called before or after the new proper framebuffer driver kicks in?
If before, it may cause glitches.

It is called by the new proper framebuffer driver's probe method,
so it can make sure that it has already claimed / enabled the
clocks/regulators before it calls remove_conlicting_framebuffers,
avoiding the glitch.

Regards,

Hans

Hi Hans,

On Wed, Sep 7, 2016 at 1:29 PM, Hans de Goede [off-list ref] wrote:

On 07-09-16 13:12, Geert Uytterhoeven wrote:

quoted

On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai [off-list ref] wrote:

quoted

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Is this called before or after the new proper framebuffer driver kicks in?
If before, it may cause glitches.

It is called by the new proper framebuffer driver's probe method,
so it can make sure that it has already claimed / enabled the
clocks/regulators before it calls remove_conlicting_framebuffers,
avoiding the glitch.

OK, thx!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On 07/09/16 12:09, Chen-Yu Tsai wrote:

simplefb gets unregister when a proper framebuffer driver comes in and
kicks it out. However the claimed clocks and regulators stay enabled
as they are only released in the platform device remove function, which
in theory would never get called.

Move the clock/regulator cleanup into the framebuffer destroy callback,
which gets called as part of the framebuffer unregister process.

Note this introduces asymmetry in how the resources are claimed and
released.

Signed-off-by: Chen-Yu Tsai <redacted>
---
 drivers/video/fbdev/simplefb.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Thanks, queued for 4.9.

 Tomi