* Re: [PATCH v2 1/2] dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
From: Krzysztof Kozlowski @ 2026-06-22 12:25 UTC (permalink / raw)
To: Liu Yu
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <SY3PPF19552C607716AE1AA440C85D348B6C7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On Fri, Jun 19, 2026 at 09:23:54PM +0800, Liu Yu wrote:
> Add compatible string for the MYIR MYS-7Z020-V2 board, based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> Signed-off-by: Liu Yu <f78fk@live.com>
You should not use outlook to send messages. That platform really sucks,
meaning:
1. You might not receive answer for me, because outlook/M$ treats kernel
maintainers as spam and does not care to change it,
2. outlook rewrites message ids making threading often broken.
Recommended is to use b4 relay in such case. You have been warned...
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 13:08 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <dbb5915e-6587-4de9-87f3-76bea5024da8@kernel.org>
On Mon, 22 Jun 2026 10:05:13 +0200
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> > There's been complaints about trace_printk() being defined in kernel.h as it
> > can increase the compilation time. As it is only used by some developers for
> > debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> > cycles for those that do not ever care about it.
>
> Do we have a measurement of the increased compilation time ?
I believe Yury does.
-- Steve
^ permalink raw reply
* Re: [PATCH] mfd: db8500-prcmu: Fold dbx500 header into db8500
From: Guenter Roeck @ 2026-06-22 13:06 UTC (permalink / raw)
To: Linus Walleij, Russell King, Ulf Hansson, Michael Turquette,
Stephen Boyd, Brian Masney, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Lee Jones, Liam Girdwood, Mark Brown, Zhang Rui,
Lukasz Luba, Wim Van Sebroeck, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-kernel, linux-clk, linux-pm, linux-watchdog,
linux-sound, kernel test robot
In-Reply-To: <20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org>
On 6/19/26 13:27, Linus Walleij wrote:
> Move the DBx500 PRCMU definitions into the DB8500 PRCMU
> header and delete the wrapper header.
>
> Convert users of simple PRCMU wrappers to call the DB8500 helpers
> directly.
>
> The dbx500-prcmu.h header was the result of an earlier attempt to
> abstract several DBx5x SoC PRCMU units to use the same abstract
> header. They are deleted from the kernel and this is not just
> causing maintenance burden and build errors.
>
> The stub code is using -ENOSYS in a way checkpatch complains about
> so replace these with -EINVAL while we're at it.
>
> Assisted-by: Codex:gpt-5-5
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> arch/arm/mach-ux500/cpu-db8500.c | 6 +-
> drivers/clk/ux500/clk-prcmu.c | 20 +-
> drivers/clk/ux500/u8500_of_clk.c | 2 +-
> drivers/cpuidle/cpuidle-ux500.c | 6 +-
> drivers/mfd/ab8500-core.c | 2 +-
> drivers/mfd/db8500-prcmu.c | 6 +-
> drivers/regulator/db8500-prcmu.c | 12 +-
> drivers/thermal/db8500_thermal.c | 10 +-
> drivers/watchdog/db8500_wdt.c | 22 +-
For watchdog:
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH RFC v8 03/24] arm64: mm: Enable overlays for all EL1 indirect permissions
From: David Hildenbrand (Arm) @ 2026-06-22 13:06 UTC (permalink / raw)
To: Kevin Brodsky, linux-hardening
Cc: Andrew Morton, Andy Lutomirski, Catalin Marinas, Dave Hansen,
Ira Weiny, Jann Horn, Jeff Xu, Joey Gouly, Kees Cook,
Linus Walleij, Marc Zyngier, Mark Brown, Matthew Wilcox,
Maxwell Bland, Mike Rapoport (IBM), Peter Zijlstra,
Pierre Langlois, Quentin Perret, Rick Edgecombe, Ryan Roberts,
Vlastimil Babka, Will Deacon, Yang Shi, Yeoreum Yun,
linux-arm-kernel, linux-mm, x86, Lorenzo Stoakes, Thomas Gleixner
In-Reply-To: <20260526-kpkeys-v8-3-eaaacdacc67c@arm.com>
On 5/26/26 13:15, Kevin Brodsky wrote:
> In preparation of using POE inside the kernel, enable "Overlay
> applied" for kernel memory types in PIR_EL1. This ensures that the
> permissions set in POR_EL1 affect all kernel mappings.
>
> User memory types must be left untouched (overlays not applied)
> because any privileged access to user memory (e.g. futex atomic
> without FEAT_LSUI) would then be mistakenly checked against POR_EL1.
That makes sense. Still learning the architecture, but ... leaving the user bits
as is sounds good to me (and unrelated to using overlays for kernel memory).
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/arm64/include/asm/pgtable-prot.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 212ce1b02e15..d4d45ab86a5a 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -183,9 +183,9 @@ static inline bool __pure lpa2_is_enabled(void)
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED_EXEC), PIE_RW) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_READONLY), PIE_R) | \
> PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_SHARED), PIE_RW) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_ROX), PIE_RX) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_EXEC), PIE_RWX) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_RO), PIE_R) | \
> - PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL), PIE_RW))
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_ROX), PIE_RX_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_EXEC), PIE_RWX_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL_RO), PIE_R_O) | \
> + PIRx_ELx_PERM_PREP(pte_pi_index(_PAGE_KERNEL), PIE_RW_O))
>
> #endif /* __ASM_PGTABLE_PROT_H */
>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Hand over hclk control exclusively to Runtime PM
From: Mark Brown @ 2026-06-22 13:04 UTC (permalink / raw)
To: phucduc.bui
Cc: Heiko Stuebner, Liam Girdwood, Nicolas Frattaroli,
Krzysztof Kozlowski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260622005613.21870-1-phucduc.bui@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
On Mon, Jun 22, 2026 at 07:56:13AM +0700, phucduc.bui@gmail.com wrote:
> Although switching to devm_clk_get_enabled() in a previous patch was
> tested successfully, it introduces overlapping ownership of the clock
> lifecycle. Since the driver requires early register access to read the
> device version during probe(), enabling hclk at that point is mandatory.
> Clean up the design by:
> 1 Reverting back to devm_clk_get() to remove the implicit devres
> enable/disable behavior.
> 2 Manually enabling and disabling hclk explicitly only around the
> early register access before Runtime PM takes over.
> 3 Dropping the stray clk_disable_unprepare() at the end of probe()
> so Runtime PM solely owns hclk afterward.
Note that runtime PM can be disabled at build time so we might not have
runtime PM at all...
> Links:
> 1 This change is based on the discussion around manual hclk handing during probe(),
> as raised by Krysztof:
> https://lore.kernel.org/all/20e4754b-ea9a-404d-b529-ec44a7263cbf@kernel.org/#t
> 2 Background for the earlier devm_clk_get_enbabled() conversion:
> https://lore.kernel.org/all/2818018.CQOukoFCf9@workhorse/
> An alternative approach would be use devm_regmap_init_mmio_clk() and let regmap
> manage clock enablement around register accesses. If preferred, I can rework the
> driver accordingly.
> - sai->hclk = devm_clk_get_enabled(&pdev->dev, "hclk");
> + sai->hclk = devm_clk_get(&pdev->dev, "hclk");
> if (IS_ERR(sai->hclk))
> return dev_err_probe(&pdev->dev, PTR_ERR(sai->hclk),
> "Failed to get hclk\n");
>
> + ret = clk_prepare_enable(sai->hclk);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "Failed to enable hclk\n");
> +
> @@ -1482,8 +1492,6 @@ static int rockchip_sai_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_put(&pdev->dev);
>
> - clk_disable_unprepare(sai->hclk);
> -
> return 0;
Are you sure that the runtime PM state there is such that it knows a
reference is held? The driver used pm_runtime_get_noresume() so the
device didn't have RPM_ACTIVE set I think?
The runtime PM API really is a miserable collection of landmines :(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:56 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajU-b32dmwS7XOg4@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]
On 6/19/26 10:04 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 11:05:43PM +0900, Harry Yoo wrote:
>> On 6/18/26 10:35 PM, Harry Yoo wrote:
>>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>>> Introduce a boot option to tag only at allocation time of the objects. This
>>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>>> catching bugs.
>>>
>>> I think most of overhead when enabling MTE comes from loading and
>>> validing tags for every memory access (either in SYNC or ASYNC mode),
>>> rather than from storing tags.
>>
>> Is there any reason not to use STGM instead of STG + DC GVA when
>> setting/clearing tags for large sizes when we know they are properly
>> aligned?
>
> STGM is intended for copying tags when paired with LDGM. Have you seen
> hardware where STGM is faster than STG or DC GVA?
No, I haven't. It was a question I had after learning that there are
multiple ways to store tags ;)
> For properly aligned
> buffers, I'd expect DC GVA to behave at least on par with STGM.
Thanks for answering!
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Avoid eager DVMSync reclaim batches with C1-Pro SME erratum
From: Joshua Liu @ 2026-06-22 12:52 UTC (permalink / raw)
To: catalin.marinas; +Cc: linux-arm-kernel, will, Joshua Liu
In-Reply-To: <20260610104829.1157497-1-catalin.marinas@arm.com>
On Wed, Jun 10, 2026 at 11:37 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> Introduce the sme_active_cpus mask tracking which CPUs run in user-space
> with SME enabled and use it for batch flushing instead of accumulating
> the mm_cpumask() of the unmapped pages.
> [...]
> The dsb() in arch_tlbbatch_add_pending() -> sme_dvmsync_add_pending()
> did introduce a performance regression for kswapd. This patch restores
> the original behaviour with the barrier only issued when the TLB batch
> is flushed. The trade-off is that the IPIs are now sent to all CPUs
> running with SME enabled at EL0 even if the reclaimed pages do not
> belong to SME tasks. This is acceptable for current SME deployments.
Profiling shows this solution has robust performance for common
workloads and is the best among a few approaches we tested with Catalin,
so we are happy to go with this solution.
Some sidenotes: for certain edge cases we still observe performance
regression, specifically when a workload pegs multiple cores with SME
status threads.
Tested-by: Joshua Liu <josliu@google.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: add Axiado AX3000 PWM
From: Krzysztof Kozlowski @ 2026-06-22 12:50 UTC (permalink / raw)
To: Petar Stepanovic, Akhila Kavi, Prasad Bolisetty,
Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-pwm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-1-c9797a909414@axiado.com>
On 18/06/2026 14:26, Petar Stepanovic wrote:
> +
> +description:
> + The Axiado PWM controller found on AX3000 and AX3005 SoCs.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + const: axiado,ax3000-pwm
Description mentions AX3005, but there is no ax3005 compatible here.
This is confusing.
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: pwm
Drop clock-names, not really useful if it has block's name.
> +
> + "#pwm-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Harry Yoo @ 2026-06-22 12:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: Dev Jain, ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will
In-Reply-To: <ajVByfkLbetzA8bB@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 2477 bytes --]
Hi Catalin,
On 6/19/26 10:19 PM, Catalin Marinas wrote:
> On Thu, Jun 18, 2026 at 10:35:15PM +0900, Harry Yoo wrote:
>> On 6/12/26 1:44 PM, Dev Jain wrote:
>>> Introduce a boot option to tag only at allocation time of the objects. This
>>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>>> catching bugs.
>>
>> I think most of overhead when enabling MTE comes from loading and
>> validing tags for every memory access (either in SYNC or ASYNC mode),
>> rather than from storing tags.
>
> I guess it depends on the workload. Lots of allocations for short-lived
> buffers (e.g. network traffic) may notice the additional tagging more
> than the actual tag checking.
Agreed. Likely depends on lifetime and size of objects.
> Of course, it would be nice to get some numbers from those who have
> access to MTE capable hardware.
Agreed! (I don't have one, unfortunately. It's pretty new hardware
feature)
>>> Now, when a memory object will be freed, it will retain the random tag it
>>> had at allocation time. This compromises on catching UAF bugs, till the
>>> time the object is not reallocated, at which point it will have a new
>>> random tag.
>>>
>>> Hence, not catching "use-after-free-before-reallocation" and not catching
>>> "double-free" will be the compromise for reduced KASAN overhead.
>>
>> I doubt users who care about security enough to enable HW_TAGS KASAN
>> are willing to compromise on security just to save a few instructions
>> to store tags in the free path.
>>
>> To me, it looks like too much of a compromise on security for little
>> performance gain.
>
> I don't think there's much compromise on security for use-after-free.
I think it depends... OH, WAIT! I see what you mean.
You mean use-after-free before reallocation does not lead to much
compromise on security because objects are initialized after allocation?
You're probably right.
Hmm, but stores to e.g.) free pointer, fields initialized by
constructor or accessed by SLAB_TYPESAFE_BY_RCU semantics after free
will be undiscovered if they happen before reallocation.
Not sure what are security implications of that,
but sounds worth discussing.
> The buffer will be re-tagged later so use-after-realloc should be
> caught, especially if we ensure that a different tag will be used (I
> don't think Dev's patches do this).
Agreed that it'll be nice to ensure that.
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ixp4xx_hss: fix duplicate HDLC netdev allocation
From: Linus Walleij @ 2026-06-22 12:36 UTC (permalink / raw)
To: Haoxiang Li
Cc: kaloz, andrew+netdev, davem, edumazet, kuba, pabeni,
huangguangbin2, lipeng321, linux-arm-kernel, netdev, linux-kernel,
stable
In-Reply-To: <20260622043015.643637-1-haoxiang_li2024@163.com>
On Mon, Jun 22, 2026 at 6:30 AM Haoxiang Li <haoxiang_li2024@163.com> wrote:
> ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored
> in ndev, initialized, and registered with register_hdlc_device(). The
> second one is stored in port->netdev and later used by the remove path
> for unregister_hdlc_device() and free_netdev().
>
> This means that the registered netdev is not the same object that is
> unregistered and freed on remove. It also leaks the first allocation if
> the second alloc_hdlcdev() call fails, and the first allocation is not
> checked before ndev is used.
>
> Older code allocated the HDLC netdev only once and stored the same object
> in both the local variable and port->netdev. The buggy conversion split
> this into two alloc_hdlcdev() calls. A later rename changed the local
> variable name to ndev, but the underlying mismatch remained.
>
> Fix this by allocating the HDLC netdev only once and assigning the same
> object to port->netdev.
>
> Fixes: 99ebe65eb9c0 ("net: ixp4xx_hss: move out assignment in if condition")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-22 12:31 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260619-airoha-qos-fixes-v2-2-5c43485038f9@kernel.org>
On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> accesses in the networking stack.
> For example, allocating channel 0 then channel 3 results in
> real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> Fix this by computing real_num_tx_queues based on the highest active
> channel index rather than using a simple counter, in both the allocation
> and deletion paths.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Thanks for the update since v1.
Reviewed-by: Simon Horman <horms@kernel.org>
FTR, there is an AI-generated review of this patch on sashiko.dev.
I do not think that should impede the progress of this patch but
you may want to consider it in the context of follow-up.
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Michal Simek @ 2026-06-22 12:25 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On 6/19/26 18:38, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
here
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
and here you have different values without any explanation why.
The rest looks good to me. It is a step in a right direction.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: David Hildenbrand (Arm) @ 2026-06-22 12:20 UTC (permalink / raw)
To: Cristian Marussi
Cc: Christian Brauner, linux-kernel, linux-arm-kernel, arm-scmi,
linux-fsdevel, linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <ajU7UqwPZBlwRGkf@pluto>
>>>
>>> There is more stuff that indeed is configurable per the SCMI spec
>>> but these additional params are hidden into the SCMI Telemetry protocol
>>> layer (the initial patches in this series) and NOT made available to
>>> the driver/users of the protocol (like the SCMI FS driver that sits on
>>> top)
>>
>> Do you assume that there will get significantly more config options added in the
>> future for user space to configure?
>
> No, I dont think so...the only planned extensions were to support more
> performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
> SCMI Telemetry shared memory areas...BUT that will immediately dump all
> the bulk of the lower layer protocol work into the tools domain...and
Right. I guess you would hide that in library code, and provide a stable API
towards tools such that they won't have to worry about the implementation
details regarding how the values are obtained exactly.
[...]
>>>
>>> ...most of the other entries in the tree are simply RO properties of the DEs
>>> that have been discovered at enumeration time.
>>
>> Is this bulk-reading relevant for performance or just a "nice to have" ?
>>
>
> I suppose depends on your usage pattern: it is definitely relevant
> because the main collection mechanism are shared memory areas (SHMTIs)
> between the platform firmware and the Kernel: such areas being accessed
> from 2 differnt worlds concurrently come with a SCMI-specified
> synchro/consistency mechanism based simply on a pair of sequence numbers
> placed at the start and at the end of the SHMTI, so that the FW increases
> such magic numbers in a well-known way before and after updating the SHMTI
> values, so that the kernel can detect (without any interlocking mechanism)
> if a platform write happened in the middle of its reads...
Okay, so sequence counters to detect concurrent changes and retry.
>
> ...so if you read one single DE 64bit value, under the hood the kernel
> would have had to really perform at leats 3 reads from the SHMTI to check
> the consistecy of that single read...
>
> ... while if you do a bulk_read the overhead due to the consistecy
> checks gets 'spread' across a number of DEs because the kernel will snapshot
> the whole SHMTIs (potentially KBytes) between the 2 consistency reads
That makes sense.
I guess a user space library could implement some kind of caching (bulk-read,
then provide clean access to individual DEs) to hide the details from the tools?
>
> ...the good side effect of all of this is that I can leverage such
> sequence number to optimize reads..i.e. do NOT even try to read anything
> if the new sequnce number is unchanged from the last one I cached on the
> last successfull read of this value...
Right.
>
> So at the end I would say it is NOT simply a nice to have BUT it is
> certainly only the first step towards a more performant alternative access
> (like with mmaps)...it depends on the usage pattern...I am not sure what
> mechanism is used by our tools more...
Okay.
>>
>> Yes. How high-priority is the fs side? Or would a tool using a library to access
>> this information also work in the first step?
>>
>
> I have to sync with tools on this...because they are stiil probably
> using currently the FS, but it was already planned for the future to move to
> a more low level access (ioctl/mmap)...
>
> ...my aim would be, at this point, to favour this transition without sudden
> breaking their current world (and have to expatriate :P)
>
> ..from my personal point of view, I would certainly like to still have the
> FUSE layer for ease of testing and verification on my side...but it is just
> a nice to have...
Okay, what I thought. I assume the most important part is to be able to grab
telemetry data in an efficient way on a system to then share it with some
monitoring agent. Manually digging through the FS to inspect data (debugging,
..) is probably less relevant for the target use case.
>> Okay, so a single writer (admin) changing stuff could get picked up my possibly
>> many concurrent readers?
>
> Mmm...not sure what you mean here...
>
> If you configure your Telemetry as you desire and start collecting data via
> readers, BUT then some other process changes configs under your belt, that is
> allowed as said, and so your analisys could be impacted...(something turned off
> as an example, or update interval changed)...
I was rather wondering about "turning on more" concurrently. But yeah, makes sense.
(it's the same situation other system-wide settings. If one app enables KSM and
the another one disables KSM, inconsistency is unavoidable)
>>
>
> Thanks a lot, David !
Let's hope for some guidance regarding the FS side soon.
But yeah, avoiding the in-kernel FS sounds completely reasonable at this point.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-22 11:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de>
On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>which may timeout and is recognized as an error. This error is siltently
>dropped and not dropped to the caller.
>
>Forward the error to the caller.
>
>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 246a9a9e39520..0028073be4a71 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> u32 val;
> int ret, count;
>
>+ ret = 0;
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> return -EINVAL;
> }
>
>- return 0;
>+ return ret;
We may need to use atomic API for TXDB_V2. For the patchset itself, it
looks good to me.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
> }
>
> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>
>--
>2.53.0
>
^ permalink raw reply
* Re: [PATCH v7 5/7] KVM: arm64: Validate the offset to the mem access descriptor
From: Sebastian Ene @ 2026-06-22 11:22 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, oupton, sudeep.holla, will, jens.wiklander,
joey.gouly, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
maz, mrigendra.chaubey, op-tee, perlarsen, seiden, smostafa,
sumit.garg, suzuki.poulose, yuzenghui
In-Reply-To: <ajj_DkqiDwiF8imZ@google.com>
On Mon, Jun 22, 2026 at 09:23:26AM +0000, Sebastian Ene wrote:
> On Thu, Jun 18, 2026 at 05:56:24PM +0100, Vincent Donnefort wrote:
> > On Wed, Jun 17, 2026 at 02:51:28PM +0000, Sebastian Ene wrote:
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header.
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this from 1.1 onward:
> > > Type | Field name | Offset
> > > [ Header | ffa_mem_region | 0
> > > EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
> > > ]
> > > Verify that the offset to the first endpoint memory access descriptor
> > > is within the mailbox buffer bounds.
> > >
> > > Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that
> > > should be replaced ffa_emad_size_get() for compatibility with FFA v1.0.
> > >
> > > Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM")
> > > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 29 +++++++++++++++++++++--------
> > > 1 file changed, 21 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 2d211661952e..1a2abd0154c6 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -476,11 +476,14 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > DECLARE_REG(u32, fraglen, ctxt, 2);
> > > DECLARE_REG(u64, addr_mbz, ctxt, 3);
> > > DECLARE_REG(u32, npages_mbz, ctxt, 4);
> > > + u32 offset, nr_ranges, checked_offset, em_mem_access_off;
> > > struct ffa_mem_region_attributes *ep_mem_access;
> > > struct ffa_composite_mem_region *reg;
> > > struct ffa_mem_region *buf;
> > > - u32 offset, nr_ranges, checked_offset;
> > > int ret = 0;
> > > + size_t mem_region_len = !FFA_MEM_REGION_HAS_EP_MEM_OFFSET(hyp_ffa_version) ?
> > > + offsetof(struct ffa_mem_region, ep_mem_offset) :
> > > + sizeof(struct ffa_mem_region);
While talking with Vincent about this change, we agreed that it would be
easier to introduce a helper that will get the size of the struct
ffa_mem_region which is different based on the ff-a version.
This would hopefully increase the readability of this. The description
of the struct ffa_mem_region can be found in (Table 5.19: Lend, donate or
share memory transaction descriptor) from DEN0077A.
I will spin a new version to address this and collect the review tags.
> > >
> > > if (addr_mbz || npages_mbz || fraglen > len ||
> > > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
> > > @@ -488,8 +491,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > goto out;
> > > }
> > >
> > > - if (fraglen < sizeof(struct ffa_mem_region) +
> > > - sizeof(struct ffa_mem_region_attributes)) {
> > > + if (fraglen < mem_region_len + ffa_emad_size_get(hyp_ffa_version)) {
> >
> > Can't we replace mem_region_len with ffa_mem_desc_offset()? that pretty much
> > looks like the same thing.
> >
>
> We can't because `ffa_mem_desc_offset` dereferences struct
> ffa_mem_region to extract ep_mem_offset as per the latest updates.
>
> >
> > > ret = FFA_RET_INVALID_PARAMETERS;
> > > goto out;
> > > }
> > > @@ -508,8 +510,13 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > > buf = hyp_buffers.tx;
> > > memcpy(buf, host_buffers.tx, fraglen);
> > >
> > > - ep_mem_access = (void *)buf +
> > > - ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
> >
> > This check looks like ffa_mem_desc_offset() with count to 1.
> >
> >
> > > + ret = FFA_RET_INVALID_PARAMETERS;
> > > + goto out_unlock;
> > > + }
> > > +
> > > + ep_mem_access = (void *)buf + em_mem_access_off;
> > > offset = ep_mem_access->composite_off;
> > > if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
> > > ret = FFA_RET_INVALID_PARAMETERS;
> > > @@ -574,9 +581,9 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > DECLARE_REG(u32, handle_lo, ctxt, 1);
> > > DECLARE_REG(u32, handle_hi, ctxt, 2);
> > > DECLARE_REG(u32, flags, ctxt, 3);
> > > + u32 offset, len, fraglen, fragoff, em_mem_access_off;
> > > struct ffa_mem_region_attributes *ep_mem_access;
> > > struct ffa_composite_mem_region *reg;
> > > - u32 offset, len, fraglen, fragoff;
> > > struct ffa_mem_region *buf;
> > > int ret = 0;
> > > u64 handle;
> > > @@ -599,8 +606,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > len = res->a1;
> > > fraglen = res->a2;
> > >
> > > - ep_mem_access = (void *)buf +
> > > - ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> > > + if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
> >
> > ditto. ffa_mem_desc_offset()
> >
> > > + ret = FFA_RET_INVALID_PARAMETERS;
> > > + ffa_rx_release(res);
> > > + goto out_unlock;
> > > + }
> > > +
> > > + ep_mem_access = (void *)buf + em_mem_access_off;
> > > offset = ep_mem_access->composite_off;
> > > /*
> > > * We can trust the SPMD to get this right, but let's at least
> > > --
> > > 2.54.0.1136.gdb2ca164c4-goog
> > >
>
> Thanks,
> Sebastian
^ permalink raw reply
* Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
From: Gary Bisson @ 2026-06-22 11:22 UTC (permalink / raw)
To: Adam Thiede
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <42607fa4-485d-4142-b31c-7bfac71118d2@adamthiede.com>
Hi,
On Thu, Jun 18, 2026 at 04:06:28PM -0500, Adam Thiede wrote:
> On 1/20/26 05:36, Gary Bisson wrote:
> > Some bridges, such as the TI SN65DSI83, require the HS clock to be
> > running in order to lock its PLL during its own pre-enable function.
> >
> > Without this change, the bridge gives the following error:
> > sn65dsi83 14-002c: failed to lock PLL, ret=-110
> > sn65dsi83 14-002c: Unexpected link status 0x01
> > sn65dsi83 14-002c: reset the pipe
> >
> > Move the necessary functions from enable to pre-enable.
> >
> > Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
> > ---
> > Tested on Tungsten510 module with sn65dsi83 + tm070jdhg30 panel.
> >
> > Left mtk_dsi_set_mode() as part of the enable function to mimic what is
> > done in the Samsung DSIM driver which is known to be working the TI
> > bridge.
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 35 +++++++++++++++++------------------
> > 1 file changed, 17 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 0e2bcd5f67b7..b560245d1be9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -672,6 +672,21 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> > }
> > }
> > +static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> > +{
> > + if (!dsi->lanes_ready) {
> > + dsi->lanes_ready = true;
> > + mtk_dsi_rxtx_control(dsi);
> > + usleep_range(30, 100);
> > + mtk_dsi_reset_dphy(dsi);
> > + mtk_dsi_clk_ulp_mode_leave(dsi);
> > + mtk_dsi_lane0_ulp_mode_leave(dsi);
> > + mtk_dsi_clk_hs_mode(dsi, 0);
> > + usleep_range(1000, 3000);
> > + /* The reaction time after pulling up the mipi signal for dsi_rx */
> > + }
> > +}
> > +
> > static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > {
> > struct device *dev = dsi->host.dev;
> > @@ -724,6 +739,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > mtk_dsi_set_vm_cmd(dsi);
> > mtk_dsi_config_vdo_timing(dsi);
> > mtk_dsi_set_interrupt_enable(dsi);
> > + mtk_dsi_lane_ready(dsi);
> > + mtk_dsi_clk_hs_mode(dsi, 1);
> > return 0;
> > err_disable_engine_clk:
> > @@ -769,30 +786,12 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > dsi->lanes_ready = false;
> > }
> > -static void mtk_dsi_lane_ready(struct mtk_dsi *dsi)
> > -{
> > - if (!dsi->lanes_ready) {
> > - dsi->lanes_ready = true;
> > - mtk_dsi_rxtx_control(dsi);
> > - usleep_range(30, 100);
> > - mtk_dsi_reset_dphy(dsi);
> > - mtk_dsi_clk_ulp_mode_leave(dsi);
> > - mtk_dsi_lane0_ulp_mode_leave(dsi);
> > - mtk_dsi_clk_hs_mode(dsi, 0);
> > - usleep_range(1000, 3000);
> > - /* The reaction time after pulling up the mipi signal for dsi_rx */
> > - }
> > -}
> > -
> > static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > {
> > if (dsi->enabled)
> > return;
> > - mtk_dsi_lane_ready(dsi);
> > mtk_dsi_set_mode(dsi);
> > - mtk_dsi_clk_hs_mode(dsi, 1);
> > -
> > mtk_dsi_start(dsi);
> > dsi->enabled = true;
> >
> > ---
> > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > change-id: 20260120-mtkdsi-29e4c84e7b38
> >
> > Best regards,
>
> Hello,
> This commit was part of 7.1 and caused a problem for me.
> I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
> chromebook with a Mediatek MT8173 processor.
> The problem: when the display on my laptop powers off (via suspend or idle,
> like xset dpms off) the picture does not come back when the display powers
> back on (from resume). The display backlight comes on and brightness is
> adjustable but there is no picture. The only fix is to reboot.
>
> Reverting this commit and applying it as a patch on top of 7.1 addresses the
> issue for me.
>
> You can view the config I'm using here:
> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8819
>
> Is there any sort of testing or other debugging info I can provide to help
> address this issue?
Thanks for reporting the issue, could you share some logs? Is the driver
saying anything during resume? Also, what type of panel is used on that
chromebook?
Thanks,
Gary
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: linux-kernel-dev @ 2026-06-22 11:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley, Guillaume La Roque,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
In-Reply-To: <2e2a93c7-6bf9-49f2-95ed-f44cf767e9fd@kernel.org>
On 6/22/26 12:02 PM, Krzysztof Kozlowski wrote:
> On 24/04/2026 17:45, Ronald Claveau via B4 Relay wrote:
>> + - |
>> + temperature-sensor@20000 {
>> + compatible = "amlogic,t7-thermal";
>> + reg = <0x0 0x20000 0x0 0x50>;
>> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
>
>
> This wasn't ever even built! Really, it fails immediately. I will send
> fixes, but quite disappointing that contributor does not test its own code.-
>
My bad, I thought that `CHECK_DTBS=y` was enough to test
`dt_binding_check` as well. I add it again to my build tests.
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH V2 1/3] dt-bindings: dma: xilinx: Add optional resets property for ZDMA
From: Krzysztof Kozlowski @ 2026-06-22 11:02 UTC (permalink / raw)
To: Golla Nagendra
Cc: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
jay.buddhabhatti, harini.katakam, m.tretter, radhey.shyam.pandey,
abin.joseph, kees, sakari.ailus, git, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-2-nagendra.golla@amd.com>
On Thu, Jun 18, 2026 at 12:40:54PM +0530, Golla Nagendra wrote:
> From: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
>
> Newer SoCs such as Versal Gen2 and Versal‑Net expose a reset line
> for ZDMA. Older SoCs do not have this provision. Add an optional
> resets property to describe this reset.
It should be then restricted further per each variant/device in
allOf:if:then: (see example-schema for syntax - ": false").
>
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
> Co-developed-by: Golla Nagendra <nagendra.golla@amd.com>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Krzysztof Kozlowski @ 2026-06-22 10:57 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-2-6859e29e72a8@proton.me>
On Wed, Jun 17, 2026 at 10:37:00PM +0900, Zakariya Hadrami wrote:
> Add entry for the MT8127 based Amazon ford tablet.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 4/5] dt-bindings: dmaengine: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
From: Krzysztof Kozlowski @ 2026-06-22 10:41 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel, Frank Li
In-Reply-To: <20260622-sun60i-a733-dma-v3-4-f697ef296cbc@gmail.com>
On Mon, Jun 22, 2026 at 01:36:26AM +0000, Yuanshen Cao wrote:
> Add `allwinner,sun60i-a733-dma` to the list of compatible strings for the
> `sun50i-a64-dma` dtbinding documentation.
>
> While the A733 DMA controller shares many similarities with the sun50i-a64
> DMA controller, it requires a specific configuration due to differences in:
> - Interrupt register layout and mapping.
> - Number of channels per interrupt register.
> - Support for higher (32G) address widths in LLI parameters.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Laurent Pinchart @ 2026-06-22 10:39 UTC (permalink / raw)
To: Frank Li
Cc: Sakari Ailus, Mauro Carvalho Chehab, Michael Riesch, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <ajNwgq96WRrykE5I@SMW015318>
Hi Frank,
On Wed, Jun 17, 2026 at 11:13:55PM -0500, Frank Li wrote:
> On Thu, Jun 18, 2026 at 01:36:20AM +0300, Sakari Ailus wrote:
> > On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> > > From: Frank Li <Frank.Li@nxp.com>
> > >
> > > Many V4L2 subdev drivers implement the same registration and media pad
> > > setup logic for simple pipelines consisting of a single sink pad and a
> > > single source pad. As a result, the same boilerplate code is duplicated
> > > across multiple drivers.
> > >
> > > Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> > > registration, media entity initialization, and cleanup paths. Drivers
> > > can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> > > APIs instead of open-coding the setup sequence.
> >
> > I appreciate your efforts in trying to reduce the amount of code drivers
> > need simply to get things done but I think there are a few issues with the
> > approach taken in this patch:
> >
> > - The new helpers aren't generic enough, but require two pads; one sink,
> > one source.
>
> It can cover many case already, there are many bridge type subdev. after
> glace of all code, many CSI2RX is type device. It should one kind important
> type/case, like sensors.
>
> And I plan do 1 TO N replicator driver, which duplicate 1 sink pad to N
> source pad (with/without register config), plus exist video-mux driver,
>
> It think It can cover more than 80% cases.
>
> > You could provide special helpers for just this case, but
> > right now it looks like that if there's something you need that the
> > helper assumes you don't, you can't use the helper at all. In other
> > words, more modularity would be nice.
>
> We can add it later if need, which easy to replace 1to1 API, like I did
> for sensor one.
>
> > - The new helper should work with the existing types and not add new types
> > (struct v4l2_subdev_1to1).
>
> May be save vep data into v4l2_subdev to avoid parse it every time. and
> enhence media_entity_pads_init() to avoid refer caller data.
I agree with Sakari about not introducing a new structure.
We could create a version of media_entity_pads_init() that allocates the
pads array dynamically (*not* with a devm_* function !), and free it in
media_entity_cleanup().
> >
> > - There should be a way to provide default V4L2 fwnode endpoint
> > configuration as well as to validate the obtained configuration.
>
> Do you means remote_bustype_cap_mask information get from a callback?
>
> > I don't have a good proposal to address the above but at least one way I
> > can think of making error handling easier would be to use devm_() for
> > teardown in more places we to today. That certainly does have its own
> > issues though.
>
> I tried it before, media and v4l2's clean up is not revised order of init.
> Sorry, I can't find original thread. I remember laurnet pinchart said there
> are order problem.
>
> 1 v4l2_subdev_init()
> 2. v4l2_async_subdev_nf_init()
> 3. v4l2_async_nf_register()
> 4. media_entity_pads_init()
> 5 v4l2_async_register_subdev()
>
>
> v4l2_async_unregister_subdev(sd);
> v4l2_subdev_cleanup(sd); // Not sure if it save to move to last step
> media_entity_cleanup(&sd->entity);
> v4l2_async_nf_unregister(&csi2->notifier);
> v4l2_async_nf_cleanup(&csi2->notifier);
The cleanup procedure is really bad, it's a known issue. Fixing that
involves resuming Sakari's work on life time management in V4L2.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] cpufreq: apple-soc: Add missing OPP table cleanup on init failure
From: Viresh Kumar @ 2026-06-22 8:25 UTC (permalink / raw)
To: Haoxiang Li
Cc: sven, j, neal, rafael, asahi, linux-arm-kernel, linux-pm,
linux-kernel
In-Reply-To: <20260622063148.751787-1-haoxiang_li2024@163.com>
On 22-06-26, 14:31, Haoxiang Li wrote:
> apple_soc_cpufreq_init() adds the OPP table with
> dev_pm_opp_of_add_table(), but some later error
> paths can return without removing it.
>
> Add the missing dev_pm_opp_of_remove_table() call
> to clean up the OPP table on init failure.
>
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/cpufreq/apple-soc-cpufreq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/apple-soc-cpufreq.c b/drivers/cpufreq/apple-soc-cpufreq.c
> index 9396034167e5..4dae968e84df 100644
> --- a/drivers/cpufreq/apple-soc-cpufreq.c
> +++ b/drivers/cpufreq/apple-soc-cpufreq.c
> @@ -260,7 +260,7 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
> ret = apple_soc_cpufreq_find_cluster(policy, ®_base, &info);
> if (ret) {
> dev_err(cpu_dev, "%s: failed to get cluster info: %d\n", __func__, ret);
> - return ret;
> + goto out_remove_table;
> }
>
> ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
> @@ -326,6 +326,8 @@ static int apple_soc_cpufreq_init(struct cpufreq_policy *policy)
> dev_pm_opp_remove_all_dynamic(cpu_dev);
This driver doesn't add any dynamic (non DT) OPPs, looks like this is incorrect
?
> out_iounmap:
> iounmap(reg_base);
> +out_remove_table:
> + dev_pm_opp_of_remove_table(cpu_dev);
This is also required to be done in apple_soc_cpufreq_exit() ?
> return ret;
> }
--
viresh
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-06-22 10:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Michael Walle, Bartosz Golaszewski, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
wbg@kernel.org, mathieu.dubois-briand@bootlin.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <CAD++jLncD2ZjH3aedOkGNYP3FyZ=i7Pb0OcKKZKuMOPGNjM_nQ@mail.gmail.com>
On Fri, Jun 19, 2026 at 11:08:30PM +0200, Linus Walleij wrote:
> On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
>
> > >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> > >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> > >>> map() function.
> >
> > Why is gpiochip_irq_reqres() called in the first place? Isn't that
> > only called if the irq handling is set up via gc->irq.chip and not
> > via gpiochip_irqchip_add_domain() like in gpio-regmap?
>
> Not really, the gpiochip_irq_reqres() is called to mark that a
> GPIO line is used for IRQ, so the gpiolib cannot turn this
> GPIO into an output line, gpiod_direction_out() will fail
> on lines used for IRQ. So it's a failsafe.
>
> You can live without it of course, but then you don't get
> this failsafe.
So, when we instantiate our own domain in regmap GPIO, we should have those
callbacks be defined somewhere?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Geert Uytterhoeven @ 2026-06-22 10:35 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 21 Jun 2026 at 04:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
> which already has that soc: label. The soc: label is useful in U-Boot
> where it is used in U-Boot extras DT fragments.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
For the whole series:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3, squashed into a single
commit. Unfortunately there is no cover letter, so I will have to add
all nine Link-tags.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/1] coresight: fix issue where coresight component has no claimtags
From: Leo Yan @ 2026-06-22 10:26 UTC (permalink / raw)
To: Mike Leach
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
james.clark
In-Reply-To: <20260619160148.499223-2-mike.leach@arm.com>
Hi Mike,
On Fri, Jun 19, 2026 at 05:01:48PM +0100, Mike Leach wrote:
[...]
> Any device which is not verified to support claim tags, will now get a
> success return from the claim/disclaim calls.
Do we really want to relax this?
AFAIK, all Arm standard modules should follow the claim tag protocol.
SoC specific modules that do not support claim tags should not enable
claim tag handling in the first place. In that case, they would not
need any claim tag-related operations.
The tricky part is that if a module provides CORESIGHT_CLAIMSET, it
likely supports claim tags. Conversely, if a module does not provide
CORESIGHT_CLAIMSET, validating claim tags using that offset seems
pointless.
As a result, can we constraint to only two cases as below?
enum coresight_claim_tag_info {
CS_CLAIM_TAG_STD_PROTOCOL,
CS_CLAIM_TAG_IGNORE,
};
For CS_CLAIM_TAG_STD_PROTOCOL type, it must pass the validation.
Otherwise, the claim tag operations will be totally ignored.
[...]
> diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
> index 43abe13995cf..d8a0ecc502af 100644
> --- a/drivers/hwtracing/coresight/coresight-catu.c
> +++ b/drivers/hwtracing/coresight/coresight-catu.c
> @@ -574,10 +574,14 @@ static int __catu_probe(struct device *dev, struct resource *res)
> catu_desc.subtype.helper_subtype = CORESIGHT_DEV_SUBTYPE_HELPER_CATU;
> catu_desc.ops = &catu_ops;
>
> - coresight_clear_self_claim_tag(&catu_desc.access);
> drvdata->csdev = coresight_register(&catu_desc);
> if (IS_ERR(drvdata->csdev))
> ret = PTR_ERR(drvdata->csdev);
> +
> + ret = coresight_init_claim_tags(drvdata->csdev);
> + if (ret)
> + coresight_unregister(drvdata->csdev);
> +
coresight_init_claim_tags() is much simpler than coresight_register(),
this is why we can put coresight_init_claim_tags() before
coresight_register() to avoid complex rollback operations for claim init
failure.
I have no strong opinion for this, as the sequence in this patch should
can work as well.
> +/* helper for checking if claim tag protocol in use */
> +static bool coresight_using_claim_tag_protocol(struct coresight_device *csdev)
> +{
> + return (bool)(csdev->claim_tag_info == CS_CLAIM_TAG_STD_PROTOCOL);
> +}
Redundant for bool cast?
> +
> +/* helper to check initialised */
> +static bool coresight_claim_tag_noinit(struct coresight_device *csdev)
> +{
> + return (bool)(csdev->claim_tag_info == CS_CLAIM_TAG_UNKNOWN);
Ditto.
> +/* cpu bound devices (etms) may need to run on bound cpu */
> +int coresight_init_claim_tags_cpu_smp(struct coresight_device *csdev, int cpu)
> +{
> + int ret = 0;
> + struct cs_claim_tag_init_arg arg = { };
> +
> + arg.csdev = csdev;
> + ret = smp_call_function_single(cpu,
> + coresight_init_claim_tags_smp_call,
> + &arg, 1);
> +
> + if (!ret)
> + ret = arg.rc;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(coresight_init_claim_tags_cpu_smp);
Do we really need a specific SMP call for this? I understand this will
be used by ETMv3/v4 drivers, can we simply init claim tags in the local
functions (e.g., etm4_init_arch_data() for ETMv4), same as the current
implemenation?
Thanks,
Leo
^ 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