From 9f9cd7ee2c05881f151e5ee4889e667a031dd8d9 Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Sat, 21 May 2016 15:30:46 +0800 Subject: ACPI / Thermal / video: fix max_level incorrect value commit 059500940def (ACPI/video: export acpi_video_get_levels) mistakenly dropped the correct value of max_level and that caused the set_level function following failed and the acpi_video backlight interface didn't get created. Fix this by passing back the correct max_level value. While at it, also fix the param used in acpi_video_device_lcd_query_levels where acpi_handle is expected but acpi_video_device is passed. Fixes: 059500940def (ACPI/video: export acpi_video_get_levels) Reported-and-tested-by: Valdis Kletnieks Signed-off-by: Aaron Lu Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 3d5b8a0..c1d138e 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -754,7 +754,8 @@ static int acpi_video_bqc_quirk(struct acpi_video_device *device, } int acpi_video_get_levels(struct acpi_device *device, - struct acpi_video_device_brightness **dev_br) + struct acpi_video_device_brightness **dev_br, + int *pmax_level) { union acpi_object *obj = NULL; int i, max_level = 0, count = 0, level_ac_battery = 0; @@ -841,6 +842,8 @@ int acpi_video_get_levels(struct acpi_device *device, br->count = count; *dev_br = br; + if (pmax_level) + *pmax_level = max_level; out: kfree(obj); @@ -869,7 +872,7 @@ acpi_video_init_brightness(struct acpi_video_device *device) struct acpi_video_device_brightness *br = NULL; int result = -EINVAL; - result = acpi_video_get_levels(device->dev, &br); + result = acpi_video_get_levels(device->dev, &br, &max_level); if (result) return result; device->brightness = br; @@ -1737,7 +1740,7 @@ static void acpi_video_run_bcl_for_osi(struct acpi_video_bus *video) mutex_lock(&video->device_list_lock); list_for_each_entry(dev, &video->video_device_list, entry) { - if (!acpi_video_device_lcd_query_levels(dev, &levels)) + if (!acpi_video_device_lcd_query_levels(dev->dev->handle, &levels)) kfree(levels); } mutex_unlock(&video->device_list_lock); diff --git a/drivers/thermal/int340x_thermal/int3406_thermal.c b/drivers/thermal/int340x_thermal/int3406_thermal.c index 13d431c..a578cd2 100644 --- a/drivers/thermal/int340x_thermal/int3406_thermal.c +++ b/drivers/thermal/int340x_thermal/int3406_thermal.c @@ -177,7 +177,7 @@ static int int3406_thermal_probe(struct platform_device *pdev) return -ENODEV; d->raw_bd = bd; - ret = acpi_video_get_levels(ACPI_COMPANION(&pdev->dev), &d->br); + ret = acpi_video_get_levels(ACPI_COMPANION(&pdev->dev), &d->br, NULL); if (ret) return ret; diff --git a/include/acpi/video.h b/include/acpi/video.h index 70a41f7..5731ccb 100644 --- a/include/acpi/video.h +++ b/include/acpi/video.h @@ -51,7 +51,8 @@ extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type); */ extern bool acpi_video_handles_brightness_key_presses(void); extern int acpi_video_get_levels(struct acpi_device *device, - struct acpi_video_device_brightness **dev_br); + struct acpi_video_device_brightness **dev_br, + int *pmax_level); #else static inline int acpi_video_register(void) { return 0; } static inline void acpi_video_unregister(void) { return; } @@ -72,7 +73,8 @@ static inline bool acpi_video_handles_brightness_key_presses(void) return false; } static inline int acpi_video_get_levels(struct acpi_device *device, - struct acpi_video_device_brightness **dev_br) + struct acpi_video_device_brightness **dev_br, + int *pmax_level) { return -ENODEV; } -- cgit v0.10.2 From 7f9bef9debafcb767d00efb177d0f2edd4940eab Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Wed, 1 Jun 2016 11:03:20 +0800 Subject: ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width() The address check in acpi_hw_get_access_bit_width() should be byte width based, not bit width based. This patch fixes this mistake. For those who want to review acpi_hw_access_bit_width(), here is the concerns and the design details of the function: It is supposed that the GAS Address field should be aligned to the byte width indicated by the GAS AccessSize field. Similarly, for the old non GAS register, it is supposed that its Address should be aligned to its Length. For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum instruction width (64 for MMIO or 32 for PIO) or the user expected access bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/ acpi_hw_write()) and it is supposed that the GAS Address field should always be aligned to the maximum expected access bit width (otherwise it can't be accessed using ANY access bit width). The problem is in acpi_tb_init_generic_address(), where the non GAS register's Length is converted into the GAS BitWidth field, its Address is converted into the GAS Address field, and the GAS AccessSize field is left 0 but most of the registers actually cannot be accessed using "ANY" accesses. As a conclusion, when AccessSize = 0 (ANY), the Address should either be aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64 for MMIO (real GAS). Since currently, max_bit_width is 32, then: 1. BitWidth for the wrong conversion is 8,16,32; and 2. The Address of the real GAS should always be aligned to 8,16,32. The address alignment check to exclude false matched real GAS is not necessary. Thus this patch fixes the issue by removing the address alignment check. On the other hand, we in fact could use a simpler check of "reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that may be issued from acpi_read()/acpi_write() in the future. Fixes: b314a172ee96 (ACPICA: Hardware: Add optimized access bit width support) Reported-and-tested-by: Boris Ostrovsky Acked-by: Mike Marshall Suggested-by: Jan Beulich Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c index 0f18dbc..daceb80 100644 --- a/drivers/acpi/acpica/hwregs.c +++ b/drivers/acpi/acpica/hwregs.c @@ -83,27 +83,22 @@ acpi_hw_write_multiple(u32 value, static u8 acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 max_bit_width) { - u64 address; - if (!reg->access_width) { + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { + max_bit_width = 32; + } + /* * Detect old register descriptors where only the bit_width field - * makes senses. The target address is copied to handle possible - * alignment issues. + * makes senses. */ - ACPI_MOVE_64_TO_64(&address, ®->address); - if (!reg->bit_offset && reg->bit_width && + if (reg->bit_width < max_bit_width && + !reg->bit_offset && reg->bit_width && ACPI_IS_POWER_OF_TWO(reg->bit_width) && - ACPI_IS_ALIGNED(reg->bit_width, 8) && - ACPI_IS_ALIGNED(address, reg->bit_width)) { + ACPI_IS_ALIGNED(reg->bit_width, 8)) { return (reg->bit_width); - } else { - if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { - return (32); - } else { - return (max_bit_width); - } } + return (max_bit_width); } else { return (1 << (reg->access_width + 2)); } -- cgit v0.10.2 From 86314751c7945fa0c67f459beeda2e7c610ca429 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 2 Jun 2016 01:57:50 +0200 Subject: ACPI / processor: Avoid reserving IO regions too early Roland Dreier reports that one of his systems cannot boot because of the changes made by commit ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure). The problematic part of it is the request_region() call in acpi_processor_get_info() that used to run at module init time before the above commit and now it runs much earlier. Unfortunately, the region(s) reserved by it fall into a range the PCI subsystem attempts to reserve for AHCI IO BARs. As a result, the PCI reservation fails and AHCI doesn't work, while previously the PCI reservation would be made before acpi_processor_get_info() and it would succeed. That request_region() call, however, was overlooked by commit ac212b6980d8, as it is not necessary for the enumeration of the processors. It only is needed when the ACPI processor driver actually attempts to handle them which doesn't happen before loading the ACPI processor driver module. Therefore that call should have been moved from acpi_processor_get_info() into that module. Address the problem by moving the request_region() call in question out of acpi_processor_get_info() and use the observation that the region reserved by it is only needed if the FADT-based CPU throttling method is going to be used, which means that it should be sufficient to invoke it from acpi_processor_get_throttling_fadt(). Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure) Reported-by: Roland Dreier Tested-by: Roland Dreier Signed-off-by: Rafael J. Wysocki diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0d92d0f..c7ba948 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -331,15 +331,6 @@ static int acpi_processor_get_info(struct acpi_device *device) pr->throttling.duty_width = acpi_gbl_FADT.duty_width; pr->pblk = object.processor.pblk_address; - - /* - * We don't care about error returns - we just try to mark - * these reserved so that nobody else is confused into thinking - * that this region might be unused.. - * - * (In particular, allocating the IO range for Cardbus) - */ - request_region(pr->throttling.address, 6, "ACPI CPU throttle"); } /* diff --git a/drivers/acpi/processor_throttling.c b/drivers/acpi/processor_throttling.c index f170d74..c72e648 100644 --- a/drivers/acpi/processor_throttling.c +++ b/drivers/acpi/processor_throttling.c @@ -676,6 +676,15 @@ static int acpi_processor_get_throttling_fadt(struct acpi_processor *pr) if (!pr->flags.throttling) return -ENODEV; + /* + * We don't care about error returns - we just try to mark + * these reserved so that nobody else is confused into thinking + * that this region might be unused.. + * + * (In particular, allocating the IO range for Cardbus) + */ + request_region(pr->throttling.address, 6, "ACPI CPU throttle"); + pr->throttling.state = 0; duty_mask = pr->throttling.state_count - 1; -- cgit v0.10.2