[PATCH] ASoC: imx-audmix: release cpu_mclk clock at failure

2025-02-12 Thread Shengjiu Wang
When defer probe happens, there may be below error:

platform 5982.sai: Resources present before probing

The cpu_mclk clock is from the cpu dai device, if it is
not released, then the cpu dai device probe will fail
for the second time.

Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/imx-audmix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 231400661c90..1b16470b2f7c 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -348,6 +348,7 @@ static int imx_audmix_probe(struct platform_device *pdev)
 
ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
if (ret) {
+   devm_clk_put(&cpu_pdev->dev, priv->cpu_mclk);
dev_err(&pdev->dev, "snd_soc_register_card failed\n");
return ret;
}
-- 
2.34.1




Re: [PATCH 0/9] Extend automarkup support for ABI symbols

2025-02-12 Thread Mauro Carvalho Chehab
Em Wed, 12 Feb 2025 18:25:15 +0700
Bagas Sanjaya  escreveu:

> On Tue, Feb 11, 2025 at 07:22:54AM +0100, Mauro Carvalho Chehab wrote:
> > Now that ABI creates a python dictionary, use automarkup to create cross
> > references for ABI symbols as well.   
> 
> I get three new warnings:
> 
> WARNING: /sys/devices/system/cpu/cpuX/topology/physical_package_id is defined 
> 2 times: 
> /home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:27;
>  
> /home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70
> WARNING: /sys/devices/system/cpu/cpuX/topology/ppin is defined 2 times: 
> /home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:89;
>  
> /home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70

Those two are new reports that get_abi.py detects after the recent changes.
In the past, symbol duplication were detected only within the same group
(testing, stable, ...). The new version can detect symbols that are
duplicated on different parts of the ABI. In this specific case, the same
symbols exist on both stable and testing.

There is a fix for them already at:

https://lore.kernel.org/linux-doc/673e9543783349b0fcf625018e38e4e93fe98f52.1738020236.git.mchehab+hua...@kernel.org/

> WARNING: Documentation/ABI/testing/sysfs-class-cxl not found

I need to double-check verify this one, as it didn't appear on
my tests. Are you getting it against docs-next or linux-next?

Thanks,
Mauro



Re: [PATCH 2/2] ASoC: imx-card: Add playback_only or capture_only support

2025-02-12 Thread Mark Brown
On Wed, Feb 12, 2025 at 11:48:43AM +0800, Shengjiu Wang wrote:
> On Tue, Feb 11, 2025 at 11:34 PM Frank Li  wrote:
> > On Tue, Feb 11, 2025 at 11:57:37AM +0800, Shengjiu Wang wrote:

> > > With the DPCM case, the backend only support capture or
> > > playback, then the linked frontend can only support
> > > capture or playback, but frontend can't automatically
> > > enable only capture or playback, it needs the input
> > > from dt-binding.

> > wrap at 75 chars

> On my side, there are in 75 chars...

It's wrapped as above in the copy I got FWIW.


signature.asc
Description: PGP signature


[PATCH] tools/perf: Pick the correct dwarf die while adding probe point for a function

2025-02-12 Thread Athira Rajeev
Perf probe on vfs_fstatat fails as below on a powerpc system

./perf probe -nf --max-probes=512 -a 'vfs_fstatat $params'
Segmentation fault (core dumped)

This is observed while running perftool-testsuite_probe testcase.

While running with verbose, its observed that segfault happens
at:

   synthesize_probe_trace_arg ()
   synthesize_probe_trace_command ()
   probe_file.add_event ()
   apply_perf_probe_events ()
   __cmd_probe ()
   cmd_probe ()
   run_builtin ()
   handle_internal_command ()
   main ()

Code in synthesize_probe_trace_arg() access a null value and results in
segfault. Data structure which is null:
struct probe_trace_arg arg->value

We are hitting a case where arg->value is null in probe point:
"vfs_fstatat $params". This is happening since 'commit e896474fe485
("getname_maybe_null() - the third variant of pathname copy-in")'
Before the commit, probe point for vfs_fstatat was getting added only
for one location:

Writing event: p:probe/vfs_fstatat _text+6345404 dfd=%gpr3:s32 
filename=%gpr4:x64 stat=%gpr5:x64 flags=%gpr6:s32

With this change, vfs_fstatat code is inlined for other locations in the
code:
Probe point found: __do_sys_lstat64+48
Probe point found: __do_sys_stat64+48
Probe point found: __do_sys_newlstat+48
Probe point found: __do_sys_newstat+48
Probe point found: vfs_fstatat+0

When trying to find matching dwarf information entry (DIE)
from the debuginfo, the code incorrectly picks DIE which is
not referring to vfs_fstatat. Snippet from dwarf entry in vmlinux
debuginfo file.

The main abstract die is:
 <1><4214883>: Abbrev Number: 147 (DW_TAG_subprogram)
<4214885>   DW_AT_external: 1
<4214885>   DW_AT_name: (indirect string, offset: 0x17b9f3): 
vfs_fstatat

With formal parameters:
 <2><4214896>: Abbrev Number: 51 (DW_TAG_formal_parameter)
<4214897>   DW_AT_name: dfd
 <2><42148a3>: Abbrev Number: 23 (DW_TAG_formal_parameter)
<42148a4>   DW_AT_name: (indirect string, offset: 0x8fda9): filename
 <2><42148b0>: Abbrev Number: 23 (DW_TAG_formal_parameter)
<42148b1>   DW_AT_name: (indirect string, offset: 0x16bd9c): stat
 <2><42148bd>: Abbrev Number: 23 (DW_TAG_formal_parameter)
<42148be>   DW_AT_name: (indirect string, offset: 0x39832b): flags

While collecting variables/parameters for a probe point, the function
copy_variables_cb() also looks at dwarf debug entries based on the
instruction address. Snippet

if (dwarf_haspc(die_mem, vf->pf->addr))
return DIE_FIND_CB_CONTINUE;
else
return DIE_FIND_CB_SIBLING;

But incase of inlined function instance for vfs_fstatat, there are two
entries which has the instruction address entry point as same.

Instance 1: which is for vfs_fstatat and DW_AT_abstract_origin points to
0x4214883 (reference above for main abstract die)

<3><42131fa>: Abbrev Number: 59 (DW_TAG_inlined_subroutine)
<42131fb>   DW_AT_abstract_origin: <0x4214883>
<42131ff>   DW_AT_entry_pc: 0xc062b1e0

Instance 2: which is not for vfs_fstatat but for getname

 <5><4213270>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
<4213271>   DW_AT_abstract_origin: <0x4215b6b>
<4213275>   DW_AT_entry_pc: 0xc062b1e0

But the copy_variables_cb() continues to add parameters from second
instance also based on the dwarf_haspc() check. This results in
formal parameters for getname also appended to params. But while
filling in the args->value for these parameters, since these args
are not part of dwarf with offset "42131fa". Hence value will be
null. This incorrect args results in segfault when value field is
accessed.

Save the Dwarf_Die which is the actual DW_TAG_subprogram as part of
"struct probe_finder". In copy_variables_cb(), include check to make
sure the DW_AT_abstract_origin points to the correct entry if the
dwarf_haspc() matches the instruction address.

Signed-off-by: Athira Rajeev 
---
 tools/perf/util/probe-finder.c | 21 ++---
 tools/perf/util/probe-finder.h |  1 +
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 1e769b68da37..361086a7adae 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -973,6 +973,7 @@ static int probe_point_search_cb(Dwarf_Die *sp_die, void 
*data)
pr_debug("Matched function: %s [%lx]\n", dwarf_diename(sp_die),
 (unsigned long)dwarf_dieoffset(sp_die));
pf->fname = fname;
+   memcpy(&pf->abstract_die, sp_die, sizeof(Dwarf_Die));
if (pp->line) { /* Function relative line */
dwarf_decl_line(sp_die, &pf->lno);
pf->lno += pp->line;
@@ -1179,6 +1180,8 @@ static int copy_variables_cb(Dwarf_Die *die_mem, void 
*data)
struct local_vars_finder *vf = data;
struct probe_finder *pf = vf->pf;
int tag;
+   Dwarf_Attribute attr;
+   Dwarf_Die var_die;
 
tag = dwarf_tag(die_mem)

[PATCH v3 5/9] powerpc: Rely on generic printing of preemption model.

2025-02-12 Thread Sebastian Andrzej Siewior
After the first printk in __die() there is show_regs() ->
show_regs_print_info() which prints the current
preemption model.

Remove the preempion model from the arch code.

Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Naveen N Rao 
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Christophe Leroy 
Reviewed-by: Shrikanth Hegde 
Signed-off-by: Sebastian Andrzej Siewior 
---
 arch/powerpc/kernel/traps.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index edf5cabe5dfdb..cb8e9357383e9 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -263,10 +263,9 @@ static int __die(const char *str, struct pt_regs *regs, 
long err)
 {
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
 
-   printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+   printk("%s PAGE_SIZE=%luK%s %s%s%s%s %s\n",
   IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
   PAGE_SIZE / 1024, get_mmu_str(),
-  IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
   IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
   IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
   debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
-- 
2.47.2




Re: [PATCH] ASoC: imx-audmix: release cpu_mclk clock at failure

2025-02-12 Thread Mark Brown
On Wed, Feb 12, 2025 at 05:38:16PM +0800, Shengjiu Wang wrote:
> When defer probe happens, there may be below error:
> 
> platform 5982.sai: Resources present before probing
> 
> The cpu_mclk clock is from the cpu dai device, if it is
> not released, then the cpu dai device probe will fail
> for the second time.

>   ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
>   if (ret) {
> + devm_clk_put(&cpu_pdev->dev, priv->cpu_mclk);

The driver shouldn't be using another driver's device to do devm_
requests (or really to look anything up), that's just going to lead to
trouble like this - if it's got to look up another device's clocks it
should do a regular clk_get().  There will also potentially be problems
if the other device unregisters first and frees our clock underneath us,
and this will request multiple copies of the clock if we unbind and
rebind the imx-audmix driver.


signature.asc
Description: PGP signature


Re: [kvm-unit-tests PATCH v2 04/18] run_tests: Introduce unittest parameter 'qemu_params'

2025-02-12 Thread Alexandru Elisei
Hi Drew,

On Tue, Jan 21, 2025 at 04:46:24PM +0100, Andrew Jones wrote:
> On Mon, Jan 20, 2025 at 04:43:02PM +, Alexandru Elisei wrote:
> > Tests for the arm and arm64 architectures can also be run with kvmtool, and
> > work is under way to have it supported by the run_tests.sh test runner. Not
> > suprisingly, kvmtool has a different syntax than qemu when configuring and
> > running a virtual machine.
> > 
> > Add a new unittest parameter, 'qemu_params', with the goal to add a similar
> > parameter for each virtual machine manager that run_tests.sh supports.
> > 
> > 'qemu_params' and 'extra_params' are interchangeable, but it is expected
> > that going forward new tests will use 'qemu_params'. A test should have
> > only one of the two parameters.
> > 
> > While we're at it, rename the variable opts to qemu_opts to match the new
> > unit configuration name, and to make it easier to distinguish from the
> > kvmtool parameters when they'll be added.
> > 
> > Signed-off-by: Alexandru Elisei 
> > ---
> >  docs/unittests.txt   | 17 +-
> >  scripts/common.bash  | 53 ++--
> >  scripts/runtime.bash | 10 -
> >  3 files changed, 47 insertions(+), 33 deletions(-)
> > 
> > diff --git a/docs/unittests.txt b/docs/unittests.txt
> > index dbc2c11e3b59..3e1a9e563016 100644
> > --- a/docs/unittests.txt
> > +++ b/docs/unittests.txt
> > @@ -24,9 +24,9 @@ param = value format.
> >  
> >  Available parameters
> >  
> > -Note! Some parameters like smp and extra_params modify how a test is run,
> > -while others like arch and accel restrict the configurations in which the
> > -test is run.
> > +Note! Some parameters like smp and qemu_params/extra_params modify how a
> > +test is run, while others like arch and accel restrict the configurations
> > +in which the test is run.
> >  
> >  file
> >  
> > @@ -56,13 +56,18 @@ smp = 
> >  Optional, the number of processors created in the machine to run the test.
> >  Defaults to 1. $MAX_SMP can be used to specify the maximum supported.
> >  
> > -extra_params
> > -
> > +qemu_params
> > +---
> >  These are extra parameters supplied to the QEMU process. -append '...' can
> >  be used to pass arguments into the test case argv. Multiple parameters can
> >  be added, for example:
> >  
> > -extra_params = -m 256 -append 'smp=2'
> > +qemu_params = -m 256 -append 'smp=2'
> > +
> > +extra_params
> > +
> > +Alias for 'qemu_params', supported for compatibility purposes. Use
> > +'qemu_params' for new tests.
> >  
> >  groups
> >  --
> > diff --git a/scripts/common.bash b/scripts/common.bash
> > index 3aa557c8c03d..a40c28121b6a 100644
> > --- a/scripts/common.bash
> > +++ b/scripts/common.bash
> > @@ -1,5 +1,28 @@
> >  source config.mak
> >  
> > +function parse_opts()
> > +{
> > +   local opts="$1"
> > +   local fd="$2"
> > +
> > +   while read -r -u $fd; do
> > +   #escape backslash newline, but not double backslash
> > +   if [[ $opts =~ [^\\]*(\\*)$'\n'$ ]]; then
> > +   if (( ${#BASH_REMATCH[1]} % 2 == 1 )); then
> > +   opts=${opts%\\$'\n'}
> > +   fi
> > +   fi
> > +   if [[ "$REPLY" =~ ^(.*)'"""'[:blank:]*$ ]]; then
> > +   opts+=${BASH_REMATCH[1]}
> > +   break
> > +   else
> > +   opts+=$REPLY$'\n'
> > +   fi
> > +   done
> > +
> > +   echo "$opts"
> > +}
> > +
> >  function for_each_unittest()
> >  {
> > local unittests="$1"
> > @@ -7,7 +30,7 @@ function for_each_unittest()
> > local testname
> > local smp
> > local kernel
> > -   local opts
> > +   local qemu_opts
> > local groups
> > local arch
> > local machine
> > @@ -22,12 +45,12 @@ function for_each_unittest()
> > if [[ "$line" =~ ^\[(.*)\]$ ]]; then
> > rematch=${BASH_REMATCH[1]}
> > if [ -n "${testname}" ]; then
> > -   $(arch_cmd) "$cmd" "$testname" "$groups" "$smp" 
> > "$kernel" "$opts" "$arch" "$machine" "$check" "$accel" "$timeout"
> > +   $(arch_cmd) "$cmd" "$testname" "$groups" "$smp" 
> > "$kernel" "$qemu_opts" "$arch" "$machine" "$check" "$accel" "$timeout"
> > fi
> > testname=$rematch
> > smp=1
> > kernel=""
> > -   opts=""
> > +   qemu_opts=""
> > groups=""
> > arch=""
> > machine=""
> > @@ -38,24 +61,10 @@ function for_each_unittest()
> > kernel=$TEST_DIR/${BASH_REMATCH[1]}
> > elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
> > smp=${BASH_REMATCH[1]}
> > -   elif [[ $line =~ ^extra_params\ *=\ *'"""'(.*)$ ]]; then
> > -   opts=${BASH_REMATCH[1]}$'\n'
> > -   while 

Re: [PATCH 0/9] Extend automarkup support for ABI symbols

2025-02-12 Thread Bagas Sanjaya
On Tue, Feb 11, 2025 at 07:22:54AM +0100, Mauro Carvalho Chehab wrote:
> Now that ABI creates a python dictionary, use automarkup to create cross
> references for ABI symbols as well. 

I get three new warnings:

WARNING: /sys/devices/system/cpu/cpuX/topology/physical_package_id is defined 2 
times: 
/home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:27;
 
/home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70
WARNING: /sys/devices/system/cpu/cpuX/topology/ppin is defined 2 times: 
/home/bagas/repo/linux-kernel/Documentation/ABI/stable/sysfs-devices-system-cpu:89;
 
/home/bagas/repo/linux-kernel/Documentation/ABI/testing/sysfs-devices-system-cpu:70
WARNING: Documentation/ABI/testing/sysfs-class-cxl not found

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


signature.asc
Description: PGP signature


Re: [PATCH 2/2] ASoC: imx-card: Add playback_only or capture_only support

2025-02-12 Thread Frank Li
On Wed, Feb 12, 2025 at 11:48:43AM +0800, Shengjiu Wang wrote:
> On Tue, Feb 11, 2025 at 11:34 PM Frank Li  wrote:
> >
> > On Tue, Feb 11, 2025 at 11:57:37AM +0800, Shengjiu Wang wrote:
> > > With the DPCM case, the backend only support capture or
> > > playback, then the linked frontend can only support
> > > capture or playback, but frontend can't automatically
> > > enable only capture or playback, it needs the input
> > > from dt-binding.
> >
> > wrap at 75 chars
>
> On my side, there are in 75 chars...
>
> >
> > >
> > > Signed-off-by: Shengjiu Wang 
> > > ---
> > >  sound/soc/fsl/imx-card.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
> > > index ac043ad367ac..905294682996 100644
> > > --- a/sound/soc/fsl/imx-card.c
> > > +++ b/sound/soc/fsl/imx-card.c
> > > @@ -518,6 +518,7 @@ static int imx_card_parse_of(struct imx_card_data 
> > > *data)
> > >   struct snd_soc_dai_link *link;
> > >   struct dai_link_data *link_data;
> > >   struct of_phandle_args args;
> > > + bool playback_only, capture_only;
> > >   int ret, num_links;
> > >   u32 asrc_fmt = 0;
> > >   u32 width;
> > > @@ -679,6 +680,10 @@ static int imx_card_parse_of(struct imx_card_data 
> > > *data)
> > >   link->ops = &imx_aif_ops;
> > >   }
> > >
> > > + graph_util_parse_link_direction(np, &playback_only, 
> > > &capture_only);
> > > + link->playback_only = playback_only;
> > > + link->capture_only = capture_only;
> > > +
> >
> > if only use once, needn't local variable.
> >
> > graph_util_parse_link_direction(np, &link->playback_only, 
> > &link->capture_only)
>
> sound/soc/fsl/imx-card.c:683:53: error: cannot take address of
> bit-field ‘playback_only’
>   683 | graph_util_parse_link_direction(np,
> &link->playback_only, &link->capture_only);
>   | ^
> sound/soc/fsl/imx-card.c:683:75: error: cannot take address of
> bit-field ‘capture_only’
>   683 | graph_util_parse_link_direction(np,
> &link->playback_only, &link->capture_only);
>
> There are errors with it.

Okay, it should be fine.

Frank

>
> best regards
> Shengjiu Wang
> >
> > Frank
> >
> > >   /* Get dai fmt */
> > >   ret = simple_util_parse_daifmt(dev, np, codec,
> > >  NULL, &link->dai_fmt);
> > > --
> > > 2.34.1
> > >



Re: [kvm-unit-tests PATCH v2 04/18] run_tests: Introduce unittest parameter 'qemu_params'

2025-02-12 Thread Andrew Jones
On Wed, Feb 12, 2025 at 01:40:51PM +, Alexandru Elisei wrote:
...
> > > @@ -80,7 +80,7 @@ function run()
> > >  local groups="$2"
> > >  local smp="$3"
> > >  local kernel="$4"
> > > -local opts="$5"
> > > +local qemu_opts="$5"
> > >  local arch="$6"
> > >  local machine="$7"
> > >  local check="${CHECK:-$8}"
> > > @@ -179,9 +179,9 @@ function run()
> > >  echo $cmdline
> > >  fi
> > >  
> > > -# extra_params in the config file may contain backticks that need to 
> > > be
> > > -# expanded, so use eval to start qemu.  Use "> >(foo)" instead of a 
> > > pipe to
> > > -# preserve the exit status.
> > > +# qemu_params/extra_params in the config file may contain backticks 
> > > that
> > > +# need to be expanded, so use eval to start qemu.  Use "> >(foo)" 
> > > instead of
> > > +# a pipe to preserve the exit status.
> > >  summary=$(eval "$cmdline" 2> >(RUNTIME_log_stderr $testname) \
> > >   > >(tee >(RUNTIME_log_stdout $testname 
> > > $kernel) | extract_summary))
> > >  ret=$?
> > > -- 
> > > 2.47.1
> > >
> > 
> > Hmm, I'll keep reading the series, but it seems like we should be choosing
> > generic names like 'extra_params' and 'opts' that we plan to use for both
> > QEMU and kvmtool since they both have the concepts of "options" and "extra
> > params".
> 
> I'm afraid I don't follow you. 'qemu_params' was chosen because it uses
> qemu-specific syntax. Same for 'kvmtool_params', introduced later in the
> series. Are you referring to unittests.cfg or to something else?
>

I didn't like the renaming of opts to qemu_opts since both kvmtool and
qemu have "options", so it seems like we should be generalizing variable
names rather than making them more specific. I see later how there may
be a need for qemu_options, kvmtool_options, and unit test
cmdline_options in the unittests.cfg, though. However, here, it seems
like we could still use 'opts' for the variable and just use another
variable to determine if we parse qemu_options or kvmtool_options, since
there shouldn't be a need to parse both.

Thanks,
drew



Re: [kvm-unit-tests PATCH v2 15/18] Add kvmtool_params to test specification

2025-02-12 Thread Andrew Jones
On Tue, Feb 11, 2025 at 03:03:09PM +, Alexandru Elisei wrote:
> Hi Drew,
> 
> On Thu, Jan 23, 2025 at 04:53:29PM +0100, Andrew Jones wrote:
> > On Mon, Jan 20, 2025 at 04:43:13PM +, Alexandru Elisei wrote:
> > > arm/arm64 supports running tests under kvmtool, but kvmtool's syntax for
> > > running a virtual machine is different than qemu's. To run tests using the
> > > automated test infrastructure, add a new test parameter, kvmtool_params.
> > > The parameter serves the exact purpose as qemu_params/extra_params, but 
> > > using
> > > kvmtool's syntax.
> > 
> > The need for qemu_params and kvmtool_params makes more sense to me now
> > that I see the use in unittests.cfg (I wonder if we can't rearrange this
> > series to help understand these things up front?). There's a lot of
> 
> Certainly, I'll move it closer to the beginning of the series.
> 
> > duplication, though, with having two sets of params since the test-
> > specific inputs always have to be duplicated. To avoid the duplication
> > I think we can use extra_params for '-append' and '--params' by
> > parametrizing the option name for "params" (-append / --params) and then
> > create qemu_opts and kvmtool_opts for extra options like --pmu, --mem,
> > and irqchip.
> 
> How about something like this (I am using selftest-setup as an example, all 
> the
> other test definitions would be similarly modified):
> 
> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> index 2bdad67d5693..3009305ba2d3 100644
> --- a/arm/unittests.cfg
> +++ b/arm/unittests.cfg
> @@ -15,7 +15,9 @@
>  [selftest-setup]
>  file = selftest.flat
>  smp = 2
> -extra_params = -m 256 -append 'setup smp=2 mem=256'
> +test_args = setup smp=2 mem=256
> +qemu_params = -m 256
> +kvmtool_params = --mem 256
>  groups = selftest
> 
> I was thinking about using 'test_args' instead of 'extra_params' to avoid any
> confusion between the two, and to match how they are passed to a test
> - they are in the argv main's argument.

Yes, this looks good and test_args is better than my suggestion in the
other mail of 'cmdline_options' since "cmdline" would be ambiguous with
the test's cmdline and the vmm's cmdline.

> 
> Also, should I change the test definitions for all the other architectures?
> It's not going to be possible for me to test all the changes.

We should be safe with an s/extra_params/qemu_params/ change for all
architectures and CI is pretty good, so we'd have good confidence
if it passes, but, I think we should keep extra_params as a qemu_params
alias anyway since it's possible that people have wrapped kvm-unit-tests
in test harnesses which generate unittests.cfg files.

Thanks,
drew



[PATCH 4/4] mm: Rename GENERIC_PTDUMP and PTDUMP_CORE

2025-02-12 Thread Anshuman Khandual
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
is confusing as they sound very similar and does not differentiate between
platform's feature subscription and feature enablement for ptdump. Rename
the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve
readability.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Jonathan Corbet 
Cc: Marc Zyngier 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: kvm...@lists.linux.dev
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@kvack.org
Signed-off-by: Anshuman Khandual 
---
 Documentation/arch/arm64/ptdump.rst   |  4 ++--
 arch/arm64/Kconfig|  2 +-
 arch/arm64/include/asm/ptdump.h   |  4 ++--
 arch/arm64/kvm/Kconfig|  4 ++--
 arch/arm64/mm/Makefile|  2 +-
 arch/powerpc/Kconfig  |  2 +-
 arch/powerpc/configs/mpc885_ads_defconfig |  2 +-
 arch/powerpc/mm/Makefile  |  2 +-
 arch/riscv/Kconfig|  2 +-
 arch/riscv/mm/Makefile|  2 +-
 arch/s390/Kconfig |  2 +-
 arch/s390/mm/Makefile |  2 +-
 arch/x86/Kconfig  |  2 +-
 arch/x86/Kconfig.debug|  2 +-
 arch/x86/mm/Makefile  |  2 +-
 mm/Kconfig.debug  | 12 ++--
 mm/Makefile   |  2 +-
 17 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/Documentation/arch/arm64/ptdump.rst 
b/Documentation/arch/arm64/ptdump.rst
index 5dcfc5d7cddf..a2e527377da3 100644
--- a/Documentation/arch/arm64/ptdump.rst
+++ b/Documentation/arch/arm64/ptdump.rst
@@ -22,8 +22,8 @@ offlining of memory being accessed by the ptdump code.
 In order to dump the kernel page tables, enable the following
 configurations and mount debugfs::
 
- CONFIG_GENERIC_PTDUMP=y
- CONFIG_PTDUMP_CORE=y
+ CONFIG_ARCH_HAS_PTDUMP=y
+ CONFIG_PTDUMP=y
  CONFIG_PTDUMP_DEBUGFS=y
 
  mount -t debugfs nodev /sys/kernel/debug
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fcdd0ed3eca8..045d24d074a0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -41,6 +41,7 @@ config ARM64
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_NONLEAF_PMD_YOUNG if ARM64_HAFT
+   select ARCH_HAS_PTDUMP
select ARCH_HAS_PTE_DEVMAP
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_HW_PTE_YOUNG
@@ -157,7 +158,6 @@ config ARM64
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_LIB_DEVMEM_IS_ALLOWED
select GENERIC_PCI_IOMAP
-   select GENERIC_PTDUMP
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
index 6cf4aae05219..b2931d1ae0fb 100644
--- a/arch/arm64/include/asm/ptdump.h
+++ b/arch/arm64/include/asm/ptdump.h
@@ -7,7 +7,7 @@
 
 #include 
 
-#ifdef CONFIG_PTDUMP_CORE
+#ifdef CONFIG_PTDUMP
 
 #include 
 #include 
@@ -70,6 +70,6 @@ static inline void ptdump_debugfs_register(struct ptdump_info 
*info,
 #else
 static inline void note_page(struct ptdump_state *pt_st, unsigned long addr,
 int level, u64 val) { }
-#endif /* CONFIG_PTDUMP_CORE */
+#endif /* CONFIG_PTDUMP */
 
 #endif /* __ASM_PTDUMP_H */
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index ead632ad01b4..096e45acadb2 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -71,8 +71,8 @@ config PTDUMP_STAGE2_DEBUGFS
depends on KVM
depends on DEBUG_KERNEL
depends on DEBUG_FS
-   depends on GENERIC_PTDUMP
-   select PTDUMP_CORE
+   depends on ARCH_HAS_PTDUMP
+   select PTDUMP
default n
help
  Say Y here if you want to show the stage-2 kernel pagetables
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index fc92170a8f37..c26489cf96cd 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -5,7 +5,7 @@ obj-y   := dma-mapping.o extable.o 
fault.o init.o \
   context.o proc.o pageattr.o fixmap.o
 obj-$(CONFIG_ARM64_CONTPTE)+= contpte.o
 obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
-obj-$(CONFIG_PTDUMP_CORE)  += ptdump.o
+obj-$(CONFIG_PTDUMP)   += ptdump.o
 obj-$(CONFIG_PTDUMP_DEBUGFS)   += ptdump_debugfs.o
 obj-$(CONFIG_TRANS_TABLE)  += trans_pgd.o
 obj-$(CONFIG_TRANS_TABLE)  += trans_pgd-asm.o
diff --git a/arch/powerpc/Kconfig 

Re: [next-20250212] FStests generic/451 on EXT4 FS resulting in kernel OOPs

2025-02-12 Thread Sourabh Jain

Hello Venkat,

Thanks for reporting the issue.

I noticed that system rebooted after kernel panic.

Just wondering did you configured kdump/fadump?

Thanks,
Sourabh Jain


On 13/02/25 11:21, Venkat Rao Bagalkote wrote:

Greetings!!!


I am observing kernel OOPs, while running FStests generic/451 on EXT4 
with linux-next kernel(next-20250212) on IBM Power Servers.



Issue is seen on: next-20250212

Issue not seen on: next-20250210


Traces:

[ 2977.768678] run fstests generic/451 at 2025-02-12 16:42:14
[ 3001.242006] list_add double add: new=ce2398c8, 
prev=ce2398c8, next=c000c1f2f0b8.

[ 3001.242047] [ cut here ]
[ 3001.242052] kernel BUG at lib/list_debug.c:35!
[ 3001.242059] Oops: Exception in kernel mode, sig: 5 [#1]
[ 3001.242065] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=8192 NUMA pSeries
[ 3001.242072] Modules linked in: overlay dm_zero dm_thin_pool 
dm_persistent_data dm_bio_prison dm_snapshot dm_bufio dm_flakey ext4 
mbcache jbd2 loop dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 
nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject 
nft_ct nft_chain_nat nf_nat nf_conntrack bonding nf_defrag_ipv6 
nf_defrag_ipv4 tls ip_set rfkill nf_tables nfnetlink pseries_rng 
aes_gcm_p10_crypto crypto_simd vmx_crypto xfs sr_mod sd_mod cdrom sg 
ibmvscsi ibmveth scsi_transport_srp fuse [last unloaded: scsi_debug]
[ 3001.242165] CPU: 26 UID: 0 PID: 894003 Comm: kworker/u228:17 Not 
tainted 6.14.0-rc2-next-20250212 #1
[ 3001.242174] Hardware name: IBM,8375-42A POWER9 (architected) 
0x4e0202 0xf05 of:IBM,FW950.80 (VL950_131) hv:phyp pSeries

[ 3001.242183] Workqueue: loop0 loop_workfn [loop]
[ 3001.242194] NIP:  c090d528 LR: c090d524 CTR: 
007088ec
[ 3001.242201] REGS: c000e5adfa70 TRAP: 0700   Not tainted 
(6.14.0-rc2-next-20250212)
[ 3001.242208] MSR:  8282b033 
  CR: 2800024f  XER: 0009

[ 3001.242229] CFAR: c0224238 IRQMASK: 1
[ 3001.242229] GPR00: c090d524 c000e5adfd10 
c1657500 0058
[ 3001.242229] GPR04: c01179a87c88 c01179a96000 
c000e5adfb58 00117781
[ 3001.242229] GPR08: 0027  
 0001
[ 3001.242229] GPR12: c2a49cd0 cf75ff00 
c01abf00 c000fda72fc0
[ 3001.242229] GPR16:   
 
[ 3001.242229] GPR20: c7acbc00 04208060 
ce239880 fef7
[ 3001.242229] GPR24: 0402 c000924b8fc0 
c000c1f2f07c c000c1f2f000
[ 3001.242229] GPR28: c000c1f2f0b8 ce2398c8 
ce2398c8 c000c1f2f0b8
[ 3001.242309] NIP [c090d528] 
__list_add_valid_or_report+0x158/0x15c
[ 3001.242318] LR [c090d524] 
__list_add_valid_or_report+0x154/0x15c

[ 3001.242324] Call Trace:
[ 3001.242327] [c000e5adfd10] [c090d524] 
__list_add_valid_or_report+0x154/0x15c (unreliable)
[ 3001.242336] [c000e5adfd90] [c008073c359c] 
loop_process_work+0x594/0x630 [loop]
[ 3001.242344] [c000e5adfe40] [c019dc5c] 
process_one_work+0x1fc/0x4bc
[ 3001.242354] [c000e5adfef0] [c019ebec] 
worker_thread+0x344/0x508

[ 3001.242362] [c000e5adff90] [c01ac024] kthread+0x12c/0x14c
[ 3001.242370] [c000e5adffe0] [c000df98] 
start_kernel_thread+0x14/0x18
[ 3001.242377] Code: 4b916cf9 6000 0fe0 7c0802a6 7c641b78 
3c62ffe5 7fe6fb78 7fc5f378 386343a0 f8010090 4b916cd1 6000 
<0fe0> 3c4c00d5 38429fd4 fbe1fff8

[ 3001.242407] ---[ end trace  ]---
[ 3001.28] pstore: backend (nvram) writing error (-1)
[ 3001.284452]
[ 3002.284455] Kernel panic - not syncing: Fatal exception
[ 3002.431023] Rebooting in 10 seconds..


Regards,

Venkat.







Re: [PATCH] tools/perf: Add check to tool pmu tests to ensure if the event is valid

2025-02-12 Thread Namhyung Kim
On Thu, Feb 13, 2025 at 12:24:38AM +0530, Athira Rajeev wrote:
> "Tool PMU" tests fails on powerpc as below:
> 
>12.1: Parsing without PMU name:
>--- start ---
>test child forked, pid 48492
>Using CPUID 0x00800200
>Attempt to add: tool/duration_time/
>..after resolving event: tool/config=0x1/
>duration_time -> tool/duration_time/
>Attempt to add: tool/user_time/
>..after resolving event: tool/config=0x2/
>user_time -> tool/user_time/
>Attempt to add: tool/system_time/
>..after resolving event: tool/config=0x3/
>system_time -> tool/system_time/
>Attempt to add: tool/has_pmem/
>..after resolving event: tool/config=0x4/
>has_pmem -> tool/has_pmem/
>Attempt to add: tool/num_cores/
>..after resolving event: tool/config=0x5/
>num_cores -> tool/num_cores/
>Attempt to add: tool/num_cpus/
>..after resolving event: tool/config=0x6/
>num_cpus -> tool/num_cpus/
>Attempt to add: tool/num_cpus_online/
>..after resolving event: tool/config=0x7/
>num_cpus_online -> tool/num_cpus_online/
>Attempt to add: tool/num_dies/
>..after resolving event: tool/config=0x8/
>num_dies -> tool/num_dies/
>Attempt to add: tool/num_packages/
>..after resolving event: tool/config=0x9/
>num_packages -> tool/num_packages/
> 
> unexpected signal (11) 
>12.1: Parsing without PMU name  : 
> FAILED!
> 
> Same fail is observed for "Parsing with PMU name" as well.
> 
> The testcase loops through events in tool_pmu__for_each_event()
> and access event name using "tool_pmu__event_to_str()".
> Here tool_pmu__event_to_str returns null for "slots" event
> and "system_tsc_freq" event. These two events are only applicable
> for arm64 and x86 respectively. So the function tool_pmu__event_to_str()
> skips for unsupported events and returns null. This null value is
> causing testcase fail.
> 
> To address this in "Tool PMU" testcase, add a helper function
> tool_pmu__all_event_to_str() which returns the name for all
> events mapping to the tool_pmu_event index including the
> skipped ones. So that even if its a skipped event, the
> helper function helps to resolve the tool_pmu_event index to
> its mapping event name. Update the testcase to check for null event
> names before proceeding the test.
> 
> Signed-off-by: Athira Rajeev 

Please take a look at:
https://lore.kernel.org/r/20250212163859.1489916-1-james.cl...@linaro.org

Thanks,
Namhyung

> ---
>  tools/perf/tests/tool_pmu.c | 12 
>  tools/perf/util/tool_pmu.c  | 17 +
>  tools/perf/util/tool_pmu.h  |  1 +
>  3 files changed, 30 insertions(+)
> 
> diff --git a/tools/perf/tests/tool_pmu.c b/tools/perf/tests/tool_pmu.c
> index 187942b749b7..e468e5fb3c73 100644
> --- a/tools/perf/tests/tool_pmu.c
> +++ b/tools/perf/tests/tool_pmu.c
> @@ -19,6 +19,18 @@ static int do_test(enum tool_pmu_event ev, bool with_pmu)
>   return TEST_FAIL;
>   }
>  
> + /*
> +  * if tool_pmu__event_to_str returns NULL, Check if the event is
> +  * valid for the platform.
> +  * Example:
> +  * slots event is only on arm64.
> +  * system_tsc_freq event is only on x86.
> +  */
> + if (!tool_pmu__event_to_str(ev) && 
> tool_pmu__skip_event(tool_pmu__all_event_to_str(ev))) {
> + ret = TEST_OK;
> + goto out;
> + }
> +
>   if (with_pmu)
>   snprintf(str, sizeof(str), "tool/%s/", 
> tool_pmu__event_to_str(ev));
>   else
> diff --git a/tools/perf/util/tool_pmu.c b/tools/perf/util/tool_pmu.c
> index 3a68debe7143..572422797f6e 100644
> --- a/tools/perf/util/tool_pmu.c
> +++ b/tools/perf/util/tool_pmu.c
> @@ -60,6 +60,15 @@ int tool_pmu__num_skip_events(void)
>   return num;
>  }
>  
> +/*
> + * tool_pmu__event_to_str returns only supported event names.
> + * For events which are supposed to be skipped in the platform,
> + * return NULL
> + *
> + * tool_pmu__all_event_to_str returns the name for all
> + * events mapping to the tool_pmu_event index including the
> + * skipped ones.
> + */
>  const char *tool_pmu__event_to_str(enum tool_pmu_event ev)
>  {
>   if ((ev > TOOL_PMU__EVENT_NONE && ev < TOOL_PMU__EVENT_MAX) &&
> @@ -69,6 +78,14 @@ const char *tool_pmu__event_to_str(enum tool_pmu_event ev)
>   return NULL;
>  }
>  
> +const char *tool_pmu__all_event_to_str(enum tool_pmu_event ev)
> +{
> + if (ev > TOOL_PMU__EVENT_NONE && ev < TOOL_PMU__EVENT_MAX)
> + return tool_pmu__event_names[ev];
> +
> + return NULL;
> +}
> +
>  enum tool_pmu_event tool_pmu__str_to_event(const char *str)
>  {
>   int i;
> diff --git a/tools/perf/util/tool_pmu.h b/tools/perf/util/tool_pmu.h
> index a60184859080..da76808ae71e 100644
> --- a/tools/perf/util/tool_pmu.h
> +++ b/tools/perf/util/tool_pmu.h
> @@ -30,6 +30,7 @@ enum tool_pmu_event {
>   for ((ev) = TOOL_PMU__EVENT_DURATION_TIME; (ev) < TOOL_PMU__EVENT_MAX; 
> ev++)
>  
>  c

[PATCH 0/4] mm: Rework generic PTDUMP configs

2025-02-12 Thread Anshuman Khandual
The series reworks generic PTDUMP configs before eventually renaming them
after some basic clean ups first. This is derived after splitting changes
from the following patch.

https://lore.kernel.org/all/20250205050039.1506377-1-anshuman.khand...@arm.com/

This series applies on v6.14-rc2 and has been tested on arm64. Although it
also builds on other platforms as well.

Cc: Andrew Morton 
Cc: Mark Rutland 
Cc: Christophe Leroy 
Cc: kvm...@lists.linux.dev
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org

Anshuman Khandual (4):
  configs: Drop GENERIC_PTDUMP from debug.config
  mm: Make DEBUG_WX depdendent on GENERIC_PTDUMP
  mm: Make GENERIC_PTDUMP dependent on MMU
  mm: Rename GENERIC_PTDUMP and PTDUMP_CORE

 Documentation/arch/arm64/ptdump.rst   |  4 ++--
 arch/arm64/Kconfig|  2 +-
 arch/arm64/include/asm/ptdump.h   |  4 ++--
 arch/arm64/kvm/Kconfig|  4 ++--
 arch/arm64/mm/Makefile|  2 +-
 arch/powerpc/Kconfig  |  2 +-
 arch/powerpc/configs/mpc885_ads_defconfig |  2 +-
 arch/powerpc/mm/Makefile  |  2 +-
 arch/riscv/Kconfig|  2 +-
 arch/riscv/mm/Makefile|  2 +-
 arch/s390/Kconfig |  2 +-
 arch/s390/mm/Makefile |  2 +-
 arch/x86/Kconfig  |  2 +-
 arch/x86/Kconfig.debug|  2 +-
 arch/x86/mm/Makefile  |  2 +-
 kernel/configs/debug.config   |  1 -
 mm/Kconfig.debug  | 12 +++-
 mm/Makefile   |  2 +-
 18 files changed, 26 insertions(+), 25 deletions(-)

-- 
2.25.1




[PATCH v2] ASoC: imx-audmix: remove cpu_mclk which is from cpu dai device

2025-02-12 Thread Shengjiu Wang
When defer probe happens, there may be below error:

platform 5982.sai: Resources present before probing

The cpu_mclk clock is from the cpu dai device, if it is not released,
then the cpu dai device probe will fail for the second time.

The cpu_mclk is used to get rate for rate constraint, rate constraint
may be specific for each platform, which is not necessary for machine
driver, so remove it.

Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Shengjiu Wang 
---
changes in v2:
- remove cpu_mclk and related constraint setting

 sound/soc/fsl/imx-audmix.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 231400661c90..50ecc5f51100 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -23,7 +23,6 @@ struct imx_audmix {
struct snd_soc_card card;
struct platform_device *audmix_pdev;
struct platform_device *out_pdev;
-   struct clk *cpu_mclk;
int num_dai;
struct snd_soc_dai_link *dai;
int num_dai_conf;
@@ -32,34 +31,11 @@ struct imx_audmix {
struct snd_soc_dapm_route *dapm_routes;
 };
 
-static const u32 imx_audmix_rates[] = {
-   8000, 12000, 16000, 24000, 32000, 48000, 64000, 96000,
-};
-
-static const struct snd_pcm_hw_constraint_list imx_audmix_rate_constraints = {
-   .count = ARRAY_SIZE(imx_audmix_rates),
-   .list = imx_audmix_rates,
-};
-
 static int imx_audmix_fe_startup(struct snd_pcm_substream *substream)
 {
-   struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
-   struct imx_audmix *priv = snd_soc_card_get_drvdata(rtd->card);
struct snd_pcm_runtime *runtime = substream->runtime;
-   struct device *dev = rtd->card->dev;
-   unsigned long clk_rate = clk_get_rate(priv->cpu_mclk);
int ret;
 
-   if (clk_rate % 24576000 == 0) {
-   ret = snd_pcm_hw_constraint_list(runtime, 0,
-SNDRV_PCM_HW_PARAM_RATE,
-&imx_audmix_rate_constraints);
-   if (ret < 0)
-   return ret;
-   } else {
-   dev_warn(dev, "mclk may be not supported %lu\n", clk_rate);
-   }
-
ret = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
   1, 8);
if (ret < 0)
@@ -323,13 +299,6 @@ static int imx_audmix_probe(struct platform_device *pdev)
}
put_device(&cpu_pdev->dev);
 
-   priv->cpu_mclk = devm_clk_get(&cpu_pdev->dev, "mclk1");
-   if (IS_ERR(priv->cpu_mclk)) {
-   ret = PTR_ERR(priv->cpu_mclk);
-   dev_err(&cpu_pdev->dev, "failed to get DAI mclk1: %d\n", ret);
-   return ret;
-   }
-
priv->audmix_pdev = audmix_pdev;
priv->out_pdev  = cpu_pdev;
 
-- 
2.34.1




Re: [PATCH 4/4] mm: Rename GENERIC_PTDUMP and PTDUMP_CORE

2025-02-12 Thread Christophe Leroy




Le 13/02/2025 à 05:09, Anshuman Khandual a écrit :

Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
is confusing as they sound very similar and does not differentiate between
platform's feature subscription and feature enablement for ptdump. Rename
the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve
readability.


For me GENERIC_PTDUMP is more explicit and similar to GENERIC_IOMAP or 
GENERIC_IOREMAP or GENERIC_GETTIMEOFDAY: The arch provides the necessary 
helpers to use the generic implementation.


For me ARCH_HAS_PTDUMP just mean't that an architecture implements 
PTDUMP, it doesn't mean it does it by using the generic infrastructure.


For instance, arm32 implements PTDUMP but without using the generic one 
so I would say that arm32 has PTDUMP and expect it to select ARCH_HAS_PTDUMP






[next-20250212] FStests generic/451 on EXT4 FS resulting in kernel OOPs

2025-02-12 Thread Venkat Rao Bagalkote

Greetings!!!


I am observing kernel OOPs, while running FStests generic/451 on EXT4 
with linux-next kernel(next-20250212) on IBM Power Servers.



Issue is seen on: next-20250212

Issue not seen on: next-20250210


Traces:

[ 2977.768678] run fstests generic/451 at 2025-02-12 16:42:14
[ 3001.242006] list_add double add: new=ce2398c8, 
prev=ce2398c8, next=c000c1f2f0b8.

[ 3001.242047] [ cut here ]
[ 3001.242052] kernel BUG at lib/list_debug.c:35!
[ 3001.242059] Oops: Exception in kernel mode, sig: 5 [#1]
[ 3001.242065] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=8192 NUMA pSeries
[ 3001.242072] Modules linked in: overlay dm_zero dm_thin_pool 
dm_persistent_data dm_bio_prison dm_snapshot dm_bufio dm_flakey ext4 
mbcache jbd2 loop dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct 
nft_chain_nat nf_nat nf_conntrack bonding nf_defrag_ipv6 nf_defrag_ipv4 
tls ip_set rfkill nf_tables nfnetlink pseries_rng aes_gcm_p10_crypto 
crypto_simd vmx_crypto xfs sr_mod sd_mod cdrom sg ibmvscsi ibmveth 
scsi_transport_srp fuse [last unloaded: scsi_debug]
[ 3001.242165] CPU: 26 UID: 0 PID: 894003 Comm: kworker/u228:17 Not 
tainted 6.14.0-rc2-next-20250212 #1
[ 3001.242174] Hardware name: IBM,8375-42A POWER9 (architected) 0x4e0202 
0xf05 of:IBM,FW950.80 (VL950_131) hv:phyp pSeries

[ 3001.242183] Workqueue: loop0 loop_workfn [loop]
[ 3001.242194] NIP:  c090d528 LR: c090d524 CTR: 
007088ec
[ 3001.242201] REGS: c000e5adfa70 TRAP: 0700   Not tainted 
(6.14.0-rc2-next-20250212)
[ 3001.242208] MSR:  8282b033   
CR: 2800024f  XER: 0009

[ 3001.242229] CFAR: c0224238 IRQMASK: 1
[ 3001.242229] GPR00: c090d524 c000e5adfd10 c1657500 
0058
[ 3001.242229] GPR04: c01179a87c88 c01179a96000 c000e5adfb58 
00117781
[ 3001.242229] GPR08: 0027   
0001
[ 3001.242229] GPR12: c2a49cd0 cf75ff00 c01abf00 
c000fda72fc0
[ 3001.242229] GPR16:    

[ 3001.242229] GPR20: c7acbc00 04208060 ce239880 
fef7
[ 3001.242229] GPR24: 0402 c000924b8fc0 c000c1f2f07c 
c000c1f2f000
[ 3001.242229] GPR28: c000c1f2f0b8 ce2398c8 ce2398c8 
c000c1f2f0b8

[ 3001.242309] NIP [c090d528] __list_add_valid_or_report+0x158/0x15c
[ 3001.242318] LR [c090d524] __list_add_valid_or_report+0x154/0x15c
[ 3001.242324] Call Trace:
[ 3001.242327] [c000e5adfd10] [c090d524] 
__list_add_valid_or_report+0x154/0x15c (unreliable)
[ 3001.242336] [c000e5adfd90] [c008073c359c] 
loop_process_work+0x594/0x630 [loop]
[ 3001.242344] [c000e5adfe40] [c019dc5c] 
process_one_work+0x1fc/0x4bc
[ 3001.242354] [c000e5adfef0] [c019ebec] 
worker_thread+0x344/0x508

[ 3001.242362] [c000e5adff90] [c01ac024] kthread+0x12c/0x14c
[ 3001.242370] [c000e5adffe0] [c000df98] 
start_kernel_thread+0x14/0x18
[ 3001.242377] Code: 4b916cf9 6000 0fe0 7c0802a6 7c641b78 
3c62ffe5 7fe6fb78 7fc5f378 386343a0 f8010090 4b916cd1 6000 
<0fe0> 3c4c00d5 38429fd4 fbe1fff8

[ 3001.242407] ---[ end trace  ]---
[ 3001.28] pstore: backend (nvram) writing error (-1)
[ 3001.284452]
[ 3002.284455] Kernel panic - not syncing: Fatal exception
[ 3002.431023] Rebooting in 10 seconds..


Regards,

Venkat.




Re: [RESEND v4 0/3] mm/pkey: Add PKEY_UNRESTRICTED macro

2025-02-12 Thread Catalin Marinas
On Mon, Jan 13, 2025 at 05:06:16PM +, Yury Khrustalev wrote:
> Add PKEY_UNRESTRICTED macro to mman.h and use it in selftests.
> 
> For context, this change will also allow for more consistent update of the
> Glibc manual which in turn will help with introducing memory protection
> keys on AArch64 targets.
[...]
> Yury Khrustalev (3):
>   mm/pkey: Add PKEY_UNRESTRICTED macro
>   selftests/mm: Use PKEY_UNRESTRICTED macro
>   selftests/powerpc: Use PKEY_UNRESTRICTED macro
> 
>  include/uapi/asm-generic/mman-common.h   | 1 +
>  tools/testing/selftests/mm/mseal_test.c  | 6 +++---
>  tools/testing/selftests/mm/pkey-helpers.h| 3 ++-
>  tools/testing/selftests/mm/pkey_sighandler_tests.c   | 4 ++--
>  tools/testing/selftests/mm/protection_keys.c | 2 +-
>  tools/testing/selftests/powerpc/include/pkeys.h  | 2 +-
>  tools/testing/selftests/powerpc/mm/pkey_exec_prot.c  | 2 +-
>  tools/testing/selftests/powerpc/mm/pkey_siginfo.c| 2 +-
>  tools/testing/selftests/powerpc/ptrace/core-pkey.c   | 6 +++---
>  tools/testing/selftests/powerpc/ptrace/ptrace-pkey.c | 6 +++---
>  10 files changed, 18 insertions(+), 16 deletions(-)

Andrew, Arnd - are you ok if I take these patches through the arm64
tree?

Thanks.

-- 
Catalin



Re: [PATCH v13 5/5] arm64: introduce copy_mc_to_kernel() implementation

2025-02-12 Thread Catalin Marinas
On Mon, Dec 09, 2024 at 10:42:57AM +0800, Tong Tiangen wrote:
> The copy_mc_to_kernel() helper is memory copy implementation that handles
> source exceptions. It can be used in memory copy scenarios that tolerate
> hardware memory errors(e.g: pmem_read/dax_copy_to_iter).
> 
> Currently, only x86 and ppc support this helper, Add this for ARM64 as
> well, if ARCH_HAS_COPY_MC is defined, by implementing copy_mc_to_kernel()
> and memcpy_mc() functions.
> 
> Because there is no caller-saved GPR is available for saving "bytes not
> copied" in memcpy(), the memcpy_mc() is referenced to the implementation
> of copy_from_user(). In addition, the fixup of MOPS insn is not considered
> at present.

Same question as on the previous patch, can we not avoid the memcpy()
duplication if the only difference is entries in the exception table?
IIUC in patch 2 fixup_exception() even ignores the new type. The error
must come on the do_sea() path.

-- 
Catalin



Re: [PATCH v2 05/12] dt-bindings: dma: Convert fsl,elo*-dma to YAML

2025-02-12 Thread Rob Herring
On Fri, Feb 07, 2025 at 10:30:22PM +0100, J. Neuschäfer wrote:
> The devicetree bindings for Freescale DMA engines have so far existed as
> a text file. This patch converts them to YAML, and specifies all the
> compatible strings currently in use in arch/powerpc/boot/dts.
> 
> Signed-off-by: J. Neuschäfer 
> ---
> 
> V2:
> - remove unnecessary multiline markers
> - fix additionalProperties to always be false
> - add description/maxItems to interrupts
> - add missing #address-cells/#size-cells properties
> - convert "Note on DMA channel compatible properties" to YAML by listing
>   fsl,ssi-dma-channel as a valid compatible value
> - fix property ordering in examples: compatible and reg come first
> - add missing newlines in examples
> - trim subject line (remove "bindings")
> ---
>  .../devicetree/bindings/dma/fsl,elo-dma.yaml   | 140 ++
>  .../devicetree/bindings/dma/fsl,elo3-dma.yaml  | 123 +
>  .../devicetree/bindings/dma/fsl,eloplus-dma.yaml   | 134 ++
>  .../devicetree/bindings/powerpc/fsl/dma.txt| 204 
> -
>  4 files changed, 397 insertions(+), 204 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml 
> b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml
> new file mode 100644
> index 
> ..3d8be9973fb98891a73cb701c1f983a63f444837
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml
> @@ -0,0 +1,140 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/fsl,elo-dma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale Elo DMA Controller
> +
> +maintainers:
> +  - J. Neuschäfer 
> +
> +description:
> +  This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
> +  series chips such as mpc8315, mpc8349, mpc8379 etc.
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +  - fsl,mpc8313-dma
> +  - fsl,mpc8315-dma
> +  - fsl,mpc8323-dma
> +  - fsl,mpc8347-dma
> +  - fsl,mpc8349-dma
> +  - fsl,mpc8360-dma
> +  - fsl,mpc8377-dma
> +  - fsl,mpc8378-dma
> +  - fsl,mpc8379-dma
> +  - const: fsl,elo-dma
> +
> +  reg:
> +maxItems: 1
> +description:
> +  DMA General Status Register, i.e. DGSR which contains status for
> +  all the 4 DMA channels.
> +
> +  cell-index:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Controller index. 0 for controller @ 0x8100.
> +
> +  ranges: true
> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 1
> +
> +  interrupts:
> +maxItems: 1
> +description: Controller interrupt.
> +
> +required:
> +  - compatible
> +  - reg
> +
> +patternProperties:
> +  "^dma-channel@.*$":

You need to define the unit-address format.

> +type: object
> +additionalProperties: false
> +
> +properties:
> +  compatible:
> +oneOf:
> +  # native DMA channel
> +  - items:
> +  - enum:
> +  - fsl,mpc8315-dma-channel
> +  - fsl,mpc8323-dma-channel
> +  - fsl,mpc8347-dma-channel
> +  - fsl,mpc8349-dma-channel
> +  - fsl,mpc8360-dma-channel
> +  - fsl,mpc8377-dma-channel
> +  - fsl,mpc8378-dma-channel
> +  - fsl,mpc8379-dma-channel
> +  - const: fsl,elo-dma-channel
> +
> +  # audio DMA channel, see fsl,ssi.yaml
> +  - const: fsl,ssi-dma-channel
> +
> +  reg:
> +maxItems: 1
> +
> +  cell-index:
> +description: DMA channel index starts at 0.
> +
> +  interrupts:
> +maxItems: 1
> +description:
> +  Per-channel interrupt. Only necessary if no controller interrupt 
> has
> +  been provided.
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +dma@82a8 {

dma-controller@...

> +compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
> +reg = <0x82a8 4>;
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges = <0 0x8100 0x1a4>;
> +interrupt-parent = <&ipic>;

Drop interrupt-parent everywhere.

> +interrupts = <71 8>;
> +cell-index = <0>;
> +
> +dma-channel@0 {
> +compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
> +reg = <0 0x80>;
> +cell-index = <0>;
> +interrupt-parent = <&ipic>;
> +interrupts = <71 8>;
> +};
> +
> +dma-channel@80 {
> +compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
> +reg = <0x80 0x80>;
> +cell-index = <1>;
> +interrupt-parent = <&ipic>;
> +interrupts = <71 8>;
> +};
> +
> +dma-channel@100 {
> +compatible = "fsl

Re: [kvm-unit-tests PATCH v2 15/18] Add kvmtool_params to test specification

2025-02-12 Thread Alexandru Elisei
Hi Drew,

On Wed, Feb 12, 2025 at 04:56:42PM +0100, Andrew Jones wrote:
> On Tue, Feb 11, 2025 at 03:03:09PM +, Alexandru Elisei wrote:
> > Hi Drew,
> > 
> > On Thu, Jan 23, 2025 at 04:53:29PM +0100, Andrew Jones wrote:
> > > On Mon, Jan 20, 2025 at 04:43:13PM +, Alexandru Elisei wrote:
> > > > arm/arm64 supports running tests under kvmtool, but kvmtool's syntax for
> > > > running a virtual machine is different than qemu's. To run tests using 
> > > > the
> > > > automated test infrastructure, add a new test parameter, kvmtool_params.
> > > > The parameter serves the exact purpose as qemu_params/extra_params, but 
> > > > using
> > > > kvmtool's syntax.
> > > 
> > > The need for qemu_params and kvmtool_params makes more sense to me now
> > > that I see the use in unittests.cfg (I wonder if we can't rearrange this
> > > series to help understand these things up front?). There's a lot of
> > 
> > Certainly, I'll move it closer to the beginning of the series.
> > 
> > > duplication, though, with having two sets of params since the test-
> > > specific inputs always have to be duplicated. To avoid the duplication
> > > I think we can use extra_params for '-append' and '--params' by
> > > parametrizing the option name for "params" (-append / --params) and then
> > > create qemu_opts and kvmtool_opts for extra options like --pmu, --mem,
> > > and irqchip.
> > 
> > How about something like this (I am using selftest-setup as an example, all 
> > the
> > other test definitions would be similarly modified):
> > 
> > diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> > index 2bdad67d5693..3009305ba2d3 100644
> > --- a/arm/unittests.cfg
> > +++ b/arm/unittests.cfg
> > @@ -15,7 +15,9 @@
> >  [selftest-setup]
> >  file = selftest.flat
> >  smp = 2
> > -extra_params = -m 256 -append 'setup smp=2 mem=256'
> > +test_args = setup smp=2 mem=256
> > +qemu_params = -m 256
> > +kvmtool_params = --mem 256
> >  groups = selftest
> > 
> > I was thinking about using 'test_args' instead of 'extra_params' to avoid 
> > any
> > confusion between the two, and to match how they are passed to a test
> > - they are in the argv main's argument.
> 
> Yes, this looks good and test_args is better than my suggestion in the
> other mail of 'cmdline_options' since "cmdline" would be ambiguous with
> the test's cmdline and the vmm's cmdline.
> 
> > 
> > Also, should I change the test definitions for all the other architectures?
> > It's not going to be possible for me to test all the changes.
> 
> We should be safe with an s/extra_params/qemu_params/ change for all
> architectures and CI is pretty good, so we'd have good confidence
> if it passes, but, I think we should keep extra_params as a qemu_params
> alias anyway since it's possible that people have wrapped kvm-unit-tests
> in test harnesses which generate unittests.cfg files.

Sounds good, split extra_params into test_args and qemu_params in all
unittests.cfg files, and keep extra_params as an alias for qemu_params.

I was thinking that maybe I should send that as a separate patch, to make
sure it gets the visibility it deserves from the other maintainers, instead
of it being buried in a 18 patch series. What do you think?

Thanks,
Alex



Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage()

2025-02-12 Thread Catalin Marinas
On Mon, Dec 09, 2024 at 10:42:56AM +0800, Tong Tiangen wrote:
> Currently, many scenarios that can tolerate memory errors when copying page
> have been supported in the kernel[1~5], all of which are implemented by
> copy_mc_[user]_highpage(). arm64 should also support this mechanism.
> 
> Due to mte, arm64 needs to have its own copy_mc_[user]_highpage()
> architecture implementation, macros __HAVE_ARCH_COPY_MC_HIGHPAGE and
> __HAVE_ARCH_COPY_MC_USER_HIGHPAGE have been added to control it.
> 
> Add new helper copy_mc_page() which provide a page copy implementation with
> hardware memory error safe. The code logic of copy_mc_page() is the same as
> copy_page(), the main difference is that the ldp insn of copy_mc_page()
> contains the fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR, therefore, the
> main logic is extracted to copy_page_template.S. In addition, the fixup of
> MOPS insn is not considered at present.

Could we not add the exception table entry permanently but ignore the
exception table entry if it's not on the do_sea() path? That would save
some code duplication.

> diff --git a/arch/arm64/lib/copy_mc_page.S b/arch/arm64/lib/copy_mc_page.S
> new file mode 100644
> index ..51564828c30c
> --- /dev/null
> +++ b/arch/arm64/lib/copy_mc_page.S
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Copy a page from src to dest (both are page aligned) with memory error 
> safe
> + *
> + * Parameters:
> + *   x0 - dest
> + *   x1 - src
> + * Returns:
> + *   x0 - Return 0 if copy success, or -EFAULT if anything goes wrong
> + *while copying.
> + */
> + .macro ldp1 reg1, reg2, ptr, val
> + KERNEL_MEM_ERR(9998f, ldp \reg1, \reg2, [\ptr, \val])
> + .endm
> +
> +SYM_FUNC_START(__pi_copy_mc_page)
> +#include "copy_page_template.S"
> +
> + mov x0, #0
> + ret
> +
> +9998:mov x0, #-EFAULT
> + ret
> +
> +SYM_FUNC_END(__pi_copy_mc_page)
> +SYM_FUNC_ALIAS(copy_mc_page, __pi_copy_mc_page)
> +EXPORT_SYMBOL(copy_mc_page)
[...]
> diff --git a/arch/arm64/lib/copy_page_template.S 
> b/arch/arm64/lib/copy_page_template.S
> new file mode 100644
> index ..f96c7988c93d
> --- /dev/null
> +++ b/arch/arm64/lib/copy_page_template.S
> @@ -0,0 +1,70 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + */
> +
> +/*
> + * Copy a page from src to dest (both are page aligned)
> + *
> + * Parameters:
> + *   x0 - dest
> + *   x1 - src
> + */
> +
> +#ifdef CONFIG_AS_HAS_MOPS
> + .arch_extension mops
> +alternative_if_not ARM64_HAS_MOPS
> + b   .Lno_mops
> +alternative_else_nop_endif
> +
> + mov x2, #PAGE_SIZE
> + cpypwn  [x0]!, [x1]!, x2!
> + cpymwn  [x0]!, [x1]!, x2!
> + cpyewn  [x0]!, [x1]!, x2!
> + ret
> +.Lno_mops:
> +#endif
[...]

So if we have FEAT_MOPS, the machine check won't work?

Kristina is going to post MOPS support for the uaccess routines soon.
You can see how they are wired up and do something similar here.

But I'd prefer if we had the same code, only the exception table entry
treated differently. Similarly for the MTE tag copying.

-- 
Catalin



Re: [RESEND v4 0/3] mm/pkey: Add PKEY_UNRESTRICTED macro

2025-02-12 Thread Andrew Morton
On Wed, 12 Feb 2025 17:24:58 + Catalin Marinas  
wrote:

> On Mon, Jan 13, 2025 at 05:06:16PM +, Yury Khrustalev wrote:
> > Add PKEY_UNRESTRICTED macro to mman.h and use it in selftests.
> > 
> > For context, this change will also allow for more consistent update of the
> > Glibc manual which in turn will help with introducing memory protection
> > keys on AArch64 targets.
> [...]
> > Yury Khrustalev (3):
> >   mm/pkey: Add PKEY_UNRESTRICTED macro
> >   selftests/mm: Use PKEY_UNRESTRICTED macro
> >   selftests/powerpc: Use PKEY_UNRESTRICTED macro
> > 
> >  include/uapi/asm-generic/mman-common.h   | 1 +
> >  tools/testing/selftests/mm/mseal_test.c  | 6 +++---
> >  tools/testing/selftests/mm/pkey-helpers.h| 3 ++-
> >  tools/testing/selftests/mm/pkey_sighandler_tests.c   | 4 ++--
> >  tools/testing/selftests/mm/protection_keys.c | 2 +-
> >  tools/testing/selftests/powerpc/include/pkeys.h  | 2 +-
> >  tools/testing/selftests/powerpc/mm/pkey_exec_prot.c  | 2 +-
> >  tools/testing/selftests/powerpc/mm/pkey_siginfo.c| 2 +-
> >  tools/testing/selftests/powerpc/ptrace/core-pkey.c   | 6 +++---
> >  tools/testing/selftests/powerpc/ptrace/ptrace-pkey.c | 6 +++---
> >  10 files changed, 18 insertions(+), 16 deletions(-)
> 
> Andrew, Arnd - are you ok if I take these patches through the arm64
> tree?

Sure.



Re: [PATCH v13 2/5] arm64: add support for ARCH_HAS_COPY_MC

2025-02-12 Thread Catalin Marinas
(catching up with old threads)

On Mon, Dec 09, 2024 at 10:42:54AM +0800, Tong Tiangen wrote:
> For the arm64 kernel, when it processes hardware memory errors for
> synchronize notifications(do_sea()), if the errors is consumed within the
> kernel, the current processing is panic. However, it is not optimal.
> 
> Take copy_from/to_user for example, If ld* triggers a memory error, even in
> kernel mode, only the associated process is affected. Killing the user
> process and isolating the corrupt page is a better choice.

I agree that killing the user process and isolating the page is a better
choice but I don't see how the latter happens after this patch. Which
page would be isolated?

> Add new fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR to identify insn
> that can recover from memory errors triggered by access to kernel memory,
> and this fixup type is used in __arch_copy_to_user(), This make the regular
> copy_to_user() will handle kernel memory errors.

Is the assumption that the error on accessing kernel memory is
transient? There's no way to isolate the kernel page and also no point
in isolating the destination page either.

-- 
Catalin



Re: [PATCH v2 03/12] dt-bindings: crypto: Convert fsl,sec-2.0 to YAML

2025-02-12 Thread Rob Herring
On Fri, Feb 07, 2025 at 10:30:20PM +0100, J. Neuschäfer wrote:
> Convert the Freescale security engine (crypto accelerator) binding from
> text form to YAML. The list of compatible strings reflects what was
> previously described in prose; not all combinations occur in existing
> devicetrees.
> 
> Signed-off-by: J. Neuschäfer 
> ---
> 
> V2:
> - several improvements suggested by Rob Herring:
>   - remove unnecessary multiline markers
>   - constrain fsl,num-channels to enum: [1,4]
>   - constrain fsl,channel-fifo-len to plausible limits
>   - constrain fsl,exec-units-mask to maximum=0xfff
> - trim subject line (remove "binding")
> ---
>  .../devicetree/bindings/crypto/fsl,sec2.0.yaml | 142 
> +
>  .../devicetree/bindings/crypto/fsl-sec2.txt|  65 --
>  2 files changed, 142 insertions(+), 65 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml 
> b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml
> new file mode 100644
> index 
> ..0b82f3b68b5f82e7fb52d292a623d452c1cdb059
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml
> @@ -0,0 +1,142 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/crypto/fsl,sec2.0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale SoC SEC Security Engines versions 1.x-2.x-3.x
> +
> +maintainers:
> +  - J. Neuschäfer 

> +
> +properties:
> +  compatible:
> +description:
> +  Should contain entries for this and backward compatible SEC versions,
> +  high to low. Warning - SEC1 and SEC2 are mutually exclusive.
> +oneOf:
> +  - items:
> +  - const: fsl,sec3.3
> +  - const: fsl,sec3.1
> +  - const: fsl,sec3.0
> +  - const: fsl,sec2.4
> +  - const: fsl,sec2.2
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec3.1
> +  - const: fsl,sec3.0
> +  - const: fsl,sec2.4
> +  - const: fsl,sec2.2
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec3.0
> +  - const: fsl,sec2.4
> +  - const: fsl,sec2.2
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec2.4
> +  - const: fsl,sec2.2
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec2.2
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec2.1
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec2.0
> +  - items:
> +  - const: fsl,sec1.2
> +  - const: fsl,sec1.0
> +  - items:
> +  - const: fsl,sec1.0
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  fsl,num-channels:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [ 1, 4 ]
> +description: An integer representing the number of channels available.
> +
> +  fsl,channel-fifo-len:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +maximum: 100
> +description:
> +  An integer representing the number of descriptor pointers each channel
> +  fetch fifo can hold.
> +
> +  fsl,exec-units-mask:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +maximum: 0xfff
> +description: |
> +  The bitmask representing what execution units (EUs) are available.
> +  EU information should be encoded following the SEC's Descriptor Header
> +  Dword EU_SEL0 field documentation, i.e. as follows:
> +
> +bit 0  = reserved - should be 0
> +bit 1  = set if SEC has the ARC4 EU (AFEU)
> +bit 2  = set if SEC has the DES/3DES EU (DEU)
> +bit 3  = set if SEC has the message digest EU (MDEU/MDEU-A)
> +bit 4  = set if SEC has the random number generator EU (RNG)
> +bit 5  = set if SEC has the public key EU (PKEU)
> +bit 6  = set if SEC has the AES EU (AESU)
> +bit 7  = set if SEC has the Kasumi EU (KEU)
> +bit 8  = set if SEC has the CRC EU (CRCU)
> +bit 11 = set if SEC has the message digest EU extended alg set 
> (MDEU-B)
> +
> +  remaining bits are reserved for future SEC EUs.
> +
> +  fsl,descriptor-types-mask:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> +  The bitmask representing what descriptors are available. Descriptor 
> type
> +  information should be encoded following the SEC's Descriptor Header 
> Dword
> +  DESC_TYPE field documentation, i.e. as follows:
> +
> +bit 0  = set if SEC supports the aesu_ctr_nonsnoop desc. type
> +bit 1  = set if SEC supports the ipsec_esp descriptor type
> +bit 2  = set if SEC supports the common_nonsnoop desc. type
> +bit 

Re: [PATCH v2 08/12] dt-bindings: spi: Convert Freescale SPI bindings to YAML

2025-02-12 Thread Rob Herring
On Fri, Feb 07, 2025 at 10:30:25PM +0100, J. Neuschäfer wrote:
> fsl-spi.txt contains the bindings for the fsl,spi and fsl,espi
> contollers. Convert them to YAML.
> 
> Signed-off-by: J. Neuschäfer 
> ---
> 
> V2:
> - add missing end-of-document ("...") markers
> - add missing constraints to interrupts, fsl,espi-num-chipselects,
>   fsl,csbef and fsl,csaft properties
> - remove unnecessary type from clock-frequency property
> - fix property order to comply with dts coding style
> ---
>  .../devicetree/bindings/spi/fsl,espi.yaml  | 64 +++
>  Documentation/devicetree/bindings/spi/fsl,spi.yaml | 73 
> ++
>  Documentation/devicetree/bindings/spi/fsl-spi.txt  | 62 --
>  3 files changed, 137 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/fsl,espi.yaml 
> b/Documentation/devicetree/bindings/spi/fsl,espi.yaml
> new file mode 100644
> index 
> ..c504b7957dde39086ef7d7a7550d6169cf5ec407
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/fsl,espi.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/fsl,espi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale eSPI (Enhanced Serial Peripheral Interface) controller
> +
> +maintainers:
> +  - J. Neuschäfer 
> +
> +properties:
> +  compatible:
> +const: fsl,mpc8536-espi
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  fsl,espi-num-chipselects:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [ 1, 4 ]
> +description: The number of the chipselect signals.
> +
> +  fsl,csbef:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 15
> +description: Chip select assertion time in bits before frame starts
> +
> +  fsl,csaft:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 15
> +description: Chip select negation time in bits after frame ends
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - fsl,espi-num-chipselects
> +
> +allOf:
> +  - $ref: spi-controller.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +spi@11 {
> +compatible = "fsl,mpc8536-espi";
> +reg = <0x11 0x1000>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +interrupts = <53 0x2>;
> +interrupt-parent = <&mpic>;

Drop interrupt-parent. Otherwise,

Reviewed-by: Rob Herring (Arm) 

> +fsl,espi-num-chipselects = <4>;
> +fsl,csbef = <1>;
> +fsl,csaft = <1>;
> +};
> +
> +...



Re: [PATCH v2 10/12] dt-bindings: memory-controllers: Add fsl,elbc-gpcm-uio

2025-02-12 Thread Rob Herring (Arm)


On Fri, 07 Feb 2025 22:30:27 +0100, J. Neuschäfer wrote:
> Formalize the binding already supported by the uio_fsl_elbc_gpcm.c
> driver.
> 
> Signed-off-by: J. Neuschäfer 
> ---
> 
> V2:
> - split out from fsl,elbc patch
> - add description
> - remove "device_type" property
> - move to bindings/memory-controllers
> ---
>  .../memory-controllers/fsl,elbc-gpcm-uio.yaml  | 59 
> ++
>  1 file changed, 59 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) 




[PATCH] tools/perf: Add check to tool pmu tests to ensure if the event is valid

2025-02-12 Thread Athira Rajeev
"Tool PMU" tests fails on powerpc as below:

   12.1: Parsing without PMU name:
   --- start ---
   test child forked, pid 48492
   Using CPUID 0x00800200
   Attempt to add: tool/duration_time/
   ..after resolving event: tool/config=0x1/
   duration_time -> tool/duration_time/
   Attempt to add: tool/user_time/
   ..after resolving event: tool/config=0x2/
   user_time -> tool/user_time/
   Attempt to add: tool/system_time/
   ..after resolving event: tool/config=0x3/
   system_time -> tool/system_time/
   Attempt to add: tool/has_pmem/
   ..after resolving event: tool/config=0x4/
   has_pmem -> tool/has_pmem/
   Attempt to add: tool/num_cores/
   ..after resolving event: tool/config=0x5/
   num_cores -> tool/num_cores/
   Attempt to add: tool/num_cpus/
   ..after resolving event: tool/config=0x6/
   num_cpus -> tool/num_cpus/
   Attempt to add: tool/num_cpus_online/
   ..after resolving event: tool/config=0x7/
   num_cpus_online -> tool/num_cpus_online/
   Attempt to add: tool/num_dies/
   ..after resolving event: tool/config=0x8/
   num_dies -> tool/num_dies/
   Attempt to add: tool/num_packages/
   ..after resolving event: tool/config=0x9/
   num_packages -> tool/num_packages/

    unexpected signal (11) 
   12.1: Parsing without PMU name  : FAILED!

Same fail is observed for "Parsing with PMU name" as well.

The testcase loops through events in tool_pmu__for_each_event()
and access event name using "tool_pmu__event_to_str()".
Here tool_pmu__event_to_str returns null for "slots" event
and "system_tsc_freq" event. These two events are only applicable
for arm64 and x86 respectively. So the function tool_pmu__event_to_str()
skips for unsupported events and returns null. This null value is
causing testcase fail.

To address this in "Tool PMU" testcase, add a helper function
tool_pmu__all_event_to_str() which returns the name for all
events mapping to the tool_pmu_event index including the
skipped ones. So that even if its a skipped event, the
helper function helps to resolve the tool_pmu_event index to
its mapping event name. Update the testcase to check for null event
names before proceeding the test.

Signed-off-by: Athira Rajeev 
---
 tools/perf/tests/tool_pmu.c | 12 
 tools/perf/util/tool_pmu.c  | 17 +
 tools/perf/util/tool_pmu.h  |  1 +
 3 files changed, 30 insertions(+)

diff --git a/tools/perf/tests/tool_pmu.c b/tools/perf/tests/tool_pmu.c
index 187942b749b7..e468e5fb3c73 100644
--- a/tools/perf/tests/tool_pmu.c
+++ b/tools/perf/tests/tool_pmu.c
@@ -19,6 +19,18 @@ static int do_test(enum tool_pmu_event ev, bool with_pmu)
return TEST_FAIL;
}
 
+   /*
+* if tool_pmu__event_to_str returns NULL, Check if the event is
+* valid for the platform.
+* Example:
+* slots event is only on arm64.
+* system_tsc_freq event is only on x86.
+*/
+   if (!tool_pmu__event_to_str(ev) && 
tool_pmu__skip_event(tool_pmu__all_event_to_str(ev))) {
+   ret = TEST_OK;
+   goto out;
+   }
+
if (with_pmu)
snprintf(str, sizeof(str), "tool/%s/", 
tool_pmu__event_to_str(ev));
else
diff --git a/tools/perf/util/tool_pmu.c b/tools/perf/util/tool_pmu.c
index 3a68debe7143..572422797f6e 100644
--- a/tools/perf/util/tool_pmu.c
+++ b/tools/perf/util/tool_pmu.c
@@ -60,6 +60,15 @@ int tool_pmu__num_skip_events(void)
return num;
 }
 
+/*
+ * tool_pmu__event_to_str returns only supported event names.
+ * For events which are supposed to be skipped in the platform,
+ * return NULL
+ *
+ * tool_pmu__all_event_to_str returns the name for all
+ * events mapping to the tool_pmu_event index including the
+ * skipped ones.
+ */
 const char *tool_pmu__event_to_str(enum tool_pmu_event ev)
 {
if ((ev > TOOL_PMU__EVENT_NONE && ev < TOOL_PMU__EVENT_MAX) &&
@@ -69,6 +78,14 @@ const char *tool_pmu__event_to_str(enum tool_pmu_event ev)
return NULL;
 }
 
+const char *tool_pmu__all_event_to_str(enum tool_pmu_event ev)
+{
+   if (ev > TOOL_PMU__EVENT_NONE && ev < TOOL_PMU__EVENT_MAX)
+   return tool_pmu__event_names[ev];
+
+   return NULL;
+}
+
 enum tool_pmu_event tool_pmu__str_to_event(const char *str)
 {
int i;
diff --git a/tools/perf/util/tool_pmu.h b/tools/perf/util/tool_pmu.h
index a60184859080..da76808ae71e 100644
--- a/tools/perf/util/tool_pmu.h
+++ b/tools/perf/util/tool_pmu.h
@@ -30,6 +30,7 @@ enum tool_pmu_event {
for ((ev) = TOOL_PMU__EVENT_DURATION_TIME; (ev) < TOOL_PMU__EVENT_MAX; 
ev++)
 
 const char *tool_pmu__event_to_str(enum tool_pmu_event ev);
+const char *tool_pmu__all_event_to_str(enum tool_pmu_event ev);
 enum tool_pmu_event tool_pmu__str_to_event(const char *str);
 bool tool_pmu__skip_event(const char *name);
 int tool_pmu__num_skip_events(void);
-- 
2.43.5




Re: [PATCH 0/9] Extend automarkup support for ABI symbols

2025-02-12 Thread Andrew Donnellan
On Wed, 2025-02-12 at 13:58 +0100, Mauro Carvalho Chehab wrote:
> > WARNING: Documentation/ABI/testing/sysfs-class-cxl not found
> 
> I need to double-check verify this one, as it didn't appear on
> my tests. Are you getting it against docs-next or linux-next?
> 

This is moved to obsolete/ by 5731d41af924b which was merged in rc1,
and will be moved again to removed/ by [0].

Andrew

[0]
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20250203072801.365551-3-...@linux.ibm.com/

-- 
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com   IBM Australia Limited