| Age | Commit message (Collapse) | Author |
|---|
|
DAI parameter will be capsuled soon, will be not enable to access from
soc-dai.h. Move it to soc-dai.c
These macros are very similar. Will be handled by same macro
snd_soc_dai_dma_data_get() -> snd_soc_dai_stream_dma_data_get()
snd_soc_dai_dma_data_set() -> snd_soc_dai_stream_dma_data_set()
snd_soc_dai_get_dma_data() -> snd_soc_dai_stream_dma_data_get()
snd_soc_dai_set_dma_data() -> snd_soc_dai_stream_dma_data_set()
This macro is not much helps code, will be removed
snd_soc_dai_init_dma_data()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87mru2ssjx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
DAI parameter will be capsuled soon, will be not enable to access from
soc-dai.h. Move it to soc-dai.c
It renames function name
snd_soc_dai_get_widget() -> snd_soc_dai_stream_widget_get()
snd_soc_dai_set_widget() -> snd_soc_dai_stream_widget_set()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87o6eissk1.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
DAI parameter will be capsuled soon, will be not enable to access from
soc-dai.h. Move it to soc-dai.c
It renames function name
snd_soc_dai_get_pcm_stream() snd_soc_dai_pcm_stream_get()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87pkyyssk4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
soc_pcm_{apply/params/update}_symmetry() are DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-pcm.c. Move it to soc-dai.c
It renames function name
- soc_pcm_xxx_symmetry()
+ snd_soc_dai_symmetric_xxx()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87qzjessk7.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
soc_pcm_set_dai_params() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-pcm.c. Move it to soc-dai.c
It renames function name
- soc_pcm_set_dai_params()
+ snd_soc_dai_symmetric_set_params()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87se3usska.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_{un}register_dai() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-core.c. Move it to soc-dai.c
Note1
snd_soc_{un}register_dai() needs to use client_mutex which is soc-core.c
local. This patch removes static from it, and allow to use it from ASoC
internal.
It renames function name
- snd_soc_register_dai()
+ snd_soc_dai_register()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87tsoasske.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_is_matching_dai() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-core.c. Move it to soc-dai.c
It renames function name
- snd_soc_is_matching_dai()
+ snd_soc_dai_matches_dlc()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87v78qsskh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_is_match_dai_args() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-core.c. Move it to soc-dai.c
It renames function name
- snd_soc_is_match_dai_args()
+ snd_soc_dai_matches_args()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87wlt6sskk.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_dai_name_get() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-core.c. Move it to soc-dai.c
It renames function name
- snd_soc_dai_name_get()
+ snd_soc_dai_name()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87y0dmssko.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_add_dai_controls() is DAI related function.
And its parameter will be capsuled soon, will be not enable to access from
soc-core.c. Move it to soc-dai.c
It renames function name
- snd_soc_add_dai_controls()
+ snd_soc_dai_add_controls()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87zey2ssku.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
DAI/Component will be capsuled soon, but fmt_{single/multiple}_name()
will be used form soc-dai.c / soc-component.c.
Let's makes them to non static function.
ASoC functions / macros are defined at linux/include/sound/xxx.h (A).
ASoC framework and each vender drivers are including it.
Some functions / macros which are only for ASoC framework. It shouldn't
be used from vender drivers. But we can't foce it because sharing same
headers (A).
This patch adds new soc-internal.h (B) which is for ASoC framework
internal use. Since this patch, we can separate global functions (for
vender drivers) and local function (for ASoC framework internal use).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/871pbeu75e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
acpi_os_vprintf() formats every ACPICA diagnostic into a 512-byte static
buffer with an unbounded vsprintf():
static char buffer[512];
vsprintf(buffer, fmt, args);
ACPICA interpolates table-derived namespace paths into its messages, so the
length is driven by table content. A malformed ACPI table can therefore
produce a diagnostic longer than the buffer and overwrite whatever follows
it.
From the System.map of an x86_64_defconfig build, acpi_ioremap_lock sits 624
bytes into that buffer - 112 bytes past its end - so bytes 624..631 of an
over-long message land on the mutex's owner field, which __mutex_lock() then
dereferences.
The overwritten bytes are attacker-influenced but not attacker-controlled:
they are printable ASCII from a NUL-terminated string, so the resulting
pointer is always non-canonical and always faults. This is a reliable denial
of service, not a demonstrated pointer-control primitive.
Because acpi_tb_load_namespace() parses the DSDT and every SSDT during
acpi_init(), a table supplied by firmware triggers this in PID 1 inside
do_one_initcall(), panicking the kernel before userspace exists.
Bound the write with vsnprintf(). Truncating a diagnostic is strictly better
than corrupting adjacent kernel objects.
Tested on pristine Linux 7.2.2 - tag: v7.2.2., Stock x86_64_defconfig
(no KASAN, no debug options), table supplied by firmware via
"qemu -acpitable":
[ 0.022259] ACPI: SSDT 0x000000003FFE1C52 000640 (v01 _ASUS_
Notebook 00000005 MSFT 0100000D)
[ 0.353684] Oops: general protection fault, probably for
non-canonical address
0x41435f2e345f2e64: 0000 [#1] SMP NOPTI
[ 0.353727] RIP: 0010:__mutex_lock.constprop.0+0xbd/0xa40
[ 0.353727] RAX: 41435f2e345f2e30 RBX: 00000000fed00000
[ 0.353727] R15: ffffffff8c248530
[ 0.353727] Call Trace:
[ 0.353727] acpi_os_map_iomem
[ 0.353727] acpi_ex_system_memory_space_handler
[ 0.353727] acpi_ev_address_space_dispatch
[ 0.353727] acpi_ex_access_region
[ 0.353727] acpi_ex_read_data_from_field
[ 0.353727] acpi_ex_resolve_node_to_value
[ 0.353727] acpi_ds_evaluate_name_path
[ 0.353727] acpi_ps_parse_loop
[ 0.353727] acpi_ps_execute_method
[ 0.354729] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
RAX is the corrupted owner; the faulting address is RAX + 0x34.
R15 matches acpi_ioremap_lock. On a KASAN build the overflow is
reported directly as:
BUG: KASAN: global-out-of-bounds in string.
Signed-off-by: Vlatko Kosturjak <vlatko.kosturjak@gmail.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/CAPAw8HEMdsNN6WhizHkv2Orp2pkQ2-g009XCGFnKnhXoRhcKZQ@mail.gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
2020) RZ09-0310
This patch adds a quirk mapping for the "Blade Stealth 13 (Early 2020) -
RZ09-0310" laptop, which exhibits the same issue as the following two
related products already accounted for in this file.
- Razer Blade Stealth 13 Late 2019
- Blade Pro 17 (Early 2020) - RZ09-0329
Summary of the issue this fixes:
The firmware's _LID method still returns "closed" after resume when the
lid was opened during S3, causing systemd-logind to suspend the system
again within several seconds (15-40) after waking.
Signed-off-by: Ian Gallagher <cdine@cdine.org>
Link: https://patch.msgid.link/90ab9b58-da8b-4ffc-bd4b-adf7590545a9@app.fastmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
rockchip_sfc_probe enables runtime PM and leaves the device active with
a usage count held by pm_runtime_get_noresume(). The remove callback
only disables the clocks and does not disable runtime PM, leaving the
device in an inconsistent state and leaking the runtime PM reference.
Add the missing runtime PM teardown in rockchip_sfc_remove to balance
the probe's enable and get_noresume calls.
Signed-off-by: jiawen <1298662399@qq.com>
Link: https://patch.msgid.link/tencent_DD16C0EEDFEF4ACAFAB5A23EC8235D462707@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When building rpmsg_client_sample.c for a 32-bit platform, such as
during arm allmodconfig, there are a few warnings due to using an
incorrect specifier for mtu:
samples/rpmsg/rpmsg_client_sample.c:68:59: error: format specifies type 'long' but the argument has type 'ssize_t' (aka 'int') [-Werror,-Wformat]
68 | dev_warn(&rpdev->dev, "invalid rpmsg MTU size = %ld\n", mtu);
| ~~~ ^~~
| %zd
...
samples/rpmsg/rpmsg_client_sample.c:72:50: error: format specifies type 'long' but the argument has type 'ssize_t' (aka 'int') [-Werror,-Wformat]
72 | dev_info(&rpdev->dev, "rpmsg MTU size = %ld\n", mtu);
| ~~~ ^~~
| %zd
...
samples/rpmsg/rpmsg_client_sample.c:79:17: error: format specifies type 'long' but the argument has type 'ssize_t' (aka 'int') [-Werror,-Wformat]
78 | "message size %zu exceeds rpmsg MTU size %ld\n",
| ~~~
| %zd
79 | strlen(MSG), mtu);
| ^~~
Use '%zd', the proper specifier for a 'ssize_t' variable, to clear up
the warning. Additionally, modify the last dev_err() call in
rpmsg_sample_probe() to reuse msg_len instead of calling strlen(MSG)
again and use '%zd' throughout the string consistently.
Fixes: 1029c89bafc7 ("samples: rpmsg: Add MTU size info")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20260908-samples-rpmsg-fix-mtu-print-v1-1-f995518f0a46@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
query_capability() copies four ACPI buffers into fixed-size fields using
the firmware-supplied lengths. The existing overflow guard rejects
oversized buffers, but shorter buffers are accepted and leave trailing
bytes of the stack-allocated cap_hdr uninitialized. PFRU_IOC_QUERY_CAP
then copies the entire structure to userspace.
Zero-initialize cap_hdr before querying the firmware. This preserves the
existing handling of short firmware responses while preventing disclosure
of kernel stack data. Oversized buffers remain rejected.
A QEMU _DSM returning one-byte buffers reproduced nonzero stack suffix
bytes in all four fields. With this change, the ioctl still succeeds and
each unwritten suffix is zero-filled, while 64-byte buffers continue to
return -EINVAL.
Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/1a001e1fee9.637da6dc3533246.238498880682901704%40a0rg.com
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260827053741.79425-1-kmehltretter@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
get_node_num() iterates over the populated zones of every online node
with a nested loop. for_each_populated_zone() iterates over the same
zones in the same order.
So use for_each_populated_zone() instead and remove the unused
variable.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260821131530.3375820-1-ekffu200098@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
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
(cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
During VM teardown, the VM's runtime PM reference is dropped
asynchronously, allowing the device to autosuspend while stale page
faults belonging to the now-dead VM are still queued. When the
page-fault worker later tries to ack one of these, it calls into
guc_ct_send_locked() on an already-suspended device, tripping:
Assertion `!xe_pm_runtime_suspended(xe)` failed!
WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe]
A live VM/exec queue always holds a PM reference while it has
outstanding work, so if the device is suspended at ack time, the
owning context is already gone and the fault is stale.
Take a runtime PM reference across the entire pagefault
queue worker to safely deliver acks for torn-down VMs.
v3:
- Move PM ref to the generic xe_pagefault_queue_work using
guard(xe_pm_runtime)(xe) instead of tracking it in the GuC
backend(Matt Brost).
v2:
- Hold PM ref across the entire batch (begin/end) instead of per-ack.
This prevents the device from autosuspending mid-batch, which would
leave write_only acks written but the end flush skipped, and skip
counter++, desyncing the cadence check.(Himal)
- Add a comment explaining stale faults.(Himal)
Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer")
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: Added xe_device struct for compatibility while cherry-picking]
|
|
The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has
seen a couple of changes that seems to cause a bit of confusion.
While sn65dsi83_reset_work() has implemented an early exit if
sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime
Ripard switched to use drm_bridge_helper_reset_crtc() [1] the
sn65dsi83_reset_pipe() function would no longer return an error code, so
the early exit was then a no-op, and even on sn65dsi83_reset_pipe()
failure, enable_irq() has been called.
When drm_bridge_enter()/drm_bridge_exit() resource protection was added,
the drm_bridge_exit() incidentally was always called, which is the correct
approach. But only because the early exit in sn65dsi83_reset_pipe() was
never hit because sn65dsi83_reset_pipe() always returns 0.
In order get back to a situation where enable_irq() is not called on
sn65dsi83_reset_pipe() failure, which should help protect against irq
storms, we need to reintroduce a non-zero return value from
sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we
always exit the DRM bridge critical section with drm_bridge_exit().
[1] commit e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc")
[2] commit d2e8d1bc840b ("drm/bridge: ti-sn65dsi83: protect device resources on unplug")
Fixes: e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc")
Cc: stable@vger.kernel.org
Signed-off-by: Esben Haabendal <esben@geanix.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of
the DACL they build in a u16. That accumulator can wrap.
validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) /
20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can
grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with
one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is
therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond
what a u16 can hold. A wraparound is reached with 863 ACEs.
After the wraparound, ndacl_ptr->size becomes meaningless and the offset
will point anywhere in the ACE array. As a result, we will see
corruption of the DACL, which then gets sent to the server. This is not
an out-of-bounds write as the allocation now covers the worst-case
expansion, so writes will always go into the buffer.
Adjust the code to use a u32 internally and return -EOVERFLOW in the
overflow case. The operation must be refused, because a DACL can only
hold 2^16-1 bytes on the wire and larger DACLs cannot be represented.
set_chmod_dacl() carries the same pattern and is fixed the same way. It
only wraps once the source DACL comes within roughly 380 bytes of the
64K ceiling, but the failure mode is identical.
Suggested-by: Namjae Jeon <linkinjeon@kernel.org>
Cc: stable@vger.kernel.org
Fixes: f5065508897a ("cifs: Retain old ACEs when converting between mode bits and ACL.")
Assisted-by: Kiro:claude-opus-5
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
|
|
When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a
buffer sized according to the on-disk DACL length reported by
dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each
ACE with a new owner/group SID obtained from the cifs.idmap upcall.
Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities,
making each ACE up to 76 bytes (sizeof(struct smb_ace)).
If the original DACL contains short SIDs (e.g., 1 sub-authority) while
the replacement SIDs are long, the rewritten ACEs overflow the
allocation.
Fix this by always budgeting for worst-case SID expansion: allocate
sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which
covers the smb_acl header and room for every ACE at maximum SID size.
This replaces the previous split logic that used dacl_ptr->size for
cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid
mounts: both paths can trigger the same rewrite and need the same
headroom.
KASAN reports this as:
BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs]
Write of size 4 at addr ffff8881a5e25374 by task chown/5298
...
The buggy address is located 0 bytes to the right of
allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)
Cc: stable@vger.kernel.org
Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.")
Assisted-by: Kiro:claude-opus-4.6
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Fixes: 5c3564852c58 ("cifs: Minimize the number of cifs_acl memory allocations")
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
|
|
nau8822_suspend() disables all codec supplies and marks the register
cache dirty, but leaves regmap in live I/O mode. Resume then attempts
the cache replay without first leaving a corresponding cache-only state.
Enter cache-only mode after the regulators have been disabled
successfully, leave it after the supplies are restored, and stop the
local resume sequence if cache replay fails. Do not power the codec back
down on a resume error, because deferred component resume remains best
effort and continues after the callback.
regulator_bulk_disable() restores regulators already disabled by the
same bulk operation if a later disable fails. Only publish cache-only
state after the whole power-off operation succeeds, so the regmap state
continues to match the hardware state on either outcome.
Fixes: 1e3cb6c321be ("ASoC: nau8822: new codec driver")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830141828.34419-1-pengpeng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Devices supporting only the legacy _BIF ACPI control method cannot
know the cycle count of the associated battery, so cycle_count always
remains 0. Claiming support for POWER_SUPPLY_PROP_CYCLE_COUNT on
such devices can thus mislead userspace applications and prevents
power supply extensions from supplying correct cycle count values.
Fix this by not claiming support for POWER_SUPPLY_PROP_CYCLE_COUNT
on devices without _BIX.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260806233817.622975-1-W_Armin@gmx.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux
Pull printk fixes from Petr Mladek:
- Use lazy irq_work for waking printk kthreads
- Flush pending irq_work before destroying printk kthreads
- Remove redundant WARN() when a printk kthread can't be created
- Typo fix
* tag 'printk-for-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
printk/nbcon: Change nbcon_irq_work to IRQ_WORK_LAZY
printk/nbcon: Flush nbcon_irq_work in nbcon_free()
console: fix /dev/kmsg reference in flags kernel doc
printk: Don't WARN on kthread_run failure.
|
|
The documentation file for the AYANEO platform EC driver was added as
Documentation/ABI/testing/sysfs-platform-ayaneo-ec, but MAINTAINERS
references it without the '-ec' suffix, causing 'make refcheckdocs'
to report a broken reference.
Update the file entry to point to the correct file name.
Signed-off-by: Gabriel Windlin <gawindlin@gmail.com>
Link: https://patch.msgid.link/20260908203412.608606-1-gawindlin@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
msgdma_probe() registers the IRQ before initializing the tasklet, lock,
and descriptor lists used by the interrupt handler. A pending interrupt
can access incomplete state during probe.
Initialize the handler state before requesting the IRQ so the interrupt
path observes ready software state.
Fixes: a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Acked-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260830053308.2190597-1-runyu.xiao@seu.edu.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Convert TI CPPI 4.1 DMA controller text bindings to DT schema. Add
ti,am3359-cppi41 and ti,da830-cppi41 into single schema since they share
the same hardware IP block and driver. Add undocumented #dma-requests
and power-domains properties to match existing DTS usage.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-1-5e15c617d2e9@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Convert Texas Instruments DMA Crossbar from text to DT schema.
Modify MAINTAINERS file to correctly point to new yaml file.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260825-ti-dma-crossbar-v4-1-b0bc78cf071e@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The DP1000 integrates a DMA controller.
Add its SoC-specific compatible with the generic fallback.
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260907-ultrarisc-dts-v2-7-5eb4c97477c5@ultrarisc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Commit 3f30db282c28 ("dmaengine: zynqmp_dma: Fix chan probe/remove error
handling") dropped the use of err_disable_pm label causing warning:
drivers/dma/xilinx/zynqmp_dma.c: In function ‘zynqmp_dma_probe’:
drivers/dma/xilinx/zynqmp_dma.c:1171:1: error: label ‘err_disable_pm’ defined but not used [-Werror=unused-label]
1171 | err_disable_pm:
Drop it
Fixes: 3f30db282c28 ("dmaengine: zynqmp_dma: Fix chan probe/remove error handling")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260903170357.1711462-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Both eDMA and HDMA perform the same remote LL read-back immediately
before writing the doorbell register.
A later patch serializes each raw doorbell write against IRQ event
capture. Keeping the read-back in the provider callback would hold
event_lock across a remote read. Move the common read-back into the
high-level dw_edma_core_ch_doorbell(), where it can run before the
serialized section. Name the provider write wrapper
dw_edma_core_do_ch_doorbell() to distinguish the raw write, and leave
dw_edma_core_ch_maybe_doorbell() to decide whether a kick is needed.
No functional change.
Suggested-by: Frank Li <Frank.li@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-11-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
A later change serializes status capture, interrupt clear, and event
recording against channel restart. It must also publish all causes
observed for a channel in that critical section through one callback.
Otherwise, the deferred worker can consume one cause before another from
the same status pass is recorded.
Replace the DONE and ABORT callback pair with one callback carrying an
event bitmap. For now, map the bitmap back to the existing deferred DONE
and ABORT work, so behavior remains unchanged.
Also split DONE handling into a lock-taking wrapper and a vc.lock-held
body. The later LL event path needs to validate its recorded event under
vc.lock before running the existing DONE state machine.
No functional change.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-10-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
A later patch records each observed LL event (STOP or PROGRESS) together
with the LLP sample taken in the same interrupt-handler pass. It needs a
provider operation to clear stale LL interrupt status before a channel
restart. Add it.
Centralize runtime request updates in dw_edma_set_request(). A later
patch uses it to cancel a pending LL recheck when STOP or PAUSE changes
the channel policy. Rename the existing workqueue event bits to
distinguish them from provider IRQ events.
No functional change.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-9-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
LL fill currently rings the doorbell every time. A running eDMA or HDMA
channel follows entries whose CB matches CCS without another kick. A
channel stopped at a CB mismatch needs one.
Move that decision to dw_edma_core_ch_maybe_doorbell(). It rings only
for a BUSY LL channel with pending entries, no EDMA_REQ_STOP or
EDMA_REQ_PAUSE. The BUSY check prevents EDMA_REQ_STOP completion from
restarting terminated work.
issue_pending() still publishes LL entries only from IDLE. A later patch
allows live appends. Non-LL channels are unchanged.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-8-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Prepare for a later patch that reclaims LL progress before request handling
and can remove the last issued descriptor. Move the request switch outside
the common descriptor check.
Keep the existing per-request descriptor checks for now. That later patch
removes them when STOP/PAUSE handling becomes independent of the descriptor
list.
No functional change.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-7-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Move dw_hdma_set_callback_result() next to the descriptor helpers so
linked-list completion and reset code can use it without a forward
declaration.
No functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-6-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The driver currently rebuilds the whole linked list for every transfer.
Use it as a circular ring instead. Append entries at ll_head with the
current cycle bit, and reserve the final entry for the link back to the
start.
Clear control words before first use so stale cycle bits cannot become
valid entries. Reject rings without usable data slots and, until reclaim
support lands, descriptors that exceed the usable ring capacity.
Termination and abort can discard descriptors while ll_done still trails
ll_head. Reset the ring after the channel has stopped so the next transfer
does not inherit occupied slots.
This prepares the driver for appending requests while the engine runs.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Co-developed-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-5-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Move linked-list programming into dw_edma_core_ll_start(). It can derive
the first-batch state from desc->start_burst, so dw_edma_core_start() no
longer needs a pass-through argument.
No functional change.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-4-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add a core operation for clearing the control word of one linked-list
entry. A later patch uses the operation to invalidate stale CB when
resetting a circular LL ring.
No functional change.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-3-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add dw_edma_core_ll_cur_idx() to get the current LL entry index and
prepare for dynamic addition of DMA requests while the DMA engine is
running.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Co-developed-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260820173439.2004068-2-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
xilinx_dma_get_metadata_ptr() returns the AXI DMA APP words from the SOP
descriptor in both directions. This is wrong for RX, where the hardware
writes the APP words into the EOF descriptor. It also leaves AXI MCDMA
without metadata support.
Return the metadata from the SOP descriptor for TX and from the EOF
descriptor for RX, matching where the hardware reads and writes the
fields. For AXI DMA, expose the APP words (20 bytes). For AXI MCDMA,
expose the control sideband, status, and APP fields (28 bytes). On TX
the control sideband holds TID and TUSER configuration for the outgoing
stream. On RX the sideband status holds the received TID, TDEST and TUSER
from the incoming stream. The field layout differs between MM2S and S2MM,
and the wider payload lets a consumer distinguish the two controllers.
No in-tree consumer is affected.
Read xlnx,axistream-connected for AXI MCDMA. Attach metadata_ops in
xilinx_mcdma_prep_slave_sg() when an AXI4-Stream interface is present,
so MCDMA clients use the metadata API the same way as AXI DMA clients.
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260818174151.1608971-5-srinivas.neeli@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
In AXI MCDMA, xilinx_dma_complete_descriptor() walks the channel's
active_list and unconditionally moves every entry to the done_list. The
MCDMA IOC interrupt handler invokes this function on every
interrupt-on-completion, but with interrupt coalescing (IRQThreshold > 1)
an IOC interrupt may fire after only a subset of the queued descriptors
have actually been processed by the hardware. As a result, descriptors
whose completion bit is not yet set in the BD status were being reported
as completed to client drivers.
Add a check for the descriptor completion bit before moving entries from
the active list to the done list, using the appropriate direction-
specific status field (s2mm_status for DMA_DEV_TO_MEM, mm2s_status for
DMA_MEM_TO_DEV).
This mirrors the AXIDMA fix in commit 7bcdaa658102 ("dmaengine:
xilinx_dma: Freeup active list based on descriptor completion bit").
Fixes: 6ccd692bfb7f ("dmaengine: xilinx_dma: Add Xilinx AXI MCDMA Engine driver support")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260818174151.1608971-3-srinivas.neeli@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The MCDMA BD format differs between memory-to-device (MM2S) and
device-to-memory (S2MM) directions, but the driver was using generic
'status' and 'sideband_status' fields for both. This led to incorrect
residue calculations when the hardware updates direction-specific fields.
Refactor the descriptor structure to use unions with direction-specific
field mappings, and update the residue calculation logic to select the
correct status field based on DMA direction.
This matches the hardware descriptor layout and fixes incorrect
residue reporting.
Fixes: 6ccd692bfb7f ("dmaengine: xilinx_dma: Add Xilinx AXI MCDMA Engine driver support")
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260818174151.1608971-2-srinivas.neeli@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The driver managed its two mandatory clocks (core-clk and cfgr-clk)
individually. This was error prone: axi_dma_resume() enabled cfgr_clk
and then core_clk, and if enabling core_clk failed it returned the
error without disabling cfgr_clk, leaving the clock refcount
unbalanced.
Convert the driver to the clk_bulk API. The two clocks are always
acquired, enabled and disabled together, so a clk_bulk_data array
expresses this naturally and shrinks the get/enable/disable paths.
clk_bulk_prepare_enable() also unwinds any clock it already enabled
when a later one fails, which fixes the resume imbalance.
Fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver")
Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com>
Link: https://lore.kernel.org/all/20260813105432.2577322-1-nagachaithanya9911@gmail.com/
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260816054858.2667380-1-nagachaithanya9911@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The admacs present on t8122 and t603x SoCs need additional writes in
order to operate correctly. The exact purpose of this register
is unknown
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260815-t603x-admac-v4-2-1149e342dcb0@chaosmail.tech
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The admacs seen in M3-generation SoCs (t603x, t8122) need additional
configuration writes and so are getting a new compatible chain.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Reviewed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260815-t603x-admac-v4-1-1149e342dcb0@chaosmail.tech
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Remove the unused ZYNQMP_DMA_SRC_ISSUE_RST_VAL define.
ZYNQMP_DMA_DST_DSCR_DONE was also set twice in the default interrupt enable
mask; remove the duplicate bit.
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260814045616.1661199-9-nagendra.golla@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Zero-length prep_memcpy() needlessly consumed a descriptor slot. Reject
zero-length memcpy at prep time and document the behaviour.
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260814045616.1661199-8-nagendra.golla@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Use of_dma_is_coherent() instead of parsing the common dma-coherent
device-tree property directly.
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260814045616.1661199-7-nagendra.golla@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
