[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VeWq_GzJ_yZag2yceuUDqPiMRWEa4XNYT5uPwXCzrsb7g@mail.gmail.com>
Date: Thu, 17 Sep 2020 16:46:45 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Dmitry Osipenko <digetx@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Laxman Dewangan <ldewangan@...dia.com>,
Wolfram Sang <wsa@...-dreams.de>,
Michał Mirosław <mirq-linux@...e.qmqm.pl>,
linux-i2c <linux-i2c@...r.kernel.org>,
linux-tegra@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 14/34] i2c: tegra: Clean up probe function
On Thu, Sep 17, 2020 at 3:37 PM Thierry Reding <thierry.reding@...il.com> wrote:
> On Wed, Sep 09, 2020 at 01:39:46AM +0300, Dmitry Osipenko wrote:
...
> > + ret = devm_request_irq(&pdev->dev, i2c_dev->irq, tegra_i2c_isr,
> > + IRQF_NO_SUSPEND, dev_name(&pdev->dev),
> > + i2c_dev);
> > + if (ret)
> > + return ret;
>
> Is it safe to install the interrupt handler at this point? What if,
> perhaps because some bootloader didn't properly quiesce the I2C
> controller, an interrupt triggers immediately after this?
It\s easy to check with debug shared IRQ, but here IRQ is not shared...
So, with a hack into the code and enabled debug it will be achievable to test.
And you probably meant that IRQ triggers *before* the handler is in place?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists