| Age | Commit message (Collapse) | Author |
|---|
|
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models.
In either model, both cond_resched() and might_resched() are always
disabled and do nothing.
Remove the unnecessary code for these when PREEMPT_DYNAMIC is selected.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Mete Durlu <meted@linux.ibm.com>
Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20260803191731.3244294-3-mark.rutland@arm.com
|
|
Propagating syncfs()/sync() to a FUSE server via FUSE_SYNCFS lets the
server flush its own cached or intermediate state when userspace asks the
filesystem to sync. This is currently enabled only for virtiofs and
fuseblk, because an untrusted server can use it to stall sync()
indefinitely (see commit 2d82ab251ef0 ("virtiofs: propagate sync() to file
server"), and commit d3906d8f3cee ("fuse: enable FUSE_SYNCFS for all
fuseblk servers")). Both of those mount types require host privilege to
set up, so the server is trusted not to abuse it.
There is nothing virtiofs- or block-specific about wanting to handle
syncfs(), though. A plain /dev/fuse server is just as entitled to
participate in the sync() path -- so that data it has buffered reaches
stable storage when the user asks for it -- provided it is equally
trusted.
The trust property that virtiofs and fuseblk satisfy is that neither can
be mounted without CAP_SYS_ADMIN in the initial user namespace (neither
sets FS_USERNS_MOUNT). A plain fuse mount does set FS_USERNS_MOUNT, so its
existence guarantees no such privilege; the privilege has to be checked
rather than assumed.
Add an opt-in INIT flag, FUSE_HAS_SYNCFS, and honor it only when the
server opened /dev/fuse with CAP_SYS_ADMIN in the initial user namespace,
recorded at mount time via file_ns_capable(). This is the same privilege
that mounting virtiofs or fuseblk requires, applied to the process that
actually services (and could stall) the connection. Checking the device
opener's capability -- rather than the mount's user namespace -- avoids
treating an unprivileged server that merely happens to run in the initial
user namespace (e.g. a normal sshfs mount) as trusted.
The flag is only advertised to servers that pass this check, so an
unprivileged server is never invited to opt in (and is ignored by
fuse_syncfs_enable() if it sets the flag anyway).
Signed-off-by: Jimmy Zuber <jamz@amazon.com>
Assisted-by: Claude:claude-opus-4-8 [Claude-Code]
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
|
|
Back in the 2.6.xx days, it was possible to for low-level drivers to set
the shost lock pointer. That is why there is a default lock and a
pointer to the shost lock.
However, support for this has long been removed, so drop
Scsi_Host.default_lock and make Scsi_Host.host_lock as the actual lock.
Getting the address of embedded host_lock structure just requires adding
a fixed offset value to the shost pointer. However, getting the value of
the host_lock pointer requires loading from a fixed offset to the shost
pointer. The latter should be very slightly slower, which is relevant as
this lock is used a lot throughout the core code and drivers.
Signed-off-by: John Garry <john.garry@linux.dev>
Acked-by: Damien Le Moal <dlemoal@kernel.org> # ata parts
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260831095821.3486994-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
IMA shouldn't measure or appraise configfs, but currently does because
it's missing from the default exclusion policies. Move CONFIGFS_MAGIC to
magic.h to expose the file system's magic to IMA, as well as other userland
applications.
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Frederick Lawler <fred@cloudflare.com>
Acked-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
|
|
The available-counter mask was a single unsigned long, but iteration
uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object.
Filling with an unsigned-long bit at index 32 and above is also wrong.
Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word
into CFG_MATCH when checking events, when allocating an index, and when
stopping all counters. Set the counter base to i times BITS_PER_LONG.
Share the CFG_MATCH ecall through a small helper so the 32-bit argument
split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits
above XLEN set, so the first word alone is not enough.
Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension")
Assisted-by: DeepSeek:deepseek-v3
Signed-off-by: Xixin Liu <liuxixin@kylinos.cn>
Link: https://patch.msgid.link/prpmask02cmap.v2.1786434000.git.liuxixin@kylinos.cn
Cc: stable@kernel.org
[pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The trace instance files set_ftrace_filter and set_ftrace_notrace was
updated to work with specific trace instances (trace_arrays). The issue is
that when these files are opened, there is a small race window where it
will use the ftrace_ops from the inode->private pointer to get a reference
to the trace_array and then take its reference. The problem is that the
ftrace_ops itself could be freed. If the rmdir on the instance happens at
the same time the set_ftrace_filter file is opened, the rmdir could have
also freed the ftrace_ops and referencing it will cause a use-after-free
bug and crash the kernel.
Instead, pass in the trace_array as the file private data (NULL for the
top level instance), and then pass both the trace_array and the ftrace_ops
to the ftrace_regex_open() function. If the trace_array is NULL, then it
just uses the ftrace_ops without the need to take its reference (like
normal). If the ftrace_ops is NULL, that is only the case for the top
level instance and the global_ops can be used.
This allows the trace_array to have its reference incremented before
touching the ftrace_ops that could also be freed when the instance is.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260828223901.29e26edb@robin
Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions")
Reported-by: Breno Leitao <leitao@debian.org>
Tested-by: Breno Leitao <leitao@debian.org>
Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
|
Only user DSQs use the per-DSQ deferred reenqueue state:
schedule_dsq_reenq() serves the local DSQ through
sch->pcpu->deferred_reenq_local and rejects all other built-in DSQ ids.
Every DSQ, built-in or not, still allocates a struct scx_dsq_pcpu per
possible CPU. As the local, reject, rescue and bypass DSQs are themselves
per-CPU, the wasted memory grows with the square of the CPU count, most of
it at boot before any scheduler is loaded.
Skip the allocation for built-in DSQ ids. While at it, rename ->pcpu to
->pcpu_user so that the per-CPU data reads as user-DSQ only.
Signed-off-by: fangqiurong <fangqiurong@kylinos.cn>
Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
There are two fields in struct acpi_device_pnp, device_name and
device_class, that were supposed to be populated and used by device
drivers, but they have never been used consistently and now they
are only set for the bus object in acpi_set_pnp_ids() (and never
read afterward).
Drop them along with all of the associated symbols except for
MAX_ACPI_CLASS_NAME_LEN and the acpi_device_class typedef that
are used by the ACPI netlink messaging code. Move those two
definitions closer to the struct acpi_bus_event that refers to
the acpi_device_class type.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/6314925.lOV4Wx5bFT@rafael.j.wysocki
|
|
Update the kernel-doc reference left over from an earlier revision
of the series, before the macro was renamed to IIO_DEV_ACQUIRE_FAILED().
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Nord routes the NSP (compute DSP) memory rail through a dedicated NMXC
resource instead of the shared MX rail. Add the index so device trees can
reference it.
Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate()
to disassociate mmap pages") introduced disassociation_lock to protect
new mmap registrations against uverbs_user_mmap_disassociate(), but
created an ABBA deadlock:
Thread A (mmap / fork):
mmap_lock -> disassociation_lock
Thread B (disassociate):
disassociation_lock -> mmap_lock
Fix by removing disassociation_lock entirely and using the pre-existing
hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same
protection: rdma_umap_open() and ib_uverbs_mmap() both use
down_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem
in uverbs_user_mmap_disassociate() is sufficient to block new registrations.
trylock is used in both mmap paths (not blocking down_read) because
mmap_lock is already held on entry, and uverbs_user_mmap_disassociate()
acquires mmap_lock internally — a blocking read would recreate the same
deadlock.
The only caller that was not taking hw_destroy_rwsem for write was
rdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while
iterating under lists_mutex. This is safe because ib_uverbs_close()
releases hw_destroy_rwsem entirely before acquiring lists_mutex, so the
two locks are never held simultaneously.
lockdep warning:
[ 776.654252] ======================================================
[ 776.655214] WARNING: possible circular locking dependency detected
[ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted
[ 776.657114] ------------------------------------------------------
[ 776.658087] devlink/14824 is trying to acquire lock:
[ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]
[ 776.660479]
[ 776.660479] but task is already holding lock:
[ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs]
[ 776.663177]
[ 776.663177] which lock already depends on the new lock.
[ 776.663177]
[ 776.664525]
[ 776.664525] the existing dependency chain (in reverse order) is:
[ 776.665724]
[ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}:
[ 776.666887] __mutex_lock+0x16d/0x2330
[ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs]
[ 776.668489] dup_mmap+0xa40/0x1790
[ 776.669170] copy_process+0x5dd2/0x6170
[ 776.669933] kernel_clone+0xb6/0x610
[ 776.670636] __do_sys_clone+0xb5/0xf0
[ 776.671354] do_syscall_64+0x70/0x12e0
[ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 776.672940]
[ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}:
[ 776.673985] down_write_nested+0x90/0x1e0
[ 776.674751] dup_mmap+0x201/0x1790
[ 776.675448] copy_process+0x5dd2/0x6170
[ 776.676180] kernel_clone+0xb6/0x610
[ 776.676904] __do_sys_clone+0xb5/0xf0
[ 776.677615] do_syscall_64+0x70/0x12e0
[ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 776.679239]
[ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}:
[ 776.680253] __lock_acquire+0x18c6/0x2ec0
[ 776.681018] lock_acquire+0x10e/0x2e0
[ 776.681742] down_read+0x95/0x430
[ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]
[ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs]
[ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs]
[ 776.685371] remove_client_context+0xa6/0xf0 [ib_core]
[ 776.686342] disable_device+0x12b/0x240 [ib_core]
[ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core]
[ 776.688233] ib_unregister_device+0x21/0x30 [ib_core]
[ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib]
[ 776.689999] device_release_driver_internal+0x3b2/0x560
[ 776.694876] bus_remove_device+0x1f5/0x3e0
[ 776.695638] device_del+0x3b9/0x990
[ 776.696329] mlx5_detach_device+0x17e/0x350 [mlx5_core]
[ 776.697429] mlx5_unload_one_devl_locked+0x3f/0xb0 [mlx5_core]
[ 776.698578] mlx5_devlink_reload_down+0x1f9/0x550 [mlx5_core]
[ 776.699712] devlink_reload+0x13e/0x680
[ 776.700456] devlink_nl_reload_doit+0xc29/0x1160
[ 776.701293] genl_family_rcv_msg_doit+0x1c9/0x2a0
[ 776.702135] genl_rcv_msg+0x3f0/0x6b0
[ 776.702854] netlink_rcv_skb+0x11d/0x370
[ 776.703605] genl_rcv+0x24/0x40
[ 776.704236] netlink_unicast+0x5b4/0x970
[ 776.704984] netlink_sendmsg+0x730/0xbf0
[ 776.705748] __sock_sendmsg+0xc5/0x190
[ 776.706461] __sys_sendto+0x201/0x2f0
[ 776.707188] __x64_sys_sendto+0xdc/0x1b0
[ 776.707931] do_syscall_64+0x70/0x12e0
[ 776.708643] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 776.709546]
[ 776.709546] other info that might help us debug this:
[ 776.709546]
[ 776.710910] Chain exists of:
[ 776.710910] &mm->mmap_lock --> &mm->mmap_lock/1 --> &file->disassociation_lock
[ 776.710910]
[ 776.712805] Possible unsafe locking scenario:
[ 776.712805]
[ 776.713828] CPU0 CPU1
[ 776.714589] ---- ----
[ 776.715347] lock(&file->disassociation_lock);
[ 776.716097] lock(&mm->mmap_lock/1);
[ 776.717067] lock(&file->disassociation_lock);
[ 776.718199] rlock(&mm->mmap_lock);
[ 776.718857]
[ 776.718857] *** DEADLOCK ***
Fixes: 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages")
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Link: https://patch.msgid.link/20260811-fix-mmap-lockdep-v1-1-1151b41063b4@nvidia.com
Acked-by: Junxian Huang <huangjunxian6@hisilicon.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Support fixed-size send WQEs for RC QPs when requested by userspace.
Calculate the WQE size from the maximum send SGE count and the 32-byte
inline OOB size, round it up to a power of two, and pass the size to
hardware in basic units.
When supported by the adapter, also enable placing the message sequence
number in the WQE. Preserve the existing variable-size WQE behavior when
userspace does not request fixed-size WQEs.
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Link: https://patch.msgid.link/20260827143736.2013093-4-kotaranov@linux.microsoft.com
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Extend the RC QP creation UAPI to support optional fixed-size WQEs and an
MMQ. Add a compatibility mask to the request, return the MMQ ID in the
response, and advertise the extended ABI through ucontext capabilities.
Use compatibility-aware udata validation so existing userspace remains
supported. Rename the legacy FMR queue definitions to MMQ and add the
corresponding hardware creation flags.
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Link: https://patch.msgid.link/20260827143736.2013093-2-kotaranov@linux.microsoft.com
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Qianghua Wang <qianghua.wang@senarytech.com> says:
This series adds SoundWire SDCA support for Senary SN624x
multi-function codecs (jack, speaker amp, DMIC) on Intel ARL,
LNL, MTL, and PTL.
Based on current sound.git tip (249bfb5d8897 — Merge branch 'for-next').
Validated previously on LG / Positivo Wildcat Lake (PTL) with
part_id 0x6244 (MODALIAS sdw:m0496p6244v03c01).
Link: https://patch.msgid.link/cover.1788230065.git.qianghua.wang@senarytech.com
|
|
Add sof_sdw helpers for SN624x jack, amp, and DMIC, and register the
codec_info entries used by the Intel SOF SoundWire machine driver.
Use name_prefix "sn624x" to match UCM and DAI widget naming.
Signed-off-by: Qianghua Wang <qianghua.wang@senarytech.com>
Link: https://patch.msgid.link/766c70645ad35ef446aa7078a2600c3361994e71.1788230065.git.qianghua.wang@senarytech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When refactoring device quirk code, the wrong git hash from my local
repository slipped into the common header.
Fixes: 5a43dc9f4ee0 ("firewire: core: detect device quirk when reading configuration ROM")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
clk_hw_get_clk() lets a provider get a struct clk for one of its own
struct clk_hw.
When a struct clk is created, the module usage count of the provider
is unconditionally increased. For a self-consuming provider, this means
it pins itself and the module can never be unloaded.
Increasing the module usage count should only be done when the consumer
lives in a different module from the provider. Use THIS_MODULE to
capture caller's module and increase the module usage count accordingly.
It is OK for consumer-only APIs such as clk_get() or of_clk_get() to
pass a NULL owner. As a result, any provider module will get pinned,
same as before.
Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
Expose the Reorder Completion Queue (RCQ) capability to userspace via
ucontext response using a comp_mask, and allow userspace to specify
ionic specific QP flags during QP creation.
Co-developed-by: Allen Hubbe <allen.hubbe@amd.com>
Signed-off-by: Allen Hubbe <allen.hubbe@amd.com>
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
Link: https://patch.msgid.link/20260813104954.319065-3-abhijit.gangurde@amd.com
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Let's start the 7.3 drm-misc-fixes cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next
Linux 7.3-rc1
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull forgotten EDAC updates from Borislav Petkov:
"Somewhat belated (and forgotten :-\) EDAC updates lineup for v7.3:
- Mark the mpc85xx and ThunderX EDAC drivers as orphaned due to lack
of access to hardware
- Remove the unused fake error injection interface from the EDAC
debugfs code due to potential races between logging a fake and a
real hw error
- edac_mc_sysfs: Use sysfs_emit_at() for proper bounds checking
- Remove Mark Gross from maintainer entries and move him to CREDITS
- Load the AMD address translation library only on systems which can
actually make use of it (have ECC memory) instead of on every AMD
Zen system out there
- In edac_altera, detect the SoC variant using the ECC manager's
compatible string instead of the build architecture to select the
correct interrupt layout, and remove leftover architecture-specific
ifdeffery from the double-bit error handling path
- Add a new reviewer for the Xilinx EDAC drivers
- Unify address translation logic in Intel client EDAC drivers igen6
and ie31200 along with detecting memory controller counts at boot
time instead of relying on hardcoded, platform specific numbers.
Also, fix a bunch of issues in them; work by Qiuxu Zhuo
- Add support for a new Intel processor platform Starfire which is a
derivative of Panther Lake SoCs
- The usual cleanups and fixlets all over"
* tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: (24 commits)
EDAC/thunderx: Orphan it
EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store()
EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation
EDAC/igen6: Add Intel Starfire SoCs support
EDAC/igen6: Refactor address translation logic
EDAC/igen6: Remove redundant resource configuration tables
EDAC/igen6: Detect present memory controllers at runtime
EDAC/igen6: Simplify compute die ID comments
EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit
EDAC/igen6: Fix Raptor Lake-P logged error address
EDAC/igen6: Fix channel address decode for non-hash mode
EDAC/igen6: Fix channel selection hash
EDAC/igen6: Fix interleave boundary condition
EDAC/ie31200: Decouple DIMM width decoding from enum order
RAS/AMD/ATL: Remove conditional return with no effect
EDAC: Remove redundant dev_err()
MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer
EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path
EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout
RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed
...
|
|
Add the ID for the Qualcomm SM7250 SoC.
Signed-off-by: Sreeshankar K <sreeshankar0910@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260824150156.1310-2-sreeshankar0910@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
When refactoring device quirk code, the wrong git hash from my local
repository slipped into the common header.
Fixes: 5a43dc9f4ee0 ("firewire: core: detect device quirk when reading configuration ROM")
Link: https://lore.kernel.org/r/20260831101253.1810143-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
pmc->sflist is read locklessly under rcu_read_lock() by
inet6_mc_check() during packet reception in the UDP and RAW
multicast receive paths.
ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place
when adding or removing a source filter. Additionally, when expanding
the filter buffer, newpsl was published via rcu_assign_pointer()
before writing the new source into the array.
Because 16-byte struct in6_addr writes are not atomic and array
shifting is not synchronized with RCU readers, concurrent readers in
inet6_mc_check() could read torn IPv6 addresses or observe
duplicated/missed source entries.
Fix this by switching ip6_mc_source() to copy-on-write RCU updates:
allocate and fully populate newpsl before publishing it via
rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(),
matching ip6_mc_msfilter().
Also remove the now unused IP6_SFBLOCK macro.
Fixes: 882ba1f73c06 ("mld: convert ipv6_mc_socklist->sflist to RCU")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828084531.1826790-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu")
added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a
use-after-free while iterating im->sources during concurrent deletions.
However, ip_check_mc_rcu() is called from RCU read-side critical
sections in packet receive and route lookup fast paths (e.g.
__mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()).
When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and
calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(),
an XFRM policy matching a multicast destination triggers
xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() ->
ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock
is already held on the same CPU, triggering a lockdep recursive locking
warning / deadlock.
Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the
IPv6 implementation in net/ipv6/mcast.c:
1. Add struct rcu_head to struct ip_sf_list and annotate sf_next,
sources, and tomb as __rcu pointers.
2. Use rcu_assign_pointer() and kfree_rcu() for list updates and
deletions.
3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse
im->sources locklessly with for_each_psf_rcu(), reading and writing
counter fields with READ_ONCE() and WRITE_ONCE().
Note: RCU conversion of /proc/net/mcfilter will be done in a
separate patch.
Fixes: 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu")
Reported-by: syzbot+3d99fb01bcd740f2fc1e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3d99fb01bcd740f2fc1e
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260827160656.903003-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
virtio_transport_recv_pkt() looks up sockets first by the full source and
destination tuple, then by destination only in the bound table. The
fallback is needed for listening and connecting sockets, but sockets remain
in the bound table after connect(), so it can also return a non-listening
socket.
The fallback does not validate the source address. In TCP_SYN_SENT, a
RESPONSE from an unrelated source can transition the victim socket to
TCP_ESTABLISHED while its stored remote address remains unchanged.
Subsequent RW packets from that source are delivered through the same
destination-only fallback.
This was reproduced with capability-empty processes under different UIDs.
The attacker discovered the target tuple through unprivileged AF_VSOCK
sock_diag and caused the victim socket to read 16 attacker-chosen bytes;
the intended peer-side socket read 0 of those 16 bytes.
Add vsock_check_source() to validate the transport, source port and source
CID against the peer stored in a non-listening socket. The local transport
is the CID exception because its packets are generated internally with
VMADDR_CID_LOCAL as their source, including connections using CID aliases.
Use the helper after lock_sock() in the virtio receive path.
Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
Closes: https://lore.kernel.org/netdev/20260813121236.2328599-1-4ncienth@gmail.com/
Cc: stable@vger.kernel.org
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Link: https://patch.msgid.link/20260826003929.966160-2-4ncienth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add UBWC configuration data for the Hawi platform, which uses UBWC 7.0
and enables the required flags and highest bank bit settings.
This allows drivers to query the correct UBWC capabilities on Hawi.
Also add UBWC 7.0 support to the version tag helper so that
qcom_ubwc_version_tag() returns the correct tag for UBWC 7.0.
Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260812-ubwc_for_hawi_maili-v1-1-c29edecb3bd8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Prep drm-xe-next for 7.4 PR.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
|
|
into clk-for-7.4
Merge the Qualcomm Kuno global clock controller binding through a topic
branch, to allow making the DeviceTree constants available to the
DeviceTree branch.
|
|
Document the Global Clock Controller (GCC) binding and associated
clock/reset IDs for the Qualcomm Kuno SoC.
Signed-off-by: Hardeep Sharma <hardeep.sharma@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260827-kuno-soc-support-v5-10-6d47636a8f09@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
apr_device_id was introduced in commit 6adba21eb434 ("soc: qcom: Add APR
bus driver") in 2018, and since then not a single driver made use of it.
So drop the unused id_table pointer from struct apr_driver and move
APR_NAME_SIZE to the apr header which still has a usage of it.
Note that with the id_table being NULL apr_device_match() degrades to just
of_driver_match_device(), so replace this callback accordingly.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/e8b352f33ae38df3616dc157c1cafd13d49c5e3e.1784554037.git.u.kleine-koenig@baylibre.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
A device-private folio migrated to system memory by a CPU fault can
remain reachable through the raw-PFN eviction path until migration
finalization drops the source reference.
If eviction selects the same device-private folio during this window,
it can attempt to migrate the folio again. The second migration can leave
an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to
retry indefinitely and resulting in a soft lockup and RCU stall.
Mark successfully migrated device-private folios using a low bit of
their zone_device_data before migration finalization. Make both CPU-fault
and raw-PFN migration paths skip device-private folios carrying this
flag.
Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve
it when a device-private folio is split. Keeping the state on the physical
folio also avoids depending on a virtual address that may change before a
fault occurs.
v2:
- Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost)
- Mark every base page covered by a migrated folio so retirement remains
valid if the folio is later split.
v3:
- Store the migrated state in a low bit of zone_device_data instead of
adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost)
- Mask the flag when retrieving the ZDD and preserve it when splitting
a folio.
- Drop the pre-existing fixes already covered by Matthew Brost's series:
https://patchwork.freedesktop.org/series/171651/
v4:
- Advance by the folio size only for migration entries marked with
MIGRATE_PFN_COMPOUND. (Sashiko)
v5:
- Simplify ZDD flag updates and folio iteration. (Matthew Brost)
- Skip retired device-private folios in the CPU-fault path. (Matthew Brost)
- Preserve flag bits while taking a new ZDD reference for split folios.
v6:
- Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration
entries are processed one at a time. (Sashiko)
- Drop the pre-existing fixes already covered by Matthew Brost's series:
https://patchwork.freedesktop.org/series/171651/
The lockup was observed as:
[10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557]
[10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
[10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023
[10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe]
[10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80
[10109.860655] Call Trace:
[10109.860655] <TASK>
[10109.860657] folio_lruvec_lock_irqsave+0x216/0x220
[10109.860661] ? __pfx_lru_add+0x10/0x10
[10109.860665] folio_batch_move_lru+0xc8/0x450
[10109.860670] ? lock_acquire+0xc4/0x2d0
[10109.860674] ? __folio_batch_add_and_move+0x60/0x2e0
[10109.860677] ? folio_migrate_mapping+0xa6/0x110
[10109.860679] ? folio_migrate_flags+0x13b/0x1b0
[10109.860681] ? __pfx_lru_add+0x10/0x10
[10109.860683] __folio_batch_add_and_move+0xe7/0x2e0
[10109.860685] ? dma_iova_try_alloc+0xb0/0x140
[10109.860689] folio_add_lru+0x64/0x80
[10109.860691] __migrate_device_finalize+0x12c/0x270
[10109.860695] migrate_device_finalize+0x10/0x20
[10109.860698] drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper]
[10109.860704] ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper]
[10109.860709] xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860819] ? xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860921] xe_bo_move+0x107e/0x1570 [xe]
[10109.860992] ? xe_ttm_tt_create+0x168/0x340 [xe]
[10109.861059] ? __up_read+0x98/0x2b0
[10109.861061] ? lock_is_held_type+0xa3/0x130
[10109.861067] ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm]
[10109.861075] ttm_bo_evict+0x141/0x1c0 [ttm]
[10109.861081] ttm_bo_evict_cb+0x9f/0x100 [ttm]
[10109.861086] ttm_lru_walk_for_evict+0x84/0x190 [ttm]
[10109.861091] ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe]
[10109.861198] ttm_bo_alloc_resource+0x219/0x750 [ttm]
[10109.861203] ? ttm_bo_alloc_resource+0xa9/0x750 [ttm]
[10109.861208] ? lock_acquire+0xc4/0x2d0
[10109.861214] ttm_bo_validate+0x94/0x1c0 [ttm]
[10109.861218] ? ww_mutex_trylock+0x19d/0x3d0
[10109.861219] ? _raw_write_unlock+0x22/0x50
[10109.861223] ttm_bo_init_reserved+0x17d/0x1f0 [ttm]
[10109.861228] xe_bo_init_locked+0x20a/0x620 [xe]
[10109.861294] ? __pfx_xe_ttm_bo_destroy+0x10/0x10 [xe]
[10109.861359] ? mark_held_locks+0x46/0x90
[10109.861361] ? __create_object+0x68/0xc0
[10109.861366] __xe_bo_create_locked+0x384/0xa20 [xe]
[10109.861432] ? lock_acquire+0xc4/0x2d0
[10109.861434] ? xe_drm_pagemap_populate_mm+0xd3/0x340 [xe]
[10109.861542] xe_bo_create_locked+0x23/0x40 [xe]
[10109.861609] xe_drm_pagemap_populate_mm+0x12e/0x340 [xe]
[10109.861707] ? __lock_acquire+0x43e/0x2930
[10109.861716] drm_pagemap_populate_mm+0x74/0xe0 [drm_gpusvm_helper]
[10109.861720] xe_svm_alloc_vram+0xb5/0x2c0 [xe]
[10109.861817] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861819] ? ktime_get+0x23/0x130
[10109.861821] ? trace_hardirqs_on+0x22/0xe0
[10109.861823] ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861826] __xe_svm_handle_pagefault+0x77d/0xbf0 [xe]
[10109.861924] ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861926] ? _raw_spin_unlock_irq+0x27/0x70
[10109.861928] ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861929] ? trace_hardirqs_on+0x22/0xe0
[10109.861931] ? _raw_spin_unlock_irq+0x27/0x70
[10109.861933] ? rwsem_down_write_slowpath+0x459/0x9a0
[10109.861937] xe_svm_handle_pagefault+0x3d/0xb0 [xe]
[10109.862030] xe_pagefault_queue_work+0x1a9/0x520 [xe]
[10109.862122] process_one_work+0x239/0x730
[10109.862127] worker_thread+0x200/0x3f0
[10109.862130] ? __pfx_worker_thread+0x10/0x10
[10109.862132] kthread+0x10d/0x150
[10109.862133] ? __pfx_kthread+0x10/0x10
[10109.862135] ret_from_fork+0x3bd/0x470
[10109.862138] ? __pfx_kthread+0x10/0x10
[10109.862140] ret_from_fork_asm+0x1a/0x30
[10109.862146] </TASK>
Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Assisted-by: Claude:claude-opus-4-8
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260810092845.2776097-1-arvind.yadav@intel.com
|
|
A bare "idle" reads as CPU idle state in sched_ext (ops.update_idle(),
idle cpumasks, scx_bpf_pick_idle_cpu()). cpu.idle is the cgroup analog
of the SCHED_IDLE policy, so name the task_group field sched_idle to
match scx_cgroup_init_args.sched_idle.
Pure rename, no behavior change.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fixes from Tejun Heo:
- After cgroup.kill was written to a cgroup, every child cloned into it
with CLONE_INTO_CGROUP was spuriously killed because the fork path
snapshotted the kill counter before resolving the target cgroup
- Releasing an isolated cpuset partition dropped the isolation of CPUs
isolated on the kernel command line
- Selftest and documentation fixes
* tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
selftests/cgroup: test clone3() into a previously killed cgroup
cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children
selftests/cgroup: Add test for preserving boot-isolated CPUs
cgroup/cpuset: Preserve boot-isolated CPUs on partition release
selftests/cgroup: Drop invalid boot isolation comparison
docs: cgroup-v2: fix misc.events key format description
selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter
selftests/cgroup: set the test plan after the setup checks
|
|
Now since all the Qcom SCM client drivers have been migrated over to
generic PAS TZ service, let's drop the exported SCM PAS wrappers.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-14-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add a new LSM audit data type LSM_AUDIT_DATA_NS that logs namespace
information in audit records. Two fields are provided:
- namespace_type: the CLONE_NEW* flag identifying the namespace type,
logged in hexadecimal.
- namespace_id: the unique 64-bit namespace identifier, retrievable
from userspace via NS_GET_ID or listns(2). Unlike the proc inode
number (inum), namespace_id is never recycled. For namespace creation
denials, namespace_id is 0 because the namespace does not exist yet.
A new audit data type is needed because no existing LSM_AUDIT_DATA_*
type carries namespace information. The closest alternatives (e.g.
LSM_AUDIT_DATA_TASK or LSM_AUDIT_DATA_NONE with custom strings) would
either lose the namespace type or require ad-hoc formatting that
bypasses the structured audit data union.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Günther Noack <gnoack@google.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
[PM: corrected audit fields in the description, subject tweaks]
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
|
All namespace types now share the same ns_common infrastructure. Extend
this to include a security blob so LSMs can start managing namespaces
uniformly without having to add one-off hooks or security fields to
every individual namespace type.
Add a ns_security pointer to ns_common and the corresponding lbs_ns blob
size to lsm_blob_sizes. Allocation and freeing hooks are called from the
common __ns_common_init() and __ns_common_free() paths so every
namespace type gets covered in one go. All information about the
namespace type and the appropriate casting helpers to get at the
containing namespace are available via ns_common making it
straightforward for LSMs to differentiate when they need to.
A namespace_install hook is called from validate_ns() during setns(2)
giving LSMs a chance to enforce policy on namespace transitions. The
LSM check runs before ns->ops->install() so the security module can deny
the operation before any type-specific installation effects.
Individual namespace types can still have their own specialized security
hooks when needed. This is just the common baseline that makes it easy
to track and manage namespaces from the security side without requiring
every namespace type to reinvent the wheel.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20260216-work-security-namespace-v1-1-075c28758e1f@kernel.org
Signed-off-by: Mickaël Salaün <mic@digikod.net>
[PM: subject tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
|
free_mnt_ns() skipped ns_common_free() for anonymous mount namespaces
(the "if (!is_anon_ns(ns))" guard) because they carry the reserved inum
MNT_NS_ANON_INO, which proc_free_inum() must never release.
A following change needs ns_common_free() to run for every namespace, to
release per-namespace state attached during __ns_common_init(). Move
the reserved-inum decision into __ns_common_free() and let free_mnt_ns()
call ns_common_free() unconditionally.
__ns_common_free() is shared by all namespace types, so it gates
proc_free_inum() on ns->inum > MNT_NS_INO_SPECIAL_MAX (a new alias for
MNT_NS_ANON_INO) rather than the mount-specific is_anon_ns(). The
reserved inums (MNT_NS_ANON_INO and the *_NS_INIT_INO values just above
it) belong to namespaces that are never freed, except the anonymous
mount namespace; dynamically allocated inums are >= PROC_DYNAMIC_FIRST.
So the comparison frees every dynamic inum and skips exactly the
anonymous mount namespace, matching the previous guard.
Cc: Günther Noack <gnoack@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Co-developed-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
|
The `cred` field in task_struct is currently marked as __rcu, but that's
not true: It can point to credentials from access_override_creds(), which
do not get freed with RCU delay.
What actually protects task_struct::cred is that accessing it is only
permitted for the current task (except for setting up a child during fork()
or tearing down a dead process).
(There is currently code in Smack that violates this rule, but that's a bug
and causes UAF, I have sent a separate fix for that.)
Clarify this, remove the __rcu marker, and remove RCU helpers from all
accesses to this field.
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
[PM: style tweak in security_init(), applied fixup from JH]
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
|
'20260801-nord_videocc_camcc-v2-1-674d7718e41f@oss.qualcomm.com' into clk-for-7.4
Merge Nord video and camera clock controller binding update through a
topic branch, to allow making them available in DeviceTree branches as
well.
|
|
Update the compatible and the bindings for CAMCC support on Nord
SoC.
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260801-nord_videocc_camcc-v2-4-674d7718e41f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The NW_GCC video axi reset clocks are required by the video SW driver
to assert and deassert the clock resets during their power down
sequence. Hence add these clock resets.
Fixes: 06498d59bb4e ("dt-bindings: clock: qcom: Add Nord Global Clock Controller")
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260801-nord_videocc_camcc-v2-1-674d7718e41f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
into clk-for-7.4
Merge the additional Monaco TSC clock controller constants through a
topci branch to make the available for DeviceTree as well.
|
|
Add the missing GCC TSCSS clocks and reset IDs that are required for the
Timestamp Counter Subsystem (TSCSS) functionality on Qualcomm QCS8300 SoC.
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260805-qcs8300-tsc-clks-v1-1-e7a5101ed479@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
clk-for-7.4
Merge the Hawi GPU clock controller DeviceTree binding through a topic
branch, so that the constants can also be merged into DeviceTree
branches.
|
|
Add the device tree binding and clock, reset and power-domain IDs for the
Hawi graphics clock controller. This lets Hawi device trees describe the
GPU clocks, resets and power domains, and lets dtbs_check validate those
nodes.
Add the qcom,hawi-gxclkctl compatible for the Hawi GX clock controller,
using qcom,kaanapali-gxclkctl as the fallback because the register layout
is identical.
Signed-off-by: Dongfang Zhao <dongfang.zhao@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260730-gpucc-hawi-v2-1-7bf618ab8a34@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Eliza camera clock controller is on CX and MX rails similar to Milos.
Add compatible string for Eliza camera and camera BIST clock
controller to the existing Milos camcc binding and add the
dt-bindings header for Eliza.
The camera clock controller provides power domains, so '#power-domain-cells'
must be present in the device tree node. Add this to required properties
to enforce it in the binding schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260806-eliza-mm-cc-v9-v10-6-6ba52dd14343@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add bindings documentation for the Eliza Graphics Clock Controller.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260806-eliza-mm-cc-v9-v10-5-6ba52dd14343@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Eliza Video clock controller is on CX and MX rails similar to Milos.
Add compatible string for Eliza video clock controller to the existing
Milos videocc binding and add the dt-bindings header for Eliza.
The video clock controller exposes power domains, so '#power-domain-cells'
must be present in the device node. Add it to the required properties list
to enforce this in binding validation.
There is no ABI breakage and no impact to the existing devices, since the
nodes using this binding already specify the '#power-domain-cells' property
for videocc.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260806-eliza-mm-cc-v9-v10-4-6ba52dd14343@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The inline wrappers: audit_log_kern_module(), audit_tk_injoffset(),
and audit_ntp_log() check audit_dummy_context() without unlikely(),
unlike every other wrapper in the file.
Add the missing annotations for consistency.
Signed-off-by: Ricardo Robaina <rrobaina@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
