From: Yunseong Kim <yunseong.kim@est.tech>
To: Miguel Vadillo <miguel.vadillo@intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
yunseong.kim@ericsson.com, ysk@kzalloc.com
Subject: [BUG] intel_cvs: WARNING in __setup_irq: IRQF_ONESHOT without thread_fn
Date: Fri, 14 Aug 2026 00:01:28 +0200 [thread overview]
Message-ID: <20260813220127.7462-2-yunseong.kim@est.tech> (raw)
Hi,
On a Dell Pro 14 Premium PA14250 (Intel Lunar Lake, BIOS 2.13.4), the
Intel CVS (Computer Vision Sensing) driver triggers the following
WARNING on every boot while probing the CVS controller (i2c-INTC10DE:00).
The probe continues afterwards and the IPU7 camera works normally, so
this is cosmetic, but it splats a full backtrace on each boot.
Kernel: 7.1.3+deb13-amd64 (Debian 7.1.3-1~bpo13+1)
Driver: intel_cvs built as a DKMS module from the standalone tree at
https://github.com/intel/vision-drivers (hence the OE/unsigned
taint below), which is what users on kernels predating the
drivers/media/i2c/cvs mainline merge have to use for this
hardware.
[ 14.002098] Intel CVS driver i2c-INTC10DE:00: cvs_common_probe: probed as i2c device
[ 14.006334] ------------[ cut here ]------------
[ 14.006335] WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x50c/0x720, CPU#3: (udev-worker)/693
[ 14.006339] Modules linked in: int3403_thermal(+) processor_thermal_device(+) ov08x40(+) processor_thermal_wt_hint intel_cvs(OE+) intel_skl_int3472_tps68470 v4l2_fwnode platform_temperature_control pmt_telemetry(+) intel_hid(+) processor_thermal_soc_slider pmt_discovery int3400_thermal v4l2_async cfg80211 processor_thermal_rfim acpi_thermal_rel processor_thermal_rapl sparse_keymap intel_skl_int3472_discrete joydev intel_rapl_common pmt_class intel_pmc_ssram_telemetry intel_skl_int3472_common processor_thermal_wt_req acpi_tad acpi_pad intel_vpu processor_thermal_power_floor intel_ipu7(C+) processor_thermal_mbox drm_shmem_helper ipu_bridge int340x_thermal_zone ac evdev rfkill v4l2loopback(OE) videodev mc msr i2c_dev parport_pc ppdev lp parport efi_pstore nfnetlink efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_cryptoapi dm_crypt dm_mod hid_sensor_custom hid_sensor_hub intel_ishtp_hid i2c_usbio gpio_usbio usbio xe drm_gpuvm configfs drm_gpusvm_helper drm_buddy gpu_sched drm_ttm_helper ttm drm_exec
[ 14.006361] i2c_algo_bit ucsi_acpi drm_suballoc_helper typec_ucsi drm_display_helper typec hid_multitouch cec hid_generic roles rc_core psmouse aesni_intel nvme i2c_hid_acpi drm_client_lib gf128mul serio_raw i2c_hid xhci_pci intel_lpss_pci nvme_core xhci_hcd hid drm_kms_helper video intel_lpss intel_ish_ipc nvme_keyring drm usbcore thunderbolt nvme_auth idma64 intel_vsec intel_ishtp usb_common wmi battery button pinctrl_intel_platform
[ 14.006373] CPU: 3 UID: 0 PID: 693 Comm: (udev-worker) Tainted: G C OE 7.1.3+deb13-amd64 #1 PREEMPT(lazy) Debian 7.1.3-1~bpo13+1
[ 14.006375] Tainted: [C]=CRAP, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[ 14.006375] Hardware name: Dell Inc. Dell Pro 14 Premium PA14250/0NGT53, BIOS 2.13.4 05/20/2026
[ 14.006377] RIP: 0010:__setup_irq+0x50c/0x720
[ 14.006378] Code: fe ff ff bb 01 00 00 00 48 c7 c1 ff ff ff ff f3 48 0f bc c9 48 d3 e3 48 83 f9 3f 0f 87 56 2d de ff 49 89 5e 48 e9 d8 fd ff ff <0f> 0b 85 c9 0f 85 87 00 00 00 81 e2 00 00 01 00 0f 85 70 fb ff ff
[ 14.006379] RSP: 0018:ffffced5853837f0 EFLAGS: 00010246
[ 14.006381] RAX: 0000000000206002 RBX: ffff8d3bc9db7f80 RCX: 0000000000000000
[ 14.006381] RDX: 0000000000000402 RSI: ffff8d3b8eeaee00 RDI: 0000000000000000
[ 14.006382] RBP: 00000000000000ae R08: 0000000000000080 R09: ffff8d3bc9db7f80
[ 14.006382] R10: 0000000000000000 R11: ffff8d3c01c2bdb8 R12: 0000000000000000
[ 14.006383] R13: ffff8d3b8eeaee00 R14: ffff8d3bc9db7f80 R15: ffff8d3b8eeaee00
[ 14.006384] FS: 00007f8def0829c0(0000) GS:ffff8d433e7d6000(0000) knlGS:0000000000000000
[ 14.006385] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 14.006385] CR2: 000055c5c6ac1998 CR3: 000000010b2dc003 CR4: 0000000008f70ef0
[ 14.006386] PKRU: 55555554
[ 14.006386] Call Trace:
[ 14.006388] <TASK>
[ 14.006390] ? __pfx_cvs_irq_handler+0x10/0x10 [intel_cvs]
[ 14.006393] request_threaded_irq+0xe2/0x1b0
[ 14.006394] devm_request_threaded_irq+0x81/0x120
[ 14.006396] ? __pfx_cvs_irq_handler+0x10/0x10 [intel_cvs]
[ 14.006398] cvs_common_probe.cold+0x266/0x41e [intel_cvs]
[ 14.006400] i2c_device_probe+0x18b/0x350
[ 14.006403] really_probe+0xde/0x380
[ 14.006404] ? __pfx___driver_attach+0x10/0x10
[ 14.006406] ? __pfx___driver_attach+0x10/0x10
[ 14.006407] __driver_probe_device+0x84/0x150
[ 14.006408] driver_probe_device+0x1f/0xa0
[ 14.006409] __driver_attach+0xba/0x1f0
[ 14.006410] bus_for_each_dev+0x8e/0xe0
[ 14.006411] bus_add_driver+0x11f/0x200
[ 14.006412] driver_register+0x72/0xd0
[ 14.006414] i2c_register_driver+0x45/0xc0
[ 14.006415] ? __pfx_icvs_init+0x10/0x10 [intel_cvs]
[ 14.006417] icvs_init+0x1d/0xff0 [intel_cvs]
[ 14.006418] ? __pfx_icvs_init+0x10/0x10 [intel_cvs]
[ 14.006419] do_one_initcall+0x5c/0x320
[ 14.006422] do_init_module+0x60/0x250
[ 14.006423] init_module_from_file+0xd6/0x130
[ 14.006425] idempotent_init_module+0x114/0x310
[ 14.006426] __x64_sys_finit_module+0x71/0xe0
[ 14.006427] do_syscall_64+0xea/0x640
[ 14.006429] ? vfs_statx+0x80/0x160
[ 14.006431] ? vfs_fstatat+0x54/0x90
[ 14.006432] ? __do_sys_newfstatat+0x3b/0x80
[ 14.006433] ? restore_fpregs_from_fpstate+0x3c/0x90
[ 14.006434] ? switch_fpu_return+0x5d/0xf0
[ 14.006435] ? __seccomp_filter+0x42/0x5d0
[ 14.006437] ? do_syscall_64+0x9f/0x640
[ 14.006438] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 14.006439] RIP: 0033:0x7f8def31a7b9
[ 14.006445] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 66 0d 00 f7 d8 64 89 01 48
[ 14.006446] RSP: 002b:00007ffccecf4ec8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 14.006447] RAX: ffffffffffffffda RBX: 00005649ac2886b0 RCX: 00007f8def31a7b9
[ 14.006448] RDX: 0000000000000004 RSI: 00007f8def06344d RDI: 000000000000002b
[ 14.006448] RBP: 0000000000000004 R08: 0000000000000000 R09: 00005649ac14a000
[ 14.006449] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8def06344d
[ 14.006449] R13: 0000000000020000 R14: 00005649ac27c980 R15: 0000000000000000
[ 14.006450] </TASK>
[ 14.006451] ---[ end trace 0000000000000000 ]---
[ 14.006493] Intel CVS driver i2c-INTC10DE:00: find_oem_prod_id: ACPI method OPID not found
[ 14.012483] ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
[ 14.013736] ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator
[ 14.013926] ov08x40 i2c-OVTI08F4:00: supply dvdd not found, using dummy regulator
[ 14.014064] Intel CVS driver i2c-INTC10DE:00: magic number in dev response not supported
[ 14.014066] Intel CVS driver i2c-INTC10DE:00: cvs_find_magic_num_support:Device protocol is 1.0
[ 14.022987] intel-ipu7 0000:00:05.0: Sending AUTHENTICATE_RUN to CSE
The warning at kernel/irq/manage.c:1502 (v7.1.3) is:
/*
* IRQF_ONESHOT means the interrupt source in the IRQ chip will be
* masked until the threaded handled is done. If there is no thread
* handler then it makes no sense to have IRQF_ONESHOT.
*/
WARN_ON_ONCE(new->flags & IRQF_ONESHOT && !new->thread_fn);
The standalone vision-drivers tree requests the wake IRQ with a hardirq
handler and no thread function (drivers/misc/icvs/intel_cvs.c, cvs_init()):
ret = devm_request_irq(icvs->dev, icvs->irq, cvs_irq_handler,
IRQF_ONESHOT | IRQF_NO_SUSPEND,
dev_name(icvs->dev), icvs);
devm_request_irq() passes thread_fn = NULL, so IRQF_ONESHOT trips the
WARN_ON_ONCE above.
The mainline driver is NOT affected: drivers/media/i2c/cvs/core.c:749
(as of v7.2-rc7) already does this correctly with a NULL primary
handler and a threaded handler:
ret = devm_request_threaded_irq(dev, ctx->irq, NULL,
cvs_irq_handler,
IRQF_ONESHOT | IRQF_NO_SUSPEND,
"cvs_wake", ctx);
Could the same fix be applied to the standalone/DKMS vision-drivers
tree (either switch to devm_request_threaded_irq() with a NULL primary
handler as in mainline, or drop IRQF_ONESHOT from the non-threaded
request)? That tree is what ships to users on pre-7.2 kernels, and
right now every boot on such systems is tainted by this splat.
My System information:
Hardware: Dell Pro 14 Premium PA14250 (Lunar Lake), BIOS 2.13.4 05/20/2026
CVS controller at ACPI i2c-INTC10DE:00, camera OV08X40
(ACPI OVTI08F4) behind Intel IPU7 via Synaptics SVP7500
USB-to-I2C bridge (usbio)
Kernel: 7.1.3+deb13-amd64, Debian 7.1.3-1~bpo13+1 (trixie-backports)
Modules: intel_cvs from intel/vision-drivers DKMS; intel_ipu7 DKMS from
intel/ipu7-drivers; in-tree usbio/i2c-usbio/gpio-usbio, ov08x40
Happy to test patches.
reply other threads:[~2026-08-13 22:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260813220127.7462-2-yunseong.kim@est.tech \
--to=yunseong.kim@est.tech \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=miguel.vadillo@intel.com \
--cc=ysk@kzalloc.com \
--cc=yunseong.kim@ericsson.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