[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e2f2408-b6a3-64fe-b616-05470c75b0f4@huawei.com>
Date: Thu, 19 Sep 2024 19:18:45 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Mark Brown <broonie@...nel.org>
CC: <xiaoning.wang@....com>, <linux-spi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in
request_irq()
On 2024/9/19 18:47, Mark Brown wrote:
> On Fri, Sep 06, 2024 at 10:28:28AM +0800, Jinjie Ruan wrote:
>> disable_irq() after request_irq() still has a time gap in which
>> interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
>> disable IRQ auto-enable when request IRQ.
>
>> @@ -948,14 +948,10 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
>> ret = fsl_lpspi_dma_init(&pdev->dev, fsl_lpspi, controller);
>> if (ret == -EPROBE_DEFER)
>> goto out_pm_get;
>> - if (ret < 0)
>> + if (ret < 0) {
>> dev_warn(&pdev->dev, "dma setup error %d, use pio\n", ret);
>> - else
>> - /*
>> - * disable LPSPI module IRQ when enable DMA mode successfully,
>> - * to prevent the unexpected LPSPI module IRQ events.
>> - */
>> - disable_irq(irq);
>> + enable_irq(irq);
>> + }
>
> This now enabled the interrupt in the case where we previously would've
> disabled it - I would have expected the condition on the if statement to
> be reversed?
It enabled the if statement rather than the else because the else
statement has been removed.
Use IRQF_NO_AUTOEN, the irq will not be enabled in devm_request_irq(),
so if (ret < 0), we should enable it, otherwise it is same with
disable_irq(irq) if we do nothing now, the main difference is that the
irq is not enabled when return before calling enable_irq().
Powered by blists - more mailing lists