* Re: [PATCH v4 12/21] misc: open-dice: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:04 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <5a83ab00195dc8d0609fa6cc525493010ac4ead1.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/misc/open-dice.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> index 24c29e0f00ef..45060fb4ea27 100644
> --- a/drivers/misc/open-dice.c
> +++ b/drivers/misc/open-dice.c
> @@ -86,29 +86,32 @@ static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> /*
> * Creates a mapping of the reserved memory region in user address space.
> */
> -static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> +static int open_dice_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *filp = desc->file;
> struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
>
> - if (vma->vm_flags & VM_MAYSHARE) {
> + if (vma_desc_test(desc, VMA_MAYSHARE_BIT)) {
> /* Do not allow userspace to modify the underlying data. */
> - if (vma->vm_flags & VM_WRITE)
> + if (vma_desc_test(desc, VMA_WRITE_BIT))
> return -EPERM;
> /* Ensure userspace cannot acquire VM_WRITE later. */
> - vm_flags_clear(vma, VM_MAYWRITE);
> + vma_desc_clear_flags(desc, VMA_MAYWRITE_BIT);
> }
>
> /* Create write-combine mapping so all clients observe a wipe. */
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> - vm_flags_set(vma, VM_DONTCOPY | VM_DONTDUMP);
> - return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> + desc->page_prot = pgprot_writecombine(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_DONTCOPY_BIT, VMA_DONTDUMP_BIT);
> + mmap_action_simple_ioremap(desc, drvdata->rmem->base,
> + drvdata->rmem->size);
> + return 0;
> }
>
> static const struct file_operations open_dice_fops = {
> .owner = THIS_MODULE,
> .read = open_dice_read,
> .write = open_dice_write,
> - .mmap = open_dice_mmap,
> + .mmap_prepare = open_dice_mmap_prepare,
> };
>
> static int __init open_dice_probe(struct platform_device *pdev)
^ permalink raw reply
* Re: [PATCH bpf-next v10 4/5] bpf, x86: Emit ENDBR for indirect jump targets
From: Leon Hwang @ 2026-03-25 10:13 UTC (permalink / raw)
To: xukuohai
Cc: a.s.protopopov, alexis.lothore, andrii, ast, bjorn, bpf, chleroy,
daniel, davem, eddyz87, gor, hbathini, hca, hengqi.chen, iii,
johan.almbladh, linux-arm-kernel, linux-kernel, linux, list+bpf,
luke.r.nels, martin.lau, naveen, paulburton, pulehui, puranjay,
udknight, xi.wang, yangtiezhu, yonghong.song, Leon Hwang
In-Reply-To: <20260324122052.342751-5-xukuohai@huaweicloud.com>
On Tue, Mar 24, 2026 at 08:20:51PM +0800, Xu Kuohai wrote:
>From: Xu Kuohai <xukuohai@huawei.com>
>
>On CPUs that support CET/IBT, the indirect jump selftest triggers
>a kernel panic because the indirect jump targets lack ENDBR
>instructions.
>
>To fix it, emit an ENDBR instruction to each indirect jump target. Since
>the ENDBR instruction shifts the position of original jited instructions,
>fix the instruction address calculation wherever the addresses are used.
>
>For reference, below is a sample panic log.
>
> Missing ENDBR: bpf_prog_2e5f1c71c13ac3e0_big_jump_table+0x97/0xe1
> ------------[ cut here ]------------
> kernel BUG at arch/x86/kernel/cet.c:133!
> Oops: invalid opcode: 0000 [#1] SMP NOPTI
>
> ...
>
> ? 0xffffffffc00fb258
> ? bpf_prog_2e5f1c71c13ac3e0_big_jump_table+0x97/0xe1
> bpf_prog_test_run_syscall+0x110/0x2f0
> ? fdget+0xba/0xe0
> __sys_bpf+0xe4b/0x2590
> ? __kmalloc_node_track_caller_noprof+0x1c7/0x680
> ? bpf_prog_test_run_syscall+0x215/0x2f0
> __x64_sys_bpf+0x21/0x30
> do_syscall_64+0x85/0x620
> ? bpf_prog_test_run_syscall+0x1e2/0x2f0
>
>Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps")
>Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com>
>Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Acked-by: Leon Hwang <leon.hwang@linux.dev>
[...]
^ permalink raw reply
* Re: [PATCH v4 12/21] misc: open-dice: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:14 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <5a83ab00195dc8d0609fa6cc525493010ac4ead1.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/misc/open-dice.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> index 24c29e0f00ef..45060fb4ea27 100644
> --- a/drivers/misc/open-dice.c
> +++ b/drivers/misc/open-dice.c
> @@ -86,29 +86,32 @@ static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> /*
> * Creates a mapping of the reserved memory region in user address space.
> */
> -static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> +static int open_dice_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *filp = desc->file;
> struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
>
> - if (vma->vm_flags & VM_MAYSHARE) {
> + if (vma_desc_test(desc, VMA_MAYSHARE_BIT)) {
> /* Do not allow userspace to modify the underlying data. */
> - if (vma->vm_flags & VM_WRITE)
> + if (vma_desc_test(desc, VMA_WRITE_BIT))
> return -EPERM;
> /* Ensure userspace cannot acquire VM_WRITE later. */
> - vm_flags_clear(vma, VM_MAYWRITE);
> + vma_desc_clear_flags(desc, VMA_MAYWRITE_BIT);
> }
>
> /* Create write-combine mapping so all clients observe a wipe. */
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> - vm_flags_set(vma, VM_DONTCOPY | VM_DONTDUMP);
> - return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> + desc->page_prot = pgprot_writecombine(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_DONTCOPY_BIT, VMA_DONTDUMP_BIT);
> + mmap_action_simple_ioremap(desc, drvdata->rmem->base,
> + drvdata->rmem->size);
> + return 0;
> }
>
> static const struct file_operations open_dice_fops = {
> .owner = THIS_MODULE,
> .read = open_dice_read,
> .write = open_dice_write,
> - .mmap = open_dice_mmap,
> + .mmap_prepare = open_dice_mmap_prepare,
> };
>
> static int __init open_dice_probe(struct platform_device *pdev)
^ permalink raw reply
* Re: [PATCH bpf-next v10 5/5] bpf, arm64: Emit BTI for indirect jump target
From: Leon Hwang @ 2026-03-25 10:14 UTC (permalink / raw)
To: Xu Kuohai, bpf, linux-kernel, linux-arm-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Yonghong Song, Puranjay Mohan,
Anton Protopopov, Alexis Lothoré, Shahab Vahedi,
Russell King, Tiezhu Yang, Hengqi Chen, Johan Almbladh,
Paul Burton, Hari Bathini, Christophe Leroy, Naveen N Rao,
Luke Nelson, Xi Wang, Björn Töpel, Pu Lehui,
Ilya Leoshkevich, Heiko Carstens, Vasily Gorbik, David S . Miller,
Wang YanQing
In-Reply-To: <20260324122052.342751-6-xukuohai@huaweicloud.com>
On 24/3/26 20:20, Xu Kuohai wrote:
> From: Xu Kuohai <xukuohai@huawei.com>
>
> On CPUs that support BTI, the indirect jump selftest triggers a kernel
> panic because there is no BTI instructions at the indirect jump targets.
>
> Fix it by emitting a BTI instruction for each indirect jump target.
>
> For reference, below is a sample panic log.
>
> Internal error: Oops - BTI: 0000000036000003 [#1] SMP
> ...
> Call trace:
> bpf_prog_2e5f1c71c13ac3e0_big_jump_table+0x54/0xf8 (P)
> bpf_prog_run_pin_on_cpu+0x140/0x468
> bpf_prog_test_run_syscall+0x280/0x3b8
> bpf_prog_test_run+0x22c/0x2c0
>
> Fixes: f4a66cf1cb14 ("bpf: arm64: Add support for indirect jumps")
> Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com>
> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Acked-by: Leon Hwang <leon.hwang@linux.dev>
> ---
[...]
^ permalink raw reply
* Re: [PATCH v4 13/21] hpet: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:17 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <094c5fcfb2459a4f6d791b1fb852b01e252a44d4.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/char/hpet.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 60dd09a56f50..8f128cc40147 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -354,8 +354,9 @@ static __init int hpet_mmap_enable(char *str)
> }
> __setup("hpet_mmap=", hpet_mmap_enable);
>
> -static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> +static int hpet_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *file = desc->file;
> struct hpet_dev *devp;
> unsigned long addr;
>
> @@ -368,11 +369,12 @@ static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> if (addr & (PAGE_SIZE - 1))
> return -ENOSYS;
>
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> - return vm_iomap_memory(vma, addr, PAGE_SIZE);
> + desc->page_prot = pgprot_noncached(desc->page_prot);
> + mmap_action_simple_ioremap(desc, addr, PAGE_SIZE);
> + return 0;
> }
> #else
> -static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
> +static int hpet_mmap_prepare(struct vm_area_desc *desc)
> {
> return -ENOSYS;
> }
> @@ -710,7 +712,7 @@ static const struct file_operations hpet_fops = {
> .open = hpet_open,
> .release = hpet_release,
> .fasync = hpet_fasync,
> - .mmap = hpet_mmap,
> + .mmap_prepare = hpet_mmap_prepare,
> };
>
> static int hpet_is_known(struct hpet_data *hdp)
^ permalink raw reply
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Suzuki K Poulose @ 2026-03-25 10:16 UTC (permalink / raw)
To: Gavin Shan, Steven Price, Mathieu Poirier
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <0b7121e7-3c74-4303-a200-01d2b7c535ce@redhat.com>
Hi Gavin
Steven is on holidays, so I am jumping in here.
On 25/03/2026 06:37, Gavin Shan wrote:
> Hi Steven,
>
> On 3/21/26 2:45 AM, Steven Price wrote:
>> On 19/03/2026 23:02, Mathieu Poirier wrote:
>
> [...]
>
>>>>
>>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>>> use the following branch:
>>>>
>>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>>
>>> This RMM version is expecting a RMM EL3 interface version of at least
>>> 2.0. Do
>>> you have a TF-A to use with it?
>>
>> You should be able to use the 'master' branch of the TF-A repository.
>> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>>
>
> In upstream TF-A repository [1], I don't see the config option
> 'RMM_V1_COMPAT'.
> would it be something else?
>
> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch:
> master)
>
suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
Makefile: RMM_V1_COMPAT \
Makefile: RMM_V1_COMPAT \
docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean
flag to enable support for RMM v1.x compatibility
include/services/rmmd_svc.h:#if RMM_V1_COMPAT
include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
make_helpers/defaults.mk:RMM_V1_COMPAT := 1
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge
changes from topic "qti_lemans_evk" into integration
suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
> I use the following command to build TF-A image. The RMM-EL3 compatible
> issue is
> still seen.
>
> TFA_PATH=$PWD
> EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/
> RELEASE_GCC5/FV/QEMU_EFI.fd
> RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
> make CROSS_COMPILE=aarch64-none-elf- \
> PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
> QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
> BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
> -j 8 all fip
>
> Booting messages
> ================
> INFO: BL31: Initializing runtime services
> INFO: RMM setup done.
> INFO: BL31: Initializing RMM
> INFO: RMM init start.
> ERROR: RMM init failed: -2
> WARNING: BL31: RMM initialization failed
This is definitely the TF-A RMM incompatibility.
Btw, the shrinkwrap overlay configs in tf-RMM repository should work.
But unfortunately the Linux/kvmtool repositories are pointing to
internal repositories. The following patch should fix it and get
it all working. I am working with the tf-rmm team to fix this.
--8>--
diff --git a/tools/shrinkwrap/configs/cca.yaml
b/tools/shrinkwrap/configs/cca.yaml
index 1c0455ba..0d70a582 100644
--- a/tools/shrinkwrap/configs/cca.yaml
+++ b/tools/shrinkwrap/configs/cca.yaml
@@ -25,8 +25,8 @@ build:
linux:
repo:
- remote: https://gitlab.geo.arm.com/software/linux-arm/fkvm.git
- revision: stepri01/cca/v13-wip+sro
+ remote: https://gitlab.arm.com/linux-arm/linux-cca
+ revision: cca-host/v13
prebuild:
- ./scripts/config --file ${param:builddir}/.config --enable
CONFIG_PCI_TSM
- ./scripts/config --file ${param:builddir}/.config --enable
CONFIG_PCI_DOE
@@ -50,5 +50,5 @@ build:
remote: https://git.kernel.org/pub/scm/utils/dtc/dtc.git
revision: v1.7.2
kvmtool:
- remote: https://gitlab.geo.arm.com/software/linux-arm/fkvmtool.git
- revision: stepri01/cca/v13-wip
+ remote: https://gitlab.arm.com/linux-arm/kvmtool-cca
+ revision: cca/v11
Kind regards
Suzuki
>
> Thanks,
> Gavin
>
>
>
^ permalink raw reply related
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Suzuki K Poulose @ 2026-03-25 10:19 UTC (permalink / raw)
To: Gavin Shan, Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Shanker Donthineni, Alper Gun,
Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <779079e1-7193-46e9-b18c-9ab5e69bb077@redhat.com>
Hi Gavin
On 25/03/2026 04:07, Gavin Shan wrote:
> Hi Steven,
>
> On 3/19/26 1:53 AM, Steven Price wrote:
>>
>> This series is based on v7.0-rc1. It is also available as a git
>> repository:
>>
>> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13
>>
>> Work in progress changes for kvmtool are available from the git
>> repository below:
>>
>> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11
>>
>
> Could you please share if we have a working qemu repository on top of this
> (v13) series? The previous qemu repository [1] seems out of dated for long
> time. I heard Jean won't be able to continue his efforts on QEMU part, who
> is going to pick it up in this case.
>
> [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/latest)
Unfortunately not at the moment. We have moved on to a simpler UABI,
which drops most of the previous configuration steps.
>
>> Note that the kvmtool code has been tidied up (thanks to Suzuki) and
>> this involves a minor change in flags. The "--restricted_mem" flag is no
>> longer recognised (or necessary).
>>
>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>> use the following branch:
>>
>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>
>
> I'm seeing error to initialize RMM with the suggested RMM branch
> (topics/rmm-v2.0-poc)
> and the upstream TF-A [1]. It seems the problem is compatible issue in the
> RMM-EL3 interface. RMM requires verion 2.0 while TF-A only supports 0.8. So
> I guess I must be using a wrong TF-A repository. Could you please share
> which
> TF-A repository you use for testing?
See the other thread with Mathieu.
Kind regards
Suzuki
^ permalink raw reply
* Re: [PATCH 08/12] vdpa: use generic driver_override infrastructure
From: Eugenio Perez Martin @ 2026-03-25 10:17 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Alex Williamson,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Christophe Leroy (CS GROUP), linux-kernel, driver-core,
linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
virtualization, kvm, xen-devel, linux-arm-kernel, Gui-Dong Han
In-Reply-To: <20260324005919.2408620-9-dakr@kernel.org>
On Tue, Mar 24, 2026 at 2:00 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> When a driver is probed through __driver_attach(), the bus' match()
> callback is called without the device lock held, thus accessing the
> driver_override field without a lock, which can cause a UAF.
>
> Fix this by using the driver-core driver_override infrastructure taking
> care of proper locking internally.
>
> Note that calling match() from __driver_attach() without the device lock
> held is intentional. [1]
>
> Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Fixes: 539fec78edb4 ("vdpa: add driver_override support")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
> drivers/vdpa/vdpa.c | 48 +++++---------------------------------------
> include/linux/vdpa.h | 4 ----
> 2 files changed, 5 insertions(+), 47 deletions(-)
>
Consolidate this logic is great, thanks!
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index 34874beb0152..caf0ee5d6856 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -67,57 +67,20 @@ static void vdpa_dev_remove(struct device *d)
>
> static int vdpa_dev_match(struct device *dev, const struct device_driver *drv)
> {
> - struct vdpa_device *vdev = dev_to_vdpa(dev);
> + int ret;
>
> /* Check override first, and if set, only use the named driver */
> - if (vdev->driver_override)
> - return strcmp(vdev->driver_override, drv->name) == 0;
> + ret = device_match_driver_override(dev, drv);
> + if (ret >= 0)
> + return ret;
>
> /* Currently devices must be supported by all vDPA bus drivers */
> return 1;
Nit: Maybe all of this can be replaced by
abs(device_match_driver_override(dev,drv))? Or maybe we're putting too
much in the same line.
Either way,
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Thanks!
> }
>
> -static ssize_t driver_override_store(struct device *dev,
> - struct device_attribute *attr,
> - const char *buf, size_t count)
> -{
> - struct vdpa_device *vdev = dev_to_vdpa(dev);
> - int ret;
> -
> - ret = driver_set_override(dev, &vdev->driver_override, buf, count);
> - if (ret)
> - return ret;
> -
> - return count;
> -}
> -
> -static ssize_t driver_override_show(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct vdpa_device *vdev = dev_to_vdpa(dev);
> - ssize_t len;
> -
> - device_lock(dev);
> - len = sysfs_emit(buf, "%s\n", vdev->driver_override);
> - device_unlock(dev);
> -
> - return len;
> -}
> -static DEVICE_ATTR_RW(driver_override);
> -
> -static struct attribute *vdpa_dev_attrs[] = {
> - &dev_attr_driver_override.attr,
> - NULL,
> -};
> -
> -static const struct attribute_group vdpa_dev_group = {
> - .attrs = vdpa_dev_attrs,
> -};
> -__ATTRIBUTE_GROUPS(vdpa_dev);
> -
> static const struct bus_type vdpa_bus = {
> .name = "vdpa",
> - .dev_groups = vdpa_dev_groups,
> + .driver_override = true,
> .match = vdpa_dev_match,
> .probe = vdpa_dev_probe,
> .remove = vdpa_dev_remove,
> @@ -132,7 +95,6 @@ static void vdpa_release_dev(struct device *d)
> ops->free(vdev);
>
> ida_free(&vdpa_index_ida, vdev->index);
> - kfree(vdev->driver_override);
> kfree(vdev);
> }
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 2bfe3baa63f4..782c42d25db1 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -72,9 +72,6 @@ struct vdpa_mgmt_dev;
> * struct vdpa_device - representation of a vDPA device
> * @dev: underlying device
> * @vmap: the metadata passed to upper layer to be used for mapping
> - * @driver_override: driver name to force a match; do not set directly,
> - * because core frees it; use driver_set_override() to
> - * set or clear it.
> * @config: the configuration ops for this device.
> * @map: the map ops for this device
> * @cf_lock: Protects get and set access to configuration layout.
> @@ -90,7 +87,6 @@ struct vdpa_mgmt_dev;
> struct vdpa_device {
> struct device dev;
> union virtio_map vmap;
> - const char *driver_override;
> const struct vdpa_config_ops *config;
> const struct virtio_map_ops *map;
> struct rw_semaphore cf_lock; /* Protects get/set config */
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v4 14/21] mtdchar: replace deprecated mmap hook with mmap_prepare, clean up
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:20 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d036855c21962c58ace0eb24ecd6d973d77424fe.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Replace the deprecated mmap callback with mmap_prepare.
>
> Commit f5cf8f07423b ("mtd: Disable mtdchar mmap on MMU systems") commented
> out the CONFIG_MMU part of this function back in 2012, so after ~14 years
> it's probably reasonable to remove this altogether rather than updating
> dead code.
>
> Acked-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/mtd/mtdchar.c | 21 +++------------------
> 1 file changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 55a43682c567..bf01e6ac7293 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -1376,27 +1376,12 @@ static unsigned mtdchar_mmap_capabilities(struct file *file)
> /*
> * set up a mapping for shared memory segments
> */
> -static int mtdchar_mmap(struct file *file, struct vm_area_struct *vma)
> +static int mtdchar_mmap_prepare(struct vm_area_desc *desc)
> {
> #ifdef CONFIG_MMU
> - struct mtd_file_info *mfi = file->private_data;
> - struct mtd_info *mtd = mfi->mtd;
> - struct map_info *map = mtd->priv;
> -
> - /* This is broken because it assumes the MTD device is map-based
> - and that mtd->priv is a valid struct map_info. It should be
> - replaced with something that uses the mtd_get_unmapped_area()
> - operation properly. */
> - if (0 /*mtd->type == MTD_RAM || mtd->type == MTD_ROM*/) {
> -#ifdef pgprot_noncached
> - if (file->f_flags & O_DSYNC || map->phys >= __pa(high_memory))
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> -#endif
> - return vm_iomap_memory(vma, map->phys, map->size);
> - }
> return -ENODEV;
> #else
> - return vma->vm_flags & VM_SHARED ? 0 : -EACCES;
> + return vma_desc_test(desc, VMA_SHARED_BIT) ? 0 : -EACCES;
> #endif
> }
>
> @@ -1411,7 +1396,7 @@ static const struct file_operations mtd_fops = {
> #endif
> .open = mtdchar_open,
> .release = mtdchar_close,
> - .mmap = mtdchar_mmap,
> + .mmap_prepare = mtdchar_mmap_prepare,
> #ifndef CONFIG_MMU
> .get_unmapped_area = mtdchar_get_unmapped_area,
> .mmap_capabilities = mtdchar_mmap_capabilities,
^ permalink raw reply
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Ulf Hansson @ 2026-03-25 10:22 UTC (permalink / raw)
To: Kevin Hilman (TI)
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <20260310-topic-lpm-pmdomain-child-ids-v1-2-5361687a18ff@baylibre.com>
On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
>
> Currently, PM domains can only support hierarchy for simple
> providers (e.g. ones with #power-domain-cells = 0).
>
> Add support for oncell providers as well by adding a new property
> `power-domains-child-ids` to describe the parent/child relationship.
>
> For example, an SCMI PM domain provider has multiple domains, each of
> which might be a child of diffeent parent domains. In this example,
> the parent domains are MAIN_PD and WKUP_PD:
>
> scmi_pds: protocol@11 {
> reg = <0x11>;
> #power-domain-cells = <1>;
> power-domains = <&MAIN_PD>, <&WKUP_PD>;
> power-domains-child-ids = <15>, <19>;
> };
>
> With this example using the new property, SCMI PM domain 15 becomes a
> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
> WKUP_PD.
>
> To support this feature, add two new core functions
>
> - of_genpd_add_child_ids()
> - of_genpd_remove_child_ids()
>
> which can be called by pmdomain providers to add/remove child domains
> if they support the new property power-domains-child-ids.
>
> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
Thanks for working on this! It certainly is a missing feature!
> ---
> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 16 ++++++++++++++++
> 2 files changed, 185 insertions(+)
>
> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> index 61c2277c9ce3..acb45dd540b7 100644
> --- a/drivers/pmdomain/core.c
> +++ b/drivers/pmdomain/core.c
> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
> return genpd;
> }
>
> +/**
> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
> + * @np: Device node pointer associated with the PM domain provider.
> + * @data: Pointer to the onecell data associated with the PM domain provider.
> + *
> + * Parse the power-domains and power-domains-child-ids properties to establish
> + * parent-child relationships for PM domains. The power-domains property lists
> + * parent domains, and power-domains-child-ids lists which child domain IDs
> + * should be associated with each parent.
> + *
> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
I think we should avoid returning specific error codes for specific
errors, simply because it usually becomes messy.
If I understand correctly the intent here is to allow the caller to
check for -ENOENT and potentially avoid bailing out as it may not
really be an error, right?
Perhaps a better option is to return the number of children for whom
we successfully assigned parents. Hence 0 or a positive value allows
the caller to understand what happened. More importantly, a negative
error code then really becomes an error for the caller to consider.
> + */
> +int of_genpd_add_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data)
> +{
> + struct of_phandle_args parent_args;
> + struct generic_pm_domain *parent_genpd, *child_genpd;
> + struct of_phandle_iterator it;
> + const struct property *prop;
> + const __be32 *item;
> + u32 child_id;
> + int ret;
> +
> + /* Check if both properties exist */
> + if (of_count_phandle_with_args(np, "power-domains", "#power-domain-cells") <= 0)
> + return -ENOENT;
> +
> + prop = of_find_property(np, "power-domains-child-ids", NULL);
> + if (!prop)
> + return -ENOENT;
> +
> + item = of_prop_next_u32(prop, NULL, &child_id);
Perhaps it's easier to check if of_property_count_u32_elems() returns
the same number as of_count_phandle_with_args() above? If it doesn't,
something is wrong, and there is no need to continue.
This way you also know the number of loops upfront that must iterate
through all indexes. This should allow us to use a simpler for-loop
below, I think. In this case you can also use
of_property_read_u32_index() instead.
> +
> + /* Iterate over power-domains phandles and power-domains-child-ids in lockstep */
> + of_for_each_phandle(&it, ret, np, "power-domains", "#power-domain-cells", 0) {
> + if (!item) {
> + pr_err("power-domains-child-ids shorter than power-domains for %pOF\n", np);
> + ret = -EINVAL;
> + goto err_put_node;
> + }
> +
> + /*
> + * Fill parent_args from the iterator. it.node is released by
> + * the next of_phandle_iterator_next() call at the top of the
> + * loop, or by the of_node_put() on the error path below.
> + */
> + parent_args.np = it.node;
> + parent_args.args_count = of_phandle_iterator_args(&it, parent_args.args,
> + MAX_PHANDLE_ARGS);
> +
> + /* Get the parent domain */
> + parent_genpd = genpd_get_from_provider(&parent_args);
Before getting the parent_genpd like this, we need to take the
gpd_list_lock. The lock must be held when genpd_add_subdomain() is
being called.
> + if (IS_ERR(parent_genpd)) {
> + pr_err("Failed to get parent domain for %pOF: %ld\n",
> + np, PTR_ERR(parent_genpd));
> + ret = PTR_ERR(parent_genpd);
> + goto err_put_node;
> + }
> +
> + /* Validate child ID is within bounds */
> + if (child_id >= data->num_domains) {
> + pr_err("Child ID %u out of bounds (max %u) for %pOF\n",
> + child_id, data->num_domains - 1, np);
> + ret = -EINVAL;
> + goto err_put_node;
> + }
> +
> + /* Get the child domain */
> + child_genpd = data->domains[child_id];
> + if (!child_genpd) {
> + pr_err("Child domain %u is NULL for %pOF\n", child_id, np);
> + ret = -EINVAL;
> + goto err_put_node;
> + }
> +
> + /* Establish parent-child relationship */
> + ret = genpd_add_subdomain(parent_genpd, child_genpd);
> + if (ret) {
> + pr_err("Failed to add child domain %u to parent in %pOF: %d\n",
> + child_id, np, ret);
> + goto err_put_node;
> + }
> +
> + pr_debug("Added child domain %u (%s) to parent %s for %pOF\n",
> + child_id, child_genpd->name, parent_genpd->name, np);
> +
> + item = of_prop_next_u32(prop, item, &child_id);
> + }
> +
> + /* of_for_each_phandle returns -ENOENT at natural end-of-list */
> + if (ret && ret != -ENOENT)
> + return ret;
> +
> + /* All power-domains phandles were consumed; check for trailing child IDs */
> + if (item) {
> + pr_err("power-domains-child-ids longer than power-domains for %pOF\n", np);
> + return -EINVAL;
> + }
> +
> + return 0;
> +
> +err_put_node:
This isn't a suffient error handling.
If we successfully added child domains using genpd_add_subdomain(), we
must remove them here, by calling pm_genpd_remove_subdomain() in the
reverse order as we just added them.
> + of_node_put(it.node);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_add_child_ids);
> +
> +/**
> + * of_genpd_remove_child_ids() - Remove parent-child PM domain relationships
> + * @np: Device node pointer associated with the PM domain provider.
> + * @data: Pointer to the onecell data associated with the PM domain provider.
> + *
> + * Reverses the effect of of_genpd_add_child_ids() by parsing the same
> + * power-domains and power-domains-child-ids properties and calling
> + * pm_genpd_remove_subdomain() for each established relationship.
> + *
> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error
> + * code on failure.
> + */
> +int of_genpd_remove_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data)
> +{
> + struct of_phandle_args parent_args;
> + struct generic_pm_domain *parent_genpd, *child_genpd;
> + struct of_phandle_iterator it;
> + const struct property *prop;
> + const __be32 *item;
> + u32 child_id;
> + int ret;
> +
> + /* Check if both properties exist */
> + if (of_count_phandle_with_args(np, "power-domains", "#power-domain-cells") <= 0)
> + return -ENOENT;
> +
> + prop = of_find_property(np, "power-domains-child-ids", NULL);
> + if (!prop)
> + return -ENOENT;
> +
> + item = of_prop_next_u32(prop, NULL, &child_id);
Similar comments as for of_genpd_add_child_ids().
Moreover, I think we should remove the children in the reverse order
of how we added them.
> +
> + of_for_each_phandle(&it, ret, np, "power-domains", "#power-domain-cells", 0) {
> + if (!item)
> + break;
> +
> + parent_args.np = it.node;
> + parent_args.args_count = of_phandle_iterator_args(&it, parent_args.args,
> + MAX_PHANDLE_ARGS);
> +
> + if (child_id >= data->num_domains || !data->domains[child_id]) {
> + item = of_prop_next_u32(prop, item, &child_id);
> + continue;
> + }
> +
> + parent_genpd = genpd_get_from_provider(&parent_args);
> + if (IS_ERR(parent_genpd)) {
> + item = of_prop_next_u32(prop, item, &child_id);
> + continue;
> + }
> +
> + child_genpd = data->domains[child_id];
> + pm_genpd_remove_subdomain(parent_genpd, child_genpd);
> +
> + item = of_prop_next_u32(prop, item, &child_id);
> + }
> +
> + return (ret == -ENOENT) ? 0 : ret;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_remove_child_ids);
> +
> /**
> * of_genpd_add_device() - Add a device to an I/O PM domain
> * @genpdspec: OF phandle args to use for look-up PM domain
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index f67a2cb7d781..b44615d79af6 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -465,6 +465,10 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
> int of_genpd_parse_idle_states(struct device_node *dn,
> struct genpd_power_state **states, int *n);
> void of_genpd_sync_state(struct device_node *np);
> +int of_genpd_add_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data);
> +int of_genpd_remove_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data);
>
> int genpd_dev_pm_attach(struct device *dev);
> struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> @@ -534,6 +538,18 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> {
> return ERR_PTR(-EOPNOTSUPP);
> }
> +
> +static inline int of_genpd_add_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int of_genpd_remove_child_ids(struct device_node *np,
> + struct genpd_onecell_data *data)
> +{
> + return -EOPNOTSUPP;
> +}
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
> #ifdef CONFIG_PM
>
> --
> 2.51.0
>
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v6 0/7] gpio: introduce a GPIO driver for SCMI
From: Bartosz Golaszewski @ 2026-03-25 10:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Dan Carpenter, AKASHI Takahiro, arm-scmi, Conor Dooley,
Cristian Marussi, devicetree, Krzysztof Kozlowski,
linux-arm-kernel, linux-gpio, linux-kernel, Rob Herring,
Sudeep Holla, Andy Shevchenko, Bartosz Golaszewski,
Vincent Guittot, Khaled Ali Ahmed, Michal Simek
In-Reply-To: <CAD++jL=mz5jOLkq6GA6ZWzfGfFnVOLTCoXKOd38YHj2UZaZ9ww@mail.gmail.com>
On Tue, Mar 24, 2026 at 2:11 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 8:01 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> > This basically abandons my earlier attempts and goes back to Takahiro
> > Akashi's driver. Here is the link to Takahiro's patchset:
> >
> > https://lore.kernel.org/all/20231005025843.508689-1-takahiro.akashi@linaro.org/
> >
> > v6: Fix a build error when CONFIG_PINCONF is disabled
> > Fix the dt-binding subject and my email address
> > Use pinconf_to_config_packed() instead of PIN_CONF_PACKED()
>
> v6 applied to this immutable branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-scmi-pinctrl-gpio
>
> Then merged into my devel branch for next.
>
> Bartosz, you might want to pull it in!
>
> Dan: thanks for your efforts to fix up the remaining hurdles and
> bringing this to completion! Sometimes the last few % of work are
> the hardest.
>
> Also thanks to Takahiro for this idea: it worked out just like you
> imagined.
>
Pulled, thanks!
Bart
^ permalink raw reply
* Re: [PATCH v4 15/21] stm: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:24 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <9f3d559a264a83cf45518fcf35cc7ef1d7dfd500.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Also, in order to correctly maintain reference counting, add a
> vm_ops->mapped callback to increment the reference count when successfully
> mapped.
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/hwtracing/stm/core.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index 37584e786bb5..f48c6a8a0654 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -666,6 +666,16 @@ static ssize_t stm_char_write(struct file *file, const char __user *buf,
> return count;
> }
>
> +static int stm_mmap_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct stm_file *stmf = file->private_data;
> + struct stm_device *stm = stmf->stm;
> +
> + pm_runtime_get_sync(&stm->dev);
> + return 0;
> +}
> +
> static void stm_mmap_open(struct vm_area_struct *vma)
> {
> struct stm_file *stmf = vma->vm_file->private_data;
> @@ -684,12 +694,14 @@ static void stm_mmap_close(struct vm_area_struct *vma)
> }
>
> static const struct vm_operations_struct stm_mmap_vmops = {
> + .mapped = stm_mmap_mapped,
> .open = stm_mmap_open,
> .close = stm_mmap_close,
> };
>
> -static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> +static int stm_char_mmap_prepare(struct vm_area_desc *desc)
> {
> + struct file *file = desc->file;
> struct stm_file *stmf = file->private_data;
> struct stm_device *stm = stmf->stm;
> unsigned long size, phys;
> @@ -697,10 +709,10 @@ static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> if (!stm->data->mmio_addr)
> return -EOPNOTSUPP;
>
> - if (vma->vm_pgoff)
> + if (desc->pgoff)
> return -EINVAL;
>
> - size = vma->vm_end - vma->vm_start;
> + size = vma_desc_size(desc);
>
> if (stmf->output.nr_chans * stm->data->sw_mmiosz != size)
> return -EINVAL;
> @@ -712,13 +724,12 @@ static int stm_char_mmap(struct file *file, struct vm_area_struct *vma)
> if (!phys)
> return -EINVAL;
>
> - pm_runtime_get_sync(&stm->dev);
> -
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> - vm_flags_set(vma, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
> - vma->vm_ops = &stm_mmap_vmops;
> - vm_iomap_memory(vma, phys, size);
> + desc->page_prot = pgprot_noncached(desc->page_prot);
> + vma_desc_set_flags(desc, VMA_IO_BIT, VMA_DONTEXPAND_BIT,
> + VMA_DONTDUMP_BIT);
> + desc->vm_ops = &stm_mmap_vmops;
>
> + mmap_action_simple_ioremap(desc, phys, size);
> return 0;
> }
>
> @@ -836,7 +847,7 @@ static const struct file_operations stm_fops = {
> .open = stm_char_open,
> .release = stm_char_release,
> .write = stm_char_write,
> - .mmap = stm_char_mmap,
> + .mmap_prepare = stm_char_mmap_prepare,
> .unlocked_ioctl = stm_char_ioctl,
> .compat_ioctl = compat_ptr_ioctl,
> };
^ permalink raw reply
* [PATCH v3 0/2] media: synopsys: csi2rx: add support for rk3588 variant
From: Michael Riesch via B4 Relay @ 2026-03-25 10:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Kever Yang, Collabora Kernel Team
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
Habidere,
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0
- MIPI1: connected to MIPI DCPHY1
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (only with split DPHY0)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (only with split DPHY1)
The MIPI DCPHYs (at least the CSI-2 features of them) as well
as the split DPHY mode of the DPHYs are not yet supported by
mainline. However, we can already provide support for the
MIPI2 and MIPI4 units.
When support for the split DPHY mode is introduced, the DPHY
nodes should have the property
#phy-cells = <1>;
and the MIPI CSI-2 receiver nodes should have the property
phys = <&csi_dphy{0,1} {0,1}>;
in case the split mode is desired. Since this is a board
specific hardware design, the properties need to be changed
in the board device tree (or any overlays).
As reasonable default, however, we can define, e.g.,
#phy-cells = <0>;
and
phys = <&csi_dphy{0,1}>;
in the SoC device tree include.
This series introduces initial support for this default
configuration.
Looking forward to your comments!
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
Changes in v3:
- rebased onto Sakari's cleanup branch (as Frank's patches were
merged) (Sakari)
- added Rob's Acked-by
- Link to v2: https://lore.kernel.org/r/20260305-rk3588-csi2rx-v2-0-79d01b615486@collabora.com
Changes in v2:
- use fallback compatible instead of separate compatible (Krzysztof)
- dropped patch 2 and 4 (as a consequence thereof)
- Link to v1: https://lore.kernel.org/r/20260305-rk3588-csi2rx-v1-0-0cd8d2bf28c0@collabora.com
---
Michael Riesch (2):
media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++--
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 52 ++++++++++++++++++++++
2 files changed, 59 insertions(+), 3 deletions(-)
---
base-commit: 66bd47face7d5d55e6c3b5dc16fb3c2d6e205360
change-id: 20260305-rk3588-csi2rx-a11f7c15a40a
Best regards,
--
Michael Riesch <michael.riesch@collabora.com>
^ permalink raw reply
* [PATCH v3 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Michael Riesch via B4 Relay @ 2026-03-25 10:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Kever Yang, Collabora Kernel Team
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20260305-rk3588-csi2rx-v3-0-754473981f39@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
the RK3568.
Introduce a list of compatible variants and add the RK3588 variant to
it.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
.../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
index 4ac4a3b6f406..3d3b3cd78884 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
@@ -16,9 +16,13 @@ description:
properties:
compatible:
- enum:
- - fsl,imx93-mipi-csi2
- - rockchip,rk3568-mipi-csi2
+ oneOf:
+ - const: fsl,imx93-mipi-csi2
+ - const: rockchip,rk3568-mipi-csi2
+ - items:
+ - enum:
+ - rockchip,rk3588-mipi-csi2
+ - const: rockchip,rk3568-mipi-csi2
reg:
maxItems: 1
--
2.39.5
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
From: Michael Riesch via B4 Relay @ 2026-03-25 10:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Kever Yang, Collabora Kernel Team
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20260305-rk3588-csi2rx-v3-0-754473981f39@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0 (not supported)
- MIPI1: connected to MIPI DCPHY1 (not supported)
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (not supported)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (not supported)
As the MIPI DCPHYs as well as the split DPHY mode of the DPHYs
are not yet supported, add only the device tree nodes for the
MIPI2 and MIPI4 units.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 52 +++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 7fe9593d8c19..6c593b0255c3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1430,6 +1430,58 @@ av1d: video-codec@fdc70000 {
resets = <&cru SRST_A_AV1>, <&cru SRST_P_AV1>, <&cru SRST_A_AV1_BIU>, <&cru SRST_P_AV1_BIU>;
};
+ csi2: csi@fdd30000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd30000 0x0 0x10000>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_2>;
+ phys = <&csi_dphy0>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_2>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ csi2_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ csi4: csi@fdd50000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd50000 0x0 0x10000>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_4>;
+ phys = <&csi_dphy1>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_4>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi4_in: port@0 {
+ reg = <0>;
+ };
+
+ csi4_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
vop: vop@fdd90000 {
compatible = "rockchip,rk3588-vop";
reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: Arnd Bergmann @ 2026-03-25 10:30 UTC (permalink / raw)
To: aspeedyh, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB4276B5BE3B96C18E3A66AD709049A@KL1PR0601MB4276.apcprd06.prod.outlook.com>
On Wed, Mar 25, 2026, at 09:41, YH Chung wrote:
>> On Tue, Mar 17, 2026, at 09:14, YH Chung wrote:
>> From reading the old comments that Andrew linked to at
>>
>> https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91
>> D49@HK0PR06MB3779.apcprd06.prod.outlook.com/
>>
>> I understand that the SoC has a "hardware mode" in which eSPI is
>> directly implemented by redirecting upper-level eSPI transactions into
>> functional blocks of the chip, while the software mode behaves like
>> a regular SPI endpoint controller and your driver implements the
>> same interfaces in a mix of kernel and userspace components. Can you
>> confirm that this is a correct understanding of what the hardware
>> does, or where I misunderstand parts?
>
> Broadly yes, except that the AST2600 does not operate in a single global
> "hardware mode" or "software mode". Instead, some backends in the eSPI target
> controller support per-function HW/SW mode selection.
>
> Depending on that function-specific setting, the controller either forwards a
> received transaction directly to the corresponding hardware block or traps it
> for software handling instead.
>
> This mechanism exists because some backend blocks include their own hardware
> filtering, but not all request types could be validated generically in
> hardware. For example, the LPC bridge can reject illegal requests. In some
> cases, blindly forwarding host requests to the target block would also have
> security implications.
>
> The channel/backend mapping on AST2600 can be summarized as:
>
> eSPI
> ├── Peripheral
> │ ├── Memory (HW mode only)
> │ └── LPC bridge (HW mode only)
> ├── Virtual Wire
> │ └── GPIO (HW/SW mode selection)
> ├── Out-of-Band (SW mode only)
> └── Flash
> └── Storage controller (HW/SW mode selection)
>
> From the link thread, what Jeremy mentioned is the GPIO HW/SW mode for CH1,
> which determines whether the host can directly control the corresponding BMC
> GPIO output, or whether BMC software can inspect and decide whether to act on
> that request.
>
> Another example is the Target Attached Flash Sharing (TAFS) defined by the
> eSPI specification that allows BMC to share its storage with the host.
>
> In hardware mode, the eSPI Target Device controller routes the request
> directly to a predefined storage controller on AST2600.
> In software mode, it raises an interrupt and lets software handle the
> transaction instead.
>
> So I would not describe the AST2600 eSPI block as being globally in either
> "hardware mode" or "software mode".
> That choice is made per backend function, and some backend functions do not
> implement such a switch at all.
I see, thanks for the detailed explanation! Two follow-up questions:
- For the HW-mode-only peripherals (memory, LPC), is there any
driver interaction at all for setting it up, or is this completely
transparent to Linux running on the BMC?
- For the other devices running in SW mode, is the interface that the
driver sees abstract in the sense that the same low-level code
is shared for all of them, or are these still separate functional
blocks that each need their own register-level interface?
>> For the higher-level interfaces (flash, gpio, ...), I don't think
>> there is any consensus yet about how this should be done, but again
>> I think this won't be drivers/soc but instead something more
>> generic.
>
> For the flash-related interface, would it make sense to follow the
> configuration model used by the USB gadget mass-storage function, and expose
> the backing storage selection through configfs?
>
> For the attributes, perhaps the only backing storage object and read-only
> flag would be required in our case.
>
> For the Virtual Wire GPIO, we think GPIO subsystem may be leveraged here,
> though some corner cases may not map cleanly to a typical GPIO controller
> model.
>
> For the Out-of-band channel, since the eSPI spec models it for tunneled SMBus
> packets, we may want to integrate it with the kernel's MCTP stack if that is
> a suitable fit.
These all seem to be viable options, but I still think we should
focus on agreeing on a design for the low-level hardware interface
and whether this can or should be abstracted between SoC vendor
specific drivers before trying to solve the user interface side.
Arnd
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Bartosz Golaszewski @ 2026-03-25 10:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, linux-kernel, linux-riscv,
spacemit, linux-arm-kernel, linux-mediatek, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260325100144.1696731-1-arnd@kernel.org>
On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> A number of GPIO drivers that used to have a CONFIG_OF_GPIO dependency now fail
> to build on targets without CONFIG_OF:
>
> WARNING: unmet direct dependencies detected for GPIO_SYSCON
> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
> Selected by [y]:
> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
>
> drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe':
> drivers/gpio/gpio-mt7621.c:254:20: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
> 254 | rg->chip.gc.of_gpio_n_cells = 2;
> | ^
> drivers/gpio/gpio-tegra186.c: In function 'tegra186_gpio_of_xlate':
> drivers/gpio/gpio-tegra186.c:502:25: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
> 502 | if (WARN_ON(chip->of_gpio_n_cells < 2))
> | ^~
> drivers/gpio/gpio-lpc32xx.c: In function 'lpc32xx_gpio_probe':
> drivers/gpio/gpio-lpc32xx.c:523:49: error: 'struct gpio_chip' has no member named 'of_xlate'
> 523 | lpc32xx_gpiochip[i].chip.of_xlate = lpc32xx_of_xlate;
> | ^
> drivers/gpio/gpio-spacemit-k1.c: In function 'spacemit_gpio_add_bank':
> drivers/gpio/gpio-spacemit-k1.c:234:11: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
> 234 | gc->of_gpio_n_cells = 3;
> | ^~
>
> Bring that back as a dependency.
>
> Fixes: 7803501e5754 ("gpio: drop unneeded Kconfig dependencies on OF_GPIO")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> There may be more fallout from the change, this is just what I found immediately,
> but you could already fold the changes into the broken patch while I look
> for additional ones.
> ---
Thanks and sorry for the breakage. However, I'm wondering if it wouldn't make
sense to do the following:
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 17511434ed077..ce0e0df68dbaa 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -473,7 +473,6 @@ struct gpio_chip {
struct gpio_irq_chip irq;
#endif /* CONFIG_GPIOLIB_IRQCHIP */
-#if defined(CONFIG_OF_GPIO)
/*
* If CONFIG_OF_GPIO is enabled, then all GPIO controllers described in
* the device tree automatically may have an OF translation
@@ -516,7 +515,6 @@ struct gpio_chip {
*/
int (*of_xlate)(struct gpio_chip *gc,
const struct of_phandle_args *gpiospec, u32 *flags);
-#endif /* CONFIG_OF_GPIO */
};
char *gpiochip_dup_line_label(struct gpio_chip *gc, unsigned int offset);
Symbols from linux/of.h are stubbed out and these drivers can build just fine
with !CONFIG_OF. This would naturally increase the build coverage.
Bartosz
^ permalink raw reply related
* Re: [PATCH v3 3/7] pinctrl: pinctrl-generic: add __pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-25 10:33 UTC (permalink / raw)
To: Frank Li
Cc: Linus Walleij, Peter Rosin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <acLxCnz3qYfAC3iB@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]
On Tue, Mar 24, 2026 at 04:16:10PM -0400, Frank Li wrote:
> On Fri, Mar 20, 2026 at 09:54:45AM -0400, Frank Li wrote:
> > On Fri, Mar 20, 2026 at 02:27:21PM +0100, Linus Walleij wrote:
> > > On Thu, Mar 19, 2026 at 12:04 AM Frank Li <Frank.li@nxp.com> wrote:
> > > > On Mon, Mar 16, 2026 at 10:37:28AM +0100, Linus Walleij wrote:
> > >
> > > > > That said: in this case you're just adding a parameter, just add
> > > > > the parameter and change all of the in-tree users to pass false
> > > > > or whatever you need, these is just one (1) in-tree user anyway.
> > > >
> > > > pinctrl_generic_pins_function_dt_node_to_map() directly feed to
> > > > .dt_node_to_map() callback, add parameter will impact too much.
> > >
> > > Why do you say that. It already has many parameters, one more
> > > or less doesn't matter. It's not like this call is performance-critical.
> > > Just change the users.
> >
> > In only user drivers/pinctrl/microchip/pinctrl-mpfs-mssio.c,
> > .dt_node_to_map = pinctrl_generic_pins_function_dt_node_to_map;
> >
> > pinctrl_generic_pins_function_dt_node_to_map() need match .dt_node_to_map()'s
> > declear.
> >
> > So it can't direct add two parameters in pinctrl_generic_pins_function_dt_node_to_map()
> > Need simple wrap function, which other in pinctrl-mpfs-mssio.c or in
> > pinconf.h.
> >
> > If add two parameter in .dt_node_to_map(), need change all functions, which
> > .dt_node_to_map = xxx_to_map(). and OF core part.
>
> Linus Walleij:
> Is my explain clear enough? I am preparing respin it?
>
> is okay use wrap function
> pinctrl_generic_pins_function_dt_node_to_map_ext()?
I don't understand this patch. The function is called
pinctrl_generic_pins_function_dt_node_to_map(). You have no pins.
You're adding a parameter to make a function with *pins* in its name not
use pins. The new function doesn't use pins but has pins in the name.
At the very least function names should not be misleading.
I was going to suggest pulling out the relevant portions and creating
some helpers that could be used by multiple different-but-similar
functions, but I don't actually even think that there's much in common.
Most damningly I think, you don't actually read either the functions or
pins properties at all and neither are permitted by your binding.
So turns out you use neither pins or functions...
You don't actually have any of these properties which runs counter to the
goal of the function, which is parsing. With this in mind, it feels to me
like you're trying way too hard to make use of a generic function when the
right thing to do is probably just have an entirely custom function.
Maybe that's a custom implementation in your driver, or a new function
here, but I think writing that will highlight just how little of the
code would be shared between the existing function and what your
use-case needs: no pin configuration stuff, no reading of the devicetree
other than the node names and no dealing with the label pointing to the
"wrong" place.
I recently bought a spacemit k1 board to go and write a sister function
to pinctrl_generic_pins_function_dt_node_to_map() that deals with pins
and groups (because that's a pretty common pattern).
I would be calling that pinctrl_generic_pinmux_dt_node_to_map(),
because it that's the property it deals with. I have honestly got no
idea what to call one for this situation since you don't have any of the
properties in pinmux-node.yaml. Maybe that's a sign.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 16/21] staging: vme_user: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 10:34 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <08ecc1e1d319564fd49b9e9012f994edaff921db.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update driver to use its
> successor, mmap_prepare.
>
> The driver previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Functions that wrap mmap() are also converted to wrap mmap_prepare()
> instead.
>
> Also update the documentation accordingly.
>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Arnd Bergmann @ 2026-03-25 10:41 UTC (permalink / raw)
To: Bartosz Golaszewski, Arnd Bergmann
Cc: Yixun Lan, Matthias Brugger, AngeloGioacchino Del Regno,
open list:GPIO SUBSYSTEM, linux-kernel, linux-riscv, spacemit,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <CAMRc=Mdwu85gghDjQEu4eP2HZxHjBFpph07q9SOfAifSDMtpVw@mail.gmail.com>
On Wed, Mar 25, 2026, at 11:32, Bartosz Golaszewski wrote:
> On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann <arnd@kernel.org> said:
>>
>> WARNING: unmet direct dependencies detected for GPIO_SYSCON
>> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
>> Selected by [y]:
>> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
>>
>
> Thanks and sorry for the breakage. However, I'm wondering if it wouldn't make
> sense to do the following:
>
>
> -#if defined(CONFIG_OF_GPIO)
> /*
> * If CONFIG_OF_GPIO is enabled, then all GPIO controllers described in
> * the device tree automatically may have an OF translation
...
> Symbols from linux/of.h are stubbed out and these drivers can build just fine
> with !CONFIG_OF. This would naturally increase the build coverage.
I don't think we need to worry about the build coverage here, CONFIG_OF
is still included in x86 allmodconfig and half the randconfig builds,
so the drivers get enough exposure either way.
On the other hand, dropping the build time check may help avoid
future Kconfig dependency issues, so that still sounds like a
reasonable suggestion. At least CONFIG_GPIO_SAMA5D2_PIOBU
is going to need the 'depends on OF' regardless though to work
around the other build error I cited above.
Arnd
^ permalink raw reply
* Re: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600 new register set
From: kernel test robot @ 2026-03-25 10:48 UTC (permalink / raw)
To: Ryan Chen, jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel
Cc: oe-kbuild-all, linux-i2c, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, openbmc, Ryan Chen
In-Reply-To: <20260324-upstream_i2c-v27-3-f19b511c8c28@aspeedtech.com>
Hi Ryan,
kernel test robot noticed the following build errors:
[auto build test ERROR on 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f]
url: https://github.com/intel-lab-lkp/linux/commits/Ryan-Chen/dt-bindings-i2c-Split-AST2600-binding-into-a-new-YAML/20260325-112805
base: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
patch link: https://lore.kernel.org/r/20260324-upstream_i2c-v27-3-f19b511c8c28%40aspeedtech.com
patch subject: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600 new register set
config: sparc-randconfig-r073-20260325 (https://download.01.org/0day-ci/archive/20260325/202603251835.KJc3nKCn-lkp@intel.com/config)
compiler: sparc-linux-gcc (GCC) 8.5.0
smatch: v0.5.0-9004-gb810ac53
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260325/202603251835.KJc3nKCn-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603251835.KJc3nKCn-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/i2c/busses/i2c-ast2600.c: In function 'ast2600_i2c_probe':
>> drivers/i2c/busses/i2c-ast2600.c:955:15: error: 'struct ast2600_i2c_bus' has no member named 'dma_abailable'; did you mean 'dma_available'?
if (i2c_bus->dma_abailable)
^~~~~~~~~~~~~
dma_available
vim +955 drivers/i2c/busses/i2c-ast2600.c
916
917 static int ast2600_i2c_probe(struct platform_device *pdev)
918 {
919 struct device *dev = &pdev->dev;
920 struct ast2600_i2c_bus *i2c_bus;
921 struct reset_control *rst;
922 struct resource *res;
923 u32 global_ctrl;
924 int ret;
925
926 if (!device_property_present(dev, "aspeed,global-regs"))
927 return -ENODEV;
928
929 i2c_bus = devm_kzalloc(dev, sizeof(*i2c_bus), GFP_KERNEL);
930 if (!i2c_bus)
931 return -ENOMEM;
932
933 i2c_bus->reg_base = devm_platform_ioremap_resource(pdev, 0);
934 if (IS_ERR(i2c_bus->reg_base))
935 return PTR_ERR(i2c_bus->reg_base);
936
937 rst = devm_reset_control_get_shared_deasserted(dev, NULL);
938 if (IS_ERR(rst))
939 return dev_err_probe(dev, PTR_ERR(rst), "Missing reset ctrl\n");
940
941 i2c_bus->global_regs =
942 syscon_regmap_lookup_by_phandle(dev_of_node(dev), "aspeed,global-regs");
943 if (IS_ERR(i2c_bus->global_regs))
944 return PTR_ERR(i2c_bus->global_regs);
945
946 regmap_read(i2c_bus->global_regs, AST2600_I2CG_CTRL, &global_ctrl);
947 if ((global_ctrl & AST2600_GLOBAL_INIT) != AST2600_GLOBAL_INIT) {
948 regmap_write(i2c_bus->global_regs, AST2600_I2CG_CTRL, AST2600_GLOBAL_INIT);
949 regmap_write(i2c_bus->global_regs, AST2600_I2CG_CLK_DIV_CTRL, I2CCG_DIV_CTRL);
950 }
951
952 i2c_bus->dev = dev;
953 i2c_bus->multi_master = device_property_read_bool(dev, "multi-master");
954 i2c_bus->dma_available = device_property_read_bool(dev, "aspeed,enable-dma");
> 955 if (i2c_bus->dma_abailable)
956 i2c_bus->mode = DMA_MODE;
957 else
958 i2c_bus->mode = BUFF_MODE;
959
960 if (i2c_bus->mode == BUFF_MODE) {
961 i2c_bus->buf_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
962 if (IS_ERR(i2c_bus->buf_base))
963 i2c_bus->mode = BYTE_MODE;
964 else
965 i2c_bus->buf_size = resource_size(res) / 2;
966 }
967
968 ast2600_i2c_set_xfer_mode(i2c_bus, i2c_bus->mode);
969
970 /*
971 * i2c timeout counter: use base clk4 1Mhz,
972 * per unit: 1/(1000/1024) = 1024us
973 */
974 ret = device_property_read_u32(dev, "i2c-scl-clk-low-timeout-us", &i2c_bus->timeout);
975 if (!ret)
976 i2c_bus->timeout = DIV_ROUND_UP(i2c_bus->timeout, 1024);
977
978 init_completion(&i2c_bus->cmd_complete);
979
980 i2c_bus->irq = platform_get_irq(pdev, 0);
981 if (i2c_bus->irq < 0)
982 return i2c_bus->irq;
983
984 platform_set_drvdata(pdev, i2c_bus);
985
986 i2c_bus->clk = devm_clk_get(i2c_bus->dev, NULL);
987 if (IS_ERR(i2c_bus->clk))
988 return dev_err_probe(i2c_bus->dev, PTR_ERR(i2c_bus->clk), "Can't get clock\n");
989
990 i2c_bus->apb_clk = clk_get_rate(i2c_bus->clk);
991
992 i2c_parse_fw_timings(i2c_bus->dev, &i2c_bus->timing_info, true);
993
994 /* Initialize the I2C adapter */
995 i2c_bus->adap.owner = THIS_MODULE;
996 i2c_bus->adap.algo = &i2c_ast2600_algorithm;
997 i2c_bus->adap.retries = 0;
998 i2c_bus->adap.dev.parent = i2c_bus->dev;
999 device_set_node(&i2c_bus->adap.dev, dev_fwnode(dev));
1000 i2c_bus->adap.algo_data = i2c_bus;
1001 strscpy(i2c_bus->adap.name, pdev->name);
1002 i2c_set_adapdata(&i2c_bus->adap, i2c_bus);
1003
1004 ret = ast2600_i2c_init(i2c_bus);
1005 if (ret < 0)
1006 return dev_err_probe(dev, ret, "Unable to initial i2c %d\n", ret);
1007
1008 ret = devm_request_irq(dev, i2c_bus->irq, ast2600_i2c_bus_irq, 0,
1009 dev_name(dev), i2c_bus);
1010 if (ret < 0) {
1011 ret = dev_err_probe(dev, ret, "Unable to request irq %d\n",
1012 i2c_bus->irq);
1013 goto err;
1014 }
1015
1016 writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER,
1017 i2c_bus->reg_base + AST2600_I2CM_IER);
1018
1019 ret = devm_i2c_add_adapter(dev, &i2c_bus->adap);
1020 if (ret)
1021 goto err;
1022
1023 ret = sysfs_create_file(&dev->kobj, &dev_attr_xfer_mode.attr);
1024 if (ret)
1025 goto err;
1026
1027 return 0;
1028
1029 err:
1030 writel(0, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
1031 writel(0, i2c_bus->reg_base + AST2600_I2CM_IER);
1032 return ret;
1033 }
1034
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Sherry Sun @ 2026-03-25 11:00 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
Note: This patch set depends on my previous patch set [1] which adds
Root Port device tree nodes and support parsing the reset property in
new Root Port binding in pci-imx6 driver.
This series integrates the PCI pwrctrl framework into the pci-imx6
driver and updates i.MX EVK board device trees to support it.
Patches 2-8 update device trees for i.MX EVK boards which maintained
by NXP to move power supply properties from the PCIe controller node
to the Root Port child node, which is required for pwrctrl framework.
Affected boards:
- i.MX6Q/DL SABRESD
- i.MX6SX SDB
- i.MX8MM EVK
- i.MX8MP EVK
- i.MX8MQ EVK
- i.MX8DXL/QM/QXP EVK
- i.MX95 15x15/19x19 EVK
The driver maintains legacy regulator handling for device trees that
haven't been updated yet. Both old and new device tree structures are
supported.
[1] https://lore.kernel.org/all/20260318062916.2747472-1-sherry.sun@nxp.com/
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
Sherry Sun (8):
PCI: imx6: Integrate new pwrctrl API for pci-imx6
arm: dts: imx6qdl-sabresd: Move power supply property to Root Port
node
arm: dts: imx6sx-sdb: Move power supply property to Root Port node
arm64: dts: imx8mm-evk: Move power supply property to Root Port node
arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port
node
arm64: dts: imx95: Move power supply properties to Root Port node
.../arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++--
.../boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
.../boot/dts/freescale/imx95-19x19-evk.dts | 8 +++----
drivers/pci/controller/dwc/Kconfig | 1 +
drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++++-
12 files changed, 42 insertions(+), 20 deletions(-)
--
2.37.1
^ permalink raw reply
* [PATCH 1/8] PCI: imx6: Integrate new pwrctrl API for pci-imx6
From: Sherry Sun @ 2026-03-25 11:00 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325110058.2854742-1-sherry.sun@nxp.com>
Integrate the PCI pwrctrl framework into the pci-imx6 driver to provide
standardized power management for PCIe devices.
Legacy regulator handling (vpcie-supply at controller level) is
maintained for backward compatibility with existing device trees.
New device trees should specify power supplies at the Root Port
level to utilize the pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/dwc/Kconfig | 1 +
drivers/pci/controller/dwc/pci-imx6.c | 23 ++++++++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index f2fde13107f2..327b0dc65550 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -114,6 +114,7 @@ config PCI_IMX6_HOST
depends on PCI_MSI
select PCIE_DW_HOST
select PCI_IMX6
+ select PCI_PWRCTRL_GENERIC
help
Enables support for the PCIe controller in the i.MX SoCs to
work in Root Complex mode. The PCI controller on i.MX is based
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 77483f44c593..b9d72793f266 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/pci.h>
+#include <linux/pci-pwrctrl.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
@@ -1314,6 +1315,7 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
return ret;
}
+ /* Legacy regulator handling for DT backward compatibility. */
if (imx_pcie->vpcie) {
ret = regulator_enable(imx_pcie->vpcie);
if (ret) {
@@ -1323,10 +1325,22 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
}
}
+ ret = pci_pwrctrl_create_devices(dev);
+ if (ret) {
+ dev_err(dev, "failed to create pwrctrl devices\n");
+ goto err_reg_disable;
+ }
+
+ ret = pci_pwrctrl_power_on_devices(dev);
+ if (ret) {
+ dev_err(dev, "failed to power on pwrctrl devices\n");
+ goto err_pwrctrl_destroy;
+ }
+
ret = imx_pcie_clk_enable(imx_pcie);
if (ret) {
dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
- goto err_reg_disable;
+ goto err_pwrctrl_power_off;
}
if (pp->bridge && imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT)) {
@@ -1385,6 +1399,11 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
phy_exit(imx_pcie->phy);
err_clk_disable:
imx_pcie_clk_disable(imx_pcie);
+err_pwrctrl_power_off:
+ pci_pwrctrl_power_off_devices(dev);
+err_pwrctrl_destroy:
+ if (ret != -EPROBE_DEFER)
+ pci_pwrctrl_destroy_devices(dev);
err_reg_disable:
if (imx_pcie->vpcie)
regulator_disable(imx_pcie->vpcie);
@@ -1403,6 +1422,7 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
}
imx_pcie_clk_disable(imx_pcie);
+ pci_pwrctrl_power_off_devices(pci->dev);
if (imx_pcie->vpcie)
regulator_disable(imx_pcie->vpcie);
}
@@ -1911,6 +1931,7 @@ static void imx_pcie_shutdown(struct platform_device *pdev)
/* bring down link, so bootloader gets clean state in case of reboot */
imx_pcie_assert_core_reset(imx_pcie);
imx_pcie_assert_perst(imx_pcie, true);
+ pci_pwrctrl_destroy_devices(&pdev->dev);
}
static const struct imx_pcie_drvdata drvdata[] = {
--
2.37.1
^ permalink raw reply related
* [PATCH 2/8] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
From: Sherry Sun @ 2026-03-25 11:00 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325110058.2854742-1-sherry.sun@nxp.com>
Move the vpcie-supply property from the PCIe controller node to the Root
Port child node to support the new PCI pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
index fe9046c03ddd..e52205d7c487 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi
@@ -756,12 +756,12 @@ &pcie {
pinctrl-0 = <&pinctrl_pcie>;
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcie>;
status = "okay";
};
&pcie_port0 {
reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie>;
};
&pwm1 {
--
2.37.1
^ permalink raw reply related
* [PATCH 3/8] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
From: Sherry Sun @ 2026-03-25 11:00 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325110058.2854742-1-sherry.sun@nxp.com>
Move the vpcie-supply property from the PCIe controller node to the Root
Port child node to support the new PCI pwrctrl framework.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
index 338de4d144b2..7633ba2139d3 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
@@ -284,12 +284,12 @@ &pcie {
pinctrl-0 = <&pinctrl_pcie>;
/* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&gpio2 0 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcie_gpio>;
status = "okay";
};
&pcie_port0 {
reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie_gpio>;
};
&lcdif1 {
--
2.37.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