kernel/git/stable/linux-stable.git/drivers/media/usb, branch linux-6.10.y

media: b2c2: flexcop-usb: fix flexcop_usb_memory_req

2024-09-12T09:12:50+00:00

[ Upstream commit b178aa6f333b07bda0548d7e45085660a112414d ] smatch generated this warning: drivers/media/usb/b2c2/flexcop-usb.c:199 flexcop_usb_memory_req() warn: iterator 'i' not incremented and indeed the function is not using i or updating buf. The reason this always worked is that this function is called to write just 6 bytes (a MAC address) to the USB device, and so in practice there is only a single chunk written. If we ever would need to write more than one chunk, this function would fail since each chunk would read from or write to the same buf address. Rewrite the function to properly handle this. Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: uvcvideo: Enforce alignment of frame and interval

2024-09-08T05:56:40+00:00

[ Upstream commit c8931ef55bd325052ec496f242aea7f6de47dc9c ] Struct uvc_frame and interval (u32*) are packaged together on streaming->formats on a single contiguous allocation. Right now they are allocated right after uvc_format, without taking into consideration their required alignment. This is working fine because both structures have a field with a pointer, but it will stop working when the sizeof() of any of those structs is not a multiple of the sizeof(void*). Enforce that alignment during the allocation. Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240404-uvc-align-v2-1-9e104b0ecfbd@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin

media: Revert "media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()"

2024-08-19T04:05:40+00:00

commit 0c84bde4f37ba27d50e4c70ecacd33fe4a57030d upstream. This reverts commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c. This breaks the TeVii s480 dual DVB-S2 S660. The device has a bulk in endpoint but no corresponding out endpoint, so the device does not pass the "has both receive and send bulk endpoint" test. Seemingly this device does not use dvb_usb_generic_rw() so I have tried removing the generic_bulk_ctrl_endpoint entry, but this resulted in different problems. As we have no explanation yet, revert. $ dmesg | grep -i -e dvb -e dw21 -e usb\ 4 [ 0.999122] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 1.023123] usb 4-1: new high-speed USB device number 2 using ehci-pci [ 1.130247] usb 1-1: New USB device found, idVendor=9022, idProduct=d482, +bcdDevice= 0.01 [ 1.130257] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1.152323] usb 4-1: New USB device found, idVendor=9022, idProduct=d481, +bcdDevice= 0.01 [ 1.152329] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 6.701033] dvb-usb: found a 'TeVii S480.2 USB' in cold state, will try to +load a firmware [ 6.701178] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.701179] dw2102: start downloading DW210X firmware [ 6.703715] dvb-usb: found a 'Microsoft Xbox One Digital TV Tuner' in cold +state, will try to load a firmware [ 6.703974] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 6.756432] usb 1-1: USB disconnect, device number 2 [ 6.862119] dvb-usb: found a 'TeVii S480.2 USB' in warm state. [ 6.862194] dvb-usb: TeVii S480.2 USB error while loading driver (-22) [ 6.862209] dvb-usb: found a 'TeVii S480.1 USB' in cold state, will try to +load a firmware [ 6.862244] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw' [ 6.862245] dw2102: start downloading DW210X firmware [ 6.914811] usb 4-1: USB disconnect, device number 2 [ 7.014131] dvb-usb: found a 'TeVii S480.1 USB' in warm state. [ 7.014487] dvb-usb: TeVii S480.1 USB error while loading driver (-22) [ 7.014538] usbcore: registered new interface driver dw2102 Closes: https://lore.kernel.org/stable/20240801165146.38991f60@mir/ Fixes: 2052138b7da5 ("media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()") Reported-by: Stefan Lippers-Hollmann Cc: stable@vger.kernel.org Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix the bandwdith quirk on USB 3.x

2024-08-14T13:34:15+00:00

[ Upstream commit 9e3d55fbd160b3ca376599a68b4cddfdc67d4153 ] The bandwidth fixup quirk doesn't know that SuperSpeed exists and has the same 8 service intervals per millisecond as High Speed, hence its calculations are wrong. Assume that all speeds from HS up use 8 intervals per millisecond. No further changes are needed, updated code has been confirmed to work with all speeds from FS to SS. Signed-off-by: Michal Pecio Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240414190040.2255a0bc@foxbook Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin

media: uvcvideo: Ignore empty TS packets

2024-08-14T13:34:15+00:00

