From 6ad90f71129219f9b87ce181189817bcbcde34b8 Mon Sep 17 00:00:00 2001 From: Stuart Hayes Date: Thu, 8 Dec 2022 17:25:36 -0600 Subject: ACPI: tables: Add support for NBFT Add support for the NVMe Boot Firmware Table (NBFT) to facilitate booting from NVM Express namespaces which are accessed via NVMe over Fabrics (NVMe-oF). Signed-off-by: Stuart Hayes Reviewed-by: John Meneghini Signed-off-by: Rafael J. Wysocki --- drivers/acpi/tables.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 5fbc32b802d0..7b4680da57d7 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -555,7 +555,8 @@ static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst = { ACPI_SIG_WDDT, ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT, ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT, ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, - ACPI_SIG_NHLT, ACPI_SIG_AEST, ACPI_SIG_CEDT, ACPI_SIG_AGDI }; + ACPI_SIG_NHLT, ACPI_SIG_AEST, ACPI_SIG_CEDT, ACPI_SIG_AGDI, + ACPI_SIG_NBFT }; #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header) -- cgit From 73d15a7c13bfe1292db85ed3de8dfa711291819d Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Tue, 13 Dec 2022 13:34:54 +0100 Subject: ACPI: PMIC: Add pmic_i2c_address to BYT Crystal Cove support Add a pmic_i2c_address entry to intel_pmic_bytcrc.c, so that intel_soc_pmic_exec_mipi_pmic_seq_element() can be used on devices with a Bay Trail Crystal Cove PMIC OpRegion driver. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- drivers/acpi/pmic/intel_pmic_bytcrc.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers') diff --git a/drivers/acpi/pmic/intel_pmic_bytcrc.c b/drivers/acpi/pmic/intel_pmic_bytcrc.c index 9ea79f210965..2b09f8da5400 100644 --- a/drivers/acpi/pmic/intel_pmic_bytcrc.c +++ b/drivers/acpi/pmic/intel_pmic_bytcrc.c @@ -283,6 +283,7 @@ static const struct intel_pmic_opregion_data intel_crc_pmic_opregion_data = { .power_table_count= ARRAY_SIZE(power_table), .thermal_table = thermal_table, .thermal_table_count = ARRAY_SIZE(thermal_table), + .pmic_i2c_address = 0x6e, }; static int intel_crc_pmic_opregion_probe(struct platform_device *pdev) -- cgit From e1d9148582ab2c3dada5c5cf8ca7531ca269fee5 Mon Sep 17 00:00:00 2001 From: Mario Limonciello Date: Thu, 15 Dec 2022 09:51:20 -0600 Subject: ACPICA: Drop port I/O validation for some regions Microsoft introduced support in Windows XP for blocking port I/O to various regions. For Windows compatibility ACPICA has adopted the same protections and will disallow writes to those (presumably) the same regions. On some systems the AML included with the firmware will issue 4 byte long writes to 0x80. These writes aren't making it over because of this blockage. The first 4 byte write attempt is rejected, and then subsequently 1 byte at a time each offset is tried. The first at 0x80 works, but then the next 3 bytes are rejected. This manifests in bizarre failures for devices that expected the AML to write all 4 bytes. Trying the same AML on Windows 10 or 11 doesn't hit this failure and all 4 bytes are written. Either some of these regions were wrong or some point after Windows XP some of these regions blocks have been lifted. In the last 15 years there doesn't seem to be any reports popping up of this error in the Windows event viewer anymore. There is no documentation at Microsoft's developer site indicating that Windows ACPI interpreter blocks these regions. Between the lack of documentation and the fact that the writes actually do work in Windows 10 and 11, it's quite likely Windows doesn't actually enforce this anymore. So to help the issue, only enforce Windows XP specific entries if the latest _OSI supported is Windows XP. Continue to enforce the ALWAYS_ILLEGAL entries. Link: https://github.com/acpica/acpica/pull/817 Fixes: 7f0719039085 ("ACPICA: New: I/O port protection") Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/hwvalid.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/acpica/hwvalid.c b/drivers/acpi/acpica/hwvalid.c index 915b26448d2c..0d392e7b0747 100644 --- a/drivers/acpi/acpica/hwvalid.c +++ b/drivers/acpi/acpica/hwvalid.c @@ -23,8 +23,8 @@ acpi_hw_validate_io_request(acpi_io_address address, u32 bit_width); * * The table is used to implement the Microsoft port access rules that * first appeared in Windows XP. Some ports are always illegal, and some - * ports are only illegal if the BIOS calls _OSI with a win_XP string or - * later (meaning that the BIOS itelf is post-XP.) + * ports are only illegal if the BIOS calls _OSI with nothing newer than + * the specific _OSI strings. * * This provides ACPICA with the desired port protections and * Microsoft compatibility. @@ -145,7 +145,8 @@ acpi_hw_validate_io_request(acpi_io_address address, u32 bit_width) /* Port illegality may depend on the _OSI calls made by the BIOS */ - if (acpi_gbl_osi_data >= port_info->osi_dependency) { + if (port_info->osi_dependency == ACPI_ALWAYS_ILLEGAL || + acpi_gbl_osi_data == port_info->osi_dependency) { ACPI_DEBUG_PRINT((ACPI_DB_VALUES, "Denied AML access to port 0x%8.8X%8.8X/%X (%s 0x%.4X-0x%.4X)\n", ACPI_FORMAT_UINT64(address), -- cgit From 91fdb91ccca2b48572a1ccf1d382fd599e3e1237 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Tue, 20 Dec 2022 17:01:26 +0200 Subject: ACPICA: Constify pathname argument for acpi_get_handle() acpi_get_handle() uses the pathname argument to find a handle related to that pathname but it does not need to modify it. Make it const, in order to be able to pass const pathname to it. Link: https://github.com/acpica/acpica/pull/773 Signed-off-by: Sakari Ailus Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/nsxfname.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c index b2cfdfef3194..a0592d15dd37 100644 --- a/drivers/acpi/acpica/nsxfname.c +++ b/drivers/acpi/acpica/nsxfname.c @@ -44,7 +44,7 @@ static char *acpi_ns_copy_device_id(struct acpi_pnp_device_id *dest, acpi_status acpi_get_handle(acpi_handle parent, - acpi_string pathname, acpi_handle *ret_handle) + const char *pathname, acpi_handle *ret_handle) { acpi_status status; struct acpi_namespace_node *node = NULL; -- cgit From fbf757e55afbd8b4d36f4808a6ae9107afeb79f3 Mon Sep 17 00:00:00 2001 From: Zhou jie Date: Fri, 23 Dec 2022 17:02:15 +0800 Subject: ACPI: processor: idle: Drop unnecessary (void *) conversion The (void *) type pointer does not need to be cast, so don't do that in lapic_timer_check_state(). Signed-off-by: Zhou jie [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/processor_idle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 7bf882fcd64b..5a01c2a1567f 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -147,7 +147,7 @@ static void lapic_timer_check_state(int state, struct acpi_processor *pr, static void __lapic_timer_propagate_broadcast(void *arg) { - struct acpi_processor *pr = (struct acpi_processor *) arg; + struct acpi_processor *pr = arg; if (pr->power.timer_broadcast_on_state < INT_MAX) tick_broadcast_enable(); -- cgit From c02d5feb6e2f60affc6ba8606d8d614c071e2ba6 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 28 Dec 2022 22:21:49 +0100 Subject: ACPI: processor: perflib: Use the "no limit" frequency QoS When _PPC returns 0, it means that the CPU frequency is not limited by the platform firmware, so make acpi_processor_get_platform_limit() update the frequency QoS request used by it to "no limit" in that case. This addresses a problem with limiting CPU frequency artificially on some systems after CPU offline/online to the frequency that corresponds to the first entry in the _PSS return package. Reported-by: Pratyush Yadav Signed-off-by: Rafael J. Wysocki Reviewed-by: Pratyush Yadav Tested-by: Pratyush Yadav --- drivers/acpi/processor_perflib.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 970f04a958cd..0da85fc2a7e4 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -53,6 +53,8 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr) { acpi_status status = 0; unsigned long long ppc = 0; + s32 qos_value; + int index; int ret; if (!pr) @@ -72,17 +74,27 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr) } } + index = ppc; + pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, - (int)ppc, ppc ? "" : "not"); + index, index ? "is" : "is not"); - pr->performance_platform_limit = (int)ppc; + pr->performance_platform_limit = index; if (ppc >= pr->performance->state_count || unlikely(!freq_qos_request_active(&pr->perflib_req))) return 0; - ret = freq_qos_update_request(&pr->perflib_req, - pr->performance->states[ppc].core_frequency * 1000); + /* + * If _PPC returns 0, it means that all of the available states can be + * used ("no limit"). + */ + if (index == 0) + qos_value = FREQ_QOS_MAX_DEFAULT_VALUE; + else + qos_value = pr->performance->states[index].core_frequency * 1000; + + ret = freq_qos_update_request(&pr->perflib_req, qos_value); if (ret < 0) { pr_warn("Failed to update perflib freq constraint: CPU%d (%d)\n", pr->id, ret); -- cgit From 99387b016022c29234c4ebf9abd34358c6e56532 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 28 Dec 2022 22:24:10 +0100 Subject: ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily Modify acpi_processor_get_platform_limit() to avoid updating its frequency QoS request when the _PPC return value has not changed by comparing that value to the previous _PPC return value stored in the performance_platform_limit field of the struct acpi_processor corresponding to the given CPU. While at it, do the _PPC return value check against the state count earlier, to avoid setting performance_platform_limit to an invalid value, and make acpi_processor_ppc_init() use FREQ_QOS_MAX_DEFAULT_VALUE as the "no limit" frequency QoS for consistency. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/processor_perflib.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 0da85fc2a7e4..4265814c74f8 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -76,13 +76,16 @@ static int acpi_processor_get_platform_limit(struct acpi_processor *pr) index = ppc; + if (pr->performance_platform_limit == index || + ppc >= pr->performance->state_count) + return 0; + pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id, index, index ? "is" : "is not"); pr->performance_platform_limit = index; - if (ppc >= pr->performance->state_count || - unlikely(!freq_qos_request_active(&pr->perflib_req))) + if (unlikely(!freq_qos_request_active(&pr->perflib_req))) return 0; /* @@ -178,9 +181,16 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy) if (!pr) continue; + /* + * Reset performance_platform_limit in case there is a stale + * value in it, so as to make it match the "no limit" QoS value + * below. + */ + pr->performance_platform_limit = 0; + ret = freq_qos_add_request(&policy->constraints, - &pr->perflib_req, - FREQ_QOS_MAX, INT_MAX); + &pr->perflib_req, FREQ_QOS_MAX, + FREQ_QOS_MAX_DEFAULT_VALUE); if (ret < 0) pr_err("Failed to add freq constraint for CPU%d (%d)\n", cpu, ret); -- cgit From e8a0e30b742f76ebd0f3b196973df4bf65d8fbbb Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 28 Dec 2022 22:26:04 +0100 Subject: cpufreq: intel_pstate: Drop ACPI _PSS states table patching After making acpi_processor_get_platform_limit() use the "no limit" value for its frequency QoS request when _PPC returns 0, it is not necessary to replace the frequency corresponding to the first _PSS return package entry with the maximum turbo frequency of the given CPU in intel_pstate_init_acpi_perf_limits() any more, so drop the code doing that along with the comment explaining it. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'drivers') diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index fd73d6d2b808..cb4beec27555 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -452,20 +452,6 @@ static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy) (u32) cpu->acpi_perf_data.states[i].control); } - /* - * The _PSS table doesn't contain whole turbo frequency range. - * This just contains +1 MHZ above the max non turbo frequency, - * with control value corresponding to max turbo ratio. But - * when cpufreq set policy is called, it will call with this - * max frequency, which will cause a reduced performance as - * this driver uses real max turbo frequency as the max - * frequency. So correct this frequency in _PSS table to - * correct max turbo frequency based on the turbo state. - * Also need to convert to MHz as _PSS freq is in MHz. - */ - if (!global.turbo_disabled) - cpu->acpi_perf_data.states[0].core_frequency = - policy->cpuinfo.max_freq / 1000; cpu->valid_pss_table = true; pr_debug("_PPC limits will be enforced\n"); -- cgit From 446c85af665cf6d911c4821ac9507c8ba0cc7e75 Mon Sep 17 00:00:00 2001 From: Ammar Faizi Date: Fri, 23 Dec 2022 21:24:18 +0700 Subject: ACPI: Silence missing prototype warnings Compiling with clang-16: drivers/acpi/acpi_lpit.c:142:6: error: no previous prototype \ for function 'acpi_init_lpit' [-Werror,-Wmissing-prototypes] drivers/acpi/ioapic.c:212:6: error: no previous prototype \ for function 'pci_ioapic_remove' [-Werror,-Wmissing-prototypes] drivers/acpi/ioapic.c:229:5: error: no previous prototype \ for function 'acpi_ioapic_remove' [-Werror,-Wmissing-prototypes] Include "internal.h" to silence them. Signed-off-by: Ammar Faizi Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_lpit.c | 1 + drivers/acpi/ioapic.c | 1 + 2 files changed, 2 insertions(+) (limited to 'drivers') diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c index 50540d4d4948..3843d2576d3f 100644 --- a/drivers/acpi/acpi_lpit.c +++ b/drivers/acpi/acpi_lpit.c @@ -10,6 +10,7 @@ #include #include #include +#include "internal.h" struct lpit_residency_info { struct acpi_generic_address gaddr; diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c index a690c7b18623..6677955b4a8e 100644 --- a/drivers/acpi/ioapic.c +++ b/drivers/acpi/ioapic.c @@ -24,6 +24,7 @@ #include #include #include +#include "internal.h" struct acpi_pci_ioapic { acpi_handle root_handle; -- cgit From ca843a4c79486e99a19b859ef0b9887854afe146 Mon Sep 17 00:00:00 2001 From: Daniil Tatianin Date: Sat, 7 Jan 2023 02:53:08 +0300 Subject: ACPICA: nsrepair: handle cases without a return value correctly Previously acpi_ns_simple_repair() would crash if expected_btypes contained any combination of ACPI_RTYPE_NONE with a different type, e.g | ACPI_RTYPE_INTEGER because of slightly incorrect logic in the !return_object branch, which wouldn't return AE_AML_NO_RETURN_VALUE for such cases. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Link: https://github.com/acpica/acpica/pull/811 Fixes: 61db45ca2163 ("ACPICA: Restore code that repairs NULL package elements in return values.") Signed-off-by: Daniil Tatianin Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/nsrepair.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/acpica/nsrepair.c b/drivers/acpi/acpica/nsrepair.c index 367fcd201f96..ec512e06a48e 100644 --- a/drivers/acpi/acpica/nsrepair.c +++ b/drivers/acpi/acpica/nsrepair.c @@ -181,8 +181,9 @@ acpi_ns_simple_repair(struct acpi_evaluate_info *info, * Try to fix if there was no return object. Warning if failed to fix. */ if (!return_object) { - if (expected_btypes && (!(expected_btypes & ACPI_RTYPE_NONE))) { - if (package_index != ACPI_NOT_PACKAGE_ELEMENT) { + if (expected_btypes) { + if (!(expected_btypes & ACPI_RTYPE_NONE) && + package_index != ACPI_NOT_PACKAGE_ELEMENT) { ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname, ACPI_WARN_ALWAYS, @@ -196,14 +197,15 @@ acpi_ns_simple_repair(struct acpi_evaluate_info *info, if (ACPI_SUCCESS(status)) { return (AE_OK); /* Repair was successful */ } - } else { + } + + if (expected_btypes != ACPI_RTYPE_NONE) { ACPI_WARN_PREDEFINED((AE_INFO, info->full_pathname, ACPI_WARN_ALWAYS, "Missing expected return value")); + return (AE_AML_NO_RETURN_VALUE); } - - return (AE_AML_NO_RETURN_VALUE); } } -- cgit From 28a35ac2f5f8719a6451932d7ab6b6b3d264a3aa Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 10 Jan 2023 18:58:05 +0100 Subject: ACPI: PNP: Introduce list of known non-PNP devices In some cases, PNP device IDs from acpi_pnp_device_ids[] are returned by _CID for devices for which matching platform drivers are present in the kernel and should be bound to them. However, the IDs coming from _CID cause the PNP scan handler to attach to those devices which prevents platform device objects from being created for them. Address this by introducing a list of known non-PNP device IDs into acpi_pnp.c such that if a device ID is there in that list, it cannot be attached to by the PNP scan handler and add the platform runtime update and telemetry device IDs to that list to start with. Reported-by: Chen Yu Signed-off-by: Rafael J. Wysocki Tested-by: Zhang Yang --- drivers/acpi/acpi_pnp.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c index ffdcfcd4a10d..01abf26764b0 100644 --- a/drivers/acpi/acpi_pnp.c +++ b/drivers/acpi/acpi_pnp.c @@ -348,10 +348,22 @@ static bool acpi_pnp_match(const char *idstr, const struct acpi_device_id **matc return false; } +/* + * If one of the device IDs below is present in the list of device IDs of a + * given ACPI device object, the PNP scan handler will not attach to that + * object, because there is a proper non-PNP driver in the kernel for the + * device represented by it. + */ +static const struct acpi_device_id acpi_nonpnp_device_ids[] = { + {"INTC1080"}, + {"INTC1081"}, + {""}, +}; + static int acpi_pnp_attach(struct acpi_device *adev, const struct acpi_device_id *id) { - return 1; + return !!acpi_match_device_ids(adev, acpi_nonpnp_device_ids); } static struct acpi_scan_handler acpi_pnp_handler = { -- cgit From f2ac14b5f197e4a2dec51e5ceaa56682ff1592bc Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Sat, 14 Jan 2023 09:50:50 +0100 Subject: ACPI: battery: Fix missing NUL-termination with large strings When encountering a string bigger than the destination buffer (32 bytes), the string is not properly NUL-terminated, causing buffer overreads later. This for example happens on the Inspiron 3505, where the battery model name is larger than 32 bytes, which leads to sysfs showing the model name together with the serial number string (which is NUL-terminated and thus prevents worse). Fix this by using strscpy() which ensures that the result is always NUL-terminated. Fixes: 106449e870b3 ("ACPI: Battery: Allow extract string from integer") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki --- drivers/acpi/battery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index f4badcdde76e..fb64bd217d82 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -440,7 +440,7 @@ static int extract_package(struct acpi_battery *battery, if (element->type == ACPI_TYPE_STRING || element->type == ACPI_TYPE_BUFFER) - strncpy(ptr, element->string.pointer, 32); + strscpy(ptr, element->string.pointer, 32); else if (element->type == ACPI_TYPE_INTEGER) { strncpy(ptr, (u8 *)&element->integer.value, sizeof(u64)); -- cgit From 53fc7e80f3aa9c34d396bcfbcc03a4c0d2eaac96 Mon Sep 17 00:00:00 2001 From: Shuai Xue Date: Wed, 18 Jan 2023 14:35:04 +0800 Subject: ACPI: APEI: EINJ: Limit error type to 32-bit width The bit map of error types to inject is 32-bit width [1]. Add parameter check to reflect the fact. [1] ACPI Specification 6.4, Section 18.6.4. Error Types Signed-off-by: Shuai Xue Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki --- drivers/acpi/apei/einj.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'drivers') diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c index ab86b2f4e719..b4373e575660 100644 --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@ -616,6 +616,10 @@ static int error_type_set(void *data, u64 val) u32 available_error_type = 0; u32 tval, vendor; + /* Only low 32 bits for error type are valid */ + if (val & GENMASK_ULL(63, 32)) + return -EINVAL; + /* * Vendor defined types have 0x80000000 bit set, and * are not enumerated by ACPI_EINJ_GET_ERROR_TYPE -- cgit From a1a32ded2887fd421d67e9c9b67ae4504bdb08c9 Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Thu, 19 Jan 2023 15:21:14 +0100 Subject: ACPI: battery: Fix buffer overread if not NUL-terminated If a buffer containing ASCII characters is not NUL-terminated (which is perfectly legal according to the ACPI specification), the ACPI battery driver might not honor its length. Fix this by limiting the amount of data to be copied to the buffer length while also using strscpy() to make sure that the resulting string is always NUL-terminated. Also replace strncpy() vs strscpy(). Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki --- drivers/acpi/battery.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index fb64bd217d82..0ec12a7dbcca 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -437,16 +437,25 @@ static int extract_package(struct acpi_battery *battery, element = &package->package.elements[i]; if (offsets[i].mode) { u8 *ptr = (u8 *)battery + offsets[i].offset; + u32 len = 32; - if (element->type == ACPI_TYPE_STRING || - element->type == ACPI_TYPE_BUFFER) - strscpy(ptr, element->string.pointer, 32); - else if (element->type == ACPI_TYPE_INTEGER) { - strncpy(ptr, (u8 *)&element->integer.value, - sizeof(u64)); - ptr[sizeof(u64)] = 0; - } else + switch (element->type) { + case ACPI_TYPE_BUFFER: + if (len > element->buffer.length + 1) + len = element->buffer.length + 1; + + fallthrough; + case ACPI_TYPE_STRING: + strscpy(ptr, element->string.pointer, len); + + break; + case ACPI_TYPE_INTEGER: + strscpy(ptr, (u8 *)&element->integer.value, sizeof(u64) + 1); + + break; + default: *ptr = 0; /* don't have value */ + } } else { int *x = (int *)((u8 *)battery + offsets[i].offset); *x = (element->type == ACPI_TYPE_INTEGER) ? -- cgit From 91507d25a67c561f97c34fdd9fdf04e9a1dd7355 Mon Sep 17 00:00:00 2001 From: Armin Wolf Date: Thu, 19 Jan 2023 15:21:15 +0100 Subject: ACPI: battery: Increase maximum string length On the Dell Inspiron 3505, the battery model name is represented as a hex string containing seven numbers, causing it to be larger than the current maximum string length (32). Increase this length to 64 to avoid truncating the string in such cases. Also introduce a common define for the length. Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki --- drivers/acpi/battery.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 0ec12a7dbcca..9c67ed02d797 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -42,6 +42,8 @@ #define ACPI_BATTERY_STATE_CHARGING 0x2 #define ACPI_BATTERY_STATE_CRITICAL 0x4 +#define MAX_STRING_LENGTH 64 + MODULE_AUTHOR("Paul Diefenbaugh"); MODULE_AUTHOR("Alexey Starikovskiy "); MODULE_DESCRIPTION("ACPI Battery Driver"); @@ -118,10 +120,10 @@ struct acpi_battery { int capacity_granularity_1; int capacity_granularity_2; int alarm; - char model_number[32]; - char serial_number[32]; - char type[32]; - char oem_info[32]; + char model_number[MAX_STRING_LENGTH]; + char serial_number[MAX_STRING_LENGTH]; + char type[MAX_STRING_LENGTH]; + char oem_info[MAX_STRING_LENGTH]; int state; int power_unit; unsigned long flags; @@ -437,7 +439,7 @@ static int extract_package(struct acpi_battery *battery, element = &package->package.elements[i]; if (offsets[i].mode) { u8 *ptr = (u8 *)battery + offsets[i].offset; - u32 len = 32; + u32 len = MAX_STRING_LENGTH; switch (element->type) { case ACPI_TYPE_BUFFER: -- cgit From 7de6c3fb6dfbf9b920caa8cad953d8ac406f6790 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Wed, 25 Jan 2023 12:38:11 +0100 Subject: ACPI: PMIC: Add comments with DSDT power opregion field names The DSDTs of CHT devices using the Dollar Cove TI PMIC, all use LDO1 - LDO14 names for the DSDT power opregion field names. Add comments with these fields to make it easier to see which PMIC registers are being set by ACPI code using these. Note that LDO4 is missing and the mapped registers jump from 0x43 to 0x45 to match. This matches with how the fields are declared in the DSDT where LDO4 is skipped too. Note there is no hole in the field addresses, LDO4 is simply just not defined on either side. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki --- drivers/acpi/pmic/intel_pmic_chtdc_ti.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/pmic/intel_pmic_chtdc_ti.c b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c index 418eec523025..c84ef3d15181 100644 --- a/drivers/acpi/pmic/intel_pmic_chtdc_ti.c +++ b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c @@ -20,19 +20,19 @@ #define CHTDC_TI_GPADC 0x5a static struct pmic_table chtdc_ti_power_table[] = { - { .address = 0x00, .reg = 0x41 }, - { .address = 0x04, .reg = 0x42 }, - { .address = 0x08, .reg = 0x43 }, - { .address = 0x0c, .reg = 0x45 }, - { .address = 0x10, .reg = 0x46 }, - { .address = 0x14, .reg = 0x47 }, - { .address = 0x18, .reg = 0x48 }, - { .address = 0x1c, .reg = 0x49 }, - { .address = 0x20, .reg = 0x4a }, - { .address = 0x24, .reg = 0x4b }, - { .address = 0x28, .reg = 0x4c }, - { .address = 0x2c, .reg = 0x4d }, - { .address = 0x30, .reg = 0x4e }, + { .address = 0x00, .reg = 0x41 }, /* LDO1 */ + { .address = 0x04, .reg = 0x42 }, /* LDO2 */ + { .address = 0x08, .reg = 0x43 }, /* LDO3 */ + { .address = 0x0c, .reg = 0x45 }, /* LDO5 */ + { .address = 0x10, .reg = 0x46 }, /* LDO6 */ + { .address = 0x14, .reg = 0x47 }, /* LDO7 */ + { .address = 0x18, .reg = 0x48 }, /* LDO8 */ + { .address = 0x1c, .reg = 0x49 }, /* LDO9 */ + { .address = 0x20, .reg = 0x4a }, /* LD10 */ + { .address = 0x24, .reg = 0x4b }, /* LD11 */ + { .address = 0x28, .reg = 0x4c }, /* LD12 */ + { .address = 0x2c, .reg = 0x4d }, /* LD13 */ + { .address = 0x30, .reg = 0x4e }, /* LD14 */ }; static struct pmic_table chtdc_ti_thermal_table[] = { -- cgit From 2d11eae42d52a131f06061015e49dc0f085c5bfc Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 2 Feb 2023 13:44:49 +0100 Subject: ACPI: video: Fix Lenovo Ideapad Z570 DMI match Multiple Ideapad Z570 variants need acpi_backlight=native to force native use on these pre Windows 8 machines since acpi_video backlight control does not work here. The original DMI quirk matches on a product_name of "102434U" but other variants may have different product_name-s such as e.g. "1024D9U". Move to checking product_version instead as is more or less standard for Lenovo DMI quirks for similar reasons. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video_detect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index a8c02608dde4..710ac640267d 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -434,7 +434,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = { /* Lenovo Ideapad Z570 */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), - DMI_MATCH(DMI_PRODUCT_NAME, "102434U"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Ideapad Z570"), }, }, { -- cgit From fda7be2068973195343d14c1f760adcd481455c9 Mon Sep 17 00:00:00 2001 From: Yang Li Date: Wed, 8 Feb 2023 10:31:58 +0800 Subject: ACPI: CPPC: Fix some kernel-doc comments Add the description of @pcc_ss_id in pcc_data_alloc(). Add the description of @cpu_num in cppc_get_transition_latency(). clear the below warnings: drivers/acpi/cppc_acpi.c:607: warning: Function parameter or member 'pcc_ss_id' not described in 'pcc_data_alloc' drivers/acpi/cppc_acpi.c:1616: warning: Function parameter or member 'cpu_num' not described in 'cppc_get_transition_latency' Reported-by: Abaci Robot Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3983 Signed-off-by: Yang Li [ rjw: Dropped redundant empty code lines, minor edits ] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/cppc_acpi.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers') diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 0f17b1c32718..1d00a73fb518 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -595,6 +595,7 @@ bool __weak cpc_supported_by_cpu(void) /** * pcc_data_alloc() - Allocate the pcc_data memory for pcc subspace + * @pcc_ss_id: PCC Subspace index as in the PCC client ACPI package. * * Check and allocate the cppc_pcc_data memory. * In some processor configurations it is possible that same subspace @@ -1536,6 +1537,7 @@ EXPORT_SYMBOL_GPL(cppc_set_perf); /** * cppc_get_transition_latency - returns frequency transition latency in ns + * @cpu_num: CPU number for per_cpu(). * * ACPI CPPC does not explicitly specify how a platform can specify the * transition latency for performance change requests. The closest we have -- cgit From cb18703c179713056bd7e3bdfc2260ab4e8658f0 Mon Sep 17 00:00:00 2001 From: Adam Niederer Date: Sat, 11 Feb 2023 15:13:33 -0500 Subject: ACPI: resource: Add IRQ overrides for MAINGEAR Vector Pro 2 models Fix a regression introduced by commit 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") on MAINGEAR Vector Pro 2 systems, which causes the built-in keyboard to not work. This restores the functionality by adding an IRQ override. No other IRQs were being overridden before, so this should be all that is needed for these systems. I have personally tested this on the 15" model (MG-VCP2-15A3070T), and I have confirmation that the issue is present on the 17" model (MG-VCP2-17A3070T). Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Signed-off-by: Adam Niederer Signed-off-by: Rafael J. Wysocki --- drivers/acpi/resource.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'drivers') diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 192d1784e409..1d9d3364bc2b 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -478,6 +478,24 @@ static const struct dmi_system_id schenker_gm_rg[] = { { } }; +static const struct dmi_system_id maingear_laptop[] = { + { + .ident = "MAINGEAR Vector Pro 2 15", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), + DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-15A3070T"), + } + }, + { + .ident = "MAINGEAR Vector Pro 2 17", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), + DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-17A3070T"), + }, + }, + { } +}; + struct irq_override_cmp { const struct dmi_system_id *system; unsigned char irq; @@ -493,6 +511,7 @@ static const struct irq_override_cmp override_table[] = { { lenovo_laptop, 6, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, { lenovo_laptop, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, { schenker_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, }; static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity, -- cgit From 17bb7046e7ce038a73ee97eaa804e0300c5199e2 Mon Sep 17 00:00:00 2001 From: Werner Sembach Date: Mon, 13 Feb 2023 19:16:53 +0100 Subject: ACPI: resource: Do IRQ override on all TongFang GMxRGxx Apply commit 7592b79ba4a9 ("ACPI: resource: do IRQ override on XMG Core 15") override for all vendors using this mainboard. Signed-off-by: Werner Sembach Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Signed-off-by: Rafael J. Wysocki --- drivers/acpi/resource.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 1d9d3364bc2b..a222bda7e15b 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -467,11 +467,10 @@ static const struct dmi_system_id lenovo_laptop[] = { { } }; -static const struct dmi_system_id schenker_gm_rg[] = { +static const struct dmi_system_id tongfang_gm_rg[] = { { - .ident = "XMG CORE 15 (M22)", + .ident = "TongFang GMxRGxx/XMG CORE 15 (M22)/TUXEDO Stellaris 15 Gen4 AMD", .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"), DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"), }, }, @@ -510,7 +509,7 @@ static const struct irq_override_cmp override_table[] = { { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, { lenovo_laptop, 6, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, { lenovo_laptop, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, - { schenker_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { tongfang_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, }; -- cgit From a527b0111798ed7b9f49830989eaabfe537e09ef Mon Sep 17 00:00:00 2001 From: Thomas Weißschuh Date: Tue, 14 Feb 2023 03:23:52 +0000 Subject: ACPI: make kobj_type structures constant MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definitions to prevent modification at runtime. Signed-off-by: Thomas Weißschuh Signed-off-by: Rafael J. Wysocki --- drivers/acpi/cppc_acpi.c | 2 +- drivers/acpi/device_sysfs.c | 2 +- drivers/acpi/sysfs.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'drivers') diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 0f17b1c32718..a8f58b32d66f 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -193,7 +193,7 @@ static struct attribute *cppc_attrs[] = { }; ATTRIBUTE_GROUPS(cppc); -static struct kobj_type cppc_ktype = { +static const struct kobj_type cppc_ktype = { .sysfs_ops = &kobj_sysfs_ops, .default_groups = cppc_groups, }; diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c index 120873dad2cc..c3aa15571f16 100644 --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -78,7 +78,7 @@ static void acpi_data_node_release(struct kobject *kobj) complete(&dn->kobj_done); } -static struct kobj_type acpi_data_node_ktype = { +static const struct kobj_type acpi_data_node_ktype = { .sysfs_ops = &acpi_data_node_sysfs_ops, .default_groups = acpi_data_node_default_groups, .release = acpi_data_node_release, diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 7db3b530279b..7f4ff56c9d42 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -953,7 +953,7 @@ static struct attribute *hotplug_profile_attrs[] = { }; ATTRIBUTE_GROUPS(hotplug_profile); -static struct kobj_type acpi_hotplug_profile_ktype = { +static const struct kobj_type acpi_hotplug_profile_ktype = { .sysfs_ops = &kobj_sysfs_ops, .default_groups = hotplug_profile_groups, }; -- cgit