[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1349305214-3241-1-git-send-email-yinghai@kernel.org>
Date: Wed, 3 Oct 2012 16:00:10 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Len Brown <lenb@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>
Subject: [PATCH 0/4] ACPI: kill acpi_pci_root_start
Now acpi_pci_root_driver has two ops: .add and .start, aka acpi_pci_root_add
and acpi_pci_root_start.
That is for hotplug handling: .add need to return early to make sure all
acpi device could be created and added early. So .start could device_add
pci device that are found in acpi_pci_root_add/pci_acpi_scan_root().
That is holding pci devics to be out of devices for while.
We could use bus notifier to handle hotplug case.
CONFIG_HOTPLUG is enabled always now.
Need to add drivers_autoprobe bit in acpi_device to hold attaching drivers
for acpi_devices, so could make sure all acpi_devices get created at first.
Then acpi_bus_attach() that is called from acpi_bus_add will attach driver
for all acpi_devices that are just created.
That make the logic more simple: hotplug path handling just like booting path
that drivers are attached after all acpi device get created.
At last we could remove all acpi_bus_start workaround.
Thanks
Yinghai
Yinghai Lu (4):
ACPI: add drivers_autoprobe in struct acpi_device
ACPI: use device drivers_autoprobe to delay loading acpi drivers
PCI, ACPI: Remove not used acpi_pci_root_start()
ACPI: remove acpi_op_start workaround
drivers/acpi/pci_root.c | 27 +++------
drivers/acpi/scan.c | 145 ++++++++++++++++++++++-------------------------
include/acpi/acpi_bus.h | 9 +---
3 files changed, 77 insertions(+), 104 deletions(-)
--
1.7.7
--
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/
Powered by blists - more mailing lists