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]

Message-ID: <20140213100814.GM14909@nuc-i3427.alporthouse.com>
Date:	Thu, 13 Feb 2014 10:08:14 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Aaron Lu <aaron.lu@...el.com>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Oleksij Rempel <linux@...pel-privat.de>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"linux-kernel@...r.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 Thu, Feb 13, 2014 at 05:10:25PM +0800, Aaron Lu wrote:
> On 02/12/2014 06:31 PM, Chris Wilson 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.
> 
> Thanks for the suggestion. As a first step, does the following un-tested
> patch look OK?

Yes. Maybe worth putting together the similar routines for blind
setting the didl and the cadl, or at least for computing the value from
the connector. For instance, the didl logic disagrees with the value of
index - is that relevant? I have a suspicion that the CADL entry should
match the DIDL entry for the connector, but that is not actually
mentioned in the opregion spec afaict.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
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/