[PATCH v2 08/57] irqdomain: ppc: Switch to of_fwnode_handle()

2025-03-19 Thread Jiri Slaby (SUSE)
of_node_to_fwnode() is irqdomain's reimplementation of the "officially"
defined of_fwnode_handle(). The former is in the process of being
removed, so use the latter instead.

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Naveen N Rao 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
 arch/powerpc/platforms/pseries/msi.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ae4b549b5ca0..d8ccf2c9b98a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1897,7 +1897,7 @@ static int __init pnv_msi_allocate_domains(struct 
pci_controller *hose, unsigned
return -ENOMEM;
}
 
-   hose->msi_domain = 
pci_msi_create_irq_domain(of_node_to_fwnode(hose->dn),
+   hose->msi_domain = pci_msi_create_irq_domain(of_fwnode_handle(hose->dn),
 &pnv_msi_domain_info,
 hose->dev_domain);
if (!hose->msi_domain) {
diff --git a/arch/powerpc/platforms/pseries/msi.c 
b/arch/powerpc/platforms/pseries/msi.c
index f9d80111c322..5b191f70c088 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -628,7 +628,7 @@ static int __pseries_msi_allocate_domains(struct 
pci_controller *phb,
return -ENOMEM;
}
 
-   phb->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(phb->dn),
+   phb->msi_domain = pci_msi_create_irq_domain(of_fwnode_handle(phb->dn),
&pseries_msi_domain_info,
phb->dev_domain);
if (!phb->msi_domain) {
-- 
2.49.0




[PATCH v2 48/57] irqdomain: soc: Switch to irq_find_mapping()

2025-03-19 Thread Jiri Slaby (SUSE)
irq_linear_revmap() is deprecated, so remove all its uses and supersede
them by an identical call to irq_find_mapping().

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Qiang Zhao 
Cc: Christophe Leroy 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/soc/fsl/qe/qe_ic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index e5831c298ad6..e4b6ff2cc76b 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -344,7 +344,7 @@ static unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic)
if (irq == 0)
return 0;
 
-   return irq_linear_revmap(qe_ic->irqhost, irq);
+   return irq_find_mapping(qe_ic->irqhost, irq);
 }
 
 /* Return an interrupt vector or 0 if no interrupt is pending. */
@@ -360,7 +360,7 @@ static unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
if (irq == 0)
return 0;
 
-   return irq_linear_revmap(qe_ic->irqhost, irq);
+   return irq_find_mapping(qe_ic->irqhost, irq);
 }
 
 static void qe_ic_cascade_low(struct irq_desc *desc)
-- 
2.49.0




Re: [PATCH v2 00/57] irqdomain: Cleanups and Documentation

2025-03-19 Thread Jiri Slaby

On 19. 03. 25, 11:21, Andy Shevchenko wrote:

I am all to support the idea, but in some cases I would think of a bit
more work to be done to get rid of the of_fwnode_handle(np) in favour
of dev_fwnode(dev). Note, this is based on a brief look, I haven't any
example at hand right now.


Aah, that's the helper I was looking for!

I was about to use dev->fwnode directly (see the commit log for the 
Switch to irq_domain_create_*()), but that is not guaranteed to be 
always properly set.


Will use this instead in v3.

thanks,
--
js
suse labs



Re: [PATCH 1/4] i2c: pasemi: Add registers bits and switch to BIT()

2025-03-19 Thread Andi Shyti
Hi Sven,

On Sat, Feb 22, 2025 at 01:38:33PM +, Sven Peter via B4 Relay wrote:
> From: Sven Peter 
> 
> Add the missing register bits to the defines and also switch
> those to use the BIT macro which is much more readable than
> using hardcoded masks
> 
> Co-developed-by: Hector Martin 
> Signed-off-by: Hector Martin 
> Signed-off-by: Sven Peter 

Just this patch merged to i2c/i2c-host.

Patch 3 and 4 look good, just some comments on patch 2.

Thanks,
Andi



Re: [PATCH 2/4] i2c: pasemi: Improve error recovery

2025-03-19 Thread Andi Shyti
Hi Sven,

On Sat, Feb 22, 2025 at 01:38:34PM +, Sven Peter via B4 Relay wrote:
> The hardware (supposedly) has a 25ms timeout for clock stretching
> and the driver uses 100ms which should be plenty.

Can we add this lines as a comment to the define you are adding?

> The error
> reocvery itself is however lacking.

...

> -static void pasemi_smb_clear(struct pasemi_smbus *smbus)
> +static int pasemi_smb_clear(struct pasemi_smbus *smbus)
>  {
>   unsigned int status;
> + int timeout = TRANSFER_TIMEOUT_MS;
>  
>   status = reg_read(smbus, REG_SMSTA);
> +
> + /* First wait for the bus to go idle */
> + while ((status & (SMSTA_XIP | SMSTA_JAM)) && timeout--) {
> + msleep(1);

Please, use usleep_range for 1 millisecond timeout.

> + status = reg_read(smbus, REG_SMSTA);
> + }

You could use here readx_poll_timeout() here.

> +
> + if (timeout < 0) {
> + dev_warn(smbus->dev, "Bus is still stuck (status 0x%08x)\n", 
> status);

if it's an error, please use an error.

> + return -EIO;
> + }
> +
> + /* If any badness happened or there is data in the FIFOs, reset the 
> FIFOs */
> + if ((status & (SMSTA_MRNE | SMSTA_JMD | SMSTA_MTO | SMSTA_TOM | 
> SMSTA_MTN | SMSTA_MTA)) ||
> + !(status & SMSTA_MTE))

Please, fixe the alignment here.

> + pasemi_reset(smbus);
> +
> + /* Clear the flags */
>   reg_write(smbus, REG_SMSTA, status);
> +
> + return 0;
>  }
>  
>  static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
>  {
> - int timeout = 100;
> + int timeout = TRANSFER_TIMEOUT_MS;
>   unsigned int status;
>  
>   if (smbus->use_irq) {
>   reinit_completion(&smbus->irq_completion);
> - reg_write(smbus, REG_IMASK, SMSTA_XEN | SMSTA_MTN);
> - wait_for_completion_timeout(&smbus->irq_completion, 
> msecs_to_jiffies(100));
> + /* XEN should be set when a transaction terminates, whether due 
> to error or not */
> + reg_write(smbus, REG_IMASK, SMSTA_XEN);
> + wait_for_completion_timeout(&smbus->irq_completion, 
> msecs_to_jiffies(timeout));

what happens if the timeout expires?

>   reg_write(smbus, REG_IMASK, 0);
>   status = reg_read(smbus, REG_SMSTA);
>   } else {

...

>   struct pasemi_smbus *smbus = adapter->algo_data;
>   int ret, i;
>  
> - pasemi_smb_clear(smbus);
> + if (pasemi_smb_clear(smbus))
> + return -EIO;

Can we use

ret = ...
if (ret)
return ret;

This way we return whatever comes from pasemi_smb_clear().

>  
>   ret = 0;

This way we can remove this line, as well.

Andi



Re: [PATCH 1/3] MAINTAINERS: add myself as maintainer for the fsl-mc bus

2025-03-19 Thread Stuart Yoder
On Wed, Mar 19, 2025 at 4:43 AM Ioana Ciornei  wrote:

> Laurentiu left the company and is no longer involved with the fsl-mc
> bus. Remove him and add myself as maintainer.
>
> Signed-off-by: Ioana Ciornei 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ebf7fa9a814d..76b6db4074ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19633,7 +19633,7 @@ F:  include/linux/qnx6_fs.h
>
>  QORIQ DPAA2 FSL-MC BUS DRIVER
>  M: Stuart Yoder 
> -M: Laurentiu Tudor 
> +M: Ioana Ciornei 
>  L: linux-ker...@vger.kernel.org
>  S: Maintained
>  F: Documentation/ABI/stable/sysfs-bus-fsl-mc
>

Please remove me as well.

Thanks,
Stuaryt


Re: [PATCH bpf-next 11/11] bpf: Fall back to nospec for spec path verification

2025-03-19 Thread Luis Gerhorst
Alexei Starovoitov  writes:

> On Thu, Mar 13, 2025 at 10:57 AM Luis Gerhorst  wrote:
>> With increased limits this allows applying mitigations to large BPF
>> progs such as the Parca Continuous Profiler's prog. However, this
>> requires a jump-seq limit of 256k. In any case, the same principle
>> should apply to smaller programs therefore include it even if the limit
>> stays at 8k for now. Most programs in [1] only require a limit of 32k.
>
> Do you mean that without this change the verifier needs 256k
> jmp limit to load Parca's prog as unpriv due to speculative
> path exploration with push_stack ?
>

Only with this change Parca is loadable when manually enabling Spectre
defenses for privileged programs and setting the following limits:
- BPF_COMPLEXITY_LIMIT_JMP_SEQ=256k
- BPF_COMPLEXITY_LIMIT_SPEC_V1_VERIFICATION=128k
- BPF_COMPLEXITY_LIMIT_INSNS=32M

>
> And this change uses 4k as a trade-off between prog runtime
> and verification time ?
>

Yes, this change uses 4k to limited nested speculative path exploration.
At the top-level (i.e., on architectural paths), spawned speculative
paths are still explored.

>
> But tracing progs use bpf_probe_read_kernel(), so they're never going
> to be unpriv.
>

I'm sorry this was not clear. Parca is only used as an example here
to test whether this improves expressiveness in general.

If you do not see this as a favorable tradeoff (because of the code
complexity), I think it would be acceptable to drop the last patch for
now. The biggest improvements is already achieved with the other patches
as evident from the selftests. I can do a more exhaustive analysis on
patch 11 later.

>
>> @@ -2010,6 +2011,19 @@ static struct bpf_verifier_state *push_stack(struct 
>> bpf_verifier_env *env,
>> struct bpf_verifier_stack_elem *elem;
>> int err;
>>
>> +   if (!env->bypass_spec_v1 &&
>> +   cur->speculative &&
>
> Should this be
> (cur->speculative || speculative)
> ?

No, I think it will be unsafe to add `|| speculative` here. If we were
to return -EINVAL from push_stack() when pushing a speculative path from
a non-speculative path (e.g., in check_cond_jmp_op() through
sanitize_speculative_path()), this will cause do_check() to add an
lfence before the jump-op.

Here's a minimal example program:

A = true
B = true
if A goto e
f()
if B goto e
unsafe()
e:  exit

There are the following speculative and non-speculative paths
(`cur->speculative` and `speculative` referring to the value of the
push_stack() parameters):

- A = true
- B = true
- if A goto e
  - A && !cur->speculative && !speculative
- exit
  - !A && !cur->speculative && speculative
- f()
- if B goto e
  - B && cur->speculative && !speculative
- exit
  - !B && cur->speculative && speculative
- unsafe()

`|| speculative` might cause us to only add an lfence before `if A goto
e`, which would not be sufficient. Intel recommends adding the lfence
after the jump [1].

>
> In general I'm not convinced that the approach is safe.
>
> This recoverable EINVAL means that exploration under speculation
> stops early, but there could be more branches and they won't be
> sanitized with extra lfence.
> So speculative execution can still happen at later insns.
>

`goto process_bpf_exit` only causes us to stop analyzing this particular
path, not the rest of the program.

This is based on the assumption, that the lfence stops the CPU from ever
reaching those branches (if they are not reachable through other means).

>
> Similar concern in patch 7:
> + if (state->speculative && cur_aux(env)->nospec)
> +   goto process_bpf_exit;
>
> One lfence at this insn doesn't stop speculation until the program end.
> Only at this insn. The rest of the code is free to speculate.
>

Taking the program above as an example, this allows us to stop before
f() if an lfence was inserted there.

Fully patched program would be:

A = true
B = true
if A goto e
lfence
f()
if B goto e
unsafe()
e:  exit

In this example, all instructions after the lfence are dead code (and
with the lfence they are also dead code speculatively).

I believe this is in line with Intel's guidance [1]:

An LFENCE instruction or a serializing instruction will ensure that
no later instructions execute, even speculatively, until all prior
instructions complete locally. Developers might prefer LFENCE over a
serializing instruction because LFENCE may have lower latency.
Inserting an LFENCE instruction after a bounds check prevents later
operations from executing before the bound check completes.

With regards to the example, this implies that `if B goto e` will not
execute before `if A goto e` completes. Once `if A goto e` completes,
the CPU should find that the speculation was wrong and continue with
`exit`.

If there is any other path that leads to `if B goto e` (and 

Re: [PATCH 1/3] MAINTAINERS: add myself as maintainer for the fsl-mc bus

2025-03-19 Thread Ioana Ciornei
On Wed, Mar 19, 2025 at 05:45:19AM -0500, Stuart Yoder wrote:
> On Wed, Mar 19, 2025 at 4:43 AM Ioana Ciornei  wrote:
> 
> > Laurentiu left the company and is no longer involved with the fsl-mc
> > bus. Remove him and add myself as maintainer.
> >
> > Signed-off-by: Ioana Ciornei 
> > ---
> >  MAINTAINERS | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ebf7fa9a814d..76b6db4074ce 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19633,7 +19633,7 @@ F:  include/linux/qnx6_fs.h
> >
> >  QORIQ DPAA2 FSL-MC BUS DRIVER
> >  M: Stuart Yoder 
> > -M: Laurentiu Tudor 
> > +M: Ioana Ciornei 
> >  L: linux-ker...@vger.kernel.org
> >  S: Maintained
> >  F: Documentation/ABI/stable/sysfs-bus-fsl-mc
> >
> 
> Please remove me as well.

Ok, sure. I will update the patch in v2.




Re: [main-line][PowerPC]selftests/powerpc/signal: sigfuz fails

2025-03-19 Thread Venkat Rao Bagalkote

Thanks Michael and Maddy for the feedback.

On 18/03/25 4:20 pm, Madhavan Srinivasan wrote:

On 3/17/25 4:43 PM, Michael Ellerman wrote:

Venkat Rao Bagalkote writes:

Greetings!!

I am observing selftests/powerpc/signal:sigfuz test fails on linux
mainline repo on IBM Power10 systems.

The test passes on the kernel with commit head:
619f0b6fad524f08d493a98d55bac9ab8895e3a6 and fails on the kernel with
commit head: ce69b4019001407f9cd738dd2ba217b3a8ab831b on the main line.


Repo:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I tried to do git bisect and the bisect tool pointed first bad commit
to: 16ebb6f5b6295c9688749862a39a4889c56227f8.

But upon reverting the first bad commit issue is still seen. So please
ignore, if the bisection dosent help.


Error:

# selftests: powerpc/signal: sigfuz
# test: signal_fuzzer
# tags: git_version:v6.14-rc7-1-g49c747976afa
# !! killing signal_fuzzer
# !! child died by signal 15
# failure: signal_fuzzer
not ok 3 selftests: powerpc/signal: sigfuz # exit=1

That error means the test is timing out and being killed by the test
harness.


I tired multiple times with the config shared by Venkat in my P10 LPAR
and it always passes for me with default timeout as 0.


ok 2 selftests: powerpc/signal: signal_tm
# timeout set to 0
# selftests: powerpc/signal: sigfuz
# test: signal_fuzzer
# tags: git_version:v6.14-rc2-61-g861efb8a48ee
# success: signal_fuzzer
ok 3 selftests: powerpc/signal: sigfuz
# timeout set to 0
# selftests: powerpc/signal: sigreturn_vdso
# test: sigreturn_vdso
# tags: git_version:v6.14-rc2-61-g861efb8a48ee
# VDSO is at 0x7fff9aac-0x7fff9aac (65536 bytes)
# Signal delivered OK with VDSO mapped
# VDSO moved to 0x7fff9aa5-0x7fff9aa5 (65536 bytes)
# Signal delivered OK with VDSO moved
# Unmapped VDSO
# Remapped the stack executable
# Signal delivered OK with VDSO unmapped
# success: sigreturn_vdso


Setup: P10 LPAR with 16CPUs, LPAR running only the selftest
Kernel: powerpc/next (861efb8a48ee), config shared by venkat

Maddy


One key difference which I could figure out so far in the set up is, mine is 
Power10 system running on P11 FW.

I quickly gave a try with P10 system with P10 FW, and issue is not seen.

Logs from P10 system running on P10 FW:

make -j 33 -C powerpc/signal/ run_tests make: Entering directory 
'/root/venkat/linux/tools/testing/selftests/powerpc/signal' TAP 
version 13 1..7 # timeout set to 0 # selftests: powerpc/signal: signal 
# test: signal # tags: git_version:v6.14-rc7-69-g81e4f8d68c66 # 
success: signal ok 1 selftests: powerpc/signal: signal # timeout set 
to 0 # selftests: powerpc/signal: signal_tm # test: signal_tm # tags: 
git_version:v6.14-rc7-69-g81e4f8d68c66 # [SKIP] Test skipped on line 
58 # skip: signal_tm ok 2 selftests: powerpc/signal: signal_tm # 
timeout set to 0 # selftests: powerpc/signal: sigfuz # test: 
signal_fuzzer # tags: git_version:v6.14-rc7-69-g81e4f8d68c66 # 
success: signal_fuzzer ok 3 selftests: powerpc/signal: sigfuz # 
timeout set to 0 # selftests: powerpc/signal: sigreturn_vdso # test: 
sigreturn_vdso # tags: git_version:v6.14-rc7-69-g81e4f8d68c66 # VDSO 
is at 0x7fffae2e-0x7fffae2e (65536 bytes) # Signal delivered 
OK with VDSO mapped # VDSO moved to 0x7fffae27-0x7fffae27 
(65536 bytes) # Signal delivered OK with VDSO moved # Unmapped VDSO # 
Remapped the stack executable # Signal delivered OK with VDSO unmapped 
# success: sigreturn_vdso ok 4 selftests: powerpc/signal: 
sigreturn_vdso # timeout set to 0 # selftests: powerpc/signal: 
sig_sc_double_restart # test: sig sys restart # tags: 
git_version:v6.14-rc7-69-g81e4f8d68c66 # success: sig sys restart ok 5 
selftests: powerpc/signal: sig_sc_double_restart # timeout set to 0 # 
selftests: powerpc/signal: sigreturn_kernel # test: sigreturn_kernel # 
tags: git_version:v6.14-rc7-69-g81e4f8d68c66 # All children killed as 
expected # success: sigreturn_kernel ok 6 selftests: powerpc/signal: 
sigreturn_kernel # timeout set to 0 # selftests: powerpc/signal: 
sigreturn_unaligned # test: sigreturn_unaligned # tags: 
git_version:v6.14-rc7-69-g81e4f8d68c66 # success: sigreturn_unaligned 
ok 7 selftests: powerpc/signal: sigreturn_unaligned make: Leaving 
directory '/root/venkat/linux/tools/testing/selftests/powerpc/signal'

That could be due to a bug, but it could just be that your system is
overloaded or something. You can increase the timeout in the code by
adding a call to test_harness_timeout().

The test also includes lots of randomisation, so if you actually need to
bisect it you'd want to change the code to use a consistent random seed
in the calls to srand().

cheers

I increased the timeout from 0 to 120, I still see the issue.

Below are the logs with and with out time out.

make -j 33 -C powerpc/signal/ run_tests all clean clean_mods_dir 
emit_tests gen_mods_dir install run_tests [root@ltcden8-lp3 
selftests]# make -j 33 -C powerpc/signal/ run_tests make: Entering 
directory '/root/linux/tools/testing/selftest

[PATCH v2 32/57] irqdomain: ppc: Switch to irq_domain_create_*()

2025-03-19 Thread Jiri Slaby (SUSE)
irq_domain_add_*() interfaces are going away as being obsolete now.
Switch to the preferred irq_domain_create_*() ones. Those differ in the
node parameter: They take more generic struct fwnode_handle instead of
struct device_node. Therefore, of_fwnode_handle() is added around the
original parameter.

Note some of the users can likely use dev->fwnode directly instead of
indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
guaranteed to be set for all, so this has to be investigated on case to
case basis (by people who can actually test with the HW).

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Naveen N Rao 
Cc: Anatolij Gustschin 
Cc: Scott Wood 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/platforms/44x/uic.c | 5 +++--
 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c   | 3 ++-
 arch/powerpc/platforms/52xx/media5200.c  | 2 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c| 4 ++--
 arch/powerpc/platforms/52xx/mpc52xx_pic.c| 2 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c  | 2 +-
 arch/powerpc/platforms/8xx/cpm1-ic.c | 3 ++-
 arch/powerpc/platforms/8xx/pic.c | 3 ++-
 arch/powerpc/platforms/embedded6xx/flipper-pic.c | 5 +++--
 arch/powerpc/platforms/embedded6xx/hlwd-pic.c| 5 +++--
 arch/powerpc/platforms/powermac/pic.c| 5 +++--
 arch/powerpc/platforms/powernv/opal-irqchip.c| 3 ++-
 arch/powerpc/sysdev/cpm2_pic.c   | 3 ++-
 arch/powerpc/sysdev/ehv_pic.c| 5 +++--
 arch/powerpc/sysdev/fsl_msi.c| 2 +-
 arch/powerpc/sysdev/ge/ge_pic.c  | 5 +++--
 arch/powerpc/sysdev/i8259.c  | 4 ++--
 arch/powerpc/sysdev/ipic.c   | 5 +++--
 arch/powerpc/sysdev/mpic.c   | 6 +++---
 arch/powerpc/sysdev/tsi108_pci.c | 4 ++--
 arch/powerpc/sysdev/xive/common.c| 2 +-
 21 files changed, 45 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/platforms/44x/uic.c b/arch/powerpc/platforms/44x/uic.c
index 31f760c2ec5d..481ec25ce78f 100644
--- a/arch/powerpc/platforms/44x/uic.c
+++ b/arch/powerpc/platforms/44x/uic.c
@@ -254,8 +254,9 @@ static struct uic * __init uic_init_one(struct device_node 
*node)
}
uic->dcrbase = *dcrreg;
 
-   uic->irqhost = irq_domain_add_linear(node, NR_UIC_INTS, &uic_host_ops,
-uic);
+   uic->irqhost = irq_domain_create_linear(of_fwnode_handle(node),
+   NR_UIC_INTS, &uic_host_ops,
+   uic);
if (! uic->irqhost)
return NULL; /* FIXME: panic? */
 
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c 
b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
index e995eb30bf09..2cf3c6237337 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
@@ -188,7 +188,8 @@ mpc5121_ads_cpld_pic_init(void)
 
cpld_pic_node = of_node_get(np);
 
-   cpld_pic_host = irq_domain_add_linear(np, 16, &cpld_pic_host_ops, NULL);
+   cpld_pic_host = irq_domain_create_linear(of_fwnode_handle(np), 16,
+&cpld_pic_host_ops, NULL);
if (!cpld_pic_host) {
printk(KERN_ERR "CPLD PIC: failed to allocate irq host!\n");
goto end;
diff --git a/arch/powerpc/platforms/52xx/media5200.c 
b/arch/powerpc/platforms/52xx/media5200.c
index 19626cd42406..bc7f83cfec1d 100644
--- a/arch/powerpc/platforms/52xx/media5200.c
+++ b/arch/powerpc/platforms/52xx/media5200.c
@@ -168,7 +168,7 @@ static void __init media5200_init_irq(void)
 
spin_lock_init(&media5200_irq.lock);
 
-   media5200_irq.irqhost = irq_domain_add_linear(fpga_np,
+   media5200_irq.irqhost = 
irq_domain_create_linear(of_fwnode_handle(fpga_np),
MEDIA5200_NUM_IRQS, &media5200_irq_ops, &media5200_irq);
if (!media5200_irq.irqhost)
goto out;
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 1ea591ec6083..f042b21b2b73 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -247,9 +247,9 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt, struct 
device_node *node)
if (!cascade_virq)
return;
 
-   gpt->irqhost = irq_domain_add_linear(node, 1, &mpc52xx_gpt_irq_ops, 
gpt);
+   gpt->irqhost = irq_domain_create_linear(of_fwnode_handle(node), 1, 
&mpc52xx_gpt_irq_ops, gpt);
if (!gpt->irqhost) {
-   dev_err(gpt->dev, "irq_domain_add_linear() failed\n");
+   dev_err(gpt->dev, "irq_domain_create_linear() failed\n");
return;
}
 
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_

[PATCH 1/3] MAINTAINERS: add myself as maintainer for the fsl-mc bus

2025-03-19 Thread Ioana Ciornei
Laurentiu left the company and is no longer involved with the fsl-mc
bus. Remove him and add myself as maintainer.

Signed-off-by: Ioana Ciornei 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ebf7fa9a814d..76b6db4074ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19633,7 +19633,7 @@ F:  include/linux/qnx6_fs.h
 
 QORIQ DPAA2 FSL-MC BUS DRIVER
 M: Stuart Yoder 
-M: Laurentiu Tudor 
+M: Ioana Ciornei 
 L: linux-ker...@vger.kernel.org
 S: Maintained
 F: Documentation/ABI/stable/sysfs-bus-fsl-mc
-- 
2.34.1




[PATCH 3/3] MAINTAINERS: add the linuppc-dev list to the fsl-mc bus entry

2025-03-19 Thread Ioana Ciornei
As discussed in the thread linked below, the fsl-mc bus lacked a clear
maintenance path. Since Christophe accepted to take the fsl-mc bus
patches through his soc fsl subtree, add the linuxppc-dev mailing list
in the MAINTAINERS entry.

Link: https://lore.kernel.org/r/1d822960-85a7-42b3-88cf-9d3dbc75a...@csgroup.eu
Signed-off-by: Ioana Ciornei 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e6aac2962dd..cfa6db4b6ce2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19634,6 +19634,7 @@ F:  include/linux/qnx6_fs.h
 QORIQ DPAA2 FSL-MC BUS DRIVER
 M: Stuart Yoder 
 M: Ioana Ciornei 
+L: linuxppc-dev@lists.ozlabs.org
 L: linux-ker...@vger.kernel.org
 S: Maintained
 F: Documentation/ABI/stable/sysfs-bus-fsl-mc
-- 
2.34.1




[PATCH 2/3] MAINTAINERS: fix nonexistent dtbinding file name

2025-03-19 Thread Ioana Ciornei
The blamed commit converted the fsl,qoriq-mc.txt into fsl,qoriq-mc.yaml
but forgot to also update the MAINTAINERS file to reference the new
filename.

Fix this by using the corrent filename - fsl,qoriq-mc.yaml.

Fixes: bfb921b2a9d5 ("dt-bindings: misc: fsl,qoriq-mc: convert to yaml format")
Signed-off-by: Ioana Ciornei 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 76b6db4074ce..1e6aac2962dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19637,7 +19637,7 @@ M:  Ioana Ciornei 
 L: linux-ker...@vger.kernel.org
 S: Maintained
 F: Documentation/ABI/stable/sysfs-bus-fsl-mc
-F: Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+F: Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
 F: 
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
 F: drivers/bus/fsl-mc/
 F: include/uapi/linux/fsl_mc.h
-- 
2.34.1




[PATCH 0/3] MAINTAINERS: updates for the fsl-mc bus entry

2025-03-19 Thread Ioana Ciornei
This patch set updates the fsl-mc bus driver MAINTAINERS entry. Since
there are small separate changes, I put each of them into a separate
patch.

Ioana Ciornei (3):
  MAINTAINERS: add myself as maintainer for the fsl-mc bus
  MAINTAINERS: fix nonexistent dtbinding file name
  MAINTAINERS: add the linuppc-dev list to the fsl-mc bus entry

 MAINTAINERS | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.34.1




Re: [PATCH v4 07/14] arm64: Add support for suppressing warning backtraces

2025-03-19 Thread Christophe Leroy




Le 18/03/2025 à 16:59, Will Deacon a écrit :

On Thu, Mar 13, 2025 at 05:40:59PM +0100, Alessandro Carminati wrote:

On Thu, Mar 13, 2025 at 1:25 PM Will Deacon  wrote:


On Thu, Mar 13, 2025 at 11:43:22AM +, Alessandro Carminati wrote:

diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 28be048db3f6..044c5e24a17d 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -11,8 +11,14 @@

  #include 

+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC  __func__
+#else
+# define __BUG_FUNC  NULL
+#endif
+
  #define __BUG_FLAGS(flags)   \
- asm volatile (__stringify(ASM_BUG_FLAGS(flags)));
+ asm volatile (__stringify(ASM_BUG_FLAGS(flags, %c0)) : : "i" 
(__BUG_FUNC));


Why is 'i' the right asm constraint to use here? It seems a bit odd to
use that for a pointer.


I received this code as legacy from a previous version.
In my review, I considered the case when HAVE_BUG_FUNCTION is defined:
Here, __BUG_FUNC is defined as __func__, which is the name of the
current function as a string literal.
Using the constraint "i" seems appropriate to me in this case.

However, when HAVE_BUG_FUNCTION is not defined:
__BUG_FUNC is defined as NULL. Initially, I considered it literal 0,
but after investigating your concern, I found:

```
$ echo -E "#include \n#include \nint main()
{\nreturn 0;\n}" | aarch64-linux-gnu-gcc -E -dM - | grep NULL
#define NULL ((void *)0)
```

I realized that NULL is actually a pointer that is not a link time
symbol, and using the "i" constraint with NULL may result in undefined
behavior.

Would the following alternative definition for __BUG_FUNC be more convincing?

```
#ifdef HAVE_BUG_FUNCTION
 #define __BUG_FUNC __func__
#else
 #define __BUG_FUNC (uintptr_t)0
#endif
```
Let me know your thoughts.


Thanks for the analysis; I hadn't noticed this specific issue, it just
smelled a bit fishy. Anyway, the diff above looks better, thanks.


That propably deserves a comment.

Doesn't sparse and/or checkpatch complain about 0 being used in lieu of 
NULL ?


By the way I had similar problem in the past with GCC not seeing NULL as 
a __builtin_constant_p(), refer commit 1d8f739b07bd ("powerpc/kuap: Fix 
set direction in allow/prevent_user_access()")


Christophe



[PATCH v2 41/57] irqdomain: ppc: Switch to irq_find_mapping()

2025-03-19 Thread Jiri Slaby (SUSE)
irq_linear_revmap() is deprecated, so remove all its uses and supersede
them by an identical call to irq_find_mapping().

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Naveen N Rao 
Cc: Anatolij Gustschin 
Cc: Scott Wood 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/platforms/44x/uic.c | 2 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c| 2 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c| 2 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c  | 2 +-
 arch/powerpc/platforms/8xx/cpm1-ic.c | 2 +-
 arch/powerpc/platforms/8xx/pic.c | 2 +-
 arch/powerpc/platforms/embedded6xx/flipper-pic.c | 2 +-
 arch/powerpc/platforms/embedded6xx/hlwd-pic.c| 2 +-
 arch/powerpc/platforms/powermac/pic.c| 2 +-
 arch/powerpc/sysdev/cpm2_pic.c   | 2 +-
 arch/powerpc/sysdev/ehv_pic.c| 2 +-
 arch/powerpc/sysdev/ge/ge_pic.c  | 2 +-
 arch/powerpc/sysdev/ipic.c   | 2 +-
 arch/powerpc/sysdev/mpic.c   | 4 ++--
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/44x/uic.c b/arch/powerpc/platforms/44x/uic.c
index 481ec25ce78f..85daf841fd3f 100644
--- a/arch/powerpc/platforms/44x/uic.c
+++ b/arch/powerpc/platforms/44x/uic.c
@@ -328,5 +328,5 @@ unsigned int uic_get_irq(void)
msr = mfdcr(primary_uic->dcrbase + UIC_MSR);
src = 32 - ffs(msr);
 
-   return irq_linear_revmap(primary_uic->irqhost, src);
+   return irq_find_mapping(primary_uic->irqhost, src);
 }
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index f042b21b2b73..3dbe5a5e5d1f 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -369,7 +369,7 @@ struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq)
mutex_lock(&mpc52xx_gpt_list_mutex);
list_for_each(pos, &mpc52xx_gpt_list) {
gpt = container_of(pos, struct mpc52xx_gpt_priv, list);
-   if (gpt->irqhost && irq == irq_linear_revmap(gpt->irqhost, 0)) {
+   if (gpt->irqhost && irq == irq_find_mapping(gpt->irqhost, 0)) {
mutex_unlock(&mpc52xx_gpt_list_mutex);
return gpt;
}
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c 
b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index 7ec56d3788a9..eb6a4e745c08 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -515,5 +515,5 @@ unsigned int mpc52xx_get_irq(void)
return 0;
}
 
-   return irq_linear_revmap(mpc52xx_irqhost, irq);
+   return irq_find_mapping(mpc52xx_irqhost, irq);
 }
diff --git a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c 
b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
index b4f6360830b1..4b69fb321a68 100644
--- a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
+++ b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
@@ -83,7 +83,7 @@ static inline unsigned int socrates_fpga_pic_get_irq(unsigned 
int irq)
if (cause >> (i + 16))
break;
}
-   return irq_linear_revmap(socrates_fpga_pic_irq_host,
+   return irq_find_mapping(socrates_fpga_pic_irq_host,
(irq_hw_number_t)i);
 }
 
diff --git a/arch/powerpc/platforms/8xx/cpm1-ic.c 
b/arch/powerpc/platforms/8xx/cpm1-ic.c
index 1549f6cd29f4..a49d4a9ab3bc 100644
--- a/arch/powerpc/platforms/8xx/cpm1-ic.c
+++ b/arch/powerpc/platforms/8xx/cpm1-ic.c
@@ -59,7 +59,7 @@ static int cpm_get_irq(struct irq_desc *desc)
cpm_vec = in_be16(&data->reg->cpic_civr);
cpm_vec >>= 11;
 
-   return irq_linear_revmap(data->host, cpm_vec);
+   return irq_find_mapping(data->host, cpm_vec);
 }
 
 static void cpm_cascade(struct irq_desc *desc)
diff --git a/arch/powerpc/platforms/8xx/pic.c b/arch/powerpc/platforms/8xx/pic.c
index 7639f28172be..933d6ab7f512 100644
--- a/arch/powerpc/platforms/8xx/pic.c
+++ b/arch/powerpc/platforms/8xx/pic.c
@@ -80,7 +80,7 @@ unsigned int mpc8xx_get_irq(void)
if (irq == PIC_VEC_SPURRIOUS)
return 0;
 
-return irq_linear_revmap(mpc8xx_pic_host, irq);
+return irq_find_mapping(mpc8xx_pic_host, irq);
 
 }
 
diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c 
b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
index a41649bf0cb8..91a8f0a7086e 100644
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -173,7 +173,7 @@ unsigned int flipper_pic_get_irq(void)
return 0;   /* no more IRQs pending */
 
irq = __ffs(irq_status);
-   return irq_linear_revmap(flipper_irq_host, irq);
+   return irq_find_mapping(flipper_irq_host, irq);
 }
 
 /*
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-

Re: [PATCH v4 07/14] arm64: Add support for suppressing warning backtraces

2025-03-19 Thread Guenter Roeck

On 3/19/25 01:05, Christophe Leroy wrote:



Le 18/03/2025 à 16:59, Will Deacon a écrit :

On Thu, Mar 13, 2025 at 05:40:59PM +0100, Alessandro Carminati wrote:

On Thu, Mar 13, 2025 at 1:25 PM Will Deacon  wrote:


On Thu, Mar 13, 2025 at 11:43:22AM +, Alessandro Carminati wrote:

diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 28be048db3f6..044c5e24a17d 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -11,8 +11,14 @@

  #include 

+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC  __func__
+#else
+# define __BUG_FUNC  NULL
+#endif
+
  #define __BUG_FLAGS(flags)   \
- asm volatile (__stringify(ASM_BUG_FLAGS(flags)));
+ asm volatile (__stringify(ASM_BUG_FLAGS(flags, %c0)) : : "i" 
(__BUG_FUNC));


Why is 'i' the right asm constraint to use here? It seems a bit odd to
use that for a pointer.


I received this code as legacy from a previous version.
In my review, I considered the case when HAVE_BUG_FUNCTION is defined:
Here, __BUG_FUNC is defined as __func__, which is the name of the
current function as a string literal.
Using the constraint "i" seems appropriate to me in this case.

However, when HAVE_BUG_FUNCTION is not defined:
__BUG_FUNC is defined as NULL. Initially, I considered it literal 0,
but after investigating your concern, I found:

```
$ echo -E "#include \n#include \nint main()
{\nreturn 0;\n}" | aarch64-linux-gnu-gcc -E -dM - | grep NULL
#define NULL ((void *)0)
```

I realized that NULL is actually a pointer that is not a link time
symbol, and using the "i" constraint with NULL may result in undefined
behavior.

Would the following alternative definition for __BUG_FUNC be more convincing?

```
#ifdef HAVE_BUG_FUNCTION
 #define __BUG_FUNC __func__
#else
 #define __BUG_FUNC (uintptr_t)0
#endif
```
Let me know your thoughts.


Thanks for the analysis; I hadn't noticed this specific issue, it just
smelled a bit fishy. Anyway, the diff above looks better, thanks.


That propably deserves a comment.

Doesn't sparse and/or checkpatch complain about 0 being used in lieu of NULL ?



__BUG_FUNC is only used as parameter to asm code, not as pointer.

From the diff:

-: : "i" (__FILE__), "i" (__LINE__),\
+: : "i" (__FILE__), "i" (__BUG_FUNC), "i" (__LINE__),\

The use is quite similar to __FILE__ and __LINE__. It might even be possible
and appropriate to just define __BUG_FUNC as 0 if HAVE_BUG_FUNCTION is not 
defined.

Guenter




Re: [PATCH 5/6] mips: drop GENERIC_IOMAP wrapper

2025-03-19 Thread Arnd Bergmann
On Wed, Mar 19, 2025, at 18:30, Nathan Chancellor wrote:
> On Tue, Mar 18, 2025 at 10:13:35PM +0100, Arnd Bergmann wrote:
>> Thanks for the report, I missed that the generic ioport_map() function
>> is missing the PCI_IOBASE macro, we should probably remove that from
>> the asm-generic/io.h header and require architectures to define it
>> themselves, since the NULL fallback is pretty much always wrong.
>> 
>> There is also a type mismatch between the MIPS
>> PCI_IOBASE/mips_io_port_base and the one that asm-generic/io.h
>> expects, so I had to add a couple of extra typecasts, which
>> makes it rather ugly, but the change below seems to work.
>
> Thanks, that does make the -Wnull-pointer-arithmetic warnings disappear.
> That build still fails in next-20250319 (which includes that change) at
> the end with:
>
>   $ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mips-linux- mrproper 
> malta_defconfig all
>   ERROR: modpost: "pci_iounmap" 
> [drivers/net/wireless/intel/ipw2x00/ipw2100.ko] undefined!
>
> which appears related to this original change.

Right, I had seen and fixed a problem like this in an earlier
version, but forgot the EXPORT_SYMBOL on the legacy host version.

Fixed it better now.

  Arnd



Re: [PATCH RFC v2 04/29] mm: asi: Add infrastructure for boot-time enablement

2025-03-19 Thread Borislav Petkov
On Fri, Jan 10, 2025 at 06:40:30PM +, Brendan Jackman wrote:
> Add a boot time parameter to control the newly added X86_FEATURE_ASI.
> "asi=on" or "asi=off" can be used in the kernel command line to enable
> or disable ASI at boot time. If not specified, ASI enablement depends
> on CONFIG_ADDRESS_SPACE_ISOLATION_DEFAULT_ON, which is off by default.

I don't know yet why we need this default-on thing...

> asi_check_boottime_disable() is modeled after
> pti_check_boottime_disable().
> 
> The boot parameter is currently ignored until ASI is fully functional.
> 
> Once we have a set of ASI features checked in that we have actually
> tested, we will stop ignoring the flag. But for now let's just add the
> infrastructure so we can implement the usage code.
> 
> Ignoring checkpatch.pl CONFIG_DESCRIPTION because the _DEFAULT_ON
> Kconfig is trivial to explain.

Those last two paragraphs go...

> Checkpatch-args: --ignore CONFIG_DESCRIPTION
> Co-developed-by: Junaid Shahid 
> Signed-off-by: Junaid Shahid 
> Co-developed-by: Yosry Ahmed 
> Signed-off-by: Yosry Ahmed 
> Signed-off-by: Brendan Jackman 
> ---

... here as that's text not really pertaining to the contents of the patch.

>  arch/x86/Kconfig |  9 +
>  arch/x86/include/asm/asi.h   | 19 --
>  arch/x86/include/asm/cpufeatures.h   |  1 +
>  arch/x86/include/asm/disabled-features.h |  8 -
>  arch/x86/mm/asi.c| 61 
> +++-
>  arch/x86/mm/init.c   |  4 ++-
>  include/asm-generic/asi.h|  4 +++
>  7 files changed, 92 insertions(+), 14 deletions(-)

...

>   * the N ASI classes.
>   */
>  
> +#define static_asi_enabled() cpu_feature_enabled(X86_FEATURE_ASI)

Yeah, as already mentioned somewhere else, whack that thing pls.

> +
>  /*
>   * ASI uses a per-CPU tainting model to track what mitigation actions are
>   * required on domain transitions. Taints exist along two dimensions:
> @@ -131,6 +134,8 @@ struct asi {
>  
>  DECLARE_PER_CPU_ALIGNED(struct asi *, curr_asi);
>  
> +void asi_check_boottime_disable(void);
> +
>  void asi_init_mm_state(struct mm_struct *mm);
>  
>  int asi_init_class(enum asi_class_id class_id, struct asi_taint_policy 
> *taint_policy);
> @@ -155,7 +160,9 @@ void asi_exit(void);
>  /* The target is the domain we'll enter when returning to process context. */
>  static __always_inline struct asi *asi_get_target(struct task_struct *p)
>  {
> - return p->thread.asi_state.target;
> + return static_asi_enabled()
> +? p->thread.asi_state.target
> +: NULL;

Waaay too fancy for old people:

if ()
return...
else
return NULL;

:-)

The others too pls.

>  static __always_inline void asi_set_target(struct task_struct *p,
> @@ -166,7 +173,9 @@ static __always_inline void asi_set_target(struct 
> task_struct *p,
>  
>  static __always_inline struct asi *asi_get_current(void)
>  {
> - return this_cpu_read(curr_asi);
> + return static_asi_enabled()
> +? this_cpu_read(curr_asi)
> +: NULL;
>  }
>  
>  /* Are we currently in a restricted address space? */
> @@ -175,7 +184,11 @@ static __always_inline bool asi_is_restricted(void)
>   return (bool)asi_get_current();
>  }
>  
> -/* If we exit/have exited, can we stay that way until the next asi_enter? */
> +/*
> + * If we exit/have exited, can we stay that way until the next asi_enter?

What is that supposed to mean here?

> + *
> + * When ASI is disabled, this returns true.
> + */
>  static __always_inline bool asi_is_relaxed(void)
>  {
>   return !asi_get_target(current);
> diff --git a/arch/x86/include/asm/cpufeatures.h 
> b/arch/x86/include/asm/cpufeatures.h
> index 
> 913fd3a7bac6506141de65f33b9ee61c615c7d7d..d6a808d10c3b8900d190ea01c66fc248863f05e2
>  100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -474,6 +474,7 @@
>  #define X86_FEATURE_CLEAR_BHB_HW (21*32+ 3) /* BHI_DIS_S HW control 
> enabled */
>  #define X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT (21*32+ 4) /* Clear branch 
> history at vmexit using SW loop */
>  #define X86_FEATURE_FAST_CPPC(21*32 + 5) /* AMD Fast CPPC */
> +#define X86_FEATURE_ASI  (21*32+6) /* Kernel Address 
> Space Isolation */
>  
>  /*
>   * BUG word(s)
> diff --git a/arch/x86/include/asm/disabled-features.h 
> b/arch/x86/include/asm/disabled-features.h
> index 
> c492bdc97b0595ec77f89dc9b0cefe5e3e64be41..c7964ed4fef8b9441e1c0453da587787d8008d9d
>  100644
> --- a/arch/x86/include/asm/disabled-features.h
> +++ b/arch/x86/include/asm/disabled-features.h
> @@ -50,6 +50,12 @@
>  # define DISABLE_PTI (1 << (X86_FEATURE_PTI & 31))
>  #endif
>  
> +#ifdef CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION
> +# define DISABLE_ASI 0
> +#else
> +# define DISABLE_ASI (1 << (X86_FEATURE_ASI & 31))
> +#endif
> +
>  #ifdef CONFIG_

Re: [PATCH] powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory

2025-03-19 Thread Michal Suchánek
Hello,

looks like this upsets some assumption qemu has about these windows.

https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg05137.html

When Linux kernel that has this patch applied is running inside a qemu
VM with a PCI device and the VM is rebooted qemu crashes shortly after
the next Linux kernel starts.

This is quite curious since qemu does AFAIK not support pmemory at all.

Any idea what went wrong there?

Thanks

Michal

On Thu, Jan 30, 2025 at 12:38:54PM -0600, Gaurav Batra wrote:
> iommu_mem_notifier() is invoked when RAM is dynamically added/removed. This
> notifier call is responsible to add/remove TCEs from the Dynamic DMA Window
> (DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM and not
> for persistent memory (pmemory). For DMA buffers in pmemory, TCEs are
> dynamically mapped when the device driver instructs to do so.
> 
> The issue is 'daxctl' command is capable of adding pmemory as "System RAM"
> after LPAR boot. The command to do so is -
> 
> daxctl reconfigure-device --mode=system-ram dax0.0 --force
> 
> This will dynamically add pmemory range to LPAR RAM eventually invoking
> iommu_mem_notifier(). The address range of pmemory is way beyond the Max
> RAM that the LPAR can have. Which means, this range is beyond the DDW
> created for the device, at device initialization time.
> 
> As a result when TCEs are pre-mapped for the pmemory range, by
> iommu_mem_notifier(), PHYP HCALL returns H_PARAMETER. This failed the
> command, daxctl, to add pmemory as RAM.
> 
> The solution is to not pre-map TCEs for pmemory.
> 
> Signed-off-by: Gaurav Batra 
> ---
>  arch/powerpc/include/asm/mmzone.h  |  1 +
>  arch/powerpc/mm/numa.c |  2 +-
>  arch/powerpc/platforms/pseries/iommu.c | 29 ++
>  3 files changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/mmzone.h 
> b/arch/powerpc/include/asm/mmzone.h
> index d99863cd6cde..049152f8d597 100644
> --- a/arch/powerpc/include/asm/mmzone.h
> +++ b/arch/powerpc/include/asm/mmzone.h
> @@ -29,6 +29,7 @@ extern cpumask_var_t node_to_cpumask_map[];
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  extern unsigned long max_pfn;
>  u64 memory_hotplug_max(void);
> +u64 hot_add_drconf_memory_max(void);
>  #else
>  #define memory_hotplug_max() memblock_end_of_DRAM()
>  #endif
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 3c1da08304d0..603a0f652ba6 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1336,7 +1336,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
>   return nid;
>  }
>  
> -static u64 hot_add_drconf_memory_max(void)
> +u64 hot_add_drconf_memory_max(void)
>  {
>   struct device_node *memory = NULL;
>   struct device_node *dn = NULL;
> diff --git a/arch/powerpc/platforms/pseries/iommu.c 
> b/arch/powerpc/platforms/pseries/iommu.c
> index 29f1a0cc59cd..abd9529a8f41 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -1284,17 +1284,13 @@ static LIST_HEAD(failed_ddw_pdn_list);
>  
>  static phys_addr_t ddw_memory_hotplug_max(void)
>  {
> - resource_size_t max_addr = memory_hotplug_max();
> - struct device_node *memory;
> + resource_size_t max_addr;
>  
> - for_each_node_by_type(memory, "memory") {
> - struct resource res;
> -
> - if (of_address_to_resource(memory, 0, &res))
> - continue;
> -
> - max_addr = max_t(resource_size_t, max_addr, res.end + 1);
> - }
> +#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
> + max_addr = hot_add_drconf_memory_max();
> +#else
> + max_addr = memblock_end_of_DRAM();
> +#endif
>  
>   return max_addr;
>  }
> @@ -1600,7 +1596,7 @@ static bool enable_ddw(struct pci_dev *dev, struct 
> device_node *pdn)
>  
>   if (direct_mapping) {
>   /* DDW maps the whole partition, so enable direct DMA mapping */
> - ret = walk_system_ram_range(0, memblock_end_of_DRAM() >> 
> PAGE_SHIFT,
> + ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >> 
> PAGE_SHIFT,
>   win64->value, 
> tce_setrange_multi_pSeriesLP_walk);
>   if (ret) {
>   dev_info(&dev->dev, "failed to map DMA window for %pOF: 
> %d\n",
> @@ -2346,11 +2342,17 @@ static int iommu_mem_notifier(struct notifier_block 
> *nb, unsigned long action,
>   struct memory_notify *arg = data;
>   int ret = 0;
>  
> + /* This notifier can get called when onlining persistent memory as well.
> +  * TCEs are not pre-mapped for persistent memory. Persistent memory will
> +  * always be above ddw_memory_hotplug_max()
> +  */
> +
>   switch (action) {
>   case MEM_GOING_ONLINE:
>   spin_lock(&dma_win_list_lock);
>   list_for_each_entry(window, &dma_win_list, list) {
> - if (window->direct) {
> + i

Re: [PATCH RFC v2 04/29] mm: asi: Add infrastructure for boot-time enablement

2025-03-19 Thread Yosry Ahmed
On Wed, Mar 19, 2025 at 06:29:35PM +0100, Borislav Petkov wrote:
> On Fri, Jan 10, 2025 at 06:40:30PM +, Brendan Jackman wrote:
> > Add a boot time parameter to control the newly added X86_FEATURE_ASI.
> > "asi=on" or "asi=off" can be used in the kernel command line to enable
> > or disable ASI at boot time. If not specified, ASI enablement depends
> > on CONFIG_ADDRESS_SPACE_ISOLATION_DEFAULT_ON, which is off by default.
> 
> I don't know yet why we need this default-on thing...

It's a convenience to avoid needing to set asi=on if you want ASI to be
on by default. It's similar to HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON
or ZSWAP_DEFAULT_ON.

[..]
> > @@ -175,7 +184,11 @@ static __always_inline bool asi_is_restricted(void)
> > return (bool)asi_get_current();
> >  }
> >  
> > -/* If we exit/have exited, can we stay that way until the next asi_enter? 
> > */
> > +/*
> > + * If we exit/have exited, can we stay that way until the next asi_enter?
> 
> What is that supposed to mean here?

asi_is_relaxed() checks if the thread is outside an ASI critical
section.

I say "the thread" because it will also return true if we are executing
an interrupt that arrived during the critical section, even though the
interrupt handler is not technically part of the critical section.

Now the reason it says "if we exit we stay that way" is probably
referring to the fact that an asi_exit() when interrupting a critical
section will be undone in the interrupt epilogue by re-entering ASI.

I agree the wording here is confusing. We should probably describe this
more explicitly and probably rename the function after the API
discussions you had in the previous patch.

> 
> > + *
> > + * When ASI is disabled, this returns true.
> > + */
> >  static __always_inline bool asi_is_relaxed(void)
> >  {
> > return !asi_get_target(current);
[..]
> > @@ -66,10 +73,36 @@ const char *asi_class_name(enum asi_class_id class_id)
> > return asi_class_names[class_id];
> >  }
> >  
> > +void __init asi_check_boottime_disable(void)
> > +{
> > +   bool enabled = 
> > IS_ENABLED(CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION_DEFAULT_ON);
> > +   char arg[4];
> > +   int ret;
> > +
> > +   ret = cmdline_find_option(boot_command_line, "asi", arg, sizeof(arg));
> > +   if (ret == 3 && !strncmp(arg, "off", 3)) {
> > +   enabled = false;
> > +   pr_info("ASI disabled through kernel command line.\n");
> > +   } else if (ret == 2 && !strncmp(arg, "on", 2)) {
> > +   enabled = true;
> > +   pr_info("Ignoring asi=on param while ASI implementation is 
> > incomplete.\n");
> > +   } else {
> > +   pr_info("ASI %s by default.\n",
> > +   enabled ? "enabled" : "disabled");
> > +   }
> > +
> > +   if (enabled)
> > +   pr_info("ASI enablement ignored due to incomplete 
> > implementation.\n");
> 
> Incomplete how?

This is referring to the fact that ASI is still not fully/correctly
functional, but it will be after the following patches.

I think it will be clearer if we just add the feature flag here so that
we have something to check for in the following patches, but add the
infrastructure for boot-time enablement at the end of the series when
the impelemntation is complete.

Basically start by a feature flag that has no way of being enabled, use
it in the implmentation, then add means of enabling it.

> 
> > +}
> > +
> >  static void __asi_destroy(struct asi *asi)
> >  {
> > -   lockdep_assert_held(&asi->mm->asi_init_lock);
> > +   WARN_ON_ONCE(asi->ref_count <= 0);
> > +   if (--(asi->ref_count) > 0)
> 
> Switch that to
> 
> include/linux/kref.h
> 
> It gives you a sanity-checking functionality too so you don't need the WARN...

I think we hve internal changes that completely get rid of this
ref_count and simplifies the lifetime handling that we can squash here.
We basically keep ASI objects around until the process is torn down,
which makes this simpler and avoids the need for complex synchronization
when we try to context switch or run userspace without exiting ASI
(spoiler alert :) ).

> 
> > +   return;
> >  
> > +   free_pages((ulong)asi->pgd, PGD_ALLOCATION_ORDER);
> > +   memset(asi, 0, sizeof(struct asi));
> 
> And then you can do:
> 
>   if (kref_put())
>   free_pages...
> 
> and so on.
> 
> Thx.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette
> 



Re: [PATCH v2 00/57] irqdomain: Cleanups and Documentation

2025-03-19 Thread Andy Shevchenko
On Wed, Mar 19, 2025 at 11:30 AM Jiri Slaby (SUSE)  wrote:
>
> Hi,
>
> tl;dr if patches are agreed upon, I ask subsys maintainers to take the
> respective ones via their trees (as they are split per subsys), so that
> the IRQ tree can take only the rest. That would minimize churn/conflicts
> during merges.
>
> ===
>
> While I was reading through the irqdomain code and headers, I found some
> naming and documentation hard to follow or incomplete. Especially the
> naming of _add/_create/_instantiate functions.
>
> I tried to come up with a better state with this patchset:
> * only irq _domain_ (not host),
> * only irq_domain_create*() functions, all taking fwnode uniformly,
>
> Finally, all the irqdomain stuff is now plugged (and generated) into
> Documentation. So that everyone can walk through it at
> https://www.kernel.org/doc/ (once applied, of course).

I am all to support the idea, but in some cases I would think of a bit
more work to be done to get rid of the of_fwnode_handle(np) in favour
of dev_fwnode(dev). Note, this is based on a brief look, I haven't any
example at hand right now.

-- 
With Best Regards,
Andy Shevchenko



Re: [PATCH 3/3] MAINTAINERS: add the linuppc-dev list to the fsl-mc bus entry

2025-03-19 Thread Christophe Leroy




Le 19/03/2025 à 10:43, Ioana Ciornei a écrit :

[Vous ne recevez pas souvent de courriers de ioana.cior...@nxp.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

As discussed in the thread linked below, the fsl-mc bus lacked a clear
maintenance path. Since Christophe accepted to take the fsl-mc bus
patches through his soc fsl subtree, add the linuxppc-dev mailing list
in the MAINTAINERS entry.

Link: https://lore.kernel.org/r/1d822960-85a7-42b3-88cf-9d3dbc75a...@csgroup.eu


Acked-by: Christophe Leroy 


Signed-off-by: Ioana Ciornei 
---
  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e6aac2962dd..cfa6db4b6ce2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19634,6 +19634,7 @@ F:  include/linux/qnx6_fs.h
  QORIQ DPAA2 FSL-MC BUS DRIVER
  M: Stuart Yoder 
  M: Ioana Ciornei 
+L: linuxppc-dev@lists.ozlabs.org
  L: linux-ker...@vger.kernel.org
  S: Maintained
  F: Documentation/ABI/stable/sysfs-bus-fsl-mc
--
2.34.1