[PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n

[PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n

[Ezequiel Garcia]

There's no point in having support for framebuffer notifications
is CONFIG_FB is disabled. This commit adds the necessary stubs
for code to link properly when CONFIG_FB=n and moves fb-notify.o
to be built only when CONFIG_FB=y.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
---
 drivers/video/fbdev/Kconfig       |  4 ++++
 drivers/video/fbdev/core/Makefile |  2 +-
 include/linux/fb.h                | 18 ++++++++++++++++++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e6d16d65e4e6..6d881260856e 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -5,6 +5,7 @@
 menuconfig FB
 	tristate "Support for frame buffer devices"
 	select FB_CMDLINE
+	select FB_NOTIFY
 	---help---
 	  The frame buffer device provides an abstraction for the graphics
 	  hardware. It represents the frame buffer of some video hardware and
@@ -56,6 +57,9 @@ config FIRMWARE_EDID
 config FB_CMDLINE
 	bool
 
+config FB_NOTIFY
+	bool
+
 config FB_DDC
        tristate
        depends on FB
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 23d86a8b7d7b..9e3ddf225393 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,5 +1,5 @@
-obj-y                             += fb_notify.o
 obj-$(CONFIG_FB_CMDLINE)          += fb_cmdline.o
+obj-$(CONFIG_FB_NOTIFY)           += fb_notify.o
 obj-$(CONFIG_FB)                  += fb.o
 fb-y                              := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
                                      modedb.o fbcvt.o
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3d003805aac3..55433f86f0a3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -175,9 +175,27 @@ struct fb_blit_caps {
 	u32 flags;
 };
 
+#ifdef CONFIG_FB_NOTIFY
 extern int fb_register_client(struct notifier_block *nb);
 extern int fb_unregister_client(struct notifier_block *nb);
 extern int fb_notifier_call_chain(unsigned long val, void *v);
+#else
+static inline int fb_register_client(struct notifier_block *nb)
+{
+	return 0;
+};
+
+static inline int fb_unregister_client(struct notifier_block *nb)
+{
+	return 0;
+};
+
+static inline int fb_notifier_call_chain(unsigned long val, void *v)
+{
+	return 0;
+};
+#endif
+
 /*
  * Pixmap structure definition
  *
-- 
2.6.2

Re: [PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]


On 25/11/15 05:11, Ezequiel Garcia wrote:
> There's no point in having support for framebuffer notifications
> is CONFIG_FB is disabled. This commit adds the necessary stubs
> for code to link properly when CONFIG_FB=n and moves fb-notify.o
> to be built only when CONFIG_FB=y.

Why do you add CONFIG_FB_NOTIFY, isn't plain CONFIG_FB enough? Oh,
right, to have it built-in even if FB is a module.

But this makes me wonder, why is fb_notify in obj-y list currently.
Nobody just bothered to make it build only when needed, or has there
been some use for it earlier... The commit descriptions in git history
suggest the former.

Actually, looks like fb_notify.c was originally made to solve the same
problem as your patch solves, but by separating the notify code from the
main fbdev code. So I still wonder, was there some reason to keep the
notification code built instead of having stub functions.

Any thoughts?

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n

[Ezequiel Garcia]

Tomi,

Thanks for looking at this patch.

On 7 December 2015 at 13:01, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> On 25/11/15 05:11, Ezequiel Garcia wrote:
>> There's no point in having support for framebuffer notifications
>> is CONFIG_FB is disabled. This commit adds the necessary stubs
>> for code to link properly when CONFIG_FB=n and moves fb-notify.o
>> to be built only when CONFIG_FB=y.
>
> Why do you add CONFIG_FB_NOTIFY, isn't plain CONFIG_FB enough? Oh,
> right, to have it built-in even if FB is a module.
>

Right.

> But this makes me wonder, why is fb_notify in obj-y list currently.
> Nobody just bothered to make it build only when needed, or has there
> been some use for it earlier... The commit descriptions in git history
> suggest the former.
>

Here's the patch that created fb_notify.c and put it in obj-y.

    [PATCH] fbdev: statically link the framebuffer notification functions

    The backlight and lcd subsystems can be notified by the framebuffer layer
    of blanking events.  However, these subsystems, as a whole, can function
    independently from the framebuffer layer.  But in order to enable to the
    lcd and backlight subsystems, the framebuffer has to be compiled also,
    effectively sucking in a huge amount of unneeded code.

    To prevent dependency problems, separate out the framebuffer notification
    mechanism from the framebuffer layer and permanently link it to the kernel.

    Signed-off-by: Antonino Daplas <adaplas@pol.net>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>


> Actually, looks like fb_notify.c was originally made to solve the same
> problem as your patch solves, but by separating the notify code from the
> main fbdev code. So I still wonder, was there some reason to keep the
> notification code built instead of having stub functions.
>
> Any thoughts?
>

I can't see any valid reason to keep the code around, since there's no
way it can be used.
Let's see if Ccing Antonino and Andrew -as per that commit- helps.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH RESEND] fbdev: Make fb-notify a no-op if CONFIG_FB=n

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]


On 07/12/15 18:14, Ezequiel Garcia wrote:

>> Actually, looks like fb_notify.c was originally made to solve the same
>> problem as your patch solves, but by separating the notify code from the
>> main fbdev code. So I still wonder, was there some reason to keep the
>> notification code built instead of having stub functions.
>>
>> Any thoughts?
>>
> 
> I can't see any valid reason to keep the code around, since there's no
> way it can be used.
> Let's see if Ccing Antonino and Andrew -as per that commit- helps.

Ok. This looks fine to me, so I'll queue it for 4.5.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]