Andrew Davis [Thu, 5 Mar 2026 19:35:45 +0000 (13:35 -0600)]
rtc: rx8025: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:44 +0000 (13:35 -0600)]
rtc: rv8803: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:43 +0000 (13:35 -0600)]
rtc: rs5c372: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:42 +0000 (13:35 -0600)]
rtc: pcf2127: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:41 +0000 (13:35 -0600)]
rtc: m41t80: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Andrew Davis [Thu, 5 Mar 2026 19:35:40 +0000 (13:35 -0600)]
rtc: abx80x: Remove use of i2c_match_id()
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Miguel Ojeda [Thu, 12 Mar 2026 11:10:14 +0000 (12:10 +0100)]
rust: kbuild: allow `unused_features`
Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28),
`rustc` introduces the new lint `unused_features` [1], which warns [2]:
warning: feature `used_with_arg` is declared but not used
--> <crate attribute>:1:93
|
1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)]
| ^^^^^^^^^^^^^
|
= note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default
The original goal of using `-Zcrate-attr` automatically was that there
is a consistent set of features enabled and managed globally for all
Rust kernel code (modulo exceptions like the `rust/` crated).
While we could require crates to enable features manually (even if we
still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr`
list), it is not really worth making all developers worry about it just
for a new lint.
The features are expected to eventually become stable anyway (most already
did), and thus having to remove features in every file that may use them
is not worth it either.
Thus just allow the new lint globally.
The lint actually existed for a long time, which is why `rustc` does
not complain about an unknown lint in the stable versions we support,
but it was "disabled" years ago [3], and now it was made to work again.
For extra context, the new implementation of the lint has already been
improved to avoid linting about features that became stable thanks to
Benno's report and the ensuing discussion [4] [5], but while that helps,
it is still the case that we may have features enabled that are not used
for one reason or another in a particular crate.
Mika Kuoppala [Wed, 4 Mar 2026 21:17:28 +0000 (23:17 +0200)]
drm/xe: Fix overflow in guc_ct_snapshot_capture
snapshot->ctb is u32*, so pointer arithmetic on it scales
the byte offset from xe_bo_size() by 4, overshooting the
intended start of the g2h portion and writing past the
allocated buffer.
Fix this by using void * to get the arithmetic right and
prevent future mishaps.
v2: s/u8/void for memcpy and iosys_map consistency (Matt)
Fixes: af3de6cf06f9 ("drm/xe: Split H2G and G2H into separate buffer objects") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260304211728.249104-1-mika.kuoppala@linux.intel.com
Nicolas Pitre [Tue, 3 Feb 2026 04:52:48 +0000 (23:52 -0500)]
vt: add fallback to plain map for modifier-aware key types
When a key is pressed with modifiers (Shift, Ctrl, Alt, etc.) and the
modifier-specific keymap has no binding (K_HOLE) or doesn't exist, fall
back to the plain keymap if the plain entry is a modifier-aware type
(KT_CUR or KT_CSI).
This allows arrow keys and CSI navigation keys to automatically handle
all modifier combinations with just a single plain map entry. The key
handlers (k_cur and k_csi) read the modifier state at runtime and encode
it into the output sequence.
For example, with just:
keycode 103 = Up
keycode 104 = Csi_Home
All these combinations now work automatically:
Up -> ESC [ A
Shift+Up -> ESC [ 1 ; 2 A
Ctrl+Up -> ESC [ 1 ; 5 A
Home -> ESC [ 1 ~
Shift+Home -> ESC [ 1 ; 2 ~
Ctrl+Home -> ESC [ 1 ; 5 ~
Previously, each modifier combination required an explicit keymap entry,
which was tedious and consumed keymap slots.
Explicit modifier bindings still take precedence - the fallback only
triggers when the modifier-specific entry is empty.
Nicolas Pitre [Tue, 3 Feb 2026 04:52:47 +0000 (23:52 -0500)]
vt: add KT_CSI keysym type for modifier-aware CSI sequences
Add a new keysym type KT_CSI that generates CSI tilde sequences with
automatic modifier encoding. The keysym value encodes the CSI parameter
number, producing sequences like ESC [ <value> ~ or ESC [ <value> ; <mod> ~
when Shift, Alt, or Ctrl modifiers are held.
This allows navigation keys (Home, End, Insert, Delete, PgUp, PgDn) and
function keys to generate modifier-aware escape sequences without
consuming string table entries for each modifier combination.
Define key symbols for navigation keys (K_CSI_HOME, K_CSI_END, etc.)
and function keys (K_CSI_F1 through K_CSI_F20) using standard xterm
CSI parameter values.
The modifier encoding follows the xterm convention:
mod = 1 + (shift ? 1 : 0) + (alt ? 2 : 0) + (ctrl ? 4 : 0)
Allowed CSI parameter values range from 0 to 99.
Note: The Linux console historically uses a non-standard double-bracket
format for F1-F5 (ESC [ [ A through ESC [ [ E) rather than the xterm
tilde format (ESC [ 11 ~ through ESC [ 15 ~). The K_CSI_F1 through
K_CSI_F5 definitions use the xterm format. Converting F1-F5 to KT_CSI
would require updating the "linux" terminfo entry to match. Navigation
keys and F6-F20 already use the tilde format and are fully compatible.
Nicolas Pitre [Tue, 3 Feb 2026 04:52:46 +0000 (23:52 -0500)]
vt: add modifier support to cursor keys
Generate xterm-style CSI sequences with modifier parameters for arrow
keys when Shift, Alt, or Ctrl are held. For example, Shift+Up produces
ESC [ 1 ; 2 A instead of plain ESC [ A.
The modifier encoding follows the standard xterm convention:
mod = 1 + (shift ? 1 : 0) + (alt ? 2 : 0) + (ctrl ? 4 : 0)
When no modifiers are pressed, the original behavior is preserved.
Explicit keymap bindings for modified cursor keys (e.g., "shift keycode
103 = Find") take precedence over this automatic modifier encoding.
Randy Dunlap [Wed, 11 Mar 2026 05:23:47 +0000 (22:23 -0700)]
serdev: serdev.h: clean up kernel-doc comments
Correct kernel-doc comment format and add a missing to avoid
kernel-doc warnings:
Warning: include/linux/serdev.h:49 struct member 'write_comp' not
described in 'serdev_device'
Warning: include/linux/serdev.h:49 struct member 'write_lock' not
described in 'serdev_device'
Warning: include/linux/serdev.h:68 struct member 'shutdown' not described
in 'serdev_device_driver'
Warning: include/linux/serdev.h:134 function parameter 'serdev' not
described in 'serdev_device_put'
Warning: include/linux/serdev.h:162 function parameter 'ctrl' not
described in 'serdev_controller_put'
Julian Braha [Mon, 9 Mar 2026 12:23:21 +0000 (12:23 +0000)]
serial: remove drivers for espressif esp32
These drivers were added about 3 years ago, and depend on the
XTENSA_PLATFORM_ESP32 config option which has never existed,
so no device can actually use them.
They can only be compiled with COMPILE_TEST.
In a previous conversation [1], Greg suggested removing the
drivers, and Max, the original submitter of the drivers, agreed
due to a lack of foreseeable development.
Some DMA controllers require transfer lengths to be aligned to a
specific boundary. For example, the Tegra GPC DMA requires 4-byte
(word) aligned transfers and will reject unaligned lengths.
Align the TX DMA buffer length down to the DMA controller's copy_align
boundary before submitting the transfer. Any remaining unaligned bytes
will be transmitted via PIO on subsequent calls, which is the existing
fallback behavior when DMA is not used.
Kartik Rajput [Wed, 25 Feb 2026 06:59:13 +0000 (12:29 +0530)]
serial: amba-pl011: Add Tegra264 UART support
Add support for the NVIDIA Tegra264 UART controller, which is derived
from the AMBA PL011 design.
On Tegra264, the fractional baud rate divisor (FBRD) register is broken.
Using IBRD alone may not achieve the required baud rate
tolerance. Enable the skip_ibrd_fbrd and set_uartclk_rate flags for
the NVIDIA variant.
Kartik Rajput [Wed, 25 Feb 2026 06:59:12 +0000 (12:29 +0530)]
serial: amba-pl011: Introduce set_uartclk_rate vendor flag
The NVIDIA Tegra264 UART relies on configuring the UART clock rate
directly to program the desired baud rate.
Introduce the set_uartclk_rate vendor flag. When set, the driver
uses clk_set_rate() to program the UART clock to the desired baud
rate and clk_round_rate() to determine the maximum supported baud
rate.
Kartik Rajput [Wed, 25 Feb 2026 06:59:11 +0000 (12:29 +0530)]
serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
The NVIDIA Tegra264 UART has a broken fractional baud rate
divisor register. Using IBRD and FBRD may cause the baud rate
to fall outside the required tolerance.
Introduce the skip_ibrd_fbrd vendor flag to skip IBRD/FBRD
programming. When set, the baud rate is derived directly from the
UART clock rate using a fixed divisor.
Peter Maydell [Tue, 10 Feb 2026 12:50:59 +0000 (12:50 +0000)]
serial: amba-pl011: Enable UART in earlycon setup
Currently the PL011 driver only enables the UART (by setting UARTEN
in REG_CR) in pl011_startup(), so if it is used for earlycon it is
relying on the bootrom/firmware having left the UART enabled.
There's no particular reason not to actively enable the UART before
using it for earlycon, and the earlycon handling for e.g. the 8250
UART sets up the UART in its setup function, so follow that in the
PL011.
This allows use of earlycon with a UART that the firmware hasn't
already been using for its own output, but the main motivation is
that QEMU will otherwise log a message complaining that the guest is
trying to write to a UART it never enabled.
Randy Dunlap [Fri, 30 Jan 2026 07:29:37 +0000 (23:29 -0800)]
tty: hvc_iucv: fix off-by-one in number of supported devices
MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.
This is the number of entries in:
static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];
Sometimes hvc_iucv_table[] is limited by:
(a) if (num > hvc_iucv_devices) // for error detection
or
(b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places
(so these 2 don't agree; second one appears to be correct to me.)
hvc_iucv_devices can be 0..8. This is a counter.
(c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES)
If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].
Oops.
Andy Shevchenko [Wed, 28 Jan 2026 14:27:26 +0000 (15:27 +0100)]
serial: 8250_port: Drop duplicate NULL check
serial8250_release_dma() is NULL-aware, no need to check this in the caller.
While at it, make sure DMA won't be used again, by NULLifying the pointer.
Alyssa Milburn [Wed, 28 Jan 2026 11:28:54 +0000 (11:28 +0000)]
tty: serial: samsung_tty: avoid dev_dbg deadlock
commit a05025d0ce72 ("tty: serial: samsung_tty: use standard
debugging macros") changed the debug prints to dev_dbg, which can
result in deadlocks:
s3c24xx_serial_set_termios can be called with the port lock, and then
calls dev_dbg, which needs the console mutex. At the same time,
s3c24xx_serial_console_write can be called with the console lock
(e.g., inside console_unlock), and needs the port lock.
To avoid this, move one dev_dbg call and just delete the other.
Adam Ford [Tue, 10 Feb 2026 05:37:01 +0000 (23:37 -0600)]
pmdomain: mediatek: Fix power domain count
The wrong value of the number of domains is wrong which leads to
failures when trying to enumerate nested power domains.
PM: genpd_xlate_onecell: invalid domain index 0
PM: genpd_xlate_onecell: invalid domain index 1
PM: genpd_xlate_onecell: invalid domain index 3
PM: genpd_xlate_onecell: invalid domain index 4
PM: genpd_xlate_onecell: invalid domain index 5
PM: genpd_xlate_onecell: invalid domain index 13
PM: genpd_xlate_onecell: invalid domain index 14
Attempts to use these power domains fail, so fix this by
using the correct value of calculated power domains.
Signed-off-by: Adam Ford <aford173@gmail.com> Fixes: 88914db077b6 ("pmdomain: mediatek: Add support for Hardware Voter power domains") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Linus Walleij [Wed, 18 Feb 2026 13:44:38 +0000 (14:44 +0100)]
HID: mcp2221: Add module parameter to enfoce GPIO mode
Add a module parameter to MCP2221 to enfor GPIO mode on the
general purpose pins GP0 thru GP3.
If I plug a device of this type into my machine, it will use the
GP0, GP1, GP2 and GP3 pins for IIO voltage readings by default
if CONFIG_IIO is set.
However there may be cases where IIO is available but we want to
use the GP0 thru GP3 lines for GPIO anyway.
Example use:
insmode hid-mcp2221.ko gpio_mode_enforce=1
Result in dmesg:
mcp2221 0003:04D8:00DD.0005: GPIO 0 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 1 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 2 not in gpio mode
mcp2221 0003:04D8:00DD.0005: GPIO 3 not in gpio mode
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 0!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 1!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 2!
mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 3!
After this the gpiolib tools such as gpioset can be used to alter
the GPIO line values successfully.
Aditya Garg [Mon, 16 Feb 2026 21:24:46 +0000 (02:54 +0530)]
HID: appletb-kbd: add .resume method in PM
Upon resuming from suspend, the Touch Bar driver was missing a resume
method in order to restore the original mode the Touch Bar was on before
suspending. It is the same as the reset_resume method.
[jkosina@suse.com: rebased on top of the pm_ptr() conversion] Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Adrian Freund [Wed, 11 Mar 2026 19:19:33 +0000 (20:19 +0100)]
HID: logitech-hidpp: Enable MX Master 4 over bluetooth
The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.
Signed-off-by: Adrian Freund <adrian@freund.io> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Merge patch series "move_mount: expand MOVE_MOUNT_BENEATH"
Christian Brauner <brauner@kernel.org> says:
I'm too tired now to keep refining this but I think it's in good enough
shape for review.
Allow MOVE_MOUNT_BENEATH to target the caller's rootfs, allowing to
switch out the rootfs without pivot_root(2).
The traditional approach to switching the rootfs involves pivot_root(2)
or a chroot_fs_refs()-based mechanism that atomically updates fs->root
for all tasks sharing the same fs_struct. This has consequences for
fork(), unshare(CLONE_FS), and setns().
This series instead decomposes root-switching into individually atomic,
locally-scoped steps:
Since each step only modifies the caller's own state, the
fork/unshare/setns races are eliminated by design.
A key step to making this possible is to remove the locked mount
restriction. Originally MOVE_MOUNT_BENEATH doesn't support mounting
beneath a mount that is locked. The locked mount protects the underlying
mount from being revealed. This is a core mechanism of
unshare(CLONE_NEWUSER | CLONE_NEWNS). The mounts in the new mount
namespace become locked. That effectively makes the new mount table
useless as the caller cannot ever get rid of any of the mounts no matter
how useless they are.
We can lift this restriction though. We simply transfer the locked
property from the top mount to the mount beneath. This works because
what we care about is to protect the underlying mount aka the parent.
The mount mounted between the parent and the top mount takes over the
job of protecting the parent mount from the top mount mount. This leaves
us free to remove the locked property from the top mount which can
consequently be unmounted:
unshare(CLONE_NEWUSER | CLONE_NEWNS)
and we inherit a clone of procfs on /proc then currently we cannot
unmount it as:
umount -l /proc
will fail with EINVAL because the procfs mount is locked.
After this series we can now do:
mount --beneath -t tmpfs tmpfs /proc
umount -l /proc
after which a tmpfs mount has been placed beneath the procfs mount. The
tmpfs mount has become locked and the procfs mount has become unlocked.
This means you can safely modify an inherited mount table after
unprivileged namespace creation.
Afterwards we simply make it possible to move a mount beneath the
rootfs allowing to upgrade the rootfs.
Removing the locked restriction makes this very useful for containers
created with unshare(CLONE_NEWUSER | CLONE_NEWNS) to reshuffle an
inherited mount table safely and MOVE_MOUNT_BENEATH makes it possible to
switch out the rootfs instead of using the costly pivot_root(2).
* patches from https://patch.msgid.link/20260224-work-mount-beneath-rootfs-v1-0-8c58bf08488f@kernel.org:
selftests/filesystems: add MOVE_MOUNT_BENEATH rootfs tests
move_mount: allow MOVE_MOUNT_BENEATH on the rootfs
move_mount: transfer MNT_LOCKED
Add tests for mounting beneath the rootfs using MOVE_MOUNT_BENEATH:
- beneath_rootfs_success: mount beneath /, fchdir, chroot, umount2
MNT_DETACH -- verify root changed
- beneath_rootfs_old_root_stacked: after mount-beneath, verify old root
parent is clone via statmount
- beneath_rootfs_in_chroot_fail: chroot into subdir of same mount,
mount-beneath fails (dentry != mnt_root)
- beneath_rootfs_in_chroot_success: chroot into separate tmpfs mount,
mount-beneath succeeds
- beneath_rootfs_locked_transfer: in user+mount ns: mount-beneath
rootfs succeeds, MNT_LOCKED transfers, old root unmountable
- beneath_rootfs_locked_containment: in user+mount ns: after full
root-switch workflow, new root is MNT_LOCKED (containment preserved)
- beneath_non_rootfs_locked_transfer: mounts created before
unshare(CLONE_NEWUSER | CLONE_NEWNS) become locked; mount-beneath
transfers MNT_LOCKED, displaced mount can be unmounted
- beneath_non_rootfs_locked_containment: same setup, verify new mount
is MNT_LOCKED (containment preserved)
move_mount: allow MOVE_MOUNT_BENEATH on the rootfs
Allow MOVE_MOUNT_BENEATH to target the caller's rootfs. When the target
of a mount-beneath operation is the caller's root mount, verify that:
(1) The caller is located at the root of the mount, as enforced by
path_mounted() in do_lock_mount().
(2) Propagation from the parent mount would not overmount the target,
to avoid propagating beneath the rootfs of other mount namespaces.
The root-switching is decomposed into individually atomic, locally-scoped
steps: mount-beneath inserts the new root under the old one, chroot(".")
switches the caller's root, and umount2(".", MNT_DETACH) removes the old
root. Since each step only modifies the caller's own state, this avoids
cross-namespace vulnerabilities and inherent fork/unshare/setns races
that a chroot_fs_refs()-based approach would have.
Userspace can use the following workflow to switch roots:
When performing a mount-beneath operation the target mount can often be
locked:
unshare(CLONE_NEWUSER | CLONE_NEWNS);
mount --beneath -t tmpfs tmpfs /proc
will fail because the procfs mount on /proc became locked when the mount
namespace was created from the parent mount namespace. Same logic for:
unshare(CLONE_NEWUSER | CLONE_NEWNS);
mount --beneath -t tmpfs tmpfs /
MNT_LOCKED is raised to prevent an unprivileged mount namespace from
revealing whatever is under a given mount. To replace the rootfs we need
to handle that case though.
We can simply transfer the locked mount property from the top mount to
the mount beneath. The new mount we mounted beneath the top mount takes
over the job of the top mount in protecting the parent mount from being
revealed. This leaves us free to allow the top mount to be unmounted.
This also works during mount propagation and also works for the
non-MOVE_MOUNT_BENEATH case:
For (1) can_move_mount_beneath() rejects overmounted @source_mnt (We
could allow this but whatever it's not really a use-case and it's fugly
to move an overmounted mount stack around. What are you even doing? So
let's keep that restriction.
For (2) we can have @source_mnt overmounted (Someone overmounted us
while we locked the target mount.). Both are fine. @source_mnt will be
mounted on whatever @q was mounted on and @q will be mounted on the top
of the @source_mnt mount stack. Even in such cases we can unlock @q and
lock @source_mnt if @q was locked.
This effectively makes mount propagation useful in cases where a mount
namespace has a locked mount somewhere and we propagate a new mount
beneath it but the mount namespace could never get at it because the old
top mount remains locked. Again, we just let the newly propagated mount
take over the protection and unlock the top mount.
Merge patch series "namespace: allow creating empty mount namespaces"
Christian Brauner <brauner@kernel.org> says:
Currently, creating a new mount namespace always copies the entire mount
tree from the caller's namespace. For containers and sandboxes that
intend to build their mount table from scratch this is wasteful: they
inherit a potentially large mount tree only to immediately tear it down.
This series adds support for creating a mount namespace that contains
only a clone of the root mount, with none of the child mounts. Two new
flags are introduced:
- CLONE_EMPTY_MNTNS (0x400000000) for clone3(), using the 64-bit flag
space.
- UNSHARE_EMPTY_MNTNS (0x00100000) for unshare(), reusing the
CLONE_PARENT_SETTID bit which has no meaning for unshare.
Both flags imply CLONE_NEWNS. The resulting namespace contains a single
nullfs root mount with an immutable empty directory. The intended
workflow is to then mount a real filesystem (e.g., tmpfs) over the root
and build the mount table from there.
* patches from https://patch.msgid.link/20260306-work-empty-mntns-consolidated-v1-0-6eb30529bbb0@kernel.org:
selftests/filesystems: add clone3 tests for empty mount namespaces
selftests/filesystems: add tests for empty mount namespaces
namespace: allow creating empty mount namespaces
selftests/filesystems: add clone3 tests for empty mount namespaces
Add a test suite for the CLONE_EMPTY_MNTNS flag exercising the empty
mount namespace functionality through the clone3() syscall.
The clone3() code path is distinct from the unshare() path already
tested in empty_mntns_test.c. With clone3(), CLONE_EMPTY_MNTNS
(0x400000000ULL) is a 64-bit flag that implies CLONE_NEWNS. The
implication happens in kernel_clone() before copy_process(), unlike
unshare() where it goes through UNSHARE_EMPTY_MNTNS to
CLONE_EMPTY_MNTNS conversion in unshare_nsproxy_namespaces().
The tests cover:
- basic functionality: clone3 child gets empty mount namespace with
exactly one mount, root and cwd point to the same mount
- CLONE_NEWNS implication: CLONE_EMPTY_MNTNS works without explicit
CLONE_NEWNS, also works with redundant CLONE_NEWNS
- flag interactions: combines correctly with CLONE_NEWUSER,
CLONE_NEWPID, CLONE_NEWUTS, CLONE_NEWIPC, CLONE_PIDFD
- mutual exclusion: CLONE_EMPTY_MNTNS | CLONE_FS returns EINVAL
because the implied CLONE_NEWNS conflicts with CLONE_FS
- error paths: EPERM without capabilities, unknown 64-bit flags
rejected
- parent isolation: parent mount namespace is unchanged after clone
- many parent mounts: child still gets exactly one mount
- mount properties: root mount is nullfs, is its own parent, is the
only listmount entry
- overmount workflow: child can mount tmpfs over nullfs root to build
a writable filesystem from scratch
- repeated clone3: each child gets a distinct mount namespace
- setns: parent can join child's empty mount namespace via setns()
- regression: plain CLONE_NEWNS via clone3 still copies the full
mount tree
selftests/filesystems: add tests for empty mount namespaces
Add a test suite for the UNSHARE_EMPTY_MNTNS and CLONE_EMPTY_MNTNS
flags exercising the empty mount namespace functionality through the
kselftest harness.
The tests cover:
- basic functionality: unshare succeeds, exactly one mount exists in
the new namespace, root and cwd point to the same mount
- flag interactions: UNSHARE_EMPTY_MNTNS works standalone without
explicit CLONE_NEWNS, combines correctly with CLONE_NEWUSER and
other namespace flags (CLONE_NEWUTS, CLONE_NEWIPC)
- edge cases: EPERM without capabilities, works from a user namespace,
many source mounts still result in one mount, cwd on a different
mount gets reset to root
- error paths: invalid flags return EINVAL
- regression: plain CLONE_NEWNS still copies the full mount tree,
other namespace unshares are unaffected
- mount properties: the root mount has the expected statmount
properties, is its own parent, and is the only entry returned by
listmount
- repeated unshare: consecutive UNSHARE_EMPTY_MNTNS calls each
produce a new namespace with a distinct mount ID
- overmount workflow: verifies the intended usage pattern of creating
an empty mount namespace with a nullfs root and then mounting tmpfs
over it to build a writable filesystem from scratch
Add support for creating a mount namespace that contains only a copy of
the root mount from the caller's mount namespace, with none of the
child mounts. This is useful for containers and sandboxes that want to
start with a minimal mount table and populate it from scratch rather
than inheriting and then tearing down the full mount tree.
Two new flags are introduced:
- CLONE_EMPTY_MNTNS for clone3(), using the 64-bit flag space.
- UNSHARE_EMPTY_MNTNS for unshare(), reusing the
CLONE_PARENT_SETTID bit which has no meaning for unshare.
Both flags imply CLONE_NEWNS. For the unshare path,
UNSHARE_EMPTY_MNTNS is converted to CLONE_EMPTY_MNTNS in
unshare_nsproxy_namespaces() before it reaches copy_mnt_ns(), so the
mount namespace code only needs to handle a single flag.
In copy_mnt_ns(), when CLONE_EMPTY_MNTNS is set, clone_mnt() is used
instead of copy_tree() to clone only the root mount. The caller's root
and working directory are both reset to the root dentry of the new
mount.
The cleanup variables are changed from vfsmount pointers with
__free(mntput) to struct path with __free(path_put) because the empty
mount namespace path needs to release both mount and dentry references
when replacing the caller's root and pwd. In the normal (non-empty)
path only the mount component is set, and dput(NULL) is a no-op so
path_put remains correct there as well.
Merge patch series "fsmount: add FSMOUNT_NAMESPACE"
Christian Brauner <brauner@kernel.org> says:
Add FSMOUNT_NAMESPACE flag to fsmount() that creates a new mount
namespace with the newly created filesystem attached to a copy of the
real rootfs. This returns a namespace file descriptor instead of an
O_PATH mount fd, similar to how OPEN_TREE_NAMESPACE works for
open_tree().
This allows creating a new filesystem and immediately placing it in a
new mount namespace in a single operation, which is useful for container
runtimes and other namespace-based isolation mechanisms.
This accompanies OPEN_TREE_NAMESPACE and avoids a needless detour via
OPEN_TREE_NAMESPACE to get the same effect. Will be especially useful
when you mount an actual filesystem to be used as the container rootfs.
Add a helper to allocate a statmount buffer and call statmount(). This
helper will be shared by multiple test suites that need to query mount
information via statmount().
Add FSMOUNT_NAMESPACE flag to fsmount() that creates a new mount
namespace with the newly created filesystem attached to a copy of the
real rootfs. This returns a namespace file descriptor instead of an
O_PATH mount fd, similar to how OPEN_TREE_NAMESPACE works for open_tree().
This allows creating a new filesystem and immediately placing it in a
new mount namespace in a single operation, which is useful for container
runtimes and other namespace-based isolation mechanisms.
The rootfs mount is created before copying the real rootfs for the new
namespace meaning that the mount namespace id for the mount of the root
of the namespace is bigger than the child mounted on top of it. We've
never explicitly given the guarantee for such ordering and I doubt
anyone relies on it. Accepting that lets us avoid copying the mount
again and also avoids having to massage may_copy_tree() to grant an
exception for fsmount->mnt->mnt_ns being NULL.
The gpio-ranges in the MT7986A pinctrl node were incorrectly defined,
therefore, pin 100 cannot be used.
Correct the range count to match the driver.
Fixes: c3a064a32ed9 ("arm64: dts: mediatek: add pinctrl support for mt7986a") Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
net: ti: icssg: Fix wrong macro used in RX classifier configuration
The RX_CLASS_OR_REG macro is being used with RX_CLASS_OR_EN parameter
when writing to the AND enable register. This should use RX_CLASS_AND_EN
instead to properly configure the classifier AND enable register.
Fix this by using the correct RX_CLASS_AND_EN macro parameter for
RX_CLASS_OR_REG when configuring the PTP duplicate and HSR tag
classifiers.
Takashi Iwai [Thu, 12 Mar 2026 11:59:28 +0000 (12:59 +0100)]
Merge tag 'asoc-fix-v7.0-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.0
Quite a large pull request, but nothing too concerning here - everything
is fairly small. We've got a couple of smaller core fixes for races on
card teardown from Matteo Cotifava, a fix for handling dodgy DMI
information generated by u-boot, some driver specific fixes and some new
device IDs for Tegra.
kbuild: Use '-fms-anonymous-structs' if it is available
Clang recently added '-fms-anonymous-structs' [1] to specifically enable
the Microsoft tagged anonymous structure / union extension, for which
the kernel added '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
enable -fms-extensions"). Switch to this more narrow option if it is
available, which would have helped avoid the issue addressed by
commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
'-fms-extensions'"). GCC has talked about adding a similar flag [2] as
well but potentially naming it differently.
Move the selection of the flag to Kconfig to make it easier to use
cc-option (as CC_FLAGS_DIALECT may be used in arch Makefiles, which may
be too early for cc-option in Kbuild) and customize based on compiler
flag names.
Introduce CC_FLAGS_DIALECT to make it easier to update the various
places in the tree that rely on the GNU C standard and Microsoft
extensions flags atomically. All remaining uses of '-std=gnu11' and
'-fms-extensions' are in the tools directory (which has its own build
system) and other standalone Makefiles. This will allow the kernel to
use a narrower option to enable the Microsoft anonymous tagged structure
extension in a simpler manner. Place the CC_FLAGS_DIALECT block after
the configuration include (so that a future change can move the
selection of the flag to Kconfig) but before the
arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available
for use in those Makefiles).
Thomas Weißschuh [Fri, 27 Feb 2026 06:38:04 +0000 (07:38 +0100)]
kbuild: uapi: provide stub includes for some libc headers
Some UAPI headers incorrectly use libc headers. To compile-test these
UAPI headers, their respective libc dependencies need to be present.
Not all kernel toolchains provide these headers, reducing test coverage.
Introduce some stub headers which provide just enough symbols to test
all UAPI headers. Most headers are empty anyways, as their symbols are
only used in macros which are not actually evaluated.
As these headers are only ever used with newer kernel toolchains, they
can defer to compiler builtins in many cases.
As more UAPI headers are cleaned up to not require these stubs anymore,
they can be removed again.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Tested-by: Nicolas Schier <nsc@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260227-kbuild-uapi-libc-v1-6-c17de0d19776@weissschuh.net Signed-off-by: Nicolas Schier <nsc@kernel.org>
Mark Brown [Thu, 12 Mar 2026 11:29:01 +0000 (11:29 +0000)]
ASoC: fsl: add bitcount and timestamp controls
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:
The SAI and XCVR have the timestamp counters and bit counters, which can
be used by software to track the progress of the transmitter and receiver.
They can also be used to calculate the relative frequency of the bit clock
against the bus interface clock.
Pei Xiao [Thu, 12 Mar 2026 02:47:55 +0000 (10:47 +0800)]
spi: atcspi200: fix mutex initialization order
The atcspi_exec_mem_op() function may call mutex_lock() on the
driver's mutex before it is properly initialized if a SPI memory
operation is initiated immediately after devm_spi_register_controller()
is called. The mutex initialization currently occurs after the
controller registration, which leaves a window where the mutex could
be used uninitialized.
Move the mutex initialization to the beginning of the probe function,
before any registration or resource allocation.
Thomas Gleixner [Fri, 23 Jan 2026 23:17:57 +0000 (00:17 +0100)]
clocksource: Don't use non-continuous clocksources as watchdog
Using a non-continuous aka untrusted clocksource as a watchdog for another
untrusted clocksource is equivalent to putting the fox in charge of the
henhouse.
That's especially true with the jiffies clocksource which depends on
interrupt delivery based on a periodic timer. Neither the frequency of that
timer is trustworthy nor the kernel's ability to react on it in a timely
manner and rearm it if it is not self rearming.
Just don't bother to deal with this. It's not worth the trouble and only
relevant to museum piece hardware.
Unconditionally setting the CLOCK_SOURCE_VALID_FOR_HRES for the real TSC
clocksource is wrong as there is no guarantee that the early TSC was
validated for high resolution mode.
Set the flag only when the early TSC was validated as otherwise the
clocksource selection might enable high resolution mode with a TSC of
unknown quality and possibly no way to back out once it is discovered to be
unsuitable.
Thomas Gleixner [Fri, 23 Jan 2026 23:17:52 +0000 (00:17 +0100)]
MIPS: Don't select CLOCKSOURCE_WATCHDOG
MIPS selects CLOCKSOURCE_WATCHDOG, but none of the clocksources actually
sets the MUST_VERIFY flag. So compiling the watchdog in is a pointless
exercise. Remove the selects.
timekeeping/auxclock: Consistently use raw timekeeper for tk_setup_internals()
In aux_clock_enable() the clocksource from tkr_raw is used to call
tk_setup_internals(). Do the same in tk_aux_update_clocksource(). While
the clocksources will be the same in any case, this is less confusing.
tracing: Use explicit array size instead of sentinel elements in symbol printing
The sentinel value added by the wrapper macros __print_symbolic() et al
prevents the callers from adding their own trailing comma. This makes
constructing symbol list dynamically based on kconfig values tedious.
Drop the sentinel elements, so callers can either specify the trailing
comma or not, just like in regular array initializers.
This is [2/3] part of hinic3 Ethernet driver second submission.
With this patch hinic3 becomes a complete Ethernet driver with
pf and vf.
Add cmdq detailed-response interfaces.
Add dump interfaces for cmdq, aeq, ceq and mailbox.
Add msg_send_lock for message sending concurrency.
Add PF device support and chip_present_flag to check cards.
Add rx vlan offload support.
Add PF FLR wait and timeout handling.
Add 5 ethtool ops for information of driver and link.
Fan Gong [Tue, 10 Mar 2026 01:04:53 +0000 (09:04 +0800)]
hinic3: Add msg_send_lock for message sending concurrecy
As send_mbox_msg is invoked by 3 functions: hinic3_send_mbox_to_mgmt,
hinic3_response_mbox_to_mgmt and hinic3_send_mbox_to_mgmt_no_ack, only
hinic3_response_mbox_to_mgmt does not has mutex and the other two has
mbox->mbox_send_lock because their send actions are mutually exclusive.
As hinic3_response_mbox_to_mgmt does not conflict with them in send
actions but in mailbox resources, add the new mutex(msg_send_lock) in
send_mbox_msg to ensure message concurrency.
Besdies, in mbox_send_seg change FIELD_PREP to FIELD_GET in
MBOX_STATUS_FINISHED and MBOX_STATUS_SUCCESS to be more reasonable.
Fan Gong [Tue, 10 Mar 2026 01:04:51 +0000 (09:04 +0800)]
hinic3: Add chip_present_flag checks to prevent errors when card is absent
chip_present_flag is added for driver to prevent errors when card does
not exist. It has been added to multiple critical functions, including
command queue, mailbox and network device operations, ensuring that the
existence of the network card is verified before performing operations.
Add dump interfaces for CMDQ, AEQ, CEQ and mailbox to enhance debugging
capabilities.
Dump the WQE header for CMDQ.
Dump the detailed queue information for AEQ and CEQ.
Dump the related register status for mailbox.
Add new detailed response interfaces for the hinic3 command
queue (CMDQ), enhancing its functionality to handle commands
requiring input and output buffer pairs.
Wolfram Sang [Thu, 5 Mar 2026 21:54:04 +0000 (22:54 +0100)]
ARM: dts: renesas: r9a06g032-rzn1d400-db: Add QSPI node including NOR flash
Enable the QSPI controller to access the connected SPI NOR flash. The
NOR datasheet may suggest faster tuning parameters but those did not
work on my board.
ARM: dts: renesas: r9a06g032: Describe the QSPI controller
Add a node describing the QSPI controller.
There are 2 clocks feeding this controller:
- one for the reference clock
- one that feeds both the ahb and the apb interfaces
As the binding expect either the ref clock, or all three (ref, ahb and
apb) clocks, it makes sense to provide the same clock twice.
drm/ttm/tests: add a test to exercise ttm_bo_swapout
Currently, ttm_bo_swapout is not exercised by the TTM KUnit tests.
It used to be exercised until commit 76689eb52667 ("drm/ttm: remove
ttm_bo_validate_swapout test"), but that test was removed as it was
unreliable due to requiring to allocate half of the system memory.
Calling ttm_bo_swapout directly with a single allocated BO, however, does
not suffer from that problem, and was able to detect a UAF introduced by
commit c06da4b3573a ("drm/ttm: Tidy usage of local variables a little
bit"), when built with KASAN.
When applying a fix to that UAF, the test passed without any issues.
Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260309-ttm_bo_swapout_test-v2-1-219f64046cfe@igalia.com
projects / thirdparty / linux.git / log
