@@ -42,6 +42,15 @@ DEFINE_MUTEX(acpi_device_lock);
LIST_HEAD(acpi_wakeup_device_list);
static DEFINE_MUTEX(acpi_hp_context_lock);
+/*
+ * Variables for the new 2 step scan scheme:
+ * Step 1. Add all devices for which acpi_should_defer_add() returns false
+ * Step 2. Add devices deferred during phase 1.
+ * These are protected by the acpi_scan_lock.
+ */
+static bool acpi_check_defer_add;
+static LIST_HEAD(acpi_deferred_devices);
+
/*
* The UART device described by the SPCR table is the only object which needs
* special-casing. Everything else is covered by ACPI namespace paths in STAO
@@ -55,6 +64,11 @@ struct acpi_dep_data {
acpi_handle slave;
};
+struct acpi_deferred_dev {
+ struct list_head node;
+ acpi_handle handle;
+};
+
void acpi_scan_lock_acquire(void)
{
mutex_lock(&acpi_scan_lock);
@@ -741,6 +755,16 @@ static const char * const acpi_ignore_dep_hids[] = {
NULL
};
+/*
+ * List of HIDs for which we defer adding them to the second step of the
+ * scanning of the root, because some of their methods used during addition
+ * depend on OpRegions registered by the drivers for other ACPI devices.
+ */
+static const char * const acpi_defer_add_hids[] = {
+ "BCM2E5B", /* Acer SW3-016 bluetooth HID when GPIO OpRegs or not available yet */
+ NULL
+};
+
static struct acpi_device *acpi_bus_get_parent(acpi_handle handle)
{
struct acpi_device *device = NULL;
@@ -1631,18 +1655,42 @@ void acpi_device_add_finalize(struct acpi_device *device)
kobject_uevent(&device->dev.kobj, KOBJ_ADD);
}
+static bool acpi_should_defer_add(acpi_handle handle, struct acpi_device_info *info)
+{
+ if (!acpi_check_defer_add || !info)
+ return false;
+
+ if (acpi_info_matches_hids(info, acpi_defer_add_hids))
+ return true;
+
+ return false;
+}
+
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
unsigned long long sta)
{
int result;
struct acpi_device *device;
+ struct acpi_deferred_dev *deferred_dev;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_device_info *info = NULL;
if (handle != ACPI_ROOT_OBJECT && type == ACPI_BUS_TYPE_DEVICE)
acpi_get_object_info(handle, &info);
+ if (acpi_should_defer_add(handle, info)) {
+ kfree(info);
+
+ deferred_dev = kzalloc(sizeof(*deferred_dev), GFP_KERNEL);
+ if (!deferred_dev)
+ return -ENOMEM;
+
+ deferred_dev->handle = handle;
+ list_add_tail(&deferred_dev->node, &acpi_deferred_devices);
+ return -EPROBE_DEFER;
+ }
+
device = kzalloc(sizeof(struct acpi_device), GFP_KERNEL);
if (!device) {
printk(KERN_ERR PREFIX "Memory allocation error\n");
@@ -2201,6 +2249,7 @@ int __init acpi_scan_init(void)
int result;
acpi_status status;
struct acpi_table_stao *stao_ptr;
+ struct acpi_deferred_dev *deferred_dev, *tmp;
acpi_pci_root_init();
acpi_pci_link_init();
@@ -2248,7 +2297,9 @@ int __init acpi_scan_init(void)
/*
* Enumerate devices in the ACPI namespace.
*/
+ acpi_check_defer_add = true;
result = acpi_bus_scan(ACPI_ROOT_OBJECT);
+ acpi_check_defer_add = false;
if (result)
goto cleanup;
@@ -2256,6 +2307,15 @@ int __init acpi_scan_init(void)
if (result)
goto cleanup;
+ list_for_each_entry_safe(deferred_dev, tmp, &acpi_deferred_devices, node) {
+ result = acpi_bus_scan(deferred_dev->handle);
+ if (result)
+ goto cleanup;
+
+ list_del(&deferred_dev->node);
+ kfree(deferred_dev);
+ }
+
/* Fixed feature devices do not exist on HW-reduced platform */
if (!acpi_gbl_reduced_hardware) {
result = acpi_bus_scan_fixed();
@@ -2275,6 +2335,11 @@ int __init acpi_scan_init(void)
put_device(&acpi_root->dev);
}
+ list_for_each_entry_safe(deferred_dev, tmp, &acpi_deferred_devices, node) {
+ list_del(&deferred_dev->node);
+ kfree(deferred_dev);
+ }
+
mutex_unlock(&acpi_scan_lock);
return result;
}
The ACPI scan code currently does not honor _DEP lists, except for ACPI battery nodes. This is an issue on some devices, where some of the methods used during device-addition may rely on OpRegions of other devices. An example of this is the Acer Switch 10E SW3-016 model. The _HID method of the ACPI node for the UART attached Bluetooth, reads GPIOs to detect the installed wifi chip and update the _HID for the Bluetooth's ACPI node accordingly. The current ACPI scan code calls _HID before the GPIO controller's OpRegions are available, leading to the wrong _HID being used and Bluetooth not working. This splits the scanning into 2 steps, deferring the addition of some devices which need access to OpRegions of other devices during scanning to the second step. This initial implementation takes a very simple approach to identify which devices need to have their device-addition deferred. It uses a static lists of HIDs for this. This list is initially populated with the HID reported for the Bluetooth on the Acer SW3-016. This uses the HID reported when the GPIO OpRegions are not yet available! A more elaborate approach, which actually looks at the _DEP list will be added by a follow up patch. This other approach has a big chance of causing regressions, so for now it will be hidden behind a kernel commandline option. Which is why the KISS approach chosen here is needed to fix the issue at hand, so that things will work OOTB on affected devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665610 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/scan.c | 65 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)