[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee3d4cf0-dccb-4ce0-9e69-a95507168e6a@kernel.org>
Date: Thu, 8 Jan 2026 09:32:51 +0100
From: Hans de Goede <hansg@...nel.org>
To: Anand Moon <linux.amoon@...il.com>
Cc: 张永波 <giraffesnn123@...il.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
FUKAUMI Naoki <naoki@...xa.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC support" <linux-rockchip@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:USB TYPEC CLASS" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt
handler
Hi,
On 8-Jan-26 07:58, Anand Moon wrote:
> Hi Hans,
>
> On Wed, 7 Jan 2026 at 16:22, Hans de Goede <hansg@...nel.org> wrote:
>>
>> Hi,
>>
>> On 7-Jan-26 10:52, 张永波 wrote:
>>>> Still ideally we would solve this in another way then
>>>> switching to a threaded IRQ handler.
>>>>
>>>> As the commit message of the mei-vsc fix mentions
>>>> the root cause of these errors is typically an interrupt
>>>> chip driver which uses IRQF_NO_THREAD disabling the auto
>>>> threading of all interrupt handlers in RT mode.
>>>>
>>>> So the first question here would be to see if that flag is
>>>> used in the interrupt chip and if yes, is that flag really
>>>> necessary ?
>>> This is very similar to the issue addressed in commit 24b176d8827d
>>> ("drm/msm/dsi: Remove spurious IRQF_ONESHOT flag").
>>> The IRQF_ONESHOT flag is preventing forced threading here.
>>>
>>> In irq_setup_forced_threading(), the conversion to threaded interrupts
>>> is explicitly skipped if any of the IRQF_NO_THREAD, IRQF_PERCPU,
>>> or IRQF_ONESHOT flags are present. In this case, IRQF_ONESHOT
>>> appears to be the reason.
>>
>> Ah, well the code effectively does its own IRQF_ONESHOT handling,
>> since it needs to do its own threaded-irq like handling for
>> suspend/resume reasons. It disables the IRQ when it fires and
>> then only re-enables it once the work has done processing the IRQ.
>>
>> So it should be perfectly safe to drop the IRQF_ONESHOT flag.
>>
> Yes, the warning disappears
>> If that also works to resolve the lockdep issue that would be
>> the preferred way of fixing this IMHO.
>>
> After applying these changes, the device initially triggered a hard reset;
> And the board reboots. I need to find another way to fix this warning.
Hmm, I guess that without the oneshot flag fusb302_irq_intn() might
trigger a second time before it disables the IRQ causing an IRQ enable
unbalance issue.
So lets just go with your original fix of moving this to a threaded
IRQ handler.
Regards,
Hans
Powered by blists - more mailing lists