Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4857088rdb; Fri, 15 Sep 2023 14:45:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFA88oAHcRDg0xTsw8yd5ZnJDvDxw8+nFW0pW5a+1OBEhkRCdDBJKMSKOKu21Wgug9WjlaL X-Received: by 2002:a17:90a:9f82:b0:267:c0cb:e462 with SMTP id o2-20020a17090a9f8200b00267c0cbe462mr2435660pjp.48.1694814324280; Fri, 15 Sep 2023 14:45:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694814324; cv=none; d=google.com; s=arc-20160816; b=ynIUPeYrQI7p80odfCJSpNx3E0o7KKO8zD/Jiu49/9gL8tZ1vblFZpnqfaAnARA4mg uxsgdw6BLxY/SrZtsijRWPgwc7oGM4xfPf+7NbTIGltsQ4JLIDf+BDIEOlMZkq8pRM0p K836DRrmSGeIYqI8zsfqQD5H26rI0zaQdfsyC6ySB+T6ngZ7MZXMGtng6b0hnzMWV/VB ABfAYhdMt3Ob9Fiktk5PlO6vvHW0LfF8KGnzZYRyfxNZb563PZXsQFPp9HVZujJ0tN1d PFKRtSB/+zaRPCoDYLR/NmWaM6PsfDYbMPQ7OJEJk+mK7FpqJkJveApFfoloJmM3zhZB 3hIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=0IJk+kR7StykOfm6QuRCPSdq+igsVWdQmd5LYma7pQk=; fh=9uSupWSKCvwMYcabfabTjuN0KiQkG06sWub5AsVGZY4=; b=VxTtVcMn+tB5/f6xPHKskL5rTeBZkAlLwDFrE5FyY5wE6gKV6qLD6ZwqbJGXuKaUBZ fbm6cPKwsi2kS7Y8/v44l9oDWCqnI35rAMe5HSzBh1vusZouj75vEXeQkSdMFzHqwREn +8bmLPbcuGBxOkgyN0cLNj5wwXRXVcoC/3ZAXZYN8BhFUk8npqDI+ceBfcEvPVrGRmHs RjaKFsxBNAL2hTHTO9pPF/XuFHPo2OCwuWGU7EM+t8hgr1OwZw+xM6zhKcilBV74FUv8 wQ0PDHC109UFJTp32jt39T6034BTh94VbXHw/Sfdk4rDZP9QsrsTTdUgw+SI1CBFVwas yQ4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UV2DNlQW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id a5-20020a655c85000000b0057755d654f4si3749643pgt.628.2023.09.15.14.45.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 14:45:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UV2DNlQW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id CC50780698DF; Fri, 15 Sep 2023 06:42:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235406AbjIONm1 (ORCPT + 99 others); Fri, 15 Sep 2023 09:42:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235355AbjIONm0 (ORCPT ); Fri, 15 Sep 2023 09:42:26 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B23BC1BEB; Fri, 15 Sep 2023 06:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694785341; x=1726321341; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=MNuTddJauiPRkBx+ucRB3S+YwwDAcFs5oVQUJiHydRY=; b=UV2DNlQWVtSuE31lqoKycRFSpD/LUNjd2BMzq+KptwWF4uwvfFhvNINE nNouIxmSGZQXkOMBGjoiJMd5khYSLrCHFUBSyp1eNSAKgawFGiteHSVwj D19YYDKd9TTuk1jsu1UjOfzarE7HFzEFg7fPz5d60n/5iuN2ci2i57eIW M7wBwVQws0MwQZoD8gvtWvYFprJPWMeeKrvKJABGjKWXyMp4k+eLr7MNt b816572vLeC1kuCuOZIwWf2NEEATiMiYZupwljCe7cH3CsV9Aig9+pY4l 4/aO5WRaRqe71R2vIVnn3sRxBSsyMrB0ERIwiIbkJHaJ1PbqMK9fN9Z0O Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10834"; a="381978246" X-IronPort-AV: E=Sophos;i="6.02,149,1688454000"; d="scan'208";a="381978246" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2023 06:42:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10834"; a="744988928" X-IronPort-AV: E=Sophos;i="6.02,149,1688454000"; d="scan'208";a="744988928" Received: from srdoo-mobl1.ger.corp.intel.com ([10.252.38.99]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2023 06:42:18 -0700 Date: Fri, 15 Sep 2023 16:42:16 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Stephen Boyd cc: Mika Westerberg , Hans de Goede , Mark Gross , linux-kernel@vger.kernel.org, patches@lists.linux.dev, platform-driver-x86@vger.kernel.org, Andy Shevchenko , Kuppuswamy Sathyanarayanan , Prashant Malani Subject: Re: [PATCH v4 1/4] platform/x86: intel_scu_ipc: Check status after timeout in busy_loop() In-Reply-To: <20230913212723.3055315-2-swboyd@chromium.org> Message-ID: References: <20230913212723.3055315-1-swboyd@chromium.org> <20230913212723.3055315-2-swboyd@chromium.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-2022163745-1694785340=:2347" X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 15 Sep 2023 06:42:27 -0700 (PDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-2022163745-1694785340=:2347 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Wed, 13 Sep 2023, Stephen Boyd wrote: > It's possible for the polling loop in busy_loop() to get scheduled away > for a long time. > > status = ipc_read_status(scu); // status = 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. > The readl_poll_timeout() macro implements all of this, and it is > shorter, so use that macro here to consolidate code and fix this. > > There were some concerns with using readl_poll_timeout() because it uses > timekeeping, and timekeeping isn't running early on or during the late > stages of system suspend or early stages of system resume, but an audit > of the code concluded that this code isn't called during those times so > it is safe to use the macro. > > Cc: Prashant Malani > Reviewed-by: Andy Shevchenko > Reviewed-by: Mika Westerberg > Reviewed-by: Kuppuswamy Sathyanarayanan > Fixes: e7b7ab3847c9 ("platform/x86: intel_scu_ipc: Sleeping is fine when polling") > Signed-off-by: Stephen Boyd Reviewed-by: Ilpo J?rvinen -- i. > --- > drivers/platform/x86/intel_scu_ipc.c | 19 ++++++++----------- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c > index 6851d10d6582..4c774ee8bb1b 100644 > --- a/drivers/platform/x86/intel_scu_ipc.c > +++ b/drivers/platform/x86/intel_scu_ipc.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -231,19 +232,15 @@ static inline u32 ipc_data_readl(struct intel_scu_ipc_dev *scu, u32 offset) > /* Wait till scu status is busy */ > static inline int busy_loop(struct intel_scu_ipc_dev *scu) > { > - unsigned long end = jiffies + IPC_TIMEOUT; > + u8 status; > + int err; > > - do { > - u32 status; > + err = readx_poll_timeout(ipc_read_status, scu, status, !(status & IPC_STATUS_BUSY), > + 100, jiffies_to_usecs(IPC_TIMEOUT)); > + if (err) > + return err; > > - status = ipc_read_status(scu); > - if (!(status & IPC_STATUS_BUSY)) > - return (status & IPC_STATUS_ERR) ? -EIO : 0; > - > - usleep_range(50, 100); > - } while (time_before(jiffies, end)); > - > - return -ETIMEDOUT; > + return (status & IPC_STATUS_ERR) ? -EIO : 0; > } > > /* Wait till ipc ioc interrupt is received or timeout in 10 HZ */ > --8323329-2022163745-1694785340=:2347--