From 3a391a39593b48341f0908511590a6c0e55cc069 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 12 Jul 2013 13:45:59 +0200 Subject: ACPI / scan: Do not try to attach scan handlers to devices having them 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 Cc: 3.10+ --- drivers/acpi/scan.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 10985573aaa7..080d75962c57 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -1981,6 +1981,9 @@ static acpi_status acpi_bus_device_attach(acpi_handle handle, u32 lvl_not_used, if (acpi_bus_get_device(handle, &device)) return AE_CTRL_DEPTH; + if (device->handler) + return AE_OK; + ret = acpi_scan_attach_handler(device); if (ret) return ret > 0 ? AE_OK : AE_CTRL_DEPTH; -- cgit v1.2.3 From 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 8 Jul 2013 02:01:53 +0200 Subject: ACPI / scan: Always call acpi_bus_scan() for bus check notifications 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 Cc: 3.10+ --- drivers/acpi/scan.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 080d75962c57..8a46c924effd 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -352,10 +352,12 @@ static void acpi_scan_bus_device_check(acpi_handle handle, u32 ost_source) mutex_lock(&acpi_scan_lock); lock_device_hotplug(); - acpi_bus_get_device(handle, &device); - if (device) { - dev_warn(&device->dev, "Attempt to re-insert\n"); - goto out; + if (ost_source != ACPI_NOTIFY_BUS_CHECK) { + acpi_bus_get_device(handle, &device); + if (device) { + dev_warn(&device->dev, "Attempt to re-insert\n"); + goto out; + } } acpi_evaluate_hotplug_ost(handle, ost_source, ACPI_OST_SC_INSERT_IN_PROGRESS, NULL); -- cgit v1.2.3 From d19f503e22316a84c39bc19445e0e4fdd49b3532 Mon Sep 17 00:00:00 2001 From: Toshi Kani Date: Wed, 10 Jul 2013 10:47:13 -0600 Subject: ACPI / memhotplug: Fix a stale pointer in error path device->driver_data needs to be cleared when releasing its data, mem_device, in an error path of acpi_memory_device_add(). The function evaluates the _CRS of memory device objects, and fails when it gets an unexpected resource or cannot allocate memory. A kernel crash or data corruption may occur when the kernel accesses the stale pointer. Signed-off-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Cc: 2.6.32+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_memhotplug.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index c711d1144044..999adb5499c7 100644 --- a/drivers/acpi/acpi_memhotplug.c +++ b/drivers/acpi/acpi_memhotplug.c @@ -323,6 +323,7 @@ static int acpi_memory_device_add(struct acpi_device *device, /* Get the range from the _CRS */ result = acpi_memory_get_device_resources(mem_device); if (result) { + device->driver_data = NULL; kfree(mem_device); return result; } -- cgit v1.2.3 From 9657a565a476d517451c10b0bcc106e300785aff Mon Sep 17 00:00:00 2001 From: Lan Tianyu Date: Tue, 16 Jul 2013 10:07:21 +0800 Subject: ACPI / video: ignore BIOS initial backlight value for Fujitsu E753 The BIOS of FUjitsu E753 reports an incorrect initial backlight value for WIN8 compatible OS, causing backlight to be dark during startup. This change causes the incorrect initial value from BIOS to be ignored. References: https://bugzilla.kernel.org/show_bug.cgi?id=60161 Reported-and-tested-by: Jan Hinnerk Stosch Signed-off-by: Lan Tianyu Cc: 3.7+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video.c | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 5d7075d25700..e441876f5d5b 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -448,6 +448,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "Fujitsu E753", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "FUJITSU"), + DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E753"), + }, + }, { .callback = video_ignore_initial_backlight, .ident = "HP Pavilion dm4", -- cgit v1.2.3