From nobody Fri Dec 19 09:50:27 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 29EB7EE14CA for ; Wed, 6 Sep 2023 18:09:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243727AbjIFSJx (ORCPT ); Wed, 6 Sep 2023 14:09:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229644AbjIFSJv (ORCPT ); Wed, 6 Sep 2023 14:09:51 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 476B7CE9 for ; Wed, 6 Sep 2023 11:09:48 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1c1f8aaab9aso777065ad.1 for ; Wed, 06 Sep 2023 11:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1694023788; x=1694628588; 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=nQ60R3rHW7RtCo/8VNaTl4hpFxxt5nZxG1tJ6/+yqfY=; b=mYSBO9Gyi+XIhlh03NXl4t4gMDxP84oFLJWwtaLxcqrPQ9zhnS+VKSwZGUFjWNESd1 pMYKwV7v+L/3xO3WrSkS6Rnq5Odwz1aqSo2NFFT7W8i18/ZXxq6cLNRo9kcXlZvPkOlL ZMI2/aDP3+DR7wx8HsMgxFCF+47GR4sADyO2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694023788; x=1694628588; 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=nQ60R3rHW7RtCo/8VNaTl4hpFxxt5nZxG1tJ6/+yqfY=; b=VJMP2j2Yt+pWK+juSMhuGttru/3gm28syEiPRHrZbLA9y7KiCGJrBfZuTu4iz0ZRjm zV7hDZaGmEojM5shwkq5LlS4XXCiv7xGkKP2npiyPKAeVdAtdcTSSR6YpiVdnkJ8lGeH jfxL2MvfpUvMPQIvWEeNnUGNCxFYPCXHlSl/N7RokF8gQ+UKfoQMyPS5kf/6oXAtu5OB w5IxRzE6U1H7L/9QT0M5KaIA51VVTOBi+V+z+O6qQiMtQjWREhSTSWlDIS1PvwGlyFRW G+aG9VqOjUkuqP5yT7KylVSdnaKIKCKsp1LVy/DZh1yjIFiCfRThEnXFdyvX1uAfcjRk ++BA== X-Gm-Message-State: AOJu0YzY6AicaBlJYvrv7H5J+oNrtMGMxLrYXjciLsU4FKrsp6suodPP QnVW3gnPO/Nl52Ghpv733gGi6A== X-Google-Smtp-Source: AGHT+IFTy5AW0hEg/3ypp2wUfruRPqHHSv6/9h119PwBpNp6mPHXIi/XqQfMzExiQ7wVnyux07tFkA== X-Received: by 2002:a17:903:24c:b0:1bc:2d43:c747 with SMTP id j12-20020a170903024c00b001bc2d43c747mr20299220plh.38.1694023787823; Wed, 06 Sep 2023 11:09:47 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:a404:ed4a:5a1e:3b4a]) by smtp.gmail.com with ESMTPSA id ix5-20020a170902f80500b001bc675068e2sm11363996plb.111.2023.09.06.11.09.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 11:09:47 -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 v2 1/3] platform/x86: intel_scu_ipc: Check status after timeout in busy_loop() Date: Wed, 6 Sep 2023 11:09:41 -0700 Message-ID: <20230906180944.2197111-2-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.283.g2d96d420d3-goog In-Reply-To: <20230906180944.2197111-1-swboyd@chromium.org> References: <20230906180944.2197111-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 polling loop in busy_loop() to get scheduled away for a long time. status =3D ipc_read_status(scu); // status =3D IPC_STATUS_BUSY if (!(status & IPC_STATUS_BUSY)) If this happens, then the status bit could change while the task is scheduled away and this function would never read the status again after timing out. Instead, the function will return -ETIMEDOUT when it's possible that scheduling didn't work out and the status bit was cleared. Bit polling code should always check the bit being polled one more time after the timeout in case this happens. Fix this by reading the status once more after the while loop breaks. Cc: Prashant Malani Cc: Andy Shevchenko Fixes: e7b7ab3847c9 ("platform/x86: intel_scu_ipc: Sleeping is fine when po= lling") Signed-off-by: Stephen Boyd --- This is sufficiently busy so I didn't add any tags from previous round. drivers/platform/x86/intel_scu_ipc.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/in= tel_scu_ipc.c index 6851d10d6582..b2a2de22b8ff 100644 --- a/drivers/platform/x86/intel_scu_ipc.c +++ b/drivers/platform/x86/intel_scu_ipc.c @@ -232,18 +232,21 @@ static inline u32 ipc_data_readl(struct intel_scu_ipc= _dev *scu, u32 offset) static inline int busy_loop(struct intel_scu_ipc_dev *scu) { unsigned long end =3D jiffies + IPC_TIMEOUT; + u32 status; =20 do { - u32 status; - status =3D ipc_read_status(scu); if (!(status & IPC_STATUS_BUSY)) - return (status & IPC_STATUS_ERR) ? -EIO : 0; + goto not_busy; =20 usleep_range(50, 100); } while (time_before(jiffies, end)); =20 - return -ETIMEDOUT; + status =3D ipc_read_status(scu); + if (status & IPC_STATUS_BUSY) + return -ETIMEDOUT; +not_busy: + return (status & IPC_STATUS_ERR) ? -EIO : 0; } =20 /* Wait till ipc ioc interrupt is received or timeout in 10 HZ */ --=20 https://chromeos.dev From nobody Fri Dec 19 09:50:27 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 4A512EE14C5 for ; Wed, 6 Sep 2023 18:09:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243736AbjIFSJ6 (ORCPT ); Wed, 6 Sep 2023 14:09:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243729AbjIFSJx (ORCPT ); Wed, 6 Sep 2023 14:09:53 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 954D9E6A for ; Wed, 6 Sep 2023 11:09:49 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1c1ff5b741cso742755ad.2 for ; Wed, 06 Sep 2023 11:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1694023789; x=1694628589; 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=6I+Tnbz1nPfP3u0q6UcUVaPekp7QP+Ha1f/com8FTBk=; b=KU6slOIMNYgrSH9j0tddSytckjy/8kTargkaEaPHL5/sh/+ZDGgarv/M5UMGuMBIBm NQHzjHUg/q+VezaF/PaGPB6rl+lW5tPVvDeb7yNWWbtL0aAiiLJmbdv9YhyDQSd5hJsA TsqKlNbYZ9LbsS5OkYS9kFp+lfVC5uMAUqk/0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694023789; x=1694628589; 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=6I+Tnbz1nPfP3u0q6UcUVaPekp7QP+Ha1f/com8FTBk=; b=Vt1uLlcaQeAbqk1pUYU20bB3uhiJWd/ezD7yO5UueZ1zpvdaTWqoW07HeoHpb4jhhq fUAbmOiPF6/mkoW14yUrx4tj6wqv6EdoUtvKc1FP41zNEYBmJbUF14cj4TT6QfkDXRhS HwKcgX7ry40S2XAW9OR8AYBtEc+3S4Om/fd44G2jZGtCS8hUwWZ74zdT6Bws9UJ3lici 8CAQwvdzNyoNPWieINyBnKbX9O/OnW85CKhAeoUXy7v4RbuPhyzXzPwlTa2m8ZJU/Ko0 OJz8zLzumbJE1NwWfctQoKtDi0QMzqsEx3nVcX8ZPyifPRe5y6L2cEeYlqUjOnyE1Nli FXDg== X-Gm-Message-State: AOJu0YzXOZX0+8XRx6xeHw9ALiqPBJkXyZmkxkOIMebFdrNY3mwE8h1O EHYuDp4gVpq58vmb5F2qFWkLiA== X-Google-Smtp-Source: AGHT+IF5QfGMo/sdxsUVNrZNDBPSiLKBWoNHf8pn6Nyc2pLXvbO3iCoWpR8ZwyEMaWKmKkYHkX0yew== X-Received: by 2002:a17:902:d504:b0:1c0:ec66:f2b5 with SMTP id b4-20020a170902d50400b001c0ec66f2b5mr20873803plg.57.1694023789107; Wed, 06 Sep 2023 11:09:49 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:a404:ed4a:5a1e:3b4a]) by smtp.gmail.com with ESMTPSA id ix5-20020a170902f80500b001bc675068e2sm11363996plb.111.2023.09.06.11.09.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 11:09:48 -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 v2 2/3] platform/x86: intel_scu_ipc: Check status upon timeout in ipc_wait_for_interrupt() Date: Wed, 6 Sep 2023 11:09:42 -0700 Message-ID: <20230906180944.2197111-3-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.283.g2d96d420d3-goog In-Reply-To: <20230906180944.2197111-1-swboyd@chromium.org> References: <20230906180944.2197111-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 Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd Reviewed-by: Andy Shevchenko --- 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 b2a2de22b8ff..3cea701d2bbd 100644 --- a/drivers/platform/x86/intel_scu_ipc.c +++ b/drivers/platform/x86/intel_scu_ipc.c @@ -254,10 +254,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 From nobody Fri Dec 19 09:50:27 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 37695EE14C9 for ; Wed, 6 Sep 2023 18:09:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243753AbjIFSJ7 (ORCPT ); Wed, 6 Sep 2023 14:09:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239230AbjIFSJy (ORCPT ); Wed, 6 Sep 2023 14:09:54 -0400 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C51F31700 for ; Wed, 6 Sep 2023 11:09:50 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-53fbf2c42bfso128421a12.3 for ; Wed, 06 Sep 2023 11:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1694023790; x=1694628590; 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=4wi6bhruWz0hbXHukGopFEWiMps+cu8JOpx7s5KKUhM=; b=hYau4/nUz5iYqd5W7Lj14r5dMlAYeqsITBKXdHZLNSG+82MGmLXvcE+458iJ+JH7oi aoU+66bn6yw+JaPcXej1plpvtQaTLUI3sW/sIpuO6gjXM02xmiuJaqwWfUqMHI45GQZd fM4MgOHCXVOBcHjG02SBO+erWI7DAr1QLyxTM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694023790; x=1694628590; 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=4wi6bhruWz0hbXHukGopFEWiMps+cu8JOpx7s5KKUhM=; b=eh/DJaT5Wn3UROcAXq+hM+LL7MZ89q9pJtjgLFobsrsvAMdNg5QJmZaemBHI0kYVQh YMiGHbU95NE9svZFOrSKMyGJbbRnrS5xzXoMB/5LPOw1cUK7Tqul/z4NB7/zjA346VYg qbLcdED/21gBMWP2eGbd2Ra5xZk+omEzST83RVsgcyjXs6QwzXGUIeKMIyMc3h7C/lyo A/WK639gP7hEQ0Kv77U/IGmYHL0YvGtRiFJ3QZmJVbin65JcU1PQ9Fr6PuxMgfhhFxt+ zQXxMxjRqx2j6XkQ0d9+sFh2Q3PAZK3tIqIQ0mAE3+czdYujAnyopyrt9ZX7DLIoWvxM T/zA== X-Gm-Message-State: AOJu0Yzp/qS0Dr7Bbot4jOZAdxp/ZDKVazOAn171NZI43MsKpFCS4gB0 dm+c/1BSkvuxwQXvC6skiC0wsg== X-Google-Smtp-Source: AGHT+IGRoSyy5prcv7s6aCNDx4HYofOxt/2GfTUCB8Kos+5pU7v9KRLevtDFB4w6cibWsZB6VVxy4A== X-Received: by 2002:a17:902:e5c3:b0:1c3:52ed:1905 with SMTP id u3-20020a170902e5c300b001c352ed1905mr6467512plf.28.1694023790329; Wed, 06 Sep 2023 11:09:50 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:11a:201:a404:ed4a:5a1e:3b4a]) by smtp.gmail.com with ESMTPSA id ix5-20020a170902f80500b001bc675068e2sm11363996plb.111.2023.09.06.11.09.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 11:09:49 -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 v2 3/3] platform/x86: intel_scu_ipc: Fail IPC send if still busy Date: Wed, 6 Sep 2023 11:09:43 -0700 Message-ID: <20230906180944.2197111-4-swboyd@chromium.org> X-Mailer: git-send-email 2.42.0.283.g2d96d420d3-goog In-Reply-To: <20230906180944.2197111-1-swboyd@chromium.org> References: <20230906180944.2197111-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 interrupts to get significantly delayed to the point that callers of intel_scu_ipc_dev_command() and friends can call the function once, hit a timeout, and call it again while the interrupt still hasn't been processed. This driver will get seriously confused if the interrupt is finally processed after the second IPC has been sent with ipc_command(). It won't know which IPC has been completed. This could be quite disastrous if calling code assumes something has happened upon return from intel_scu_ipc_dev_simple_command() when it actually hasn't. Let's avoid this scenario by simply returning -EBUSY in this case. Hopefully higher layers will know to back off or fail gracefully when this happens. It's all highly unlikely anyway, but it's better to be correct here as we have no way to know which IPC the status register is telling us about if we send a second IPC while the previous IPC is still processing. Cc: Prashant Malani Cc: Kuppuswamy Sathyanarayanan Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd Reviewed-by: Andy Shevchenko --- drivers/platform/x86/intel_scu_ipc.c | 29 ++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/in= tel_scu_ipc.c index 3cea701d2bbd..8be24f48a0fa 100644 --- a/drivers/platform/x86/intel_scu_ipc.c +++ b/drivers/platform/x86/intel_scu_ipc.c @@ -271,6 +271,19 @@ static int intel_scu_ipc_check_status(struct intel_scu= _ipc_dev *scu) return scu->irq > 0 ? ipc_wait_for_interrupt(scu) : busy_loop(scu); } =20 +static int intel_scu_ipc_busy(struct intel_scu_ipc_dev *scu) +{ + u8 status; + + status =3D ipc_read_status(scu); + if (status & IPC_STATUS_BUSY) { + dev_dbg(&scu->dev, "device is busy\n"); + return -EBUSY; + } + + return 0; +} + /* Read/Write power control(PMIC in Langwell, MSIC in PenWell) registers */ static int pwr_reg_rdwr(struct intel_scu_ipc_dev *scu, u16 *addr, u8 *data, u32 count, u32 op, u32 id) @@ -290,6 +303,11 @@ static int pwr_reg_rdwr(struct intel_scu_ipc_dev *scu,= u16 *addr, u8 *data, mutex_unlock(&ipclock); return -ENODEV; } + err =3D intel_scu_ipc_busy(scu); + if (err) { + mutex_unlock(&ipclock); + return err; + } =20 for (nc =3D 0; nc < count; nc++, offset +=3D 2) { cbuf[offset] =3D addr[nc]; @@ -450,6 +468,12 @@ int intel_scu_ipc_dev_simple_command(struct intel_scu_= ipc_dev *scu, int cmd, return -ENODEV; } scu =3D ipcdev; + err =3D intel_scu_ipc_busy(scu); + if (err) { + mutex_unlock(&ipclock); + return err; + } + cmdval =3D sub << 12 | cmd; ipc_command(scu, cmdval); err =3D intel_scu_ipc_check_status(scu); @@ -495,6 +519,11 @@ int intel_scu_ipc_dev_command_with_size(struct intel_s= cu_ipc_dev *scu, int cmd, mutex_unlock(&ipclock); return -ENODEV; } + err =3D intel_scu_ipc_busy(scu); + if (err) { + mutex_unlock(&ipclock); + return err; + } =20 memcpy(inbuf, in, inlen); for (i =3D 0; i < inbuflen; i++) --=20 https://chromeos.dev