Hi Laurent,

On Tue, Dec 20, 2011 at 16:42, Laurent Pinchart
[off-list ref] wrote:

On Tuesday 20 December 2011 16:24:30 Geert Uytterhoeven wrote:

quoted

On Tue, Dec 20, 2011 at 16:19, Laurent Pinchart wrote:

quoted

On Tuesday 20 December 2011 14:48:33 Geert Uytterhoeven wrote:

quoted

On Tue, Dec 20, 2011 at 11:37, Laurent Pinchart wrote:

quoted

On Tuesday 20 December 2011 06:32:14 Stephen Rothwell wrote:

quoted

After merging the fbdev tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

drivers/video/matrox/matroxfb_base.c:150:2: warning: braces around
scalar initializer [enabled by default]
drivers/video/matrox/matroxfb_base.c:150:2: warning: (near
initialization for 'vesafb_defined.colorspace') [enabled by default]
drivers/video/matrox/matroxfb_base.c:150:2: warning: excess elements
in scalar initializer [enabled by default]
drivers/video/matrox/matroxfb_base.c:150:2: warning: (near
initialization for 'vesafb_defined.colorspace') [enabled by default]
drivers/video/matrox/matroxfb_crtc2.c:596:3: warning: braces around
scalar initializer [enabled by default]
drivers/video/matrox/matroxfb_crtc2.c:596:3: warning: (near
initialization for 'matroxfb_dh_defined.colorspace') [enabled by
default]
drivers/video/matrox/matroxfb_crtc2.c:596:3: warning: excess elements
in scalar initializer [enabled by default]
drivers/video/matrox/matroxfb_crtc2.c:596:3: warning: (near
initialization for 'matroxfb_dh_defined.colorspace') [enabled by
default]

Introduced by commit fb21c2f42879 ("fbdev: Add FOURCC-based format
configuration API").

The following patch should fix the issue. Florian, are you fine with
it, or would you rather modify the initializers to be name-based ?

From 078987fc14dba806fc1bc628e3e5c371db3cf1b8 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Tue, 20 Dec 2011 11:30:53 +0100
Subject: [PATCH] fbdev: matroxfb: Fix compilation after
fb_var_screeninfo change

Commit fb21c2f42879 ("fbdev: Add FOURCC-based format configuration
API") modified the layout of the fb_var_screeninfo structure. Update
the static initializers in the matroxfb driver accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/matrox/matroxfb_base.c  |    2 +-
 drivers/video/matrox/matroxfb_crtc2.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/matrox/matroxfb_base.c

b/drivers/video/matrox/matroxfb_base.c index 44bf8d4..f98aad5 100644

--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c

@@ -147,7 +147,7 @@ static struct fb_var_screeninfo vesafb_defined = {

       39721L,48L,16L,33L,10L,
       96L,2L,~0,      /* No sync info */
       FB_VMODE_NONINTERLACED,
-       0, {0,0,0,0,0}
+       0, 0, {0,0,0,0}

All these zeroes should not be specified, the compiler will do the
right thing for
static variables anyway.

Else they have to be updated manually everytime one of the reserved
fields is consumed for a new feature.

I agree. Should I just remove them, or switch the structures to named
initializers while I'm at it ?

I would just remove them. What do they buy you?

Even with named initializers

    .reserved = { 0, 0, 0, 0 }

will break once we consume one more reserved field, unless you write

    .reserved = { 0, }

to let the compiler handle it, but then you could just not specify the
field at all.

Sure. In both cases I would remove them, but I was wondering if I should
switch the whole structure to named initializers in addition to removing them.
I don't know if the common practice to solve issues in the -next tree is to
apply patches that are as little intrusive as possible, or if bigger patches
are allowed.

I'd fix the build error first.
The conversion to named initializers can be separate cleanup patch.

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