[PATCH] ACPI: update acpi_get_pci_dev() comments

[Alex Chiang]

Recent commit 412af978 (ACPI: video: prevent NULL deref in
acpi_get_pci_dev()) was added to prevent a boot oops.

Update the implementation with some notes and analysis as to why
the fix is correct.

Cc: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
Cc: Troy Moure <twmoure@xxxxxxxxx>
Signed-off-by: Alex Chiang <achiang@xxxxxx>
---
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 55b5b90..570f32e 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -344,6 +344,16 @@ struct acpi_handle_node {
  * function returns a pointer to its data structure.  The caller must
  * decrement the reference count by calling pci_dev_put().
  * If no device is found, %NULL is returned.
+ *
+ * XXX: You may be surprised at the results if you call this interface
+ * with a handle to a PCI root bridge and expect to get a pci_dev back.
+ * The PCI specification does not require a PCI root bridge to present
+ * configuration space, and thus may not have a valid associated pci_dev.
+ *
+ * [nb, all P2P bridges _are_ required to present configuration space]
+ *
+ * A PCI root bridge that presents config space is referred to as
+ * "materialized"; its converse is "non-materialized".
  */
 struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
 {
@@ -385,6 +395,11 @@ struct pci_dev *acpi_get_pci_dev(acpi_handle handle)
 	 * Now, walk back down the PCI device tree until we return to our
 	 * original handle. Assumes that everything between the PCI root
 	 * bridge and the device we're looking for must be a P2P bridge.
+	 *
+	 * Note! It's possible for ACPI to describe a non-existent PCI device
+	 * due to either hotplug or a namespace shared across different
+	 * platforms with just enable or present bits to mask them out from
+	 * the initial PCI scan. So take care to check for a NULL pdev.
 	 */
 	list_for_each_entry(node, &device_list, node) {
 		acpi_handle hnd = node->handle;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/