Re: [PATCH v2] nfc: nxp-nci: remove interrupt trigger type

["Mark Pearson" <mpearson@squebb.ca>]

On Mon, May 4, 2026, at 5:33 AM, Bartosz Golaszewski wrote:
> On Wed, Mar 11, 2026 at 11:01 AM Carl Lee <qq1145099@gmail.com> wrote:
>>
>> On Mon, Mar 09, 2026 at 07:13:18PM +0100, Luca Stefani wrote:
>> >
>> > On 05/02/2026 12:11, Carl Lee wrote:
>> > > For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and
>> > > active high, not edge-triggered.
>> > >
>> > > Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail
>> > > to trigger correctly.
>> > >
>> > > Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured
>> > > via Device Tree.
>> > >
>> > > Signed-off-by: Carl Lee <carl.lee@amd.com>
>> > > ---
>> > > This v2 of the series includes Krzysztof Kozlowski in the review list
>> > > for NXP-NCI NFC.
>> > >
>> > > This series removes IRQF_TRIGGER_RISING in nxp-nci driver,
>> > > relying on the IRQ trigger type specified via Device Tree.
>> > > ---
>> > > Changes in v2:
>> > > - Include Krzysztof Kozlowski in the review list for NXP-NCI NFC.
>> > > - Link to v1: https://lore.kernel.org/r/20260204-fc-nxp-nci-remove-interrupt-trigger-type-v1-1-3bde91593173@amd.com
>> > > ---
>> > >   drivers/nfc/nxp-nci/i2c.c | 2 +-
>> > >   1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
>> > > index 049662ffdf97..6a5ce8ff91f0 100644
>> > > --- a/drivers/nfc/nxp-nci/i2c.c
>> > > +++ b/drivers/nfc/nxp-nci/i2c.c
>> > > @@ -305,7 +305,7 @@ static int nxp_nci_i2c_probe(struct i2c_client *client)
>> > >     r = request_threaded_irq(client->irq, NULL,
>> > >                              nxp_nci_i2c_irq_thread_fn,
>> > > -                            IRQF_TRIGGER_RISING | IRQF_ONESHOT,
>> > > +                            IRQF_ONESHOT,
>> >
>> > This is causing an IRQ storm on my ACPI device that eats away a core of my
>> > cpu...
>> >
>> > I'm not sure how this should be fixed but by looking at other drivers they
>> > all use irq_get_trigger_type() and then apply extra bits on top.
>> >
>> > If there's no clear path that handles both ACPI+DT I'll upload a revert.
>> >
>>
>> Thanks for the report.
>>
>> I’ve sent a follow-up patch series that restores a fallback to the
>> historically used rising-edge trigger when the firmware does not provide
>> a trigger type. This should prevent the IRQ storm on ACPI platforms
>> while keeping proper behavior on DT-based systems.
>>
>> Patch series link: https://lore.kernel.org/all/20260311-nfc-nxp-nci-i2c-restore-irq-trigger-fallback-v1-1-9e20714411d7@amd.com/
>>
>
> Hi!
>
> I'm experiencing the same issue since v6.19.5 (still present on
> v7.0.3) and the linked patch *does not* fix the problem - only
> reverting the offending commit
> (57be33f85e369ce9f69f61eaa34734e0d3bd47a7 in mainline) does. I'm
> running a T14s laptop with AMD Ryzen 7 PRO 6850U.
>
Hi all

Just to confirm that I'm seeing the same on a number of Lenovo platforms with NFC devices on them (so far AMD platforms only, though I don't know if that is always true). I think it's going to be  common unfortunately.

I've been discussing with Carl, but reverting the patch for now would be my preference while we figure out how to not break things on the x86 platforms.

The patch from Carl where it checks for a not configured irqtype doesn't work unfortunately. On my test systems it returns with the irq set as IRQF_TRIGGER_HIGH, which triggers the IRQ storm (which breaks things).

I do have a question in to the platform team to determine how the IRQ should be configured on our platforms (is HIGH correct and we're not servicing it correctly, or is it wrong and in which case how do we fix it).

Unfortunately the NFC device hasn't been part of our Linux certification program (I get a question about it about once every 2 years). I'd love to get it working properly - but that will take some time to figure out the options.

If this is lenovo specific we could put a dmi quirk in for the short term? I suspect it might hit other vendors too though - so maybe remove it for non device tree platforms?

Let me know what I can do to help

Mark