date:20220308

[PATCH] powerpc: Use rol32() instead of opencoding in csum_fold()

2022-03-08 Thread Christophe Leroy

rol32(x, 16) will do the rotate using rlwinm.

No need to open code using inline assembly.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/checksum.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/checksum.h 
b/arch/powerpc/include/asm/checksum.h
index 8321f6053a67..4b573a3b7e17 100644
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -38,14 +38,15 @@ extern __wsum csum_and_copy_to_user(const void *src, void 
__user *dst,
  */
 static inline __sum16 csum_fold(__wsum sum)
 {
-   unsigned int tmp;
-
-   /* swap the two 16-bit halves of sum */
-   __asm__("rlwinm %0,%1,16,0,31" : "=r" (tmp) : "r" (sum));
-   /* if there is a carry from adding the two 16-bit halves,
-  it will carry from the lower half into the upper half,
-  giving us the correct sum in the upper half. */
-   return (__force __sum16)(~((__force u32)sum + tmp) >> 16);
+   u32 tmp = (__force u32)sum;
+
+   /*
+* swap the two 16-bit halves of sum
+* if there is a carry from adding the two 16-bit halves,
+* it will carry from the lower half into the upper half,
+* giving us the correct sum in the upper half.
+*/
+   return (__force __sum16)(~(tmp + rol32(tmp, 16)) >> 16);
 }
 
 static inline u32 from64to32(u64 x)
-- 
2.34.1

Re: [PATCH] powerpc: 8xx: fix a return value error in mpc8xx_pic_init

2022-03-08 Thread Christophe Leroy



Le 09/03/2022 à 04:24, Michael Ellerman a écrit :
> Hangyu Hua  writes:
>> mpc8xx_pic_init() should return -ENOMEM instead of 0 when
>> irq_domain_add_linear() return NULL. This cause mpc8xx_pics_init to continue
>> executing even if mpc8xx_pic_host is NULL.
>>
>> Fixes: cc76404feaed ("powerpc/8xx: Fix possible device node reference leak")
>> Signed-off-by: Hangyu Hua 
>> ---
>>   arch/powerpc/platforms/8xx/pic.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/platforms/8xx/pic.c 
>> b/arch/powerpc/platforms/8xx/pic.c
>> index f2ba837249d6..04a6abf14c29 100644
>> --- a/arch/powerpc/platforms/8xx/pic.c
>> +++ b/arch/powerpc/platforms/8xx/pic.c
>> @@ -153,6 +153,7 @@ int __init mpc8xx_pic_init(void)
> 
> Expanding the context:
> 
>   siu_reg = ioremap(res.start, resource_size(&res));
>   if (siu_reg == NULL) {
>   ret = -EINVAL;
>   goto out;
>   }
> 
>   mpc8xx_pic_host = irq_domain_add_linear(np, 64, &mpc8xx_pic_host_ops, 
> NULL);
>>  if (mpc8xx_pic_host == NULL) {
>>  printk(KERN_ERR "MPC8xx PIC: failed to allocate irq host!\n");
>>  ret = -ENOMEM;
>> +goto out;
>>  }
>>   
>>  ret = 0;
>>  
> out:
>   of_node_put(np);
>   return ret;
> }
> 
> Proper error cleanup should also undo the ioremap() if
> irq_domain_add_linear() fails.

Uh ...

If siu_reg is NULL, you get a serious problem when __do_irq() calls 
mpc8xx_get_irq()

unsigned int mpc8xx_get_irq(void)
{
int irq;

/* For MPC8xx, read the SIVEC register and shift the bits down
 * to get the irq number.
 */
irq = in_be32(&siu_reg->sc_sivec) >> 26;

if (irq == PIC_VEC_SPURRIOUS)
return 0;

 return irq_linear_revmap(mpc8xx_pic_host, irq);

}


So I'll leave siu_reg as is even if irq_domain_add_linear() fails.

Whatever, if we do something about that it should be done in another 
patch I think.

Christophe

Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb

2022-03-08 Thread Christoph Hellwig

On Tue, Mar 08, 2022 at 04:38:21PM -0500, Boris Ostrovsky wrote:
>
> On 3/1/22 5:53 AM, Christoph Hellwig wrote:
>> Allow to pass a remap argument to the swiotlb initialization functions
>> to handle the Xen/x86 remap case.  ARM/ARM64 never did any remapping
>> from xen_swiotlb_fixup, so we don't even need that quirk.
>
>
> Any chance this patch could be split? Lots of things are happening here and 
> it's somewhat hard to review. (Patch 7 too BTW but I think I managed to get 
> through it)

What would be your preferred split?

>> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
>> index e0def4b1c3181..2f2c468acb955 100644
>> --- a/arch/x86/kernel/pci-dma.c
>> +++ b/arch/x86/kernel/pci-dma.c
>> @@ -71,15 +71,12 @@ static inline void __init pci_swiotlb_detect(void)
>>   #endif /* CONFIG_SWIOTLB */
>> #ifdef CONFIG_SWIOTLB_XEN
>> -static bool xen_swiotlb;
>> -
>>   static void __init pci_xen_swiotlb_init(void)
>>   {
>>  if (!xen_initial_domain() && !x86_swiotlb_enable)
>>  return;
>
>
> Now that there is a single call site for this routine I think this check can 
> be dropped. We are only called here for xen_initial_domain()==true.

The callsite just checks xen_pv_domain() and itself is called
unconditionally during initialization.

[PATCH kernel v4] powerpc/64: Add UADDR64 relocation support

2022-03-08 Thread Alexey Kardashevskiy

When ld detects unaligned relocations, it emits R_PPC64_UADDR64
relocations instead of R_PPC64_RELATIVE. Currently R_PPC64_UADDR64 are
detected by arch/powerpc/tools/relocs_check.sh and expected not to work.
Below is a simple chunk to trigger this behaviour (this disables
optimization for the demonstration purposes only, this also happens with
-O1/-O2 when CONFIG_PRINTK_INDEX=y, for example):

\#pragma GCC push_options
\#pragma GCC optimize ("O0")
struct entry {
const char *file;
int line;
} __attribute__((packed));
static const struct entry e1 = { .file = __FILE__, .line = __LINE__ };
static const struct entry e2 = { .file = __FILE__, .line = __LINE__ };
...
prom_printf("e1=%s %lx %lx\n", e1.file, (unsigned long) e1.file, mfmsr());
prom_printf("e2=%s %lx\n", e2.file, (unsigned long) e2.file);
\#pragma GCC pop_options

This adds support for UADDR64 for 64bit. This reuses __dynamic_symtab
from the 32bit which supports more relocation types already.

Because RELACOUNT includes only R_PPC64_RELATIVE, this replaces it with
RELASZ which is the size of all relocation records.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* fixed reloc->r_info hadling on big endian

v3:
* named some labels

v2:
* replaced RELACOUNT with RELASZ/RELAENT
* removed FIXME
---
 arch/powerpc/kernel/reloc_64.S | 67 +-
 arch/powerpc/kernel/vmlinux.lds.S  |  2 -
 arch/powerpc/tools/relocs_check.sh |  7 +---
 3 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
index 02d4719bf43a..232e4549defe 100644
--- a/arch/powerpc/kernel/reloc_64.S
+++ b/arch/powerpc/kernel/reloc_64.S
@@ -8,8 +8,10 @@
 #include 
 
 RELA = 7
-RELACOUNT = 0x6ff9
+RELASZ = 8
+RELAENT = 9
 R_PPC64_RELATIVE = 22
+R_PPC64_UADDR64 = 43
 
 /*
  * r3 = desired final address of kernel
@@ -25,29 +27,38 @@ _GLOBAL(relocate)
add r9,r9,r12   /* r9 has runtime addr of .rela.dyn section */
ld  r10,(p_st - 0b)(r12)
add r10,r10,r12 /* r10 has runtime addr of _stext */
+   ld  r13,(p_sym - 0b)(r12)
+   add r13,r13,r12 /* r13 has runtime addr of .dynsym */
 
/*
-* Scan the dynamic section for the RELA and RELACOUNT entries.
+* Scan the dynamic section for the RELA, RELASZ and RELAENT entries.
 */
li  r7,0
li  r8,0
-1: ld  r6,0(r11)   /* get tag */
+.Ltags:
+   ld  r6,0(r11)   /* get tag */
cmpdi   r6,0
-   beq 4f  /* end of list */
+   beq .Lend_of_list   /* end of list */
cmpdi   r6,RELA
bne 2f
ld  r7,8(r11)   /* get RELA pointer in r7 */
-   b   3f
-2: addis   r6,r6,(-RELACOUNT)@ha
-   cmpdi   r6,RELACOUNT@l
+   b   4f
+2: cmpdi   r6,RELASZ
bne 3f
-   ld  r8,8(r11)   /* get RELACOUNT value in r8 */
-3: addir11,r11,16
-   b   1b
-4: cmpdi   r7,0/* check we have both RELA and RELACOUNT */
+   ld  r8,8(r11)   /* get RELASZ value in r8 */
+   b   4f
+3: cmpdi   r6,RELAENT
+   bne 4f
+   ld  r12,8(r11)  /* get RELAENT value in r12 */
+4: addir11,r11,16
+   b   .Ltags
+.Lend_of_list:
+   cmpdi   r7,0/* check we have RELA, RELASZ, RELAENT */
cmpdi   cr1,r8,0
-   beq 6f
-   beq cr1,6f
+   beq .Lout
+   beq cr1,.Lout
+   cmpdi   r12,0
+   beq .Lout
 
/*
 * Work out linktime address of _stext and hence the
@@ -62,23 +73,39 @@ _GLOBAL(relocate)
 
/*
 * Run through the list of relocations and process the
-* R_PPC64_RELATIVE ones.
+* R_PPC64_RELATIVE and R_PPC64_UADDR64 ones.
 */
+   divdr8,r8,r12   /* RELASZ / RELAENT */
mtctr   r8
-5: ld  r0,8(9) /* ELF64_R_TYPE(reloc->r_info) */
+.Lrels:ld  r0,8(r9)/* ELF64_R_TYPE(reloc->r_info) 
*/
cmpdi   r0,R_PPC64_RELATIVE
-   bne 6f
+   bne .Luaddr64
ld  r6,0(r9)/* reloc->r_offset */
ld  r0,16(r9)   /* reloc->r_addend */
+   b   .Lstore
+.Luaddr64:
+   srdir14,r0,32   /* ELF64_R_SYM(reloc->r_info) */
+   clrldi  r0,r0,32
+   cmpdi   r0,R_PPC64_UADDR64
+   bne .Lnext
+   ld  r6,0(r9)
+   ld  r0,16(r9)
+   mulli   r14,r14,24  /* 24 == sizeof(elf64_sym) */
+   add r14,r14,r13 /* elf64_sym[ELF64_R_SYM] */
+   ld  r14,8(r14)
+   add r0,r0,r14
+.Lstore:
add r0,r0,r3
stdxr0,r7,r6
-   addir9,r9,24
-   bdnz5b
-
-6: blr
+.Lnext:
+   add r9,r9,r12
+   bdnz.Lrels
+.Lout:
+   blr
 
 .balign 8
 p_dyn: .8byte  __dynamic_start - 0b
 p_rela:.8byte  __rela_dyn_start - 0b
+p_sym:

Re: [PATCH] powerpc: 8xx: fix a return value error in mpc8xx_pic_init

2022-03-08 Thread Michael Ellerman

Hangyu Hua  writes:
> mpc8xx_pic_init() should return -ENOMEM instead of 0 when
> irq_domain_add_linear() return NULL. This cause mpc8xx_pics_init to continue
> executing even if mpc8xx_pic_host is NULL.
>
> Fixes: cc76404feaed ("powerpc/8xx: Fix possible device node reference leak")
> Signed-off-by: Hangyu Hua 
> ---
>  arch/powerpc/platforms/8xx/pic.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/8xx/pic.c 
> b/arch/powerpc/platforms/8xx/pic.c
> index f2ba837249d6..04a6abf14c29 100644
> --- a/arch/powerpc/platforms/8xx/pic.c
> +++ b/arch/powerpc/platforms/8xx/pic.c
> @@ -153,6 +153,7 @@ int __init mpc8xx_pic_init(void)

Expanding the context:

siu_reg = ioremap(res.start, resource_size(&res));
if (siu_reg == NULL) {
ret = -EINVAL;
goto out;
}

mpc8xx_pic_host = irq_domain_add_linear(np, 64, &mpc8xx_pic_host_ops, 
NULL);
>   if (mpc8xx_pic_host == NULL) {
>   printk(KERN_ERR "MPC8xx PIC: failed to allocate irq host!\n");
>   ret = -ENOMEM;
> + goto out;
>   }
>  
>   ret = 0;
>   
out:
of_node_put(np);
return ret;
}

Proper error cleanup should also undo the ioremap() if
irq_domain_add_linear() fails.

cheers

Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4

2022-03-08 Thread Michael Ellerman

Michael Ellerman  writes:
> On Tue, 15 Feb 2022 13:40:55 +0100, Christophe Leroy wrote:
>> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
>> on those three architectures because LKDTM messes up function
>> descriptors with functions.
>> 
>> This series does some cleanup in the three architectures and
>> refactors function descriptors so that it can then easily use it
>> in a generic way in LKDTM.
>> 
>> [...]
>
> Applied to powerpc/next.

I also have it in an rc2-based topic branch if there are any merge
conflicts that people want to resolve, I don't see any in linux-next at
the moment though.

https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/func-desc-lkdtm

cheers

[powerpc:next-test] BUILD SUCCESS 792993919349fefba20f58ae4843c80e8b01f518

2022-03-08 Thread kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
branch HEAD: 792993919349fefba20f58ae4843c80e8b01f518  powerpc/64: Force 
inlining of prevent_user_access() and set_kuap()

elapsed time: 723m

configs tested: 138
configs skipped: 3

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
i386  randconfig-c001
powerpcklondike_defconfig
sh   secureedge5410_defconfig
openrisc simple_smp_defconfig
m68k  multi_defconfig
arc nsimosci_hs_smp_defconfig
arm   h5000_defconfig
powerpc asp8347_defconfig
powerpc ps3_defconfig
parisc  defconfig
mips loongson1b_defconfig
m68km5307c3_defconfig
powerpc64   defconfig
xtensa  cadence_csp_defconfig
powerpc  storcenter_defconfig
arm vf610m4_defconfig
shsh7757lcr_defconfig
nios2 3c120_defconfig
sh  r7785rp_defconfig
pariscgeneric-64bit_defconfig
powerpc rainier_defconfig
sh   se7722_defconfig
m68k alldefconfig
arm s3c6400_defconfig
arm cm_x300_defconfig
sh   sh7724_generic_defconfig
h8300h8300h-sim_defconfig
m68kstmark2_defconfig
sh  rsk7201_defconfig
arm  pxa3xx_defconfig
xtensaxip_kc705_defconfig
sh   se7721_defconfig
powerpc mpc834x_itx_defconfig
um   x86_64_defconfig
m68k   m5249evb_defconfig
armhisi_defconfig
riscv   defconfig
sh   se7206_defconfig
xtensa  iss_defconfig
ia64defconfig
arm  randconfig-c002-20220308
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
s390 allyesconfig
s390 allmodconfig
parisc64defconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
i386   debian-10.3-kselftests
i386  debian-10.3
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64randconfig-a006
x86_64randconfig-a004
x86_64randconfig-a002
i386  randconfig-a003
i386  randconfig-a001
i386  randconfig-a005
x86_64randconfig-a013
x86_64randconfig-a011
x86_64randconfig-a015
i386  randconfig-a014
i386  randconfig-a012
i386  randconfig-a016
arc  randconfig-r043-20220308
riscvrandconfig-r042-20220308
s390 randconfig-r044-20220308
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv  rv32_defconfig
riscvallmodconfig

[powerpc:next] BUILD SUCCESS 1a76e520ee1831a81dabf8a9a58c6453f700026e

2022-03-08 Thread kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next
branch HEAD: 1a76e520ee1831a81dabf8a9a58c6453f700026e  powerpc/64e: Tie 
PPC_BOOK3E_64 to PPC_FSL_BOOK3E

elapsed time: 724m

configs tested: 128
configs skipped: 3

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
i386  randconfig-c001
powerpcklondike_defconfig
sh   secureedge5410_defconfig
openrisc simple_smp_defconfig
m68k  multi_defconfig
powerpc ps3_defconfig
parisc  defconfig
mips loongson1b_defconfig
m68km5307c3_defconfig
powerpc64   defconfig
xtensa  cadence_csp_defconfig
powerpc  storcenter_defconfig
arm vf610m4_defconfig
shsh7757lcr_defconfig
nios2 3c120_defconfig
sh  r7785rp_defconfig
pariscgeneric-64bit_defconfig
powerpc rainier_defconfig
sh   se7722_defconfig
m68k alldefconfig
arm s3c6400_defconfig
arm cm_x300_defconfig
sh   sh7724_generic_defconfig
h8300h8300h-sim_defconfig
m68kstmark2_defconfig
sh  rsk7201_defconfig
arm  pxa3xx_defconfig
xtensaxip_kc705_defconfig
sh   se7721_defconfig
powerpc mpc834x_itx_defconfig
um   x86_64_defconfig
m68k   m5249evb_defconfig
armhisi_defconfig
riscv   defconfig
sh   se7206_defconfig
xtensa  iss_defconfig
ia64defconfig
arm  randconfig-c002-20220308
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32 allnoconfig
nios2   defconfig
arc  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
s390 allyesconfig
s390 allmodconfig
parisc64defconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
i386   debian-10.3-kselftests
i386  debian-10.3
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64randconfig-a006
x86_64randconfig-a004
x86_64randconfig-a002
i386  randconfig-a003
i386  randconfig-a001
i386  randconfig-a005
x86_64randconfig-a015
x86_64randconfig-a013
x86_64randconfig-a011
arc  randconfig-r043-20220308
riscvrandconfig-r042-20220308
s390 randconfig-r044-20220308
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64rhel-8.3-kselftests
um i386_defconfig
x86_64   allyesconfig
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-func
x86_64

[RFC PATCH] KVM: PPC: Book3S HV: Add KVM_CAP_PPC_GTSE

2022-03-08 Thread Fabiano Rosas

This patch adds a new KVM capability to address a crash we're
currently having inside the nested guest kernel when running with
GTSE disabled in the nested hypervisor.

The summary is:

We allow any guest a cmdline override of GTSE for migration
purposes. The nested guest does not know it needs to use the option
and tries to run 'tlbie' with LPCR_GTSE=0.

The details are a bit more intricate:

QEMU always sets GTSE=1 in OV5 even before calling KVM. At prom_init,
guests use the OV5 value to set MMU_FTR_GTSE. This setting can be
overridden by 'radix_hcall_invalidate=on' in the kernel cmdline. The
option itself depends on the availability of
FW_FEATURE_RPT_INVALIDATE, which is tied to QEMU's cap-rpt-invalidate
capability.

The MMU_FTR_GTSE flag leads guests to set PROC_TABLE_GTSE in their
process tables and after H_REGISTER_PROC_TBL, both QEMU and KVM will
set LPCR_GTSE=1 for that guest. Unless the guest uses the cmdline
override, in which case:

  MMU_FTR_GTSE=0 -> PROC_TABLE_GTSE=0 -> LPCR_GTSE=0

We don't allow the nested hypervisor to set some LPCR bits for its
nested guests, so if the nested HV has LPCR_GTSE=0, its nested guests
will also have LPCR_GTSE=0. But since the only thing that can really
flip GTSE is the cmdline override, if a nested guest runs without it,
then the sequence goes:

  MMU_FTR_GTSE=1 -> PROC_TABLE_GTSE=1 -> LPCR_GTSE=0.

With LPCR_GTSE=0 the HW will treat 'tlbie' as HV privileged.

How the new capability helps:

By having QEMU consult KVM on what the correct GTSE value is, we can
have the nested hypervisor return the same value that it is currently
using. QEMU will then put the correct value in the device-tree for the
nested guest and MMU_FTR_GTSE will match LPCR_GTSE.

Fixes: b87cc116c7e1 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE 
capability")
Signed-off-by: Fabiano Rosas 
---
This supersedes the previous RFC: "KVM: PPC: Book3s HV: Allow setting
GTSE for the nested guest"*. Aneesh explained to me that we don't want
to allow L1 and L2 GTSE values to differ.

*- https://lore.kernel.org/r/20220304182657.2489303-1-faro...@linux.ibm.com
---
 arch/powerpc/kvm/powerpc.c | 3 +++
 include/uapi/linux/kvm.h   | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2ad0ccd202d5..dd08b3b729cd 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -677,6 +677,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_PPC_RPT_INVALIDATE:
r = 1;
break;
+   case KVM_CAP_PPC_GTSE:
+   r = mmu_has_feature(MMU_FTR_GTSE);
+   break;
 #endif
default:
r = 0;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 507ee1f2aa96..cc581e345d2a 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1135,6 +1135,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_XSAVE2 208
 #define KVM_CAP_SYS_ATTRIBUTES 209
 #define KVM_CAP_PPC_AIL_MODE_3 210
+#define KVM_CAP_PPC_GTSE 211
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.34.1

Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb

2022-03-08 Thread Boris Ostrovsky




On 3/1/22 5:53 AM, Christoph Hellwig wrote:

Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case.  ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.



Any chance this patch could be split? Lots of things are happening here and 
it's somewhat hard to review. (Patch 7 too BTW but I think I managed to get 
through it)



diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index e0def4b1c3181..2f2c468acb955 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -71,15 +71,12 @@ static inline void __init pci_swiotlb_detect(void)
  #endif /* CONFIG_SWIOTLB */
  
  #ifdef CONFIG_SWIOTLB_XEN

-static bool xen_swiotlb;
-
  static void __init pci_xen_swiotlb_init(void)
  {
if (!xen_initial_domain() && !x86_swiotlb_enable)
return;



Now that there is a single call site for this routine I think this check can be 
dropped. We are only called here for xen_initial_domain()==true.


-boris

[PATCH v1 6/6] powerpc: Add missing headers

2022-03-08 Thread Christophe Leroy

Don't inherit headers "by chances" from asm/prom.h, asm/mpc52xx.h,
asm/pci.h etc...

Include the needed headers, and remove asm/prom.h when it was
needed exclusively for pulling necessary headers.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/pnv-pci.h | 1 +
 arch/powerpc/kernel/btext.c| 2 +-
 arch/powerpc/kernel/cputable.c | 2 +-
 arch/powerpc/kernel/crash_dump.c   | 2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c  | 2 +-
 arch/powerpc/kernel/eeh_pe.c   | 1 +
 arch/powerpc/kernel/eeh_sysfs.c| 1 +
 arch/powerpc/kernel/fadump.c   | 3 ++-
 arch/powerpc/kernel/isa-bridge.c   | 2 +-
 arch/powerpc/kernel/legacy_serial.c| 2 +-
 arch/powerpc/kernel/nvram_64.c | 2 +-
 arch/powerpc/kernel/pci-common.c   | 2 +-
 arch/powerpc/kernel/pci-hotplug.c  | 1 +
 arch/powerpc/kernel/pci_64.c   | 2 +-
 arch/powerpc/kernel/pci_dn.c   | 2 +-
 arch/powerpc/kernel/pci_of_scan.c  | 2 +-
 arch/powerpc/kernel/proc_powerpc.c | 2 +-
 arch/powerpc/kernel/prom_init.c| 2 ++
 arch/powerpc/kernel/rtas-proc.c| 2 +-
 arch/powerpc/kernel/rtas.c | 3 ++-
 arch/powerpc/kernel/rtas_pci.c | 3 ++-
 arch/powerpc/kernel/setup-common.c | 3 ++-
 arch/powerpc/kernel/setup_32.c | 3 ++-
 arch/powerpc/kernel/setup_64.c | 3 ++-
 arch/powerpc/kernel/sysfs.c| 2 +-
 arch/powerpc/kernel/time.c | 2 +-
 arch/powerpc/kexec/core_64.c   | 2 +-
 arch/powerpc/kvm/book3s_hv.c   | 1 +
 arch/powerpc/kvm/powerpc.c | 1 +
 arch/powerpc/mm/book3s64/hash_utils.c  | 2 +-
 arch/powerpc/mm/drmem.c| 2 +-
 arch/powerpc/perf/imc-pmu.c| 1 +
 arch/powerpc/platforms/44x/canyonlands.c   | 1 +
 arch/powerpc/platforms/44x/fsp2.c  | 2 +-
 arch/powerpc/platforms/44x/ppc476.c| 2 +-
 arch/powerpc/platforms/44x/warp.c  | 3 ++-
 arch/powerpc/platforms/4xx/hsta_msi.c  | 1 +
 arch/powerpc/platforms/4xx/pci.c   | 1 +
 arch/powerpc/platforms/4xx/uic.c   | 3 ++-
 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 3 ++-
 arch/powerpc/platforms/512x/mpc512x_shared.c   | 2 +-
 arch/powerpc/platforms/52xx/lite5200_pm.c  | 2 ++
 arch/powerpc/platforms/52xx/media5200.c| 3 ++-
 arch/powerpc/platforms/52xx/mpc5200_simple.c   | 2 +-
 arch/powerpc/platforms/52xx/mpc52xx_common.c   | 2 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c  | 2 ++
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c  | 3 ++-
 arch/powerpc/platforms/52xx/mpc52xx_pci.c  | 1 +
 arch/powerpc/platforms/52xx/mpc52xx_pic.c  | 3 ++-
 arch/powerpc/platforms/52xx/mpc52xx_pm.c   | 2 ++
 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c   | 2 +-
 arch/powerpc/platforms/83xx/mpc832x_rdb.c  | 1 +
 arch/powerpc/platforms/83xx/mpc834x_mds.c  | 2 +-
 arch/powerpc/platforms/83xx/mpc837x_mds.c  | 2 +-
 arch/powerpc/platforms/83xx/usb.c  | 2 +-
 arch/powerpc/platforms/85xx/ge_imp3a.c | 2 +-
 arch/powerpc/platforms/85xx/mpc85xx_cds.c  | 3 ++-
 arch/powerpc/platforms/85xx/mpc85xx_ds.c   | 2 +-
 arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
 arch/powerpc/platforms/85xx/p1022_rdk.c| 1 +
 arch/powerpc/platforms/85xx/p1023_rdb.c| 2 +-
 arch/powerpc/platforms/85xx/qemu_e500.c| 1 +
 arch/powerpc/platforms/85xx/xes_mpc85xx.c  | 2 +-
 arch/powerpc/platforms/86xx/gef_ppc9a.c| 2 +-
 arch/powerpc/platforms/86xx/gef_sbc310.c   | 2 +-
 arch/powerpc/platforms/86xx/gef_sbc610.c   | 2 +-
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 ++-
 arch/powerpc/platforms/86xx/mvme7100.c | 1 +
 arch/powerpc/platforms/8xx/cpm1.c  | 2 +-
 arch/powerpc/platforms/8xx/m8xx_setup.c| 3 ++-
 arch/powerpc/platforms/8xx/pic.c   | 3 ++-
 arch/powerpc/platforms/amigaone/setup.c| 1 +
 arch/powerpc/platforms/cell/axon_msi.c | 2 +-
 arch/powerpc/platforms/cell/cbe_powerbutton.c  | 2 +-
 arch/powerpc/platforms/cell/cbe_regs.c | 2 +-
 arch/powerpc/platforms/cell/interrupt.c| 3 ++-
 arch/powerpc/platforms/cell/iommu.c| 2 ++
 arch/powerpc/platforms/cell/ras.c  | 2 +-
 arch/powerpc/platforms/cell/spider-pci.c   | 1 +
 arch/powerpc/platforms/cell/spider-pic.c   | 3 ++-
 arch/powerpc/platforms/cell/spu_manage.c

[PATCH v1 5/6] powerpc: Remove asm/prom.h from all files that don't need it

2022-03-08 Thread Christophe Leroy

Several files include asm/prom.h for no reason.

Clean it up.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/cacheinfo.c  | 1 -
 arch/powerpc/kernel/eeh_driver.c | 1 -
 arch/powerpc/kernel/iommu.c  | 1 -
 arch/powerpc/kernel/irq.c| 1 -
 arch/powerpc/kernel/pci_32.c | 1 -
 arch/powerpc/kernel/process.c| 1 -
 arch/powerpc/kernel/prom.c   | 1 -
 arch/powerpc/kernel/prom_parse.c | 1 -
 arch/powerpc/kernel/rtas-rtc.c   | 1 -
 arch/powerpc/kernel/rtasd.c  | 1 -
 arch/powerpc/kernel/smp.c| 1 -
 arch/powerpc/kernel/vdso.c   | 1 -
 arch/powerpc/kexec/core.c| 1 -
 arch/powerpc/kexec/crash.c   | 1 -
 arch/powerpc/mm/book3s32/mmu.c   | 1 -
 arch/powerpc/mm/init_32.c| 1 -
 arch/powerpc/mm/nohash/40x.c | 1 -
 arch/powerpc/mm/nohash/fsl_book3e.c  | 1 -
 arch/powerpc/mm/nohash/kaslr_booke.c | 1 -
 arch/powerpc/mm/numa.c   | 1 -
 arch/powerpc/mm/pgtable_64.c | 1 -
 arch/powerpc/platforms/40x/ppc40x_simple.c   | 1 -
 arch/powerpc/platforms/44x/ppc44x_simple.c   | 1 -
 arch/powerpc/platforms/44x/sam440ep.c| 1 -
 arch/powerpc/platforms/512x/mpc5121_ads.c| 1 -
 arch/powerpc/platforms/512x/mpc512x_generic.c| 1 -
 arch/powerpc/platforms/52xx/efika.c  | 1 -
 arch/powerpc/platforms/52xx/lite5200.c   | 1 -
 arch/powerpc/platforms/82xx/ep8248e.c| 1 -
 arch/powerpc/platforms/82xx/km82xx.c | 1 -
 arch/powerpc/platforms/83xx/km83xx.c | 1 -
 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c   | 1 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c| 1 -
 arch/powerpc/platforms/83xx/mpc834x_itx.c| 1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c| 1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c| 1 -
 arch/powerpc/platforms/85xx/corenet_generic.c| 1 -
 arch/powerpc/platforms/85xx/ksi8560.c| 1 -
 arch/powerpc/platforms/85xx/mpc8536_ds.c | 1 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c| 1 -
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c| 1 -
 arch/powerpc/platforms/85xx/p1010rdb.c   | 1 -
 arch/powerpc/platforms/85xx/socrates.c   | 1 -
 arch/powerpc/platforms/85xx/stx_gp3.c| 1 -
 arch/powerpc/platforms/85xx/tqm85xx.c| 1 -
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c   | 1 -
 arch/powerpc/platforms/8xx/adder875.c| 1 -
 arch/powerpc/platforms/cell/cbe_thermal.c| 1 -
 arch/powerpc/platforms/cell/pervasive.c  | 1 -
 arch/powerpc/platforms/cell/setup.c  | 1 -
 arch/powerpc/platforms/cell/smp.c| 1 -
 arch/powerpc/platforms/cell/spu_base.c   | 1 -
 arch/powerpc/platforms/cell/spu_priv1_mmio.c | 1 -
 arch/powerpc/platforms/chrp/smp.c| 1 -
 arch/powerpc/platforms/embedded6xx/gamecube.c| 1 -
 arch/powerpc/platforms/embedded6xx/linkstation.c | 1 -
 arch/powerpc/platforms/embedded6xx/storcenter.c  | 1 -
 arch/powerpc/platforms/powermac/backlight.c  | 1 -
 arch/powerpc/platforms/powermac/feature.c| 1 -
 arch/powerpc/platforms/powermac/setup.c  | 1 -
 arch/powerpc/platforms/powermac/udbg_adb.c   | 1 -
 arch/powerpc/platforms/powermac/udbg_scc.c   | 1 -
 arch/powerpc/platforms/powernv/pci.c | 1 -
 arch/powerpc/platforms/ps3/htab.c| 1 -
 arch/powerpc/platforms/ps3/mm.c  | 1 -
 arch/powerpc/platforms/ps3/os-area.c | 2 --
 arch/powerpc/platforms/pseries/dlpar.c   | 1 -
 arch/powerpc/platforms/pseries/hotplug-memory.c  | 1 -
 arch/powerpc/platforms/pseries/lpar.c| 1 -
 arch/powerpc/platforms/pseries/lparcfg.c | 1 -
 arch/powerpc/platforms/pseries/pci.c | 1 -
 arch/powerpc/platforms/pseries/pmem.c| 1 -
 arch/powerpc/platforms/pseries/reconfig.c| 1 -
 arch/powerpc/platforms/pseries/smp.c | 1 -
 arch/powerpc/sysdev/fsl_soc.c| 1 -
 arch/powerpc/sysdev/indirect_pci.c   | 1 -
 arch/powerpc/sysdev/xics/ics-native.c| 1 -
 arch/powerpc/sysdev/xics/ics-opal.c  | 1 -
 arch/powerpc/sysdev/xics/ics-rtas.c  | 1 -
 arch/powerpc/xmon/xmon.c | 1 -
 80 files changed, 81 deletions(-)

diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 00b0992be3e7..f502337dd37d 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 422f80b5b27b..

[PATCH v1 2/6] powerpc: Don't include asm/prom.h in asm/parport.h

2022-03-08 Thread Christophe Leroy

parport.h needs only of_irq.h, no need to go via asm/prom.h

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/parport.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/parport.h 
b/arch/powerpc/include/asm/parport.h
index 8abfb8f7c33d..42cc321ed754 100644
--- a/arch/powerpc/include/asm/parport.h
+++ b/arch/powerpc/include/asm/parport.h
@@ -11,7 +11,7 @@
 #define _ASM_POWERPC_PARPORT_H
 #ifdef __KERNEL__
 
-#include 
+#include 
 
 static int parport_pc_find_nonpci_ports (int autoirq, int autodma)
 {
-- 
2.34.1

[PATCH v1 1/6] powerpc/64: Move pci_device_from_OF_node() out of asm/pci-bridge.h

2022-03-08 Thread Christophe Leroy

Move pci_device_from_OF_node() in pci64.c because it needs definition
of struct device_node and is not worth inlining.

ppc32.c already has it in pci32.c.

That way pci-bridge.h doesn't need linux/of.h (Brought by asm/prom.h
via asm/pci.h)

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/pci-bridge.h | 14 ++
 arch/powerpc/kernel/pci_64.c  |  9 +
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index 90f488fa4c17..c85f901227c9 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -170,10 +170,10 @@ static inline struct pci_controller 
*pci_bus_to_host(const struct pci_bus *bus)
return bus->sysdata;
 }
 
-#ifndef CONFIG_PPC64
-
 extern int pci_device_from_OF_node(struct device_node *node,
   u8 *bus, u8 *devfn);
+#ifndef CONFIG_PPC64
+
 extern void pci_create_OF_bus_map(void);
 
 #else  /* CONFIG_PPC64 */
@@ -235,16 +235,6 @@ struct pci_dn *add_sriov_vf_pdns(struct pci_dev *pdev);
 void remove_sriov_vf_pdns(struct pci_dev *pdev);
 #endif
 
-static inline int pci_device_from_OF_node(struct device_node *np,
- u8 *bus, u8 *devfn)
-{
-   if (!PCI_DN(np))
-   return -ENODEV;
-   *bus = PCI_DN(np)->busno;
-   *devfn = PCI_DN(np)->devfn;
-   return 0;
-}
-
 #if defined(CONFIG_EEH)
 static inline struct eeh_dev *pdn_to_eeh_dev(struct pci_dn *pdn)
 {
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 3fb7e572abed..81f84e71ab93 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -285,3 +285,12 @@ int pcibus_to_node(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibus_to_node);
 #endif
+
+int pci_device_from_OF_node(struct device_node *np, u8 *bus, u8 *devfn)
+{
+   if (!PCI_DN(np))
+   return -ENODEV;
+   *bus = PCI_DN(np)->busno;
+   *devfn = PCI_DN(np)->devfn;
+   return 0;
+}
-- 
2.34.1

[PATCH v1 3/6] powerpc: Include asm/reg.h in asm/svm.h

2022-03-08 Thread Christophe Leroy

is_secure_guest() uses mfmsr().

Don't rely on users to include asm/reg.h, include
it in asm/svm.h

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/svm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
index 7546402d796a..da864623cc00 100644
--- a/arch/powerpc/include/asm/svm.h
+++ b/arch/powerpc/include/asm/svm.h
@@ -10,6 +10,8 @@
 
 #ifdef CONFIG_PPC_SVM
 
+#include 
+
 static inline bool is_secure_guest(void)
 {
return mfmsr() & MSR_S;
-- 
2.34.1

[PATCH v1 4/6] powerpc: Add missing declaration in asm/drmem.h

2022-03-08 Thread Christophe Leroy

Don't rely on random inclusion of linux/of.h by users
of asm/drmem.h

Add a forward declaration of struct property and
struct device_node.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/drmem.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index 4265d5e95c2c..13bf6dee8e2d 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -23,6 +23,9 @@ struct drmem_lmb_info {
u64 lmb_size;
 };
 
+struct device_node;
+struct property;
+
 extern struct drmem_lmb_info *drmem_info;
 
 static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb,
-- 
2.34.1

Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1

2022-03-08 Thread Tokunori Ikegami


Hi,

On 2022/03/09 1:23, Ahmad Fatoum wrote:

Hello Tokunori-san,

On 08.03.22 17:13, Tokunori Ikegami wrote:

Hi Ahmad-san,

On 2022/03/08 18:44, Ahmad Fatoum wrote:

Hello Tokunori,

On 06.03.22 16:49, Tokunori Ikegami wrote:

Hi,

On 2022/03/04 20:11, Ahmad Fatoum wrote:

Hello Tokunori-san,

On 20.02.22 13:22, Tokunori Ikegami wrote:

Hi Ahmad-san,

Could you please try the version 2 patch attached for the error case?
This version is to check the DQ true data 0xFF by chip_good().

I had a similar patch locally as well at first. I just tested yours
and I can't reproduce the issue.

Thanks for your support.
Sorry if possible could you please retest the attached the patch again since 
this fixed the version 1 patch maintainer review comments?

Works good.

Tested-by: Ahmad Fatoum 

Thank you so much for your test.

But I am not sure if this works or not since the error is possible to be caused 
by Hi-Z 0xff on floating bus or etc.

That it works for me could be because of Hi-Z 0xff, which is why
decided against it.

I see.

What seems to work for me is checking if chip_good or chip_ready
and map_word is equal to 0xFF. I can't justify why this is ok though.
(Worst case bus is floating at this point of time and Hi-Z is read
as 0xff on CPU data lines...)

Sorry I am not sure about this.
I thought the chip_ready() itself is correct as implemented as the data sheet 
in the past.
But it did not work correctly so changed to use chip_good() instead as it is 
also correct.

What exactly in the datasheet makes you believe chip_good is not appropriate?

I just mentioned about the actual issue behaviors as not worked chip_good() on 
S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G before etc.
Anyway let me recheck the data sheet details as just checked it again quickly 
but needed more investigation to understand.

As far as I checked still both chip_good() and chip_ready() seem correct but 
still the root cause is unknown.
If as you mentioned the issue was cased by the DQ true data 0xFF I am not sure 
why the read work without any error after the write operation.
Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned I am 
not sure why the read work without any error after the write operation with 
chip_ready().
Sorry anyway the root cause is also unknown when the write operation was 
changed to use chip_good() instead of chip_ready().

I've be ok with v1 then. Restores working behavior for me and shouldn't break 
others.

Noted but still I am thinking the version 2 patch to check 0xff seems better 
than to use chip_ready() so let me consider this again later.

The original version has less room for surprise as it restores previously
working behavior. Assuming 0xFF to be good without backing from documentation
is more risky IMO.

The change to check 0xFF can be limited for the S29GL064N chip do you have any 
comment about this?

I see that, but I am not sure it's the correct thing to do on the S29GL064N,
even if it seems to work. In absence of definitive information from the vendor,
I'd prefer we just restore behavior as it was before, i.e. using chip_ready
instead of chip_good for S29GL064N. This is the way of least surprise.


Thanks for your comment. I see okay I will keep the version patch 2 
reverting to use chip_ready() for S29GL064N under the review without the 
change to check 0xFF.


Regards,
Ikegami




Just attached the patch changed as so and thinking to send the patch as version 
3 to the maintainer if you are okay.

Regards,
Ikegami


Thanks for your continued support,
Ahmad


Regards,
Ikegami


Cheers and thanks again,
Ahmad


Regards,
Ikegami


Regards,
Ikegami


Cheers,
Ahmad

Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1

2022-03-08 Thread Ahmad Fatoum

Hello Tokunori-san,

On 08.03.22 17:13, Tokunori Ikegami wrote:
> Hi Ahmad-san,
> 
> On 2022/03/08 18:44, Ahmad Fatoum wrote:
>> Hello Tokunori,
>>
>> On 06.03.22 16:49, Tokunori Ikegami wrote:
>>> Hi,
>>>
>>> On 2022/03/04 20:11, Ahmad Fatoum wrote:
 Hello Tokunori-san,

 On 20.02.22 13:22, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Could you please try the version 2 patch attached for the error case?
> This version is to check the DQ true data 0xFF by chip_good().
 I had a similar patch locally as well at first. I just tested yours
 and I can't reproduce the issue.
>>> Thanks for your support.
>>> Sorry if possible could you please retest the attached the patch again 
>>> since this fixed the version 1 patch maintainer review comments?
>> Works good.
>>
>> Tested-by: Ahmad Fatoum 
> Thank you so much for your test.
>>
> But I am not sure if this works or not since the error is possible to be 
> caused by Hi-Z 0xff on floating bus or etc.
 That it works for me could be because of Hi-Z 0xff, which is why
 decided against it.
>>> I see.
> What seems to work for me is checking if chip_good or chip_ready
> and map_word is equal to 0xFF. I can't justify why this is ok though.
> (Worst case bus is floating at this point of time and Hi-Z is read
> as 0xff on CPU data lines...)
 Sorry I am not sure about this.
 I thought the chip_ready() itself is correct as implemented as the 
 data sheet in the past.
 But it did not work correctly so changed to use chip_good() instead as 
 it is also correct.
>>> What exactly in the datasheet makes you believe chip_good is not 
>>> appropriate?
>> I just mentioned about the actual issue behaviors as not worked 
>> chip_good() on S29GL964N and not worked chip_ready() on 
>> MX29GL512FHT2I-11G before etc.
>> Anyway let me recheck the data sheet details as just checked it again 
>> quickly but needed more investigation to understand.
> As far as I checked still both chip_good() and chip_ready() seem correct 
> but still the root cause is unknown.
> If as you mentioned the issue was cased by the DQ true data 0xFF I am not 
> sure why the read work without any error after the write operation.
> Also if the error was caused by the Hi-Z 0xff on floating bus as 
> mentioned I am not sure why the read work without any error after the 
> write operation with chip_ready().
> Sorry anyway the root cause is also unknown when the write operation was 
> changed to use chip_good() instead of chip_ready().
 I've be ok with v1 then. Restores working behavior for me and shouldn't 
 break others.
>>> Noted but still I am thinking the version 2 patch to check 0xff seems 
>>> better than to use chip_ready() so let me consider this again later.
>> The original version has less room for surprise as it restores previously
>> working behavior. Assuming 0xFF to be good without backing from documentation
>> is more risky IMO.
> The change to check 0xFF can be limited for the S29GL064N chip do you have 
> any comment about this?

I see that, but I am not sure it's the correct thing to do on the S29GL064N,
even if it seems to work. In absence of definitive information from the vendor,
I'd prefer we just restore behavior as it was before, i.e. using chip_ready
instead of chip_good for S29GL064N. This is the way of least surprise.

> Just attached the patch changed as so and thinking to send the patch as 
> version 3 to the maintainer if you are okay.
> 
> Regards,
> Ikegami
> 
>>
>> Thanks for your continued support,
>> Ahmad
>>
>>> Regards,
>>> Ikegami
>>>
 Cheers and thanks again,
 Ahmad

> Regards,
> Ikegami
>
>> Regards,
>> Ikegami
>>
>>> Cheers,
>>> Ahmad
>>>
>>>
>>


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1

2022-03-08 Thread Tokunori Ikegami


Hi Ahmad-san,

On 2022/03/08 18:44, Ahmad Fatoum wrote:

Hello Tokunori,

On 06.03.22 16:49, Tokunori Ikegami wrote:

Hi,

On 2022/03/04 20:11, Ahmad Fatoum wrote:

Hello Tokunori-san,

On 20.02.22 13:22, Tokunori Ikegami wrote:

Hi Ahmad-san,

Could you please try the version 2 patch attached for the error case?
This version is to check the DQ true data 0xFF by chip_good().

I had a similar patch locally as well at first. I just tested yours
and I can't reproduce the issue.

Thanks for your support.
Sorry if possible could you please retest the attached the patch again since 
this fixed the version 1 patch maintainer review comments?

Works good.

Tested-by: Ahmad Fatoum 

Thank you so much for your test.



But I am not sure if this works or not since the error is possible to be caused 
by Hi-Z 0xff on floating bus or etc.

That it works for me could be because of Hi-Z 0xff, which is why
decided against it.

I see.

What seems to work for me is checking if chip_good or chip_ready
and map_word is equal to 0xFF. I can't justify why this is ok though.
(Worst case bus is floating at this point of time and Hi-Z is read
as 0xff on CPU data lines...)

Sorry I am not sure about this.
I thought the chip_ready() itself is correct as implemented as the data sheet 
in the past.
But it did not work correctly so changed to use chip_good() instead as it is 
also correct.

What exactly in the datasheet makes you believe chip_good is not appropriate?

I just mentioned about the actual issue behaviors as not worked chip_good() on 
S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G before etc.
Anyway let me recheck the data sheet details as just checked it again quickly 
but needed more investigation to understand.

As far as I checked still both chip_good() and chip_ready() seem correct but 
still the root cause is unknown.
If as you mentioned the issue was cased by the DQ true data 0xFF I am not sure 
why the read work without any error after the write operation.
Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned I am 
not sure why the read work without any error after the write operation with 
chip_ready().
Sorry anyway the root cause is also unknown when the write operation was 
changed to use chip_good() instead of chip_ready().

I've be ok with v1 then. Restores working behavior for me and shouldn't break 
others.

Noted but still I am thinking the version 2 patch to check 0xff seems better 
than to use chip_ready() so let me consider this again later.

The original version has less room for surprise as it restores previously
working behavior. Assuming 0xFF to be good without backing from documentation
is more risky IMO.
The change to check 0xFF can be limited for the S29GL064N chip do you 
have any comment about this?
Just attached the patch changed as so and thinking to send the patch as 
version 3 to the maintainer if you are okay.


Regards,
Ikegami



Thanks for your continued support,
Ahmad


Regards,
Ikegami


Cheers and thanks again,
Ahmad


Regards,
Ikegami


Regards,
Ikegami


Cheers,
Ahmad


From f4e767b4c9b2d5139387175f0c57afd81f0b62de Mon Sep 17 00:00:00 2001
From: Tokunori Ikegami 
Date: Sat, 19 Feb 2022 19:39:32 +0900
Subject: [PATCH v3] mtd: cfi_cmdset_0002: Change chip_good() to check DQ true
 data 0xFF on S29GL064N

The regression issue has been caused on S29GL064N and reported it.
The change mentioned for regression is to use chip_good() for buffered write.
Also it seems that the 0xFF value is read on the error case.
It is possible to be caused by DQ true data described by S29GL064N datasheet.
So change chip_good() to check DQ true data 0xFF additionally for the error.

Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct 
value")
Signed-off-by: Tokunori Ikegami 
Cc: Miquel Raynal 
Cc: Richard Weinberger 
Cc: Vignesh Raghavendra 
Cc: linux-...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea...@pengutronix.de/
---
 drivers/mtd/chips/cfi_cmdset_0002.c | 36 -
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c 
b/drivers/mtd/chips/cfi_cmdset_0002.c
index a761134fd3be..99c1c6741b69 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -48,6 +48,7 @@
 #define SST49LF040B0x0050
 #define SST49LF008A0x005a
 #define AT49BV6416 0x00d6
+#define S29GL064N_MN12 0x0c01
 
 /*
  * Status Register bit description. Used by flash devices that don't
@@ -462,7 +463,7 @@ static struct cfi_fixup cfi_fixup_table[] = {
{ CFI_MFR_AMD, 0x0056, fixup_use_secsi },
{ CFI_MFR_AMD, 0x005C, fixup_use_secsi },
{ CFI_MFR_AMD, 0x005F, fixup_use_secsi },
-   { CFI_MFR_AMD, 0x0c01, fixup_s29gl064n_sectors },
+   { CFI_MFR_AMD, S29GL064N_MN12, fixup_s29gl064n_sectors },
{ CFI_MFR_AMD, 0x1301, fixup_s29gl064n_sector

[PATCH net-next v2] powerpc/net: Implement powerpc specific csum_shift() to remove branch

2022-03-08 Thread Christophe Leroy

Today's implementation of csum_shift() leads to branching based on
parity of 'offset'

02f8 :
 2f8:   70 a5 00 01 andi.   r5,r5,1
 2fc:   41 a2 00 08 beq 304 
 300:   54 84 c0 3e rotlwi  r4,r4,24
 304:   7c 63 20 14 addcr3,r3,r4
 308:   7c 63 01 94 addze   r3,r3
 30c:   4e 80 00 20 blr

Use first bit of 'offset' directly as input of the rotation instead of
branching.

02f8 :
 2f8:   54 a5 1f 38 rlwinm  r5,r5,3,28,28
 2fc:   20 a5 00 20 subfic  r5,r5,32
 300:   5c 84 28 3e rotlw   r4,r4,r5
 304:   7c 63 20 14 addcr3,r3,r4
 308:   7c 63 01 94 addze   r3,r3
 30c:   4e 80 00 20 blr

And change to left shift instead of right shift to skip one more
instruction. This has no impact on the final sum.

02f8 :
 2f8:   54 a5 1f 38 rlwinm  r5,r5,3,28,28
 2fc:   5c 84 28 3e rotlw   r4,r4,r5
 300:   7c 63 20 14 addcr3,r3,r4
 304:   7c 63 01 94 addze   r3,r3
 308:   4e 80 00 20 blr

Seems like only powerpc benefits from a branchless implementation.
Other main architectures like ARM or X86 get better code with
the generic implementation and its branch.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/checksum.h | 7 +++
 include/net/checksum.h  | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/powerpc/include/asm/checksum.h 
b/arch/powerpc/include/asm/checksum.h
index 19eaa2b6d043..8321f6053a67 100644
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -111,6 +111,13 @@ static __always_inline __wsum csum_add(__wsum csum, __wsum 
addend)
 #endif
 }
 
+#define HAVE_ARCH_CSUM_SHIFT
+static __always_inline __wsum csum_shift(__wsum sum, int offset)
+{
+   /* rotate sum to align it with a 16b boundary */
+   return (__force __wsum)rol32((__force u32)sum, (offset & 1) << 3);
+}
+
 /*
  * This is a version of ip_compute_csum() optimized for IP headers,
  * which always checksum on 4 octet boundaries.  ihl is the number
diff --git a/include/net/checksum.h b/include/net/checksum.h
index 79c67f14c448..6bc783b7a06c 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -80,6 +80,7 @@ static __always_inline __sum16 csum16_sub(__sum16 csum, 
__be16 addend)
return csum16_add(csum, ~addend);
 }
 
+#ifndef HAVE_ARCH_CSUM_SHIFT
 static __always_inline __wsum csum_shift(__wsum sum, int offset)
 {
/* rotate sum to align it with a 16b boundary */
@@ -87,6 +88,7 @@ static __always_inline __wsum csum_shift(__wsum sum, int 
offset)
return (__force __wsum)ror32((__force u32)sum, 8);
return sum;
 }
+#endif
 
 static __always_inline __wsum
 csum_block_add(__wsum csum, __wsum csum2, int offset)
-- 
2.34.1

Re: [PATCH] powerpc: 8xx: fix a return value error in mpc8xx_pic_init

2022-03-08 Thread Christophe Leroy



Le 07/03/2022 à 02:41, Hangyu Hua a écrit :
> Ping?
> 
> On 2022/2/23 15:02, Hangyu Hua wrote:
>> mpc8xx_pic_init() should return -ENOMEM instead of 0 when
>> irq_domain_add_linear() return NULL. This cause mpc8xx_pics_init to 
>> continue
>> executing even if mpc8xx_pic_host is NULL.
>>
>> Fixes: cc76404feaed ("powerpc/8xx: Fix possible device node reference 
>> leak")
>> Signed-off-by: Hangyu Hua 

Reviewed-by: Christophe Leroy 

>> ---
>>   arch/powerpc/platforms/8xx/pic.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/platforms/8xx/pic.c 
>> b/arch/powerpc/platforms/8xx/pic.c
>> index f2ba837249d6..04a6abf14c29 100644
>> --- a/arch/powerpc/platforms/8xx/pic.c
>> +++ b/arch/powerpc/platforms/8xx/pic.c
>> @@ -153,6 +153,7 @@ int __init mpc8xx_pic_init(void)
>>   if (mpc8xx_pic_host == NULL) {
>>   printk(KERN_ERR "MPC8xx PIC: failed to allocate irq host!\n");
>>   ret = -ENOMEM;
>> +    goto out;
>>   }
>>   ret = 0;

Re: [PATCH 00/14] powerpc/rtas: various cleanups and improvements

2022-03-08 Thread Christophe Leroy

Hi Nick,

Le 08/03/2022 à 14:50, Nicholas Piggin a écrit :
> I had a bunch of random little fixes and cleanups around and
> was prompted to put them together and make a change to call
> RTAS with MSR[RI] enabled because of a report of the hard
> lockup watchdog NMI IPI hitting in an rtas call which then
> crashed because it's unrecoverable.
> 
> Could possibly move patch 9 earlier if it would help with
> backporting.
> 
> Thanks,
> Nick

While you are at cleaning RTAS, maybe you could add to your series the 
two following patches, unless they are not applicable anymore ?

https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210714122753.76021-1-zhuang...@huawei.com/

https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210526092020.554341-1-chenhua...@huawei.com/

Christophe

> 
> Nicholas Piggin (14):
>powerpc/rtas: Move rtas entry assembly into its own file
>powerpc/rtas: Make enter_rtas a nokprobe symbol on 64-bit
>powerpc/rtas: Fix whitespace in rtas_entry.S
>powerpc/rtas: Call enter_rtas with MSR[EE] disabled
>powerpc/rtas: Modernise RI clearing on 64-bit
>powerpc/rtas: Load rtas entry MSR explicitly
>powerpc/rtas: PACA can be restored directly from SPRG
>powerpc/rtas: call enter_rtas in real-mode on 64-bit
>powerpc/rtas: Leave MSR[RI] enabled over RTAS call
>powerpc/rtas: replace rtas_call_unlocked with raw_rtas_call
>powerpc/rtas: tidy __fetch_rtas_last_error
>powerpc/rtas: Close theoretical memory leak
>powerpc/rtas: enture rtas_call is called with MMU enabled
>powerpc/rtas: Consolidate and improve checking for rtas callers
> 
>   arch/powerpc/include/asm/rtas.h  |   4 +-
>   arch/powerpc/kernel/Makefile |   2 +-
>   arch/powerpc/kernel/entry_32.S   |  49 --
>   arch/powerpc/kernel/entry_64.S   | 150 ---
>   arch/powerpc/kernel/rtas.c   | 132 +---
>   arch/powerpc/kernel/rtas_entry.S | 144 ++
>   arch/powerpc/platforms/pseries/hotplug-cpu.c |   2 +-
>   arch/powerpc/platforms/pseries/ras.c |   7 +-
>   arch/powerpc/xmon/xmon.c |   2 +-
>   9 files changed, 227 insertions(+), 265 deletions(-)
>   create mode 100644 arch/powerpc/kernel/rtas_entry.S
>

Re: [RFC PATCH 2/2] KVM: PPC: Book3S HV: Provide a more accurate MAX_VCPU_ID in P9

2022-03-08 Thread Fabiano Rosas

Christophe Leroy  writes:

> Le 13/04/2021 à 00:26, Fabiano Rosas a écrit :
>> The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6
>> ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than
>> KVM_MAX_VCPU in powerpc.
>> 
>> For a P9 host we depend on the guest VSMT value to know what is the
>> maximum number of vcpu id we can support:
>> 
>> kvmppc_core_vcpu_create_hv:
>>  (...)
>>  if (cpu_has_feature(CPU_FTR_ARCH_300)) {
>> --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
>>  pr_devel("KVM: VCPU ID too high\n");
>>  core = KVM_MAX_VCORES;
>>  } else {
>>  BUG_ON(kvm->arch.smt_mode != 1);
>>  core = kvmppc_pack_vcpu_id(kvm, id);
>>  }
>>  } else {
>>  core = id / kvm->arch.smt_mode;
>>  }
>> 
>> which means that the value being returned by the capability today for
>> a given guest is potentially way larger than what we actually support:
>> 
>> \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
>> 
>> If the capability is queried before userspace enables the
>> KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated
>> smt mode is already known we could provide a more accurate value.
>> 
>> The only practical effect of this change today is to make the
>> kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has
>> a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not
>> reached.
>> 
>> Signed-off-by: Fabiano Rosas 
>
> This patch won't apply after commit a1c42ddedf35 ("kvm: rename 
> KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS")
>
> Feel free to resubmit if still applicable.

Thanks for the reminder, Christophe.

I was focusing on enabling the rest of the kvm-selftests:
https://lore.kernel.org/r/20220120170109.948681-1-faro...@linux.ibm.com

I'm preparing a v2 for that series and will try to include these patches
as well.

[PATCH 14/14] powerpc/rtas: Consolidate and improve checking for rtas callers

2022-03-08 Thread Nicholas Piggin

