linux-kernel - Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices

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:	Wed, 12 Feb 2014 12:52:13 +0200
From:	Jani Nikula <jani.nikula@...ux.intel.com>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Aaron Lu <aaron.lu@...el.com>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Oleksij Rempel <linux@...pel-privat.de>,
	"intel-gfx\@lists.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices

On Wed, 12 Feb 2014, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> On Wed, Feb 12, 2014 at 11:05:40AM +0800, Aaron Lu wrote:
>> The ACPI table on ASUS UX302LA has more than 8 output devices under the
>> graphics controller device node. The problem is, the real active output
>> device, the LCD panel, is listed the last. The result is, the LCD's
>> device id doesn't get recorded in the active device list CADL array and
>> when the _DCS control method for the LCD device is executed, it returns
>> 0x1d, meaning it is not active. This affects the hotkey delivery ASL
>> code that will not deliver a notification if the output device is not
>> active on backlight hotkey press.
>> 
>> I don't see a clean way to solve this problem since the operation region
>> spec doesn't allow more than 8 output devices so we have no way of
>> storing all these output devices. The fact that output devices that have
>> _BCM control method usually means they have a higher possibility of being
>> used than those who don't made me choose a simple way to work around
>> the buggy firmware by replacing the last entry in CADL array with the one
>> that has _BCM control method. There is no specific reason why the last
>> entry is picked instead of others.
>
> Another possibility is that the connector list is in rough priority
> order so might be useful for sorting the CADL array.
>
> Since the CADL should only be a list of currently active devices, we
> could just bite the bullet and repopulate it correctly after every
> setcrtc.

Agreed. Per spec,

DIDL: Writes - Graphics driver writes to this field once during its
initialization after determining platform supported connectors.

CPDL: Writes - Graphics driver writes to this field on every monitor
detection process.

CADL: Writes - Graphics driver writes to this field on every mode set
process and during boot.

And for all of the above: Writes - System BIOS POST or ASL code should
not write to these fields.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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/