linux-stable.git/drivers/media/usb, branch linux-rolling-stable Linux kernel stable tree media: uvcvideo: Fix sequence number when no EOF 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-03-23T09:53:52+00:00 cf5f54c018967394f54ea196a98f4f016f70eb89 commit f078966ca1fb1b3865d8e6bbe2705cfd277fc637 upstream. If the driver could not detect the EOF, the sequence number is increased twice: 1) When we enter uvc_video_decode_start() with the old buffer and FID has flipped => We return -EAGAIN and last_fid is not flipped 2) When we enter uvc_video_decode_start() with the new buffer. Fix this issue by moving the new frame detection logic earlier in uvc_video_decode_start(). This also has some nice side affects: - The error status from the new packet will no longer get propagated to the previous frame-buffer. - uvc_video_clock_decode() will no longer update the previous frame buf->stf with info from the new packet. - uvc_video_clock_decode() and uvc_video_stats_decode() will no longer get called twice for the same packet. Cc: stable@kernel.org Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost") Reported-by: Hans de Goede <hansg@kernel.org> Closes: https://lore.kernel.org/linux-media/CANiDSCuj4cPuB5_v2xyvAagA5FjoN8V5scXiFFOeD3aKDMqkCg@mail.gmail.com/T/#me39fb134e8c2c085567a31548c3403eb639625e4 Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f078966ca1fb1b3865d8e6bbe2705cfd277fc637 upstream.

If the driver could not detect the EOF, the sequence number is increased
twice:
 1) When we enter uvc_video_decode_start() with the old buffer and FID has
   flipped => We return -EAGAIN and last_fid is not flipped
 2) When we enter uvc_video_decode_start() with the new buffer.

Fix this issue by moving the new frame detection logic earlier in
uvc_video_decode_start().

This also has some nice side affects:

- The error status from the new packet will no longer get propagated
  to the previous frame-buffer.
- uvc_video_clock_decode() will no longer update the previous frame
  buf->stf with info from the new packet.
- uvc_video_clock_decode() and uvc_video_stats_decode() will no longer
  get called twice for the same packet.

Cc: stable@kernel.org
Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost")
Reported-by: Hans de Goede <hansg@kernel.org>
Closes: https://lore.kernel.org/linux-media/CANiDSCuj4cPuB5_v2xyvAagA5FjoN8V5scXiFFOeD3aKDMqkCg@mail.gmail.com/T/#me39fb134e8c2c085567a31548c3403eb639625e4
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Relax the constrains for interpolating the hw clock 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-05-13T11:49:22+00:00 f3970948369e41569a566fb37615c64e397661c8 commit 1719d78f832dda8dd3f09a867ba74e05d6f11308 upstream. In the initial version we set the min value to 250msec. Looks like 100msec can also provide a good value. Now that we are at it, add a macro to make it cleaner. Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Yunke Cao <yunkec@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-3-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1719d78f832dda8dd3f09a867ba74e05d6f11308 upstream.

In the initial version we set the min value to 250msec. Looks like
100msec can also provide a good value.

Now that we are at it, add a macro to make it cleaner.

Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full")
Cc: stable@vger.kernel.org
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Tested-by: Yunke Cao <yunkec@google.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-3-7a64838b0b02@chromium.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Do not add clock samples with small sof delta 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-05-13T11:49:23+00:00 600e379bd5891ff1d530418b5a0513c981157aa8 commit ba649fff36c1fe68489a86d00285224907edd436 upstream. Some UVC 1.1 cameras running in fast isochronous mode tend to spam the USB host with a lot of empty packets. These packets contain clock information and are added to the clock buffer but do not add any accuracy to the calculation. In fact, it is quite the opposite, in our calculations, only the first and the last timestamp is used, and we only have 32 slots. Ignore the samples that will produce less than MIN_HW_TIMESTAMP_DIFF data. Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer") Cc: stable@vger.kernel.org Tested-by: Yunke Cao <yunkec@google.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-4-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ba649fff36c1fe68489a86d00285224907edd436 upstream.

Some UVC 1.1 cameras running in fast isochronous mode tend to spam the
USB host with a lot of empty packets. These packets contain clock
information and are added to the clock buffer but do not add any
accuracy to the calculation. In fact, it is quite the opposite, in our
calculations, only the first and the last timestamp is used, and we only
have 32 slots.

Ignore the samples that will produce less than MIN_HW_TIMESTAMP_DIFF
data.

Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer")
Cc: stable@vger.kernel.org
Tested-by: Yunke Cao <yunkec@google.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-4-7a64838b0b02@chromium.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Fix dev_sof filtering in hw timestamp 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-05-13T11:49:20+00:00 40aaf991dc0a7928b72500d3119c974956aa8216 commit edc1917599c5339aedc83135cade66517e0a2972 upstream. To avoid filling the clock circular buffer with duplicated data we only add it if the new value sof is different than the last added sof. The issue is that we compare the unprocess sof with the processed sof. If there is a sof_offset, or UVC_QUIRK_INVALID_DEVICE_SOF is enabled, the comparison will not work as expected. This patch moves the comparison to the right place. Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Yunke Cao <yunkec@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-1-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit edc1917599c5339aedc83135cade66517e0a2972 upstream.

To avoid filling the clock circular buffer with duplicated data we only
add it if the new value sof is different than the last added sof.

The issue is that we compare the unprocess sof with the processed sof.
If there is a sof_offset, or UVC_QUIRK_INVALID_DEVICE_SOF is enabled,
the comparison will not work as expected.

This patch moves the comparison to the right place.

Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer")
Cc: stable@vger.kernel.org
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Tested-by: Yunke Cao <yunkec@google.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-1-7a64838b0b02@chromium.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Fix buffer sequence in frame gaps 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-03-23T09:53:53+00:00 c082b0ed2db6d6f9e369f1855cfbef78cc7bb205 commit 2f24ac8dd87983a55f0498898f34a5f2b735b802 upstream. In UVC, the FID flips with every frame. For every FID flip, we increase the stream sequence number. Now, if a FID flips multiple times and there is no data transferred between the flips, the buffer sequence number will be set to the value of the stream sequence number after the first flip. Userspace uses the buffer sequence number to determine if there have been missing frames. With the current behaviour, userspace will think that the gap is in the wrong location. This patch modifies uvc_video_decode_start() to provide the correct buffer sequence number and timestamp. Cc: stable@kernel.org Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2f24ac8dd87983a55f0498898f34a5f2b735b802 upstream.

In UVC, the FID flips with every frame. For every FID flip, we increase
the stream sequence number.

Now, if a FID flips multiple times and there is no data transferred between
the flips, the buffer sequence number will be set to the value of the
stream sequence number after the first flip.

Userspace uses the buffer sequence number to determine if there have been
missing frames. With the current behaviour, userspace will think that the
gap is in the wrong location.

This patch modifies uvc_video_decode_start() to provide the correct buffer
sequence number and timestamp.

Cc: stable@kernel.org
Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Avoid partial metadata buffers 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-04-17T05:19:29+00:00 b058d9a21694466e83d4dc3213a94397c4d87ab8 commit a15b773fe4ffa450b56347cc506b2d1405600f5d upstream. If the metadata queue that is empty receives a new buffer while we are in the middle of processing a frame, the first metadata buffer will contain partial information. Avoid this by tracking the state of the metadata buffer and making sure that it is in sync with the data buffer. Now that we are at it, make sure that we skip buffers of size 1 or 0. They are not allowed by the spec... but it is a simple check to add and better be safe than sorry. Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20260417-uvc-meta-partial-v2-2-31d274af7d2d@chromium.org Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a15b773fe4ffa450b56347cc506b2d1405600f5d upstream.

If the metadata queue that is empty receives a new buffer while we are
in the middle of processing a frame, the first metadata buffer will
contain partial information.

Avoid this by tracking the state of the metadata buffer and making sure
that it is in sync with the data buffer.

Now that we are at it, make sure that we skip buffers of size 1 or 0.
They are not allowed by the spec... but it is a simple check to add and
better be safe than sorry.

Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node")
Cc: stable@vger.kernel.org
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20260417-uvc-meta-partial-v2-2-31d274af7d2d@chromium.org
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Use hw timestaming if the clock buffer is full 2026-07-24T14:18:59+00:00 Ricardo Ribalda ribalda@chromium.org 2026-05-13T11:49:21+00:00 ca4c918226845ea3ea2c60e538f7e5920d25207a commit ede7de6e6b3db552d10ac50557d69c50d1b08486 upstream. In some situations, even with a full clock buffer, it does not contain 250msec of data. This results in the driver jumping back from software to hardware timestapsing creating a nasty artifact in the video. If the clock buffer is full, use it to calculate the timestamp instead of defaulting to software stamps, the reduced accuracy is less visible than jumping from one timestamping mechanism to the other. Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Yunke Cao <yunkec@google.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-2-7a64838b0b02@chromium.org Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ede7de6e6b3db552d10ac50557d69c50d1b08486 upstream.

