* [PATCH v2] remoteproc: xlnx: check remote core state
From: Tanmay Shah @ 2026-04-28 21:33 UTC (permalink / raw)
To: michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
Changes in v2:
- fix subject line: %s/node/core/
- add comment explaining optional resource table availability in the
fw
drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++
drivers/remoteproc/xlnx_r5_remoteproc.c | 46 +++++++++++++++++++------
include/linux/firmware/xlnx-zynqmp.h | 21 +++++++++++
3 files changed, 85 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fbe8510f4927..af838b2dc327 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1450,6 +1450,34 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
}
EXPORT_SYMBOL_GPL(zynqmp_pm_get_node_status);
+/**
+ * zynqmp_pm_get_rpu_node_status - PM call to request a RPU node's current power state
+ * @node: ID of the RPU component or sub-system in question
+ * @status: Current operating state of the requested RPU node.
+ * @requirements: Current requirements asserted on the RPU node.
+ * @usage: Usage information, used for RPU slave nodes only:
+ * PM_USAGE_NO_MASTER - No master is currently using
+ * the node
+ * PM_USAGE_CURRENT_MASTER - Only requesting master is
+ * currently using the node
+ * PM_USAGE_OTHER_MASTER - Only other masters are
+ * currently using the node
+ * PM_USAGE_BOTH_MASTERS - Both the current and at least
+ * one other master is currently
+ * using the node
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage)
+{
+ if (zynqmp_pm_feature(PM_GET_NODE_STATUS) < PM_API_VERSION_2)
+ return -EOPNOTSUPP;
+
+ return zynqmp_pm_get_node_status(node, status, requirements, usage);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_node_status);
+
/**
* zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
* be powered down forcefully
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 50a9974f3202..45a62cb98072 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -948,16 +948,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
goto free_rproc;
}
- /*
- * If firmware is already available in the memory then move rproc state
- * to DETACHED. Firmware can be preloaded via debugger or by any other
- * agent (processors) in the system.
- * If firmware isn't available in the memory and resource table isn't
- * found, then rproc state remains OFFLINE.
- */
- if (!zynqmp_r5_get_rsc_table_va(r5_core))
- r5_rproc->state = RPROC_DETACHED;
-
r5_core->rproc = r5_rproc;
return r5_core;
@@ -1210,6 +1200,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
{
struct device *dev = cluster->dev;
struct zynqmp_r5_core *r5_core;
+ u32 req, usage, status;
int ret = -EINVAL, i;
r5_core = cluster->r5_cores[0];
@@ -1255,6 +1246,41 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
ret = zynqmp_r5_get_sram_banks(r5_core);
if (ret)
return ret;
+
+ /*
+ * It is possible that firmware is loaded into the memory, but
+ * RPU (remote) is not running. In such case, RPU state will be
+ * moved to RPROC_DETACHED wrongfully. To avoid it first make
+ * sure RPU is power-on and out of reset before parsing for the
+ * resource table.
+ */
+ ret = zynqmp_pm_get_rpu_node_status(r5_core->pm_domain_id,
+ &status, &req, &usage);
+ if (ret) {
+ dev_warn(r5_core->dev,
+ "failed to get rpu node status, err %d\n", ret);
+ continue;
+ }
+
+ /*
+ * If RPU state is power on and out of reset i.e. running, then
+ * assign RPROC_DETACHED state. If the RPU is not out of reset
+ * then do not attempt to attach to the remote processor.
+ */
+ if (status == PM_NODE_RUNNING) {
+ /*
+ * Not all the firmware that is running on the remote
+ * core is expected to have the resource table. The
+ * firmware might not use RPMsg at all, and in that case
+ * resource table becomes irrelevant. However, we still
+ * need to make sure that running core is not reported
+ * as offline. so do not decide remote core state based
+ * on the resource table availability
+ */
+ if (zynqmp_r5_get_rsc_table_va(r5_core))
+ dev_dbg(r5_core->dev, "rsc tbl not found\n");
+ r5_core->rproc->state = RPROC_DETACHED;
+ }
}
return 0;
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index d70dcd462b44..7e27b0f7bf7e 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -542,6 +542,18 @@ enum pm_gem_config_type {
GEM_CONFIG_FIXED = 2,
};
+/**
+ * enum pm_node_status - Device node status provided by xilpm fw
+ * @PM_NODE_UNUSED: Device is not used
+ * @PM_NODE_RUNNING: Device is power-on and out of reset
+ * @PM_NODE_HALT: Device is power-on but in the reset state
+ */
+enum pm_node_status {
+ PM_NODE_UNUSED = 0,
+ PM_NODE_RUNNING = 1,
+ PM_NODE_HALT = 12,
+};
+
/**
* struct zynqmp_pm_query_data - PM query data
* @qid: query ID
@@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode);
int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
u32 *const requirements, u32 *const usage);
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage);
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
@@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
return -ENODEV;
}
+static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements,
+ u32 *const usage)
+{
+ return -ENODEV;
+}
+
static inline int zynqmp_pm_set_sd_config(u32 node,
enum pm_sd_config_type config,
u32 value)
base-commit: fcdf2df56d34a3f04cab0725c5bc3abdaa73c2be
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack
From: Alexis Lothoré @ 2026-04-28 21:37 UTC (permalink / raw)
To: Ihor Solodrai, Alexis Lothoré (eBPF Foundation),
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf,
linux-kernel, netdev, linux-kselftest, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <7dd64547-25a4-46de-a896-98fcec04468e@linux.dev>
On Sat Apr 25, 2026 at 1:18 AM CEST, Ihor Solodrai wrote:
> On 4/13/26 11:28 AM, Alexis Lothoré (eBPF Foundation) wrote:
>> In order to prepare to emit KASAN checks in JITed programs, JIT
>> compilers need to be aware about whether some load/store instructions
>> are targeting the bpf program stack, as those should not be monitored
>> (we already have guard pages for that, and it is difficult anyway to
>> correctly monitor any kind of data passed on stack).
>>
>> To support this need, make the BPF verifier mark the instructions that
>> access program stack:
>> - add a setter that allows the verifier to mark instructions accessing
>> the program stack
>> - add a getter that allows JIT compilers to check whether instructions
>> being JITed are accessing the stack
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> include/linux/bpf.h | 2 ++
>> include/linux/bpf_verifier.h | 2 ++
>> kernel/bpf/core.c | 10 ++++++++++
>> kernel/bpf/verifier.c | 7 +++++++
>> 4 files changed, 21 insertions(+)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index b4b703c90ca9..774a0395c498 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -1543,6 +1543,8 @@ void bpf_jit_uncharge_modmem(u32 size);
>> bool bpf_prog_has_trampoline(const struct bpf_prog *prog);
>> bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struct bpf_prog *prog,
>> int insn_idx);
>> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
>> + const struct bpf_prog *prog, int insn_idx);
>> #else
>> static inline int bpf_trampoline_link_prog(struct bpf_tramp_link *link,
>> struct bpf_trampoline *tr,
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index b148f816f25b..ab99ed4c4227 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -660,6 +660,8 @@ struct bpf_insn_aux_data {
>> u16 const_reg_map_mask;
>> u16 const_reg_subprog_mask;
>> u32 const_reg_vals[10];
>> + /* instruction accesses stack */
>> + bool accesses_stack;
>> };
>>
>> #define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 8b018ff48875..340abfdadbed 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -1582,6 +1582,16 @@ bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struc
>> insn_idx += prog->aux->subprog_start;
>> return env->insn_aux_data[insn_idx].indirect_target;
>> }
>> +
>> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
>> + const struct bpf_prog *prog, int insn_idx)
>> +{
>> + if (!env)
>> + return false;
>> + insn_idx += prog->aux->subprog_start;
>> + return env->insn_aux_data[insn_idx].accesses_stack;
>> +}
>> +
>> #endif /* CONFIG_BPF_JIT */
>>
>> /* Base function for offset calculation. Needs to go into .text section,
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 1e36b9e91277..7bce4fb4e540 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -3502,6 +3502,11 @@ static void mark_indirect_target(struct bpf_verifier_env *env, int idx)
>> env->insn_aux_data[idx].indirect_target = true;
>> }
>>
>> +static void mark_insn_accesses_stack(struct bpf_verifier_env *env, int idx)
>> +{
>> + env->insn_aux_data[idx].accesses_stack = true;
>> +}
>> +
>> #define LR_FRAMENO_BITS 3
>> #define LR_SPI_BITS 6
>> #define LR_ENTRY_BITS (LR_SPI_BITS + LR_FRAMENO_BITS + 1)
>> @@ -6490,6 +6495,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
>> else
>> err = check_stack_write(env, regno, off, size,
>> value_regno, insn_idx);
>> +
>> + mark_insn_accesses_stack(env, insn_idx);
>
> I am not sure this can be done unconditionally here.
>
> It may be possible in different states to have different pointer
> types for the affected reg (PTR_TO_STACK in one execution path and say
> PTR_TO_MAP_VALUE in another). And if set uncoditionally,
> instrumentation may be skipped for legitimate targets.
>
> Maybe reset by default in check_mem_access()?
Hmm, ok, thanks, I missed this subtlety. I still need to dig in there to
make sure to really understand how the verifier handles those states,
but if I understand correctly your point, I guess that just resetting
the "accesses stack" flag at the entry of check_mem_access is not
enough: it would make the final result depend on the order of the states
being checked, eg:
- first state being checked result in PTR_TO_MAP_VALUE, no flag set
- second (and final) state being checked result in PTR_TO_STACK, flag is
now set
- if no other state: insn ends up being (wrongly) marked to be ignored
So unless I am misunderstanding things here, the question rather becomes
"for this specific insn, is there any state in which the accessed memory
is anything else other than PTR_TO_STACK". The flag could just be
inverted (ie set to true by default), and reset by any state resulting
in something other than PTR_TO_STACK.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs
From: Julius Werner @ 2026-04-28 21:43 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-1-briannorris@chromium.org>
> I reviewed Depthcharge code history and found that this problematic
> bootloader behavior dates back to at least 2014, with the Tegra/Nyan
> device. Older devices may have similar DTB structures, but I'm not sure
> if they have the same address-cells problems. In any case, these changes
> shouldn't hurt even if a device was not affected.
I can confirm that Nyan was the first Arm device shipping with
depthcharge. Note that the Exynos devices are all older and shipped
with an old fork of U-Boot that probably handled this very differently
(I believe they had `/firmware/chromeos` but not `/firmware/coreboot`,
so they wouldn't have had a `reg` node and should need no `ranges`).
^ permalink raw reply
* [PATCH] ARM: Kconfig: Disable ARM_VIRT extension if XIP_KERNEL
From: Rob Herring (Arm) @ 2026-04-28 21:58 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Vishnu Banavath, linux-arm-kernel, linux-kernel
From: Vishnu Banavath <vishnu.banavath@arm.com>
XIP is intended to execute kernel inplace and typically from
flash and is used mostly on low memory devices.
.macro store_primary_cpu_mode reg1, reg2, reg3
mrs \reg1, cpsr
and \reg1, \reg1, #MODE_MASK
adr \reg2, .L__boot_cpu_mode_offset
ldr \reg3, [\reg2]
str \reg1, [\reg2, \reg3]
As text section is in flash memory and data section is in RAM.
L__boot_cpu_mode_offset would evaluate to address based
on virtual addresses provided by linker script. At this stage
the MMU is OFF.
The logic used based stored @L__boot_cpu_mode_offset on the offset
between the boot_cpu_mode in data section and the location of
L__boot_cpu_mode_offset can't be used along with PC to fetch the value
of boot_cpu_mode doesn't work.
Signed-off-by: Vishnu Banavath <vishnu.banavath@arm.com>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
This patch is from Alif E8 SoC tree which I'm working on. It's
originally from corstone700 trees.
arch/arm/mm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 7b27ee9482b3..e2f5d3d7d3fb 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -705,6 +705,7 @@ config ARM_THUMBEE
config ARM_VIRT_EXT
bool
+ depends on MMU && !XIP_KERNEL
default y if CPU_V7
help
Enable the kernel to make use of the ARM Virtualization
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs
From: Brian Norris @ 2026-04-28 22:15 UTC (permalink / raw)
To: Julius Werner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <CAODwPW-YuhQxyGSeahp8+i-bz_hAvPQQCNWxaZCjrbvkHOQa7A@mail.gmail.com>
On Tue, Apr 28, 2026 at 02:43:21PM -0700, Julius Werner wrote:
> > I reviewed Depthcharge code history and found that this problematic
> > bootloader behavior dates back to at least 2014, with the Tegra/Nyan
> > device. Older devices may have similar DTB structures, but I'm not sure
> > if they have the same address-cells problems. In any case, these changes
> > shouldn't hurt even if a device was not affected.
>
> I can confirm that Nyan was the first Arm device shipping with
> depthcharge. Note that the Exynos devices are all older and shipped
> with an old fork of U-Boot that probably handled this very differently
> (I believe they had `/firmware/chromeos` but not `/firmware/coreboot`,
> so they wouldn't have had a `reg` node and should need no `ranges`).
OK, so that makes patch 4 unnecessary:
[PATCH 4/7] ARM: dts: samsung: Add #{address,size}-cells to Chromium-based /firmware
If I respin this, I can drop it. Or if it otherwise looks good,
presumably folks can just skip patch 4.
Thanks,
Brian
^ permalink raw reply
* [PATCH v3] remoteproc: xlnx: check remote core state
From: Tanmay Shah @ 2026-04-28 22:18 UTC (permalink / raw)
To: michal.simek, andersson, mathieu.poirier, tanmay.shah
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
Changes in v3:
- add fixes tag
Changes in v2:
- fix subject line: %s/node/core/
- add comment explaining optional resource table availability in the
drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++
drivers/remoteproc/xlnx_r5_remoteproc.c | 46 +++++++++++++++++++------
include/linux/firmware/xlnx-zynqmp.h | 21 +++++++++++
3 files changed, 85 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index fbe8510f4927..af838b2dc327 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1450,6 +1450,34 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
}
EXPORT_SYMBOL_GPL(zynqmp_pm_get_node_status);
+/**
+ * zynqmp_pm_get_rpu_node_status - PM call to request a RPU node's current power state
+ * @node: ID of the RPU component or sub-system in question
+ * @status: Current operating state of the requested RPU node.
+ * @requirements: Current requirements asserted on the RPU node.
+ * @usage: Usage information, used for RPU slave nodes only:
+ * PM_USAGE_NO_MASTER - No master is currently using
+ * the node
+ * PM_USAGE_CURRENT_MASTER - Only requesting master is
+ * currently using the node
+ * PM_USAGE_OTHER_MASTER - Only other masters are
+ * currently using the node
+ * PM_USAGE_BOTH_MASTERS - Both the current and at least
+ * one other master is currently
+ * using the node
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage)
+{
+ if (zynqmp_pm_feature(PM_GET_NODE_STATUS) < PM_API_VERSION_2)
+ return -EOPNOTSUPP;
+
+ return zynqmp_pm_get_node_status(node, status, requirements, usage);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_node_status);
+
/**
* zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
* be powered down forcefully
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 50a9974f3202..45a62cb98072 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -948,16 +948,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
goto free_rproc;
}
- /*
- * If firmware is already available in the memory then move rproc state
- * to DETACHED. Firmware can be preloaded via debugger or by any other
- * agent (processors) in the system.
- * If firmware isn't available in the memory and resource table isn't
- * found, then rproc state remains OFFLINE.
- */
- if (!zynqmp_r5_get_rsc_table_va(r5_core))
- r5_rproc->state = RPROC_DETACHED;
-
r5_core->rproc = r5_rproc;
return r5_core;
@@ -1210,6 +1200,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
{
struct device *dev = cluster->dev;
struct zynqmp_r5_core *r5_core;
+ u32 req, usage, status;
int ret = -EINVAL, i;
r5_core = cluster->r5_cores[0];
@@ -1255,6 +1246,41 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
ret = zynqmp_r5_get_sram_banks(r5_core);
if (ret)
return ret;
+
+ /*
+ * It is possible that firmware is loaded into the memory, but
+ * RPU (remote) is not running. In such case, RPU state will be
+ * moved to RPROC_DETACHED wrongfully. To avoid it first make
+ * sure RPU is power-on and out of reset before parsing for the
+ * resource table.
+ */
+ ret = zynqmp_pm_get_rpu_node_status(r5_core->pm_domain_id,
+ &status, &req, &usage);
+ if (ret) {
+ dev_warn(r5_core->dev,
+ "failed to get rpu node status, err %d\n", ret);
+ continue;
+ }
+
+ /*
+ * If RPU state is power on and out of reset i.e. running, then
+ * assign RPROC_DETACHED state. If the RPU is not out of reset
+ * then do not attempt to attach to the remote processor.
+ */
+ if (status == PM_NODE_RUNNING) {
+ /*
+ * Not all the firmware that is running on the remote
+ * core is expected to have the resource table. The
+ * firmware might not use RPMsg at all, and in that case
+ * resource table becomes irrelevant. However, we still
+ * need to make sure that running core is not reported
+ * as offline. so do not decide remote core state based
+ * on the resource table availability
+ */
+ if (zynqmp_r5_get_rsc_table_va(r5_core))
+ dev_dbg(r5_core->dev, "rsc tbl not found\n");
+ r5_core->rproc->state = RPROC_DETACHED;
+ }
}
return 0;
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index d70dcd462b44..7e27b0f7bf7e 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -542,6 +542,18 @@ enum pm_gem_config_type {
GEM_CONFIG_FIXED = 2,
};
+/**
+ * enum pm_node_status - Device node status provided by xilpm fw
+ * @PM_NODE_UNUSED: Device is not used
+ * @PM_NODE_RUNNING: Device is power-on and out of reset
+ * @PM_NODE_HALT: Device is power-on but in the reset state
+ */
+enum pm_node_status {
+ PM_NODE_UNUSED = 0,
+ PM_NODE_RUNNING = 1,
+ PM_NODE_HALT = 12,
+};
+
/**
* struct zynqmp_pm_query_data - PM query data
* @qid: query ID
@@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode);
int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
u32 *const requirements, u32 *const usage);
+int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements, u32 *const usage);
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
@@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
return -ENODEV;
}
+static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
+ u32 *const requirements,
+ u32 *const usage)
+{
+ return -ENODEV;
+}
+
static inline int zynqmp_pm_set_sd_config(u32 node,
enum pm_sd_config_type config,
u32 value)
base-commit: fcdf2df56d34a3f04cab0725c5bc3abdaa73c2be
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 03/15] clk: scmi: Use new determine_rate clock operation
From: Cristian Marussi @ 2026-04-28 22:20 UTC (permalink / raw)
To: Brian Masney
Cc: Cristian Marussi, linux-kernel, linux-arm-kernel, arm-scmi,
linux-clk, linux-renesas-soc, sudeep.holla, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas, Michael Turquette, Stephen Boyd
In-Reply-To: <afEZotnIZYXEtMiC@redhat.com>
On Tue, Apr 28, 2026 at 04:33:38PM -0400, Brian Masney wrote:
> Hi Cristian,
>
> On Tue, Apr 28, 2026 at 09:15:10PM +0100, Cristian Marussi wrote:
> > Use the Clock protocol layer determine_rate logic to calculate the closest
> > rate that can be supported by a specific clock.
> >
> > No functional change.
> >
> > Cc: Brian Masney <bmasney@redhat.com>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: linux-clk@vger.kernel.org
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > @brian: I'd modify further this clk-scmi driver, with a patch on top of
> > this series, to properly use your new CLK_ROUNDING_NOOP flag once your
> > series AND another (already reviewed) series on clk-scmi from Peng are in.
Hi Brian,
>
> I don't know if Stephen is going to pick up my CLK_ROUNDING_NOOP series.
> We talked about it in person at LPC in Tokyo, and he was the one that
> suggested the flag rather than a new shared noop function. However he
> didn't pick it up last development cycle.
>
> I would recommend NOT basing on that series of mine to reduce
> dependencies, and so that your stuff doesn't get held up by series.
>
Ok, thanks for the heads up, I was indeed not able to find the _NOOP in
v7.1-rc1 and I was NOT sure...anyway a patch on top of this whenever
your series goes in should not be a problem....maybe if you can ping me
when it's merged, it would be easy NOT to miss/forget :P
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2] remoteproc: xlnx: check remote core state
From: Shah, Tanmay @ 2026-04-28 22:21 UTC (permalink / raw)
To: Tanmay Shah, michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260428213327.210574-1-tanmay.shah@amd.com>
Rejected-by: Tanmay Shah <tanmay.shah@amd.com>
Sent v3 with Fixes tag in the commit text.
Thanks.
On 4/28/2026 4:33 PM, Tanmay Shah wrote:
> The remote state is set to RPROC_DETACHED if the resource table is found
> in the memory. However, this can be wrong if the remote is not started,
> but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
> to the firmware to request the state of the RPU node. If the RPU is
> actually out of reset and running, only then move the remote state to
> RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
>
> Changes in v2:
> - fix subject line: %s/node/core/
> - add comment explaining optional resource table availability in the
> fw
>
> drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 46 +++++++++++++++++++------
> include/linux/firmware/xlnx-zynqmp.h | 21 +++++++++++
> 3 files changed, 85 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index fbe8510f4927..af838b2dc327 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1450,6 +1450,34 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_get_node_status);
>
> +/**
> + * zynqmp_pm_get_rpu_node_status - PM call to request a RPU node's current power state
> + * @node: ID of the RPU component or sub-system in question
> + * @status: Current operating state of the requested RPU node.
> + * @requirements: Current requirements asserted on the RPU node.
> + * @usage: Usage information, used for RPU slave nodes only:
> + * PM_USAGE_NO_MASTER - No master is currently using
> + * the node
> + * PM_USAGE_CURRENT_MASTER - Only requesting master is
> + * currently using the node
> + * PM_USAGE_OTHER_MASTER - Only other masters are
> + * currently using the node
> + * PM_USAGE_BOTH_MASTERS - Both the current and at least
> + * one other master is currently
> + * using the node
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements, u32 *const usage)
> +{
> + if (zynqmp_pm_feature(PM_GET_NODE_STATUS) < PM_API_VERSION_2)
> + return -EOPNOTSUPP;
> +
> + return zynqmp_pm_get_node_status(node, status, requirements, usage);
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_node_status);
> +
> /**
> * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
> * be powered down forcefully
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 50a9974f3202..45a62cb98072 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -948,16 +948,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> goto free_rproc;
> }
>
> - /*
> - * If firmware is already available in the memory then move rproc state
> - * to DETACHED. Firmware can be preloaded via debugger or by any other
> - * agent (processors) in the system.
> - * If firmware isn't available in the memory and resource table isn't
> - * found, then rproc state remains OFFLINE.
> - */
> - if (!zynqmp_r5_get_rsc_table_va(r5_core))
> - r5_rproc->state = RPROC_DETACHED;
> -
> r5_core->rproc = r5_rproc;
> return r5_core;
>
> @@ -1210,6 +1200,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> {
> struct device *dev = cluster->dev;
> struct zynqmp_r5_core *r5_core;
> + u32 req, usage, status;
> int ret = -EINVAL, i;
>
> r5_core = cluster->r5_cores[0];
> @@ -1255,6 +1246,41 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> ret = zynqmp_r5_get_sram_banks(r5_core);
> if (ret)
> return ret;
> +
> + /*
> + * It is possible that firmware is loaded into the memory, but
> + * RPU (remote) is not running. In such case, RPU state will be
> + * moved to RPROC_DETACHED wrongfully. To avoid it first make
> + * sure RPU is power-on and out of reset before parsing for the
> + * resource table.
> + */
> + ret = zynqmp_pm_get_rpu_node_status(r5_core->pm_domain_id,
> + &status, &req, &usage);
> + if (ret) {
> + dev_warn(r5_core->dev,
> + "failed to get rpu node status, err %d\n", ret);
> + continue;
> + }
> +
> + /*
> + * If RPU state is power on and out of reset i.e. running, then
> + * assign RPROC_DETACHED state. If the RPU is not out of reset
> + * then do not attempt to attach to the remote processor.
> + */
> + if (status == PM_NODE_RUNNING) {
> + /*
> + * Not all the firmware that is running on the remote
> + * core is expected to have the resource table. The
> + * firmware might not use RPMsg at all, and in that case
> + * resource table becomes irrelevant. However, we still
> + * need to make sure that running core is not reported
> + * as offline. so do not decide remote core state based
> + * on the resource table availability
> + */
> + if (zynqmp_r5_get_rsc_table_va(r5_core))
> + dev_dbg(r5_core->dev, "rsc tbl not found\n");
> + r5_core->rproc->state = RPROC_DETACHED;
> + }
> }
>
> return 0;
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index d70dcd462b44..7e27b0f7bf7e 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -542,6 +542,18 @@ enum pm_gem_config_type {
> GEM_CONFIG_FIXED = 2,
> };
>
> +/**
> + * enum pm_node_status - Device node status provided by xilpm fw
> + * @PM_NODE_UNUSED: Device is not used
> + * @PM_NODE_RUNNING: Device is power-on and out of reset
> + * @PM_NODE_HALT: Device is power-on but in the reset state
> + */
> +enum pm_node_status {
> + PM_NODE_UNUSED = 0,
> + PM_NODE_RUNNING = 1,
> + PM_NODE_HALT = 12,
> +};
> +
> /**
> * struct zynqmp_pm_query_data - PM query data
> * @qid: query ID
> @@ -630,6 +642,8 @@ int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode);
> int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode);
> int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements, u32 *const usage);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -939,6 +953,13 @@ static inline int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> + u32 *const requirements,
> + u32 *const usage)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: fcdf2df56d34a3f04cab0725c5bc3abdaa73c2be
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: Make important drivers default
From: Linus Walleij @ 2026-04-28 22:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Russell King, Bjorn Andersson, Konrad Dybcio, linux-arm-kernel,
linux-kernel, linux-arm-msm, linux-gpio
In-Reply-To: <e5e60e25-9edb-4b1f-811a-ce719ea89ed6@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 6:28 PM Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
> On 28/04/2026 14:06, Krzysztof Kozlowski wrote:
> > On 27/04/2026 22:18, Linus Walleij wrote:
> >>>
> >>> 3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
> >>> platforms, which are already enabled on qcom_defconfig.
> >>>
> >>> 4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
> >>> builds, whenever ARCH_QCOM is selected. This has impact on build
> >>> time and feels logical, because if one selects ARCH_QCOM then
> >>> probably by default wants to build test it entirely. Kernels with
> >>> COMPILE_TEST are not supposed to be used for booting.
> >>>
> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >>
> >> Way better like this.
> >> Reviewed-by: Linus Walleij <linusw@kernel.org>
> >
> > I think this should rather go through your tree, because new drivers are
> > coming and some other changes from me might be touching similar lines.
> > Well, defconfig also might be changed in parallel, so obviously someone
> > will need to handle conflicts.
>
> I'll rebase on recent patches you applied.
OK then, let's try that! Maybe I should just split out all the early Qualcomm
stuff we merged into an immutable branch if something starts to cobble
up later?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] arm64: dts: mediatek: add crypto offload support on MT7981
From: Aleksander Jan Bajkowski @ 2026-04-28 22:47 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Aleksander Jan Bajkowski
The MT7981 as well as the MT7986 have a built-in EIP-97 rev 2.3p0 crypto
accelerator. This commit adds the missing entry in the dts.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
index 1bbe219380f9..e63ba3ae395e 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
@@ -150,6 +150,21 @@ sgmiisys1: syscon@10070000 {
#clock-cells = <1>;
};
+ crypto@10320000 {
+ compatible = "mediatek,mt7981-crypto",
+ "inside-secure,safexcel-eip97ies";
+ reg = <0 0x10320000 0 0x40000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ring0", "ring1", "ring2", "ring3";
+ clocks = <&topckgen CLK_TOP_EIP97B>;
+ clock-names = "core";
+ assigned-clocks = <&topckgen CLK_TOP_EIP97B_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_CB_NET1_D5>;
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt7981-uart", "mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x100>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] kselftest/arm64: Fix build failure with GCC-15
From: Mark Brown @ 2026-04-28 23:26 UTC (permalink / raw)
To: Leo Yan
Cc: Catalin Marinas, Will Deacon, Shuah Khan, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <20260428101513.GE16537@e132581.arm.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Tue, Apr 28, 2026 at 11:15:13AM +0100, Leo Yan wrote:
> > It's not glibc specific so it seems reasonable to keep it in gcs-util.h,
> > even though we don't currently have any nolibc stuff that uses ptrace.
> > That said this isn't particularly strongly held opinion so I don't
> > *really* mind either way.
> Does below change make sense to you?
That looks fine to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v10 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne @ 2026-04-29 0:29 UTC (permalink / raw)
To: Lee Jones
Cc: André Draszik, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Sebastian Reichel,
Heikki Krogerus, Peter Griffin, Tudor Ambarus, Alim Akhtar,
linux-kernel, devicetree, linux-usb, linux-pm, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso
In-Reply-To: <20260424082639.GI170138@google.com>
Hi Lee,
Thanks for your review.
On 4/24/26 1:26 AM, Lee Jones wrote:
> On Tue, 31 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
>
>> From: Amit Sunil Dhamne <amitsd@google.com>
>>
>> Add register bitmasks for charger function.
>> In addition split the charger IRQs further such that each bit represents
>> an IRQ downstream of charger regmap irq chip. In addition populate the
>> ack_base to offload irq ack to the regmap irq chip framework.
> Please reword this commit messages.
>
> Using 'In addition' twice in such close proximity reads a little awkwardly.
Thanks for pointing it out. Unfortunately, this commit is already part
of the linux and linux-next so I am not sure if I could fix the commit
message retrospectively.
>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> Reviewed-by: André Draszik <andre.draszik@linaro.org>
>> ---
>> drivers/mfd/max77759.c | 95 ++++++++++++++++++++++---
>> include/linux/mfd/max77759.h | 166 +++++++++++++++++++++++++++++++++++--------
>> 2 files changed, 222 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/mfd/max77759.c b/drivers/mfd/max77759.c
>> index a7efe233ec8c..9fa6027a92c4 100644
>> --- a/drivers/mfd/max77759.c
>> +++ b/drivers/mfd/max77759.c
>> @@ -201,8 +201,24 @@ static const struct regmap_config max77759_regmap_config_charger = {
>> * - SYSUVLO_INT
>> * - FSHIP_NOT_RD
>> * - CHGR_INT: charger
>> - * - CHG_INT
>> - * - CHG_INT2
>> + * - INT1
>> + * - AICL
>> + * - CHGIN
>> + * - WCIN
>> + * - CHG
>> + * - BAT
>> + * - INLIM
>> + * - THM2
>> + * - BYP
>> + * - INT2
>> + * - INSEL
>> + * - SYS_UVLO1
>> + * - SYS_UVLO2
>> + * - BAT_OILO
>> + * - CHG_STA_CC
>> + * - CHG_STA_CV
>> + * - CHG_STA_TO
>> + * - CHG_STA_DONE
>> */
>> enum {
>> MAX77759_INT_MAXQ,
>> @@ -228,8 +244,22 @@ enum {
>> };
>>
>> enum {
>> - MAX77759_CHARGER_INT_1,
>> - MAX77759_CHARGER_INT_2,
>> + MAX77759_CHGR_INT1_AICL,
>> + MAX77759_CHGR_INT1_CHGIN,
>> + MAX77759_CHGR_INT1_WCIN,
>> + MAX77759_CHGR_INT1_CHG,
>> + MAX77759_CHGR_INT1_BAT,
>> + MAX77759_CHGR_INT1_INLIM,
>> + MAX77759_CHGR_INT1_THM2,
>> + MAX77759_CHGR_INT1_BYP,
>> + MAX77759_CHGR_INT2_INSEL,
>> + MAX77759_CHGR_INT2_SYS_UVLO1,
>> + MAX77759_CHGR_INT2_SYS_UVLO2,
>> + MAX77759_CHGR_INT2_BAT_OILO,
>> + MAX77759_CHGR_INT2_CHG_STA_CC,
>> + MAX77759_CHGR_INT2_CHG_STA_CV,
>> + MAX77759_CHGR_INT2_CHG_STA_TO,
>> + MAX77759_CHGR_INT2_CHG_STA_DONE,
>> };
>>
>> static const struct regmap_irq max77759_pmic_irqs[] = {
>> @@ -256,8 +286,38 @@ static const struct regmap_irq max77759_topsys_irqs[] = {
>> };
>>
>> static const struct regmap_irq max77759_chgr_irqs[] = {
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_1, 0, GENMASK(7, 0)),
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_2, 1, GENMASK(7, 0)),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_AICL, 0,
>> + MAX77759_CHGR_REG_CHG_INT_AICL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHGIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHGIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_WCIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_WCIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHG, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHG),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BAT, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BAT),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_INLIM, 0,
>> + MAX77759_CHGR_REG_CHG_INT_INLIM),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_THM2, 0,
>> + MAX77759_CHGR_REG_CHG_INT_THM2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BYP, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BYP),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_INSEL, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_INSEL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO1, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO2, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_BAT_OILO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_BAT_OILO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CC, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CV, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_TO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_DONE, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE),
> Can I suggest using the 100-char limit to expand and neaten these up a bit.
Sounds good I will send a new "fixes" patch to address this.
>
>> };
>>
>> static const struct regmap_irq_chip max77759_pmic_irq_chip = {
>> @@ -297,11 +357,12 @@ static const struct regmap_irq_chip max77759_topsys_irq_chip = {
>> .num_irqs = ARRAY_SIZE(max77759_topsys_irqs),
>> };
>>
>> -static const struct regmap_irq_chip max77759_chrg_irq_chip = {
>> +static const struct regmap_irq_chip max77759_chgr_irq_chip = {
> This is a sneaky change. If you're going to bundle fixes like this, at
> least drop a mention in the commit message.
This wasn't part of the original commit but was pointed out during the
code review. While I captured this in the changlogs maybe I should have
added it in the commit msg.
Unfortunately, this has the same issue as before, i.e., modifying commit
message after it has been applied.
>
>> .name = "max77759-chgr",
>> .domain_suffix = "CHGR",
>> .status_base = MAX77759_CHGR_REG_CHG_INT,
>> .mask_base = MAX77759_CHGR_REG_CHG_INT_MASK,
>> + .ack_base = MAX77759_CHGR_REG_CHG_INT,
>> .num_regs = 2,
>> .irqs = max77759_chgr_irqs,
>> .num_irqs = ARRAY_SIZE(max77759_chgr_irqs),
>> @@ -325,8 +386,22 @@ static const struct resource max77759_gpio_resources[] = {
>> };
>>
>> static const struct resource max77759_charger_resources[] = {
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_1, "INT1"),
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_2, "INT2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_AICL, "AICL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHGIN, "CHGIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_WCIN, "WCIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHG, "CHG"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BAT, "BAT"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_INLIM, "INLIM"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_THM2, "THM2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BYP, "BYP"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_INSEL, "INSEL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO1, "SYS_UVLO1"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO2, "SYS_UVLO2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_BAT_OILO, "BAT_OILO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CC, "CHG_STA_CC"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CV, "CHG_STA_CV"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_TO, "CHG_STA_TO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_DONE, "CHG_STA_DONE"),
>> };
>>
>> static const struct mfd_cell max77759_cells[] = {
>> @@ -567,7 +642,7 @@ static int max77759_add_chained_charger(struct i2c_client *client,
>> max77759->regmap_charger,
>> MAX77759_INT_CHGR,
>> parent,
>> - &max77759_chrg_irq_chip,
>> + &max77759_chgr_irq_chip,
>> &irq_chip_data);
>> if (ret)
>> return ret;
>> diff --git a/include/linux/mfd/max77759.h b/include/linux/mfd/max77759.h
>> index c6face34e385..ec19be952877 100644
>> --- a/include/linux/mfd/max77759.h
>> +++ b/include/linux/mfd/max77759.h
>> @@ -59,35 +59,65 @@
>> #define MAX77759_MAXQ_REG_AP_DATAIN0 0xb1
>> #define MAX77759_MAXQ_REG_UIC_SWRST 0xe0
>>
>> -#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> -#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> -#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> -#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> -#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> -#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> -#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> -#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> -#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> -#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> -#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> -#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> -#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> -#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> -#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> -#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> -#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> -#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> -#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>> +#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> +#define MAX77759_CHGR_REG_CHG_INT_AICL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHGIN BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT_WCIN BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHG BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT_BAT BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT_INLIM BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT_THM2 BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT_BYP BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> +#define MAX77759_CHGR_REG_CHG_INT2_INSEL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1 BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2 BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT2_BAT_OILO BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> +#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> +#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00_CHGIN_DTLS GENMASK(6, 5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_BAT_DTLS GENMASK(6, 4)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00_MODE GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT GENMASK(3, 2)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> +#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM GENMASK(6, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> +#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> +/* Wireless Charging input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_WCINSEL BIT(6)
>> +/* CHGIN/USB input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_CHGINSEL BIT(5)
> Should we ensure these comments are formatted as complete sentences with a full
> stop at the end, to comply with our documentation guidelines?
Sounds good I will add this fix in the new fixes patch.
>
>> +#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> +#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> +#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18_WDTEN BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>>
>> /* MaxQ opcodes for max77759_maxq_command() */
>> #define MAX77759_MAXQ_OPCODE_MAXLENGTH (MAX77759_MAXQ_REG_AP_DATAOUT32 - \
>> @@ -101,6 +131,84 @@
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_READ 0x81
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_WRITE 0x82
>>
>> +/**
>> + * enum max77759_chgr_chgin_dtls_status - Charger Input Status
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
>> + * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE:
>> + * Vchgin > Vuvlo and Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
>> + * Vchgin > Over Voltage threshold (Vovlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
>> + * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
>> + */
>> +enum max77759_chgr_chgin_dtls_status {
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
>> +};
>> +
>> +/**
>> + * enum max77759_chgr_bat_dtls_states - Battery Details
>> + * @MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP: No battery and the charger suspended
>> + * @MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY: Vbatt < Vtrickle
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT: Charging suspended due to timer fault
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OKAY: Battery okay and Vbatt > Min Sys Voltage (Vsysmin)
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE: Battery is okay. Vtrickle < Vbatt < Vsysmin
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE: Battery voltage > Overvoltage threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT: Battery current exceeds overcurrent threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE: Battery only mode and battery level not available
>> + */
>> +enum max77759_chgr_bat_dtls_states {
>> + MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP,
>> + MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OKAY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE,
>> +};
>> +
>> +/**
>> + * enum max77759_chgr_chg_dtls_states - Charger Details
>> + * @MAX77759_CHGR_CHG_DTLS_PREQUAL: Charger in prequalification mode
>> + * @MAX77759_CHGR_CHG_DTLS_CC: Charger in fast charge const curr mode
>> + * @MAX77759_CHGR_CHG_DTLS_CV: Charger in fast charge const voltage mode
>> + * @MAX77759_CHGR_CHG_DTLS_TO: Charger is in top off mode
>> + * @MAX77759_CHGR_CHG_DTLS_DONE: Charger is done
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_1: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_TIMER_FAULT: Charger is in timer fault mode
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM: Charger is suspended as battery removal detected
>> + * @MAX77759_CHGR_CHG_DTLS_OFF: Charger is off. Input invalid or charger disabled
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_2: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_3: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER: Charger is off as watchdog timer expired
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_JEITA: Charger is in JEITA control mode
>> + */
>> +enum max77759_chgr_chg_dtls_states {
>> + MAX77759_CHGR_CHG_DTLS_PREQUAL,
>> + MAX77759_CHGR_CHG_DTLS_CC,
>> + MAX77759_CHGR_CHG_DTLS_CV,
>> + MAX77759_CHGR_CHG_DTLS_TO,
>> + MAX77759_CHGR_CHG_DTLS_DONE,
>> + MAX77759_CHGR_CHG_DTLS_RSVD_1,
>> + MAX77759_CHGR_CHG_DTLS_TIMER_FAULT,
>> + MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM,
>> + MAX77759_CHGR_CHG_DTLS_OFF,
>> + MAX77759_CHGR_CHG_DTLS_RSVD_2,
>> + MAX77759_CHGR_CHG_DTLS_RSVD_3,
>> + MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER,
>> + MAX77759_CHGR_CHG_DTLS_SUSP_JEITA,
>> +};
>> +
>> +enum max77759_chgr_mode {
>> + MAX77759_CHGR_MODE_OFF,
>> + MAX77759_CHGR_MODE_CHG_BUCK_ON = 0x5,
>> + MAX77759_CHGR_MODE_OTG_BOOST_ON = 0xA,
>> +};
> Would it be safer to explicitly initialise 'MAX77759_CHGR_MODE_OFF' to 0 here?
> Relying on implicit zero initialisation whilst explicitly setting other values
> can sometimes lead to unexpected behaviour if new entries are added.
Sounds good. Will fix.
Best Regards,
Amit
>
^ permalink raw reply
* Re: [PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
From: Jakub Kicinski @ 2026-04-29 1:06 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms
In-Reply-To: <20260427072508.1151-1-lizhi2@eswincomputing.com>
On Mon, 27 Apr 2026 15:25:05 +0800 lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> The second Ethernet controller (eth1) on the Eswin EIC7700 SoC may fail
> to sample RX data correctly at Gigabit speed due to EIC7700-specific
> receive clock to data skew at the MAC input in the silicon.
>
> The existing internal delay configuration does not provide sufficient
> adjustment range to compensate for this condition at 1000Mbps.
> Update the EIC7700 DWMAC glue driver to apply EIC7700-specific clock
> sampling inversion only during Gigabit operation on MAC instances
> that require it.
>
> TXD and RXD delay registers are explicitly cleared during initialization
> to override any residual configuration left by the bootloader. All HSP
> CSR register accesses are performed only after the required clocks are
> enabled.
>
> Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Why Fixes? If eth1 never worked this is not a fix but new functionality
If you want to make this a fix to prevent incompatibility - cut it down
just to the eth0 changes.
> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> ---
> .../ethernet/stmicro/stmmac/dwmac-eic7700.c | 183 ++++++++++++++----
> 1 file changed, 140 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> index bcb8e000e720..33144611da8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> @@ -28,20 +28,40 @@
>
> /*
> * TX/RX Clock Delay Bit Masks:
> - * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.1ns per bit)
> - * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.1ns per bit)
> + * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.02ns per bit)
> + * - TX Invert : bit [15]
> + * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.02ns per bit)
> + * - RX Invert : bit [31]
> */
> #define EIC7700_ETH_TX_ADJ_DELAY GENMASK(14, 8)
> #define EIC7700_ETH_RX_ADJ_DELAY GENMASK(30, 24)
> +#define EIC7700_ETH_TX_INV_DELAY BIT(15)
> +#define EIC7700_ETH_RX_INV_DELAY BIT(31)
>
> -#define EIC7700_MAX_DELAY_UNIT 0x7F
> +#define EIC7700_MAX_DELAY_STEPS 0x7F
> +#define EIC7700_DELAY_STEP_PS 20
> +#define EIC7700_MAX_DELAY_PS \
> + (EIC7700_MAX_DELAY_STEPS * EIC7700_DELAY_STEP_PS)
AI says:
The step unit is being silently changed from 0.1 ns (delay_ps / 100)
to 0.02 ns (delay_ps / 20). The same DT value now programs 5x the number
of delay steps into the hardware.
> static const char * const eic7700_clk_names[] = {
> "tx", "axi", "cfg",
> };
>
> +struct eic7700_dwmac_data {
> + bool rgmii_rx_clk_invert;
> +};
> +
> struct eic7700_qos_priv {
> + struct device *dev;
> struct plat_stmmacenet_data *plat_dat;
> + struct regmap *eic7700_hsp_regmap;
> + u32 eth_axi_lp_ctrl_offset;
> + u32 eth_phy_ctrl_offset;
> + u32 eth_txd_offset;
> + u32 eth_clk_offset;
> + u32 eth_rxd_offset;
> + u32 eth_clk_dly_param;
> + bool eth_rx_clk_inv;
> };
>
> static int eic7700_clks_config(void *priv, bool enabled)
> @@ -61,8 +81,28 @@ static int eic7700_clks_config(void *priv, bool enabled)
> static int eic7700_dwmac_init(struct device *dev, void *priv)
> {
> struct eic7700_qos_priv *dwc = priv;
> + int ret;
> +
> + ret = eic7700_clks_config(dwc, true);
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(dwc->eic7700_hsp_regmap,
> + dwc->eth_phy_ctrl_offset,
> + EIC7700_ETH_TX_CLK_SEL |
> + EIC7700_ETH_PHY_INTF_SELI);
> + if (ret) {
> + eic7700_clks_config(dwc, false);
> + return ret;
> + }
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset,
> + EIC7700_ETH_CSYSREQ_VAL);
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_txd_offset, 0);
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_rxd_offset, 0);
>
> - return eic7700_clks_config(dwc, true);
> + return 0;
> }
>
> static void eic7700_dwmac_exit(struct device *dev, void *priv)
> @@ -88,18 +128,35 @@ static int eic7700_dwmac_resume(struct device *dev, void *priv)
> return ret;
> }
>
> +static void eic7700_dwmac_fix_speed(void *priv, phy_interface_t interface,
> + int speed, unsigned int mode)
> +{
> + struct eic7700_qos_priv *dwc = (struct eic7700_qos_priv *)priv;
> + u32 dly_param = dwc->eth_clk_dly_param;
> +
> + switch (speed) {
> + case SPEED_1000:
> + if (dwc->eth_rx_clk_inv)
> + dly_param |= EIC7700_ETH_RX_INV_DELAY;
> + break;
> + case SPEED_100:
> + case SPEED_10:
> + break;
> + default:
> + dev_err(dwc->dev, "invalid speed %u\n", speed);
> + break;
> + }
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_clk_offset, dly_param);
AI says
In the default case this logs "invalid speed %u" but then falls
through and still executes the regmap_write() with the base dly_param. An
unsupported speed reports an error and reprograms the hardware anyway.
Should the default path return without writing, or should the write be
moved into the valid cases only?
> +}
> +
> static int eic7700_dwmac_probe(struct platform_device *pdev)
> {
> + const struct eic7700_dwmac_data *data;
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> struct eic7700_qos_priv *dwc_priv;
> - struct regmap *eic7700_hsp_regmap;
> - u32 eth_axi_lp_ctrl_offset;
> - u32 eth_phy_ctrl_offset;
> - u32 eth_phy_ctrl_regset;
> - u32 eth_rxd_dly_offset;
> - u32 eth_dly_param = 0;
> - u32 delay_ps;
> + u32 delay_ps, val;
> int i, ret;
>
> ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> @@ -116,70 +173,95 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> if (!dwc_priv)
> return -ENOMEM;
>
> + dwc_priv->dev = &pdev->dev;
> +
> + data = device_get_match_data(&pdev->dev);
> + if (!data)
> + return dev_err_probe(&pdev->dev,
> + -EINVAL, "no match data found\n");
> +
> + dwc_priv->eth_rx_clk_inv = data->rgmii_rx_clk_invert;
> +
> /* Read rx-internal-delay-ps and update rx_clk delay */
> if (!of_property_read_u32(pdev->dev.of_node,
> "rx-internal-delay-ps", &delay_ps)) {
> - u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
> + if (delay_ps % EIC7700_DELAY_STEP_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "rx delay must be multiple of %dps\n",
> + EIC7700_DELAY_STEP_PS);
> +
> + if (delay_ps > EIC7700_MAX_DELAY_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "rx delay out of range\n");
>
> - eth_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> - eth_dly_param |= FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property rx-internal-delay-ps\n");
> + val = delay_ps / EIC7700_DELAY_STEP_PS;
> +
> + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> + dwc_priv->eth_clk_dly_param |=
> + FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> }
>
> /* Read tx-internal-delay-ps and update tx_clk delay */
> if (!of_property_read_u32(pdev->dev.of_node,
> "tx-internal-delay-ps", &delay_ps)) {
> - u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
> + if (delay_ps % EIC7700_DELAY_STEP_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "tx delay must be multiple of %dps\n",
> + EIC7700_DELAY_STEP_PS);
> +
> + if (delay_ps > EIC7700_MAX_DELAY_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "tx delay out of range\n");
> +
> + val = delay_ps / EIC7700_DELAY_STEP_PS;
>
> - eth_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> - eth_dly_param |= FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property tx-internal-delay-ps\n");
> + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> + dwc_priv->eth_clk_dly_param |=
> + FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> }
AI says:
First, rx-internal-delay-ps and tx-internal-delay-ps are silently
demoted from required to optional. The previous driver returned
-EINVAL with "missing required property ..." when either was absent;
the else branches have been removed, so missing properties now leave
eth_clk_dly_param at zero and fix_mac_speed() programs zero delay
without diagnostic. Is this intentional, and if so should the commit
message and the DT binding reflect it?
Second, the previous code silently clamped out-of-range values via
min() and only required non-zero step units by integer truncation.
The new code rejects non-multiples of 20 and values greater than 2540
ps with -EINVAL at probe time. DTBs that previously probed with
clamped delays will now fail probe. Should this stricter validation
also be called out in the commit message?
> - eic7700_hsp_regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> - "eswin,hsp-sp-csr");
> - if (IS_ERR(eic7700_hsp_regmap))
> + dwc_priv->eic7700_hsp_regmap =
> + syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "eswin,hsp-sp-csr");
> + if (IS_ERR(dwc_priv->eic7700_hsp_regmap))
> return dev_err_probe(&pdev->dev,
> - PTR_ERR(eic7700_hsp_regmap),
> + PTR_ERR(dwc_priv->eic7700_hsp_regmap),
> "Failed to get hsp-sp-csr regmap\n");
>
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 1, ð_phy_ctrl_offset);
> + 1, &dwc_priv->eth_phy_ctrl_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> "can't get eth_phy_ctrl_offset\n");
>
> - regmap_read(eic7700_hsp_regmap, eth_phy_ctrl_offset,
> - ð_phy_ctrl_regset);
> - eth_phy_ctrl_regset |=
> - (EIC7700_ETH_TX_CLK_SEL | EIC7700_ETH_PHY_INTF_SELI);
> - regmap_write(eic7700_hsp_regmap, eth_phy_ctrl_offset,
> - eth_phy_ctrl_regset);
> -
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 2, ð_axi_lp_ctrl_offset);
> + 2, &dwc_priv->eth_axi_lp_ctrl_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> "can't get eth_axi_lp_ctrl_offset\n");
>
> - regmap_write(eic7700_hsp_regmap, eth_axi_lp_ctrl_offset,
> - EIC7700_ETH_CSYSREQ_VAL);
> + ret = of_property_read_u32_index(pdev->dev.of_node,
> + "eswin,hsp-sp-csr",
> + 3, &dwc_priv->eth_clk_offset);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "can't get eth_clk_offset\n");
>
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 3, ð_rxd_dly_offset);
> + 4, &dwc_priv->eth_txd_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> - "can't get eth_rxd_dly_offset\n");
> + "can't get eth_txd_offset\n");
>
> - regmap_write(eic7700_hsp_regmap, eth_rxd_dly_offset,
> - eth_dly_param);
> + ret = of_property_read_u32_index(pdev->dev.of_node,
> + "eswin,hsp-sp-csr",
> + 5, &dwc_priv->eth_rxd_offset);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "can't get eth_rxd_offset\n");
AI says:
The eswin,hsp-sp-csr phandle-args layout is expanded from 4 cells
(phandle + 3 offsets) to 6 cells (phandle + 5 offsets), with new
indices 3/4/5 now required. Any DTB produced against the original
ea77dbbdbc4e binding will fail probe here with -EINVAL.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v7 1/4] dt-bindings: ethernet: eswin: add clock sampling control
From: Andrew Lunn @ 2026-04-29 1:28 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, Conor Dooley
In-Reply-To: <20260427072439.1134-1-lizhi2@eswincomputing.com>
> For the TX path of eth1, there is also a skew between the TX clock
> and data on the MAC controller inside the silicon. This skew happens
> to be approximately 2 ns. Therefore, it can be considered that the
> 2 ns delay of TX is provided by the MAC, so the TX is compliant with
> the RGMII standard.
> tx-internal-delay-ps:
> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> + minimum: 0
> + maximum: 2540
> + multipleOf: 20
This does not seem correct for eth1. Isn't minimum 2000, maximum 4540?
You have this fixed 2ns you cannot turn off.
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: freescale: add i.MX95 19x19 FRDM PRO board dts
From: Fabio Estevam @ 2026-04-29 1:37 UTC (permalink / raw)
To: Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, devicetree,
linux-kernel, imx, linux-arm-kernel, xinyu.chen, qijian.guo,
justin.jiang
In-Reply-To: <20260428-imx95_frdm_pro-v2-2-434240b652f4@nxp.com>
On Tue, Apr 28, 2026 at 5:03 AM Joseph Guo <qijian.guo@nxp.com> wrote:
>
> NXP i.MX95 19x19 FRDM PRO is cost-effective with extensive
> expansion capabilities based on the i.MX95 19x19 SoC.
It would be good to explain the difference between the i.MX95 FRDM PRO
and i.MX95 FRDM.
Also, does it make sense to share common nodes in a dtsi that can be
used by the two variants?
^ permalink raw reply
* Re: [PATCH net-next v7 4/4] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: Andrew Lunn @ 2026-04-29 1:41 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms
In-Reply-To: <20260427072603.1191-1-lizhi2@eswincomputing.com>
> +&gmac1 {
> + phy-handle = <&gmac1_phy0>;
> + /*
> + * For the TX path of gmac1, there is a skew between the TX clock
> + * and data on the MAC controller inside the silicon. This skew happens
> + * to be approximately 2 ns. Therefore, it can be considered that the
> + * 2 ns delay of TX is provided by the MAC.
> + * No delay configuration for tx is needed in software via PHY driver.
> + */
> + phy-mode = "rgmii-rxid";
This is wrong. Take a read of
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
phy-mode describes the board. If the board provides the 2ns delay, you
use rgmii. If the MAC/PHY pair needs to provide the delay, you using
rgmii-id.
If rgmii-id is used, it is up to the MAC/PHY to decide which will add
the delay. If the MAC adds the delay, it needs to mask the value of
phy-mode it passes to the PHY so it does not also add the delay.
Your broken hardware means you cannot support 'rgmii' or 'rgmii-rx',
since you cannot turn off this 2ns delay, so you end up with double
delays if anybody designs a board with 2ns TX delay on the board
itself. So please validate the PHY modes and return -EINVAL if these
modes are used.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on i.MX95
From: Peng Fan @ 2026-04-29 2:13 UTC (permalink / raw)
To: Richard Zhu
Cc: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer,
festevam, linux-clk, imx, linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <20260417082910.489995-1-hongxing.zhu@nxp.com>
On Fri, Apr 17, 2026 at 04:29:10PM +0800, Richard Zhu wrote:
>When the internal PLL is used as the PCIe reference clock source on i.MX95,
>a REFCLK rise-fall time mismatch is observed during PCIe Gen1 compliance
>testing with the Lfast IO analyzer.
>
>Fix this issue by configuring the IREF_TX field to 0xF (15), which adjusts
>the transmitter current reference to meet the PCIe specification timing
>requirements.
>
>Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH v3 0/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Chancel Liu @ 2026-04-29 2:12 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, Frank.Li, s.hauer, kernel, shumingf,
rander.wang, pierre-louis.bossart, linux-sound, linux-kernel,
linuxppc-dev, imx, linux-arm-kernel
Some audio systems require specific DAPM widgets to remain powered
during system suspend. Introduce a generic and reusable mechanism in
the ASoC core to mark selected DAPM widgets as ignore_suspend.
The unified mechanism consists of two parts:
1. Parse and store the name list of widgets to ignore suspend in
struct snd_soc_card
The list of widgets can be provided either by the machine driver or
parsed from Device Tree. Different machines have different routing and
power requirements. Each machine can specify its own widgets to ignore
suspend through DT property. It enables flexible policy without hard
code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
for this purpose.
2. Apply ignore_suspend flags during snd_soc_bind_card()
After all components have been probed and all DAPM widgets have been
registered, snd_soc_bind_card() performs a unified lookup of the
configured widget names across all DAPM contexts of the card and marks
the matching widgets with ignore_suspend = 1.
Switch to use core ignore-suspend-widgets support for imx-rpmsg driver.
Changes in v3:
- Reword first patch subject to use snd_soc_dapm_widget_name_cmp()
- Use goto fail for error handling in imx_rpmsg_probe() to ensure proper
cleanup of of_node references
The v2 series is a rework of the previous "[PATCH] ASoC: imx-rpmsg:
Fix ignore-suspend-widgets only applied to codec DAPM".
Changes in v2:
- Rework to use a unified core mechanism instead of machine driver
specific code
Chancel Liu (3):
ASoC: dapm: Fix widget lookup with snd_soc_dapm_widget_name_cmp()
ASoC: soc-core: Add core support for ignoring suspend on selected DAPM
widgets
ASoC: fsl: imx-rpmsg: Switch to core ignore-suspend-widgets support
include/sound/soc-dapm.h | 1 +
include/sound/soc.h | 5 +++++
sound/soc/fsl/imx-rpmsg.c | 26 ++++++++---------------
sound/soc/soc-core.c | 43 +++++++++++++++++++++++++++++++++++++++
sound/soc/soc-dapm.c | 43 ++++++++++++++++++++++++++++-----------
5 files changed, 89 insertions(+), 29 deletions(-)
--
2.50.1
^ permalink raw reply
* [PATCH v3 1/3] ASoC: dapm: Fix widget lookup with snd_soc_dapm_widget_name_cmp()
From: Chancel Liu @ 2026-04-29 2:12 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, Frank.Li, s.hauer, kernel, shumingf,
rander.wang, pierre-louis.bossart, linux-sound, linux-kernel,
linuxppc-dev, imx, linux-arm-kernel
In-Reply-To: <20260429021252.691263-1-chancel.liu@nxp.com>
Currently dapm_find_widget() manually constructs a prefixed widget name
based on the provided DAPM context and compares it using strcmp(). This
happens to work in most cases because callers usually know which DAPM
context the target widget belongs to and pass in the matching DAPM
context.
However, this assumption breaks when search_other_contexts is enabled.
In such cases, callers may intentionally pass a different DAPM context,
while searching for a widget that actually belongs to another DAPM
context.
For example, when searching for a "DAC" widget, the widget belongs to
the codec DAPM and be registered with a codec prefix, while the caller
passes card->dapm and intends to search across all DAPM contexts. The
current implementation incorrectly applies the caller card DAPM causing
the lookup to fail even though the widget exists on the card.
Use snd_soc_dapm_widget_name_cmp() instead, which compares widget names
using the widget's own DAPM context and prefix. It fixes widget lookup
failures when searching across different DAPM contexts on the card.
Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking widget names")
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Assisted-by: Cody:Claude-3.5-Sonnet
---
sound/soc/soc-dapm.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index d6192204e613..c5b80d9ed64b 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2906,20 +2906,9 @@ static struct snd_soc_dapm_widget *dapm_find_widget(
{
struct snd_soc_dapm_widget *w;
struct snd_soc_dapm_widget *fallback = NULL;
- char prefixed_pin[80];
- const char *pin_name;
- const char *prefix = dapm_prefix(dapm);
-
- if (prefix) {
- snprintf(prefixed_pin, sizeof(prefixed_pin), "%s %s",
- prefix, pin);
- pin_name = prefixed_pin;
- } else {
- pin_name = pin;
- }
for_each_card_widgets(dapm->card, w) {
- if (!strcmp(w->name, pin_name)) {
+ if (!snd_soc_dapm_widget_name_cmp(w, pin)) {
if (w->dapm == dapm)
return w;
else
--
2.50.1
^ permalink raw reply related
* [PATCH v3 2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Chancel Liu @ 2026-04-29 2:12 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, Frank.Li, s.hauer, kernel, shumingf,
rander.wang, pierre-louis.bossart, linux-sound, linux-kernel,
linuxppc-dev, imx, linux-arm-kernel
In-Reply-To: <20260429021252.691263-1-chancel.liu@nxp.com>
Some audio systems require specific DAPM widgets to remain powered
during system suspend. Introduce a generic and reusable mechanism in
the ASoC core to mark selected DAPM widgets as ignore_suspend.
The unified mechanism consists of two parts:
1. Parse and store the name list of widgets to ignore suspend in
struct snd_soc_card
The list of widgets can be provided either by the machine driver or
parsed from Device Tree. Different machines have different routing and
power requirements. Each machine can specify its own widgets to ignore
suspend through DT property. It enables flexible policy without hard
code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
for this purpose.
2. Apply ignore_suspend flags during snd_soc_bind_card()
After all components have been probed and all DAPM widgets have been
registered, snd_soc_bind_card() performs a unified lookup of the
configured widget names across all DAPM contexts of the card and marks
the matching widgets with ignore_suspend = 1.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
include/sound/soc-dapm.h | 1 +
include/sound/soc.h | 5 +++++
sound/soc/soc-core.c | 43 ++++++++++++++++++++++++++++++++++++++++
sound/soc/soc-dapm.c | 30 ++++++++++++++++++++++++++++
4 files changed, 79 insertions(+)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index 4f8fb7622a13..39c290e0eb7f 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -636,6 +636,7 @@ int snd_soc_dapm_new_dai_widgets(struct snd_soc_dapm_context *dapm, struct snd_s
void snd_soc_dapm_free_widget(struct snd_soc_dapm_widget *w);
int snd_soc_dapm_link_dai_widgets(struct snd_soc_card *card);
void snd_soc_dapm_connect_dai_link_widgets(struct snd_soc_card *card);
+int snd_soc_dapm_ignore_suspend_widgets(struct snd_soc_card *card);
int snd_soc_dapm_update_dai(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params, struct snd_soc_dai *dai);
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 5e3eb617d832..7d6fa79f48e3 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1057,10 +1057,14 @@ struct snd_soc_card {
int num_dapm_widgets;
const struct snd_soc_dapm_route *dapm_routes;
int num_dapm_routes;
+ const char **ignore_suspend_widgets;
+ int num_ignore_suspend_widgets;
const struct snd_soc_dapm_widget *of_dapm_widgets;
int num_of_dapm_widgets;
const struct snd_soc_dapm_route *of_dapm_routes;
int num_of_dapm_routes;
+ const char **of_ignore_suspend_widgets;
+ int num_of_ignore_suspend_widgets;
/* lists of probed devices belonging to this card */
struct list_head component_dev_list;
@@ -1339,6 +1343,7 @@ void snd_soc_of_parse_node_prefix(struct device_node *np,
int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
const char *propname);
int snd_soc_of_parse_aux_devs(struct snd_soc_card *card, const char *propname);
+int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card, const char *propname);
unsigned int snd_soc_daifmt_clock_provider_flipped(unsigned int dai_fmt);
unsigned int snd_soc_daifmt_clock_provider_from_bitmap(unsigned int bit_frame);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 3fecf9fc903c..705181dae472 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2289,6 +2289,10 @@ static int snd_soc_bind_card(struct snd_soc_card *card)
if (ret < 0)
goto probe_end;
+ ret = snd_soc_dapm_ignore_suspend_widgets(card);
+ if (ret < 0)
+ goto probe_end;
+
snd_soc_dapm_new_widgets(card);
snd_soc_card_fixup_controls(card);
@@ -3294,6 +3298,45 @@ int snd_soc_of_parse_aux_devs(struct snd_soc_card *card, const char *propname)
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_aux_devs);
+int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card,
+ const char *propname)
+{
+ struct device_node *np = card->dev->of_node;
+ int num_widgets;
+ const char **widgets;
+ int i;
+
+ num_widgets = of_property_count_strings(np, propname);
+ if (num_widgets < 0) {
+ dev_err(card->dev,
+ "ASoC: Property '%s' does not exist\n", propname);
+ return -EINVAL;
+ }
+
+ widgets = devm_kcalloc(card->dev, num_widgets, sizeof(char *), GFP_KERNEL);
+ if (!widgets)
+ return -ENOMEM;
+
+ for (i = 0; i < num_widgets; i++) {
+ const char *name;
+ int ret = of_property_read_string_index(np, propname, i, &name);
+
+ if (ret) {
+ dev_err(card->dev,
+ "ASoC: Property '%s' could not be read: %d\n",
+ propname, ret);
+ return -EINVAL;
+ }
+ widgets[i] = name;
+ }
+
+ card->num_of_ignore_suspend_widgets = num_widgets;
+ card->of_ignore_suspend_widgets = widgets;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_ignore_suspend_widgets);
+
unsigned int snd_soc_daifmt_clock_provider_flipped(unsigned int dai_fmt)
{
unsigned int inv_dai_fmt = dai_fmt & ~SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK;
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c5b80d9ed64b..209f86b9add6 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -4595,6 +4595,36 @@ void snd_soc_dapm_connect_dai_link_widgets(struct snd_soc_card *card)
}
}
+int snd_soc_dapm_ignore_suspend_widgets(struct snd_soc_card *card)
+{
+ struct snd_soc_dapm_widget *w;
+ int i;
+
+ for (i = 0; i < card->num_ignore_suspend_widgets; i++) {
+ w = dapm_find_widget(snd_soc_card_to_dapm(card),
+ card->ignore_suspend_widgets[i], true);
+ if (!w) {
+ dev_err(card->dev, "ASoC: DAPM unknown ignore suspend widget %s\n",
+ card->ignore_suspend_widgets[i]);
+ return -EINVAL;
+ }
+ w->ignore_suspend = 1;
+ }
+
+ for (i = 0; i < card->num_of_ignore_suspend_widgets; i++) {
+ w = dapm_find_widget(snd_soc_card_to_dapm(card),
+ card->of_ignore_suspend_widgets[i], true);
+ if (!w) {
+ dev_err(card->dev, "ASoC: DAPM unknown ignore suspend widget %s\n",
+ card->of_ignore_suspend_widgets[i]);
+ return -EINVAL;
+ }
+ w->ignore_suspend = 1;
+ }
+
+ return 0;
+}
+
static void dapm_stream_event(struct snd_soc_pcm_runtime *rtd, int stream, int event)
{
struct snd_soc_dai *dai;
--
2.50.1
^ permalink raw reply related
* [PATCH v3 3/3] ASoC: fsl: imx-rpmsg: Switch to core ignore-suspend-widgets support
From: Chancel Liu @ 2026-04-29 2:12 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, Frank.Li, s.hauer, kernel, shumingf,
rander.wang, pierre-louis.bossart, linux-sound, linux-kernel,
linuxppc-dev, imx, linux-arm-kernel
In-Reply-To: <20260429021252.691263-1-chancel.liu@nxp.com>
The imx-rpmsg machine driver currently implements its own logic to
parse ignore-suspend-widgets from Device Tree and manually traverse
DAPM widgets to mark them as ignore_suspend.
It also has a potential issue that some widgets listed in the property
(e.g. "Headphone Jack") belong to card or CPU DAI DAPM context.
Switch to use snd_soc_of_parse_ignore_suspend_widgets() with the
introduction of a generic ignore-suspend-widgets mechanism in the ASoC
core.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
sound/soc/fsl/imx-rpmsg.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
index 40e0043cfe15..fd4624786b62 100644
--- a/sound/soc/fsl/imx-rpmsg.c
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -87,7 +87,6 @@ static int imx_rpmsg_late_probe(struct snd_soc_card *card)
int ret;
if (data->lpa) {
- struct snd_soc_component *codec_comp;
struct device_node *codec_np;
struct device_driver *codec_drv;
struct device *codec_dev = NULL;
@@ -107,22 +106,6 @@ static int imx_rpmsg_late_probe(struct snd_soc_card *card)
}
}
if (codec_dev) {
- codec_comp = snd_soc_lookup_component_nolocked(codec_dev, NULL);
- if (codec_comp) {
- int i, num_widgets;
- const char *widgets;
- struct snd_soc_dapm_context *dapm;
-
- num_widgets = of_property_count_strings(data->card.dev->of_node,
- "ignore-suspend-widgets");
- for (i = 0; i < num_widgets; i++) {
- of_property_read_string_index(data->card.dev->of_node,
- "ignore-suspend-widgets",
- i, &widgets);
- dapm = snd_soc_component_to_dapm(codec_comp);
- snd_soc_dapm_ignore_suspend(dapm, widgets);
- }
- }
codec_drv = codec_dev->driver;
if (codec_drv->pm) {
memcpy(&lpa_pm, codec_drv->pm, sizeof(lpa_pm));
@@ -274,6 +257,15 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
}
}
+ if (data->lpa && of_property_present(np, "ignore-suspend-widgets")) {
+ ret = snd_soc_of_parse_ignore_suspend_widgets(&data->card,
+ "ignore-suspend-widgets");
+ if (ret) {
+ dev_err(&pdev->dev, "failed to parse ignore-suspend-widgets: %d\n", ret);
+ goto fail;
+ }
+ }
+
platform_set_drvdata(pdev, &data->card);
snd_soc_card_set_drvdata(&data->card, data);
ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
--
2.50.1
^ permalink raw reply related
* [PATCH v9 0/4] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-29 2:47 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Alexey Charkov, Quentin Schulz, FUKAUMI Naoki, Peter Robinson,
devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Dennis Gilmore
This series adds initial support for the Xunlong Orange Pi 5 Pro, based on
the Rockchip RK3588S SoC. The board features eMMC, SD card, NVMe (PCIe),
a Motorcomm YT6801 NIC (PCIe), WiFi/BT (BCM43456), HDMI connected to SoC
(Second port is disabled in this patch), and a 40-pin expansion header.
The series was tested against Linux 7.0
Please take a look.
Thank you,
Dennis Gilmore
Changes in v9:
- removed support for the dp-to-HDMI bridge, will send in a second patch
set to enable discusion to finish on how to handle its two operating
modes
- link to v8: https://lore.kernel.org/linux-devicetree/20260425031011.2529364-1-dennis@ausil.us/
Changes in v8:
- Bridge node: renamed label from lt8711uxd to hdmi-bridge
- Bridge node: added vdd-supply = <&vcc3v3_dp>. The vcc3v3_dp regulator
gates power to the LT8711UXD. regulator-always-on is kept because
drm_simple_bridge only enables vdd-supply with HPD which does not
happen without power on
- GPIO output pinctrl groups (bt_wake_gpio, dp_bridge_en, ethernet_en,
vcc5v0_otg_en, wifi_enable_h) changed from pcfg_pull_none to
pcfg_pull_down to match the RK3588S power-on-reset default state
- pcie2x1l1 (NVMe): switched from GPIO-mode reset to hardware sideband pins
using pinctrl-0 = <&pcie30x1m1_1_perstn>, <&pcie30x1m1_1_clkreqn>,
<&pcie30x1m1_1_waken>. Note: despite the "pcie30" prefix in the DTSI
group names, the SoC pin-mux table confirms these alt-function 4 pads
physically route to pcie2x1l1's native PERST#/CLKREQ#/WAKE# inputs.
reset-gpios is retained alongside the pinctrl entry for U-Boot
compatibility (pcie_dw_rockchip in U-Boot requires reset-gpios).
- pcie2x1l2 (NIC): added &pcie20x1m0_clkreqn and &pcie20x1m0_waken to
pinctrl-0
- Renamed pinctrl group vcc3v3_phy1_en to ethernet_en to match the
schematic signal name (Ethernet_EN)
- link to v7: https://lore.kernel.org/linux-devicetree/20260414214104.1363987-1-dennis@ausil.us/
Changes in v7:
- Fix up whitespace issues identified by checkpatch.pl --strict in
rk3588s-orangepi-5-5b.dtsi
- checkpatch gave a warning for WARNING: phy-mode "rgmii-rxid" without
comment, as this was moved over I left it untouched
- Added lontium,lt8711uxd to the compatible enum in the simple-bridge
binding
- Added lontium,lt8711uxd match entry with DRM_MODE_CONNECTOR_HDMIA to
the simple-bridge driver
- New patch to rename the regulator labels for the es8388 supplies to
match the schematics and they all use vcca_*
- Fixed ES8388 PVDD-supply — vcca_3v3_s0 → vcca_1v8_s0, 5 Pro is
different to 5 and 5b.
- analog-sound: use CPU-as-clock-master on the Pro. The ES8388 is wired to
i2s2_2ch (the only I2S block physically routed to the codec pins on this
board), which uses the legacy rockchip_i2s driver. That driver's
slave-mode trigger path hangs for 200 µs polling I2S_CLR and bails with
-ETIMEDOUT ("lrclk update failed"). The TDM-capable i2s0/i2s1/i2s5
blocks served by rockchip_i2s_tdm don't have this issue, which is why
other mainline ES8388 boards get away with bitclock-master = masterdai.
Drop bitclock-master/frame-master and the masterdai label to let the I2S
block generate BCLK/LRCK itself
- Removed regulator-always-on/regulator-boot-on from vcc3v3_dp
- Added pinctrl entries for all GPIO pins (dp_bridge_en, vcc3v3_phy1_en,
wifi_enable_h, pcie2x1l1_rst, pcie2x1l2_rst)
- DP bridge rework — replaced dp-connector node with proper chain:
- lt8711uxd bridge node (compatible lontium,lt8711uxd, with port@0/port@1
endpoints). Bridge power is gated by the vcc3v3_dp regulator, whose
enable GPIO (GPIO3_PC2) is driven via the dp_bridge_en pinctrl group;
no enable-gpios/vdd-supply on the bridge node itself.
- hdmi1-con connector node (compatible hdmi-connector, type a)
- dp0_out endpoint now points to bridge input instead of old connector
- remove accidentally included unnecessary changes
- link to v6: https://lore.kernel.org/linux-devicetree/20260411024743.195385-1-dennis@ausil.us/
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5: https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4: https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3: https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purpose
- actually clean up the delete lines and comments missed in v2
- link to v2: https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- link to v1: https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (4):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels
to match schematic
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 256 +++++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 358 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 263 +------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
7 files changed, 637 insertions(+), 250 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.54.0
^ permalink raw reply
* [PATCH v9 2/4] arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels to match schematic
From: Dennis Gilmore @ 2026-04-29 2:47 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Alexey Charkov, Quentin Schulz, FUKAUMI Naoki, Peter Robinson,
devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Dennis Gilmore
In-Reply-To: <20260429024737.544813-1-dennis@ausil.us>
The Orange Pi 5, 5B and 5 Pro schematics label the RK806 PLDO outputs
using the pattern VCC_*_S0 / VCCA_*_S0 / VDDA_*_S0. Rename the base
dtsi regulator labels (and the es8388 supply references) to match:
pldo-reg1: avcc_1v8_s0 -> vcc_1v8_s0
pldo-reg2: vcc_1v8_s0 -> vcca_1v8_s0
pldo-reg3: avdd_1v2_s0 -> vdda_1v2_s0
pldo-reg4: vcc_3v3_s0 -> vcca_3v3_s0
Also update the saradc vref-supply reference to track the pldo-reg1
rename. No functional change.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..fd5c6a025cd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -274,10 +274,10 @@ es8388: audio-codec@10 {
compatible = "everest,es8388", "everest,es8328";
reg = <0x10>;
clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
#sound-dai-cells = <0>;
@@ -441,7 +441,7 @@ &rknn_mmu_2 {
};
&saradc {
- vref-supply = <&avcc_1v8_s0>;
+ vref-supply = <&vcc_1v8_s0>;
status = "okay";
};
@@ -666,8 +666,8 @@ regulator-state-mem {
};
};
- avcc_1v8_s0: pldo-reg1 {
- regulator-name = "avcc_1v8_s0";
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -678,8 +678,8 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg2 {
- regulator-name = "vcc_1v8_s0";
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -691,8 +691,8 @@ regulator-state-mem {
};
};
- avdd_1v2_s0: pldo-reg3 {
- regulator-name = "avdd_1v2_s0";
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-name = "vdda_1v2_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200000>;
@@ -703,8 +703,8 @@ regulator-state-mem {
};
};
- vcc_3v3_s0: pldo-reg4 {
- regulator-name = "vcc_3v3_s0";
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-name = "vcca_3v3_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <3300000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v9 4/4] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-29 2:47 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Alexey Charkov, Quentin Schulz, FUKAUMI Naoki, Peter Robinson,
devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Dennis Gilmore
In-Reply-To: <20260429024737.544813-1-dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l2)
- PCIe NVMe slot (pcie2x1l1)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- HDMI output is enabled
- the second HDMI port connected to the DP bridge is left out for a
followup set
Vendors schematics are available at:
https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Alexey Charkov <alchark@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 358 ++++++++++++++++++
2 files changed, 359 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70d0e..7677a0c27b1e 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -221,6 +221,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..895d954a9f23
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_eth: regulator-vcc3v3-eth {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_eth";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_1v8_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie30x1m1_1_perstn>, <&pcie30x1m1_1_clkreqn>,
+ <&pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie20x1m0_perstn>, <&pcie20x1m0_clkreqn>,
+ <&pcie20x1m0_waken>;
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_eth>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ ethernet {
+ ethernet_en: ethernet-en {
+ rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ wlan {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&u2phy0_otg {
+ phy-supply = <&vcc5v0_otg>;
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ /*
+ * The USB3 Type-A host connector is wired to PHY lanes 2/3. Lanes 0/1
+ * are connected to the LT8711UXD DP-to-HDMI bridge on the board.
+ * dp-lane-mux routes USB3 SuperSpeed to the correct lanes.
+ */
+ rockchip,dp-lane-mux = <0 1>;
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v9 3/4] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-29 2:47 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman,
Alexey Charkov, Quentin Schulz, FUKAUMI Naoki, Peter Robinson,
devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Dennis Gilmore
In-Reply-To: <20260429024737.544813-1-dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
5 and 5B boards use gmac for ethernet where the Pro has a PCIe attached
NIC.
Move the 5/5B-specific bits (analog-sound/es8388, FUSB302 Type-C,
gmac1, pwm-leds, i2s1_8ch routing, USB role-switch plumbing) out of
rk3588s-orangepi-5.dtsi into a new rk3588s-orangepi-5-5b.dtsi that is
included by both 5 and 5B.
The RK806 PLDO1 and PLDO2 outputs are wired differently between the
5/5B and the Pro (PLDO1/PLDO2 are swapped), so label the PMIC node
rk806_single in the base dtsi, drop pldo-reg1/pldo-reg2 from it, and
define them via a &rk806_single regulators augmentation in
rk3588s-orangepi-5-5b.dtsi. The Pro will supply its own mapping.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Alexey Charkov <alchark@gmail.com>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 256 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 253 +----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 272 insertions(+), 245 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..b42d2f5d9e3e
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+
+ vbus_typec: regulator-vbus-typec {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec5v_pwren>;
+ regulator-name = "vbus_typec";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pinctrl {
+ usb-typec {
+ usbc0_int: usbc0-int {
+ rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ typec5v_pwren: typec5v-pwren {
+ rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index fd5c6a025cd1..9bdecd5a07e5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,28 +39,14 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
- vbus_typec: regulator-vbus-typec {
+ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&typec5v_pwren>;
- regulator-name = "vbus_typec";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc5v0_sys>;
+ gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
+ regulator-name = "vcc_3v3_sd_s0";
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_s3>;
};
vcc5v0_sys: regulator-vcc5v0-sys {
@@ -109,16 +57,6 @@ vcc5v0_sys: regulator-vcc5v0-sys {
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
-
- vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
- compatible = "regulator-fixed";
- gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
- regulator-name = "vcc_3v3_sd_s0";
- regulator-boot-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_3v3_s3>;
- };
};
&combphy0_ps {
@@ -161,20 +99,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +194,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcca_3v3_s0>;
- DVDD-supply = <&vcca_1v8_s0>;
- HPVDD-supply = <&vcca_3v3_s0>;
- PVDD-supply = <&vcca_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,32 +207,10 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
-&mdio1 {
- rgmii_phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0x1>;
- reset-assert-us = <20000>;
- reset-deassert-us = <100000>;
- reset-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_LOW>;
- };
-};
-
&pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
@@ -392,22 +231,6 @@ hp_detect: hp-detect {
rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
-
- usb-typec {
- usbc0_int: usbc0-int {
- rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- typec5v_pwren: typec5v-pwren {
- rockchip,pins = <3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-};
-
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
};
&rknn_core_0 {
@@ -491,7 +314,7 @@ &spi2 {
pinctrl-names = "default";
pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
- pmic@0 {
+ rk806_single: pmic@0 {
compatible = "rockchip,rk806";
reg = <0x0>;
interrupt-parent = <&gpio0>;
@@ -666,31 +489,6 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg1 {
- regulator-name = "vcc_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcca_1v8_s0: pldo-reg2 {
- regulator-name = "vcca_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
vdda_1v2_s0: pldo-reg3 {
regulator-name = "vdda_1v2_s0";
regulator-always-on;
@@ -841,26 +639,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +651,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +662,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +670,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox