* Re: [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Andrew Lunn @ 2026-04-17 12:06 UTC (permalink / raw)
To: Daniel Golle
Cc: Chester A. Unal, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Frank Wunderlich, John Crispin
In-Reply-To: <79dc0ec5b6be698b14cb66339d6f63033ca2934a.1776397542.git.daniel@makrotopia.org>
On Fri, Apr 17, 2026 at 04:55:57AM +0100, Daniel Golle wrote:
> The .get_stats64 callback runs in atomic context, but on
> MDIO-connected switches every register read acquires the MDIO bus
> mutex, which can sleep:
> [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> [ 12.663377] preempt_count: 0, expected: 0
> [ 12.667410] RCU nest depth: 1, expected: 0
> [ 12.671511] INFO: lockdep is turned off.
> [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> [ 12.675459] Call trace:
> [ 12.675462] show_stack+0x14/0x1c (C)
> [ 12.675477] dump_stack_lvl+0x68/0x8c
> [ 12.675487] dump_stack+0x14/0x1c
> [ 12.675495] __might_resched+0x14c/0x220
> [ 12.675504] __might_sleep+0x44/0x80
> [ 12.675511] __mutex_lock+0x50/0xb10
> [ 12.675523] mutex_lock_nested+0x20/0x30
> [ 12.675532] mt7530_get_stats64+0x40/0x2ac
> [ 12.675542] dsa_user_get_stats64+0x2c/0x40
> [ 12.675553] dev_get_stats+0x44/0x1e0
> [ 12.675564] dev_seq_printf_stats+0x24/0xe0
> [ 12.675575] dev_seq_show+0x14/0x3c
> [ 12.675583] seq_read_iter+0x37c/0x480
> [ 12.675595] seq_read+0xd0/0xec
> [ 12.675605] proc_reg_read+0x94/0xe4
> [ 12.675615] vfs_read+0x98/0x29c
> [ 12.675625] ksys_read+0x54/0xdc
> [ 12.675633] __arm64_sys_read+0x18/0x20
> [ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> [ 12.675653] do_el0_svc+0x3c/0xb4
> [ 12.675662] el0_svc+0x38/0x200
> [ 12.675670] el0t_64_sync_handler+0x98/0xdc
> [ 12.675679] el0t_64_sync+0x158/0x15c
>
> For MDIO-connected switches, poll MIB counters asynchronously using a
> delayed workqueue every second and let .get_stats64 return the cached
> values under a per-port spinlock. A mod_delayed_work() call on each
> read triggers an immediate refresh so counters stay responsive when
> queried more frequently.
>
> MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
> because their regmap does not sleep, so they continue to read MIB
> counters directly in .get_stats64.
>
> Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] drm/mediatek: hdmi: Convert DRM_ERROR() to drm_err()
From: Jani Nikula @ 2026-04-17 12:03 UTC (permalink / raw)
To: sai madhu, Chun-Kuang Hu
Cc: Philipp Zabel, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel, sai madhu
In-Reply-To: <20260417113310.2903091-1-suryasaimadhu369@gmail.com>
On Fri, 17 Apr 2026, sai madhu <suryasaimadhu369@gmail.com> wrote:
> The DRM_ERROR() macro is deprecated in favor of drm_err() which
> provides device-specific logging.
>
> Replace DRM_ERROR() with drm_err() in the Mediatek HDMI bridge
> driver and pass the drm_device pointer via bridge->dev.
>
> No functional change intended.
>
> Signed-off-by: sai madhu <suryasaimadhu369@gmail.com>
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 1ea259854780..f431fc9adca5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -981,8 +981,9 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge *bridge,
> int ret;
>
> if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> - DRM_ERROR("%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
> - __func__);
> + drm_err(bridge->dev,
> + "%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
> + __func__);
We really shouldn't be logging __func__ either. Errors should be
unambigious anyway, and drm_dbg* logging uses
__builtin_return_address(0) to achieve the same with a much smaller
footprint.
BR,
Jani.
> return -EINVAL;
> }
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v6 01/30] mm: Introduce kpkeys
From: David Hildenbrand (Arm) @ 2026-04-17 12:00 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: linux-kernel, Andrew Morton, Andy Lutomirski, Catalin Marinas,
Dave Hansen, Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Lorenzo Stoakes, Marc Zyngier, Mark Brown,
Matthew Wilcox, Maxwell Bland, Mike Rapoport (IBM),
Peter Zijlstra, Pierre Langlois, Quentin Perret, Rick Edgecombe,
Ryan Roberts, Thomas Gleixner, Vlastimil Babka, Will Deacon,
Yang Shi, Yeoreum Yun, linux-arm-kernel, linux-mm, x86
In-Reply-To: <fea9c939-f955-4020-bed6-427e592f0024@arm.com>
On 4/15/26 17:50, Kevin Brodsky wrote:
> On 15/04/2026 15:00, David Hildenbrand (Arm) wrote:
>> On 2/27/26 18:54, Kevin Brodsky wrote:
>>> kpkeys is a simple framework to enable the use of protection keys
>>> (pkeys) to harden the kernel itself. This patch introduces the basic
>>> API in <linux/kpkeys.h>: a couple of functions to set and restore
>>> the pkey register and macros to define guard objects.
>>>
>>> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
>>> Each level is associated to a set of permissions for the pkeys
>>> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
>>> permissions according to lvl, and returns the original pkey
>>> register, to be later restored by kpkeys_restore_pkey_reg(). To
>>> start with, only KPKEYS_LVL_DEFAULT is available, which is meant
>>> to grant RW access to KPKEYS_PKEY_DEFAULT (i.e. all memory since
>>> this is the only available pkey for now).
>>>
>>> Because each architecture implementing pkeys uses a different
>>> representation for the pkey register, and may reserve certain pkeys
>>> for specific uses, support for kpkeys must be explicitly indicated
>>> by selecting ARCH_HAS_KPKEYS and defining the following functions in
>>> <asm/kpkeys.h>, in addition to the macros provided in
>>> <asm-generic/kpkeys.h>:
>> I don't quite understand the reason for using levels. Levels sounds like
>> it would all be in some ordered fashion, where higher levels have access
>> to lower levels.
>
> That was originally the idea indeed, but in practice I don't expect
> levels to have a strict ordering, as it's not practical for composing
> features.
>
>> Think of that as a key that can unlock all "lower" locks, not just a
>> single lock.
>>
>> Then, the question is about the ordering once we introduce new
>> keys/locks. With two, it obviously doesn't matter :)
>>
>> So naturally I wonder whether levels is really the right abstraction
>> here, and why we are not simply using "distinct" keys, like
>>
>> KPKEY_DEFAULT
>> KPKEY_PGTABLE
>> KPKEY_SUPER_SECRET1
>> KPKEY_SUPER_SECRET2
>>
>> Is it because you want KPKEY_PGTABLE also be able to write to KPKEY_DEFAULT?
>
> Right, and in general a given level may be able to write to any number
> of pkeys. That's why I don't want to conflate pkeys and levels. Agreed
> that "level" might not be the clearest term though, since there's no
> strict ordering.
As discussed offline, maybe the right terminology to use here would be
something like a "context".
You'd be activating/setting a context.
KPKEY_CTX_DEFAULT
KPKEY_CTX_PGTABLE
KPKEY_CTX_SUPER_SECRET1
What is accessible (and how) is defined for each context. For example, I
would assume that all context allow for read/write access to everything
that KPKEY_CTX_DEFAULT has access to.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
From: kernel test robot @ 2026-04-17 11:59 UTC (permalink / raw)
To: Besar Wicaksono, will, mark.rutland, james.clark
Cc: oe-kbuild-all, linux-arm-kernel, linux-kernel, linux-tegra,
treding, jonathanh, vsethi, rwiley, sdonthineni, mochs, nirmoyd,
skelley, Besar Wicaksono
In-Reply-To: <20260406232034.2566133-1-bwicaksono@nvidia.com>
Hi Besar,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v7.0 next-20260416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Besar-Wicaksono/perf-arm_pmu-Skip-PMCCNTR_EL0-on-NVIDIA-Olympus/20260417-021859
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/20260406232034.2566133-1-bwicaksono%40nvidia.com
patch subject: [PATCH] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260417/202604171959.Zy8qD08x-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260417/202604171959.Zy8qD08x-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604171959.Zy8qD08x-lkp@intel.com/
All warnings (new ones prefixed by >>):
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:125:65: warning: initialized field overwritten [-Woverride-init]
125 | #define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x0043
| ^~~~~~
drivers/perf/arm_pmuv3.c:147:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR'
147 | [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:125:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[0][1][1]')
125 | #define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x0043
| ^~~~~~
drivers/perf/arm_pmuv3.c:147:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR'
147 | [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:134:65: warning: initialized field overwritten [-Woverride-init]
134 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x004E
| ^~~~~~
drivers/perf/arm_pmuv3.c:149:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD'
149 | [C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:134:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][0][0]')
134 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x004E
| ^~~~~~
drivers/perf/arm_pmuv3.c:149:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD'
149 | [C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:135:65: warning: initialized field overwritten [-Woverride-init]
135 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x004F
| ^~~~~~
drivers/perf/arm_pmuv3.c:150:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR'
150 | [C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:135:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][1][0]')
135 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x004F
| ^~~~~~
drivers/perf/arm_pmuv3.c:150:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR'
150 | [C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:132:65: warning: initialized field overwritten [-Woverride-init]
132 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x004C
| ^~~~~~
drivers/perf/arm_pmuv3.c:151:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD'
151 | [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:132:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][0][1]')
132 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x004C
| ^~~~~~
drivers/perf/arm_pmuv3.c:151:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD'
151 | [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:133:65: warning: initialized field overwritten [-Woverride-init]
133 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x004D
| ^~~~~~
drivers/perf/arm_pmuv3.c:152:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR'
152 | [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:133:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[3][1][1]')
133 | #define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x004D
| ^~~~~~
drivers/perf/arm_pmuv3.c:152:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR'
152 | [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:149:65: warning: initialized field overwritten [-Woverride-init]
149 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x0060
| ^~~~~~
drivers/perf/arm_pmuv3.c:154:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD'
154 | [C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:149:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[6][0][0]')
149 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x0060
| ^~~~~~
drivers/perf/arm_pmuv3.c:154:51: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD'
154 | [C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:150:65: warning: initialized field overwritten [-Woverride-init]
150 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x0061
| ^~~~~~
drivers/perf/arm_pmuv3.c:155:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR'
155 | [C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/perf/arm_pmuv3.h:150:65: note: (near initialization for 'armv8_vulcan_perf_cache_map[6][1][0]')
150 | #define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x0061
| ^~~~~~
drivers/perf/arm_pmuv3.c:155:52: note: in expansion of macro 'ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR'
155 | [C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c:984:26: error: array type has incomplete element type 'struct midr_range'
984 | static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c:1000:9: error: implicit declaration of function 'MIDR_ALL_VERSIONS'; did you mean 'MODULE_VERSION'? [-Wimplicit-function-declaration]
1000 | MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
| ^~~~~~~~~~~~~~~~~
| MODULE_VERSION
drivers/perf/arm_pmuv3.c:1000:27: error: 'MIDR_NVIDIA_OLYMPUS' undeclared here (not in a function)
1000 | MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
| ^~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c: In function 'armv8pmu_can_use_pmccntr':
drivers/perf/arm_pmuv3.c:1042:13: error: implicit declaration of function 'is_midr_in_range_list' [-Wimplicit-function-declaration]
1042 | if (is_midr_in_range_list(armv8pmu_avoid_pmccntr_cpus))
| ^~~~~~~~~~~~~~~~~~~~~
drivers/perf/arm_pmuv3.c: At top level:
>> drivers/perf/arm_pmuv3.c:984:26: warning: 'armv8pmu_avoid_pmccntr_cpus' defined but not used [-Wunused-variable]
984 | static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/armv8pmu_avoid_pmccntr_cpus +984 drivers/perf/arm_pmuv3.c
980
981 /*
982 * List of CPUs that should avoid using PMCCNTR_EL0.
983 */
> 984 static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
985 /*
986 * The PMCCNTR_EL0 in Olympus CPU may still increment while in WFI/WFE state.
987 * This is an implementation specific behavior and not an erratum.
988 *
989 * From ARM DDI0487 D14.4:
990 * It is IMPLEMENTATION SPECIFIC whether CPU_CYCLES and PMCCNTR count
991 * when the PE is in WFI or WFE state, even if the clocks are not stopped.
992 *
993 * From ARM DDI0487 D24.5.2:
994 * All counters are subject to any changes in clock frequency, including
995 * clock stopping caused by the WFI and WFE instructions.
996 * This means that it is CONSTRAINED UNPREDICTABLE whether or not
997 * PMCCNTR_EL0 continues to increment when clocks are stopped by WFI and
998 * WFE instructions.
999 */
1000 MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
1001 {}
1002 };
1003
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH rc v2 0/5] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-04-17 11:59 UTC (permalink / raw)
To: Tian, Kevin
Cc: Robin Murphy, Nicolin Chen, will@kernel.org, joro@8bytes.org,
praan@google.com, baolu.lu@linux.intel.com,
miko.lenczewski@arm.com, smostafa@google.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
jamien@nvidia.com
In-Reply-To: <BN9PR11MB5276A13A8014C5C6403FB4EC8C202@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Apr 17, 2026 at 07:48:46AM +0000, Tian, Kevin wrote:
> is there any report on such systems? It might be informational to include
> a link to the report so it's clear that this series fixes real issues instead of
> a preparation for coming systems...
Yeah, we have an internal report and this was confirmed to fix it.
> btw the DMA is allowed after the previous kernel is hung til the point
> where smmu driver blocks it. In cases where in-fly DMAs are considered
> dangerous to kdump, this series just make it worse instead of creating
> a new issue. While for majority other failures not related to DMAs,
> unblocking then increases the chance of success...
Right, exactly.
If DMA's are splattering over the kdump carve out memory its is
probably dead no matter what.
Jason
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-17 11:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
Hi Cristan,
Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
[...]
> Cristian Ciocaltea (40):
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
sense, because these patches really are mostly identical :-)
Heiko
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-firefly-itx-3588j
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-h96-max-v58
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-jaguar
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-mnt-reform2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-nanopc-t6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-max
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-plus
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-ultra
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-roc-rt
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588-tiger
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-coolpi-4b
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
> arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
>
> .../boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
> .../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
> arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
> .../boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
> .../boot/dts/rockchip/rk3588-firefly-itx-3588j.dts | 9 +++++++++
> .../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts | 15 ++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 16 ++++++++++++++++
> .../arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-roc-rt.dts | 16 ++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 9 ++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts | 8 +++-----
> .../arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
> arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
> .../boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
> arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
> arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
> 41 files changed, 392 insertions(+), 35 deletions(-)
> ---
> base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
> change-id: 20260417-dts-rk-frl-enable-gpios-ce9930dbf5ca
>
>
^ permalink raw reply
* [PATCH] drm/mediatek: hdmi: Convert DRM_ERROR() to drm_err()
From: sai madhu @ 2026-04-17 11:33 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Philipp Zabel, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel, sai madhu
The DRM_ERROR() macro is deprecated in favor of drm_err() which
provides device-specific logging.
Replace DRM_ERROR() with drm_err() in the Mediatek HDMI bridge
driver and pass the drm_device pointer via bridge->dev.
No functional change intended.
Signed-off-by: sai madhu <suryasaimadhu369@gmail.com>
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1ea259854780..f431fc9adca5 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -981,8 +981,9 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge *bridge,
int ret;
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
- DRM_ERROR("%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
- __func__);
+ drm_err(bridge->dev,
+ "%s: The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR must be supplied\n",
+ __func__);
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-17 11:32 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-5-a19c0dd8c9f6@collabora.com>
Hi Cristian,
the comments below apply sort of to all patches in that series.
Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> The board exposes the GPIO4_C6 line to control the voltage bias on the
> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>
> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> property and drop the line from the vcc_5v0_hdmi regulator to allow
> adjusting the bias when transitioning between TMDS and FRL operating
> modes.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> index 749f0a54b478..93ae37699366 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> @@ -140,10 +140,7 @@ regulator-state-mem {
>
> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
> compatible = "regulator-fixed";
> - enable-active-high;
> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_con_en>;
> + regulator-always-on;
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> regulator-name = "vcc_5v0_hdmi";
I think this regulator was sort of a complete hack, to set that
gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
is completely functionless now, the whole thing could be removed?
> @@ -231,6 +228,8 @@ &gpu {
> };
>
> &hdmi {
> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
this should be sorted the other way around I think.
Also please provide a pinctrl-names property too. If for whatever reason
the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
board DTs are staying in the "old" compatible mode until they are adapted.
> status = "okay";
> };
>
> @@ -655,7 +654,7 @@ &pcie0 {
>
> &pinctrl {
> hdmi {
> - hdmi_con_en: hdmi-con-en {
> + hdmi_frl_en: hdmi-frl-en {
pinctrl names should ideally match the naming in schematics, for example
the "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to
go from DT to schematics and back.
> rockchip,pins = <4 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
>
>
Heiko
^ permalink raw reply
* Re: [PATCH v2 0/9] driver core / pmdomain: Add support for fined grained sync_state
From: Ulf Hansson @ 2026-04-17 11:27 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman,
Danilo Krummrich, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
+ Danilo (for the driver core changes)
On Fri, 10 Apr 2026 at 12:41, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> Since the introduction [1] of the common sync_state support for pmdomains
> (genpd), we have encountered a lot of various interesting problems. In most
> cases the new behaviour of genpd triggered some weird platform specific bugs.
>
> That said, in LPC in Tokyo me and Saravana hosted a session to walk through the
> remaining limitations that we have found for genpd's sync state support. In
> particular, we discussed the problems we have for the so-called onecell power
> domain providers, where a single provider typically provides multiple
> independent power domains, all with their own set of consumers.
>
> Note that, onecell power domain providers are very common. It's being used by
> many SoCs/platforms/technologies. To name a few:
> SCMI, Qualcomm, NXP, Mediatek, Renesas, TI, etc.
>
> Anyway, in these cases, the generic sync_state mechanism with fw_devlink isn't
> fine grained enough, as we end up waiting for all consumers for all power
> domains before the ->sync_callback gets called for the supplier/provider. In
> other words, we may end up keeping unused power domains powered-on, for no good
> reasons.
>
> The series intends to fix this problem. Please have a look at the commit
> messages for more details and help review/test!
>
> Kind regards
> Ulf Hansson
>
> [1]
> https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
>
> Ulf Hansson (9):
> driver core: Enable suppliers to implement fine grained sync_state
> support
> driver core: Add dev_set_drv_queue_sync_state()
> pmdomain: core: Move genpd_get_from_provider()
> pmdomain: core: Add initial fine grained sync_state support
> pmdomain: core: Extend fine grained sync_state to more onecell
> providers
> pmdomain: core: Export a common function for ->queue_sync_state()
> pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
> pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
>
> drivers/base/core.c | 7 +-
> drivers/pmdomain/core.c | 205 ++++++++++++++++++----
> drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
> drivers/pmdomain/renesas/rcar-sysc.c | 1 -
> drivers/pmdomain/renesas/rmobile-sysc.c | 3 +-
> include/linux/device.h | 12 ++
> include/linux/device/driver.h | 7 +
> include/linux/pm_domain.h | 3 +
> 8 files changed, 197 insertions(+), 42 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Frank Li @ 2026-04-17 11:22 UTC (permalink / raw)
To: Robby Cai
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260417110200.753678-2-robby.cai@nxp.com>
On Fri, Apr 17, 2026 at 07:01:59PM +0800, Robby Cai wrote:
> CSI capture may intermittently fail due to mismatched clock rates. The
> previous configuration violated the timing requirement stated in the
> i.MX8MQ Reference Manual:
>
> "The frequency of clk must be exactly equal to or greater than the RX
> byte clock coming from the RX DPHY."
>
> Update the clock configuration to ensure that the CSI core clock rate is
> equal to or greater than the incoming DPHY byte clock.
You reduce clock, how to make sure it >= ?
> The updated clock
> ratios are consistent with those used in NXP's downstream BSP.
"downstream BSP" is not solidate reference for clock rate, it'd better
refer to date sheet, dose datasheet require such frequecy
Frank
>
> Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
> Cc: stable@vger.kernel.org
> Signed-off-by: Robby Cai <robby.cai@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6a25e219832c..165716d08e64 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
> <&clk IMX8MQ_CLK_CSI1_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> @@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
> <&clk IMX8MQ_CLK_CSI2_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI2_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: Daniel Borkmann @ 2026-04-17 11:21 UTC (permalink / raw)
To: Puranjay Mohan, bpf, linux-arm-kernel
Cc: Jonas Rebmann, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Russell King, kernel
In-Reply-To: <20260417103004.3552500-1-puranjay@kernel.org>
On 4/17/26 12:30 PM, Puranjay Mohan wrote:
> The ARM32 BPF JIT does not support BPF-to-BPF function calls
> (subprogram calls). When insn->src_reg == BPF_PSEUDO_CALL, the
> imm field contains a pc-relative offset to another BPF function,
> not a helper function index.
>
> When a program containing BPF-to-BPF calls is loaded, the verifier
> invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each
> subprogram. Since ARM32 does not reject BPF_PSEUDO_CALL, the JIT
> silently emits code for the call using the wrong address computation:
>
> func = __bpf_call_base + imm
>
> where imm is actually a pc-relative subprogram offset, producing
> a bogus function pointer. Because build_body() reports success,
> bpf_jit_binary_alloc() is reached and a JIT image is allocated.
>
> ARM32 also lacks the jit_data/extra_pass mechanism needed for
> the second JIT pass in bpf_jit_subprogs(). On the second pass,
> bpf_int_jit_compile() performs a full fresh compilation,
> allocating a new JIT binary and overwriting prog->bpf_func. The
> first allocation is never freed. bpf_jit_subprogs() then detects
> the function pointer changed and aborts with -ENOTSUPP, but the
> original JIT binary has already been leaked. Each program
> load/unload cycle leaks one JIT binary allocation, as reported
> by kmemleak:
>
> unreferenced object 0xbf0a1000 (size 4096):
> backtrace:
> bpf_jit_binary_alloc+0x64/0xfc
> bpf_int_jit_compile+0x14c/0x348
> bpf_jit_subprogs+0x4fc/0xa60
>
> Fix this by rejecting BPF_PSEUDO_CALL early in build_insn(),
> falling through to the existing 'notyet' path. This causes
> build_body() to fail before any JIT binary is allocated, so
> bpf_int_jit_compile() returns the original program unjitted.
> bpf_jit_subprogs() then sees !prog->jited and cleanly falls
> back to the interpreter.
>
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
> Reported-by: Jonas Rebmann <jre@pengutronix.de>
> Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de
> Tested-by: Jonas Rebmann <jre@pengutronix.de>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: bot+bpf-ci @ 2026-04-17 11:17 UTC (permalink / raw)
To: puranjay, bpf, linux-arm-kernel
Cc: puranjay, jre, ast, daniel, andrii, martin.lau, eddyz87, memxor,
song, linux, kernel, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260417103004.3552500-1-puranjay@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Is this the correct Fixes tag? That commit only modified x64 JIT code
and BPF core infrastructure for BPF-to-BPF calls - it never touched
arch/arm/net/bpf_jit_32.c.
The actual bug was introduced by commit 39c13c204bb1 ("arm: eBPF JIT
compiler") from August 2017, which added the ARM32 eBPF JIT with
BPF_CALL handling but failed to reject BPF_PSEUDO_CALL. The code has
been incorrectly computing function addresses as 'func = __bpf_call_base
+ imm' for BPF_PSEUDO_CALL since the ARM32 JIT was first introduced.
Suggested: Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index deeb8f292454..91fef10e88bc 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -2047,6 +2047,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
> /* function call */
> case BPF_JMP | BPF_CALL:
> {
> + if (insn->src_reg == BPF_PSEUDO_CALL)
> + goto notyet;
> const s8 *r0 = bpf2a32[BPF_REG_0];
> const s8 *r1 = bpf2a32[BPF_REG_1];
> const s8 *r2 = bpf2a32[BPF_REG_2];
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24561211195
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Frank Li @ 2026-04-17 11:14 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260415081942.4183108-3-chancel.liu@nxp.com>
On Wed, Apr 15, 2026 at 05:19:41PM +0900, Chancel Liu wrote:
> Some audio systems require specific DAPM widgets to remain powered
> during system suspend. Introduce a generic and reusable mechanism in
> the ASoC core to mark selected DAPM widgets as ignore_suspend.
>
> The unified mechanism consists of two parts:
> 1. Parse and store the name list of widgets to ignore suspend in
> struct snd_soc_card
>
> The list of widgets can be provided either by the machine driver or
> parsed from Device Tree. Different machines have different routing and
> power requirements. Each machine can specify its own widgets to ignore
> suspend through DT property. It enables flexible policy without hard
> code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
> for this purpose.
>
> 2. Apply ignore_suspend flags during snd_soc_bind_card()
>
> After all components have been probed and all DAPM widgets have been
> registered, snd_soc_bind_card() performs a unified lookup of the
> configured widget names across all DAPM contexts of the card and marks
> the matching widgets with ignore_suspend = 1.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
...
> @@ -3294,6 +3298,45 @@ int snd_soc_of_parse_aux_devs(struct snd_soc_card *card, const char *propname)
> }
> EXPORT_SYMBOL_GPL(snd_soc_of_parse_aux_devs);
>
> +int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card,
> + const char *propname)
propname is fixed value "ignore-suspend-widgets"，needn't this agument.
you funciton include "ignore_suspend_widgets", suppose only parse property.
ignore_suspend_widgets
Frank
^ permalink raw reply
* [PATCH] pmdomain: core: Fix detach procedure for virtual devices in genpd
From: Ulf Hansson @ 2026-04-17 11:13 UTC (permalink / raw)
To: Geert Uytterhoeven, Ulf Hansson, linux-pm
Cc: Geert Uytterhoeven, Frank Binns, Matt Coster, Marek Vasut,
Rafael J . Wysocki, linux-arm-kernel, linux-kernel, Ulf Hansson,
stable
If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),
genpd calls pm_runtime_enable() for the corresponding virtual device that
it registers. While this avoids boilerplate code in drivers, there is no
corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().
This means these virtual devices are typically detached from its genpd,
while runtime PM remains enabled for them, which is not how things are
designed to work. In worst cases it may lead to critical errors, like a
NULL pointer dereference bug in genpd_runtime_suspend(), which was recently
reported. For another case, we may end up keeping an unnecessary vote for a
performance state for the device.
To fix these problems, let's add this missing call to pm_runtime_disable()
in genpd_dev_pm_detach().
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4d32fc676aaf..71e930e80178 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3089,6 +3089,7 @@ static const struct bus_type genpd_bus_type = {
static void genpd_dev_pm_detach(struct device *dev, bool power_off)
{
struct generic_pm_domain *pd;
+ bool is_virt_dev;
unsigned int i;
int ret = 0;
@@ -3098,6 +3099,13 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
dev_dbg(dev, "removing from PM domain %s\n", pd->name);
+ /* Check if the device was created by genpd at attach. */
+ is_virt_dev = dev->bus == &genpd_bus_type;
+
+ /* Disable runtime PM if we enabled it at attach. */
+ if (is_virt_dev)
+ pm_runtime_disable(dev);
+
/* Drop the default performance state */
if (dev_gpd_data(dev)->default_pstate) {
dev_pm_genpd_set_performance_state(dev, 0);
@@ -3123,7 +3131,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
genpd_queue_power_off_work(pd);
/* Unregister the device if it was created by genpd. */
- if (dev->bus == &genpd_bus_type)
+ if (is_virt_dev)
device_unregister(dev);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/5] dt-bindings: interrupt-controller: Add support for secure donated SGIs
From: Sudeep Holla @ 2026-04-17 11:07 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Marc Zyngier, Sudeep Holla,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAL_JsqLdSi2x-KibY7WXTEot8Bj=54XeE1VACtLTujxn0VTxRw@mail.gmail.com>
On Thu, Apr 16, 2026 at 09:02:27AM -0500, Rob Herring wrote:
> On Thu, Apr 16, 2026 at 8:09 AM Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >
> > On Thu, Apr 16, 2026 at 07:11:46AM -0500, Rob Herring wrote:
> > > On Sun, Apr 12, 2026 at 06:04:37PM +0100, Sudeep Holla wrote:
> > > > In GICv3, SGI security is defined by interrupt grouping and configuration
> > > > rather than by SGI number alone. Linux conventionally reserves SGIs 0-7
> > > > for non-secure internal kernel IPIs, while higher SGIs is assumed to be
> > > > owned/stolen by the Secure world unless explicitly made available.
> > > >
> > > > Document secure donated SGI interrupt specifiers for the GICv3 binding.
> > > > It describes "arm,secure-donated-ns-sgi-ranges" for SGIs donated by the
> > > > secure world to non-secure software. It excludes SGIs 0-7, which are
> > > > already used by the kernel for internal IPI purposes.
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > > > ---
> > > > .../bindings/interrupt-controller/arm,gic-v3.yaml | 27 +++++++++++++++++++++-
> > > > include/dt-bindings/interrupt-controller/arm-gic.h | 1 +
> > > > 2 files changed, 27 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > index bfd30aae682b..664727d071c9 100644
> > > > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > > > @@ -45,17 +45,24 @@ description: |
> > > >
> > > > The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > > > interrupts, 2 for interrupts in the Extended SPI range, 3 for the
> > > > - Extended PPI range. Other values are reserved for future use.
> > > > + Extended PPI range, and 4 for SGI interrupts. Other values are
> > > > + reserved for future use.
> > > >
> > > > The 2nd cell contains the interrupt number for the interrupt type.
> > > > SPI interrupts are in the range [0-987]. PPI interrupts are in the
> > > > range [0-15]. Extended SPI interrupts are in the range [0-1023].
> > > > Extended PPI interrupts are in the range [0-127].
> > > >
> > > > + SGI interrupts are in the range [8-15] which overlaps with the SGIs
> > > > + assigned to/reserved for the secure world but donated to the non
> > > > + secure world to use. Refer "arm,secure-donated-ns-sgi-ranges" for
> > > > + more details.
> > > > +
> > > > The 3rd cell is the flags, encoded as follows:
> > > > bits[3:0] trigger type and level flags.
> > > > 1 = edge triggered
> > > > 4 = level triggered
> > > > + SGIs are edge triggered and must be described as such.
> > > >
> > > > The 4th cell is a phandle to a node describing a set of CPUs this
> > > > interrupt is affine to. The interrupt must be a PPI, and the node
> > > > @@ -136,6 +143,24 @@ description: |
> > > > - $ref: /schemas/types.yaml#/definitions/uint32
> > > > - $ref: /schemas/types.yaml#/definitions/uint64
> > > >
> > > > + arm,secure-donated-ns-sgi-ranges:
> > > > + description:
> > > > + A list of pairs <sgi span>, where "sgi" is the first SGI INTID of a
> > > > + range donated by the secure side to non-secure software, and "span" is
> > > > + the size of that range. Multiple ranges can be provided.
> > > > +
> > > > + SGIs described by interrupt specifiers with type 4 (SGI) must fall
> > > > + within one of these ranges. SGIs(0-7) reserved by non-secure world
> > > > + for internal IPIs must not be listed here. "sgi" must be in the
> > > > + range [8-15], "span" must be in the range [1-8], and the range must
> > > > + not extend past SGI 15.
> > > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > > > + items:
> > >
> > > As a matrix, you need:
> > >
> > > items:
> > > items:
> > > - ...
> > > - ...
> > >
> > > However, given this is at most 8 entries, I would just do an array:
> > >
> > > minItems: 1
> > > maxItems: 8
> > > uniqueItems: true
> > > items:
> > > minimum: 8
> > > maximum: 15
> > >
> >
> > Makes sense.
> >
> > > Unless we need more flexibility in GICv5?
> > >
> >
> > IIUC, there are not SGIs in GICv5 and we may need to use one software PPI
> > as a replacement for SGIs. LPIs are used for IPIs.
> >
> > I am assuming Marc will soon post his opinion/rejection on this series 😉
> > based on some offline discussion we had with respect to how it fits with
> > GICv5.
> >
> > > Is there an example we can stick this property into so it gets tested?
> > >
> >
> > Not sure if [1] serves as an example or you are looking for something else.
>
> In the binding example, but don't add a whole new example for it.
>
> Did [1] pass validation? If it did, it shouldn't have and I need to
> investigate. If you didn't run it, then that would be the reason I
> want it in the binding example.
>
By validation, do you mean `dtbs_check` ? If so, yes I didn't see any
warnings. But it is likely that I might have missed some flags as I was
doing `dtbs_check` and `dt_bindings_check` after very long time. I will
check again. But the commands did produce warnings in other files.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 1/3] ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
From: Frank Li @ 2026-04-17 11:03 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260415081942.4183108-2-chancel.liu@nxp.com>
On Wed, Apr 15, 2026 at 05:19:40PM +0900, Chancel Liu wrote:
subject suggest change to
ASoC: dapm: Use snd_soc_dapm_widget_name_cmp() to fix widget lookup failures
Frank
> Currently dapm_find_widget() manually constructs a prefixed widget name
> based on the provided DAPM context and compares it using strcmp(). This
> happens to work in most cases because callers usually know which DAPM
> context the target widget belongs to and pass in the matching DAPM
> context.
>
> However, this assumption breaks when search_other_contexts is enabled.
> In such cases, callers may intentionally pass a different DAPM context,
> while searching for a widget that actually belongs to another DAPM
> context.
>
> For example, when searching for a "DAC" widget, the widget belongs to
> the codec DAPM and be registered with a codec prefix, while the caller
> passes card->dapm and intends to search across all DAPM contexts. The
> current implementation incorrectly applies the caller card DAPM causing
> the lookup to fail even though the widget exists on the card.
>
> Use snd_soc_dapm_widget_name_cmp() instead, which compares widget names
> using the widget's own DAPM context and prefix. It fixes widget lookup
> failures when searching across different DAPM contexts on the card.
>
> Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking widget names")
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> Assisted-by: Cody:Claude-3.5-Sonnet
> ---
> sound/soc/soc-dapm.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
> index d6192204e613..c5b80d9ed64b 100644
> --- a/sound/soc/soc-dapm.c
> +++ b/sound/soc/soc-dapm.c
> @@ -2906,20 +2906,9 @@ static struct snd_soc_dapm_widget *dapm_find_widget(
> {
> struct snd_soc_dapm_widget *w;
> struct snd_soc_dapm_widget *fallback = NULL;
> - char prefixed_pin[80];
> - const char *pin_name;
> - const char *prefix = dapm_prefix(dapm);
> -
> - if (prefix) {
> - snprintf(prefixed_pin, sizeof(prefixed_pin), "%s %s",
> - prefix, pin);
> - pin_name = prefixed_pin;
> - } else {
> - pin_name = pin;
> - }
>
> for_each_card_widgets(dapm->card, w) {
> - if (!strcmp(w->name, pin_name)) {
> + if (!snd_soc_dapm_widget_name_cmp(w, pin)) {
> if (w->dapm == dapm)
> return w;
> else
> --
> 2.50.1
>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-04-17 11:02 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
Enable CSI1/CSI2 bridges and the MIPI-CSI host interfaces, and add
two OV5640 MIPI camera sensor nodes on I2C1 and I2C2.
The resulting camera pipelines are as follows:
- OV5640 on I2C2 -> MIPI CSI1 -> CSI1
- OV5640 on I2C1 -> MIPI CSI2 -> CSI2
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
Tested with following commands:
On CSI1:
media-ctl -d 0 -l "'ov5640 1-003c':0 -> 'imx8mq-mipi-csi2 30a70000.csi':0 [1]"
media-ctl -d 0 -V "'ov5640 1-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'imx8mq-mipi-csi2 30a70000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
On CSI2:
media-ctl -d 1 -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 30b60000.csi':0 [1]"
media-ctl -d 1 -V "'ov5640 0-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'imx8mq-mipi-csi2 30b60000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 1 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
1 file changed, 149 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index d48f901487d4..8bdfbfebfcc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include <dt-bindings/media/video-interfaces.h>
+
#include "imx8mq.dtsi"
/ {
@@ -50,6 +52,20 @@ reg_usdhc2_vmmc: regulator-vsd-3v3 {
enable-active-high;
};
+ reg_1v5: regulator-1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ reg_2v8: regulator-2v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_2V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
buck2_reg: regulator-buck2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_buck2>;
@@ -172,6 +188,14 @@ &A53_3 {
cpu-supply = <&buck2_reg>;
};
+&csi1 {
+ status = "okay";
+};
+
+&csi2 {
+ status = "okay";
+};
+
&ddrc {
operating-points-v2 = <&ddrc_opp_table>;
status = "okay";
@@ -330,12 +354,101 @@ vgen6_reg: vgen6 {
};
};
};
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera2_pwdn>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera2_ep: endpoint {
+ remote-endpoint = <&mipi_csi2_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera1_pwdn>, <&pinctrl_camera_rst>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera1_ep: endpoint {
+ remote-endpoint = <&mipi_csi1_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
};
&lcdif {
status = "okay";
};
+&mipi_csi1 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi1_in_ep: endpoint {
+ remote-endpoint = <&camera1_ep>;
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ };
+ };
+ };
+};
+
+&mipi_csi2 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in_ep: endpoint {
+ remote-endpoint = <&camera2_ep>;
+ data-lanes = <1 2>;
+ bus-type = <4>;
+ };
+ };
+ };
+};
+
&mipi_dsi {
#address-cells = <1>;
#size-cells = <0>;
@@ -532,12 +645,41 @@ &wdog1 {
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MCLK for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x59
+ >;
+ };
+
pinctrl_buck2: vddarmgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x19
>;
};
+ pinctrl_camera1_pwdn: camera1pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19
+ >;
+ };
+
+ pinctrl_camera2_pwdn: camera2pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19
+ >;
+ };
+
+ pinctrl_camera_rst: camerarstgrp {
+ fsl,pins = <
+ /* Reset PIN for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x19
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
@@ -565,6 +707,13 @@ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
pinctrl_ir: irgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x4f
--
2.37.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
CSI capture may intermittently fail due to mismatched clock rates. The
previous configuration violated the timing requirement stated in the
i.MX8MQ Reference Manual:
"The frequency of clk must be exactly equal to or greater than the RX
byte clock coming from the RX DPHY."
Update the clock configuration to ensure that the CSI core clock rate is
equal to or greater than the incoming DPHY byte clock. The updated clock
ratios are consistent with those used in NXP's downstream BSP.
Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
Cc: stable@vger.kernel.org
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6a25e219832c..165716d08e64 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
<&clk IMX8MQ_CLK_CSI1_PHY_REF>,
<&clk IMX8MQ_CLK_CSI1_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
@@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
<&clk IMX8MQ_CLK_CSI2_PHY_REF>,
<&clk IMX8MQ_CLK_CSI2_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
--
2.37.1
^ permalink raw reply related
* [PATCH 0/2] Enable dual OV5640 cameras on i.MX8MQ EVK board
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
This series adds dual-camera support for the i.MX8MQ EVK board.
Patch 1 fixes the MIPI CSI clock configuration in the i.MX8MQ device tree.
The previous configuration violated a timing constraint defined in the
i.MX8MQ Reference Manual:
"The frequency of clk must be exactly equal to or greater than the RX
byte clock coming from the RX DPHY."
This mismatch could lead to unstable operation, observed as intermittent
capture failures. The updated clock ratios align with those used in NXP��s
downstream BSP and were verified to resolve the issue.
Patch 2 enables full MIPI CSI support and dual OV5640 camera operation on
the i.MX8MQ EVK. This includes enabling both CSI controllers and their
corresponding MIPI CSI-2 host interfaces, as well as adding two OV5640
sensor nodes on I2C1 and I2C2.
Note:
This series depends on patch [1] currently under review, as well as commit
6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly release reset").
[1] https://lore.kernel.org/imx/20260417080851.489303-1-robby.cai@nxp.com/
Robby Cai (2):
arm64: dts: imx8mq: Correct MIPI CSI clocks
arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 +-
2 files changed, 151 insertions(+), 2 deletions(-)
--
2.37.1
^ permalink raw reply
* Re: [PATCH v3 1/2] media: verisilicon: Simplify motion vectors and rfc buffers allocation
From: Frank Li @ 2026-04-17 10:54 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: nicolas.dufresne, p.zabel, mchehab, s.hauer, kernel, festevam,
heiko, mcoquelin.stm32, alexandre.torgue, wens, jernej.skrabec,
samuel, linux-kernel, linux-media, linux-rockchip, imx,
linux-arm-kernel, linux-stm32, linux-sunxi, kernel
In-Reply-To: <20260415140420.282084-2-benjamin.gaignard@collabora.com>
On Wed, Apr 15, 2026 at 04:04:19PM +0200, Benjamin Gaignard wrote:
> Until now we reserve the space needed for motion vectors and reference
> frame compression at the end of the frame buffer.
> Disentanglement mv and rfc from frame buffers by allocating
> distinct buffers for each purpose.
> That simplify the code by removing lot of offset computation.
Can you try split to more small and straight forward patches, for example
for example create patch just move hantro_h264_mv_size() to header file,
...
> +++ b/drivers/media/platform/verisilicon/hantro_hevc.c
> @@ -44,30 +44,49 @@ dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
> int i;
>
> /* Find the reference buffer in already known ones */
> - for (i = 0; i < NUM_REF_PICTURES; i++) {
> + for (i = 0; i < NUM_REF_PICTURES; i++) {
> if (hevc_dec->ref_bufs_poc[i] == poc) {
> hevc_dec->ref_bufs_used |= 1 << i;
> return hevc_dec->ref_bufs[i].dma;
> }
> }
> -
> return 0;
Move this code style change to new patches.
Frank
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-17 10:50 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
In-Reply-To: <aeH373a_xmr6fnAy@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 6889 bytes --]
Hello Andrea,
On Fri, Apr 17, 2026 at 11:05:51AM +0200, Andrea della Porta wrote:
> On 15:48 Thu 16 Apr , Uwe Kleine-König wrote:
> > one thing I forgot to ask: Is there a public reference manual covering
> > the hardware. If yes, please add a link at the top of the driver.
>
> Sort of, it's already reported in this driver top comment (Datasheet: tag).
> The PWM controller is part of the RP1 chipset and you can find its description
> under the PWM section. This is not a full-fledged datasheet but the registers
> for the controller are somewhow documented.
Ah, then I missed something different than I thought :-)
> > On Thu, Apr 16, 2026 at 12:30:43PM +0200, Andrea della Porta wrote:
> > > On 19:31 Fri 10 Apr , Uwe Kleine-König wrote:
> > > > I assume there is a glitch if I update two channels and the old
> > > > configuration of the first channel ends while I'm in the middle of
> > > > configuring the second?
> > >
> > > The configuration registers are per-channel but the update flag is global.
> > > I don't have details of the hw insights, my best guess is that anything that
> > > you set in the registers before updating the flag will take effect, so there
> > > should be no glitches.
> >
> > Would be great if you could test that. (Something along the lines of:
> > configure a very short period and wait a bit to be sure the short
> > configuration is active. Configure something with a long period and wait
> > shortly to be sure that the long period started, then change the duty,
> > toggle the update bit and modify a 2nd channel without toggling update
> > again. Then check the output of the 2nd channel after the first
> > channel's period ended.
>
> I stand corrected here: after some more investigation it seems that only the
> enable/disable (plus osme other not currently used registers) depends on the
> global update flag, while the period and duty per-channel registers are
> independtly updatable while they are latched on the end of (specific channel)
> period strobe.
> I'd say that this should avoid any cross-channel glitches since they are managed
> independently. Unfortunately I'm not able to test this with my current (and
> rather old) equipment, this would require at least an external trigger channel.
> Regarding the setup of a new value exactly during the strobe: I think this is
> quite hard to achieve.
To sum up: period and duty_cycle changes might result in glitches unless
the channel is disabled. This is ok, please just document it.
The purpose of the update flag then is only to start several channels in
sync? What happens if sync is asserted while a disabled channel didn't
complete the last period yet?
Maybe it's worth to test the following procedure for updating duty and
period:
disable channel
configure duty
configure period
enable
set update flag
Assumint disable is delayed until the end of the currently running
period, the effect of this procedure might be that no glitch happens if
the update flag is asserted before the currently running period ends and
the anormality is reduced to a longer inactive state if the updates are
not that lucky (in contrast to more severe glitches).
If you can configure a short and a long period that is distinguishable
"manually" with an LED I think this should be testable even without
further equipment.
> > > > > + if (ticks > U32_MAX)
> > > > > + ticks = U32_MAX;
> > > > > + wfhw->period_ticks = ticks;
> > > >
> > > > What happens if wf->period_length_ns > 0 but ticks == 0?
> > >
> > > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > > in this case.
> >
> > Sounds good. Are you able to verify that there is no +1 missing in the
> > calculation, e.g. using 1 as register value really gives you a period of
> > 1 tick and not 2?
>
> You are right. The scope reveals there's always one extra (low signal) tick at the
> end of each period.
So the hardware cannot do 100% relative duty, right? Please document
that.
> Let's say that teh user want 10 tick period, we have to use
> 9 instead to account for the extra tick at the end, so that the complete period
> contains that extra tick?
I would describe that a bit differently, but in general: yes.
The more straight forward description is that setting
RP1_PWM_RANGE(pwm->hwpwm) := x
results in a period of x + 1 ticks.
> This also means that if we ask for 100% duty cycle, the output waveform will
> have the high part of the signal lasting one tick less than expected.a I guess
> this is the accepted compromise.
I assume you considered something like:
RP1_PWM_RANGE(pwm->hwpwm) := 17
RP1_PWM_DUTY(pwm->hwpwm) := 18
to get a 100% relative duty?
If this doesn't work that means that this has to be formalized in the
callbacks. That is the fromhw function has to always report
duty_length_ns less than period_length_ns.
> OTOH, the minimum tick period would be 2 tick, less than that will otherwise
> degenerate in a disabled channel.
It's expected that in general for a period_length of 1 tick you can only
have 0% and 100% relative duty. IIUC for this hardware you cannot do the
100% case so there is only a single valid duty_length for period_length
= 1 tick.
I think it would be more complicated to consistently filter out
period_length = 1 tick in the driver than to just accept the conceptual
limitations. (Otherwise: What would you report in the fromhw callback if
period_length = 1 tick is configured in wfhw? Would you refuse to commit
that wfhw to hardware in .write_waveform()? The pwm core handles that
just fine and consumers have all the means to detect and prevent that if
they care enough.)
> > > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> > >
> > > Since this driver now exports a syscon, it's only builtin (=Y) so
> > > it cannot be unloaded.
> > > I've also avoided the .remove callback via .suppress_bind_attrs.
> >
> > Oh no, please work cleanly here and make the driver unbindable. This
> > yields better code quality and also helps during development and
> > debugging.
>
> I wish to, but the issue here is that this driver exports a syscon via
> of_syscon_register_regmap() which I think doesn't have the unregister
> counterpart. So the consumer will break in case we can unbind/unload
> the module and the syscon will leak.
> If you have any alternative I'll be glad to discuss.
My (not so well articulated) point is: Please be stringent about clock
handling to not bank up technical dept more than necessary and such that
the driver can be made unbindable if and when syscons grow
that feature. Optionally wail at the syscon guys :-)
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/2] media: verisilicon: Simplification and clean up
From: Frank Li @ 2026-04-17 10:43 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: nicolas.dufresne, p.zabel, mchehab, s.hauer, kernel, festevam,
heiko, mcoquelin.stm32, alexandre.torgue, wens, jernej.skrabec,
samuel, linux-kernel, linux-media, linux-rockchip, imx,
linux-arm-kernel, linux-stm32, linux-sunxi, kernel
In-Reply-To: <20260415140420.282084-1-benjamin.gaignard@collabora.com>
On Wed, Apr 15, 2026 at 04:04:18PM +0200, Benjamin Gaignard wrote:
> Simplify motion vectors and reference allocation with common helpers.
> Since it requires to move some of codecs specific functions and
> structure in codecs header files add a patch to finish the clean up.
>
Already V3:
where the change log?
Frank
> Benjamin Gaignard (2):
> media: verisilicon: Simplify motion vectors and rfc buffers allocation
> media: verisilicon: Clean up messy include
>
> drivers/media/platform/verisilicon/hantro.h | 31 +-
> .../media/platform/verisilicon/hantro_av1.c | 7 -
> .../media/platform/verisilicon/hantro_av1.h | 100 +++-
> .../platform/verisilicon/hantro_g1_h264_dec.c | 1 +
> .../verisilicon/hantro_g1_mpeg2_dec.c | 2 +-
> .../platform/verisilicon/hantro_g1_vp8_dec.c | 2 +-
> .../media/platform/verisilicon/hantro_g2.c | 36 --
> .../platform/verisilicon/hantro_g2_hevc_dec.c | 26 +-
> .../platform/verisilicon/hantro_g2_vp9_dec.c | 12 +-
> .../media/platform/verisilicon/hantro_h264.c | 2 +-
> .../media/platform/verisilicon/hantro_h264.h | 98 ++++
> .../media/platform/verisilicon/hantro_hevc.c | 37 +-
> .../media/platform/verisilicon/hantro_hevc.h | 82 ++++
> .../media/platform/verisilicon/hantro_hw.h | 446 +-----------------
> .../media/platform/verisilicon/hantro_mpeg2.c | 1 +
> .../media/platform/verisilicon/hantro_mpeg2.h | 27 ++
> .../platform/verisilicon/hantro_postproc.c | 29 +-
> .../media/platform/verisilicon/hantro_v4l2.c | 262 +++++++++-
> .../media/platform/verisilicon/hantro_vp8.c | 1 +
> .../media/platform/verisilicon/hantro_vp8.h | 29 ++
> .../media/platform/verisilicon/hantro_vp9.h | 104 ++++
> .../media/platform/verisilicon/imx8m_vpu_hw.c | 5 +
> .../verisilicon/rockchip_vpu2_hw_h264_dec.c | 2 +-
> .../verisilicon/rockchip_vpu2_hw_mpeg2_dec.c | 2 +-
> .../verisilicon/rockchip_vpu2_hw_vp8_dec.c | 2 +-
> .../verisilicon/rockchip_vpu981_hw_av1_dec.c | 16 +-
> .../platform/verisilicon/rockchip_vpu_hw.c | 3 +
> .../platform/verisilicon/stm32mp25_vpu_hw.c | 2 +
> .../media/platform/verisilicon/sunxi_vpu_hw.c | 1 +
> 29 files changed, 796 insertions(+), 572 deletions(-)
> create mode 100644 drivers/media/platform/verisilicon/hantro_h264.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_hevc.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_mpeg2.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_vp8.h
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] serial: mxs-auart: Compare the return value of gpiod_get_direction against GPIO_LINE_DIRECTION_IN
From: Nikola Z. Ivanov @ 2026-04-17 10:31 UTC (permalink / raw)
To: Frank Li
Cc: gregkh, jirislaby, s.hauer, kernel, festevam, linux-kernel,
linux-serial, imx, linux-arm-kernel
In-Reply-To: <aeHt3c9Fqp6-WdLV@lizhi-Precision-Tower-5810>
On 4/17/26 11:22 AM, Frank Li wrote:
> On Thu, Apr 16, 2026 at 11:32:54AM +0300, Nikola Z. Ivanov wrote:
>
> subjust suggest change to
>
> Replace hardcode 1 with predefined macro GPIO_LINE_DIRECTION_IN
>
> Frank
Hello,
I suppose you are suggesting a subject change, in that case I will send v2.
Also I can see that automated code review notes that this will not build
on greg's tty tree as 7.0 is not yet merged into it. I will wait for
that to happen
before mailing v2.
BR,
Nikola
>
>> The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to
>> gpio consumers.h by breaking them out in a separate defs.h file.
>>
>> Use this to validate the gpio direction instead of the hard-coded literal.
>>
>> Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
>> ---
>> drivers/tty/serial/mxs-auart.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
>> index cc65c9fb6446..6c6df4d5c21f 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -1519,7 +1519,7 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
>>
>> for (i = 0; i < UART_GPIO_MAX; i++) {
>> gpiod = mctrl_gpio_to_gpiod(s->gpios, i);
>> - if (gpiod && (gpiod_get_direction(gpiod) == 1))
>> + if (gpiod && (gpiod_get_direction(gpiod) == GPIO_LINE_DIRECTION_IN))
>> s->gpio_irq[i] = gpiod_to_irq(gpiod);
>> else
>> s->gpio_irq[i] = -EINVAL;
>> --
>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
From: Frank Li @ 2026-04-17 10:30 UTC (permalink / raw)
To: G.N. Zhou (OSS)
Cc: Krzysztof Kozlowski, Michael Riesch, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
In-Reply-To: <DU2PR04MB9081CE0130B8924A2B3C9E14FA222@DU2PR04MB9081.eurprd04.prod.outlook.com>
On Wed, Apr 15, 2026 at 09:21:44AM +0000, G.N. Zhou (OSS) wrote:
> Hi Krzysztof Kozlowski
>
> Thanks for your review.
>
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > Sent: Wednesday, April 15, 2026 4:10 PM
> > To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> > Cc: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> > <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> > <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> > Frank Li <frank.li@nxp.com>; linux-media@vger.kernel.org; linux-
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; imx@lists.linux.dev; linux-
> > arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> > Subject: Re: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
> >
> > On Wed, Apr 15, 2026 at 11:46:55AM +0800, Guoniu Zhou wrote:
> > > The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
> > > only difference being the use of IDI (Image Data Interface) instead of
> > > IPI (Image Pixel Interface). The binding constraints are otherwise the
> > > same.
> >
> > Nearly identical with some difference really, really suggests they are
> > compatible. Express compatibility or explain why they are not compatible
> > (difference between IDI and IPI unfortunately does not help me).
>
> You're right that they are very similar. The key difference between IDI and IPI
> is in the software interface:
>
> - IPI (Image Pixel Interface) on i.MX93 requires software configuration through
> a set of registers to enable the interface and configure data routing.
>
> - IDI (Image Data Interface) on i.MX95 is software transparent - it requires no
> register configuration and the data routing is handled automatically by hardware.
>
> Because of this difference in register layout and initialization requirements,
> they cannot share the same compatible string. The driver needs to know which
> interface is present
Just include these key information into commit message to do judgement
it is not compatible with imx93.
Frank
>
> >
> > Best regards,
> > Krzysztof
>
^ permalink raw reply
* [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
From: Puranjay Mohan @ 2026-04-17 10:30 UTC (permalink / raw)
To: bpf, linux-arm-kernel
Cc: Puranjay Mohan, Jonas Rebmann, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu, Russell King,
kernel
The ARM32 BPF JIT does not support BPF-to-BPF function calls
(subprogram calls). When insn->src_reg == BPF_PSEUDO_CALL, the
imm field contains a pc-relative offset to another BPF function,
not a helper function index.
When a program containing BPF-to-BPF calls is loaded, the verifier
invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each
subprogram. Since ARM32 does not reject BPF_PSEUDO_CALL, the JIT
silently emits code for the call using the wrong address computation:
func = __bpf_call_base + imm
where imm is actually a pc-relative subprogram offset, producing
a bogus function pointer. Because build_body() reports success,
bpf_jit_binary_alloc() is reached and a JIT image is allocated.
ARM32 also lacks the jit_data/extra_pass mechanism needed for
the second JIT pass in bpf_jit_subprogs(). On the second pass,
bpf_int_jit_compile() performs a full fresh compilation,
allocating a new JIT binary and overwriting prog->bpf_func. The
first allocation is never freed. bpf_jit_subprogs() then detects
the function pointer changed and aborts with -ENOTSUPP, but the
original JIT binary has already been leaked. Each program
load/unload cycle leaks one JIT binary allocation, as reported
by kmemleak:
unreferenced object 0xbf0a1000 (size 4096):
backtrace:
bpf_jit_binary_alloc+0x64/0xfc
bpf_int_jit_compile+0x14c/0x348
bpf_jit_subprogs+0x4fc/0xa60
Fix this by rejecting BPF_PSEUDO_CALL early in build_insn(),
falling through to the existing 'notyet' path. This causes
build_body() to fail before any JIT binary is allocated, so
bpf_int_jit_compile() returns the original program unjitted.
bpf_jit_subprogs() then sees !prog->jited and cleanly falls
back to the interpreter.
Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Reported-by: Jonas Rebmann <jre@pengutronix.de>
Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de
Tested-by: Jonas Rebmann <jre@pengutronix.de>
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
arch/arm/net/bpf_jit_32.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index deeb8f292454..91fef10e88bc 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -2047,6 +2047,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
/* function call */
case BPF_JMP | BPF_CALL:
{
+ if (insn->src_reg == BPF_PSEUDO_CALL)
+ goto notyet;
const s8 *r0 = bpf2a32[BPF_REG_0];
const s8 *r1 = bpf2a32[BPF_REG_1];
const s8 *r2 = bpf2a32[BPF_REG_2];
base-commit: 1f5ffc672165ff851063a5fd044b727ab2517ae3
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox