From: Luca Stefani <luca.stefani.ge1@gmail.com>
To: David Heidelberg <david@ixit.cz>, Carl Lee <carl.lee@amd.com>,
netdev@vger.kernel.org, krzk@kernel.org, peter.shen@amd.com,
colin.huang2@amd.com
Cc: linux-kernel@vger.kernel.org, oe-linux-nfc@lists.linux.dev
Subject: Re: [PATCH] nfc: nxp-nci: i2c: restore IRQ trigger fallback
Date: Mon, 11 May 2026 12:44:09 +0200 [thread overview]
Message-ID: <f176bf40-a5c8-4f6f-86db-ebdbff639da9@gmail.com> (raw)
In-Reply-To: <862b37a1-a25b-49d0-902d-cbb082e2822d@ixit.cz>
On 11/05/2026 12:11, David Heidelberg wrote:
> On 11/03/2026 12:08, Luca Stefani wrote:
>>
>> On 11/03/2026 10:26, Carl Lee wrote:
>>> The driver previously relied on IRQF_TRIGGER_RISING when requesting
>>> the interrupt. This was removed to rely on the trigger type provided
>>> by firmware.
>>>
>>> However, some platforms do not propagate the interrupt trigger type
>>> to the IRQ descriptor, resulting in interrupts not being triggered.
>>>
>>> Use the trigger type provided by firmware when available and fall
>>> back to the historically used rising-edge trigger otherwise.
>>>
>>> Signed-off-by: Carl Lee<carl.lee@amd.com>
>>> ---
>>> drivers/nfc/nxp-nci/i2c.c | 11 ++++++++++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
>>> index 6a5ce8ff91f0..6339586a6a1b 100644
>>> --- a/drivers/nfc/nxp-nci/i2c.c
>>> +++ b/drivers/nfc/nxp-nci/i2c.c
>>> @@ -268,6 +268,7 @@ static int nxp_nci_i2c_probe(struct i2c_client
>>> *client)
>>> struct device *dev = &client->dev;
>>> struct nxp_nci_i2c_phy *phy;
>>> int r;
>>> + unsigned long irqflags;
>>> if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
>>> nfc_err(&client->dev, "Need I2C_FUNC_I2C\n");
>>> @@ -303,9 +304,17 @@ static int nxp_nci_i2c_probe(struct i2c_client
>>> *client)
>>> if (r < 0)
>>> return r;
>>> + /* Prefer the trigger type configured by firmware.
>>> + * Some platforms do not provide it, so fall back to the
>>> + * historically used rising-edge trigger.
>>> + */
>>> + irqflags = irq_get_trigger_type(client->irq);
>> Doesn't build, needs #include <linux/irq.h>
>>> + if (!irqflags)
>>> + irqflags = IRQF_TRIGGER_RISING;
>>> +
>>> r = request_threaded_irq(client->irq, NULL,
>>> nxp_nci_i2c_irq_thread_fn,
>>> - IRQF_ONESHOT,
>>> + irqflags | IRQF_ONESHOT,
>>> NXP_NCI_I2C_DRIVER_NAME, phy);
>>> if (r < 0)
>>> nfc_err(&client->dev, "Unable to register IRQ handler\n");
>>>
>>> ---
>>> base-commit: 7109a2155340cc7b21f27e832ece6df03592f2e8
>>> change-id:
>>> 20260311-nfc-nxp-nci-i2c-restore-irq-trigger-fallback-cda942530c60
>>>
>>> Best regards,
>>
>> My ACPI NXP1001 table specifies ActiveHigh that properly gets
>> translated into IRQF_TRIGGER_HIGH.
>
> Hello Luca,
>
> I'm looking into the issue, I wonder
> would make sense to provide ACPI quirk then?
The old driver didn't really work for me as far as I remember, so if you
just want to fix the storm, that's fine by me, but it's more a bandaid
than anything else.
Ideally we'd make the driver work but I didn't get much further compared
to the diff I sent above.
>
> David
>>
>> Sadly this seems to just show the same storm as before, I played a
>> bit with the driver and noticed that it is simply broken on my
>> device, all I get are timeouts if I read the NCI device.
>>
>> I could get it working (reading tags) by hacking the driver a bit,
>> first of all I disable the irq as soon as I get it, otherwise I keep
>> getting interrupts when the device is in MODE_COLD that would end up
>> setting hard_fault to EREMOTEIO. With that in place I re-implemented
>> the enable/disable routine in nxp_nci_i2c_set_mode, and that seems to
>> be enough to make it working.
>
next prev parent reply other threads:[~2026-05-11 10:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 9:26 [PATCH] nfc: nxp-nci: i2c: restore IRQ trigger fallback Carl Lee via B4 Relay
2026-03-11 11:08 ` Luca Stefani
2026-05-11 10:11 ` David Heidelberg
2026-05-11 10:44 ` Luca Stefani [this message]
2026-03-11 23:46 ` kernel test robot
2026-03-12 2:43 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f176bf40-a5c8-4f6f-86db-ebdbff639da9@gmail.com \
--to=luca.stefani.ge1@gmail.com \
--cc=carl.lee@amd.com \
--cc=colin.huang2@amd.com \
--cc=david@ixit.cz \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oe-linux-nfc@lists.linux.dev \
--cc=peter.shen@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox