* Re: (sashiko status) [PATCH 0/3] mm/damon: non-hotfix reviewed patches in damon/next tree
From: SeongJae Park @ 2026-04-03 0:27 UTC (permalink / raw)
To: SeongJae Park
Cc: Andrew Morton, Liam R. Howlett, damon, linux-doc, linux-kernel,
linux-mm
In-Reply-To: <20260402155733.77050-1-sj@kernel.org>
Dropping recipients who are not 100% surely interested in the sashiko review.
TL; DR: no blocker for this series is found.
Forwarding sashiko.dev review status for this series in a reply format with my
inline comments for details of why I say the TL; DR.
> # review url: https://sashiko.dev/#/patchset/20260402155733.77050-1-sj@kernel.org
>
> - [PATCH 1/3] mm/damon/ops-common: optimize damon_hot_score() using ilog2()
> - status: Reviewed
> - review: ISSUES MAY FOUND
No real issues here. Read my reply to the patch for more details.
> - [PATCH 2/3] Docs/admin-guide/mm/damon: fix 'parametrs' typo
> - status: Reviewed
> - review: No issues found.
As the 'review' is saying.
> - [PATCH 3/3] mm/damon: add synchronous commit for commit_inputs
> - status: Reviewed
> - review: ISSUES MAY FOUND
No real issues here. Read my reply to the patch for more details.
Thanks,
SJ
^ permalink raw reply
* RE: [PATCH v6 00/40] arm_mpam: Add KVM/arm64 and resctrl glue code
From: Rose, Charles @ 2026-04-02 23:38 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
tan.shaopeng@fujitsu.com, xhao@linux.alibaba.com,
catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net,
maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com,
suzuki.poulose@arm.com, kvmarm@lists.linux.dev,
zengheng4@huawei.com, linux-doc@vger.kernel.org
In-Reply-To: <20260313144617.3420416-1-ben.horgan@arm.com>
Hi Ben,
> This version of the mpam missing pieces series sees a couple of things
> dropped or hidden. Memory bandwith utilization with free-running counters
> is dropped in preference of just always using 'mbm_event' mode (ABMC
> emulation) which simplifies the code and allows for, in the future,
> filtering by read/write traffic. So, for the interim, there is no memory
> bandwidth utilization support. CDP is hidden behind config expert as
> remount of resctrl fs could potentially lead to out of range PARTIDs being
> used and the fix requires a change in fs/resctrl. The setting of MPAM2_EL2
> (for pkvm/nvhe) is dropped as too expensive a write for not much value.
>
> There are a couple of 'fixes' at the start of the series which address
> problems in the base driver but are only user visible due to this series.
>
I tested cache occupancy and memory bandwidth allocation on a Dell PowerEdge XE8712 with NVIDIA Grace A02P. Both seem to work as expected.
For the series:
Tested-by: Charles Rose <charles.rose@dell.com>
Thanks,
Charles
Internal Use - Confidential
^ permalink raw reply
* Re: [PATCH v3] doc: Add CPU Isolation documentation
From: Paul E. McKenney @ 2026-04-02 22:21 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Anna-Maria Behnsen, Gabriele Monaco, Ingo Molnar,
Jonathan Corbet, Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Peter Zijlstra, Phil Auld, Steven Rostedt, Thomas Gleixner,
Valentin Schneider, Vlastimil Babka, Waiman Long, linux-doc,
Sebastian Andrzej Siewior, Bagas Sanjaya
In-Reply-To: <20260402094749.18879-1-frederic@kernel.org>
On Thu, Apr 02, 2026 at 11:47:49AM +0200, Frederic Weisbecker wrote:
> nohz_full was introduced in v3.10 in 2013, which means this
> documentation is overdue for 13 years.
>
> Fortunately Paul wrote a part of the needed documentation a while ago,
> especially concerning nohz_full in Documentation/timers/no_hz.rst and
> also about per-CPU kthreads in
> Documentation/admin-guide/kernel-per-CPU-kthreads.rst
>
> Introduce a new page that gives an overview of CPU isolation in general.
>
> Acked-by: Waiman Long <longman@redhat.com>
> Reviewed-by: Valentin Schneider <vschneid@redhat.com>
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> ---
> v3: Apply suggestions from Randy, Steven, Valentin, Waiman and also Sashiko!
>
> Documentation/admin-guide/cpu-isolation.rst | 357 ++++++++++++++++++++
> Documentation/admin-guide/index.rst | 1 +
> 2 files changed, 358 insertions(+)
> create mode 100644 Documentation/admin-guide/cpu-isolation.rst
>
> diff --git a/Documentation/admin-guide/cpu-isolation.rst b/Documentation/admin-guide/cpu-isolation.rst
> new file mode 100644
> index 000000000000..8c65d03fd28c
> --- /dev/null
> +++ b/Documentation/admin-guide/cpu-isolation.rst
> @@ -0,0 +1,357 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============
> +CPU Isolation
> +=============
> +
> +Introduction
> +============
> +
> +"CPU Isolation" means leaving a CPU exclusive to a given workload
> +without any undesired code interference from the kernel.
> +
> +Those interferences, commonly pointed out as "noise", can be triggered
> +by asynchronous events (interrupts, timers, scheduler preemption by
> +workqueues and kthreads, ...) or synchronous events (syscalls and page
> +faults).
> +
> +Such noise usually goes unnoticed. After all, synchronous events are a
> +component of the requested kernel service. And asynchronous events are
> +either sufficiently well-distributed by the scheduler when executed
> +as tasks or reasonably fast when executed as interrupt. The timer
> +interrupt can even execute 1024 times per seconds without a significant
> +and measurable impact most of the time.
> +
> +However some rare and extreme workloads can be quite sensitive to
> +those kinds of noise. This is the case, for example, with high
> +bandwidth network processing that can't afford losing a single packet
> +or very low latency network processing. Typically those use cases
> +involve DPDK, bypassing the kernel networking stack and performing
> +direct access to the networking device from userspace.
> +
> +In order to run a CPU without or with limited kernel noise, the
> +related housekeeping work needs to be either shut down, migrated or
> +offloaded.
> +
> +Housekeeping
> +============
> +
> +In the CPU isolation terminology, housekeeping is the work, often
> +asynchronous, that the kernel needs to process in order to maintain
> +all its services. It matches the noises and disturbances enumerated
> +above except when at least one CPU is isolated. Then housekeeping may
> +make use of further coping mechanisms if CPU-tied work must be
> +offloaded.
> +
> +Housekeeping CPUs are the non-isolated CPUs where the kernel noise
> +is moved away from isolated CPUs.
> +
> +The isolation can be implemented in several ways depending on the
> +nature of the noise:
> +
> +- Unbound work, where "unbound" means not tied to any CPU, can be
> + simply migrated away from isolated CPUs to housekeeping CPUs.
> + This is the case of unbound workqueues, kthreads and timers.
> +
> +- Bound work, where "bound" means tied to a specific CPU, usually
> + can't be moved away as-is by nature. Either:
> +
> + - The work must switch to a locked implementation. E.g.:
> + This is the case of RCU with CONFIG_RCU_NOCB_CPU.
> +
> + - The related feature must be shut down and considered
> + incompatible with isolated CPUs. E.g.: Lockup watchdog,
> + unreliable clocksources, etc...
> +
> + - An elaborate and heavyweight coping mechanism stands as a
> + replacement. E.g.: the timer tick is shut down on nohz_full
> + CPUs but with the constraint of running a single task on
> + them. A significant cost penalty is added on kernel entry/exit
> + and a residual 1Hz scheduler tick is offloaded to housekeeping
> + CPUs.
> +
> +In any case, housekeeping work has to be handled, which is why there
> +must be at least one housekeeping CPU in the system, preferably more
> +if the machine runs a lot of CPUs. For example one per node on NUMA
> +systems.
> +
> +Also CPU isolation often means a tradeoff between noise-free isolated
> +CPUs and added overhead on housekeeping CPUs, sometimes even on
> +isolated CPUs entering the kernel.
> +
> +Isolation features
> +==================
> +
> +Different levels of isolation can be configured in the kernel, each of
> +which has its own drawbacks and tradeoffs.
> +
> +Scheduler domain isolation
> +--------------------------
> +
> +This feature isolates a CPU from the scheduler topology. As a result,
> +the target isn't part of the load balancing. Tasks won't migrate
> +either from or to it unless affined explicitly.
> +
> +As a side effect the CPU is also isolated from unbound workqueues and
> +unbound kthreads.
> +
> +Requirements
> +~~~~~~~~~~~~
> +
> +- CONFIG_CPUSETS=y for the cpusets-based interface
> +
> +Tradeoffs
> +~~~~~~~~~
> +
> +By nature, the system load is overall less distributed since some CPUs
> +are extracted from the global load balancing.
> +
> +Interfaces
> +~~~~~~~~~~
> +
> +- Documentation/admin-guide/cgroup-v2.rst cpuset isolated partitions are recommended
> + because they are tunable at runtime.
> +
> +- The 'isolcpus=' kernel boot parameter with the 'domain' flag is a
> + less flexible alternative that doesn't allow for runtime
> + reconfiguration.
> +
> +IRQs isolation
> +--------------
> +
> +Isolate the IRQs whenever possible, so that they don't fire on the
> +target CPUs.
> +
> +Interfaces
> +~~~~~~~~~~
> +
> +- The file /proc/irq/\*/smp_affinity as explained in detail in
> + Documentation/core-api/irq/irq-affinity.rst page.
> +
> +- The "irqaffinity=" kernel boot parameter for a default setting.
> +
> +- The "managed_irq" flag in the "isolcpus=" kernel boot parameter
> + tries a best effort affinity override for managed IRQs.
> +
> +Full Dynticks (aka nohz_full)
> +-----------------------------
> +
> +Full dynticks extends the dynticks idle mode, which stops the tick when
> +the CPU is idle, to CPUs running a single task in userspace. That is,
> +the timer tick is stopped if the environment allows it.
> +
> +Global timer callbacks are also isolated from the nohz_full CPUs.
> +
> +Requirements
> +~~~~~~~~~~~~
> +
> +- CONFIG_NO_HZ_FULL=y
> +
> +Constraints
> +~~~~~~~~~~~
> +
> +- The isolated CPUs must run a single task only. Multitask requires
> + the tick to maintain preemption. This is usually fine since the
> + workload usually can't stand the latency of random context switches.
> +
> +- No call to the kernel from isolated CPUs, at the risk of triggering
> + random noise.
> +
> +- No use of POSIX CPU timers on isolated CPUs.
> +
> +- Architecture must have a stable and reliable clocksource (no
> + unreliable TSC that requires the watchdog).
> +
> +
> +Tradeoffs
> +~~~~~~~~~
> +
> +In terms of cost, this is the most invasive isolation feature. It is
> +assumed to be used when the workload spends most of its time in
> +userspace and doesn't rely on the kernel except for preparatory
> +work because:
> +
> +- RCU adds more overhead due to the locked, offloaded and threaded
> + callbacks processing (the same that would be obtained with "rcu_nocbs"
> + boot parameter).
> +
> +- Kernel entry/exit through syscalls, exceptions and IRQs are more
> + costly due to fully ordered RmW operations that maintain userspace
> + as RCU extended quiescent state. Also the CPU time is accounted on
> + kernel boundaries instead of periodically from the tick.
> +
> +- Housekeeping CPUs must run a 1Hz residual remote scheduler tick
> + on behalf of the isolated CPUs.
> +
> +Checklist
> +=========
> +
> +You have set up each of the above isolation features but you still
> +observe jitters that trash your workload? Make sure to check a few
> +elements before proceeding.
> +
> +Some of these checklist items are similar to those of real-time
> +workloads:
> +
> +- Use mlock() to prevent your pages from being swapped away. Page
> + faults are usually not compatible with jitter sensitive workloads.
> +
> +- Avoid SMT to prevent your hardware thread from being "preempted"
> + by another one.
> +
> +- CPU frequency changes may induce subtle sorts of jitter in a
> + workload. Cpufreq should be used and tuned with caution.
> +
> +- Deep C-states may result in latency issues upon wake-up. If this
> + happens to be a problem, C-states can be limited via kernel boot
> + parameters such as processor.max_cstate or intel_idle.max_cstate.
> + More finegrained tunings are described in
> + Documentation/admin-guide/pm/cpuidle.rst page
> +
> +- Your system may be subject to firmware-originating interrupts - x86 has
> + System Management Interrupts (SMIs) for example. Check your system BIOS
> + to disable such interference, and with some luck your vendor will have
> + a BIOS tuning guidance for low-latency operations.
> +
> +
> +Full isolation example
> +======================
> +
> +In this example, the system has 8 CPUs and the 8th is to be fully
> +isolated. Since CPUs start from 0, the 8th CPU is CPU 7.
> +
> +Kernel parameters
> +-----------------
> +
> +Set the following kernel boot parameters to disable SMT and setup tick
> +and IRQ isolation:
> +
> +- Full dynticks: nohz_full=7
> +
> +- IRQs isolation: irqaffinity=0-6
> +
> +- Managed IRQs isolation: isolcpus=managed_irq,7
> +
> +- Prevent SMT: nosmt
> +
> +The full command line is then:
> +
> + nohz_full=7 irqaffinity=0-6 isolcpus=managed_irq,7 nosmt
> +
> +CPUSET configuration (cgroup v2)
> +--------------------------------
> +
> +Assuming cgroup v2 is mounted to /sys/fs/cgroup, the following script
> +isolates CPU 7 from scheduler domains.
> +
> +::
> +
> + cd /sys/fs/cgroup
> + # Activate the cpuset subsystem
> + echo +cpuset > cgroup.subtree_control
> + # Create partition to be isolated
> + mkdir test
> + cd test
> + echo +cpuset > cgroup.subtree_control
> + # Isolate CPU 7
> + echo 7 > cpuset.cpus
> + echo "isolated" > cpuset.cpus.partition
> +
> +The userspace workload
> +----------------------
> +
> +Fake a pure userspace workload, the program below runs a dummy
> +userspace loop on the isolated CPU 7.
> +
> +::
> +
> + #include <stdio.h>
> + #include <fcntl.h>
> + #include <unistd.h>
> + #include <errno.h>
> + int main(void)
> + {
> + // Move the current task to the isolated cpuset (bind to CPU 7)
> + int fd = open("/sys/fs/cgroup/test/cgroup.procs", O_WRONLY);
> + if (fd < 0) {
> + perror("Can't open cpuset file...\n");
> + return 0;
> + }
> +
> + write(fd, "0\n", 2);
> + close(fd);
> +
> + // Run an endless dummy loop until the launcher kills us
> + while (1)
> + ;
> +
> + return 0;
> + }
> +
> +Build it and save for later step:
> +
> +::
> +
> + # gcc user_loop.c -o user_loop
> +
> +The launcher
> +------------
> +
> +The below launcher runs the above program for 10 seconds and traces
> +the noise resulting from preempting tasks and IRQs.
> +
> +::
> +
> + TRACING=/sys/kernel/tracing/
> + # Make sure tracing is off for now
> + echo 0 > $TRACING/tracing_on
> + # Flush previous traces
> + echo > $TRACING/trace
> + # Record disturbance from other tasks
> + echo 1 > $TRACING/events/sched/sched_switch/enable
> + # Record disturbance from interrupts
> + echo 1 > $TRACING/events/irq_vectors/enable
> + # Now we can start tracing
> + echo 1 > $TRACING/tracing_on
> + # Run the dummy user_loop for 10 seconds on CPU 7
> + ./user_loop &
> + USER_LOOP_PID=$!
> + sleep 10
> + kill $USER_LOOP_PID
> + # Disable tracing and save traces from CPU 7 in a file
> + echo 0 > $TRACING/tracing_on
> + cat $TRACING/per_cpu/cpu7/trace > trace.7
> +
> +If no specific problem arose, the output of trace.7 should look like
> +the following:
> +
> +::
> +
> + <idle>-0 [007] d..2. 1980.976624: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=user_loop next_pid=1553 next_prio=120
> + user_loop-1553 [007] d.h.. 1990.946593: reschedule_entry: vector=253
> + user_loop-1553 [007] d.h.. 1990.946593: reschedule_exit: vector=253
> +
> +That is, no specific noise triggered between the first trace and the
> +second during 10 seconds when user_loop was running.
> +
> +Debugging
> +=========
> +
> +Of course things are never so easy, especially on this matter.
> +Chances are that actual noise will be observed in the aforementioned
> +trace.7 file.
> +
> +The best way to investigate further is to enable finer grained
> +tracepoints such as those of subsystems producing asynchronous
> +events: workqueue, timer, irq_vector, etc... It also can be
> +interesting to enable the tick_stop event to diagnose why the tick is
> +retained when that happens.
> +
> +Some tools may also be useful for higher level analysis:
> +
> +- Documentation/tools/rtla/rtla.rst provides a suite of tools to analyze
> + latency and noise in the system. For example Documentation/tools/rtla/rtla-osnoise.rst
> + runs a kernel tracer that analyzes and output a summary of the noises.
> +
> +- dynticks-testing does something similar to rtla-osnoise but in userspace. It is available
> + at git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index b734f8a2a2c4..cd28dfe91b06 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -94,6 +94,7 @@ likely to be of interest on almost any system.
>
> cgroup-v2
> cgroup-v1/index
> + cpu-isolation
> cpu-load
> mm/index
> module-signing
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH] docs: leds: uleds: Make the documentation match the code.
From: Björn Persson @ 2026-04-02 20:27 UTC (permalink / raw)
To: Lee Jones, Pavel Machek
Cc: Jonathan Corbet, Shuah Khan, linux-leds, linux-doc, linux-kernel
From: Björn Persson <Bjorn@Rombobjörn.se>
· max_brightness must be set. Leaving it uninitialized or just omitting it
won't work.
· The maximum brightness is not 255 but the value given to max_brightness.
· Brightness values must be read as ints, not bytes.
· The ints are signed, so the word "unsigned" is misleading.
Signed-off-by: Björn Persson <Bjorn@Rombobjörn.se>
---
Documentation/leds/uleds.rst | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/Documentation/leds/uleds.rst b/Documentation/leds/uleds.rst
index 83221098009c..9875a0fa4185 100644
--- a/Documentation/leds/uleds.rst
+++ b/Documentation/leds/uleds.rst
@@ -17,16 +17,20 @@ structure to it (found in kernel public header file linux/uleds.h)::
struct uleds_user_dev {
char name[LED_MAX_NAME_SIZE];
+ int max_brightness;
};
-A new LED class device will be created with the name given. The name can be
-any valid sysfs device node name, but consider using the LED class naming
-convention of "devicename:color:function".
+A new LED class device will be created with the given name and maximum
+brightness. The name can be any valid sysfs device node name, but consider
+using the LED class naming convention of "devicename:color:function".
-The current brightness is found by reading a single byte from the character
-device. Values are unsigned: 0 to 255. Reading will block until the brightness
-changes. The device node can also be polled to notify when the brightness value
-changes.
+Although max_brightness is a signed int, only positive values are valid:
+1 to INT_MAX.
+
+The current brightness is found by reading a whole int from the character
+device. The possible values are 0 to max_brightness. Reading will block until
+the brightness changes. The device node can also be polled to notify when the
+brightness value changes.
The LED class device will be removed when the open file handle to /dev/uleds
is closed.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v6 1/2] docs: s390/pci: Improve and update PCI documentation
From: Matthew Rosato @ 2026-04-02 21:43 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Jonathan Corbet, Lukas Wunner,
Shuah Khan
Cc: Farhan Ali, Alexander Gordeev, Christian Borntraeger,
Gerald Schaefer, Gerd Bayer, Heiko Carstens, Julian Ruess,
Peter Oberparleiter, Ramesh Errabolu, Sven Schnelle,
Vasily Gorbik, linux-doc, linux-kernel, linux-pci, linux-s390
In-Reply-To: <20260402-uid_slot-v6-1-d5ea0a14ddb9@linux.ibm.com>
On 4/2/26 4:34 PM, Niklas Schnelle wrote:
> Update the s390 specific PCI documentation to better reflect current
> behavior and terms such as the handling of Isolated VFs via commit
> 25f39d3dcb48 ("s390/pci: Ignore RID for isolated VFs").
>
> Add a descriptions for /sys/firmware/clp/uid_is_unique which was added
> in commit b043a81ce3ee ("s390/pci: Expose firmware provided UID Checking
> state in sysfs") but missed documentation.
>
> Similarly add documentation for the fidparm attribute added by commit
> 99ad39306a62 ("s390/pci: Expose FIDPARM attribute in sysfs") and
> add a list of pft values and their names.
>
> Finally improve formatting of the different attribute descriptions by
> adding a separating colon.
>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Definitely an improvement. Thanks!
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v3 02/24] PCI: Add API to track PCI devices preserved across Live Update
From: Yanjun.Zhu @ 2026-04-02 21:28 UTC (permalink / raw)
To: David Matlack, Alex Williamson, Bjorn Helgaas
Cc: Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Chris Li, Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan,
Jason Gunthorpe, Jason Gunthorpe, Jonathan Corbet, Josh Hilke,
Kees Cook, Kevin Tian, kexec, kvm, Leon Romanovsky,
Leon Romanovsky, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-pci, Li RongQing, Lukas Wunner, Marco Elver,
Michał Winiarski, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra (Intel), Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Rodrigo Vivi,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Vivek Kasireddy, William Tu, Yi Liu
In-Reply-To: <20260323235817.1960573-3-dmatlack@google.com>
On 3/23/26 4:57 PM, David Matlack wrote:
> Add an API to enable the PCI subsystem to participate in a Live Update
> and track all devices that are being preserved by drivers. Since this
> support is still under development, hide it behind a new Kconfig
> PCI_LIVEUPDATE that is marked experimental.
>
> This API will be used in subsequent commits by the vfio-pci driver to
> preserve VFIO devices across Live Update.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/Kconfig | 11 ++
> drivers/pci/Makefile | 1 +
> drivers/pci/liveupdate.c | 380 ++++++++++++++++++++++++++++++++++++
> drivers/pci/pci.h | 14 ++
> drivers/pci/probe.c | 2 +
> include/linux/kho/abi/pci.h | 62 ++++++
> include/linux/pci.h | 41 ++++
> 7 files changed, 511 insertions(+)
> create mode 100644 drivers/pci/liveupdate.c
> create mode 100644 include/linux/kho/abi/pci.h
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index e3f848ffb52a..05307d89c3f4 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -334,6 +334,17 @@ config VGA_ARB_MAX_GPUS
> Reserves space in the kernel to maintain resource locking for
> multiple GPUS. The overhead for each GPU is very small.
>
> +config PCI_LIVEUPDATE
> + bool "PCI Live Update Support (EXPERIMENTAL)"
> + depends on PCI && LIVEUPDATE
> + help
> + Support for preserving PCI devices across a Live Update. This option
> + should only be enabled by developers working on implementing this
> + support. Once enough support as landed in the kernel, this option
> + will no longer be marked EXPERIMENTAL.
> +
> + If unsure, say N.
Currently, it only supports 'n' or 'y'. Is it possible to add 'm'
(modular support)?
This would allow the feature to be built as a kernel module. For
development
purposes, modularization means we only need to recompile a single module
for testing, rather than rebuilding the entire kernel. Compiling a
module should
be significantly faster than a full kernel build.
Zhu Yanjun
> +
> source "drivers/pci/hotplug/Kconfig"
> source "drivers/pci/controller/Kconfig"
> source "drivers/pci/endpoint/Kconfig"
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 41ebc3b9a518..e8d003cb6757 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_PROC_FS) += proc.o
> obj-$(CONFIG_SYSFS) += pci-sysfs.o slot.o
> obj-$(CONFIG_ACPI) += pci-acpi.o
> obj-$(CONFIG_GENERIC_PCI_IOMAP) += iomap.o
> +obj-$(CONFIG_PCI_LIVEUPDATE) += liveupdate.o
> endif
>
> obj-$(CONFIG_OF) += of.o
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> new file mode 100644
> index 000000000000..bec7b3500057
> --- /dev/null
> +++ b/drivers/pci/liveupdate.c
> @@ -0,0 +1,380 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (c) 2026, Google LLC.
> + * David Matlack <dmatlack@google.com>
> + */
> +
> +/**
> + * DOC: PCI Live Update
> + *
> + * The PCI subsystem participates in the Live Update process to enable drivers
> + * to preserve their PCI devices across kexec.
> + *
> + * Device preservation across Live Update is built on top of the Live Update
> + * Orchestrator (LUO) support for file preservation across kexec. Userspace
> + * indicates that a device should be preserved by preserving the file associated
> + * with the device with ``ioctl(LIVEUPDATE_SESSION_PRESERVE_FD)``.
> + *
> + * .. note::
> + * The support for preserving PCI devices across Live Update is currently
> + * *partial* and should be considered *experimental*. It should only be
> + * used by developers working on the implementation for the time being.
> + *
> + * To enable the support, enable ``CONFIG_PCI_LIVEUPDATE``.
> + *
> + * Driver API
> + * ==========
> + *
> + * Drivers that support file-based device preservation must register their
> + * ``liveupdate_file_handler`` with the PCI subsystem by calling
> + * ``pci_liveupdate_register_flb()``. This ensures the PCI subsystem will be
> + * notified whenever a device file is preserved so that ``struct pci_ser``
> + * can be allocated to track all preserved devices. This struct is an ABI
> + * and is eventually handed off to the next kernel via Kexec-Handover (KHO).
> + *
> + * In the "outgoing" kernel (before kexec), drivers should then notify the PCI
> + * subsystem directly whenever the preservation status for a device changes:
> + *
> + * * ``pci_liveupdate_preserve(pci_dev)``: The device is being preserved.
> + *
> + * * ``pci_liveupdate_unpreserve(pci_dev)``: The device is no longer being
> + * preserved (preservation is cancelled).
> + *
> + * In the "incoming" kernel (after kexec), drivers should notify the PCI
> + * subsystem with the following calls:
> + *
> + * * ``pci_liveupdate_retrieve(pci_dev)``: The device file is being retrieved
> + * by userspace.
> + *
> + * * ``pci_liveupdate_finish(pci_dev)``: The device is done participating in
> + * Live Update. After this point the device may no longer be even associated
> + * with the same driver.
> + *
> + * Incoming/Outgoing
> + * =================
> + *
> + * The state of each device's participation in Live Update is stored in
> + * ``struct pci_dev``:
> + *
> + * * ``liveupdate_outgoing``: True if the device is being preserved in the
> + * outgoing kernel. Set in ``pci_liveupdate_preserve()`` and cleared in
> + * ``pci_liveupdate_unpreserve()``.
> + *
> + * * ``liveupdate_incoming``: True if the device is preserved in the incoming
> + * kernel. Set during probing when the device is first created and cleared
> + * in ``pci_liveupdate_finish()``.
> + *
> + * Restrictions
> + * ============
> + *
> + * Preserved devices currently have the following restrictions. Each of these
> + * may be relaxed in the future.
> + *
> + * * The device must not be a Virtual Function (VF).
> + *
> + * * The device must not be a Physical Function (PF).
> + *
> + * Preservation Behavior
> + * =====================
> + *
> + * The kernel preserves the following state for devices preserved across a Live
> + * Update:
> + *
> + * * The PCI Segment, Bus, Device, and Function numbers assigned to the device
> + * are guaranteed to remain the same across Live Update.
> + *
> + * This list will be extended in the future as new support is added.
> + *
> + * Driver Binding
> + * ==============
> + *
> + * It is the driver's responsibility for ensuring that preserved devices are not
> + * released or bound to a different driver for as long as they are preserved. In
> + * practice, this is enforced by LUO taking an extra referenced to the preserved
> + * device file for as long as it is preserved.
> + *
> + * However, there is a window of time in the incoming kernel when a device is
> + * first probed and when userspace retrieves the device file with
> + * ``LIVEUPDATE_SESSION_RETRIEVE_FD`` when the device could be bound to any
> + * driver.
> + *
> + * It is currently userspace's responsibility to ensure that the device is bound
> + * to the correct driver in this window.
> + */
> +
> +#include <linux/bsearch.h>
> +#include <linux/io.h>
> +#include <linux/kexec_handover.h>
> +#include <linux/kho/abi/pci.h>
> +#include <linux/liveupdate.h>
> +#include <linux/mutex.h>
> +#include <linux/mm.h>
> +#include <linux/pci.h>
> +#include <linux/sort.h>
> +
> +#include "pci.h"
> +
> +static DEFINE_MUTEX(pci_flb_outgoing_lock);
> +
> +static int pci_flb_preserve(struct liveupdate_flb_op_args *args)
> +{
> + struct pci_dev *dev = NULL;
> + int max_nr_devices = 0;
> + struct pci_ser *ser;
> + unsigned long size;
> +
> + /*
> + * Don't both accounting for VFs that could be created after this
> + * since preserving VFs is not supported yet. Also don't account
> + * for devices that could be hot-plugged after this since preserving
> + * hot-plugged devices across Live Update is not yet an expected
> + * use-case.
> + */
> + for_each_pci_dev(dev)
> + max_nr_devices++;
> +
> + size = struct_size_t(struct pci_ser, devices, max_nr_devices);
> +
> + ser = kho_alloc_preserve(size);
> + if (IS_ERR(ser))
> + return PTR_ERR(ser);
> +
> + ser->max_nr_devices = max_nr_devices;
> +
> + args->obj = ser;
> + args->data = virt_to_phys(ser);
> + return 0;
> +}
> +
> +static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
> +{
> + struct pci_ser *ser = args->obj;
> +
> + WARN_ON_ONCE(ser->nr_devices);
> + kho_unpreserve_free(ser);
> +}
> +
> +static int pci_flb_retrieve(struct liveupdate_flb_op_args *args)
> +{
> + args->obj = phys_to_virt(args->data);
> + return 0;
> +}
> +
> +static void pci_flb_finish(struct liveupdate_flb_op_args *args)
> +{
> + kho_restore_free(args->obj);
> +}
> +
> +static struct liveupdate_flb_ops pci_liveupdate_flb_ops = {
> + .preserve = pci_flb_preserve,
> + .unpreserve = pci_flb_unpreserve,
> + .retrieve = pci_flb_retrieve,
> + .finish = pci_flb_finish,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct liveupdate_flb pci_liveupdate_flb = {
> + .ops = &pci_liveupdate_flb_ops,
> + .compatible = PCI_LUO_FLB_COMPATIBLE,
> +};
> +
> +#define INIT_PCI_DEV_SER(_dev) { \
> + .domain = pci_domain_nr((_dev)->bus), \
> + .bdf = pci_dev_id(_dev), \
> +}
> +
> +static int pci_dev_ser_cmp(const void *__a, const void *__b)
> +{
> + const struct pci_dev_ser *a = __a, *b = __b;
> +
> + return cmp_int((u64)a->domain << 16 | a->bdf,
> + (u64)b->domain << 16 | b->bdf);
> +}
> +
> +static struct pci_dev_ser *pci_ser_find(struct pci_ser *ser,
> + struct pci_dev *dev)
> +{
> + const struct pci_dev_ser key = INIT_PCI_DEV_SER(dev);
> +
> + return bsearch(&key, ser->devices, ser->nr_devices,
> + sizeof(key), pci_dev_ser_cmp);
> +}
> +
> +static void pci_ser_delete(struct pci_ser *ser, struct pci_dev *dev)
> +{
> + struct pci_dev_ser *dev_ser;
> + int i;
> +
> + dev_ser = pci_ser_find(ser, dev);
> +
> + /*
> + * This should never happen unless there is a kernel bug or
> + * corruption that causes the state in struct pci_ser to get
> + * out of sync with struct pci_dev.
> + */
> + if (pci_WARN_ONCE(dev, !dev_ser, "Cannot find preserved device!"))
> + return;
> +
> + for (i = dev_ser - ser->devices; i < ser->nr_devices - 1; i++)
> + ser->devices[i] = ser->devices[i + 1];
> +
> + ser->nr_devices--;
> +}
> +
> +int pci_liveupdate_preserve(struct pci_dev *dev)
> +{
> + struct pci_dev_ser new = INIT_PCI_DEV_SER(dev);
> + struct pci_ser *ser;
> + int i, ret;
> +
> + /* SR-IOV is not supported yet. */
> + if (dev->is_virtfn || dev->is_physfn)
> + return -EINVAL;
> +
> + guard(mutex)(&pci_flb_outgoing_lock);
> +
> + if (dev->liveupdate_outgoing)
> + return -EBUSY;
> +
> + ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&ser);
> + if (ret)
> + return ret;
> +
> + if (ser->nr_devices == ser->max_nr_devices)
> + return -E2BIG;
> +
> + for (i = ser->nr_devices; i > 0; i--) {
> + struct pci_dev_ser *prev = &ser->devices[i - 1];
> + int cmp = pci_dev_ser_cmp(&new, prev);
> +
> + /*
> + * This should never happen unless there is a kernel bug or
> + * corruption that causes the state in struct pci_ser to get out
> + * of sync with struct pci_dev.
> + */
> + if (WARN_ON_ONCE(!cmp))
> + return -EBUSY;
> +
> + if (cmp > 0)
> + break;
> +
> + ser->devices[i] = *prev;
> + }
> +
> + ser->devices[i] = new;
> + ser->nr_devices++;
> + dev->liveupdate_outgoing = true;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_preserve);
> +
> +void pci_liveupdate_unpreserve(struct pci_dev *dev)
> +{
> + struct pci_ser *ser;
> + int ret;
> +
> + /* This should never happen unless the caller (driver) is buggy */
> + if (WARN_ON_ONCE(!dev->liveupdate_outgoing))
> + return;
> +
> + guard(mutex)(&pci_flb_outgoing_lock);
> +
> + ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&ser);
> +
> + /* This should never happen unless there is a bug in LUO */
> + if (WARN_ON_ONCE(ret))
> + return;
> +
> + pci_ser_delete(ser, dev);
> + dev->liveupdate_outgoing = false;
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
> +
> +static int pci_liveupdate_flb_get_incoming(struct pci_ser **serp)
> +{
> + int ret;
> +
> + ret = liveupdate_flb_get_incoming(&pci_liveupdate_flb, (void **)serp);
> +
> + /* Live Update is not enabled. */
> + if (ret == -EOPNOTSUPP)
> + return ret;
> +
> + /* Live Update is enabled, but there is no incoming FLB data. */
> + if (ret == -ENODATA)
> + return ret;
> +
> + /*
> + * Live Update is enabled and there is incoming FLB data, but none of it
> + * matches pci_liveupdate_flb.compatible.
> + *
> + * This could mean that no PCI FLB data was passed by the previous
> + * kernel, but it could also mean the previous kernel used a different
> + * compatibility string (i.e.a different ABI). The latter deserves at
> + * least a WARN_ON_ONCE() but it cannot be distinguished from the
> + * former.
> + */
> + if (ret == -ENOENT) {
> + pr_info_once("PCI: No incoming FLB data detected during Live Update");
> + return ret;
> + }
> +
> + /*
> + * There is incoming FLB data that matches pci_liveupdate_flb.compatible
> + * but it cannot be retrieved. Proceed with standard initialization as
> + * if there was not incoming PCI FLB data.
> + */
> + WARN_ONCE(ret, "PCI: Failed to retrieve incoming FLB data during Live Update");
> + return ret;
> +}
> +
> +u32 pci_liveupdate_incoming_nr_devices(void)
> +{
> + struct pci_ser *ser;
> +
> + if (pci_liveupdate_flb_get_incoming(&ser))
> + return 0;
> +
> + return ser->nr_devices;
> +}
> +
> +void pci_liveupdate_setup_device(struct pci_dev *dev)
> +{
> + struct pci_ser *ser;
> +
> + if (pci_liveupdate_flb_get_incoming(&ser))
> + return;
> +
> + if (!pci_ser_find(ser, dev))
> + return;
> +
> + dev->liveupdate_incoming = true;
> +}
> +
> +int pci_liveupdate_retrieve(struct pci_dev *dev)
> +{
> + if (!dev->liveupdate_incoming)
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_retrieve);
> +
> +void pci_liveupdate_finish(struct pci_dev *dev)
> +{
> + dev->liveupdate_incoming = false;
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_finish);
> +
> +int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
> +{
> + return liveupdate_register_flb(fh, &pci_liveupdate_flb);
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_register_flb);
> +
> +void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
> +{
> + liveupdate_unregister_flb(fh, &pci_liveupdate_flb);
> +}
> +EXPORT_SYMBOL_GPL(pci_liveupdate_unregister_flb);
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..979cb9921340 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -1434,4 +1434,18 @@ static inline int pci_msix_write_tph_tag(struct pci_dev *pdev, unsigned int inde
> (PCI_CONF1_ADDRESS(bus, dev, func, reg) | \
> PCI_CONF1_EXT_REG(reg))
>
> +#ifdef CONFIG_PCI_LIVEUPDATE
> +void pci_liveupdate_setup_device(struct pci_dev *dev);
> +u32 pci_liveupdate_incoming_nr_devices(void);
> +#else
> +static inline void pci_liveupdate_setup_device(struct pci_dev *dev)
> +{
> +}
> +
> +static inline u32 pci_liveupdate_incoming_nr_devices(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif /* DRIVERS_PCI_H */
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..c60222d45659 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2064,6 +2064,8 @@ int pci_setup_device(struct pci_dev *dev)
> if (pci_early_dump)
> early_dump_pci_device(dev);
>
> + pci_liveupdate_setup_device(dev);
> +
> /* Need to have dev->class ready */
> dev->cfg_size = pci_cfg_space_size(dev);
>
> diff --git a/include/linux/kho/abi/pci.h b/include/linux/kho/abi/pci.h
> new file mode 100644
> index 000000000000..7764795f6818
> --- /dev/null
> +++ b/include/linux/kho/abi/pci.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Copyright (c) 2025, Google LLC.
> + * David Matlack <dmatlack@google.com>
> + */
> +
> +#ifndef _LINUX_KHO_ABI_PCI_H
> +#define _LINUX_KHO_ABI_PCI_H
> +
> +#include <linux/bug.h>
> +#include <linux/compiler.h>
> +#include <linux/types.h>
> +
> +/**
> + * DOC: PCI File-Lifecycle Bound (FLB) Live Update ABI
> + *
> + * This header defines the ABI for preserving core PCI state across kexec using
> + * Live Update File-Lifecycle Bound (FLB) data.
> + *
> + * This interface is a contract. Any modification to any of the serialization
> + * structs defined here constitutes a breaking change. Such changes require
> + * incrementing the version number in the PCI_LUO_FLB_COMPATIBLE string.
> + */
> +
> +#define PCI_LUO_FLB_COMPATIBLE "pci-v1"
> +
> +/**
> + * struct pci_dev_ser - Serialized state about a single PCI device.
> + *
> + * @domain: The device's PCI domain number (segment).
> + * @bdf: The device's PCI bus, device, and function number.
> + * @reserved: Reserved (to naturally align struct pci_dev_ser).
> + */
> +struct pci_dev_ser {
> + u32 domain;
> + u16 bdf;
> + u16 reserved;
> +} __packed;
> +
> +/**
> + * struct pci_ser - PCI Subsystem Live Update State
> + *
> + * This struct tracks state about all devices that are being preserved across
> + * a Live Update for the next kernel.
> + *
> + * @max_nr_devices: The length of the devices[] flexible array.
> + * @nr_devices: The number of devices that were preserved.
> + * @devices: Flexible array of pci_dev_ser structs for each device. Guaranteed
> + * to be sorted ascending by domain and bdf.
> + */
> +struct pci_ser {
> + u64 max_nr_devices;
> + u64 nr_devices;
> + struct pci_dev_ser devices[];
> +} __packed;
> +
> +/* Ensure all elements of devices[] are naturally aligned. */
> +static_assert(offsetof(struct pci_ser, devices) % sizeof(unsigned long) == 0);
> +static_assert(sizeof(struct pci_dev_ser) % sizeof(unsigned long) == 0);
> +
> +#endif /* _LINUX_KHO_ABI_PCI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 1c270f1d5123..27ee9846a2fd 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -40,6 +40,7 @@
> #include <linux/resource_ext.h>
> #include <linux/msi_api.h>
> #include <uapi/linux/pci.h>
> +#include <linux/liveupdate.h>
>
> #include <linux/pci_ids.h>
>
> @@ -591,6 +592,10 @@ struct pci_dev {
> u8 tph_mode; /* TPH mode */
> u8 tph_req_type; /* TPH requester type */
> #endif
> +#ifdef CONFIG_PCI_LIVEUPDATE
> + unsigned int liveupdate_incoming:1; /* Preserved by previous kernel */
> + unsigned int liveupdate_outgoing:1; /* Preserved for next kernel */
> +#endif
> };
>
> static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
> @@ -2871,4 +2876,40 @@ void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type);
> WARN_ONCE(condition, "%s %s: " fmt, \
> dev_driver_string(&(pdev)->dev), pci_name(pdev), ##arg)
>
> +#ifdef CONFIG_PCI_LIVEUPDATE
> +int pci_liveupdate_preserve(struct pci_dev *dev);
> +void pci_liveupdate_unpreserve(struct pci_dev *dev);
> +int pci_liveupdate_retrieve(struct pci_dev *dev);
> +void pci_liveupdate_finish(struct pci_dev *dev);
> +int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh);
> +void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh);
> +#else
> +static inline int pci_liveupdate_preserve(struct pci_dev *dev)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void pci_liveupdate_unpreserve(struct pci_dev *dev)
> +{
> +}
> +
> +static inline int pci_liveupdate_retrieve(struct pci_dev *dev)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void pci_liveupdate_finish(struct pci_dev *dev)
> +{
> +}
> +
> +static inline int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
> +{
> +}
> +#endif
> +
> #endif /* LINUX_PCI_H */
^ permalink raw reply
* Re: (subset) [PATCH v10 00/30] KVM: arm64: Implement support for SME
From: Catalin Marinas @ 2026-04-02 21:12 UTC (permalink / raw)
To: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Will Deacon,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Oliver Upton,
Mark Brown
Cc: Dave Martin, Fuad Tabba, Mark Rutland, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-0-43f7683a0fb7@kernel.org>
On Fri, 06 Mar 2026 17:00:52 +0000, Mark Brown wrote:
> I've removed the RFC tag from this version of the series, but the items
> that I'm looking for feedback on remains the same:
>
> - The userspace ABI, in particular:
> - The vector length used for the SVE registers, access to the SVE
> registers and access to ZA and (if available) ZT0 depending on
> the current state of PSTATE.{SM,ZA}.
> - The use of a single finalisation for both SVE and SME.
>
> [...]
Applied to arm64 (for-next/sysreg), thanks!
[01/30] arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06
https://git.kernel.org/arm64/c/85b6f920a869
I looked to add more core arch patches but they all look like
preparation for subsequent KVM support. If the subsequent patches will
have to change following review, I couldn't figure out whether the first
3-4 patches in this series will remain the same.
--
Catalin
^ permalink raw reply
* [PATCH v6 2/2] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Niklas Schnelle @ 2026-04-02 20:34 UTC (permalink / raw)
To: Bjorn Helgaas, Jonathan Corbet, Lukas Wunner, Shuah Khan
Cc: Farhan Ali, Alexander Gordeev, Christian Borntraeger,
Gerald Schaefer, Gerd Bayer, Heiko Carstens, Julian Ruess,
Matthew Rosato, Peter Oberparleiter, Ramesh Errabolu,
Sven Schnelle, Vasily Gorbik, linux-doc, linux-kernel, linux-pci,
linux-s390, Niklas Schnelle
In-Reply-To: <20260402-uid_slot-v6-0-d5ea0a14ddb9@linux.ibm.com>
On s390, an individual PCI function can generally be identified by two
identifiers, the FID and the UID. Which identifier is used depends on
the scope and the platform configuration.
The first identifier, the FID, is always available and identifies a PCI
device uniquely within a machine. The FID may be virtualized by
hypervisors, but on the LPAR level, the machine scope makes it
impossible to create the same configuration based on FIDs on two
different LPARs of the same machine, and difficult to reuse across
machines.
Such matching LPAR configurations are useful, though, allowing
standardized setups and booting a Linux installation on different LPARs.
To this end the UID, or user-defined identifier, was introduced. While
it is only guaranteed to be unique within an LPAR and only if indicated
by firmware, it allows users to replicate PCI device setups.
On s390, which uses a machine hypervisor, a per PCI function hotplug
model is used. The shortcoming with the UID then is, that it is not
visible to the user without first attaching the PCI function and
accessing the "uid" device attribute. The FID, on the other hand, is
used as the slot name and is thus known even with the PCI function in
standby.
Remedy this shortcoming by providing the UID as an attribute on the slot
allowing the user to identify a PCI function based on the UID without
having to first attach it. Do this via a macro mechanism analogous to
what was introduced by commit 265baca69a07 ("s390/pci: Stop usurping
pdev->dev.groups") for the PCI device attributes.
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
Documentation/arch/s390/pci.rst | 7 +++++++
arch/s390/include/asm/pci.h | 4 ++++
arch/s390/pci/pci_sysfs.c | 20 ++++++++++++++++++++
drivers/pci/slot.c | 13 ++++++++++++-
4 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
index 31c24ed5506f1fc07f89821f67a814118514f441..4c0f35c8a5588eee3cf0d596e0057f24b3ed079c 100644
--- a/Documentation/arch/s390/pci.rst
+++ b/Documentation/arch/s390/pci.rst
@@ -57,6 +57,13 @@ Entries specific to zPCI functions and entries that hold zPCI information.
- /sys/bus/pci/slots/XXXXXXXX/power
+ In addition to using the FID as the name of the slot the slot directory
+ also contains the following s390 specific slot attributes.
+
+ - uid:
+ The User-defined identifier (UID) of the function which may be configured
+ by this slot. See also the corresponding attribute of the device.
+
A physical function that currently supports a virtual function cannot be
powered off until all virtual functions are removed with:
echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c0ff19dab5807c7e1aabb48a0e9436aac45ec97d..5dcf35f0f325f5f44b28109a1c8d9aef18401035 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -208,6 +208,10 @@ extern const struct attribute_group zpci_ident_attr_group;
&pfip_attr_group, \
&zpci_ident_attr_group,
+extern const struct attribute_group zpci_slot_attr_group;
+
+#define ARCH_PCI_SLOT_GROUPS (&zpci_slot_attr_group)
+
extern unsigned int s390_pci_force_floating __initdata;
extern unsigned int s390_pci_no_rid;
diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c
index c2444a23e26c4218832bb91930b5f0ffd498d28f..d98d97df792adb3c7e415a8d374cc2f3a65fbb52 100644
--- a/arch/s390/pci/pci_sysfs.c
+++ b/arch/s390/pci/pci_sysfs.c
@@ -187,6 +187,17 @@ static ssize_t index_show(struct device *dev,
}
static DEVICE_ATTR_RO(index);
+static ssize_t zpci_uid_slot_show(struct pci_slot *slot, char *buf)
+{
+ struct zpci_dev *zdev = container_of(slot->hotplug, struct zpci_dev,
+ hotplug_slot);
+
+ return sysfs_emit(buf, "0x%x\n", zdev->uid);
+}
+
+static struct pci_slot_attribute zpci_slot_attr_uid =
+ __ATTR(uid, 0444, zpci_uid_slot_show, NULL);
+
static umode_t zpci_index_is_visible(struct kobject *kobj,
struct attribute *attr, int n)
{
@@ -243,6 +254,15 @@ const struct attribute_group pfip_attr_group = {
.attrs = pfip_attrs,
};
+static struct attribute *zpci_slot_attrs[] = {
+ &zpci_slot_attr_uid.attr,
+ NULL,
+};
+
+const struct attribute_group zpci_slot_attr_group = {
+ .attrs = zpci_slot_attrs,
+};
+
static struct attribute *clp_fw_attrs[] = {
&uid_checking_attr.attr,
NULL,
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 787311614e5b6ebb39e7284f9b9f205a0a684d6d..2f8fcfbbec24e73d0bb6e40fd04c05a94f518045 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -96,7 +96,18 @@ static struct attribute *pci_slot_default_attrs[] = {
&pci_slot_attr_cur_speed.attr,
NULL,
};
-ATTRIBUTE_GROUPS(pci_slot_default);
+
+static const struct attribute_group pci_slot_default_group = {
+ .attrs = pci_slot_default_attrs,
+};
+
+static const struct attribute_group *pci_slot_default_groups[] = {
+ &pci_slot_default_group,
+#ifdef ARCH_PCI_SLOT_GROUPS
+ ARCH_PCI_SLOT_GROUPS,
+#endif
+ NULL,
+};
static const struct kobj_type pci_slot_ktype = {
.sysfs_ops = &pci_slot_sysfs_ops,
--
2.51.0
^ permalink raw reply related
* [PATCH v6 1/2] docs: s390/pci: Improve and update PCI documentation
From: Niklas Schnelle @ 2026-04-02 20:34 UTC (permalink / raw)
To: Bjorn Helgaas, Jonathan Corbet, Lukas Wunner, Shuah Khan
Cc: Farhan Ali, Alexander Gordeev, Christian Borntraeger,
Gerald Schaefer, Gerd Bayer, Heiko Carstens, Julian Ruess,
Matthew Rosato, Peter Oberparleiter, Ramesh Errabolu,
Sven Schnelle, Vasily Gorbik, linux-doc, linux-kernel, linux-pci,
linux-s390, Niklas Schnelle
In-Reply-To: <20260402-uid_slot-v6-0-d5ea0a14ddb9@linux.ibm.com>
Update the s390 specific PCI documentation to better reflect current
behavior and terms such as the handling of Isolated VFs via commit
25f39d3dcb48 ("s390/pci: Ignore RID for isolated VFs").
Add a descriptions for /sys/firmware/clp/uid_is_unique which was added
in commit b043a81ce3ee ("s390/pci: Expose firmware provided UID Checking
state in sysfs") but missed documentation.
Similarly add documentation for the fidparm attribute added by commit
99ad39306a62 ("s390/pci: Expose FIDPARM attribute in sysfs") and
add a list of pft values and their names.
Finally improve formatting of the different attribute descriptions by
adding a separating colon.
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
Documentation/arch/s390/pci.rst | 139 +++++++++++++++++++++++++++-------------
1 file changed, 94 insertions(+), 45 deletions(-)
diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
index d5755484d8e75c7bf67a350e61bbe04f0452a2fa..31c24ed5506f1fc07f89821f67a814118514f441 100644
--- a/Documentation/arch/s390/pci.rst
+++ b/Documentation/arch/s390/pci.rst
@@ -6,6 +6,7 @@ S/390 PCI
Authors:
- Pierre Morel
+ - Niklas Schnelle
Copyright, IBM Corp. 2020
@@ -27,7 +28,8 @@ Command line parameters
debugfs entries
---------------
-The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
+The S/390 debug feature (s390dbf) generates views to hold various debug results
+in sysfs directories of the form:
* /sys/kernel/debug/s390dbf/pci_*/
@@ -47,87 +49,134 @@ Sysfs entries
Entries specific to zPCI functions and entries that hold zPCI information.
-* /sys/bus/pci/slots/XXXXXXXX
+* /sys/bus/pci/slots/XXXXXXXX:
- The slot entries are set up using the function identifier (FID) of the
- PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
- with 0 padding and lower case hexadecimal digits.
+ The slot entries are set up using the function identifier (FID) of the PCI
+ function as slot name. The format depicted as XXXXXXXX above is 8 hexadecimal
+ digits with 0 padding and lower case hexadecimal digits.
- /sys/bus/pci/slots/XXXXXXXX/power
A physical function that currently supports a virtual function cannot be
powered off until all virtual functions are removed with:
- echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
+ echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
-* /sys/bus/pci/devices/XXXX:XX:XX.X/
+* /sys/bus/pci/devices/DDDD:BB:dd.f/:
- - function_id
- A zPCI function identifier that uniquely identifies the function in the Z server.
+ - function_id:
+ The zPCI function identifier (FID) is a 32 bit hexadecimal value that
+ uniquely identifies the PCI function. Unless the hypervisor provides
+ a virtual FID e.g. on KVM this identifier is unique across the machine even
+ between different partitions.
- - function_handle
- Low-level identifier used for a configured PCI function.
- It might be useful for debugging.
+ - function_handle:
+ This 32 bit hexadecimal value is a low-level identifier used for a PCI
+ function. Note that the function handle may be changed and become invalid
+ on PCI events and when enabling/disabling the PCI function.
- - pchid
- Model-dependent location of the I/O adapter.
+ - pchid:
+ This 16 bit hexadecimal value encodes a model-dependent location for
+ the PCI function.
- - pfgid
+ - pfgid:
PCI function group ID, functions that share identical functionality
use a common identifier.
A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
- - vfn
+ - vfn:
The virtual function number, from 1 to N for virtual functions,
0 for physical functions.
- - pft
- The PCI function type
+ - pft:
+ The PCI function type is an s390 specific type attribute. It indicates
+ a more general, usage oriented, type than PCI Specification
+ class/vendor/device identifiers. That is PCI functions with the same pft
+ value may be backed by different hardware implementations. At the same time
+ apart from unclassified functions (pft is 0x00) the same pft value
+ generally implies a similar usage model. At the same time the same
+ PCI hardware device may appear with different pft values when in a
+ different usage model. For example NETD and NETH VFs may be implemented
+ by the same PCI hardware device but in NETD the parent Physical Function
+ is user managed while with NETH it is platform managed.
- - port
- The port corresponds to the physical port the function is attached to.
- It also gives an indication of the physical function a virtual function
- is attached to.
+ Currently the following PFT values are defined:
- - uid
- The user identifier (UID) may be defined as part of the machine
- configuration or the z/VM or KVM guest configuration. If the accompanying
- uid_is_unique attribute is 1 the platform guarantees that the UID is unique
- within that instance and no devices with the same UID can be attached
- during the lifetime of the system.
+ - 0x00 (UNC): Unclassified
+ - 0x02 (ROCE): RoCE Express
+ - 0x05 (ISM): Internal Shared Memory
+ - 0x0a (ROC2): RoCE Express 2
+ - 0x0b (NVMe): NVMe
+ - 0x0c (NETH): Network Express hybrid
+ - 0x0d (CNW): Cloud Network Adapter
+ - 0x0f (NETD): Network Express direct
- - uid_is_unique
- Indicates whether the user identifier (UID) is guaranteed to be and remain
- unique within this Linux instance.
+ - port:
+ The port is a decimal value corresponding to the physical port the function
+ is attached to. Virtual Functions (VFs) share the port with their parent
+ Physical Function (PF). A value of 0 indicates that the port attribute is
+ not applicable for that PCI function type.
- - pfip/segmentX
+ - uid:
+ The user-defined identifier (UID) for a PCI function is a 32 bit
+ hexadecimal value. It is defined on a per instance basis as part of the
+ partition, KVM guest, or z/VM guest configuration. If UID Checking is
+ enabled the platform ensures that the UID is unique within that instance
+ and no two PCI functions with the same UID will be visible to the instance.
+
+ Independent of this guarantee and unlike the function ID (FID) the UID may
+ be the same in different partitions within the same machine. This allows to
+ create PCI configurations in multiple partitions to be identical in the
+ UID-namespace.
+
+ - uid_is_unique:
+ A 0 or 1 flag indicating whether the user-defined identifier (UID) is
+ guaranteed to be and remain unique within this Linux instance. This
+ platform feature is called UID Checking.
+
+ - pfip/segmentX:
The segments determine the isolation of a function.
They correspond to the physical path to the function.
The more the segments are different, the more the functions are isolated.
+ - fidparm:
+ Contains an 8 bit per PCI function parameter field in hexadecimal provided
+ by the platform. The meaning of this field is PCI function type specific.
+ For NETH VFs a value of 0x01 indicates that the function supports
+ promiscuous mode.
+
+* /sys/firmware/clp/uid_is_unique:
+
+ In addition to the per-device uid_is_unique attribute this presents a
+ global indication of whether UID Checking is enabled. This allows users
+ to check for UID Checking even when no PCI functions are configured.
+
Enumeration and hotplug
=======================
The PCI address consists of four parts: domain, bus, device and function,
-and is of this form: DDDD:BB:dd.f
+and is of this form: DDDD:BB:dd.f.
-* When not using multi-functions (norid is set, or the firmware does not
- support multi-functions):
+* For a PCI function for which the platform does not expose the RID, the
+ pci=norid kernel parameter is used, or a so called isolated Virtual Function
+ which does have RID information but is used without its parent Physical
+ Function being part of the same PCI configuration:
- There is only one function per domain.
- - The domain is set from the zPCI function's UID as defined during the
- LPAR creation.
+ - The domain is set from the zPCI function's UID if UID Checking is on
+ otherwise the domain ID is generated dynamically and is not stable
+ across reboots or hot plug.
-* When using multi-functions (norid parameter is not set),
- zPCI functions are addressed differently:
+* For a PCI function for which the platform exposes the RID and which
+ is not an Isolated Virtual Function:
- There is still only one bus per domain.
- - There can be up to 256 functions per bus.
+ - There can be up to 256 PCI functions per bus.
- - The domain part of the address of all functions for
- a multi-Function device is set from the zPCI function's UID as defined
- in the LPAR creation for the function zero.
+ - The domain part of the address of all functions within the same topology is
+ that of the configured PCI function with the lowest devfn within that
+ topology.
- - New functions will only be ready for use after the function zero
- (the function with devfn 0) has been enumerated.
+ - Virtual Functions generated by an SR-IOV capable Physical Function only
+ become visible once SR-IOV is enabled.
--
2.51.0
^ permalink raw reply related
* [PATCH v6 0/2] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Niklas Schnelle @ 2026-04-02 20:34 UTC (permalink / raw)
To: Bjorn Helgaas, Jonathan Corbet, Lukas Wunner, Shuah Khan
Cc: Farhan Ali, Alexander Gordeev, Christian Borntraeger,
Gerald Schaefer, Gerd Bayer, Heiko Carstens, Julian Ruess,
Matthew Rosato, Peter Oberparleiter, Ramesh Errabolu,
Sven Schnelle, Vasily Gorbik, linux-doc, linux-kernel, linux-pci,
linux-s390, Niklas Schnelle
Hi all,
Add a mechanism for architecture specific attributes on
PCI slots in order to add the user-defined ID (UID) as an s390 specific
PCI slot attribute. First though improve some issues with the s390 specific
documentation of PCI sysfs attributes noticed during development.
Also note, I considered adding the UID as a generic slot index attribute
analogous to the PCI device index attribute (SMBIOS index / s390 UID)
but decided against it as this seems rather s390 specific and having
it named UID makes things easier for users and aligns with the existing
separate uid device attribute.
Thanks,
Niklas
v5->v6:
- Add documentation cleanup patch before adding new slot attribute
- Link to v5: https://lore.kernel.org/r/20260401-uid_slot-v5-1-e73036c74bf6@linux.ibm.com
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
---
Niklas Schnelle (2):
docs: s390/pci: Improve and update PCI documentation
PCI: s390: Expose the UID as an arch specific PCI slot attribute
Documentation/arch/s390/pci.rst | 146 +++++++++++++++++++++++++++-------------
arch/s390/include/asm/pci.h | 4 ++
arch/s390/pci/pci_sysfs.c | 20 ++++++
drivers/pci/slot.c | 13 +++-
4 files changed, 137 insertions(+), 46 deletions(-)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20250923-uid_slot-e3559cf5ca30
Best regards,
--
Niklas Schnelle
^ permalink raw reply
* Re: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
From: Yosry Ahmed @ 2026-04-02 20:26 UTC (permalink / raw)
To: Jim Mattson
Cc: kernel test robot, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, kvm, linux-doc,
linux-kernel, linux-kselftest, oe-kbuild-all
In-Reply-To: <CALMp9eSO6gz4R0f1S=E-sA3YE8KE0uJ30otcGsMV1NS3ujUcNA@mail.gmail.com>
> It looks like svm.h should include x86.h.
>
> Sean: Do you want me to send a new series?
FWIW, this is the same problem as:
https://lore.kernel.org/kvm/CAO9r8zPuDcHMObfzTQVY-P0Z3kXZbw6y5KJizxvpFWXdW7uKbQ@mail.gmail.com/.
So only the first series that gets picked up will need the fixup.
^ permalink raw reply
* Re: [PATCH] Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
From: Nicolas Schier @ 2026-04-02 20:19 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jonathan Corbet, Shuah Khan, linux-kbuild, linux-doc,
linux-kernel, Alexander Coffin
In-Reply-To: <20260313-kbuild-docs-repro-builds-fdebug-prefix-map-updates-v1-1-3aeeef7fa710@kernel.org>
On Fri, 13 Mar 2026 16:37:29 -0700, Nathan Chancellor wrote:
> Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
Applied to kbuild/linux.git (kbuild-next-unstable), thanks!
[1/1] Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
https://git.kernel.org/kbuild/c/d88af9ef
Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers). Patches applied to the
kbuild-next-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-next branch in about a week if no issues are found.
Best regards,
--
Nicolas
^ permalink raw reply
* Re: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
From: Jim Mattson @ 2026-04-02 19:39 UTC (permalink / raw)
To: kernel test robot
Cc: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, kvm, linux-doc, linux-kernel, linux-kselftest,
Yosry Ahmed, oe-kbuild-all
In-Reply-To: <202603301501.N2sdlIQ9-lkp@intel.com>
On Mon, Mar 30, 2026 at 12:50 AM kernel test robot <lkp@intel.com> wrote:
>
> Hi Jim,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 3d6cdcc8883b5726513d245eef0e91cabfc397f7]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Jim-Mattson/KVM-x86-Define-KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT/20260328-110805
> base: 3d6cdcc8883b5726513d245eef0e91cabfc397f7
> patch link: https://lore.kernel.org/r/20260327234023.2659476-2-jmattson%40google.com
> patch subject: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
> config: x86_64-randconfig-016-20260330 (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-lkp@intel.com/config)
> compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202603301501.N2sdlIQ9-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> In file included from arch/x86/kvm/svm/svm_onhyperv.c:11:
> arch/x86/kvm/svm/svm.h: In function 'l2_has_separate_pat':
> >> arch/x86/kvm/svm/svm.h:626:18: error: implicit declaration of function 'kvm_check_has_quirk'; did you mean 'kvm_check_request'? [-Wimplicit-function-declaration]
> 626 | !kvm_check_has_quirk(svm->vcpu.kvm,
> | ^~~~~~~~~~~~~~~~~~~
> | kvm_check_request
> In file included from arch/x86/kvm/svm/svm_ops.h:7,
> from arch/x86/kvm/svm/svm_onhyperv.c:12:
> arch/x86/kvm/x86.h: At top level:
> >> arch/x86/kvm/x86.h:429:20: error: conflicting types for 'kvm_check_has_quirk'; have 'bool(struct kvm *, u64)' {aka '_Bool(struct kvm *, long long unsigned int)'}
> 429 | static inline bool kvm_check_has_quirk(struct kvm *kvm, u64 quirk)
> | ^~~~~~~~~~~~~~~~~~~
> arch/x86/kvm/svm/svm.h:626:18: note: previous implicit declaration of 'kvm_check_has_quirk' with type 'int()'
> 626 | !kvm_check_has_quirk(svm->vcpu.kvm,
> | ^~~~~~~~~~~~~~~~~~~
> --
It looks like svm.h should include x86.h.
Sean: Do you want me to send a new series?
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <d26e37d4-0a29-4aaf-9034-3e1cc91bc6ce@infradead.org>
On Thu, Apr 02, 2026 at 12:17:38PM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 12:03 PM, Willy Tarreau wrote:
> > Hi Randy,
> >
> > On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
> >>
> >> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> >>> A significant part of the effort of the security team consists in begging
> >>> reporters for patch proposals, or asking them to provide them in regular
> >>> format, and most of the time they're willing to provide this, they just
> >>> didn't know that it would help. So let's add a section detailing the
> >>> required and desirable contents in a security report to help reporters
> >>> write more actionable reports which do not require round trips.
> >>>
> >>> Cc: Eric Dumazet <edumazet@google.com>
> >>> Cc: Greg KH <greg@kroah.com>
> >>> Signed-off-by: Willy Tarreau <w@1wt.eu>
> >>> ---
> >>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> >>> 1 file changed, 59 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> >>> index 6937fa9fba5a..b243ac24eb12 100644
> >>> --- a/Documentation/process/security-bugs.rst
> >>> +++ b/Documentation/process/security-bugs.rst
> >>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> >>> like to know when a security bug is found so that it can be fixed and
> >>> disclosed as quickly as possible.
> >>>
> >>> +Preparing your report
> >>> +---------------------
> >>> +
> >>> +Like with any bug report, a security bug report requires a lot of analysis work
> >>> +from the developers, so the more information you can share about the issue, the
> >>> +better. Please review the procedure outlined in
> >>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
> >>
> >> Drop the single quote marks.
> >
> > I just moved this part as-is, and I've been extremely hesitant to change
> > formatting as I can't easily check the validity of the output.
> >
> >>> +information is helpful. The following information are absolutely necessary in
> >>> +**any** security bug report:
> >>> +
> >>> + * **affected kernel version range**: with no version indication, your report
> >>> + will not be processed. A significant part of reports are for bugs that
> >>> + have already been fixed, so it is extremely important that vulnerabilities
> >>> + are verified on recent versions (development tree or latest stable
> >>> + version), at least by verifying that the code has not changed since the
> >>> + version where it was detected.
> >>> +
> >>> + * **description of the problem**: a detailed description of the problem, with
> >>> + traces showing its manifestation, and why you consider that the observed
> >>> + behavior as a problem in the kernel, is necessary.
> >>> +
> >>> + * **reproducer**: developers will need to be able to reproduce the problem to
> >>> + consider a fix as effective. This includes both a way to trigger the issue
> >>> + and a way to confirm it happens. A reproducer with low complexity
> >>> + dependencies will be needed (source code, shell script, sequence of
> >>> + instructions, file-system image etc). Binary-only executables are not
> >>> + accepted. Working exploits are extremely helpful and will not be released
> >>> + without consent from the reporter, unless they are already public. By
> >>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> >>> + is not a security bug.
> >>> +
> >>> + * **conditions**: if the bug depends on certain configuration options,
> >>> + sysctls, permissions, timing, code modifications etc, these should be
> >>> + indicated.
> >>> +
> >>> +In addition, the following information are highly desirable:
> >>> +
> >>> + * **suspected location of the bug**: the file names and functions where the
> >>> + bug is suspected to be present are very important, at least to help forward
> >>> + the report to the appropriate maintainers. When not possible (for example,
> >>> + "system freezes each time I run this command"), the security team will help
> >>> + identify the source of the bug.
> >>> +
> >>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> >>> + the source code almost always have an accurate idea on how to fix it,
> >>> + because they spent a long time studying it and its implications. Proposing
> >>> + a tested fix will save maintainers a lot of time, even if the fix ends up
> >>> + not being the right one, because it helps understand the bug. When
> >>> + proposing a tested fix, please always format it in a way that can be
> >>> + immediately merged (see :doc:`regular patch submission
> >>> + <../process/submitting-patches>`). This will save some back-and-forth
> >>
> >> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> >> Is it in some other patch?
> >
> > Not sure what you mean. Is this supposed to be a sub-section and not just a
> > title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> > it appears as the title. This one was already present in the same document
> > and was moved there without a change.
>
> I see. Sorry for the noise.
No worries, I appreciate your help, the format is not trivial and mistakes
are easy!
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 19:17 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <ac69iG5fihUd82yH@1wt.eu>
On 4/2/26 12:03 PM, Willy Tarreau wrote:
> Hi Randy,
>
> On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>>
>> On 4/2/26 11:26 AM, Willy Tarreau wrote:
>>> A significant part of the effort of the security team consists in begging
>>> reporters for patch proposals, or asking them to provide them in regular
>>> format, and most of the time they're willing to provide this, they just
>>> didn't know that it would help. So let's add a section detailing the
>>> required and desirable contents in a security report to help reporters
>>> write more actionable reports which do not require round trips.
>>>
>>> Cc: Eric Dumazet <edumazet@google.com>
>>> Cc: Greg KH <greg@kroah.com>
>>> Signed-off-by: Willy Tarreau <w@1wt.eu>
>>> ---
>>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
>>> 1 file changed, 59 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
>>> index 6937fa9fba5a..b243ac24eb12 100644
>>> --- a/Documentation/process/security-bugs.rst
>>> +++ b/Documentation/process/security-bugs.rst
>>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
>>> like to know when a security bug is found so that it can be fixed and
>>> disclosed as quickly as possible.
>>>
>>> +Preparing your report
>>> +---------------------
>>> +
>>> +Like with any bug report, a security bug report requires a lot of analysis work
>>> +from the developers, so the more information you can share about the issue, the
>>> +better. Please review the procedure outlined in
>>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>>
>> Drop the single quote marks.
>
> I just moved this part as-is, and I've been extremely hesitant to change
> formatting as I can't easily check the validity of the output.
>
>>> +information is helpful. The following information are absolutely necessary in
>>> +**any** security bug report:
>>> +
>>> + * **affected kernel version range**: with no version indication, your report
>>> + will not be processed. A significant part of reports are for bugs that
>>> + have already been fixed, so it is extremely important that vulnerabilities
>>> + are verified on recent versions (development tree or latest stable
>>> + version), at least by verifying that the code has not changed since the
>>> + version where it was detected.
>>> +
>>> + * **description of the problem**: a detailed description of the problem, with
>>> + traces showing its manifestation, and why you consider that the observed
>>> + behavior as a problem in the kernel, is necessary.
>>> +
>>> + * **reproducer**: developers will need to be able to reproduce the problem to
>>> + consider a fix as effective. This includes both a way to trigger the issue
>>> + and a way to confirm it happens. A reproducer with low complexity
>>> + dependencies will be needed (source code, shell script, sequence of
>>> + instructions, file-system image etc). Binary-only executables are not
>>> + accepted. Working exploits are extremely helpful and will not be released
>>> + without consent from the reporter, unless they are already public. By
>>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
>>> + is not a security bug.
>>> +
>>> + * **conditions**: if the bug depends on certain configuration options,
>>> + sysctls, permissions, timing, code modifications etc, these should be
>>> + indicated.
>>> +
>>> +In addition, the following information are highly desirable:
>>> +
>>> + * **suspected location of the bug**: the file names and functions where the
>>> + bug is suspected to be present are very important, at least to help forward
>>> + the report to the appropriate maintainers. When not possible (for example,
>>> + "system freezes each time I run this command"), the security team will help
>>> + identify the source of the bug.
>>> +
>>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
>>> + the source code almost always have an accurate idea on how to fix it,
>>> + because they spent a long time studying it and its implications. Proposing
>>> + a tested fix will save maintainers a lot of time, even if the fix ends up
>>> + not being the right one, because it helps understand the bug. When
>>> + proposing a tested fix, please always format it in a way that can be
>>> + immediately merged (see :doc:`regular patch submission
>>> + <../process/submitting-patches>`). This will save some back-and-forth
>>
>> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
>> Is it in some other patch?
>
> Not sure what you mean. Is this supposed to be a sub-section and not just a
> title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> it appears as the title. This one was already present in the same document
> and was moved there without a change.
I see. Sorry for the noise.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-02 19:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <e9f0bbe9-fbff-45c8-af99-4c66982bd2cd@infradead.org>
On Thu, Apr 02, 2026 at 11:42:51AM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > These days, 80% of the work done by the security team consists in
> > locating the affected subsystem in a report, running get_maintainers on
> > it, forwarding the report to these persons and responding to the reporter
> > with them in Cc. This is a huge and unneeded overhead that we must try to
> > lower for a better overall efficiency. This patch adds a complete section
> > explaining how to figure the list of recipients to send the report to.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> > 1 file changed, 73 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index da7937fd59df..6937fa9fba5a 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
>
>
> > Markdown, HTML and RST formatted reports are particularly frowned upon since
> > they're quite hard to read for humans and encourage to use dedicated viewers,
> > sometimes online, which by definition is not acceptable for a confidential
> > -security report.
> > +security report. Note that some mailers tend to mangle formatting of plain
> > +text by default, please consult :doc:`the email client howto
> > +<../process/email-clients>` for more info.
>
> Just use the file name and let automarkup do its job:
>
> text by default; please consult Documentation/process/email-clients.rst
> for more information.
>
> It's also more convenient for text readers that way.
If that's supposed to work, I'm indeed all for it! I must confess that
I have not even understood the reason for "../process" when coming from
the same directory, but I just picked that from existing entries.
Thanks for your feedback, much appreciated!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:03 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <18127458-1951-4b44-bcbb-a5747a3b4b6b@infradead.org>
Hi Randy,
On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > A significant part of the effort of the security team consists in begging
> > reporters for patch proposals, or asking them to provide them in regular
> > format, and most of the time they're willing to provide this, they just
> > didn't know that it would help. So let's add a section detailing the
> > required and desirable contents in a security report to help reporters
> > write more actionable reports which do not require round trips.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> > 1 file changed, 59 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index 6937fa9fba5a..b243ac24eb12 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
> > @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> > like to know when a security bug is found so that it can be fixed and
> > disclosed as quickly as possible.
> >
> > +Preparing your report
> > +---------------------
> > +
> > +Like with any bug report, a security bug report requires a lot of analysis work
> > +from the developers, so the more information you can share about the issue, the
> > +better. Please review the procedure outlined in
> > +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>
> Drop the single quote marks.
I just moved this part as-is, and I've been extremely hesitant to change
formatting as I can't easily check the validity of the output.
> > +information is helpful. The following information are absolutely necessary in
> > +**any** security bug report:
> > +
> > + * **affected kernel version range**: with no version indication, your report
> > + will not be processed. A significant part of reports are for bugs that
> > + have already been fixed, so it is extremely important that vulnerabilities
> > + are verified on recent versions (development tree or latest stable
> > + version), at least by verifying that the code has not changed since the
> > + version where it was detected.
> > +
> > + * **description of the problem**: a detailed description of the problem, with
> > + traces showing its manifestation, and why you consider that the observed
> > + behavior as a problem in the kernel, is necessary.
> > +
> > + * **reproducer**: developers will need to be able to reproduce the problem to
> > + consider a fix as effective. This includes both a way to trigger the issue
> > + and a way to confirm it happens. A reproducer with low complexity
> > + dependencies will be needed (source code, shell script, sequence of
> > + instructions, file-system image etc). Binary-only executables are not
> > + accepted. Working exploits are extremely helpful and will not be released
> > + without consent from the reporter, unless they are already public. By
> > + definition if an issue cannot be reproduced, it is not exploitable, thus it
> > + is not a security bug.
> > +
> > + * **conditions**: if the bug depends on certain configuration options,
> > + sysctls, permissions, timing, code modifications etc, these should be
> > + indicated.
> > +
> > +In addition, the following information are highly desirable:
> > +
> > + * **suspected location of the bug**: the file names and functions where the
> > + bug is suspected to be present are very important, at least to help forward
> > + the report to the appropriate maintainers. When not possible (for example,
> > + "system freezes each time I run this command"), the security team will help
> > + identify the source of the bug.
> > +
> > + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> > + the source code almost always have an accurate idea on how to fix it,
> > + because they spent a long time studying it and its implications. Proposing
> > + a tested fix will save maintainers a lot of time, even if the fix ends up
> > + not being the right one, because it helps understand the bug. When
> > + proposing a tested fix, please always format it in a way that can be
> > + immediately merged (see :doc:`regular patch submission
> > + <../process/submitting-patches>`). This will save some back-and-forth
>
> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> Is it in some other patch?
Not sure what you mean. Is this supposed to be a sub-section and not just a
title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
it appears as the title. This one was already present in the same document
and was moved there without a change.
Thanks a lot for your help!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 18:50 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-4-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> A significant part of the effort of the security team consists in begging
> reporters for patch proposals, or asking them to provide them in regular
> format, and most of the time they're willing to provide this, they just
> didn't know that it would help. So let's add a section detailing the
> required and desirable contents in a security report to help reporters
> write more actionable reports which do not require round trips.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> 1 file changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 6937fa9fba5a..b243ac24eb12 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> like to know when a security bug is found so that it can be fixed and
> disclosed as quickly as possible.
>
> +Preparing your report
> +---------------------
> +
> +Like with any bug report, a security bug report requires a lot of analysis work
> +from the developers, so the more information you can share about the issue, the
> +better. Please review the procedure outlined in
> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
Drop the single quote marks.
> +information is helpful. The following information are absolutely necessary in
> +**any** security bug report:
> +
> + * **affected kernel version range**: with no version indication, your report
> + will not be processed. A significant part of reports are for bugs that
> + have already been fixed, so it is extremely important that vulnerabilities
> + are verified on recent versions (development tree or latest stable
> + version), at least by verifying that the code has not changed since the
> + version where it was detected.
> +
> + * **description of the problem**: a detailed description of the problem, with
> + traces showing its manifestation, and why you consider that the observed
> + behavior as a problem in the kernel, is necessary.
> +
> + * **reproducer**: developers will need to be able to reproduce the problem to
> + consider a fix as effective. This includes both a way to trigger the issue
> + and a way to confirm it happens. A reproducer with low complexity
> + dependencies will be needed (source code, shell script, sequence of
> + instructions, file-system image etc). Binary-only executables are not
> + accepted. Working exploits are extremely helpful and will not be released
> + without consent from the reporter, unless they are already public. By
> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> + is not a security bug.
> +
> + * **conditions**: if the bug depends on certain configuration options,
> + sysctls, permissions, timing, code modifications etc, these should be
> + indicated.
> +
> +In addition, the following information are highly desirable:
> +
> + * **suspected location of the bug**: the file names and functions where the
> + bug is suspected to be present are very important, at least to help forward
> + the report to the appropriate maintainers. When not possible (for example,
> + "system freezes each time I run this command"), the security team will help
> + identify the source of the bug.
> +
> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> + the source code almost always have an accurate idea on how to fix it,
> + because they spent a long time studying it and its implications. Proposing
> + a tested fix will save maintainers a lot of time, even if the fix ends up
> + not being the right one, because it helps understand the bug. When
> + proposing a tested fix, please always format it in a way that can be
> + immediately merged (see :doc:`regular patch submission
> + <../process/submitting-patches>`). This will save some back-and-forth
Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
Is it in some other patch?
> + exchanges if it is accepted, and you will be credited for finding and
> + fixing this issue. Note that in this case only a ``Signed-off-by:`` tag is
> + needed, without ``Reported-by:` when the reporter and author are the same.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Randy Dunlap @ 2026-04-02 18:42 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-3-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> These days, 80% of the work done by the security team consists in
> locating the affected subsystem in a report, running get_maintainers on
> it, forwarding the report to these persons and responding to the reporter
> with them in Cc. This is a huge and unneeded overhead that we must try to
> lower for a better overall efficiency. This patch adds a complete section
> explaining how to figure the list of recipients to send the report to.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> 1 file changed, 73 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index da7937fd59df..6937fa9fba5a 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> Markdown, HTML and RST formatted reports are particularly frowned upon since
> they're quite hard to read for humans and encourage to use dedicated viewers,
> sometimes online, which by definition is not acceptable for a confidential
> -security report.
> +security report. Note that some mailers tend to mangle formatting of plain
> +text by default, please consult :doc:`the email client howto
> +<../process/email-clients>` for more info.
Just use the file name and let automarkup do its job:
text by default; please consult Documentation/process/email-clients.rst
for more information.
It's also more convenient for text readers that way.
>
> Disclosure and embargoed information
> ------------------------------------
--
~Randy
^ permalink raw reply
* [PATCH v4 3/3] dpll: zl3073x: implement frequency monitoring
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Prathosh Satish, Shuah Khan,
Simon Horman, Vadim Fedorenko, linux-doc, linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Extract common measurement latch logic from zl3073x_ref_ffo_update()
into a new zl3073x_ref_freq_meas_latch() helper and add
zl3073x_ref_freq_meas_update() that uses it to latch and read absolute
input reference frequencies in Hz.
Add meas_freq field to struct zl3073x_ref and the corresponding
zl3073x_ref_meas_freq_get() accessor. The measured frequencies are
updated periodically alongside the existing FFO measurements.
Add freq_monitor boolean to struct zl3073x_dpll and implement the
freq_monitor_set/get device callbacks to enable/disable frequency
monitoring via the DPLL netlink interface.
Implement measured_freq_get pin callback for input pins that returns the
measured input frequency in mHz.
Reviewed-by: Petr Oros <poros@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/core.c | 88 ++++++++++++++++++++++++++-----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 +++++
4 files changed, 187 insertions(+), 17 deletions(-)
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 6363002d48d46..cb47a5db061aa 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -632,22 +632,21 @@ int zl3073x_ref_phase_offsets_update(struct zl3073x_dev *zldev, int channel)
}
/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * zl3073x_ref_freq_meas_latch - latch reference frequency measurements
* @zldev: pointer to zl3073x_dev structure
+ * @type: measurement type (ZL_REF_FREQ_MEAS_CTRL_*)
*
- * The function asks device to update fractional frequency offsets latch
- * registers the latest measured values, reads and stores them into
+ * The function waits for the previous measurement to finish, selects all
+ * references and requests a new measurement of the given type.
*
* Return: 0 on success, <0 on error
*/
static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+zl3073x_ref_freq_meas_latch(struct zl3073x_dev *zldev, u8 type)
{
- int i, rc;
+ int rc;
- /* Per datasheet we have to wait for 'ref_freq_meas_ctrl' to be zero
- * to ensure that the measured data are coherent.
- */
+ /* Wait for previous measurement to finish */
rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
ZL_REF_FREQ_MEAS_CTRL);
if (rc)
@@ -663,15 +662,64 @@ zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
if (rc)
return rc;
- /* Request frequency offset measurement */
- rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
+ /* Request measurement */
+ rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL, type);
if (rc)
return rc;
/* Wait for finish */
- rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL);
+ return zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
+ ZL_REF_FREQ_MEAS_CTRL);
+}
+
+/**
+ * zl3073x_ref_freq_meas_update - update measured input reference frequencies
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch measured input reference frequencies
+ * and stores the results in the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev, ZL_REF_FREQ_MEAS_CTRL_REF_FREQ);
+ if (rc)
+ return rc;
+
+ /* Read measured frequencies in Hz (unsigned 32-bit, LSB = 1 Hz) */
+ for (i = 0; i < ZL3073X_NUM_REFS; i++) {
+ u32 value;
+
+ rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
+ if (rc)
+ return rc;
+
+ zldev->ref[i].meas_freq = value;
+ }
+
+ return 0;
+}
+
+/**
+ * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch the latest measured fractional
+ * frequency offset values, reads and stores them into the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev,
+ ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
if (rc)
return rc;
@@ -714,6 +762,20 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
dev_warn(zldev->dev, "Failed to update phase offsets: %pe\n",
ERR_PTR(rc));
+ /* Update measured input reference frequencies if any DPLL has
+ * frequency monitoring enabled.
+ */
+ list_for_each_entry(zldpll, &zldev->dplls, list) {
+ if (zldpll->freq_monitor) {
+ rc = zl3073x_ref_freq_meas_update(zldev);
+ if (rc)
+ dev_warn(zldev->dev,
+ "Failed to update measured frequencies: %pe\n",
+ ERR_PTR(rc));
+ break;
+ }
+ }
+
/* Update references' fractional frequency offsets */
rc = zl3073x_ref_ffo_update(zldev);
if (rc)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index a29f606318f6d..d788ca45a17e5 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -39,6 +39,7 @@
* @pin_state: last saved pin state
* @phase_offset: last saved pin phase offset
* @freq_offset: last saved fractional frequency offset
+ * @measured_freq: last saved measured frequency
*/
struct zl3073x_dpll_pin {
struct list_head list;
@@ -54,6 +55,7 @@ struct zl3073x_dpll_pin {
enum dpll_pin_state pin_state;
s64 phase_offset;
s64 freq_offset;
+ u32 measured_freq;
};
/*
@@ -202,6 +204,21 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
return 0;
}
+static int
+zl3073x_dpll_input_pin_measured_freq_get(const struct dpll_pin *dpll_pin,
+ void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll_pin *pin = pin_priv;
+
+ *measured_freq = pin->measured_freq;
+ *measured_freq *= DPLL_PIN_MEASURED_FREQUENCY_DIVIDER;
+
+ return 0;
+}
+
static int
zl3073x_dpll_input_pin_frequency_get(const struct dpll_pin *dpll_pin,
void *pin_priv,
@@ -1116,6 +1133,35 @@ zl3073x_dpll_phase_offset_monitor_set(const struct dpll_device *dpll,
return 0;
}
+static int
+zl3073x_dpll_freq_monitor_get(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ if (zldpll->freq_monitor)
+ *state = DPLL_FEATURE_STATE_ENABLE;
+ else
+ *state = DPLL_FEATURE_STATE_DISABLE;
+
+ return 0;
+}
+
+static int
+zl3073x_dpll_freq_monitor_set(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ zldpll->freq_monitor = (state == DPLL_FEATURE_STATE_ENABLE);
+
+ return 0;
+}
+
static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.direction_get = zl3073x_dpll_pin_direction_get,
.esync_get = zl3073x_dpll_input_pin_esync_get,
@@ -1123,6 +1169,7 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.ffo_get = zl3073x_dpll_input_pin_ffo_get,
.frequency_get = zl3073x_dpll_input_pin_frequency_get,
.frequency_set = zl3073x_dpll_input_pin_frequency_set,
+ .measured_freq_get = zl3073x_dpll_input_pin_measured_freq_get,
.phase_offset_get = zl3073x_dpll_input_pin_phase_offset_get,
.phase_adjust_get = zl3073x_dpll_input_pin_phase_adjust_get,
.phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
@@ -1151,6 +1198,8 @@ static const struct dpll_device_ops zl3073x_dpll_device_ops = {
.phase_offset_avg_factor_set = zl3073x_dpll_phase_offset_avg_factor_set,
.phase_offset_monitor_get = zl3073x_dpll_phase_offset_monitor_get,
.phase_offset_monitor_set = zl3073x_dpll_phase_offset_monitor_set,
+ .freq_monitor_get = zl3073x_dpll_freq_monitor_get,
+ .freq_monitor_set = zl3073x_dpll_freq_monitor_set,
.supported_modes_get = zl3073x_dpll_supported_modes_get,
};
@@ -1572,6 +1621,7 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
struct zl3073x_dev *zldev = zldpll->dev;
const struct zl3073x_ref *ref;
u8 ref_id;
+ s64 ffo;
/* Get reference monitor status */
ref_id = zl3073x_input_pin_ref_get(pin->id);
@@ -1582,10 +1632,47 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
return false;
/* Compare with previous value */
- if (pin->freq_offset != ref->ffo) {
+ ffo = zl3073x_ref_ffo_get(ref);
+ if (pin->freq_offset != ffo) {
dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ref->ffo);
- pin->freq_offset = ref->ffo;
+ pin->label, pin->freq_offset, ffo);
+ pin->freq_offset = ffo;
+
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * zl3073x_dpll_pin_measured_freq_check - check for pin measured frequency
+ * change
+ * @pin: pin to check
+ *
+ * Check for the given pin's measured frequency change.
+ *
+ * Return: true on measured frequency change, false otherwise
+ */
+static bool
+zl3073x_dpll_pin_measured_freq_check(struct zl3073x_dpll_pin *pin)
+{
+ struct zl3073x_dpll *zldpll = pin->dpll;
+ struct zl3073x_dev *zldev = zldpll->dev;
+ const struct zl3073x_ref *ref;
+ u8 ref_id;
+ u32 freq;
+
+ if (!zldpll->freq_monitor)
+ return false;
+
+ ref_id = zl3073x_input_pin_ref_get(pin->id);
+ ref = zl3073x_ref_state_get(zldev, ref_id);
+
+ freq = zl3073x_ref_meas_freq_get(ref);
+ if (pin->measured_freq != freq) {
+ dev_dbg(zldev->dev, "%s measured freq changed: %u -> %u\n",
+ pin->label, pin->measured_freq, freq);
+ pin->measured_freq = freq;
return true;
}
@@ -1677,13 +1764,18 @@ zl3073x_dpll_changes_check(struct zl3073x_dpll *zldpll)
pin_changed = true;
}
- /* Check for phase offset and ffo change once per second */
+ /* Check for phase offset, ffo, and measured freq change
+ * once per second.
+ */
if (zldpll->check_count % 2 == 0) {
if (zl3073x_dpll_pin_phase_offset_check(pin))
pin_changed = true;
if (zl3073x_dpll_pin_ffo_check(pin))
pin_changed = true;
+
+ if (zl3073x_dpll_pin_measured_freq_check(pin))
+ pin_changed = true;
}
if (pin_changed)
diff --git a/drivers/dpll/zl3073x/dpll.h b/drivers/dpll/zl3073x/dpll.h
index 115ee4f67e7ab..434c32a7db123 100644
--- a/drivers/dpll/zl3073x/dpll.h
+++ b/drivers/dpll/zl3073x/dpll.h
@@ -15,6 +15,7 @@
* @id: DPLL index
* @check_count: periodic check counter
* @phase_monitor: is phase offset monitor enabled
+ * @freq_monitor: is frequency monitor enabled
* @ops: DPLL device operations for this instance
* @dpll_dev: pointer to registered DPLL device
* @tracker: tracking object for the acquired reference
@@ -28,6 +29,7 @@ struct zl3073x_dpll {
u8 id;
u8 check_count;
bool phase_monitor;
+ bool freq_monitor;
struct dpll_device_ops ops;
struct dpll_device *dpll_dev;
dpll_tracker tracker;
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 06d8d4d97ea26..be16be20dbc7e 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -23,6 +23,7 @@ struct zl3073x_dev;
* @sync_ctrl: reference sync control
* @config: reference config
* @ffo: current fractional frequency offset
+ * @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
struct zl3073x_ref {
@@ -40,6 +41,7 @@ struct zl3073x_ref {
);
struct_group(stat, /* Status */
s64 ffo;
+ u32 meas_freq;
u8 mon_status;
);
};
@@ -68,6 +70,18 @@ zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
return ref->ffo;
}
+/**
+ * zl3073x_ref_meas_freq_get - get measured input frequency
+ * @ref: pointer to ref state
+ *
+ * Return: measured input frequency in Hz
+ */
+static inline u32
+zl3073x_ref_meas_freq_get(const struct zl3073x_ref *ref)
+{
+ return ref->meas_freq;
+}
+
/**
* zl3073x_ref_freq_get - get given input reference frequency
* @ref: pointer to ref state
--
2.52.0
^ permalink raw reply related
* [PATCH v4 2/3] dpll: add frequency monitoring callback ops
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Add new callback operations for a dpll device:
- freq_monitor_get(..) - to obtain current state of frequency monitor
feature from dpll device,
- freq_monitor_set(..) - to allow feature configuration.
Add new callback operation for a dpll pin:
- measured_freq_get(..) - to obtain the measured frequency in mHz.
Obtain the feature state value using the get callback and provide it to
the user if the device driver implements callbacks. The measured_freq_get
pin callback is only invoked when the frequency monitor is enabled.
The freq_monitor_get device callback is required when measured_freq_get
is provided by the driver.
Execute the set callback upon user requests.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v3 -> v4:
- Moved freq_monitor_{g,s}et validation from netlink to pin
registration with WARN_ON (Vadim)
Changes v2 -> v3:
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
drivers/dpll/dpll_core.c | 5 ++-
drivers/dpll/dpll_netlink.c | 90 +++++++++++++++++++++++++++++++++++++
include/linux/dpll.h | 10 +++++
3 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c
index 3f54754cdec4b..cbb635db43210 100644
--- a/drivers/dpll/dpll_core.c
+++ b/drivers/dpll/dpll_core.c
@@ -876,7 +876,10 @@ dpll_pin_register(struct dpll_device *dpll, struct dpll_pin *pin,
if (WARN_ON(!ops) ||
WARN_ON(!ops->state_on_dpll_get) ||
- WARN_ON(!ops->direction_get))
+ WARN_ON(!ops->direction_get) ||
+ WARN_ON(ops->measured_freq_get &&
+ (!dpll_device_ops(dpll)->freq_monitor_get ||
+ !dpll_device_ops(dpll)->freq_monitor_set)))
return -EINVAL;
mutex_lock(&dpll_lock);
diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 83cbd64abf5a4..af7ce62ec55ca 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -175,6 +175,26 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll,
return 0;
}
+static int
+dpll_msg_add_freq_monitor(struct sk_buff *msg, struct dpll_device *dpll,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state;
+ int ret;
+
+ if (ops->freq_monitor_set && ops->freq_monitor_get) {
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (nla_put_u32(msg, DPLL_A_FREQUENCY_MONITOR, state))
+ return -EMSGSIZE;
+ }
+
+ return 0;
+}
+
static int
dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg,
struct dpll_device *dpll,
@@ -400,6 +420,38 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
ffo);
}
+static int dpll_msg_add_measured_freq(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *dev_ops = dpll_device_ops(ref->dpll);
+ const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+ struct dpll_device *dpll = ref->dpll;
+ enum dpll_feature_state state;
+ u64 measured_freq;
+ int ret;
+
+ if (!ops->measured_freq_get)
+ return 0;
+ ret = dev_ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (state == DPLL_FEATURE_STATE_DISABLE)
+ return 0;
+ ret = ops->measured_freq_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
+ dpll, dpll_priv(dpll), &measured_freq,
+ extack);
+ if (ret)
+ return ret;
+ if (nla_put_64bit(msg, DPLL_A_PIN_MEASURED_FREQUENCY,
+ sizeof(measured_freq), &measured_freq,
+ DPLL_A_PIN_PAD))
+ return -EMSGSIZE;
+
+ return 0;
+}
+
static int
dpll_msg_add_pin_freq(struct sk_buff *msg, struct dpll_pin *pin,
struct dpll_pin_ref *ref, struct netlink_ext_ack *extack)
@@ -670,6 +722,9 @@ dpll_cmd_pin_get_one(struct sk_buff *msg, struct dpll_pin *pin,
if (ret)
return ret;
ret = dpll_msg_add_ffo(msg, pin, ref, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_measured_freq(msg, pin, ref, extack);
if (ret)
return ret;
ret = dpll_msg_add_pin_esync(msg, pin, ref, extack);
@@ -722,6 +777,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct sk_buff *msg,
if (ret)
return ret;
ret = dpll_msg_add_phase_offset_avg_factor(msg, dpll, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_freq_monitor(msg, dpll, extack);
if (ret)
return ret;
@@ -948,6 +1006,32 @@ dpll_phase_offset_avg_factor_set(struct dpll_device *dpll, struct nlattr *a,
extack);
}
+static int
+dpll_freq_monitor_set(struct dpll_device *dpll, struct nlattr *a,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state = nla_get_u32(a), old_state;
+ int ret;
+
+ if (!(ops->freq_monitor_set && ops->freq_monitor_get)) {
+ NL_SET_ERR_MSG_ATTR(extack, a,
+ "dpll device not capable of frequency monitor");
+ return -EOPNOTSUPP;
+ }
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll), &old_state,
+ extack);
+ if (ret) {
+ NL_SET_ERR_MSG(extack,
+ "unable to get current state of frequency monitor");
+ return ret;
+ }
+ if (state == old_state)
+ return 0;
+
+ return ops->freq_monitor_set(dpll, dpll_priv(dpll), state, extack);
+}
+
static int
dpll_pin_freq_set(struct dpll_pin *pin, struct nlattr *a,
struct netlink_ext_ack *extack)
@@ -1878,6 +1962,12 @@ dpll_set_from_nlattr(struct dpll_device *dpll, struct genl_info *info)
if (ret)
return ret;
break;
+ case DPLL_A_FREQUENCY_MONITOR:
+ ret = dpll_freq_monitor_set(dpll, a,
+ info->extack);
+ if (ret)
+ return ret;
+ break;
}
}
diff --git a/include/linux/dpll.h b/include/linux/dpll.h
index 2ce295b46b8cd..b7277a8b484d2 100644
--- a/include/linux/dpll.h
+++ b/include/linux/dpll.h
@@ -52,6 +52,12 @@ struct dpll_device_ops {
int (*phase_offset_avg_factor_get)(const struct dpll_device *dpll,
void *dpll_priv, u32 *factor,
struct netlink_ext_ack *extack);
+ int (*freq_monitor_set)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack);
+ int (*freq_monitor_get)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack);
};
struct dpll_pin_ops {
@@ -110,6 +116,10 @@ struct dpll_pin_ops {
int (*ffo_get)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
s64 *ffo, struct netlink_ext_ack *extack);
+ int (*measured_freq_get)(const struct dpll_pin *pin, void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack);
int (*esync_set)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
u64 freq, struct netlink_ext_ack *extack);
--
2.52.0
^ permalink raw reply related
* [PATCH v4 1/3] dpll: add frequency monitoring to netlink spec
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Add DPLL_A_FREQUENCY_MONITOR device attribute to allow control over
the frequency monitor feature. The attribute uses the existing
dpll_feature_state enum (enable/disable) and is present in both
device-get reply and device-set request.
Add DPLL_A_PIN_MEASURED_FREQUENCY pin attribute to expose the measured
input frequency in millihertz (mHz). The attribute is present in the
pin-get reply. Add DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant to
allow userspace to extract integer and fractional parts.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
Documentation/driver-api/dpll.rst | 20 +++++++++++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 ++--
include/uapi/linux/dpll.h | 5 +++-
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 83118c728ed90..93c191b2d0898 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -250,6 +250,24 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Frequency monitor
+=================
+
+Some DPLL devices may offer the capability to measure the actual
+frequency of all available input pins. The attribute and current feature state
+shall be included in the response message of the ``DPLL_CMD_DEVICE_GET``
+command for supported DPLL devices. In such cases, users can also control
+the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the
+``enum dpll_feature_state`` values for the attribute.
+Once enabled the measured input frequency for each input pin shall be
+returned in the ``DPLL_A_PIN_MEASURED_FREQUENCY`` attribute. The value
+is in millihertz (mHz), using ``DPLL_PIN_MEASURED_FREQUENCY_DIVIDER``
+as the divider.
+
+ =============================== ========================
+ ``DPLL_A_FREQUENCY_MONITOR`` attr state of a feature
+ =============================== ========================
+
Embedded SYNC
=============
@@ -411,6 +429,8 @@ according to attribute purpose.
``DPLL_A_PIN_STATE`` attr state of pin on the parent
pin
``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
+ ``DPLL_A_PIN_MEASURED_FREQUENCY`` attr measured frequency of
+ an input pin in mHz
==================================== ==================================
==================================== =================================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index 3dd48a32f7837..40465a3d7fc20 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -240,6 +240,20 @@ definitions:
integer part of a measured phase offset value.
Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
fractional part of a measured phase offset value.
+ -
+ type: const
+ name: pin-measured-frequency-divider
+ value: 1000
+ doc: |
+ pin measured frequency divider allows userspace to calculate
+ a value of measured input frequency as a fractional value with
+ three digit decimal precision (millihertz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part of
+ a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part of
+ a measured frequency value.
-
type: enum
name: feature-state
@@ -319,6 +333,13 @@ attribute-sets:
name: phase-offset-avg-factor
type: u32
doc: Averaging factor applied to calculation of reported phase offset.
+ -
+ name: frequency-monitor
+ type: u32
+ enum: feature-state
+ doc: Current or desired state of the frequency monitor feature.
+ If enabled, dpll device shall measure all currently available
+ inputs for their actual input frequency.
-
name: pin
enum-name: dpll_a_pin
@@ -456,6 +477,17 @@ attribute-sets:
Value is in PPT (parts per trillion, 10^-12).
Note: This attribute provides higher resolution than the standard
fractional-frequency-offset (which is in PPM).
+ -
+ name: measured-frequency
+ type: u64
+ doc: |
+ The measured frequency of the input pin in millihertz (mHz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part (Hz)
+ of a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
+ of a measured frequency value.
-
name: pin-parent-device
@@ -544,6 +576,7 @@ operations:
- type
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
dump:
reply: *dev-attrs
@@ -563,6 +596,7 @@ operations:
- mode
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
-
name: device-create-ntf
doc: Notification about device appearing
@@ -643,6 +677,7 @@ operations:
- esync-frequency-supported
- esync-pulse
- reference-sync
+ - measured-frequency
dump:
request:
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index a2b22d4921142..1e652340a5d73 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -43,11 +43,12 @@ static const struct nla_policy dpll_device_get_nl_policy[DPLL_A_ID + 1] = {
};
/* DPLL_CMD_DEVICE_SET - do */
-static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_PHASE_OFFSET_AVG_FACTOR + 1] = {
+static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_FREQUENCY_MONITOR + 1] = {
[DPLL_A_ID] = { .type = NLA_U32, },
[DPLL_A_MODE] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
[DPLL_A_PHASE_OFFSET_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
[DPLL_A_PHASE_OFFSET_AVG_FACTOR] = { .type = NLA_U32, },
+ [DPLL_A_FREQUENCY_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
};
/* DPLL_CMD_PIN_ID_GET - do */
@@ -115,7 +116,7 @@ static const struct genl_split_ops dpll_nl_ops[] = {
.doit = dpll_nl_device_set_doit,
.post_doit = dpll_post_doit,
.policy = dpll_device_set_nl_policy,
- .maxattr = DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ .maxattr = DPLL_A_FREQUENCY_MONITOR,
.flags = GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
},
{
diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
index de0005f28e5c5..871685f7c353b 100644
--- a/include/uapi/linux/dpll.h
+++ b/include/uapi/linux/dpll.h
@@ -191,7 +191,8 @@ enum dpll_pin_capabilities {
DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE = 4,
};
-#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PIN_MEASURED_FREQUENCY_DIVIDER 1000
/**
* enum dpll_feature_state - Allow control (enable/disable) and status checking
@@ -218,6 +219,7 @@ enum dpll_a {
DPLL_A_CLOCK_QUALITY_LEVEL,
DPLL_A_PHASE_OFFSET_MONITOR,
DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ DPLL_A_FREQUENCY_MONITOR,
__DPLL_A_MAX,
DPLL_A_MAX = (__DPLL_A_MAX - 1)
@@ -254,6 +256,7 @@ enum dpll_a_pin {
DPLL_A_PIN_REFERENCE_SYNC,
DPLL_A_PIN_PHASE_ADJUST_GRAN,
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ DPLL_A_PIN_MEASURED_FREQUENCY,
__DPLL_A_PIN_MAX,
DPLL_A_PIN_MAX = (__DPLL_A_PIN_MAX - 1)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 0/3] dpll: add frequency monitoring feature
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Petr Oros, Prathosh Satish,
Shuah Khan, Simon Horman, Vadim Fedorenko, linux-doc,
linux-kernel
This series adds support for monitoring the measured input frequency
of DPLL input pins via the DPLL netlink interface.
Some DPLL devices can measure the actual frequency being received on
input pins. The approach mirrors the existing phase-offset-monitor
feature: a device-level attribute (DPLL_A_FREQUENCY_MONITOR) enables
or disables monitoring, and a per-pin attribute
(DPLL_A_PIN_MEASURED_FREQUENCY) exposes the measured frequency in
millihertz (mHz) when monitoring is enabled.
Patch 1 adds the new attributes to the DPLL netlink spec (dpll.yaml),
the DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant, regenerates the
auto-generated UAPI header and netlink policy, and updates
Documentation/driver-api/dpll.rst.
Patch 2 adds the callback operations (freq_monitor_get/set for
devices, measured_freq_get for pins) and the corresponding netlink
GET/SET handlers in the DPLL core. The core only invokes
measured_freq_get when the frequency monitor is enabled on the parent
device. The freq_monitor_get callback is required when measured_freq_get
is provided.
Patch 3 implements the feature in the ZL3073x driver by extracting
a common measurement latch helper from the existing FFO update path,
adding a frequency measurement function, and wiring up the new
callbacks.
Changes v3 -> v4:
- Moved freq_monitor_{g,s}et validation from netlink to pin
registration with WARN_ON (Vadim)
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Ivan Vecera (3):
dpll: add frequency monitoring to netlink spec
dpll: add frequency monitoring callback ops
dpll: zl3073x: implement frequency monitoring
Documentation/driver-api/dpll.rst | 20 ++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++
drivers/dpll/dpll_core.c | 5 +-
drivers/dpll/dpll_netlink.c | 90 +++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 +-
drivers/dpll/zl3073x/core.c | 88 +++++++++++++++++++----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 ++++
include/linux/dpll.h | 10 +++
include/uapi/linux/dpll.h | 5 +-
11 files changed, 353 insertions(+), 21 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v7 4/4] RISC-V: KVM: add KVM_CAP_RISCV_SET_HGATP_MODE
From: Radim Krčmář @ 2026-04-02 18:27 UTC (permalink / raw)
To: fangyu.yu, pbonzini, corbet, anup, atish.patra, pjw, palmer, aou,
alex, skhan
Cc: guoren, andrew.jones, linux-doc, kvm, kvm-riscv, linux-riscv,
linux-kernel
In-Reply-To: <20260402132303.6252-5-fangyu.yu@linux.alibaba.com>
2026-04-02T21:23:03+08:00, <fangyu.yu@linux.alibaba.com>:
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Add a VM capability that allows userspace to select the G-stage page table
> format by setting HGATP.MODE on a per-VM basis.
>
> Userspace enables the capability via KVM_ENABLE_CAP, passing the requested
> HGATP.MODE in args[0]. The request is rejected with -EINVAL if the mode is
> not supported by the host, and with -EBUSY if the VM has already been
> committed (e.g. vCPUs have been created or any memslot is populated).
>
> KVM_CHECK_EXTENSION(KVM_CAP_RISCV_SET_HGATP_MODE) returns a bitmask of the
> HGATP.MODE formats supported by the host.
>
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> ---
> diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c
> @@ -211,12 +214,23 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
> {
> + case KVM_CAP_RISCV_SET_HGATP_MODE:
> + if (!kvm_riscv_hgatp_mode_is_valid(cap->args[0]))
> + return -EINVAL;
> +
> + if (kvm->created_vcpus || !kvm_are_all_memslots_empty(kvm))
> + return -EBUSY;
Since multiple VM ioctls can execute concurrently, I would protect
created_vcpus by kvm->lock and kvm_are_all_memslots_empty by
kvm->slots_lock.
Thanks.
^ permalink raw reply
* [PATCH 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
Hi Greg,
I'm sending you the doc clarifications we discussed for the process of
reporting security issues. It's cut into the 3 patches I shared this
morning on the security list (plus two typos fixed and a paragraph
asking for one single issue per report):
- one patch that reminds our need for a valid e-mail address
- one that explains to reporters how to proceed to find maintainers
addresses, hoping we won't have to do it for 90% of reports anymore
- one that enumerates basic requirements for every report
I think it covers the difficulties we've faced this week. As always,
we might possibly find tiny adjustments to add, but my goal would be
for such updates to be merged in time to update the public page ASAP
so that we can redirect incomplete reports in an attempt to lower the
team's current load.
Thanks!
Willy
---
Willy Tarreau (3):
Documentation: minor updates to the security contacts
Documentation: explain how to find maintainers addresses for security
reports
Documentation: clarify the mandatory and desirable info for security
reports
Documentation/process/security-bugs.rst | 147 +++++++++++++++++++++---
1 file changed, 132 insertions(+), 15 deletions(-)
--
2.52.0
^ 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