In some situations, even with a full clock buffer, it does not contain
250msec of data. This results in the driver jumping back from software
to hardware timestapsing creating a nasty artifact in the video.

If the clock buffer is full, use it to calculate the timestamp instead
of defaulting to software stamps, the reduced accuracy is less visible
than jumping from one timestamping mechanism to the other.

Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full")
Cc: stable@vger.kernel.org
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Tested-by: Yunke Cao <yunkec@google.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-2-7a64838b0b02@chromium.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work 2026-07-24T14:18:58+00:00 Sean Anderson sean.anderson@linux.dev 2026-03-16T15:58:22+00:00 7f6c5fe1633272c926361b73d83dfc6ae01b1504 [ Upstream commit 6d27f92c54ce28cfbd2a8a479a96d6f4a781b7d2 ] If a UVC camera has an asynchronous control, uvc_status_stop may be called from async_ctrl.work: uvc_ctrl_status_event_work() uvc_ctrl_status_event() uvc_ctrl_clear_handle() uvc_pm_put() uvc_status_put() uvc_status_stop() cancel_work_sync() This will cause a deadlock, since cancel_work_sync will wait for uvc_ctrl_status_event_work to complete before returning. Fix this by returning early from uvc_status_stop if we are currently in the work function. flush_status now remains false until uvc_status_start is called again, ensuring that uvc_ctrl_status_event_work won't resubmit the URB. Fixes: a32d9c41bdb8 ("media: uvcvideo: Make power management granular") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/6733bdfb-3e88-479f-8956-ab09c04c433e@linux.dev/ Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20260316155823.1855434-1-sean.anderson@linux.dev Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Tested-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6d27f92c54ce28cfbd2a8a479a96d6f4a781b7d2 ]

If a UVC camera has an asynchronous control, uvc_status_stop may be
called from async_ctrl.work:

uvc_ctrl_status_event_work()
    uvc_ctrl_status_event()
        uvc_ctrl_clear_handle()
	    uvc_pm_put()
	        uvc_status_put()
		    uvc_status_stop()
		        cancel_work_sync()

This will cause a deadlock, since cancel_work_sync will wait for
uvc_ctrl_status_event_work to complete before returning.

Fix this by returning early from uvc_status_stop if we are currently in
the work function. flush_status now remains false until uvc_status_start
is called again, ensuring that uvc_ctrl_status_event_work won't resubmit
the URB.

