From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Thomas Renninger <trenn@suse.de>
Cc: linux-acpi <linux-acpi@vger.kernel.org>,
Len Brown <lenb@kernel.org>, Andrew Morton <akpm@osdl.org>,
"Li, Shaohua" <shaohua.li@intel.com>
Subject: [PATCH] Ignore ACPI video devices that aren't present in hardware
Date: Thu, 17 Jan 2008 03:39:36 +0000 [thread overview]
Message-ID: <20080117033936.GB26703@srcf.ucam.org> (raw)
In-Reply-To: <20080117031154.GA26703@srcf.ucam.org>
Vendors often ship machines with a choice of integrated or discrete
graphics, and use the same DSDT for both. As a result, the ACPI video
module will locate devices that may not exist on this specific platform.
Attempt to determine whether the device exists or not, and abort the
device creation if it doesn't.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
---
I'm still not convinced that this can be done reliably, especially if
anyone ever produces ACPI devices that aren't PCI-based. On the other
hand, I believe that this will work correctly (ie, discard devices for
integrated hardware if discrete hardware is present, and vice-versa) in
all existing cases. The most irritating feature is that there's no good
way to determine if an _ADR method refers to a PCI device or not - 0x00
could mean the PCI host bridge or the first video device hanging off an
AGP bridge. So far all the implementations I've seen use low numbers for
devices that aren't directly on the root PCI bus, so I've just assumed
that they'll always be less than 0x10000. If someone puts a graphics
core in their host bridge, this will break. But that would seem a mad
thing to do, so I'm going to pretend it's impossible.
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 12b2adb..1906eff 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1266,8 +1266,37 @@ acpi_video_bus_write_DOS(struct file *file,
static int acpi_video_bus_add_fs(struct acpi_device *device)
{
+ long device_id;
+ int status;
struct proc_dir_entry *entry = NULL;
struct acpi_video_bus *video;
+ struct device *dev;
+
+ status =
+ acpi_evaluate_integer(device->handle, "_ADR", NULL, &device_id);
+
+ if (!ACPI_SUCCESS(status))
+ return -ENODEV;
+
+ /* We need to attempt to determine whether the _ADR refers to a
+ PCI device or not. There's no terribly good way to do this,
+ so the best we can hope for is to assume that there'll never
+ be a video device in the host bridge */
+ if (device_id >= 0x10000) {
+ /* It looks like a PCI device. Does it exist? */
+ dev = acpi_get_physical_device(device->handle);
+ } else {
+ /* It doesn't look like a PCI device. Does its parent
+ exist? */
+ acpi_handle phandle;
+ if (acpi_get_parent(device->handle, &phandle))
+ return -ENODEV;
+ dev = acpi_get_physical_device(phandle);
+ }
+ if (!dev)
+ return -ENODEV;
+ put_device(dev);
+
video = acpi_driver_data(device);
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2008-01-17 3:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-07 12:55 [PATCH] Recent Lenovo ThinkPads define a dummy grahpics device, find it and ignore it Thomas Renninger
2007-12-07 15:27 ` Thomas Renninger
2007-12-07 22:50 ` Matthew Garrett
2007-12-10 12:48 ` Thomas Renninger
2008-01-17 3:11 ` Matthew Garrett
2008-01-17 3:39 ` Matthew Garrett [this message]
2008-01-17 10:57 ` [PATCH] Ignore ACPI video devices that aren't present in hardware Thomas Renninger
2008-01-17 12:02 ` Matthew Garrett
2008-01-22 8:52 ` Zhang Rui
2008-01-22 12:11 ` Julian Sikorski
2008-01-24 22:21 ` Len Brown
2008-01-27 2:09 ` Matthew Garrett
2008-02-02 7:12 ` Len Brown
2008-02-03 0:03 ` Matthew Garrett
2008-02-07 1:44 ` Matthew Garrett
2008-02-07 7:03 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080117033936.GB26703@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=akpm@osdl.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).