If v4l2_async_register_subdev_sensor failed, then the sensor had
already been powered down by pm_runtime_idle, but the error path
then also explicitly called imx355_power_off as well. That left
an imbalance in the regulator and clock calls.
Call pm_runtime_idle only after v4l2_async_register_subdev_sensor
succeeds to avoid this.
Fixes: efa5fe19c0 ("media: imx355: Enable runtime PM before registering async sub-device")
Cc: stable@vger.kernel.org
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
vd55g1_update_pad_fmt() is called in vd55g1_init_state(). But
vd55g1_set_pad_fmt(), called at the end of vd55g1_init_state(), also
calls vd55g1_update_pad_fmt() itself.
Enhance readability and clear confusion by only preparing the format in
vd55g1_init_state() and let vd55g1_set_pad_fmt() update it instead,
effectively calling it only 1 time instead of 2.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
In the driver initialization, the index of the default media bus code
from the supported media bus code array is passed directly to the
vd55g1_get_fmt_code() function instead of the proper media bus code.
This works correctly as a proper media bus code is set after
initialization but could not have been the case. This also resulted in
mutliple "Unsupported mbus format" error messages.
Retrieve the media bus code from the media bus code array, and pass this
media bus code to vd55g1_get_fmt_code() instead of the code index.
Rename VD55G1_MBUS_CODE_DEF to VD55G1_MBUS_CODE_IDX_DEF and
VD55G1_MODE_DEF to VD55G1_MODE_IDX_DEF while at it to avoid future
confusions. Display the guilty error code in warning message.
Cc: stable@vger.kernel.org
Fixes: e138e7f000 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
ipu6_bus_initialize_device() stores the isys/psys pdata pointer in
struct ipu6_bus_device and initializes the auxiliary device. After that
point, error unwinding must drop the auxiliary device reference and let
ipu6_bus_release() free both the bus device and adev->pdata.
The isys and psys init paths already call put_device() when MMU
initialization fails, and ipu6_bus_add_device() calls
auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths
therefore run the bus release callback. The extra kfree(pdata) in the
callers can release the same object a second time.
Remove the manual pdata frees after the auxiliary device has been
initialized.
This issue was found by a static analysis checker and confirmed by
manual source review.
Fixes: cb3117b074 ("media: intel/ipu6: add IPU auxiliary devices")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The sensor registers are only written in the runtime PM resume
handler; ov8865_set_fmt() merely stores the requested mode, relying on
the sensor being runtime suspended between uses so that the next
resume applies it.
That assumption breaks when something keeps the sensor powered. On
IPU3 platforms, ipu_bridge instantiates the VCM device with a
DL_FLAG_PM_RUNTIME device link to the sensor, so a userspace process
holding the VCM subdev open (e.g. wireplumber's camera monitor) pins
the sensor runtime-active. A subsequent set_fmt() then never reaches
the hardware: the sensor keeps streaming the mode programmed on the
last resume while the CSI-2 receiver expects the newly negotiated
format.
On a Surface Book 2 (IPU3, ov8865 + dw9719 VCM), requesting the
3264x2448 mode while the hardware was left programmed for the
1632x1224 binned mode makes ipu3-cio2 report "frame sync error" and
"payload length is 10340352, received 2585088" (exactly one binned
frame) for every frame, and the inverse case stalls the stream after
a single frame. Camera applications end up displaying one bogus frame
forever.
Program the sensor configuration and apply the control values on
stream start instead, where the negotiated mode is always current,
and only write the configuration in the runtime PM resume handler
when resuming with the stream already started.
Signed-off-by: Jurison Murati <eng.juri@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
ov8865_s_stream() takes a runtime PM reference when enabling the
stream, but returns without releasing it if ov8865_sw_standby()
fails, leaving the reference unbalanced and the sensor powered
indefinitely. The same applies to a failure while disabling the
stream, in which case the reference acquired at stream start is
never dropped.
Drop the reference in a single place, both when disabling the
stream and on failure, and only update the streaming state on
success.
Signed-off-by: Jurison Murati <eng.juri@gmail.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Add a blank line between the local variable declarations and
the following statement in ipu_bridge_get_ivsc_acpi_dev().
Also remove an unnecessary blank line within the declaration block.
This addresses a checkpatch.pl warning.
No functional change intended.
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Several camera sensor drivers access the "clock-frequency" property
directly to retrieve the external clock rate or handle the external
clock manually in the driver. While this is valid on a subset of ACPI
platforms, implementing this logic directly in drivers is deprecated
and can lead to inconsistent behaviour across drivers.
This driver supports ACPI platforms only. It currently retrieves the
external clock rate from the "clock-frequency" property and fails
probing if the rate does not match the expected value, which is the
correct policy for ACPI platforms.
Switch to using the devm_v4l2_sensor_clk_get() helper to standardise
clock handling. This preserves the existing behaviour on ACPI
platforms that specify a clock-frequency property without providing
a clock. On platforms that provide a clock, the helper will program
the clock to the rate specified by clock-frequency, which is also
consistent with the driver's expectations.
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Currently, VIDEO_AMD_ISP4_CAPTURE selects VIDEO_V4L2_SUBDEV_API without
ensuring MEDIA_CONTROLLER is enabled, causing an unmet dependency:
WARNING: unmet direct dependencies detected for VIDEO_V4L2_SUBDEV_API
Depends on [n]: MEDIA_SUPPORT [=m] && VIDEO_DEV [=m] && MEDIA_CONTROLLER [=n]
Selected by [m]:
- VIDEO_AMD_ISP4_CAPTURE [=m] && MEDIA_SUPPORT [=m] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && DRM_AMDGPU [=m] && DRM_AMD_ISP [=y] && HAS_DMA [=y] && VIDEO_DEV [=m]
Many other options in this subsystem select MEDIA_CONTROLLER, let's do the
same here.
This unmet dependency bug was detected by kconfirm, a static analysis tool
for Kconfig.
Fixes: 9a54c28563 ("media: platform: amd: Introduce amd isp4 capture driver")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Bin Du <bin.du@amd.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is
acquired using fwnode_graph_get_remote_endpoint(). This reference is
properly released in the error paths, but it is leaked on the success
path.
Add the missing fwnode_handle_put() before returning 0 to prevent the
reference leak.
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
Fixes: ca50c197bd ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties")
Cc: stable@vger.kernel.org
[Sakari Ailus: Fix subject prefix and coding style a little.]
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The driver misses calling media_entity_cleanup() on the probe error path
and during remove, leaking resources if probe fails after entity
initialization or when the driver is unloaded.
Fix this by adding media_entity_cleanup() to the rdacm21_probe() error
handling path and to rdacm21_remove().
Fixes: a59f853b3b ("media: i2c: Add driver for RDACM21 camera module")
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The Dell 16 Premium DA16250 (marketed as XPS 16) has its OV02C10 front
sensor mounted upside down, like the other Dell XPS models already present
in upside_down_sensor_dmi_ids[]. The rotation is reported as 0 in both the
SSDB and the _PLD, so without a DMI quirk the image is presented upside
down.
Add a DMI quirk entry for this model so that a rotation of 180 degrees is
reported for its OVTI02C1 sensor.
Signed-off-by: Samuele Angioli <samuele.angioli@inspect.it>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The VIP driver uses v4l2_fwnode_endpoint_parse() and the
v4l2_async_nf_*() notifier APIs, but its Kconfig entry does not
select V4L2_FWNODE. Hence kernel test robot reports:
vip.c:3236: undefined reference to `v4l2_async_nf_unregister'
vip.c:3237: undefined reference to `v4l2_async_nf_cleanup'
vip.c:3339: undefined reference to `v4l2_fwnode_endpoint_parse'
vip.c:3346: undefined reference to `v4l2_async_nf_init'
vip.c:3348: undefined reference to `__v4l2_async_nf_add_fwnode'
vip.c:3357: undefined reference to `v4l2_async_nf_register'
Select V4L2_FWNODE, which in turn selects V4L2_ASYNC, providing
all the missing symbols.
Fixes: fc2873aa4a ("media: ti: vpe: Add the VIP driver")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607031826.vOPABT39-lkp@intel.com/
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the
compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3:
coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame()
encodes one plane per component, and an incompressible plane takes the
FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim.
For a 4-component pixel format all four planes are full resolution
(width_div == height_div == 1), so a frame that forces every plane
through the unencoded fallback writes
sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning
the plane by coded_w * coded_h, which can result in corruption
of adjacent kernel heap memory.
Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest
components_num among the supported raw formats, so the capture buffer is
always large enough for the unencoded fallback.
Fixes: 16ecf6dff9 ("media: vicodec: Add support for 4 planes formats")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The int3472 driver (under drivers/platform/x86/intel/int3472) implements
an effective kernel API (via instantiating regulators, clocks and GPIOs)
that is primarily used by the drivers under drivers/media. This means that
there are often dependencies between patches to the int3472 driver and the
camera sensor drivers whereas dependencies to other parts of the x86
platform tree are fairly rare.
Assign the int3472 driver tree to the Media tree.
Patches that have dependencies elsewhere than in the Media tree will be
coordinated with the respective maintainers as usual.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Daniel Scally <dan.scally@ideasonboard.com>
If start_streaming fails, then all queued buffers must be
returned to vb2 in state QUEUED.
Otherwise it will trigger a WARN_ON.
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use vb2_video_unregister_device instead of video_unregister_device
to ensure any streaming is correctly stopped at unregister time.
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The em28xx driver creates a lot of video devices, but life-time management
is really bad. Instead use the struct v4l2_device release() callback to
have a single place where memory can be freed once the last user has gone.
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When my em28xx USB device that uses the i2c tvp5150 driver is
disconnected, it crashes.
The cause is that the tvp5150 i2c module uses v4l2_async, but
the em28xx driver does not since it predates v4l2_async.
In that corner case sd->asc_list is empty, so
v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev().
Modify the code so that, if sd->asc_list is empty,
v4l2_device_unregister_subdev() is still called.
Fixes: 28a1295795 ("media: v4l: async: Allow multiple connections between entities")
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
We can rearrange a bit the function to reduce the indentation levels.
No functional change added to this patch.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Split out the wait function, and introduce some new toys: guard and
lockdep.
This fixes the following cocci warnings:
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2776
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2786
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2809
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Move the actual opening to its own function.
Not intended code change. This is a preparation for the next patch.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Coccinelle triggers a false positive where it thinks that the priv
variable in helene_attach_s and helene_attach is the same variable as
helene_probe. This is due to a bad heuristic in cocci.
We have reported it to cocci, but until/if this is fixed, renaming a
local variable is a good compromise to fix this warning:
./dvb-frontends/helene.c:1049:2-7: WARNING: invalid free of devm_ allocated data
./dvb-frontends/helene.c:1013:2-7: WARNING: invalid free of devm_ allocated data
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
We are using the refcnt variable for refcounting. Use the refcount_t
type instead, as it has support for saturation and underflow.
This also makes cocci happier, as it will fix the following warning:
./platform/amd/isp4/isp4_subdev.c:394:6-25: WARNING: atomic_dec_and_test variation before object free at line 395.
Fixes: 4c5feef6a6 ("media: platform: amd: Add isp4 fw and hw interface")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Reviewed-by: Bin Du <bin.du@amd.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
pixel_rate is set to VIMC_PIXEL_RATE_FIXED, which the code expects to
fit in 32 bits. Make that constraint into a WARN_ON, so if we ever break
that constraint a kernel warning will be triggered.
It also fixes the following cocci warning:
./test-drivers/vimc/vimc-sensor.c:107:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The max() macro is simpler to read than the current construction, it
also makes cocci happier, which currently throws these warnings:
./platform/qcom/iris/iris_vpu_buffer.c:703:13-15: WARNING opportunity for max()
./platform/qcom/iris/iris_vpu_buffer.c:583:23-25: WARNING opportunity for max()
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
There is no need to add a semicolon after a switch statement.
It also makes cocci a bit uneasy. It triggers the following warnings:
./usb/em28xx/em28xx-cards.c:4085:2-3: Unneeded semicolon
./usb/em28xx/em28xx-core.c:635:2-3: Unneeded semicolon
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The video_ioctl2() kernel-doc comment says "hancle" and
refers to v4l2_ioctl_ops.unlocked_ioctl.
Fix the typo and refer to v4l2_file_operations.unlocked_ioctl
instead. The unlocked_ioctl member belongs to struct
v4l2_file_operations.
Signed-off-by: Binglin Zhao <1311165354@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
tpg_fill_plane_buffer() is a rather complex function. While there is
nothing wrong with it per se, I have run into corner cases with clang-22
on s390 using KASAN that makes it run out of registers and blow the
stack warning limit from excessive spills:
drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2629:6: error: stack frame size (1560) exceeds limit (1536)
in 'tpg_fill_plane_buffer' [-Werror,-Wframe-larger-than]
2629 | void tpg_fill_plane_buffer(struct tpg_data *tpg, v4l2_std_id std,
Forcing the two largest callees out of line completely avoids the problem
and prevents all the register spills, with the stack usage for each function
going down to a few bytes for the local variables.
Arguably this is a problem caused by clang rather than the code, but
a noinline_for_stack annotation is an easy workaround.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide
dev->width / dev->norm but only refuse the change when the *video* queue
(dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry:
cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm,
the VBI videobuf2 plane is sized from dev->width / dev->norm in
vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then
recomputes the destination offset from the *live* dev->width and the
latched lines_per_field on every URB completion:
offset = lines_completed * (dev->width << 1) + ...;
if (dma_q->current_field == 2)
offset += dev->width * 2 * dma_q->lines_per_field;
memcpy(plane + offset, p_buffer, lencopy);
Because the VBI node shares video_ioctl_ops with the video node, an
application can size a small VBI plane (REQBUFS/QBUF with a small width,
or with the NTSC standard), then enlarge dev->width (or switch dev->norm
to PAL) through the video node while the VBI stream is running -- the
change is allowed because only dev->vidq is checked -- and let the device
deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the
offset with the larger geometry and memcpy()s past the end of the smaller
plane that was already allocated, a heap out-of-bounds write whose offset
is attacker-chosen and whose contents come from the device. The
per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the
copy against the latched lines_per_field, not the plane's real capacity,
and vb2 does not re-run buf_prepare() for an already prepared buffer.
Refuse the format/standard change when the VBI queue is busy as well, so
the geometry cannot change underneath an allocated VBI buffer.
Fixes: 7c617138b8 ("media: cx231xx: convert to the vb2 framework")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The HWS driver uses the V4L2 control handler callbacks provided by
hws_ctrl_ops and does not implement legacy vidioc_g_ctrl, vidioc_s_ctrl,
or vidioc_queryctrl callbacks.
Drop the stale prototypes from hws_v4l2_ioctl.h.
Signed-off-by: Ben Hoff <hoff.benjamin.k@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The driver and platform data refers to the legacy GPIO API,
doesn't really use it, and also calls some GPIO-related functions
passed as platform data.
This platform data is not used anywhere in the kernel.
I'm not outright deleting the driver, just deleting the bogus
GPIO handling. If outoftree developers want to fix up the
driver the GPIOs should be defined in some kind of firmware
node and be obtained using the gpiod_get*() APIs directly
in the driver, but I don't even know what these GPIOs are
since they are hidden in platform data that is not in the
mainline kernel, so what can I do.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(),
rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and
shares a single err: label that only unlocks the mutex and returns.
When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs()
itself returns -ENOMEM after alloc_stream_bufs() has already succeeded,
the URBs and/or the coherent DMA stream buffers stay allocated while
streaming reports failure to vb2. Two latent defects follow on the next
VIDIOC_STREAMON:
1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num
to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently
leaking the coherent DMA memory allocated by the previous attempt.
2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only
increments it. After a second successful pass urbs_initialized can
exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks
from urbs_initialized - 1 down to 0 and reads past the end of
dev->urb_list[], passing garbage pointers to usb_free_urb().
Mirror the teardown that stop_streaming() already performs: on the error
path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs()
before unlocking. Both helpers are idempotent (free_urbs kills and zeros
urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the
buf_num counter), so partial-failure paths and the no-allocation paths
remain safe.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/
Fixes: 771138920e ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
airspy_disconnect() clears s->udev under v4l2_lock, but
airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and
airspy_free_stream_bufs() afterwards. If a streaming user closes the
device after disconnect, stop_streaming() runs and dereferences the
NULL s->udev:
airspy_stop_streaming()
airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0)
usb_sndctrlpipe(s->udev, 0) /* NULL deref */
airspy_free_stream_bufs(s)
usb_free_coherent(s->udev, ...) /* NULL deref */
The airspy driver uses vb2_fop_release() in its file_operations, so
replace video_unregister_device(&s->vdev) with
vb2_video_unregister_device(&s->vdev) and move it before clearing
s->udev. vb2_video_unregister_device() releases the vb2 queue, which
synchronously runs airspy_stop_streaming() if streaming is active, so
the URBs, coherent DMA stream buffers and the hardware stop control
message all execute while s->udev is still valid.
vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock)
internally, and stop_streaming() locks v4l2_lock, so the previous outer
mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around
the unregister sequence would self-deadlock and has been removed. A
short v4l2_lock critical section around s->udev = NULL remains so any
ioctl path that still holds the file descriptor sees coherent state.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/
Fixes: 634fe50339 ("[media] airspy: AirSpy SDR driver")
Cc: stable@vger.kernel.org
Suggested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to
NULL before any pending streaming teardown has run. When user space
later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming()
which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases
each coherent buffer with:
usb_free_coherent(dev->udev, dev->buf_size,
dev->buf_list[dev->buf_num],
dev->dma_addr[dev->buf_num]);
usb_free_coherent() returns immediately when its dev argument is NULL,
so every DMA stream buffer that was live at disconnect is silently
leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the
device for the same reason.
The rtl2832_sdr driver uses vb2_fop_release() in its file_operations,
so replace video_unregister_device(&dev->vdev) with
vb2_video_unregister_device(&dev->vdev) and move it before clearing
dev->udev. vb2_video_unregister_device() releases the vb2 queue, which
synchronously runs rtl2832_sdr_stop_streaming() if streaming is active,
so URBs and coherent DMA stream buffers are freed while dev->udev is
still valid.
vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock)
internally, and stop_streaming() locks v4l2_lock, so the previous outer
mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair
around the unregister sequence would self-deadlock and has been removed.
A short v4l2_lock critical section around dev->udev = NULL remains so
any ioctl path that still holds the file descriptor sees coherent state.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/
Fixes: 771138920e ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Suggested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add support for the StarTech SVID2USB232 USB analog video grabber
(USB ID eb1a:8286). The device uses the Empia EM28281 bridge, a
member of the em2828X family with an integrated video decoder.
Reuses the EM28XX_BUILTIN decoder path introduced in commit
8e53399c63 ("media: em28xx: Add support for Empia em2828X bridge").
The standard PAL/NTSC switching and composite/S-Video input
switching in em2828X_decoder_set_std() handle this board without
board-specific code.
Inputs:
- Composite video
- S-Video
- Analog stereo audio (line in)
Tested on hardware with a PAL signal on both S-Video and composite
inputs (ffplay -f v4l2 /dev/video0).
This supersedes an earlier RFC posting from before EM28XX_BUILTIN was
available, which proposed a custom EM28XX_I2C_ALGO_EM28281_INTEGRATED
TVP5150-bridge algorithm. That approach is no longer necessary now that
the em2828X bridge support landed.
Link: https://lore.kernel.org/all/20260119185921.575666-1-xeeynamo@hotmail.com/
Signed-off-by: Luciano Ciccariello <xeeynamo@hotmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