Fixes: a32d9c41bdb8 ("media: uvcvideo: Make power management granular")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/6733bdfb-3e88-479f-8956-ab09c04c433e@linux.dev/
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://patch.msgid.link/20260316155823.1855434-1-sean.anderson@linux.dev
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Tested-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'media/v7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 2026-04-15T15:32:10+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-15T15:32:10+00:00 00c6649bafef628955569dd39a59e3170e48f7b5 Pull media updates from Mauro Carvalho Chehab: - new CSI tegra support, covering Tegra20 and Tegra30 - new camera sensor drivers: T4ka3 and ov2732 - m88ds3103: add 3103c chip support - uvcvideo: add support for Intel RealSense D436/D555 and P010 pixel format - synopsys csi2rx: add i.MX93 support - imx8-isi: add i.MX95 support - imx8mq-mipi-csi2: add i.MX8ULP support - dw100: add V4L2 requests support - support for DTV devices from Hauppauge got some improvements - media staging: dropped starfive-camss driver - media docs: document multi-committers model and improve maint profile - media core: - add v4l2_subdev_get_frame_desc_passthrough() helper - improve error handling in fwnode parsing - lots of driver fixes, cleanups and improvements * tag 'media/v7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (251 commits) Revert "media: cx231xx: add USB ID 2040:8360 for Hauppauge WinTV-HVR-935" media: synopsys: csi2rx: add i.MX93 support media: dt-bindings: add NXP i.MX93 compatible string media: synopsys: csi2rx: Use enum and u32 array for register offsets media: synopsys: csi2rx: implement .get_frame_desc() callback media: synopsys: csi2rx: only check errors from devm_clk_bulk_get_all() media: synopsys: csi2rx: use devm_reset_control_get_optional_exclusive() media: i2c: imx283: add support for non-continuous MIPI clock mode media: i2c: ov08d10: add support for 24 MHz input clock media: i2c: ov08d10: add support for reset and power management media: i2c: ov08d10: add support for binding via device tree dt-bindings: media: i2c: document Omnivision OV08D10 CMOS image sensor media: i2c: ov08d10: add missing newline to prints media: i2c: ov08d10: fix some typos in comments media: i2c: ov08d10: remove duplicate register write media: i2c: ov08d10: fix image vertical start setting media: i2c: ov08d10: fix runtime PM handling in probe staging: media: ipu7: Update TODO media: Add t4ka3 camera sensor driver media: i2c: Add ov2732 image sensor driver ... 
Pull media updates from Mauro Carvalho Chehab:

 - new CSI tegra support, covering Tegra20 and Tegra30

 - new camera sensor drivers: T4ka3 and ov2732

 - m88ds3103: add 3103c chip support

 - uvcvideo: add support for Intel RealSense D436/D555 and P010 pixel format

 - synopsys csi2rx: add i.MX93 support

 - imx8-isi: add i.MX95 support

 - imx8mq-mipi-csi2: add i.MX8ULP support

 - dw100: add V4L2 requests support

 - support for DTV devices from Hauppauge got some improvements

 - media staging: dropped starfive-camss driver

 - media docs: document multi-committers model and improve maint profile

 - media core:
    - add v4l2_subdev_get_frame_desc_passthrough() helper
    - improve error handling in fwnode parsing

 - lots of driver fixes, cleanups and improvements

* tag 'media/v7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (251 commits)
  Revert "media: cx231xx: add USB ID 2040:8360 for Hauppauge WinTV-HVR-935"
  media: synopsys: csi2rx: add i.MX93 support
  media: dt-bindings: add NXP i.MX93 compatible string
  media: synopsys: csi2rx: Use enum and u32 array for register offsets
  media: synopsys: csi2rx: implement .get_frame_desc() callback
  media: synopsys: csi2rx: only check errors from devm_clk_bulk_get_all()
  media: synopsys: csi2rx: use devm_reset_control_get_optional_exclusive()
  media: i2c: imx283: add support for non-continuous MIPI clock mode
  media: i2c: ov08d10: add support for 24 MHz input clock
  media: i2c: ov08d10: add support for reset and power management
  media: i2c: ov08d10: add support for binding via device tree
  dt-bindings: media: i2c: document Omnivision OV08D10 CMOS image sensor
  media: i2c: ov08d10: add missing newline to prints
  media: i2c: ov08d10: fix some typos in comments
  media: i2c: ov08d10: remove duplicate register write
  media: i2c: ov08d10: fix image vertical start setting
  media: i2c: ov08d10: fix runtime PM handling in probe
  staging: media: ipu7: Update TODO
  media: Add t4ka3 camera sensor driver
  media: i2c: Add ov2732 image sensor driver
  ...
Revert "media: cx231xx: add USB ID 2040:8360 for Hauppauge WinTV-HVR-935" 2026-03-26T21:27:24+00:00 Bradford Love brad@nextdimension.cc 2026-03-26T17:10:23+00:00 4fbeef21f5387234111b5d52924e77757626faa5 This reverts commit bb2a3912549d3b5cef5ed27200402fe8f6fb0694. The USB ID 2040:8360 was reported as a new revision of Hauppauge HVR-935 and requested to be added to the cx231xx driver. The issue is current generation of Hauppauge 9x5 devices including 935, 955, and 975 have moved to em2828x usb bridge. Support for the em2828x usb bridge and USB ID's for the new devices has been submitted. Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
This reverts commit bb2a3912549d3b5cef5ed27200402fe8f6fb0694.

The USB ID 2040:8360 was reported as a new revision
of Hauppauge HVR-935 and requested to be added to
the cx231xx driver. The issue is current generation
of Hauppauge 9x5 devices including 935, 955, and 975
have moved to em2828x usb bridge. Support for the
em2828x usb bridge and USB ID's for the new devices
has been submitted.

Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>