From patchwork Sat Oct 22 07:21:10 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 7228 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1090574wrr; Sat, 22 Oct 2022 00:47:36 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5Gt0X2Z0KR0eXiwDR22Og6pn9Ys+0v5BZjkq8XqsKgX1wIm8qY+J0tCbWggYjYVRjwU3Bs X-Received: by 2002:a63:2212:0:b0:43b:f03d:856a with SMTP id i18-20020a632212000000b0043bf03d856amr19606799pgi.192.1666424855829; Sat, 22 Oct 2022 00:47:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666424855; cv=none; d=google.com; s=arc-20160816; b=kbYVe9QW3Jo4NPsVJ7sjTSaOjc0kLNrlziNS+9m6OYujGd8FAvTpfq1QyTxavhJeWS RSeUBdfUJKpd+fKGXdjo4ZbdMD0rdthdjWQq6C2Z/06QjywY0cVK38AqVkR36aWvfZQ3 x9XcQ6M0AQ4839hJVQa03zqsdvTWpskdm33mnR+4c/Z6JjWb/ByQgnyxs+eubsD1V/h4 ffBaamsyhOP2wMaGShcQR0OHmXAqHHsLMrakJU8BaPNfy7S3RN0KPkgx5NKZdReKcibm vLO0BRaGsBnvvyXQd3dpufvPX0+lELVo9/3Y8nGloUn29ieWtkbj7hLYDDGfogoiVH7p Qw+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=G0xMA3E5pvJoByC07Ve/JswS6SYCKYAdI0wOjruq/9U=; b=hJwnwBVXQYc8sraUKix0NLt9UMNHSm5z7Ftn3w3Eu7Bj/R0FgJCPT0COG+Wr+VFkTZ ECqlEw7oclNpMUOJZvy3rfeO36s6VngXR6qVt73S7FZ7FwZNDGXp3yQlq6Da3Ssd0xlt Kc5JRtJhocdtxPVcfA4L8Nu3Tdcjdv3pYLWdKjC5+A/k7VNMwC1lt5PYyEngpU3jGhNK N0fWp7uHGGBfXRsnkJHGRpk9VD+doy9vS+xWKrNeZbrWofV/nSDsZz+ABIJuBO44T+ts GGlv8h5YLUsDAv2ZDqLnyEuDRVzOASaM7+HKZ343s5ee3l4ZYvxtiMIKnb/SkybGtX85 EZRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NfBsqYQb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w2-20020a170902904200b00183a85a9b54si25579245plz.279.2022.10.22.00.47.23; Sat, 22 Oct 2022 00:47:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=NfBsqYQb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231156AbiJVHrA (ORCPT + 99 others); Sat, 22 Oct 2022 03:47:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231631AbiJVHop (ORCPT ); Sat, 22 Oct 2022 03:44:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E696859EA4; Sat, 22 Oct 2022 00:43:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8BB18B82E19; Sat, 22 Oct 2022 07:42:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 002A7C433C1; Sat, 22 Oct 2022 07:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666424560; bh=2PDkRAInx+5qdYpVRI+2RTNMv7awcytT6P1oXVUQ3zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NfBsqYQb2/M3ES38czFoOsk7T1CH+5IfZjOlCvQHCZMmo7+FDaTHSqRYplithjnUG Khj/UI+tiPOs49yOlQyQHsXGtYWaxT6m3EwyozgIrTp4eDm9TBpNKO/sOBzR+VgsT3 cMIVP1qNK3E6XVoQf3JdNSQxYN9nA2xAW+90uK+I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Huisong Li , Sudeep Holla , "Rafael J. Wysocki" , Sasha Levin Subject: [PATCH 5.19 191/717] ACPI: PCC: replace wait_for_completion() Date: Sat, 22 Oct 2022 09:21:10 +0200 Message-Id: <20221022072449.415628006@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747373109580472991?= X-GMAIL-MSGID: =?utf-8?q?1747373109580472991?= From: Huisong Li [ Upstream commit 91cefefb699120efd0a5ba345d12626b688f86ce ] Currently, the function waiting for completion of mailbox operation is 'wait_for_completion()'. The PCC method will be permanently blocked if this mailbox message fails to execute. So this patch replaces it with 'wait_for_completion_timeout()'. And set the timeout interval to an arbitrary retries on top of nominal to prevent the remote processor is slow to respond to PCC commands. Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Signed-off-by: Huisong Li Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin --- drivers/acpi/acpi_pcc.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c index 84f1ac416b57..16ba875e3293 100644 --- a/drivers/acpi/acpi_pcc.c +++ b/drivers/acpi/acpi_pcc.c @@ -23,6 +23,12 @@ #include +/* + * Arbitrary retries in case the remote processor is slow to respond + * to PCC commands + */ +#define PCC_CMD_WAIT_RETRIES_NUM 500 + struct pcc_data { struct pcc_mbox_chan *pcc_chan; void __iomem *pcc_comm_addr; @@ -89,6 +95,7 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, { int ret; struct pcc_data *data = region_context; + u64 usecs_lat; reinit_completion(&data->done); @@ -99,8 +106,20 @@ acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr, if (ret < 0) return AE_ERROR; - if (data->pcc_chan->mchan->mbox->txdone_irq) - wait_for_completion(&data->done); + if (data->pcc_chan->mchan->mbox->txdone_irq) { + /* + * pcc_chan->latency is just a Nominal value. In reality the remote + * processor could be much slower to reply. So add an arbitrary + * amount of wait on top of Nominal. + */ + usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency; + ret = wait_for_completion_timeout(&data->done, + usecs_to_jiffies(usecs_lat)); + if (ret == 0) { + pr_err("PCC command executed timeout!\n"); + return AE_TIME; + } + } mbox_client_txdone(data->pcc_chan->mchan, ret);