Re: [PATCH v3] ASoC: fsl: Rename stream name of SAI DAI driver
On Mon, Feb 17, 2025 at 9:05 AM Chancel Liu wrote:
>
> If stream names of DAI driver are duplicated there'll be warnings when
> machine driver tries to add widgets on a route:
>
> [8.831335] fsl-asoc-card sound-wm8960: ASoC: sink widget CPU-Playback
> overwritten
> [8.839917] fsl-asoc-card sound-wm8960: ASoC: source widget CPU-Capture
> overwritten
>
> Use different stream names to avoid such warnings.
> DAI names in AUDMIX are also updated accordingly.
>
> Fixes: 15c958390460 ("ASoC: fsl_sai: Add separate DAI for transmitter and
> receiver")
> Signed-off-by: Chancel Liu
Acked-by: Shengjiu Wang
Best regards
Shengjiu Wang
> ---
> - changes in v3
> Squash two fix patches in one commit
>
> sound/soc/fsl/fsl_sai.c| 6 +++---
> sound/soc/fsl/imx-audmix.c | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index c4eb87c5d39e..9f33dd11d47f 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -994,10 +994,10 @@ static struct snd_soc_dai_driver fsl_sai_dai_template[]
> = {
> {
> .name = "sai-tx",
> .playback = {
> - .stream_name = "CPU-Playback",
> + .stream_name = "SAI-Playback",
> .channels_min = 1,
> .channels_max = 32,
> - .rate_min = 8000,
> + .rate_min = 8000,
> .rate_max = 2822400,
> .rates = SNDRV_PCM_RATE_KNOT,
> .formats = FSL_SAI_FORMATS,
> @@ -1007,7 +1007,7 @@ static struct snd_soc_dai_driver fsl_sai_dai_template[]
> = {
> {
> .name = "sai-rx",
> .capture = {
> - .stream_name = "CPU-Capture",
> + .stream_name = "SAI-Capture",
> .channels_min = 1,
> .channels_max = 32,
> .rate_min = 8000,
> diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
> index 50ecc5f51100..dac5d4ddacd6 100644
> --- a/sound/soc/fsl/imx-audmix.c
> +++ b/sound/soc/fsl/imx-audmix.c
> @@ -119,8 +119,8 @@ static const struct snd_soc_ops imx_audmix_be_ops = {
> static const char *name[][3] = {
> {"HiFi-AUDMIX-FE-0", "HiFi-AUDMIX-FE-1", "HiFi-AUDMIX-FE-2"},
> {"sai-tx", "sai-tx", "sai-rx"},
> - {"AUDMIX-Playback-0", "AUDMIX-Playback-1", "CPU-Capture"},
> - {"CPU-Playback", "CPU-Playback", "AUDMIX-Capture-0"},
> + {"AUDMIX-Playback-0", "AUDMIX-Playback-1", "SAI-Capture"},
> + {"SAI-Playback", "SAI-Playback", "AUDMIX-Capture-0"},
> };
>
> static int imx_audmix_probe(struct platform_device *pdev)
> --
> 2.47.1
>
Re: [PATCH v8 19/20] fs/dax: Properly refcount fs dax pages
-static inline unsigned long dax_folio_share_put(struct folio *folio)
+static inline unsigned long dax_folio_put(struct folio *folio)
{
- return --folio->page.share;
+ unsigned long ref;
+ int order, i;
+
+ if (!dax_folio_is_shared(folio))
+ ref = 0;
+ else
+ ref = --folio->share;
+
out of interest, what synchronizes access to folio->share?
Actually that's an excellent question as I hadn't looked too closely at this
given I wasn't changing the overall flow with regards to synchronization, merely
representation of the "shared" state. So I don't have a good answer for you off
the top of my head - Dan maybe you can shed some light here?
Not that I understand what that dax-shared thing is or does, but the
non-atomic update on a folio_put path looked "surprising".
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 2333c30..dcc9fcd 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -209,7 +209,7 @@ int dax_truncate_page(struct inode *inode, loff_t pos, bool
*did_zero,
[...]
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d189826..1a0d6a8 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2225,7 +2225,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
vm_area_struct *vma,
tlb->fullmm);
arch_check_zapped_pmd(vma, orig_pmd);
tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
- if (vma_is_special_huge(vma)) {
+ if (!vma_is_dax(vma) && vma_is_special_huge(vma)) {
I wonder if we actually want to remove the vma_is_dax() check from
vma_is_special_huge(), and instead add it to the remaining callers of
vma_is_special_huge() that still need it -- if any need it.
Did we sanity-check which callers of vma_is_special_huge() still need it? Is
there still reason to have that DAX check in vma_is_special_huge()?
If by "we" you mean "me" then yes :) There are still a few callers of it, mainly
for page splitting.
Heh, "you or any of the reviewers" :)
So IIUC, the existing users still need the DAX check I assume (until
that part is cleaned up, below).
But vma_is_special_huge() is rather confusing from me ... the whole
vma_is_special_huge() thing should probably be removed. That's a cleanup for
another day, though.
But after double checking I have come to the same conclusion as you - it should
be removed. I will add that to my ever growing clean-up series that can go on
top of this one.
Nice!
--
Cheers,
David / dhildenb
Re: [RFC PATCH v2 1/3] sched/fair: introduce new scheduler group type group_parked
On 18/02/2025 06:44, Shrikanth Hegde wrote:
[...]
@@ -1352,6 +1352,9 @@ bool sched_can_stop_tick(struct rq *rq)
if (rq->cfs.h_nr_queued > 1)
return false;
+ if (rq->cfs.nr_running > 0 && arch_cpu_parked(cpu_of(rq)))
+ return false;
+
you mean rq->cfs.h_nr_queued or rq->nr_running ?
cfs.h_nr_queued is probably more sensible, will use that.
[...]
@@ -11259,6 +11293,8 @@ static inline void calculate_imbalance(struct
lb_env *env, struct sd_lb_stats *s
* avg_load : Only if imbalance is significant enough.
* nr_idle : dst_cpu is not busy and the number of idle CPUs is quite
* different in groups.
+ * nr_task : balancing can go either way depending on the number of
running tasks
+ * per group
*/
This comment on nr_task can be removed as it is not present in the list.
Consider it gone.
[...]
@@ -11766,7 +11822,7 @@ static int sched_balance_rq(int this_cpu,
struct rq *this_rq,
ld_moved = 0;
/* Clear this flag as soon as we find a pullable task */
env.flags |= LBF_ALL_PINNED;
- if (busiest->nr_running > 1) {
+ if (busiest->nr_running > 1 || arch_cpu_parked(busiest->cpu)) {
Since there is reliance on active balance if there is single task, it
think above isn't needed. Is there any usecase for it?
Seems to work without that check. I have no particular use case in mind.
/*
* Attempt to move tasks. If sched_balance_find_src_group
has found
* an imbalance but busiest->nr_running <= 1, the group is
@@ -12356,6 +12412,11 @@ static void nohz_balancer_kick(struct rq *rq)
if (time_before(now, nohz.next_balance))
goto out;
+ if (!idle_cpu(rq->cpu)) {
+ flags = NOHZ_STATS_KICK | NOHZ_BALANCE_KICK;
+ goto out;
+ }
+
This could be agrressive. Note when the code comes here, it is not idle.
It would bail out early if it is idle.
It seems like we can do without this one as well.
if (rq->nr_running >= 2) {
flags = NOHZ_STATS_KICK | NOHZ_BALANCE_KICK;
goto out;
@@ -12767,6 +12828,9 @@ static int sched_balance_newidle(struct rq
*this_rq, struct rq_flags *rf)
update_misfit_status(NULL, this_rq);
+ if (arch_cpu_parked(this_cpu))
+ return 0;
+
/*
* There is a task waiting to run. No need to search for one.
* Return 0; the task will be enqueued when switching to idle.
diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
index 456d339be98f..7efd76a30be7 100644
--- a/kernel/sched/syscalls.c
+++ b/kernel/sched/syscalls.c
@@ -214,6 +214,9 @@ int idle_cpu(int cpu)
return 0;
#endif
+ if (arch_cpu_parked(cpu))
+ return 0;
+
return 1;
}
Re: [RFC PATCH v2 0/3] sched/fair: introduce new scheduler group type group_parked
On 18/02/2025 06:58, Shrikanth Hegde wrote: [...] There are a couple of issues and corner cases which need further considerations: - rt & dl: Realtime and deadline scheduling require some additional attention. I think we need to address atleast rt, there would be some non percpu kworker threads which need to move out of parked cpus. Yea, sounds reasonable. Would probably make sense to go next for that one. - ext: Probably affected as well. Needs some conceptional thoughts first. - raciness: Right now, there are no synchronization efforts. It needs to be considered whether those might be necessary or if it is alright that the parked-state of a CPU might change during load-balancing. Patches apply to tip:sched/core The s390 patch serves as a simplified implementation example. Gave it a try on powerpc with the debugfs file. it works for sched_normal tasks. That's great to hear! Tobias Huschle (3): sched/fair: introduce new scheduler group type group_parked sched/fair: adapt scheduler group weight and capacity for parked CPUs s390/topology: Add initial implementation for selection of parked CPUs arch/s390/include/asm/smp.h | 2 + arch/s390/kernel/smp.c | 5 ++ include/linux/sched/topology.h | 19 ++ kernel/sched/core.c | 13 - kernel/sched/fair.c | 104 - kernel/sched/syscalls.c | 3 + 6 files changed, 130 insertions(+), 16 deletions(-)
[PATCH] KVM: powerpc: Enable commented out BUILD_BUG_ON() assertion
The BUILD_BUG_ON() assertion was commented out in commit 38634e676992
("powerpc/kvm: Remove problematic BUILD_BUG_ON statement") and fixed in
commit c0a187e12d48 ("KVM: powerpc: Fix BUILD_BUG_ON condition"), but
not enabled. Enable it now that this no longer breaks and remove the
comment.
Signed-off-by: Thorsten Blum
---
arch/powerpc/kvm/timing.h | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
index 45817ab82bb4..14b0e23f601f 100644
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@ -38,11 +38,7 @@ static inline void kvmppc_set_exit_type(struct kvm_vcpu
*vcpu, int type) {}
static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
{
/* type has to be known at build time for optimization */
-
- /* The BUILD_BUG_ON below breaks in funny ways, commented out
-* for now ... -BenH
BUILD_BUG_ON(!__builtin_constant_p(type));
- */
switch (type) {
case EXT_INTR_EXITS:
vcpu->stat.ext_intr_exits++;
--
2.48.1
Re: [PATCH] powerpc/fsl_lbc: Explicitly populate bus
On Sun, Feb 09, 2025 at 10:58:50PM +0100, J. Neuschäfer via B4 Relay wrote: > From: "J. Neuschäfer" > > Historically, devicetree nodes representing the Freescale Enhanced > Local Bus Controller (eLBC) have compatible strings such as: > > compatible = "fsl,mpc8313-elbc", "fsl,elbc", "simple-bus"; > > The "simple-bus" string causes the bus to be populated, and the memory > devices contained within it to be discovered. The eLBC bus (as > represented in device trees) differs from a simple-bus in a few ways, > though: > > - Addresses are not simple/linear: The first cell of an address is a >chip select, the second is an linear address within the space thus >selected. Representing 1,0 as 1, for example, would decrease >readability[1]. > - It is expected that the devices on a simple-bus "can be accessed >directly without additional configuration required"[2], but the eLBC >needs some configuration. > > To accommodate devicetrees that declare an eLBC without "simple-bus", > explicitly populate the bus in the eLBC driver. > > [1]: dtc makes such a suggestion opon encountering an eLBC > [2]: Quoting the Devicetree Specification Release v0.3 > > Signed-off-by: J. Neuschäfer > --- Due to advice from Crystal Wood and Rob Herring[1], I reached the conclusion that this patch is not necessary. [1]: https://lore.kernel.org/lkml/Z7ILej_AJYot_wKP@probook/ > arch/powerpc/sysdev/fsl_lbc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c > index > 217cea150987df1e1b5c6dbf9e9a1607dd5ce49b..2007ced997fcf0c7059e5b780893b530764dc8b2 > 100644 > --- a/arch/powerpc/sysdev/fsl_lbc.c > +++ b/arch/powerpc/sysdev/fsl_lbc.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -336,7 +337,7 @@ static int fsl_lbc_ctrl_probe(struct platform_device *dev) > /* Enable interrupts for any detected events */ > out_be32(&fsl_lbc_ctrl_dev->regs->lteir, LTEIR_ENABLE); > > - return 0; > + return devm_of_platform_populate(&dev->dev); > > err1: > free_irq(fsl_lbc_ctrl_dev->irq[0], fsl_lbc_ctrl_dev); > > --- > base-commit: 7ccde445dddcca030cd6ed66974bb80915ad9dd5 > change-id: 20250209-localbus-94a6ebb04c12 > > Best regards, > -- > J. Neuschäfer > >
Re: [PATCH v8 20/20] device/dax: Properly refcount device dax pages when mapping
On Tue, 18 Feb 2025 14:55:36 +1100
Alistair Popple wrote:
[...]
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 9a8879b..532a52a 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -460,11 +460,10 @@ void free_zone_device_folio(struct folio *folio)
> {
> struct dev_pagemap *pgmap = folio->pgmap;
>
> - if (WARN_ON_ONCE(!pgmap->ops))
> - return;
> -
> - if (WARN_ON_ONCE(pgmap->type != MEMORY_DEVICE_FS_DAX &&
> - !pgmap->ops->page_free))
> + if (WARN_ON_ONCE((!pgmap->ops &&
> + pgmap->type != MEMORY_DEVICE_GENERIC) ||
> + (pgmap->ops && !pgmap->ops->page_free &&
> + pgmap->type != MEMORY_DEVICE_FS_DAX)))
Playing around with dcssblk, adding devm_memremap_pages() and
pgmap.type = MEMORY_DEVICE_FS_DAX, similar to the other two existing
FS_DAX drivers drivers/nvdimm/pmem.c and fs/fuse/virtio_fs.c, I hit
this warning when executing binaries from DAX-mounted fs.
I do not set up pgmap->ops, similar to fs/fuse/virtio_fs.c, and I don't see
why they would be needed here anyway, at least for MEMORY_DEVICE_FS_DAX.
drivers/nvdimm/pmem.c does set up pgmap->ops, but only ->memory_failure,
which is still good enough to not trigger the warning here, probably just
by chance.
Now I wonder:
1) What is this check / warning good for, when this function only ever
calls pgmap->ops->page_free(), but not for MEMORY_DEVICE_FS_DAX and
not for MEMORY_DEVICE_GENERIC (the latter only after this patch)?
2) Is the warning also seen for virtio DAX mappings (added Vivek and
Stefan on CC)? No pgmap->ops set up there, so I would guess "yes",
and already before this series, with the old check / warning.
3) Could this be changed to only check / warn if pgmap->ops (or maybe
rather pgmap->ops->page_free) is not set up, but not for
MEMORY_DEVICE_GENERIC and MEMORY_DEVICE_FS_DAX where this is not
being called?
4) Or is there any reason why pgmap->ops would be required for
MEMORY_DEVICE_FS_DAX?
Apart from the warning, we would also miss out on the
wake_up_var(&folio->page) in the MEMORY_DEVICE_FS_DAX case, when no
pgmap->ops was set up. IIUC, even before this change / series (i.e.
for virtio DAX only, since dcssblk was not using ZONE_DEVICE before,
and pmem seems to work by chance because they have ops->memory_failure).
> return;
>
> mem_cgroup_uncharge(folio);
> @@ -494,7 +493,8 @@ void free_zone_device_folio(struct folio *folio)
>* zero which indicating the page has been removed from the file
>* system mapping.
>*/
> - if (pgmap->type != MEMORY_DEVICE_FS_DAX)
> + if (pgmap->type != MEMORY_DEVICE_FS_DAX &&
> + pgmap->type != MEMORY_DEVICE_GENERIC)
> folio->mapping = NULL;
>
> switch (pgmap->type) {
> @@ -509,7 +509,6 @@ void free_zone_device_folio(struct folio *folio)
>* Reset the refcount to 1 to prepare for handing out the page
>* again.
>*/
> - pgmap->ops->page_free(folio_page(folio, 0));
Ok, this is probably the reason why you adjusted the check above, since
no more pgmap->ops needed for MEMORY_DEVICE_GENERIC.
Still, the MEMORY_DEVICE_FS_DAX case also does not seem to need
pgmap->ops, and at least the existing virtio DAX should already be
affected, and of course future dcssblk DAX.
But maybe that should be addressed in a separate patch, since your changes
here seem consistent, and not change or worsen anything wrt !pgmap->ops
and MEMORY_DEVICE_FS_DAX.
> folio_set_count(folio, 1);
> break;
>
For reference, this is call trace I see when I hit the warning:
[ 283.567945] [ cut here ]
[ 283.567947] WARNING: CPU: 12 PID: 878 at mm/memremap.c:436
free_zone_device_folio+0x6e/0x140
[ 283.567959] Modules linked in:
[ 283.567963] CPU: 12 UID: 0 PID: 878 Comm: ls Not tainted
6.14.0-rc3-next-20250220-00012-gd072dabf62e8-dirty #44
[ 283.567968] Hardware name: IBM 3931 A01 704 (z/VM 7.4.0)
[ 283.567971] Krnl PSW : 0704d0018000 01ec0548b44a
(free_zone_device_folio+0x72/0x140)
[ 283.567978]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0
RI:0 EA:3
[ 283.567982] Krnl GPRS: 0038 0003
01ec06cc42e8
[ 283.567986]0004cc38e400 0003
93eacd00
[ 283.567990]9a68413f 016614010940 9553a640
016614010940
[ 283.567994] 01ec0548b416
016c05da3bf8
[ 283.568004] Krnl Code: 01ec0548b43e: a70e0003
Re: [RFC PATCH] objtool: Skip unannotated intra-function call warning for bl+mflr pattern
On Wed, Feb 19, 2025 at 09:50:14PM +0530, Sathvika Vasireddy wrote:
> Architectures like PowerPC use a pattern where the compiler generates a
> branch-and-link (bl) instruction that targets the very next instruction,
> followed by loading the link register (mflr) later. This pattern appears
> in the code like:
>
> bl .+4
> li r5,0
> mflr r30
If I understand correctly, this is basically a fake call which is used
to get the value of the program counter?
> Objtool currently warns about this as an "unannotated intra-function
> call" because find_call_destination() fails to find any symbol at the
> target offset. Add a check to skip the warning when a branch targets
> the immediate next instruction in the same function.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202502180818.xnfdv8i8-...@intel.com/
> Signed-off-by: Sathvika Vasireddy
This should have a Fixes tag as well.
> static int add_call_destinations(struct objtool_file *file)
> {
> + struct instruction *next_insn;
> struct instruction *insn;
> unsigned long dest_off;
> struct symbol *dest;
> @@ -1625,6 +1626,11 @@ static int add_call_destinations(struct objtool_file
> *file)
> reloc = insn_reloc(file, insn);
> if (!reloc) {
> dest_off = arch_jump_destination(insn);
> +
> + next_insn = next_insn_same_func(file, insn);
> + if (next_insn && dest_off == next_insn->offset)
> + continue;
> +
This won't work on x86, where an intra-function call is converted to a
stack-modifying JUMP. So this should probably be checked in an
arch-specific function.
--
Josh
[powerpc:fixes-test] BUILD SUCCESS eff2eb592efd73f00590d578c3d6021f604df62c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: eff2eb592efd73f00590d578c3d6021f604df62c cxl: Fix cross-reference in documentation and add deprecation warning elapsed time: 1446m configs tested: 128 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfiggcc-14.2.0 alphaallyesconfiggcc-14.2.0 alpha defconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allnoconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc defconfiggcc-13.2.0 arc randconfig-001-20250219gcc-13.2.0 arc randconfig-002-20250219gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-17 arm allyesconfiggcc-14.2.0 arm defconfigclang-21 arm imxrt_defconfigclang-19 armmvebu_v7_defconfigclang-15 arm nhk8815_defconfigclang-21 arm randconfig-001-20250219gcc-14.2.0 arm randconfig-002-20250219clang-17 arm randconfig-003-20250219clang-15 arm randconfig-004-20250219gcc-14.2.0 arm u8500_defconfiggcc-14.2.0 arm versatile_defconfiggcc-14.2.0 armvexpress_defconfiggcc-14.2.0 arm64allmodconfigclang-18 arm64 allnoconfiggcc-14.2.0 arm64 defconfiggcc-14.2.0 arm64 randconfig-001-20250219clang-21 arm64 randconfig-002-20250219gcc-14.2.0 arm64 randconfig-003-20250219gcc-14.2.0 arm64 randconfig-004-20250219gcc-14.2.0 csky allnoconfiggcc-14.2.0 cskydefconfiggcc-14.2.0 csky randconfig-001-20250219gcc-14.2.0 csky randconfig-002-20250219gcc-14.2.0 hexagon allnoconfigclang-21 hexagon allyesconfigclang-18 hexagon defconfigclang-21 hexagon randconfig-001-20250219clang-14 hexagon randconfig-002-20250219clang-21 i386 allmodconfiggcc-12 i386 allnoconfiggcc-12 i386 allyesconfiggcc-12 i386buildonly-randconfig-001-20250219clang-19 i386buildonly-randconfig-002-20250219clang-19 i386buildonly-randconfig-003-20250219gcc-12 i386buildonly-randconfig-004-20250219clang-19 i386buildonly-randconfig-005-20250219clang-19 i386buildonly-randconfig-006-20250219gcc-12 i386defconfigclang-19 loongarch allnoconfiggcc-14.2.0 loongarch randconfig-001-20250219gcc-14.2.0 loongarch randconfig-002-20250219gcc-14.2.0 m68k allnoconfiggcc-14.2.0 m68kdefconfiggcc-14.2.0 m68k m5249evb_defconfiggcc-14.2.0 microblazeallnoconfiggcc-14.2.0 microblaze defconfiggcc-14.2.0 mips allnoconfiggcc-14.2.0 nios2 allnoconfiggcc-14.2.0 nios2 randconfig-001-20250219gcc-14.2.0 nios2 randconfig-002-20250219gcc-14.2.0 openrisc allnoconfiggcc-14.2.0 openrisc allyesconfiggcc-14.2.0 openriscdefconfiggcc-14.2.0 parisc allmodconfiggcc-14.2.0 pariscallnoconfiggcc-14.2.0 parisc allyesconfiggcc-14.2.0 parisc defconfiggcc-14.2.0 pariscrandconfig-001-20250219gcc-14.2.0 pariscrandconfig-002-20250219gcc-14.2.0 powerpc allmodconfiggcc-14.2.0 powerpc allnoconfiggcc-14.2.0 powerpc randconfig-001-20250219clang-15 powerpc randconfig-002-20250219clang-17 powerpc randconfig-003-20250219gcc-14.2.0 powerpc tqm8555_defconfiggcc-14.2.0 powerpc64 randconfig-001-20250219gcc-14.2.0 powerpc64 randconfig-002-20250219
[PATCH v3] dt-bindings: powerpc: Add Freescale/NXP MPC83xx SoCs
From: "J. Neuschäfer"
Add a new binding for MPC83xx platforms, describing the board compatible
strings used in currently existing device trees.
Note that the SoC bus is called immr@... in many existing devicetrees,
but this contradicts the simple-bus binding.
Reviewed-by: Rob Herring (Arm)
Signed-off-by: J. Neuschäfer
---
V3:
- split out as a single patch
- otherwise no changes
V2:
- part of series [PATCH v2 00/12] YAML conversion of several Freescale/PowerPC
DT bindings
Link:
https://lore.kernel.org/lkml/20250207-ppcyaml-v2-1-8137b0c42...@posteo.net/
- trim subject line
- fix property order to comply with dts coding style
- add Rob Herrings's R-b tag
---
.../bindings/powerpc/fsl/fsl,mpc83xx.yaml | 67 ++
1 file changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fsl,mpc83xx.yaml
b/Documentation/devicetree/bindings/powerpc/fsl/fsl,mpc83xx.yaml
new file mode 100644
index
..1d7ed67473ca447e0fd2e9b8f30d20e18c601ccf
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fsl,mpc83xx.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/powerpc/fsl/fsl,mpc83xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale PowerQUICC II Pro (MPC83xx) platforms
+
+maintainers:
+ - J. Neuschäfer
+
+properties:
+ $nodename:
+const: '/'
+ compatible:
+oneOf:
+ - description: MPC83xx Reference Design Boards
+items:
+ - enum:
+ - fsl,mpc8308rdb
+ - fsl,mpc8315erdb
+ - fsl,mpc8360rdk
+ - fsl,mpc8377rdb
+ - fsl,mpc8377wlan
+ - fsl,mpc8378rdb
+ - fsl,mpc8379rdb
+
+patternProperties:
+ "^soc@.*$":
+type: object
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - fsl,mpc8315-immr
+ - fsl,mpc8308-immr
+ - const: simple-bus
+ - items:
+ - const: fsl,mpc8360-immr
+ - const: fsl,immr
+ - const: fsl,soc
+ - const: simple-bus
+ - const: simple-bus
+
+additionalProperties: true
+
+examples:
+ - |
+/ {
+compatible = "fsl,mpc8315erdb";
+model = "MPC8315E-RDB";
+#address-cells = <1>;
+#size-cells = <1>;
+
+soc@e000 {
+compatible = "fsl,mpc8315-immr", "simple-bus";
+reg = <0xe000 0x0200>;
+#address-cells = <1>;
+#size-cells = <1>;
+device_type = "soc";
+ranges = <0 0xe000 0x0010>;
+ bus-frequency = <0>;
+};
+};
+
+...
---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250220-ppcyaml-soc-cae1f14cf389
Best regards,
--
J. Neuschäfer
