About boot time Tux logo with -EPROBE_DEFER

Subsystems: framebuffer layer, the rest

3 messages, 2 authors, 2017-03-08 · open the first message on its own page

About boot time Tux logo with -EPROBE_DEFER

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: 2017-03-07 01:25:39

Hi

I want to ask you about boot time Tux logo.

For some reasons, current our video driver returns -EPROBE_DEFER when
probe timing, but logo init function doesn't care it.
Thus, our kernel can't have logo when boot time.

I think this is not only our issue, but general issue ?

Thus, I think logo init function should care about -EPROBE_DEFER
or something. In our quick hack, this issue was solved by below patch,
but I don't know this is OK.

So, how to solve this issue ? do you have nice idea ?
or can maintainer accept below patch ?

-------------------
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index b6bc4a0bda2a..4d50bfd13e7c 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -34,7 +34,7 @@ static int __init fb_logo_late_init(void)
     return 0;
 }

-late_initcall(fb_logo_late_init);
+late_initcall_sync(fb_logo_late_init);

 /* logo's are marked __initdata. Use __ref to tell
  * modpost that it is intended that this function uses data
-------------------
Best regards
---
Kuninori Morimoto

Re: About boot time Tux logo with -EPROBE_DEFER

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2017-03-08 09:35:46

Hi Morimoto-san,

On Tue, Mar 7, 2017 at 2:24 AM, Kuninori Morimoto
[off-list ref] wrote:
I want to ask you about boot time Tux logo.

For some reasons, current our video driver returns -EPROBE_DEFER when
probe timing, but logo init function doesn't care it.
Thus, our kernel can't have logo when boot time.

I think this is not only our issue, but general issue ?

Thus, I think logo init function should care about -EPROBE_DEFER
or something. In our quick hack, this issue was solved by below patch,
but I don't know this is OK.
The important part is that fb_logo_late_init() is called
  - as late as possible, to allow to draw the logo as late as possible,
  - but before free_initmem(), to avoid using freed memory.

kernel_init()
{
    kernel_init_freeable()
    {
        ...
        do_basic_setup()
        {
            ...
            do_initcalls();
            ...
        }
        ...
    }
    /* need to finish all async __init code before freeing the memory */
    async_synchronize_full();
    free_initmem();
    ...
}

According to the call graph above, the latest initcall() should be OK.
quoted hunk
So, how to solve this issue ? do you have nice idea ?
or can maintainer accept below patch ?

-------------------
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index b6bc4a0bda2a..4d50bfd13e7c 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -34,7 +34,7 @@ static int __init fb_logo_late_init(void)
     return 0;
 }

-late_initcall(fb_logo_late_init);
+late_initcall_sync(fb_logo_late_init);

 /* logo's are marked __initdata. Use __ref to tell
  * modpost that it is intended that this function uses data
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

Re: About boot time Tux logo with -EPROBE_DEFER

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: 2017-03-08 11:19:00

Hi Geert

Thanks.
I asked this because some maintainer doesn't accept the patch which
exchanges xxx_initcall.
But, I will try it with your Reviewed-by.
quoted
I want to ask you about boot time Tux logo.

For some reasons, current our video driver returns -EPROBE_DEFER when
probe timing, but logo init function doesn't care it.
Thus, our kernel can't have logo when boot time.

I think this is not only our issue, but general issue ?

Thus, I think logo init function should care about -EPROBE_DEFER
or something. In our quick hack, this issue was solved by below patch,
but I don't know this is OK.
The important part is that fb_logo_late_init() is called
  - as late as possible, to allow to draw the logo as late as possible,
  - but before free_initmem(), to avoid using freed memory.

kernel_init()
{
    kernel_init_freeable()
    {
        ...
        do_basic_setup()
        {
            ...
            do_initcalls();
            ...
        }
        ...
    }
    /* need to finish all async __init code before freeing the memory */
    async_synchronize_full();
    free_initmem();
    ...
}

According to the call graph above, the latest initcall() should be OK.
quoted
So, how to solve this issue ? do you have nice idea ?
or can maintainer accept below patch ?

-------------------
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index b6bc4a0bda2a..4d50bfd13e7c 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -34,7 +34,7 @@ static int __init fb_logo_late_init(void)
     return 0;
 }

-late_initcall(fb_logo_late_init);
+late_initcall_sync(fb_logo_late_init);

 /* logo's are marked __initdata. Use __ref to tell
  * modpost that it is intended that this function uses data
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help