* Re: [PATCH 08/16] media: v4l2-common: Add NV12_32L32 pixel format to v4l2 format info
From: Nicolas Dufresne @ 2026-05-19 15:23 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-9-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Represent the NV12_32L32 pixel format in the v4l2 format info table.
> This is a 32x32 tiled version of NV12.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 6194d6eb9c56..fe7141883ec5 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -315,6 +315,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 16, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
> + { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 32, 32, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
Same.
+ { .format = V4L2_PIX_FMT_NV12_32L32, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+ .block_w = { 32, 16, 0, 0 }, .block_h = { 32, 32, 0, 0 }},
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel, Anshuman Khandual
Cc: catalin.marinas, kernel-team, Will Deacon, Ryan Roberts,
David Hildenbrand, linux-kernel
In-Reply-To: <20260430053859.890613-1-anshuman.khandual@arm.com>
On Thu, 30 Apr 2026 06:38:59 +0100, Anshuman Khandual wrote:
> Avoid BUG_ON() while checking for inconsistent page table state conditions
> and instead replace them with VM_WARN_ON_ONCE().
>
>
Applied to arm64 (for-next/mm), thanks!
[1/1] arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()
https://git.kernel.org/arm64/c/13d0fdc09016
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3] iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Joerg Roedel, Anna Maniscalco
Cc: catalin.marinas, kernel-team, Will Deacon, iommu, linux-arm-msm,
linux-arm-kernel, linux-kernel, Rob Clark
In-Reply-To: <20260507-qcom_smmu_pmfix-v3-1-af8cd05831a2@gmail.com>
On Thu, 07 May 2026 17:43:15 +0200, Anna Maniscalco wrote:
> arm_smmu_write_context_bank() assumes it is being called with RPM
> active, but it turns out that is not guaranteed in the path from
> qcom_adreno_smmu_set_ttbr0_cfg(), so it's possible for the register
> writes to get lost when configuring the context bank while the GPU is
> idle, leading to page faults later.
> Add the RPM calls here to make sure the SMMU is active before we touch
> it.
>
> [...]
Applied to iommu (arm/smmu/updates), thanks!
[1/1] iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg
https://git.kernel.org/iommu/c/8a0aab012b52
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 0/6] Devicetree support for Glymur GPU
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Robin Murphy, Joerg Roedel, Akhil P Oommen
Cc: catalin.marinas, kernel-team, Will Deacon, linux-arm-msm,
devicetree, linux-kernel, dri-devel, freedreno, linux-arm-kernel,
iommu, Rajendra Nayak, Konrad Dybcio, Dmitry Baryshkov,
Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260513-glymur-gpu-dt-v4-0-f83832c3bc9a@oss.qualcomm.com>
On Wed, 13 May 2026 00:51:17 +0530, Akhil P Oommen wrote:
> This series adds the necessary Device Tree bits to enable GPU support
> on the Glymur-based CRD devices. The Adreno X2-85 GPU present in Glymur
> chipsets is based on the new Adreno A8x family of GPUs. It features a new
> slice architecture with 4 slices, significantly higher bandwidth
> throughput compared to mobile counterparts, raytracing support, and the
> highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other
> improvements.
>
> [...]
Applied SMMU bindings update to iommu (arm/smmu/bindings), thanks!
[3/6] dt-bindings: arm-smmu: Update the description for Glymur GPU SMMU
https://git.kernel.org/iommu/c/23bc2dd17b20
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 07/16] media: v4l2-common: Add NV12_16L16 pixel format to v4l2 format info
From: Nicolas Dufresne @ 2026-05-19 15:22 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-8-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Represent the NV12_16L16 pixel format in the v4l2 format info table.
> This is a 16x16 tiled version of NV12.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index e142d40c71b9..6194d6eb9c56 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -313,6 +313,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> + { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 16, 16, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
I suspect this is:
+ { .format = V4L2_PIX_FMT_NV12_16L16, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
+ .block_w = { 16, 8, 0, 0 }, .block_h = { 16, 16, 0, 0 }},
This was introduced for the Samsung MFC decoders on Exynos 5, has been matched
to V4L2_PIX_FMT_HM12, but I don't how it was tested though. But in this erra,
all the tiling was fixes dimensions in bytes, where your definition would make
the UV tiles twice the size of Y tiles.
Nicolas
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v8 0/4] backlight: add new max25014 backlight driver
From: Frank.Li @ 2026-05-19 15:22 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Maud Spierings
Cc: Frank Li, dri-devel, linux-leds, devicetree, linux-kernel,
linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <20260407-max25014-v8-0-14eac7ed673a@gocontroll.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 07 Apr 2026 16:41:41 +0200, Maud Spierings wrote:
> The Maxim MAX25014 is an automotive grade backlight driver IC. Its
> datasheet can be found at [1].
>
> With its integrated boost controller, it can power 4 channels (led
> strings) and has a number of different modes using pwm and or i2c.
> Currently implemented is only i2c control.
>
> [...]
Applied, thanks!
[3/4] arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
commit: 10fd5ba8fae66d60c65ec4bdb51fbbe5e34d9d83
[4/4] arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
commit: 159746425710c94befb317132816f5eece4ea25d
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v4 0/5] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-05-19 15:20 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Srinivas Kandagatla, Kees Cook, Gustavo A. R. Silva,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening
In-Reply-To: <d9e3e10a-c346-4391-b133-4b60fbee5dc3@gmx.net>
On Tue, May 19, 2026 at 04:55:10PM +0200, Stefan Wahren wrote:
> Hi Gregor,
>
> Am 08.05.26 um 16:42 schrieb Gregor Herburger:
> > Hi,
> >
> > This series adds support for the Raspberry Pis OTP registers. The
> > Raspberry Pi has one or more OTP regions. These registers are accessible
> > through the firmware. Add a driver for it and add updates the devicetree
> > for the Raspberry Pi 5.
> >
> > ---
> > Changes in v4:
> > - Additional patch to drop unnecessary select schema
> > - fix dt-bindings
> > - use __counted_by_le
> > - additional alignment check in read/write callbacks
> > - Link to v3: https://patch.msgid.link/20260506-rpi-otp-driver-v3-0-294602663695@linutronix.de
> >
> > Changes in v3:
> > - dts: add "raspberrypi,bcm2835-firmware" as fallback and fix dt-bindings
> > - Fix Kconfig depends
> > - Changed firmware data fields to __le32
> > - Add MODULE_ALIAS
> > - Link to v2: https://patch.msgid.link/20260505-rpi-otp-driver-v2-0-e9176ec72837@linutronix.de
> >
> > Changes in v2:
> > - register nvmem driver from firmware driver and drop firmware sub nodes
> > - Use struct_size and __counted_by for dynamic array
> > - Drop unneeded comment in Kconfig
> > - Use NVMEM_DEVID_NONE
> > - Use kzalloc
> > - Update module description
> > - Link to v1: https://patch.msgid.link/20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de
> >
> > ---
> > Gregor Herburger (5):
> > dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
> > nvmem: Add the Raspberry Pi OTP driver
> > firmware: raspberrypi: register nvmem driver
> > arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
> > dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
> >
> > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++--
> > .../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +-
> > drivers/firmware/raspberrypi.c | 59 +++++++++-
> > drivers/nvmem/Kconfig | 10 ++
> > drivers/nvmem/Makefile | 1 +
> > drivers/nvmem/raspberrypi-otp.c | 130 +++++++++++++++++++++
> > include/soc/bcm2835/raspberrypi-firmware.h | 14 +++
> > 7 files changed, 224 insertions(+), 14 deletions(-)
> since you plan to submit a V5 of this series, could you please append
> another patch to enable the driver as module for arm64/defconfig?
Good Idea, will add it.
Gregor
^ permalink raw reply
* Re: [PATCH v7 04/23] drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
From: Jonas Karlman @ 2026-05-19 15:18 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Heiko Stuebner,
Laurent Pinchart, Jernej Skrabec, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Cristian Ciocaltea, Louis Chauvet, Liu Ying, Sandy Huang,
Andy Yan, Chen-Yu Tsai, Christian Hewitt, Diederik de Haas,
Nicolas Frattaroli, Dmitry Baryshkov, dri-devel, linux-arm-kernel,
linux-rockchip, linux-amlogic, linux-sunxi, imx, linux-kernel
In-Reply-To: <177919241969.545972.18169905222569864569.b4-review@b4>
Hello Luca,
On 5/19/2026 2:06 PM, Luca Ceresoli wrote:
> On Mon, 18 May 2026 18:01:40 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
>
> Hello Jonas,
>
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index b7bfc0e9a6b2..9d795c550f8a 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2600,10 +2609,14 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>>
>> drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
>>
>> - drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>> - &dw_hdmi_connector_funcs,
>> - DRM_MODE_CONNECTOR_HDMIA,
>> - hdmi->ddc);
>> + ret = drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
>> + &dw_hdmi_connector_funcs,
>> + DRM_MODE_CONNECTOR_HDMIA,
>> + hdmi->ddc);
>> + if (ret)
>> + return ret;
>> +
>> + drm_bridge_get(&hdmi->bridge);
>
> I'm not fully following the code paths, but both the report and the fix
> make sense to me. Only I'd move the drm_bridge_get() before
> drm_connector_init_with_ddc(), to avoid a short window where no reference
> is held and the bridge might be destroyed before drm_bridge_get() is
> called. I'm not sure this can happen, but it's better to write the code in
> a way that clearly makes it impossible.
dw_hdmi_connector_create() is only called from dw_hdmi_bridge_attach()
so the bridge should already have a ref for the lifetime of this call.
I explicitly chose the placement after drm_connector_init_with_ddc()
to ensure ref count is correctly balanced without having to add a
drm_bridge_put() call in any error path. I.e. connector destroy() is
only called when drm_connector_init_with_ddc() succeeds.
This code/call is also planned to be removed in a future series, so I do
not think moving drm_bridge_get() is necessary unless you think we need
to protect against possible bad behavior from DRM core?
Regards,
Jonas
>
> Otherwise looks good.
>
> Luca
>
^ permalink raw reply
* [PATCH v5 12/13] arm64: mm: Map the kernel data/bss read-only in the linear map
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
On systems where the bootloader adheres to the original arm64 boot
protocol, the placement of the kernel in the physical address space is
highly predictable, and this makes the placement of its linear alias in
the kernel virtual address space equally predictable, given the lack of
randomization of the linear map.
The linear aliases of the kernel text and rodata regions are already
mapped read-only, but the kernel data and bss are mapped read-write in
this region. This is not needed, so map them read-only as well.
Note that the statically allocated kernel page tables do need to be
modifiable via the linear map, so leave these mapped read-write.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dcff1a538f20..136cfe0f7375 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1122,7 +1122,9 @@ static void __init map_mem(void)
{
static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
phys_addr_t kernel_start = __pa_symbol(_text);
- phys_addr_t kernel_end = __pa_symbol(__init_begin);
+ phys_addr_t init_begin = __pa_symbol(__init_begin);
+ phys_addr_t init_end = __pa_symbol(__init_end);
+ phys_addr_t kernel_end = __pa_symbol(__bss_stop);
phys_addr_t start, end;
int flags = NO_EXEC_MAPPINGS;
u64 i;
@@ -1155,7 +1157,11 @@ static void __init map_mem(void)
* of the region accessible to subsystems such as hibernate,
* but protects it from inadvertent modification or execution.
*/
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ __map_memblock(kernel_start, init_begin, pgprot_tagged(PAGE_KERNEL),
+ flags);
+
+ /* Map the kernel data/bss so it can be remapped later */
+ __map_memblock(init_end, kernel_end, pgprot_tagged(PAGE_KERNEL),
flags);
/* map all the memory banks */
@@ -1168,6 +1174,11 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
+
+ /* Map the kernel data/bss read-only in the linear map */
+ __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
+ flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
+ (unsigned long)lm_alias(__bss_stop));
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 10/13] arm64: Move fixmap page tables to end of kernel image
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Move the fixmap page tables out of the BSS section, and place them at
the end of the image, right before the init_pg_dir section where some of
the other statically allocated page tables live.
These page tables are currently the only data objects in vmlinux that
are meant to be accessed via the kernel image's linear alias, and so
placing them together allows the remainder of the data/bss section to be
remapped read-only or unmapped entirely.
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/kernel/vmlinux.lds.S | 10 ++++++++--
arch/arm64/mm/fixmap.c | 7 ++++---
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e1ac876200a3..64c7bf4b7176 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -349,10 +349,16 @@ SECTIONS
_edata = .;
/* start of zero-init region */
- BSS_SECTION(SBSS_ALIGN, 0, 0)
+ BSS_SECTION(SBSS_ALIGN, 0, PAGE_SIZE)
__pi___bss_start = __bss_start;
- . = ALIGN(PAGE_SIZE);
+ /* fixmap BSS starts here - preceding data/BSS is omitted from the linear map */
+ .fixmap_pgdir : ALIGN(PAGE_SIZE) {
+ *(.fixmap_bss)
+ }
+ ASSERT(ADDR(.fixmap_pgdir) == __bss_stop, ".fixmap_pgdir should follow BSS")
+
+
__pi_init_pg_dir = .;
. += INIT_DIR_SIZE;
__pi_init_pg_end = .;
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c5c5425791da..b649ea1a46e4 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -31,9 +31,10 @@ static_assert(NR_BM_PMD_TABLES == 1);
#define BM_PTE_TABLE_IDX(addr) __BM_TABLE_IDX(addr, PMD_SHIFT)
-static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __page_aligned_bss;
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
+#define __fixmap_bss __section(".fixmap_bss") __aligned(PAGE_SIZE)
+static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __fixmap_bss;
+static pmd_t bm_pmd[PTRS_PER_PMD] __fixmap_bss __maybe_unused;
+static pud_t bm_pud[PTRS_PER_PUD] __fixmap_bss __maybe_unused;
static inline pte_t *fixmap_pte(unsigned long addr)
{
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH 06/16] media: v4l2-common: Add missing tiled format info block sizes
From: Nicolas Dufresne @ 2026-05-19 15:18 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-7-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> Some YUV420 tiled format info definitions are missing block sizes.
> Add the missing block sizes (they are all 4x4).
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 77a0daa92c2b..e142d40c71b9 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -307,10 +307,12 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_GREY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
>
> /* Tiled YUV formats */
> - { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> + { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
.block_w = { 4, 2, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> { .format = V4L2_PIX_FMT_NV15_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
> - { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> + { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> + .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
.block_w = { 4, 2, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
This one is speecial, this format does not exists. I believe Jernej made that
one based on assumptions, the actual HW should produce NV15 4L4, but I don't own
that hardware, and so I never managed remove that last "user" of it, which is I
believe H6 VP9 decoder.
Nicolas
>
> /* YUV planar formats, non contiguous variant */
> { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v5 08/13] arm64: kfence: Avoid NOMAP tricks when mapping the early pool
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Now that the map_mem() routines respect existing page mappings and
contiguous granule sized blocks with the contiguous bit cleared, there
is no longer a reason to play tricks with the memblock NOMAP attribute.
Instead, the kfence pool can be allocated and mapped with page
granularity first, and this granularity will be respected when the rest
of DRAM is mapped later, even if block and contiguous mappings are
allowed for the remainder of those mappings.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 25 ++++----------------
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7cecd25aa83b..224fec6ce9d7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1067,36 +1067,24 @@ static int __init parse_kfence_early_init(char *arg)
}
early_param("kfence.sample_interval", parse_kfence_early_init);
-static phys_addr_t __init arm64_kfence_alloc_pool(void)
+static void __init arm64_kfence_map_pool(void)
{
phys_addr_t kfence_pool;
if (!kfence_early_init)
- return 0;
+ return;
kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE);
if (!kfence_pool) {
pr_err("failed to allocate kfence pool\n");
kfence_early_init = false;
- return 0;
- }
-
- /* Temporarily mark as NOMAP. */
- memblock_mark_nomap(kfence_pool, KFENCE_POOL_SIZE);
-
- return kfence_pool;
-}
-
-static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool)
-{
- if (!kfence_pool)
return;
+ }
/* KFENCE pool needs page-level mapping. */
__map_memblock(kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
pgprot_tagged(PAGE_KERNEL),
NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
- memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE);
__kfence_pool = phys_to_virt(kfence_pool);
}
@@ -1128,8 +1116,7 @@ bool arch_kfence_init_pool(void)
}
#else /* CONFIG_KFENCE */
-static inline phys_addr_t arm64_kfence_alloc_pool(void) { return 0; }
-static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool) { }
+static inline void arm64_kfence_map_pool(void) { }
#endif /* CONFIG_KFENCE */
@@ -1139,7 +1126,6 @@ static void __init map_mem(void)
phys_addr_t kernel_start = __pa_symbol(_text);
phys_addr_t kernel_end = __pa_symbol(__init_begin);
phys_addr_t start, end;
- phys_addr_t early_kfence_pool;
int flags = NO_EXEC_MAPPINGS;
u64 i;
@@ -1156,7 +1142,7 @@ static void __init map_mem(void)
BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end) &&
pgd_index(_PAGE_OFFSET(VA_BITS_MIN)) != PTRS_PER_PGD - 1);
- early_kfence_pool = arm64_kfence_alloc_pool();
+ arm64_kfence_map_pool();
linear_map_requires_bbml2 = !force_pte_mapping() && can_set_direct_map();
@@ -1195,7 +1181,6 @@ static void __init map_mem(void)
__map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
- arm64_kfence_map_pool(early_kfence_pool);
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 13/13] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The linear aliases of the kernel text and rodata are mapped read-only in
the linear map as well. Given that the contents of these regions are
mostly identical to the version in the loadable image, mapping them
read-only and leaving their contents visible is a reasonable hardening
measure.
Data and bss, however, are now also mapped read-only but the contents of
these regions are more likely to contain data that we'd rather not leak.
So let's unmap these entirely in the linear map when the kernel is
running normally.
When going into hibernation or waking up from it, these regions need to
be mapped, so map the region initially, and toggle the valid bit so
map/unmap the region as needed. (While the hibernation snapshot logic
seems able to map inaccessible pages as needed, it currently disregards
non-present pages entirely.)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 39 +++++++++++++++++---
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 136cfe0f7375..9b6d90deb6d5 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -24,6 +24,7 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/set_memory.h>
+#include <linux/suspend.h>
#include <linux/kfence.h>
#include <linux/pkeys.h>
#include <linux/mm_inline.h>
@@ -1040,6 +1041,29 @@ static void __init __map_memblock(phys_addr_t start, phys_addr_t end,
end - start, prot, early_pgtable_alloc, flags);
}
+static void remap_linear_data_alias(bool unmap)
+{
+ set_memory_valid((unsigned long)lm_alias(__init_end),
+ (unsigned long)(__bss_stop - __init_end) / PAGE_SIZE,
+ !unmap);
+}
+
+static int arm64_hibernate_pm_notify(struct notifier_block *nb,
+ unsigned long mode, void *unused)
+{
+ switch (mode) {
+ default:
+ break;
+ case PM_POST_HIBERNATION:
+ remap_linear_data_alias(true);
+ break;
+ case PM_HIBERNATION_PREPARE:
+ remap_linear_data_alias(false);
+ break;
+ }
+ return 0;
+}
+
void __init mark_linear_text_alias_ro(void)
{
/*
@@ -1048,6 +1072,16 @@ void __init mark_linear_text_alias_ro(void)
update_mapping_prot(__pa_symbol(_text), (unsigned long)lm_alias(_text),
(unsigned long)__init_begin - (unsigned long)_text,
PAGE_KERNEL_RO);
+
+ remap_linear_data_alias(true);
+
+ if (IS_ENABLED(CONFIG_HIBERNATION)) {
+ static struct notifier_block nb = {
+ .notifier_call = arm64_hibernate_pm_notify
+ };
+
+ register_pm_notifier(&nb);
+ }
}
#ifdef CONFIG_KFENCE
@@ -1174,11 +1208,6 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
-
- /* Map the kernel data/bss read-only in the linear map */
- __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
- flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
- (unsigned long)lm_alias(__bss_stop));
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 11/13] arm64: mm: Don't abuse memblock NOMAP to check for overlaps
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Now that the DRAM mapping routines respect existing table mappings and
contiguous block and page mappings, it is no longer needed to fiddle
with the memblock tables to set and clear the NOMAP attribute in order
to omit text and rodata when creating the linear map.
Instead, map the kernel text and rodata alias first with the desired
attributes, so that they will not be remapped later with different
attributes when mapping the memblocks.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 24 +++++++-------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index d4ad9e4766a6..dcff1a538f20 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1148,12 +1148,15 @@ static void __init map_mem(void)
flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
/*
- * Take care not to create a writable alias for the
- * read-only text and rodata sections of the kernel image.
- * So temporarily mark them as NOMAP to skip mappings in
- * the following for-loop
+ * Map the linear alias of the [_text, __init_begin) interval
+ * as non-executable now, and remove the write permission in
+ * mark_linear_text_alias_ro() above (which will be called after
+ * alternative patching has completed). This makes the contents
+ * of the region accessible to subsystems such as hibernate,
+ * but protects it from inadvertent modification or execution.
*/
- memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ flags);
/* map all the memory banks */
for_each_mem_range(i, &start, &end) {
@@ -1165,17 +1168,6 @@ static void __init map_mem(void)
__map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
-
- /*
- * Map the linear alias of the [_text, __init_begin) interval
- * as non-executable now, and remove the write permission in
- * mark_linear_text_alias_ro() below (which will be called after
- * alternative patching has completed). This makes the contents
- * of the region accessible to subsystems such as hibernate,
- * but protects it from inadvertent modification or execution.
- */
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL), 0);
- memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
}
void mark_rodata_ro(void)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 09/13] arm64: mm: Permit contiguous attribute for preliminary mappings
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
There are a few cases where we omit the contiguous hint for mappings
that start out as read-write and are remapped read-only later, on the
basis that manipulating live descriptors with the PTE_CONT attribute set
is unsafe. When support for the contiguous hint was added to the code,
the ARM ARM was ambiguous about this, and so we erred on the side of
caution.
In the meantime, this has been clarified [0], and regions that will be
remapped in their entirety can use the contiguous hint both in the
initial mapping as well as the one that replaces it. Note that this
requires that the logic that may be called to remap overlapping regions
respects existing valid descriptors that have the contiguous bit
cleared.
So omit the NO_CONT_MAPPINGS flag in places where it is unneeded.
Thanks to Ryan for the reference.
[0] RJQQTC
For a TLB lookup in a contiguous region mapped by translation table entries that
have consistent values for the Contiguous bit, but have the OA, attributes, or
permissions misprogrammed, that TLB lookup is permitted to produce an OA, access
permissions, and memory attributes that are consistent with any one of the
programmed translation table values.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 224fec6ce9d7..d4ad9e4766a6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1000,8 +1000,7 @@ void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
&phys, virt);
return;
}
- early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, 0);
}
void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -1028,8 +1027,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
return;
}
- early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ early_create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL, 0);
/* flush the TLBs after updating live kernel mappings */
flush_tlb_kernel_range(virt, virt + size);
@@ -1175,11 +1173,8 @@ static void __init map_mem(void)
* alternative patching has completed). This makes the contents
* of the region accessible to subsystems such as hibernate,
* but protects it from inadvertent modification or execution.
- * Note that contiguous mappings cannot be remapped in this way,
- * so we should avoid them here.
*/
- __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
- NO_CONT_MAPPINGS);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL), 0);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 07/13] arm64: mm: Permit contiguous descriptors to be rewritten
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Currently, pgattr_change_is_safe() is overly pedantic when it comes to
descriptors with the contiguous hint attribute set, as it rejects
assignments even if the old and the new value are the same.
So relax the check to allow that.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0405fac18959..7cecd25aa83b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -134,10 +134,6 @@ bool pgattr_change_is_safe(pteval_t old, pteval_t new)
if (pte_pfn(__pte(old)) != pte_pfn(__pte(new)))
return false;
- /* live contiguous mappings may not be manipulated at all */
- if ((old | new) & PTE_CONT)
- return false;
-
/* Transitioning from Non-Global to Global is unsafe */
if (old & ~new & PTE_NG)
return false;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 06/13] arm64: mm: Drop redundant pgd_t* argument from map_mem()
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
__map_memblock() and map_mem() always operate on swapper_pg_dir, so
there is no need to pass around a pgd_t pointer between them.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 26 ++++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index cd841a392b44..0405fac18959 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1039,11 +1039,11 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
flush_tlb_kernel_range(virt, virt + size);
}
-static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
- phys_addr_t end, pgprot_t prot, int flags)
+static void __init __map_memblock(phys_addr_t start, phys_addr_t end,
+ pgprot_t prot, int flags)
{
- early_create_pgd_mapping(pgdp, start, __phys_to_virt(start), end - start,
- prot, early_pgtable_alloc, flags);
+ early_create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
+ end - start, prot, early_pgtable_alloc, flags);
}
void __init mark_linear_text_alias_ro(void)
@@ -1091,13 +1091,13 @@ static phys_addr_t __init arm64_kfence_alloc_pool(void)
return kfence_pool;
}
-static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool, pgd_t *pgdp)
+static void __init arm64_kfence_map_pool(phys_addr_t kfence_pool)
{
if (!kfence_pool)
return;
/* KFENCE pool needs page-level mapping. */
- __map_memblock(pgdp, kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
+ __map_memblock(kfence_pool, kfence_pool + KFENCE_POOL_SIZE,
pgprot_tagged(PAGE_KERNEL),
NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE);
@@ -1133,11 +1133,11 @@ bool arch_kfence_init_pool(void)
#else /* CONFIG_KFENCE */
static inline phys_addr_t arm64_kfence_alloc_pool(void) { return 0; }
-static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool, pgd_t *pgdp) { }
+static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool) { }
#endif /* CONFIG_KFENCE */
-static void __init map_mem(pgd_t *pgdp)
+static void __init map_mem(void)
{
static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
phys_addr_t kernel_start = __pa_symbol(_text);
@@ -1182,7 +1182,7 @@ static void __init map_mem(pgd_t *pgdp)
* if MTE is present. Otherwise, it has the same attributes as
* PAGE_KERNEL.
*/
- __map_memblock(pgdp, start, end, pgprot_tagged(PAGE_KERNEL),
+ __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
flags);
}
@@ -1196,10 +1196,10 @@ static void __init map_mem(pgd_t *pgdp)
* Note that contiguous mappings cannot be remapped in this way,
* so we should avoid them here.
*/
- __map_memblock(pgdp, kernel_start, kernel_end,
- pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
+ __map_memblock(kernel_start, kernel_end, pgprot_tagged(PAGE_KERNEL),
+ NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
- arm64_kfence_map_pool(early_kfence_pool, pgdp);
+ arm64_kfence_map_pool(early_kfence_pool);
}
void mark_rodata_ro(void)
@@ -1421,7 +1421,7 @@ static void __init create_idmap(void)
void __init paging_init(void)
{
- map_mem(swapper_pg_dir);
+ map_mem();
memblock_allow_resize();
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 04/13] arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Instead of blindly overwriting existing live entries with the contiguous
bit cleared when mapping DRAM regions, check whether the contiguous
region in question starts with a descriptor that has the valid bit set
and the contiguous bit cleared, and in that case, leave the contiguous
bit unset on the entire region. This permits the logic of mapping the
kernel's linear alias to be simplified in a subsequent patch.
Note that not setting the contiguous bit on any of the descriptors in
the contiguous region can only result in an invalid configuration if it
was already invalid to begin with.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 4 ++++
arch/arm64/mm/mmu.c | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4dfa42b7d053..a1c5894332d9 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -181,6 +181,10 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
* Returns true if the pte is valid and has the contiguous bit set.
*/
#define pte_valid_cont(pte) (pte_valid(pte) && pte_cont(pte))
+/*
+ * Returns true if the pte is valid and has the contiguous bit cleared.
+ */
+#define pte_valid_noncont(pte) (pte_valid(pte) && !pte_cont(pte))
/*
* Could the pte be present in the TLB? We must check mm_tlb_flush_pending
* so that we don't erroneously return false for pages that have been
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index bd2764f02a7d..4c6ef0d35714 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -224,7 +224,8 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
/* use a contiguous mapping if the range is suitably aligned */
if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
- (flags & NO_CONT_MAPPINGS) == 0)
+ (flags & NO_CONT_MAPPINGS) == 0 &&
+ !pte_valid_noncont(__ptep_get(ptep)))
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
init_pte(ptep, addr, next, phys, __prot);
@@ -324,7 +325,8 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
/* use a contiguous mapping if the range is suitably aligned */
if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
- (flags & NO_CONT_MAPPINGS) == 0)
+ (flags & NO_CONT_MAPPINGS) == 0 &&
+ !pte_valid_noncont(pmd_pte(READ_ONCE(*pmdp))))
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
ret = init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc, flags);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 05/13] arm64: mm: Remove bogus stop condition from map_mem() loop
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The memblock API guarantees that start is not greater than or equal to
end, so there is no need to test it. And if it were, it is doubtful that
breaking out of the loop would be a reasonable course of action here
(rather than attempting to map the remaining regions)
So let's drop this check.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4c6ef0d35714..cd841a392b44 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1177,8 +1177,6 @@ static void __init map_mem(pgd_t *pgdp)
/* map all the memory banks */
for_each_mem_range(i, &start, &end) {
- if (start >= end)
- break;
/*
* The linear map must allow allocation tags reading/writing
* if MTE is present. Otherwise, it has the same attributes as
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 03/13] arm64: mm: Preserve existing table mappings when mapping DRAM
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Instead of blindly overwriting an existing table entry when mapping DRAM
regions, take care not to replace a pre-existing table entry with a
block entry. This permits the logic of mapping the kernel's linear alias
to be simplified in a subsequent patch.
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0c3d97f120e1..bd2764f02a7d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -256,7 +256,8 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
/* try section mapping first */
if (((addr | next | phys) & ~PMD_MASK) == 0 &&
- (flags & NO_BLOCK_MAPPINGS) == 0) {
+ (flags & NO_BLOCK_MAPPINGS) == 0 &&
+ !pmd_table(old_pmd)) {
pmd_set_huge(pmdp, phys, prot);
/*
@@ -379,7 +380,8 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
*/
if (pud_sect_supported() &&
((addr | next | phys) & ~PUD_MASK) == 0 &&
- (flags & NO_BLOCK_MAPPINGS) == 0) {
+ (flags & NO_BLOCK_MAPPINGS) == 0 &&
+ !pud_table(old_pud)) {
pud_set_huge(pudp, phys, prot);
/*
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 02/13] mm: Make empty_zero_page[] const
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening, Kevin Brodsky, Feng Tang
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The empty zero page is used to back any kernel or user space mapping
that is supposed to remain cleared, and so the page itself is never
supposed to be modified.
So mark it as const, which moves it into .rodata rather than .bss: on
most architectures, this ensures that both the kernel's mapping of it
and any aliases that are accessible via the kernel direct (linear) map
are mapped read-only, and cannot be used (inadvertently or maliciously)
to corrupt the contents of the zero page.
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Jann Horn <jannh@google.com>
Reviewed-by: Feng Tang <feng.tang@linux.alibaba.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
include/linux/pgtable.h | 2 +-
mm/mm_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index cdd68ed3ae1a..67aa23814010 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1993,7 +1993,7 @@ static inline unsigned long zero_pfn(unsigned long addr)
return zero_page_pfn;
}
-extern uint8_t empty_zero_page[PAGE_SIZE];
+extern const uint8_t empty_zero_page[PAGE_SIZE];
extern struct page *__zero_page;
static inline struct page *_zero_page(unsigned long addr)
diff --git a/mm/mm_init.c b/mm/mm_init.c
index f9f8e1af921c..46cf001238c5 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -57,7 +57,7 @@ unsigned long zero_page_pfn __ro_after_init;
EXPORT_SYMBOL(zero_page_pfn);
#ifndef __HAVE_COLOR_ZERO_PAGE
-uint8_t empty_zero_page[PAGE_SIZE] __page_aligned_bss;
+const uint8_t empty_zero_page[PAGE_SIZE] __aligned(PAGE_SIZE);
EXPORT_SYMBOL(empty_zero_page);
struct page *__zero_page __ro_after_init;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 01/13] arm64: mm: Map the linear alias of text/rodata as tagged
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
In-Reply-To: <20260519151616.2557018-15-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Before moving the empty_zero_page into the .rodata section, make
sure its linear alias has the memory-tagged type. This is needed to
ensure that cpu_enable_mte() will be able to initialize the tags
correctly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dd85e093ffdb..0c3d97f120e1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1195,7 +1195,7 @@ static void __init map_mem(pgd_t *pgdp)
* so we should avoid them here.
*/
__map_memblock(pgdp, kernel_start, kernel_end,
- PAGE_KERNEL, NO_CONT_MAPPINGS);
+ pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
arm64_kfence_map_pool(early_kfence_pool, pgdp);
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v5 00/13] arm64: Unmap linear alias of kernel data/bss
From: Ard Biesheuvel @ 2026-05-19 15:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, Mike Rapoport, David Hildenbrand, Andrew Morton,
Jann Horn, linux-mm, linux-hardening
From: Ard Biesheuvel <ardb@kernel.org>
One of the reasons the lack of randomization of the linear map on arm64
is considered problematic is the fact that bootloaders adhering to the
original arm64 boot protocol (i.e., a substantial fraction of all
Android phones) may place the kernel at the base of DRAM, and therefore
at the base of the non-randomized linear map. This puts a writable alias
of the kernel's data and bss regions at a predictable location, removing
the need for an attacker to guess where KASLR mapped the kernel.
Let's unmap this linear, writable alias entirely, so that knowing the
location of the linear alias does not give write access to the kernel's
data and bss regions.
Changes since v4:
- Update the correct [early] mapping in patch #1
- Make empty_zero_page[] const instead of __ro_after_init
- Drop patches that remap the fixmap page tables r/o for now
- Don't force page mappings for the data/bss linear alias, as it is no
longer needed for set_memory_valid()
- Add acks
Changes since v3:
- Drop bogus patch adding hierarchical PXN to the fixmap mapping, which
breaks the KPTI trampoline (thanks to Sashiko)
- Add generic patch to move the empty_zero_page to __ro_after_init, as
it now lives in generic code.
- Add patches to remap the linear aliases of the fixmap page tables
read-only too - these live at an a priori known offset in the linear
map if physical KASLR was omitted, and control a priori known
addresses in the virtual kernel space.
- Rebase onto v7.1-rc1
Changes since v2:
- Keep bm_pte[] in the region that is remapped r/o or unmapped, as it is
only manipulated via its kernel alias
- Drop check that prohibits any manipulation of descriptors with the
CONT bit set
- Add Ryan's ack to a couple of patches
- Rebase onto v7.0-rc4
Changes since v1:
- Put zero page patch at the start of the series
- Tweak __map_memblock() API to respect existing table and contiguous
mappings, so that the logic to map the kernel alias can be simplified
- Stop abusing the MEMBLOCK_NOMAP flag to initially omit the kernel
linear alias from the linear map
- Some additional cleanup patches
- Use proper API [set_memory_valid()] to (un)map the linear alias of
data/bss.
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc; Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Liz Prucka <lizprucka@google.com>
Cc: Seth Jenkins <sethjenkins@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: linux-mm@kvack.org
Cc: linux-hardening@vger.kernel.org
Ard Biesheuvel (13):
arm64: mm: Map the linear alias of text/rodata as tagged
mm: Make empty_zero_page[] const
arm64: mm: Preserve existing table mappings when mapping DRAM
arm64: mm: Preserve non-contiguous descriptors when mapping DRAM
arm64: mm: Remove bogus stop condition from map_mem() loop
arm64: mm: Drop redundant pgd_t* argument from map_mem()
arm64: mm: Permit contiguous descriptors to be rewritten
arm64: kfence: Avoid NOMAP tricks when mapping the early pool
arm64: mm: Permit contiguous attribute for preliminary mappings
arm64: Move fixmap page tables to end of kernel image
arm64: mm: Don't abuse memblock NOMAP to check for overlaps
arm64: mm: Map the kernel data/bss read-only in the linear map
arm64: mm: Unmap kernel data/bss entirely from the linear map
arch/arm64/include/asm/pgtable.h | 4 +
arch/arm64/kernel/vmlinux.lds.S | 10 +-
arch/arm64/mm/fixmap.c | 7 +-
arch/arm64/mm/mmu.c | 134 +++++++++++---------
include/linux/pgtable.h | 2 +-
mm/mm_init.c | 2 +-
6 files changed, 90 insertions(+), 69 deletions(-)
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank.Li @ 2026-05-19 15:17 UTC (permalink / raw)
To: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liu Ying
Cc: Frank Li, imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260407-tianma-tm050rdh03-imx93-9x9-qsb-v1-1-24d514a62fdc@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 07 Apr 2026 17:15:31 +0800, Liu Ying wrote:
> Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
>
> The panel connects with the QSB board through an adapter board[1]
> designed by NXP.
Applied, thanks!
[1/1] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
commit: e19f72999dd1bdacd2d15957919557c9457067ac
Add description about create common dtsi part in commit message.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 05/16] media: v4l2-common: Fix NV15_4L4 format info block height
From: Nicolas Dufresne @ 2026-05-19 15:16 UTC (permalink / raw)
To: Paul Kocialkowski, linux-media, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-staging
Cc: Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Greg Kroah-Hartman, Arash Golgol,
Laurent Pinchart
In-Reply-To: <20260518102451.417971-6-paulk@sys-base.io>
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
Le lundi 18 mai 2026 à 12:24 +0200, Paul Kocialkowski a écrit :
> The NV15_4L4 format is specified as a 4x4 format, not 4x1.
> In addition the block size should not take subsampling in account,
> so specify it as 4x4 for both luma and chroma.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 554c591e1113..77a0daa92c2b 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -309,7 +309,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> /* Tiled YUV formats */
> { .format = V4L2_PIX_FMT_NV12_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> { .format = V4L2_PIX_FMT_NV15_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> - .block_w = { 4, 2, 0, 0 }, .block_h = { 1, 1, 0, 0 }},
> + .block_w = { 4, 4, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
Only the block_h is broken. The block_w is in "pixels" which for the UV plane is
component pairs. So both set of tiles have 5bytes stride. But since the second
set, the UV tiles, are interleaved, they only have 2 pairs of UV per row. So to
me the correct fix is:
+ .block_w = { 4, 2, 0, 0 }, .block_h = { 4, 4, 0, 0 }},
If its not the case for the camera pipeline, then a new format is needed, since
this format should perfectly match NV15 + VIVANTE_TILED in the DRM world.
regards,
Nicolas
> { .format = V4L2_PIX_FMT_P010_4L4, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 2, 4, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
>
> /* YUV planar formats, non contiguous variant */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox