* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-04-03 4:43 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <m3ldf4mzh4.fsf@t19.piap.pl>
Krzysztof Hałasa <khalasa@piap.pl> writes:
> Also, the 25 ms in the patch (commit) message is no longer accurate.
Aaah, it's before 7 a.m. here :-)
On the second try I was finally able to parse that sentence. Perhaps.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* [PATCH] ARM: devtree: validate compatible strings before dumping them
From: Pengpeng Hou @ 2026-04-03 2:41 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, pengpeng
setup_machine_fdt() dumps the root compatible list on the
unsupported-machine path by walking raw property bytes with strlen() and
early_print("%s"). Flat DT properties are external boot input, and this
path does not prove that the compatible string list is NUL-terminated
within its declared bounds.
Switch the local walk to fdt_stringlist_get() so malformed
unterminated entries are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/kernel/devtree.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 3b78966e750a..a9593479305e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -10,6 +10,7 @@
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/memblock.h>
+#include <linux/libfdt.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
@@ -207,19 +208,16 @@ const struct machine_desc * __init setup_machine_fdt(void *dt_virt)
if (!mdesc) {
const char *prop;
- int size;
+ int idx = 0;
unsigned long dt_root;
early_print("\nError: unrecognized/unsupported "
"device tree compatible list:\n[ ");
dt_root = of_get_flat_dt_root();
- prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
- while (size > 0) {
+ while ((prop = fdt_stringlist_get(initial_boot_params, dt_root,
+ "compatible", idx++, NULL)))
early_print("'%s' ", prop);
- size -= strlen(prop) + 1;
- prop += strlen(prop) + 1;
- }
early_print("]\n\n");
dump_machine_table(); /* does not return */
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: at91: validate memory node device_type strings
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: linux-arm-kernel, linux-kernel, pengpeng
at91_pm_backup_scan_memcs() fetches the raw device_type property and
immediately compares it with strcmp(). Flat DT properties are external
boot input, and this path does not prove that the property is
NUL-terminated within its declared bounds.
Use fdt_stringlist_get() so malformed unterminated device_type
properties are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/mach-at91/pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 68bb4a86cd94..0767fc9f30ab 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -8,6 +8,7 @@
#include <linux/genalloc.h>
#include <linux/io.h>
+#include <linux/libfdt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
@@ -1044,7 +1045,8 @@ static int __init at91_pm_backup_scan_memcs(unsigned long node,
if (*located)
return 0;
- type = of_get_flat_dt_prop(node, "device_type", NULL);
+ type = fdt_stringlist_get(initial_boot_params, node, "device_type",
+ 0, NULL);
/* We are scanning "memory" nodes only. */
if (!type || strcmp(type, "memory"))
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: xen: validate hypervisor compatible before parsing its version
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, linux-arm-kernel, linux-kernel, pengpeng
fdt_find_hyper_node() reads the raw compatible property and then
derives hyper_node.version from a prefix match before later printing it
with %s. Flat DT properties are external boot input, and this path does
not prove that the compatible string is NUL-terminated within its
declared bounds.
Fetch the first compatible entry with fdt_stringlist_get() so malformed
unterminated properties are rejected before the version suffix is
parsed.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/xen/enlighten.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 4feed2c2498d..f69290a4c639 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -19,6 +19,7 @@
#include <asm/efi.h>
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
+#include <linux/libfdt.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
@@ -218,8 +219,9 @@ static __initdata struct {
static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
int depth, void *data)
{
- const void *s = NULL;
+ const char *s = NULL;
int len;
+ size_t prefix_len = strlen(hyper_node.prefix);
if (depth != 1 || strcmp(uname, "hypervisor") != 0)
return 0;
@@ -227,10 +229,10 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
if (of_flat_dt_is_compatible(node, hyper_node.compat))
hyper_node.found = true;
- s = of_get_flat_dt_prop(node, "compatible", &len);
- if (strlen(hyper_node.prefix) + 3 < len &&
- !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
- hyper_node.version = s + strlen(hyper_node.prefix);
+ s = fdt_stringlist_get(initial_boot_params, node, "compatible", 0, &len);
+ if (s && len > prefix_len + 2 &&
+ !strncmp(hyper_node.prefix, s, prefix_len))
+ hyper_node.version = s + prefix_len;
/*
* Check if Xen supports EFI by checking whether there is the
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] ARM: mvebu: validate memory node device_type strings
From: Pengpeng Hou @ 2026-04-03 2:42 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-kernel, pengpeng
mvebu_scan_mem() fetches the raw device_type property and immediately
compares it with strcmp(). Flat DT properties are external boot input,
and this path does not prove that the property is NUL-terminated within
its declared bounds.
Use fdt_stringlist_get() so malformed unterminated device_type
properties are rejected before they are used as C strings.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/mach-mvebu/board-v7.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a0740ab0dca9..f867f6233108 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/libfdt.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
#include <linux/io.h>
@@ -66,7 +67,8 @@ void __iomem *mvebu_get_scu_base(void)
static int __init mvebu_scan_mem(unsigned long node, const char *uname,
int depth, void *data)
{
- const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ const char *type = fdt_stringlist_get(initial_boot_params, node,
+ "device_type", 0, NULL);
const __be32 *reg, *endp;
int l;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [soc:drivers/reset] BUILD SUCCESS d373605cd514837d8a6de3d00c786d4bae6dbaf8
From: kernel test robot @ 2026-04-03 5:57 UTC (permalink / raw)
To: Philipp Zabel; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/reset
branch HEAD: d373605cd514837d8a6de3d00c786d4bae6dbaf8 Merge tag 'reset-fixes-for-v7.0-2' into reset/next
elapsed time: 740m
configs tested: 171
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-002-20260403 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm orion5x_defconfig clang-23
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-004-20260403 gcc-10.5.0
arm vf610m4_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-004-20260403 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-002-20260403 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-002-20260403 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-006-20260403 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260403 gcc-14
i386 randconfig-002-20260403 gcc-14
i386 randconfig-003-20260403 gcc-14
i386 randconfig-004-20260403 gcc-14
i386 randconfig-005-20260403 gcc-14
i386 randconfig-006-20260403 gcc-14
i386 randconfig-007-20260403 gcc-14
i386 randconfig-011-20260403 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-017-20260403 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-002-20260403 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-002-20260403 clang-23
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc tqm5200_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-002-20260403 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-002-20260403 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh magicpanelr2_defconfig gcc-15.2.0
sh randconfig-001-20260403 clang-23
sh randconfig-002-20260403 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-002-20260403 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-002-20260403 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260403 clang-20
um randconfig-002-20260403 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260403 clang-20
x86_64 randconfig-002-20260403 clang-20
x86_64 randconfig-003-20260403 clang-20
x86_64 randconfig-004-20260403 clang-20
x86_64 randconfig-005-20260403 clang-20
x86_64 randconfig-006-20260403 clang-20
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-076-20260403 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-002-20260403 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] arm: kernel: add NULL pointer check in early_mem()
From: Austin Kim @ 2026-04-03 6:08 UTC (permalink / raw)
To: linux; +Cc: linux-arm-kernel, linux-kernel, austindh.kim
The 'early_mem' function handles memory-related boot parameters.
If the parameter 'p' is passed as NULL, it could lead to an
uninitialized or invalid memory access during parsing.
This patch adds a NULL pointer check at the beginning of the
function to return early if no argument is provided, ensuring
system stability during the early boot process.
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
---
arch/arm/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 0bfd66c7a..b718a7df3 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -830,6 +830,8 @@ static int __init early_mem(char *p)
u64 start;
char *endp;
+ if (!p)
+ return 1;
/*
* If the user specifies memory size, we
* blow away any automatically generated
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Maxime Chevallier @ 2026-04-03 6:14 UTC (permalink / raw)
To: Russell King (Oracle), Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Ovidiu Panait,
Vladimir Oltean, Baruch Siach, Serge Semin, Giuseppe Cavallaro,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <ac6kfQ98Xjt3dCGj@shell.armlinux.org.uk>
Hi Russell
On 02/04/2026 19:16, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 09:19:27PM -0700, Sam Edwards wrote:
>> Hi netdev,
>>
>> This is v4 of my series containing a pair of bugfixes for the stmmac driver's
>> receive pipeline. These issues occur when stmmac_rx_refill() does not (fully)
>> succeed, which happens more frequently when free memory is low.
>>
>> The first patch closes Bugzilla bug #221010 [1], where stmmac_rx() can circle
>> around to a still-dirty descriptor (with a NULL buffer pointer), mistake it for
>> a filled descriptor (due to OWN=0), and attempt to dereference the buffer.
>>
>> In testing that patch, I discovered a second issue: starvation of available RX
>> buffers causes the NIC to stop sending interrupts; if the driver stops polling,
>> it will wait indefinitely for an interrupt that will never come. (Note: the
>> first patch makes this issue more prominent -- mostly because it lets the
>> system survive long enough to exhibit it -- but doesn't *cause* it.) The second
>> patch addresses that problem as well.
>>
>> Both patches are minimal, appropriate for stable, and designated to `net`. My
>> focus is on small, obviously-correct, easy-to-explain changes: I'll follow up
>> with another patch/series (something like [2]) for `net-next` that fixes the
>> ring in a more robust way.
>>
>> The tx and zc paths seem to have similar low-memory bugs, to be addressed in
>> separate series.
>
> I've tested this on my Jetson Xavier platform. One of the issues I've
> had is that running iperf3 results in the receive side stalling because
> it runs out of descriptors. However, despite the receive ring
> eventually being re-filled and the hardware appropriately prodded, it
> steadfastly refuses to restart, despite the descriptors having been
> updated.
>
> What I can see is there's 40 packets in the internal FIFOs via the
> PRXQ[13:0] field of the ETH_MTLRXQxDR register.
>
> With your patches applied:
>
> root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
> Connecting to host 192.168.248.1, port 5201
> Reverse mode, remote host 192.168.248.1 is sending
> [ 5] local 192.168.248.174 port 43728 connected to 192.168.248.1 port 5201
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-1.00 sec 30.3 MBytes 254 Mbits/sec
> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
> ...
Ah !!
I have been struggling with that problem this week too. I stumbled upon
it while trying to test your TSO series, and at firts I thought it was
because of the TSO patches, but turns out it's not, I reproduce it on
net-next.
The main problem for me is that it's not always reproducible, it may or
may not show up when I run iperf3 after a fresh restart.
This is on socfpga (dwmac1000), so it seems the problem exists across IP
versions.
I've been on and off trying to make progress on that during the week,
but without success so far...
Maxime
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Andrew Morton @ 2026-04-03 6:31 UTC (permalink / raw)
To: Sourabh Jain
Cc: Coiby Xu, kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Krzysztof Kozlowski, Rob Herring, Thomas Staudt, Will Deacon,
Christophe Leroy (CS GROUP), Catalin Marinas, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Saravana Kannan, open list
In-Reply-To: <51761fcf-955f-45e2-97a5-2b49d8e79d04@linux.ibm.com>
On Thu, 2 Apr 2026 16:24:14 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:
> But while reading crash_load_dm_crypt_keys() I noticed a possibility of a
> double free at the address pointed by `keys_header`:
>
> In crash_load_dm_crypt_keys()/crash_dump_dm_crypt.c
> snip...
>
> kbuf.buffer = keys_header;
>
> snip....
>
> r = kexec_add_buffer(&kbuf);
> if (r) {
> pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
> kvfree((void *)kbuf.buffer); <---
> First Free
> return r;
> }
>
> Since `keys_header` is not reset, the next call to build_keys_header()
> will cause a double free at `keys_header`.
>
> static int build_keys_header(void)
> {
>
> snip...
>
> if (keys_header != NULL)
> kvfree(keys_header);
>
> snip...
> }
>
> What do you think?
It looks that way to me.
^ permalink raw reply
* Re: [PATCH 0/5] crc64: Tweak intrinsics code and enable it for ARM
From: Ard Biesheuvel @ 2026-04-03 6:49 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, linux-arm-kernel, Demian Shulhan
In-Reply-To: <20260402234028.GA2256@sol>
On Fri, 3 Apr 2026, at 01:40, Eric Biggers wrote:
> On Thu, Apr 02, 2026 at 10:52:17AM +0200, Ard Biesheuvel wrote:
>>
>> On Wed, 1 Apr 2026, at 21:59, Eric Biggers wrote:
>> > On Mon, Mar 30, 2026 at 04:46:31PM +0200, Ard Biesheuvel wrote:
>> >> Apply some tweaks to the new arm64 crc64 NEON intrinsics code, and wire
>> >> it up for the 32-bit ARM build. Note that true 32-bit ARM CPUs usually
>> >> don't implement the prerequisite 64x64 PMULL instructions, but 32-bit
>> >> kernels are commonly used on 64-bit capable hardware too, which do
>> >> implement the 32-bit versions of the crypto instructions if they are
>> >> implemented for the 64-bit ISA (as per the architecture).
>> >>
>> >> Cc: Demian Shulhan <demyansh@gmail.com>
>> >> Cc: Eric Biggers <ebiggers@kernel.org>
>> >>
>> >> Ard Biesheuvel (5):
>> >> lib/crc: arm64: Drop unnecessary chunking logic from crc64
>> >> lib/crc: arm64: Use existing macros for kernel-mode FPU cflags
>> >> ARM: Add a neon-intrinsics.h header like on arm64
>> >> lib/crc: arm64: Simplify intrinsics implementation
>> >> lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
>> >
>> > I think patches 3 and 4 should be swapped, so it's cleanups first (which
>> > make sense regardless of the 32-bit ARM support) and then the 32-bit ARM
>> > support.
>> >
>>
>> Ok.
>
> I can also apply patches 1-2 and 4 now if you want. Let me know if I
> should do that or if a new version is coming.
>
Yes, good idea. I'll take care of the ARM stuff next cycle.
^ permalink raw reply
* [PATCH v6 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on tag: next-20260327, linux-next/master
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 46 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 ++++++++++++++++++
3 files changed, 95 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v6 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 8c684756d5fc..786cc2942c3a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1867,6 +1867,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1898,6 +1902,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1937,6 +1973,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin, Krzysztof Kozlowski
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 46 +++++++++++++++----
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..6596b686980c 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,20 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
power-domains:
maxItems: 1
@@ -60,6 +67,29 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+ clock-names:
+ minItems: 1
+ maxItems: 1
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v6 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-03 6:49 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin, Krzysztof Kozlowski
In-Reply-To: <20260403064912.17259-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..19948ed25f98 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,16 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -34,6 +37,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
--
2.45.2
^ permalink raw reply related
* [PATCH v1 3/4] drm/rockchip: dw_hdmi: Apply DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
drm_bridge_connector framework which is the current DRM bridge best
practice.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index e7f49fe845ea..69b832d0c8c4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -76,6 +76,7 @@ config ROCKCHIP_DW_DP
config ROCKCHIP_DW_HDMI
bool "Rockchip specific extensions for Synopsys DW HDMI"
+ select DRM_BRIDGE_CONNECTOR
help
This selects support for Rockchip SoC specific extensions
for the Synopsys DesignWare HDMI driver. If you want to
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 21b141b7cb9c..b5cfcb936078 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -13,6 +13,7 @@
#include <linux/regulator/consumer.h>
#include <drm/bridge/dw_hdmi.h>
+#include <drm/drm_bridge_connector.h>
#include <drm/drm_edid.h>
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
@@ -542,6 +543,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct rockchip_hdmi *hdmi;
+ struct drm_connector *connector;
int ret;
if (!pdev->dev.of_node)
@@ -608,7 +610,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -616,12 +618,21 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
*/
if (IS_ERR(hdmi->hdmi)) {
ret = PTR_ERR(hdmi->hdmi);
- goto err_bind;
+ goto err_cleanup_encoder;
}
- return 0;
+ connector = drm_bridge_connector_init(drm, encoder);
+ if (IS_ERR(connector)) {
+ ret = PTR_ERR(connector);
+ dev_err(hdmi->dev, "Failed to initialize bridge_connector\n");
+ goto err_unbind_bridge;
+ }
-err_bind:
+ return drm_connector_attach_encoder(connector, encoder);
+
+err_unbind_bridge:
+ dw_hdmi_unbind(hdmi->hdmi);
+err_cleanup_encoder:
drm_encoder_cleanup(encoder);
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/4] drm/bridge: dw-hdmi: Pass bridge attach flags for dw_hdmi_bind()
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
For Rockchip and Allwinner platforms, the HDMI encoder attaches the
dw-hdmi bridge via dw_hdmi_bind(). This additional bridge attach flag
serves as preparation for the Rockchip dw-hdmi driver to support the
bridge-connector framework.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 +++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
include/drm/bridge/dw_hdmi.h | 4 +++-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ada45e8b3e2c..dd50dda3a4f5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3619,7 +3619,8 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
*/
struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
struct drm_encoder *encoder,
- const struct dw_hdmi_plat_data *plat_data)
+ const struct dw_hdmi_plat_data *plat_data,
+ enum drm_bridge_attach_flags flags)
{
struct dw_hdmi *hdmi;
int ret;
@@ -3628,7 +3629,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
if (IS_ERR(hdmi))
return hdmi;
- ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, 0);
+ ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, flags);
if (ret) {
dw_hdmi_remove(hdmi);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 0dc1eb5d2ae3..21b141b7cb9c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -608,7 +608,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 96532709c2a7..04173335f7e7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -188,7 +188,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
- hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, 0);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 8500dd4f99d8..e789fb451ef2 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -6,6 +6,7 @@
#ifndef __DW_HDMI__
#define __DW_HDMI__
+#include <drm/drm_bridge.h>
#include <sound/hdmi-codec.h>
struct drm_display_info;
@@ -182,7 +183,8 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi);
void dw_hdmi_unbind(struct dw_hdmi *hdmi);
struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
struct drm_encoder *encoder,
- const struct dw_hdmi_plat_data *plat_data);
+ const struct dw_hdmi_plat_data *plat_data,
+ enum drm_bridge_attach_flags flags);
void dw_hdmi_resume(struct dw_hdmi *hdmi);
--
2.34.1
^ permalink raw reply related
* [PATCH v1 4/4] drm/rockchip: dw_hdmi: Support to find the next bridge
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
If there is a remote node connected to the HDMI output (port@1), the
&dw_hdmi_plat_data.output_port should be set to 1. This patch allows
Rockchip dw-hdmi to support the hdmi-connector and the next bridge.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b5cfcb936078..014ac09fd733 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -544,6 +544,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
struct drm_encoder *encoder;
struct rockchip_hdmi *hdmi;
struct drm_connector *connector;
+ struct device_node *remote;
+ struct drm_bridge *next_bridge;
int ret;
if (!pdev->dev.of_node)
@@ -610,6 +612,18 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
platform_set_drvdata(pdev, hdmi);
+ remote = of_graph_get_remote_node(hdmi->dev->of_node, 1, -1);
+ if (remote) {
+ of_node_put(remote);
+
+ ret = drm_of_find_panel_or_bridge(hdmi->dev->of_node, 1, 0,
+ NULL, &next_bridge);
+ if (ret && ret != -ENODEV)
+ goto err_cleanup_encoder;
+
+ plat_data->output_port = 1;
+ }
+
hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v1 0/4] Apply bridge-connector for the Rockchip DW-HDMI driver
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
This patch series depends on and must be applied after:
https://lore.kernel.org/all/20260402-drm-lcdif-dbanc-v3-7-27cd247a0847@bootlin.com/
(Series [v3,00/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector)
Patch 1: Make DRM_BRIDGE_ATTACH_NO_CONNECTOR optional for platforms that call
dw_hdmi_bind() to attach the dw-hdmi bridge.
Patch 2: Allow &dw_hdmi_plat_data.output_port = 0 without the attach flag
DRM_BRIDGE_ATTACH_NO_CONNECTOR for dw-hdmi bridge.
Patch 3: Apply bridge-connector for Rockchip dw-hdmi driver, so that connector
management is unified under bridge-connector. Treat dw-hdmi purely as
a bridge without using its own connector helper functions, which
partially overlaps with the bridge helper.
Patch 4: Add next bridge support for Rockchip dw-hdmi driver, so that it can
support both the HDMI connector and additional bridge chips.
Damon Ding (4):
drm/bridge: dw-hdmi: Pass bridge attach flags for dw_hdmi_bind()
drm/bridge: dw-hdmi: Allow &dw_hdmi_plat_data.output_port = 0 without
DRM_BRIDGE_ATTACH_NO_CONNECTOR
drm/rockchip: dw_hdmi: Apply DRM_BRIDGE_ATTACH_NO_CONNECTOR and the
bridge-connector
drm/rockchip: dw_hdmi: Support to find the next bridge
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 +++----
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 33 ++++++++++++++++++---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
include/drm/bridge/dw_hdmi.h | 4 ++-
5 files changed, 39 insertions(+), 11 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v1 2/4] drm/bridge: dw-hdmi: Allow &dw_hdmi_plat_data.output_port = 0 without DRM_BRIDGE_ATTACH_NO_CONNECTOR
From: Damon Ding @ 2026-04-03 7:00 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, hjc, heiko, andy.yan, wens, samuel,
luca.ceresoli
Cc: Laurent.pinchart, jonas, jernej.skrabec, victor.liu,
dmitry.baryshkov, shengjiu.wang, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-sunxi, Damon Ding
In-Reply-To: <20260403070032.447102-1-damon.ding@rock-chips.com>
In the previous commit, Luca split the dw-hdmi attach process into two
cases:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
For Rockchip, many older platforms (RK3288, RK3399, etc.) only support
case A by default. They can support DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
after adapting to the bridge connector helper. Relax this constraint in
preparation for Rockchip dw-hdmi bridge-connector adaptation.
Link: https://lore.kernel.org/all/20260402-drm-lcdif-dbanc-v3-6-27cd247a0847@bootlin.com/
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dd50dda3a4f5..20b2f9e145b0 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2912,9 +2912,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
{
struct dw_hdmi *hdmi = bridge->driver_private;
- /* DRM_BRIDGE_ATTACH_NO_CONNECTOR requires a remote-endpoint to the next bridge */
- if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port))
- return -EINVAL;
+ if ((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port)
+ return 0;
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
struct device_node *remote __free(device_node) =
--
2.34.1
^ permalink raw reply related
* [GIT PULL] Microchip AT91 fixes for v7.0
From: Claudiu Beznea @ 2026-04-03 7:02 UTC (permalink / raw)
To: soc, arm; +Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-fixes-7.0
for you to fetch changes up to 907150bbe566e23714a25d7bcb910f236c3c44c0:
ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB (2026-03-23 12:54:24 +0200)
----------------------------------------------------------------
Microchip AT91 fixes for v7.0
This update includes:
- fix gpio-lines for SAM9X7 PIOB GPIO controller
----------------------------------------------------------------
Mihai Sain (1):
ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB
arch/arm/boot/dts/microchip/sam9x7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL] Microchip AT91 defconfig updates for v7.1
From: Claudiu Beznea @ 2026-04-03 7:02 UTC (permalink / raw)
To: soc, arm; +Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-7.1
for you to fetch changes up to 1f17fce8bf19a48e5e5610c6da8f806eab81878a:
ARM: configs: at91: sama7: enable LVDS serializer support (2026-02-28 16:04:03 +0200)
----------------------------------------------------------------
Microchip AT91 defconfig updates for v7.1
This update includes:
- LCD controller, LVDS controller, backlight, simple pannel, touchscreen
configuration flags required by SAMA7D65 SoC
----------------------------------------------------------------
Aubin Constans (1):
ARM: configs: at91: sama7: enable LVDS serializer support
Romain Sioen (1):
ARM: configs: at91: sama7: enable config for atmel maxtouch
Ryan Wanner (1):
ARM: configs: at91: sama7: enable DRM hlcdc support
arch/arm/configs/sama7_defconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
^ permalink raw reply
* [GIT PULL] Microchip AT91 device tree updates for v7.1
From: Claudiu Beznea @ 2026-04-03 7:03 UTC (permalink / raw)
To: soc, arm; +Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-7.1
for you to fetch changes up to 7d7a9fc1310a0ade8ea61c5eb4d8b29456f8d604:
ARM: dts: microchip: sama7d65: add Cortex-A7 PMU node (2026-03-24 15:35:37 +0200)
----------------------------------------------------------------
Microchip AT91 device tree updates for v7.1
This update includes:
- enable LVDS, LCD and PMU for SAMA7D64 SoC
- drop unused #address-cells, #size-cells for SAM9X60 UDC node
----------------------------------------------------------------
Charan Pedumuru (1):
arm: dts: microchip: remove unused #address-cells/#size-cells from sam9x60 udc node
Mihai Sain (1):
ARM: dts: microchip: sama7d65: add Cortex-A7 PMU node
Ryan Wanner (2):
ARM: dts: microchip: sama7d65: add LCD controller
ARM: dts: microchip: sama7d65: add LVDS controller
arch/arm/boot/dts/microchip/sam9x60.dtsi | 2 --
arch/arm/boot/dts/microchip/sama7d65.dtsi | 40 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL] Microchip AT91 SoC updates for v7.1
From: Claudiu Beznea @ 2026-04-03 7:03 UTC (permalink / raw)
To: soc, arm; +Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-soc-7.1
for you to fetch changes up to f3ae0049ff8a3d2cbd8c05857705744435629d0c:
dt-bindings: arm: atmel,at91rm9200-sdramc: convert to DT schema (2026-03-07 16:41:03 +0200)
----------------------------------------------------------------
Microchip AT91 SoC updates for v7.1
This update includes:
- device tree bindings conversion to DT schema for CHIPID, RAM
controller and PIT, PIT64b, ST timers
----------------------------------------------------------------
Akhila YS (5):
dt-bindings: arm: microchip,sama7g5-chipid : convert to DT schema
dt-bindings: arm: atmel,at91sam9260-pit: convert to DT schema
dt-bindings: arm: microchip,sam9x60-pit64b : convert to DT schema
dt-bindings: arm: atmel,at91rm9200-st: convert to DT schema
dt-bindings: arm: atmel,at91rm9200-sdramc: convert to DT schema
.../bindings/arm/atmel,at91rm9200-sdramc.yaml | 66 +++++++++++++++++++++
.../bindings/arm/atmel,at91rm9200-st.yaml | 69 ++++++++++++++++++++++
.../bindings/arm/atmel,at91sam9260-pit.yaml | 49 +++++++++++++++
.../devicetree/bindings/arm/atmel-sysregs.txt | 48 ---------------
.../bindings/arm/microchip,sam9x60-pit64b.yaml | 68 +++++++++++++++++++++
.../bindings/arm/microchip,sama7g5-chipid.yaml | 41 +++++++++++++
6 files changed, 293 insertions(+), 48 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/atmel,at91rm9200-sdramc.yaml
create mode 100644 Documentation/devicetree/bindings/arm/atmel,at91rm9200-st.yaml
create mode 100644 Documentation/devicetree/bindings/arm/atmel,at91sam9260-pit.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/atmel-sysregs.txt
create mode 100644 Documentation/devicetree/bindings/arm/microchip,sam9x60-pit64b.yaml
create mode 100644 Documentation/devicetree/bindings/arm/microchip,sama7g5-chipid.yaml
^ permalink raw reply
* [GIT PULL] Microchip ARM64 device tree updates for v7.1
From: Claudiu Beznea @ 2026-04-03 7:06 UTC (permalink / raw)
To: soc, arm; +Cc: conor, nicolas.ferre, claudiu.beznea, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-dt64-7.1
for you to fetch changes up to 711cca0f1cfef57018654b969da4041c2bab68d3:
arm64: dts: microchip: add EV23X71A board (2026-03-20 10:56:22 +0200)
----------------------------------------------------------------
Microchip ARM64 device tree updates for v7.1
This update includes:
- device tree files for the Microchip LAN9691 SoC and its evaluation
board (Microchip EV23X71A)
----------------------------------------------------------------
Robert Marko (4):
arm64: dts: microchip: add LAN969x clock header file
arm64: dts: microchip: add LAN969x support
dt-bindings: arm: AT91: document EV23X71A board
arm64: dts: microchip: add EV23X71A board
.../devicetree/bindings/arm/atmel-at91.yaml | 6 +
arch/arm64/boot/dts/microchip/Makefile | 1 +
arch/arm64/boot/dts/microchip/clk-lan9691.h | 24 +
arch/arm64/boot/dts/microchip/lan9691.dtsi | 488 +++++++++++++
arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts | 756 +++++++++++++++++++++
5 files changed, 1275 insertions(+)
create mode 100644 arch/arm64/boot/dts/microchip/clk-lan9691.h
create mode 100644 arch/arm64/boot/dts/microchip/lan9691.dtsi
create mode 100644 arch/arm64/boot/dts/microchip/lan9696-ev23x71a.dts
^ permalink raw reply
* [GIT PULL] Microchip ARM64 SoC updates for v7.1
From: Claudiu Beznea @ 2026-04-03 7:06 UTC (permalink / raw)
To: soc, arm; +Cc: conor, nicolas.ferre, claudiu.beznea, linux-arm-kernel
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-soc-7.1
for you to fetch changes up to e4ffa98a02f4d16eda9a5faec6792493b41dab35:
arm64: Kconfig: provide a top-level switch for Microchip platforms (2026-03-18 10:55:49 +0200)
----------------------------------------------------------------
Microchip ARM64 SoC updates for v7.1
This update includes:
- use a top-level configuration flag for all Microchip platforms
----------------------------------------------------------------
Bartosz Golaszewski (1):
arm64: Kconfig: provide a top-level switch for Microchip platforms
arch/arm64/Kconfig.platforms | 10 ++++------
arch/arm64/configs/defconfig | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
^ 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