> Great question! I have sent out patches for a couple of actual bugs that
> came from this warning in the past few months.
>
> I still have a couple of patches that I have not sent out so far,
> I think they are all false-positives, and I have not found a good
> workaround for most of them other than disabling the warning locally.
>
> Once we get the patches below (or some other workaround) into the
> kernel, we should definitely enable the warning by default.
So it looks like some are from initialising a range of values with
a default value:
[0 ... SH_ETH_MAX_REGISTER_OFFSET - 1] = SH_ETH_OFFSET_INVALID
and then some entries specific values. Maybe the compiler can help out
here? A different warning in this case? And have that at W=1? Could
you ask the gcc folks about this?
Others causes seem like
226 #define DRM_FB_HELPER_DEFAULT_OPS \
227 .fb_check_var = drm_fb_helper_check_var, \
228 .fb_set_par = drm_fb_helper_set_par, \
229 .fb_setcmap = drm_fb_helper_setcmap, \
230 .fb_blank = drm_fb_helper_blank, \
231 .fb_pan_display = drm_fb_helper_pan_display
static struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
...
.fb_pan_display = omap_fbdev_pan_display,
There are at least three drivers which need to replace the
default fb_pan_display. So maybe a different macro?
Andrew
