From nobody Fri Dec 19 19:15:42 2025 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 E87FFC83F14 for ; Thu, 31 Aug 2023 01:14:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345522AbjHaBOU (ORCPT ); Wed, 30 Aug 2023 21:14:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345504AbjHaBOR (ORCPT ); Wed, 30 Aug 2023 21:14:17 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A893CE8 for ; Wed, 30 Aug 2023 18:14:10 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1c0c6d4d650so2177535ad.0 for ; Wed, 30 Aug 2023 18:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1693444450; x=1694049250; 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=Evb7/BN7ItVli8O1MCLcSe5YscQaq6FblNFUqza6B98=; b=XRUgTPyN2NE22JnmgQAaVgbzPgd0oJ2+K5S26+wWwAlMgA9PNGZFbGFy1ucyV36ENm 1dVCwOgf7TutnTKhf2XFcADN3lCVWcLA4DC3ZovtJqFq+DENxAq+q5aHoFCz+UQpECw9 rlUVgS3/9X2p04C8YAZKp3+lMZzatbRyxx7aE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693444450; x=1694049250; 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=Evb7/BN7ItVli8O1MCLcSe5YscQaq6FblNFUqza6B98=; b=U/kqijmI9w3cqIp1aMTpEq3HfQ+HTXGwvMiHT/HwDWMumV4RkqOfAE4r1mmJ0e0uXq VpIs7xsAjuvtK2vtJDyfF1goZMwrj6eScPI4hrNCnlRhi4fZrQiLEOR0OLxfQ8RnJHHs c0lxquvZmop4eVmGdmYI3cwJrs3SlS1nAi3pve0FdG/k9FuCs5G69kf21hZbOpPUxSGN IVoCY0R+CLkmWWftkLrqQwsU2uEKwJcABH+BVud8HjLTcbrUpKRlnmXucgmtSTOalO6n Xqym3Xy1Ovd1CDatH6u3zY8reTiSPnV36n+qfO0ufcBcfRPVLbxb86E707uwAhbksXH/ hYDQ== X-Gm-Message-State: AOJu0Yz78AObmha/IYi3TzTeAZgEc6csoOlGN7jBYc727aiPuuiGUHR4 o7wHqzcSFsQXC77mSP7pRaSB1Q== X-Google-Smtp-Source: AGHT+IFYusCNVLK7C29ZkzYj1eGJCKZt8+lyPCyvbxdXZnw6xYC4O8RV0ZX9Jg5wTDXLG27eEM/K/Q== X-Received: by 2002:a17:902:db0c:b0:1b9:e81f:fb08 with SMTP id m12-20020a170902db0c00b001b9e81ffb08mr4163642plx.55.1693444449861; Wed, 30 Aug 2023 18:14:09 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:248f:d364:b451:2bc0]) by smtp.gmail.com with ESMTPSA id im23-20020a170902bb1700b001bbb7af4963sm132604plb.68.2023.08.30.18.14.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Aug 2023 18:14:09 -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 2/3] platform/x86: intel_scu_ipc: Check status upon timeout in ipc_wait_for_interrupt() Date: Wed, 30 Aug 2023 18:14:02 -0700 Message-ID: <20230831011405.3246849-3-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.rc2.253.gd59a3bf2b4-goog In-Reply-To: <20230831011405.3246849-1-swboyd@chromium.org> References: <20230831011405.3246849-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_BUSY]=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_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 Cc: Kuppuswamy Sathyanarayanan Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd Reviewed-by: Andy Shevchenko Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Mika Westerberg --- drivers/platform/x86/intel_scu_ipc.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/in= tel_scu_ipc.c index 5a37becc65aa..2a21153e3bf3 100644 --- a/drivers/platform/x86/intel_scu_ipc.c +++ b/drivers/platform/x86/intel_scu_ipc.c @@ -246,16 +246,19 @@ static inline int busy_loop(struct intel_scu_ipc_dev = *scu) /* Wait till ipc ioc interrupt is received or timeout in 10 HZ */ static inline int ipc_wait_for_interrupt(struct intel_scu_ipc_dev *scu) { - int status; + unsigned long time_left; + u8 status; + int err =3D 0; =20 - if (!wait_for_completion_timeout(&scu->cmd_complete, IPC_TIMEOUT)) - return -ETIMEDOUT; + time_left =3D wait_for_completion_timeout(&scu->cmd_complete, IPC_TIMEOUT= ); + if (!time_left) + err =3D -ETIMEDOUT; =20 status =3D ipc_read_status(scu); - if (status & IPC_STATUS_ERR) - return -EIO; + if (!(status & IPC_STATUS_BUSY)) + err =3D (status & IPC_STATUS_ERR) ? -EIO : 0; =20 - return 0; + return err; } =20 static int intel_scu_ipc_check_status(struct intel_scu_ipc_dev *scu) --=20 https://chromeos.dev