icvs: don't request a non-threaded IRQ with IRQF_ONESHOT

[jibsta210]

cvs_init() registers cvs_irq_handler() as a primary (hardirq) handler via devm_request_irq() but passes IRQF_ONESHOT.

IRQF_ONESHOT is intended for threaded interrupts — it keeps the line masked after the hardirq until the threaded handler runs. cvs_irq_handler() has no threaded component (it only sets hostwake_event_arg and wakes a waitqueue), so the flag is inappropriate. On the Synaptics SVP7500 (06cb:0701) CVS bridge it leaves the device interrupt masked after an event, so the bridge stops delivering interrupts after a brief idle and wedges. libcamera then can no longer drive the sensor and falls back to the simple pipeline with no frames — the ov08x40 … Unable to get rectangle N … Inappropriate ioctl for device + simple-pipeline-fallback signature reported in #33, #31 and #36.

Dropping IRQF_ONESHOT restores reliable IRQ delivery and streaming; IRQF_NO_SUSPEND is kept so the line stays armed across suspend.

Tested on a Dell XPS 16 (Panther Lake, SVP7500 + ov08x40): with the change the RGB camera streams (500 frames @ 28.57 fps via libcamera cam); without it the bridge wedges after a brief idle.

[AskeFC]

Please merge this 🙏

[milamberspace]

Confirming this on a different platform and CVS bridge, which I think strengthens the case that it's not bridge-specific.

• Machine: Dell XPS 13 9350, Intel Lunar Lake
• CVS bridge: Lattice AI USB 2.0 (2ac1:20c9), ACPI INTC10DE:00 — not the Synaptics SVP7500 from the description
• Kernel: 7.1.3 (CONFIG_INTEL_VSC, intel_cvs via DKMS)

Without this change, every cold boot logs the WARN at __setup_irq from cvs_init():

WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x50c/0x720
 ? __pfx_cvs_irq_handler+0x10/0x10 [intel_cvs]
 request_threaded_irq+0xe2/0x1b0
 devm_request_threaded_irq+0x81/0x120
 cvs_common_probe.cold+0x25e/0x3d6 [intel_cvs]

With IRQF_ONESHOT dropped, the WARN is gone and the probe is clean (Transfer of ownership success), camera + mic stream fine.

One data point in the other direction: on this Lattice bridge I did not observe the post-idle wedge you saw on the SVP7500 — the camera worked even with the buggy flag (once the sensor-ownership race was worked around separately). So on this bridge the flag looks harmless at runtime but still trips the WARN and taints the kernel on every boot. Either way the flag is wrong for a non-threaded handler, and this is the correct minimal fix. +1 for merging.