From nobody Wed Feb 11 20:05:58 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 111ECCA0EC3 for ; Mon, 11 Sep 2023 23:02:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349767AbjIKVer (ORCPT ); Mon, 11 Sep 2023 17:34:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244219AbjIKTjs (ORCPT ); Mon, 11 Sep 2023 15:39:48 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 055CC18D for ; Mon, 11 Sep 2023 12:39:44 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-273e1aec35aso2141848a91.1 for ; Mon, 11 Sep 2023 12:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1694461183; x=1695065983; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kZYrHnobXTh0OSmcxOutmTVdFw75ZwDUd6CgfQDQ3MU=; b=jkpQtQkf9CmjnLo2qkfbo+ma1IvYZZrIkQVDU8FeE0rGYwCLnaZ2QYzS8PTcjwpEkk 1pVi5tfGDk1WtalnGLnTbYe/2N+3rHKrQd4u/ghEXLcE1/AyKTwPwD/R3JOjTOc77lcQ YWZPU8SZpMWz3iF+GZsj9IikXLe19fEeZYRiI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694461183; x=1695065983; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kZYrHnobXTh0OSmcxOutmTVdFw75ZwDUd6CgfQDQ3MU=; b=mRQBFfvHlOV6ln8I1RLR4qF8cM0Ub0sGMZUvzfz1AwkuigM7pNoDZBytXg+ncIbHkb r/X8n8/dJwvu8tdC2tpEdrU/kCwXbufEBvLJKJV6/sgiewpVMVjkkZ59fPnHD1mANxtA 2Z1c92Aw+j1QnVn8Cs5Znsg/TFpvUUS+xzPMwXAXkaK1TToeONmFvy5JIpEXSeFQwiw1 l4RyiorISez3h25Nq/r22xOLsCRqZ+pipmmwAJvcmuXpPU28s/nS/JRqzo7I66+BHTYm maaYdEPaX8HkfqlMDx31Vdb/rS5SAOpUIak7cER8pUXlbmUOink9e4brqo4x1OVh3axf 0PXQ== X-Gm-Message-State: AOJu0Yx8mZ/+SRIRtN3WnR73DKccGblT1IMxSgHbP4LlTFdnEU9tq9FL NUupDyzSf/JMSdRb6DIUKU5PmQ== X-Google-Smtp-Source: AGHT+IGOfdGvbw1wwt4Gf9ldbs/gHOpAtrlGyNreNjdfdz8lCBCPYU+3AOX6Bw9QrL5rSH9U2KMdvA== X-Received: by 2002:a17:90a:3481:b0:268:557e:1848 with SMTP id p1-20020a17090a348100b00268557e1848mr8154453pjb.2.1694461183460; Mon, 11 Sep 2023 12:39:43 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:d487:5e33:6656:3711]) by smtp.gmail.com with ESMTPSA id fu8-20020a17090ad18800b00262e485156esm7736543pjb.57.2023.09.11.12.39.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 12:39:42 -0700 (PDT) From: Stephen Boyd To: Mika Westerberg , Hans de Goede , Mark Gross Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, platform-driver-x86@vger.kernel.org, Andy Shevchenko , Kuppuswamy Sathyanarayanan , Prashant Malani Subject: [PATCH v3 2/4] platform/x86: intel_scu_ipc: Check status upon timeout in ipc_wait_for_interrupt() Date: Mon, 11 Sep 2023 12:39:34 -0700 Message-ID: <20230911193937.302552-3-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.283.g2d96d420d3-goog In-Reply-To: <20230911193937.302552-1-swboyd@chromium.org> References: <20230911193937.302552-1-swboyd@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" It's possible for the completion in ipc_wait_for_interrupt() to timeout, simply because the interrupt was delayed in being processed. A timeout in itself is not an error. This driver should check the status register upon a timeout to ensure that scheduling or interrupt processing delays don't affect the outcome of the IPC return value. CPU0 SCU ---- --- ipc_wait_for_interrupt() wait_for_completion_timeout(&scu->cmd_complete) [TIMEOUT] status[IPC_STATUS_B= USY]=3D0 Fix this problem by reading the status bit in all cases, regardless of the timeout. If the completion times out, we'll assume the problem was that the IPC_STATUS_BUSY bit was still set, but if the status bit is cleared in the meantime we know that we hit some scheduling delay and we should just check the error bit. Cc: Prashant Malani Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Andy Shevchenko Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd Reviewed-by: Mika Westerberg --- drivers/platform/x86/intel_scu_ipc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/in= tel_scu_ipc.c index 5a37becc65aa..8be1686e22e9 100644 --- a/drivers/platform/x86/intel_scu_ipc.c +++ b/drivers/platform/x86/intel_scu_ipc.c @@ -248,10 +248,12 @@ static inline int ipc_wait_for_interrupt(struct intel= _scu_ipc_dev *scu) { int status; =20 - if (!wait_for_completion_timeout(&scu->cmd_complete, IPC_TIMEOUT)) - return -ETIMEDOUT; + wait_for_completion_timeout(&scu->cmd_complete, IPC_TIMEOUT); =20 status =3D ipc_read_status(scu); + if (status & IPC_STATUS_BUSY) + return -ETIMEDOUT; + if (status & IPC_STATUS_ERR) return -EIO; =20 --=20 https://chromeos.dev