lwn.git/drivers/acpi/scan.c, branch v3.10.54

ACPI / hotplug: Fix conflicted PCI bridge notify handlers

2013-12-04T18:57:04+00:00

commit ca499fc87ed945094d952da0eb7eea7dbeb1feec upstream. The PCI host bridge scan handler installs its own notify handler, handle_hotplug_event_root(), by itself. Nevertheless, the ACPI hotplug framework also installs the common notify handler, acpi_hotplug_notify_cb(), for PCI root bridges. This causes acpi_hotplug_notify_cb() to call _OST method with unsupported error as hotplug.enabled is not set. To address this issue, introduce hotplug.ignore flag, which indicates that the scan handler installs its own notify handler by itself. The ACPI hotplug framework does not install the common notify handler when this flag is set. Signed-off-by: Toshi Kani [rjw: Changed the name of the new flag] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / hotplug: Do not execute "insert in progress" _OST

2013-11-29T19:11:43+00:00

commit 176a88d79d6b5aebabaff16734e8b3107efcaaad upstream. According to the ACPI spec (5.0, Section 6.3.5), the "Device insertion in progress (pending)" (0x80) _OST status code is reserved for the "Insertion Processing" (0x200) source event which is "a result of an OSPM action". Specifically, it is not a notification, so that status code should not be used during notification processing, which unfortunately is done by acpi_scan_bus_device_check(). For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST status evaluation from there (it was a mistake to put it in there in the first place). Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / scan: Do not try to attach scan handlers to devices having them

2013-08-04T08:51:01+00:00

commit 3a391a39593b48341f0908511590a6c0e55cc069 upstream. In acpi_bus_device_attach(), if there is an ACPI device object for the given handle and that device object has a scan handler attached to it already, there's nothing more to do for that handle. Moreover, if acpi_scan_attach_handler() is called then, it may execute the .attach() callback of the ACPI scan handler already attached to the device object and that may lead to interesting breakage. For this reason, make acpi_bus_device_attach() return success immediately when the handle's device object has a scan handler attached to it. Reported-by: Toshi Kani Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Signed-off-by: Greg Kroah-Hartman

ACPI / scan: Always call acpi_bus_scan() for bus check notifications

2013-08-04T08:50:58+00:00

commit 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f upstream. An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the entire namespace starting from the given handle even if the device represented by that handle is present (other devices below it may just have appeared). For this reason, modify acpi_scan_bus_device_check() to always run acpi_bus_scan() if the notification being handled is of type ACPI_NOTIFY_BUS_CHECK. Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Signed-off-by: Greg Kroah-Hartman

ACPI: Add CMOS RTC Operation Region handler support

2013-07-22T01:21:28+00:00

commit 2fa97feb4406c546b52e35b6b6c50cb8f63425d2 upstream. On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and the EC's _REG methord accesses that region. Thus an appropriate address space handler must be registered for that region before the EC driver is loaded. Introduce a mechanism for adding CMOS RTC address space handlers. Register an ACPI scan handler for CMOS RTC devices such that, when a device of that kind is detected during an ACPI namespace scan, a common CMOS RTC operation region address space handler will be installed for it. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / dock: Initialize ACPI dock subsystem upfront

2013-06-22T22:59:55+00:00

Commit 3b63aaa70e1 (PCI: acpiphp: Do not use ACPI PCI subdriver mechanism) introduced an ACPI dock support regression, because it changed the relative initialization order of the ACPI dock subsystem and the ACPI-based PCI hotplug (acpiphp). Namely, the ACPI dock subsystem has to be initialized before acpiphp_enumerate_slots() is first run, which after commit 3b63aaa70e1 happens during the initial enumeration of the PCI hierarchy triggered by the initial ACPI namespace scan in acpi_scan_init(). For this reason, the dock subsystem has to be initialized before the initial ACPI namespace scan in acpi_scan_init(). To make that happen, modify the ACPI dock subsystem to be non-modular and add the invocation of its initialization routine, acpi_dock_init(), to acpi_scan_init() directly before the initial namespace scan. [rjw: Changelog, removal of dock_exit().] References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov Tested-by: Illya Klymov Signed-off-by: Jiang Liu Acked-by: Yinghai Lu Cc: 3.9+ Signed-off-by: Rafael J. Wysocki

ACPI / video: Do not bind to device objects with a scan handler

2013-06-10T11:00:29+00:00

With the introduction of ACPI scan handlers, ACPI device objects with an ACPI scan handler attached to them must not be bound to by ACPI drivers any more. Unfortunately, however, the ACPI video driver attempts to do just that if there is a _ROM ACPI control method defined under a device object with an ACPI scan handler. Prevent that from happening by making the video driver's "add" routine check if the device object already has an ACPI scan handler attached to it and return an error code in that case. That is not sufficient, though, because acpi_bus_driver_init() would then clear the device object's driver_data that may be set by its scan handler, so for the fix to work acpi_bus_driver_init() has to be modified to leave driver_data as is on errors. References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Bisected-and-tested-by: Dmitry S. Demin Reported-and-tested-by: Jason Cassell Tracked-down-by: Aaron Lu Cc: 3.9+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Aaron Lu

Revert "ACPI / scan: do not match drivers against objects having scan handlers"

2013-06-08T01:33:12+00:00

Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects having scan handlers") introduced a boot regression on Tony's ia64 HP rx2600. Tony says: "It panics with the message: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel [...] my problem comes from arch/ia64/hp/common/sba_iommu.c where the code in sba_init() says: acpi_bus_register_driver(&acpi_sba_ioc_driver); if (!ioc_list) { but because of this change we never managed to call ioc_init() so ioc_list doesn't get set up, and we die." Revert it to avoid this breakage and we'll fix the problem it attempted to address later. Reported-by: Tony Luck Cc: 3.9+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds

ACPI / scan: do not match drivers against objects having scan handlers

2013-06-05T11:11:47+00:00

With the introduction of ACPI scan handlers, an ACPI device object with an ACPI scan handler attached to it must not be bound to an ACPI driver any more. Therefore it doesn't make sense to match those ACPI device objects against a newly registered ACPI driver in acpi_bus_match(), so make that function return 0 if the device object passed to it has an ACPI scan handler attached. This also addresses a regression related to a broken ACPI table in the BIOS, where it has defined a _ROM method under the PCI root bridge object. This causes the video module to treat that object as a display controller device (since only display devices are supposed to have a _ROM method defined according to the ACPI spec). As a result, the ACPI video driver binds to the PCI root bridge object and overwrites the previously assigned driver_data field of it, causing subsequent calls to acpi_get_pci_dev() to fail. [rjw: Subject and changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell Reported-and-bisected-by: Dmitry S. Demin Cc: 3.9+ Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

2013-05-26T03:30:31+00:00

Pull slave-dma fixes from Vinod Koul: "We have two patches from Andy & Rafael fixing the Lynxpoint dma" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: ACPI / LPSS: register clock device for Lynxpoint DMA properly dma: acpi-dma: parse CSRT to extract additional resources