lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hobxkzs02.wl%tiwai@suse.de>
Date:	Thu, 13 Oct 2011 20:05:49 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Keith Packard <keithp@...thp.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915/panel: Alwyas record the backlight level again (but cleverly)

At Thu, 13 Oct 2011 09:40:29 -0700,
Keith Packard wrote:
> 
> On Thu, 13 Oct 2011 10:57:35 +0200, Takashi Iwai <tiwai@...e.de> wrote:
> 
> > This patch fixes the bug by recording the backlight level always
> > when changed but only when dev_priv->backlight_enabled is set.
> > In this way, the bogus value for disabling backlight can be skipped.
> 
> I think this is better than what we have, but I'm not sure it's quite
> what we want -- the backlight level will only be remembered when it is
> enabled, so requested changes that happen while the backlight is off
> will have no effect. And, requested changes while the panel is disabled
> will still go through to the hardware, which can cause problems with
> panel power sequencing.
> 
> I think intel_panel_set_backlight should always record the level passed
> in, but that intel_panel_disable_backlight and
> intel_panel_enable_backlight should use a lower-level function, shared
> with intel_panel_set_backlight that doesn't record the value:
> 
> intel_panel_actually_set_backlight(dev, level) {
>         <internals of current intel_panel_set_backlight>
> }
> 
> intel_panel_set_backlight(dev, level) {
>         dev_priv->backlight_level = level;
>         if (dev_priv->backlight_enabled)
>                 intel_panel_actually_set_backlight(dev, level);
> }
> 
> intel_panel_enable_backlight(dev) {
>         dev_priv->backlight_enabled = true;
>         intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
> }
> 
> intel_panel_disable_backlight(dev) {
>         dev_priv->backlight_enabled = false;
>         intel_panel_actually_set_backlight(dev, 0);
> }

Yes, this looks more understandable, indeed.
Would you patch it by yourself or should I refresh the patch?
In either way, I'll test tomorrow, as I'm already at home without a
test machine.


thanks,

Takashi
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