[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20120522135902.90253d07.akpm@linux-foundation.org>
Date: Tue, 22 May 2012 13:59:02 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Corentin Chary <corentin.chary@...il.com>
Cc: Richard Purdie <rpurdie@...ys.net>,
Keith Packard <keithp@...thp.com>,
David Airlie <airlied@...ux.ie>,
Matthew Garrett <mjg@...hat.com>,
Florian Tobias Schandinat <FlorianSchandinat@....de>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Dave Airlie <airlied@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
Lars-Peter Clausen <lars@...afoo.de>,
Axel Lin <axel.lin@...il.com>, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-fbdev@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
linux-omap@...r.kernel.org
Subject: Re: [PATCH] backlight: initialize struct backlight_properties
properly
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary <corentin.chary@...il.com> wrote:
> In all these files, the .power field was never correctly initialized.
>
> ...
>
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
> else
> return -ENODEV;
>
> + memset(&props, 0, sizeof(props));
This code is all still quite fragile. What happens if we add a new
field to backlight_properties? We need to go edit a zillion drivers?
There are two ways of fixing this:
a) write and use
void backlight_properties_init(struct backlight_properties *props,
int type, int max_brightness, etc);
or
b) edit all sites to do
struct backlight_properties bl_props = {
.type = BACKLIGHT_RAW,
.max_brighness = intel_panel_get_max_backlight(dev),
.power = FB_BLANK_UNBLANK,
};
they're largely equivalent - the struct will be zeroed out and
then certain fields will be initialised. a) is a bit better because
some future field may not want the all-zeroes pattern (eg, a spinlock).
But they're both better than what we have now!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists