summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-12fs: add immutable rootfsChristian Brauner
Currently pivot_root() doesn't work on the real rootfs because it cannot be unmounted. Userspace has to do a recursive removal of the initramfs contents manually before continuing the boot. Really all we want from the real rootfs is to serve as the parent mount for anything that is actually useful such as the tmpfs or ramfs for initramfs unpacking or the rootfs itself. There's no need for the real rootfs to actually be anything meaningful or useful. Add a immutable rootfs called "nullfs" that can be selected via the "nullfs_rootfs" kernel command line option. The kernel will mount a tmpfs/ramfs on top of it, unpack the initramfs and fire up userspace which mounts the rootfs and can then just do: chdir(rootfs); pivot_root(".", "."); umount2(".", MNT_DETACH); and be done with it. (Ofc, userspace can also choose to retain the initramfs contents by using something like pivot_root(".", "/initramfs") without unmounting it.) Technically this also means that the rootfs mount in unprivileged namespaces doesn't need to become MNT_LOCKED anymore as it's guaranteed that the immutable rootfs remains permanently empty so there cannot be anything revealed by unmounting the covering mount. In the future this will also allow us to create completely empty mount namespaces without risking to leak anything. systemd already handles this all correctly as it tries to pivot_root() first and falls back to MS_MOVE only when that fails. This goes back to various discussion in previous years and a LPC 2024 presentation about this very topic. Link: https://patch.msgid.link/20260112-work-immutable-rootfs-v2-3-88dd1c34a204@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12fs: add init_pivot_root()Christian Brauner
We will soon be able to pivot_root() with the introduction of the immutable rootfs. Add a wrapper for kernel internal usage. Link: https://patch.msgid.link/20260112-work-immutable-rootfs-v2-2-88dd1c34a204@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12fs: ensure that internal tmpfs mount gets mount id zeroChristian Brauner
and the rootfs get mount id one as it always has. Before we actually mount the rootfs we create an internal tmpfs mount which has mount id zero but is never exposed anywhere. Continue that "tradition". Link: https://patch.msgid.link/20260112-work-immutable-rootfs-v2-1-88dd1c34a204@kernel.org Fixes: 7f9bfafc5f49 ("fs: use xarray for old mount id") Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12x86/paravirt: Use common code for paravirt_steal_clock()Juergen Gross
Remove the arch-specific variant of paravirt_steal_clock() and use the common one instead. With all archs supporting Xen now having been switched to the common variant, including paravirt.h can be dropped from drivers/xen/time.c. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-12-jgross@suse.com
2026-01-12riscv/paravirt: Use common code for paravirt_steal_clock()Juergen Gross
Remove the arch specific variant of paravirt_steal_clock() and use the common one instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-11-jgross@suse.com
2026-01-12loongarch/paravirt: Use common code for paravirt_steal_clock()Juergen Gross
Remove the arch specific variant of paravirt_steal_clock() and use the common one instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-10-jgross@suse.com
2026-01-12tools: jobserver: Prevent deadlock caused by incorrect jobserver ↵Changbin Du
configuration and enhance error reporting When using GNU Make's jobserver feature in kernel builds, a bug in MAKEFLAGS propagation caused "--jobserver-auth=r,w" to reference an unintended file descriptor. This led to infinite loops in jobserver-exec's os.read() calls due to empty token. My shell opened /etc/passwd for some reason without closing it, and as a result, all child processes inherited this fd 3. $ ls -l /proc/self/fd total 0 lrwx------ 1 changbin changbin 64 Dec 25 13:03 0 -> /dev/pts/1 lrwx------ 1 changbin changbin 64 Dec 25 13:03 1 -> /dev/pts/1 lrwx------ 1 changbin changbin 64 Dec 25 13:03 2 -> /dev/pts/1 lr-x------ 1 changbin changbin 64 Dec 25 13:03 3 -> /etc/passwd lr-x------ 1 changbin changbin 64 Dec 25 13:03 4 -> /proc/1421383/fd In this case, the `make` should open a new file descriptor for jobserver control, but clearly, it did not do so and instead still passed fd 3 as "--jobserver-auth=3,4" in MAKEFLAGS. (The version of my gnu make is 4.3) This update ensures robustness against invalid jobserver configurations, even when `make` incorrectly pass non-pipe file descriptors. * Rejecting empty reads to prevent infinite loops on EOF. * Clearing `self.jobs` to avoid writing to incorrect files if invalid tokens are detected. * Printing detailed error messages to stderr to inform the user. Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Changbin Du <changbin.du@huawei.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260108113836.2976527-1-changbin.du@huawei.com>
2026-01-12arm64/paravirt: Use common code for paravirt_steal_clock()Juergen Gross
Remove the arch-specific variant of paravirt_steal_clock() and use the common one instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-9-jgross@suse.com
2026-01-12drm/xe: Privatize xe_ggtt_nodeMaarten Lankhorst
Nothing requires it any more, make the member private. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260108101014.579906-16-dev@lankhorst.se
2026-01-12drm/xe: Improve xe_gt_sriov_pf_config GGTT handlingMaarten Lankhorst
Do not directly dereference xe_ggtt_node, and add a function to retrieve the allocated GGTT size. Reviewed-by: Matthew.brost@intel.com Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260108101014.579906-15-dev@lankhorst.se
2026-01-12drm/xe: Do not dereference ggtt_node in xe_bo.cMaarten Lankhorst
A careful inspection of __xe_ggtt_insert_bo_at() shows that the ggtt_node can always be seen as inserted from xe_bo.c due to the way error handling is performed. The checks are also a little bit too paranoid, since we never create a bo with ggtt_node[id] initialised but not inserted into the GGTT, which can be seen by looking at __xe_ggtt_insert_bo_at() Additionally, the size of the GGTT is never bigger than 4 GB, so adding a check at that level is incorrect. Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260108101014.579906-14-dev@lankhorst.se
2026-01-12drm/xe/display: Avoid dereferencing xe_ggtt_nodeMaarten Lankhorst
Start using xe_ggtt_node_addr, and avoid comparing the base offset as vma->node is dynamically allocated. Also sneak in a xe_bo_size() for stolen, too small to put as separate commit. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260108101014.579906-13-dev@lankhorst.se
2026-01-12drm/xe: Add xe_ggtt_node_addr() to avoid dereferencing xe_ggtt_nodeMaarten Lankhorst
This function makes it possible to add an offset that is applied to all xe_ggtt_node's, and hides the internals from all its users. Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260108101014.579906-12-dev@lankhorst.se
2026-01-12drm/xe: Convert xe_fb_pin to use a callback for insertion into GGTTMaarten Lankhorst
The rotation details belong in xe_fb_pin.c, while the operations involving GGTT belong to xe_ggtt.c. As directly locking xe_ggtt etc results in exposing all of xe_ggtt details anyway, create a special function that allocates a ggtt_node, and allow display to populate it using a callback as a compromise. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260108101014.579906-11-dev@lankhorst.se
2026-01-12drm/xe: Start using ggtt->start in preparation of balloon removalMaarten Lankhorst
Instead of having ggtt->size point to the end of ggtt, have ggtt->size be the actual size of the GGTT, and introduce ggtt->start to point to the beginning of GGTT. This will allow a massive cleanup of GGTT in case of SRIOV-VF. Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260108101014.579906-10-dev@lankhorst.se
2026-01-12btrfs: fix memory leaks in create_space_info() error pathsJiasheng Jiang
In create_space_info(), the 'space_info' object is allocated at the beginning of the function. However, there are two error paths where the function returns an error code without freeing the allocated memory: 1. When create_space_info_sub_group() fails in zoned mode. 2. When btrfs_sysfs_add_space_info_type() fails. In both cases, 'space_info' has not yet been added to the fs_info->space_info list, resulting in a memory leak. Fix this by adding an error handling label to kfree(space_info) before returning. Fixes: 2be12ef79fe9 ("btrfs: Separate space_info create/update") Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-12btrfs: invalidate pages instead of truncate after reflinkingFilipe Manana
Qu reported that generic/164 often fails because the read operations get zeroes when it expects to either get all bytes with a value of 0x61 or 0x62. The issue stems from truncating the pages from the page cache instead of invalidating, as truncating can zero page contents. This zeroing is not just in case the range is not page sized (as it's commented in truncate_inode_pages_range()) but also in case we are using large folios, they need to be split and the splitting fails. Stealing Qu's comment in the thread linked below: "We can have the following case: 0 4K 8K 12K 16K | | | | | |<---- Extent A ----->|<----- Extent B ------>| The page size is still 4K, but the folio we got is 16K. Then if we remap the range for [8K, 16K), then truncate_inode_pages_range() will get the large folio 0 sized 16K, then call truncate_inode_partial_folio(). Which later calls folio_zero_range() for the [8K, 16K) range first, then tries to split the folio into smaller ones to properly drop them from the cache. But if splitting failed (e.g. racing with other operations holding the filemap lock), the partially zeroed large folio will be kept, resulting the range [8K, 16K) being zeroed meanwhile the folio is still a 16K sized large one." So instead of truncating, invalidate the page cache range with a call to filemap_invalidate_inode(), which besides not doing any zeroing also ensures that while it's invalidating folios, no new folios are added. This helps ensure that buffered reads that happen while a reflink operation is in progress always get either the whole old data (the one before the reflink) or the whole new data, which is what generic/164 expects. Link: https://lore.kernel.org/linux-btrfs/7fb9b44f-9680-4c22-a47f-6648cb109ddf@suse.com/ Reported-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-12btrfs: update the Kconfig string for CONFIG_BTRFS_EXPERIMENTALQu Wenruo
The following new features are missing: - Async checksum - Shutdown ioctl and auto-degradation - Larger block size support Which is dependent on larger folios. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-12arm/paravirt: Use common code for paravirt_steal_clock()Juergen Gross
Remove the arch-specific variant of paravirt_steal_clock() and use the common one instead. This allows to remove paravirt.c and paravirt.h from arch/arm. Until all archs supporting Xen have been switched to the common code of paravirt_steal_clock(), drivers/xen/time.c needs to include asm/paravirt.h for those archs, while this is not necessary for arm any longer. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-8-jgross@suse.com
2026-01-12sched: Move clock related paravirt code to kernel/schedJuergen Gross
Paravirt clock related functions are available in multiple archs. In order to share the common parts, move the common static keys to kernel/sched/ and remove them from the arch specific files. Make a common paravirt_steal_clock() implementation available in kernel/sched/cputime.c, guarding it with a new config option CONFIG_HAVE_PV_STEAL_CLOCK_GEN, which can be selected by an arch in case it wants to use that common variant. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-7-jgross@suse.com
2026-01-12paravirt: Remove asm/paravirt_api_clock.hJuergen Gross
All architectures supporting CONFIG_PARAVIRT share the same contents of asm/paravirt_api_clock.h: #include <asm/paravirt.h> So remove all incarnations of asm/paravirt_api_clock.h and remove the only place where it is included, as there asm/paravirt.h is included anyway. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> # powerpc, scheduler bits Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-6-jgross@suse.com
2026-01-12x86/paravirt: Move thunk macros to paravirt_types.hJuergen Gross
The macros for generating PV-thunks are part of the generic paravirt infrastructure, so they should be in paravirt_types.h. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-5-jgross@suse.com
2026-01-12x86/paravirt: Remove PARAVIRT_DEBUG config optionJuergen Gross
The only effect of CONFIG_PARAVIRT_DEBUG set is that instead of doing a call using a NULL pointer a BUG() is being raised. While the BUG() will be a little bit easier to analyse, the call of NULL isn't really that difficult to find the reason for. Remove the config option to make paravirt coding a little bit less annoying. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-4-jgross@suse.com
2026-01-12x86/paravirt: Remove some unneeded struct declarationsJuergen Gross
In paravirt_types.h and paravirt.h there are some struct declarations which are not needed. Remove them. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260105110520.21356-3-jgross@suse.com
2026-01-12Revert "gfs2: Fix use of bio_chain"Andreas Gruenbacher
This reverts commit 8a157e0a0aa5143b5d94201508c0ca1bb8cfb941. That commit incorrectly assumed that the bio_chain() arguments were swapped in gfs2. However, gfs2 intentionally constructs bio chains so that the first bio's bi_end_io callback is invoked when all bios in the chain have completed, unlike bio chains where the last bio's callback is invoked. Fixes: 8a157e0a0aa5 ("gfs2: Fix use of bio_chain") Cc: stable@vger.kernel.org Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2026-01-12gpu: nova-core: add missing newlines to several print stringsTimur Tabi
Although the dev_xx!() macro calls do not technically require terminating newlines for the format strings, they should be added anyway to maintain consistency, both within Rust code and with the C versions. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260107201647.2490140-2-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12gpu: nova-core: check for overflow to DMATRFBASE1Timur Tabi
The NV_PFALCON_FALCON_DMATRFBASE/1 register pair supports DMA addresses up to 49 bits only, but the write to DMATRFBASE1 could exceed that. To mitigate, check first that the DMA address will fit. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base code") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260107201647.2490140-1-ttabi@nvidia.com [ Import ::kernel::dma::DmaMask. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12drm/xe/mert: Move MERT initialization to xe_mert.cMichal Wajdeczko
Most of the MERT code is already in dedicated file, no reason to keep internal MERT data structure initialization elsewhere. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260109151219.26206-6-michal.wajdeczko@intel.com
2026-01-12drm/xe/mert: Use local mert variable to simplify the codeMichal Wajdeczko
There is no need to always refer to MERT data using tile pointer. Use of local mert pointer will simplify the code and make it look like other existing MERT function. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260109151219.26206-5-michal.wajdeczko@intel.com
2026-01-12drm/xe/mert: Always refer to MERT using xe_deviceMichal Wajdeczko
There is only one MERT instance and while it is located on the root tile, it is safer to refer to it using xe_device rather than xe_tile. This will also allow to align signature with other MERT function. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260111213847.27869-1-michal.wajdeczko@intel.com
2026-01-12drm/xe/mert: Fix kernel-doc for struct xe_mertMichal Wajdeczko
Add simple top level kernel-doc for the struct itself to allow the script recognize that and fix tag of the one member. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260109151219.26206-3-michal.wajdeczko@intel.com
2026-01-12drm/xe/mert: Normalize xe_mert.h include guardsMichal Wajdeczko
Most of our header files are using include guard names with single underscore and we don't use trailing comments on final #endif. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260109151219.26206-2-michal.wajdeczko@intel.com
2026-01-12arm64: dts: mediatek: mt6795-xperia-m5: Add UHS pins for MMC1 and 2AngeloGioacchino Del Regno
Add the UHS state pins for the MMC1 and MMC2 controllers and, while at it, also add the correct drive strength parameters for the default pin states for those two. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8192-asurada: Remove unused clock-stretch-nsAngeloGioacchino Del Regno
Remove the clock-stretch-ns property from i2c2, as it has always been (and still is) unused. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8173-elm: Remove regulators from thermal nodeAngeloGioacchino Del Regno
The only reason to have a regulator in the thermal node is to keep the CPU cores up while reading temperatures, but this is incorrect because the AUXADC Thermal IP doesn't need any regulators to work, at all. Since the thermal node was inherited only for adding vregs, remove it entirely. This change is safe also because, among other things, the actual driver never used those regulators anyway. This also fixes a dtbs_check warning. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8173-elm: Fix dsi0 ports warningAngeloGioacchino Del Regno
Since only a single port is present, remove the inner `ports` parent node and just declare the single port as `port`. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8173-elm: Fix bluetooth node name and reorderAngeloGioacchino Del Regno
Change the node name for Marvell SD8897 SDIO Bluetooth from `btmrvl@2` to `bluetooth@2` to fix a dtbs_check warning. While at it, also change the WiFi one from `mwifiex@1" to a generic "wifi@1" and reorder the nodes so that wifi@1 comes before bluetooth@2. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8183-pumpkin: Fix pinmux node namesAngeloGioacchino Del Regno
Change all of the pinmux main nodes to have a "-pins" suffix to satisfy devicetree bindings checks. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8183-jacuzzi-pico6: Fix typo in pinmux nodeAngeloGioacchino Del Regno
Rename "piins-bt-wakeup" to "pins-bt-wakeup" to fix a dtbs_check warning happening due to this typo. Fixes: 055ef10ccdd4 ("arm64: dts: mt8183: Add jacuzzi pico/pico6 board") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt7981b-openwrt-one: Remove useless cells from flash@0AngeloGioacchino Del Regno
In spi2's flash@0 there is only one `partitions` subnode: this alone makes specifying address and size cells useless, but then this subnode has no address and no size, which even makes the currently declared address/size cells wrong. Fixes: 869b3bb5ada2 ("arm64: dts: mediatek: mt7981b-openwrt-one: Enable SPI NOR") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8183-evb: Fix dtbs_check warningsAngeloGioacchino Del Regno
Change the Murata NCM03WF104 node name from "thermal-sensor" to "thermistor" (as that's what it is, after all), and change all of the pinmux main nodes to have a "-pins" suffix to satisfy devicetree bindings checks. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8173: Fix pinctrl node names and cleanupAngeloGioacchino Del Regno
Fix the pinctrl node names to adhere to the bindings, as the main pin node is supposed to be named like "uart0-pins" and the pinmux node named like "pins-bus". While at it, also cleanup all of the MTK_DRIVE_(x)mA by changing that to just the (x) number. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12arm64: dts: mediatek: mt8188-geralt: drop firmware-name from first SCP coreChen-Yu Tsai
Arnd pointed out that having firmware-name in the device tree is wrong. Drop it. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-12gpu: nova-core: don't print raw PMU table entriesJohn Hubbard
Remove the (large) raw form of the PMU table entries. The resulting PMULookupTable is still getting printed (in more useful form) later, anyway, so this was redundant, even for debugging. This output (the example is from an Ampere GPU) is what is being removed: NovaCore 0000:e1:00.0: PMU entry: [01, 01, 54, 54, 01, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [07, 06, e0, b7, 03, 00] NovaCore 0000:e1:00.0: PMU entry: [08, 01, bc, 56, 05, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [45, 07, 88, da, 01, 00] NovaCore 0000:e1:00.0: PMU entry: [85, 07, 34, c9, 02, 00] NovaCore 0000:e1:00.0: PMU entry: [49, 05, 7c, b3, 04, 00] NovaCore 0000:e1:00.0: PMU entry: [89, 05, 1c, 05, 05, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00] And it is immediately followed by a more useful, interpreted list of selected PMU table data, which is *not* being removed as part of this commit. That looks like this: NovaCore 0000:e1:00.0: PmuLookupTableEntry desc: FalconUCodeDescV3 { hdr: 78381825, stored_size: 59904, pkc_data_offset: 1444, interface_offset: 28, imem_phys_base: 0, imem_load_size: 57856, imem_virt_base: 0, dmem_phys_base: 0, dmem_load_size: 2048, engine_id_mask: 1024, ucode_id: 9, signature_count: 3, signature_versions: 7, _reserved: 37449, } Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260108005811.86014-3-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12gpu: nova-core: preserve error information in gpu_name()John Hubbard
Change gpu_name() to return a Result instead of an Option. This avoids silently discarding error information when parsing the GPU name string from the GSP. Update the callsite to log a warning with the error details on failure, rather than just displaying "invalid GPU name". Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260108005811.86014-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12Merge patch series "re-enable IOCB_NOWAIT writes to files v6"Christian Brauner
Christoph Hellwig <hch@lst.de> says: Hi all, commit 66fa3cedf16a ("fs: Add async write file modification handling.") effectively disabled IOCB_NOWAIT writes as timestamp updates currently always require blocking, and the modern timestamp resolution means we always update timestamps. This leads to a lot of context switches from applications using io_uring to submit file writes, making it often worse than using the legacy aio code that is not using IOCB_NOWAIT. This series allows non-blocking updates for lazytime if the file system supports it, and adds that support for XFS. * patches from https://patch.msgid.link/20260108141934.2052404-1-hch@lst.de: xfs: enable non-blocking timestamp updates xfs: implement ->sync_lazytime fs: refactor file_update_time_flags fs: add support for non-blocking timestamp updates fs: add a ->sync_lazytime method fs: factor out a sync_lazytime helper fs: refactor ->update_time handling fat: cleanup the flags for fat_truncate_time nfs: split nfs_update_timestamps fs: allow error returns from generic_update_time fs: remove inode_update_time Link: https://patch.msgid.link/20260108141934.2052404-1-hch@lst.de Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12xfs: enable non-blocking timestamp updatesChristoph Hellwig
The lazytime path using the generic helpers can never block in XFS because there is no ->dirty_inode method that could block. Allow non-blocking timestamp updates for this case by replacing generic_update_time with the open coded version without the S_NOWAIT check. Fixes: 66fa3cedf16a ("fs: Add async write file modification handling.") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260108141934.2052404-12-hch@lst.de Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12xfs: implement ->sync_lazytimeChristoph Hellwig
Switch to the new explicit lazytime syncing method instead of trying to second guess what could be a lazytime update in ->dirty_inode. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260108141934.2052404-11-hch@lst.de Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12fs: refactor file_update_time_flagsChristoph Hellwig
Split all the inode timestamp flags into a helper. This not only makes the code a bit more readable, but also optimizes away the further checks as soon as know we need an update. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260108141934.2052404-10-hch@lst.de Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-12fs: add support for non-blocking timestamp updatesChristoph Hellwig
Currently file_update_time_flags unconditionally returns -EAGAIN if any timestamp needs to be updated and IOCB_NOWAIT is passed. This makes non-blocking direct writes impossible on file systems with granular enough timestamps. Pass IOCB_NOWAIT to ->update_time and return -EAGAIN if it could block. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260108141934.2052404-9-hch@lst.de Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>