| Age | Commit message (Collapse) | Author |
|---|
|
irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails.
The current condition also checks for negative values, even though
irq_of_parse_and_map() does not return negative error codes.
Check only for a zero return value to match the semantics of
irq_of_parse_and_map().
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260903075753.346647-1-phucduc.bui@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel
format with alpha exposed"), drm_mode_config_validate() warns when a
plane exposes an alpha pixel format but not the "pixel blend mode"
property. Both the vboxvideo primary and cursor planes expose ARGB8888
and trip this on driver load.
VirtualBox draws the cursor through the host windowing system, which
treats the guest-supplied pointer shape as straight
(non-pre-multiplied) alpha: the host frontend loads the pixels
verbatim into an unpremultiplied ARGB image before handing them to the
host cursor APIs. This corresponds to DRM_MODE_BLEND_COVERAGE. Expose
a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE
to make these semantics explicit and silence the warning. The primary
plane's alpha channel is ignored by the host (opaque blit) and it is
the bottom-most plane anyway; advertise the same value there for
consistency.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901083234.1828755-5-qinyuntan@linux.alibaba.com
|
|
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel
format with alpha exposed"), drm_mode_config_validate() warns when a
plane exposes an alpha pixel format but not the "pixel blend mode"
property. The virtio-gpu cursor plane (HOST_ARGB8888) trips this.
The virtio-gpu specification does not define the cursor alpha
semantics. The host forwards the cursor pixels verbatim to its display
frontends, and the remote cursor protocols among them (SPICE alpha
cursors, the VNC "Cursor With Alpha" encoding) both define
pre-multiplied alpha, matching what userspace has always assumed when
the property is not attached. Expose a "pixel blend mode" property
advertising only DRM_MODE_BLEND_PREMULTI to make these semantics
explicit and silence the warning. The primary plane only exposes
HOST_XRGB8888, so the call is gated to the cursor. No functional
change.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901083234.1828755-4-qinyuntan@linux.alibaba.com
|
|
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel
format with alpha exposed"), drm_mode_config_validate() warns when a
plane exposes an alpha pixel format but not the "pixel blend mode"
property. Both the qxl primary and cursor planes expose ARGB8888 and
trip this on driver load.
qxl submits cursors as SPICE_CURSOR_TYPE_ALPHA, which the SPICE
protocol explicitly defines as a "pre-multiplied ARGB8888 pixmap"
(Spice Protocol, "Cursor channel definition" section [1]). This
matches the blend mode userspace has always assumed when the property
is not attached. Expose a "pixel blend mode" property advertising only
DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence
the warning. The primary plane is the bottom-most plane so its blend
mode has no visible effect; advertise the same value there for
consistency. No functional change.
[1] https://www.spice-space.org/spice-protocol.html
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901083234.1828755-3-qinyuntan@linux.alibaba.com
|
|
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel
format with alpha exposed"), drm_mode_config_validate() warns when a
plane exposes an alpha pixel format but not the "pixel blend mode"
property. The ast cursor plane (ARGB4444, ARGB8888) trips this on
driver load:
[PLANE:37:plane-1] pixel format with alpha exposed but blend mode not setup
WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x48f/0x510 [drm]
...
Call Trace:
drm_dev_register+0x1ce/0x290 [drm]
ast_pci_probe+0x19d/0x3f0 [ast]
local_pci_probe+0x41/0x90
Per Thomas Zimmermann's review, the ASPEED documentation describes the
hardware cursor as blending with straight (non-pre-multiplied) alpha,
which corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend
mode" property advertising only DRM_MODE_BLEND_COVERAGE to make the
hardware semantics explicit and silence the warning.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260901083234.1828755-2-qinyuntan@linux.alibaba.com
|
|
queue_init() initializes default formats for both the source and capture
queues. It first sets the source field to V4L2_FIELD_SEQ_TB, but then
stores the capture default, V4L2_FIELD_INTERLACED_TB, in the source queue
again while initializing the capture queue.
This overwrites the valid source default and leaves the capture field at
its zero-initialized value, V4L2_FIELD_ANY. vidioc_streamon() accepts
only V4L2_FIELD_SEQ_TB or V4L2_FIELD_SEQ_BT on the source queue, and
requires the capture queue to use a compatible interlaced or NONE field.
Userspace that relies on the default formats can therefore get -EINVAL
when starting streaming.
Initialize the capture field instead. The bug is usually hidden because
mem2mem applications commonly call S_FMT on both queues before streaming;
the TRY_FMT paths normalize the fields and S_FMT overwrites q_data[].field.
Fixes: 8f0755c06b90 ("[media] media: Add mem2mem deinterlacing driver")
Cc: stable@vger.kernel.org
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The SP8870 DVB frontend driver prematurely flags the device as
initialized at the very beginning of the sp8870_init() routine, prior
to requesting the firmware (dvb-fe-sp8870.fw) and executing the I2C
upload sequence.
If request_firmware() times out or sp8870_firmware_upload() encounters
an I2C bus error, the function aborts and returns -EIO. However,
because `state->initialised` is already set to 1, all subsequent
invocations of `fe->ops.init()` by the DVB core will immediately return
0 (success) without attempting to load the firmware again. This leaves
the demodulator microcontroller halted and the frontend permanently dead
until the module is forcibly reloaded.
Relocate the `state->initialised = 1` assignment to the end of
sp8870_init(), ensuring the flag is only set after the firmware is
successfully uploaded and the system controller is actually restarted.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Punnay Sharma <punnaysharma805@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In sp8870_read_ber(), the 14-bit Bit Error Rate (BER) is assembled by
reading two I2C registers: 0xC08 (lower 6 bits) and 0xC07 (upper 8 bits).
The current implementation masks the lower bits via `tmp = ret & 0x3F;`
but subsequently overwrites `tmp` entirely when processing the upper
bits using a direct assignment (`tmp = ret << 6;`). This logical error
causes the lower 6 bits of the BER hardware metric to be silently
discarded.
Fix this by using a bitwise OR (`tmp |= ret << 6;`) to correctly merge
the MSB and LSB payloads before returning the metric to the DVB core.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Punnay Sharma <punnaysharma805@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In vmalloc mode the frame-completion IRQ queues mcam_frame_work() on
cam->s_bh_work, which memcpy()s from the dma_bufs[] that
mcam_free_dma_bufs() frees with dma_free_coherent(). mccic_shutdown()
frees those buffers without stopping the controller, so while streaming
a late frame IRQ can re-arm the work after the buffers are gone, causing a
use-after-free.
Stop the controller in mccic_shutdown() when streaming is still active
(gated on an open fd, which holds a runtime-PM reference, so the device
is powered), cancel s_bh_work in mcam_free_dma_bufs(), and move
INIT_WORK() into mccic_register() before the device can be published.
Fixes: 67a8dbbc4e04 ("[media] marvell-cam: Basic working MMP camera driver")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The Linux kernel coding style specifies that return is not a function
and therefore parentheses are not required.
Signed-off-by: Ashmit Kumar <work.ashmitkumar@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
VIDEO_MMP_CAMERA selects I2C_GPIO without ensuring
'GPIOLIB || COMPILE_TEST' is enabled, despite I2C_GPIO depending on it.
Let's add the same dependency to VIDEO_MMP_CAMERA.
This unmet dependency bug was found by kconfirm, a static analysis tool for
Kconfig.
Fixes: 67a8dbbc4e04 ("[media] marvell-cam: Basic working MMP camera driver")
Cc: stable@vger.kernel.org
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
tegra_vi_channels_alloc() needs two error variables because its loop body
mixes two things: ports that are skipped because they cannot be used, and
errors that have to stop the whole allocation.
Move the loop body into tegra_vi_port_channel_alloc(), which returns 0
both when the port is skipped and when a channel was allocated, and a
negative error only when allocation must stop. The loop is then a call
and an error check, and the second error variable is no longer needed.
No functional change intended.
Suggested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Hao-Qun Huang <alvinhuang0603@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
av7110_ir.c contains MODULE_AUTHOR() and MODULE_LICENSE() commented
out. This file is compiled into dvb-ttpci.ko (dvb-ttpci-objs +=
av7110_ir.o in Makefile), and the MODULE_LICENSE(), MODULE_AUTHOR()
and MODULE_DESCRIPTION() are declared in av7110.c.
These commented out lines are unchanged since before kernel moved to git
which was checked using git log. Removing them will clean up the file.
Signed-off-by: Joyeta Modak <joyetamdk@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The lists of frequencies the simulated tuner locks onto are module
parameters, and were handed over to the tuner module without being
checked first.
A terrestrial or cable frequency outside the range the demodulator
reports to the DVB core is unreachable, as dvb_frontend_check_parameters()
rejects such a tuning request before the tuner is ever asked about the
frequency. A satellite frequency outside the Ku-band covered by the
simulated LNBf is equally meaningless, since it is downconverted using
the LNBf local oscillators before reaching the tuner.
In both cases vidtv used to initialize successfully and then never lock
on anything, leaving no clue about the cause.
Check the terrestrial and cable frequencies against the range advertised
by the demodulator, and the satellite ones against the Ku-band covered by
the simulated LNBf, failing the probe with an explicit error message
otherwise.
Signed-off-by: Alberto Pimpo <me@albertopimpo.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Attempting to unbind a dvbdevice that is in the process of feeding
data causes a UAF as we free the underlying device without
stopping the feed first. Fix this by stopping the stream first using
vidtv_stop_streaming(). However, our codepath in the reproducer
(mentioned in the below reply) does not decrement our users
(dmxdev->dvr_dvbdev->users) to 1 after it has been incremented to 2
by our read() in the reproducer, that is only possible on .release.
This can cause a task hang as dvb_dmxdev_release() uses wait_event()
in the wait_queue unless we use a close(fd)(in the reproducer).
Is this a problem? Please advise.
Reported-by: syzbot+c7fc4794e59786f5b4dc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c7fc4794e59786f5b4dc
Fixes: f90cf6079bf6 ("media: vidtv: add a bridge driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
dvb_register_frontend() keeps two references to the frontend. One is
released by dvb_unregister_frontend(), and the other by
dvb_frontend_detach(). vidtv only called dvb_unregister_frontend(), so
the second reference was never released. As a result,
__dvb_frontend_free() was never called, leaking the frontend private
data and its struct dvb_device.
The detach call was removed by commit 63101b756893 ("media: vidtv: fix
driver unbind/remove") because it caused an OOPS. The demod .release
callback freed vidtv_demod_state, and the I2C remove callbacks then
accessed the freed state.
That commit also removed those accesses from the I2C remove callbacks.
Restore the detach call, but remove the demod .release callback.
vidtv_demod_state is owned by the I2C client and is already freed by
vidtv_demod_i2c_remove(), so the frontend detach path should not free
it.
Tested with kmemleak and KASAN over 10 bind/unbind cycles. The reported
frontend and dvb_device leaks were present before the fix and were gone
after it, with no KASAN reports.
Reported-by: syzbot+32f018fd65e799f79ae0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=32f018fd65e799f79ae0
Fixes: 63101b756893 ("media: vidtv: fix driver unbind/remove")
Cc: stable@vger.kernel.org
Tested-by: syzbot+32f018fd65e799f79ae0@syzkaller.appspotmail.com
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Setting the encoder's compressed CAPTURE format to a smaller resolution
than the raw OUTPUT format makes the encoder write past the end of the
CAPTURE buffer.
For a stateful encoder the CAPTURE width and height are not
client-settable; Documentation/userspace-api/media/v4l/dev-encoder.rst
specifies them as "ignored (read-only)" on VIDIOC_S_FMT. vicodec only
implements half of that: vidioc_s_fmt_vid_out() derives the CAPTURE coded
size and sizeimage from the OUTPUT format, but S_FMT on the CAPTURE queue
overwrites them. The encoder then takes its geometry from the OUTPUT
queue alone, and v4l2_fwht_encode() gets no destination length.
Overwrite the requested width and height with the OUTPUT queue's coded
dimensions in vidioc_try_fmt_vid_cap(), making them read-only as the
interface requires.
Fixes: efec9c815e5d ("media: vicodec: pass on enc output format to capture side")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
A capture format whose width or height is one more than a multiple of 16
makes the FWHT codec write one 8x8 block row, or column, past the end of
the capture plane, and read the same block out of the reference frame for
P-coded frames.
vic_round_dim() is documented to round a frame dimension up so that both
the luma and the chroma plane end up a multiple of 8, but it only rounds
the chroma plane:
round_up((dim) / (div), 8) * (div)
For div == 2 the result is a multiple of 16 in every case but one: when
dim % 16 == 1, dim / div is already a multiple of 8 and the macro returns
dim - 1. encode_plane() and decode_plane() round the same dimension with
round_up(dim, 8), which yields dim + 7 -- one block more than the coded
dimension that sized the buffer.
On a KASAN-enabled kernel, a 641x360 YUYV P-frame triggers:
BUG: KASAN: slab-out-of-bounds in add_deltas+0x450/0xcc0
Read of size 1 at addr ffff888009070800 by task trigger_bin/70
Call Trace:
add_deltas+0x450/0xcc0
decode_plane+0x1916/0x3390
fwht_decode_frame+0x173/0x620
v4l2_fwht_decode+0x751/0x1120
device_run+0x6bb/0x1850
Round the dimension itself up to a multiple of 8 * div. The rounding
changes only for div == 2 and dim % 16 == 1, and MAX_WIDTH and MAX_HEIGHT
are both multiples of 16, so the rounded value still fits the advertised
limits.
Fixes: 3b15f68e19c2 ("media: vicodec: Add support for resolution change event.")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
vsensor->pixel_rate->val is a plain s32 field. Declaring the local
"pixel_rate" variable as u64 misrepresented its actual range and made
do_div()'s divisor look wider than the 32-bit division it actually
performs, which is exactly what the do_div() coccinelle check warns.
Revert pixel_rate back to its original s32 type to match
vsensor->pixel_rate->val, resolving the warning correctly.
Fixes: ec1e620b2454 ("media: vimc: sensor: Add pixel_rate,vblank and hblank configuration")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604191731.10nxGZ92-lkp@intel.com/
Link: https://lore.kernel.org/lkml/CANiDSCs9s03DUjKwcPgDtZt2QJ4i0FGwab4zpEP+wCawagSC2Q@mail.gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Faizel K B <faizel.kb@gmail.com>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Use %*ph format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
V4L2_CID_TRANS_NUM_BUFS controls how many buffer pairs a vim2m
mem2mem job processes before the job is completed. The driver stores
the value in ctx->translen and device_work() uses it later to decide
whether the current transaction should continue.
Letting userspace change this control while streaming is active can
make a queued job observe a different transaction length than the one
it started with. That leaves the transaction state inconsistent with
the buffers currently queued for the job.
Grab the transaction buffer count control while either queue is
streaming, and release it only after both queues have stopped
streaming. The V4L2 control framework then rejects changes with
-EBUSY while the value is in use, while still allowing userspace to
configure the value before streaming starts.
Keep the control handler alive until after v4l2_m2m_ctx_release(),
since releasing the mem2mem context can call stop_streaming(), which
now ungrabs the control.
Fixes: 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf framework test device")
Cc: stable@vger.kernel.org
Signed-off-by: Younho Choi <gdool88@mju.ac.kr>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The saa7146 interrupt handler can call SAA7146_IER_DISABLE(), which
serializes register access with dev->int_slock. request_irq() allows the
shared handler to run before saa7146_init_one() reaches the current lock
initialization block.
Initialize dev->int_slock before requesting the interrupt so every handler
path sees an initialized lock.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Convert the Toshiba TC358743 HDMI-RX to MIPI CSI2-TX bridge device
tree binding from txt to YAML format.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
go7007_usb_i2c_master_xfer() copies msgs[i].len bytes into go->usb_buf,
a 16-byte buffer embedded in struct go7007, without any length check.
The adapter declares no transfer limits, so an SMBus block transfer
issued through /dev/i2c-N can write up to 34 bytes into it and corrupt
the struct fields that follow the buffer.
Bound the transfer size with i2c_adapter_quirks so the I2C core
rejects oversized messages before they reach the driver.
Fixes: 7955f03d18d1 ("[media] go7007: move out of staging into drivers/media/usb.")
Cc: stable@vger.kernel.org
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
Assisted-by: GLM:5.3
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
than 20ms
msleep() isn't precise for delays under 20ms and relies on jiffies, which
can lead to sleeps longer than requested, depending on the system's HZ
configurations.
Replace msleep(3) with usleep_range(3000, 4000) to use high-resolution
timers, without forcing the system to wait unnecessarily.
Signed-off-by: Bhoomika Hardwani <bhoomika.hardwani@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Red/Blue chroma are swapped on PAL analog TV due to register 0x7A07
missing in the configuration block for PAL. Copying in the setting for
composite fixes the issue and everything decodes properly.
Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
VI_STATUS3 S_V_COLOR is four bits, so the index after the shift
is 0-15. input_color_space[] only has 14 entries. Add the two
reserved values so log_status() cannot walk off the table.
Fixes: d32d98642de6 ("[media] Driver for Toshiba TC358743 HDMI to CSI-2 bridge")
Cc: stable@vger.kernel.org
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
saa7164_dumpregs() dumps device register contents during initialization
for debugging purposes. The helper has a single caller and is explicitly
marked for removal.
Remove the call, helper, and declaration.
Signed-off-by: Zain Aboobacker <zainaboobacker33@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Convert the deprecated SIMPLE_DEV_PM_OPS
to DEFINE_SIMPLE_DEV_PM_OPS
and pm_sleep_ptr().
This lets us drop the __maybe_unused annotations
from its suspend and resume callbacks,
also reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled.
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Convert the deprecated SIMPLE_DEV_PM_OPS
to DEFINE_SIMPLE_DEV_PM_OPS
and pm_sleep_ptr().
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Convert the deprecated SIMPLE_DEV_PM_OPS
to DEFINE_SIMPLE_DEV_PM_OPS
and pm_sleep_ptr().
This lets us drop the __maybe_unused annotations
from its suspend and resume callbacks,
also reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled.
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Convert the deprecated SIMPLE_DEV_PM_OPS
to DEFINE_SIMPLE_DEV_PM_OPS
and pm_sleep_ptr().
This lets us drop the __maybe_unused annotations
from its suspend and resume callbacks,
also reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled.
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
A null-pointer dereference can occur in usb_make_path() when called from
usbtv_querycap() (and other ioctl handlers) during device disconnection.
Oops: general protection fault, probably for non-canonical address
0xdffffc000000000a: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
RIP: 0010:usb_make_path include/linux/usb.h:985 [inline]
RIP: 0010:usbtv_querycap+0x9c/0x100
drivers/media/usb/usbtv/usbtv-video.c:612
...
Call Trace:
<TASK>
v4l_querycap+0x236/0x470 drivers/media/v4l2-core/v4l2-ioctl.c:1106
__video_do_ioctl+0x8af/0xc70 drivers/media/v4l2-core/v4l2-ioctl.c:3133
video_usercopy+0x860/0x1430 drivers/media/v4l2-core/v4l2-ioctl.c:3475
v4l2_ioctl+0x18d/0x1e0 drivers/media/v4l2-core/v4l2-dev.c:366
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
This happens due to a race condition between the USB device disconnect
routine (usbtv_disconnect()) and V4L2 ioctls. When the device is
disconnected, usbtv_disconnect() sets usbtv->udev = NULL without holding
the usbtv->v4l2_lock mutex. Concurrently, an ioctl handler like
usbtv_querycap() can be executing under the v4l2_lock and attempt to use
usbtv->udev, leading to a crash.
To fix this, move the usbtv->udev = NULL assignment into usbtv_video_free()
and protect it with mutex_lock(&usbtv->v4l2_lock). This ensures that no
non-queue ioctl handler can run concurrently with the pointer being
nullified. If an ioctl is already running, the mutex will block the
disconnect path until the ioctl finishes. If an ioctl is blocked waiting
for the lock, it will acquire it after the disconnect routine releases it,
but will then check video_is_registered() (which was cleared by
vb2_video_unregister_device()) and safely return -ENODEV.
Acquiring v4l2_lock after vb2_video_unregister_device() avoids
reintroducing a historical deadlock issue, and usbtv_audio_free() remains
safe as it is called before usbtv_video_free().
Fixes: 65e6a2773d65 ("media: usbtv: Remove useless locks in usbtv_video_free()")
Cc: stable@vger.kernel.org
Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+37a57a84893052ab6071@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=37a57a84893052ab6071
Link: https://syzkaller.appspot.com/ai_job?id=5abbe65a-5853-4bc2-9135-5c75f88d51ed
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
start_urb_transfer() stores each allocated URB in dev->urbs[], but sets
urb_streaming only after all URBs have been submitted. If a later URB or
transfer buffer allocation fails, earlier entries are left allocated. A
submission failure calls stop_urb_transfer(), but that function returns
immediately while urb_streaming is false, leaving both submitted and
unsubmitted URBs behind.
Make stop_urb_transfer() release every populated slot regardless of the
streaming flag and clear each slot after release. Route all start errors
through this cleanup. usb_kill_urb() safely handles both submitted and
unsubmitted URBs, while the existing preallocation check preserves the
lifetime of shared transfer buffers.
This issue was found by a static analysis checker and confirmed by
manual source review.
Fixes: 265a6510629a ("V4L/DVB (7621): Add support for Hauppauge HVR950Q/HVR850/FusioHDTV7-USB")
Cc: stable@vger.kernel.org
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
gspca uses vb2_fop_release(), but gspca_disconnect() only unregisters
the video device. If the queue owner closes the device after USB
disconnect, vb2_fop_release() releases the queue and invokes
gspca_stop_streaming() at that point.
gspca_stream_off() calls subdriver stop callbacks and
usb_set_interface() through gspca_dev->dev. By the time the late close
runs, the USB core can have freed the usb_device, resulting in a
use-after-free. This was observed as a KASAN use-after-free in sd_stopN().
Use vb2_video_unregister_device() so the queue is released and streaming
is stopped synchronously during disconnect, while the usb_device is still
valid. Since the helper takes the queue lock, which is usb_lock, call it
after dropping that lock.
Fixes: f729ef5796d8 ("media: videobuf2-v4l2.c: add vb2_video_unregister_device helper function")
Cc: stable@vger.kernel.org # 5.10.x
Suggested-by: Hans Verkuil <hverkuil@kernel.org>
Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
start_urb_transfer() arms dev->bulk_timeout, whose callback
au0828_bulk_timeout() queues dev->restart_streaming; that work in turn
calls start_urb_transfer() and re-arms the timer.
au0828_dvb_unregister() cancels restart_streaming on disconnect but does
not sync bulk_timeout. au0828_usb_release() then frees dev with kfree(),
so a timer still armed or pending at that point can fire after the free
and dereference dev through timer_container_of().
Sync the timer with timer_shutdown_sync() before cancel_work_sync(). The
timer callback queues the work, so the timer must be stopped first; the
shutdown variant is needed because the work re-arms the timer through
start_urb_transfer(). The dvb->frontend == NULL early return guards the
register-failure path where the timer was never set up.
This bug was found by static analysis.
Fixes: 53460c53b761 ("[media] au0828: Add timer to restart TS stream if no data arrives on bulk endpoint")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In cx23885_v4l2_dev_notify_init, &dev->cx25840_work is bound with
cx23885_av_work_handler, and &dev->ir_rx_work and &dev->ir_tx_work
are bound with cx23885_ir_rx_work_handler and
cx23885_ir_tx_work_handler. cx23885_irq can schedule these works on
system_wq when an AV_CORE interrupt is received, and the IR subdevice
can also schedule the IR works from its interrupt service routine via
the v4l2_device notify callback.
If we remove the device, cx23885_finidev makes cleanup and the memory
allocated for dev is released by kfree(dev), while the works mentioned
above may still be pending or running. The sequence of operations that
may lead to a UAF bug is as follows:
CPU0 CPU1
| cx23885_irq
| schedule_work(&dev->cx25840_work)
cx23885_finidev |
cx23885_input_fini(dev) |
cx23885_ir_fini(dev) |
cx23885_shutdown(dev) |
free_irq(pci_dev->irq, dev) |
pci_disable_device(pci_dev) |
cx23885_dev_unregister(dev) |
v4l2_device_unregister(v4l2_dev) |
kfree(dev) |
// dev is freed |
| cx23885_av_work_handler
| // use dev (use-after-free)
Fix it by canceling the works after the IRQ handler that can schedule
them has been stopped, and before proceeding with the remaining
cleanup in cx23885_finidev.
Note that the flush_work() calls in cx23885_input_ir_stop() do not
close this race: they only wait for works that are already queued or
running at that moment, they do not prevent the IRQ handler, which is
still registered at that point, from scheduling the works again
afterwards, and they are skipped entirely when dev->sd_ir is NULL.
The cancel_work_sync() calls are therefore placed after free_irq(),
the only point at which no new work can be scheduled.
Fixes: e5514f104d87 ("V4L/DVB: cx23885: Move AV Core irq handling to a work handler")
Cc: stable@vger.kernel.org
Assisted-by: Codex:deepseek-v4-flash
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
hackrf_alloc_urbs() frees the URBs it allocated so far when one
allocation fails, but leaves the entries in dev->urb_list[] and
dev->urbs_initialized untouched. The caller, hackrf_start_streaming(),
then calls hackrf_free_urbs() on the error path, which walks
dev->urbs_initialized entries and calls usb_free_urb() a second time on
the already-freed URBs, causing a use-after-free (slab-use-after-free
Write in usb_free_urb()).
Drop the redundant cleanup loop inside hackrf_alloc_urbs() and let
hackrf_free_urbs(), which the caller already invokes on error, own the
cleanup of the successfully allocated URBs.
Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d
Fixes: 969ec1f6bd92 ("[media] hackrf: HackRF SDR driver")
Cc: stable@vger.kernel.org
Signed-off-by: Anuj Bolewar <bolewara@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
In pvr2_send_request_ex(), when usb_urb_ep_type_check() fails for either
the write or read control endpoint, the code returned -EINVAL directly
without clearing the corresponding pending flags (ctl_write_pend_flag or
ctl_read_pend_flag) or going through the done: cleanup path.
This left the pending flags set while the URBs were never actually
submitted. On the next call to pvr2_send_request_ex(), the URBs would be
filled and submitted while the kernel still considered them active,
triggering the WARNING "URB submitted while active" in usb_submit_urb().
Fix this by:
- Clearing the pending flag before returning on invalid endpoint
- Using goto done instead of direct return to go through proper cleanup
- For the read endpoint case, unlinking the write URB if it was already
submitted and waiting for its completion before returning
Reported-by: syzbot+20fef510634faf733060@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=20fef510634faf733060
Signed-off-by: Nguyen Quang Le Kien <khiemtranzo532001@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> says:
These two patches were originally part of
https://lore.kernel.org/all/20260907083727.733705-1-srinivas.kandagatla@oss.qualcomm.com/
As Suggested by Charles and Pierre am sending them as independent
of the rest of that series and can be picked up on their own.
Patch 1 adds SDCA_FUNCTION_TYPE_SIMPLE_JACK to the class function
driver's auxiliary id table so a SimpleJack auxdev is bound and
enumerated as an ASoC component, and wires set_jack for this
function type so the machine driver can register an ASoC jack
against it.
Patch 2 is a small cleanup: find_sdca_control_reset() only ever
returns 0, so convert it to void and drop the dead error check in
the caller. No functional change.
Both patches already carry Reviewed-by tags from Charles and
Pierre-Louis from the original posting.
Link: https://patch.msgid.link/20260908063644.463819-1-srinivas.kandagatla@oss.qualcomm.com
|
|
find_sdca_control_reset() only ever returns 0 -- it just sets
control->has_reset / control->reset for the framework-known
(entity type, control selector) mappings. The int return + caller
error check in find_sdca_entity_control() are dead code.
Convert to void and drop the check. No functional change.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908063644.463819-3-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add SDCA_FUNCTION_TYPE_SIMPLE_JACK to the class function driver's
auxiliary id table so a SimpleJack auxdev is bound and enumerated as
an ASoC component. Wire set_jack for this function type so the machine
driver can register an ASoC jack against it.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908063644.463819-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
dibs->lock is acquired in process context and interrupt context
(ism_handle_irq()). So always use spin_lock_irqsave() in process context.
Note that this is not a real deadlock, as dibs_lo devices don't have
any interrupt context.
Example warning:
[ 153.760872] ================================
[ 153.760878] WARNING: inconsistent lock state
[ 153.760885] 7.2.0-15871-g544d85de4dc2 #16 Not tainted
[ 153.760891] --------------------------------
[ 153.760896] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 153.760901] python3/5134 [HC0[0]:SC0[2]:HE1:SE0] takes:
[ 153.760909] 0001222c0fe72428 (&dibs->lock){?...}-{2:2}, at: dibs_lo_move_data+0x1ce/0x380
[ 153.760932] {IN-HARDIRQ-W} state was registered at:
[ 153.760937] __lock_acquire+0x59c/0x15d0
[ 153.760947] lock_acquire.part.0+0x11c/0x290
[ 153.760953] lock_acquire+0xb4/0x1e0
[ 153.760959] _raw_spin_lock+0x58/0xb0
[ 153.760966] ism_handle_irq+0x80/0x3f0 [ism]
[ 153.760974] __handle_irq_event_percpu+0x282/0x920
[ 153.760983] handle_irq_event_percpu+0x26/0xe0
[ 153.760989] handle_percpu_irq+0x10e/0x1a0
[ 153.760997] handle_irq_desc+0xa6/0x100
[ 153.761003] zpci_floating_irq_handler+0x3ca/0x610
[ 153.761011] do_airq_interrupt+0x206/0x500
[ 153.761018] __handle_irq_event_percpu+0x282/0x920
[ 153.761025] handle_irq_event_percpu+0x26/0xe0
[ 153.761031] handle_percpu_irq+0x10e/0x1a0
[ 153.761039] handle_irq_desc+0xa6/0x100
[ 153.761045] do_irq_async+0xec/0x150
[ 153.761052] do_io_irq+0x150/0x2e0
[ 153.761060] io_int_handler+0xec/0x118
[ 153.761066] arch_cpu_idle+0x120/0x130
[ 153.761118] arch_cpu_idle+0xbe/0x130
[ 153.761124] s390_enter_idle+0x20/0x30
[ 153.761131] cpuidle_enter_state+0xb6/0x440
[ 153.761138] cpuidle_enter+0x64/0xb0
[ 153.761144] cpuidle_idle_call+0x174/0x380
[ 153.761151] do_idle+0x16e/0x250
[ 153.761157] cpu_startup_entry+0x70/0x80
[ 153.761163] smp_start_secondary+0x36e/0x440
[ 153.761171] restart_int_handler+0x72/0x88
[ 153.761178] irq event stamp: 46536
[ 153.761182] hardirqs last enabled at (46536): [<000127b697450a90>] __local_bh_enable_ip+0x140/0x270
[ 153.761193] hardirqs last disabled at (46535): [<000127b697450b20>] __local_bh_enable_ip+0x1d0/0x270
[ 153.761202] softirqs last enabled at (46532): [<000127b6185f82c8>] smc_close_active+0x438/0xba0 [smc]
[ 153.761232] softirqs last disabled at (46534): [<000127b6185ee998>] smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
[ 153.761257]
other info that might help us debug this:
[ 153.761262] Possible unsafe locking scenario:
[ 153.761267] CPU0
[ 153.761271] ----
[ 153.761274] lock(&dibs->lock);
[ 153.761282] <Interrupt>
[ 153.761286] lock(&dibs->lock);
[ 153.761294]
*** DEADLOCK ***
[ 153.761299] locks held by python3/5134: 3, last CPU#1:
[ 153.761305] #0: 0001222bab975f50 (&sb->s_type->i_mutex_key#11){+.+.}-{3:3}, at: __sock_release+0x7e/0x230
[ 153.761329] #1: 0001222ba5450378 (sk_lock-AF_SMC){+.+.}-{0:0}, at: smc_close_active+0x438/0xba0 [smc]
[ 153.761360] #2: 0001222ba54508a0 (&smc->conn.send_lock){+...}-{2:2}, at: smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
[ 153.761394]
stack backtrace:
[ 153.761400] CPU: 1 UID: 0 PID: 5134 Comm: python3 Not tainted 7.2.0-15871-g544d85de4dc2 #16 PREEMPT
[ 153.761406] Hardware name: IBM 3931 A01 703 (LPAR)
[ 153.761408] Call Trace:
[ 153.761409] [<000127b697366190>] dump_stack_lvl+0xe8/0x140
[ 153.761415] [<000127b6975ccc8c>] print_usage_bug.part.0+0x2ec/0x3a0
[ 153.761419] [<000127b6975cd454>] mark_lock_irq+0x714/0xa20
[ 153.761422] [<000127b6975cda52>] mark_lock+0x2f2/0x790
[ 153.761426] [<000127b6975ce2e6>] mark_usage+0x136/0x1c0
[ 153.761430] [<000127b6975ce90c>] __lock_acquire+0x59c/0x15d0
[ 153.761433] [<000127b6975cfa5c>] lock_acquire.part.0+0x11c/0x290
[ 153.761437] [<000127b6975cfc84>] lock_acquire+0xb4/0x1e0
[ 153.761441] [<000127b699d02a98>] _raw_spin_lock+0x58/0xb0
[ 153.761444] [<000127b6992ca4fe>] dibs_lo_move_data+0x1ce/0x380
[ 153.761449] [<000127b6185f0912>] smcd_tx_ism_write+0x182/0x250 [smc]
[ 153.761469] [<000127b6185ee4c6>] smcd_cdc_msg_send+0x156/0x410 [smc]
[ 153.761487] [<000127b6185ee9a2>] smc_cdc_get_slot_and_msg_send+0x222/0x370 [smc]
[ 153.761507] [<000127b6185f8370>] smc_close_active+0x4e0/0xba0 [smc]
[ 153.761526] [<000127b6185a293c>] __smc_release+0x4ac/0x6a0 [smc]
[ 153.761546] [<000127b6185a2c6e>] smc_release+0x13e/0x480 [smc]
[ 153.761565] [<000127b6994544d4>] __sock_release+0xa4/0x230
[ 153.761569] [<000127b69945468c>] sock_close+0x2c/0x40
[ 153.761573] [<000127b697e57180>] __fput+0x2f0/0x880
[ 153.761579] [<000127b697e58440>] fput_close_sync+0xd0/0x1c0
[ 153.761583] [<000127b697e4b3f0>] __s390x_sys_close+0x90/0xf0
[ 153.761586] [<000127b699cdc19e>] __do_syscall+0x1be/0x5a0
[ 153.761590] [<000127b699d04c7a>] system_call+0x72/0x90
[ 153.761594] INFO: lockdep is turned off.
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Link: https://patch.msgid.link/20260904094446.1342654-1-wintera@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
After commit cd51b74bdd0b ("ipv6: Fix redirect exception creation for
UDP/RAW sockets") the two redirect calls are now equivalent and there is
no need to specifically call ip6_redirect() for tunnel sockets. Simplify
and call ip6_sk_redirect() for both tunnel sockets and regular sockets.
Note that for ICMPv6 Redirect Message packets the VRF driver does not
reset skb->dev to the VRF device, so skb->dev->ifindex is equivalent to
inet6_iif(skb), even when the packet was received from a VRF port.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260907101358.596953-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260907064346.3288-1-hemanth.selam@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The type of transaction data should be __be32 in the stub function for the
asynchronous transactions.
Fixes: 23e0d2e849eb ("firewire: core: add test to detect irm-is-1394-1995-only quirk in config ROM parser")
Fixes: f8e5070bf292 ("firewire: core: add test to avoid excessive configuration ROM length")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609060257.8wQo9w9N-lkp@intel.com/
Link: https://lore.kernel.org/r/20260908122929.2886698-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The type of the hard-coded configuration ROM image should be __be32
instead of u32.
Fixes: ee9a8c9afb57 ("firewire: core: add test for root directory generation in config ROM generator")
Fixes: 996096154e7b ("firewire: core: add test to generate with AV/C unit in config ROM generator")
Fixes: 7bd19bbed9ea ("firewire: core: add test to generate with IIDC unit in config ROM generator")
Fixes: c3b64c7d752c ("firewire: core: add test to generate with both AV/C and IIDC units in config ROM generator")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609060630.rC0Zz88P-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609061023.GbWS6Skb-lkp@intel.com/
Link: https://lore.kernel.org/r/20260908122900.2886661-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The source bus ID bit in AT DMA context is not detected correctly on
big-endian systems because the little-endian data is not converted to
CPU endianness.
Fix the bug. The helper functions related to this are never used in
driver code, so extend the test to check the field instead.
Cc: stable@vger.kernel.org # v6.12
Fixes: 8db9d1557122 ("firewire: ohci: add static inline functions to serialize/deserialize data of AT DMA")
Link: https://lore.kernel.org/r/20260908122840.2886621-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
flush the L2/HDC data cache before fence signalling, but it never
requests a flush of the LSC untyped L1 data cache via the 'Untyped
Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].
Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to
also flush/invalidate the untyped L1 cache, but only depending on how
HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
between HDC Pipeline Flush and the untyped L1 cache flush no longer
holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan
driver (anv) has been assuming the kernel flushes both caches between
submissions, and hit user-visible corruption in apps such as Llama.cpp
because of this gap; it now works around it by flushing both caches
again from userspace at the end of every command buffer.
Correctness between submissions on the same queue is userspace's
responsibility and belongs in Mesa, not the kernel. However, for
security we must ensure stale data can't leak through the untyped L1
dataport cache once memory is reclaimed or evicted, which requires the
KMD to flush it before releasing memory for reuse.
Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for
DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline
Flush coupled to the untyped L1 cache flush, so those platforms are
unaffected. Mesa's own anv driver found that on MTL the HW
disconnected the two independently of how HDC_CHICKEN0 is programmed,
and could not bring the old behavior back even by writing the register
by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped
cache flush in 3D mode"). The kernel can't reliably request the flush
from the CS on MTL either, so restrict the new PIPE_CONTROL bit to
GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on.
Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together
with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on
Xe2 and later, so the L1 data cache is known clean before memory is
released for reuse, without depending on undocumented
platform-specific HDC_CHICKEN0 behavior.
Bspec: 56551
Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3
Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch")
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: intel-xe@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.8+
Assisted-by: GitHub_Copilot:claude-sonnet-5
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com
|
