From 1985f8c7f9a42a651a9750d6fcadc74336d182df Mon Sep 17 00:00:00 2001 From: Zhengyuan Liu Date: Sat, 14 Dec 2019 00:27:12 +0800 Subject: [PATCH 1/5] tools/power/acpi: fix compilation error If we compile tools/acpi target in the top source directory, we'd get a compilation error showing as bellow: # make tools/acpi DESCEND power/acpi DESCEND tools/acpidbg CC tools/acpidbg/acpidbg.o Assembler messages: Fatal error: can't create /home/lzy/kernel-upstream/power/acpi/\ tools/acpidbg/acpidbg.o: No such file or directory ../../Makefile.rules:26: recipe for target '/home/lzy/kernel-upstream/\ power/acpi/tools/acpidbg/acpidbg.o' failed make[3]: *** [/home/lzy/kernel-upstream//power/acpi/tools/acpidbg/\ acpidbg.o] Error 1 Makefile:19: recipe for target 'acpidbg' failed make[2]: *** [acpidbg] Error 2 Makefile:54: recipe for target 'acpi' failed make[1]: *** [acpi] Error 2 Makefile:1607: recipe for target 'tools/acpi' failed make: *** [tools/acpi] Error 2 Fixes: d5a4b1a540b8 ("tools/power/acpi: Remove direct kernel source include reference") Signed-off-by: Zhengyuan Liu Signed-off-by: Rafael J. Wysocki --- tools/power/acpi/Makefile.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/power/acpi/Makefile.config b/tools/power/acpi/Makefile.config index 0111d246d1ca..54a2857c2510 100644 --- a/tools/power/acpi/Makefile.config +++ b/tools/power/acpi/Makefile.config @@ -15,7 +15,7 @@ include $(srctree)/../../scripts/Makefile.include OUTPUT=$(srctree)/ ifeq ("$(origin O)", "command line") - OUTPUT := $(O)/power/acpi/ + OUTPUT := $(O)/tools/power/acpi/ endif #$(info Determined 'OUTPUT' to be $(OUTPUT)) From 0435bcd9e185803402a2566e78c1067c615bc579 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 17 Dec 2019 12:48:56 +0200 Subject: [PATCH 2/5] docs: firmware-guide: ACPI: Replace dma_request_slave_channel() with dma_request_chan() dma_request_chan() is the preferred API to request slave channels. Signed-off-by: Peter Ujfalusi [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki --- .../firmware-guide/acpi/enumeration.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 0a72b6321f5f..c13fee8b02ba 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -71,8 +71,8 @@ DMA support DMA controllers enumerated via ACPI should be registered in the system to provide generic access to their resources. For example, a driver that would like to be accessible to slave devices via generic API call -dma_request_slave_channel() must register itself at the end of the probe -function like this:: +dma_request_chan() must register itself at the end of the probe function like +this:: err = devm_acpi_dma_controller_register(dev, xlate_func, dw); /* Handle the error if it's not a case of !CONFIG_ACPI */ @@ -112,15 +112,15 @@ could look like:: } #endif -dma_request_slave_channel() will call xlate_func() for each registered DMA -controller. In the xlate function the proper channel must be chosen based on +dma_request_chan() will call xlate_func() for each registered DMA controller. +In the xlate function the proper channel must be chosen based on information in struct acpi_dma_spec and the properties of the controller provided by struct acpi_dma. -Clients must call dma_request_slave_channel() with the string parameter that -corresponds to a specific FixedDMA resource. By default "tx" means the first -entry of the FixedDMA resource array, "rx" means the second entry. The table -below shows a layout:: +Clients must call dma_request_chan() with the string parameter that corresponds +to a specific FixedDMA resource. By default "tx" means the first entry of the +FixedDMA resource array, "rx" means the second entry. The table below shows a +layout:: Device (I2C0) { From 3df663a147fe077a6ee8444ec626738946e65547 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 27 Dec 2019 11:04:21 +0100 Subject: [PATCH 3/5] ACPI: EC: Reference count query handlers under lock There is a race condition in acpi_ec_get_query_handler() theoretically allowing query handlers to go away before refernce counting them. In order to avoid it, call kref_get() on query handlers under ec->mutex. Also simplify the code a bit while at it. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/ec.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index d05be13c1022..08bc9751fe66 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1052,29 +1052,21 @@ void acpi_ec_unblock_transactions(void) /* -------------------------------------------------------------------------- Event Management -------------------------------------------------------------------------- */ -static struct acpi_ec_query_handler * -acpi_ec_get_query_handler(struct acpi_ec_query_handler *handler) -{ - if (handler) - kref_get(&handler->kref); - return handler; -} - static struct acpi_ec_query_handler * acpi_ec_get_query_handler_by_value(struct acpi_ec *ec, u8 value) { struct acpi_ec_query_handler *handler; - bool found = false; mutex_lock(&ec->mutex); list_for_each_entry(handler, &ec->list, node) { if (value == handler->query_bit) { - found = true; - break; + kref_get(&handler->kref); + mutex_unlock(&ec->mutex); + return handler; } } mutex_unlock(&ec->mutex); - return found ? acpi_ec_get_query_handler(handler) : NULL; + return NULL; } static void acpi_ec_query_handler_release(struct kref *kref) From 643956e61ced913a2bbdcf2c95f3d03026b39d1c Mon Sep 17 00:00:00 2001 From: Tian Tao Date: Mon, 30 Dec 2019 19:56:28 +0800 Subject: [PATCH 4/5] ACPI: PPTT: Consistently use unsigned int as parameter type The fourth parameter 'level' of function 'acpi_find_cache_level()' is a signed interger, but its caller 'acpi_find_cache_node()' passes that parameter an unsigned interger. Make the paramter type inconsistency go away. Signed-off-by: Tian Tao Signed-off-by: Xiongfeng Wang [ rjw: Subject/changelog ] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/pptt.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index f31544d3656e..4ae93350b70d 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -98,11 +98,11 @@ static inline bool acpi_pptt_match_type(int table_type, int type) * * Return: The cache structure and the level we terminated with. */ -static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, - int local_level, - struct acpi_subtable_header *res, - struct acpi_pptt_cache **found, - int level, int type) +static unsigned int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, + unsigned int local_level, + struct acpi_subtable_header *res, + struct acpi_pptt_cache **found, + unsigned int level, int type) { struct acpi_pptt_cache *cache; @@ -119,7 +119,7 @@ static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, if (*found != NULL && cache != *found) pr_warn("Found duplicate cache level/type unable to determine uniqueness\n"); - pr_debug("Found cache @ level %d\n", level); + pr_debug("Found cache @ level %u\n", level); *found = cache; /* * continue looking at this node's resource list @@ -132,16 +132,17 @@ static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, return local_level; } -static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *table_hdr, - struct acpi_pptt_processor *cpu_node, - int *starting_level, int level, - int type) +static struct acpi_pptt_cache * +acpi_find_cache_level(struct acpi_table_header *table_hdr, + struct acpi_pptt_processor *cpu_node, + unsigned int *starting_level, unsigned int level, + int type) { struct acpi_subtable_header *res; - int number_of_levels = *starting_level; + unsigned int number_of_levels = *starting_level; int resource = 0; struct acpi_pptt_cache *ret = NULL; - int local_level; + unsigned int local_level; /* walk down from processor node */ while ((res = acpi_get_pptt_resource(table_hdr, cpu_node, resource))) { @@ -321,12 +322,12 @@ static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *ta unsigned int level, struct acpi_pptt_processor **node) { - int total_levels = 0; + unsigned int total_levels = 0; struct acpi_pptt_cache *found = NULL; struct acpi_pptt_processor *cpu_node; u8 acpi_type = acpi_cache_type(type); - pr_debug("Looking for CPU %d's level %d cache type %d\n", + pr_debug("Looking for CPU %d's level %u cache type %d\n", acpi_cpu_id, level, acpi_type); cpu_node = acpi_find_processor_node(table_hdr, acpi_cpu_id); From 0528904926aab19bffb2068879aa44db166c6d5f Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Thu, 2 Jan 2020 14:27:54 -0600 Subject: [PATCH 5/5] ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch Running evemu-record on the lid switch event shows that the lid reports the first "close" but then never reports an "open". This causes systemd to continuously re-suspend the laptop every 30s. Resetting the _LID to "open" fixes the issue. Signed-off-by: Jason Ekstrand Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki --- drivers/acpi/button.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index b758b45737f5..f6925f16c4a2 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -122,6 +122,17 @@ static const struct dmi_system_id dmi_lid_quirks[] = { }, .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, }, + { + /* + * Razer Blade Stealth 13 late 2019, notification of the LID device + * only happens on close, not on open and _LID always returns closed. + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Razer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Razer Blade Stealth 13 Late 2019"), + }, + .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, + }, {} };