Re: [PATCH] backlight: initialize struct backlight_properties properly |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH] backlight: initialize struct backlight_properties properly
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 22 May 2012 13:59:02 -0700
- Cc: Richard Purdie <rpurdie@xxxxxxxxx>, Keith Packard <keithp@xxxxxxxxxx>, David Airlie <airlied@xxxxxxxx>, Matthew Garrett <mjg@xxxxxxxxxx>, Florian Tobias Schandinat <FlorianSchandinat@xxxxxx>, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, Tomi Valkeinen <tomi.valkeinen@xxxxxx>, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>, Dave Airlie <airlied@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Lars-Peter Clausen <lars@xxxxxxxxxx>, Axel Lin <axel.lin@xxxxxxxxx>, dri-devel@xxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, platform-driver-x86@xxxxxxxxxxxxxxx, linux-fbdev@xxxxxxxxxxxxxxx, patches@xxxxxxxxxxxxxxxxxxxxxxxxxxx, linux-omap@xxxxxxxxxxxxxxx
- In-reply-to: <1337585085-4891-1-git-send-email-corentin.chary@gmail.com>
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary <corentin.chary@xxxxxxxxx> 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-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]