Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2136727imm; Sat, 28 Jul 2018 10:00:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeAcoeZW6jAD/5M26Zr+rem4wyMsUaosff5/bhb0PEkVeeNKaxtBpR1QeAGzjELRbNWZAwy X-Received: by 2002:a62:d94a:: with SMTP id s71-v6mr11213154pfg.164.1532797251591; Sat, 28 Jul 2018 10:00:51 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k185-v6si6607136pgd.15.2018.07.28.10.00.37; Sat, 28 Jul 2018 10:00:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@natalenko.name header.s=dkim-20170712 header.b=keeINCM+; arc=fail (signature failed); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=natalenko.name Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729438AbeG1S0X (ORCPT + 99 others); Sat, 28 Jul 2018 14:26:23 -0400 Received: from vulcan.natalenko.name ([104.207.131.136]:23828 "EHLO vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729371AbeG1S0X (ORCPT ); Sat, 28 Jul 2018 14:26:23 -0400 Received: from mail.natalenko.name (vulcan.natalenko.name [IPv6:fe80::5400:ff:fe0c:dfa0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vulcan.natalenko.name (Postfix) with ESMTPSA id D5E253BB990; Sat, 28 Jul 2018 18:59:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=dkim-20170712; t=1532797153; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references; bh=qzpRA97Bwpj4+xsajotANWY9Z2CGdurdb4hQWHhvubU=; b=keeINCM+KChf9Y70d4EnrZkBWORAgBwpCN1HffuFUsZPP6KGDzCIjz8wwIN1YAEATu/oeq oPjqdSGJvBzrWNi0okiBMfnD9zMHw2aptWDh4OH+J0wqsMjsJ3XwDXURwykb3F+NHpvf8q 5TO/8EQVFQJ7Id+l+G0nxY52Xui54N8= DMARC-Filter: OpenDMARC Filter v1.3.2 vulcan.natalenko.name D5E253BB990 Authentication-Results: vulcan.natalenko.name; dmarc=fail (p=none dis=none) header.from=natalenko.name MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 28 Jul 2018 18:59:12 +0200 From: Oleksandr Natalenko To: erik.schmauss@intel.com Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, rafael@kernel.org, torvalds@linux-foundation.org Subject: RE: [GIT PULL] ACPI fix for v4.18-rc7 In-Reply-To: Message-ID: X-Sender: oleksandr@natalenko.name User-Agent: Roundcube Webmail/1.3.6 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=arc-20170712; t=1532797153; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references; bh=qzpRA97Bwpj4+xsajotANWY9Z2CGdurdb4hQWHhvubU=; b=KCWR0oNcGcnk2gVXjgNH+SHNKL/7hJ9U2sCztRnHhPiGg66ttVBJTCOiOVDm4UdP2S9oGP R03eCVZBHEZRrPgk0gCBuPVHKJgSpponUIn0ILmDne2dpTvm9xQUI0BhbV27r/Iqmn9Cfo iFbFrvSScnb4bVA31/QIaHkcabtrufc= ARC-Seal: i=1; s=arc-20170712; d=natalenko.name; t=1532797153; a=rsa-sha256; cv=none; b=zWMSRoWo7/XuQ+6Fe1VzMTIsmW1rHtqdvQ9MZP1Mi9wTctouovMVRR2zlAmUMBwepHnOaDhEXE8FCIfiQ7QE66RJfeJk5ri76FgN8eBFiPm4zoRRRlBTu4zDRf8UkJHSTg3TC7NWwJ5F4+0HUU5G91jLYc0FybvEFSGly2cQcpI= ARC-Authentication-Results: i=1; vulcan.natalenko.name; auth=pass smtp.auth=oleksandr@natalenko.name smtp.mailfrom=oleksandr@natalenko.name Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi. > From a828a091828599154d8f6e8bfee1495a3df5cf34 Mon Sep 17 00:00:00 2001 > From: Erik Schmauss > Date: Fri, 27 Jul 2018 15:37:35 -0700 > From: Erik Schmauss > Subject: [PATCH 1] ACPICA: AML Parser: ignore control method status in > module-level code > > Previous change in the AML parser code blindly set all non-successful > dispatcher statuses to AE_OK. This approach is incorrect because > successful control method invocations from module-level return > AE_CTRL_TRANSFER. Overwriting AE_OK to this status causes the AML > parser to think that there was no return value from the control > method invocation. > > fixes: 73c2a01c52b6 (ACPICA: AML Parser: ignore dispatcher error status > during table load) > > Reported-by: Linus Torvalds > Signed-off-by: Erik Schmauss > --- > psloop.c | 19 ++++++++++++------- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff -Nurp linux.before_name/drivers/acpi/acpica/psloop.c > linux.after_name/drivers/acpi/acpica/psloop.c > --- linux.before_name/drivers/acpi/acpica/psloop.c 2018-07-27 > 15:53:31.073522915 -0700 > +++ linux.after_name/drivers/acpi/acpica/psloop.c 2018-07-27 > 15:53:25.320522527 -0700 > @@ -714,15 +714,20 @@ acpi_status acpi_ps_parse_loop(struct ac > } else > if ((walk_state-> > parse_flags & ACPI_PARSE_MODULE_LEVEL) > + && status != AE_CTRL_TRANSFER > && ACPI_FAILURE(status)) { > /* > - * ACPI_PARSE_MODULE_LEVEL means that we are loading a table by > - * executing it as a control method. However, if we encounter > - * an error while loading the table, we need to keep trying to > - * load the table rather than aborting the table load. Set the > - * status to AE_OK to proceed with the table load. If we get a > - * failure at this point, it means that the dispatcher got an > - * error while processing Op (most likely an AML operand error. > + * ACPI_PARSE_MODULE_LEVEL flag means that we are currently > + * loading a table by executing it as a control method. > + * However, if we encounter an error while loading the table, > + * we need to keep trying to load the table rather than > + * aborting the table load (setting the status to AE_OK > + * continues the table load). If we get a failure at this > + * point, it means that the dispatcher got an error while > + * processing Op (most likely an AML operand error) or a > + * control method was called from module level and the > + * dispatcher returned AE_CTRL_TRANSFER. In the latter case, > + * leave the status alone, there's nothing wrong with it. > */ > status = AE_OK; > } Faced the same on my Dell Vostro 3360 with v4.17.11 update, and confirming that this patch fixes the issue for me too. Thus, Tested-by: Oleksandr Natalenko Also, please Cc Greg once you do a submission, so v4.17 stable branch will be fixed too. Thanks. -- Oleksandr Natalenko (post-factum)