From patchwork Thu Mar 14 14:24:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maximilian Luz X-Patchwork-Id: 10853017 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4DD716C2 for ; Thu, 14 Mar 2019 14:24:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 338D029F99 for ; Thu, 14 Mar 2019 14:24:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 276232A08F; Thu, 14 Mar 2019 14:24:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A405129F99 for ; Thu, 14 Mar 2019 14:24:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727572AbfCNOYJ (ORCPT ); Thu, 14 Mar 2019 10:24:09 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:50667 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727566AbfCNOYI (ORCPT ); Thu, 14 Mar 2019 10:24:08 -0400 Received: by mail-wm1-f68.google.com with SMTP id x7so3228335wmj.0 for ; Thu, 14 Mar 2019 07:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=pNYpQMdxnANcZjd3PvsxFk0LAE09n1ISO9apj+ke3m4=; b=A2/bYoIj5ehnwpurDTShGmBhVWghreeCwWY17XHRhJd/u0s7Pm5K8JthEU0YZXwHl3 gwUkjpUmOvFuTRZFUbPw/wAxMWpuiEtx0Ra2I0WDfGobkgL8/11T4xK546AT72PBkkCf LBdiEoF9WyZP8rnUCFY6abGthoZBTtMdQ6iOSkS6KNh5FqhP7+/fUtPlwye+HrnejZEX sTJTuaUzmjLewAooCTQD/5BcCweUiHW6XXQgH9+DGDxl3luzo3JMR5mrAoc/BXNt/suz l2WMt1CrERp9o8Bbu9Sfm8Vpru9VW8AhUaEEgmx7KQGqBQL7rn9kBttgdKonSbm7PCER Lu6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=pNYpQMdxnANcZjd3PvsxFk0LAE09n1ISO9apj+ke3m4=; b=cUQysz9n++NwRAR/8hs7+J0x1cVbHavTn7KwEZCpvJokCMBbNqMGt4QCYefDIIKIQH /Dcw2n6Qzg6SeIebsWLsDQ1AQeqJ7XmH1jITyN62qbBsEaOdhJ6pxWsx0fQeU7u8m6Ye ReS8gkInjBe6BElzko3gewGzoZXigEnH6wNidt8o9rYBo0N7t5z5b1otOV0zVtukXN6b 9XMHYwKC8JN1x9kNC1MJ2PNBE9bQXuv+vUeCHfPpFDwHRSAEDCcVc7PiWNFCcUlK5xj6 B26SYrA4sL4JXYgct3Wo4bP2/QgKeYdeYm9so2QaufU2qwa+AVuRewKxITUpHrte9V5m QAcQ== X-Gm-Message-State: APjAAAUyUozjciJic+ExjiLMsE5hu3Szt60cEoKteevxVQDjDNKHq8wr mDSRuQHFQqVy1FST2i1XPFvRNOE6 X-Google-Smtp-Source: APXvYqxKaneyuJq/lVajzy1lJKI1hqN0yxz5115iJPd6IKzZ3KDOouzbdCQOIjya4Vt4x5eI52MyUA== X-Received: by 2002:a1c:cecd:: with SMTP id e196mr2883792wmg.31.1552573446802; Thu, 14 Mar 2019 07:24:06 -0700 (PDT) Received: from [192.168.2.202] (pD9E5A36D.dip0.t-ipconnect.de. [217.229.163.109]) by smtp.gmail.com with ESMTPSA id f191sm5173390wmg.41.2019.03.14.07.24.05 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 07:24:06 -0700 (PDT) To: Robert Moore , Erik Schmauss , "Rafael J. Wysocki" Cc: linux-acpi@vger.kernel.org, devel@acpica.org From: Maximilian Luz Subject: PROBLEM: Calling ObjectType on buffer field reports type integer Message-ID: <3ef42aa1-196d-f3db-0e5d-2fd84c198242@gmail.com> Date: Thu, 14 Mar 2019 15:24:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, it seems that buffer fields (created via CreateField) are incorrectly reported as being of type integer (via ObjectType) when they are small enough to allow for that. As far as I know all kernel versions are affected by this, I have specifically checked 5.0 (5.0.2), 4.20, 4.19 and 4.18. In more detail: On the Microsoft Surface Book 2, Surface Pro (2017), Surface Pro 6, Surface Laptop and Surface Laptop 2 devices there is the following piece of AML code: Local0 = ^^_SAN.RQST (0x02, One, One, Zero, One) If ((ObjectType (Local0) != 0x03)) { // Error path } Else { // Success path } Which executes a command (RQST) and then checks the type of the returned field to determine if that command was successful (i.e. returned a buffer object) or failed (i.e. returned any other type, including integer). The buffer field that is being returned by RQST is crated as follows: CreateField (RQBF, 0x20, Local3, ARB) Local4 = ARB /* \_SB_._SAN.RQSX.ARB_ */ ... Return (Local4) If the returned buffer field is small enough (smaller than acpi_gbl_integer_byte_width), the error-path will always be executed. The full DSDT for the Surface Book 2 can be found here: https://github.com/qzed/surfacebook2-dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L15396 I have attached a patch (for 5.0) that fixes this issue and has been in use on the affected devices for a few months now via https://github.com/qzed/linux-surfacegen5-acpi and https://github.com/jakeday/linux-surface/ I'm not aware of any issues regarding the patch, but then again this has, to my knowledge, only been tested on Microsoft Surface devices. Maximilian Signed-off-by: Maximilian Luz Reported-by: Maximilian Luz Signed-off-by: Erik Schmauss --- drivers/acpi/acpica/dsopcode.c | 2 +- drivers/acpi/acpica/exfield.c | 12 +++++++++--- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c index 78f9de260d5f..0cd858520f5b 100644 --- a/drivers/acpi/acpica/dsopcode.c +++ b/drivers/acpi/acpica/dsopcode.c @@ -123,7 +123,7 @@ acpi_ds_init_buffer_field(u16 aml_opcode, /* Offset is in bits, count is in bits */ - field_flags = AML_FIELD_ACCESS_BYTE; + field_flags = AML_FIELD_ACCESS_BUFFER; bit_offset = offset; bit_count = (u32) length_desc->integer.value; diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c index e5798f15793a..55abd9e035a0 100644 --- a/drivers/acpi/acpica/exfield.c +++ b/drivers/acpi/acpica/exfield.c @@ -98,6 +98,7 @@ acpi_ex_read_data_from_field(struct acpi_walk_state *walk_state, union acpi_operand_object *buffer_desc; void *buffer; u32 buffer_length; + u8 field_flags; ACPI_FUNCTION_TRACE_PTR(ex_read_data_from_field, obj_desc); @@ -146,11 +147,16 @@ acpi_ex_read_data_from_field(struct acpi_walk_state *walk_state, * Note: Field.length is in bits. */ buffer_length = - (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc->field.bit_length); + (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc->common_field.bit_length); + field_flags = obj_desc->common_field.field_flags; - if (buffer_length > acpi_gbl_integer_byte_width) { + if (buffer_length > acpi_gbl_integer_byte_width || + (field_flags & AML_FIELD_ACCESS_TYPE_MASK) == AML_FIELD_ACCESS_BUFFER) { - /* Field is too large for an Integer, create a Buffer instead */ + /* + * Field is either too large for an Integer, or a actually of type + * buffer, so create a Buffer. + */ buffer_desc = acpi_ut_create_buffer_object(buffer_length); if (!buffer_desc) {