[ Upstream commit 5cd7c25f6f0576073b3d03bc4cfb1e8ca63a1195 ] Some SunplusIT cameras took a borderline interpretation of the UVC 1.5 standard, and fill the PTS and SCR fields with invalid data if the package does not contain data. "STC must be captured when the first video data of a video frame is put on the USB bus." Some SunplusIT devices send, e.g., buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000 buffer: 0xa7755c00 len 000012 header:0x8c stc 00000000 sof 0000 pts 00000000 buffer: 0xa7755c00 len 000668 header:0x8c stc 73779dba sof 070c pts 7376d37a While the UVC specification meant that the first two packets shouldn't have had the SCR bit set in the header. This borderline/buggy interpretation has been implemented in a variety of devices, from directly SunplusIT and from other OEMs that rebrand SunplusIT products. So quirking based on VID:PID will be problematic. All the affected modules have the following extension unit: VideoControl Interface Descriptor: guidExtensionCode {82066163-7050-ab49-b8cc-b3855e8d221d} But the vendor plans to use that GUID in the future and fix the bug, this means that we should use heuristic to figure out the broken packets. This patch takes care of this. lsusb of one of the affected cameras: Bus 001 Device 003: ID 1bcf:2a01 Sunplus Innovation Technology Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1bcf Sunplus Innovation Technology Inc. idProduct 0x2a01 bcdDevice 0.02 iManufacturer 1 SunplusIT Inc iProduct 2 HanChen Wise Camera iSerial 3 01.00.00 bNumConfigurations 1 Tested-by: HungNien Chen Reviewed-by: Sergey Senozhatsky Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20240323-resend-hwtimestamp-v10-2-b08e590d97c7@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin

media: uvcvideo: Fix integer overflow calculating timestamp

2024-08-03T07:00:40+00:00

commit 8676a5e796fa18f55897ca36a94b2adf7f73ebd1 upstream. The function uvc_video_clock_update() supports a single SOF overflow. Or in other words, the maximum difference between the first ant the last timestamp can be 4096 ticks or 4.096 seconds. This results in a maximum value for y2 of: 0x12FBECA00, that overflows 32bits. y2 = (u32)ktime_to_ns(ktime_sub(last->host_time, first->host_time)) + y1; Extend the size of y2 to u64 to support all its values. Without this patch: # yavta -s 1920x1080 -f YUYV -t 1/5 -c /dev/video0 Device /dev/v4l/by-id/usb-Shine-Optics_Integrated_Camera_0001-video-index0 opened. Device `Integrated Camera: Integrated C' on `usb-0000:00:14.0-6' (driver 'uvcvideo') supports video, capture, without mplanes. Video format set: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200 Video format: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200 Current frame rate: 1/5 Setting frame rate to: 1/5 Frame rate set: 1/5 8 buffers requested. length: 4147200 offset: 0 timestamp type/source: mono/SoE Buffer 0/0 mapped at address 0x7947ea94c000. length: 4147200 offset: 4149248 timestamp type/source: mono/SoE Buffer 1/0 mapped at address 0x7947ea557000. length: 4147200 offset: 8298496 timestamp type/source: mono/SoE Buffer 2/0 mapped at address 0x7947ea162000. length: 4147200 offset: 12447744 timestamp type/source: mono/SoE Buffer 3/0 mapped at address 0x7947e9d6d000. length: 4147200 offset: 16596992 timestamp type/source: mono/SoE Buffer 4/0 mapped at address 0x7947e9978000. length: 4147200 offset: 20746240 timestamp type/source: mono/SoE Buffer 5/0 mapped at address 0x7947e9583000. length: 4147200 offset: 24895488 timestamp type/source: mono/SoE Buffer 6/0 mapped at address 0x7947e918e000. length: 4147200 offset: 29044736 timestamp type/source: mono/SoE Buffer 7/0 mapped at address 0x7947e8d99000. 0 (0) [-] none 0 4147200 B 507.554210 508.874282 242.836 fps ts mono/SoE 1 (1) [-] none 2 4147200 B 508.886298 509.074289 0.751 fps ts mono/SoE 2 (2) [-] none 3 4147200 B 509.076362 509.274307 5.261 fps ts mono/SoE 3 (3) [-] none 4 4147200 B 509.276371 509.474336 5.000 fps ts mono/SoE 4 (4) [-] none 5 4147200 B 509.476394 509.674394 4.999 fps ts mono/SoE 5 (5) [-] none 6 4147200 B 509.676506 509.874345 4.997 fps ts mono/SoE 6 (6) [-] none 7 4147200 B 509.876430 510.074370 5.002 fps ts mono/SoE 7 (7) [-] none 8 4147200 B 510.076434 510.274365 5.000 fps ts mono/SoE 8 (0) [-] none 9 4147200 B 510.276421 510.474333 5.000 fps ts mono/SoE 9 (1) [-] none 10 4147200 B 510.476391 510.674429 5.001 fps ts mono/SoE 10 (2) [-] none 11 4147200 B 510.676434 510.874283 4.999 fps ts mono/SoE 11 (3) [-] none 12 4147200 B 510.886264 511.074349 4.766 fps ts mono/SoE 12 (4) [-] none 13 4147200 B 511.070577 511.274304 5.426 fps ts mono/SoE 13 (5) [-] none 14 4147200 B 511.286249 511.474301 4.637 fps ts mono/SoE 14 (6) [-] none 15 4147200 B 511.470542 511.674251 5.426 fps ts mono/SoE 15 (7) [-] none 16 4147200 B 511.672651 511.874337 4.948 fps ts mono/SoE 16 (0) [-] none 17 4147200 B 511.873988 512.074462 4.967 fps ts mono/SoE 17 (1) [-] none 18 4147200 B 512.075982 512.278296 4.951 fps ts mono/SoE 18 (2) [-] none 19 4147200 B 512.282631 512.482423 4.839 fps ts mono/SoE 19 (3) [-] none 20 4147200 B 518.986637 512.686333 0.149 fps ts mono/SoE 20 (4) [-] none 21 4147200 B 518.342709 512.886386 -1.553 fps ts mono/SoE 21 (5) [-] none 22 4147200 B 517.909812 513.090360 -2.310 fps ts mono/SoE 22 (6) [-] none 23 4147200 B 517.590775 513.294454 -3.134 fps ts mono/SoE 23 (7) [-] none 24 4147200 B 513.298465 513.494335 -0.233 fps ts mono/SoE 24 (0) [-] none 25 4147200 B 513.510273 513.698375 4.721 fps ts mono/SoE 25 (1) [-] none 26 4147200 B 513.698904 513.902327 5.301 fps ts mono/SoE 26 (2) [-] none 27 4147200 B 513.895971 514.102348 5.074 fps ts mono/SoE 27 (3) [-] none 28 4147200 B 514.099091 514.306337 4.923 fps ts mono/SoE 28 (4) [-] none 29 4147200 B 514.310348 514.510567 4.734 fps ts mono/SoE 29 (5) [-] none 30 4147200 B 514.509295 514.710367 5.026 fps ts mono/SoE 30 (6) [-] none 31 4147200 B 521.532513 514.914398 0.142 fps ts mono/SoE 31 (7) [-] none 32 4147200 B 520.885277 515.118385 -1.545 fps ts mono/SoE 32 (0) [-] none 33 4147200 B 520.411140 515.318336 -2.109 fps ts mono/SoE 33 (1) [-] none 34 4147200 B 515.325425 515.522278 -0.197 fps ts mono/SoE 34 (2) [-] none 35 4147200 B 515.538276 515.726423 4.698 fps ts mono/SoE 35 (3) [-] none 36 4147200 B 515.720767 515.930373 5.480 fps ts mono/SoE Cc: stable@vger.kernel.org Fixes: 66847ef013cc ("[media] uvcvideo: Add UVC timestamps support") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240610-hwtimestamp-followup-v1-2-f9eaed7be7f0@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Override default flags

2024-08-03T06:59:56+00:00

[ Upstream commit 86419686e66da5b90a07fb8a40ab138fe97189b5 ] When the UVC device has a control that is readonly it doesn't set the SET_CUR flag. For example the privacy control has SET_CUR flag set in the defaults in the `uvc_ctrls` variable. Even if the device does not have it set, it's not cleared by uvc_ctrl_get_flags(). Originally written with assignment in commit 859086ae3636 ("media: uvcvideo: Apply flags from device to actual properties"). But changed to |= in commit 0dc68cabdb62 ("media: uvcvideo: Prevent setting unavailable flags"). It would not clear the default flags. With this patch applied the correct flags are reported to user space. Tested with: ``` > v4l2-ctl --list-ctrls | grep privacy privacy 0x009a0910 (bool) : default=0 value=0 flags=read-only ``` Signed-off-by: Daniel Schaefer Fixes: 0dc68cabdb62 ("media: uvcvideo: Prevent setting unavailable flags") Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240602065053.36850-1-dhs@frame.work Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin

media: uvcvideo: Add quirk for invalid dev_sof in Logitech C920

2024-08-03T06:59:56+00:00

[ Upstream commit 85fbe91a7c9210bb30638846b551fa5d3cb7bc4c ] Similarly to Logitech C922, C920 seems to also suffer from a firmware bug that breaks hardware timestamping. Add a quirk for this camera model too. Before applying the quirk: ``` 100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE 101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE 102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE 103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE 104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE 105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE 106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE … ``` After applying the quirk: ``` 154 (2) [-] none 154 192417 B 42.199823 42.207788 27.779 fps ts mono/SoE 155 (3) [-] none 155 192040 B 42.231834 42.239791 31.239 fps ts mono/SoE 156 (4) [-] none 156 192213 B 42.263823 42.271822 31.261 fps ts mono/SoE 157 (5) [-] none 157 191981 B 42.299824 42.303827 27.777 fps ts mono/SoE 158 (6) [-] none 158 191953 B 42.331835 42.339811 31.239 fps ts mono/SoE 159 (7) [-] none 159 191904 B 42.363824 42.371813 31.261 fps ts mono/SoE 160 (0) [-] none 160 192210 B 42.399834 42.407801 27.770 fps ts mono/SoE ``` Fixes: 5d0fd3c806b9 ("[media] uvcvideo: Disable hardware timestamps by default") Signed-off-by: Oleksandr Natalenko Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240325142611.15550-1-oleksandr@natalenko.name Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin

media: uvcvideo: Quirk for invalid dev_sof in Logitech C922

2024-08-03T06:59:55+00:00

[ Upstream commit 9183c6f1a21e0da4415762c504e2d7f784304d12 ] Logitech C922 internal SOF does not increases at a stable rate of 1kHz. This causes that the device_sof and the host_sof run at different rates, breaking the clock domain conversion algorithm. Eg: 30 (6) [-] none 30 614400 B 21.245557 21.395214 34.133 fps ts mono/SoE 31 (7) [-] none 31 614400 B 21.275327 21.427246 33.591 fps ts mono/SoE 32 (0) [-] none 32 614400 B 21.304739 21.459256 34.000 fps ts mono/SoE 33 (1) [-] none 33 614400 B 21.334324 21.495274 33.801 fps ts mono/SoE * 34 (2) [-] none 34 614400 B 21.529237 21.527297 5.130 fps ts mono/SoE * 35 (3) [-] none 35 614400 B 21.649416 21.559306 8.321 fps ts mono/SoE 36 (4) [-] none 36 614400 B 21.678789 21.595320 34.045 fps ts mono/SoE ... 99 (3) [-] none 99 614400 B 23.542226 23.696352 33.541 fps ts mono/SoE 100 (4) [-] none 100 614400 B 23.571578 23.728404 34.069 fps ts mono/SoE 101 (5) [-] none 101 614400 B 23.601425 23.760420 33.504 fps ts mono/SoE * 102 (6) [-] none 102 614400 B 23.798324 23.796428 5.079 fps ts mono/SoE * 103 (7) [-] none 103 614400 B 23.916271 23.828450 8.478 fps ts mono/SoE 104 (0) [-] none 104 614400 B 23.945720 23.860479 33.957 fps ts mono/SoE Instead of disabling completely the hardware timestamping for such hardware we take the assumption that the packet handling jitter is under 2ms and use the host_sof as dev_sof. We can think of the UVC hardware clock as a system with a coarse clock (the SOF) and a fine clock (the PTS). The coarse clock can be replaced with a clock on the same frequency, if the jitter of such clock is smaller than its sampling rate. That way we can save some of the precision of the fine clock. To probe this point we have run three experiments on the Logitech C922. On that experiment we run the camera at 33fps and we analyse the difference in msec between a frame and its predecessor. If we display the histogram of that value, a thinner histogram will mean a better meassurement. The results for: - original hw timestamp: https://ibb.co/D1HJJ4x - pure software timestamp: https://ibb.co/QC9MgVK - modified hw timestamp: https://ibb.co/8s9dBdk This bug in the camera firmware has been confirmed by the vendor. lsusb -v Bus 001 Device 044: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x046d Logitech, Inc. idProduct 0x085c C922 Pro Stream Webcam bcdDevice 0.16 iManufacturer 0 iProduct 2 C922 Pro Stream Webcam iSerial 1 80B912DF bNumConfigurations 1 Reviewed-by: Sergey Senozhatsky Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Ricardo Ribalda Signed-off-by: Oleksandr Natalenko Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20240323-resend-hwtimestamp-v10-3-b08e590d97c7@chromium.org Signed-off-by: Laurent Pinchart Stable-dep-of: 85fbe91a7c92 ("media: uvcvideo: Add quirk for invalid dev_sof in Logitech C920") Signed-off-by: Sasha Levin

media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control()

2024-08-03T06:59:52+00:00

[ Upstream commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c ] Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, we need to add endpoint check for 'generic_bulk_ctrl_endpoint'. And as Sean suggested, the same check and clear halts should be done for 'generic_bulk_ctrl_endpoint_response'. So introduce dvb_usb_check_bulk_endpoint() to do it for both of them. Fixes: 4d43e13f723e ("V4L/DVB (4643): Multi-input patch for DVB-USB device") Signed-off-by: Zheng Yejian Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin