Skip to content

Commit bb203a6

Browse files
committed
ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()
The handling of _OSC errors in acpi_run_osc() is inconsistent and arguably not compliant with the _OSC definition (cf. Section 6.2.12 of ACPI 6.6 [1]). Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and any of the error bits are set in the _OSC return buffer, acpi_run_osc() returns an error code and the _OSC return buffer is discarded. However, in that case, depending on what error bits are set, the return buffer may contain acknowledged bits for features that need to be controlled by the kernel going forward. If the OSC_INVALID_UUID_ERROR bit is set, the request could not be processed at all and so in that particular case discarding the _OSC return buffer and returning an error is the right thing to do regardless of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer. If OSC_QUERY_ENABLE is set in the capabilities buffer and the OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the return buffer, acpi_run_osc() may return an error and discard the _OSC return buffer because in that case the platform configuration does not change. However, if any of them is set in the return buffer when OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature mask in the _OSC return buffer still represents a set of acknowleded features as per the _OSC definition: The platform acknowledges the Capabilities Buffer by returning a buffer of DWORDs of the same length. Set bits indicate acknowledgment that OSPM may take control of the capability and cleared bits indicate that the platform either does not support the capability or that OSPM may not assume control. which is not conditional on the error bits being clear, so in that case, discarding the _OSC return buffer is questionable. There is also no reason to return an error and discard the _OSC return buffer if the OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic messages is appropriate when that happens with OSC_QUERY_ENABLE clear in the capabilities buffer. Adress this issue by making acpi_run_osc() follow the rules outlined above. Moreover, make acpi_run_osc() only take the defined _OSC error bits into account when checking _OSC errors. Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> [ rjw: Corrected typo in the changelog ] Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
1 parent dd2fc7b commit bb203a6

1 file changed

Lines changed: 38 additions & 14 deletions

File tree

drivers/acpi/bus.c

Lines changed: 38 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -194,14 +194,18 @@ static void acpi_print_osc_error(acpi_handle handle,
194194
pr_debug("\n");
195195
}
196196

197+
#define OSC_ERROR_MASK (OSC_REQUEST_ERROR | OSC_INVALID_UUID_ERROR | \
198+
OSC_INVALID_REVISION_ERROR | \
199+
OSC_CAPABILITIES_MASK_ERROR)
200+
197201
acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
198202
{
203+
u32 errors, *capbuf = context->cap.pointer;
199204
acpi_status status;
200205
struct acpi_object_list input;
201206
union acpi_object in_params[4];
202207
union acpi_object *out_obj;
203208
guid_t guid;
204-
u32 errors;
205209
struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
206210

207211
if (!context)
@@ -240,29 +244,49 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context)
240244
status = AE_TYPE;
241245
goto out_kfree;
242246
}
243-
/* Need to ignore the bit0 in result code */
244-
errors = *((u32 *)out_obj->buffer.pointer) & ~(1 << 0);
247+
/* Only take defined error bits into account. */
248+
errors = *((u32 *)out_obj->buffer.pointer) & OSC_ERROR_MASK;
249+
/*
250+
* If OSC_QUERY_ENABLE is set, ignore the "capabilities masked"
251+
* bit because it merely means that some features have not been
252+
* acknowledged which is not unexpected.
253+
*/
254+
if (capbuf[OSC_QUERY_DWORD] & OSC_QUERY_ENABLE)
255+
errors &= ~OSC_CAPABILITIES_MASK_ERROR;
256+
245257
if (errors) {
258+
/*
259+
* As a rule, fail only if OSC_QUERY_ENABLE is set because
260+
* otherwise the acknowledged features need to be controlled.
261+
*/
262+
bool fail = !!(capbuf[OSC_QUERY_DWORD] & OSC_QUERY_ENABLE);
263+
264+
if (errors & OSC_INVALID_UUID_ERROR) {
265+
acpi_print_osc_error(handle, context,
266+
"_OSC invalid UUID");
267+
/*
268+
* Always fail if this bit is set because it means that
269+
* the request could not be processed.
270+
*/
271+
fail = true;
272+
goto out_kfree;
273+
}
246274
if (errors & OSC_REQUEST_ERROR)
247275
acpi_print_osc_error(handle, context,
248276
"_OSC request failed");
249-
if (errors & OSC_INVALID_UUID_ERROR)
250-
acpi_print_osc_error(handle, context,
251-
"_OSC invalid UUID");
252277
if (errors & OSC_INVALID_REVISION_ERROR)
253278
acpi_print_osc_error(handle, context,
254279
"_OSC invalid revision");
255-
if (errors & OSC_CAPABILITIES_MASK_ERROR) {
256-
if (((u32 *)context->cap.pointer)[OSC_QUERY_DWORD]
257-
& OSC_QUERY_ENABLE)
258-
goto out_success;
259-
status = AE_SUPPORT;
280+
if (errors & OSC_CAPABILITIES_MASK_ERROR)
281+
acpi_print_osc_error(handle, context,
282+
"_OSC capability bits masked");
283+
284+
if (fail) {
285+
status = AE_ERROR;
260286
goto out_kfree;
261287
}
262-
status = AE_ERROR;
263-
goto out_kfree;
264288
}
265-
out_success:
289+
266290
context->ret.length = out_obj->buffer.length;
267291
context->ret.pointer = kmemdup(out_obj->buffer.pointer,
268292
context->ret.length, GFP_KERNEL);

0 commit comments

Comments
 (0)