| Age | Commit message (Collapse) | Author |
|---|
|
This reverts a patch which was perhaps inadvertently added.
This was changed during the 5.15-rc4 merge. The faulty commit appears
lost in the pull request somehow, I cannot find it to check the
explanation.
commit c52e7b855b33 ("Merge tag 'v5.15-rc4' into media_tree")
There was nothing wrong with this device and no reason to moodify the
board profile. The DVB capabilities are added via dvb_module_probe.
Additionally, the device contains *zero* analog inputs, so I'm not
sure why one was added.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Include possible vid:pid combination of DualHD models
that are in the wild.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
New HVR1265 and ImpactVCB-e devices are PCIe baords
with USB controller and essentially embedded
Hauppauge 950Q.
HVR1265 - digital+analog TV, S-Video, and audio inputs
ImpactVCB-e - Composite, S-Video, and audio inputs
This also fixes AU8522_COMPOSITE_CH4, which was missing
from video routing.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The wrong firmware file is listed, leading to non functional devices
on REV2 models.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Ignoring version 4.0-11 firmware leads to non functional devices
after sleep on all Hauppauge DVB devices containing the si2168 and
firmware version 4.0-11.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
On many embedded platforms i2c responses through USB are not returned
as quickly, plus constantly banging on the i2c master receive essentially
deadlocks the driver. Inserting a 3ms delay between i2c receive calls
and extending the timeout fixes all tested platforms.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Windows uses the implemented command sequence to set AGC for NTSC-M.
The previous Linux values work, mostly, but on some embedded
platforms NTSC-M is very unstable. The Windows default values
completely fix any signal stability issues and produce a clear image.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Without a rf strength function implemented, analog lock
cannot be detected by standardized command line tools.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Formats did not correctly decode prior.
Modifications are based off cx25840 datasheet.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Updates to support PAL-N and PAL-Nc
Verifies PAL-I and PAL-DK standards are working
Fixes and verifies SECAM-L now works
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Use the sensor's pre-calculated jiffies value to add appropriate
delay between frames according to the configured timing value.
The actual frame rate will vary depending on processing delays in
other media pipeline components.
Tested using yavta frame rate display with QCIF resolution:
yavta <video-node> --capture=<no_of_frames>
Signed-off-by: Faizel K B <faizel.kb@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
pixel_rate and hblank as read only parameter. vblank can be configured
to match the desired frame rate.
Default values are, pixel_rate - 160 MHz, hblank - 800.
vblank defaults to an equivalent value of 30 fps for resolutions less than
or equal to 1920x1080 and 10 fps for higher resolutions. For higher
resolutions, modify pixel_rate in the driver code.
fps = pixel_rate / ((width + hblank) * (height + vblank))
minimum vblank - 4, maximum vblank - 65535
The configured fps delay is pre-calculated into jiffies and
stored in the sensor's hw structure for efficient access by the
streamer thread.
Signed-off-by: Faizel K B <faizel.kb@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Move the vimc_sensor_device structure from vimc-sensor.c to
vimc-common.h to make it accessible to the vimc-streamer component.
Signed-off-by: Faizel K B <faizel.kb@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
as102_usb_probe()
In as102_usb driver, the following race condition occurs:
```
CPU0 CPU1
as102_usb_probe()
kzalloc(); // alloc as102_dev_t
....
usb_register_dev();
fd = sys_open("/path/to/dev"); // open as102 fd
....
usb_deregister_dev();
....
kfree(); // free as102_dev_t
....
sys_close(fd);
as102_release() // UAF!!
as102_usb_release()
kfree(); // DFB!!
```
When a USB character device registered with usb_register_dev() is later
unregistered (via usb_deregister_dev() or disconnect), the device node is
removed so new open() calls fail. However, file descriptors that are
already open do not go away immediately: they remain valid until the last
reference is dropped and the driver's .release() is invoked.
In as102, as102_usb_probe() calls usb_register_dev() and then, on an
error path, does usb_deregister_dev() and frees as102_dev_t right away.
If userspace raced a successful open() before the deregistration, that
open FD will later hit as102_release() --> as102_usb_release() and access
or free as102_dev_t again, occur a race to use-after-free and
double-free vuln.
The fix is to never kfree(as102_dev_t) directly once usb_register_dev()
has succeeded. After deregistration, defer freeing memory to .release().
In other words, let release() perform the last kfree when the final open
FD is closed.
Cc: <stable@vger.kernel.org>
Reported-by: syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db
Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
hackrf_probe()
In hackrf driver, the following race condition occurs:
```
CPU0 CPU1
hackrf_probe()
kzalloc(); // alloc hackrf_dev
....
v4l2_device_register();
....
fd = sys_open("/path/to/dev"); // open hackrf fd
....
v4l2_device_unregister();
....
kfree(); // free hackrf_dev
....
sys_ioctl(fd, ...);
v4l2_ioctl();
video_is_registered() // UAF!!
....
sys_close(fd);
v4l2_release() // UAF!!
hackrf_video_release()
kfree(); // DFB!!
```
When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.
However, file descriptors that are already open-and any in-flight I/O-do
not terminate immediately; they remain valid until the last reference is
dropped and the driver's release() is invoked.
Therefore, freeing device memory on the error path after hackrf_probe()
has registered dev it will lead to a race to use-after-free vuln, since
those already-open handles haven't been released yet.
And since release() free memory too, race to use-after-free and
double-free vuln occur.
To prevent this, if device is registered from probe(), it should be
modified to free memory only through release() rather than calling
kfree() directly.
Cc: <stable@vger.kernel.org>
Reported-by: syzbot+6ffd76b5405c006a46b7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6ffd76b5405c006a46b7
Reported-by: syzbot+f1b20958f93d2d250727@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f1b20958f93d2d250727
Fixes: 8bc4a9ed8504 ("[media] hackrf: add support for transmitter")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The Hauppauge WinTV-HVR-935 HD stick is supported as 2040:b151
(CX231XX_BOARD_HAUPPAUGE_935C).
Some units report USB id 2040:8360 with product string "HVR-935 Audio"
and are not bound by cx231xx, so no DVB adapter is created.
Please consider adding 2040:8360 to the cx231xx_id_table with the same
driver_info as 0xb151 so these devices work without out-of-tree
patches.
How the ID was obtained (Debian, kernel 6.1.0-40-amd64):
$ lsusb -d 2040:8360
Bus 001 Device 006: ID 2040:8360 Hauppauge HVR-935 Audio
$ lsusb -t | grep -A3 "Port 3"
|__ Port 3: Dev 6, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 3: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 3: Dev 6, If 1, Class=Audio, Driver=snd-usb-audio, 480M
Interface 0 (Vendor Specific) has no driver; the stock cx231xx module
has no 2040:8360 in its alias table.
Reported-by: Lucian Onicescu <lucian.onicescu@gmail.com>
Closes: https://lore.kernel.org/linux-media/CALbYB1O79OnqKMF--HWVx-nuKtYKJbE+Ux=yK_45HDb4oujQyA@mail.gmail.com/
Suggested-by: Lucian Onicescu <lucian.onicescu@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Add checks for ioremap return values in saa7164_dev_setup(). If
ioremap for BAR0 or BAR2 fails, release the already allocated PCI
memory regions, remove the device from the global list, decrement
the device count, and return -ENODEV.
This prevents potential null pointer dereferences and ensures proper
cleanup on memory mapping failures.
Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon")
Cc: stable@vger.kernel.org
Signed-off-by: Wang Jun <1742789905@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The memory allocated for codec in videocodec_attach() is not freed in
one of the error paths, due to an incorrect goto label. Fix the label
to free it on error.
Fixes: 8f7cc5c0b0eb ("media: staging: media: zoran: introduce zoran_i2c_init")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock,
creating a race with em28xx_v4l2_init()'s error path and
em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct
and set dev->v4l2 to NULL under dev->lock.
This race leads to two issues:
- use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler,
since the video_device is embedded in the freed em28xx_v4l2 struct.
- NULL pointer dereference in em28xx_resolution_set() when accessing
v4l2->norm, since dev->v4l2 has been set to NULL.
Fix this by moving the mutex_lock() before the dev->v4l2 read and
adding a NULL check for dev->v4l2 under the lock.
Reported-by: syzbot+c025d34b8eaa54c571b8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c025d34b8eaa54c571b8
Fixes: 8139a4d583ab ("[media] em28xx: move v4l2 user counting fields from struct em28xx to struct v4l2")
Cc: stable@vger.kernel.org
Signed-off-by: Abhishek Kumar <abhishek_sts8@yahoo.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In the event that the cec dev node is held open while the adapter is
disconnected the serio device will be cleaned up but the cec device won't
be. As the serio device is freed but the ping_eeprom_work is not canceled,
the next ping will still attempt to send, leading to a kernel oops.
This patch both cancels the ping_eeprom_work in the serio cleanup as well
as checking to make sure the serio is still present before attempting to
write to it. Note that while the added serio = NULL line looks similar to
one that was removed in commit 024e01dead12c ("media: pulse8-cec: fix
duplicate free at disconnect or probe error"), it notably happens before
calling cec_unregister_adapter, and as such shouldn't lead to the
user-after-free that removing it fixed.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
syzbot reported a general protection fault in vidtv_psi_desc_assign [1].
vidtv_psi_pmt_stream_init() can return NULL on memory allocation
failure, but vidtv_channel_pmt_match_sections() does not check for
this. When tail is NULL, the subsequent call to
vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL
pointer offset, causing a general protection fault.
Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean
up the already-allocated stream chain and return.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629
Call Trace:
<TASK>
vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline]
vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479
vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519
vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239
Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver")
Cc: stable@vger.kernel.org
Reported-by: syzbot+1f5bcc7c919ec578777a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1f5bcc7c919ec578777a
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
syzbot reported a memory leak in vidtv_psi_service_desc_init [1].
When vidtv_start_streaming() fails inside vidtv_start_feed(), the
nfeeds counter is left incremented even though no feed was actually
started. This corrupts the driver state: subsequent start_feed calls
see nfeeds > 1 and skip starting the mux, while stop_feed calls
eventually try to stop a non-existent stream.
This state corruption can also lead to memory leaks, since the mux
and channel resources may be partially allocated during a failed
start_streaming but never cleaned up, as the stop path finds
dvb->streaming == false and returns early.
Fix by decrementing nfeeds back when start_streaming fails, keeping
the counter in sync with the actual number of active feeds.
[1]
BUG: memory leak
unreferenced object 0xffff888145b50820 (size 32):
comm "syz.0.17", pid 6068, jiffies 4294944486
backtrace (crc 90a0c7d4):
vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288
vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83
vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524
vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518
vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239
Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver")
Cc: stable@vger.kernel.org
Reported-by: syzbot+639ebc6ec75e96674741@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=639ebc6ec75e96674741
Signed-off-by: Ruslan Valiyev <linuxoid@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Ahead of introducing I2C-adapter-specific printk() helpers, preemptively
avoid a conflict with the upcoming i2c_dbg() and rename the local macro
in the saa7134 driver to saa7134_i2c_dbg().
Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their
argument structs by value, causing MSAN to report uninit-value warnings.
While only vidtv_ts_null_write_into() has triggered a report so far,
both functions share the same issue.
Fix by passing both structs by const pointer instead, avoiding the
stack copy of the struct along with its MSAN shadow and origin metadata.
The functions do not modify the structs, which is enforced by the const
qualifier.
Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver")
Cc: stable@vger.kernel.org
Reported-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=96f901260a0b2d29cd1a
Tested-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com
Suggested-by: Yihan Ding <dingyihan@uniontech.com>
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In dib8000_set_dds(), 1 << 26 (67108864) divided by e.g. 1 apparently can't
fit into 16-bit variable unit_khz_dds_val, being truncated to 0; this will
cause division by 0 while calling dprintk() with debugging enabled (via the
module parameter). Use s32 instead of s16 to declare the variable, getting
rid of the cast to u16 in the *else* branch as well...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Fixes: 173a64cb3fcf ("[media] dib8000: enhancement")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
media: cx25821-alsa: replace BUG_ON() with WARN_ON()
Avoid crashing the kernel for a recoverable condition
by replacing BUG_ON() with WARN_ON().
Signed-off-by: Atharv Dubey <atharvd440@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In fimc_runtime_resume(), the return value of
clk_enable(fimc->clock[CLK_GATE]) was not checked. If enabling the clock
fails, subsequent register accesses (fimc_hw_reset() and capture/m2m
resume) may trigger a bus error or undefined behavior.
Fix this by checking the return value. If clk_enable() fails, return the
error immediately, preventing unsafe hardware access.
Signed-off-by: Zhaoyang Yu <2426767509@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The v4l2_device is registered during probe but was not being unregistered
during remove. Add the missing v4l2_device_unregister() call to properly
clean up resources.
Fixes: fc2873aa4a21 ("media: ti: vpe: Add the VIP driver")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not
see a reason why vb2_dma_sg should behave differently. This avoids
hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in
drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of
tree Apple ISP camera capture driver which uses vb2_dma_sg_memops.
gst-launch-1.0 v4l2src ! gtk4paintablesink
[ 38.201528] ------------[ cut here ]------------
[ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210
[ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
snd_seq snd_seq_device uinput nf_conntrack_netbios_ns
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep
nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc
hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic
cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev
aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2
snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor
macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi
macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3
snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon
apple_sart apple_dockchannel macsmc apple_rtkit_helper
spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses
pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core
spi_apple
[ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram
[ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full)
[ 38.219040] Tainted: [W]=WARN
[ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
[ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210
[ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210
[ 38.222178] sp : ffffc0008dc678e0
[ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480
[ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968
[ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0
[ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968
[ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8
[ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff
[ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8
[ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000
[ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038
[ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb
[ 38.231488] Call trace:
[ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P)
[ 38.232342] drm_gem_mmap+0x140/0x260
[ 38.232813] __mmap_region+0x488/0x9a0
[ 38.233277] mmap_region+0xd0/0x148
[ 38.233703] do_mmap+0x350/0x5c0
[ 38.234148] vm_mmap_pgoff+0x14c/0x200
[ 38.234612] ksys_mmap_pgoff+0x150/0x208
[ 38.235107] __arm64_sys_mmap+0x34/0x50
[ 38.235611] invoke_syscall+0x50/0x120
[ 38.236075] el0_svc_common.constprop.0+0x48/0xf0
[ 38.236680] do_el0_svc+0x24/0x38
[ 38.237113] el0_svc+0x38/0x168
[ 38.237507] el0t_64_sync_handler+0xa0/0xe8
[ 38.238034] el0t_64_sync+0x198/0x1a0
[ 38.238491] ---[ end trace 0000000000000000 ]---
There were discussions in [1] at the end of 2023 that mmap() on imported
dma-bufs should not be supported but as of v6.17 drm_gem_shmem_mmap() in
drm_gem_shmem_helper.c still supports it.
This might affect all gpu or accel drivers using drm_gem_shmem_mmap() or
the wrapper drm_gem_shmem_object_mmap().
[1] https://lore.kernel.org/dri-devel/bc7f7844-0aa3-4802-b203-69d58e8be2fa@linux.intel.com/
Cc: stable@vger.kernel.org
Fixes: 5ba3f757f059 ("[media] v4l: videobuf2: add DMA scatter/gather allocator")
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The bcm2835-camera driver was dropped in commit <90204a38a760>.
Remove the paragraph in Kconfig making reference to it.
Signed-off-by: Gaston Gonzalez <gascoar@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The bcm2835-camera driver was dropped in commit <90204a38a760>, but it
is still mentioned as a current driver in a comment section.
Remove the comment making reference to it.
Signed-off-by: Gaston Gonzalez <gascoar@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Add zDML (a special signal mapping as used in Audi Digital Matrix Lights)
color mapping support. In addition to extending the already existing color
mapping property of the inputs, the same property is added for the outputs
that must be configured in the same way as the inputs.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The "magic" temperature formula must be computed using a signed integer for
negative temperatures to work properly.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Use scoped for_each_compatible_node_scoped() loop when iterating over
device nodes to make code a bit simpler.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The definition of PI in the driver is not the actual value in radians,
but rather degrees. Since we are going to have a value in radians
defined in a global header, rename this definition to avoid potential
collisions. No functional changes.
Acked-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Change from my company email address to gmail.com.
Signed-off-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
This function initializes two large structures with arrays. On at least
parisc, the specific code sequence here leads to a badly misoptimized
output from the compiler along with a warning about the resulting
excessive stack usage from many spilled variables:
drivers/media/tuners/mxl5005s.c: In function 'MXL5005_ControlInit.isra':
drivers/media/tuners/mxl5005s.c:1660:1: warning: the frame size of 1400 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Splitting this one function into two functions avoids this because there
are few temporaries that can be spilled to the stack in each of the smaller
structures, so this avoids the warning and also improves readability.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In isp_video_open(), drop the use count of v4l2
pipeline if vb2_queue_init() fails.
Fixes: 8fd390b89cc8 ("media: Split v4l2_pipeline_pm_use into v4l2_pipeline_pm_{get, put}")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
The Synopsys DesignWare MIPI CSI-2 Receiver is currently only supported
on Rockchip RK3568 SoCs. Hence add a dependency on ARCH_ROCKCHIP, to
prevent asking the user about this driver when configuring a kernel
without Rockchip platform support.
The dependency can be relaxed later, when adding support for appropriate
SoCs from other vendors (if any).
Fixes: 355a110040665e43 ("media: synopsys: add driver for the designware mipi csi-2 receiver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Michael Riesch <michael.riesch@collabora.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
imx258_open(), imx258_enum_mbus_code(), and imx258_enum_frame_size()
call imx258_get_format_code() without holding imx258->mutex. However,
imx258_get_format_code() has lockdep_assert_held(&imx258->mutex)
indicating that callers must hold this lock.
All other callers of imx258_get_format_code() properly acquire the mutex:
- imx258_set_pad_format() acquires mutex at imx258.c:918
- imx258_get_pad_format() acquires mutex at imx258.c:896
The mutex is needed to protect access to imx258->vflip->val and
imx258->hflip->val which are used to calculate the bayer format code.
Add mutex_lock()/mutex_unlock() around the imx258_get_format_code()
calls in the affected functions to fix the missing lock protection.
Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
ar0521_probe()
The devm_gpiod_get_optional() function may return an error pointer
(ERR_PTR) in case of a genuine failure during GPIO acquisition, not just
NULL which indicates the legitimate absence of an optional GPIO.
Add an IS_ERR() check after the function call to catch such errors and
propagate them to the probe function, ensuring the driver fails to load
safely rather than proceeding with an invalid pointer.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
vgxy61_probe()
The devm_gpiod_get_optional() function may return an error pointer
(ERR_PTR) in case of a genuine failure during GPIO acquisition,
not just NULL which indicates the legitimate absence of an optional
GPIO.
Add an IS_ERR() check after the function call to catch such errors and
propagate them to the probe function, ensuring the driver fails to load
safely rather than proceeding with an invalid pointer.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
mt9p031_probe()
The devm_gpiod_get_optional() function may return an error pointer
(ERR_PTR) in case of a genuine failure during GPIO acquisition, not just
NULL which indicates the legitimate absence of an optional GPIO.
Add an IS_ERR() check after the function call to catch such errors and
propagate them to the probe function, ensuring the driver fails to load
safely rather than proceeding with an invalid pointer.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
imx219_probe()
The devm_gpiod_get_optional() function may return an error pointer
(ERR_PTR) in case of a genuine failure during GPIO acquisition,
not just NULL which indicates the legitimate absence of an optional
GPIO.
Add an IS_ERR() check after the function call to catch such errors and
propagate them to the probe function, ensuring the driver fails to load
safely rather than proceeding with an invalid pointer.
Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor")
Cc: stable@vger.kernel.org
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Three media drivers have unnecessary module_init and module_exit
functions that are empty or just print a message. Remove them. Note
that if a module_init function exists, a module_exit function must also
exist; otherwise, the module cannot be unloaded.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Add the Omnivision OV5675 (ACPI HID OVTI5675) to the
ipu_supported_sensors[] table with a link frequency of 450 MHz.
This sensor is found in the Lenovo ThinkPad X1 Fold 16 Gen 1 behind
an Intel Vision Sensing Controller (IVSC). Without this entry the IPU
bridge does not create the software-node fwnode graph for the sensor,
preventing the camera from being enumerated.
Signed-off-by: Leif Skunberg <diamondback@cohunt.app>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
A device tree compatible makes it possible for this driver to be used on
Open Firmware devices. Initialization of power-managed resources such as
the reset GPIO and voltage regulators can be specified in the device
tree and handled by the driver. Add support for this so the Pixel 3a can
use the driver.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
