[PATCH v3 0/2] Improving calls to kvmppc_hv_entry

2023-03-15 Thread Kautuk Consul
- remove .global scope of kvmppc_hv_entry
- remove r4 argument to kvmppc_hv_entry as it is not required

Changes since v2:
- Add the lwsync instruction before the load to r4 to order
  load of vcore before load of vcpu

Kautuk Consul (2):
  arch/powerpc/kvm: kvmppc_hv_entry: remove .global scope
  arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument

 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

-- 
2.39.2



[PATCH v3 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument

2023-03-15 Thread Kautuk Consul
kvmppc_hv_entry is called from only 2 locations within
book3s_hv_rmhandlers.S. Both of those locations set r4
as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
So, shift the r4 load instruction to kvmppc_hv_entry and
thus modify the calling convention of this function.

Signed-off-by: Kautuk Consul 
---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index b81ba4ee0521..b61f0b2c677b 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
RFI_TO_KERNEL
 
 kvmppc_call_hv_entry:
-   ld  r4, HSTATE_KVM_VCPU(r13)
+   /* Enter guest. */
bl  kvmppc_hv_entry
 
/* Back from guest - restore host state and return to caller */
@@ -352,9 +352,7 @@ kvm_secondary_got_guest:
mtspr   SPRN_LDBAR, r0
isync
 63:
-   /* Order load of vcpu after load of vcore */
-   lwsync
-   ld  r4, HSTATE_KVM_VCPU(r13)
+   /* Enter guest. */
bl  kvmppc_hv_entry
 
/* Back from the guest, go back to nap */
@@ -506,7 +504,6 @@ SYM_INNER_LABEL(kvmppc_hv_entry, SYM_L_LOCAL)
 
/* Required state:
 *
-* R4 = vcpu pointer (or NULL)
 * MSR = ~IR|DR
 * R13 = PACA
 * R1 = host R1
@@ -524,6 +521,10 @@ SYM_INNER_LABEL(kvmppc_hv_entry, SYM_L_LOCAL)
li  r6, KVM_GUEST_MODE_HOST_HV
stb r6, HSTATE_IN_GUEST(r13)
 
+   /* Order load of vcpu after load of vcore */
+   lwsync
+   ld  r4, HSTATE_KVM_VCPU(r13)
+
 #ifdef CONFIG_KVM_BOOK3S_HV_P8_TIMING
/* Store initial timestamp */
cmpdi   r4, 0
-- 
2.39.2



[PATCH v3 1/2] arch/powerpc/kvm: kvmppc_hv_entry: remove .global scope

2023-03-15 Thread Kautuk Consul
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function and annotating it with SYM_INNER_LABEL.

Signed-off-by: Kautuk Consul 
---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index acf80915f406..b81ba4ee0521 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -502,8 +502,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
  **
  */
 
-.global kvmppc_hv_entry
-kvmppc_hv_entry:
+SYM_INNER_LABEL(kvmppc_hv_entry, SYM_L_LOCAL)
 
/* Required state:
 *
-- 
2.39.2



[PATCH 000/173] ALSA/ASoC: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
Hello,

this series adapts the platform drivers below sound/ to use the .remove_new()
callback. Compared to the traditional .remove() callback .remove_new() returns
no value. This is a good thing because the driver core doesn't (and cannot)
cope for errors during remove. The only effect of a non-zero return value in
.remove() is that the driver core emits a warning. The device is removed anyhow
and an early return from .remove() usually yields a resource leak.

By changing the remove callback to return void driver authors cannot
reasonably assume any more that there is some kind of cleanup later.

The first two patches simplify a driver each to return zero unconditionally,
and then all drivers are trivially converted to .remove_new().

There are nearly no interdependencies in this patch set---only 1 <- 11 and
2 <- 16. So even if some individual problems are found (I don't expect that),
the other patches can (and from my POV should) still be applied.

Best regards
Uwe

Uwe Kleine-König (173):
  ALSA: sh: aica: Drop if blocks with always false condition
  ASoC: amd: acp: rembrandt: Drop if blocks with always false condition
  ALSA: pxa2xx: Convert to platform remove callback returning void
  ALSA: atmel: ac97: Convert to platform remove callback returning void
  ALSA: mts64: Convert to platform remove callback returning void
  ALSA: portman2x4: Convert to platform remove callback returning void
  ALSA: mips/hal2: Convert to platform remove callback returning void
  ALSA: mips/sgio2audio: Convert to platform remove callback returning
void
  ALSA: hda/tegra: Convert to platform remove callback returning void
  ALSA: ppc/powermac: Convert to platform remove callback returning void
  ALSA: sh: aica: Convert to platform remove callback returning void
  ALSA: sh_dac_audio: Convert to platform remove callback returning void
  ASoC: adi: axi-i2s: Convert to platform remove callback returning void
  ASoC: adi: axi-spdif: Convert to platform remove callback returning
void
  ASoC: amd: acp-pcm-dma: Convert to platform remove callback returning
void
  ASoC: amd: acp: rembrandt: Convert to platform remove callback
returning void
  ASoC: amd: acp: renoir: Convert to platform remove callback returning
void
  ASoC: amd: ps: Convert to platform remove callback returning void
  ASoC: amd: raven: acp3x-pcm-dma: Convert to platform remove callback
returning void
  ASoC: amd: raven: acp3x-pdm-dma: Convert to platform remove callback
returning void
  ASoC: amd: vangogh: acp5x-pcm-dma: Convert to platform remove callback
returning void
  ASoC: amd: yc: acp6x-pdm-dma: Convert to platform remove callback
returning void
  ASoC: apple: mca: Convert to platform remove callback returning void
  ASoC: atmel: atmel-i2s: Convert to platform remove callback returning
void
  ASoC: atmel: atmel_wm8904: Convert to platform remove callback
returning void
  ASoC: atmel: mchp-i2s-mcc: Convert to platform remove callback
returning void
  ASoC: atmel: mchp-pdmc: Convert to platform remove callback returning
void
  ASoC: atmel: mchp-spdifrx: Convert to platform remove callback
returning void
  ASoC: atmel: mchp-spdiftx: Convert to platform remove callback
returning void
  ASoC: atmel: mikroe-proto: Convert to platform remove callback
returning void
  ASoC: atmel: sam9g20_wm8731: Convert to platform remove callback
returning void
  ASoC: atmel: sam9x5_wm8731: Convert to platform remove callback
returning void
  ASoC: atmel: tse850-pcm5142: Convert to platform remove callback
returning void
  ASoC: au1x: ac97c: Convert to platform remove callback returning void
  ASoC: au1x: i2sc: Convert to platform remove callback returning void
  ASoC: au1x: psc-ac97: Convert to platform remove callback returning
void
  ASoC: au1x: psc-i2s: Convert to platform remove callback returning
void
  ASoC: bcm: bcm63xx-i2s-whistler: Convert to platform remove callback
returning void
  ASoC: bcm: cygnus-ssp: Convert to platform remove callback returning
void
  ASoC: cirrus: edb93xx: Convert to platform remove callback returning
void
  ASoC: cirrus: ep93xx-i2s: Convert to platform remove callback
returning void
  ASoC: codecs: cs47l15: Convert to platform remove callback returning
void
  ASoC: codecs: cs47l24: Convert to platform remove callback returning
void
  ASoC: codecs: cs47l35: Convert to platform remove callback returning
void
  ASoC: codecs: cs47l85: Convert to platform remove callback returning
void
  ASoC: codecs: cs47l90: Convert to platform remove callback returning
void
  ASoC: codecs: cs47l92: Convert to platform remove callback returning
void
  ASoC: codecs: inno_rk3036: Convert to platform remove callback
returning void
  ASoC: codecs: lpass-rx-macro: Convert to platform remove callback
returning void
  ASoC: codecs: lpass-tx-macro: Convert to platform remove callback
returning void
  ASoC: codecs: lpass-va-macro: Convert 

Re: [PATCH] cpufreq: pmac32: Use of_property_read_bool() for boolean properties

2023-03-15 Thread Michael Ellerman
Rob Herring  writes:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties.
> Convert reading boolean properties to to of_property_read_bool().
>
> Signed-off-by: Rob Herring 
> ---
>  drivers/cpufreq/pmac32-cpufreq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Michael Ellerman 

cheers

> diff --git a/drivers/cpufreq/pmac32-cpufreq.c 
> b/drivers/cpufreq/pmac32-cpufreq.c
> index 4b8ee2014da6..7ec6d1bb4592 100644
> --- a/drivers/cpufreq/pmac32-cpufreq.c
> +++ b/drivers/cpufreq/pmac32-cpufreq.c
> @@ -546,7 +546,7 @@ static int pmac_cpufreq_init_7447A(struct device_node 
> *cpunode)
>  {
>   struct device_node *volt_gpio_np;
>  
> - if (of_get_property(cpunode, "dynamic-power-step", NULL) == NULL)
> + if (!of_property_read_bool(cpunode, "dynamic-power-step"))
>   return 1;
>  
>   volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
> @@ -576,7 +576,7 @@ static int pmac_cpufreq_init_750FX(struct device_node 
> *cpunode)
>   u32 pvr;
>   const u32 *value;
>  
> - if (of_get_property(cpunode, "dynamic-power-step", NULL) == NULL)
> + if (!of_property_read_bool(cpunode, "dynamic-power-step"))
>   return 1;
>  
>   hi_freq = cur_freq;
> @@ -632,7 +632,7 @@ static int __init pmac_cpufreq_setup(void)
>  
>   /*  Check for 7447A based MacRISC3 */
>   if (of_machine_is_compatible("MacRISC3") &&
> - of_get_property(cpunode, "dynamic-power-step", NULL) &&
> + of_property_read_bool(cpunode, "dynamic-power-step") &&
>   PVR_VER(mfspr(SPRN_PVR)) == 0x8003) {
>   pmac_cpufreq_init_7447A(cpunode);
>  
> -- 
> 2.39.2


Re: [PATCH] crypto: p10-aes-gcm - remove duplicate include header

2023-03-15 Thread Herbert Xu
On Thu, Mar 16, 2023 at 02:58:04PM +1100, Michael Ellerman wrote:
>
> Although one question I do have for you is what rules, if any, do we
> have for deciding whether crypto code goes in drivers/crypto vs
> arch/*/crypto?

If it's on the CPU then it should probably live under arch.  Yes
there have been exceptions in the past, with VIA PadLock on x86
and vmx on PPC being prime examples.

> I wonder if we should move drivers/crypto/vmx into arch/powerpc/crypto,
> so that all the powerpc CRYPTOGAMS code is in one place. That would help
> to clean up some of the duplication of perl scripts we now have.

Yes I think that would certainly make sense.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: p10-aes-gcm - remove duplicate include header

2023-03-15 Thread Michael Ellerman
Herbert Xu  writes:
> On Tue, Mar 14, 2023 at 09:44:52PM +1100, Michael Ellerman wrote:
>>
>> Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the
>> first I've seen of them.
>
> Sorry, I didn't know that you weren't aware of this change.  I
> will be more careful with these ppc patches in future.

No worries, not your fault. My comments were mostly intended for Danny.

Although one question I do have for you is what rules, if any, do we
have for deciding whether crypto code goes in drivers/crypto vs
arch/*/crypto?

On powerpc we have some in arch/powerpc/crypto and some in
drivers/crypto/vmx, and I don't really know why it's split that way.

It seems like drivers/crypto is where non-CPU crypto accelerator drivers
go, but then it also has lots of in-CPU crypto code as well AFAICS.

I wonder if we should move drivers/crypto/vmx into arch/powerpc/crypto,
so that all the powerpc CRYPTOGAMS code is in one place. That would help
to clean up some of the duplication of perl scripts we now have.

cheers


Re: [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument

2023-03-15 Thread Kautuk Consul
Hi,

On 2023-03-16 14:39:08, Michael Ellerman wrote:
> Kautuk Consul  writes:
> > On 2023-03-15 15:48:53, Michael Ellerman wrote:
> >> Kautuk Consul  writes:
> >> > kvmppc_hv_entry is called from only 2 locations within
> >> > book3s_hv_rmhandlers.S. Both of those locations set r4
> >> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
> >> > So, shift the r4 load instruction to kvmppc_hv_entry and
> >> > thus modify the calling convention of this function.
> >> >
> >> > Signed-off-by: Kautuk Consul 
> >> > ---
> >> >  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 -
> >> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> >> > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> >> > index b81ba4ee0521..da9a15db12fe 100644
> >> > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> >> > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> >> > @@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
> >> >  RFI_TO_KERNEL
> >> >  
> >> >  kvmppc_call_hv_entry:
> >> > -ld  r4, HSTATE_KVM_VCPU(r13)
> >> > +/* Enter guest. */
> >> >  bl  kvmppc_hv_entry
> >> >  
> >> >  /* Back from guest - restore host state and return to caller */
> >> > @@ -352,9 +352,7 @@ kvm_secondary_got_guest:
> >> >  mtspr   SPRN_LDBAR, r0
> >> >  isync
> >> >  63:
> >> > -/* Order load of vcpu after load of vcore */
> >> > -lwsync
> >> 
> >> Where did this barrier go?
> >> 
> >> I don't see that it's covered by any existing barriers in
> >> kvmppc_hv_entry, and you don't add it back anywhere. 
> >
> > My concept about this is that since now the call to kvmppc_hv_entry
> > is first taken before the load to r4 shouldn't the pending load in the
> > pipeline of the HSTATE_KVM_VCORE as per the earlier comment be ordered 
> > anyway
> > before-hand ?
> 
> No.
> 
> > Or do you mean to say that pending loads may not be
> > cleared/flushed across the "bl " boundary ?
> 
> Right.
> 
> The "bl" imposes no ordering on loads before or after it.
> 
> In general nothing orders two independant loads, other than a barrier.
> 
> cheers

Okay, I will post a patch v3 with lwsync before the load to r4 in
kvmppc_hv_entry.

Thanks.


Re: [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument

2023-03-15 Thread Michael Ellerman
Michael Ellerman  writes:
> Kautuk Consul  writes:
>> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>>> Kautuk Consul  writes:
>>> > kvmppc_hv_entry is called from only 2 locations within
>>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>>> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
>>> > So, shift the r4 load instruction to kvmppc_hv_entry and
>>> > thus modify the calling convention of this function.
>>> >
>>> > Signed-off-by: Kautuk Consul 
>>> > ---
>>> >  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 -
>>> >  1 file changed, 4 insertions(+), 5 deletions(-)
>>> >
>>> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
>>> > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> > index b81ba4ee0521..da9a15db12fe 100644
>>> > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> > @@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
>>> >   RFI_TO_KERNEL
>>> >  
>>> >  kvmppc_call_hv_entry:
>>> > - ld  r4, HSTATE_KVM_VCPU(r13)
>>> > + /* Enter guest. */
>>> >   bl  kvmppc_hv_entry
>>> >  
>>> >   /* Back from guest - restore host state and return to caller */
>>> > @@ -352,9 +352,7 @@ kvm_secondary_got_guest:
>>> >   mtspr   SPRN_LDBAR, r0
>>> >   isync
>>> >  63:
>>> > - /* Order load of vcpu after load of vcore */
>>> > - lwsync
>>> 
>>> Where did this barrier go?
>>> 
>>> I don't see that it's covered by any existing barriers in
>>> kvmppc_hv_entry, and you don't add it back anywhere. 
>>
>> My concept about this is that since now the call to kvmppc_hv_entry
>> is first taken before the load to r4 shouldn't the pending load in the
>> pipeline of the HSTATE_KVM_VCORE as per the earlier comment be ordered anyway
>> before-hand ?
>
> No.
>  
>> Or do you mean to say that pending loads may not be
>> cleared/flushed across the "bl " boundary ?
>
> Right.
>
> The "bl" imposes no ordering on loads before or after it.
>
> In general nothing orders two independant loads, other than a barrier.

There's some docs on barriers here:

  https://www.kernel.org/doc/Documentation/memory-barriers.txt

Though admittedly it is pretty dense.

cheers


Re: [PATCH v2 2/2] arch/powerpc/kvm: kvmppc_hv_entry: remove r4 argument

2023-03-15 Thread Michael Ellerman
Kautuk Consul  writes:
> On 2023-03-15 15:48:53, Michael Ellerman wrote:
>> Kautuk Consul  writes:
>> > kvmppc_hv_entry is called from only 2 locations within
>> > book3s_hv_rmhandlers.S. Both of those locations set r4
>> > as HSTATE_KVM_VCPU(r13) before calling kvmppc_hv_entry.
>> > So, shift the r4 load instruction to kvmppc_hv_entry and
>> > thus modify the calling convention of this function.
>> >
>> > Signed-off-by: Kautuk Consul 
>> > ---
>> >  arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 -
>> >  1 file changed, 4 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
>> > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > index b81ba4ee0521..da9a15db12fe 100644
>> > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>> > @@ -85,7 +85,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
>> >RFI_TO_KERNEL
>> >  
>> >  kvmppc_call_hv_entry:
>> > -  ld  r4, HSTATE_KVM_VCPU(r13)
>> > +  /* Enter guest. */
>> >bl  kvmppc_hv_entry
>> >  
>> >/* Back from guest - restore host state and return to caller */
>> > @@ -352,9 +352,7 @@ kvm_secondary_got_guest:
>> >mtspr   SPRN_LDBAR, r0
>> >isync
>> >  63:
>> > -  /* Order load of vcpu after load of vcore */
>> > -  lwsync
>> 
>> Where did this barrier go?
>> 
>> I don't see that it's covered by any existing barriers in
>> kvmppc_hv_entry, and you don't add it back anywhere. 
>
> My concept about this is that since now the call to kvmppc_hv_entry
> is first taken before the load to r4 shouldn't the pending load in the
> pipeline of the HSTATE_KVM_VCORE as per the earlier comment be ordered anyway
> before-hand ?

No.
 
> Or do you mean to say that pending loads may not be
> cleared/flushed across the "bl " boundary ?

Right.

The "bl" imposes no ordering on loads before or after it.

In general nothing orders two independant loads, other than a barrier.

cheers


[PATCH 2/2] KVM: PPC: Add basic framework tests for kvm selftests

2023-03-15 Thread Nicholas Piggin
Add some tests that exercise basic functions of the kvm selftests
framework, guest creation, ucalls, hcalls, copying data between guest
and host, interrupts and page faults.

These don't test KVM so much, but were useful when developing the
selftests support for powerpc.

Signed-off-by: Nicholas Piggin 
---
 tools/testing/selftests/kvm/Makefile  |   2 +
 .../selftests/kvm/include/powerpc/hcall.h |   4 +-
 .../testing/selftests/kvm/powerpc/null_test.c | 186 ++
 .../selftests/kvm/powerpc/rtas_hcall.c| 146 ++
 4 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/kvm/powerpc/null_test.c
 create mode 100644 tools/testing/selftests/kvm/powerpc/rtas_hcall.c

diff --git a/tools/testing/selftests/kvm/Makefile 
b/tools/testing/selftests/kvm/Makefile
index 081cee3ecc0c..1d9eb4f3284d 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -180,6 +180,8 @@ TEST_GEN_PROGS_riscv += kvm_page_table_test
 TEST_GEN_PROGS_riscv += set_memory_region_test
 TEST_GEN_PROGS_riscv += kvm_binary_stats_test
 
+TEST_GEN_PROGS_powerpc += powerpc/null_test
+TEST_GEN_PROGS_powerpc += powerpc/rtas_hcall
 TEST_GEN_PROGS_powerpc += demand_paging_test
 TEST_GEN_PROGS_powerpc += dirty_log_test
 TEST_GEN_PROGS_powerpc += kvm_create_max_vcpus
diff --git a/tools/testing/selftests/kvm/include/powerpc/hcall.h 
b/tools/testing/selftests/kvm/include/powerpc/hcall.h
index bbad5904f37a..cbcaf180c427 100644
--- a/tools/testing/selftests/kvm/include/powerpc/hcall.h
+++ b/tools/testing/selftests/kvm/include/powerpc/hcall.h
@@ -11,7 +11,9 @@
 #define H_UCALL0
 #define UCALL_R4_UCALL 0x5715 // regular ucall, r5 contains ucall pointer
 #define UCALL_R4_EXCPT 0x1b0f // other exception, r5 contains vector, r6,7 SRRs
-  // R4==0 is a simple asm exit
+#define UCALL_R4_SIMPLE0x // simple exit usable by asm with no 
ucall data
+
+#define H_RTAS 0xf000
 
 int64_t hcall0(uint64_t token);
 int64_t hcall1(uint64_t token, uint64_t arg1);
diff --git a/tools/testing/selftests/kvm/powerpc/null_test.c 
b/tools/testing/selftests/kvm/powerpc/null_test.c
new file mode 100644
index ..ee3cf20a5cf3
--- /dev/null
+++ b/tools/testing/selftests/kvm/powerpc/null_test.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Tests for guest creation, run, ucall, interrupt, and vm dumping.
+ */
+
+#define _GNU_SOURCE /* for program_invocation_short_name */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "kselftest.h"
+#include "processor.h"
+
+extern void guest_code_asm(void);
+asm(".global guest_code_asm");
+asm(".balign 4");
+asm("guest_code_asm:");
+asm("li 3,0"); // H_UCALL
+asm("li 4,0"); // UCALL_R4_SIMPLE
+asm("sc 1");
+
+static void guest_code_ucall(void)
+{
+   GUEST_DONE();
+}
+
+static void guest_code_trap(void)
+{
+   asm volatile("trap");
+}
+
+static void guest_code_dsi(void)
+{
+   *(volatile int *)0;
+}
+
+static void test_asm(void)
+{
+   struct kvm_vcpu *vcpu;
+   struct kvm_vm *vm;
+   int ret;
+
+   vm = vm_create_with_one_vcpu(, guest_code_asm);
+
+   ret = _vcpu_run(vcpu);
+
+   TEST_ASSERT(ret == 0, "vcpu_run failed: %d\n", ret);
+   TEST_ASSERT(get_ucall(vcpu, NULL) == UCALL_NONE,
+   "Invalid guest done status: exit_reason=%s\n",
+   exit_reason_str(vcpu->run->exit_reason));
+
+   kvm_vm_free(vm);
+}
+
+static void test_ucall(void)
+{
+   struct kvm_vcpu *vcpu;
+   struct kvm_vm *vm;
+   int ret;
+
+   vm = vm_create_with_one_vcpu(, guest_code_ucall);
+
+   ret = _vcpu_run(vcpu);
+
+   TEST_ASSERT(ret == 0, "vcpu_run failed: %d\n", ret);
+   TEST_ASSERT(get_ucall(vcpu, NULL) == UCALL_DONE,
+   "Invalid guest done status: exit_reason=%s\n",
+   exit_reason_str(vcpu->run->exit_reason));
+
+   kvm_vm_free(vm);
+}
+
+static bool got_trap;
+static bool trap_handler(struct kvm_vcpu *vcpu, unsigned trap)
+{
+   if (trap == 0x700) {
+   got_trap = true;
+   return true;
+   }
+   return false;
+}
+
+static void test_trap(void)
+{
+   struct kvm_vcpu *vcpu;
+   struct kvm_vm *vm;
+   int ret;
+
+   interrupt_handler = trap_handler;
+
+   vm = vm_create_with_one_vcpu(, guest_code_trap);
+
+   ret = _vcpu_run(vcpu);
+
+   TEST_ASSERT(ret == 0, "vcpu_run failed: %d\n", ret);
+   TEST_ASSERT(got_trap,
+   "Invalid guest done status: exit_reason=%s\n",
+   exit_reason_str(vcpu->run->exit_reason));
+
+   kvm_vm_free(vm);
+
+   interrupt_handler = NULL;
+}
+
+static bool got_dsi;
+static bool dsi_handler(struct kvm_vcpu *vcpu, unsigned trap)
+{
+   if (trap == 0x300) {
+   got_dsi = true;
+   return true;
+   }
+   return 

[PATCH 1/2] KVM: PPC: Add kvm selftests support for powerpc

2023-03-15 Thread Nicholas Piggin
Implement KVM selftests support for Book3S-64.

ucalls are implemented with an unsuppored PAPR hcall number which causes
KVM to exit to userspace.

Virtual memory is only implemented for 64K page size and the radix MMU,
and only the base page size is supported for now.

Signed-off-by: Nicholas Piggin 
---
 tools/testing/selftests/kvm/Makefile  |  12 +
 .../selftests/kvm/include/kvm_util_base.h |  13 +
 .../selftests/kvm/include/powerpc/hcall.h |  20 +
 .../selftests/kvm/include/powerpc/processor.h |  13 +
 tools/testing/selftests/kvm/lib/kvm_util.c|  10 +
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 +++
 .../selftests/kvm/lib/powerpc/processor.c | 355 ++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  30 ++
 8 files changed, 498 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c

diff --git a/tools/testing/selftests/kvm/Makefile 
b/tools/testing/selftests/kvm/Makefile
index 84a627c43795..081cee3ecc0c 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -55,6 +55,10 @@ LIBKVM_s390x += lib/s390x/ucall.c
 LIBKVM_riscv += lib/riscv/processor.c
 LIBKVM_riscv += lib/riscv/ucall.c
 
+LIBKVM_powerpc += lib/powerpc/processor.c
+LIBKVM_powerpc += lib/powerpc/ucall.c
+LIBKVM_powerpc += lib/powerpc/hcall.c
+
 # Non-compiled test targets
 TEST_PROGS_x86_64 += x86_64/nx_huge_pages_test.sh
 
@@ -176,6 +180,14 @@ TEST_GEN_PROGS_riscv += kvm_page_table_test
 TEST_GEN_PROGS_riscv += set_memory_region_test
 TEST_GEN_PROGS_riscv += kvm_binary_stats_test
 
+TEST_GEN_PROGS_powerpc += demand_paging_test
+TEST_GEN_PROGS_powerpc += dirty_log_test
+TEST_GEN_PROGS_powerpc += kvm_create_max_vcpus
+TEST_GEN_PROGS_powerpc += kvm_page_table_test
+TEST_GEN_PROGS_powerpc += rseq_test
+TEST_GEN_PROGS_powerpc += set_memory_region_test
+TEST_GEN_PROGS_powerpc += kvm_binary_stats_test
+
 TEST_PROGS += $(TEST_PROGS_$(ARCH_DIR))
 TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(ARCH_DIR))
 TEST_GEN_PROGS_EXTENDED += $(TEST_GEN_PROGS_EXTENDED_$(ARCH_DIR))
diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h 
b/tools/testing/selftests/kvm/include/kvm_util_base.h
index fbc2a79369b8..f6807aea634f 100644
--- a/tools/testing/selftests/kvm/include/kvm_util_base.h
+++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
@@ -105,6 +105,7 @@ struct kvm_vm {
bool pgd_created;
vm_paddr_t ucall_mmio_addr;
vm_paddr_t pgd;
+   vm_paddr_t prtb; // powerpc process table
vm_vaddr_t gdt;
vm_vaddr_t tss;
vm_vaddr_t idt;
@@ -160,6 +161,7 @@ enum vm_guest_mode {
VM_MODE_PXXV48_4K,  /* For 48bits VA but ANY bits PA */
VM_MODE_P47V64_4K,
VM_MODE_P44V64_4K,
+   VM_MODE_P52V52_64K,
VM_MODE_P36V48_4K,
VM_MODE_P36V48_16K,
VM_MODE_P36V48_64K,
@@ -197,6 +199,17 @@ extern enum vm_guest_mode vm_mode_default;
 #define MIN_PAGE_SHIFT 12U
 #define ptes_per_page(page_size)   ((page_size) / 8)
 
+#elif defined(__powerpc64__)
+
+/* Radix guest EA and RA are 52-bit on POWER9 and POWER10 */
+#define VM_MODE_DEFAULTVM_MODE_P52V52_64K
+#define MIN_PAGE_SHIFT 12U /// XXX: hack to allocate more page 
table memory because we aren't allocating page tables well on 64K base page size
+#define ptes_per_page(page_size)   ((page_size) / 8)
+
+#else
+
+#error "KVM selftests not implemented for architecture"
+
 #endif
 
 #define MIN_PAGE_SIZE  (1U << MIN_PAGE_SHIFT)
diff --git a/tools/testing/selftests/kvm/include/powerpc/hcall.h 
b/tools/testing/selftests/kvm/include/powerpc/hcall.h
new file mode 100644
index ..bbad5904f37a
--- /dev/null
+++ b/tools/testing/selftests/kvm/include/powerpc/hcall.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * powerpc hcall defines
+ */
+#ifndef SELFTEST_KVM_HCALL_H
+#define SELFTEST_KVM_HCALL_H
+
+#include 
+
+/* Ucalls use unimplemented PAPR hcall 0 which exits KVM */
+#define H_UCALL0
+#define UCALL_R4_UCALL 0x5715 // regular ucall, r5 contains ucall pointer
+#define UCALL_R4_EXCPT 0x1b0f // other exception, r5 contains vector, r6,7 SRRs
+  // R4==0 is a simple asm exit
+
+int64_t hcall0(uint64_t token);
+int64_t hcall1(uint64_t token, uint64_t arg1);
+int64_t hcall2(uint64_t token, uint64_t arg1, uint64_t arg2);
+
+#endif
diff --git a/tools/testing/selftests/kvm/include/powerpc/processor.h 
b/tools/testing/selftests/kvm/include/powerpc/processor.h
new file mode 100644
index ..b800b565b638
--- /dev/null
+++ b/tools/testing/selftests/kvm/include/powerpc/processor.h
@@ -0,0 +1,13 @@
+/* 

[PATCH 0/2] KVM: PPC: support kvm selftests

2023-03-15 Thread Nicholas Piggin
Hi,

This series adds initial KVM selftests support for powerpc
(64-bit, BookS). It spans 3 maintainers but it does not really
affect arch/powerpc, and it is well contained in selftests
code, just touches some makefiles and a tiny bit headers so
conflicts should be unlikely and trivial.

I guess Paolo is the best point to merge these, if no comments
or objections?

Thanks,
Nick

Nicholas Piggin (2):
  KVM: PPC: Add kvm selftests support for powerpc
  KVM: PPC: Add basic framework tests for kvm selftests

 tools/testing/selftests/kvm/Makefile  |  14 +
 .../selftests/kvm/include/kvm_util_base.h |  13 +
 .../selftests/kvm/include/powerpc/hcall.h |  22 ++
 .../selftests/kvm/include/powerpc/processor.h |  13 +
 tools/testing/selftests/kvm/lib/kvm_util.c|  10 +
 .../testing/selftests/kvm/lib/powerpc/hcall.c |  45 +++
 .../selftests/kvm/lib/powerpc/processor.c | 355 ++
 .../testing/selftests/kvm/lib/powerpc/ucall.c |  30 ++
 .../testing/selftests/kvm/powerpc/null_test.c | 186 +
 .../selftests/kvm/powerpc/rtas_hcall.c| 146 +++
 10 files changed, 834 insertions(+)
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
 create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
 create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
 create mode 100644 tools/testing/selftests/kvm/powerpc/null_test.c
 create mode 100644 tools/testing/selftests/kvm/powerpc/rtas_hcall.c

-- 
2.37.2



[powerpc:merge] BUILD SUCCESS 065ffaee73892e8a3629b4cfbe635697807a3c6f

2023-03-15 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
merge
branch HEAD: 065ffaee73892e8a3629b4cfbe635697807a3c6f  Automatic merge of 
'master' into merge (2023-03-14 09:54)

elapsed time: 728m

configs tested: 137
configs skipped: 11

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
alpharandconfig-r025-20230312   gcc  
alpharandconfig-r026-20230313   gcc  
alpharandconfig-r031-20230313   gcc  
alpharandconfig-r033-20230313   gcc  
alpharandconfig-r034-20230313   gcc  
alpharandconfig-r036-20230313   gcc  
arc  allyesconfig   gcc  
arc  buildonly-randconfig-r001-20230312   gcc  
arc defconfig   gcc  
arc  randconfig-r043-20230312   gcc  
arc  randconfig-r043-20230313   gcc  
arm  allmodconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   gcc  
arm  randconfig-r001-20230312   gcc  
arm  randconfig-r013-20230312   clang
arm  randconfig-r021-20230312   clang
arm  randconfig-r046-20230312   clang
arm  randconfig-r046-20230313   gcc  
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
arm64randconfig-r002-20230313   gcc  
arm64randconfig-r012-20230315   clang
arm64randconfig-r033-20230312   clang
arm64randconfig-r035-20230313   gcc  
cskydefconfig   gcc  
csky randconfig-r026-20230312   gcc  
csky randconfig-r032-20230312   gcc  
hexagon  buildonly-randconfig-r001-20230313   clang
hexagon  randconfig-r004-20230312   clang
hexagon  randconfig-r041-20230312   clang
hexagon  randconfig-r041-20230313   clang
hexagon  randconfig-r045-20230312   clang
hexagon  randconfig-r045-20230313   clang
i386 allyesconfig   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386 randconfig-a001-20230313   gcc  
i386 randconfig-a002-20230313   gcc  
i386 randconfig-a003-20230313   gcc  
i386 randconfig-a004-20230313   gcc  
i386 randconfig-a005-20230313   gcc  
i386 randconfig-a006-20230313   gcc  
i386 randconfig-a011-20230313   clang
i386 randconfig-a012-20230313   clang
i386 randconfig-a013-20230313   clang
i386 randconfig-a014-20230313   clang
i386 randconfig-a015-20230313   clang
i386 randconfig-a016-20230313   clang
i386 randconfig-r014-20230313   clang
ia64 allmodconfig   gcc  
ia64defconfig   gcc  
ia64 randconfig-r006-20230313   gcc  
ia64 randconfig-r015-20230315   gcc  
ia64 randconfig-r016-20230312   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
loongarchrandconfig-r004-20230313   gcc  
loongarchrandconfig-r013-20230313   gcc  
m68k allmodconfig   gcc  
m68kdefconfig   gcc  
m68k randconfig-r011-20230312   gcc  
m68k randconfig-r011-20230313   gcc  
m68k randconfig-r012-20230312   gcc  
m68k randconfig-r014-20230315   gcc  
m68k randconfig-r025-20230313   gcc  
microblaze   buildonly-randconfig-r005-20230312   gcc  
microblaze   randconfig-r003-20230312   gcc  
microblaze   randconfig-r005-20230312   gcc  
mips allmodconfig   gcc  
mips allyesconfig   gcc  
mips randconfig-r022-20230312   clang
nios2   defconfig   gcc  
nios2randconfig-r003-20230313   gcc  
nios2randconfig-r015-20230313   gcc  
nios2randconfig-r016-20230313   gcc  
nios2randconfig-r023-20230313   gcc  
nios2randconfig-r031-20230312   gcc  
openrisc randconfig-r012-20230313   gcc  
openrisc randconfig-r023-20230312   gcc  
openrisc randconfig-r032-20230313   gcc  
parisc  defconfig   gcc  
parisc

[powerpc:fixes] BUILD SUCCESS f2c7e3562b4c4f1699acc1538ebf3e75f5cced35

2023-03-15 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
fixes
branch HEAD: f2c7e3562b4c4f1699acc1538ebf3e75f5cced35  powerpc/mm: Fix false 
detection of read faults

elapsed time: 729m

configs tested: 71
configs skipped: 138

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arc  randconfig-r014-20230312   gcc  
arm  allmodconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   gcc  
arm  randconfig-r013-20230313   gcc  
arm  randconfig-r016-20230313   gcc  
arm  randconfig-r046-20230312   clang
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
arm64randconfig-r011-20230312   gcc  
cskydefconfig   gcc  
csky randconfig-r011-20230313   gcc  
csky randconfig-r012-20230313   gcc  
hexagon  randconfig-r041-20230312   clang
hexagon  randconfig-r041-20230313   clang
hexagon  randconfig-r045-20230312   clang
hexagon  randconfig-r045-20230313   clang
i386 allyesconfig   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386 randconfig-a011-20230313   clang
i386 randconfig-a012-20230313   clang
i386 randconfig-a013-20230313   clang
i386 randconfig-a014-20230313   clang
i386 randconfig-a015-20230313   clang
i386 randconfig-a016-20230313   clang
ia64 allmodconfig   gcc  
ia64defconfig   gcc  
m68k allmodconfig   gcc  
m68kdefconfig   gcc  
m68k randconfig-r014-20230313   gcc  
m68k randconfig-r015-20230313   gcc  
m68k randconfig-r016-20230312   gcc  
mips allmodconfig   gcc  
nios2   defconfig   gcc  
nios2randconfig-r012-20230312   gcc  
nios2randconfig-r013-20230312   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  randconfig-r015-20230312   gcc  
riscvrandconfig-r042-20230313   clang
s390 allmodconfig   gcc  
s390 allyesconfig   gcc  
s390defconfig   gcc  
s390 randconfig-r044-20230313   clang
sh   allmodconfig   gcc  
sparc   defconfig   gcc  
x86_64allnoconfig   gcc  
x86_64   allyesconfig   gcc  
x86_64  defconfig   gcc  
x86_64  kexec   gcc  
x86_64   randconfig-a001-20230313   gcc  
x86_64   randconfig-a002-20230313   gcc  
x86_64   randconfig-a003-20230313   gcc  
x86_64   randconfig-a004-20230313   gcc  
x86_64   randconfig-a005-20230313   gcc  
x86_64   randconfig-a006-20230313   gcc  
x86_64   randconfig-a011-20230313   clang
x86_64   randconfig-a012-20230313   clang
x86_64   randconfig-a013-20230313   clang
x86_64   randconfig-a014-20230313   clang
x86_64   randconfig-a015-20230313   clang
x86_64   randconfig-a016-20230313   clang
x86_64randconfig-k001   clang
x86_64   rhel-8.3   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests


Re: [PATCH 0/3] COVER: Remove memcpy_page_flushcache()

2023-03-15 Thread Ira Weiny
Dave Hansen wrote:
> On 3/15/23 16:20, Ira Weiny wrote:
> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray 
> > callbacks") removed the calls to memcpy_page_flushcache().
> > 
> > kmap_atomic() is deprecated and used in the x86 version of
> > memcpy_page_flushcache().
> > 
> > Remove the unnecessary memcpy_page_flushcache() call from all arch's.
> 
> Hi Ira,
> 
> Since the common code user is already gone these three patches seem
> quite independent.  It seems like the right thing to do is have
> individual arch maintainers cherry pick their arch patch and carry it
> independently.

Yes.

> 
> Is there a compelling reason to have someone pick up and carry these all
> together that I'm missing?

No reason.  Would you like me to submit them individually?

Sorry, submitting them separately crossed my mind when I wrote them but I
kind of forgot as they were all on the same branch and I was waiting for
after the merge window to submit them.

Ira


Re: boot regression on ppc64 with linux 6.2

2023-03-15 Thread Michael Ellerman
Andrea Righi  writes:
> On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
>> Andrea Righi  writes:
>> > I'm triggering the following bug when booting my qemu powerpc VM:
>> 
>> I'm not seeing that here :/
>> 
>> Can you give a bit more detail?
>>  - qemu version
>>  - qemu command line
>>  - what userspace are you using?
>>  - full dmesg of the failing case
>
> Yeah, ignore this for now, it could be related to another custom patch
> that I had applied (and forgot about it sorry), this one:
> https://lore.kernel.org/lkml/20230119155709.20d87e35.g...@garyguo.net/T/

OK. Did you do the bisect with that patch applied though?

> That is causing other issues on ppc64, so I think it might be related to
> that, I'll do more tests making sure I use a vanilla kernel.

I don't see an obvious connection between the modversions stuff and this
crash, but I guess it's possible.

cheers


Re: [PATCH 0/3] COVER: Remove memcpy_page_flushcache()

2023-03-15 Thread Dave Hansen
On 3/15/23 16:20, Ira Weiny wrote:
> Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray 
> callbacks") removed the calls to memcpy_page_flushcache().
> 
> kmap_atomic() is deprecated and used in the x86 version of
> memcpy_page_flushcache().
> 
> Remove the unnecessary memcpy_page_flushcache() call from all arch's.

Hi Ira,

Since the common code user is already gone these three patches seem
quite independent.  It seems like the right thing to do is have
individual arch maintainers cherry pick their arch patch and carry it
independently.

Is there a compelling reason to have someone pick up and carry these all
together that I'm missing?


[PATCH 3/3] arm: uaccess: Remove memcpy_page_flushcache()

2023-03-15 Thread Ira Weiny
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().

Remove the unnecessary memcpy_page_flushcache() call.

Cc: Al Viro 
Cc: "Dan Williams" 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Ira Weiny 
---
 arch/arm64/include/asm/uaccess.h| 2 --
 arch/arm64/lib/uaccess_flushcache.c | 6 --
 2 files changed, 8 deletions(-)

diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 5c7b2f9d5913..4bf2c0975a82 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -449,8 +449,6 @@ extern long strncpy_from_user(char *dest, const char __user 
*src, long count);
 extern __must_check long strnlen_user(const char __user *str, long n);
 
 #ifdef CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE
-struct page;
-void memcpy_page_flushcache(char *to, struct page *page, size_t offset, size_t 
len);
 extern unsigned long __must_check __copy_user_flushcache(void *to, const void 
__user *from, unsigned long n);
 
 static inline int __copy_from_user_flushcache(void *dst, const void __user 
*src, unsigned size)
diff --git a/arch/arm64/lib/uaccess_flushcache.c 
b/arch/arm64/lib/uaccess_flushcache.c
index baee22961bdb..7510d1a23124 100644
--- a/arch/arm64/lib/uaccess_flushcache.c
+++ b/arch/arm64/lib/uaccess_flushcache.c
@@ -19,12 +19,6 @@ void memcpy_flushcache(void *dst, const void *src, size_t 
cnt)
 }
 EXPORT_SYMBOL_GPL(memcpy_flushcache);
 
-void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
-   size_t len)
-{
-   memcpy_flushcache(to, page_address(page) + offset, len);
-}
-
 unsigned long __copy_user_flushcache(void *to, const void __user *from,
 unsigned long n)
 {

-- 
2.39.2



[PATCH 2/3] powerpc: Remove memcpy_page_flushcache()

2023-03-15 Thread Ira Weiny
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().

Remove the unnecessary memcpy_page_flushcache() call.

Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Al Viro 
Cc: "Dan Williams" 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ira Weiny 
---
 arch/powerpc/include/asm/uaccess.h | 2 --
 arch/powerpc/lib/pmem.c| 7 ---
 2 files changed, 9 deletions(-)

diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 3ddc65c63a49..52378e641d38 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -361,8 +361,6 @@ copy_mc_to_user(void __user *to, const void *from, unsigned 
long n)
 
 extern long __copy_from_user_flushcache(void *dst, const void __user *src,
unsigned size);
-extern void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
-  size_t len);
 
 static __must_check inline bool user_access_begin(const void __user *ptr, 
size_t len)
 {
diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
index eb2919ddf9b9..4e724c4c01ad 100644
--- a/arch/powerpc/lib/pmem.c
+++ b/arch/powerpc/lib/pmem.c
@@ -85,10 +85,3 @@ void memcpy_flushcache(void *dest, const void *src, size_t 
size)
clean_pmem_range(start, start + size);
 }
 EXPORT_SYMBOL(memcpy_flushcache);
-
-void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
-   size_t len)
-{
-   memcpy_flushcache(to, page_to_virt(page) + offset, len);
-}
-EXPORT_SYMBOL(memcpy_page_flushcache);

-- 
2.39.2



[PATCH 1/3] x86, uaccess: Remove memcpy_page_flushcache()

2023-03-15 Thread Ira Weiny
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
callbacks") removed the calls to memcpy_page_flushcache().

kmap_atomic() is deprecated and used in memcpy_page_flushcache().

Remove the unnecessary memcpy_page_flushcache() call.

Cc: Al Viro 
Cc: "Dan Williams" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Signed-off-by: Ira Weiny 
---
 arch/x86/include/asm/uaccess_64.h | 2 --
 arch/x86/lib/usercopy_64.c| 9 -
 2 files changed, 11 deletions(-)

diff --git a/arch/x86/include/asm/uaccess_64.h 
b/arch/x86/include/asm/uaccess_64.h
index d13d71af5cf6..c6b1dcded364 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -62,8 +62,6 @@ extern long __copy_user_nocache(void *dst, const void __user 
*src,
unsigned size, int zerorest);
 
 extern long __copy_user_flushcache(void *dst, const void __user *src, unsigned 
size);
-extern void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
-  size_t len);
 
 static inline int
 __copy_from_user_inatomic_nocache(void *dst, const void __user *src,
diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
index 6c1f8ac5e721..f515542f017f 100644
--- a/arch/x86/lib/usercopy_64.c
+++ b/arch/x86/lib/usercopy_64.c
@@ -136,13 +136,4 @@ void __memcpy_flushcache(void *_dst, const void *_src, 
size_t size)
}
 }
 EXPORT_SYMBOL_GPL(__memcpy_flushcache);
-
-void memcpy_page_flushcache(char *to, struct page *page, size_t offset,
-   size_t len)
-{
-   char *from = kmap_atomic(page);
-
-   memcpy_flushcache(to, from + offset, len);
-   kunmap_atomic(from);
-}
 #endif

-- 
2.39.2



[PATCH 0/3] COVER: Remove memcpy_page_flushcache()

2023-03-15 Thread Ira Weiny
Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray 
callbacks") removed the calls to memcpy_page_flushcache().

kmap_atomic() is deprecated and used in the x86 version of
memcpy_page_flushcache().

Remove the unnecessary memcpy_page_flushcache() call from all arch's.

Signed-off-by: Ira Weiny 
---
Ira Weiny (3):
  x86, uaccess: Remove memcpy_page_flushcache()
  powerpc: Remove memcpy_page_flushcache()
  arm: uaccess: Remove memcpy_page_flushcache()

 arch/arm64/include/asm/uaccess.h| 2 --
 arch/arm64/lib/uaccess_flushcache.c | 6 --
 arch/powerpc/include/asm/uaccess.h  | 2 --
 arch/powerpc/lib/pmem.c | 7 ---
 arch/x86/include/asm/uaccess_64.h   | 2 --
 arch/x86/lib/usercopy_64.c  | 9 -
 6 files changed, 28 deletions(-)
---
base-commit: 6015b1aca1a233379625385feb01dd014aca60b5
change-id: 20221230-kmap-x86-bfda7e1f07ee

Best regards,
-- 
Ira Weiny 



Re: [PATCH v3 4/9] scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()

2023-03-15 Thread Bjorn Helgaas
On Tue, Dec 06, 2022 at 04:13:35PM -0600, Bjorn Helgaas wrote:
> On Wed, Sep 28, 2022 at 06:59:41PM +0800, Zhuo Chen wrote:
> > lpfc_aer_cleanup_state() requires clearing both fatal and non-fatal
> > uncorrectable error status.
> 
> I don't know what the point of lpfc_aer_cleanup_state() is.  AER
> errors should be handled and cleared by the PCI core, not by
> individual drivers.  Only lpfc, liquidio, and sky2 touch
> PCI_ERR_UNCOR_STATUS.
> 
> But lpfc_aer_cleanup_state() is visible in the
> "lpfc_aer_state_cleanup" sysfs file, so removing it would break any
> userspace that uses it.
> 
> If we can rely on the PCI core to clean up AER errors itself
> (admittedly, that might be a big "if"), maybe lpfc_aer_cleanup_state()
> could just become a no-op?
> 
> Any comment from the LPFC folks?
> 
> Ideally, I would rather not export pci_aer_clear_nonfatal_status() or
> pci_aer_clear_uncorrect_error_status() outside the PCI core at all.

Resurrecting this old thread.  Zhuo, can you figure out where the PCI
core clears these errors, include that in the commit log, and propose
a patch that makes lpfc_aer_cleanup_state() a no-op, by removing the
pci_aer_clear_nonfatal_status() call completely?

Such a patch could be sent to the SCSI maintainers since it doesn't
involve the PCI core.

If it turns out that the PCI core *doesn't* clear these errors, we
should figure out *why* it doesn't and try to change the PCI core so
it does.

> > But using pci_aer_clear_nonfatal_status()
> > will only clear non-fatal error status. To clear both fatal and
> > non-fatal error status, use pci_aer_clear_uncorrect_error_status().
> > 
> > Signed-off-by: Zhuo Chen 
> > ---
> >  drivers/scsi/lpfc/lpfc_attr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
> > index 09cf2cd0ae60..d835cc0ba153 100644
> > --- a/drivers/scsi/lpfc/lpfc_attr.c
> > +++ b/drivers/scsi/lpfc/lpfc_attr.c
> > @@ -4689,7 +4689,7 @@ static DEVICE_ATTR_RW(lpfc_aer_support);
> >   * Description:
> >   * If the @buf contains 1 and the device currently has the AER support
> >   * enabled, then invokes the kernel AER helper routine
> > - * pci_aer_clear_nonfatal_status() to clean up the uncorrectable
> > + * pci_aer_clear_uncorrect_error_status() to clean up the uncorrectable
> >   * error status register.
> >   *
> >   * Notes:
> > @@ -4715,7 +4715,7 @@ lpfc_aer_cleanup_state(struct device *dev, struct 
> > device_attribute *attr,
> > return -EINVAL;
> >  
> > if (phba->hba_flag & HBA_AER_ENABLED)
> > -   rc = pci_aer_clear_nonfatal_status(phba->pcidev);
> > +   rc = pci_aer_clear_uncorrect_error_status(phba->pcidev);
> >  
> > if (rc == 0)
> > return strlen(buf);
> > -- 
> > 2.30.1 (Apple Git-130)
> > 


Re: [PATCH v3 3/9] NTB: Remove pci_aer_clear_nonfatal_status() call

2023-03-15 Thread Bjorn Helgaas
On Wed, Sep 28, 2022 at 06:59:40PM +0800, Zhuo Chen wrote:
> There is no need to clear error status during init code, so remove it.
> 
> Signed-off-by: Zhuo Chen 

Can you send this to the NTB folks?  It doesn't depend on anything, so
no real reason to merge via the PCI tree.

To help reviewers, ideally the commit log would mention where the PCI
core clears the non-fatal errors so the driver doesn't have to.

> ---
>  drivers/ntb/hw/idt/ntb_hw_idt.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
> index 0ed6f809ff2e..fed03217289d 100644
> --- a/drivers/ntb/hw/idt/ntb_hw_idt.c
> +++ b/drivers/ntb/hw/idt/ntb_hw_idt.c
> @@ -2657,8 +2657,6 @@ static int idt_init_pci(struct idt_ntb_dev *ndev)
>   ret = pci_enable_pcie_error_reporting(pdev);
>   if (ret != 0)
>   dev_warn(>dev, "PCIe AER capability disabled\n");
> - else /* Cleanup nonfatal error status before getting to init */
> - pci_aer_clear_nonfatal_status(pdev);
>  
>   /* First enable the PCI device */
>   ret = pcim_enable_device(pdev);
> -- 
> 2.30.1 (Apple Git-130)
> 


Re: [PATCH v3 1/9] PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core

2023-03-15 Thread Bjorn Helgaas
On Wed, Sep 28, 2022 at 06:59:38PM +0800, Zhuo Chen wrote:
> In lpfc_aer_cleanup_state(), uncorrectable error status needs to be
> cleared, which can be done by calling pci_aer_clear_nonfatal_status()
> and pci_aer_clear_fatal_status(). Meanwhile they can be combined in
> one function (the same in dpc_process_error). So add
> pci_aer_clear_uncorrect_error_status() function to PCI core and
> export symbol to other modules which wants to use it.

Sorry for getting back to this so late.

Why does lpfc need this?  I think AER error status should be cleared
by the PCI core, not by individual drivers, so I really would rather
not add a new interface for drivers to use.

> Signed-off-by: Zhuo Chen 
> ---
>  drivers/pci/pcie/aer.c | 16 
>  include/linux/aer.h|  5 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index e2d8a74f83c3..4e637121be23 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -286,6 +286,22 @@ void pci_aer_clear_fatal_status(struct pci_dev *dev)
>   pci_write_config_dword(dev, aer + PCI_ERR_UNCOR_STATUS, status);
>  }
>  
> +int pci_aer_clear_uncorrect_error_status(struct pci_dev *dev)
> +{
> + int aer = dev->aer_cap;
> + u32 status;
> +
> + if (!pcie_aer_is_native(dev))
> + return -EIO;
> +
> + pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_STATUS, );
> + if (status)
> + pci_write_config_dword(dev, aer + PCI_ERR_UNCOR_STATUS, status);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_aer_clear_uncorrect_error_status);
> +
>  /**
>   * pci_aer_raw_clear_status - Clear AER error registers.
>   * @dev: the PCI device
> diff --git a/include/linux/aer.h b/include/linux/aer.h
> index 97f64ba1b34a..154690c278cb 100644
> --- a/include/linux/aer.h
> +++ b/include/linux/aer.h
> @@ -45,6 +45,7 @@ struct aer_capability_regs {
>  int pci_enable_pcie_error_reporting(struct pci_dev *dev);
>  int pci_disable_pcie_error_reporting(struct pci_dev *dev);
>  int pci_aer_clear_nonfatal_status(struct pci_dev *dev);
> +int pci_aer_clear_uncorrect_error_status(struct pci_dev *dev);
>  void pci_save_aer_state(struct pci_dev *dev);
>  void pci_restore_aer_state(struct pci_dev *dev);
>  #else
> @@ -60,6 +61,10 @@ static inline int pci_aer_clear_nonfatal_status(struct 
> pci_dev *dev)
>  {
>   return -EINVAL;
>  }
> +static inline int pci_aer_clear_uncorrect_error_status(struct pci_dev *dev)
> +{
> + return -EINVAL;
> +}
>  static inline void pci_save_aer_state(struct pci_dev *dev) {}
>  static inline void pci_restore_aer_state(struct pci_dev *dev) {}
>  #endif
> -- 
> 2.30.1 (Apple Git-130)
> 


Re: [PATCH] modpost: support arbitrary symbol length in modversion

2023-03-15 Thread Andrea Righi
On Thu, Mar 16, 2023 at 01:18:23AM +0900, Masahiro Yamada wrote:
> On Tue, Mar 14, 2023 at 11:38 PM Andrea Righi
>  wrote:
> >
> > On Mon, Mar 13, 2023 at 11:09:31PM +0100, Andrea Righi wrote:
> > > On Mon, Mar 13, 2023 at 11:02:34PM +0100, Michal Suchánek wrote:
> > > > On Mon, Mar 13, 2023 at 10:53:34PM +0100, Andrea Righi wrote:
> > > > > On Mon, Mar 13, 2023 at 10:48:53PM +0100, Michal Suchánek wrote:
> > > > > > Hello,
> > > > > >
> > > > > > On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> > > > > > > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > > > > > > > Currently modversion uses a fixed size array of size (64 - 
> > > > > > > > sizeof(long))
> > > > > > > > to store symbol names, thus placing a hard limit on length of 
> > > > > > > > symbols.
> > > > > > > > Rust symbols (which encodes crate and module names) can be 
> > > > > > > > quite a bit
> > > > > > > > longer. The length limit in kallsyms is increased to 512 for 
> > > > > > > > this reason.
> > > > > > > >
> > > > > > > > It's a waste of space to simply expand the fixed array size to 
> > > > > > > > 512 in
> > > > > > > > modversion info entries. I therefore make it variably sized, 
> > > > > > > > with offset
> > > > > > > > to the next entry indicated by the initial "next" field.
> > > > > > > >
> > > > > > > > In addition to supporting longer-than-56/60 byte symbols, this 
> > > > > > > > patch also
> > > > > > > > reduce the size for short symbols by getting rid of excessive 0 
> > > > > > > > paddings.
> > > > > > > > There are still some zero paddings to ensure "next" and "crc" 
> > > > > > > > fields are
> > > > > > > > properly aligned.
> > > > > > > >
> > > > > > > > This patch does have a tiny drawback that it makes ".mod.c" 
> > > > > > > > files generated
> > > > > > > > a bit less easy to read, as code like
> > > > > > > >
> > > > > > > > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > > > > > > > "symbol\0\0"
> > > > > > > >
> > > > > > > > is generated as opposed to
> > > > > > > >
> > > > > > > > { 0x12345678, "symbol" },
> > > > > > > >
> > > > > > > > because the structure is now variable-length. But hopefully 
> > > > > > > > nobody reads
> > > > > > > > the generated file :)
> > > > > > > >
> > > > > > > > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol 
> > > > > > > > length to 512")
> > > > > > > > Link: https://github.com/Rust-for-Linux/linux/pull/379
> > > > > > > >
> > > > > > > > Signed-off-by: Gary Guo 
> > > > > > >
> > > > > > > Is there any newer version of this patch?
> > > > > > >
> > > > > > > I'm doing some tests with it, but I'm getting boot failures on 
> > > > > > > ppc64
> > > > > > > with this applied (at boot kernel is spitting out lots of oops'es 
> > > > > > > and
> > > > > > > unfortunately it's really hard to copy paste or just read them 
> > > > > > > from the
> > > > > > > console).
> > > > > >
> > > > > > Are you using the ELF ABI v1 or v2?
> > > > > >
> > > > > > v1 may have some additional issues when it comes to these symbol 
> > > > > > tables.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Michal
> > > > >
> > > > > I have CONFIG_PPC64_ELF_ABI_V2=y in my .config, so I guess I'm using 
> > > > > v2.
> > > > >
> > > > > BTW, the issue seems to be in dedotify_versions(), as a silly test I
> > > > > tried to comment out this function completely to be a no-op and now my
> > > > > system boots fine (but I guess I'm probably breaking something else).
> > > >
> > > > Probably not. You should not have the extra leading dot on ABI v2. So if
> > > > dedotify does something that means something generates and then expects
> > > > back symbols with a leading dot, and this workaround for ABI v1 breaks
> > > > that. Or maybe it is called when it shouldn't.
> > >
> > > Hm.. I'll add some debugging to this function to see what happens exactly.
> >
> > Alright I've done more tests across different architectures. My problem
> > with ppc64 is that this architecture is evaluating sechdrs[i].sh_size
> > using get_stubs_size(), that apparently can add some extra padding, so
> > doing (vers + vers->next < end) isn't a reliable check to determine the
> > end of the variable array, because sometimes "end" can be greater than
> > the last "vers + vers->next" entry.
> 
> 
> I am not familiar enough with ppc, so I may be misundering.
> 
> Checking the for-loop in module_frob_arch_sections(),
> they seem to be orthogonal to me.
> 
> dedotify_versions() is only called for the "__versions" section.
> get_stubs_size() only affects the ".stubs" section.
> I did not get how they are related to each other.
> 
> 
> BTW, we decided to not go in this direction in the former discussion.
> I am not sure how much effort is needed to track down the issue
> in this version.
> 
> If we add new sections to keep the backward compatibility
> for the current "__versions", this issue may not exist.

I think need to investigate more on this. But according to the results
(and 

Re: [PATCH 2/2] powerpc: use node_has_cpus() instead of nr_cpus_node()

2023-03-15 Thread Valentin Schneider
On 21/02/23 18:50, Yury Norov wrote:
> Use node_has_cpus() as more efficient alternative to nr_cpus_node()
> where possible.
>
> Signed-off-by: Yury Norov 

Reviewed-by: Valentin Schneider 



Re: [PATCH 1/2] sched/topology: introduce node_has_cpus() macro

2023-03-15 Thread Valentin Schneider
On 21/02/23 18:50, Yury Norov wrote:
> Currently, to check if NUMA node has CPUs, one has to use the
> nr_cpus_node() macro, which ends up with cpumask_weight. We can do it
> better with cpumask_empty(), because the latter can potentially return
> earlier - as soon as 1st set bit found.
>
> This patch adds a node_has_cpus() macro to implement that.
>
> Signed-off-by: Yury Norov 

Reviewed-by: Valentin Schneider 



Re: [PATCH] modpost: support arbitrary symbol length in modversion

2023-03-15 Thread Masahiro Yamada
On Tue, Mar 14, 2023 at 11:38 PM Andrea Righi
 wrote:
>
> On Mon, Mar 13, 2023 at 11:09:31PM +0100, Andrea Righi wrote:
> > On Mon, Mar 13, 2023 at 11:02:34PM +0100, Michal Suchánek wrote:
> > > On Mon, Mar 13, 2023 at 10:53:34PM +0100, Andrea Righi wrote:
> > > > On Mon, Mar 13, 2023 at 10:48:53PM +0100, Michal Suchánek wrote:
> > > > > Hello,
> > > > >
> > > > > On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> > > > > > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > > > > > > Currently modversion uses a fixed size array of size (64 - 
> > > > > > > sizeof(long))
> > > > > > > to store symbol names, thus placing a hard limit on length of 
> > > > > > > symbols.
> > > > > > > Rust symbols (which encodes crate and module names) can be quite 
> > > > > > > a bit
> > > > > > > longer. The length limit in kallsyms is increased to 512 for this 
> > > > > > > reason.
> > > > > > >
> > > > > > > It's a waste of space to simply expand the fixed array size to 
> > > > > > > 512 in
> > > > > > > modversion info entries. I therefore make it variably sized, with 
> > > > > > > offset
> > > > > > > to the next entry indicated by the initial "next" field.
> > > > > > >
> > > > > > > In addition to supporting longer-than-56/60 byte symbols, this 
> > > > > > > patch also
> > > > > > > reduce the size for short symbols by getting rid of excessive 0 
> > > > > > > paddings.
> > > > > > > There are still some zero paddings to ensure "next" and "crc" 
> > > > > > > fields are
> > > > > > > properly aligned.
> > > > > > >
> > > > > > > This patch does have a tiny drawback that it makes ".mod.c" files 
> > > > > > > generated
> > > > > > > a bit less easy to read, as code like
> > > > > > >
> > > > > > > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > > > > > > "symbol\0\0"
> > > > > > >
> > > > > > > is generated as opposed to
> > > > > > >
> > > > > > > { 0x12345678, "symbol" },
> > > > > > >
> > > > > > > because the structure is now variable-length. But hopefully 
> > > > > > > nobody reads
> > > > > > > the generated file :)
> > > > > > >
> > > > > > > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol 
> > > > > > > length to 512")
> > > > > > > Link: https://github.com/Rust-for-Linux/linux/pull/379
> > > > > > >
> > > > > > > Signed-off-by: Gary Guo 
> > > > > >
> > > > > > Is there any newer version of this patch?
> > > > > >
> > > > > > I'm doing some tests with it, but I'm getting boot failures on ppc64
> > > > > > with this applied (at boot kernel is spitting out lots of oops'es 
> > > > > > and
> > > > > > unfortunately it's really hard to copy paste or just read them from 
> > > > > > the
> > > > > > console).
> > > > >
> > > > > Are you using the ELF ABI v1 or v2?
> > > > >
> > > > > v1 may have some additional issues when it comes to these symbol 
> > > > > tables.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Michal
> > > >
> > > > I have CONFIG_PPC64_ELF_ABI_V2=y in my .config, so I guess I'm using v2.
> > > >
> > > > BTW, the issue seems to be in dedotify_versions(), as a silly test I
> > > > tried to comment out this function completely to be a no-op and now my
> > > > system boots fine (but I guess I'm probably breaking something else).
> > >
> > > Probably not. You should not have the extra leading dot on ABI v2. So if
> > > dedotify does something that means something generates and then expects
> > > back symbols with a leading dot, and this workaround for ABI v1 breaks
> > > that. Or maybe it is called when it shouldn't.
> >
> > Hm.. I'll add some debugging to this function to see what happens exactly.
>
> Alright I've done more tests across different architectures. My problem
> with ppc64 is that this architecture is evaluating sechdrs[i].sh_size
> using get_stubs_size(), that apparently can add some extra padding, so
> doing (vers + vers->next < end) isn't a reliable check to determine the
> end of the variable array, because sometimes "end" can be greater than
> the last "vers + vers->next" entry.


I am not familiar enough with ppc, so I may be misundering.

Checking the for-loop in module_frob_arch_sections(),
they seem to be orthogonal to me.

dedotify_versions() is only called for the "__versions" section.
get_stubs_size() only affects the ".stubs" section.
I did not get how they are related to each other.


BTW, we decided to not go in this direction in the former discussion.
I am not sure how much effort is needed to track down the issue
in this version.

If we add new sections to keep the backward compatibility
for the current "__versions", this issue may not exist.



> In general I think it'd be more reliable to add a dummy NULL entry at
> the end of the modversion array.
>
> Moreover, I think we also need to enforce struct modversion_info to be
> __packed, just to make sure that no extra padding is added (otherwise it
> may break our logic to determine the offset of the next entry).
>
> > @@ -2062,16 +2066,25 @@ static void add_versions(struct 

[PATCH 076/173] ASoC: fsl: imx-audmux: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/imx-audmux.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
index 582f1e2431ee..be003a117b39 100644
--- a/sound/soc/fsl/imx-audmux.c
+++ b/sound/soc/fsl/imx-audmux.c
@@ -315,12 +315,10 @@ static int imx_audmux_probe(struct platform_device *pdev)
return 0;
 }
 
-static int imx_audmux_remove(struct platform_device *pdev)
+static void imx_audmux_remove(struct platform_device *pdev)
 {
if (audmux_type == IMX31_AUDMUX)
audmux_debugfs_remove();
-
-   return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -359,7 +357,7 @@ static const struct dev_pm_ops imx_audmux_pm = {
 
 static struct platform_driver imx_audmux_driver = {
.probe  = imx_audmux_probe,
-   .remove = imx_audmux_remove,
+   .remove_new = imx_audmux_remove,
.driver = {
.name   = DRIVER_NAME,
.pm = _audmux_pm,
-- 
2.39.2



[PATCH 077/173] ASoC: fsl: imx-pcm-rpmsg: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/imx-pcm-rpmsg.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-rpmsg.c b/sound/soc/fsl/imx-pcm-rpmsg.c
index 6614b3447649..765dad607bf6 100644
--- a/sound/soc/fsl/imx-pcm-rpmsg.c
+++ b/sound/soc/fsl/imx-pcm-rpmsg.c
@@ -743,14 +743,12 @@ static int imx_rpmsg_pcm_probe(struct platform_device 
*pdev)
return ret;
 }
 
-static int imx_rpmsg_pcm_remove(struct platform_device *pdev)
+static void imx_rpmsg_pcm_remove(struct platform_device *pdev)
 {
struct rpmsg_info *info = platform_get_drvdata(pdev);
 
if (info->rpmsg_wq)
destroy_workqueue(info->rpmsg_wq);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM
@@ -821,7 +819,7 @@ static const struct dev_pm_ops imx_rpmsg_pcm_pm_ops = {
 
 static struct platform_driver imx_pcm_rpmsg_driver = {
.probe  = imx_rpmsg_pcm_probe,
-   .remove = imx_rpmsg_pcm_remove,
+   .remove_new = imx_rpmsg_pcm_remove,
.driver = {
.name = IMX_PCM_DRV_NAME,
.pm = _rpmsg_pcm_pm_ops,
-- 
2.39.2



[PATCH 078/173] ASoC: fsl: imx-sgtl5000: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/imx-sgtl5000.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 580a0d963f0e..26c22783927b 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -193,14 +193,12 @@ static int imx_sgtl5000_probe(struct platform_device 
*pdev)
return ret;
 }
 
-static int imx_sgtl5000_remove(struct platform_device *pdev)
+static void imx_sgtl5000_remove(struct platform_device *pdev)
 {
struct snd_soc_card *card = platform_get_drvdata(pdev);
struct imx_sgtl5000_data *data = snd_soc_card_get_drvdata(card);
 
clk_put(data->codec_clk);
-
-   return 0;
 }
 
 static const struct of_device_id imx_sgtl5000_dt_ids[] = {
@@ -216,7 +214,7 @@ static struct platform_driver imx_sgtl5000_driver = {
.of_match_table = imx_sgtl5000_dt_ids,
},
.probe = imx_sgtl5000_probe,
-   .remove = imx_sgtl5000_remove,
+   .remove_new = imx_sgtl5000_remove,
 };
 module_platform_driver(imx_sgtl5000_driver);
 
-- 
2.39.2



[PATCH 081/173] ASoC: fsl: mpc8610_hpcd: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/mpc8610_hpcd.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index e71a992fbf93..ea2076ea8afe 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -387,7 +387,7 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev)
  *
  * This function is called when the platform device is removed.
  */
-static int mpc8610_hpcd_remove(struct platform_device *pdev)
+static void mpc8610_hpcd_remove(struct platform_device *pdev)
 {
struct snd_soc_card *card = platform_get_drvdata(pdev);
struct mpc8610_hpcd_data *machine_data =
@@ -395,13 +395,11 @@ static int mpc8610_hpcd_remove(struct platform_device 
*pdev)
 
snd_soc_unregister_card(card);
kfree(machine_data);
-
-   return 0;
 }
 
 static struct platform_driver mpc8610_hpcd_driver = {
.probe = mpc8610_hpcd_probe,
-   .remove = mpc8610_hpcd_remove,
+   .remove_new = mpc8610_hpcd_remove,
.driver = {
/* The name must match 'compatible' property in the device tree,
 * in lowercase letters.
-- 
2.39.2



[PATCH 074/173] ASoC: fsl: fsl_ssi: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_ssi.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 46a53551b955..f9097268589c 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1671,7 +1671,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_ssi_remove(struct platform_device *pdev)
+static void fsl_ssi_remove(struct platform_device *pdev)
 {
struct fsl_ssi *ssi = dev_get_drvdata(>dev);
 
@@ -1690,8 +1690,6 @@ static int fsl_ssi_remove(struct platform_device *pdev)
snd_soc_set_ac97_ops(NULL);
mutex_destroy(>ac97_reg_lock);
}
-
-   return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -1737,7 +1735,7 @@ static struct platform_driver fsl_ssi_driver = {
.pm = _ssi_pm,
},
.probe = fsl_ssi_probe,
-   .remove = fsl_ssi_remove,
+   .remove_new = fsl_ssi_remove,
 };
 
 module_platform_driver(fsl_ssi_driver);
-- 
2.39.2



[PATCH 075/173] ASoC: fsl: fsl_xcvr: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_xcvr.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
index 2a78243df752..318fe77683f5 100644
--- a/sound/soc/fsl/fsl_xcvr.c
+++ b/sound/soc/fsl/fsl_xcvr.c
@@ -1339,10 +1339,9 @@ static int fsl_xcvr_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_xcvr_remove(struct platform_device *pdev)
+static void fsl_xcvr_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
-   return 0;
 }
 
 static __maybe_unused int fsl_xcvr_runtime_suspend(struct device *dev)
@@ -1478,7 +1477,7 @@ static struct platform_driver fsl_xcvr_driver = {
.pm = _xcvr_pm_ops,
.of_match_table = fsl_xcvr_dt_ids,
},
-   .remove = fsl_xcvr_remove,
+   .remove_new = fsl_xcvr_remove,
 };
 module_platform_driver(fsl_xcvr_driver);
 
-- 
2.39.2



[PATCH 073/173] ASoC: fsl: fsl_spdif: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_spdif.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 275aba8e0c46..015c3708aa04 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -1659,11 +1659,9 @@ static int fsl_spdif_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_spdif_remove(struct platform_device *pdev)
+static void fsl_spdif_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM
@@ -1765,7 +1763,7 @@ static struct platform_driver fsl_spdif_driver = {
.pm = _spdif_pm,
},
.probe = fsl_spdif_probe,
-   .remove = fsl_spdif_remove,
+   .remove_new = fsl_spdif_remove,
 };
 
 module_platform_driver(fsl_spdif_driver);
-- 
2.39.2



[PATCH 072/173] ASoC: fsl: fsl_sai: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_sai.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1b197478b3d9..a5e56e0484f2 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1489,13 +1489,11 @@ static int fsl_sai_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_sai_remove(struct platform_device *pdev)
+static void fsl_sai_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
if (!pm_runtime_status_suspended(>dev))
fsl_sai_runtime_suspend(>dev);
-
-   return 0;
 }
 
 static const struct fsl_sai_soc_data fsl_sai_vf610_data = {
@@ -1696,7 +1694,7 @@ static const struct dev_pm_ops fsl_sai_pm_ops = {
 
 static struct platform_driver fsl_sai_driver = {
.probe = fsl_sai_probe,
-   .remove = fsl_sai_remove,
+   .remove_new = fsl_sai_remove,
.driver = {
.name = "fsl-sai",
.pm = _sai_pm_ops,
-- 
2.39.2



[PATCH 069/173] ASoC: fsl: fsl_esai: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_esai.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 17fefd27ec90..936f0cd4b06d 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -1101,7 +1101,7 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_esai_remove(struct platform_device *pdev)
+static void fsl_esai_remove(struct platform_device *pdev)
 {
struct fsl_esai *esai_priv = platform_get_drvdata(pdev);
 
@@ -1110,8 +1110,6 @@ static int fsl_esai_remove(struct platform_device *pdev)
fsl_esai_runtime_suspend(>dev);
 
cancel_work_sync(_priv->work);
-
-   return 0;
 }
 
 static const struct of_device_id fsl_esai_dt_ids[] = {
@@ -1200,7 +1198,7 @@ static const struct dev_pm_ops fsl_esai_pm_ops = {
 
 static struct platform_driver fsl_esai_driver = {
.probe = fsl_esai_probe,
-   .remove = fsl_esai_remove,
+   .remove_new = fsl_esai_remove,
.driver = {
.name = "fsl-esai-dai",
.pm = _esai_pm_ops,
-- 
2.39.2



[PATCH 071/173] ASoC: fsl: fsl_rpmsg: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_rpmsg.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index 46c7868a2653..15b48b5ea856 100644
--- a/sound/soc/fsl/fsl_rpmsg.c
+++ b/sound/soc/fsl/fsl_rpmsg.c
@@ -247,14 +247,12 @@ static int fsl_rpmsg_probe(struct platform_device *pdev)
return 0;
 }
 
-static int fsl_rpmsg_remove(struct platform_device *pdev)
+static void fsl_rpmsg_remove(struct platform_device *pdev)
 {
struct fsl_rpmsg *rpmsg = platform_get_drvdata(pdev);
 
if (rpmsg->card_pdev)
platform_device_unregister(rpmsg->card_pdev);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM
@@ -302,7 +300,7 @@ static const struct dev_pm_ops fsl_rpmsg_pm_ops = {
 
 static struct platform_driver fsl_rpmsg_driver = {
.probe  = fsl_rpmsg_probe,
-   .remove = fsl_rpmsg_remove,
+   .remove_new = fsl_rpmsg_remove,
.driver = {
.name = "fsl_rpmsg",
.pm = _rpmsg_pm_ops,
-- 
2.39.2



[PATCH 067/173] ASoC: fsl: fsl_dma: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_dma.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index 808fb61a7a0f..963f9774c883 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -890,15 +890,13 @@ static int fsl_soc_dma_probe(struct platform_device *pdev)
return 0;
 }
 
-static int fsl_soc_dma_remove(struct platform_device *pdev)
+static void fsl_soc_dma_remove(struct platform_device *pdev)
 {
struct dma_object *dma = dev_get_drvdata(>dev);
 
iounmap(dma->channel);
irq_dispose_mapping(dma->irq);
kfree(dma);
-
-   return 0;
 }
 
 static const struct of_device_id fsl_soc_dma_ids[] = {
@@ -913,7 +911,7 @@ static struct platform_driver fsl_soc_dma_driver = {
.of_match_table = fsl_soc_dma_ids,
},
.probe = fsl_soc_dma_probe,
-   .remove = fsl_soc_dma_remove,
+   .remove_new = fsl_soc_dma_remove,
 };
 
 module_platform_driver(fsl_soc_dma_driver);
-- 
2.39.2



[PATCH 066/173] ASoC: fsl: fsl_audmix: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_audmix.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
index 672148dd4b23..0ab2c1962117 100644
--- a/sound/soc/fsl/fsl_audmix.c
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -506,7 +506,7 @@ static int fsl_audmix_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_audmix_remove(struct platform_device *pdev)
+static void fsl_audmix_remove(struct platform_device *pdev)
 {
struct fsl_audmix *priv = dev_get_drvdata(>dev);
 
@@ -514,8 +514,6 @@ static int fsl_audmix_remove(struct platform_device *pdev)
 
if (priv->pdev)
platform_device_unregister(priv->pdev);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM
@@ -558,7 +556,7 @@ static const struct dev_pm_ops fsl_audmix_pm = {
 
 static struct platform_driver fsl_audmix_driver = {
.probe = fsl_audmix_probe,
-   .remove = fsl_audmix_remove,
+   .remove_new = fsl_audmix_remove,
.driver = {
.name = "fsl-audmix",
.of_match_table = fsl_audmix_ids,
-- 
2.39.2



[PATCH 070/173] ASoC: fsl: fsl_mqs: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_mqs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_mqs.c b/sound/soc/fsl/fsl_mqs.c
index 4922e6795b73..3fb3d3e4d09a 100644
--- a/sound/soc/fsl/fsl_mqs.c
+++ b/sound/soc/fsl/fsl_mqs.c
@@ -261,10 +261,9 @@ static int fsl_mqs_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_mqs_remove(struct platform_device *pdev)
+static void fsl_mqs_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
-   return 0;
 }
 
 #ifdef CONFIG_PM
@@ -360,7 +359,7 @@ MODULE_DEVICE_TABLE(of, fsl_mqs_dt_ids);
 
 static struct platform_driver fsl_mqs_driver = {
.probe  = fsl_mqs_probe,
-   .remove = fsl_mqs_remove,
+   .remove_new = fsl_mqs_remove,
.driver = {
.name   = "fsl-mqs",
.of_match_table = fsl_mqs_dt_ids,
-- 
2.39.2



[PATCH 068/173] ASoC: fsl: fsl_easrc: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_easrc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 3153d19136b2..670cbdb361b6 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1979,11 +1979,9 @@ static int fsl_easrc_probe(struct platform_device *pdev)
return 0;
 }
 
-static int fsl_easrc_remove(struct platform_device *pdev)
+static void fsl_easrc_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
-
-   return 0;
 }
 
 static __maybe_unused int fsl_easrc_runtime_suspend(struct device *dev)
@@ -2093,7 +2091,7 @@ static const struct dev_pm_ops fsl_easrc_pm_ops = {
 
 static struct platform_driver fsl_easrc_driver = {
.probe = fsl_easrc_probe,
-   .remove = fsl_easrc_remove,
+   .remove_new = fsl_easrc_remove,
.driver = {
.name = "fsl-easrc",
.pm = _easrc_pm_ops,
-- 
2.39.2



[PATCH 065/173] ASoC: fsl: fsl_aud2htx: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_aud2htx.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_aud2htx.c b/sound/soc/fsl/fsl_aud2htx.c
index 1e421d9a03fb..46b0c5dcc4a5 100644
--- a/sound/soc/fsl/fsl_aud2htx.c
+++ b/sound/soc/fsl/fsl_aud2htx.c
@@ -257,11 +257,9 @@ static int fsl_aud2htx_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_aud2htx_remove(struct platform_device *pdev)
+static void fsl_aud2htx_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
-
-   return 0;
 }
 
 static int __maybe_unused fsl_aud2htx_runtime_suspend(struct device *dev)
@@ -300,7 +298,7 @@ static const struct dev_pm_ops fsl_aud2htx_pm_ops = {
 
 static struct platform_driver fsl_aud2htx_driver = {
.probe = fsl_aud2htx_probe,
-   .remove = fsl_aud2htx_remove,
+   .remove_new = fsl_aud2htx_remove,
.driver = {
.name = "fsl-aud2htx",
.pm = _aud2htx_pm_ops,
-- 
2.39.2



[PATCH 064/173] ASoC: fsl: fsl_asrc: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/soc/fsl/fsl_asrc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index e16e7b3fa96c..adb8a59de2bd 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -1252,13 +1252,11 @@ static int fsl_asrc_probe(struct platform_device *pdev)
return ret;
 }
 
-static int fsl_asrc_remove(struct platform_device *pdev)
+static void fsl_asrc_remove(struct platform_device *pdev)
 {
pm_runtime_disable(>dev);
if (!pm_runtime_status_suspended(>dev))
fsl_asrc_runtime_suspend(>dev);
-
-   return 0;
 }
 
 static int fsl_asrc_runtime_resume(struct device *dev)
@@ -1394,7 +1392,7 @@ MODULE_DEVICE_TABLE(of, fsl_asrc_ids);
 
 static struct platform_driver fsl_asrc_driver = {
.probe = fsl_asrc_probe,
-   .remove = fsl_asrc_remove,
+   .remove_new = fsl_asrc_remove,
.driver = {
.name = "fsl-asrc",
.of_match_table = fsl_asrc_ids,
-- 
2.39.2



[PATCH 010/173] ALSA: ppc/powermac: Convert to platform remove callback returning void

2023-03-15 Thread Uwe Kleine-König
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König 
---
 sound/ppc/powermac.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/ppc/powermac.c b/sound/ppc/powermac.c
index db414b61157e..e17af46abddd 100644
--- a/sound/ppc/powermac.c
+++ b/sound/ppc/powermac.c
@@ -130,10 +130,9 @@ static int snd_pmac_probe(struct platform_device *devptr)
 }
 
 
-static int snd_pmac_remove(struct platform_device *devptr)
+static void snd_pmac_remove(struct platform_device *devptr)
 {
snd_card_free(platform_get_drvdata(devptr));
-   return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -161,7 +160,7 @@ static SIMPLE_DEV_PM_OPS(snd_pmac_pm, 
snd_pmac_driver_suspend, snd_pmac_driver_r
 
 static struct platform_driver snd_pmac_driver = {
.probe  = snd_pmac_probe,
-   .remove = snd_pmac_remove,
+   .remove_new = snd_pmac_remove,
.driver = {
.name   = SND_PMAC_DRIVER,
.pm = SND_PMAC_PM_OPS,
-- 
2.39.2



Re: [PATCH] soc: fsl: cpm1: qmc: Fix test dependency

2023-03-15 Thread Mark Brown
On Tue, 14 Mar 2023 09:21:57 +0100, Herve Codina wrote:
> The QMC depends on (SOC_FSL && COMPILE_TEST). SOC_FSL does not exist.
> 
> Fix the dependency using the correct one: FSL_SOC.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] soc: fsl: cpm1: qmc: Fix test dependency
  commit: 6ffa0da5c63f8408101d01075709981005eb66ec

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark



Re: [PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml

2023-03-15 Thread kernel test robot
Hi Sean,

I love your patch! Perhaps something to improve:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on brgl/gpio/for-next clk/clk-next linus/master 
v6.3-rc2 next-20230315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/dt-bindings-phy-Add-2500BASE-X-and-10GBASE-R/20230314-001522
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
patch link:
https://lore.kernel.org/r/20230313161138.3598068-4-sean.anderson%40seco.com
patch subject: [PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml
reproduce:
# 
https://github.com/intel-lab-lkp/linux/commit/2d1e86be168e32ea3d3f11325881f7cb1e5492f8
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Sean-Anderson/dt-bindings-phy-Add-2500BASE-X-and-10GBASE-R/20230314-001522
git checkout 2d1e86be168e32ea3d3f11325881f7cb1e5492f8
make menuconfig
# enable CONFIG_COMPILE_TEST, CONFIG_WARN_MISSING_DOCUMENTS, 
CONFIG_WARN_ABI_ERRORS
make htmldocs

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303152008.kxrjsw73-...@intel.com/

All warnings (new ones prefixed by >>):

>> Warning: Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> Warning: 
>> Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> Warning: Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> Warning: Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> Warning: Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
>> Warning: Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml 
>> references a file that doesn't exist: 
>> Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests


Re: [PATCH v4 20/36] powerpc: Implement the new page table range API

2023-03-15 Thread Christophe Leroy


Le 15/03/2023 à 10:43, Christophe Leroy a écrit :
> 
> 
> Le 15/03/2023 à 06:14, Matthew Wilcox (Oracle) a écrit :
>> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
>> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
>> per-folio.
>>
>> Signed-off-by: Matthew Wilcox (Oracle) 
>> Cc: Michael Ellerman 
>> Cc: Nicholas Piggin 
>> Cc: Christophe Leroy 
>> Cc: linuxppc-dev@lists.ozlabs.org
>> ---

>> @@ -203,7 +203,14 @@ void set_pte_at(struct mm_struct *mm, unsigned 
>> long addr, pte_t *ptep,
>>   pte = set_pte_filter(pte);
>>   /* Perform the setting of the PTE */
>> -    __set_pte_at(mm, addr, ptep, pte, 0);
>> +    for (;;) {
>> +    __set_pte_at(mm, addr, ptep, pte, 0);
>> +    if (--nr == 0)
>> +    break;
>> +    ptep++;
>> +    pte = __pte(pte_val(pte) + PAGE_SIZE);
> 
> I don't like that math too much, but I have no better idea at the moment.
> 
> Maybe set_ptes() should take a pgprot_t and rebuild the pte with 
> mk_pte() or similar ?
> 
>> +    addr += PAGE_SIZE;
>> +    }
>>   }
>>   void unmap_kernel_page(unsigned long va)

I investigated a bit further and can confirm now that the above won't 
always work, see comment 
https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/32/pgtable.h#L147

And then you see 
https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/pte-e500.h#L63

Christophe


Re: [PATCH v4 20/36] powerpc: Implement the new page table range API

2023-03-15 Thread Mike Rapoport
On Wed, Mar 15, 2023 at 05:14:28AM +, Matthew Wilcox (Oracle) wrote:
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
> 
> Signed-off-by: Matthew Wilcox (Oracle) 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> Cc: linuxppc-dev@lists.ozlabs.org

Acked-by: Mike Rapoport (IBM) 

> ---
>  arch/powerpc/include/asm/book3s/pgtable.h | 10 +
>  arch/powerpc/include/asm/cacheflush.h | 14 +--
>  arch/powerpc/include/asm/kvm_ppc.h| 10 ++---
>  arch/powerpc/include/asm/nohash/pgtable.h | 13 ++
>  arch/powerpc/include/asm/pgtable.h|  6 +++
>  arch/powerpc/mm/book3s64/hash_utils.c | 11 ++---
>  arch/powerpc/mm/cacheflush.c  | 40 ++
>  arch/powerpc/mm/nohash/e500_hugetlbpage.c |  3 +-
>  arch/powerpc/mm/pgtable.c | 51 +--
>  9 files changed, 77 insertions(+), 81 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/pgtable.h 
> b/arch/powerpc/include/asm/book3s/pgtable.h
> index d18b748ea3ae..c2ef811505b0 100644
> --- a/arch/powerpc/include/asm/book3s/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/pgtable.h
> @@ -9,13 +9,6 @@
>  #endif
>  
>  #ifndef __ASSEMBLY__
> -/* Insert a PTE, top-level function is out of line. It uses an inline
> - * low level function in the respective pgtable-* files
> - */
> -extern void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> -pte_t pte);
> -
> -
>  #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
>  extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long 
> address,
>pte_t *ptep, pte_t entry, int dirty);
> @@ -36,7 +29,8 @@ void __update_mmu_cache(struct vm_area_struct *vma, 
> unsigned long address, pte_t
>   * corresponding HPTE into the hash table ahead of time, instead of
>   * waiting for the inevitable extra hash-table miss exception.
>   */
> -static inline void update_mmu_cache(struct vm_area_struct *vma, unsigned 
> long address, pte_t *ptep)
> +static inline void update_mmu_cache_range(struct vm_area_struct *vma,
> + unsigned long address, pte_t *ptep, unsigned int nr)
>  {
>   if (IS_ENABLED(CONFIG_PPC32) && !mmu_has_feature(MMU_FTR_HPTE_TABLE))
>   return;
> diff --git a/arch/powerpc/include/asm/cacheflush.h 
> b/arch/powerpc/include/asm/cacheflush.h
> index 7564dd4fd12b..ef7d2de33b89 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -35,13 +35,19 @@ static inline void flush_cache_vmap(unsigned long start, 
> unsigned long end)
>   * It just marks the page as not i-cache clean.  We do the i-cache
>   * flush later when the page is given to a user process, if necessary.
>   */
> -static inline void flush_dcache_page(struct page *page)
> +static inline void flush_dcache_folio(struct folio *folio)
>  {
>   if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>   return;
>   /* avoid an atomic op if possible */
> - if (test_bit(PG_dcache_clean, >flags))
> - clear_bit(PG_dcache_clean, >flags);
> + if (test_bit(PG_dcache_clean, >flags))
> + clear_bit(PG_dcache_clean, >flags);
> +}
> +#define flush_dcache_folio flush_dcache_folio
> +
> +static inline void flush_dcache_page(struct page *page)
> +{
> + flush_dcache_folio(page_folio(page));
>  }
>  
>  void flush_icache_range(unsigned long start, unsigned long stop);
> @@ -51,7 +57,7 @@ void flush_icache_user_page(struct vm_area_struct *vma, 
> struct page *page,
>   unsigned long addr, int len);
>  #define flush_icache_user_page flush_icache_user_page
>  
> -void flush_dcache_icache_page(struct page *page);
> +void flush_dcache_icache_folio(struct folio *folio);
>  
>  /**
>   * flush_dcache_range(): Write any modified data cache blocks out to memory 
> and
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
> b/arch/powerpc/include/asm/kvm_ppc.h
> index 6bef23d6d0e3..e91dd8e88bb7 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -868,7 +868,7 @@ void kvmppc_init_lpid(unsigned long nr_lpids);
>  
>  static inline void kvmppc_mmu_flush_icache(kvm_pfn_t pfn)
>  {
> - struct page *page;
> + struct folio *folio;
>   /*
>* We can only access pages that the kernel maps
>* as memory. Bail out for unmapped ones.
> @@ -877,10 +877,10 @@ static inline void kvmppc_mmu_flush_icache(kvm_pfn_t 
> pfn)
>   return;
>  
>   /* Clear i-cache for new pages */
> - page = pfn_to_page(pfn);
> - if (!test_bit(PG_dcache_clean, >flags)) {
> - flush_dcache_icache_page(page);
> - set_bit(PG_dcache_clean, >flags);
> + folio = page_folio(pfn_to_page(pfn));
> + if (!test_bit(PG_dcache_clean, >flags)) {
> + flush_dcache_icache_folio(folio);
> + 

Re: [PATCH v4 20/36] powerpc: Implement the new page table range API

2023-03-15 Thread Christophe Leroy


Le 15/03/2023 à 06:14, Matthew Wilcox (Oracle) a écrit :
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
> 
> Signed-off-by: Matthew Wilcox (Oracle) 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
>   arch/powerpc/include/asm/book3s/pgtable.h | 10 +
>   arch/powerpc/include/asm/cacheflush.h | 14 +--
>   arch/powerpc/include/asm/kvm_ppc.h| 10 ++---
>   arch/powerpc/include/asm/nohash/pgtable.h | 13 ++
>   arch/powerpc/include/asm/pgtable.h|  6 +++
>   arch/powerpc/mm/book3s64/hash_utils.c | 11 ++---
>   arch/powerpc/mm/cacheflush.c  | 40 ++
>   arch/powerpc/mm/nohash/e500_hugetlbpage.c |  3 +-
>   arch/powerpc/mm/pgtable.c | 51 +--
>   9 files changed, 77 insertions(+), 81 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/pgtable.h 
> b/arch/powerpc/include/asm/book3s/pgtable.h
> index d18b748ea3ae..c2ef811505b0 100644
> --- a/arch/powerpc/include/asm/book3s/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/pgtable.h
> @@ -9,13 +9,6 @@
>   #endif
>   
>   #ifndef __ASSEMBLY__
> -/* Insert a PTE, top-level function is out of line. It uses an inline
> - * low level function in the respective pgtable-* files
> - */
> -extern void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> -pte_t pte);
> -
> -
>   #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
>   extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long 
> address,
>pte_t *ptep, pte_t entry, int dirty);
> @@ -36,7 +29,8 @@ void __update_mmu_cache(struct vm_area_struct *vma, 
> unsigned long address, pte_t
>* corresponding HPTE into the hash table ahead of time, instead of
>* waiting for the inevitable extra hash-table miss exception.
>*/
> -static inline void update_mmu_cache(struct vm_area_struct *vma, unsigned 
> long address, pte_t *ptep)
> +static inline void update_mmu_cache_range(struct vm_area_struct *vma,
> + unsigned long address, pte_t *ptep, unsigned int nr)
>   {
>   if (IS_ENABLED(CONFIG_PPC32) && !mmu_has_feature(MMU_FTR_HPTE_TABLE))
>   return;
> diff --git a/arch/powerpc/include/asm/cacheflush.h 
> b/arch/powerpc/include/asm/cacheflush.h
> index 7564dd4fd12b..ef7d2de33b89 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -35,13 +35,19 @@ static inline void flush_cache_vmap(unsigned long start, 
> unsigned long end)
>* It just marks the page as not i-cache clean.  We do the i-cache
>* flush later when the page is given to a user process, if necessary.
>*/
> -static inline void flush_dcache_page(struct page *page)
> +static inline void flush_dcache_folio(struct folio *folio)
>   {
>   if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>   return;
>   /* avoid an atomic op if possible */
> - if (test_bit(PG_dcache_clean, >flags))
> - clear_bit(PG_dcache_clean, >flags);
> + if (test_bit(PG_dcache_clean, >flags))
> + clear_bit(PG_dcache_clean, >flags);
> +}
> +#define flush_dcache_folio flush_dcache_folio
> +
> +static inline void flush_dcache_page(struct page *page)
> +{
> + flush_dcache_folio(page_folio(page));
>   }
>   
>   void flush_icache_range(unsigned long start, unsigned long stop);
> @@ -51,7 +57,7 @@ void flush_icache_user_page(struct vm_area_struct *vma, 
> struct page *page,
>   unsigned long addr, int len);
>   #define flush_icache_user_page flush_icache_user_page
>   
> -void flush_dcache_icache_page(struct page *page);
> +void flush_dcache_icache_folio(struct folio *folio);
>   
>   /**
>* flush_dcache_range(): Write any modified data cache blocks out to memory 
> and
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
> b/arch/powerpc/include/asm/kvm_ppc.h
> index 6bef23d6d0e3..e91dd8e88bb7 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -868,7 +868,7 @@ void kvmppc_init_lpid(unsigned long nr_lpids);
>   
>   static inline void kvmppc_mmu_flush_icache(kvm_pfn_t pfn)
>   {
> - struct page *page;
> + struct folio *folio;
>   /*
>* We can only access pages that the kernel maps
>* as memory. Bail out for unmapped ones.
> @@ -877,10 +877,10 @@ static inline void kvmppc_mmu_flush_icache(kvm_pfn_t 
> pfn)
>   return;
>   
>   /* Clear i-cache for new pages */
> - page = pfn_to_page(pfn);
> - if (!test_bit(PG_dcache_clean, >flags)) {
> - flush_dcache_icache_page(page);
> - set_bit(PG_dcache_clean, >flags);
> + folio = page_folio(pfn_to_page(pfn));
> + if (!test_bit(PG_dcache_clean, >flags)) {
> + flush_dcache_icache_folio(folio);
> + 

Re: [PATCH] net: Use of_property_read_bool() for boolean properties

2023-03-15 Thread Simon Horman
On Tue, Mar 14, 2023 at 02:14:37PM -0500, Rob Herring wrote:
> On Sat, Mar 11, 2023 at 5:50 AM Simon Horman  
> wrote:
> >
> > On Fri, Mar 10, 2023 at 08:47:16AM -0600, Rob Herring wrote:
> > > It is preferred to use typed property access functions (i.e.
> > > of_property_read_ functions) rather than low-level
> > > of_get_property/of_find_property functions for reading properties.
> > > Convert reading boolean properties to to of_property_read_bool().
> > >
> > > Signed-off-by: Rob Herring 
> >
> > Reviewed-by: Simon Horman 
> >
> > ...
> >
> > > diff --git a/drivers/net/ethernet/via/via-velocity.c 
> > > b/drivers/net/ethernet/via/via-velocity.c
> > > index a502812ac418..86f7843b4591 100644
> > > --- a/drivers/net/ethernet/via/via-velocity.c
> > > +++ b/drivers/net/ethernet/via/via-velocity.c
> > > @@ -2709,8 +2709,7 @@ static int velocity_get_platform_info(struct 
> > > velocity_info *vptr)
> > >   struct resource res;
> > >   int ret;
> > >
> > > - if (of_get_property(vptr->dev->of_node, "no-eeprom", NULL))
> > > - vptr->no_eeprom = 1;
> > > + vptr->no_eeprom = of_property_read_bool(vptr->dev->of_node, 
> > > "no-eeprom");
> >
> > As per my comment on "[PATCH] nfc: mrvl: Use of_property_read_bool() for
> > boolean properties".
> >
> > I'm not that enthusiastic about assigning a bool value to a field
> > with an integer type. But that is likely a topic for another patch.
> >
> > >   ret = of_address_to_resource(vptr->dev->of_node, 0, );
> > >   if (ret) {
> >
> > ...
> >
> > > diff --git a/drivers/net/wan/fsl_ucc_hdlc.c 
> > > b/drivers/net/wan/fsl_ucc_hdlc.c
> > > index 1c53b5546927..47c2ad7a3e42 100644
> > > --- a/drivers/net/wan/fsl_ucc_hdlc.c
> > > +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> > > @@ -1177,14 +1177,9 @@ static int ucc_hdlc_probe(struct platform_device 
> > > *pdev)
> > >   uhdlc_priv->dev = >dev;
> > >   uhdlc_priv->ut_info = ut_info;
> > >
> > > - if (of_get_property(np, "fsl,tdm-interface", NULL))
> > > - uhdlc_priv->tsa = 1;
> > > -
> > > - if (of_get_property(np, "fsl,ucc-internal-loopback", NULL))
> > > - uhdlc_priv->loopback = 1;
> > > -
> > > - if (of_get_property(np, "fsl,hdlc-bus", NULL))
> > > - uhdlc_priv->hdlc_bus = 1;
> > > + uhdlc_priv->tsa = of_property_read_bool(np, "fsl,tdm-interface");
> >
> > Here too.
> 
> These are already bool.

Sorry, I thought I checked. But clearly I messed it up somehow.

> Turns out the only one that needs changing is
> no_eeprom. netdev folks marked this as changes requested, so I'll add
> that in v2.

Thanks.


Re: boot regression on ppc64 with linux 6.2

2023-03-15 Thread Andrea Righi
On Wed, Mar 15, 2023 at 07:10:25AM +0100, Andrea Righi wrote:
> On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
> > Andrea Righi  writes:
> > > I'm triggering the following bug when booting my qemu powerpc VM:
> > 
> > I'm not seeing that here :/
> > 
> > Can you give a bit more detail?
> >  - qemu version
> >  - qemu command line
> >  - what userspace are you using?
> >  - full dmesg of the failing case
> 
> Yeah, ignore this for now, it could be related to another custom patch
> that I had applied (and forgot about it sorry), this one:
> https://lore.kernel.org/lkml/20230119155709.20d87e35.g...@garyguo.net/T/
> 
> That is causing other issues on ppc64, so I think it might be related to
> that, I'll do more tests making sure I use a vanilla kernel.
> 
> Sorry for the noise.

In fact, I confirm that everything works fine with v6.2.6.

Thanks,
-Andrea


Re: boot regression on ppc64 with linux 6.2

2023-03-15 Thread Andrea Righi
On Wed, Mar 15, 2023 at 02:30:53PM +1100, Michael Ellerman wrote:
> Andrea Righi  writes:
> > I'm triggering the following bug when booting my qemu powerpc VM:
> 
> I'm not seeing that here :/
> 
> Can you give a bit more detail?
>  - qemu version
>  - qemu command line
>  - what userspace are you using?
>  - full dmesg of the failing case

Yeah, ignore this for now, it could be related to another custom patch
that I had applied (and forgot about it sorry), this one:
https://lore.kernel.org/lkml/20230119155709.20d87e35.g...@garyguo.net/T/

That is causing other issues on ppc64, so I think it might be related to
that, I'll do more tests making sure I use a vanilla kernel.

Sorry for the noise.

-Andrea

> 
> > event-sources: Unable to request interrupt 23 for 
> > /event-sources/hot-plug-events
> > WARNING: CPU: 0 PID: 1 at arch/powerpc/platforms/pseries/event_sources.c:26 
> > request_event_sources_irqs+0xbc/0xf0
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW  6.2.2-kc #1
> > Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 
> > 0xf05 of:SLOF,HEAD pSeries
> > NIP:  c2022eec LR: c2022ee8 CTR: 
> > REGS: c3483910 TRAP: 0700   Tainted: GW   (6.2.2-kc)
> > MSR:  82029033   CR: 24483200  XER: 
> > 
> > CFAR: c0180838 IRQMASK: 0 
> > GPR00: c2022ee8 c3483bb0 c1a5ce00 0050 
> > GPR04: c2437d78 c2437e28 0001 0001 
> > GPR08: c2437d00 0001  44483200 
> > GPR12:  c272 c0012758  
> > GPR16:     
> > GPR20:     
> > GPR24:  c20033fc cccd c00e07f0 
> > GPR28: c0db0520  c000fff92ac0 0017 
> > NIP [c2022eec] request_event_sources_irqs+0xbc/0xf0
> > LR [c2022ee8] request_event_sources_irqs+0xb8/0xf0
> > Call Trace:
> > [c3483bb0] [c2022ee8] request_event_sources_irqs+0xb8/0xf0 
> > (unreliable)
> > [c3483c40] [c2022fa0] 
> > __machine_initcall_pseries_init_ras_hotplug_IRQ+0x80/0xb0
> > [c3483c70] [c00121b8] do_one_initcall+0x98/0x300
> > [c3483d50] [c2004b28] kernel_init_freeable+0x2ec/0x370
> > [c3483df0] [c0012780] kernel_init+0x30/0x190
> > [c3483e50] [c000cf5c] ret_from_kernel_thread+0x5c/0x64
> > --- interrupt: 0 at 0x0
> >
> > I did a bisect it and it seems that the offending commit is:
> > baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")
> >
> > Reverting that and also dfecd06bc552 ("powerpc: remove
> > STACK_FRAME_OVERHEAD"), because we need to re-introduce
> > STACK_FRAME_OVERHEAD, seems to fix everything.
> 
> That function doesn't make a hcall, so presumably there was some earlier
> problem which we only detect here.
> 
> cheers


Re: [PATCH] modpost: support arbitrary symbol length in modversion

2023-03-15 Thread Andrea Righi
On Wed, Mar 15, 2023 at 01:15:03AM +0100, Vincenzo Palazzo wrote:
> > In practice, this is what I'm testing at the moment:
> >
> > ---
> > diff --git a/arch/powerpc/kernel/module_64.c 
> > b/arch/powerpc/kernel/module_64.c
> > index ff045644f13f..ea6c830ed1e7 100644
> > --- a/arch/powerpc/kernel/module_64.c
> > +++ b/arch/powerpc/kernel/module_64.c
> > @@ -234,12 +234,13 @@ static unsigned long get_stubs_size(const Elf64_Ehdr 
> > *hdr,
> >  static void dedotify_versions(struct modversion_info *vers,
> >   unsigned long size)
> >  {
> > -   struct modversion_info *end;
> > +   struct modversion_info *end = (void *)vers + size;
> >  
> > -   for (end = (void *)vers + size; vers < end; vers++)
> > +   for (; vers < end && vers->next; vers = (void *)vers + vers->next) {
> > if (vers->name[0] == '.') {
> > memmove(vers->name, vers->name+1, strlen(vers->name));
> > }
> > +   }
> >  }
> >  
> >  /*
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index 8c5909c0076c..4744901bdf63 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -34,9 +34,11 @@
> >  #define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
> >  
> >  struct modversion_info {
> > -   unsigned long crc;
> > -   char name[MODULE_NAME_LEN];
> > -};
> > +   /* Offset of the next modversion entry in relation to this one. */
> > +   u32 next;
> > +   u32 crc;
> > +   char name[0];
> > +} __packed;
> >  
> >  struct module;
> >  struct exception_table_entry;
> > diff --git a/kernel/module/version.c b/kernel/module/version.c
> > index 53f43ac5a73e..5528f98c42dc 100644
> > --- a/kernel/module/version.c
> > +++ b/kernel/module/version.c
> > @@ -17,32 +17,30 @@ int check_version(const struct load_info *info,
> >  {
> > Elf_Shdr *sechdrs = info->sechdrs;
> > unsigned int versindex = info->index.vers;
> > -   unsigned int i, num_versions;
> > -   struct modversion_info *versions;
> > +   struct modversion_info *versions, *end;
> > +   u32 crcval;
> >  
> > /* Exporting module didn't supply crcs?  OK, we're already tainted. */
> > if (!crc)
> > return 1;
> > +   crcval = *crc;
> >  
> > /* No versions at all?  modprobe --force does this. */
> > if (versindex == 0)
> > return try_to_force_load(mod, symname) == 0;
> >  
> > versions = (void *)sechdrs[versindex].sh_addr;
> > -   num_versions = sechdrs[versindex].sh_size
> > -   / sizeof(struct modversion_info);
> > +   end = (void *)versions + sechdrs[versindex].sh_size;
> >  
> > -   for (i = 0; i < num_versions; i++) {
> > -   u32 crcval;
> > -
> > -   if (strcmp(versions[i].name, symname) != 0)
> > +   for (; versions < end && versions->next;
> > +  versions = (void *)versions + versions->next) {
> > +   if (strcmp(versions->name, symname) != 0)
> > continue;
> >  
> > -   crcval = *crc;
> > -   if (versions[i].crc == crcval)
> > +   if (versions->crc == crcval)
> > return 1;
> > -   pr_debug("Found checksum %X vs module %lX\n",
> > -crcval, versions[i].crc);
> > +   pr_debug("Found checksum %X vs module %X\n",
> > +crcval, versions->crc);
> > goto bad_version;
> > }
> >  
> > diff --git a/scripts/export_report.pl b/scripts/export_report.pl
> > index feb3d5542a62..1117646f3141 100755
> > --- a/scripts/export_report.pl
> > +++ b/scripts/export_report.pl
> > @@ -116,18 +116,19 @@ foreach my $thismod (@allcfiles) {
> > while ( <$module> ) {
> > chomp;
> > if ($state == 0) {
> > -   $state = 1 if ($_ =~ /static const struct 
> > modversion_info/);
> > +   $state = 1 if ($_ =~ /static const char versions/);
> > next;
> > }
> > if ($state == 1) {
> > -   $state = 2 if ($_ =~ 
> > /__attribute__\(\(section\("__versions"\)\)\)/);
> > +   $state = 2 if ($_ =~ /__used 
> > __section\("__versions"\)/);
> > next;
> > }
> > if ($state == 2) {
> > -   if ( $_ !~ /0x[0-9a-f]+,/ ) {
> > +   if ( $_ !~ /\\0"/ ) {
> > +   last if ($_ =~ /;/);
> > next;
> > }
> > -   my $sym = (split /([,"])/,)[4];
> > +   my $sym = (split /(["\\])/,)[2];
> > my ($module, $value, $symbol, $gpl) = @{$SYMBOL{$sym}};
> > $SYMBOL{ $sym } =  [ $module, $value+1, $symbol, $gpl];
> > push(@{$MODULE{$thismod}} , $sym);
> > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > index efff8078e395..55335ae98f4f 100644
> > --- a/scripts/mod/modpost.c
> > +++ b/scripts/mod/modpost.c
> > @@ -2046,13 +2046,17 @@ static void add_exported_symbols(struct