Commit 26dda57695 "tools/bootconfig: Cleanup bootconfig footer size
calculations" replaced some expressions of type int with the
BOOTCONFIG_FOOTER_SIZE macro, which expands to an expression of type
size_t, which is unsigned.
On 32-bit architectures with LFS enabled (i.e. off_t is 64-bit), the
seek offset of -BOOTCONFIG_FOOTER_SIZE now turns into a positive
value.
Fix this by casting the size to off_t before negating it.
Just in case someone changes BOOTCONFIG_MAGIC_LEN to have type size_t
later, do the same thing to the seek offset of -BOOTCONFIG_MAGIC_LEN.
Link: https://lore.kernel.org/all/aKHlevxeg6Y7UQrz@decadent.org.uk/
Fixes: 26dda57695 ("tools/bootconfig: Cleanup bootconfig footer size calculations")
Signed-off-by: Ben Hutchings <benh@debian.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
As described in buffer-format.rst, the existing initramfs.c extraction
logic works fine if the cpio filename field is padded out with trailing
zeros, with a caveat that the padded namesize can't exceed PATH_MAX.
Add filename zero-padding logic to gen_init_cpio, which can be triggered
via the new -a <data_align> parameter. Performance and storage
utilization is improved for Btrfs and XFS workloads, as copy_file_range
can reflink the entire source file into a filesystem block-size aligned
destination offset within the cpio archive.
Btrfs benchmarks run on 6.15.8-1-default (Tumbleweed) x86_64 host:
> truncate --size=2G /tmp/backing.img
> /sbin/mkfs.btrfs /tmp/backing.img
...
Sector size: 4096 (CPU page size: 4096)
...
> sudo mount /tmp/backing.img mnt
> sudo chown $USER mnt
> cd mnt
mnt> dd if=/dev/urandom of=foo bs=1M count=20 && cat foo >/dev/null
...
mnt> echo "file /foo foo 0755 0 0" > list
mnt> perf stat -r 10 gen_init_cpio -o unaligned_btrfs list
...
0.023496 +- 0.000472 seconds time elapsed ( +- 2.01% )
mnt> perf stat -r 10 gen_init_cpio -o aligned_btrfs -a 4096 list
...
0.0010010 +- 0.0000565 seconds time elapsed ( +- 5.65% )
mnt> /sbin/xfs_io -c "fiemap -v" unaligned_btrfs
unaligned_btrfs:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..40967]: 695040..736007 40968 0x1
mnt> /sbin/xfs_io -c "fiemap -v" aligned_btrfs
aligned_btrfs:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..7]: 26768..26775 8 0x0
1: [8..40967]: 269056..310015 40960 0x2000
2: [40968..40975]: 26776..26783 8 0x1
mnt> /sbin/btrfs fi du unaligned_btrfs aligned_btrfs
Total Exclusive Set shared Filename
20.00MiB 20.00MiB 0.00B unaligned_btrfs
20.01MiB 8.00KiB 20.00MiB aligned_btrfs
XFS benchmarks run on same host:
> sudo umount mnt && rm /tmp/backing.img
> truncate --size=2G /tmp/backing.img
> /sbin/mkfs.xfs /tmp/backing.img
...
= reflink=1 ...
data = bsize=4096 blocks=524288, imaxpct=25
...
> sudo mount /tmp/backing.img mnt
> sudo chown $USER mnt
> cd mnt
mnt> dd if=/dev/urandom of=foo bs=1M count=20 && cat foo >/dev/null
...
mnt> echo "file /foo foo 0755 0 0" > list
mnt> perf stat -r 10 gen_init_cpio -o unaligned_xfs list
...
0.011069 +- 0.000469 seconds time elapsed ( +- 4.24% )
mnt> perf stat -r 10 gen_init_cpio -o aligned_xfs -a 4096 list
...
0.001273 +- 0.000288 seconds time elapsed ( +- 22.60% )
mnt> /sbin/xfs_io -c "fiemap -v" unaligned_xfs
unaligned_xfs:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..40967]: 106176..147143 40968 0x0
1: [40968..65023]: 147144..171199 24056 0x801
mnt> /sbin/xfs_io -c "fiemap -v" aligned_xfs
aligned_xfs:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..7]: 120..127 8 0x0
1: [8..40967]: 192..41151 40960 0x2000
2: [40968..40975]: 236728..236735 8 0x0
3: [40976..106495]: 236736..302255 65520 0x801
The alignment is best-effort; a stderr message is printed if alignment
can't be achieved due to PATH_MAX overrun, with fallback to non-padded
filename. This allows it to still be useful for opportunistic alignment,
e.g. on aarch64 Btrfs with 64K block-size. Alignment failure messages
provide an indicator that reordering of the cpio-manifest may be
beneficial.
Archive read performance for reflinked initramfs images may suffer due
to the effects of fragmentation, particularly on spinning disks. To
mitigate excessive fragmentation, files with lengths less than
data_align aren't padded.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-8-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The existing cpio extraction logic reads (maximum PATH_MAX) name_len
bytes from the archive into the collected name buffer and ensures that
the trailing byte is a null-terminator. This allows the actual file name
to be shorter than name_len, with the name string simply zero-terminated
prior to the last byte.
Initramfs generators, such as dracut-cpio[1], can take advantage of name
zero-padding to align file data segments within the archive to
filesystem block boundaries. Block boundary alignment may allow the
copy_file_range syscall to reflink archive source and destination
extents.
Link: 300e4b116c [1]
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-7-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
gen_init_cpio can now write to a file directly, so use it when
gen_initramfs.sh is called with -o (e.g. usr/Makefile invocation).
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-6-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
We determine the filename length for the cpio header, so shouldn't
recalculate it when writing out the filename.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-5-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The copy_file_range syscall can improve copy performance by cloning
extents between cpio archive source and destination files.
Existing read / write based copy logic is retained for fallback in case
the copy_file_range syscall is unsupported or unavailable due to
cross-filesystem EXDEV, etc.
Clone or reflink, as opposed to copy, of source file extents into the
output cpio archive may (e.g. on Btrfs and XFS) require alignment of the
output to the filesystem block size. This could be achieved by inserting
padding entries into the cpio archive manifest.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-4-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
This is another preparatory change to allow for reflink-optimized
cpio archives with file data written / cloned via copy_file_range().
The output file is truncated prior to write, so that it maps to
usr/gen_initramfs.sh usage. It may make sense to offer an append option
in future, for easier archive concatenation.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-3-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
In preparation for more efficient archiving using copy_file_range(),
switch from writing archive data to stdout to using STDOUT_FILENO and
I/O via write(), dprintf(), etc.
Basic I/O error handling is added to cover cases such as ENOSPC. Partial
writes are treated as errors.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250819032607.28727-2-ddiss@suse.de
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
We are currently bumping gt_count as we define GTs for each tile. While
that works with our current code, there are reasons to improve that:
* That section of the code is dedicated to define each tile's set of GTs
and their respective info. The gt_count can be seen as a device level
property. While it is fair to bump it as we define each GT, we can
also focus on the GT themselves and count after we are done with the
definitions.
* More *importantly*, gt_count should reflect the number of GTs that we
would get when looping over them with for_each_gt(). Bumping gt_count
the way we are currently doing makes that value not really connected
to for_each_gt(). This could bite us in the future if in the loop gets
extra checks that are not accounted for in each existing "gt_count++".
As such, let's use for_each_gt() and extract the calculation of gt_count
into a separate block, just after we define the set of GTs for each
tile.
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-2-ee12870c6f57@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The function mmio_multi_tile_setup() does not look like the proper
location for probing for the number of existing tiles in the hardware.
It should not be that function's responsibility and such information
should instead be already available when it gets called.
The fact that we need to adjust gt_count is a symptom of that.
Move probing of available tile count to a dedicated function named
xe_info_probe_tile_count() and call it from xe_info_init(), which seems
like a more appropriate place for that.
With that move, we no longer need to (and shouldn't) adjust gt_count as
a part of xe_info_probe_tile_count(), as that field will be initialized
later in xe_info_init().
v4:
- Only probe for tile count if the default tile_count != 1 (just like
was done in mmio_multi_tile_setup()). (CI)
v3:
- Unchanged.
v2:
- Use KUnit static stub so that we do not try to query hardware when
running KUnit tests. (CI)
- Tweak last paragraph of commit message to make it clearer.
(Jonathan)
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-1-ee12870c6f57@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The PCI capability/extended capability offsets are not guaranteed to be the
same across all SoCs integrating the Cadence PCIe IP.
Use the cdns_pcie_find_{ext}_capability() APIs to find the capabilities,
which avoids hardcoding the offsets in the driver.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250813144529.303548-7-18255117159@163.com
The PCI core now provides generic PCI_FIND_NEXT_CAP() and
PCI_FIND_NEXT_EXT_CAP() macros to search for PCI capabilities, using
config accessors we supply.
Use them in the CDNS driver to add cdns_pcie_find_capability() and
cdns_pcie_find_ext_capability() interfaces.
Signed-off-by: Hans Zhang <18255117159@163.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250813144529.303548-6-18255117159@163.com
The PCI core now provides generic PCI_FIND_NEXT_CAP() macros to search for
PCI capabilities, using config accessors we supply.
Use them in the DWC EP driver to implement dw_pcie_ep_find_capability()
instead of duplicating the algorithm.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250819145828.438541-1-18255117159@163.com
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmimLV8UHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vwguw//bWbTJrRhEUtD6tS0vp1jrHpozOUR
U8oSpiNIB8b+XxLUf5Olew8jdJpBfjWMKDLG+Cu/qOe4WINzvo1xIka4tTdlHNK9
LovK6smoBgFKeV5miV4q9IOa6fpJtmwfRZlmajHcTr0WrKJA70IRRXqMKAZv93+W
+U//5/CubXW2bPtY7r7Hy+NnXASwSOIZCBxQYFVToi6cxXPO8fA9fdW7h4laZun3
OtK36qxXKCYM4/kWdH0CjEEaQozeqq9dsiEVnFzH3P49IAiwM6SMyrudSwhSfKHA
vz9nD+IhuD7jxP1Yy+AcMExzcRd7PHuWmZcSLMdw0d8/wfTUwQPPNrc8iQLZRu3r
Zsxx6uFTUVr26lj58pKMtvV9ZuQFerWA8E0i0pixf/HpkuAVe7Kdv7LEB2r0G+e9
ruHfu8+PAC+aYEeoy79XlWW36eHoWv+yOIitjOsRZlLEuuCFt6+BTPQzr7xx/+4g
imES22giwbX3Y92Q/MibVHTxSPBjw/cQtNL5DDQdN0hl9Hh61T0xXwISqqoKky+W
10tsyxsaaq9TM8ry4u3LwOTGn38jB0ZZUAtENe8TiztvzKx2vGHm9Ib9bXUga9v8
HDF3BQHTF3XdZsaeXHg70CZu80S/psENpxjPJhwGzJ9CAQngYi6cHfzBO0+Yc7aG
d6paTZ2Qq1+d8aA=
=JkKs
-----END PGP SIGNATURE-----
Merge tag 'pci-v6.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull pci fixes from Bjorn Helgaas:
- Remove vmd restriction on children using MSI-X because VMD does in
fact support both MSI and MSI-X for children (Nam Cao)
- Fix a NULL pointer dereference in the xilinx interrupt handler (Nam
Cao)
* tag 'pci-v6.17-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: vmd: Remove MSI-X check on child devices
PCI: xilinx: Fix NULL pointer dereference in xilinx_pcie_intr_handler()
The error handling path in pci_p2pdma_add_resource() contains a bug in its
`pgmap_free` label.
Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored
in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`,
which is a pointer to a member field within the `p2p_pgmap` struct, not the
base pointer of the allocation.
Correct the bug by passing the correct base pointer, `p2p_pgmap`, to
devm_kfree().
Signed-off-by: Sungho Kim <sungho.kim@furiosa.ai>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://patch.msgid.link/20250820105714.2939896-1-sungho.kim@furiosa.ai
As of today, pinging the remote processor during k3_rproc_request_mbox()
does not have any functional effect. This behavior was originally based on
the OMAP remoteproc driver, where the idea was to send messages such as
suspend requests (among others) to the remote processor, but this was
never upstreamed.
Currently, the ping message has no effect in upstream usage and causes an
unread message to remain in the mailbox, which ultimately prevents the
system from entering suspend mode:
Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
omap-mailbox 29000000.mailbox: fifo 1 has unexpected unread messages
omap-mailbox 29000000.mailbox: PM: dpm_run_callback(): platform_pm_suspend returns -16
omap-mailbox 29000000.mailbox: PM: failed to suspend: error -16
The ping is only replied if the remote core firmware is capable of doing
it, otherwise the unread message stays into the mailbox.
Remove the ping and fix the suspend issue.
Suggested-by: Andrew Davis <afd@ti.com>
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250806-v1-fix-am62-hmp-suspend-v1-1-1c4a81bb5dde@toradex.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
When enabled FW recovery, but is broken because software reset is missed
in this recovery flow. So move software reset from
imx_dsp_runtime_resume() to .load() and clear memory before loading
firmware to make recovery work.
Add call rproc_coredump_set_elf_info() to initialize the elf info for
coredump, otherwise coredump will report error "ELF class is not set".
Fixes: ec0e5549f3 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20250722075225.544319-1-shengjiu.wang@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Merge series from Qianfeng Rong <rongqianfeng@vivo.com>:
Replace devm_kzalloc() with devm_kcalloc() in sound/soc. As noted in the
kernel documentation [1], open-coded multiplication in allocator arguments
is discouraged because it can lead to integer overflow.
Using devm_kcalloc() provides built-in overflow protection, making the
memory allocation safer when calculating the allocation size compared
to explicit multiplication.
[1]: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Merge series from Stefan Binding <sbinding@opensource.cirrus.com>:
Production silicon for CS36L63 has some small differences compared to
pre-production silicon. This requires small fixes in driver.
Update firmware addresses, tuning algorithm IDs and remove soundwire
clock workaround as no longer necessary.
No product was ever released using pre-production silicon, therefore
there is no need to keep support for it.
Here is a list of conventions applied here:
- Don't mark up function names, to be taken care of by the automarkup
extension. Just say func().
- Instead of ".. code-block:: none", just say "::".
- Mark inline literals by a pair of ``xxxx``. Don't use rust doc's
dialect of `yyyy`.
- Instead of emphasizing headings by **strong emphasis**, use sub-level
title adornments, in this case "^^^^^^^^^^" and make them proper
sub-sections under "Hotplug CPU".
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Bring this file kicking and screaming into the year 2025!
[ paulmck: Apply feedback from Bagas Sanjaya. ]
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Current minimum required version of binutils is 2.30, which supports GFNI
instruction mnemonics.
Remove check for assembler support of GFNI instructions and all relevant
macros for conditional compilation.
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Link: https://lore.kernel.org/20250819085855.333380-1-ubizjak@gmail.com
Adds support for the G PRO 2 LIGHTSPEED Wireless via it's nano receiver
or directly. This nano receiver appears to work identically to the 1_1
receiver for the case I've verified, which is the battery status through
lg-hidpp.
The same appears to be the case wired, sharing much with the Pro X
Superlight 2; differences seemed to lie in userland configuration rather
than in interfaces used by hid_logitech_hidpp on the kernel side.
I verified the sysfs interface for battery charge/discharge status, and
capacity read to be working on my 910-007290 device (white).
Signed-off-by: Matt Coffin <mcoffin13@gmail.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Previously, the battery status (charging/discharging) was not reported
immediately to user-space.
For most input devices, this wasn't problematic because changing their
battery status requires connecting them to a different bus.
For example, a gamepad would report a discharging status while
connected via Bluetooth and a charging status while connected via USB.
However, certain devices are not connected or disconnected when their
battery status changes. For example, a phone battery changes its status
without connecting or disconnecting it.
In these cases, the battery status was not reported immediately to user
space.
Report battery status changes immediately to user space to support
these kinds of devices.
Fixes: a608dc1c06 ("HID: input: map battery system charging")
Reported-by: 卢国宏 <luguohong@xiaomi.com>
Closes: https://lore.kernel.org/linux-input/aI49Im0sGb6fpgc8@fedora/T/
Tested-by: 卢国宏 <luguohong@xiaomi.com>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
In preparation for a patch fixing a bug affecting
hidinput_set_battery_charge_status(), rename the function to
hidinput_update_battery_charge_status() and move it up so it can be used
by hidinput_update_battery().
Refactor, no functional changes.
Tested-by: 卢国宏 <luguohong@xiaomi.com>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Merge series from Jihed Chaibi <jihed.chaibi.dev@gmail.com>:
This series converts the legacy TXT bindings for the TI TWL4030
sound-related modules to the modern YAML DT schema format.
This work was previously part of a larger series but is now being sent
as a focused submission for the ASoC subsystem.
This patch introduces a proc entry to show the currently enrolled donation
files.
- "File path" indicates a file.
- "Status"
a. "Donated" means the file is registed in the donation list by
fadvise(offset, length, POSIX_FADV_NOREUSE)
b. "Evicted" means the donated pages were reclaimed.
- "Offset (kb)" and "Length (kb) show the registered donation range.
- "Cached pages (kb)" shows the amount of cached pages in the inode page cache.
For example,
# of files : 2
File path Status Donation offset (kb) Donation size (kb) File cached size (kb)
---
/local/test2 Donated 0 1048576 2097152
/local/test Evicted 0 1048576 1048576
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Introduce get_left_section_blocks() for cleanup, no logic changes.
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
This patch allows privileged users to reserve nodes via the
'reserve_node' mount option, which is similar to the existing
'reserve_root' option.
"-o reserve_node=<N>" means <N> nodes are reserved for privileged
users only.
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Currently, we have encountered some issues while testing ZUFS. In
situations near the storage limit (e.g., 50GB remaining), and after
simulating fragmentation by repeatedly writing and deleting data, we found
that application installation and startup tests conducted after idling for
a few minutes take significantly longer several times that of traditional
UFS. Tracing the operations revealed that the majority of I/Os were issued
by background GC, which blocks normal I/O operations.
Under normal circumstances, ZUFS indeed requires more background GC and
employs a more aggressive GC strategy. However, I aim to find a way to
minimize the impact on regular I/O operations under these near-limit
conditions. To address this, I have introduced a bggc_io_aware feature,
which controls the prioritization of background GC in the presence of I/Os.
This switch can be adjusted at the framework level to implement different
strategies. If set to AWARE_ALL_IO, all background GC operations will be
skipped during active I/O issuance. The default option remains consistent
with the current strategy, ensuring no change in behavior.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Changes as below:
- print more logs for f2fs_{enable,disable}_checkpoint()
- account and dump time stats for f2fs_enable_checkpoint()
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
During f2fs_enable_checkpoint() in remount(), if we flush a large
amount of dirty pages into slow device, it may take long time which
will block write IO, let's add a timeout machanism during dirty
pages flush to avoid long time block in f2fs_enable_checkpoint().
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
As reported, on-disk footer.ino and footer.nid is the same and
out-of-range, let's add sanity check on f2fs_alloc_nid() to detect
any potential corruption in free_nid_list.
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
mount -t f2fs -o checkpoint=disable:10% /dev/vdb /mnt/f2fs/
mount -t f2fs -o remount,checkpoint=enable /dev/vdb /mnt/f2fs/
kernel log:
F2FS-fs (vdb): Adjust unusable cap for checkpoint=disable = 204440 / 10%
If we has assigned checkpoint=enable mount option, unusable_cap{,_perc}
parameters of checkpoint=disable should be reset, then calculation and
log print could be avoid in adjust_unusable_cap_perc().
Fixes: 1ae18f71cb ("f2fs: fix checkpoint=disable:%u%%")
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
A new IAA device ID, 0xfd2d, is introduced across all Wildcat Lake
family platforms. Add the device ID to the IDXD driver.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20250801215936.188555-1-vinicius.gomes@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The clean up in idxd_setup_wqs() has had a couple bugs because the error
handling is a bit subtle. It's simpler to just re-write it in a cleaner
way. The issues here are:
1) If "idxd->max_wqs" is <= 0 then we call put_device(conf_dev) when
"conf_dev" hasn't been initialized.
2) If kzalloc_node() fails then again "conf_dev" is invalid. It's
either uninitialized or it points to the "conf_dev" from the
previous iteration so it leads to a double free.
It's better to free partial loop iterations within the loop and then
the unwinding at the end can handle whole loop iterations. I also
renamed the labels to describe what the goto does and not where the goto
was located.
Fixes: 3fd2f4bc01 ("dmaengine: idxd: fix memory leak in error handling path of idxd_setup_wqs")
Reported-by: Colin Ian King <colin.i.king@gmail.com>
Closes: https://lore.kernel.org/all/20250811095836.1642093-1-colin.i.king@gmail.com/
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/aJnJW3iYTDDCj9sk@stanley.mountain
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Replace memset(0) followed by strscpy() with strscpy_pad() to improve
idxd_load_iaa_device_defaults(). This avoids zeroing the memory before
copying the strings and ensures the destination buffers are only written
to once, simplifying the code and improving efficiency.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20250810225858.2953-2-thorsten.blum@linux.dev
Signed-off-by: Vinod Koul <vkoul@kernel.org>
A recent refactor introduced a misplaced put_device() call, resulting in a
reference count underflow during module unload.
There is no need to add additional put_device() calls for idxd groups,
engines, or workqueues. Although the commit claims: "Note, this also
fixes the missing put_device() for idxd groups, engines, and wqs."
It appears no such omission actually existed. The required cleanup is
already handled by the call chain:
idxd_unregister_devices() -> device_unregister() -> put_device()
Extend idxd_cleanup() to handle the remaining necessary cleanup and
remove idxd_cleanup_internals(), which duplicates deallocation logic
for idxd, engines, groups, and workqueues. Memory management is also
properly handled through the Linux device model.
Fixes: a409e919ca ("dmaengine: idxd: Refactor remove call with idxd_cleanup() helper")
Signed-off-by: Yi Sun <yi.sun@intel.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Link: https://lore.kernel.org/r/20250729150313.1934101-3-yi.sun@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The call to idxd_free() introduces a duplicate put_device() leading to a
reference count underflow:
refcount_t: underflow; use-after-free.
WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110
...
Call Trace:
<TASK>
idxd_remove+0xe4/0x120 [idxd]
pci_device_remove+0x3f/0xb0
device_release_driver_internal+0x197/0x200
driver_detach+0x48/0x90
bus_remove_driver+0x74/0xf0
pci_unregister_driver+0x2e/0xb0
idxd_exit_module+0x34/0x7a0 [idxd]
__do_sys_delete_module.constprop.0+0x183/0x280
do_syscall_64+0x54/0xd70
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The idxd_unregister_devices() which is invoked at the very beginning of
idxd_remove(), already takes care of the necessary put_device() through the
following call path:
idxd_unregister_devices() -> device_unregister() -> put_device()
In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may
trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is
called immediately after, it can result in a use-after-free.
Remove the improper idxd_free() to avoid both the refcount underflow and
potential memory corruption during module unload.
Fixes: d5449ff1b0 ("dmaengine: idxd: Add missing idxd cleanup to fix memory leak in remove call")
Signed-off-by: Yi Sun <yi.sun@intel.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Link: https://lore.kernel.org/r/20250729150313.1934101-2-yi.sun@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add the undocumented NVIDIA APBDMA compatibles and "clock-names" which
are already in use. There doesn't appear to be any per compatible
differences.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250812203308.727731-1-robh@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add shutdown callback to ensure that DMA operations are properly stopped
and resources are released during system shutdown or kexec operations.
Fix incorrect PM state handling in the remove function that was causing
clock disable warnings during the shutdown operations, which was not
implemented earlier. The original logic used pm_runtime_enabled() check
after calling the pm_runtime_disable(), would always evaluate to true
after the disable call, which leads to unconditionally calling the
runtime_suspend regardless of the device's actual power state.
During shutdown, the device may already be suspended with clock disabled
from the autosuspend timer, causing the clock framework to warn about
the double-disable attempt. The pm_runtime_active() function checks the
actual device power state rather than the PM subsystem's enabled/disabled
status. ensuring the runtime_suspend is only called when the device is in
active power state. This prevents clock warnings during shutdown while
maintaining proper cleanup during normal remove operations.
Signed-off-by: Abin Joseph <abin.joseph@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/20250722070255.28944-1-abin.joseph@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Radxa Cubie A5E has a 3-color LED. The green and blue LEDs are wired
to GPIO pins on the SoC, and the green one is lit by default to serve as
a power indicator. The red LED is wired to the M.2 slot.
Add device nodes for the green and blue LEDs.
A default "heartbeat" trigger is set for the green power LED, though in
practice it might be better if it were inverted, i.e. lit most of the
time.
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250812175927.2199219-1-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Use core driver model helper dev_err_probe() defined at
drivers/base/core.c in driver probe path to propagate errors.
standardize and improve the code of deferred probe error handling
using this helper for ingenic usb phy driver.
Inspired by,
commit a787e5400a ("driver core: add device probe log helper")
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Link: https://lore.kernel.org/r/aIIMW971BYsIk4As@bhairav-test.ee.iitb.ac.in
Signed-off-by: Vinod Koul <vkoul@kernel.org>
