Re: [PATCH v11 10/16] iommu/arm-smmu-v3: Factor out arm_smmu_handle_gerror()

From: Will Deacon

Date: Wed Oct 07 2026 - 10:07:53 EST


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 <jgg@xxxxxxxxxx>
> Reviewed-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Signed-off-by: Pranjal Shrivastava <praan@xxxxxxxxxx>
> ---
> 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