Add range checking from the rtas syscall, and other error checks
and warnings to kernel callers, so problems can be found and
fixed.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index adf4892aeecd..7f8a3fd685f9 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -428,6 +428,23 @@ static int notrace va_raw_rtas_call(struct rtas_args 
*args, int token,
 {
int i;
 
+   if (!irqs_disabled()) {
+   WARN_ON_ONCE(1);
+   return -1;
+   }
+
+   if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE) {
+   WARN_ON_ONCE(1);
+   return -1;
+   }
+
+   if (nargs >= ARRAY_SIZE(args->args)
+   || nret > ARRAY_SIZE(args->args)
+   || nargs + nret > ARRAY_SIZE(args->args)) {
+   WARN_ON_ONCE(1);
+   return -1;
+   }
+
args->token = cpu_to_be32(token);
args->nargs = cpu_to_be32(nargs);
args->nret  = cpu_to_be32(nret);
@@ -476,9 +493,6 @@ int rtas_call(int token, int nargs, int nret, int *outputs, 
...)
char *buff_copy = NULL;
int ret;
 
-   if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
-   return -1;
-
if ((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)) {
WARN_ON_ONCE(1);
return -1;
@@ -955,9 +969,6 @@ int rtas_call_reentrant(int token, int nargs, int nret, int 
*outputs, ...)
unsigned long flags;
int ret;
 
-   if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
-   return -1;
-
local_irq_save(flags);
preempt_disable();
 
-- 
2.23.0

[PATCH 13/14] powerpc/rtas: enture rtas_call is called with MMU enabled

2022-03-08 Thread Nicholas Piggin

rtas_call must not be called with the MMU disabled because in case
of rtas error, log_error is called which requires MMU enabled. Add
a test and warning for this.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 1fc22138e3ab..adf4892aeecd 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -479,6 +479,11 @@ int rtas_call(int token, int nargs, int nret, int 
*outputs, ...)
if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
return -1;
 
+   if ((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)) {
+   WARN_ON_ONCE(1);
+   return -1;
+   }
+
s = lock_rtas();
 
/* We use the global rtas args buffer */
-- 
2.23.0

[PATCH 12/14] powerpc/rtas: Close theoretical memory leak

2022-03-08 Thread Nicholas Piggin

If buff_copy allocation failed then there was an error and the errbuf
allocation succeeded, it will not be logged or freed.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index e047793cbb80..1fc22138e3ab 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1239,9 +1239,10 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
 
unlock_rtas(flags);
 
-   if (buff_copy) {
-   if (errbuf)
-   log_error(errbuf, ERR_TYPE_RTAS_LOG, 0);
+   if (errbuf) {
+   log_error(errbuf, ERR_TYPE_RTAS_LOG, 0);
+   kfree(errbuf);
+   } else if (buff_copy) {
kfree(buff_copy);
}
 
-- 
2.23.0

[PATCH 11/14] powerpc/rtas: tidy __fetch_rtas_last_error

2022-03-08 Thread Nicholas Piggin

__fetch_rtas_last_error can use the same rtas_args as the caller used
for the failed rtas call. It can also use a higher-level helper to
assemble the rtas_args.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c | 30 +-
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 751a20669669..e047793cbb80 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -385,34 +385,22 @@ static int rtas_last_error_token;
  *  this routine must be called atomically with whatever produced
  *  the error (i.e. with rtas.lock still held from the previous call).
  */
-static char *__fetch_rtas_last_error(char *altbuf)
+static char *__fetch_rtas_last_error(struct rtas_args *args, char *altbuf)
 {
-   struct rtas_args err_args, save_args;
u32 bufsz;
char *buf = NULL;
+   int ret;
 
if (rtas_last_error_token == -1)
return NULL;
 
bufsz = rtas_get_error_log_max();
 
-   err_args.token = cpu_to_be32(rtas_last_error_token);
-   err_args.nargs = cpu_to_be32(2);
-   err_args.nret = cpu_to_be32(1);
-   err_args.args[0] = cpu_to_be32(__pa(rtas_err_buf));
-   err_args.args[1] = cpu_to_be32(bufsz);
-   err_args.args[2] = 0;
-
-   save_args = rtas.args;
-   rtas.args = err_args;
-
-   do_enter_rtas(__pa(&rtas.args));
-
-   err_args = rtas.args;
-   rtas.args = save_args;
+   ret = raw_rtas_call(args, rtas_last_error_token, 2, 1, NULL,
+   __pa(rtas_err_buf), bufsz);
 
/* Log the error in the unlikely case that there was one. */
-   if (unlikely(err_args.args[2] == 0)) {
+   if (unlikely(ret == 0)) {
if (altbuf) {
buf = altbuf;
} else {
@@ -430,8 +418,8 @@ static char *__fetch_rtas_last_error(char *altbuf)
 #define get_errorlog_buffer()  kmalloc(RTAS_ERROR_LOG_MAX, GFP_KERNEL)
 
 #else /* CONFIG_RTAS_ERROR_LOGGING */
-#define __fetch_rtas_last_error(x) NULL
-#define get_errorlog_buffer()  NULL
+#define __fetch_rtas_last_error(args, x)   NULL
+#define get_errorlog_buffer()  NULL
 #endif
 
 static int notrace va_raw_rtas_call(struct rtas_args *args, int token,
@@ -503,7 +491,7 @@ int rtas_call(int token, int nargs, int nret, int *outputs, 
...)
/* A -1 return code indicates that the last command couldn't
   be completed due to a hardware error. */
if (ret == -1)
-   buff_copy = __fetch_rtas_last_error(NULL);
+   buff_copy = __fetch_rtas_last_error(rtas_args, NULL);
 
unlock_rtas(s);
 
@@ -1247,7 +1235,7 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
/* A -1 return code indicates that the last command couldn't
   be completed due to a hardware error. */
if (be32_to_cpu(args.rets[0]) == -1)
-   errbuf = __fetch_rtas_last_error(buff_copy);
+   errbuf = __fetch_rtas_last_error(&rtas.args, buff_copy);
 
unlock_rtas(flags);
 
-- 
2.23.0

[PATCH 10/14] powerpc/rtas: replace rtas_call_unlocked with raw_rtas_call

2022-03-08 Thread Nicholas Piggin

Use the same calling and rets return convention with the raw rtas
call rather than requiring callers to load and byteswap return
values out of rtas_args.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/rtas.h  |  4 +-
 arch/powerpc/kernel/rtas.c   | 53 +++-
 arch/powerpc/platforms/pseries/hotplug-cpu.c |  2 +-
 arch/powerpc/platforms/pseries/ras.c |  7 +--
 arch/powerpc/xmon/xmon.c |  2 +-
 5 files changed, 33 insertions(+), 35 deletions(-)

diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 82e5b055fa2a..1014ff140cf8 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -241,8 +241,8 @@ extern int rtas_token(const char *service);
 extern int rtas_service_present(const char *service);
 extern int rtas_call(int token, int, int, int *, ...);
 int rtas_call_reentrant(int token, int nargs, int nret, int *outputs, ...);
-void rtas_call_unlocked(struct rtas_args *args, int token, int nargs,
-   int nret, ...);
+int raw_rtas_call(struct rtas_args *args, int token,
+   int nargs, int nret, int *outputs, ...);
 extern void __noreturn rtas_restart(char *cmd);
 extern void rtas_power_off(void);
 extern void __noreturn rtas_halt(void);
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index fece066115f0..751a20669669 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -123,7 +123,7 @@ static void call_rtas_display_status(unsigned char c)
return;
 
s = lock_rtas();
-   rtas_call_unlocked(&rtas.args, 10, 1, 1, NULL, c);
+   raw_rtas_call(&rtas.args, 10, 1, 1, NULL, c);
unlock_rtas(s);
 }
 
@@ -434,10 +434,9 @@ static char *__fetch_rtas_last_error(char *altbuf)
 #define get_errorlog_buffer()  NULL
 #endif
 
-
-static void
-va_rtas_call_unlocked(struct rtas_args *args, int token, int nargs, int nret,
- va_list list)
+static int notrace va_raw_rtas_call(struct rtas_args *args, int token,
+   int nargs, int nret, int *outputs,
+   va_list list)
 {
int i;
 
@@ -453,21 +452,37 @@ va_rtas_call_unlocked(struct rtas_args *args, int token, 
int nargs, int nret,
args->rets[i] = 0;
 
do_enter_rtas(__pa(args));
+
+   if (nret > 1 && outputs != NULL) {
+   for (i = 0; i < nret-1; ++i)
+   outputs[i] = be32_to_cpu(args->rets[i+1]);
+   }
+
+   return (nret > 0) ? be32_to_cpu(args->rets[0]) : 0;
 }
 
-void rtas_call_unlocked(struct rtas_args *args, int token, int nargs, int 
nret, ...)
+/*
+ * Like rtas_call but no kmalloc or printk etc in error handling, so
+ * error won't go through log_error. No tracing, may be called in real mode.
+ * rtas_args must be supplied, and appropriate synchronization for the rtas
+ * call being made has to be performed by the caller.
+ */
+int notrace raw_rtas_call(struct rtas_args *args, int token,
+   int nargs, int nret, int *outputs, ...)
 {
va_list list;
+   int ret;
 
-   va_start(list, nret);
-   va_rtas_call_unlocked(args, token, nargs, nret, list);
+   va_start(list, outputs);
+   ret = va_raw_rtas_call(args, token, nargs, nret, outputs, list);
va_end(list);
+
+   return ret;
 }
 
 int rtas_call(int token, int nargs, int nret, int *outputs, ...)
 {
va_list list;
-   int i;
unsigned long s;
struct rtas_args *rtas_args;
char *buff_copy = NULL;
@@ -482,19 +497,14 @@ int rtas_call(int token, int nargs, int nret, int 
*outputs, ...)
rtas_args = &rtas.args;
 
va_start(list, outputs);
-   va_rtas_call_unlocked(rtas_args, token, nargs, nret, list);
+   ret = va_raw_rtas_call(rtas_args, token, nargs, nret, outputs, list);
va_end(list);
 
/* A -1 return code indicates that the last command couldn't
   be completed due to a hardware error. */
-   if (be32_to_cpu(rtas_args->rets[0]) == -1)
+   if (ret == -1)
buff_copy = __fetch_rtas_last_error(NULL);
 
-   if (nret > 1 && outputs != NULL)
-   for (i = 0; i < nret-1; ++i)
-   outputs[i] = be32_to_cpu(rtas_args->rets[i+1]);
-   ret = (nret > 0)? be32_to_cpu(rtas_args->rets[0]): 0;
-
unlock_rtas(s);
 
if (buff_copy) {
@@ -950,7 +960,7 @@ int rtas_call_reentrant(int token, int nargs, int nret, int 
*outputs, ...)
va_list list;
struct rtas_args *args;
unsigned long flags;
-   int i, ret = 0;
+   int ret;
 
if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
return -1;
@@ -962,16 +972,9 @@ int rtas_call_reentrant(int token, int nargs, int nret, 
int *outputs, ...)
args = local_paca->rtas_args_reentrant;
 
va_start(list, outputs);
-   va_rtas_ca

[PATCH 09/14] powerpc/rtas: Leave MSR[RI] enabled over RTAS call

2022-03-08 Thread Nicholas Piggin

PAPR specifies that RTAS may be called with MSR[RI] enabled if the
calling context is recoverable, and RTAS will manage RI as necessary.
Call the rtas entry point with RI enabled, and add a check to ensure
the caller has RI enabled.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c   |  1 +
 arch/powerpc/kernel/rtas_entry.S | 13 +++--
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 87ede1877816..fece066115f0 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -57,6 +57,7 @@ static noinline void do_enter_rtas(unsigned long args)
hard_irq_disable();
 
msr = mfmsr();
+   BUG_ON(!(msr & MSR_RI));
mtmsr(msr & ~(MSR_IR|MSR_DR));
enter_rtas(args);
mtmsr(msr);
diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 292551684bbd..72b27b14ccc9 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -95,7 +95,7 @@ _GLOBAL(enter_rtas)
clrldi  r4,r4,2 /* convert to realmode address */
mtlrr4
 
-   LOAD_REG_IMMEDIATE(r6, MSR_ME)
+   LOAD_REG_IMMEDIATE(r6, MSR_ME|MSR_RI)
 
LOAD_REG_ADDR(r4, rtas)
ld  r5,RTASENTRY(r4)/* get the rtas->entry value */
@@ -113,15 +113,8 @@ _ASM_NOKPROBE_SYMBOL(enter_rtas)
 rtas_return_loc:
FIXUP_ENDIAN
 
-   /*
-* Clear RI and set SF before anything.
-*/
-   mfmsr   r6
-   li  r0,MSR_RI
-   andcr6,r6,r0
-   sldir0,r0,(MSR_SF_LG - MSR_RI_LG)
-   or  r6,r6,r0
-   sync
+   /* Set SF before anything. */
+   LOAD_REG_IMMEDIATE(r6, MSR_KERNEL & ~(MSR_IR|MSR_DR))
mtmsrd  r6
 
GET_PACA(r13)
-- 
2.23.0

[PATCH 08/14] powerpc/rtas: call enter_rtas in real-mode on 64-bit

2022-03-08 Thread Nicholas Piggin

This moves MSR save/restore and some real-mode juggling out of asm and
into C code, simplifying things.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c   | 15 ---
 arch/powerpc/kernel/rtas_entry.S | 32 +---
 2 files changed, 17 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 6b5892d6a56b..87ede1877816 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -47,13 +47,22 @@
 /* This is here deliberately so it's only used in this file */
 void enter_rtas(unsigned long);
 
-static inline void do_enter_rtas(unsigned long args)
+static noinline void do_enter_rtas(unsigned long args)
 {
BUG_ON(!irqs_disabled());
 
-   hard_irq_disable(); /* Ensure MSR[EE] is disabled on PPC64 */
+   if (IS_ENABLED(CONFIG_PPC64)) {
+   unsigned long msr;
 
-   enter_rtas(args);
+   hard_irq_disable();
+
+   msr = mfmsr();
+   mtmsr(msr & ~(MSR_IR|MSR_DR));
+   enter_rtas(args);
+   mtmsr(msr);
+   } else {
+   enter_rtas(args);
+   }
 
srr_regs_clobbered(); /* rtas uses SRRs, invalidate */
 }
diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 5f65ea4436c6..292551684bbd 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -84,14 +84,11 @@ _GLOBAL(enter_rtas)
li  r0,0
mtcrr0
 
-   mfmsr   r6
-
-   /* Unfortunately, the stack pointer and the MSR are also clobbered,
-* so they are saved in the PACA which allows us to restore
-* our original state after RTAS returns.
+   /*
+* The stack pointer is clobbered, so it is saved in the PACA which
+* allows us to restore our original state after RTAS returns.
 */
std r1,PACAR1(r13)
-   std r6,PACASAVEDMSR(r13)
 
/* Setup our real return addr */
LOAD_REG_ADDR(r4,rtas_return_loc)
@@ -100,7 +97,6 @@ _GLOBAL(enter_rtas)
 
LOAD_REG_IMMEDIATE(r6, MSR_ME)
 
-__enter_rtas:
LOAD_REG_ADDR(r4, rtas)
ld  r5,RTASENTRY(r4)/* get the rtas->entry value */
ld  r4,RTASBASE(r4) /* get the rtas->base value */
@@ -112,6 +108,7 @@ __enter_rtas:
mtspr   SPRN_SRR1,r6
RFI_TO_KERNEL
b   .   /* prevent speculative execution */
+_ASM_NOKPROBE_SYMBOL(enter_rtas)
 
 rtas_return_loc:
FIXUP_ENDIAN
@@ -127,29 +124,10 @@ rtas_return_loc:
sync
mtmsrd  r6
 
-   /* relocation is off at this point */
GET_PACA(r13)
 
-   bcl 20,31,$+4
-0: mflrr3
-   ld  r3,(1f-0b)(r3)  /* get &rtas_restore_regs */
-
ld  r1,PACAR1(r13)  /* Restore our SP */
-   ld  r4,PACASAVEDMSR(r13)/* Restore our MSR */
 
-   mtspr   SPRN_SRR0,r3
-   mtspr   SPRN_SRR1,r4
-   RFI_TO_KERNEL
-   b   .   /* prevent speculative execution */
-_ASM_NOKPROBE_SYMBOL(enter_rtas)
-_ASM_NOKPROBE_SYMBOL(__enter_rtas)
-_ASM_NOKPROBE_SYMBOL(rtas_return_loc)
-
-   .align  3
-1: .8byte  rtas_restore_regs
-
-rtas_restore_regs:
-   /* relocation is on at this point */
REST_GPR(2, r1) /* Restore the TOC */
REST_NVGPRS(r1) /* Restore the non-volatiles */
 
@@ -169,5 +147,5 @@ rtas_restore_regs:
 
mtlrr0
blr /* return to caller */
-
+_ASM_NOKPROBE_SYMBOL(rtas_return_loc)
 #endif /* CONFIG_PPC32 */
-- 
2.23.0

[PATCH 07/14] powerpc/rtas: PACA can be restored directly from SPRG

2022-03-08 Thread Nicholas Piggin

On 64-bit, PACA is saved in a SPRG so it does not need to be saved on
stack. We also don't need to mask off the top bits for real mode
addresses because the architecture does this for us.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas_entry.S | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 08eb731f08b8..5f65ea4436c6 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -62,10 +62,9 @@ _GLOBAL(enter_rtas)
 
/* Because RTAS is running in 32b mode, it clobbers the high order half
 * of all registers that it saves.  We therefore save those registers
-* RTAS might touch to the stack.  (r0, r3-r13 are caller saved)
+* RTAS might touch to the stack.  (r0, r3-r12 are caller saved)
 */
SAVE_GPR(2, r1) /* Save the TOC */
-   SAVE_GPR(13, r1)/* Save paca */
SAVE_NVGPRS(r1) /* Save the non-volatiles */
 
mfcrr4
@@ -129,15 +128,14 @@ rtas_return_loc:
mtmsrd  r6
 
/* relocation is off at this point */
-   GET_PACA(r4)
-   clrldi  r4,r4,2 /* convert to realmode address */
+   GET_PACA(r13)
 
bcl 20,31,$+4
 0: mflrr3
ld  r3,(1f-0b)(r3)  /* get &rtas_restore_regs */
 
-   ld  r1,PACAR1(r4)   /* Restore our SP */
-   ld  r4,PACASAVEDMSR(r4) /* Restore our MSR */
+   ld  r1,PACAR1(r13)  /* Restore our SP */
+   ld  r4,PACASAVEDMSR(r13)/* Restore our MSR */
 
mtspr   SPRN_SRR0,r3
mtspr   SPRN_SRR1,r4
@@ -153,11 +151,8 @@ _ASM_NOKPROBE_SYMBOL(rtas_return_loc)
 rtas_restore_regs:
/* relocation is on at this point */
REST_GPR(2, r1) /* Restore the TOC */
-   REST_GPR(13, r1)/* Restore paca */
REST_NVGPRS(r1) /* Restore the non-volatiles */
 
-   GET_PACA(r13)
-
ld  r4,_CCR(r1)
mtcrr4
ld  r5,_CTR(r1)
-- 
2.23.0

[PATCH 06/14] powerpc/rtas: Load rtas entry MSR explicitly

2022-03-08 Thread Nicholas Piggin

Rather than adjust the current MSR value to find the rtas entry
MSR on 64-bit, load the explicit value we want as 32-bit does.

This prevents some facilities (e.g., VEC and VSX) from being left
enabled which doesn't seem to cause a problem but it's more
consistent to always use the same MSR and minimise facilities
enabled.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas_entry.S | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 7b93687b9a10..08eb731f08b8 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -99,14 +99,7 @@ _GLOBAL(enter_rtas)
clrldi  r4,r4,2 /* convert to realmode address */
mtlrr4
 
-   li  r0,0
-   ori r0,r0,MSR_EE|MSR_SE|MSR_BE|MSR_RI
-   andcr0,r6,r0
-
-   li  r9,1
-   rldicr  r9,r9,MSR_SF_LG,(63-MSR_SF_LG)
-   ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI|MSR_LE
-   andcr6,r0,r9
+   LOAD_REG_IMMEDIATE(r6, MSR_ME)
 
 __enter_rtas:
LOAD_REG_ADDR(r4, rtas)
-- 
2.23.0

[PATCH 05/14] powerpc/rtas: Modernise RI clearing on 64-bit

2022-03-08 Thread Nicholas Piggin

mtmsrd L=1 can clear MSR[RI] without the previous MSR value; it does
not require sync; it can be moved later to before SRRs are live.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas_entry.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 45fa661c2ff6..7b93687b9a10 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -109,13 +109,13 @@ _GLOBAL(enter_rtas)
andcr6,r0,r9
 
 __enter_rtas:
-   sync/* disable RI so SRR0/1 */
-   mtmsrd  r0  /* don't get trashed */
-
LOAD_REG_ADDR(r4, rtas)
ld  r5,RTASENTRY(r4)/* get the rtas->entry value */
ld  r4,RTASBASE(r4) /* get the rtas->base value */
 
+   li  r0,0
+   mtmsrd  r0,1/* disable RI before using SRR0/1 */
+
mtspr   SPRN_SRR0,r5
mtspr   SPRN_SRR1,r6
RFI_TO_KERNEL
-- 
2.23.0

[PATCH 04/14] powerpc/rtas: Call enter_rtas with MSR[EE] disabled

2022-03-08 Thread Nicholas Piggin

Disable MSR[EE] in C code rather than asm.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas.c   |  4 
 arch/powerpc/kernel/rtas_entry.S | 17 +
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 733e6ef36758..6b5892d6a56b 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -49,6 +49,10 @@ void enter_rtas(unsigned long);
 
 static inline void do_enter_rtas(unsigned long args)
 {
+   BUG_ON(!irqs_disabled());
+
+   hard_irq_disable(); /* Ensure MSR[EE] is disabled on PPC64 */
+
enter_rtas(args);
 
srr_regs_clobbered(); /* rtas uses SRRs, invalidate */
diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 6fa10eb49a9c..45fa661c2ff6 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -24,8 +24,6 @@ _GLOBAL(enter_rtas)
lwz r4,RTASBASE(r4)
mfmsr   r9
stw r9,8(r1)
-   LOAD_REG_IMMEDIATE(r0,MSR_KERNEL)
-   mtmsr   r0  /* disable interrupts so SRR0/1 don't get trashed */
li  r9,MSR_KERNEL & ~(MSR_IR|MSR_DR)
mtlrr6
stw r1, THREAD + RTAS_SP(r2)
@@ -87,20 +85,7 @@ _GLOBAL(enter_rtas)
li  r0,0
mtcrr0
 
-#ifdef CONFIG_BUG
-   /* There is no way it is acceptable to get here with interrupts enabled,
-* check it with the asm equivalent of WARN_ON
-*/
-   lbz r0,PACAIRQSOFTMASK(r13)
-1: tdeqi   r0,IRQS_ENABLED
-   EMIT_WARN_ENTRY 1b,__FILE__,__LINE__,BUGFLAG_WARNING
-#endif
-
-   /* Hard-disable interrupts */
mfmsr   r6
-   rldicl  r7,r6,48,1
-   rotldi  r7,r7,16
-   mtmsrd  r7,1
 
/* Unfortunately, the stack pointer and the MSR are also clobbered,
 * so they are saved in the PACA which allows us to restore
@@ -124,7 +109,7 @@ _GLOBAL(enter_rtas)
andcr6,r0,r9
 
 __enter_rtas:
-   sync/* disable interrupts so SRR0/1 */
+   sync/* disable RI so SRR0/1 */
mtmsrd  r0  /* don't get trashed */
 
LOAD_REG_ADDR(r4, rtas)
-- 
2.23.0

[PATCH 03/14] powerpc/rtas: Fix whitespace in rtas_entry.S

2022-03-08 Thread Nicholas Piggin

The code was moved verbatim including whitespace cruft. Fix that.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas_entry.S | 34 
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index afe3b789bc36..6fa10eb49a9c 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -60,12 +60,12 @@ _ASM_NOKPROBE_SYMBOL(enter_rtas)
 _GLOBAL(enter_rtas)
mflrr0
std r0,16(r1)
-stdu   r1,-SWITCH_FRAME_SIZE(r1) /* Save SP and create stack space. */
+   stdur1,-SWITCH_FRAME_SIZE(r1) /* Save SP and create stack space. */
 
/* Because RTAS is running in 32b mode, it clobbers the high order half
 * of all registers that it saves.  We therefore save those registers
 * RTAS might touch to the stack.  (r0, r3-r13 are caller saved)
-*/
+*/
SAVE_GPR(2, r1) /* Save the TOC */
SAVE_GPR(13, r1)/* Save paca */
SAVE_NVGPRS(r1) /* Save the non-volatiles */
@@ -105,21 +105,21 @@ _GLOBAL(enter_rtas)
/* Unfortunately, the stack pointer and the MSR are also clobbered,
 * so they are saved in the PACA which allows us to restore
 * our original state after RTAS returns.
- */
+*/
std r1,PACAR1(r13)
-stdr6,PACASAVEDMSR(r13)
+   std r6,PACASAVEDMSR(r13)
 
-   /* Setup our real return addr */
+   /* Setup our real return addr */
LOAD_REG_ADDR(r4,rtas_return_loc)
clrldi  r4,r4,2 /* convert to realmode address */
-   mtlrr4
+   mtlrr4
 
li  r0,0
ori r0,r0,MSR_EE|MSR_SE|MSR_BE|MSR_RI
andcr0,r6,r0
-   
-li  r9,1
-rldicr  r9,r9,MSR_SF_LG,(63-MSR_SF_LG)
+
+   li  r9,1
+   rldicr  r9,r9,MSR_SF_LG,(63-MSR_SF_LG)
ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI|MSR_LE
andcr6,r0,r9
 
@@ -130,7 +130,7 @@ __enter_rtas:
LOAD_REG_ADDR(r4, rtas)
ld  r5,RTASENTRY(r4)/* get the rtas->entry value */
ld  r4,RTASBASE(r4) /* get the rtas->base value */
-   
+
mtspr   SPRN_SRR0,r5
mtspr   SPRN_SRR1,r6
RFI_TO_KERNEL
@@ -142,13 +142,13 @@ rtas_return_loc:
/*
 * Clear RI and set SF before anything.
 */
-   mfmsr   r6
+   mfmsr   r6
li  r0,MSR_RI
andcr6,r6,r0
sldir0,r0,(MSR_SF_LG - MSR_RI_LG)
or  r6,r6,r0
sync
-   mtmsrd  r6
+   mtmsrd  r6
 
/* relocation is off at this point */
GET_PACA(r4)
@@ -158,8 +158,8 @@ rtas_return_loc:
 0: mflrr3
ld  r3,(1f-0b)(r3)  /* get &rtas_restore_regs */
 
-ld r1,PACAR1(r4)   /* Restore our SP */
-ld r4,PACASAVEDMSR(r4) /* Restore our MSR */
+   ld  r1,PACAR1(r4)   /* Restore our SP */
+   ld  r4,PACASAVEDMSR(r4) /* Restore our MSR */
 
mtspr   SPRN_SRR0,r3
mtspr   SPRN_SRR1,r4
@@ -191,10 +191,10 @@ rtas_restore_regs:
ld  r8,_DSISR(r1)
mtdsisr r8
 
-addi   r1,r1,SWITCH_FRAME_SIZE /* Unstack our frame */
+   addir1,r1,SWITCH_FRAME_SIZE /* Unstack our frame */
ld  r0,16(r1)   /* get return address */
 
-   mtlrr0
-blr/* return to caller */
+   mtlrr0
+   blr /* return to caller */
 
 #endif /* CONFIG_PPC32 */
-- 
2.23.0

[PATCH 02/14] powerpc/rtas: Make enter_rtas a nokprobe symbol on 64-bit

2022-03-08 Thread Nicholas Piggin

This symbol is marked nokprobe on 32-bit but not 64-bit, add it.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/rtas_entry.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/rtas_entry.S b/arch/powerpc/kernel/rtas_entry.S
index 192fea342744..afe3b789bc36 100644
--- a/arch/powerpc/kernel/rtas_entry.S
+++ b/arch/powerpc/kernel/rtas_entry.S
@@ -165,6 +165,7 @@ rtas_return_loc:
mtspr   SPRN_SRR1,r4
RFI_TO_KERNEL
b   .   /* prevent speculative execution */
+_ASM_NOKPROBE_SYMBOL(enter_rtas)
 _ASM_NOKPROBE_SYMBOL(__enter_rtas)
 _ASM_NOKPROBE_SYMBOL(rtas_return_loc)
 
-- 
2.23.0

[PATCH 00/14] powerpc/rtas: various cleanups and improvements

2022-03-08 Thread Nicholas Piggin

I had a bunch of random little fixes and cleanups around and
was prompted to put them together and make a change to call
RTAS with MSR[RI] enabled because of a report of the hard
lockup watchdog NMI IPI hitting in an rtas call which then
crashed because it's unrecoverable.

Could possibly move patch 9 earlier if it would help with
backporting.

Thanks,
Nick

Nicholas Piggin (14):
  powerpc/rtas: Move rtas entry assembly into its own file
  powerpc/rtas: Make enter_rtas a nokprobe symbol on 64-bit
  powerpc/rtas: Fix whitespace in rtas_entry.S
  powerpc/rtas: Call enter_rtas with MSR[EE] disabled
  powerpc/rtas: Modernise RI clearing on 64-bit
  powerpc/rtas: Load rtas entry MSR explicitly
  powerpc/rtas: PACA can be restored directly from SPRG
  powerpc/rtas: call enter_rtas in real-mode on 64-bit
  powerpc/rtas: Leave MSR[RI] enabled over RTAS call
  powerpc/rtas: replace rtas_call_unlocked with raw_rtas_call
  powerpc/rtas: tidy __fetch_rtas_last_error
  powerpc/rtas: Close theoretical memory leak
  powerpc/rtas: enture rtas_call is called with MMU enabled
  powerpc/rtas: Consolidate and improve checking for rtas callers

 arch/powerpc/include/asm/rtas.h  |   4 +-
 arch/powerpc/kernel/Makefile |   2 +-
 arch/powerpc/kernel/entry_32.S   |  49 --
 arch/powerpc/kernel/entry_64.S   | 150 ---
 arch/powerpc/kernel/rtas.c   | 132 +---
 arch/powerpc/kernel/rtas_entry.S | 144 ++
 arch/powerpc/platforms/pseries/hotplug-cpu.c |   2 +-
 arch/powerpc/platforms/pseries/ras.c |   7 +-
 arch/powerpc/xmon/xmon.c |   2 +-
 9 files changed, 227 insertions(+), 265 deletions(-)
 create mode 100644 arch/powerpc/kernel/rtas_entry.S

-- 
2.23.0

[PATCH 01/14] powerpc/rtas: Move rtas entry assembly into its own file

2022-03-08 Thread Nicholas Piggin

This makes working on the code a bit easier.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/Makefile |   2 +-
 arch/powerpc/kernel/entry_32.S   |  49 
 arch/powerpc/kernel/entry_64.S   | 150 ---
 arch/powerpc/kernel/rtas_entry.S | 199 +++
 4 files changed, 200 insertions(+), 200 deletions(-)
 create mode 100644 arch/powerpc/kernel/rtas_entry.S

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 4d7829399570..13602b0f0472 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -68,7 +68,7 @@ obj-$(CONFIG_PPC_BOOK3S_IDLE) += idle_book3s.o
 procfs-y   := proc_powerpc.o
 obj-$(CONFIG_PROC_FS)  += $(procfs-y)
 rtaspci-$(CONFIG_PPC64)-$(CONFIG_PCI)  := rtas_pci.o
-obj-$(CONFIG_PPC_RTAS) += rtas.o rtas-rtc.o $(rtaspci-y-y)
+obj-$(CONFIG_PPC_RTAS) += rtas_entry.o rtas.o rtas-rtc.o $(rtaspci-y-y)
 obj-$(CONFIG_PPC_RTAS_DAEMON)  += rtasd.o
 obj-$(CONFIG_RTAS_FLASH)   += rtas_flash.o
 obj-$(CONFIG_RTAS_PROC)+= rtas-proc.o
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 7748c278d13c..1d599df6f169 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -555,52 +555,3 @@ ret_from_mcheck_exc:
 _ASM_NOKPROBE_SYMBOL(ret_from_mcheck_exc)
 #endif /* CONFIG_BOOKE */
 #endif /* !(CONFIG_4xx || CONFIG_BOOKE) */
-
-/*
- * PROM code for specific machines follows.  Put it
- * here so it's easy to add arch-specific sections later.
- * -- Cort
- */
-#ifdef CONFIG_PPC_RTAS
-/*
- * On CHRP, the Run-Time Abstraction Services (RTAS) have to be
- * called with the MMU off.
- */
-_GLOBAL(enter_rtas)
-   stwur1,-INT_FRAME_SIZE(r1)
-   mflrr0
-   stw r0,INT_FRAME_SIZE+4(r1)
-   LOAD_REG_ADDR(r4, rtas)
-   lis r6,1f@ha/* physical return address for rtas */
-   addir6,r6,1f@l
-   tophys(r6,r6)
-   lwz r8,RTASENTRY(r4)
-   lwz r4,RTASBASE(r4)
-   mfmsr   r9
-   stw r9,8(r1)
-   LOAD_REG_IMMEDIATE(r0,MSR_KERNEL)
-   mtmsr   r0  /* disable interrupts so SRR0/1 don't get trashed */
-   li  r9,MSR_KERNEL & ~(MSR_IR|MSR_DR)
-   mtlrr6
-   stw r1, THREAD + RTAS_SP(r2)
-   mtspr   SPRN_SRR0,r8
-   mtspr   SPRN_SRR1,r9
-   rfi
-1:
-   lis r8, 1f@h
-   ori r8, r8, 1f@l
-   LOAD_REG_IMMEDIATE(r9,MSR_KERNEL)
-   mtspr   SPRN_SRR0,r8
-   mtspr   SPRN_SRR1,r9
-   rfi /* Reactivate MMU translation */
-1:
-   lwz r8,INT_FRAME_SIZE+4(r1) /* get return address */
-   lwz r9,8(r1)/* original msr value */
-   addir1,r1,INT_FRAME_SIZE
-   li  r0,0
-   stw r0, THREAD + RTAS_SP(r2)
-   mtlrr8
-   mtmsr   r9
-   blr /* return to caller */
-_ASM_NOKPROBE_SYMBOL(enter_rtas)
-#endif /* CONFIG_PPC_RTAS */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9581906b5ee9..01ace4c56104 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -264,156 +264,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
addir1,r1,SWITCH_FRAME_SIZE
blr
 
-#ifdef CONFIG_PPC_RTAS
-/*
- * On CHRP, the Run-Time Abstraction Services (RTAS) have to be
- * called with the MMU off.
- *
- * In addition, we need to be in 32b mode, at least for now.
- * 
- * Note: r3 is an input parameter to rtas, so don't trash it...
- */
-_GLOBAL(enter_rtas)
-   mflrr0
-   std r0,16(r1)
-stdu   r1,-SWITCH_FRAME_SIZE(r1) /* Save SP and create stack space. */
-
-   /* Because RTAS is running in 32b mode, it clobbers the high order half
-* of all registers that it saves.  We therefore save those registers
-* RTAS might touch to the stack.  (r0, r3-r13 are caller saved)
-*/
-   SAVE_GPR(2, r1) /* Save the TOC */
-   SAVE_GPR(13, r1)/* Save paca */
-   SAVE_NVGPRS(r1) /* Save the non-volatiles */
-
-   mfcrr4
-   std r4,_CCR(r1)
-   mfctr   r5
-   std r5,_CTR(r1)
-   mfspr   r6,SPRN_XER
-   std r6,_XER(r1)
-   mfdar   r7
-   std r7,_DAR(r1)
-   mfdsisr r8
-   std r8,_DSISR(r1)
-
-   /* Temporary workaround to clear CR until RTAS can be modified to
-* ignore all bits.
-*/
-   li  r0,0
-   mtcrr0
-
-#ifdef CONFIG_BUG
-   /* There is no way it is acceptable to get here with interrupts enabled,
-* check it with the asm equivalent of WARN_ON
-*/
-   lbz r0,PACAIRQSOFTMASK(r13)
-1: tdeqi   r0,IRQS_ENABLED
-   EMIT_WARN_ENTRY 1b,__FILE__,__LINE__,BUGFLAG_WARNING
-#endif
-
-   /* Hard-disable interrupts */
-   mfmsr   r6
-   rldicl  r7,r6,48,1
-   rotldi  r7,r7,16
-   mtmsrd  r7,1
-
-

Re: [RFC PATCH 2/2] KVM: PPC: Book3S HV: Provide a more accurate MAX_VCPU_ID in P9

2022-03-08 Thread Christophe Leroy





Le 13/04/2021 à 00:26, Fabiano Rosas a écrit :

The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6
("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than
KVM_MAX_VCPU in powerpc.

For a P9 host we depend on the guest VSMT value to know what is the
maximum number of vcpu id we can support:

kvmppc_core_vcpu_create_hv:
 (...)
 if (cpu_has_feature(CPU_FTR_ARCH_300)) {
--> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
 pr_devel("KVM: VCPU ID too high\n");
 core = KVM_MAX_VCORES;
 } else {
 BUG_ON(kvm->arch.smt_mode != 1);
 core = kvmppc_pack_vcpu_id(kvm, id);
 }
 } else {
 core = id / kvm->arch.smt_mode;
 }

which means that the value being returned by the capability today for
a given guest is potentially way larger than what we actually support:

\#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)

If the capability is queried before userspace enables the
KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated
smt mode is already known we could provide a more accurate value.

The only practical effect of this change today is to make the
kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has
a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not
reached.

Signed-off-by: Fabiano Rosas 


This patch won't apply after commit a1c42ddedf35 ("kvm: rename 
KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS")


Feel free to resubmit if still applicable.

Christsophe




---
I see that for ppc, QEMU uses the capability after enabling
KVM_CAP_PPC_SMT, so we could change QEMU to issue the check extension
on the vm fd so that it would get the more accurate value.
---
  arch/powerpc/kvm/powerpc.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a2a68a958fa0..95c9f47cc1b3 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -649,7 +649,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
-   r = KVM_MAX_VCPU_ID;
+   if (hv_enabled && cpu_has_feature(CPU_FTR_ARCH_300))
+   r = KVM_MAX_VCPUS * ((kvm) ? kvm->arch.emul_smt_mode : 
1);
+   else
+   r = KVM_MAX_VCPU_ID;
break;
  #ifdef CONFIG_PPC_BOOK3S_64
case KVM_CAP_PPC_GET_SMMU_INFO:

[powerpc:next-test] BUILD REGRESSION 0a448e06d10e149bf5ed23202d49246b6c4cf77b

2022-03-08 Thread kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
branch HEAD: 0a448e06d10e149bf5ed23202d49246b6c4cf77b  powerpc/64e: Tie 
PPC_BOOK3E_64 to PPC_FSL_BOOK3E

Error/Warning reports:

https://lore.kernel.org/lkml/202203081701.3ljh6dgc-...@intel.com
https://lore.kernel.org/lkml/202203081921.spuknaaj-...@intel.com

Error/Warning:

arch/powerpc/kernel/prom_init.c:3302:22: error: no previous prototype for 
'prom_init' [-Werror=missing-prototypes]
arch/powerpc/kernel/prom_init.c:3302:22: warning: no previous prototype for 
'prom_init' [-Wmissing-prototypes]

Unverified Error/Warning (likely false positive, please contact us if 
interested):

clang-15: error: linker command failed with exit code 1 (use -v to see 
invocation)

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- powerpc-allmodconfig
|   `-- 
arch-powerpc-kernel-prom_init.c:warning:no-previous-prototype-for-prom_init
|-- powerpc-allyesconfig
|   `-- 
arch-powerpc-kernel-prom_init.c:warning:no-previous-prototype-for-prom_init
|-- powerpc-mpc834x_itx_defconfig
|   `-- 
arch-powerpc-kernel-prom_init.c:error:no-previous-prototype-for-prom_init
|-- powerpc-randconfig-r014-20220308
|   `-- 
arch-powerpc-kernel-prom_init.c:warning:no-previous-prototype-for-prom_init
|-- powerpc-randconfig-r023-20220308
|   `-- 
arch-powerpc-kernel-prom_init.c:warning:no-previous-prototype-for-prom_init
|-- powerpc64-defconfig
|   `-- 
arch-powerpc-kernel-prom_init.c:error:no-previous-prototype-for-prom_init
`-- powerpc64-randconfig-s031-20220307
`-- 
arch-powerpc-kernel-prom_init.c:error:no-previous-prototype-for-prom_init

clang_recent_errors
|-- powerpc-pseries_defconfig
|   `-- 
clang:error:linker-command-failed-with-exit-code-(use-v-to-see-invocation)
|-- powerpc-randconfig-c003-20220308
|   `-- 
clang:error:linker-command-failed-with-exit-code-(use-v-to-see-invocation)
|-- powerpc-randconfig-r033-20220308
|   `-- 
clang:error:linker-command-failed-with-exit-code-(use-v-to-see-invocation)
`-- powerpc64-allmodconfig
`-- 
clang:error:linker-command-failed-with-exit-code-(use-v-to-see-invocation)

elapsed time: 1364m

configs tested: 200
configs skipped: 10

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
i386  randconfig-c001
i386 randconfig-c001-20220307
alphaalldefconfig
arm  footbridge_defconfig
m68k   sun3_defconfig
sh   se7722_defconfig
sh  urquell_defconfig
powerpc  ep88xc_defconfig
arm nhk8815_defconfig
powerpc asp8347_defconfig
armrealview_defconfig
sh   se7780_defconfig
mips   ip32_defconfig
sh  landisk_defconfig
nios2   defconfig
m68k  sun3x_defconfig
arm assabet_defconfig
mips   bmips_be_defconfig
m68km5307c3_defconfig
mips loongson1b_defconfig
powerpc64   defconfig
xtensa  cadence_csp_defconfig
arm  pxa3xx_defconfig
arm   sama5_defconfig
archsdk_defconfig
x86_64   alldefconfig
m68k   m5208evb_defconfig
shapsh4ad0a_defconfig
sh   sh2007_defconfig
m68k  multi_defconfig
shsh7763rdp_defconfig
s390defconfig
mips decstation_defconfig
ia64  tiger_defconfig
x86_64  defconfig
sparc   sparc32_defconfig
arm rpc_defconfig
arc   tb10x_defconfig
parisc64 alldefconfig
sh   se7750_defconfig
sh sh03_defconfig
sh  r7785rp_defconfig
nios2 3c120_defconfig
powerpc ep8248e_defconfig
powerpcwarp_defconfig
arm  jornada720_defconfig
sh  sdk7780_defconfig
um  defconfig
shhp6xx_defconfig
arm   viper_defconfig
armzeus_defconfig
powerpc   currituck_defconfig
powerpc  ppc40x_defconfig
xtensa   alldefconfig
microblaze

Re: [PATCH 1/1] powerpc/ps3: Remove a couple of unneeded semicolons

2022-03-08 Thread Christophe Leroy





Le 08/05/2021 à 11:51, Zhen Lei a écrit :

The semicolon immediately following '}' is unneeded.

Signed-off-by: Zhen Lei 


A more recent version of your patch are available at 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/01647102607ce9640c9f27786d976109a3c4ea7e.1629197153.git.jing.yangy...@zte.com.cn/




---
  arch/powerpc/platforms/ps3/system-bus.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/ps3/system-bus.c 
b/arch/powerpc/platforms/ps3/system-bus.c
index b431f41c6cb53ab..5c739267ddd2174 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -603,7 +603,7 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, 
struct page *page,
default:
/* not happned */
BUG();
-   };
+   }
result = ps3_dma_map(dev->d_region, (unsigned long)ptr, size,
 &bus_addr, iopte_flag);
  
@@ -762,7 +762,7 @@ int ps3_system_bus_device_register(struct ps3_system_bus_device *dev)

break;
default:
BUG();
-   };
+   }
  
  	dev->core.of_node = NULL;

set_dev_node(&dev->core, 0);

Re: [PATCH v9 0/2] Interface to represent PAPR firmware attributes

2022-03-08 Thread Michael Ellerman

On Thu, 17 Feb 2022 16:23:19 +0530, Pratik R. Sampat wrote:
> RFC: https://lkml.org/lkml/2021/6/4/791
> PATCH v1: https://lkml.org/lkml/2021/6/16/805
> PATCH v2: https://lkml.org/lkml/2021/7/6/138
> PATCH v3: https://lkml.org/lkml/2021/7/12/2799
> PATCH v4: https://lkml.org/lkml/2021/7/16/532
> PATCH v5: https://lkml.org/lkml/2021/7/19/247
> PATCH v6: https://lkml.org/lkml/2021/7/20/36
> PATCH v7: https://lkml.org/lkml/2021/7/23/26
> PATCH v8: https://lkml.org/lkml/2021/9/28/554
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/pseries: Interface to represent PAPR firmware attributes
  https://git.kernel.org/powerpc/c/3c14b73454cf9f6e2146443fdfbdfb912c0efed3
[2/2] selftest/powerpc: Add PAPR sysfs attributes sniff test
  https://git.kernel.org/powerpc/c/57201d657eb76d735298405d3200a3b1f67197e1

cheers

Re: [PATCH powerpc/next 00/17] powerpc/bpf: Some updates and cleanups

2022-03-08 Thread Michael Ellerman

On Mon, 14 Feb 2022 16:11:34 +0530, Naveen N. Rao wrote:
> This is a follow-up series with the pending patches from:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=279602&state=*
> 
> Patches 1-5 and 8 are unchanged. Patch 6 is new and patch 7 has changes
> based on discussion from the last series. Patch 9 has a small change to
> not skip the toc load for elf v2.
> 
> [...]

Applied to powerpc/next.

[01/17] powerpc/bpf: Skip branch range validation during first pass

https://git.kernel.org/powerpc/c/acd7408d2748533d767387cb4308692fba543658
[02/17] powerpc/bpf: Emit a single branch instruction for known short branch 
ranges

https://git.kernel.org/powerpc/c/bafb5898de5d2f15133774cb049fe55720b9c92f
[03/17] powerpc/bpf: Handle large branch ranges with BPF_EXIT

https://git.kernel.org/powerpc/c/0ffdbce6f4a89bb7c0002904d6438ec83cf05ce7
[04/17] powerpc64/bpf: Do not save/restore LR on each call to bpf_stf_barrier()

https://git.kernel.org/powerpc/c/c2067f7f88830cdd020c775ffefe84a8177337af
[05/17] powerpc64/bpf: Use r12 for constant blinding

https://git.kernel.org/powerpc/c/1d4866d5652f7a19dcbed0c4e366c3402c7775b7
[06/17] powerpc64: Set PPC64_ELF_ABI_v[1|2] macros to 1

https://git.kernel.org/powerpc/c/4eeac2b0aaadc3d1943d348d8565f7cfb93272b9
[07/17] powerpc64/bpf elfv2: Setup kernel TOC in r2 on entry

https://git.kernel.org/powerpc/c/b10cb163c4b31b03ac5014abbfd0b868913fd8e3
[08/17] powerpc64/bpf elfv1: Do not load TOC before calling functions

https://git.kernel.org/powerpc/c/43d636f8b4fd2ee668e75e835fae2fcf4bc0f699
[09/17] powerpc64/bpf: Optimize instruction sequence used for function calls

https://git.kernel.org/powerpc/c/feb6307289d85262c5aed04d6f192d38abba7c45
[10/17] powerpc/bpf: Rename PPC_BL_ABS() to PPC_BL()

https://git.kernel.org/powerpc/c/74bbe3f08463c48a27088be4823a5803b7f7d9a1
[11/17] powerpc64/bpf: Convert some of the uses of PPC_BPF_[LL|STL] to 
PPC_BPF_[LD|STD]

https://git.kernel.org/powerpc/c/391c271f4deb7356482d12f962a6fc018b6a3fb0
[12/17] powerpc64/bpf: Get rid of PPC_BPF_[LL|STL|STLU] macros

https://git.kernel.org/powerpc/c/794abc08d75e9f2833f493090af14b748e182c5f
[13/17] powerpc/bpf: Cleanup bpf_jit.h

https://git.kernel.org/powerpc/c/7b187dcdb5d348aa916dcda769313512c08e85a5
[14/17] powerpc/bpf: Move bpf_jit64.h into bpf_jit_comp64.c

https://git.kernel.org/powerpc/c/576a6c3a00c1a2a3645e039b126b52f6c7755e54
[15/17] powerpc/bpf: Use _Rn macros for GPRs

https://git.kernel.org/powerpc/c/036d559c0bdea75bf4840ba6780790d08572480c
[16/17] powerpc64/bpf: Store temp registers' bpf to ppc mapping

https://git.kernel.org/powerpc/c/3a3fc9bf103974d9a886fa37087d5d491c806e00
[17/17] powerpc/bpf: Simplify bpf_to_ppc() and adopt it for powerpc64

https://git.kernel.org/powerpc/c/49c3af43e65fbcc13860e0cf5fb2507b13e9724c

cheers

Re: [PATCH] powerpc/64s: Don't use DSISR for SLB faults

2022-03-08 Thread Michael Ellerman

On Tue, 22 Feb 2022 22:34:49 +1100, Michael Ellerman wrote:
> Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data
> is read or write.") we use page_fault_is_write(regs->dsisr) in
> __bad_page_fault() to determine if the fault is for a read or write, and
> change the message printed accordingly.
> 
> But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data
> Storage Interrupt Status Register) to a useful value. All ISA versions
> from v2.03 through v3.1 specify that the Data Segment Interrupt sets
> DSISR "to an undefined value". As far as I can see there's no mention of
> SLB faults setting DSISR in any BookIV content either.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64s: Don't use DSISR for SLB faults
  https://git.kernel.org/powerpc/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a

cheers

Re: [PATCH] powerpc/code-patching: Pre-map patch area

2022-03-08 Thread Michael Ellerman

On Wed, 23 Feb 2022 12:58:21 +1100, Michael Ellerman wrote:
> Paul reported a warning with DEBUG_ATOMIC_SLEEP=y:
> 
>   BUG: sleeping function called from invalid context at 
> include/linux/sched/mm.h:256
>   in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
>   preempt_count: 0, expected: 0
>   ...
>   Call Trace:
> dump_stack_lvl+0xa0/0xec (unreliable)
> __might_resched+0x2f4/0x310
> kmem_cache_alloc+0x220/0x4b0
> __pud_alloc+0x74/0x1d0
> hash__map_kernel_page+0x2cc/0x390
> do_patch_instruction+0x134/0x4a0
> arch_jump_label_transform+0x64/0x78
> __jump_label_update+0x148/0x180
> static_key_enable_cpuslocked+0xd0/0x120
> static_key_enable+0x30/0x50
> check_kvm_guest+0x60/0x88
> pSeries_smp_probe+0x54/0xb0
> smp_prepare_cpus+0x3e0/0x430
> kernel_init_freeable+0x20c/0x43c
> kernel_init+0x30/0x1a0
> ret_from_kernel_thread+0x5c/0x64
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/code-patching: Pre-map patch area
  https://git.kernel.org/powerpc/c/591b4b268435f00d2f0b81f786c2c7bd5ef66416

cheers

Re: [PATCH] arch:powerpc:kvm: remove unnecessary type castings

2022-03-08 Thread Michael Ellerman

On Thu, 3 Mar 2022 15:34:16 +0100, Nour-eddine Taleb wrote:
> remove unnecessary castings, from "void *" to "struct kvmppc_xics *"
> 
> 

Applied to powerpc/next.

[1/1] arch:powerpc:kvm: remove unnecessary type castings
  https://git.kernel.org/powerpc/c/e40b38a41ce916d6a3a4751d59a01b6c0c03afd0

cheers

Re: [PATCH] powerpc/sysdev: fix incorrect use to determine if list is empty

2022-03-08 Thread Michael Ellerman

On Mon, 28 Feb 2022 15:24:33 +0100, Jakob Koschel wrote:
> 'gtm' will *always* be set by list_for_each_entry().
> It is incorrect to assume that the iterator value will be NULL if the
> list is empty.
> 
> Instead of checking the pointer it should be checked if
> the list is empty.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/sysdev: fix incorrect use to determine if list is empty
  https://git.kernel.org/powerpc/c/fa1321b11bd01752f5be2415e74a0e1a7c378262

cheers

Re: [PATCH v6 0/9] powerpc/pseries/vas: NXGZIP support with DLPAR

2022-03-08 Thread Michael Ellerman

On Mon, 28 Feb 2022 17:09:57 -0800, Haren Myneni wrote:
> PowerPC provides HW compression with NX coprocessor. This feature
> is available on both PowerNV and PowerVM and included in Linux.
> Since each powerpc chip has one NX coprocessor, the VAS introduces
> the concept of windows / credits to manage access to this hardware
> resource. On powerVM, these limited resources should be available
> across all LPARs. So the hypervisor assigns the specific credits
> to each LPAR based on processor entitlement so that one LPAR does
> not overload NX. The hypervisor can reject the window open request
> to a partition if exceeds its credit limit (1 credit per window).
> 
> [...]

Applied to powerpc/next.

[1/9] powerpc/pseries/vas: Use common names in VAS capability structure
  https://git.kernel.org/powerpc/c/40562fe4fa3d94c7462ec909ab89b075e26c59ac
[2/9] powerpc/pseries/vas: Save PID in pseries_vas_window struct
  https://git.kernel.org/powerpc/c/976410cd2cb4c6ed53bd12c192fc46bbcc0fbce7
[3/9] powerpc/vas: Add paste address mmap fault handler
  https://git.kernel.org/powerpc/c/1fe3a33ba0a37e7aa0df0acbe31d5dda7610c16e
[4/9] powerpc/vas: Return paste instruction failure if no active window
  https://git.kernel.org/powerpc/c/b5c63d90cc2de8ac6724fec84d1d72cfebcae41d
[5/9] powerpc/vas: Map paste address only if window is active
  https://git.kernel.org/powerpc/c/6a8d4ca891aa5f9402973eab5d7d9cf3929678b7
[6/9] powerpc/pseries/vas: Close windows with DLPAR core removal
  https://git.kernel.org/powerpc/c/8ef7b9e1765a52c8023d9133a2438ac9f6da486a
[7/9] powerpc/pseries/vas: Reopen windows with DLPAR core add
  https://git.kernel.org/powerpc/c/c656cfe571a9b8b882e31177f554bd79141fc015
[8/9] powerpc/pseries/vas: sysfs interface to export capabilities
  https://git.kernel.org/powerpc/c/b903737bc522e0ef3f45a2a60c364ff547572c9b
[9/9] powerpc/pseries/vas: Add 'update_total_credits' entry for QoS capabilities
  https://git.kernel.org/powerpc/c/45f06eac30e5abebecc66e41e7c89d5b4413bac1

cheers

Re: [PATCH v5] powerpc/mce: Avoid using irq_work_queue() in realmode

2022-03-08 Thread Michael Ellerman

On Thu, 20 Jan 2022 17:49:31 +0530, Ganesh Goudar wrote:
> In realmode mce handler we use irq_work_queue() to defer
> the processing of mce events, irq_work_queue() can only
> be called when translation is enabled because it touches
> memory outside RMA, hence we enable translation before
> calling irq_work_queue and disable on return, though it
> is not safe to do in realmode.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/mce: Avoid using irq_work_queue() in realmode
  https://git.kernel.org/powerpc/c/cc15ff3275694fedc33cd3d53212a43eec7aa0bc

cheers

Re: [PATCH v3 RESEND 1/3] powerpc/pseries: Parse control memory access error

2022-03-08 Thread Michael Ellerman

On Fri, 7 Jan 2022 19:44:26 +0530, Ganesh Goudar wrote:
> Add support to parse and log control memory access
> error for pseries. These changes are made according to
> PAPR v2.11 10.3.2.2.12.
> 
> 

Applied to powerpc/next.

[1/3] powerpc/pseries: Parse control memory access error
  https://git.kernel.org/powerpc/c/0f54bddefe7f5e4c98bea6f945ebdf85d1c44117
[2/3] selftests/powerpc: Add test for real address error handling
  https://git.kernel.org/powerpc/c/0f4ef8a3bf784f250abc7d0155ae4e9fa22d8210
[3/3] powerpc/mce: Modify the real address error logging messages
  https://git.kernel.org/powerpc/c/0a182611d149b5b747014fbb230ec35b20a45c86

cheers

Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4

2022-03-08 Thread Michael Ellerman

On Tue, 15 Feb 2022 13:40:55 +0100, Christophe Leroy wrote:
> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
> on those three architectures because LKDTM messes up function
> descriptors with functions.
> 
> This series does some cleanup in the three architectures and
> refactors function descriptors so that it can then easily use it
> in a generic way in LKDTM.
> 
> [...]

Applied to powerpc/next.

[01/13] powerpc: Fix 'sparse' checking on PPC64le

https://git.kernel.org/powerpc/c/81df21de8fb45d3a55d41da9c7f5724797d51ce6
[02/13] powerpc: Move and rename func_descr_t

https://git.kernel.org/powerpc/c/5b23cb8cc6b0aab0535253cc2aa362572bab7072
[03/13] powerpc: Use 'struct func_desc' instead of 'struct ppc64_opd_entry'

https://git.kernel.org/powerpc/c/d3e32b997a4ca2e7be71cb770bcb2c000ee20b36
[04/13] powerpc: Remove 'struct ppc64_opd_entry'

https://git.kernel.org/powerpc/c/0a9c5ae279c963149df9a84588281d3d607f7a1f
[05/13] powerpc: Prepare func_desc_t for refactorisation

https://git.kernel.org/powerpc/c/2fd986377d546bedaf27e36554dc9090d272f15d
[06/13] ia64: Rename 'ip' to 'addr' in 'struct fdesc'

https://git.kernel.org/powerpc/c/41a88b45479da873bfc5d29ba1a545a780c5329a
[07/13] asm-generic: Define CONFIG_HAVE_FUNCTION_DESCRIPTORS

https://git.kernel.org/powerpc/c/a257cacc38718c83cee003487e03197f237f5c3f
[08/13] asm-generic: Define 'func_desc_t' to commonly describe function 
descriptors

https://git.kernel.org/powerpc/c/0dc690e4ef5b901e9d4b53520854fbd5c749e09d
[09/13] asm-generic: Refactor dereference_[kernel]_function_descriptor()

https://git.kernel.org/powerpc/c/e1478d8eaf27704db17a44dee4c53696ed01fc9c
[10/13] lkdtm: Force do_nothing() out of line

https://git.kernel.org/powerpc/c/69b420ed8fd3917ac7073256b4929aa246b6fe31
[11/13] lkdtm: Really write into kernel text in WRITE_KERN

https://git.kernel.org/powerpc/c/b64913394f123e819bffabc79a0e48f98e78dc5d
[12/13] lkdtm: Fix execute_[user]_location()

https://git.kernel.org/powerpc/c/72a86433049dcfe918886645ac3d19c1eaaa67ab
[13/13] lkdtm: Add a test for function descriptors protection

https://git.kernel.org/powerpc/c/5e5a6c5441654d1b9e576ce4ca8a1759e701079e

cheers

Re: [PATCH v1 1/4] powerpc/ftrace: Don't use lmw/stmw in ftrace_regs_caller()

2022-03-08 Thread Michael Ellerman

On Thu, 17 Feb 2022 13:01:56 +0100, Christophe Leroy wrote:
> For the same reason as commit a85c728cb5e1 ("powerpc/32: Don't use
> lmw/stmw for saving/restoring non volatile regs"), don't use
> lmw/stmw in ftrace_regs_caller().
> 
> Use the same macros for PPC32 and PPC64.
> 
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc/ftrace: Don't use lmw/stmw in ftrace_regs_caller()
  https://git.kernel.org/powerpc/c/9bdb2eec3dde4d66b71cb4bbaebde0caed2cf0e3
[2/4] powerpc/ftrace: Refactor ftrace_{regs_}caller
  https://git.kernel.org/powerpc/c/228216716cb5f9a19d70bfc40bdc0d6a7fb7e72f
[3/4] powerpc/ftrace: Regroup PPC64 specific operations in ftrace_mprofile.S
  https://git.kernel.org/powerpc/c/a5f04d1f2724db036ba4087873c0691881932bc9
[4/4] powerpc/ftrace: Use STK_GOT in ftrace_mprofile.S
  https://git.kernel.org/powerpc/c/2ca48dbb210767b9e7166d7d47febc8fcd1da6e1

cheers

Re: [PATCH v1 4/4] powerpc: Move C prototypes out of asm-prototypes.h

2022-03-08 Thread Michael Ellerman

Christophe Leroy  writes:
> Le 04/03/2022 à 18:04, Christophe Leroy a écrit :
>> We originally added asm-prototypes.h in commit 42f5b4cacd78 ("powerpc:
>> Introduce asm-prototypes.h"). It's purpose was for prototypes of C
>> functions that are only called from asm, in order to fix sparse
>> warnings about missing prototypes.
>> 
>> A few months later Nick added a different use case in
>> commit 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
>> for C prototypes for exported asm functions. This is basically the
>> inverse of our original usage.
>> 
>> Since then we've added various prototypes to asm-prototypes.h for both
>> reasons, meaning we now need to unstitch it all.
>> 
>> Dispatch prototypes of C functions into relevant headers and keep
>> only the prototypes for functions defined in assembly.
>> 
>> For the time being, leave prom_init() there because moving it
>> into asm/prom.h or asm/setup.h conflicts with
>> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o
>> This will be fixed later by untaggling asm/pci.h and asm/prom.h
>> or by renaming the function in shadowrom.c
>> 
>> Signed-off-by: Christophe Leroy 
>> ---
>>   arch/powerpc/include/asm/asm-prototypes.h | 51 ---
>>   arch/powerpc/include/asm/ftrace.h |  3 ++
>>   arch/powerpc/include/asm/hvcall.h |  5 ++
>>   arch/powerpc/include/asm/interrupt.h  | 11 
>>   arch/powerpc/include/asm/kexec.h  |  2 +
>>   arch/powerpc/include/asm/processor.h  |  8 +++
>>   arch/powerpc/include/asm/setup.h  |  7 +++
>>   arch/powerpc/include/asm/smp.h|  3 ++
>>   arch/powerpc/include/asm/syscalls.h   |  4 ++
>>   arch/powerpc/kernel/early_32.c|  1 -
>>   arch/powerpc/kernel/interrupt.c   |  1 -
>>   arch/powerpc/kernel/irq.c |  1 -
>>   arch/powerpc/kernel/mce.c |  1 -
>>   arch/powerpc/kernel/prom_init.c   |  1 -
>>   arch/powerpc/kernel/ptrace/ptrace.c   |  1 -
>>   arch/powerpc/kernel/setup_64.c|  1 -
>>   arch/powerpc/kernel/smp.c |  1 -
>>   arch/powerpc/kernel/syscalls.c|  1 -
>>   arch/powerpc/kernel/tau_6xx.c |  1 -
>>   arch/powerpc/kernel/time.c|  1 -
>>   arch/powerpc/kernel/trace/ftrace.c|  1 -
>>   arch/powerpc/kexec/core_64.c  |  1 -
>>   arch/powerpc/kvm/book3s_hv_builtin.c  |  1 -
>>   arch/powerpc/kvm/book3s_hv_rm_xive.c  |  1 -
>>   arch/powerpc/lib/vmx-helper.c |  1 -
>>   arch/powerpc/mm/book3s64/slb.c|  1 -
>>   arch/powerpc/mm/fault.c   |  1 -
>>   arch/powerpc/platforms/powernv/idle.c |  1 -
>>   .../platforms/powernv/opal-tracepoints.c  |  1 -
>>   arch/powerpc/platforms/pseries/lpar.c |  1 -
>>   30 files changed, 43 insertions(+), 72 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/prom_init.c 
>> b/arch/powerpc/kernel/prom_init.c
>> index 0ac5faacc909..3b49065daf21 100644
>> --- a/arch/powerpc/kernel/prom_init.c
>> +++ b/arch/powerpc/kernel/prom_init.c
>> @@ -41,7 +41,6 @@
>>   #include 
>>   #include 
>>   #include 
>> -#include 
>
> Need to keep this include as prom_init() couldn't be moved to asm/prom.h 
> due to conflict with drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c
>
> Can you fix it ?

Yep, done.

cheers

Re: [PATCH v1 1/4] powerpc: Cleanup asm-prototypes.c

2022-03-08 Thread Michael Ellerman

Christophe Leroy  writes:
> Le 04/03/2022 à 18:04, Christophe Leroy a écrit :
>> Last call to sys_swapcontext() from ASM was removed by
>> commit fbcee2ebe8ed ("powerpc/32: Always save non volatile GPRs at
>> syscall entry")
>> 
>> sys_debug_setcontext() prototype not needed anymore since
>> commit f3675644e172 ("powerpc/syscalls: signal_{32, 64} - switch
>> to SYSCALL_DEFINE")
>> 
>> sys_switch_endian() prototype not needed anymore since
>> commit 81dac8177862 ("powerpc/64: Make sys_switch_endian() traceable")
>> 
>> _mount() prototype is already in asm/ftrace.h
>> 
>> Signed-off-by: Christophe Leroy 
>> ---
>
> I see this series in next-test branch.
>
> Can you #include  in asm/asm-prototypes.h so that 
> _mcount() still gets versionned.

I just left the existing _mcount() prototype in asm-prototypes.h.

I've run that through some build tests, and want to push it for
tomorrow's next, so I'd rather not change it now.

Send me a follow-up patch to add the include of ftrace.h and drop the
_mcount() prototype.

cheers

Re: [PATCH v2 -next] powerpc/spufs: Fix build warning when CONFIG_PROC_FS=n

2022-03-08 Thread Christophe Leroy



Le 08/03/2022 à 11:09, YueHaibing a écrit :
> arch/powerpc/platforms/cell/spufs/sched.c:1055:12: warning: 
> ‘show_spu_loadavg’ defined but not used [-Wunused-function]
>   static int show_spu_loadavg(struct seq_file *s, void *private)
>  ^~~~
> 
> Move it into #ifdef block to fix this, also remove unneeded semicolon.
> 
> Signed-off-by: YueHaibing 

Reviewed-by: Christophe Leroy 

> ---
> v2: use #ifdef instead of __maybe_unused
> ---
>   arch/powerpc/platforms/cell/spufs/sched.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/cell/spufs/sched.c 
> b/arch/powerpc/platforms/cell/spufs/sched.c
> index d058f6233e66..99bd027a7f7c 100644
> --- a/arch/powerpc/platforms/cell/spufs/sched.c
> +++ b/arch/powerpc/platforms/cell/spufs/sched.c
> @@ -1052,6 +1052,7 @@ void spuctx_switch_state(struct spu_context *ctx,
>   }
>   }
>   
> +#ifdef CONFIG_PROC_FS
>   static int show_spu_loadavg(struct seq_file *s, void *private)
>   {
>   int a, b, c;
> @@ -1073,7 +1074,8 @@ static int show_spu_loadavg(struct seq_file *s, void 
> *private)
>   atomic_read(&nr_spu_contexts),
>   idr_get_cursor(&task_active_pid_ns(current)->idr) - 1);
>   return 0;
> -};
> +}
> +#endif
>   
>   int __init spu_sched_init(void)
>   {

Re: [PATCH v1 4/4] powerpc: Move C prototypes out of asm-prototypes.h

2022-03-08 Thread Christophe Leroy

Hi again Michael,

Le 04/03/2022 à 18:04, Christophe Leroy a écrit :
> We originally added asm-prototypes.h in commit 42f5b4cacd78 ("powerpc:
> Introduce asm-prototypes.h"). It's purpose was for prototypes of C
> functions that are only called from asm, in order to fix sparse
> warnings about missing prototypes.
> 
> A few months later Nick added a different use case in
> commit 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
> for C prototypes for exported asm functions. This is basically the
> inverse of our original usage.
> 
> Since then we've added various prototypes to asm-prototypes.h for both
> reasons, meaning we now need to unstitch it all.
> 
> Dispatch prototypes of C functions into relevant headers and keep
> only the prototypes for functions defined in assembly.
> 
> For the time being, leave prom_init() there because moving it
> into asm/prom.h or asm/setup.h conflicts with
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o
> This will be fixed later by untaggling asm/pci.h and asm/prom.h
> or by renaming the function in shadowrom.c
> 
> Signed-off-by: Christophe Leroy 
> ---
>   arch/powerpc/include/asm/asm-prototypes.h | 51 ---
>   arch/powerpc/include/asm/ftrace.h |  3 ++
>   arch/powerpc/include/asm/hvcall.h |  5 ++
>   arch/powerpc/include/asm/interrupt.h  | 11 
>   arch/powerpc/include/asm/kexec.h  |  2 +
>   arch/powerpc/include/asm/processor.h  |  8 +++
>   arch/powerpc/include/asm/setup.h  |  7 +++
>   arch/powerpc/include/asm/smp.h|  3 ++
>   arch/powerpc/include/asm/syscalls.h   |  4 ++
>   arch/powerpc/kernel/early_32.c|  1 -
>   arch/powerpc/kernel/interrupt.c   |  1 -
>   arch/powerpc/kernel/irq.c |  1 -
>   arch/powerpc/kernel/mce.c |  1 -
>   arch/powerpc/kernel/prom_init.c   |  1 -
>   arch/powerpc/kernel/ptrace/ptrace.c   |  1 -
>   arch/powerpc/kernel/setup_64.c|  1 -
>   arch/powerpc/kernel/smp.c |  1 -
>   arch/powerpc/kernel/syscalls.c|  1 -
>   arch/powerpc/kernel/tau_6xx.c |  1 -
>   arch/powerpc/kernel/time.c|  1 -
>   arch/powerpc/kernel/trace/ftrace.c|  1 -
>   arch/powerpc/kexec/core_64.c  |  1 -
>   arch/powerpc/kvm/book3s_hv_builtin.c  |  1 -
>   arch/powerpc/kvm/book3s_hv_rm_xive.c  |  1 -
>   arch/powerpc/lib/vmx-helper.c |  1 -
>   arch/powerpc/mm/book3s64/slb.c|  1 -
>   arch/powerpc/mm/fault.c   |  1 -
>   arch/powerpc/platforms/powernv/idle.c |  1 -
>   .../platforms/powernv/opal-tracepoints.c  |  1 -
>   arch/powerpc/platforms/pseries/lpar.c |  1 -
>   30 files changed, 43 insertions(+), 72 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 0ac5faacc909..3b49065daf21 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -41,7 +41,6 @@
>   #include 
>   #include 
>   #include 
> -#include 

Need to keep this include as prom_init() couldn't be moved to asm/prom.h 
due to conflict with drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c

Can you fix it ?

>   #include 
>   
>   #include

Re: [BUG] mtd: cfi_cmdset_0002: write regression since v4.17-rc1

2022-03-08 Thread Ahmad Fatoum

Hello Tokunori,

On 06.03.22 16:49, Tokunori Ikegami wrote:
> Hi,
> 
> On 2022/03/04 20:11, Ahmad Fatoum wrote:
>> Hello Tokunori-san,
>>
>> On 20.02.22 13:22, Tokunori Ikegami wrote:
>>> Hi Ahmad-san,
>>>
>>> Could you please try the version 2 patch attached for the error case?
>>> This version is to check the DQ true data 0xFF by chip_good().
>> I had a similar patch locally as well at first. I just tested yours
>> and I can't reproduce the issue.
> Thanks for your support.
> Sorry if possible could you please retest the attached the patch again since 
> this fixed the version 1 patch maintainer review comments?

Works good.

Tested-by: Ahmad Fatoum 

>>> But I am not sure if this works or not since the error is possible to be 
>>> caused by Hi-Z 0xff on floating bus or etc.
>> That it works for me could be because of Hi-Z 0xff, which is why
>> decided against it.
> I see.
>>
>>> What seems to work for me is checking if chip_good or chip_ready
>>> and map_word is equal to 0xFF. I can't justify why this is ok though.
>>> (Worst case bus is floating at this point of time and Hi-Z is read
>>> as 0xff on CPU data lines...)
>> Sorry I am not sure about this.
>> I thought the chip_ready() itself is correct as implemented as the data 
>> sheet in the past.
>> But it did not work correctly so changed to use chip_good() instead as 
>> it is also correct.
> What exactly in the datasheet makes you believe chip_good is not 
> appropriate?
 I just mentioned about the actual issue behaviors as not worked 
 chip_good() on S29GL964N and not worked chip_ready() on MX29GL512FHT2I-11G 
 before etc.
 Anyway let me recheck the data sheet details as just checked it again 
 quickly but needed more investigation to understand.
>>> As far as I checked still both chip_good() and chip_ready() seem correct 
>>> but still the root cause is unknown.
>>> If as you mentioned the issue was cased by the DQ true data 0xFF I am not 
>>> sure why the read work without any error after the write operation.
>>> Also if the error was caused by the Hi-Z 0xff on floating bus as mentioned 
>>> I am not sure why the read work without any error after the write operation 
>>> with chip_ready().
>>> Sorry anyway the root cause is also unknown when the write operation was 
>>> changed to use chip_good() instead of chip_ready().
>> I've be ok with v1 then. Restores working behavior for me and shouldn't 
>> break others.
> 
> Noted but still I am thinking the version 2 patch to check 0xff seems better 
> than to use chip_ready() so let me consider this again later.

The original version has less room for surprise as it restores previously
working behavior. Assuming 0xFF to be good without backing from documentation
is more risky IMO.

Thanks for your continued support,
Ahmad

> 
> Regards,
> Ikegami
> 
>>
>> Cheers and thanks again,
>> Ahmad
>>
>>> Regards,
>>> Ikegami
>>>
 Regards,
 Ikegami

> Cheers,
> Ahmad
>
>
>>


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v1 1/4] powerpc: Cleanup asm-prototypes.c

2022-03-08 Thread Christophe Leroy

Hi Michael,

Le 04/03/2022 à 18:04, Christophe Leroy a écrit :
> Last call to sys_swapcontext() from ASM was removed by
> commit fbcee2ebe8ed ("powerpc/32: Always save non volatile GPRs at
> syscall entry")
> 
> sys_debug_setcontext() prototype not needed anymore since
> commit f3675644e172 ("powerpc/syscalls: signal_{32, 64} - switch
> to SYSCALL_DEFINE")
> 
> sys_switch_endian() prototype not needed anymore since
> commit 81dac8177862 ("powerpc/64: Make sys_switch_endian() traceable")
> 
> _mount() prototype is already in asm/ftrace.h
> 
> Signed-off-by: Christophe Leroy 
> ---

I see this series in next-test branch.

Can you #include  in asm/asm-prototypes.h so that 
_mcount() still gets versionned.

If you prefer I can resend the series.

Thanks
Christophe

>   arch/powerpc/include/asm/asm-prototypes.h | 7 ---
>   1 file changed, 7 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h 
> b/arch/powerpc/include/asm/asm-prototypes.h
> index 41b8a1e1144a..4fd79207fd41 100644
> --- a/arch/powerpc/include/asm/asm-prototypes.h
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -57,12 +57,7 @@ int enter_vmx_ops(void);
>   void *exit_vmx_ops(void *dest);
>   
>   /* signals, syscalls and interrupts */
> -long sys_swapcontext(struct ucontext __user *old_ctx,
> - struct ucontext __user *new_ctx,
> - long ctx_size);
>   #ifdef CONFIG_PPC32
> -long sys_debug_setcontext(struct ucontext __user *ctx,
> -   int ndbg, struct sig_dbg_op __user *dbg);
>   int
>   ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user 
> *exp,
>  struct __kernel_old_timeval __user *tvp);
> @@ -81,7 +76,6 @@ unsigned long interrupt_exit_kernel_restart(struct pt_regs 
> *regs);
>   
>   long ppc_fadvise64_64(int fd, int advice, u32 offset_high, u32 offset_low,
> u32 len_high, u32 len_low);
> -long sys_switch_endian(void);
>   
>   /* prom_init (OpenFirmware) */
>   unsigned long __init prom_init(unsigned long r3, unsigned long r4,
> @@ -102,7 +96,6 @@ extern int __cmpdi2(s64, s64);
>   extern int __ucmpdi2(u64, u64);
>   
>   /* tracing */
> -void _mcount(void);
>   unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip,
>   unsigned long sp);
>

58 matches

Mail list logo