linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).