* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-24 14:02 UTC (permalink / raw)
To: Michal Simek
Cc: tanmay.shah, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <59d9a4c9-1f12-4de9-a0d6-613d2f5e9852@amd.com>
On Wed, 24 Jun 2026 at 00:12, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/23/26 00:29, Shah, Tanmay wrote:
> > Hello,
> >
> >
> > On 6/22/2026 7:25 AM, Michal Simek wrote:
> >>
> >>
> >> 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 value in the comment is correct, but the check is done for all of
> > OCM address range. This is just refactoring of the interfaces and not
> > the actual logic. There is a separate patch which actually refactors the
> > logic, I will send it later. I would like to keep this as it is because
> > this was originally there, and the intent of the commit is not to modify it.
>
> ok.
>
> Acked-by: Michal Simek <michal.simek@amd.com>
>
Michal - do you prefer that I pick this patch on the remoteproc side?
> Thanks,
> Michal
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The PCIe PHY node references mipi_pcie_analog_dphy via its phys property.
Enable this analog PHY node to make PCIe functionally viable.
Fixes: 9715b01da6cf ("arm64: dts: meson-axg-s400: enable PCIe M.2 Key E slots")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7ba249cc3d56..4f13e2b041e1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -431,6 +431,10 @@ gpio_speaker: gpio-controller@1f {
};
};
+&mipi_pcie_analog_dphy {
+ status = "okay";
+};
+
&pdm {
pinctrl-0 = <&pdm_dclk_a14_pins>, <&pdm_din0_pins>,
<&pdm_din1_pins>, <&pdm_din2_pins>, <&pdm_din3_pins>;
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Adrian Barnaś @ 2026-06-24 13:57 UTC (permalink / raw)
To: Mike Rapoport
Cc: Brendan Jackman, linux-arm-kernel, linux-mm, Catalin Marinas,
Will Deacon, Ryan Roberts, David Hildenbrand, Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman, owner-linux-mm
In-Reply-To: <ajLqGZ7sfKsQaSf4@kernel.org>
On Wed, Jun 17, 2026 at 09:40:25PM +0300, Mike Rapoport wrote:
>Hi Adrian,
>
>On Wed, Jun 17, 2026 at 03:18:27PM +0000, Adrian Barnaś wrote:
>> On Fri, Jun 12, 2026 at 10:17:55AM +0300, Mike Rapoport wrote:
>> > >
>> > > Hm, maybe desirable for execmem but that doesn't really mean the x86
>> > > behaviour is correct. Maybe it makes more sense to change the x86
>> > > to align with the arm64 behaviour here?
>> > >
>> > > BTW we should probably document this API a little bit, I never thought
>> > > abut what "valid" actually means until now. I had thought of it as "I
>> > > can access this memory" but that's an unclear concept and now I realise
>> > > "valid" is a technical concept in Arm that's confusing. And it's extra
>> > > confusing if the kernel API uses "valid" to mean a _different_ thing.
>> >
>> > I've got confused too and that's how set_direct_map_valid() got into x86
>> > with a different semantics than on arm64.
>> >
>> > What execmem really needs is set_direct_map_default() variant that gets
>> > nr_pages.
>> >
>> > AFAIR, set_direct_map_default() has a single 'page' parameter because it
>> > was added to reset permissions for the direct map alias for vmalloc()'ed
>> > pages before there was VMALLOC_HUGE and each page had to be reset
>> > independently anyway.
>> >
>> > Maybe it's time to add nr_pages to set_direct_map_valid().
>>
>> I was also quite confused by this initially. I spent some time debugging
>> until I realized why unloading all the modules was causing the kernel to
>> crash.
>>
>> The reason I took this approach was that I wanted to send out a working
>> prototype for arm64 that wouldn't interfere with the existing, working
>> implementation on x86.
>>
>> Following your suggestion, I can put together a preparatory patch series to
>> refactor the set_direct_map_* APIs to accept a nr_pages parameter. This
>
>There was a patch Nikita sent a while ago that does something similar:
>
>https://lore.kernel.org/all/20260410151746.61150-2-kalyazin@amazon.com
>
>I believe you can start from there.
>
I will pick the 01 patch from there to my series.
>> refactoring would also allow us to drop the redundant set_area_direct_map
>
>We can't drop set_area_direct_map() because vmalloc pages might be not
>physically contiguous.
>
Agree.
>> helper. I could then rebase the rox_cache series on top of that.
>>
>> Does this sound like a good path forward?
>>
>> Thanks,
>> Adrian
>
>--
>Sincerely yours,
>Mike.
Thanks,
Adrian
^ permalink raw reply
* [PATCH v4 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-24 13:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
- Enable mipi_pcie_analog_dphy for PCIe on S400 board.
Changes in v4:
- Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
- Link to v3:
https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (4):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for
PCIe
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 8 ++++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [RFC PATCH 2/6] arm64: mm: allow huge vmap permission adjustments with bbml2_no_abort
From: Adrian Barnaś @ 2026-06-24 13:54 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <07ab8b6f-cb58-4f8c-af7e-c99c2fb8933a@arm.com>
On Thu, Jun 18, 2026 at 03:21:24PM +0100, Ryan Roberts wrote:
>On 11/06/2026 14:01, Adrian Barnaś wrote:
>> Remove the protection against huge vmap permission adjustments on
>> systems that support the bbml2_no_abort CPU feature.
>>
>> Splitting live kernel VA section mappings into page mappings was
>> restricted because it could cause TLB Conflict Aborts. This forced
>> permission adjustments on memory allocated with VM_ALLOW_HUGE_VMAP to be
>> rejected, resulting in performance drops (e.g., when enforcing rodata=on
>> disables huge mappings).
>>
>> The bbml2_no_abort feature (which mirrors the architectural guarantees of
>> FEAT_BBML3) ensures that changing between table and block sizes without
>> following a break-before-make sequence will not generate a TLB Conflict
>> Abort. This hardware guarantee makes it safe to allow dynamic permission
>> adjustments on huge vmap regions.
>
>FYI Linu Cherian has a series that renames bbml2_no_abort to bbml3. I think he's
>planning to post at -rc1. Would be good to rebase this on top once merged.
>
I will keep an eye on next releases.
>>
>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>> ---
>> arch/arm64/mm/pageattr.c | 22 ++++++++++++++--------
>> 1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index 358d1dc9a576..88720bbba892 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -157,23 +157,29 @@ static int change_memory_common(unsigned long addr, int numpages,
>> }
>>
>> /*
>> - * Kernel VA mappings are always live, and splitting live section
>> - * mappings into page mappings may cause TLB conflicts. This means
>> - * we have to ensure that changing the permission bits of the range
>> - * we are operating on does not result in such splitting.
>> - *
>> * Let's restrict ourselves to mappings created by vmalloc (or vmap).
>> - * Disallow VM_ALLOW_HUGE_VMAP mappings to guarantee that only page
>> - * mappings are updated and splitting is never needed.
>> *
>> * So check whether the [addr, addr + size) interval is entirely
>> * covered by precisely one VM area that has the VM_ALLOC flag set.
>> */
>> area = find_vm_area((void *)addr);
>> +
>> if (!area ||
>> ((unsigned long)kasan_reset_tag((void *)end) >
>> (unsigned long)kasan_reset_tag(area->addr) + area->size) ||
>> - ((area->flags & (VM_ALLOC | VM_ALLOW_HUGE_VMAP)) != VM_ALLOC))
>> + !(area->flags & VM_ALLOC))
>> + return -EINVAL;
>> +
>> + /*
>> + * Kernel VA mappings are always live, and splitting live section
>> + * mappings into page mappings may cause TLB conflicts if bbml2_noabort
>> + * is not present.
>> + *
>> + * While bbml2_noabort is not present disallow VM_ALLOW_HUGE_VMAP mappings
>> + * to guarantee that only page mappings are updated and splitting is not
>> + * needed.
>> + */
>> + if (!system_supports_bbml2_noabort() && (area->flags & (VM_ALLOW_HUGE_VMAP)))
>
>nit: no need for the parentheses around VM_ALLOW_HUGE_VMAP.
>
>With that:
>
>Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
>
>> return -EINVAL;
>>
>> if (!numpages)
>
Thanks,
Adrian
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-24 13:51 UTC (permalink / raw)
To: Jie Gan, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <f39ec59f-97c4-4d5f-bf02-560adae312d9@oss.qualcomm.com>
On 24/06/2026 14:48, Jie Gan wrote:
>
>
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
>
> For an AMBA device, the periphid is mandatory for probing. In the
> amba_match function, AMBA attempts to read the periphid from the CID/PID
> registers if the arm,primecell-periphid property is absent in the device
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe
> ultimately fails.
Why does it fail ? power management ? hw broken ? Is it really AMBA or
do you pretend that to be an AMBA device by faking the CID/PID?
Suzuki
> Most AMBA devices expose valid CID/PID registers, so specifying
> arm,primecell-periphid in the device tree is usually unnecessary.
> However, for the TraceNoC device in this case, AMBA cannot reliably read
> the periphid from the corresponding registers.
>
>> And is this required for all TNOC devices?
>
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali
> platforms, and all exhibit probe failures due to the same root cause.
>
> I prefer to fix it on Kaanapali first.
>
> Thanks,
> Jie
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [RFC PATCH 3/6] arm64: mm: fix restoring linear map permissions on execmem cache clean
From: Adrian Barnaś @ 2026-06-24 13:52 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <751c564b-d6c3-4bd5-a269-e3de89e8cf13@arm.com>
On Fri, Jun 19, 2026 at 09:33:18AM +0100, Ryan Roberts wrote:
>On 18/06/2026 16:05, Ryan Roberts wrote:
>> On 11/06/2026 14:01, Adrian Barnaś wrote:
>>> Strip the read-only attribute from the selected memory range when
>>> restoring the linear map after an execmem cache clean.
>>>
>>> An execmem cache clean is performed when a cache block becomes empty
>>> after unloading a module. When making the memory valid again, the linear
>>> memory alias must also have its read-only attribute cleared.
>>>
>>> Without this change, the linear memory alias remains read-only even
>>> after the execmem cache block itself is freed, which prevents subsequent
>>> allocations from writing to that memory.
>>>
>>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>>> ---
>>> arch/arm64/mm/pageattr.c | 17 ++++++++++++++++-
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>>> index 88720bbba892..eaefdf90b0d5 100644
>>> --- a/arch/arm64/mm/pageattr.c
>>> +++ b/arch/arm64/mm/pageattr.c
>>> @@ -239,6 +239,13 @@ int set_memory_x(unsigned long addr, int numpages)
>>> __pgprot(PTE_PXN));
>>> }
>>>
>>> +static int set_memory_default(unsigned long addr, int numpages)
>>> +{
>>> + return __change_memory_common(addr, PAGE_SIZE * numpages,
>>> + __pgprot(PTE_VALID),
>>> + __pgprot(PTE_RDONLY));
>>
>> This is not sufficient to convert an invalid entry to valid. As well as setting
>> the PTE_VALID bit, you would also need to clear the PTE_PRESENT_INVALID and set
>> PTE_MAYBE_NG.
>>
>> e.g:
>>
>> int set_memory_valid(unsigned long addr, int numpages, int enable)
>> {
>> if (enable)
>> return __change_memory_common(addr, PAGE_SIZE * numpages,
>> __pgprot(PTE_PRESENT_VALID_KERNEL),
>> __pgprot(PTE_PRESENT_INVALID));
>>
Thanks, I will fix that
>>
>>> +}
>>> +
>>> int set_memory_valid(unsigned long addr, int numpages, int enable)
>>> {
>>> if (enable)
>>> @@ -362,7 +369,15 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
>>> if (!can_set_direct_map())
>>> return 0;
>>>
>>> - return set_memory_valid(addr, nr, valid);
>>> + /*
>>> + * Execmem cache uses this function to reset permissions on linear mapping
>>> + * when freeing unused cache block. On x86 it makes memory RW which is
>>> + * desirable. On ARM64 set_memory_valid() just change valid bit which
>>> + * leave direct mapping read-only so use set_memory_default instead.
>>> + */
>>> +
>>> + return valid ? set_memory_default(addr, nr) :
>>> + set_memory_valid(addr, nr, false);
>>
>> Surely execmem should just be using set_direct_map_default_noflush() if that's
>> the behaviour it wants?
>>
>> I think that the current implementation of set_direct_map_default_noflush()
>> doesn't undo the effects of set_memory_nx() / set_memory_x(). That might be
>> worth checking?
>
>It's also worth mentioning that set_direct_map_valid_noflush() has "noflush" in
>the name, implies it doesn't expect/require any TLB flushing to occur. But the
>implementation will perform tlb flushing for any case that is not just a
>invalid->valid transition (which for the existing impl is the case when
>valid=true and for your changes is never the case - see __change_memory_common).
>
>But execmem doesn't do any tlb flushing so it looks to me like it actually
>requires that set_direct_map_valid_noflush() handles the tlb flushing? All seems
>a bit fishy and probably warrants a cleanup to make things clearer.
>
I think that the clean approach would be to have the `set_direct_map_default`
function (without `noflush`) that does flushing as needed (like the current
one on ARM64). I am not entirely sure but x86 seems to handle permission
faults gracefully while on ARM64 those would cause panics. Is that correct?
>>
>> Thanks,
>> Ryan
>>
>>
>>> }
>>>
>>> #ifdef CONFIG_DEBUG_PAGEALLOC
>>
>
Thanks,
Adrian
^ permalink raw reply
* Re: [PATCH v6 0/2] add mcf54415 DAC driver
From: Angelo Dureghello @ 2026-06-24 13:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Angelo Dureghello, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Geert Uytterhoeven, Maxime Coquelin,
Alexandre Torgue, linux-kernel, linux-iio, linux-m68k,
linux-stm32, linux-arm-kernel
In-Reply-To: <ajr4LvdPZKHrqDVp@ashevche-desk.local>
Hi Andy,
On Wed, Jun 24, 2026 at 12:18:38AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 11:04:14PM +0200, Angelo Dureghello wrote:
> > This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
> > builtin DACs.
> >
> > Currently the driver enables the raw write only. Feature as dma, sync, or
> > format are not supoprted for this version.
> >
> > Additional options suppoerted by the DAC module will be added to the driver
> > later on, as needed.
> >
> > The same patchset prepares the m68k/coldfire architecture to support
> > the driver.
> >
> > Below some basic tests done on stmark2 mcf54415-based board, voltage check
> > on DAC0 and DAC1:
> >
> > ~ # cd /sys/bus/iio/devices/iio:device0/
> > /sys/bus/iio/devices/iio:device0 # ls
> > name out_voltage_scale uevent
> > out_voltage_raw subsystem
> > /sys/bus/iio/devices/iio:device0 # cat name
> > mcf54415
> > /sys/bus/iio/devices/iio:device0 # echo 4095 > out_voltage_raw
> > /sys/bus/iio/devices/iio:device0 # echo 2048 > out_voltage_raw
> > /sys/bus/iio/devices/iio:device0 # echo 4096 > out_voltage_raw
> > sh: write error: Invalid argument
> > /sys/bus/iio/devices/iio:device0 # cat out_voltage_raw
> > 2048
> > /sys/bus/iio/devices/iio:device0 #
> >
> > Same behavior for /sys/bus/iio/devices/iio:device1.
> >
> > Generated a sine wave by shell script, sine shape is good.
>
> Heard a presentation (Embedded Recipes IIRC) where one tried sine and real
> sound (it was about sound DAC) was really awful. So, Can you try a bit more
> sophisticated signal?
>
sure can try some sound with this 12-bit, but don't think is possible now
with only raw output. My idea is with further patches, once ColdFire DMA
is fixed, to extend the driver and be able to sample higher frequencies.
> --
> With Best Regards,
> Andy Shevchenko
>
>
Regards,
angelo
^ permalink raw reply
* Re: [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-24 13:49 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB68027B9C426D7CD42E256B92E8ED2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Hi Carlos,
On Wed, 24 Jun 2026 09:22:02 +0000
"Carlos Song (OSS)" <carlos.song@oss.nxp.com> wrote:
> > -----Original Message-----
> > From: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> > Sent: Tuesday, June 23, 2026 11:33 PM
> > To: Mark Brown <broonie@kernel.org>; Frank Li <frank.li@nxp.com>;
> > Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Carlos
> > Song <carlos.song@nxp.com>; linux-spi@vger.kernel.org;
> > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org Cc: javier.pastrana@linutronix.de;
> > stable@vger.kernel.org Subject: [PATCH] spi: imx: reconfigure for
> > PIO when DMA cannot be started
> >
> > [You don't often get email from javier.pastrana@linutronix.de.
> > Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
> > spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
> > spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and
> > the SDMA watermarks.
> >
> > If the DMA descriptor cannot be prepared
> > (dmaengine_prep_slave_single() returns NULL), the transfer is
> > failed with SPI_TRANS_FAIL_NO_START and falls back to PIO. The
> > dynamic-burst DMA path uses its own bounce buffers instead of the
> > SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the
> > core's DMA->PIO retry is skipped; the driver falls back to PIO
> > internally. But none of the DMA-mode configuration is undone, so
> > the PIO transfer runs with CTRL.SMC set, the wrong burst length and
> > dynamic_burst cleared, and the transferred data is corrupted.
> >
> > This is easily hit on i.MX8MP boards that describe ECSPI DMA in the
> > device tree but run SDMA on ROM firmware (no external
> > sdma-imx7d.bin): every ECSPI DMA prepare fails. An Infineon SLB9670
> > TPM on ECSPI1 then returns shifted TPM2_GetCapability data, is
> > flagged "field failure mode", /dev/tpmrm0 is never created.
> >
> > Mark the controller PIO-only (controller->fallback) and re-run
> > spi_imx_setupxfer() before falling back, so the ECSPI is
> > reconfigured exactly like a normal PIO transfer.
> >
> > Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for
> > ECSPI DMA mode")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Javier Fernandez Pastrana
> > <javier.pastrana@linutronix.de> ---
> > drivers/spi/spi-imx.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index
> > 480d1e8b281f..64c78bd79d7d 100644
> > --- a/drivers/spi/spi-imx.c
> > +++ b/drivers/spi/spi-imx.c
> > @@ -2153,6 +2153,8 @@ static int spi_imx_transfer_one(struct
> > spi_controller *controller,
> > ret = spi_imx_dma_transfer(spi_imx, transfer);
> > if (transfer->error & SPI_TRANS_FAIL_NO_START) {
> > spi_imx->usedma = false;
> > + controller->fallback = true;
> > + spi_imx_setupxfer(spi, transfer);
>
> Hi, Javier
>
> Thank you very much for fixing this issue!
>
> You can remove this line also: spi_imx->usedma = false;
> Because spi_imx_setupxfer() will recheck spi_imx_can_dma() and return
> false because controller->fallback = true;
>
> How do you think about it?
Good catch. You're right, spi_imx_setupxfer() rechecks
spi_imx_can_dma(), so spi_imx->usedma = false is redundant.
I'll remove it in v2.
Thanks for reviewing!
>
> Carlos Song
>
> > if (spi_imx->target_mode)
> > return
> > spi_imx_pio_transfer_target(spi, transfer);
> > else
> > --
> > 2.47.3
> >
>
Javier
--
Javier Fernandez Pastrana
Linutronix GmbH | Bahnhofstraße 3 | D-88690 Uhldingen-Mühlhofen
Phone: +49 7556 25 999 32; Fax.: +49 7556 25 999 99
Hinweise zum Datenschutz finden Sie hier (Informations on data privacy
can be found here): https://linutronix.de/legal/data-protection.php
Linutronix GmbH | Firmensitz (Registered Office): Uhldingen-Mühlhofen |
Registergericht (Registration Court): Amtsgericht Freiburg i.Br., HRB700
806 | Geschäftsführer (Managing Directors): Heinz Egger, Thomas
Gleixner, Sharon Heck, Yulia Beck, Tiffany Silva
^ permalink raw reply
* Re: [PATCH v15 06/11] arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
From: Ada Couprie Diaz @ 2026-06-24 13:46 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-7-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Move the rseq_syscall() check earlier in the syscall exit path to ensure
> it operates on the original instruction pointer (regs->pc) before any
> potential modification by a tracer.
>
> [Background]
> When CONFIG_DEBUG_RSEQ is enabled, rseq_syscall() verifies that a system
> call was not executed within an rseq critical section by examining
> regs->pc. If a violation is detected, it triggers a SIGSEGV.
>
> [Problem]
> Currently, arm64 invokes rseq_syscall() after report_syscall_exit().
> However, during report_syscall_exit(), a ptrace tracer can modify the
> task's instruction pointer via PTRACE_SETREGS. This leads to an
> inconsistency where rseq may analyze a post-trace PC instead of the
> actual PC at the time of syscall exit.
>
> [Why this matters]
> The rseq check is intended to validate the execution context of the
> syscall itself. Analyzing a tracer-modified PC can lead to incorrect
> detection or missed violations. Moving the check earlier ensures rseq
> sees the authentic state of the task.
>
> [Alignment]
> This change aligns arm64 with:
> - Generic entry, which calls rseq_syscall() first.
> - arm32 implementation, which also performs the check before audit.
>
> [Impact]
> There is no functional change to signal delivery; SIGSEGV will still be
> processed in arm64_exit_to_user_mode() at the end of the exit path.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 05/11] arm64/ptrace: Use syscall_get_arguments() helper for audit
From: Ada Couprie Diaz @ 2026-06-24 13:44 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-6-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Extract syscall_enter_audit() helper and use syscall_get_arguments()
> to get syscall arguments, matching the generic entry implementation.
>
> The new code:
> - Checks audit_context() first to avoid unnecessary memcpy when audit
> is not active.
> - Uses syscall_get_arguments() helper instead of directly accessing
> regs fields.
> - Is now exactly equivalent to generic entry's syscall_enter_audit().
>
> No functional changes.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v15 04/11] arm64/ptrace: Expand secure_computing() in place
From: Ada Couprie Diaz @ 2026-06-24 13:43 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-5-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() by open-coding the seccomp check
> to align with the generic entry framework.
>
> [Background]
> The generic entry implementation expands the seccomp check in-place
> instead of using the secure_computing() wrapper. It directly tests
> SYSCALL_WORK_SECCOMP and calls the underlying __secure_computing()
> function to handle syscall filtering.
>
> [Changes]
> 1. Open-code seccomp check:
> - Instead of calling the secure_computing() wrapper, explicitly check
> the 'flags' parameter for _TIF_SECCOMP.
> - Call __secure_computing() directly if the flag is set.
>
> [Why this matters]
> - Aligns the arm64 syscall path with the generic entry implementation,
> simplifying future migration to the generic entry framework.
> - No functional changes are intended; seccomp behavior remains identical.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH] clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
From: Sebastian Reichel @ 2026-06-24 13:42 UTC (permalink / raw)
To: Daniele Briguglio
Cc: Michael Turquette, Stephen Boyd, Heiko Stuebner, linux-clk,
linux-arm-kernel, linux-rockchip, linux-kernel, Diederik de Haas,
Nicolas Frattaroli, Ricardo Pardini
In-Reply-To: <20260624123914.1767374-1-hello@superkali.me>
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
Hi,
On Wed, Jun 24, 2026 at 02:39:14PM +0200, Daniele Briguglio wrote:
> No in-tree board references these gates yet. Boards drive the codec
> MCLK through the parent I2S*_8CH_MCLKOUT, and now that the gates are
> managed clocks, clk_disable_unused() turns them off at boot. On a board
> that relied on firmware leaving the output enabled, that cuts the MCLK
> and analog audio stops working.
>
> Mark the four gates CLK_IGNORE_UNUSED so an unreferenced gate keeps the
> state firmware left. A board that wants the kernel to own the gate can
> reference I2S*_8CH_MCLKOUT_TO_IO from DT instead.
>
> Fixes: 02b9b0bb6269 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
> Reported-by: Diederik de Haas <diederik@cknow-tech.com>
> Closes: https://lore.kernel.org/linux-rockchip/DJGDSS875DDO.22TYPVYK5X8KZ@cknow-tech.com/
> Tested-by: Diederik de Haas <diederik@cknow-tech.com>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Greetings,
-- Sebastian
> drivers/clk/rockchip/clk-rk3588.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c
> index 2ba9976654c..86953f9ffee 100644
> --- a/drivers/clk/rockchip/clk-rk3588.c
> +++ b/drivers/clk/rockchip/clk-rk3588.c
> @@ -895,7 +895,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S2_2CH_MCLKOUT, "i2s2_2ch_mclkout", i2s2_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(30), 2, 1, MFLAGS),
> GATE_GRF(I2S2_2CH_MCLKOUT_TO_IO, "i2s2_2ch_mclkout_to_io", "i2s2_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
>
> COMPOSITE(CLK_I2S3_2CH_SRC, "clk_i2s3_2ch_src", gpll_aupll_p, 0,
> RK3588_CLKSEL_CON(30), 8, 1, MFLAGS, 3, 5, DFLAGS,
> @@ -912,7 +912,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S3_2CH_MCLKOUT, "i2s3_2ch_mclkout", i2s3_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(32), 2, 1, MFLAGS),
> GATE_GRF(I2S3_2CH_MCLKOUT_TO_IO, "i2s3_2ch_mclkout_to_io", "i2s3_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> GATE(PCLK_ACDCDIG, "pclk_acdcdig", "pclk_audio_root", 0,
> RK3588_CLKGATE_CON(7), 11, GFLAGS),
> GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_audio_root", 0,
> @@ -942,7 +942,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S0_8CH_MCLKOUT, "i2s0_8ch_mclkout", i2s0_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(28), 2, 2, MFLAGS),
> GATE_GRF(I2S0_8CH_MCLKOUT_TO_IO, "i2s0_8ch_mclkout_to_io", "i2s0_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
>
> GATE(HCLK_PDM1, "hclk_pdm1", "hclk_audio_root", 0,
> RK3588_CLKGATE_CON(9), 6, GFLAGS),
> @@ -2229,7 +2229,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S1_8CH_MCLKOUT, "i2s1_8ch_mclkout", i2s1_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_PMU_CLKSEL_CON(9), 2, 2, MFLAGS),
> GATE_GRF(I2S1_8CH_MCLKOUT_TO_IO, "i2s1_8ch_mclkout_to_io", "i2s1_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> GATE(PCLK_PMU1, "pclk_pmu1", "pclk_pmu0_root", CLK_IS_CRITICAL,
> RK3588_PMU_CLKGATE_CON(1), 0, GFLAGS),
> GATE(CLK_DDR_FAIL_SAFE, "clk_ddr_fail_safe", "clk_pmu0", CLK_IGNORE_UNUSED,
>
> base-commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8
> --
> 2.47.3
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v15 03/11] arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
From: Ada Couprie Diaz @ 2026-06-24 13:42 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-4-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Use syscall_get_nr() to get syscall number for syscall_trace_enter().
> This aligns arm64's internal tracing logic with the generic
> entry framework.
>
> [Changes]
> 1. Use syscall_get_nr() helper:
> - Replace direct regs->syscallno access with
> syscall_get_nr(current, regs).
> - This helper is functionally equivalent to direct access on arm64.
>
> 2. Re-read syscall number after tracepoint:
> - Re-fetch the syscall number after trace_sys_enter() as it may have
> been modified by BPF or ftrace probes, matching generic entry behavior.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
This is missing what it makes the future migration . Easier, possible ?
(Same in patch 02, but I missed it !)
> - Properly handles syscall number modifications by tracers.
> - Uses standard architecture-independent helpers.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Otherwise,
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 02/11] arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags parameter
From: Ada Couprie Diaz @ 2026-06-24 13:38 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-3-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() and syscall_trace_exit() to move thread
> flag reading to the caller. This aligns arm64's syscall trace enter/exit
> function signature with generic entry framework.
>
> [Changes]
> 1. Function signature changes:
> - syscall_trace_enter(regs) → syscall_trace_enter(regs, flags)
> - syscall_trace_exit(regs) → syscall_trace_exit(regs, flags)
>
> 2. Move flags reading to caller:
> - Previously: read_thread_flags() called inside each function.
> - Now: caller (like el0_svc_common) passes flags as parameter.
>
> 3. Update syscall.c:
> - el0_svc_common() now passes flags to tracing functions and
> re-fetches flags before entry/exit to handle potential TIF
> updates.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
I was a bit confused with some parts, but those changes were made to align
exactly on the generic entry code, so makes sense !
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 01/11] entry: Fix potential syscall truncation in syscall_trace_enter()
From: Ada Couprie Diaz @ 2026-06-24 13:34 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-2-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> In syscall_trace_enter(), the current logic returns "ret ? : syscall".
> While __secure_computing() currently only returns 0 (allow) or -1 (kill),
> this "ret ? : syscall" pattern is conceptually flawed.
>
> If __secure_computing() were to return a non-zero value that isn't -1, it
> would unintentionally override the actual system call number. This logic
> is redundant because if seccomp denies the syscall, the execution path
> should already be handled by the caller based on the error return, rather
> than conflating the return code with the syscall number.
>
> Fix it by explicitly returning the syscall number. This ensures
> the syscall register remains untainted by the trace return values and
> aligns with the expectation that seccomp-related interceptions are
> handled via the -1 return status.
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-24 13:28 UTC (permalink / raw)
To: Esteban Urrutia, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <b3541802-3035-40ee-8327-a65bd5d2dfee@proton.me>
On 6/24/26 3:26 PM, Esteban Urrutia wrote:
>
>
> On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>>> This is mentioned in the memory map description, but is not part
>>> of it.
>>>
>>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>>> probably valid
>>
>> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
>> trapping it.
> Then, should device trees delete these memory regions on a case-by-case
> basis, or be left as is?
I'd delete it and reintroduce as necessary
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Konrad Dybcio @ 2026-06-24 13:27 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
Why does it probe defer?
And is this required for all TNOC devices?
Konrad
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Esteban Urrutia @ 2026-06-24 13:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <6123a923-21dd-4f69-9ac5-02165963027c@oss.qualcomm.com>
On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>> This is mentioned in the memory map description, but is not part
>> of it.
>>
>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>> probably valid
>
> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
> trapping it.
Then, should device trees delete these memory regions on a case-by-case
basis, or be left as is?
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-original-vigorous-mayfly-dfceac@quoll>
Hi Krzysztof,
> What does that mean? How UART can be accessible over PCI bus?
It's a Virtual UART. Internally, it's two FIFOs accessible via
8250-compatible register sets on both ends.
There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
are bridged over the PCI bus.
So, from the host, you can access the 8250 register set on the PCI bus.
> > + aspeed,vuart-over-pci:
> > + type: boolean
> > + default: false
>
> There is no such syntax. Please do not introduce own style. Instead,
> look at other files how this is done.
Ack. I will remove 'default: false' for the v4.
> > + description: |
>
> Do not need '|' unless you need to preserve formatting.
Acknowledged
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas: div6: Use ZT/ZTR trace clock in R-Mobile APE6 example
From: Rob Herring @ 2026-06-24 13:10 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Brian Masney, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260523192622.56605-1-marek.vasut+renesas@mailbox.org>
On Sat, May 23, 2026 at 09:25:50PM +0200, Marek Vasut wrote:
> Since commit 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks:
> Document ZT/ZTR trace clock on R-Mobile APE6"), the APE6 clock node
> expects two additional "clock-output-names" entries, "zt" and "ztr".
> Update the example accordingly.
>
> Fixes: 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6")
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Applied for rc1.
Rob
^ 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