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: <20140304144504.GE17001@phenom.ffwll.local>
Date:	Tue, 4 Mar 2014 15:45:04 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Aaron Lu <aaron.lu@...el.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	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 Wed, Feb 19, 2014 at 04:59:06PM +0800, Aaron Lu wrote:
> On 02/19/2014 03:33 PM, Matthew Garrett wrote:
> > On Wed, Feb 19, 2014 at 03:31:29PM +0800, Aaron Lu wrote:
> > 
> >> DID2 is in system memory region and has some assigned value like 0x400
> >> when we read it. For this case it is easy since there is only one output
> >> device that is of type LVDS so we can match it to connector of type eDP
> >> or LVDS, suppose there is only one such connector. But for output
> >> devices' whose _ADR has the value of 0x301, 0x302, etc. I have no idea
> >> how to match them up to the connectors of that type as we can't be sure
> >> the probe order we have used in i915 driver is the same as BIOS'.
> > 
> > Non-standard _ADR values are assigend by the GPU vendor, so Intel should 
> > be able to provide you with the correct interpretations.
> 
> It doesn't seem the _ADR value has to be the format defined by _DOD, as
> the example of the ACPI spec gives:
> Method (_ADR, 0) {
>     return(0x0100)
> }
> So that is not the problem here.
> 
> The problem is, we don't have any way of matching an ACPI output device
> node to a drm connector of the same type when there are more than 1 of
> those with the same type, i.e. we don't know how the index value are
> assigned by BIOS.

I've thought the OpRegion spec has some additional fields in there
indicating the port number, which we could match up at least on modern
platforms (where there's only ever port A-E). But that's very hazy
recollection from a really old OpRegion spec, i.e. I have no bloody clue
at all ;-)

If I misremember this then we need to start on a begging tour again and
ask the windows guys how this is all supposed to work ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/