From: Christopher Snowhill <chris@kode54.net>
To: "Mauro Carvalho Chehab" <mchehab@kernel.org>
Cc: Christopher Snowhill <chris@kode54.net>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
"Bradford Love" <brad@nextdimension.cc>,
stable@vger.kernel.org
Subject: [PATCH] media: em28xx: fix inverted tuner capability check for VBI device
Date: Tue, 29 Sep 2026 19:00:06 -0700 [thread overview]
Message-ID: <20260930020010.85250-2-chris@kode54.net> (raw)
Commit 8e53399c63c3 ("media: em28xx: Add support for Empia em2828X
bridge") changed the condition for setting V4L2_CAP_TUNER on the VBI
device from "dev->tuner_type != TUNER_ABSENT" to a check of the video
device's capabilities, but inverted it: the VBI node now advertises a
tuner only when the video node does not have one.
On boards without a tuner (e.g. the MyGica iGrabber, card=105) the VBI
device's device_caps therefore contain V4L2_CAP_TUNER, while the shared
vidioc_querycap() correctly omits it from cap->capabilities. This trips
the sanity check in v4l_querycap() whenever the VBI node is queried,
for example by udev's v4l_id on every hotplug:
WARNING: drivers/media/v4l2-core/v4l2-ioctl.c:1119 at v4l_querycap+0xff/0x110 [videodev]
(cap->capabilities & (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)) != (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)
It also leaves the tuner ioctls enabled on the VBI node of tuner-less
boards and disables them on boards that do have a tuner.
Restore the intended logic so the VBI device has V4L2_CAP_TUNER exactly
when the video device does.
Fixes: 8e53399c63c3 ("media: em28xx: Add support for Empia em2828X bridge")
Assisted-by: LLM
Signed-off-by: Christopher Snowhill <chris@kode54.net>
Cc: stable@vger.kernel.org
---
drivers/media/usb/em28xx/em28xx-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c
index c418add65bb5..cdf1dc692b08 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -3001,7 +3001,7 @@ static int em28xx_v4l2_init(struct em28xx *dev)
v4l2->vbi_dev.queue->lock = &v4l2->vb_vbi_queue_lock;
v4l2->vbi_dev.device_caps = V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE | V4L2_CAP_VBI_CAPTURE;
- if ((v4l2->vdev.device_caps & V4L2_CAP_TUNER) == 0)
+ if (v4l2->vdev.device_caps & V4L2_CAP_TUNER)
v4l2->vbi_dev.device_caps |= V4L2_CAP_TUNER;
/* disable inapplicable ioctls */
--
2.55.0
reply other threads:[~2026-09-30 2:01 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=20260930020010.85250-2-chris@kode54.net \
--to=chris@kode54.net \
--cc=brad@nextdimension.cc \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=stable@vger.kernel.org \
/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
all inboxes | Powered by JetHome®