* [PATCH v2 0/3] Fix bugs for realm guest plus BBML2_NOABORT
From: Ryan Roberts @ 2026-03-30 16:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel
Hi All,
This fixes a couple of bugs in the "large block mappings for linear map when we
have BBML2_NOABORT" feature when used in conjunction with a CCA realm guest.
While investigating I found and fixed some more general issues too. See commit
logs for full explanations.
Applies on top of v7.0-rc4.
Changes since v1 [1]
====================
Patch 1:
- Moved page_alloc_available declaration to asm/mmu.c (per Kevin)
- Added PTE_PRESENT_VALID_KERNEL macro to hide VALID|NG confusion (per Kevin)
- Improved logic in split_kernel_leaf_mapping() to avoid warning for
DEBUG_PAGEALLOC (per Sashiko)
Patch 2:
- Fixed transitional pgtables to handle present-invalid large leaves (per
Sashiko)
- Hardened split_pXd() for present-invalid leaves (per Sashiko)
Patch 3:
- Converted pXd_leaf() to function to avoid multi-eval of READ_ONCE() (per
Sashiko)
[1] https://lore.kernel.org/all/20260323130317.1737522-1-ryan.roberts@arm.com/
Thanks,
Ryan
Ryan Roberts (3):
arm64: mm: Fix rodata=full block mapping support for realm guests
arm64: mm: Handle invalid large leaf mappings correctly
arm64: mm: Remove pmd_sect() and pud_sect()
arch/arm64/include/asm/mmu.h | 2 +
arch/arm64/include/asm/pgtable-prot.h | 2 +
arch/arm64/include/asm/pgtable.h | 28 +++++++----
arch/arm64/mm/init.c | 9 +++-
arch/arm64/mm/mmu.c | 67 ++++++++++++++++++---------
arch/arm64/mm/pageattr.c | 50 +++++++++++---------
arch/arm64/mm/trans_pgd.c | 42 +++--------------
7 files changed, 111 insertions(+), 89 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns
From: Paul Kocialkowski @ 2026-03-30 16:09 UTC (permalink / raw)
To: Krzysztof Hałasa
Cc: Liu Ying, Maxime Ripard, Marco Felsch, Marek Vasut, Stefan Agner,
Simona Vetter, imx, Fabio Estevam, Pengutronix Kernel Team,
Maarten Lankhorst, Sascha Hauer, Frank Li, linux-kernel,
dri-devel, Thomas Zimmermann, David Airlie, linux-arm-kernel,
Lucas Stach
In-Reply-To: <m3se9onkv0.fsf@t19.piap.pl>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
Hi folks,
On Wed 25 Mar 26, 13:40, Krzysztof Hałasa wrote:
> Why did the first (boot) sequence result in success and this second one
> in failure? This is somehow reproducible.
I've been seeing the same issue that is described in this thread when driving
a regular 1080p@60 monitor, which shows a solid color background with a pixel
from the previous frame when reconfiguring the mode from time to time.
When that happens, I see the lcdif fifo underrun/empty status until a new mode
is applied, which often resolves the situation. This situation never happens
with the downstream nxp bsp driver.
After weeks of investigation I finally narrowed it down to a part of the nxp
original code that is missing in the upstream driver:
https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy/drivers/gpu/imx/lcdifv3/lcdifv3-common.c#L492
A big old sleep that waits for the DMA engine to finish handling the current
frame before it is disabled. When this delay is not respected, there seems to
be "unlucky" times when disabling the DMA engine too early will confuse the
unit and make it unable to resume proper operation later.
It is a bit surprising that the issue is not actually related to configuring
the display engine but to disabling it. This is why the first mode set always
works but subsequentil ones might fail. The crtc is essentially disabled and
re-enabled each time a new mode is applied.
Adding the sleep solves the issue on my side and all mode sets now work
reliably. It does add a delay before returning to userspace when configuring
a new mode, but it seems legitimate to me if the underlying hardware is still
in-flight. I'm also unsure if it would apply to an async atomic commit.
I will send a patch adding the delay and the undocumented fifo clear
bit that was discovered in this thread too.
All the best,
Paul
Perhaps there is a more elegant way to handle this
> Interestingly, Weston usually starts fine in subsequent launches.
>
> How is this first (actually second - after the first VSYNC) frame
> different from all the others? Maybe we're programming UPDATE_SHADOW
> after the actual start of blanking period, but before DE, so it has no
> chance to reload registers, yet the DMA is somehow not ready?
>
> The manual (LCDIF display control Register (CTRL)) suggests that the DMA
> (with present settings) starts to fetch FB data at the end of the
> previous active video pixel time (DE and pixel data going inactive):
> fetch_start_option (bits 9-8): Indicates when to start fetching for new
> frame. This signals also decide the shadow load, fifo clear time
> 00b - fetch start as soon as FPV begins(as the end of the data_enable).
>
> This should leave a lot of time to fill the FIFO (before the next DE),
> shouldn't it?
>
> 297 MHz pixclk, 3840x2160, 30 Hz, H back porch 296 pixclks, Vfp 176,
> V back porch 72 lines, Hfp 8 lines, VSYNC 10 lines, HSYNC 88 pixclks.
> HTotal = 4400 pixels which makes Vactive time = 4400 * 2160/297e6 =
> 32 ms, with the remaining 1.3333 ms for all the V sync stuff.
> --
> Krzysztof "Chris" Hałasa
>
> Sieć Badawcza Łukasiewicz
> Przemysłowy Instytut Automatyki i Pomiarów PIAP
> Al. Jerozolimskie 202, 02-486 Warszawa
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: qcom: enable UARTs for robot expansion board
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, Canfeng Zhuang
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-1-canfeng.zhuang@oss.qualcomm.com>
On Fri, 27 Mar 2026 16:30:59 +0800, Canfeng Zhuang wrote:
> The Qualcomm Lemans EVK and Monaco EVK boards expose a mezzanine
> connector used by a motor control expansion board.
>
> This expansion board hosts an MCU running NuttX and communicates with
> Linux over UART, with all protocol handling done in userspace.
>
> This series enables the required UARTs and assigns stable serial aliases
> to ensure consistent device enumeration across platforms.
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
commit: 0be638f326c2015ae9406f4238d9bc54b5b7a584
[2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
commit: 74620bf0c3c6091ecd7972075f5ddeba29994407
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH V2 3/5] dmaengine: xilinx_dma: Extend metadata handling for AXI MCDMA
From: Frank Li @ 2026-03-30 15:58 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Vinod Koul, git, Frank Li, Michal Simek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suraj Gupta,
Radhey Shyam Pandey, Thomas Gessler, Folker Schwesinger,
Tomi Valkeinen, Kees Cook, Abin Joseph, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260313062533.421249-4-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:31AM +0530, Srinivas Neeli wrote:
> From: Suraj Gupta <suraj.gupta2@amd.com>
>
> Extend probe logic to detect AXI Stream connections for MCDMA. When
> an AXI Stream interface is present, metadata operations are enabled for
> the MCDMA channel. The xilinx_dma_get_metadata_ptr() is enhanced to
> retrieve metadata directly from MCDMA descriptors.
Need extra empty line between paragraph
> Add corresponding channel reference in struct xilinx_dma_tx_descriptor to
> retrieve associated channel.
> These changes ensure proper metadata handling and accurate transfer
> size reporting for MCDMA transfers.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 00200b4c2372..52203d44e7a4 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -222,6 +222,8 @@
> #define XILINX_MCDMA_BD_EOP BIT(30)
> #define XILINX_MCDMA_BD_SOP BIT(31)
>
> +struct xilinx_dma_chan;
> +
> /**
> * struct xilinx_vdma_desc_hw - Hardware Descriptor
> * @next_desc: Next Descriptor Pointer @0x00
> @@ -371,6 +373,7 @@ struct xilinx_cdma_tx_segment {
>
> /**
> * struct xilinx_dma_tx_descriptor - Per Transaction structure
> + * @chan: DMA channel for which this descriptor is allocated
> * @async_tx: Async transaction descriptor
> * @segments: TX segments list
> * @node: Node in the channel descriptors list
> @@ -379,6 +382,7 @@ struct xilinx_cdma_tx_segment {
> * @residue: Residue of the completed descriptor
> */
> struct xilinx_dma_tx_descriptor {
> + struct xilinx_dma_chan *chan;
async_tx already include dma_chan's information.
Frank
^ permalink raw reply
* Re: [PATCH] media: cedrus: skip invalid H.264 reference list entries
From: Nicolas Dufresne @ 2026-03-30 15:55 UTC (permalink / raw)
To: wens, Jernej Škrabec
Cc: mripard, Pengpeng Hou, paulk, mchehab, gregkh, samuel,
linux-media, linux-staging, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <CAGb2v674Ei2uFh6O0LoFoJrPcqGKGr_v+hfvE7TSfwztxDfTAA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
Le dimanche 29 mars 2026 à 20:44 +0800, Chen-Yu Tsai a écrit :
> On Sun, Mar 29, 2026 at 5:21 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Dne torek, 24. marec 2026 ob 09:08:56 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> > > Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
> > > stateless slice control and later uses their indices to look up
> > > decode->dpb[] in _cedrus_write_ref_list().
> > >
> > > Rejecting such controls in cedrus_try_ctrl() would break existing
> > > userspace, since stateless H.264 reference lists may legitimately carry
> > > out-of-range indices for missing references. Instead, guard the actual
> > > DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
> > > V4L2_H264_NUM_DPB_ENTRIES array.
> > >
> > > This keeps the fix local to the driver use site and avoids out-of-bounds
> > > reads from malformed or unsupported reference list entries.
> > >
> > > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> >
> > Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> Tested-by: Chen-Yu Tsai <wens@kernel.org>
>
> This fixes a KASAN slab-use-after-free warning when running fluster H.264
> tests.
Ah, very good, can you cite which test caused that ? I didn't expect fluster to
cover cases with missing references. I think it will be handy for future
testing.
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/5] dmaengine: xilinx_dma: Move descriptors to done list based on completion bit
From: Frank Li @ 2026-03-30 15:54 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Vinod Koul, git, Frank Li, Michal Simek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suraj Gupta,
Radhey Shyam Pandey, Thomas Gessler, Folker Schwesinger,
Tomi Valkeinen, Kees Cook, Abin Joseph, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260313062533.421249-3-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:30AM +0530, Srinivas Neeli wrote:
> In AXIMCDMA scatter-gather mode, the hardware sets the completion bit when
> a transfer finishes. The driver now checks this bit to free descriptors
> from the active list and move them to the done list.
Add check complete bit because irq may be triggered before a configured
threshold is reached when interrupt delay timeout Dly_IrqEn is enabled.
Frank
> This is required when interrupt delay timeout Dly_IrqEn is enabled,
> as interrupts may be triggered before the configured threshold is reached,
> even if not all descriptors have completed.
>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 4a83492f2435..00200b4c2372 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1762,6 +1762,18 @@ static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
> struct xilinx_axidma_tx_segment, node);
> if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
> break;
> + } else if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> + struct xilinx_aximcdma_tx_segment *seg;
> + bool completed;
> +
> + seg = list_last_entry(&desc->segments,
> + struct xilinx_aximcdma_tx_segment,
> + node);
> + completed = (chan->direction == DMA_DEV_TO_MEM) ?
> + (seg->hw.s2mm_status & XILINX_DMA_BD_COMP_MASK) :
> + (seg->hw.mm2s_status & XILINX_DMA_BD_COMP_MASK);
> + if (!completed)
> + break;
> }
> if (chan->has_sg && chan->xdev->dma_config->dmatype !=
> XDMA_TYPE_VDMA)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] media: cedrus: skip invalid H.264 reference list entries
From: Nicolas Dufresne @ 2026-03-30 15:54 UTC (permalink / raw)
To: Pengpeng Hou, mripard
Cc: paulk, mchehab, gregkh, wens, jernej.skrabec, samuel, linux-media,
linux-staging, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260324080856.56787-1-pengpeng@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
Le mardi 24 mars 2026 à 16:08 +0800, Pengpeng Hou a écrit :
> Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
> stateless slice control and later uses their indices to look up
> decode->dpb[] in _cedrus_write_ref_list().
>
> Rejecting such controls in cedrus_try_ctrl() would break existing
> userspace, since stateless H.264 reference lists may legitimately carry
> out-of-range indices for missing references. Instead, guard the actual
> DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
> V4L2_H264_NUM_DPB_ENTRIES array.
>
> This keeps the fix local to the driver use site and avoids out-of-bounds
> reads from malformed or unsupported reference list entries.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> @@ -210,6 +210,9 @@ static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> u8 dpb_idx;
>
> dpb_idx = ref_list[i].index;
> + if (dpb_idx >= V4L2_H264_NUM_DPB_ENTRIES)
> + continue;
Matches how we skip inactive references (in this diff, though most userspace
just don't pass them). Now, if I looked lower, we set a position for each
references. My understanding is that if no bits are set, it means "no position".
How much testing have you done to confirm the HW behaves properly ?
Despite this question, I think this is going to work better then doing memory
overrun:
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Nicolas
> +
> dpb = &decode->dpb[dpb_idx];
>
> if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH V2 1/5] dmaengine: xilinx_dma: Fix MCDMA descriptor fields for MM2S vs S2MM
From: Frank Li @ 2026-03-30 15:46 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Vinod Koul, git, Frank Li, Michal Simek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suraj Gupta,
Radhey Shyam Pandey, Thomas Gessler, Folker Schwesinger,
Tomi Valkeinen, Kees Cook, Abin Joseph, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260313062533.421249-2-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:29AM +0530, Srinivas Neeli wrote:
> The MCDMA BD format differs between MM2S and S2MM directions, but the
Can you use DMA_DEV_TO_MEM and DMA_MEM_TO_DEV instead of MM2S and S2MM?
or memory to slave, at least first place need extend term MM2S(memory to
slave).
> driver was using generic 'status' and 'sideband_status' fields for both.
> This could lead to incorrect residue calculations when the hardware
> updates direction-specific fields.
driver was using generic 'status' and 'sideband_status' fields for both,
which lead ... (use Affirmative Tone)
>
> Refactor the descriptor structure to use unions with direction-specific
> field names (mm2s_status/s2mm_status, etc.). This ensures the driver
Ensure .. (needn't this)
Frank
> accesses the correct hardware fields based on channel direction and
> matches the hardware documentation.
>
> Fixes: 6ccd692bfb7f ("dmaengine: xilinx_dma: Add Xilinx AXI MCDMA Engine driver support")
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 29 ++++++++++++++++++++++-------
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index b53292e02448..4a83492f2435 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -275,8 +275,10 @@ struct xilinx_axidma_desc_hw {
> * @buf_addr_msb: MSB of Buffer address @0x0C
> * @rsvd: Reserved field @0x10
> * @control: Control Information field @0x14
> - * @status: Status field @0x18
> - * @sideband_status: Status of sideband signals @0x1C
> + * @mm2s_ctrl_sideband: Sideband control info for mm2s @0x18
> + * @s2mm_status: Status field for s2mm @0x18
> + * @mm2s_status: Status field for mm2s @0x1C
> + * @s2mm_sideband_status: Sideband status for s2mm @0x1C
> * @app: APP Fields @0x20 - 0x30
> */
> struct xilinx_aximcdma_desc_hw {
> @@ -286,8 +288,14 @@ struct xilinx_aximcdma_desc_hw {
> u32 buf_addr_msb;
> u32 rsvd;
> u32 control;
> - u32 status;
> - u32 sideband_status;
> + union {
> + u32 mm2s_ctrl_sideband;
> + u32 s2mm_status;
> + };
> + union {
> + u32 mm2s_status;
> + u32 s2mm_sideband_status;
> + };
> u32 app[XILINX_DMA_NUM_APP_WORDS];
> } __aligned(64);
>
> @@ -1013,9 +1021,16 @@ static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> struct xilinx_aximcdma_tx_segment,
> node);
> aximcdma_hw = &aximcdma_seg->hw;
> - residue +=
> - (aximcdma_hw->control - aximcdma_hw->status) &
> - chan->xdev->max_buffer_len;
> + if (chan->direction == DMA_DEV_TO_MEM)
> + residue +=
> + (aximcdma_hw->control -
> + aximcdma_hw->s2mm_status) &
> + chan->xdev->max_buffer_len;
> + else
> + residue +=
> + (aximcdma_hw->control -
> + aximcdma_hw->mm2s_status) &
> + chan->xdev->max_buffer_len;
> }
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] media: nxp: imx8-isi: fix memory leaks in probe error paths and remove
From: Laurent Pinchart @ 2026-03-30 15:41 UTC (permalink / raw)
To: Frank Li
Cc: David Carlier, mchehab, s.hauer, festevam, jacopo, aisheng.dong,
guoniu.zhou, linux-media, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <acqM06YySijL1VpU@lizhi-Precision-Tower-5810>
On Mon, Mar 30, 2026 at 10:46:43AM -0400, Frank Li wrote:
> On Fri, Mar 27, 2026 at 10:27:11PM +0000, David Carlier wrote:
> > mxc_isi_probe() allocates isi->pipes with kzalloc_objs() but never
> > frees it on any probe failure path or in mxc_isi_remove(), leaking the
> > allocation on every failed probe and every normal unbind.
> >
> > Additionally, when mxc_isi_pipe_init() fails partway through the
> > channel loop or when mxc_isi_v4l2_init() fails, the already initialized
> > pipes are not cleaned up — their media entities and mutexes are leaked.
> >
> > Fix both by adding kfree(isi->pipes) to all probe error paths and to
> > mxc_isi_remove(), and cleaning up already-initialized pipes in the
> > err_xbar error path.
> >
> > Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISP Channel driver")
> > Signed-off-by: David Carlier <devnexen@gmail.com>
> > ---
>
> I think provide a helper function, devm_kzalloc_objs(), or using old
> devm_kzalloc is better fix method.
I quite agree. Kees said he's planning to introduce devm_kzalloc_objs().
I assume this will come in the next kernel version. I think we can wait
for that to fix this leak as it's a really minor issue.
> > .../platform/nxp/imx8-isi/imx8-isi-core.c | 24 +++++++++++++++----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> > index 4bf8570e1b9e..ab32c5b6ac9c 100644
> > --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> > +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.c
> > @@ -490,33 +490,43 @@ static int mxc_isi_probe(struct platform_device *pdev)
> > return -ENOMEM;
> >
> > isi->num_clks = devm_clk_bulk_get_all(dev, &isi->clks);
> > - if (isi->num_clks < 0)
> > + if (isi->num_clks < 0) {
> > + kfree(isi->pipes);
> > return dev_err_probe(dev, isi->num_clks, "Failed to get clocks\n");
> > + }
> >
> >
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-30 15:33 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen, Conor Dooley
In-Reply-To: <20260327-pinctrl-mux-v5-3-d4aec9d62c62@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
On Fri, Mar 27, 2026 at 05:34:00PM -0400, Frank Li wrote:
> Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
> parsing logic from map creation. Introduce a new helper
> pinctrl_generic_to_map() to handle mapping to kernel data structures, while
> keeping DT property parsing in the subnode function.
>
> Improve code structure and enables easier reuse for platforms using
> different DT properties (e.g. pinmux) without modifying the
> dt_node_to_map-style callback API. Avoid unnecessary coupling to
> pinctrl_generic_pins_function_dt_node_to_map(), which provides
> functionality not needed when the phandle target is unambiguous.
>
> Maximize code reuse and provide a cleaner extension point for future
> pinctrl drivers.
>
> Suggested-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Will Deacon @ 2026-03-30 15:29 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Oliver Upton, Marc Zyngier,
Catalin Marinas, Mark Rutland
When running with VHE, TPIDR_EL2 is only used for the percpu offset once
the ARM64_HAS_VIRT_HOST_EXTN capability has been detected, at which
point cpu_copy_el2regs() will populate its contents from TPIDR_EL1.
Remove the redundant initialisation of TPIDR_EL2 from finalise_el2().
Cc: Oliver Upton <oupton@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
I spotted this by inspection as part of an ill-fated (abandoned) attempt
at repurposing tpidr_elx for something else.
arch/arm64/kernel/hyp-stub.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 085bc9972f6b..8b8614c0b9a5 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -105,11 +105,9 @@ SYM_CODE_START_LOCAL(__finalise_el2)
msr_hcr_el2 x0
isb
- // Use the EL1 allocated stack, per-cpu offset
+ // Use the EL1 allocated stack
mrs x0, sp_el1
mov sp, x0
- mrs x0, tpidr_el1
- msr tpidr_el2, x0
// FP configuration, vectors
mrs_s x0, SYS_CPACR_EL12
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
From: Gabor Juhos @ 2026-03-30 15:25 UTC (permalink / raw)
To: Gregory Clement, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
Instead of the generic 'usb2-phy' name, the Armada 37xx device trees
are using a custom 'usb2-utmi-otg-phy' name for the USB2 PHY in the USB3
controller node. Since commit 53a2d95df836 ("usb: core: add phy notify
connect and disconnect"), this triggers a bug [1] in the USB core which
causes double use of the USB3 PHY.
Change the PHY name to 'usb2-phy' in the SoC and in the uDPU specific
dtsi files in order to avoid triggering the bug and also to keep the
names in line with the ones used by other platforms.
Link: https://lore.kernel.org/r/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com # [1]
Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
index cd856c0aba71e6f6fd3db8fb386ad607912e7577..12deacb741ccbea684d905f246f26a4399fc8cd8 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi
@@ -161,7 +161,7 @@ ð1 {
&usb3 {
status = "okay";
phys = <&usb2_utmi_otg_phy>;
- phy-names = "usb2-utmi-otg-phy";
+ phy-names = "usb2-phy";
};
&uart0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 44c47409f8793ae1266303607812ef481edbfbc5..7470d504a41081b32bee45368028189a13ea7087 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -372,7 +372,7 @@ usb3: usb@58000 {
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&sb_periph_clk 12>;
phys = <&comphy0 0>, <&usb2_utmi_otg_phy>;
- phy-names = "usb3-phy", "usb2-utmi-otg-phy";
+ phy-names = "usb3-phy", "usb2-phy";
status = "disabled";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
From: Gabor Juhos @ 2026-03-30 15:25 UTC (permalink / raw)
To: Gregory Clement, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
It seems that the Armada 3700 is the only platform where the USB3 specific
PHY is defined before the USB2 specific one in the device tree:
$ git grep -E 'phy-names[ \t]*=[ \t]*"usb3-phy"[ \t]*,' next-20260327 -- *.dts *.dtsi | tr '\t' ' '
next-20260327:arch/arm64/boot/dts/marvell/armada-37xx.dtsi: phy-names = "usb3-phy", "usb2-utmi-otg-phy";
In contrary to this, there are 93 other platforms/boards where 'usb2-phy'
is defined first:
$ git grep -E 'phy-names[ \t]*=[ \t]*"usb2-phy"[ \t]*,' next-20260327 -- *.dts *.dtsi | wc -l
93
Swap the order of the USB3 and USB2 PHYs to follow the common pattern
used on other platforms.
No functional changes intended.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 7470d504a41081b32bee45368028189a13ea7087..360fc24fdde2204540ac415852146d3020be87c0 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -371,8 +371,8 @@ usb3: usb@58000 {
reg = <0x58000 0x4000>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&sb_periph_clk 12>;
- phys = <&comphy0 0>, <&usb2_utmi_otg_phy>;
- phy-names = "usb3-phy", "usb2-phy";
+ phys = <&usb2_utmi_otg_phy>, <&comphy0 0>;
+ phy-names = "usb2-phy", "usb3-phy";
status = "disabled";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: marvell: armada-37xx: USB3 PHY cleanup
From: Gabor Juhos @ 2026-03-30 15:25 UTC (permalink / raw)
To: Gregory Clement, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
There are two small patches in the series. The first helps to avoid
triggering a bug in the USB core code, whereas the second one is a
small cleanup to align PHY definitions of the USB3 node with other
platforms.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
Gabor Juhos (2):
arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: 2ff6cc999a04bcb094b8cbba68a9251f03a5c876
change-id: 20260330-armada-37xx-usb3-phy-cleanup-922a5472794a
Best regards,
--
Gabor Juhos <j4g8y7@gmail.com>
^ permalink raw reply
* [PATCH] usb: core: avoid double use of 'usb3-phy'
From: Gabor Juhos @ 2026-03-30 15:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Stanley Chang
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Miquel Raynal, linux-usb, linux-kernel, linux-arm-kernel,
Gabor Juhos
Commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect")
causes double use of the 'usb3-phy' in certain cases.
Since that commit, if a generic PHY named 'usb3-phy' is specified in
the device tree, that is getting added to the 'phy_roothub' list of the
secondary HCD by the usb_phy_roothub_alloc_usb3_phy() function. However,
that PHY is getting added also to the primary HCD's 'phy_roothub' list
by usb_phy_roothub_alloc() if there is no generic PHY specified with
'usb2-phy' name.
This causes that the usb_add_hcd() function executes each phy operations
twice on the 'usb3-phy'. Once when the primary HCD is added, then once
again when the secondary HCD is added.
The issue affects the Marvell Armada 3700 platform at least, where a
custom name is used for the USB2 PHY:
$ git grep 'phy-names.*usb3' arch/arm64/boot/dts/marvell/armada-37xx.dtsi | tr '\t' ' '
arch/arm64/boot/dts/marvell/armada-37xx.dtsi: phy-names = "usb3-phy", "usb2-utmi-otg-phy";
Extend the usb_phy_roothub_alloc_usb3_phy() function to skip adding the
'usb3-phy' to the 'phy_roothub' list of the secondary HCD when 'usb2-phy'
is not specified in the device tree to avoid the double use.
Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
drivers/usb/core/phy.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 4bba1c2757406a35bf19eb7984a2807212374d18..4d966cc9cdc9510147041df7875ad9e48a9ea3af 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -114,7 +114,7 @@ EXPORT_SYMBOL_GPL(usb_phy_roothub_alloc);
struct usb_phy_roothub *usb_phy_roothub_alloc_usb3_phy(struct device *dev)
{
struct usb_phy_roothub *phy_roothub;
- int num_phys;
+ int num_phys, usb2_phy_index;
if (!IS_ENABLED(CONFIG_GENERIC_PHY))
return NULL;
@@ -124,6 +124,16 @@ struct usb_phy_roothub *usb_phy_roothub_alloc_usb3_phy(struct device *dev)
if (num_phys <= 0)
return NULL;
+ /*
+ * If 'usb2-phy' is not present, usb_phy_roothub_alloc() added
+ * all PHYs to the primary HCD's phy_roothub already, so skip
+ * adding 'usb3-phy' here to avoid double use of that.
+ */
+ usb2_phy_index = of_property_match_string(dev->of_node, "phy-names",
+ "usb2-phy");
+ if (usb2_phy_index < 0)
+ return NULL;
+
phy_roothub = devm_kzalloc(dev, sizeof(*phy_roothub), GFP_KERNEL);
if (!phy_roothub)
return ERR_PTR(-ENOMEM);
---
base-commit: f50200dd44125e445a6164e88c217472fa79cdbc
change-id: 20260329-usb-avoid-usb3-phy-double-use-7e498373073c
Best regards,
--
Gabor Juhos <j4g8y7@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3 1/3] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: Krzysztof Kozlowski @ 2026-03-30 14:57 UTC (permalink / raw)
To: Hawkins, Nick
Cc: catalin.marinas@arm.com, will@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DM4PR84MB192724F4949F614E3965E60A8852A@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM>
On 30/03/2026 16:53, Hawkins, Nick wrote:
> Hi Krzysztof Kozlowski,
>
>>> maintainers:
>>> - Nick Hawkins <nick.hawkins@hpe.com>
>>> @@ -18,6 +18,11 @@ properties:
>>> - enum:
>>> - hpe,gxp-dl360gen10
>>> - const: hpe,gxp
>>> + - description: GSC Based Boards
>>> + items:
>>> + - enum:
>>> + - hpe,gsc-dl340gen12
>>> + - const: hpe,gsc
>
>> What sort of ordering are you going to use in this file? Usual choice is
>> the fallback compatible, but I see you have chosen something else. That
>> is fine, just keep that else sorting in the future instead of adding to
>> the end.
>
> Thank you for the feedback, just to confirm are you looking for me
> to do something like this?:
>
> - description: GSC Based Boards
> items:
> - enum:
> - hpe,gsc-dl340gen12
> - const: hpe,gsc
> - description: GXP Based Boards
> items:
> - enum:
> - hpe,gxp-dl360gen10
> - const: hpe,gxp
Yes, that's the typical/usual way.
>
> That way we have the newest first and going forward if there is
Usual order is the alphanumerical.
> something newer we add it to the top of the list rather than
> the bottom?
If you want to order by date of release of the SoC, that's fine. I think
Allwinner does it. It's pretty non obvious because the chips are
upstreamed different time than released, so it is difficult for people
knot knowing the release dates. Just don't use the rule of "add at the
beginning" or "at the end".
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Mathieu Poirier @ 2026-03-30 14:56 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, Rob Herring, Conor Dooley, Vignesh Raghavendra,
Tero Kristo, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
devicetree, Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com>
On Wed, Mar 18, 2026 at 04:13:06PM +0100, Markus Schneider-Pargmann (TI) wrote:
> Hi,
>
> Split the firmware memory region in more specific parts so it is better
> described where which information is stored. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data and resume from RAM.
>
> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
> for wakeup while the DDR is kept in self refresh. Everything else is
> powered off.
>
> The changes in this series were suggested as part of the IO+DDR u-boot series:
> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>
> There are currently no real users of the memory-region that is split in
> this series. The size of the memory-region in total stays the same.
> The new layout is derived from the software running on the r5f
> processor:
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>
> Additionally the two important devicetree nodes for resuming from IO+DDR
> have the bootph-pre-ram flag added as this data needs to be read before
> the RAM is in use.
>
> Best
> Markus
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> Changes in v3:
> - Squash the enforcement of the memory-region-names requirement in the
> patch adding the memory-region-names, as suggested.
> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>
> Changes in v2:
> - Make memory-region-names required if memory-region is present
> - Fixup memory-region and memory-region-names conditions. Require either
> 2 or 6 regions for memory-region and memory-region-names
> - Reword and restructure the binding documentation for memory-region and
> memory-region-names
> - Add memory-region-names to all uses of memory-region
> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>
> ---
> Markus Schneider-Pargmann (TI) (7):
> dt-bindings: remoteproc: k3-r5f: Split up memory regions
> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
I have picked-up the above two. The .dtsi files need to go through the TI
tree.
Thanks,
Mathieu
> arm64: dts: ti: k3: Use memory-region-names for r5f
> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
>
> .../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 55 ++++++++++++++++++----
> .../arm64/boot/dts/ti/k3-am62-ti-ipc-firmware.dtsi | 1 +
> .../boot/dts/ti/k3-am62a-ti-ipc-firmware.dtsi | 2 +
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 42 ++++++++++++++++-
> .../boot/dts/ti/k3-am62p-ti-ipc-firmware.dtsi | 2 +
> arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 42 ++++++++++++++++-
> .../arm64/boot/dts/ti/k3-am64-ti-ipc-firmware.dtsi | 4 ++
> .../arm64/boot/dts/ti/k3-am65-ti-ipc-firmware.dtsi | 2 +
> .../boot/dts/ti/k3-j7200-ti-ipc-firmware.dtsi | 4 ++
> .../boot/dts/ti/k3-j721e-ti-ipc-firmware.dtsi | 6 +++
> .../boot/dts/ti/k3-j721s2-ti-ipc-firmware.dtsi | 6 +++
> .../boot/dts/ti/k3-j722s-ti-ipc-firmware.dtsi | 3 ++
> .../k3-j784s4-j742s2-ti-ipc-firmware-common.dtsi | 8 ++++
> 13 files changed, 163 insertions(+), 14 deletions(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260210-topic-am62a-ioddr-dt-v6-19-0da7712081d7
>
> Best regards,
> --
> Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-30 14:55 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <20260325-add-traceid-show-for-tpdm-v3-1-0eb836d4ec30@oss.qualcomm.com>
On 25/03/2026 3:10 am, Jie Gan wrote:
> Save the trace ID in drvdata during TPDM enablement and expose it
> to userspace to support trace data parsing.
>
> The TPDM device’s trace ID corresponds to the trace ID allocated
> to the connected TPDA device.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Changes in v3:
> 1. Only allow user to read the traceid while the TPDM device is enabled.
> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>
> Changes in V2:
> 1. Use sysfs_emit instead of sprintf.
> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
> ---
> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++++++++-
> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index da77bdaad0a4..c8339b973bfc 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
>
> static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> enum cs_mode mode,
> - __maybe_unused struct coresight_path *path)
> + struct coresight_path *path)
> {
> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> }
>
> __tpdm_enable(drvdata);
> + drvdata->traceid = path->trace_id;
> drvdata->enable = true;
> spin_unlock(&drvdata->spinlock);
>
> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
> .attrs = tpdm_attrs,
> };
>
> +static ssize_t traceid_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
> + return -EINVAL;
> +
> + val = drvdata->traceid;
You probably need to take the coresight_mutex here otherwise you could
still return an invalid or stale value despite checking the mode.
There might also be some value in it returning the last used trace ID
even if the mode isn't enabled anymore. Because you can still read out
of the sink after disabling, so it makes more sense for a script to read
it at that point rather than when it's enabled. Also, you probably don't
want to be doing other things in your script in the point between
enabling and disabling.
> + return sysfs_emit(buf, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(traceid);
> +
> +static struct attribute *traceid_attrs[] = {
> + &dev_attr_traceid.attr,
> + NULL,
> +};
> +
> +static struct attribute_group traceid_attr_grp = {
> + .attrs = traceid_attrs,
> +};
> +
> static ssize_t dsb_mode_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
> &tpdm_cmb_patt_grp,
> &tpdm_cmb_msr_grp,
> &tpdm_mcmb_attr_grp,
> + &traceid_attr_grp,
> + NULL,
> +};
> +
> +static const struct attribute_group *static_tpdm_attr_grps[] = {
> + &traceid_attr_grp,
> NULL,
> };
>
> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> desc.access = CSDEV_ACCESS_IOMEM(base);
> if (res)
> desc.groups = tpdm_attr_grps;
> + else
> + desc.groups = static_tpdm_attr_grps;
> drvdata->csdev = coresight_register(&desc);
> if (IS_ERR(drvdata->csdev))
> return PTR_ERR(drvdata->csdev);
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index 2867f3ab8186..11da64e1ade8 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -300,6 +300,7 @@ struct cmb_dataset {
> * @cmb Specifics associated to TPDM CMB.
> * @dsb_msr_num Number of MSR supported by DSB TPDM
> * @cmb_msr_num Number of MSR supported by CMB TPDM
> + * @traceid Trace ID of the path.
> */
>
> struct tpdm_drvdata {
> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
> struct cmb_dataset *cmb;
> u32 dsb_msr_num;
> u32 cmb_msr_num;
> + u8 traceid;
> };
>
> /* Enumerate members of various datasets */
>
> ---
> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>
> Best regards,
^ permalink raw reply
* RE: [PATCH v3 1/3] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: Hawkins, Nick @ 2026-03-30 14:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: catalin.marinas@arm.com, will@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260328-chirpy-sturdy-emu-9eb0cb@quoll>
Hi Krzysztof Kozlowski,
> > maintainers:
> > - Nick Hawkins <nick.hawkins@hpe.com>
> > @@ -18,6 +18,11 @@ properties:
> > - enum:
> > - hpe,gxp-dl360gen10
> > - const: hpe,gxp
> > + - description: GSC Based Boards
> > + items:
> > + - enum:
> > + - hpe,gsc-dl340gen12
> > + - const: hpe,gsc
> What sort of ordering are you going to use in this file? Usual choice is
> the fallback compatible, but I see you have chosen something else. That
> is fine, just keep that else sorting in the future instead of adding to
> the end.
Thank you for the feedback, just to confirm are you looking for me
to do something like this?:
- description: GSC Based Boards
items:
- enum:
- hpe,gsc-dl340gen12
- const: hpe,gsc
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
That way we have the newest first and going forward if there is
something newer we add it to the top of the list rather than
the bottom?
Thanks,
-Nick Hawkins
^ permalink raw reply
* Re: [PATCH v2 0/3] media: imx-csi: cleanup media pipeline start
From: Frank Li @ 2026-03-30 14:38 UTC (permalink / raw)
To: Michael Tretter, Hans Verkuil, Steve Longerbeam, Philipp Zabel,
Mauro Carvalho Chehab, Fabio Estevam, Greg Kroah-Hartman,
Shawn Guo, Sascha Hauer, linux-media, imx, linux-arm-kernel,
Pengutronix Kernel Team, linux-staging
In-Reply-To: <aco5Ei1B4vJWKMMj@pengutronix.de>
On Mon, Mar 30, 2026 at 10:49:22AM +0200, Michael Tretter wrote:
> Hi Hans,
>
> On Fri, 23 Jan 2026 17:57:23 +0100, Michael Tretter wrote:
> > On Thu, 18 Dec 2025 10:23:48 +0100, Michael Tretter wrote:
> > > The imx media device currently assumes that there is only a single media
> > > pipeline. However, the media graph has multiple imx capture devices.
> > > These may be started separately on media pipelines if they don't cause
> > > conflicts in the media graph.
> > >
> > > Move the media pipeline from the media device to the capture devices to
> > > properly track and handle multiple media pipelines for the imx-csi.
> > > Refactor the code to start the media pipeline from the driver to help
> > > the reader.
> >
>
> Could you take a look and apply this series for the imx-media driver,
> too? The patches are already reviewed by Frank Li and Philipp Zabel.
Michael Tretter:
Sorry, I will take care imx's stage driver. I already sent pull-request,
which included your other two patches.
Do you have others patches, which need me take care. I am not sure if
there are chance to send 2nd pull request for 7.1.
Frank
>
> Michael
>
> >
> > >
> > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
> > > ---
> > > Changes in v2:
> > > - Improve code readability in Patch 2
> > > - Update commit message of Patch 3 as suggested by Frank Li
> > > - Link to v1: https://patch.msgid.link/20251107-media-imx-cleanup-v1-0-f82a693c28f4@pengutronix.de
> > >
> > > ---
> > > Michael Tretter (3):
> > > media: imx-csi: move media_pipeline to video device
> > > media: imx-csi: explicitly start media pipeline on pad 0
> > > media: imx-csi: use media_pad_is_streaming helper
> > >
> > > drivers/staging/media/imx/imx-media-capture.c | 8 ++++----
> > > drivers/staging/media/imx/imx-media-utils.c | 12 ++++++++----
> > > drivers/staging/media/imx/imx-media.h | 7 ++++---
> > > 3 files changed, 16 insertions(+), 11 deletions(-)
> > > ---
> > > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > > change-id: 20251107-media-imx-cleanup-9022d941ae44
^ permalink raw reply
* [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Jun Yan @ 2026-03-30 14:51 UTC (permalink / raw)
To: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, Jun Yan
Correct the interrupt number assigned to the Realtek PHY in the p230
following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
interrupt improvements [1].
[1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index 7dffeb5931c9..701de57ff0f3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -84,7 +84,8 @@ external_phy: ethernet-phy@0 {
reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio_intc>;
- interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
eee-broken-1000t;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v5 38/38] drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL
From: Will Deacon @ 2026-03-30 14:48 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260330144841.26181-1-will@kernel.org>
pKVM guests practically rely on CONFIG_DMA_RESTRICTED_POOL=y in order
to establish shared memory regions with the host for virtio buffers.
Make CONFIG_ARM_PKVM_GUEST depend on CONFIG_DMA_RESTRICTED_POOL to avoid
the inevitable segmentation faults experience if you have the former but
not the latter.
Reported-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
drivers/virt/coco/pkvm-guest/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virt/coco/pkvm-guest/Kconfig b/drivers/virt/coco/pkvm-guest/Kconfig
index d2f344f1f98f..928b8e1668cc 100644
--- a/drivers/virt/coco/pkvm-guest/Kconfig
+++ b/drivers/virt/coco/pkvm-guest/Kconfig
@@ -1,6 +1,6 @@
config ARM_PKVM_GUEST
bool "Arm pKVM protected guest driver"
- depends on ARM64
+ depends on ARM64 && DMA_RESTRICTED_POOL
help
Protected guests running under the pKVM hypervisor on arm64
are isolated from the host and must issue hypercalls to enable
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v5 36/38] KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs
From: Will Deacon @ 2026-03-30 14:48 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260330144841.26181-1-will@kernel.org>
Now that the guest can share and unshare memory with the host using
hypercalls, extend the pKVM page ownership selftest to exercise these
new transitions.
Tested-by: Fuad Tabba <tabba@google.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 0775a82ee4fe..28a471d1927c 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -1814,11 +1814,41 @@ void pkvm_ownership_selftest(void *base)
assert_transition_res(-EPERM, __pkvm_host_unshare_hyp, pfn);
assert_transition_res(-EPERM, __pkvm_hyp_donate_host, pfn, 1);
+ selftest_state.host = PKVM_PAGE_SHARED_BORROWED;
+ selftest_state.guest[0] = PKVM_PAGE_SHARED_OWNED;
+ assert_transition_res(0, __pkvm_guest_share_host, vcpu, gfn);
+ assert_transition_res(-EPERM, __pkvm_guest_share_host, vcpu, gfn);
+ assert_transition_res(-EPERM, __pkvm_host_donate_guest, pfn, gfn, vcpu);
+ assert_transition_res(-EPERM, __pkvm_host_donate_guest, pfn, gfn + 1, vcpu);
+ assert_transition_res(-EPERM, __pkvm_host_share_guest, pfn, gfn, 1, vcpu, prot);
+ assert_transition_res(-EPERM, __pkvm_host_share_guest, pfn, gfn + 1, 1, vcpu, prot);
+ assert_transition_res(-EPERM, __pkvm_host_share_ffa, pfn, 1);
+ assert_transition_res(-EPERM, __pkvm_host_donate_hyp, pfn, 1);
+ assert_transition_res(-EPERM, __pkvm_host_share_hyp, pfn);
+ assert_transition_res(-EPERM, __pkvm_host_unshare_hyp, pfn);
+ assert_transition_res(-EPERM, __pkvm_hyp_donate_host, pfn, 1);
+
+ selftest_state.host = PKVM_NOPAGE;
+ selftest_state.guest[0] = PKVM_PAGE_OWNED;
+ assert_transition_res(0, __pkvm_guest_unshare_host, vcpu, gfn);
+ assert_transition_res(-EPERM, __pkvm_guest_unshare_host, vcpu, gfn);
+ assert_transition_res(-EPERM, __pkvm_host_donate_guest, pfn, gfn, vcpu);
+ assert_transition_res(-EPERM, __pkvm_host_donate_guest, pfn, gfn + 1, vcpu);
+ assert_transition_res(-EPERM, __pkvm_host_share_guest, pfn, gfn, 1, vcpu, prot);
+ assert_transition_res(-EPERM, __pkvm_host_share_guest, pfn, gfn + 1, 1, vcpu, prot);
+ assert_transition_res(-EPERM, __pkvm_host_share_ffa, pfn, 1);
+ assert_transition_res(-EPERM, __pkvm_host_donate_hyp, pfn, 1);
+ assert_transition_res(-EPERM, __pkvm_host_share_hyp, pfn);
+ assert_transition_res(-EPERM, __pkvm_host_unshare_hyp, pfn);
+ assert_transition_res(-EPERM, __pkvm_hyp_donate_host, pfn, 1);
+
selftest_state.host = PKVM_PAGE_OWNED;
selftest_state.guest[0] = PKVM_POISON;
assert_transition_res(0, __pkvm_host_force_reclaim_page_guest, phys);
assert_transition_res(-EPERM, __pkvm_host_donate_guest, pfn, gfn, vcpu);
assert_transition_res(-EPERM, __pkvm_host_share_guest, pfn, gfn, 1, vcpu, prot);
+ assert_transition_res(-EHWPOISON, __pkvm_guest_share_host, vcpu, gfn);
+ assert_transition_res(-EHWPOISON, __pkvm_guest_unshare_host, vcpu, gfn);
selftest_state.host = PKVM_NOPAGE;
selftest_state.guest[1] = PKVM_PAGE_OWNED;
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v5 34/38] KVM: arm64: Register 'selftest_vm' in the VM table
From: Will Deacon @ 2026-03-30 14:48 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260330144841.26181-1-will@kernel.org>
In preparation for extending the pKVM page ownership selftests to cover
forceful reclaim of donated pages, rework the creation of the
'selftest_vm' so that it is registered in the VM table while the tests
are running.
Tested-by: Fuad Tabba <tabba@google.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 53 ++++---------------
arch/arm64/kvm/hyp/nvhe/pkvm.c | 49 +++++++++++++++++
3 files changed, 61 insertions(+), 43 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index 99d8398afe20..5031879ccb87 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -76,6 +76,8 @@ static __always_inline void __load_host_stage2(void)
#ifdef CONFIG_NVHE_EL2_DEBUG
void pkvm_ownership_selftest(void *base);
+struct pkvm_hyp_vcpu *init_selftest_vm(void *virt);
+void teardown_selftest_vm(void);
#else
static inline void pkvm_ownership_selftest(void *base) { }
#endif
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 13d2cb2f5fab..d8f8ebe59129 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -1648,53 +1648,18 @@ struct pkvm_expected_state {
static struct pkvm_expected_state selftest_state;
static struct hyp_page *selftest_page;
-
-static struct pkvm_hyp_vm selftest_vm = {
- .kvm = {
- .arch = {
- .mmu = {
- .arch = &selftest_vm.kvm.arch,
- .pgt = &selftest_vm.pgt,
- },
- },
- },
-};
-
-static struct pkvm_hyp_vcpu selftest_vcpu = {
- .vcpu = {
- .arch = {
- .hw_mmu = &selftest_vm.kvm.arch.mmu,
- },
- .kvm = &selftest_vm.kvm,
- },
-};
-
-static void init_selftest_vm(void *virt)
-{
- struct hyp_page *p = hyp_virt_to_page(virt);
- int i;
-
- selftest_vm.kvm.arch.mmu.vtcr = host_mmu.arch.mmu.vtcr;
- WARN_ON(kvm_guest_prepare_stage2(&selftest_vm, virt));
-
- for (i = 0; i < pkvm_selftest_pages(); i++) {
- if (p[i].refcount)
- continue;
- p[i].refcount = 1;
- hyp_put_page(&selftest_vm.pool, hyp_page_to_virt(&p[i]));
- }
-}
+static struct pkvm_hyp_vcpu *selftest_vcpu;
static u64 selftest_ipa(void)
{
- return BIT(selftest_vm.pgt.ia_bits - 1);
+ return BIT(selftest_vcpu->vcpu.arch.hw_mmu->pgt->ia_bits - 1);
}
static void assert_page_state(void)
{
void *virt = hyp_page_to_virt(selftest_page);
u64 size = PAGE_SIZE << selftest_page->order;
- struct pkvm_hyp_vcpu *vcpu = &selftest_vcpu;
+ struct pkvm_hyp_vcpu *vcpu = selftest_vcpu;
u64 phys = hyp_virt_to_phys(virt);
u64 ipa[2] = { selftest_ipa(), selftest_ipa() + PAGE_SIZE };
struct pkvm_hyp_vm *vm;
@@ -1709,10 +1674,10 @@ static void assert_page_state(void)
WARN_ON(__hyp_check_page_state_range(phys, size, selftest_state.hyp));
hyp_unlock_component();
- guest_lock_component(&selftest_vm);
+ guest_lock_component(vm);
WARN_ON(__guest_check_page_state_range(vm, ipa[0], size, selftest_state.guest[0]));
WARN_ON(__guest_check_page_state_range(vm, ipa[1], size, selftest_state.guest[1]));
- guest_unlock_component(&selftest_vm);
+ guest_unlock_component(vm);
}
#define assert_transition_res(res, fn, ...) \
@@ -1725,14 +1690,15 @@ void pkvm_ownership_selftest(void *base)
{
enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_RWX;
void *virt = hyp_alloc_pages(&host_s2_pool, 0);
- struct pkvm_hyp_vcpu *vcpu = &selftest_vcpu;
- struct pkvm_hyp_vm *vm = &selftest_vm;
+ struct pkvm_hyp_vcpu *vcpu;
u64 phys, size, pfn, gfn;
+ struct pkvm_hyp_vm *vm;
WARN_ON(!virt);
selftest_page = hyp_virt_to_page(virt);
selftest_page->refcount = 0;
- init_selftest_vm(base);
+ selftest_vcpu = vcpu = init_selftest_vm(base);
+ vm = pkvm_hyp_vcpu_to_hyp_vm(vcpu);
size = PAGE_SIZE << selftest_page->order;
phys = hyp_virt_to_phys(virt);
@@ -1856,6 +1822,7 @@ void pkvm_ownership_selftest(void *base)
selftest_state.hyp = PKVM_PAGE_OWNED;
assert_transition_res(0, __pkvm_host_donate_hyp, pfn, 1);
+ teardown_selftest_vm();
selftest_page->refcount = 1;
hyp_put_page(&host_s2_pool, virt);
}
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 6f3b94a37fe3..8b906217c4c3 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -733,6 +733,55 @@ void __pkvm_unreserve_vm(pkvm_handle_t handle)
hyp_spin_unlock(&vm_table_lock);
}
+#ifdef CONFIG_NVHE_EL2_DEBUG
+static struct pkvm_hyp_vm selftest_vm = {
+ .kvm = {
+ .arch = {
+ .mmu = {
+ .arch = &selftest_vm.kvm.arch,
+ .pgt = &selftest_vm.pgt,
+ },
+ },
+ },
+};
+
+static struct pkvm_hyp_vcpu selftest_vcpu = {
+ .vcpu = {
+ .arch = {
+ .hw_mmu = &selftest_vm.kvm.arch.mmu,
+ },
+ .kvm = &selftest_vm.kvm,
+ },
+};
+
+struct pkvm_hyp_vcpu *init_selftest_vm(void *virt)
+{
+ struct hyp_page *p = hyp_virt_to_page(virt);
+ int i;
+
+ selftest_vm.kvm.arch.mmu.vtcr = host_mmu.arch.mmu.vtcr;
+ WARN_ON(kvm_guest_prepare_stage2(&selftest_vm, virt));
+
+ for (i = 0; i < pkvm_selftest_pages(); i++) {
+ if (p[i].refcount)
+ continue;
+ p[i].refcount = 1;
+ hyp_put_page(&selftest_vm.pool, hyp_page_to_virt(&p[i]));
+ }
+
+ selftest_vm.kvm.arch.pkvm.handle = __pkvm_reserve_vm();
+ insert_vm_table_entry(selftest_vm.kvm.arch.pkvm.handle, &selftest_vm);
+ return &selftest_vcpu;
+}
+
+void teardown_selftest_vm(void)
+{
+ hyp_spin_lock(&vm_table_lock);
+ remove_vm_table_entry(selftest_vm.kvm.arch.pkvm.handle);
+ hyp_spin_unlock(&vm_table_lock);
+}
+#endif /* CONFIG_NVHE_EL2_DEBUG */
+
/*
* Initialize the hypervisor copy of the VM state using host-donated memory.
*
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v5 37/38] KVM: arm64: Rename PKVM_PAGE_STATE_MASK
From: Will Deacon @ 2026-03-30 14:48 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260330144841.26181-1-will@kernel.org>
Rename PKVM_PAGE_STATE_MASK to PKVM_PAGE_STATE_VMEMMAP_MASK to make it
clear that the mask applies to the page state recorded in the entries
of the 'hyp_vmemmap', rather than page states stored elsewhere (e.g. in
the ptes).
Suggested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/include/nvhe/memory.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/include/nvhe/memory.h b/arch/arm64/kvm/hyp/include/nvhe/memory.h
index 4cedb720c75d..b50712d47f6d 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/memory.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/memory.h
@@ -37,7 +37,7 @@ enum pkvm_page_state {
*/
PKVM_POISON = BIT(2),
};
-#define PKVM_PAGE_STATE_MASK (BIT(0) | BIT(1))
+#define PKVM_PAGE_STATE_VMEMMAP_MASK (BIT(0) | BIT(1))
#define PKVM_PAGE_STATE_PROT_MASK (KVM_PGTABLE_PROT_SW0 | KVM_PGTABLE_PROT_SW1)
static inline enum kvm_pgtable_prot pkvm_mkstate(enum kvm_pgtable_prot prot,
@@ -114,12 +114,12 @@ static inline void set_host_state(struct hyp_page *p, enum pkvm_page_state state
static inline enum pkvm_page_state get_hyp_state(struct hyp_page *p)
{
- return p->__hyp_state_comp ^ PKVM_PAGE_STATE_MASK;
+ return p->__hyp_state_comp ^ PKVM_PAGE_STATE_VMEMMAP_MASK;
}
static inline void set_hyp_state(struct hyp_page *p, enum pkvm_page_state state)
{
- p->__hyp_state_comp = state ^ PKVM_PAGE_STATE_MASK;
+ p->__hyp_state_comp = state ^ PKVM_PAGE_STATE_VMEMMAP_MASK;
}
/*
--
2.53.0.1018.g2bb0e51243-goog
^ 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