* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Alexei Starovoitov @ 2026-04-24 23:28 UTC (permalink / raw)
To: Ihor Solodrai
Cc: 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 ML, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton,
ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf, LKML,
Network Development, open list:KERNEL SELFTEST FRAMEWORK,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <71fb19ff-6dde-43f4-a0e9-5c8cf2ba4ed4@linux.dev>
On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> I wonder if it's feasible to implement KASAN support on the verifier
> side in post-verification fixups. AI slop for illustration:
>
> ;; Original (1 BPF insn):
> dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
>
> ;; Rewrite (~7 BPF insns):
> r_tmp1 = src ; BPF_MOV64_REG
> r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
> r_tmp2 = r_tmp1 ; copy
> r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
> r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
> r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
> if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
> dst = *(u64 *)(src + off) ; original access (fast path)
> goto +1 ; skip slowpath
> call __asan_report_load8 ; BPF kfunc
> dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
>
> A sort of inline kasan directly in BPF.
>
> There are plenty of issues with it: instruction limit, exposing asan
> API as kfuncs, etc. On the flip side we get cross-arch support out of
> the box with no or mininal JIT changes.
>
> Honestly I'm not excited about this approach, but curious if anyone
> thought about this, or maybe it was already discussed?
We discussed this.
It won't work because we don't have that many temp registers for once
and second it has to preserve all (both callee and caller saved regs).
This is arch specific.
Second, we do not want other archs. This feature is x86-64 only.
It's being added to find _verifier_ bugs. To do that one arch is enough.
>
> > - not all memory accessing BPF instructions are being instrumented:
> > - it focuses on STX/LDX instructions
> > - it discards instructions accessing BPF program stack (already
> > monitored by page guards)
> > - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> > BPF_PROBE_ATOMIC insns
> >
> > The series is marked and sent as RFC:
> > - to allow collecting feedback early and make sure that it goes into the
> > right direction
> > - because it depends on Xu's work to pass data between the verifier and
> > JIT compilers. This work is not merged yet, see [2]. I have been
> > tracking the various revisions he sent on the ML and based my local
> > branch on his work
> > - because tests brought by this series currently can't run on BPF CI:
> > they expect kasan multishot to be enabled, otherwise the first test
> > will make all other kasan-related tests fail.
>
> AFAICT this can be trivially fixed on BPF CI side, we just need to set
> kasan_multi_shot for the VMs running the tests. I will do that, your
> next revision doesn't have to be and RFC.
+1
> > - because some cases like atomic loads/stores are not instrumented yet
> > (and are still making me scratch my head)
> > - because it will hopefully provide a good basis to discuss the topic at
> > LSFMMBPF (see [3])
>
> Apparently, KASAN reporting routine takes a lock [1]:
>
> __asan_load()
> -> check_region_inline()
> -> kasan_report()
> -> start_report()
> -> raw_spin_lock_irqsave(&report_lock, *flags);
>
> BPF programs can run in NMI context, and so it appears to be possible
> to get an unflagged (because of lockdep_off() in start_report)
> deadlock, if an NMI fires on a CPU already holding report_lock.
> Although I guess you'd need two KASAN bugs to happen
> simultaneously for that to occur?... A rare event, I would hope.
>
> It could be addressed with either in_nmi() check at runtime, or
> forbidding kasan for NMI-runnable BPF program types.
We don't need that. If this bpf KASAN finds a bug, it means that
it found a verifier bug. All things are out of the window.
kasan_report() splat can just as well be the last thing that users will see.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Ihor Solodrai @ 2026-04-24 23:31 UTC (permalink / raw)
To: Alexei Starovoitov, Andrey Konovalov
Cc: Alexis Lothoré, 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 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On 4/19/26 3:51 PM, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>>>
>>> I think we're talking past each other.
>>> We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
>>> We're not going to modify arm64 JIT at all.
>>>
>>> This is purely KASAN_GENRIC and only on x86-64.
>>> JIT will emit exactly what compilers emit for generic
>>> which is __asan_load/store. This is as stable ABI as it can get
>>> and we don't want to deviate from it.
>>
>> OK, I supposed that's fair. You did throw me off point with your
>> performance comment. But if you decide to add SW_TAGS support at some
>> point, I think this discussion needs to be revisited.
>>
>> But please add a comment saying that those functions are only exposed
>> for BPF JIT and they are not supposed to be used by other parts of the
>> kernel. And in case you do end up adding a new config option, guard
>> the public declarations by a corresponding ifdef.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
>
>>> The goal here is to find bugs in the verifier.
>>> If something got past it, that shouldn't have,
>>> kasan generic on x86-64 is enough.
>>
>> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
This comment got me curious, and acckktually if we *really* want to,
we can get some KASAN_HW_TAGS testing for BPF already.
The first option is emulation, since QEMU supports MTE [1], e.g.:
qemu-system-aarch64 -machine virt,mte=on ...
This is of course slow, because it runs in software, so it's
infeasible to run this for every signle patch on BPF CI. But we could
run it on schedule on the base branches or smth like that.
[1] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
The second option is set up an AmpereOne machine on Oracle Cloud
(assuming they are available, haven't checked), because apparently [2]
those CPUs run with MTE.
It's a bunch of infra work and spending, but it is doable if it was
a priority.
[2] https://arxiv.org/abs/2511.17773
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
^ permalink raw reply
* Re: [PATCH v3 05/11] iommu: Change group->devices to RCU-protected list
From: Nicolin Chen @ 2026-04-25 0:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Baolu Lu, Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260424225820.GN3444440@nvidia.com>
On Fri, Apr 24, 2026 at 07:58:20PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 12:12:40PM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 10:11:48AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> > > > On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > > > > On 4/17/26 07:28, Nicolin Chen wrote:
> > > > > mutex_unlock(&group->mutex);
> > > > > /*
> > > > > * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > > > > * of some IOMMU drivers calls arm_iommu_attach_device() which
> > > > > * in-turn might call back into IOMMU core code, where it tries
> > > > > * to take group->mutex, resulting in a deadlock.
> > > > > */
> > > > > for_each_group_device(group, gdev)
> > > > > iommu_group_do_probe_finalize(gdev->dev);
> > > > > }
> > > > >
> > > > > return 0;
> > > > > }
> > > > >
> > > > > Will the change above trigger a lockdep splat due to this "mis-locked"
> > > > > case?"
> > > >
> > > > Oh, I missed this one. That's a good finding!
> > > >
> > > > Perhaps we can just change it to list_for_each_entry_rcu holding
> > > > rcu_read_lock() and drop the FIXME.
> > >
> > > You can't hold rcu across that function IIRC
> >
> > Oh right. I didn't think too carefully...
> >
> > I tend to keep it as-is. So, maybe just list_for_each_entry?
>
> Does your series make this existing race materially worse?
I think it would be a status quo.
The only possible place is __iommu_group_remove_device() that this
series touched by changing the kfree(gdev) within the mutex to the
kfree_rcu(gdev, rcu) outside the mutex, which actually added small
delay. Though that doesn't fix a potential race, it shouldn't make
things worse.
Nicolin
^ permalink raw reply
* Re: [PATCH rc v2 1/5] iommu/arm-smmu-v3: Add arm_smmu_adopt_strtab() for kdump
From: Nicolin Chen @ 2026-04-25 0:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, kevin.tian, joro, praan, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <20260424205031.GK3444440@nvidia.com>
On Fri, Apr 24, 2026 at 05:50:31PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 11:33:16AM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 01:56:13PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 15, 2026 at 02:17:36PM -0700, Nicolin Chen wrote:
> > > > +static int arm_smmu_adopt_strtab_2lvl(struct arm_smmu_device *smmu, u32 cfg_reg,
> > [..]
> > > > + cfg->l2.l1tab = devm_memremap(
> > > > + smmu->dev, dma, num_l1_ents * sizeof(struct arm_smmu_strtab_l1),
> > > > + MEMREMAP_WB);
> > >
> > > WB shouldn't be unconditional? If the SMMU is working non-coherently
> > > we need to map it NC. Same remark everwhere
> >
> > Hmm, I am trying to add a coherent-only gate for the series.
>
> OK, may just add a comment to that effect here
Yea, I will add an assertion to the adopt functions as well.
> > MEMREMAP_WC might work. But we cannot verify that on a coherent
> > SMMU, right?
>
> At most you could fake the smmu to noncoherent and check it maps the
> right thing and assume the arch code does it right
I see. I tend to leave it until somebody can verify. It should be
easy to make a followup change:
unsigned long flags = coherent ? MEMREMAP_WB : MEMREMAP_WC;
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-04-25 2:05 UTC (permalink / raw)
To: Catalin Marinas
Cc: Thomas Gleixner, peterz, sudeep.holla, yangyicong,
dietmar.eggemann, Jonathan Cameron, linux-kernel, James Morse,
linux-arm-kernel
In-Reply-To: <aetnTT51ucm2azGG@arm.com>
On 4/24/2026 8:51 PM, Catalin Marinas wrote:
> (updating Jonathan's email address to match MAINTAINERS)
>
> On Fri, Apr 24, 2026 at 09:56:24AM +0800, Jinjie Ruan wrote:
>> On 4/24/2026 4:11 AM, Catalin Marinas wrote:
>>> On Thu, Apr 23, 2026 at 08:32:34PM +0800, Jinjie Ruan wrote:
>>>> On 4/23/2026 6:08 PM, Thomas Gleixner wrote:
>>>>> On Sat, Apr 18 2026 at 12:55, Catalin Marinas wrote:
>>>>>> Another option would have been to avoid marking such CPUs present but I
>>>>>> think this will break other things. Yet another option is to register
>>>>>> all CPU devices even if they never come up (like maxcpus greater than
>>>>>> actual CPUs).
>>>>>>
>>>>>> Opinions? It might be an arm64+ACPI-only thing.
>>>>>
>>>>> I think so. The proper thing to do is to apply sane limits:
>>>>>
>>>>> 1) The possible CPUs enumerated by firmware N_POSSIBLE_FW
>>>>>
>>>>> 2) The maxcpus limit on the command line N_MAXCPUS_CL
>>>>>
>>>>> So the actual possible CPUs evaluates to:
>>>>>
>>>>> num_possible = min(N_POSSIBLE_FW, N_MAXCPUS_CL, CONFIG_NR_CPUS);
>>>>>
>>>>> The evaluation of the firmware should not mark CPUs present which are
>>>>> actually not. ACPI gives you that information. See:
>>>>>
>>>>> 5.2.12.14 GIC CPU Interface (GICC) Structure
>>>>>
>>>>> in the ACPI spec. That has two related bits:
>>>>>
>>>>> Enabled:
>>>>>
>>>>> If this bit is set, the processor is ready for use. If this bit is
>>>>> clear and the Online Capable bit is set, the system supports enabling
>>>>> this processor during OS runtime. If this bit is clear and the Online
>>>>> Capable bit is also clear, this processor is un- usable, and the
>>>>> operating system support will not attempt to use it.
>>>>>
>>>>> Online Capable:
>>>>>
>>>>> The information conveyed by this bit depends on the value of the
>>>>> Enabled bit. If the Enabled bit is set, this bit is reserved and must
>>>>> be zero. Otherwise, if this bit is set, the system supports enabling
>>>>> this processor later during OS runtime
>>>>>
>>>>> So the combination of those gives you the right answer:
>>>>>
>>>>> Enabled Online
>>>>> Capable
>>>>> 0 0 Not present, not possible
>>>>> 0 1 Not present, but possible to "hotplug" layter
>>>>> 1 0 Present
>>>>> 1 1 Invalid
>>>>
>>>> On x86, it seems that all CPUs with the ACPI_MADT_ENABLED bit set will
>>>> be marked as present.
>>>>
>>>> acpi_parse_x2apic()
>>>> -> enabled = processor->lapic_flags & ACPI_MADT_ENABLED
>>>> -> topology_register_apic(enabled)
>>>> -> topo_register_apic(enabled)
>>>> -> set_cpu_present(cpu, true)
>>>
>>> Yes but arm64 marks all CPUs present even if !ACPI_MADT_ENABLED as we
>>> don't have the notion of hardware CPU hotplug.
>>>
>>> I need to dig some more into the original vCPU hotplug support and why
>>> we ended up with all CPUs marked as present even if not calling
>>> register_cpu():
>>>
>>> https://lore.kernel.org/linux-arm-kernel/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
>>>
>>> What's the MADT GICC provided by qemu with "-smp cpus=4,maxcpus=8"? If
>>> it says Enabled for the first 4 and Online Capable for the rest, maybe
>>> we can try something like below:
>>
>> Yes, you are absolutely right,Enabled for the first 4(with GIC Flags:
>> 0x1, bit0 set) and Online Capable for the rest(with GIC Flags: 0x8, bit3
>> set). The ACPI MADT disassembly result is as follows:
>
> That's great, thanks for checking.
>
> I'd like to get some feedback from Jonathan and James as they
> contributed the vCPU hotplug support. The reason was for kubernetes to
> add vCPUs to an existing VM. Hopefully no-one relied on
> /sys/devices/system/cpu/present to report 0-7 in the above
> configuration.
Yes, only cpu 0~3 present.
# cat /sys/devices/system/cpu/possible
0-7
# cat /sys/devices/system/cpu/enabled
0-3
# cat /sys/devices/system/cpu/present
0-3
# cat /sys/devices/system/cpu/online
0-3
# cat /sys/devices/system/cpu/offline
4-7
>
> Have you tried the vCPU hotplug with this patch (the original use-case)?
Yes，the basic vCPU hotplug has no problem as below:
Add the last four CPUs:
(qemu) device_add host-arm-cpu,id=cpu4,core-id=2,thread-id=0
(qemu) [ 678.984281] ACPI: CPU4 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu5,core-id=2,thread-id=1
(qemu) [ 686.593536] ACPI: CPU5 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu6,core-id=3,thread-id=0
(qemu) [ 699.493530] ACPI: CPU6 has been hot-added
(qemu) device_add host-arm-cpu,id=cpu7,core-id=3,thread-id=1
(qemu) [ 706.165770] ACPI: CPU7 has been hot-added
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
0
0
0
0
# echo 1 > /sys/devices/system/cpu/cpu4/online
[ 868.423001] Detected PIPT I-cache on CPU4
[ 868.437103] GICv3: CPU4: found redistributor 4 region
0:0x0000000008120000
[ 868.437193] GICv3: CPU4: using allocated LPI pending table
@0x0000000040120000
[ 868.437330] CPU4: Booted secondary processor 0x0000000004 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu5/online
[ 871.855694] Detected PIPT I-cache on CPU5
[ 871.869725] GICv3: CPU5: found redistributor 5 region
0:0x0000000008140000
[ 871.869811] GICv3: CPU5: using allocated LPI pending table
@0x0000000040130000
[ 871.869938] CPU5: Booted secondary processor 0x0000000005 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu6/online
[ 874.756497] Detected PIPT I-cache on CPU6
[ 874.770521] GICv3: CPU6: found redistributor 6 region
0:0x0000000008160000
[ 874.770606] GICv3: CPU6: using allocated LPI pending table
@0x0000000040140000
[ 874.770748] CPU6: Booted secondary processor 0x0000000006 [0x410fd082]
# echo 1 > /sys/devices/system/cpu/cpu7/online
[ 878.212505] Detected PIPT I-cache on CPU7
[ 878.226560] GICv3: CPU7: found redistributor 7 region
0:0x0000000008180000
[ 878.226646] GICv3: CPU7: using allocated LPI pending table
@0x0000000040150000
[ 878.226783] CPU7: Booted secondary processor 0x0000000007 [0x410fd082]
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
1
1
1
1
# cat /sys/devices/system/cpu/enabled
0-7
# cat /sys/devices/system/cpu/present
0-7
# cat /sys/devices/system/cpu/online
0-7
Unplug the last four CPUs.
# (qemu) device_del cpu4
(qemu) [ 977.336251] psci: CPU4 killed (polled 0 ms)
(qemu) device_del cpu5
(qemu) [ 979.948212] psci: CPU5 killed (polled 0 ms)
(qemu) device_del cpu6
(qemu) [ 981.976337] psci: CPU6 killed (polled 0 ms)
(qemu) device_del cpu7
(qemu) [ 984.476253] psci: CPU7 killed (polled 0 ms)
# cat /sys/devices/system/cpu/cpu*/online
1
1
1
1
# cat /sys/devices/system/cpu/possible
0-7
# cat /sys/devices/system/cpu/enabled
0-3
# cat /sys/devices/system/cpu/present
0-3
# cat /sys/devices/system/cpu/online
0-3
# cat /sys/devices/system/cpu/offline
4-7
>
> Anyway, feel free to post a v2 with the above proposal, cc Jonathan (on
> kernel.org) and James Morse and we'll take it from there. You can add a
> suggested-by me.
>
> Thanks.
>
^ permalink raw reply
* RE: [PATCH] EDAC/xilinx: Fix stack off-by-one in debugfs UE injection handlers
From: Zhuo, Qiuxu @ 2026-04-25 2:51 UTC (permalink / raw)
To: Shengzhuo Wei, Shubhrajyoti Datta, Sai Krishna Potthuri,
Borislav Petkov, Luck, Tony, Michal Simek
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260425-edac-stack-off-by-one-v1-1-4b2dd2b9c7df@cherr.cc>
> From: Shengzhuo Wei <me@cherr.cc>
> Sent: Saturday, April 25, 2026 2:49 AM
> To: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>; Sai Krishna Potthuri
> <sai.krishna.potthuri@amd.com>; Borislav Petkov <bp@alien8.de>; Luck,
> Tony <tony.luck@intel.com>; Michal Simek <michal.simek@amd.com>
> Cc: linux-edac@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; Shengzhuo Wei <me@cherr.cc>
> Subject: [PATCH] EDAC/xilinx: Fix stack off-by-one in debugfs UE injection
> handlers
>
> Two EDAC debugfs write handlers copy up to sizeof(buf) bytes into a fixed-size
> stack buffer and then unconditionally NUL-terminate it via buf[len] = '\0'.
> When userspace writes >= sizeof(buf) bytes, len becomes sizeof(buf) and the
> NUL write lands 1 byte past the end of the stack buffer.
>
> Fix by clamping the copy length to sizeof(buf) - 1 so that the NUL terminator is
> always in-bounds.
>
> Fixes: 3bd2706c910f ("EDAC/zynqmp: Add EDAC support for Xilinx ZynqMP
> OCM")
> Fixes: 83bf24051a60 ("EDAC/versal: Make the bit position of injected errors
> configurable")
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
LGTM,
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
^ permalink raw reply
* [PATCH] remoteproc: xlnx: check remote node state
From: Tanmay Shah @ 2026-04-25 3:02 UTC (permalink / raw)
To: michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc, Tanmay Shah
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>
---
drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++++++
drivers/remoteproc/xlnx_r5_remoteproc.c | 37 ++++++++++++++++++-------
include/linux/firmware/xlnx-zynqmp.h | 21 ++++++++++++++
3 files changed, 76 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..e2f25d94177d 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,32 @@ 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) {
+ 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: 6f860d238b44da8ac57be25289b9f4410691c4e2
--
2.34.1
^ permalink raw reply related
* [PATCH v8 0/6] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
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), dual HDMI output (the
second via a Lontium LT8711UXD DP-to-HDMI bridge on dp0), and a 40-pin
expansion header.
The series was tested against Linux 7.0
This series depends on:
https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
Please take a look.
Thank you,
Dennis Gilmore
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 (6):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
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 +
.../display/bridge/simple-bridge.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 256 ++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 440 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 263 +----------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
9 files changed, 725 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.53.0
^ permalink raw reply
* [PATCH v8 2/6] dt-bindings: display: bridge: simple: document the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Krzysztof Kozlowski
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..752c736c8f85 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - lontium,lt8711uxd
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.53.0
^ permalink raw reply related
* [PATCH v8 1/6] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Krzysztof Kozlowski
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
^ permalink raw reply related
* [PATCH v8 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore, Dmitry Baryshkov
In-Reply-To: <20260425031011.2529364-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..42c1f3d5ba0c 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "lontium,lt8711uxd",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.53.0
^ permalink raw reply related
* [PATCH v8 4/6] arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels to match schematic
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-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.53.0
^ permalink raw reply related
* [PATCH v8 5/6] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-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.53.0
^ permalink raw reply related
* [PATCH v8 6/6] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-25 3:10 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maxime Ripard, Alexey Charkov,
devicetree, linux-rockchip, linux-arm-kernel, dri-devel,
linux-kernel, Dennis Gilmore
In-Reply-To: <20260425031011.2529364-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
- Two HDMI ports, the second is connected to the SoC's DP controller
driven through a Lontium LT8711UXD bridge.
Vendors schematics are available at:
https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 440 ++++++++++++++++++
2 files changed, 441 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 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,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..67363709c4ca
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,440 @@
+// 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;
+ };
+
+ hdmi1-con {
+ compatible = "hdmi-connector";
+ label = "HDMI1 OUT";
+ type = "a";
+
+ port {
+ hdmi1_con_in: endpoint {
+ remote-endpoint = <<8711uxd_out>;
+ };
+ };
+ };
+
+ hdmi-bridge {
+ compatible = "lontium,lt8711uxd";
+ vdd-supply = <&vcc3v3_dp>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt8711uxd_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt8711uxd_out: endpoint {
+ remote-endpoint = <&hdmi1_con_in>;
+ };
+ };
+ };
+ };
+
+ 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_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_bridge_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ regulator-always-on;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ 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>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <<8711uxd_in>;
+ };
+};
+
+&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>;
+ };
+ };
+
+ dp {
+ dp_bridge_en: dp-bridge-en {
+ rockchip,pins = <3 RK_PC2 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 {
+ /*
+ * USBDP PHY0 is wired to a USB3 Type-A host connector via lanes 2/3.
+ * Additionally lanes 0/1 and the aux channel are wired to the
+ * Lontium LT8711UXD DP-to-HDMI bridge feeding the HDMI1 connector.
+ */
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] remoteproc: xlnx: check remote node state
From: Padhi, Beleswar @ 2026-04-25 3:51 UTC (permalink / raw)
To: Tanmay Shah, michal.simek, andersson, mathieu.poirier
Cc: linux-arm-kernel, linux-kernel, linux-remoteproc
In-Reply-To: <20260425030231.3145225-1-tanmay.shah@amd.com>
Hi Tanmay,
In $subject-line, s/remote node/remoteproc
On 4/25/2026 8:32 AM, 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.
This is a good additional check. However, one thing to note is
remoteproc core
framework will load the firmware if the state is set to RPROC_OFFLINE. This
will override the existing firmware in the memory, I hope that is not
fatal for
your usecase?
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 28 +++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 37 ++++++++++++++++++-------
> include/linux/firmware/xlnx-zynqmp.h | 21 ++++++++++++++
> 3 files changed, 76 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..e2f25d94177d 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,32 @@ 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) {
> + if (zynqmp_r5_get_rsc_table_va(r5_core))
> + dev_dbg(r5_core->dev, "rsc tbl not found\n");
Do you still want to set state = RPROC_DETACHED if resource table is not
found in the
memory?
Thanks,
Beleswar
> + 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: 6f860d238b44da8ac57be25289b9f4410691c4e2
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-25 4:53 UTC (permalink / raw)
To: Mimi Zohar
Cc: Paul Moore, roberto.sassu, Jonathan McDowell,
linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, jmorris, serge, dmitry.kasatkin,
eric.snowberg, jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <014cf39aa8d6a0bcfa1a95c069675977ac67b843.camel@linux.ibm.com>
[...]
> > I understand the need to ensure that the TPM is available, but if it
> > isn't safe to wait to initialize IMA at late_initcall_sync() then it
> > would seem like this is a bad option and we need another mechanism to
> > synchronize IMA with TPM devices. If it is safe to initalize IMA in
> > late_initcall_sync(), just do that and be done with it.
>
> Within the same initcall level there is no way of ordering the initialization.
> Yeorum attempted to address the ordering issue in commit 0e0546eabcd6
> ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"),
> which is being reverted in this patch set.
>
> Ordering within an initcall level needs to be fixed, but for now retrying at
> late_initcall_sync works for some, hopefully most, cases.
Ordering within an initcall level is not good idea.
Though it came to my mind first long ago,
It also goes against existing mechanisms like deferred probe, and
can cause the driver model’s dependency handling to harden
in the wrong direction. So this I think it wouldn't be an option.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH 00/35] Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
This patch series introduces wrapper functions strscpy().
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Summary:
fbdev: matroxfb: Use safer strscpy() instead of strcpy()
fbdev: i810: Use safer strscpy() instead of strcpy()
fbdev: sisfb: Use safer strscpy() instead of strcpy()
fbdev: geode: Use safer strscpy() instead of strcpy()
fbdev: atafb: Use safer strscpy() instead of strcpy()
fbdev: tdfxfb: Use safer strscpy() instead of strcpy()
fbdev: pm2fb: Use safer strscpy() instead of strcpy()
fbdev: xen-fbfront: Use safer strscpy() instead of strcpy()
fbdev: controlfb: Use safer strscpy() instead of strcpy()
fbdev: stifb: Use safer strscpy() instead of strcpy()
fbdev: fm2fb: Use safer strscpy() instead of strcpy()
fbdev: arkfb: Use safer strscpy() instead of strcpy()
fbdev: vt8500lcdfb: Use safer strscpy() instead of strcpy()
fbdev: vt8623fb: Use safer strscpy() instead of strcpy()
fbdev: gbefb: Use safer strscpy() instead of strcpy()
fbdev: wm8505fb: Use safer strscpy() instead of strcpy()
fbdev: rivafb: Use safer strscpy() instead of strcpy()
fbdev: sh7760fb: Use safer strscpy() instead of strcpy()
fbdev: savage: Use safer strscpy() instead of strcpy()
fbdev: atmel_lcdfb: Use safer strscpy() instead of strcpy()
fbdev: aty128fb: Use safer strscpy() instead of strcpy()
fbdev: amifb: Use safer strscpy() instead of strcpy()
fbdev: s3fb: Use safer strscpy() instead of strcpy()
fbdev: viafb: Use safer strscpy() instead of strcpy()
fbdev: platinumfb: Use safer strscpy() instead of strcpy()
fbdev: cyber2000fb: Use safer strscpy() instead of strcpy()
fbdev: mb862xxfb: Use safer strscpy() instead of strcpy()
fbdev: mmpfb: Use safer strscpy() instead of strcpy()
fbdev: ep93xx-fb: Use safer strscpy() instead of strcpy()
fbdev: valkyriefb: Use safer strscpy() instead of strcpy()
fbdev: pxafb: Use safer strscpy() instead of strcpy()
fbdev: sa1100fb: Use safer strscpy() instead of strcpy()
fbdev: sm501fb: Use safer strscpy() instead of strcpy()
fbdev: acornfb: Use safer strscpy() instead of strcpy()
fbdev: ocfb: Use safer strscpy() instead of strcpy()
drivers/video/fbdev/acornfb.c | 2 +-
drivers/video/fbdev/amifb.c | 2 +-
drivers/video/fbdev/arkfb.c | 2 +-
drivers/video/fbdev/atafb.c | 10 +++++-----
drivers/video/fbdev/atmel_lcdfb.c | 2 +-
drivers/video/fbdev/aty/aty128fb.c | 2 +-
drivers/video/fbdev/controlfb.c | 2 +-
drivers/video/fbdev/cyber2000fb.c | 2 +-
drivers/video/fbdev/ep93xx-fb.c | 2 +-
drivers/video/fbdev/fm2fb.c | 2 +-
drivers/video/fbdev/gbefb.c | 2 +-
drivers/video/fbdev/geode/gx1fb_core.c | 2 +-
drivers/video/fbdev/geode/gxfb_core.c | 2 +-
drivers/video/fbdev/geode/lxfb_core.c | 2 +-
drivers/video/fbdev/i810/i810-i2c.c | 2 +-
drivers/video/fbdev/i810/i810_main.c | 2 +-
drivers/video/fbdev/matrox/matroxfb_base.c | 6 +++---
drivers/video/fbdev/matrox/matroxfb_crtc2.c | 2 +-
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 2 +-
drivers/video/fbdev/mmp/fb/mmpfb.c | 2 +-
drivers/video/fbdev/ocfb.c | 2 +-
drivers/video/fbdev/platinumfb.c | 2 +-
drivers/video/fbdev/pm2fb.c | 6 +++---
drivers/video/fbdev/pxafb.c | 2 +-
drivers/video/fbdev/riva/rivafb-i2c.c | 2 +-
drivers/video/fbdev/s3fb.c | 2 +-
drivers/video/fbdev/sa1100fb.c | 2 +-
drivers/video/fbdev/savage/savagefb-i2c.c | 2 +-
drivers/video/fbdev/sh7760fb.c | 2 +-
drivers/video/fbdev/sis/sis_main.c | 16 ++++++++--------
drivers/video/fbdev/sm501fb.c | 2 +-
drivers/video/fbdev/stifb.c | 2 +-
drivers/video/fbdev/tdfxfb.c | 6 +++---
drivers/video/fbdev/valkyriefb.c | 2 +-
drivers/video/fbdev/via/viafbdev.c | 2 +-
drivers/video/fbdev/vt8500lcdfb.c | 2 +-
drivers/video/fbdev/vt8623fb.c | 2 +-
drivers/video/fbdev/wm8505fb.c | 2 +-
drivers/video/fbdev/xen-fbfront.c | 2 +-
39 files changed, 56 insertions(+), 56 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 02/35] fbdev: i810: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/i810/i810-i2c.c | 2 +-
drivers/video/fbdev/i810/i810_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810-i2c.c b/drivers/video/fbdev/i810/i810-i2c.c
index 7db17d0d8a8c..6141e9d2fff4 100644
--- a/drivers/video/fbdev/i810/i810-i2c.c
+++ b/drivers/video/fbdev/i810/i810-i2c.c
@@ -91,7 +91,7 @@ static int i810_setup_i2c_bus(struct i810fb_i2c_chan *chan, const char *name)
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
chan->adapter.algo_data = &chan->algo;
chan->adapter.dev.parent = &chan->par->dev->dev;
diff --git a/drivers/video/fbdev/i810/i810_main.c b/drivers/video/fbdev/i810/i810_main.c
index 10b914a24114..0499058a3ea8 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1091,7 +1091,7 @@ static int encode_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
memset(fix, 0, sizeof(struct fb_fix_screeninfo));
- strcpy(fix->id, "I810");
+ strscpy(fix->id, "I810");
mutex_lock(&info->mm_lock);
fix->smem_start = par->fb.physical;
fix->smem_len = par->fb.size;
--
2.34.1
^ permalink raw reply related
* [PATCH 01/35] fbdev: matroxfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/matrox/matroxfb_base.c | 6 +++---
drivers/video/fbdev/matrox/matroxfb_crtc2.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
index e1a4bc7c2318..bd786543478c 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -709,7 +709,7 @@ static void matroxfb_init_fix(struct matrox_fb_info *minfo)
struct fb_fix_screeninfo *fix = &minfo->fbcon.fix;
DBG(__func__)
- strcpy(fix->id,"MATROX");
+ strscpy(fix->id, "MATROX");
fix->xpanstep = 8; /* 8 for 8bpp, 4 for 16bpp, 2 for 32bpp */
fix->ypanstep = 1;
@@ -1091,8 +1091,8 @@ static int matroxfb_ioctl(struct fb_info *info,
struct v4l2_capability r;
memset(&r, 0, sizeof(r));
- strcpy(r.driver, "matroxfb");
- strcpy(r.card, "Matrox");
+ strscpy(r.driver, "matroxfb");
+ strscpy(r.card, "Matrox");
sprintf(r.bus_info, "PCI:%s", pci_name(minfo->pcidev));
r.version = KERNEL_VERSION(1,0,0);
r.capabilities = V4L2_CAP_VIDEO_OUTPUT;
diff --git a/drivers/video/fbdev/matrox/matroxfb_crtc2.c b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
index 8de882b09a24..c20dd06c5fcd 100644
--- a/drivers/video/fbdev/matrox/matroxfb_crtc2.c
+++ b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
@@ -299,7 +299,7 @@ static void matroxfb_dh_init_fix(struct matroxfb_dh_fb_info *m2info)
{
struct fb_fix_screeninfo *fix = &m2info->fbcon.fix;
- strcpy(fix->id, "MATROX DH");
+ strscpy(fix->id, "MATROX DH");
fix->smem_start = m2info->video.base;
fix->smem_len = m2info->video.len_usable;
--
2.34.1
^ permalink raw reply related
* [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/sis/sis_main.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
index 84567d67f71d..e87fa261f76c 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -205,7 +205,7 @@ static void sisfb_search_mode(char *name, bool quiet)
}
if(strlen(name) <= 19) {
- strcpy(strbuf1, name);
+ strscpy(strbuf1, name);
for(i = 0; i < strlen(strbuf1); i++) {
if(strbuf1[i] < '0' || strbuf1[i] > '9') strbuf1[i] = ' ';
}
@@ -5947,33 +5947,33 @@ static int sisfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
#ifdef CONFIG_FB_SIS_300
case PCI_DEVICE_ID_SI_730:
ivideo->chip = SIS_730;
- strcpy(ivideo->myid, "SiS 730");
+ strscpy(ivideo->myid, "SiS 730");
break;
#endif
#ifdef CONFIG_FB_SIS_315
case PCI_DEVICE_ID_SI_651:
/* ivideo->chip is ok */
- strcpy(ivideo->myid, "SiS 651");
+ strscpy(ivideo->myid, "SiS 651");
break;
case PCI_DEVICE_ID_SI_740:
ivideo->chip = SIS_740;
- strcpy(ivideo->myid, "SiS 740");
+ strscpy(ivideo->myid, "SiS 740");
break;
case PCI_DEVICE_ID_SI_661:
ivideo->chip = SIS_661;
- strcpy(ivideo->myid, "SiS 661");
+ strscpy(ivideo->myid, "SiS 661");
break;
case PCI_DEVICE_ID_SI_741:
ivideo->chip = SIS_741;
- strcpy(ivideo->myid, "SiS 741");
+ strscpy(ivideo->myid, "SiS 741");
break;
case PCI_DEVICE_ID_SI_760:
ivideo->chip = SIS_760;
- strcpy(ivideo->myid, "SiS 760");
+ strscpy(ivideo->myid, "SiS 760");
break;
case PCI_DEVICE_ID_SI_761:
ivideo->chip = SIS_761;
- strcpy(ivideo->myid, "SiS 761");
+ strscpy(ivideo->myid, "SiS 761");
break;
#endif
default:
--
2.34.1
^ permalink raw reply related
* [PATCH 04/35] fbdev: geode: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/geode/gx1fb_core.c | 2 +-
drivers/video/fbdev/geode/gxfb_core.c | 2 +-
drivers/video/fbdev/geode/lxfb_core.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/geode/gx1fb_core.c b/drivers/video/fbdev/geode/gx1fb_core.c
index a1919c1934ac..c5a6e3038b98 100644
--- a/drivers/video/fbdev/geode/gx1fb_core.c
+++ b/drivers/video/fbdev/geode/gx1fb_core.c
@@ -274,7 +274,7 @@ static struct fb_info *gx1fb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "GX1");
+ strscpy(info->fix.id, "GX1");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c
index 8d69be7c9d31..fe987829315b 100644
--- a/drivers/video/fbdev/geode/gxfb_core.c
+++ b/drivers/video/fbdev/geode/gxfb_core.c
@@ -289,7 +289,7 @@ static struct fb_info *gxfb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "Geode GX");
+ strscpy(info->fix.id, "Geode GX");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
diff --git a/drivers/video/fbdev/geode/lxfb_core.c b/drivers/video/fbdev/geode/lxfb_core.c
index cad99f5b7fe8..3ae37ec9f151 100644
--- a/drivers/video/fbdev/geode/lxfb_core.c
+++ b/drivers/video/fbdev/geode/lxfb_core.c
@@ -412,7 +412,7 @@ static struct fb_info *lxfb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "Geode LX");
+ strscpy(info->fix.id, "Geode LX");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
--
2.34.1
^ permalink raw reply related
* [PATCH 06/35] fbdev: tdfxfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/tdfxfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index 4c4e53aaea3a..b7cc2b1012eb 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -1401,15 +1401,15 @@ static int tdfxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
/* Configure the default fb_fix_screeninfo first */
switch (pdev->device) {
case PCI_DEVICE_ID_3DFX_BANSHEE:
- strcpy(info->fix.id, "3Dfx Banshee");
+ strscpy(info->fix.id, "3Dfx Banshee");
default_par->max_pixclock = BANSHEE_MAX_PIXCLOCK;
break;
case PCI_DEVICE_ID_3DFX_VOODOO3:
- strcpy(info->fix.id, "3Dfx Voodoo3");
+ strscpy(info->fix.id, "3Dfx Voodoo3");
default_par->max_pixclock = VOODOO3_MAX_PIXCLOCK;
break;
case PCI_DEVICE_ID_3DFX_VOODOO5:
- strcpy(info->fix.id, "3Dfx Voodoo5");
+ strscpy(info->fix.id, "3Dfx Voodoo5");
default_par->max_pixclock = VOODOO5_MAX_PIXCLOCK;
break;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 05/35] fbdev: atafb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/atafb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index b8ed1c537293..5f2d50919718 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -555,7 +555,7 @@ static int tt_encode_fix(struct fb_fix_screeninfo *fix, struct atafb_par *par)
{
int mode;
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -851,7 +851,7 @@ static inline int hxx_prescale(struct falcon_hw *hw)
static int falcon_encode_fix(struct fb_fix_screeninfo *fix,
struct atafb_par *par)
{
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -1770,7 +1770,7 @@ static int stste_encode_fix(struct fb_fix_screeninfo *fix,
{
int mode;
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -2069,7 +2069,7 @@ static void st_ovsc_switch(void)
static int ext_encode_fix(struct fb_fix_screeninfo *fix, struct atafb_par *par)
{
- strcpy(fix->id, "Unknown Extern");
+ strscpy(fix->id, "Unknown Extern");
fix->smem_start = external_addr;
fix->smem_len = PAGE_ALIGN(external_len);
if (external_depth == 1) {
@@ -3100,7 +3100,7 @@ static int __init atafb_probe(struct platform_device *pdev)
}
#endif /* ATAFB_EXT */
-// strcpy(fb_info.mode->name, "Atari Builtin ");
+// strscpy(fb_info.mode->name, "Atari Builtin ");
fb_info.fbops = &atafb_ops;
// try to set default (detected; requested) var
do_fb_set_var(&atafb_predefined[default_par - 1], 1);
--
2.34.1
^ permalink raw reply related
* [PATCH 08/35] fbdev: xen-fbfront: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/xen-fbfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
index 4385976277ac..1cc234751be5 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -429,7 +429,7 @@ static int xenfb_probe(struct xenbus_device *dev,
fb_info->fix.line_length = fb_info->var.xres * XENFB_DEPTH / 8;
fb_info->fix.smem_start = 0;
fb_info->fix.smem_len = fb_size;
- strcpy(fb_info->fix.id, "xen");
+ strscpy(fb_info->fix.id, "xen");
fb_info->fix.type = FB_TYPE_PACKED_PIXELS;
fb_info->fix.accel = FB_ACCEL_NONE;
--
2.34.1
^ permalink raw reply related
* [PATCH 09/35] fbdev: controlfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:59 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/controlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 4bb821d7f284..09cf6befd8d3 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -780,7 +780,7 @@ static void __init control_init_info(struct fb_info *info, struct fb_info_contro
fb_alloc_cmap(&info->cmap, 256, 0);
/* Fill fix common fields */
- strcpy(info->fix.id, "control");
+ strscpy(info->fix.id, "control");
info->fix.mmio_start = p->control_regs_phys;
info->fix.mmio_len = sizeof(struct control_regs);
info->fix.type = FB_TYPE_PACKED_PIXELS;
--
2.34.1
^ 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