Artem Lytkin [Sat, 7 Feb 2026 22:05:44 +0000 (22:05 +0000)]
staging: media: av7110: replace BUG() with error return in gpioirq
Replace BUG() with a return statement in the gpioirq tasklet handler.
If saa7146_wait_for_debi_done() times out, crashing the kernel is
disproportionate. The pr_err() already logs the failure, and returning
early avoids accessing hardware in a potentially broken state.
Signed-off-by: Artem Lytkin <iprintercanon@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
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>
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>
Hans Verkuil [Mon, 16 Mar 2026 13:43:03 +0000 (14:43 +0100)]
media: cx231xx: add USB ID 2040:8360 for Hauppauge WinTV-HVR-935
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.
Wang Jun [Mon, 16 Mar 2026 12:24:01 +0000 (20:24 +0800)]
media: saa7164: add ioremap return checks and cleanups
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>
Abdun Nihaal [Thu, 12 Mar 2026 12:32:56 +0000 (18:02 +0530)]
media: pci: zoran: fix potential memory leak in zoran_probe()
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.
Abhishek Kumar [Tue, 10 Mar 2026 16:44:37 +0000 (22:14 +0530)]
media: em28xx: fix use-after-free in em28xx_v4l2_open()
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>
Vicki Pfau [Tue, 10 Mar 2026 04:50:34 +0000 (21:50 -0700)]
media: pulse8-cec: Handle partial deinit
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>
Johan Hovold [Thu, 5 Mar 2026 13:00:25 +0000 (14:00 +0100)]
media: cx231xx: drop redundant device reference
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>
Johan Hovold [Thu, 5 Mar 2026 10:39:19 +0000 (11:39 +0100)]
media: usbtv: drop redundant device reference
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>
Johan Hovold [Thu, 5 Mar 2026 10:39:18 +0000 (11:39 +0100)]
media: go7007-loader: drop redundant device reference
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>
Ruslan Valiyev [Tue, 3 Mar 2026 11:27:54 +0000 (11:27 +0000)]
media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections
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>
Ruslan Valiyev [Sun, 1 Mar 2026 21:07:35 +0000 (21:07 +0000)]
media: vidtv: fix nfeeds state corruption on start_streaming failure
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.
media: saa7134: rename i2c_dbg() to saa7134_i2c_dbg()
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.
Sergey Shtylyov [Fri, 6 Feb 2026 14:22:26 +0000 (17:22 +0300)]
media: dib8000: avoid division by 0 in dib8000_set_dds()
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.
Zhaoyang Yu [Sun, 1 Mar 2026 16:18:54 +0000 (16:18 +0000)]
media: fimc: check return value of clk_enable in runtime_resume
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>
Felix Gu [Sun, 1 Mar 2026 13:39:25 +0000 (21:39 +0800)]
media: ti: vpe: Add missing v4l2_device_unregister in vip_remove()
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>
Janne Grunau [Sun, 15 Feb 2026 17:42:59 +0000 (18:42 +0100)]
media: videobuf2: Set vma_flags in vb2_dma_sg_mmap
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.
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().
Hans Verkuil [Thu, 12 Feb 2026 09:57:58 +0000 (10:57 +0100)]
.mailmap: Add back old email alias
The old hans.verkuil@cisco.com email, long since dead, still pops up
once in a while when using get_maintainer.pl. Add it back to .mailmap
so it is mapped to a working email.
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Martin Tůma [Tue, 27 Jan 2026 12:43:07 +0000 (13:43 +0100)]
media:pci:mgb4: Add zDML color mapping support
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>
media: samsung: exynos4-is: Simplify with scoped for each OF child loop
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>
Andy Shevchenko [Fri, 7 Nov 2025 20:02:59 +0000 (21:02 +0100)]
media: vidtv: Rename PI definition to PI_SAMPLES
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>
Martin Hecht [Tue, 9 Sep 2025 11:32:15 +0000 (13:32 +0200)]
dt-bindings: media: i2c: alliedvision,alvium-csi2
Change from my company email address to gmail.com.
Signed-off-by: Martin Hecht <mhecht73@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Arnd Bergmann [Fri, 20 Jun 2025 11:14:23 +0000 (13:14 +0200)]
media: mxl5005s: reduce stack usage in MXL5005_ControlInit
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>
media: synopsys: VIDEO_DW_MIPI_CSI2RX should depend on ARCH_ROCKCHIP
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>
Ziyi Guo [Fri, 30 Jan 2026 02:31:54 +0000 (02:31 +0000)]
media: i2c: imx258: add missing mutex protection for format code access
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.
Chen Ni [Fri, 30 Jan 2026 04:18:15 +0000 (12:18 +0800)]
media: i2c: ar0521: Check return value of devm_gpiod_get_optional() in 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>
Chen Ni [Fri, 30 Jan 2026 04:20:43 +0000 (12:20 +0800)]
media: i2c: vgxy61: Check return value of devm_gpiod_get_optional() in 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>
Chen Ni [Mon, 2 Feb 2026 02:43:12 +0000 (10:43 +0800)]
media: i2c: mt9p031: Check return value of devm_gpiod_get_optional() in 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>
Chen Ni [Wed, 4 Feb 2026 02:48:59 +0000 (10:48 +0800)]
media: i2c: imx219: Check return value of devm_gpiod_get_optional() in 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.
Sakari Ailus [Thu, 26 Feb 2026 13:10:54 +0000 (15:10 +0200)]
staging: media: atomisp: Disallow all private IOCTLs
Disallow all private IOCTLs. These aren't quite as safe as one could
assume of IOCTL handlers; disable them for now. Instead of removing the
code, return in the beginning of the function if cmd is non-zero in order
to keep static checkers happy.
Reported-by: Soufiane Dani <soufianeda@tutanota.com> Closes: https://lore.kernel.org/linux-staging/20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com/ Cc: stable@vger.kernel.org Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Leif Skunberg [Tue, 10 Feb 2026 09:45:45 +0000 (10:45 +0100)]
media: ipu-bridge: Add OV5675 sensor config
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>
Richard Acayan [Tue, 17 Feb 2026 00:27:34 +0000 (19:27 -0500)]
media: i2c: imx355: Support devicetree and power management
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>
Richard Acayan [Tue, 17 Feb 2026 00:27:33 +0000 (19:27 -0500)]
dt-bindings: media: i2c: Add Sony IMX355
The IMX355 camera sensor is a camera sensor that can be found as the
front camera in some smartphones, such as the Pixel 3, Pixel 3 XL, Pixel
3a, and Pixel 3a XL. It already has a driver, but needs support for
device tree. Document the IMX355 to support defining it in device tree.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> 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>
The clock-lanes property has no effect on the hardware configuration, as
of commit 336136e197e2 ("media: dt-bindings: media: camss: Remove
clock-lane property"). Since boards with new camss support can omit the
property, remove it from the required lists.
Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: i2c: og01a1b: Switch from .s_stream to .enable_streams/.disable_streams
The change allows to simplify the driver code, in particular the explicit
locking scheme for stream on/off or format update serialization can be
dropped in favour to the one provided by the V4L2 core internals.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
[Sakari Ailus: Fix error handling for enable_streams callback.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: i2c: og01a1b: Fix V4L2 subdevice data initialization on probe
It's necessary to finalize the camera sensor subdevice initialization on
driver probe and clean V4L2 subdevice data up on error paths and driver
removal.
The change fixes a previously reported by v4l2-compliance issue of
the failed VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT test:
fail: v4l2-test-controls.cpp(1104): subscribe event for control 'User Controls' failed
Fixes: 472377febf84 ("media: Add a driver for the og01a1b camera sensor") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jai Luthra [Sat, 14 Feb 2026 13:05:22 +0000 (18:35 +0530)]
media: i2c: imx283: Fix hang when going from large to small resolution
When switching between modes (e.g. full resolution to binned),
standby_cancel() previously cleared XMSTA (starting master mode data
output) before the new mode's MDSEL, crop, and timing registers were
programmed in start_streaming(). This caused the sensor to briefly
output MIPI data using the previous mode's configuration.
On receivers like imx-mipi-csis, this leads to FIFO overflow errors
when switching from a higher to a lower resolution, as the receiver is
configured for the new smaller frame size but receives stale
full-resolution data.
Fix this by moving the XMSTA and SYNCDRV register writes from
standby_cancel() to the end of start_streaming(), after all mode,
crop, and timing registers have been configured. Also explicitly stop
master mode (XMSTA=1) when stopping the stream, matching the pattern
used by other Sony sensor drivers (imx290, imx415).
Use named macros IMX283_XMSTA_START/STOP instead of raw 0/BIT(0) for
readability.
Jai Luthra [Sat, 14 Feb 2026 13:05:21 +0000 (18:35 +0530)]
media: i2c: imx283: Enter full standby when stopping streaming
Use IMX283_STANDBY (bit 0) instead of IMX283_STBLOGIC (bit 1) when
stopping streaming. STBLOGIC only puts the sensor logic into standby but
leaves the MIPI interface (along with other components) in an
indeterminate state.
This (presumably) causes the CSI receiver (e.g. Raspberry Pi's CFE) to
miss the LP-11 to HS transition when streaming restarts, resulting in a
hang of 10+ seconds. The issue is most visible when immediately
restarting a full-resolution stream after stopping a 3x3 binned one, so
that runtime suspend hasn't yet been triggered.
Writing IMX283_STANDBY puts the entire sensor into standby. The
imx283_standby_cancel() sequence already handles the full wakeup from
this suspended state.
Dmitry Torokhov [Wed, 18 Feb 2026 20:53:48 +0000 (12:53 -0800)]
media: i2c: max9286: normalize return value of gpio_get
The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by max9286_gpiochip_get() is
normalized to the [0, 1] range.
Ethan Tidmore [Sat, 7 Mar 2026 03:03:55 +0000 (21:03 -0600)]
media: intel/ipu6: fix error pointer dereference
In a error path isp->psys is confirmed to be an error pointer not NULL so
this condition is true and the error pointer is dereferenced. So isp-psys
should be set to NULL before going to out_ipu6_bus_del_devices.
Detected by Smatch:
drivers/media/pci/intel/ipu6/ipu6.c:690 ipu6_pci_probe() error:
'isp->psys' dereferencing possible ERR_PTR()
media: ccs-pll: Fix pre-PLL divider calculation for EXT_IP_PLL_DIVIDER flag
When the CCS_PLL_FLAG_EXT_IP_PLL_DIVIDER flag is set, odd pre-PLL divider
values are allowed. However, in the operational timing branch the
calculation of the minimum pre-PLL divider incorrectly uses clk_div_even_up,
forcing the minimum value to be even, even if the flag is set. This prevents
selecting a valid odd divider like 3, which may be required for certain
sensor configurations.
Fix this by removing the forced even rounding from the minimum pre-PLL
divider calculation. The loop later uses the flag to determine the step,
so odd values will be considered when the flag is set.
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Mark Brown [Mon, 2 Mar 2026 16:32:18 +0000 (16:32 +0000)]
media: synopsys: hdmirx: support use with sleeping GPIOs
The recent change in commit 20cf2aed89ac ("gpio: rockchip: mark the GPIO
controller as sleeping") to mark the rockchip GPIO driver as sleeping
has started triggering the warning at drivers/gpio/gpiolib.c:3523
indicating that a sleepable GPIO was called via the non-sleeping APIs on
the Rock 5B:
Currently the active use of the GPIO is all done from process context so
can be simply converted to use gpiod_get_value_cansleep(). There is one use
of the GPIO from hard interrupt context but this is only done so the status
can be displayed in a debug print so can simply be deleted without any
functional effect.
Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dan Carpenter [Fri, 20 Feb 2026 08:15:07 +0000 (09:15 +0100)]
media: rockchip: rkcif: fix off by one bugs
Change these comparisons from > vs >= to avoid accessing one element
beyond the end of the arrays.
While at it, use ARRAY_SIZE instead of the _MAX enum values.
Fixes: 1f2353f5a1af ("media: rockchip: rkcif: add support for rk3568 vicap mipi capture") Cc: stable@kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Chen-Yu Tsai <wens@kernel.org>
[fix cosmetic issues] Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Xiaolei Wang [Thu, 5 Mar 2026 04:33:48 +0000 (12:33 +0800)]
media: i2c: ov9282: Convert to CCI register access helpers
Use the new common CCI register access helpers to replace the private
register access helpers in the ov9282 driver. This simplifies the driver
by reducing the amount of code.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
[Sakari Ailus: Declare ret_hold earlier to make old GCC happy.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Alain Volmat [Tue, 6 Jan 2026 11:34:38 +0000 (12:34 +0100)]
media: stm32: dcmi: addition of DMA-MDMA chaining support
Add possibility to rely on an additional MDMA channel and chain
the DMA and MDMA channels allowing to achieve faster capture.
Indeed, on the MP15 platform, the MDMA engine has an higher
bandwidth to the DDR than the DMA engine. Relying on that
it is possible to capture frames from the DCMI IP into the DDR
by using two channels as follow:
DCMI -> (DMA) -> SRAM -> (MDMA) -> DDR
The DMA is able by himself to trigger a MDMA request hence, once
properly configured, the DCMI IP can simply trigger the DMA in order
to have the data pushed up to the DDR (via the SRAM and a MDMA
channel).
This behavior is detailed in the document
Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
Alain Volmat [Tue, 6 Jan 2026 11:34:36 +0000 (12:34 +0100)]
media: stm32: dcmi: continuous mode capture in JPEG
Overall cleanup done allows to now have the JPEG handling
done in the same way as other formats in continuous mode,
allowing to achieve a faster framerate in all resolutions.
Alain Volmat [Tue, 6 Jan 2026 11:34:35 +0000 (12:34 +0100)]
media: stm32: dcmi: use dmaengine_terminate_async in irq context
Whenever receiving an OVERRUN event or an end of frame, the driver stops
currently ongoing DMA transfer since the DCMI stops sending data to dma.
Not doing this would lead to having DMA & DCMI no more synchronized in term
of expected data to be copied.
Since this is done in irq handler context, it is not possible to make any
call that would lead to scheduling hence dmaengine_terminate_sync are not
possible.
Since the dcmi driver is NOT using dma callbacks, it is possible thus to
call instead dmaengine_terminate_async (aka without synchronize) and call
again right after a new dmaengine_submit to setup again a new transfer.
And since this is now a dmaengine_submit_async, there is no need to release
the spinlock around calls to the dmaengine_submit_async.
Alain Volmat [Tue, 6 Jan 2026 11:34:34 +0000 (12:34 +0100)]
media: stm32: dcmi: perform all dma handling within irq_thread
Move all the type of frame handling within the dcmi_irq_thread
handler and do not rely on dma_callback as previously.
This simplifies the code by having only a single path for both
compressed and uncompressed data while also making the system
more reactive since irq_handler have more chances to be called
faster than the dma completion callback. Indeed, in case of the
dma completion callback, this run as a tasklet created by the
dma framework upon getting an interrupt from the dma and run
at a lower priority level than other irq handlers.
Alain Volmat [Tue, 6 Jan 2026 11:34:33 +0000 (12:34 +0100)]
media: stm32: dcmi: rework spin_lock calls
Rework of the spin_lock calls in preparation of the rework
of the data handling of the driver. Keep it straight forward
with basically spin_lock protection around everything except
dmaengine calls that might sleep (ex: synchronize / terminate)
Alain Volmat [Tue, 6 Jan 2026 11:34:31 +0000 (12:34 +0100)]
media: stm32: dcmi: only create dma descriptor once at buf_prepare
Perform the dmaengine prep_slave_sg call within buf_prepare and
mark the descriptor as reusable in order to avoid having to redo
this at every start of the dma.
This also allow to remove the mutex used by the driver to protect
dma descriptors related piece of codes.
Alain Volmat [Tue, 6 Jan 2026 11:34:29 +0000 (12:34 +0100)]
media: stm32: dcmi: Switch from __maybe_unused to pm_ptr()
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less heavier for builds
than the use of __maybe_unused attributes.
media: i2c: mt9m114: add support for Aptina MI1040
Slightly different version of MT9M114 camera module is used in a several
devices like ASUS Nexus 7 (2012) or ASUS Transformer Prime TF201 and is
called Aptina MI1040. The only difference found so far is lacking ability
to poll STATE register during power on sequence, which causes driver to
fail with time out error. Add state_standby_polling flag to diverge models
and address quirk found in MI1040.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> 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>
The Aptina MI1040 is a slightly different version of the MT9M114 camera
module. It is used in several devices, such as the ASUS Nexus 7 (2012) and
the ASUS Transformer Prime TF201. The compatible "onnn,mt9m114" is placed
first in the enum, as it is considered the default compatible value.
Tomi Valkeinen [Thu, 15 Jan 2026 10:07:01 +0000 (12:07 +0200)]
media: rcar-csi2: Optimize rcsi2_calc_mbps()
With modern drivers supporting link-freq, we don't need to do any
calculations based on the bpp and number of lanes when figuring out the
link frequency. However, the code currently always runs code to get the
bpp and number of lanes.
Optimize the rcsi2_calc_mbps() so that we only do that when needed, i.e.
when querying the link-freq is not supported by the upstream subdevice.
Tomi Valkeinen [Thu, 15 Jan 2026 10:07:00 +0000 (12:07 +0200)]
media: rcar-csi2: Simplify rcsi2_calc_mbps()
Instead of taking the bpp and the number of lanes as parameters to
rcsi2_calc_mbps(), change the function to get those parameters inside
the function. This centralizes the code a bit and makes it easier to add
streams support.
Also, in the future when the legacy (non-link-freq) code is removed,
there will be no need to change rcsi2_calc_mbps() parameters.
media: i2c: ds90ub960: Add support for DS90UB954-Q1
DS90UB954-Q1 is an FPDLink-III deserializer that is mostly register
compatible with DS90UB960-Q1. The main difference is that it supports half
of the RX and TX ports, i.e. 2x FPDLink RX ports and 1x CSI TX port.
A couple of differences are between the status registers and the
strobe setting registers. Hence accommodate these differences in
the UB960 driver so that we can reuse a large part of the existing code.
Link: https://www.ti.com/lit/gpn/ds90ub954-q1 Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: dt-bindings: ti,ds90ub960: Add support for DS90UB954-Q1
DS90UB954-Q1 is an FPDLink-III deserializer that is mostly register
compatible with DS90UB960-Q1. The main difference is that it supports
half of the RX and TX ports, i.e. 2x FPDLink RX ports and 1x CSI TX
port. Therefore, add support for DS90UB954 within the existing bindings.
Link: https://www.ti.com/lit/gpn/ds90ub954-q1 Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: i2c: ds90ub960: Use enums for chip type and chip family
Replace chip-specific boolean flags with chip_type and chip_family enums.
This simplifies the process of adding support for newer devices and also
improves code readability.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
media: dt-bindings: ti,ds90ub960: Refactor port definitions
The current bindings duplicate the port definitions for each FPD-Link RX
and CSI-2 TX ports. This results in a large amount of repeated schema
blocks and makes it harder to extend the bindings for new devices.
Refactor the bindings by introducing shared deftinitions for FPD-Link
input ports and CSI-2 output ports. No functional change intended.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Wenmeng Liu [Fri, 23 Jan 2026 09:19:56 +0000 (17:19 +0800)]
media: i2c: imx412: Extend the power-on waiting time
The Arducam IMX577 module requires a longer reset time than the 1000µs
configured in the current driver. Increase the wait time after power-on
to ensure proper initialization.
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Wenmeng Liu [Fri, 23 Jan 2026 09:19:55 +0000 (17:19 +0800)]
media: i2c: imx412: Assert reset GPIO during probe
Assert the reset GPIO before first power up. This avoids a mismatch where
the first power up (when the reset GPIO defaults deasserted) differs from
subsequent cycles.
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Merge tag 'v7.0-rc2' into __tmp-hverkuil-media-tags_br_v7_1a
Linux 7.0-rc2
* tag 'v7.0-rc2': (372 commits)
Linux 7.0-rc2
firewire: ohci: initialize page array to use alloc_pages_bulk() correctly
KVM: always define KVM_CAP_SYNC_MMU
KVM: remove CONFIG_KVM_GENERIC_MMU_NOTIFIER
selftests/bpf: Avoid simplification of crafted bounds test
selftests/bpf: Test refinement of single-value tnum
bpf: Improve bounds when tnum has a single possible value
bpf: Introduce tnum_step to step through tnum's members
bpf: Fix race in devmap on PREEMPT_RT
bpf: Fix race in cpumap on PREEMPT_RT
selftests/bpf: Add tests for special fields races
bpf: Retire rcu_trace_implies_rcu_gp() from local storage
bpf: Delay freeing fields in local storage
bpf: Lose const-ness of map in map_check_btf()
bpf: Register dtor for freeing special fields
PCI: Correct PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 value
smb: client: Use snprintf in cifs_set_cifscreds
mm/slab: initialize slab->stride early to avoid memory ordering issues
smb: client: Don't log plaintext credentials in cifs_set_cifscreds
smb: client: fix broken multichannel with krb5+signing
...
Linus Torvalds [Sun, 1 Mar 2026 23:34:47 +0000 (15:34 -0800)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Arm:
- Make sure we don't leak any S1POE state from guest to guest when
the feature is supported on the HW, but not enabled on the host
- Propagate the ID registers from the host into non-protected VMs
managed by pKVM, ensuring that the guest sees the intended feature
set
- Drop double kern_hyp_va() from unpin_host_sve_state(), which could
bite us if we were to change kern_hyp_va() to not being idempotent
- Don't leak stage-2 mappings in protected mode
- Correctly align the faulting address when dealing with single page
stage-2 mappings for PAGE_SIZE > 4kB
- Fix detection of virtualisation-capable GICv5 IRS, due to the
maintainer being obviously fat fingered... [his words, not mine]
- Remove duplication of code retrieving the ASID for the purpose of
S1 PT handling
- Fix slightly abusive const-ification in vgic_set_kvm_info()
Generic:
- Remove internal Kconfigs that are now set on all architectures
- Remove per-architecture code to enable KVM_CAP_SYNC_MMU, all
architectures finally enable it in Linux 7.0"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: always define KVM_CAP_SYNC_MMU
KVM: remove CONFIG_KVM_GENERIC_MMU_NOTIFIER
KVM: arm64: Deduplicate ASID retrieval code
irqchip/gic-v5: Fix inversion of IRS_IDR0.virt flag
KVM: arm64: Revert accidental drop of kvm_uninit_stage2_mmu() for non-NV VMs
KVM: arm64: Fix protected mode handling of pages larger than 4kB
KVM: arm64: vgic: Handle const qualifier from gic_kvm_info allocation type
KVM: arm64: Remove redundant kern_hyp_va() in unpin_host_sve_state()
KVM: arm64: Fix ID register initialization for non-protected pKVM guests
KVM: arm64: Optimise away S1POE handling when not supported by host
KVM: arm64: Hide S1POE from guests when not supported by the host
projects / thirdparty / kernel / linux.git / log
