linux-kernel - Re: [PATCH] drm/i915: Revive combination mode for backlight control

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]

Date:	Thu, 10 Mar 2011 11:36:51 -0800
From:	Keith Packard <keithp@...thp.com>
To:	Takashi Iwai <tiwai@...e.de>, Indan Zupancic <indan@....nu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Alex Riesen <raa.lkml@...il.com>,
	Tino Keitel <tino.keitel@...ei.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	stable@...nel.org
Subject: Re: [PATCH] drm/i915: Revive combination mode for backlight control

On Thu, 10 Mar 2011 14:02:12 +0100, Takashi Iwai <tiwai@...e.de> wrote:
> This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
> 
>     drm/i915: Do not handle backlight combination mode specially
> 
> since this commit introduced other regressions due to untouched LBPC
> register, e.g. the backlight dimmed after resume.
> 
> In addition to the revert, this patch includes a fix for the original
> issue (weird backlight levels) by removing the wrong bit shift for
> computing the current backlight level.
> Also, including typo fixes (lpbc -> lbpc).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
> Acked-by: Indan Zupancic <indan@....nu>
> Cc: <stable@...nel.org>
> Signed-off-by: Takashi Iwai <tiwai@...e.de>

This looks good, and ensures that LBPC ranges from 0 - 0xfe as required.

The one thing we want is a comment that explains

> +			val &= ~1;

The reason for this is that some ancient platforms wire this bit to
be "go to max backlight", or at least that's why this was in the 2D
driver from which this code was derived.

Reviewed-by: Keith Packard <keithp@...thp.com>
Reviewed-by: Jesse Barnes <jbarnes@...tuousgeek.org>

-- 
keith.packard@...el.com

Content of type "application/pgp-signature" skipped