* Re: [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Heiner Kallweit @ 2026-06-17 16:43 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-1-2bd38922d129@pardini.net>
On 17.06.2026 14:58, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
> controller.
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> new file mode 100644
> index 0000000000000..eee13fbc1e6a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
> + interface.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + const: pci10ec,8125
IIRC we came to the conclusion that the compatible string isn't used in the
relevant code path. Then why add it here? Is there an alignment on this?
If it should be added here, then an explaining comment would be helpful.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c8d4b913f26c1..e5fbd82946aec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 16:45 UTC (permalink / raw)
To: Fuad Tabba
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <20260617144907.2972095-1-tabba@google.com>
On Wed, 17 Jun 2026 15:49:07 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> R_VWJHB takes them from the SPSR being returned to and leaves
> PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> and PM were not applied at all.
>
> Build the PSTATE by taking those fields from the SPSR while preserving
> EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
>
> Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> This is a modified version of Marc's suggested diff [1]. That diff applied
> a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> illegal exception return. This path is reached precisely because SPSR.M is
> illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> and PAN/ALLINT/PM from the SPSR.
>
> [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> ---
> arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index dba7ced74ca5..ace2b40cf875 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> (spsr & PSR_MODE32_BIT) ||
> (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> mode == PSR_MODE_EL1h))) {
> - /*
> - * The guest is playing with our nerves. Preserve EL, SP,
> - * masks, flags from the existing PSTATE, and set IL.
> - * The HW will then generate an Illegal State Exception
> - * immediately after ERET.
> - */
> - spsr = *vcpu_cpsr(vcpu);
> + u64 cpsr = *vcpu_cpsr(vcpu);
> + u64 mask;
>
> - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> - PSR_MODE_MASK | PSR_MODE32_BIT);
> + /*
> + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> + * HW generates an Illegal State Exception right after ERET.
> + */
> + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> +
> + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> + mask |= PSR_PAN_BIT;
> + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> + mask |= ALLINT_ALLINT;
> + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> + mask |= BIT_ULL(32); /* PSTATE.PM */
> +
> + spsr &= mask;
> + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> spsr |= PSR_IL_BIT;
> }
While I'm happy that you caught the bugs I left for you to address,
the overall structure is a bit inconsistent. I'd like to have:
- a mask of the bits we preserve from SPSR, and apply that to SPSR
itself
- a mask of the bits we preserve from PSTATE, and transfer them to
SPSR
- the comment at the top to describe this in that particular order.
With that, I reworked your patch as follows:
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index bb335fa16f7cc..243e5e26f7018 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
(spsr & PSR_MODE32_BIT) ||
(vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
mode == PSR_MODE_EL1h))) {
- u64 cpsr = *vcpu_cpsr(vcpu);
u64 mask;
/*
- * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
- * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
- * and masks are taken from the SPSR (R_VWJHB). Set IL so the
- * HW generates an Illegal State Exception right after ERET.
+ * On an illegal exception return, the flags and masks are
+ * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
+ * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
+ * so the HW generates an Illegal State Exception right
+ * after ERET.
*/
mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
@@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
mask |= BIT_ULL(32); /* PSTATE.PM */
spsr &= mask;
- spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
+
+ mask = PSR_MODE_MASK | PSR_MODE32_BIT;
if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
- spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
+ mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
+
+ spsr |= *vcpu_cpsr(vcpu) & mask;
spsr |= PSR_IL_BIT;
}
Does that work for you?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets
From: Shivendra Pratap @ 2026-06-17 17:00 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Bartosz Golaszewski, Song Xue, Sebastian Reichel, Mark Rutland,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer,
Bartosz Golaszewski, Sudeep Holla
In-Reply-To: <0c6636b0-f6c7-49dc-b335-2b4fac16b848@oss.qualcomm.com>
On 29-05-2026 19:00, Shivendra Pratap wrote:
>
>
> On 14-05-2026 19:55, Shivendra Pratap wrote:
>> Userspace should be able to initiate device reboots using the various
>> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
>> patch series introduces psci-reboot-mode driver that will induce
>> command-based resets to psci driver for executing the device reset.
>>
>> The PSCI system reset calls takes two arguments: reset_type and cookie.
>> It defines predefined reset types, such as warm and cold reset, and
>> vendor-specific reset types which are SoC vendor specific. To support
>> these requirements, the reboot-mode framework is enhanced in two key
>> ways:
>
> Hi Lorenzo,
>
> Can you please review the if its aligning towards the suggestion in v20?
>
Hi Lorenzo,
Was planning to address the mfd, and other comments, for re-post. Any
feedbacks, that we should take care in next post?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Cristian Marussi @ 2026-06-17 17:11 UTC (permalink / raw)
To: Christian Brauner
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <20260617-waten-allabendlich-zueinander-93d4b1367b8c@brauner>
On Wed, Jun 17, 2026 at 02:58:09PM +0200, Christian Brauner wrote:
> On Fri, Jun 12, 2026 at 11:37:30PM +0100, Cristian Marussi wrote:
> > Hi all,
> >
Hi Christian,
thanks for having had a look at this, first of all.
A few remarks down below...
> > --------------------------------------------------------------------------------
> > [TLDR Summary]
> > This series introduces a new SCMI driver which uses a new Telemetry FS to expose
> > and configure SCMI Telemetry Data Events retrieved from the platform SCMI FW
> > at runtime. The patches carrying the new STLMFS Filesystem support are tagged
> > with 'stlmfs'.
> > --------------------------------------------------------------------------------
> >
> > the upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
> > dedicated to System Telemetry.
> >
> > In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
> > runtime the set of Telemetry Data Events (DEs) available on a specific
> > platform and provides the means to configure the set of DEs that a user is
> > interested into, while reading them back using the collection method that
> > is deeemed more suitable for the usecase at hand. (...amongst the various
> > possible collection methods allowed by SCMI specification)
> >
> > Without delving into the gory details of the whole SCMI Telemetry protocol
> > let's just say that the SCMI platform/server firmware advertises a number
> > of Telemetry Data Events, each one identified by a 32bit unique ID, and an
> > SCMI agent/client, like Linux, can discover them and read back at will the
> > associated data value in a number of ways.
> > Data collection is mainly intended to happen on demand via shared memory
> > areas exposed by the platform firmware, discovered dynamically via SCMI
> > Telemetry and accessed by Linux on-demand, but some DE can also be reported
> > via SCMI Notifications asynchronous messages or via direct dedicated
> > FastChannels (another kind of SCMI memory based access): all of this
> > underlying mechanism is anyway hidden to the user since it is mediated by
> > the kernel driver which will return the proper data value when queried.
> >
> > Anyway, the set of well-known architected DE IDs defined by the spec is
> > limited to a dozen IDs, which means that the vast majority of DE IDs are
> > customizable per-platform: as a consequence, though, the same ID, say
> > '0x1234', could represent completely different things on different systems.
> >
> > Precise definitions and semantic of such custom Data Event IDs are out of
> > the scope of the SCMI Telemetry specification and of this implementation:
> > they are supposed to be provided using some kind of JSON-like description
> > file that will have to be consumed by a userspace tool which would be
> > finally in charge of making sense of the set of available DEs.
> >
> > IOW, in turn, this means that even though the DEs enumerated via SCMI come
> > with some sort of topological and qualitative description provided by the
> > protocol (like unit of measurements, name, topology info etc), kernel-wise
> > we CANNOT be completely sure of "what is what" without being fed-back some
> > sort of information about the DEs by the afore mentioned userspace tool.
> >
> > For these reasons, currently this series does NOT attempt to register any
> > of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
> > PERF etc), simply because we cannot be sure which DE is suitable, or even
> > desirable, for a given subsystem. This also means there are NO in-kernel
> > users of these Telemetry data events as of now.
> >
> > So, while we do not exclude, for the future, to feed/register some of the
> > discovered DEs to/with some of the above mentioned Kernel subsystems, as
> > of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
> > available to userspace tools.
> >
> > In deciding which kind of interface to expose SCMI Telemetry data to a
> > user, this new SCMI Telemetry driver aims at satisfying 2 main reqs:
> >
> > - exposing an FS-based human-readable interface that can be used to
> > discover, configure and access our Telemetry data directly also from
> > the shell without special tools
> >
> > - exposing alternative machine-friendly, more-performant, binary
> > interfaces that can be used to avoid the overhead of multiple accesses
> > to the VFS and that can be more suitable to access with custom tools
> >
> > In the initial RFC posted a few months ago [1], the above was achieved
> > with a combination of a SysFS interface, for the human-readable side of
> > the story, and a classic chardev/ioctl for the plain binary access.
> >
> > Since V1, instead, we moved away from this combined approach, especially
> > away from SysFS, for the following reason:
> >
> > 1. "Abusing SysFS": SysFS is a handy way to expose device related
> > properties in a common way, using a few common helpers built on
> > kernfs; this means, though, that unfortunately in our scenario I had
> > to generate a dummy simple device for EACH SCMI Telemetry DataEvent
> > that I got to discover at runtime and attach to them, all of the
> > properties I need.
> > This by itself seemed to me abusing the SysFS framework, but, even
> > ignoring this, the impact on the system when we have to deal with
> > hundreds or tens of thousands of DEs is sensible.
> > In some test scenario I ended with 50k DE devices and half-a-millon
> > related property files ... O_o
> >
> > 2. "SysFS constraints": SysFS usage itself has its well-known constraints
> > and best practices, like the one-file/one-value rule, and due to the
> > fact that any virtual file with a complex structure or handling logic
> > is frowned upon, you can forget about IOCTLs and mmap'ing to provide
> > a more performant interface within SysFs, which is the reason why,
> > in the previous RFC, there was an additional alternative chardev
> > interface.
> > These latter limitations around the implementation of files with a
> > more complex semantic (i.e. with a broader set of file_operations)
> > derive from the underlying KernFS support, so KernFS is equally not
> > suitable as a building block for our implementation.
> >
> > 2. "Chardev limitations": Given the nature of the protocol, the hybrid
> > approach employing character devices was itself problematic: first
> > of all because there is an upper limit on the number of chardev we
> > can create, dictated by the range of available minor numbers, and
> > then because the fact itself to have to maintain 2 completely
> > different interfaces (FS + chardev) is painful.
> >
> > As a final remark, please NOTE THAT all of this is supposed to be available
> > in production systems across a number of heterogeneous platforms: for these
> > reasons the easy choice, debugFS, is NOT an option here.
> >
> > Due to the above reasoning, since V1 we opted for a new approach with the
> > proposed interfaces now based on a full fledged, unified, virtual pseudo
> > filesystem implemented from scratch, so that we can:
> >
> > - expose all the DEs property we like as before with SysFS, but without
> > any of the constraint imposed by the usage of SysFs or kernfs.
> >
> > - easily expose additional alternative views of the same set of DEs
> > using symlinking capabilities (e.g. alternative topological view)
> >
> > - additionally expose a few alternative and more performant interfaces
> > by embedding in that same FS, a few special virtual files:
> >
> > + 'control': to issue IOCTLs for quicker discovery and on-demand access
> > to data
> > + 'pipe' [TBD]: to provide a stream of events using a virtual
> > infinite-style file
> > + 'raw_<N>' [TBD]: to provide direct memory mapped access to the raw
> > SCMI Telemetry data from userspace
>
> A filsystem driver for telemetry like this is really misguided. I think
> shell access is really not an argument for adding a filesystem into the
> kernel like this. That's just not appropriate justification to push
> thousand and thousands of lines of code into the kernel.
>
> You're building completely new infrastructure. The format is whatever it
> is. If you stream it somehow just add a binary that userspace can use to
> consume or translate it. If you need a filesystem interface for
> convenience build it via FUSE on top of whatever streams that data and
> get it ouf of the kernels way.
>
...I would not say that this was the kind of feedback I was hoping for,
but I am NOT gonna argue, given that you shot down already what I thought
were all my best selling points :P
At this point my understanding is that the way forward must be to use
a custom tool to configure/extract/translate the raw Telemetry data and
move up into userspace the whole human readable FS layer via FUSE, if
really needed.
I suppose that the new kernel/user interface has to be some dedicated char
device implementing proper fops. (like I did previously in early versions
of this series and then abandoned...)
Is this you have in mind ? Dedicated character device(s) with enough fops
to be able to configure/extract Telemetry data with a custom tool ?
Should/could such a tool live in the kernel tree (tools/) at least for
ease of development/deployment ?
> You also buy into all kinds of really wonky properties. If you split it
> over multiple files you can never get a snapshot of data that is
> consistent if it's across multiple files.
There were also bulk read-all-together interfaces but it does not matter
at this point...
>
> Telemetry over a filesystem is just not a great idea. If you did it via
> sysfs I really wouldn't care because all because the infrastructure
> already exists and I couldn't be bothered if this grew yet another wart
> but as a separate massive hand-rolled pseudofs, no I'm not seeing it.
...well, I am sure Greg would have shot down the SysFS approach even
more quickly, given the amount of abuse I had to carry-on to be able
to fit my Telemetry sources on top of a zillion dummy devices created
just to be representable in SysFS; indeed I did try to use SysFS in the
initial RFC and it was also a lot of pain to play that game in my
context from the implementation point of view...
...so I thought that adopting this new unified FS approach would have
been much cleaner and acceptable upstream... :D
Thanks again,
Cristian
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Fuad Tabba @ 2026-06-17 17:19 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <86se6lru7w.wl-maz@kernel.org>
On Wed, 17 Jun 2026 at 17:45, Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 17 Jun 2026 15:49:07 +0100,
> Fuad Tabba <tabba@google.com> wrote:
> >
> > kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> > masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> > R_VWJHB takes them from the SPSR being returned to and leaves
> > PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> > and PM were not applied at all.
> >
> > Build the PSTATE by taking those fields from the SPSR while preserving
> > EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
> >
> > Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> > Suggested-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> > ---
> > This is a modified version of Marc's suggested diff [1]. That diff applied
> > a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> > (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> > illegal exception return. This path is reached precisely because SPSR.M is
> > illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> > EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> > and PAN/ALLINT/PM from the SPSR.
> >
> > [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > ---
> > arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> > 1 file changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5..ace2b40cf875 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > (spsr & PSR_MODE32_BIT) ||
> > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > mode == PSR_MODE_EL1h))) {
> > - /*
> > - * The guest is playing with our nerves. Preserve EL, SP,
> > - * masks, flags from the existing PSTATE, and set IL.
> > - * The HW will then generate an Illegal State Exception
> > - * immediately after ERET.
> > - */
> > - spsr = *vcpu_cpsr(vcpu);
> > + u64 cpsr = *vcpu_cpsr(vcpu);
> > + u64 mask;
> >
> > - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> > - PSR_MODE_MASK | PSR_MODE32_BIT);
> > + /*
> > + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > + * HW generates an Illegal State Exception right after ERET.
> > + */
> > + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > +
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> > + mask |= PSR_PAN_BIT;
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> > + mask |= ALLINT_ALLINT;
> > + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> > + mask |= BIT_ULL(32); /* PSTATE.PM */
> > +
> > + spsr &= mask;
> > + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > spsr |= PSR_IL_BIT;
> > }
>
> While I'm happy that you caught the bugs I left for you to address,
> the overall structure is a bit inconsistent. I'd like to have:
>
> - a mask of the bits we preserve from SPSR, and apply that to SPSR
> itself
>
> - a mask of the bits we preserve from PSTATE, and transfer them to
> SPSR
>
> - the comment at the top to describe this in that particular order.
>
> With that, I reworked your patch as follows:
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index bb335fa16f7cc..243e5e26f7018 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> (spsr & PSR_MODE32_BIT) ||
> (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> mode == PSR_MODE_EL1h))) {
> - u64 cpsr = *vcpu_cpsr(vcpu);
> u64 mask;
>
> /*
> - * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> - * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> - * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> - * HW generates an Illegal State Exception right after ERET.
> + * On an illegal exception return, the flags and masks are
> + * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
> + * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
> + * so the HW generates an Illegal State Exception right
> + * after ERET.
> */
> mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> @@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> mask |= BIT_ULL(32); /* PSTATE.PM */
>
> spsr &= mask;
> - spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> +
> + mask = PSR_MODE_MASK | PSR_MODE32_BIT;
> if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> - spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> + mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
> +
> + spsr |= *vcpu_cpsr(vcpu) & mask;
> spsr |= PSR_IL_BIT;
> }
>
> Does that work for you?
Yes, that's cleaner, thanks. The two-mask form (take from SPSR, then
preserve from PSTATE) reads better than my interleaved version.
Would you like me to send a v2 (which would be identical to the above?
:) ), or would you fold it in?
Cheers,
/fuad
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Oliver Upton @ 2026-06-17 17:29 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, kvmarm, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260617131237.2842619-1-tabba@google.com>
On Wed, Jun 17, 2026 at 02:12:36PM +0100, Fuad Tabba wrote:
> I have been working on KVM/arm64 for a couple of years, mostly on
> pKVM, and am currently upstreaming protected guest support, with more
> to come later. I already review KVM/arm64 patches more broadly, and
> am happy to continue doing so in an official capacity.
>
> Add myself to the KVM/arm64 reviewer list.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
Welcome to the party! Marc, I'm guessing you'll take this as a fix so
Fuad can suffer through reviews ASAP :)
Acked-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..61eb5dc2bd03 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13991,6 +13991,7 @@ F: virt/kvm/*
> KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
> M: Marc Zyngier <maz@kernel.org>
> M: Oliver Upton <oupton@kernel.org>
> +R: Fuad Tabba <tabba@google.com>
> R: Joey Gouly <joey.gouly@arm.com>
> R: Suzuki K Poulose <suzuki.poulose@arm.com>
> R: Zenghui Yu <yuzenghui@huawei.com>
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 17:32 UTC (permalink / raw)
To: Fuad Tabba
Cc: Oliver Upton, kvmarm, linux-arm-kernel, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Jintack Lim, Ganapatrao Kulkarni, Christoffer Dall, linux-kernel
In-Reply-To: <CA+EHjTyv107RDF_MG1AtqqpJsiRbFx=xbrp12TgSu_N8dS55oA@mail.gmail.com>
On Wed, 17 Jun 2026 18:19:20 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> On Wed, 17 Jun 2026 at 17:45, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 17 Jun 2026 15:49:07 +0100,
> > Fuad Tabba <tabba@google.com> wrote:
> > >
> > > kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> > > masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> > > R_VWJHB takes them from the SPSR being returned to and leaves
> > > PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> > > and PM were not applied at all.
> > >
> > > Build the PSTATE by taking those fields from the SPSR while preserving
> > > EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
> > >
> > > Fixes: 47f3a2fc765a ("KVM: arm64: nv: Support virtual EL2 exceptions")
> > > Suggested-by: Marc Zyngier <maz@kernel.org>
> > > Link: https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > > This is a modified version of Marc's suggested diff [1]. That diff applied
> > > a single mask to the incoming SPSR, which also takes PSTATE.{EL,SP,nRW}
> > > (and EXLOCK) from the SPSR. The ARM ARM leaves those fields unchanged on an
> > > illegal exception return. This path is reached precisely because SPSR.M is
> > > illegal (EL3, M[1]=1, AArch32, EL1 under TGE), so this version preserves
> > > EL/SP/nRW/EXLOCK from the current PSTATE and takes only the flags, masks
> > > and PAN/ALLINT/PM from the SPSR.
> > >
> > > [1] https://lore.kernel.org/all/86wlvxs5r0.wl-maz@kernel.org/
> > > ---
> > > arch/arm64/kvm/emulate-nested.c | 33 +++++++++++++++++++++++----------
> > > 1 file changed, 23 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > > index dba7ced74ca5..ace2b40cf875 100644
> > > --- a/arch/arm64/kvm/emulate-nested.c
> > > +++ b/arch/arm64/kvm/emulate-nested.c
> > > @@ -2738,17 +2738,30 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > > (spsr & PSR_MODE32_BIT) ||
> > > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > > mode == PSR_MODE_EL1h))) {
> > > - /*
> > > - * The guest is playing with our nerves. Preserve EL, SP,
> > > - * masks, flags from the existing PSTATE, and set IL.
> > > - * The HW will then generate an Illegal State Exception
> > > - * immediately after ERET.
> > > - */
> > > - spsr = *vcpu_cpsr(vcpu);
> > > + u64 cpsr = *vcpu_cpsr(vcpu);
> > > + u64 mask;
> > >
> > > - spsr &= (PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > > - PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT |
> > > - PSR_MODE_MASK | PSR_MODE32_BIT);
> > > + /*
> > > + * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > > + * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > > + * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > > + * HW generates an Illegal State Exception right after ERET.
> > > + */
> > > + mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > > + PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > > +
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR1_EL1, PAN, IMP))
> > > + mask |= PSR_PAN_BIT;
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, NMI, IMP))
> > > + mask |= ALLINT_ALLINT;
> > > + /* FEAT_SPE_EXC and FEAT_TRBE_EXC also gate PSTATE.PM one day... */
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64DFR1_EL1, EBEP, IMP))
> > > + mask |= BIT_ULL(32); /* PSTATE.PM */
> > > +
> > > + spsr &= mask;
> > > + spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > > + spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > > spsr |= PSR_IL_BIT;
> > > }
> >
> > While I'm happy that you caught the bugs I left for you to address,
> > the overall structure is a bit inconsistent. I'd like to have:
> >
> > - a mask of the bits we preserve from SPSR, and apply that to SPSR
> > itself
> >
> > - a mask of the bits we preserve from PSTATE, and transfer them to
> > SPSR
> >
> > - the comment at the top to describe this in that particular order.
> >
> > With that, I reworked your patch as follows:
> >
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index bb335fa16f7cc..243e5e26f7018 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2746,14 +2746,14 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > (spsr & PSR_MODE32_BIT) ||
> > (vcpu_el2_tge_is_set(vcpu) && (mode == PSR_MODE_EL1t ||
> > mode == PSR_MODE_EL1h))) {
> > - u64 cpsr = *vcpu_cpsr(vcpu);
> > u64 mask;
> >
> > /*
> > - * On an illegal exception return, PSTATE.{EL,SP,nRW} and,
> > - * if FEAT_GCS, PSTATE.EXLOCK are unchanged, while the flags
> > - * and masks are taken from the SPSR (R_VWJHB). Set IL so the
> > - * HW generates an Illegal State Exception right after ERET.
> > + * On an illegal exception return, the flags and masks are
> > + * taken from the SPSR while PSTATE.{EL,SP,nRW} and, if
> > + * FEAT_GCS, PSTATE.EXLOCK are unchanged (R_VWJHB). Set IL
> > + * so the HW generates an Illegal State Exception right
> > + * after ERET.
> > */
> > mask = PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT |
> > PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
> > @@ -2767,9 +2767,12 @@ static u64 kvm_check_illegal_exception_return(struct kvm_vcpu *vcpu, u64 spsr)
> > mask |= BIT_ULL(32); /* PSTATE.PM */
> >
> > spsr &= mask;
> > - spsr |= cpsr & (PSR_MODE_MASK | PSR_MODE32_BIT);
> > +
> > + mask = PSR_MODE_MASK | PSR_MODE32_BIT;
> > if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > - spsr |= cpsr & BIT_ULL(34); /* PSTATE.EXLOCK */
> > + mask |= BIT_ULL(34); /* PSTATE.EXLOCK */
> > +
> > + spsr |= *vcpu_cpsr(vcpu) & mask;
> > spsr |= PSR_IL_BIT;
> > }
> >
> > Does that work for you?
>
> Yes, that's cleaner, thanks. The two-mask form (take from SPSR, then
> preserve from PSTATE) reads better than my interleaved version.
>
> Would you like me to send a v2 (which would be identical to the above?
> :) ), or would you fold it in?
I've squashed that in.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v9 9/9] perf test: Add Arm CoreSight callchain test
From: James Clark @ 2026-06-17 17:35 UTC (permalink / raw)
To: Leo Yan
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, Paschalis Mpeis, Amir Ayupov
In-Reply-To: <20260617150828.GE31870@e132581.arm.com>
On 17/06/2026 4:08 pm, Leo Yan wrote:
> On Wed, Jun 17, 2026 at 01:33:22PM +0100, Coresight ML wrote:
>> On Wed, Jun 17, 2026 at 11:03:07AM +0100, James Clark wrote:
>>
>> [...]
>>
>>>> + # It is safe to use 'i3i' with a three-instruction interval, since the
>>>> + # workload is compiled with -O0.
>>>> + perf script --itrace=g16i3il64 -i "$data" > "$script"
>>>
>>> Is there a reason we don't generate callstacks on branch samples and use
>>> --itrace=g16bl64? That removes the magic number 3 and reduces the output
>>> file size and test runtime a bit.
>>
>> I checked Intel-PT which does not generate callchain and branch stack for
>> branch samples. I just keep cs-etm aligned.
>>
>> I can add callstack / branch stack for branch samples.
>
> Tried a bit for this.
>
> The branch stack is skipped due the check:
>
> if (is_bts_event(attr)) {
> perf_sample__fprintf_bts(sample, evsel, thread, al, addr_al, machine, fp);
> return;
> }
>
> For the callstack attached to branch samples, the output seems not
> directive:
>
> callchain_test 4372 [003] 75596.459422: 1 branches:
> aaaaabdb0794 print+0x8 (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb0798 print+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb07b0 foo+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> aaaaabdb07c8 main+0xc (/home/kernel/leoy/test_cs_callchain/callchain_test)
> ffff9a10225c __libc_start_call_main+0x7c (/usr/lib/aarch64-linux-gnu/libc.so.6)
> ffff9a10233c call_init+0x9c (inlined)
> ffff9a10233c __libc_start_main_impl+0x9c (inlined)
> aaaaabdb0670 _start+0x30 (/home/kernel/leoy/test_cs_callchain/callchain_test)
> ffff9a2206a0 __libc_early_init+0x100 (/usr/lib/aarch64-linux-gnu/libc.so.6)
> => aaaaabdb0768 do_svc+0x0 (/home/kernel/leoy/test_cs_callchain/callchain_test)
>
> It is hard to digest the log as it separates branch from address
> (aaaaabdb0794 print+0x8) and to address (aaaaabdb0768 do_svc+0x0),
> and put the callchain in the middle of from and to ranges.
>
> Given this is not enabled by other hardware trace (e.g., Intel-PT),
> and we need to change the common code to make it better, I'd first
> enable callchain/branch stack for instruction samples. Let's see if
> further requirement after get this done.
>
> Thanks,
> Leo
Yep that sounds ok to me
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
From: Marc Zyngier @ 2026-06-17 17:36 UTC (permalink / raw)
To: Oliver Upton, kvmarm, linux-arm-kernel, Fuad Tabba
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Jintack Lim, Ganapatrao Kulkarni,
Christoffer Dall, linux-kernel
In-Reply-To: <20260617144907.2972095-1-tabba@google.com>
On Wed, 17 Jun 2026 15:49:07 +0100, Fuad Tabba wrote:
> kvm_check_illegal_exception_return() sourced the flags {N,Z,C,V} and
> masks {D,A,I,F} of the resulting PSTATE from the current PSTATE, but
> R_VWJHB takes them from the SPSR being returned to and leaves
> PSTATE.{EL,SP,nRW} (and EXLOCK when FEAT_GCS) unchanged. PAN, ALLINT
> and PM were not applied at all.
>
> Build the PSTATE by taking those fields from the SPSR while preserving
> EL, SP, nRW and EXLOCK from the current PSTATE, then set IL.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: nv: Fix PSTATE construction on illegal exception return
commit: 0e8e955b9bcf84a70f20079390e19971fec1586d
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-06-17 17:41 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260409122110.214680-1-ayushi.makhija@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 05:51:09PM +0530, Ayushi Makhija wrote:
Here's a link to "v1":
https://lore.kernel.org/all/20260323102229.1546504-1-quic_amakhija@quicinc.com/
Which makes this v2.
You also ignored my feedback.
Thank you,
Bjorn
> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>
> Fixes: 4fca6849864d ("drm/panel: Add Novatek NT37801 panel driver")
> Signed-off-by: Ayushi Makhija <ayushi.makhija@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> index 3837f6785320..6ba4e69bf377 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
>
> vreg_l12b_1p8: ldo12 {
> regulator-name = "vreg_l12b_1p8";
> - regulator-min-microvolt = <1200000>;
> + regulator-min-microvolt = <1650000>;
> regulator-max-microvolt = <1800000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> regulator-allow-set-load;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Marc Zyngier @ 2026-06-17 17:42 UTC (permalink / raw)
To: Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, kvmarm, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajLZXw3m4QGaYeTa@kernel.org>
On Wed, 17 Jun 2026 18:29:03 +0100,
Oliver Upton <oupton@kernel.org> wrote:
>
> On Wed, Jun 17, 2026 at 02:12:36PM +0100, Fuad Tabba wrote:
> > I have been working on KVM/arm64 for a couple of years, mostly on
> > pKVM, and am currently upstreaming protected guest support, with more
> > to come later. I already review KVM/arm64 patches more broadly, and
> > am happy to continue doing so in an official capacity.
> >
> > Add myself to the KVM/arm64 reviewer list.
> >
> > Signed-off-by: Fuad Tabba <tabba@google.com>
>
> Welcome to the party! Marc, I'm guessing you'll take this as a fix so
> Fuad can suffer through reviews ASAP :)
Yup. Though it doesn't apply to the current kvmarm/fixes tree, as it
is missing Steffen who has been in the same boat since 7.1-rc4! I've
fixed that.
>
> Acked-by: Oliver Upton <oupton@kernel.org>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Marc Zyngier @ 2026-06-17 17:43 UTC (permalink / raw)
To: Oliver Upton, Fuad Tabba
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, kvmarm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617131237.2842619-1-tabba@google.com>
On Wed, 17 Jun 2026 14:12:36 +0100, Fuad Tabba wrote:
> I have been working on KVM/arm64 for a couple of years, mostly on
> pKVM, and am currently upstreaming protected guest support, with more
> to come later. I already review KVM/arm64 patches more broadly, and
> am happy to continue doing so in an official capacity.
>
> Add myself to the KVM/arm64 reviewer list.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Add Fuad Tabba as a reviewer
commit: fcda30b134d262a1b1826555352bd7349051486e
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Stefan Dösinger @ 2026-06-17 17:47 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617-tabasco-pulsate-454ed3f8f0b6@spud>
[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]
Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
Dooley:
> On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> > +F: Documentation/devicetree/zte,zx297520v3-*
>
> Sashiko complaint here looks valid.
Yes, it is valid.
It also brought up another concern in patch 12 that has an impact on this
binding:
Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
bot@kernel.org:
> issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> defined at the root level using the explicitly deprecated `regmap`
> property. --
And indeed "regmap" is deprecated and I missed it somehow. As far as I
understand, to put syscon-reboot as a child of the clock, I need to add the
simple-mfd .compatible:
Either
topclk: clock-controller@13b000 {
compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
...
syscon-reboot {
compatible = "syscon-reboot";
regmap = <&topclk>;
offset = <0x0>;
mask = <0x1>;
};
};
--- or ---
something@13b000 {
compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
ranges;
topclk: clock-controller@0 {
compatible = "zte,zx297520v3-topclk";
...
}
syscon-reboot {
compatible = "syscon-reboot";
offset = <0x0>;
mask = <0x1>;
};
};
I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
preference for the first, as it would keep all 3 clocks in the same way. If I
go for the second, the clock driver would have to query its own node and the
parent node for the regmap.
AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
have separate clock and reset nodes and bindings and skip the aux bus, but
this would not be a correct representation of how the hardware works.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH v2 1/5] media: v4l2: Add callback for show_fdinfo
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
Allow v4l2 drivers to add information in the fdinfo file matching the
opened /dev/videoX file.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
drivers/media/v4l2-core/v4l2-dev.c | 10 ++++++++++
include/media/v4l2-dev.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 6ce623a1245a..3878fa2ff73e 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -481,6 +481,15 @@ static int v4l2_release(struct inode *inode, struct file *filp)
return ret;
}
+/* Override for the show_fdinfo function */
+static void v4l2_show_fdinfo(struct seq_file *m, struct file *filp)
+{
+ struct video_device *vdev = video_devdata(filp);
+
+ if (vdev->fops->show_fdinfo)
+ vdev->fops->show_fdinfo(m, filp);
+}
+
static const struct file_operations v4l2_fops = {
.owner = THIS_MODULE,
.read = v4l2_read,
@@ -494,6 +503,7 @@ static const struct file_operations v4l2_fops = {
#endif
.release = v4l2_release,
.poll = v4l2_poll,
+ .show_fdinfo = v4l2_show_fdinfo,
};
/**
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2e0f6d2e6a78..1635ab186f21 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -212,6 +212,7 @@ struct v4l2_file_operations {
int (*mmap) (struct file *, struct vm_area_struct *);
int (*open) (struct file *);
int (*release) (struct file *);
+ void (*show_fdinfo)(struct seq_file *, struct file *);
};
/*
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/5] docs: media: add documentation for media client usage stats
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel, Christopher Healy
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
From: Christopher Healy <healych@amazon.com>
Document the media fdinfo interface for per-file-descriptor usage
statistics exposed by stateless V4L2 codec drivers via
/proc/<pid>/fdinfo/<fd>.
This interface is designed for stateless (request API based) codec
devices where the kernel driver has per-job visibility into hardware
execution. Stateful codecs cannot support all of this because their
firmware manages job scheduling opaquely.
The specification defines media- prefixed keys for engine utilization
time, and operating frequency, following the same conventions as the DRM
fdinfo mechanism documented in drm-usage-stats.rst.
More fields can be added later.
Signed-off-by: Christopher Healy <healych@amazon.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
.../userspace-api/media/drivers/index.rst | 1 +
.../media/drivers/media-usage-stats.rst | 85 ++++++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
index 02967c9b18d6..61879738836c 100644
--- a/Documentation/userspace-api/media/drivers/index.rst
+++ b/Documentation/userspace-api/media/drivers/index.rst
@@ -34,6 +34,7 @@ For more details see the file COPYING in the source distribution of Linux.
imx-uapi
mali-c55
max2175
+ media-usage-stats
npcm-video
omap3isp-uapi
thp7312
diff --git a/Documentation/userspace-api/media/drivers/media-usage-stats.rst b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
new file mode 100644
index 000000000000..d3dc07002f62
--- /dev/null
+++ b/Documentation/userspace-api/media/drivers/media-usage-stats.rst
@@ -0,0 +1,85 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _media-usage-stats:
+
+==========================
+Media client usage stats
+==========================
+
+Stateless V4L2 codec drivers can optionally expose per-file-descriptor usage
+statistics via ``/proc/<pid>/fdinfo/<fd>``. This is analogous to the DRM fdinfo
+mechanism documented in :ref:`drm-client-usage-stats`, but uses the ``media-``
+key prefix for V4L2 media devices.
+
+This interface is specific to stateless (request API based) codec devices,
+including both decoders and encoders. With stateless codecs, the kernel driver
+explicitly submits each frame to the hardware and receives a completion
+interrupt, providing a clean per-job boundary that can be attributed to the
+submitting file descriptor.
+
+Stateful codec devices cannot support this interface because their firmware
+manages job scheduling internally. The kernel driver submits bitstream data
+but has no visibility into per-frame hardware execution timing.
+
+Implementation
+==============
+
+The V4L2 core provides the plumbing: drivers implement the ``show_fdinfo``
+callback in ``struct v4l2_file_operations``, and the core wires it into the
+kernel ``struct file_operations`` so that ``/proc/<pid>/fdinfo/<fd>`` output
+includes the driver-provided keys.
+
+File format specification
+=========================
+
+- File shall contain one key value pair per one line of text.
+- Colon character (``:``) must be used to delimit keys and values.
+- All standardised keys shall be prefixed with ``media-``.
+- Driver-specific keys shall be prefixed with ``driver_name-``.
+
+Mandatory keys
+--------------
+
+- media-driver: <valstr>
+
+ String shall contain the name of the media driver.
+
+- media-type: <valstr>
+
+ String shall identify the type of media engine exposed through this file
+ descriptor. Standard values are ``decoder`` and ``encoder``.
+
+Utilization keys
+----------------
+
+- media-engine-usage: <uint> ns
+
+ Time in nanoseconds that the hardware engine spent busy processing work
+ belonging to this file descriptor. The engine being measured is identified
+ by the ``media-type`` key.
+
+ Values are not required to be constantly monotonic if it makes the driver
+ implementation easier, but are required to catch up with the previously
+ reported larger value within a reasonable period.
+
+Frequency keys
+--------------
+
+- media-maxfreq: <uint> Hz
+
+ Maximum operating frequency of the main engine clock.
+
+- media-curfreq: <uint> Hz
+
+ Current operating frequency of the main engine clock.
+
+Example output
+==============
+
+::
+
+ media-driver: hantro-vpu
+ media-type: decoder
+ media-engine-usage: 123456789 ns
+ media-maxfreq: 600000000 Hz
+ media-curfreq: 600000000 Hz
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/5] media: Add fdinfo support for v4l2 drivers
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel, Christopher Healy
fdinfo is useful to poll information from the driver.
Unlike the ftrace interface, it lets userspace tools get a snapshot of
the state of the driver at their own pace, instead of getting events for
each driver status change.
This works better to get information like HW usage time or clock
frequencies, as well as memory usage.
This patch set focuses on mem2mem drivers that are per-frame based and
an implementation is proposed for the Verisilicon Hantro and Rockchip
rkvdec drivers, limited to main clock frequency and HW usage time.
To ease support in drivers, a v4l2_stats struct is added.
It stores statistics information and provides helper functions to write
the fdinfo file in a standard way.
An example of usage of this from userspace is implemented in v4l2top:
https://github.com/cazou/v4l2top (Check the upstream branch)
checkpatch.pl warning: The 2 arguments in the show_fdinfo callback
definition are kept unnamed to match with the rest of the struct
definition.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
Changes in v2:
- Simplify key/value pairs by removing repeated <eng> suffix
- Add media type support
- Add v4l2_stats helpers
- Add support in rkvdec too
- Link to v1: https://patch.msgid.link/20260612-v4l2-add-fdinfo-v1-0-723211abc861@collabora.com
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Benjamin Gaignard <benjamin.gaignard@collabora.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
To: Detlev Casanova <detlev.casanova@collabora.com>
To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Heiko Stuebner <heiko@sntech.de>
Cc: kernel@collabora.com
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
---
Christopher Healy (2):
docs: media: add documentation for media client usage stats
media: hantro: add per-context fdinfo usage stats
Detlev Casanova (3):
media: v4l2: Add callback for show_fdinfo
media: v4l2-core: Add v4l2-stats interface
media: rkvdec: Add per-context fdinfo usage stats
.../userspace-api/media/drivers/index.rst | 1 +
.../media/drivers/media-usage-stats.rst | 85 ++++++++++++++++++++++
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 19 +++++
drivers/media/platform/rockchip/rkvdec/rkvdec.h | 1 +
drivers/media/platform/verisilicon/hantro.h | 3 +
drivers/media/platform/verisilicon/hantro_drv.c | 19 +++++
drivers/media/v4l2-core/Makefile | 2 +-
drivers/media/v4l2-core/v4l2-dev.c | 12 +++
drivers/media/v4l2-core/v4l2-fh.c | 3 +
drivers/media/v4l2-core/v4l2-stats.c | 65 +++++++++++++++++
include/media/v4l2-dev.h | 1 +
include/media/v4l2-fh.h | 2 +
include/media/v4l2-stats.h | 44 +++++++++++
13 files changed, 256 insertions(+), 1 deletion(-)
---
base-commit: 66affa37cfac0aec061cc4bcf4a065b0c52f7e19
change-id: 20260610-v4l2-add-fdinfo-a790fceab329
Best regards,
--
Detlev Casanova <detlev.casanova@collabora.com>
^ permalink raw reply
* [PATCH v2 3/5] media: v4l2-core: Add v4l2-stats interface
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
Provide helpers for media drivers to set fdinfo data and print the
key:value pairs in a standard way.
User drivers can set stats values with helpers like:
- v4l2_stats_update_hw_usage
- v4l2_stats_set_media_dev_type
And also call the show helpers from their show_fdinfo callback with:
- v4l2_stats_show -- Shows the values set previously
- v4l2_stats_show_clock -- Shows the main clock state.
The show_clock helper is used instead of updating a clock value in
v4l2_stats for the following reasons:
- Clocks are at the device level, this is not a per-fd information
- This avoids having clock references in v4l2-core
- Drivers can use different approaches to manage clocks
(e.g.: bulk_data or not: A set helper wouldn't please all drivers)
- Arguably, clocks could be exposed elsewhere (like a debugfs), but we
want something close to what DRM does and centralizing information has
its advantages for userspace tooling.
In DRM the key:value pair format for clocks is documented and each driver
can write them directly based on that.
In this case, provide a helper and document the format.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
drivers/media/v4l2-core/Makefile | 2 +-
drivers/media/v4l2-core/v4l2-dev.c | 2 ++
drivers/media/v4l2-core/v4l2-fh.c | 3 ++
drivers/media/v4l2-core/v4l2-stats.c | 65 ++++++++++++++++++++++++++++++++++++
include/media/v4l2-fh.h | 2 ++
include/media/v4l2-stats.h | 44 ++++++++++++++++++++++++
6 files changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 329f0eadce99..20e1ab74ac09 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -9,7 +9,7 @@ ccflags-y += -I$(srctree)/drivers/media/tuners
tuner-objs := tuner-core.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
- v4l2-event.o v4l2-subdev.o v4l2-common.o \
+ v4l2-event.o v4l2-subdev.o v4l2-common.o v4l2-stats.o \
v4l2-ctrls-core.o v4l2-ctrls-api.o \
v4l2-ctrls-request.o v4l2-ctrls-defs.o
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 3878fa2ff73e..3e7a6876dffd 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -486,6 +486,8 @@ static void v4l2_show_fdinfo(struct seq_file *m, struct file *filp)
{
struct video_device *vdev = video_devdata(filp);
+ seq_printf(m, "media-driver:\t%s\n", vdev->v4l2_dev->name);
+
if (vdev->fops->show_fdinfo)
vdev->fops->show_fdinfo(m, filp);
}
diff --git a/drivers/media/v4l2-core/v4l2-fh.c b/drivers/media/v4l2-core/v4l2-fh.c
index b184bed8aca9..1b655672c718 100644
--- a/drivers/media/v4l2-core/v4l2-fh.c
+++ b/drivers/media/v4l2-core/v4l2-fh.c
@@ -17,6 +17,7 @@
#include <media/v4l2-event.h>
#include <media/v4l2-ioctl.h>
#include <media/v4l2-mc.h>
+#include <media/v4l2-stats.h>
void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
{
@@ -38,6 +39,7 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
INIT_LIST_HEAD(&fh->subscribed);
fh->sequence = -1;
mutex_init(&fh->subscribe_lock);
+ v4l2_stats_init(&fh->stats);
}
EXPORT_SYMBOL_GPL(v4l2_fh_init);
@@ -88,6 +90,7 @@ void v4l2_fh_exit(struct v4l2_fh *fh)
v4l2_event_unsubscribe_all(fh);
mutex_destroy(&fh->subscribe_lock);
fh->vdev = NULL;
+ v4l2_stats_exit(&fh->stats);
}
EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/drivers/media/v4l2-core/v4l2-stats.c b/drivers/media/v4l2-core/v4l2-stats.c
new file mode 100644
index 000000000000..93e64ef2e7bb
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-stats.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * v4l2-stats.c
+ *
+ * V4L2 statistics management.
+ *
+ * Maintain a per-file handle list of statistics about the hardware and handle
+ * exposing it in the fdinfo.
+ *
+ * Copyright (C) 2026 Collabora.
+ *
+ * Contact: Detlev Casanova <detlev.casanova@collabora.com>
+ */
+
+#include <linux/types.h>
+#include <linux/seq_file.h>
+#include <linux/clk.h>
+#include <media/v4l2-stats.h>
+
+static const char * const dev_type_name[] = {
+ [MEDIA_DEV_TYPE_V4L2] = "media",
+ [MEDIA_DEV_TYPE_V4L2_STATELESS_ENCODER] = "encoder",
+ [MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER] = "decoder",
+};
+
+void v4l2_stats_init(struct v4l2_stats *stats)
+{
+ stats->hw_usage_time = 0;
+ stats->media_dev_type = MEDIA_DEV_TYPE_V4L2;
+}
+
+void v4l2_stats_exit(struct v4l2_stats *stats)
+{
+}
+
+void v4l2_stats_update_hw_usage(struct v4l2_stats *stats, u64 usage_time)
+{
+ stats->hw_usage_time += usage_time;
+}
+EXPORT_SYMBOL_GPL(v4l2_stats_update_hw_usage);
+
+void v4l2_stats_set_media_dev_type(struct v4l2_stats *stats, enum v4l2_media_dev_type type)
+{
+ if (type >= MEDIA_DEV_TYPE_COUNT)
+ return;
+
+ stats->media_dev_type = type;
+}
+EXPORT_SYMBOL_GPL(v4l2_stats_set_media_dev_type);
+
+void v4l2_stats_show(struct v4l2_stats *stats, struct seq_file *m)
+{
+ seq_printf(m, "media-type:\t%s\n", dev_type_name[stats->media_dev_type]);
+ seq_printf(m, "media-engine-usage:\t%llu ns\n", stats->hw_usage_time);
+}
+EXPORT_SYMBOL_GPL(v4l2_stats_show);
+
+void v4l2_stats_show_clock(struct seq_file *m, struct clk *clk)
+{
+ seq_printf(m, "media-maxfreq:\t%lu Hz\n",
+ clk_get_rate(clk));
+ seq_printf(m, "media-curfreq:\t%lu Hz\n",
+ clk_get_rate(clk));
+}
+EXPORT_SYMBOL_GPL(v4l2_stats_show_clock);
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
index aad4b3689d7e..ae6688722bee 100644
--- a/include/media/v4l2-fh.h
+++ b/include/media/v4l2-fh.h
@@ -17,6 +17,7 @@
#include <linux/kconfig.h>
#include <linux/list.h>
#include <linux/videodev2.h>
+#include <media/v4l2-stats.h>
struct video_device;
struct v4l2_ctrl_handler;
@@ -43,6 +44,7 @@ struct v4l2_fh {
struct list_head list;
struct video_device *vdev;
struct v4l2_ctrl_handler *ctrl_handler;
+ struct v4l2_stats stats;
enum v4l2_priority prio;
/* Events */
diff --git a/include/media/v4l2-stats.h b/include/media/v4l2-stats.h
new file mode 100644
index 000000000000..d580933c4181
--- /dev/null
+++ b/include/media/v4l2-stats.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * v4l2-stats.h
+ *
+ * V4L2 statistics management.
+ *
+ * Maintain a per-file handle list of statistics about the hardware and handle
+ * exposing it in the fdinfo.
+ *
+ * Copyright (C) 2026 Collabora.
+ *
+ * Contact: Detlev Casanova <detlev.casanova@collabora.com>
+ */
+#ifndef V4L2_STATS_H
+#define V4L2_STATS_H
+
+#include <linux/types.h>
+
+struct clk;
+struct seq_file;
+
+enum v4l2_media_dev_type {
+ MEDIA_DEV_TYPE_V4L2 = 0,
+ MEDIA_DEV_TYPE_V4L2_STATELESS_ENCODER,
+ MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER,
+
+ MEDIA_DEV_TYPE_COUNT,
+};
+
+struct v4l2_stats {
+ u64 hw_usage_time;
+ enum v4l2_media_dev_type media_dev_type;
+};
+
+void v4l2_stats_init(struct v4l2_stats *stats);
+void v4l2_stats_exit(struct v4l2_stats *stats);
+
+void v4l2_stats_update_hw_usage(struct v4l2_stats *stats, u64 usage_time);
+void v4l2_stats_set_media_dev_type(struct v4l2_stats *stats, enum v4l2_media_dev_type type);
+
+void v4l2_stats_show(struct v4l2_stats *stats, struct seq_file *m);
+void v4l2_stats_show_clock(struct seq_file *m, struct clk *clk);
+
+#endif /* V4L2_STATS_H */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 5/5] media: rkvdec: Add per-context fdinfo usage stats
From: Detlev Casanova @ 2026-06-17 18:11 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
Add per-file-descriptor hardware utilization tracking to the rkvdec
stateless codec driver, exposed via v4l2_stats.
Update the v4l2_stats instance each time a job completes with the
time it took in ns.
This enables userspace monitoring tools to compute per-process decoder
and encoder utilization. The current and max frequency keys report the
same value today since the driver lacks devfreq support, but will
diverge once DVFS is added, allowing userspace to approximate true
capacity utilization without any fdinfo code changes. A future series
can add hardware cycle counter support (via media-cycles) to v4l2_stats
for exact utilization under DVFS, with no changes to the existing uAPI.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 19 +++++++++++++++++++
drivers/media/platform/rockchip/rkvdec/rkvdec.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 1d1e9bfef8e9..929171232ccf 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -25,6 +25,7 @@
#include <linux/workqueue.h>
#include <media/v4l2-event.h>
#include <media/v4l2-mem2mem.h>
+#include <media/v4l2-stats.h>
#include <media/videobuf2-core.h>
#include <media/videobuf2-vmalloc.h>
@@ -1094,6 +1095,9 @@ static void rkvdec_job_finish(struct rkvdec_ctx *ctx,
{
struct rkvdec_dev *rkvdec = ctx->dev;
+ v4l2_stats_update_hw_usage(&ctx->fh.stats,
+ ktime_to_ns(ktime_sub(ktime_get(), ctx->start_time)));
+
pm_runtime_put_autosuspend(rkvdec->dev);
rkvdec_job_finish_no_pm(ctx, result);
}
@@ -1174,6 +1178,8 @@ static void rkvdec_device_run(void *priv)
return;
}
+ ctx->start_time = ktime_get();
+
ret = desc->ops->run(ctx);
if (ret)
rkvdec_job_finish(ctx, VB2_BUF_STATE_ERROR);
@@ -1304,6 +1310,8 @@ static int rkvdec_open(struct file *filp)
v4l2_fh_add(&ctx->fh, filp);
+ v4l2_stats_set_media_dev_type(&ctx->fh.stats, MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER);
+
return 0;
err_cleanup_m2m_ctx:
@@ -1327,10 +1335,21 @@ static int rkvdec_release(struct file *filp)
return 0;
}
+static void rkvdec_show_fdinfo(struct seq_file *m, struct file *file)
+{
+ struct rkvdec_ctx *ctx = file_to_rkvdec_ctx(file);
+ struct rkvdec_dev *rkvdec = ctx->dev;
+
+ v4l2_stats_show(&ctx->fh.stats, m);
+
+ v4l2_stats_show_clock(m, rkvdec->axi_clk);
+}
+
static const struct v4l2_file_operations rkvdec_fops = {
.owner = THIS_MODULE,
.open = rkvdec_open,
.release = rkvdec_release,
+ .show_fdinfo = rkvdec_show_fdinfo,
.poll = v4l2_m2m_fop_poll,
.unlocked_ioctl = video_ioctl2,
.mmap = v4l2_m2m_fop_mmap,
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.h b/drivers/media/platform/rockchip/rkvdec/rkvdec.h
index a24be6638b6b..590e213bd800 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.h
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.h
@@ -157,6 +157,7 @@ struct rkvdec_ctx {
void *priv;
u8 has_sps_st_rps: 1;
u8 has_sps_lt_rps: 1;
+ ktime_t start_time;
};
static inline struct rkvdec_ctx *file_to_rkvdec_ctx(struct file *filp)
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] media: hantro: add per-context fdinfo usage stats
From: Detlev Casanova @ 2026-06-17 18:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nicolas Dufresne, Benjamin Gaignard,
Philipp Zabel, Ezequiel Garcia, Heiko Stuebner
Cc: linux-media, linux-kernel, linux-rockchip, kernel,
Detlev Casanova, linux-arm-kernel, Christopher Healy
In-Reply-To: <20260617-v4l2-add-fdinfo-v2-0-d298e98ce06a@collabora.com>
From: Christopher Healy <healych@amazon.com>
Add per-file-descriptor hardware utilization tracking to the Hantro
VPU stateless codec driver, exposed via v4l2_stats.
Update the v4l2_stats instance each time a job completes with the
time it took in ns.
This enables userspace monitoring tools to compute per-process decoder
and encoder utilization. The current and max frequency keys report the
same value today since the driver lacks devfreq support, but will
diverge once DVFS is added, allowing userspace to approximate true
capacity utilization without any fdinfo code changes. A future series
can add hardware cycle counter support (via media-cycles) to v4l2_stats
for exact utilization under DVFS, with no changes to the existing uAPI.
Signed-off-by: Christopher Healy <healych@amazon.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
drivers/media/platform/verisilicon/hantro.h | 3 +++
drivers/media/platform/verisilicon/hantro_drv.c | 19 +++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/drivers/media/platform/verisilicon/hantro.h b/drivers/media/platform/verisilicon/hantro.h
index 0353de154a1e..37fd13cc7afa 100644
--- a/drivers/media/platform/verisilicon/hantro.h
+++ b/drivers/media/platform/verisilicon/hantro.h
@@ -16,6 +16,7 @@
#include <linux/videodev2.h>
#include <linux/wait.h>
#include <linux/clk.h>
+#include <linux/ktime.h>
#include <linux/reset.h>
#include <media/v4l2-ctrls.h>
@@ -268,6 +269,8 @@ struct hantro_ctx {
struct hantro_postproc_ctx postproc;
bool need_postproc;
+ ktime_t start_time;
+
/* Specific for particular codec modes. */
union {
struct hantro_h264_dec_hw_ctx h264_dec;
diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
index 2e81877f640f..3b837ef0f3bc 100644
--- a/drivers/media/platform/verisilicon/hantro_drv.c
+++ b/drivers/media/platform/verisilicon/hantro_drv.c
@@ -21,6 +21,7 @@
#include <linux/videodev2.h>
#include <linux/workqueue.h>
#include <media/v4l2-event.h>
+#include <media/v4l2-stats.h>
#include <media/v4l2-mem2mem.h>
#include <media/videobuf2-core.h>
#include <media/videobuf2-vmalloc.h>
@@ -90,6 +91,9 @@ static void hantro_job_finish(struct hantro_dev *vpu,
struct hantro_ctx *ctx,
enum vb2_buffer_state result)
{
+ v4l2_stats_update_hw_usage(&ctx->fh.stats,
+ ktime_to_ns(ktime_sub(ktime_get(), ctx->start_time)));
+
pm_runtime_put_autosuspend(vpu->dev);
clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
@@ -186,6 +190,8 @@ static void device_run(void *priv)
v4l2_m2m_buf_copy_metadata(src, dst);
+ ctx->start_time = ktime_get();
+
if (ctx->codec_ops->run(ctx))
goto err_cancel_job;
@@ -664,6 +670,9 @@ static int hantro_open(struct file *filp)
v4l2_fh_init(&ctx->fh, vdev);
v4l2_fh_add(&ctx->fh, filp);
+ v4l2_stats_set_media_dev_type(&ctx->fh.stats,
+ ctx->is_encoder ? MEDIA_DEV_TYPE_V4L2_STATELESS_ENCODER
+ : MEDIA_DEV_TYPE_V4L2_STATELESS_DECODER);
hantro_reset_fmts(ctx);
@@ -701,10 +710,20 @@ static int hantro_release(struct file *filp)
return 0;
}
+static void hantro_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct hantro_ctx *ctx = file_to_ctx(f);
+ struct hantro_dev *vpu = ctx->dev;
+
+ v4l2_stats_show(&ctx->fh.stats, m);
+ v4l2_stats_show_clock(m, vpu->clocks[0].clk);
+}
+
static const struct v4l2_file_operations hantro_fops = {
.owner = THIS_MODULE,
.open = hantro_open,
.release = hantro_release,
+ .show_fdinfo = hantro_show_fdinfo,
.poll = v4l2_m2m_fop_poll,
.unlocked_ioctl = video_ioctl2,
.mmap = v4l2_m2m_fop_mmap,
--
2.54.0
^ permalink raw reply related
* [PATCH] memory: stm32_omm: initialize ret in stm32_omm_set_amcr
From: Ruoyu Wang @ 2026-06-17 18:22 UTC (permalink / raw)
To: Patrice Chotard, Krzysztof Kozlowski, Maxime Coquelin,
Alexandre Torgue, linux-kernel, linux-stm32, linux-arm-kernel
stm32_omm_set_amcr() returns ret after checking whether the AMCR value
matches the device tree description. On the normal matching path ret is
not otherwise assigned, so initialize it to 0 before the checks.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/memory/stm32_omm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/stm32_omm.c b/drivers/memory/stm32_omm.c
index 5d06623f3f689..2a1af229d2444 100644
--- a/drivers/memory/stm32_omm.c
+++ b/drivers/memory/stm32_omm.c
@@ -47,7 +47,7 @@ static int stm32_omm_set_amcr(struct device *dev, bool set)
struct device_node *node;
struct resource res, res1;
unsigned int syscon_args[2];
- int ret, idx;
+ int ret = 0, idx;
unsigned int i, amcr, read_amcr;
for (i = 0; i < omm->nb_child; i++) {
--
2.51.0
^ permalink raw reply related
* Re: [GIT PULL 1/4] soc: devicetree updates for 7.2
From: pr-tracker-bot @ 2026-06-17 18:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, soc, linux-arm-kernel, Krzysztof Kozlowski,
Linus Walleij, linux-kernel
In-Reply-To: <ef5fa237-1d2f-4c1d-8940-0e8c6c156759@app.fastmail.com>
The pull request you sent on Tue, 16 Jun 2026 09:51:35 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-dt-7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aab799b1bdd1ff3e6912f96e66c910b8a5d011bb
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 0/4] soc: defconfig updates for 7.2
From: pr-tracker-bot @ 2026-06-17 18:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, soc, linux-arm-kernel, Krzysztof Kozlowski,
Linus Walleij, linux-kernel
In-Reply-To: <287ca074-9329-4a51-a5f7-35abc0d977f7@app.fastmail.com>
The pull request you sent on Tue, 16 Jun 2026 09:53:53 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-defconfig-7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/61cf9588108762323c4c186f94a0c6e7ce5cb9f6
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 2/4] soc: drivers for 7.2
From: pr-tracker-bot @ 2026-06-17 18:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, soc, linux-arm-kernel, Krzysztof Kozlowski,
Linus Walleij, Marek Vasut, linux-kernel
In-Reply-To: <528465a7-4ffb-45ed-82e4-898b01d2da98@app.fastmail.com>
The pull request you sent on Tue, 16 Jun 2026 09:53:00 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-drivers-7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70cb95c736807da2c4952423c9f9afe470341996
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 4/4] soc: arm code changes for 7.2
From: pr-tracker-bot @ 2026-06-17 18:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, soc, linux-arm-kernel, Krzysztof Kozlowski,
Linus Walleij, linux-kernel
In-Reply-To: <c00cadd6-b8ae-4d09-bcdf-adbeab2f0e11@app.fastmail.com>
The pull request you sent on Tue, 16 Jun 2026 09:55:00 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-arm-7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6505114e82e7541414b176b5da4a3c015a1214ea
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH] nvmem: rockchip-otp: initialize ret in rk3588_otp_read
From: Ruoyu Wang @ 2026-06-17 18:38 UTC (permalink / raw)
To: Srinivas Kandagatla, Heiko Stuebner, linux-arm-kernel,
linux-rockchip, linux-kernel
rk3588_otp_read() returns ret after a count-controlled loop. If count is
zero, the loop is skipped and ret is not assigned. Initialize ret to 0
for the empty read path.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/nvmem/rockchip-otp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvmem/rockchip-otp.c b/drivers/nvmem/rockchip-otp.c
index 0ec78b5e19e7d..50a19b6dc4027 100644
--- a/drivers/nvmem/rockchip-otp.c
+++ b/drivers/nvmem/rockchip-otp.c
@@ -242,7 +242,7 @@ static int rk3588_otp_read(void *context, unsigned int offset,
{
struct rockchip_otp *otp = context;
u32 *buf = val;
- int ret;
+ int ret = 0;
while (count--) {
writel((offset++ << RK3588_ADDR_SHIFT) |
--
2.51.0
^ permalink raw reply related
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