| Message ID | 82cba203551939399d219e4cb6c602315fd0c410.1573498518.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 5b47748ecf2e3b7e346d6ce136e1c57239f995b0 |
| Headers | show |
| Series | iommu/rockchip: Don't provoke WARN for harmless IRQs | expand |
On 2019-11-11 20:04, Robin Murphy wrote: > Although we don't generally expect IRQs to fire for a suspended > IOMMU, > there are certain situations (particularly with debug options) where > we might legitimately end up with the pm_runtime_get_if_in_use() call > from rk_iommu_irq() returning 0. Since this doesn't represent an > actual > error, follow the other parts of the driver and save the WARN_ON() > condition for a genuine negative value. Even if we do have spurious > IRQs due to a wedged VOP asserting the shared line, it's not this > driver's job to try to second-guess the IRQ core to warn about that. > > Reported-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > drivers/iommu/rockchip-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iommu/rockchip-iommu.c > b/drivers/iommu/rockchip-iommu.c > index 4dcbf68dfda4..bd7e9b1e40ac 100644 > --- a/drivers/iommu/rockchip-iommu.c > +++ b/drivers/iommu/rockchip-iommu.c > @@ -527,7 +527,7 @@ static irqreturn_t rk_iommu_irq(int irq, void > *dev_id) > int i, err; > > err = pm_runtime_get_if_in_use(iommu->dev); > - if (WARN_ON_ONCE(err <= 0)) > + if (!err || WARN_ON_ONCE(err < 0)) > return ret; > > if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks))) Acked-by: Marc Zyngier <maz@kernel.org> M.
On Mon, Nov 11, 2019 at 06:55:18PM +0000, Robin Murphy wrote: > Although we don't generally expect IRQs to fire for a suspended IOMMU, > there are certain situations (particularly with debug options) where > we might legitimately end up with the pm_runtime_get_if_in_use() call > from rk_iommu_irq() returning 0. Since this doesn't represent an actual > error, follow the other parts of the driver and save the WARN_ON() > condition for a genuine negative value. Even if we do have spurious > IRQs due to a wedged VOP asserting the shared line, it's not this > driver's job to try to second-guess the IRQ core to warn about that. > > Reported-by: Vasily Khoruzhick <anarsoul@gmail.com> > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > drivers/iommu/rockchip-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks.
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c index 4dcbf68dfda4..bd7e9b1e40ac 100644 --- a/drivers/iommu/rockchip-iommu.c +++ b/drivers/iommu/rockchip-iommu.c @@ -527,7 +527,7 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id) int i, err; err = pm_runtime_get_if_in_use(iommu->dev); - if (WARN_ON_ONCE(err <= 0)) + if (!err || WARN_ON_ONCE(err < 0)) return ret; if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks)))
Although we don't generally expect IRQs to fire for a suspended IOMMU, there are certain situations (particularly with debug options) where we might legitimately end up with the pm_runtime_get_if_in_use() call from rk_iommu_irq() returning 0. Since this doesn't represent an actual error, follow the other parts of the driver and save the WARN_ON() condition for a genuine negative value. Even if we do have spurious IRQs due to a wedged VOP asserting the shared line, it's not this driver's job to try to second-guess the IRQ core to warn about that. Reported-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/iommu/rockchip-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)