* Re: [PATCH v1 2/2] arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
From: Gavin Shan @ 2026-04-14 23:09 UTC (permalink / raw)
To: Ben Horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel, kernel test robot
In-Reply-To: <20260414132758.196874-4-ben.horgan@arm.com>
On 4/14/26 11:27 PM, Ben Horgan wrote:
> resctrl_mon_ctx_waiters is not used outside of this file, so make it
> static. This fixes the sparse warning:
>
> drivers/resctrl/mpam_resctrl.c:25:1: warning: symbol 'resctrl_mon_ctx_waiters' was not declared. Should it be static?
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603281842.c2K96tJA-lkp@intel.com/
> Fixes: 2a3c79c61539 ("arm_mpam: resctrl: Allow resctrl to allocate monitors")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> drivers/resctrl/mpam_resctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* [PATCH v2 1/1] vfio: selftests: Find devices that have VFIO selftest drivers
From: Josh Hilke @ 2026-04-14 23:09 UTC (permalink / raw)
To: Alex Williamson
Cc: Sean Christopherson, David Matlack, Vipin Sharma,
Raghavendra Rao Ananta, kvm, linux-kernel, Josh Hilke
In-Reply-To: <20260414230943.41198-1-jrhilke@google.com>
Add a new script, list_devices.sh, which prints out the
segment:bus:device.function numbers of devices on a machine that have a VFIO
selftest driver. This makes it easier to determine if the system is capable of
running VFIO selftests, because devices that have a VFIO selftest driver are
compatible with all VFIO selftests.
Example:
$ ./tools/testing/selftests/vfio/scripts/list_devices.sh
0000:6a:01.0
0000:6f:01.0
0000:74:01.0
Signed-off-by: Josh Hilke <jrhilke@google.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
---
tools/testing/selftests/vfio/Makefile | 1 +
.../selftests/vfio/scripts/list_devices.sh | 22 +++++++++++++++++++
2 files changed, 23 insertions(+)
create mode 100755 tools/testing/selftests/vfio/scripts/list_devices.sh
diff --git a/tools/testing/selftests/vfio/Makefile b/tools/testing/selftests/vfio/Makefile
index 8e90e409e91d..d48ac967f1dc 100644
--- a/tools/testing/selftests/vfio/Makefile
+++ b/tools/testing/selftests/vfio/Makefile
@@ -15,6 +15,7 @@ TEST_GEN_PROGS += vfio_pci_driver_test
TEST_FILES += scripts/cleanup.sh
TEST_FILES += scripts/lib.sh
+TEST_FILES += scripts/list_devices.sh
TEST_FILES += scripts/run.sh
TEST_FILES += scripts/setup.sh
diff --git a/tools/testing/selftests/vfio/scripts/list_devices.sh b/tools/testing/selftests/vfio/scripts/list_devices.sh
new file mode 100755
index 000000000000..b56fa23d5657
--- /dev/null
+++ b/tools/testing/selftests/vfio/scripts/list_devices.sh
@@ -0,0 +1,22 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+# List of devices which have a VFIO selftest driver
+DEVICES=(
+ "8086:0b25" # Intel SPR DSA
+ "8086:11fb" # Intel GNR-D DSA
+ "8086:1212" # Intel DR DSA
+ "8086:0cf8" # Intel CBDMA
+)
+
+# Print the segment:bus:device.function numbers of PCI devices that can be used
+# to run VFIO selftests.
+function main() {
+ local vendor_device_id
+
+ for vendor_device_id in "${DEVICES[@]}"; do
+ lspci -D -d "${vendor_device_id}" | awk '{print $1}'
+ done
+}
+
+main "$@"
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH v2 0/1] vfio: selftests: Find devices that have VFIO selftest drivers
From: Josh Hilke @ 2026-04-14 23:09 UTC (permalink / raw)
To: Alex Williamson
Cc: Sean Christopherson, David Matlack, Vipin Sharma,
Raghavendra Rao Ananta, kvm, linux-kernel, Josh Hilke
v2 of this series is only a single patch which adds a new script to print the
segment:bus:device.function numbers of PCI devices on the user's system which
have a VFIO selftest driver.
Example:
$ ./tools/testing/selftests/vfio/scripts/list_devices.sh
0000:6a:01.0
0000:6f:01.0
0000:74:01.0
The devices are compatible with all VFIO selftests. Other devices may be
compatible with VFIO selftests that don't use the driver functionality, but no
gaurantees.
User's can automate binding devices to VFIO (which is required in order to run
the selftests) by directing the output of list_devices.sh into
tools/testing/selftests/vfio/scripts/setup.sh.
Example:
$ ./tools/testing/selftests/vfio/scripts/setup.sh $(./tools/testing/selftests/vfio/scripts/list_devices.sh)
+ echo "0000:6a:01.0" > /sys/bus/pci/drivers/vfio-pci/unbind
+ echo "" > /sys/bus/pci/devices/0000:6a:01.0/driver_override
+ echo "0000:6a:01.0" > /sys/bus/pci/drivers/idxd/bind
+ echo "0000:6f:01.0" > /sys/bus/pci/drivers/vfio-pci/unbind
+ echo "" > /sys/bus/pci/devices/0000:6f:01.0/driver_override
+ echo "0000:6f:01.0" > /sys/bus/pci/drivers/idxd/bind
+ echo "0000:74:01.0" > /sys/bus/pci/drivers/vfio-pci/unbind
+ echo "" > /sys/bus/pci/devices/0000:74:01.0/driver_override
+ echo "0000:74:01.0" > /sys/bus/pci/drivers/idxd/bind
This series is based on top of the kvm/queue branch.
Changes from v1:
---
- Move the functionality to discover devices from setup.sh into its own script (Sean)
- Omit the patch which automates binding devices to VFIO (Sean, David)
- Change title of cover letter (Me)
v1: https://lore.kernel.org/kvm/20260409015139.2800185-1-jrhilke@google.com/
Josh Hilke (1):
vfio: selftests: Find devices that have VFIO selftest drivers
tools/testing/selftests/vfio/Makefile | 1 +
.../selftests/vfio/scripts/list_devices.sh | 22 +++++++++++++++++++
2 files changed, 23 insertions(+)
create mode 100755 tools/testing/selftests/vfio/scripts/list_devices.sh
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply
* Re: [PATCH v4 3/5] locking: Add contended_release tracepoint to sleepable locks
From: Paul E. McKenney @ 2026-04-14 23:09 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Thomas Bogendoerfer, Juergen Gross, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Thomas Gleixner,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, linux-mips,
virtualization, linux-arch, linux-mm, linux-trace-kernel,
kernel-team
In-Reply-To: <d2e5763278812499335b22a013aafb4979e3324b.1774536681.git.d@ilvokhin.com>
On Thu, Mar 26, 2026 at 03:10:02PM +0000, Dmitry Ilvokhin wrote:
> Add the contended_release trace event. This tracepoint fires on the
> holder side when a contended lock is released, complementing the
> existing contention_begin/contention_end tracepoints which fire on the
> waiter side.
>
> This enables correlating lock hold time under contention with waiter
> events by lock address.
>
> Add trace_contended_release() calls to the slowpath unlock paths of
> sleepable locks: mutex, rtmutex, semaphore, rwsem, percpu-rwsem, and
> RT-specific rwbase locks.
>
> Where possible, trace_contended_release() fires before the lock is
> released and before the waiter is woken. For some lock types, the
> tracepoint fires after the release but before the wake. Making the
> placement consistent across all lock types is not worth the added
> complexity.
>
> For reader/writer locks, the tracepoint fires for every reader releasing
> while a writer is waiting, not only for the last reader.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Looks plausible:
Acked-by: Paul E. McKenney <paulmck@kernel.org>
> ---
> include/trace/events/lock.h | 17 +++++++++++++++++
> kernel/locking/mutex.c | 4 ++++
> kernel/locking/percpu-rwsem.c | 11 +++++++++++
> kernel/locking/rtmutex.c | 1 +
> kernel/locking/rwbase_rt.c | 6 ++++++
> kernel/locking/rwsem.c | 10 ++++++++--
> kernel/locking/semaphore.c | 4 ++++
> 7 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/lock.h b/include/trace/events/lock.h
> index da978f2afb45..1ded869cd619 100644
> --- a/include/trace/events/lock.h
> +++ b/include/trace/events/lock.h
> @@ -137,6 +137,23 @@ TRACE_EVENT(contention_end,
> TP_printk("%p (ret=%d)", __entry->lock_addr, __entry->ret)
> );
>
> +TRACE_EVENT(contended_release,
> +
> + TP_PROTO(void *lock),
> +
> + TP_ARGS(lock),
> +
> + TP_STRUCT__entry(
> + __field(void *, lock_addr)
> + ),
> +
> + TP_fast_assign(
> + __entry->lock_addr = lock;
> + ),
> +
> + TP_printk("%p", __entry->lock_addr)
> +);
> +
> #endif /* _TRACE_LOCK_H */
>
> /* This part must be outside protection */
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 427187ff02db..6c2c9312eb8f 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -997,6 +997,9 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
> wake_q_add(&wake_q, next);
> }
>
> + if (trace_contended_release_enabled() && waiter)
> + trace_contended_release(lock);
> +
> if (owner & MUTEX_FLAG_HANDOFF)
> __mutex_handoff(lock, next);
>
> @@ -1194,6 +1197,7 @@ EXPORT_SYMBOL(ww_mutex_lock_interruptible);
>
> EXPORT_TRACEPOINT_SYMBOL_GPL(contention_begin);
> EXPORT_TRACEPOINT_SYMBOL_GPL(contention_end);
> +EXPORT_TRACEPOINT_SYMBOL_GPL(contended_release);
>
> /**
> * atomic_dec_and_mutex_lock - return holding mutex if we dec to 0
> diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
> index f3ee7a0d6047..46b5903989b8 100644
> --- a/kernel/locking/percpu-rwsem.c
> +++ b/kernel/locking/percpu-rwsem.c
> @@ -263,6 +263,9 @@ void percpu_up_write(struct percpu_rw_semaphore *sem)
> {
> rwsem_release(&sem->dep_map, _RET_IP_);
>
> + if (trace_contended_release_enabled() && wq_has_sleeper(&sem->waiters))
> + trace_contended_release(sem);
> +
> /*
> * Signal the writer is done, no fast path yet.
> *
> @@ -292,6 +295,14 @@ EXPORT_SYMBOL_GPL(percpu_up_write);
> void __percpu_up_read(struct percpu_rw_semaphore *sem)
> {
> lockdep_assert_preemption_disabled();
> + /*
> + * After percpu_up_write() completes, rcu_sync_is_idle() can still
> + * return false during the grace period, forcing readers into this
> + * slowpath. Only trace when a writer is actually waiting for
> + * readers to drain.
> + */
> + if (trace_contended_release_enabled() && rcuwait_active(&sem->writer))
> + trace_contended_release(sem);
> /*
> * slowpath; reader will only ever wake a single blocked
> * writer.
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index ccaba6148b61..3db8a840b4e8 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1466,6 +1466,7 @@ static void __sched rt_mutex_slowunlock(struct rt_mutex_base *lock)
> raw_spin_lock_irqsave(&lock->wait_lock, flags);
> }
>
> + trace_contended_release(lock);
> /*
> * The wakeup next waiter path does not suffer from the above
> * race. See the comments there.
> diff --git a/kernel/locking/rwbase_rt.c b/kernel/locking/rwbase_rt.c
> index 82e078c0665a..74da5601018f 100644
> --- a/kernel/locking/rwbase_rt.c
> +++ b/kernel/locking/rwbase_rt.c
> @@ -174,6 +174,8 @@ static void __sched __rwbase_read_unlock(struct rwbase_rt *rwb,
> static __always_inline void rwbase_read_unlock(struct rwbase_rt *rwb,
> unsigned int state)
> {
> + if (trace_contended_release_enabled() && rt_mutex_owner(&rwb->rtmutex))
> + trace_contended_release(rwb);
> /*
> * rwb->readers can only hit 0 when a writer is waiting for the
> * active readers to leave the critical section.
> @@ -205,6 +207,8 @@ static inline void rwbase_write_unlock(struct rwbase_rt *rwb)
> unsigned long flags;
>
> raw_spin_lock_irqsave(&rtm->wait_lock, flags);
> + if (trace_contended_release_enabled() && rt_mutex_has_waiters(rtm))
> + trace_contended_release(rwb);
> __rwbase_write_unlock(rwb, WRITER_BIAS, flags);
> }
>
> @@ -214,6 +218,8 @@ static inline void rwbase_write_downgrade(struct rwbase_rt *rwb)
> unsigned long flags;
>
> raw_spin_lock_irqsave(&rtm->wait_lock, flags);
> + if (trace_contended_release_enabled() && rt_mutex_has_waiters(rtm))
> + trace_contended_release(rwb);
> /* Release it and account current as reader */
> __rwbase_write_unlock(rwb, WRITER_BIAS - 1, flags);
> }
> diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
> index bf647097369c..602d5fd3c91a 100644
> --- a/kernel/locking/rwsem.c
> +++ b/kernel/locking/rwsem.c
> @@ -1387,6 +1387,8 @@ static inline void __up_read(struct rw_semaphore *sem)
> rwsem_clear_reader_owned(sem);
> tmp = atomic_long_add_return_release(-RWSEM_READER_BIAS, &sem->count);
> DEBUG_RWSEMS_WARN_ON(tmp < 0, sem);
> + if (trace_contended_release_enabled() && (tmp & RWSEM_FLAG_WAITERS))
> + trace_contended_release(sem);
> if (unlikely((tmp & (RWSEM_LOCK_MASK|RWSEM_FLAG_WAITERS)) ==
> RWSEM_FLAG_WAITERS)) {
> clear_nonspinnable(sem);
> @@ -1413,8 +1415,10 @@ static inline void __up_write(struct rw_semaphore *sem)
> preempt_disable();
> rwsem_clear_owner(sem);
> tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, &sem->count);
> - if (unlikely(tmp & RWSEM_FLAG_WAITERS))
> + if (unlikely(tmp & RWSEM_FLAG_WAITERS)) {
> + trace_contended_release(sem);
> rwsem_wake(sem);
> + }
> preempt_enable();
> }
>
> @@ -1437,8 +1441,10 @@ static inline void __downgrade_write(struct rw_semaphore *sem)
> tmp = atomic_long_fetch_add_release(
> -RWSEM_WRITER_LOCKED+RWSEM_READER_BIAS, &sem->count);
> rwsem_set_reader_owned(sem);
> - if (tmp & RWSEM_FLAG_WAITERS)
> + if (tmp & RWSEM_FLAG_WAITERS) {
> + trace_contended_release(sem);
> rwsem_downgrade_wake(sem);
> + }
> preempt_enable();
> }
>
> diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
> index 74d41433ba13..35ac3498dca5 100644
> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -230,6 +230,10 @@ void __sched up(struct semaphore *sem)
> sem->count++;
> else
> __up(sem, &wake_q);
> +
> + if (trace_contended_release_enabled() && !wake_q_empty(&wake_q))
> + trace_contended_release(sem);
> +
> raw_spin_unlock_irqrestore(&sem->lock, flags);
> if (!wake_q_empty(&wake_q))
> wake_up_q(&wake_q);
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v1 1/2] arm_mpam: resctrl: Fix the check for no monitor components found
From: Gavin Shan @ 2026-04-14 23:08 UTC (permalink / raw)
To: Ben Horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
In-Reply-To: <20260414132758.196874-3-ben.horgan@arm.com>
On 4/14/26 11:27 PM, Ben Horgan wrote:
> Dan Carpenter reports that, in mpam_resctrl_alloc_domain(), any_mon_comp is
> used in an 'if' condition when it may be uninitialized. Initialize it to
> NULL so that the check behaves correctly when no monitor components are
> found.
>
> Reported-by: Dan Carpenter <error27@gmail.com>
> Fixes: 264c285999fc ("arm_mpam: resctrl: Add monitor initialisation and domain boilerplate")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> drivers/resctrl/mpam_resctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [GIT PULL] Driver core changes for 7.0-rc1
From: Danilo Krummrich @ 2026-04-14 23:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Linus Torvalds, Greg Kroah-Hartman, Rafael J. Wysocki,
Saravana Kannan, Andrew Morton, driver-core, rust-for-linux,
linux-kernel
In-Reply-To: <ad6IJwpp5AA0-fAW@monoceros>
On Tue Apr 14, 2026 at 8:39 PM CEST, Uwe Kleine-König wrote:
> does that mean that there is a driver involved that somehow violates driver
> core assumptions and should be fixed even without the consistent locking?
Most likely. There are two known cases where interactions with this commit are
expected.
(1) One of the drivers probed on your machine gets stuck within probe() (or
any other place where the device lock is held, e.g. bus callbacks) for
some reason, e.g. due to a deadlock. In this case this commit would
potentially cause other tasks to get stuck in driver_attach() when they
attempt to register a driver for the same bus the bad one sits on.
This is also the main reason why we eventually reverted this commit, i.e.
despite not being the root cause of an issue, it makes an already bad
situation worse.
(2) If there is a driver probed on your machine that registers another driver
from within its probe() function for the same bus it results in a
deadlock. Note that this is transitive -- if a driver is probed on bus A,
which e.g. deploys devices on bus B that are subsequently probed, and then
in one of the probe() calls on bus B a driver is registered for bus A,
that is a deadlock as well.
For instance, this could happen when a platform driver that runs a PCIe
root complex deploys the corresponding PCI devices and one of the
corresponding PCI drivers registers a platform driver from probe().
Anyways, for the underlying problem this reveals, the exact constellation
doesn't matter. The anti-pattern it reveals is that drivers shouldn't be
registered from another driver's probe() function in the first place.
I fixed a few drivers having this anti-pattern and all of them had other
(lifetime) issues due to this and I think there are other potential
deadlock scenarios as well.
> Hints about how to approach the issue (if there is any) welcome.
For (1) I think it's obvious, and I think it wouldn't have gone unnoticed if any
of the drivers were bad to the point that they're getting stuck in probe() or
any other place where the device lock is held.
As for (2) I think the best way to catch it is lockdep. Unfortunately, lockdep
won't be very helpful without some additional tricks, since the driver core
calls lockdep_set_novalidate_class() for the device lock to avoid false
positives.
However, we can work around this by registering a dynamic lock class key for
every struct device individually [1] and fake taking the device lock with
mutex_acquire() and mutex_release() in __driver_attach().
This way your box should still boot properly, and in case it got stuck due to
(2), print a proper lockdep splat.
I hope this helps!
- Danilo
[1]
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 763e17e9f148..6770eba83fbd 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2555,6 +2555,7 @@ static void device_release(struct kobject *kobj)
*/
devres_release_all(dev);
+ lockdep_unregister_key(&dev->mutex_key);
kfree(dev->dma_range_map);
kfree(dev->driver_override.name);
@@ -3160,9 +3161,9 @@ void device_initialize(struct device *dev)
dev->kobj.kset = devices_kset;
kobject_init(&dev->kobj, &device_ktype);
INIT_LIST_HEAD(&dev->dma_pools);
- mutex_init(&dev->mutex);
+ lockdep_register_key(&dev->mutex_key);
+ __mutex_init(&dev->mutex, "dev->mutex", &dev->mutex_key);
spin_lock_init(&dev->driver_override.lock);
- lockdep_set_novalidate_class(&dev->mutex);
spin_lock_init(&dev->devres_lock);
INIT_LIST_HEAD(&dev->devres_head);
device_pm_init(dev);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index cb5046f0634d..a81a4ec2284c 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1228,7 +1228,9 @@ static int __driver_attach(struct device *dev, void *data)
* is an error.
*/
+ mutex_acquire(&dev->mutex.dep_map, 0, 0, _THIS_IP_);
ret = driver_match_device(drv, dev);
+ mutex_release(&dev->mutex.dep_map, _THIS_IP_);
if (ret == 0) {
/* no match */
return 0;
diff --git a/include/linux/device.h b/include/linux/device.h
index f0d52e1a6e07..2185d50f1c1d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -585,6 +585,7 @@ struct device {
struct mutex mutex; /* mutex to synchronize calls to
* its driver.
*/
+ struct lock_class_key mutex_key;
struct dev_links_info links;
struct dev_pm_info power;
^ permalink raw reply related
* Re: [REGRESSION] amdgpu fails to load eGPU after 6.19
From: Rio Liu @ 2026-04-14 23:03 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
regressions@lists.linux.dev, Bjorn Helgaas
In-Reply-To: <4dfc25f2-f660-c234-4e4d-c5c76216523d@linux.intel.com>
Hi Ilpo,
> This snippet only contains collateral damage and does not show where the
> problem originates from. Please provide a full dmesg instead with
> dyndbg="file drivers/pci/*.c +p" on the kernel command line.
>
> Preferrably test with the latest code + fixes that are in pci/resources
> branch (you can just take all changes from there) and get the logs from
> there. I wouldn't be surprised if your problem is already addressed by
> those fixes but we'll see.
Thanks a lot for the help! I tested on pci/resources
8cb081667377709f4924ab6b3a88a0d7a761fe91 "PCI: Fix alignment calculation for
resource size larger than align", and the eGPU is now loading! There are some
messages in dmesg showing "can't assign; no space" and "failed to assign", but I
don't see any functional impact from it. Including the dmesg anyways in case
there's anything important: https://pastebin.com/n5hhtkz0.
Thanks,
Rio
^ permalink raw reply
* Re: [v1,PATCH 1/1] i2c: mediatek: add bus regulator control for power saving
From: Andi Shyti @ 2026-04-14 23:03 UTC (permalink / raw)
To: adlavinitha reddy
Cc: Qii Wang, Matthias Brugger, AngeloGioacchino Del Regno, linux-i2c,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260318084621.4127757-2-adlavinitha.reddy@mediatek.com>
Hi Adlavinitha,
On Wed, Mar 18, 2026 at 04:46:16PM +0800, adlavinitha reddy wrote:
> Add conditional bus regulator enable/disable in mtk_i2c_transfer()
> to support I2C bus power gating for platforms that require it.
>
> This implementation:
> - Enables bus_regulator before clk_bulk_enable() if vbus-supply is defined
> - Disables bus_regulator after clk_bulk_disable()
> - Only activates when vbus-supply is provided in device tree
> - Has no impact on platforms without vbus-supply defined
>
> This approach provides power savinggs for platforms with an extra I2C bus
I changed /savinggs/savings/.
> regulator, while avoiding runtime PM complexity.
>
> TEST= Build and boot on MT8188
'"TEST=..." is a tag. There is no need to save characters in the
commit log. I changed it to "Tested on MT8188.".'
> Signed-off-by: adlavinitha reddy <adlavinitha.reddy@mediatek.com>
Please use capital letters for your name and for the committer's
name as well. I fixed it.
Now you have to explain me why you sent three times this same
patch.
Next time, please use the format '[PATCH v1 1/1]' instead of
'[v1,PATCH 1/1]'. Normally for the first version you can omit v1.
For single patches you don't need the 0/1 cover letter. Just send
as [PATCH].
Please read Documentation/SubmittingPatches.
For now I merged this patch in i2c/i2c-host-2.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH RFC v2 2/7] mm: memory_failure: Allow truncate_error_folio to return MF_DELAYED
From: Lisa Wang @ 2026-04-14 23:02 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Miaohe Lin, rientjes, seanjc, ackerleytng, vannapurve,
michael.roth, jiaqiyan, tabba, dave.hansen, Naoya Horiguchi,
Andrew Morton, Paolo Bonzini, Shuah Khan, Hugh Dickins,
Baolin Wang, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, linux-mm,
linux-kernel, kvm, linux-kselftest
In-Reply-To: <4d38d333-d446-40a3-b6f4-c4890bfd24cf@kernel.org>
On Mon, Apr 13, 2026 at 09:18:13PM +0200, David Hildenbrand (Arm) wrote:
> On 4/7/26 05:55, Miaohe Lin wrote:
> > On 2026/4/4 6:31, Lisa Wang wrote:
> >> [...snip...]
> >>>
> >>> Will it be better to add a pr_info here to provide some information for users?
> >>>
> >>> Thanks.
> >>> .
> >> I think we don't need to add pr_info here; truncate_error_folio() always
> >> leads to action_result, which already logs the recovery status.
> >
> > No strong opinion but I want to make code style more consistent with sth. like below:
> >
>
> Yeah, would be cleaner.
>
> > if (err == MF_DELAYED)
> > pr_info xxx
> > else if (err != 0)
> > pr_info("%#lx: Failed to punch page: %d\n", pfn, err);
> > else if (!filemap_release_folio(folio, GFP_NOIO))
> > pr_info("%#lx: failed to release buffers\n", pfn);
>
> Maybe we can even make the failed here a "Failed" ;)
Noted. Will update in V4.
Lisa
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH 2/4] perf/x86/intel: Don't context switch DS_AREA (and PEBS config) if PEBS is unused
From: Sean Christopherson @ 2026-04-14 22:49 UTC (permalink / raw)
To: Jim Mattson
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Borislav Petkov, Dave Hansen, x86,
Paolo Bonzini, linux-perf-users, linux-kernel, kvm, Mingwei Zhang,
Stephane Eranian, Dapeng Mi
In-Reply-To: <CALMp9eRxd=-xotnr9rLYhHtVK6G5oGAbXByXgpt078G8mWQEqg@mail.gmail.com>
On Tue, Apr 14, 2026, Jim Mattson wrote:
> On Tue, Apr 14, 2026 at 12:14 PM Sean Christopherson <seanjc@google.com> wrote:
> > @@ -5065,6 +5056,28 @@ static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, void *data)
> > if (pebs_mask & ~cpuc->intel_ctrl_guest_mask)
> > guest_pebs_mask = 0;
> >
> > + /*
> > + * Context switch DS_AREA and PEBS_DATA_CFG if and only if PEBS will be
> > + * active in the guest; if no records will be generated while the guest
> > + * is running, then running with host values is safe (see above).
> > + */
> > + if (!guest_pebs_mask)
> > + return arr;
>
> I think this has an unintended side effect. If DS_AREA and
> PEBS_DATA_CFG were previously listed (because pebs_guest_mask was
> previously non-zero), KVM will leave the stale entries in the MSR-load
> lists.
>
> KVM only clears MSR-load list entries for enumerated MSRs with
> matching guest and host values.
Argh, right. This as a delta change I guess? I'd love to overhaul the interface,
but reworking KVM to play nice with core_guest_get_msrs() would be much more
difficult.
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 20a153aa33cb..3244d5589981 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -5059,22 +5059,20 @@ static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, void *data)
/*
* Context switch DS_AREA and PEBS_DATA_CFG if and only if PEBS will be
* active in the guest; if no records will be generated while the guest
- * is running, then running with host values is safe (see above).
+ * is running, then simply keep the host values resident in hardware.
*/
- if (!guest_pebs_mask)
- return arr;
-
arr[(*nr)++] = (struct perf_guest_switch_msr){
.msr = MSR_IA32_DS_AREA,
.host = (unsigned long)cpuc->ds,
- .guest = kvm_pmu->ds_area,
+ .guest = guest_pebs_mask ? kvm_pmu->ds_area : (unsigned long)cpuc->ds,
};
if (x86_pmu.intel_cap.pebs_baseline) {
arr[(*nr)++] = (struct perf_guest_switch_msr){
.msr = MSR_PEBS_DATA_CFG,
.host = cpuc->active_pebs_data_cfg,
- .guest = kvm_pmu->pebs_data_cfg,
+ .guest = guest_pebs_mask ? kvm_pmu->data_cfg :
+ cpuc->active_pebs_data_cfg,
};
}
^ permalink raw reply related
* Re: [GIT PULL] x86/sev for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413212912.GAad1gKFHBqMyxF6xa@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 23:29:12 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/x86_sev_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/60b8d4d492815eed6d52646998167bc60dd94e5a
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] x86/misc for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413205435.GAad1YC1MWRQWnsiLc@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 22:54:35 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/x86_misc_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/970216e0231d7984a85492b9de9dba71004f4ee6
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] x86/microcode for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413201827.GAad1Pk78ZpiNkst7M@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 22:18:27 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/x86_microcode_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cd4cdc53cc5e7009ea6ef305336682d7800becf7
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] x86/fred for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413194444.GAad1HrCe2ScYYET2l@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 21:44:44 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/x86_fred_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e9635f2a73604ad9cb33d480b489a03bdd03329f
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] x86/cache for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413190518.GAad0-bpm1PrDujhXy@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 21:05:18 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/x86_cache_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fabd5a8d24fb5b430f71d3d3608696a7d5e9d720
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] RAS updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml
In-Reply-To: <20260413173144.GAad0ogErS0Ceh52Tx@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 19:31:44 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/tip/tip tags/ras_core_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/508fed6795411f5ab277fd1edc0d7adca4946f23
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] EDAC updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-14 22:48 UTC (permalink / raw)
To: Borislav Petkov; +Cc: Linus Torvalds, linux-edac, lkml
In-Reply-To: <20260413101846.GAadzDBgcGq09VOfpH@fat_crate.local>
The pull request you sent on Mon, 13 Apr 2026 12:18:46 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_v7.1_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1834703b8426c92211fd92a0e552fd4ae84dcb71
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* RE: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
From: Thomas Gleixner @ 2026-04-14 22:48 UTC (permalink / raw)
To: Bird, Tim, kernel test robot, pmladek@suse.com,
rostedt@goodmis.org, john.ogness@linutronix.de,
senozhatsky@chromium.org
Cc: oe-kbuild-all@lists.linux.dev, francesco@valla.it,
geert@linux-m68k.org, shashankbalaji02@gmail.com,
linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <MW5PR13MB563241C9F7C8BCAF0D5F3D21FD242@MW5PR13MB5632.namprd13.prod.outlook.com>
On Mon, Apr 13 2026 at 17:58, Tim Bird wrote:
> This is a false positive warning from the compiler (see below).
This is _NOT_ a false positive warning. The compiler is absolutely
correct.
>> 34
>> 35 /* returns a nanosecond value based on early cycles */
>> 36 static inline u64 early_times_ns(void)
>> 37 {
>> 38 if (CONFIG_EARLY_CYCLES_KHZ)
>> 39 /*
>> 40 * Note: the multiply must precede the division to avoid
>> 41 * truncation and loss of resolution
>> 42 * Don't use fancier MULT/SHIFT math here. Since this is
>> 43 * static, the compiler can optimize the math operations.
>> 44 */
>> > 45 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
> Based on this conditional, it's not possible for CONFIG_EARLY_CYCLES_KHZ to be zero
> on this line of code. Does GCC not catch this?
> if (0)
> x = <some expression>/0;
>
> So this is a false positive.
You clearly fail to understand how compilers work. The dead code
elimination happens _after_ the evaluation of the code and the compiler
does not care whether your initial condition evaluated to false or
not. That's documented compiler behaviour,
Whether GCC complains about it or not is completely irrelevant.
> I'll see if I can silence this warning.
Don't put much effort into it. This whole hack is going nowhere.
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 3/3] iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Replace multiple open-coded switch statements that map between
scan_index, alarm bits, and register offsets with a centralized
table-driven approach.
Introduce a struct-based alarm_map to describe the relationship
between scan indices and alarm offsets, and add a helper to
translate scan_index to event IDs. This removes duplicated logic
across ams_get_alarm_offset(), ams_event_to_channel(), and
ams_get_alarm_mask().
The new approach improves maintainability, reduces code size,
and makes it easier to extend or modify alarm mappings in the
future, while preserving existing behavior.
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
---
drivers/iio/adc/xilinx-ams.c | 161 +++++++++++++----------------------
1 file changed, 58 insertions(+), 103 deletions(-)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 70a1f97f6dad..2ce78883cead 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -102,6 +102,7 @@
#define AMS_PS_SEQ_MASK GENMASK(21, 0)
#define AMS_PL_SEQ_MASK GENMASK_ULL(59, 22)
+#define AMS_ALARM_NONE 0x000 /* not a real offset */
#define AMS_ALARM_TEMP 0x140
#define AMS_ALARM_SUPPLY1 0x144
#define AMS_ALARM_SUPPLY2 0x148
@@ -763,9 +764,49 @@ static int ams_read_raw(struct iio_dev *indio_dev,
}
}
+struct ams_alarm_map {
+ enum ams_ps_pl_seq scan_index;
+ unsigned int base_offset;
+};
+
+/*
+ * Array index matches enum ams_alarm_bit.
+ * Entries with base_offset == AMS_ALARM_NONE are unused/invalid
+ * (e.g. RESERVED) and must be skipped.
+ */
+static const struct ams_alarm_map alarm_map[] = {
+ [AMS_ALARM_BIT_TEMP] = { AMS_SEQ_TEMP, AMS_ALARM_TEMP },
+ [AMS_ALARM_BIT_SUPPLY1] = { AMS_SEQ_SUPPLY1, AMS_ALARM_SUPPLY1 },
+ [AMS_ALARM_BIT_SUPPLY2] = { AMS_SEQ_SUPPLY2, AMS_ALARM_SUPPLY2 },
+ [AMS_ALARM_BIT_SUPPLY3] = { AMS_SEQ_SUPPLY3, AMS_ALARM_SUPPLY3 },
+ [AMS_ALARM_BIT_SUPPLY4] = { AMS_SEQ_SUPPLY4, AMS_ALARM_SUPPLY4 },
+ [AMS_ALARM_BIT_SUPPLY5] = { AMS_SEQ_SUPPLY5, AMS_ALARM_SUPPLY5 },
+ [AMS_ALARM_BIT_SUPPLY6] = { AMS_SEQ_SUPPLY6, AMS_ALARM_SUPPLY6 },
+ [AMS_ALARM_BIT_RESERVED] = { 0, AMS_ALARM_NONE },
+ [AMS_ALARM_BIT_SUPPLY7] = { AMS_SEQ_SUPPLY7, AMS_ALARM_SUPPLY7 },
+ [AMS_ALARM_BIT_SUPPLY8] = { AMS_SEQ_SUPPLY8, AMS_ALARM_SUPPLY8 },
+ [AMS_ALARM_BIT_SUPPLY9] = { AMS_SEQ_SUPPLY9, AMS_ALARM_SUPPLY9 },
+ [AMS_ALARM_BIT_SUPPLY10] = { AMS_SEQ_SUPPLY10, AMS_ALARM_SUPPLY10 },
+ [AMS_ALARM_BIT_VCCAMS] = { AMS_SEQ_VCCAMS, AMS_ALARM_VCCAMS },
+ [AMS_ALARM_BIT_TEMP_REMOTE] = { AMS_SEQ_TEMP_REMOTE, AMS_ALARM_TEMP_REMOTE },
+};
+
+static int ams_scan_index_to_event(int scan_index)
+{
+ for (unsigned int i = 0; i < ARRAY_SIZE(alarm_map); i++) {
+ if (alarm_map[i].base_offset == AMS_ALARM_NONE)
+ continue;
+
+ if (alarm_map[i].scan_index == scan_index)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
static int ams_get_alarm_offset(int scan_index, enum iio_event_direction dir)
{
- int offset;
+ int offset, event;
if (scan_index >= AMS_PS_SEQ_MAX)
scan_index -= AMS_PS_SEQ_MAX;
@@ -779,36 +820,11 @@ static int ams_get_alarm_offset(int scan_index, enum iio_event_direction dir)
offset = 0;
}
- switch (scan_index) {
- case AMS_SEQ_TEMP:
- return AMS_ALARM_TEMP + offset;
- case AMS_SEQ_SUPPLY1:
- return AMS_ALARM_SUPPLY1 + offset;
- case AMS_SEQ_SUPPLY2:
- return AMS_ALARM_SUPPLY2 + offset;
- case AMS_SEQ_SUPPLY3:
- return AMS_ALARM_SUPPLY3 + offset;
- case AMS_SEQ_SUPPLY4:
- return AMS_ALARM_SUPPLY4 + offset;
- case AMS_SEQ_SUPPLY5:
- return AMS_ALARM_SUPPLY5 + offset;
- case AMS_SEQ_SUPPLY6:
- return AMS_ALARM_SUPPLY6 + offset;
- case AMS_SEQ_SUPPLY7:
- return AMS_ALARM_SUPPLY7 + offset;
- case AMS_SEQ_SUPPLY8:
- return AMS_ALARM_SUPPLY8 + offset;
- case AMS_SEQ_SUPPLY9:
- return AMS_ALARM_SUPPLY9 + offset;
- case AMS_SEQ_SUPPLY10:
- return AMS_ALARM_SUPPLY10 + offset;
- case AMS_SEQ_VCCAMS:
- return AMS_ALARM_VCCAMS + offset;
- case AMS_SEQ_TEMP_REMOTE:
- return AMS_ALARM_TEMP_REMOTE + offset;
- default:
+ event = ams_scan_index_to_event(scan_index);
+ if (event < 0 || alarm_map[event].base_offset == AMS_ALARM_NONE)
return 0;
- }
+
+ return alarm_map[event].base_offset + offset;
}
static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
@@ -821,49 +837,13 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
scan_index = AMS_PS_SEQ_MAX;
}
- switch (event) {
- case AMS_ALARM_BIT_TEMP:
- scan_index += AMS_SEQ_TEMP;
- break;
- case AMS_ALARM_BIT_SUPPLY1:
- scan_index += AMS_SEQ_SUPPLY1;
- break;
- case AMS_ALARM_BIT_SUPPLY2:
- scan_index += AMS_SEQ_SUPPLY2;
- break;
- case AMS_ALARM_BIT_SUPPLY3:
- scan_index += AMS_SEQ_SUPPLY3;
- break;
- case AMS_ALARM_BIT_SUPPLY4:
- scan_index += AMS_SEQ_SUPPLY4;
- break;
- case AMS_ALARM_BIT_SUPPLY5:
- scan_index += AMS_SEQ_SUPPLY5;
- break;
- case AMS_ALARM_BIT_SUPPLY6:
- scan_index += AMS_SEQ_SUPPLY6;
- break;
- case AMS_ALARM_BIT_SUPPLY7:
- scan_index += AMS_SEQ_SUPPLY7;
- break;
- case AMS_ALARM_BIT_SUPPLY8:
- scan_index += AMS_SEQ_SUPPLY8;
- break;
- case AMS_ALARM_BIT_SUPPLY9:
- scan_index += AMS_SEQ_SUPPLY9;
- break;
- case AMS_ALARM_BIT_SUPPLY10:
- scan_index += AMS_SEQ_SUPPLY10;
- break;
- case AMS_ALARM_BIT_VCCAMS:
- scan_index += AMS_SEQ_VCCAMS;
- break;
- case AMS_ALARM_BIT_TEMP_REMOTE:
- scan_index += AMS_SEQ_TEMP_REMOTE;
- break;
- default:
- break;
- }
+ if (event < 0 || event >= ARRAY_SIZE(alarm_map))
+ return NULL;
+
+ if (alarm_map[event].base_offset == AMS_ALARM_NONE)
+ return NULL;
+
+ scan_index += alarm_map[event].scan_index;
for (i = 0; i < dev->num_channels; i++)
if (dev->channels[i].scan_index == scan_index)
@@ -877,43 +857,18 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
static int ams_get_alarm_mask(int scan_index)
{
- int bit = 0;
+ int bit = 0, event;
if (scan_index >= AMS_PS_SEQ_MAX) {
bit = AMS_PL_ALARM_START;
scan_index -= AMS_PS_SEQ_MAX;
}
- switch (scan_index) {
- case AMS_SEQ_TEMP:
- return BIT(AMS_ALARM_BIT_TEMP + bit);
- case AMS_SEQ_SUPPLY1:
- return BIT(AMS_ALARM_BIT_SUPPLY1 + bit);
- case AMS_SEQ_SUPPLY2:
- return BIT(AMS_ALARM_BIT_SUPPLY2 + bit);
- case AMS_SEQ_SUPPLY3:
- return BIT(AMS_ALARM_BIT_SUPPLY3 + bit);
- case AMS_SEQ_SUPPLY4:
- return BIT(AMS_ALARM_BIT_SUPPLY4 + bit);
- case AMS_SEQ_SUPPLY5:
- return BIT(AMS_ALARM_BIT_SUPPLY5 + bit);
- case AMS_SEQ_SUPPLY6:
- return BIT(AMS_ALARM_BIT_SUPPLY6 + bit);
- case AMS_SEQ_SUPPLY7:
- return BIT(AMS_ALARM_BIT_SUPPLY7 + bit);
- case AMS_SEQ_SUPPLY8:
- return BIT(AMS_ALARM_BIT_SUPPLY8 + bit);
- case AMS_SEQ_SUPPLY9:
- return BIT(AMS_ALARM_BIT_SUPPLY9 + bit);
- case AMS_SEQ_SUPPLY10:
- return BIT(AMS_ALARM_BIT_SUPPLY10 + bit);
- case AMS_SEQ_VCCAMS:
- return BIT(AMS_ALARM_BIT_VCCAMS + bit);
- case AMS_SEQ_TEMP_REMOTE:
- return BIT(AMS_ALARM_BIT_TEMP_REMOTE + bit);
- default:
+ event = ams_scan_index_to_event(scan_index);
+ if (event < 0)
return 0;
- }
+
+ return BIT(event + bit);
}
static int ams_read_event_config(struct iio_dev *indio_dev,
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/3] iio: adc: xilinx-ams: use guard(mutex) for automatic locking
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi,
Andy Shevchenko
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Replace open-coded mutex_lock()/mutex_unlock() pairs with
guard(mutex) to simplify locking and ensure proper unlock on
all control flow paths.
This removes explicit unlock handling, reduces boilerplate,
and avoids potential mistakes in error paths while keeping
the behavior unchanged.
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
drivers/iio/adc/xilinx-ams.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 6191cd1b29a5..70a1f97f6dad 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -720,22 +720,20 @@ static int ams_read_raw(struct iio_dev *indio_dev,
int ret;
switch (mask) {
- case IIO_CHAN_INFO_RAW:
- mutex_lock(&ams->lock);
+ case IIO_CHAN_INFO_RAW: {
+ guard(mutex)(&ams->lock);
if (chan->scan_index >= AMS_CTRL_SEQ_BASE) {
ret = ams_read_vcc_reg(ams, chan->address, val);
if (ret)
- goto unlock_mutex;
+ return ret;
ams_enable_channel_sequence(indio_dev);
} else if (chan->scan_index >= AMS_PS_SEQ_MAX)
*val = readl(ams->pl_base + chan->address);
else
*val = readl(ams->ps_base + chan->address);
- ret = IIO_VAL_INT;
-unlock_mutex:
- mutex_unlock(&ams->lock);
- return ret;
+ return IIO_VAL_INT;
+ }
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_VOLTAGE:
@@ -939,7 +937,7 @@ static int ams_write_event_config(struct iio_dev *indio_dev,
alarm = ams_get_alarm_mask(chan->scan_index);
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
if (state)
ams->alarm_mask |= alarm;
@@ -948,8 +946,6 @@ static int ams_write_event_config(struct iio_dev *indio_dev,
ams_update_alarm(ams, ams->alarm_mask);
- mutex_unlock(&ams->lock);
-
return 0;
}
@@ -962,15 +958,13 @@ static int ams_read_event_value(struct iio_dev *indio_dev,
struct ams *ams = iio_priv(indio_dev);
unsigned int offset = ams_get_alarm_offset(chan->scan_index, dir);
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
if (chan->scan_index >= AMS_PS_SEQ_MAX)
*val = readl(ams->pl_base + offset);
else
*val = readl(ams->ps_base + offset);
- mutex_unlock(&ams->lock);
-
return IIO_VAL_INT;
}
@@ -983,7 +977,7 @@ static int ams_write_event_value(struct iio_dev *indio_dev,
struct ams *ams = iio_priv(indio_dev);
unsigned int offset;
- mutex_lock(&ams->lock);
+ guard(mutex)(&ams->lock);
/* Set temperature channel threshold to direct threshold */
if (chan->type == IIO_TEMP) {
@@ -1005,8 +999,6 @@ static int ams_write_event_value(struct iio_dev *indio_dev,
else
writel(val, ams->ps_base + offset);
- mutex_unlock(&ams->lock);
-
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
ams_event_to_channel() may return a pointer past the end of
dev->channels when no matching scan_index is found. This can lead
to invalid memory access in ams_handle_event().
Add a bounds check in ams_event_to_channel() and return NULL when
no channel is found. Also guard the caller to safely handle this
case.
Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
---
drivers/iio/adc/xilinx-ams.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 124470c92529..6191cd1b29a5 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -871,6 +871,9 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
if (dev->channels[i].scan_index == scan_index)
break;
+ if (i == dev->num_channels)
+ return NULL;
+
return &dev->channels[i];
}
@@ -1012,6 +1015,8 @@ static void ams_handle_event(struct iio_dev *indio_dev, u32 event)
const struct iio_chan_spec *chan;
chan = ams_event_to_channel(indio_dev, event);
+ if (!chan)
+ return;
if (chan->type == IIO_TEMP) {
/*
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Guilherme Ivo Bozi @ 2026-04-14 22:40 UTC (permalink / raw)
To: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Guilherme Ivo Bozi
This series addresses significant code duplication in alarm handling
logic across the Xilinx AMS IIO driver.
To address this, the series introduces a centralized table-driven
mapping (alarm_map) that replaces multiple switch statements spread
across the driver.
This improves:
- maintainability (single source of truth for mappings)
- readability (removes repeated switch logic)
- extensibility (new alarms require only table updates)
No functional changes are intended.
Series overview:
- Patch 1: fix out-of-bounds channel lookup
- Patch 2: convert mutex handling to guard(mutex)
- Patch 3: introduce table-driven alarm mapping
v1 -> v2:
- Fixed Fixes tag format
- Replaced AMS_ALARM_INVALID with AMS_ALARM_NONE
- Changed alarm_map base_offset type
v2 -> v3:
- Replace 'i >= num_channels' with 'i == num_channels'
- Add missing trailing comma in alarm_map array initializer
Guilherme Ivo Bozi (3):
iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event
handling
iio: adc: xilinx-ams: use guard(mutex) for automatic locking
iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
drivers/iio/adc/xilinx-ams.c | 190 +++++++++++++----------------------
1 file changed, 71 insertions(+), 119 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 22:42 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module,
Casey Schaufler
In-Reply-To: <CAHC9VhRoaECt03Rs-ZyoGhW2_qZkA_1weTYYjiXc41Yf5U8A_g@mail.gmail.com>
On 4/14/2026 1:44 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 4/14/2026 12:09 PM, Paul Moore wrote:
>>> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> For those of you who are interested in a more detailed explanation,
>>> here ya go ...
>>>
>>> NetLabel passes security attributes between itself and various LSMs
>>> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
>>> is an abstraction not only for the underlying labeling protocols, e.g.
>>> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
>>> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
>>> then translate the attributes into their own label representation.
>>>
>>> Outbound traffic is a bit more complicated as it involves changing the
>>> state of either a sock, via netlbl_sock_setattr(), or a packet, via
>>> netlbl_skbuff_setattr(), but in both cases we are once again dealing
>>> with netlbl_lsm_secattr struct, not a LSM specific label. Since the
>>> underlying labeling protocol is configured within the NetLabel
>>> subsystem and outside the individual LSMs, there is no worry about
>>> different LSMs requesting different protocol configurations (that is a
>>> separate system/network management issue). The only concern is that
>>> the on-the-wire representation is the same for each LSM that is using
>>> NetLabel based labeling. While some additional work would be
>>> required, it shouldn't be that hard to add NetLabel/protocol code to
>>> ensure the protocol specific labels are the same, and reject/drop the
>>> packet if not.
>> Indeed, we've discussed this, and I had at one point implemented it.
>> The problem is that for any meaningful access control policies you will
>> never get the two LSMs to agree on a unified network representation.
> That is also not correct. In the early days when SELinux was first
> being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used
> to interoperate between the systems and it did so quite well despite
> the SELinux TE/MLS policy being quite different than the CMW MLS
> policies. Yes, there were aspects of the SELinux policy that made
> this easier - it had a MLS component after all - but they were still
> *very* different policies.
CMW MLS and SELinux MLS can be mapped. They have the same components.
Comparing a full SELinux context and a Smack label is another beast.
>> SELinux transmits the MLS component of the security context. Smack passes
>> the text of its context.
> Arguably the NetLabel/CIPSO interoperability challenge between SELinux
> and Smack is due more to differences in how Smack encodes its security
> labels into MLS attributes than from any inherent interop limitation.
Yes. That is correct. The big issue I see is that SELinux does not represent
the entire context in the CIPSO header. Thus, you're up against many SELinux
contexts having the same wire representation, where Smack will have a unique
on wire for each context. You'll have many-to-one mapping issues.
> In fact, I thought the "cipso2" Smack interface was intended to
> resolve this by allowing admins to control how a Smack/CIPSO
> translation so that Smack could interop with MLS systems, is that not
> the case?
Indeed. A CMW MLS policy is way simpler than an SELinux policy.
>
>> Unless the Smack label is completely in step with
>> the MLS component of the SELinux context there is no hope of a common
>> network representation. If a *very talented* sysadmin could create such a
>> policy, you would have to wonder why, because Smack would be duplicating
>> the SELinux MLS policy.
> Interoperability wouldn't be a problem if everyone the "right" systems :D
Where would the fun in that be? ;)
>
>>> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
>>> require some additional work to convert over to a lsm_prop instead of
>>> a u32/secid, but if you look at the caching code that should be
>>> trivial. It might be as simple as adding a lsm_prop to the
>>> netlbl_lsm_secattr::attr struct since the cache stores a full secattr
>>> and not just a u32/secid.
>> Indeed. But with no viable users it seems like a lower priority task.
> You need to be very careful about those "viable users" claims ...
Today there are no users. There are other problems (e.g. mount options)
that have yet to be addressed.
>> And to be clear, I have no problem with netlabel as written. Multiple tag
>> support isn't simple (we did it for Trusted IRIX) and the limited space
>> available for IP options make it tricky.
> That's an entirely different problem from the LSM and protocol
> abstractions, but yeah.
>
^ permalink raw reply
* Re: [PATCH 07/11] KVM: x86: Add mode-aware versions of kvm_<reg>_{read,write}() helpers
From: Huang, Kai @ 2026-04-14 22:40 UTC (permalink / raw)
To: seanjc@google.com
Cc: yosry@kernel.org, kvm@vger.kernel.org, pbonzini@redhat.com,
linux-kernel@vger.kernel.org, vkuznets@redhat.com,
dwmw2@infradead.org, paul@xen.org
In-Reply-To: <ad5gYWAQAkkxqOza@google.com>
On Tue, 2026-04-14 at 08:42 -0700, Sean Christopherson wrote:
> On Tue, Apr 14, 2026, Kai Huang wrote:
> >
> > > --- a/arch/x86/kvm/svm/nested.c
> > > +++ b/arch/x86/kvm/svm/nested.c
> > > @@ -757,7 +757,7 @@ static void nested_vmcb02_prepare_save(struct vcpu_svm *svm)
> > >
> > > svm->vcpu.arch.cr2 = save->cr2;
> > >
> > > - kvm_rax_write(vcpu, save->rax);
> > > + kvm_rax_write_raw(vcpu, save->rax);
> > > kvm_rsp_write(vcpu, save->rsp);
> > > kvm_rip_write(vcpu, save->rip);
> > >
> > > @@ -1238,7 +1238,7 @@ static int nested_svm_vmexit_update_vmcb12(struct kvm_vcpu *vcpu)
> > > vmcb12->save.rflags = kvm_get_rflags(vcpu);
> > > vmcb12->save.rip = kvm_rip_read(vcpu);
> > > vmcb12->save.rsp = kvm_rsp_read(vcpu);
> > > - vmcb12->save.rax = kvm_rax_read(vcpu);
> > > + vmcb12->save.rax = kvm_rax_read_raw(vcpu);
> >
> > Not sure whether it matters, I think there's an inconsistency here:
> >
> > The "rax" one has "raw" postfix, but "rsp" doesn't, despite in practice it
> > is also a "raw" operation. Ditto for "rip", although it will be moved out
> > of the "regs[]" GPR array.
>
> Oh, there's very much an inconsistency. RIP probably "fine", as it should be
> impossible to get a 64-bit RIP into the CPU when it's not in 64-bit mode. RSP
> is likely not "fine", i.e. should probably use a "raw" version.
>
> But most importantly, for this patch, I want to avoid introducing functional
> changes, which means using the "raw" variant to read RAX.
Yeah make sense.
>
> > But maybe they are different?
> >
> > [...]
> >
> > > case EXIT_REASON_MSR_WRITE:
> > > - kvm_rcx_write(vcpu, tdx->vp_enter_args.r12);
> > > - kvm_rax_write(vcpu, tdx->vp_enter_args.r13 & -1u);
> > > - kvm_rdx_write(vcpu, tdx->vp_enter_args.r13 >> 32);
> > > + kvm_ecx_write(vcpu, tdx->vp_enter_args.r12);
> > > + kvm_eax_write(vcpu, tdx->vp_enter_args.r13 & -1u);
> >
> > Nit: the "& -1u" isn't needed anymore with using kvm_eax_write(), but maybe
> > we should just focus on replacing the functions in this patch but leave
> > cleanup in the future.
>
> Gah, good eyeballs. I intended to drop it here.
If you want to drop it in this patch, then there's another one in
__kvm_emulate_rdmsr():
@@ -2140,8 +2140,8 @@ static int __kvm_emulate_rdmsr(struct kvm_vcpu *vcpu,
u32 msr, int reg,
trace_kvm_msr_read(msr, data);
if (reg < 0) {
- kvm_rax_write(vcpu, data & -1u);
- kvm_rdx_write(vcpu, (data >> 32) & -1u);
+ kvm_eax_write(vcpu, data & -1u);
+ kvm_edx_write(vcpu, (data >> 32) & -1u);
} else {
kvm_register_write(vcpu, reg, data);
}
>
> > [...]
> >
> >
> > > @@ -12184,23 +12185,23 @@ static void __set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> > > vcpu->arch.emulate_regs_need_sync_from_vcpu = true;
> > > vcpu->arch.emulate_regs_need_sync_to_vcpu = false;
> > >
> > > - kvm_rax_write(vcpu, regs->rax);
> > > - kvm_rbx_write(vcpu, regs->rbx);
> > > - kvm_rcx_write(vcpu, regs->rcx);
> > > - kvm_rdx_write(vcpu, regs->rdx);
> > > - kvm_rsi_write(vcpu, regs->rsi);
> > > - kvm_rdi_write(vcpu, regs->rdi);
> > > + kvm_rax_write_raw(vcpu, regs->rax);
> > > + kvm_rbx_write_raw(vcpu, regs->rbx);
> > > + kvm_rcx_write_raw(vcpu, regs->rcx);
> > > + kvm_rdx_write_raw(vcpu, regs->rdx);
> > > + kvm_rsi_write_raw(vcpu, regs->rsi);
> > > + kvm_rdi_write_raw(vcpu, regs->rdi);
> > > kvm_rsp_write(vcpu, regs->rsp);
> > > - kvm_rbp_write(vcpu, regs->rbp);
> > > + kvm_rbp_write_raw(vcpu, regs->rbp);
> > >
> >
> > Ditto, the "rsp" one stands out. :-)
>
> Yeah, same thing as above. I don't think the currently code is 100% correct, but
> in practice it probably doesn't matter.
>
> If we want to clean up RSP handling, it should definitely be done in a separate
> patch (or patches, plural). But I'm hesitant to even try, especially for this
> path since it's very much part of KVM's ABI. I.e. if ain't broke, don't fix it.
Right.
I was thinking maybe just rename the RSP version to have the "raw" postfix
as well, just for consistency, but no other functional changes.
^ permalink raw reply
* Re: [PATCH] KVM: Drop kvm_vcpu.ready to squash race where "ready" can get stuck "true"
From: Sean Christopherson @ 2026-04-14 22:38 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm, linux-kernel, zhanghao, Wanpeng Li
In-Reply-To: <cb458ee1-e0c7-43e2-83a0-9effd9a723af@redhat.com>
On Tue, Apr 14, 2026, Paolo Bonzini wrote:
> On 4/9/26 23:33, Sean Christopherson wrote:
> > +static inline bool kvm_vcpu_is_runnable_and_scheduled_out(struct kvm_vcpu *vcpu)
> > +{
> > + return READ_ONCE(vcpu->preempted) ||
> > + (READ_ONCE(vcpu->scheduled_out) &&
> > + READ_ONCE(vcpu->wants_to_run) &&
>
> wants_to_run doesn't seem important here, because blocking will never be set
> outside KVM_RUN (unlike scheduled_out which can be set within any
> vcpu_load/vcpu_put pair, if you're unlucky enough).
Oh, good point.
> > + READ_ONCE(vcpu->stat.generic.blocking) &&
> > + !kvm_vcpu_is_blocking(vcpu));
>
> If you get here you have done the finish_rcuwait() in kvm_vcpu_block(),
> meaning that you've been already scheduled in, haven't you?
Gah, yes. I didn't realize finish_rcuwait() is what actually completes the
wakeup from KVM's perspective.
> So, you would need something like this:
>
> static inline bool kvm_vcpu_is_runnable_and_scheduled_out(struct kvm_vcpu *vcpu)
> {
> if (READ_ONCE(vcpu->preempted))
> return true;
>
> if (!READ_ONCE(vcpu->scheduled_out))
> return false;
> if (!READ_ONCE(vcpu->stat.generic.blocking))
Hmm, I think this could actually be:
if (!kvm_vcpu_is_blocking(vcpu))
return false;
Because my use of vcpu->stat.generic.blocking was purely due to missing that
finish_rcuwait() is effectively what clears "blocking". That would narrow the
window for false positives a little, e.g. would at least wait until after the
kvm_arch_vcpu_blocking() call to treat the vCPU as blocking.
> return false;
> return rcuwait_was_woken(kvm_arch_vcpu_get_wait(vcpu));
> }
>
> // in rcuwait.h
> static inline bool rcuwait_was_woken(struct rcuwait *w)
> {
> guard(rcu)();
> struct task_struct *t = rcu_access_pointer(w->task);
> return t && !task_is_runnable(t);
Ah, and I missed the task_is_runnable() check guarding vcpu->ready. I suspect I
assumed kvm_vcpu_on_spin() would do that check.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox