From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BA531CA5FF1 for ; Wed, 7 Oct 2026 14:07:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bOAv0R3ZhwJIJUgI99yXwYkreNKP5pjHIRNnaTrY9Pc=; b=bD4HQdTsPGLqaiSWkhb14ial15 l302/v6eWoeSHjkidRUQSOp4zm+FXCSSkcWzogl85hHAr7xh11GnFbgG9WFWTr8HmQOC8gkcwUS0D jyvbvO7wpqgTWlqvbBhRLxuecROihW++mbgL0yeT3/QGDexmGabyPqzJtdCJiP7zCxtwL+jA6W6kJ tzWeNJmrnQ2ywyZk3SAXYwbhpDsqeWexfR8DYxlR2O+GSOrMP45ivrXG7fC5krDVo+czNPwi6u+gk /Y5tjOQ051y7ZJnUBoj0+Wwx9QBdggX/tfuOL+6xfbAPbfeEJ9aENTCXYYPaDKGcTbMo3cEjZXk/V 9nYr2fsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xESIy-00000002aHb-2N3Q; Wed, 07 Oct 2026 14:07:36 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xESIx-00000002aHD-0dTr for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2026 14:07:35 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E355C43275; Wed, 7 Oct 2026 14:07:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 384B91F0089B; Wed, 7 Oct 2026 14:07:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791382054; bh=bOAv0R3ZhwJIJUgI99yXwYkreNKP5pjHIRNnaTrY9Pc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=eyFCCcBJRgoHWtSILSChmLCTdptTF0dqOismLghOMQPjOc86+n6D6Y5a0QK8wLk6H /zj/LHEGXw1LO6uai8bKNky2WbsUxJ1FqboclhLZhHSWtqIUXZMRuXcNSmVK3UolcI c2aYHTrSXa58igX39CvzUfTEoJH2tzQr8nlmDsoXYRCOXAuFAHgq1J6kZwvQTK9CdD A5ASMCTRmuHjXFaTNmxeqHj1wivmBY2fUg7dXgK3iylM9LhGKTaJ4LIyFIOxSpQ1qS Jc7t9M7ZBcj/Ds2ee8WrL0cYaM1vvCX75V4xXcHhlrBpAIz/S8wndPXQdaZ6rKgr93 oOvKrAvpQhq+w== Date: Wed, 7 Oct 2026 15:07:28 +0100 From: Will Deacon To: Pranjal Shrivastava Cc: iommu@lists.linux.dev, Joerg Roedel , Robin Murphy , Jason Gunthorpe , Mostafa Saleh , Nicolin Chen , Daniel Mentz , Ashish Mhetre , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Radu Rendec , Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , rafael@kernel.org, Danilo Krummrich , driver-core@lists.linux.dev, Jason Gunthorpe Subject: Re: [PATCH v11 10/16] iommu/arm-smmu-v3: Factor out arm_smmu_handle_gerror() Message-ID: References: <20260929034510.2023173-1-praan@google.com> <20260929034510.2023173-11-praan@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260929034510.2023173-11-praan@google.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 29, 2026 at 03:45:04AM +0000, Pranjal Shrivastava wrote: > The GERROR register's state might be lost when the SMMU is powered down > during runtime suspend, requiring the suspend sequence to handle any > pending errors before the hardware state is lost. > > Refactor the gerror handling logic into a helper function. Subsequent > patches will invoke it from the runtime suspend callback after disabling > the SMMU, ensuring that any late-breaking gerrors are logged and ack'ed > before the hardware state is lost. > > Suggested-by: Jason Gunthorpe > Reviewed-by: Nicolin Chen > Reviewed-by: Jason Gunthorpe > Signed-off-by: Pranjal Shrivastava > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index 7347d3ecdae8..a123810fac57 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -2406,10 +2406,10 @@ static irqreturn_t arm_smmu_priq_thread(int irq, void *dev) > > static int arm_smmu_device_disable(struct arm_smmu_device *smmu); > > -static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev) > +/* Lockless; must ensure that there are no concurrent callers */ This comment doesn't add an awful lot imo. You could probably say the same about many kernel functions and this isn't exposed outside of the file... > +static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu) > { > u32 gerror, gerrorn, active; > - struct arm_smmu_device *smmu = dev; > > gerror = readl_relaxed(smmu->base + ARM_SMMU_GERROR); > gerrorn = readl_relaxed(smmu->base + ARM_SMMU_GERRORN); > @@ -2452,6 +2452,13 @@ static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev) > return IRQ_HANDLED; > } I think it's a bit weird to return an irqreturn_t from a function that is now going to be called outside of irq context. Also, it looks like you end up calling this later on after you have drained the cmdq, which makes me a little worried about the case when we can end up calling __arm_smmu_cmdq_skip_err(). Will