Re: linux-next: Tree for Jun 2 (arch/powerpc/kernel/iommu.c)

2023-06-15 Thread Christophe Leroy


Le 15/06/2023 à 18:34, Randy Dunlap a écrit :
> 
> 
> On 6/15/23 09:13, Randy Dunlap wrote:
>>
>>
>> On 6/15/23 09:05, Timothy Pearson wrote:
>>>
>>>
>>> - Original Message -
 From: "Randy Dunlap" 
 To: "Timothy Pearson" , "Michael Ellerman" 
 
 Cc: "Stephen Rothwell" , "Linux Next Mailing List" 
 , "linux-kernel"
 , "linuxppc-dev" 
 , "Alexey Kardashevskiy" 
 Sent: Thursday, June 15, 2023 11:00:08 AM
 Subject: Re: linux-next: Tree for Jun 2 (arch/powerpc/kernel/iommu.c)
>>>
 Hi Timothy,

 On 6/3/23 20:57, Timothy Pearson wrote:
>
>
> - Original Message -
>> From: "Michael Ellerman" 
>> To: "Randy Dunlap" , "Stephen Rothwell"
>> , "Linux Next Mailing List"
>> 
>> Cc: "linux-kernel" , "linuxppc-dev"
>> , "Alexey
>> Kardashevskiy" , "Timothy Pearson"
>> 
>> Sent: Saturday, June 3, 2023 7:22:51 PM
>> Subject: Re: linux-next: Tree for Jun 2 (arch/powerpc/kernel/iommu.c)
>
>> Randy Dunlap  writes:
>>> On 6/1/23 21:01, Stephen Rothwell wrote:
 Hi all,

 Changes since 20230601:

>>>
>>> On powerpc64, a randconfig failed with:
>>>
>>> In file included from ../include/linux/list.h:5,
>>>   from ../include/linux/preempt.h:11,
>>>   from ../include/linux/spinlock.h:56,
>>>   from ../include/linux/mmzone.h:8,
>>>   from ../include/linux/gfp.h:7,
>>>   from ../include/linux/slab.h:15,
>>>   from ../arch/powerpc/kernel/iommu.c:15:
>>> ../arch/powerpc/kernel/iommu.c: In function
>>> 'spapr_tce_setup_phb_iommus_initcall':
>>> ../arch/powerpc/kernel/iommu.c:1391:36: error: 'hose_list' undeclared 
>>> (first use
>>> in this function); did you mean 'zonelist'?
>>>   1391 | list_for_each_entry(hose, _list, list_node) {
>>>|^
>> ...
>>
>> hose_list is in pci-common.c which is built when PCI=y.
>>
>> PSERIES and POWERNV force PCI=y.
>>
>> But this config has neither:
>>
>> # CONFIG_PPC_POWERNV is not set
>> # CONFIG_PPC_PSERIES is not set
>> CONFIG_HAVE_PCI=y
>> # CONFIG_PCI is not set
>> # CONFIG_COMMON_CLK_RS9_PCIE is not set
>>
>>
>> Probably the spapr_tce code should be wrapped in an #ifdef that is only
>> enabled when POWERNV || PSERIES is enabled.
>>
>> cheers
>
> Sounds reasonable, I was going to look into this further over the 
> weekend.  I
> can put together a patch for Monday if that works?

 Did you prepare a patch for this? I am still seeing this build error.

 thanks.
 --
 ~Randy
>>>
>>> Yes, it was sent in to the linuxppc-dev list some weeks ago.  Did it not 
>>> arrive?
>>
>> I don't know - I'm not subscribed to that list.
>>
>> It's probably still in the patchworks review cycle
>> so it hasn't been applied anywhere that gets into linux-next.
> 
> OK, it's here, mark with Success:
> http://patchwork.ozlabs.org/project/linuxppc-dev/patch/2015925968.3546872.1685990936823.javamail.zim...@raptorengineeringinc.com/
> 
> I don't know what happens to it next or when.

Is that supposed to fix anything ? I doesn't have any Fixes: tag

Christophe


Re: [PATCH] powerpc/xmon: Fix comparing pointer

2023-06-13 Thread Christophe Leroy


Le 14/06/2023 à 07:48, wuyonggang...@208suo.com a écrit :
> [Vous ne recevez pas souvent de courriers de wuyonggang...@208suo.com. 
> D?couvrez pourquoi ceci est important ? 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Fix the following coccicheck warning:
> 
> arch/powerpc/xmon/spu-dis.c:51:34-35: WARNING comparing pointer to 0

Once again, why do you change the formating of the document ?

> 
> Signed-off-by: Yonggang Wu 
> ---
>   arch/powerpc/xmon/spu-dis.c | 384 ++--
>   1 file changed, 193 insertions(+), 191 deletions(-)
> 
> diff --git a/arch/powerpc/xmon/spu-dis.c b/arch/powerpc/xmon/spu-dis.c
> index 4b0a4e640f08..f48a2ddd7440 100644
> --- a/arch/powerpc/xmon/spu-dis.c
> +++ b/arch/powerpc/xmon/spu-dis.c
> @@ -22,216 +22,218 @@ extern const int spu_num_opcodes;
>   #define SPU_DISASM_TBL_SIZE (1 << 11)
>   static const struct spu_opcode
> *spu_disassemble_table[SPU_DISASM_TBL_SIZE];
> 
> -static void
> -init_spu_disassemble (void)
> +static void init_spu_disassemble(void)
>   {
> -  int i;
> -
> -  /* If two instructions have the same opcode then we prefer the first
> -   * one.  In most cases it is just an alternate mnemonic. */
> -  for (i = 0; i < spu_num_opcodes; i++)
> -    {
> -  int o = spu_opcodes[i].opcode;
> -  if (o >= SPU_DISASM_TBL_SIZE)
> -    continue; /* abort (); */
> -  if (spu_disassemble_table[o] == 0)
> -    spu_disassemble_table[o] = _opcodes[i];
> -    }
> +    int i;
> +
> +    /*
> + * If two instructions have the same opcode then we prefer the
> first
> + * one.  In most cases it is just an alternate mnemonic.
> + */
> +    for (i = 0; i < spu_num_opcodes; i++) {
> +    int o = spu_opcodes[i].opcode;
> +
> +    if (o >= SPU_DISASM_TBL_SIZE)
> +    continue; /* abort(); */
> +    if (spu_disassemble_table[o] == NULL)
> +    spu_disassemble_table[o] = _opcodes[i];
> +    }
>   }
> 
>   /* Determine the instruction from the 10 least significant bits. */
> -static const struct spu_opcode *
> -get_index_for_opcode (unsigned int insn)
> +static const struct spu_opcode *get_index_for_opcode(unsigned int insn)
>   {
> -  const struct spu_opcode *index;
> -  unsigned int opcode = insn >> (32-11);
> -
> -  /* Init the table.  This assumes that element 0/opcode 0 (currently
> -   * NOP) is always used */
> -  if (spu_disassemble_table[0] == 0)
> -    init_spu_disassemble ();
> -
> -  if ((index = spu_disassemble_table[opcode & 0x780]) != 0
> -  && index->insn_type == RRR)
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7f0]) != 0
> -  && (index->insn_type == RI18 || index->insn_type == LBT))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7f8]) != 0
> -  && index->insn_type == RI10)
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7fc]) != 0
> -  && (index->insn_type == RI16))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7fe]) != 0
> -  && (index->insn_type == RI8))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7ff]) != 0)
> -    return index;
> -
> -  return NULL;
> +    const struct spu_opcode *index;
> +    unsigned int opcode = insn >> (32-11);
> +
> +    /*
> + * Init the table.  This assumes that element 0/opcode 0 (currently
> + * NOP) is always used
> + */
> +    if (spu_disassemble_table[0] == NULL)
> +    init_spu_disassemble();
> +
> +    index = spu_disassemble_table[opcode & 0x780];
> +    if (index != NULL && index->insn_type == RRR)
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7f0];
> +    if (index != NULL
> +  && (index->insn_type == RI18 || index->insn_type == LBT))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7f8];
> +    if (index != NULL
> +  && index->insn_type == RI10)
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7fc]
> +    if (index != NULL && (index->insn_type == RI16))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7fe];
> +    if (index != NULL && (index->insn_type == RI8))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7ff];
> +    if (index != NULL)
> +    return index;
> +
> +    return NULL;
>   }
> 
>   /* Print a Spu instruction.  */
> 
> -int
> -print_insn_spu (unsigned long insn, unsigned long memaddr)
> +int print_insn_spu(unsigned long insn, unsigned long memaddr)
>   {
> -  int value;
> -  int hex_value;
> -  const struct spu_opcode *index;
> -  enum spu_insns tag;
> +    int value;
> +    int hex_value;
> +    const struct spu_opcode *index;
> +    enum spu_insns tag;
> 
> -  index = get_index_for_opcode (insn);
> +    index = get_index_for_opcode(insn);
> 
> -  if (index == 0)
> -    {
> -  printf(".long 0x%lx", insn);
> -    }
> -  else
> -    {
> -  int i;
> -  int paren = 0;
> -  tag = 

Re: [PATCH 0/3] Move the ARCH_DMA_MINALIGN definition to asm/cache.h

2023-06-13 Thread Christophe Leroy


Le 13/06/2023 à 17:52, Catalin Marinas a écrit :
> Hi,
> 
> The ARCH_KMALLOC_MINALIGN reduction series defines a generic
> ARCH_DMA_MINALIGN in linux/cache.h:
> 
> https://lore.kernel.org/r/20230612153201.554742-2-catalin.mari...@arm.com/
> 
> Unfortunately, this causes a duplicate definition warning for
> microblaze, powerpc (32-bit only) and sh as these architectures define
> ARCH_DMA_MINALIGN in a different file than asm/cache.h. Move the macro
> to asm/cache.h to avoid this issue and also bring them in line with the
> other architectures.

What about mips ?

arch/mips/include/asm/mach-generic/kmalloc.h:#define ARCH_DMA_MINALIGN  128
arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_DMA_MINALIGN 32
arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_DMA_MINALIGN 128
arch/mips/include/asm/mach-n64/kmalloc.h:#define ARCH_DMA_MINALIGN 
L1_CACHE_BYTES
arch/mips/include/asm/mach-tx49xx/kmalloc.h:#define ARCH_DMA_MINALIGN 
L1_CACHE_BYTES


> 
> Andrew, if the arch maintainers cc'ed are fine with such change, could
> you please take these three patches together with the
> ARCH_KMALLOC_MINALIGN series?
> 
> Thank you.
> 
> Catalin Marinas (3):
>powerpc: Move the ARCH_DMA_MINALIGN definition to asm/cache.h
>microblaze: Move the ARCH_{DMA,SLAB}_MINALIGN definitions to
>  asm/cache.h
>sh: Move the ARCH_DMA_MINALIGN definition to asm/cache.h
> 
>   arch/microblaze/include/asm/cache.h | 5 +
>   arch/microblaze/include/asm/page.h  | 5 -
>   arch/powerpc/include/asm/cache.h| 4 
>   arch/powerpc/include/asm/page_32.h  | 4 
>   arch/sh/include/asm/cache.h | 6 ++
>   arch/sh/include/asm/page.h  | 6 --
>   6 files changed, 15 insertions(+), 15 deletions(-)
> 


Re: [PATCH] powerpc/xmon: Fix comparing pointer

2023-06-13 Thread Christophe Leroy


Le 13/06/2023 à 05:38, wuyonggang...@208suo.com a écrit :
>   
> 
> Fix the following coccicheck warning:
> 
> arch/powerpc/xmon/spu-dis.c:51:34-35: WARNING comparing pointer to 0


Please send text messages, not html.

And please check your patch, a lot of lines have no modifications but 
appears as modified in your patch because you changed the formating.

Please don't change more than what is intended to change.

Thanks

> 
> Signed-off-by: Yonggang Wu 
> ---
>   arch/powerpc/xmon/spu-dis.c | 384 ++--
>   1 file changed, 193 insertions(+), 191 deletions(-)
> 
> diff --git a/arch/powerpc/xmon/spu-dis.c b/arch/powerpc/xmon/spu-dis.c
> index 4b0a4e640f08..f48a2ddd7440 100644
> --- a/arch/powerpc/xmon/spu-dis.c
> +++ b/arch/powerpc/xmon/spu-dis.c
> @@ -22,216 +22,218 @@ extern const int spu_num_opcodes;
>   #define SPU_DISASM_TBL_SIZE (1 << 11)
>   static const struct spu_opcode 
> *spu_disassemble_table[SPU_DISASM_TBL_SIZE];
> 
> -static void
> -init_spu_disassemble (void)
> +static void init_spu_disassemble(void)
>   {
> -  int i;
> -
> -  /* If two instructions have the same opcode then we prefer the first
> -   * one.  In most cases it is just an alternate mnemonic. */
> -  for (i = 0; i < spu_num_opcodes; i++)
> -    {
> -  int o = spu_opcodes[i].opcode;
> -  if (o >= SPU_DISASM_TBL_SIZE)
> -    continue; /* abort (); */
> -  if (spu_disassemble_table[o] == 0)
> -    spu_disassemble_table[o] = _opcodes[i];
> -    }
> +    int i;
> +
> +    /*
> + * If two instructions have the same opcode then we prefer the first
> + * one.  In most cases it is just an alternate mnemonic.
> + */
> +    for (i = 0; i < spu_num_opcodes; i++) {
> +    int o = spu_opcodes[i].opcode;
> +
> +    if (o >= SPU_DISASM_TBL_SIZE)
> +    continue; /* abort(); */
> +    if (spu_disassemble_table[o] == NULL)
> +    spu_disassemble_table[o] = _opcodes[i];
> +    }
>   }
> 
>   /* Determine the instruction from the 10 least significant bits. */
> -static const struct spu_opcode *
> -get_index_for_opcode (unsigned int insn)
> +static const struct spu_opcode *get_index_for_opcode(unsigned int insn)
>   {
> -  const struct spu_opcode *index;
> -  unsigned int opcode = insn >> (32-11);
> -
> -  /* Init the table.  This assumes that element 0/opcode 0 (currently
> -   * NOP) is always used */
> -  if (spu_disassemble_table[0] == 0)
> -    init_spu_disassemble ();
> -
> -  if ((index = spu_disassemble_table[opcode & 0x780]) != 0
> -  && index->insn_type == RRR)
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7f0]) != 0
> -  && (index->insn_type == RI18 || index->insn_type == LBT))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7f8]) != 0
> -  && index->insn_type == RI10)
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7fc]) != 0
> -  && (index->insn_type == RI16))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7fe]) != 0
> -  && (index->insn_type == RI8))
> -    return index;
> -
> -  if ((index = spu_disassemble_table[opcode & 0x7ff]) != 0)
> -    return index;
> -
> -  return NULL;
> +    const struct spu_opcode *index;
> +    unsigned int opcode = insn >> (32-11);
> +
> +    /*
> + * Init the table.  This assumes that element 0/opcode 0 (currently
> + * NOP) is always used
> + */
> +    if (spu_disassemble_table[0] == NULL)
> +    init_spu_disassemble();
> +
> +    index = spu_disassemble_table[opcode & 0x780];
> +    if (index != NULL && index->insn_type == RRR)
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7f0];
> +    if (index != NULL
> +  && (index->insn_type == RI18 || index->insn_type == LBT))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7f8];
> +    if (index != NULL
> +  && index->insn_type == RI10)
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7fc]
> +    if (index != NULL && (index->insn_type == RI16))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7fe];
> +    if (index != NULL && (index->insn_type == RI8))
> +    return index;
> +
> +    index = spu_disassemble_table[opcode & 0x7ff];
> +    if (index != NULL)
> +    return index;
> +
> +    return NULL;
>   }
> 
>   /* Print a Spu instruction.  */
> 
> -int
> -print_insn_spu (unsigned long insn, unsigned long memaddr)
> +int print_insn_spu(unsigned long insn, unsigned long memaddr)
>   {
> -  int value;
> -  int hex_value;
> -  const struct spu_opcode *index;
> -  enum spu_insns tag;
> +    int value;
> +    int hex_value;
> +    const struct spu_opcode *index;
> +    enum spu_insns tag;
> 
> -  index = get_index_for_opcode (insn);
> +    index = get_index_for_opcode(insn);
> 
> -  if (index == 0)
> -    {
> -  printf(".long 0x%lx", insn);
> -    }
> -  else
> -    {
> -  int i;
> -  int 

[PATCH 4/4] powerpc/kuap: Make disabling KUAP at boottime optional

2023-06-05 Thread Christophe Leroy
It is possible to disable KUAP at boottime with 'nosmap' parameter.

That is implemented with jump_label hence adds a 'nop' in front
of each open/close of userspace access.

>From a security point of view it makes sence to disallow disabling
KUAP. And on processors like the 8xx where 'nop' is not seamless,
it saves a few cycles.

So add a CONFIG item to make it optionnal.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/kup.h |  2 +-
 arch/powerpc/mm/init-common.c  |  3 +++
 arch/powerpc/platforms/Kconfig.cputype | 10 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 74b7f4cee2ed..f3280169aeec 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -53,7 +53,7 @@ extern struct static_key_false disable_kuap_key;
 
 static __always_inline bool kuap_is_disabled(void)
 {
-   return static_branch_unlikely(_kuap_key);
+   return IS_ENABLED(CONFIG_PPC_KUAP_BOOTTIME) && 
static_branch_unlikely(_kuap_key);
 }
 #endif
 #else
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index 74e140b1efef..994ee58f0092 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -48,6 +48,9 @@ early_param("nosmep", parse_nosmep);
 
 static int __init parse_nosmap(char *p)
 {
+   if (!IS_ENABLED(CONFIG_PPC_KUAP_BOOTTIME))
+   return 0;
+
disable_kuap = true;
pr_warn("Disabling Kernel Userspace Access Protection\n");
return 0;
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 45fd975ef521..f75c2d5cd182 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -502,6 +502,16 @@ config PPC_KUAP
 
  If you're unsure, say Y.
 
+config PPC_KUAP_BOOTTIME
+   bool "Allow disabling Kernel Userspace Access Protection at boottime"
+   depends on PPC_KUAP
+   default y
+   help
+ Allow the user to disable Kernel Userspace Access Protection (KUAP)
+ at boot time using 'nosmap' kernel parameter.
+
+ If you're unsure, say Y.
+
 config PPC_KUAP_DEBUG
bool "Extra debugging for Kernel Userspace Access Protection"
depends on PPC_KUAP
-- 
2.40.1



[PATCH 3/4] powerpc/kuap: Refactor static branch for disabling kuap

2023-06-05 Thread Christophe Leroy
All but book3s/64 use a static branch key for disabling kuap.
book3s/64 uses a memory feature.

Refactor all targets except book3s/64.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h |  7 ---
 arch/powerpc/include/asm/book3s/64/kup.h |  1 +
 arch/powerpc/include/asm/kup.h   | 15 +++
 arch/powerpc/include/asm/nohash/32/kup-8xx.h |  7 ---
 arch/powerpc/include/asm/nohash/kup-booke.h  |  7 ---
 arch/powerpc/mm/book3s32/kuap.c  |  3 ---
 arch/powerpc/mm/init-common.c|  3 +++
 arch/powerpc/mm/nohash/kup.c |  3 ---
 8 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 466a19cfb4df..8da9997a67ba 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -11,8 +11,6 @@
 
 #include 
 
-extern struct static_key_false disable_kuap_key;
-
 static __always_inline bool kuep_is_disabled(void)
 {
return !IS_ENABLED(CONFIG_PPC_KUEP);
@@ -25,11 +23,6 @@ static __always_inline bool kuep_is_disabled(void)
 #define KUAP_NONE  (~0UL)
 #define KUAP_ALL   (~1UL)
 
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void kuap_lock_one(unsigned long addr)
 {
mtsr(mfsr(addr) | SR_KS, addr);
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index 1b0215ff3710..f8b8e93c488c 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -233,6 +233,7 @@ static __always_inline bool kuap_is_disabled(void)
 {
return !mmu_has_feature(MMU_FTR_BOOK3S_KUAP);
 }
+#define kuap_is_disabled kuap_is_disabled
 
 static inline void kuap_user_restore(struct pt_regs *regs)
 {
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 0a4e07175612..74b7f4cee2ed 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -6,6 +6,12 @@
 #define KUAP_WRITE 2
 #define KUAP_READ_WRITE(KUAP_READ | KUAP_WRITE)
 
+#ifndef __ASSEMBLY__
+#include 
+
+static __always_inline bool kuap_is_disabled(void);
+#endif
+
 #ifdef CONFIG_PPC_BOOK3S_64
 #include 
 #endif
@@ -41,6 +47,15 @@ void setup_kuep(bool disabled);
 
 #ifdef CONFIG_PPC_KUAP
 void setup_kuap(bool disabled);
+
+#ifndef kuap_is_disabled
+extern struct static_key_false disable_kuap_key;
+
+static __always_inline bool kuap_is_disabled(void)
+{
+   return static_branch_unlikely(_kuap_key);
+}
+#endif
 #else
 static inline void setup_kuap(bool disabled) { }
 
diff --git a/arch/powerpc/include/asm/nohash/32/kup-8xx.h 
b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
index a372cd822887..1d53f38c5cd5 100644
--- a/arch/powerpc/include/asm/nohash/32/kup-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
@@ -13,13 +13,6 @@
 
 #include 
 
-extern struct static_key_false disable_kuap_key;
-
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
regs->kuap = mfspr(SPRN_MD_AP);
diff --git a/arch/powerpc/include/asm/nohash/kup-booke.h 
b/arch/powerpc/include/asm/nohash/kup-booke.h
index 71182cbe20c3..07759ae9117b 100644
--- a/arch/powerpc/include/asm/nohash/kup-booke.h
+++ b/arch/powerpc/include/asm/nohash/kup-booke.h
@@ -18,13 +18,6 @@
 
 #include 
 
-extern struct static_key_false disable_kuap_key;
-
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void __kuap_lock(void)
 {
mtspr(SPRN_PID, 0);
diff --git a/arch/powerpc/mm/book3s32/kuap.c b/arch/powerpc/mm/book3s32/kuap.c
index 28676cabb005..c5484729b595 100644
--- a/arch/powerpc/mm/book3s32/kuap.c
+++ b/arch/powerpc/mm/book3s32/kuap.c
@@ -3,9 +3,6 @@
 #include 
 #include 
 
-struct static_key_false disable_kuap_key;
-EXPORT_SYMBOL(disable_kuap_key);
-
 void kuap_lock_all_ool(void)
 {
kuap_lock_all();
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index 119ef491f797..74e140b1efef 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -32,6 +32,9 @@ EXPORT_SYMBOL_GPL(kernstart_virt_addr);
 bool disable_kuep = !IS_ENABLED(CONFIG_PPC_KUEP);
 bool disable_kuap = !IS_ENABLED(CONFIG_PPC_KUAP);
 
+struct static_key_false disable_kuap_key;
+EXPORT_SYMBOL(disable_kuap_key);
+
 static int __init parse_nosmep(char *p)
 {
if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64))
diff --git a/arch/powerpc/mm/nohash/kup.c b/arch/powerpc/mm/nohash/kup.c
index 552becf90e97..4e22adfa2aa8 100644
--- a/arch/powerpc/mm/nohash/kup.c
+++ b/arch/powerpc/mm/nohash/kup.c
@@ -13,9 +13,6 @@
 #include 
 
 #ifdef CONFIG_PPC_KUAP
-struct static_key_false disable_kuap_key;
-EXPORT_SYMBOL(disable_kuap_key);
-
 v

[PATCH 2/4] powerpc/kuap: Avoid useless jump_label on empty function

2023-06-05 Thread Christophe Leroy
Disassembly of interrupt_enter_prepare() shows a pointless nop before the mftb

  c000abf0 :
  c000abf0:   81 23 00 84 lwz r9,132(r3)
  c000abf4:   71 29 40 00 andi.   r9,r9,16384
  c000abf8:   41 82 00 28 beq-c000ac20 

  c000abfc: ===>  60 00 00 00 nop   <
  c000ac00:   7d 0c 42 e6 mftbr8
  c000ac04:   80 e2 00 08 lwz r7,8(r2)
  c000ac08:   81 22 00 28 lwz r9,40(r2)
  c000ac0c:   91 02 00 24 stw r8,36(r2)
  c000ac10:   7d 29 38 50 subfr9,r9,r7
  c000ac14:   7d 29 42 14 add r9,r9,r8
  c000ac18:   91 22 00 08 stw r9,8(r2)
  c000ac1c:   4e 80 00 20 blr
  c000ac20:   60 00 00 00 nop
  c000ac24:   7d 5a c2 a6 mfmd_ap r10
  c000ac28:   3d 20 de 00 lis r9,-8704
  c000ac2c:   91 43 00 b0 stw r10,176(r3)
  c000ac30:   7d 3a c3 a6 mtspr   794,r9
  c000ac34:   4e 80 00 20 blr

That comes from the call to kuap_loc(), allthough __kuap_lock() is an empty
function on the 8xx.

To avoid that, only perform kuap_is_disabled() check when there is something
to do with __kuap_lock().

Do the same with __kuap_save_and_lock() and __kuap_get_and_assert_locked().

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h |  6 ++---
 arch/powerpc/include/asm/book3s/64/kup.h | 10 +---
 arch/powerpc/include/asm/kup.h   | 25 ++--
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 11 -
 arch/powerpc/include/asm/nohash/kup-booke.h  |  8 +--
 5 files changed, 26 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 678f9c9d89b6..466a19cfb4df 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -77,10 +77,6 @@ static inline void kuap_unlock(unsigned long addr, bool ool)
kuap_unlock_all_ool();
 }
 
-static inline void __kuap_lock(void)
-{
-}
-
 static inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
unsigned long kuap = current->thread.kuap;
@@ -92,6 +88,7 @@ static inline void __kuap_save_and_lock(struct pt_regs *regs)
current->thread.kuap = KUAP_NONE;
kuap_lock_addr(kuap, false);
 }
+#define __kuap_save_and_lock __kuap_save_and_lock
 
 static inline void kuap_user_restore(struct pt_regs *regs)
 {
@@ -120,6 +117,7 @@ static inline unsigned long 
__kuap_get_and_assert_locked(void)
 
return kuap;
 }
+#define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
 
 static __always_inline void __allow_user_access(void __user *to, const void 
__user *from,
u32 size, unsigned long dir)
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index 54cf46808157..1b0215ff3710 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -297,15 +297,7 @@ static inline unsigned long 
__kuap_get_and_assert_locked(void)
WARN_ON_ONCE(amr != AMR_KUAP_BLOCKED);
return amr;
 }
-
-/* Do nothing, book3s/64 does that in ASM */
-static inline void __kuap_lock(void)
-{
-}
-
-static inline void __kuap_save_and_lock(struct pt_regs *regs)
-{
-}
+#define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
 
 /*
  * We support individually allowing read or write, but we don't support nesting
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index d751ddd08110..0a4e07175612 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -52,16 +52,9 @@ __bad_kuap_fault(struct pt_regs *regs, unsigned long 
address, bool is_write)
return false;
 }
 
-static inline void __kuap_lock(void) { }
-static inline void __kuap_save_and_lock(struct pt_regs *regs) { }
 static inline void kuap_user_restore(struct pt_regs *regs) { }
 static inline void __kuap_kernel_restore(struct pt_regs *regs, unsigned long 
amr) { }
 
-static inline unsigned long __kuap_get_and_assert_locked(void)
-{
-   return 0;
-}
-
 /*
  * book3s/64/kup-radix.h defines these functions for the !KUAP case to flush
  * the L1D cache after user accesses. Only include the empty stubs for other
@@ -87,27 +80,32 @@ bad_kuap_fault(struct pt_regs *regs, unsigned long address, 
bool is_write)
 
 static __always_inline void kuap_assert_locked(void)
 {
+#if defined(CONFIG_PPC_KUAP_DEBUG) && defined(__kuap_get_and_assert_locked)
if (kuap_is_disabled())
return;
 
-   if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   __kuap_get_and_assert_locked();
+   __kuap_get_and_assert_locked();
+#endif
 }
 
 static __always_inline void kuap_lock(void)
 {
+#ifdef __kuap_lock
if (kuap_is_disabled())
return;
 
__kuap_lock();
+#endif
 }
 
 static __always_inline void kuap_save_and_lock(

[PATCH 1/4] powerpc/kuap: Avoid unnecessary reads of MD_AP

2023-06-05 Thread Christophe Leroy
A disassembly of interrupt_exit_kernel_prepare() shows a useless read
of MD_AP register. This is shown by r9 being re-used immediately without
doing anything with the value read.

  c000e0e0:   60 00 00 00 nop
  c000e0e4: ===>  7d 3a c2 a6 mfmd_ap r9<
  c000e0e8:   7d 20 00 a6 mfmsr   r9
  c000e0ec:   7c 51 13 a6 mtspr   81,r2
  c000e0f0:   81 3f 00 84 lwz r9,132(r31)
  c000e0f4:   71 29 80 00 andi.   r9,r9,32768

kuap_get_and_assert_locked() is paired with kuap_kernel_restore()
and are only used in interrupt_exit_kernel_prepare(). The value
returned by kuap_get_and_assert_locked() is only used by
kuap_kernel_restore().

On 8xx, kuap_kernel_restore() doesn't use the value read by
kuap_get_and_assert_locked() so modify kuap_get_and_assert_locked()
to not perform the read of MD_AP and return 0 instead.

The same applies on BOOKE.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 8 ++--
 arch/powerpc/include/asm/nohash/kup-booke.h  | 6 ++
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/nohash/32/kup-8xx.h 
b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
index c44d97751723..8579210f2a6a 100644
--- a/arch/powerpc/include/asm/nohash/32/kup-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
@@ -41,14 +41,10 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 
 static inline unsigned long __kuap_get_and_assert_locked(void)
 {
-   unsigned long kuap;
-
-   kuap = mfspr(SPRN_MD_AP);
-
if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   WARN_ON_ONCE(kuap >> 16 != MD_APG_KUAP >> 16);
+   WARN_ON_ONCE(mfspr(SPRN_MD_AP) >> 16 != MD_APG_KUAP >> 16);
 
-   return kuap;
+   return 0;
 }
 
 static inline void __allow_user_access(void __user *to, const void __user 
*from,
diff --git a/arch/powerpc/include/asm/nohash/kup-booke.h 
b/arch/powerpc/include/asm/nohash/kup-booke.h
index 49bb41ed0816..823c5a3a96d8 100644
--- a/arch/powerpc/include/asm/nohash/kup-booke.h
+++ b/arch/powerpc/include/asm/nohash/kup-booke.h
@@ -58,12 +58,10 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 
 static inline unsigned long __kuap_get_and_assert_locked(void)
 {
-   unsigned long kuap = mfspr(SPRN_PID);
-
if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   WARN_ON_ONCE(kuap);
+   WARN_ON_ONCE(mfspr(SPRN_PID));
 
-   return kuap;
+   return 0;
 }
 
 static inline void __allow_user_access(void __user *to, const void __user 
*from,
-- 
2.40.1



[PATCH] powerpc/interrupt: Don't read MSR from interrupt_exit_kernel_prepare()

2023-06-05 Thread Christophe Leroy
A disassembly of interrupt_exit_kernel_prepare() shows a useless read
of MSR register. This is shown by r9 being re-used immediately without
doing anything with the value read.

  c000e0e0:   60 00 00 00 nop
  c000e0e4:   7d 3a c2 a6 mfmd_ap r9
  c000e0e8:   7d 20 00 a6 mfmsr   r9
  c000e0ec:   7c 51 13 a6 mtspr   81,r2
  c000e0f0:   81 3f 00 84 lwz r9,132(r31)
  c000e0f4:   71 29 80 00 andi.   r9,r9,32768

This is due to the use of local_irq_save(). The flags read by
local_irq_save() are never used, use local_irq_disable() instead.

Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up 
return from interrupt")
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/interrupt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index e34c72285b4e..f3fc5fe919d9 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -368,7 +368,6 @@ void preempt_schedule_irq(void);
 
 notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs)
 {
-   unsigned long flags;
unsigned long ret = 0;
unsigned long kuap;
bool stack_store = read_thread_flags() & _TIF_EMULATE_STACK_STORE;
@@ -392,7 +391,7 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs)
 
kuap = kuap_get_and_assert_locked();
 
-   local_irq_save(flags);
+   local_irq_disable();
 
if (!arch_irq_disabled_regs(regs)) {
/* Returning to a kernel context with local irqs enabled. */
-- 
2.40.1



[PATCH] powerpc/signal32: Force inlining of __unsafe_save_user_regs() and save_tm_user_regs_unsafe()

2023-06-05 Thread Christophe Leroy
Looking at generated code for handle_signal32() shows calls to a
function called __unsafe_save_user_regs.constprop.0 while user access
is open.

And that __unsafe_save_user_regs.constprop.0 function has two nops at
the begining, allowing it to be traced, which is unexpected during
user access open window.

The solution could be to mark __unsafe_save_user_regs() no trace, but
to be on the safe side the most efficient is to flag it __always_inline
as already done for function __unsafe_restore_general_regs(). The
function is relatively small and only called twice, so the size
increase will remain in the noise.

Do the same with save_tm_user_regs_unsafe() as it may suffer the
same issue.

Fixes: ef75e7318294 ("powerpc/signal32: Transform save_user_regs() and 
save_tm_user_regs() in 'unsafe' version")
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/signal_32.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index c114c7f25645..7a718ed32b27 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -264,8 +264,9 @@ static void prepare_save_user_regs(int ctx_has_vsx_region)
 #endif
 }
 
-static int __unsafe_save_user_regs(struct pt_regs *regs, struct mcontext 
__user *frame,
-  struct mcontext __user *tm_frame, int 
ctx_has_vsx_region)
+static __always_inline int
+__unsafe_save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
+   struct mcontext __user *tm_frame, int 
ctx_has_vsx_region)
 {
unsigned long msr = regs->msr;
 
@@ -364,8 +365,9 @@ static void prepare_save_tm_user_regs(void)
current->thread.ckvrsave = mfspr(SPRN_VRSAVE);
 }
 
-static int save_tm_user_regs_unsafe(struct pt_regs *regs, struct mcontext 
__user *frame,
-   struct mcontext __user *tm_frame, unsigned 
long msr)
+static __always_inline int
+save_tm_user_regs_unsafe(struct pt_regs *regs, struct mcontext __user *frame,
+struct mcontext __user *tm_frame, unsigned long msr)
 {
/* Save both sets of general registers */
unsafe_save_general_regs(>thread.ckpt_regs, frame, failed);
@@ -444,8 +446,9 @@ static int save_tm_user_regs_unsafe(struct pt_regs *regs, 
struct mcontext __user
 #else
 static void prepare_save_tm_user_regs(void) { }
 
-static int save_tm_user_regs_unsafe(struct pt_regs *regs, struct mcontext 
__user *frame,
-   struct mcontext __user *tm_frame, unsigned 
long msr)
+static __always_inline int
+save_tm_user_regs_unsafe(struct pt_regs *regs, struct mcontext __user *frame,
+struct mcontext __user *tm_frame, unsigned long msr)
 {
return 0;
 }
-- 
2.40.1



[PATCH] powerpc/kcsan: Properly instrument arch_spin_unlock()

2023-05-29 Thread Christophe Leroy
The following boottime error is encountered with SMP kernel:

  kcsan: improperly instrumented type=(0): arch_spin_unlock(_spinlock)
  kcsan: improperly instrumented type=(0): spin_unlock(_spinlock)
  kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): 
arch_spin_unlock(_spinlock)
  kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): 
spin_unlock(_spinlock)
  kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | 
KCSAN_ACCESS_COMPOUND): arch_spin_unlock(_spinlock)
  kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | 
KCSAN_ACCESS_COMPOUND): spin_unlock(_spinlock)
  kcsan: selftest: test_barrier failed
  kcsan: selftest: 2/3 tests passed
  Kernel panic - not syncing: selftests failed

Properly instrument arch_spin_unlock() with kcsan_mb().

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

diff --git a/arch/powerpc/include/asm/simple_spinlock.h 
b/arch/powerpc/include/asm/simple_spinlock.h
index 9dcc7e9993b9..4dd12dcb9ef8 100644
--- a/arch/powerpc/include/asm/simple_spinlock.h
+++ b/arch/powerpc/include/asm/simple_spinlock.h
@@ -15,6 +15,7 @@
  * (the type definitions are in asm/simple_spinlock_types.h)
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -126,6 +127,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
 
 static inline void arch_spin_unlock(arch_spinlock_t *lock)
 {
+   kcsan_mb();
__asm__ __volatile__("# arch_spin_unlock\n\t"
PPC_RELEASE_BARRIER: : :"memory");
lock->slock = 0;
-- 
2.40.1



Bug: Write fault blocked by KUAP! in do_notify_resume()

2023-05-26 Thread Christophe Leroy
Can't find how that can happen.

I have:

CONFIG_PREEMPT_BUILD=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_RCU=y

We are inside an access_begin / access_end block.


[  380.407589] [ cut here ]
[  380.408019] Bug: Write fault blocked by KUAP!
[  380.408497] WARNING: CPU: 0 PID: 422 at arch/powerpc/mm/fault.c:228 
do_page_fault+0x510/0x78c
[  380.409353] CPU: 0 PID: 422 Comm: CORSurv Tainted: GW 
  6.4.0-rc2-s3k-dev-02274-gca69d28ba73c #328
[  380.409879] Hardware name: MCR3000_2G 8xx 0x50 CMPC885
[  380.410346] NIP:  c00135cc LR: c00135cc CTR: c0065b08
[  380.410834] REGS: cae53ce0 TRAP: 0700   Tainted: GW 
(6.4.0-rc2-s3k-dev-02274-gca69d28ba73c)
[  380.411335] MSR:  00021032   CR: 22e822d2  XER: 2000f701
[  380.414300]
[  380.414300] GPR00: c00135cc cae53da0 c26439c0 0021 c0a75d78 
0001 c0a75e88 1032
[  380.414300] GPR08: 0027  0001 921a5f00 22e822d2 
1002c9f4 0001 0005
[  380.414300] GPR16: 10025760   100254bc 10024eec 
  0004
[  380.414300] GPR24: 0006 10025770 100100cc c26c8d80 7fab7b50 
0200 0300 cae53de0
[  380.428316] NIP [c00135cc] do_page_fault+0x510/0x78c
[  380.429005] LR [c00135cc] do_page_fault+0x510/0x78c
[  380.429673] Call Trace:
[  380.430115] [cae53da0] [c00135cc] do_page_fault+0x510/0x78c (unreliable)
[  380.431513] [cae53dd0] [c0003ac4] DataTLBError_virt+0x114/0x118
[  380.432546] --- interrupt: 300 at 
__unsafe_save_user_regs.constprop.0+0x24/0x88
[  380.433231] NIP:  c000656c LR: c0006980 CTR: 0006
[  380.433714] REGS: cae53de0 TRAP: 0300   Tainted: GW 
(6.4.0-rc2-s3k-dev-02274-gca69d28ba73c)
[  380.434216] MSR:  9032   CR: 22084442  XER: 2000f701
[  380.437561] DAR: 7fab7b50 DSISR: 8a00
[  380.437561] GPR00: c0006980 cae53ea0 c26439c0 cae53f40 7fab7b50 
7fab7b30 001d 7fab8010
[  380.437561] GPR08: cae53f38 7fab7b50 cae53f40 918ffc00 22084442 
1002c9f4 0001 0005
[  380.437561] GPR16: 10025760   100254bc 10024eec 
  0004
[  380.437561] GPR24: 0006 10025770 100100cc cae53f40 cae53f40 
cae53ec8 c26439c0 7fab7b50
[  380.451991] NIP [c000656c] __unsafe_save_user_regs.constprop.0+0x24/0x88
[  380.452678] LR [c0006980] handle_signal32+0x9c/0x1a0
[  380.453329] --- interrupt: 300
[  380.453803] [cae53ea0] [10025770] 0x10025770 (unreliable)
[  380.455086] [cae53ec0] [c0008844] do_notify_resume+0x128/0x2cc
[  380.456149] [cae53f20] [c000df70] 
interrupt_exit_user_prepare_main+0x7c/0xd8
[  380.457205] [cae53f30] [c00120b4] ret_from_syscall+0xc/0x28
[  380.458249] --- interrupt: c00 at 0xff42e98
[  380.458809] NIP:  0ff42e98 LR: 0ff42e8c CTR: 0fdff244
[  380.459298] REGS: cae53f40 TRAP: 0c00   Tainted: GW 
(6.4.0-rc2-s3k-dev-02274-gca69d28ba73c)
[  380.459796] MSR:  d032   CR: 38084448  XER: 
2000f701
[  380.463473]
[  380.463473] GPR00: 001d 7fab8010 77fc34d0 0004  
  
[  380.463473] GPR08:  2009  7fab7ef0 28084842 
1002c9f4 0001 0005
[  380.463473] GPR16: 10025760   100254bc 10024eec 
  0004
[  380.463473] GPR24: 0006 10025770 100100cc 0fc425ec 1001048c 
7fab8048 10025558 10024ee8
[  380.477466] NIP [0ff42e98] 0xff42e98
[  380.478015] LR [0ff42e8c] 0xff42e8c
[  380.478546] --- interrupt: c00
[  380.479026] Code: 408201f8 807f0080 48033361 2c03 41a2ffc8 
2c1d 41820138 3c80c096 3884d5d0 3c60c096 3863d6bc 4800fa79 
<0fe0> 93410018 814203c8 714a0100
[  380.486263] ---[ end trace  ]---
[  380.492813]
[  380.547950] CORSurv[422]: bad frame in handle_signal32: 3e6b61e5 nip 
0ff42e98 lr 0ff42e8c


Any idea ?

Christophe


Re: [RFC PATCH] powerpc/ftrace: Refactoring and support for -fpatchable-function-entry

2023-05-25 Thread Christophe Leroy


Le 23/05/2023 à 11:31, Naveen N Rao a écrit :
> Christophe Leroy wrote:
>>
>> That's better, but still more time than original implementation:
>>
>> +20% to activate function tracer (was +40% with your RFC)
>> +21% to activate nop tracer (was +24% with your RFC)
>>
>> perf record (without strict kernel rwx) :
>>
>>  17.75%  echo [kernel.kallsyms]   [k] ftrace_check_record
>>   9.76%  echo [kernel.kallsyms]   [k] ftrace_replace_code
>>   6.53%  echo [kernel.kallsyms]   [k] patch_instruction
>>   5.21%  echo [kernel.kallsyms]   [k] __ftrace_hash_rec_update
>>   4.26%  echo [kernel.kallsyms]   [k] ftrace_get_addr_curr
>>   4.18%  echo [kernel.kallsyms]   [k] ftrace_get_call_inst.isra.0
>>   3.45%  echo [kernel.kallsyms]   [k] ftrace_get_addr_new
>>   3.08%  echo [kernel.kallsyms]   [k] function_trace_call
>>   2.20%  echo [kernel.kallsyms]   [k] 
>> __rb_reserve_next.constprop.0
>>   2.05%  echo [kernel.kallsyms]   [k] copy_page
>>   1.91%  echo [kernel.kallsyms]   [k] 
>> ftrace_create_branch_inst.constprop.0
>>   1.83%  echo [kernel.kallsyms]   [k] ftrace_rec_iter_next
>>   1.83%  echo [kernel.kallsyms]   [k] rb_commit
>>   1.69%  echo [kernel.kallsyms]   [k] ring_buffer_lock_reserve
>>   1.54%  echo [kernel.kallsyms]   [k] trace_function
>>   1.39%  echo [kernel.kallsyms]   [k] 
>> __call_rcu_common.constprop.0
>>   1.25%  echo ld-2.23.so  [.] do_lookup_x
>>   1.17%  echo [kernel.kallsyms]   [k] ftrace_rec_iter_record
>>   1.03%  echo [kernel.kallsyms]   [k] unmap_page_range
>>   0.95%  echo [kernel.kallsyms]   [k] flush_dcache_icache_page
>>   0.95%  echo [kernel.kallsyms]   [k] ftrace_lookup_ip
> 
> Ok, I simplified this further, and this is as close to the previous fast 
> path as we can get (applies atop the original RFC). The only difference 
> left is the ftrace_rec iterator.

That's not better, that's even slightly worse (less than 1%).

I will try to investigate why.

Christophe


Re: [RFC PATCH] powerpc/ftrace: Refactoring and support for -fpatchable-function-entry

2023-05-21 Thread Christophe Leroy


Le 20/05/2023 à 20:17, Naveen N Rao a écrit :
> Christophe Leroy wrote:
>>
>>
>> Le 20/05/2023 à 12:34, Christophe Leroy a écrit :
>>>
>>>
>>> Le 19/05/2023 à 21:26, Naveen N Rao a écrit :
>>>> [Vous ne recevez pas souvent de courriers de nav...@kernel.org. 
>>>> Découvrez pourquoi ceci est important à 
>>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> Refactor ftrace code and move to using ftrace_replace_code() to help
>>>> simplify and make the code more maintainable.
>>>>
>>>> - The existing ftrace.c code is moved to a separate file so that ppc64
>>>>    elfv1 and clang -pg only support continue. This makes it possible to
>>>>    converge ppc32 and ppc64 support further.
>>>> - Drop code to re-purpose compiler-generated long branches for ftrace
>>>>    use in support of large kernels. We still retain the ftrace stubs at
>>>>    the end of .text, so we now support kernels upto ~64MB.
>>>> - Add ftrace_init_nop() to keep boot-time validations and init separate
>>>>    from runtime.
>>>> - Implement ftrace_replace_code() to simplify overall ftrace setup. 
>>>> This
>>>>    will be especially useful when adding ability to nop out 'mflr r0'
>>>>    later, and for other subsequent ftrace features.
>>>> - Add support for -fpatchable-function-entry. On ppc64, this needs gcc
>>>>    v13.1 so that the nops are generated at LEP. This also moves 
>>>> ppc32 to
>>>>    using the same two-instruction sequence as that of ppc64.
>>>>
>>>> This applies atop patches 1-3 of Nick's series for elfv2 conversion, as
>>>> well as Nick's patch enabling -mprofile-kernel for elfv2 BE:
>>>> - 
>>>> https://lore.kernel.org/all/20230505071850.228734-1-npig...@gmail.com/
>>>> - https://lore.kernel.org/all/20230506011814.8766-1-npig...@gmail.com/
>>>>
>>>> This builds for me and passes a quick test, posting this as an early
>>>> RFC.
>>>>
>>>> Signed-off-by: Naveen N Rao 
>>>
>>> Looks good, works on PPC32 but I observed some performance 
>>> degradation, around 25% more time needed to activate function tracer 
>>> and around 10% more time needed to de-activate function tracer (by 
>>> writting function/nop into /sys/kernel/debug/tracing/current_tracer.
> 
> Thanks for the test!
> 
> I hadn't looked at the performance, though I was expecting it to be 
> better. On ppc64, I am actually not seeing much of a difference.
> 
>>
>>
>> perf record with your patch applied:
>>
>>  20.59%  echo [kernel.kallsyms]  [k] ftrace_check_record
>>  15.71%  echo [kernel.kallsyms]  [k] patch_instruction
>>   6.75%  echo [kernel.kallsyms]  [k] ftrace_replace_code
>>   4.30%  echo [kernel.kallsyms]  [k] __ftrace_hash_rec_update
>>   3.96%  echo [kernel.kallsyms]  [k] 
>> __rb_reserve_next.constprop.0
>>   3.20%  echo [kernel.kallsyms]  [k] 
>> ftrace_get_call_inst.isra.0
>>   2.62%  echo [kernel.kallsyms]  [k] ftrace_get_addr_new
>>   2.44%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_next
>>   2.15%  echo [kernel.kallsyms]  [k] function_trace_call
>>   2.09%  echo [kernel.kallsyms]  [k] rb_commit
>>   1.92%  echo [kernel.kallsyms]  [k] 
>> ring_buffer_unlock_commit
>>   1.69%  echo [kernel.kallsyms]  [k] ring_buffer_lock_reserve
>>   1.63%  echo [kernel.kallsyms]  [k] copy_page
>>   1.45%  echo [kernel.kallsyms]  [k] 
>> ftrace_create_branch_inst.constprop.0
>>   1.40%  echo [kernel.kallsyms]  [k] unmap_page_range
>>   1.34%  echo [kernel.kallsyms]  [k] mas_next_entry
>>   1.28%  echo ld-2.23.so [.] do_lookup_x
>>   1.22%  echo [kernel.kallsyms]  [k] ftrace_call
>>   1.05%  echo [kernel.kallsyms]  [k] trace_function
>>   0.99%  echo [kernel.kallsyms]  [k] ftrace_caller
>>   0.81%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_record
>>
>> perf record without your patch:
>>
>>  22.58%  echo [kernel.kallsyms]  [k] patch_instruction
>>  17.85%  echo [kernel.kallsyms]  [k] ftrace_check_record
>>  11.65%  echo [kernel.kallsyms]  [k] ftrace_replace_code
>>   6.76%  echo [kernel.kallsyms]  [k] ftrace_make_call
>>   6.68%  echo

Re: [RFC PATCH] powerpc/ftrace: Refactoring and support for -fpatchable-function-entry

2023-05-20 Thread Christophe Leroy


Le 20/05/2023 à 18:28, Christophe Leroy a écrit :
> 
> 
> Le 20/05/2023 à 12:34, Christophe Leroy a écrit :
>>
>>
>> Le 19/05/2023 à 21:26, Naveen N Rao a écrit :
>>> [Vous ne recevez pas souvent de courriers de nav...@kernel.org. 
>>> Découvrez pourquoi ceci est important à 
>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> Refactor ftrace code and move to using ftrace_replace_code() to help
>>> simplify and make the code more maintainable.
>>>
>>> - The existing ftrace.c code is moved to a separate file so that ppc64
>>>    elfv1 and clang -pg only support continue. This makes it possible to
>>>    converge ppc32 and ppc64 support further.
>>> - Drop code to re-purpose compiler-generated long branches for ftrace
>>>    use in support of large kernels. We still retain the ftrace stubs at
>>>    the end of .text, so we now support kernels upto ~64MB.
>>> - Add ftrace_init_nop() to keep boot-time validations and init separate
>>>    from runtime.
>>> - Implement ftrace_replace_code() to simplify overall ftrace setup. This
>>>    will be especially useful when adding ability to nop out 'mflr r0'
>>>    later, and for other subsequent ftrace features.
>>> - Add support for -fpatchable-function-entry. On ppc64, this needs gcc
>>>    v13.1 so that the nops are generated at LEP. This also moves ppc32 to
>>>    using the same two-instruction sequence as that of ppc64.
>>>
>>> This applies atop patches 1-3 of Nick's series for elfv2 conversion, as
>>> well as Nick's patch enabling -mprofile-kernel for elfv2 BE:
>>> - https://lore.kernel.org/all/20230505071850.228734-1-npig...@gmail.com/
>>> - https://lore.kernel.org/all/20230506011814.8766-1-npig...@gmail.com/
>>>
>>> This builds for me and passes a quick test, posting this as an early
>>> RFC.
>>>
>>> Signed-off-by: Naveen N Rao 
>>
>> Looks good, works on PPC32 but I observed some performance 
>> degradation, around 25% more time needed to activate function tracer 
>> and around 10% more time needed to de-activate function tracer (by 
>> writting function/nop into /sys/kernel/debug/tracing/current_tracer.
> 
> 
> perf record with your patch applied:
> 
>      20.59%  echo [kernel.kallsyms]  [k] ftrace_check_record
>      15.71%  echo [kernel.kallsyms]  [k] patch_instruction
>   6.75%  echo [kernel.kallsyms]  [k] ftrace_replace_code
>   4.30%  echo [kernel.kallsyms]  [k] __ftrace_hash_rec_update
>   3.96%  echo [kernel.kallsyms]  [k] 
> __rb_reserve_next.constprop.0
>   3.20%  echo [kernel.kallsyms]  [k] 
> ftrace_get_call_inst.isra.0
>   2.62%  echo [kernel.kallsyms]  [k] ftrace_get_addr_new
>   2.44%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_next
>   2.15%  echo [kernel.kallsyms]  [k] function_trace_call
>   2.09%  echo [kernel.kallsyms]  [k] rb_commit
>   1.92%  echo [kernel.kallsyms]  [k] ring_buffer_unlock_commit
>   1.69%  echo [kernel.kallsyms]  [k] ring_buffer_lock_reserve
>   1.63%  echo [kernel.kallsyms]  [k] copy_page
>   1.45%  echo [kernel.kallsyms]  [k] 
> ftrace_create_branch_inst.constprop.0
>   1.40%  echo [kernel.kallsyms]  [k] unmap_page_range
>   1.34%  echo [kernel.kallsyms]  [k] mas_next_entry
>   1.28%  echo ld-2.23.so [.] do_lookup_x
>   1.22%  echo [kernel.kallsyms]  [k] ftrace_call
>   1.05%  echo [kernel.kallsyms]  [k] trace_function
>   0.99%  echo [kernel.kallsyms]  [k] ftrace_caller
>   0.81%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_record
> 
> perf record without your patch:
> 
>      22.58%  echo [kernel.kallsyms]  [k] patch_instruction
>      17.85%  echo [kernel.kallsyms]  [k] ftrace_check_record
>      11.65%  echo [kernel.kallsyms]  [k] ftrace_replace_code
>   6.76%  echo [kernel.kallsyms]  [k] ftrace_make_call
>   6.68%  echo [kernel.kallsyms]  [k] __ftrace_hash_rec_update
>   3.50%  echo [kernel.kallsyms]  [k] ftrace_get_addr_curr
>   3.42%  echo [kernel.kallsyms]  [k] ftrace_get_addr_new
>   2.36%  echo [kernel.kallsyms]  [k] copy_page
>   1.22%  echo [kernel.kallsyms]  [k] __rb_reserve_next.constprop.0
>   1.22%  echo ld-2.23.so [.] do_lookup_x
>   1.06%  echo [kernel.kallsyms]  [k] ftrace_lookup_ip
>   0.73%  echo ld-2.23.so [.] _dl_relocate_object
>   0.65%  echo [kernel.kalls

Re: [RFC PATCH] powerpc/ftrace: Refactoring and support for -fpatchable-function-entry

2023-05-20 Thread Christophe Leroy


Le 20/05/2023 à 12:34, Christophe Leroy a écrit :
> 
> 
> Le 19/05/2023 à 21:26, Naveen N Rao a écrit :
>> [Vous ne recevez pas souvent de courriers de nav...@kernel.org. 
>> Découvrez pourquoi ceci est important à 
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Refactor ftrace code and move to using ftrace_replace_code() to help
>> simplify and make the code more maintainable.
>>
>> - The existing ftrace.c code is moved to a separate file so that ppc64
>>    elfv1 and clang -pg only support continue. This makes it possible to
>>    converge ppc32 and ppc64 support further.
>> - Drop code to re-purpose compiler-generated long branches for ftrace
>>    use in support of large kernels. We still retain the ftrace stubs at
>>    the end of .text, so we now support kernels upto ~64MB.
>> - Add ftrace_init_nop() to keep boot-time validations and init separate
>>    from runtime.
>> - Implement ftrace_replace_code() to simplify overall ftrace setup. This
>>    will be especially useful when adding ability to nop out 'mflr r0'
>>    later, and for other subsequent ftrace features.
>> - Add support for -fpatchable-function-entry. On ppc64, this needs gcc
>>    v13.1 so that the nops are generated at LEP. This also moves ppc32 to
>>    using the same two-instruction sequence as that of ppc64.
>>
>> This applies atop patches 1-3 of Nick's series for elfv2 conversion, as
>> well as Nick's patch enabling -mprofile-kernel for elfv2 BE:
>> - https://lore.kernel.org/all/20230505071850.228734-1-npig...@gmail.com/
>> - https://lore.kernel.org/all/20230506011814.8766-1-npig...@gmail.com/
>>
>> This builds for me and passes a quick test, posting this as an early
>> RFC.
>>
>> Signed-off-by: Naveen N Rao 
> 
> Looks good, works on PPC32 but I observed some performance degradation, 
> around 25% more time needed to activate function tracer and around 10% 
> more time needed to de-activate function tracer (by writting 
> function/nop into /sys/kernel/debug/tracing/current_tracer.


perf record with your patch applied:

 20.59%  echo [kernel.kallsyms]  [k] ftrace_check_record
 15.71%  echo [kernel.kallsyms]  [k] patch_instruction
  6.75%  echo [kernel.kallsyms]  [k] ftrace_replace_code
  4.30%  echo [kernel.kallsyms]  [k] __ftrace_hash_rec_update
  3.96%  echo [kernel.kallsyms]  [k] 
__rb_reserve_next.constprop.0
  3.20%  echo [kernel.kallsyms]  [k] ftrace_get_call_inst.isra.0
  2.62%  echo [kernel.kallsyms]  [k] ftrace_get_addr_new
  2.44%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_next
  2.15%  echo [kernel.kallsyms]  [k] function_trace_call
  2.09%  echo [kernel.kallsyms]  [k] rb_commit
  1.92%  echo [kernel.kallsyms]  [k] ring_buffer_unlock_commit
  1.69%  echo [kernel.kallsyms]  [k] ring_buffer_lock_reserve
  1.63%  echo [kernel.kallsyms]  [k] copy_page
  1.45%  echo [kernel.kallsyms]  [k] 
ftrace_create_branch_inst.constprop.0
  1.40%  echo [kernel.kallsyms]  [k] unmap_page_range
  1.34%  echo [kernel.kallsyms]  [k] mas_next_entry
  1.28%  echo ld-2.23.so [.] do_lookup_x
  1.22%  echo [kernel.kallsyms]  [k] ftrace_call
  1.05%  echo [kernel.kallsyms]  [k] trace_function
  0.99%  echo [kernel.kallsyms]  [k] ftrace_caller
  0.81%  echo [kernel.kallsyms]  [k] ftrace_rec_iter_record

perf record without your patch:

 22.58%  echo [kernel.kallsyms]  [k] patch_instruction
 17.85%  echo [kernel.kallsyms]  [k] ftrace_check_record
 11.65%  echo [kernel.kallsyms]  [k] ftrace_replace_code
  6.76%  echo [kernel.kallsyms]  [k] ftrace_make_call
  6.68%  echo [kernel.kallsyms]  [k] __ftrace_hash_rec_update
  3.50%  echo [kernel.kallsyms]  [k] ftrace_get_addr_curr
  3.42%  echo [kernel.kallsyms]  [k] ftrace_get_addr_new
  2.36%  echo [kernel.kallsyms]  [k] copy_page
  1.22%  echo [kernel.kallsyms]  [k] __rb_reserve_next.constprop.0
  1.22%  echo ld-2.23.so [.] do_lookup_x
  1.06%  echo [kernel.kallsyms]  [k] ftrace_lookup_ip
  0.73%  echo ld-2.23.so [.] _dl_relocate_object
  0.65%  echo [kernel.kallsyms]  [k] flush_dcache_icache_page
  0.65%  echo [kernel.kallsyms]  [k] function_trace_call


Re: [RFC PATCH] powerpc/ftrace: Refactoring and support for -fpatchable-function-entry

2023-05-20 Thread Christophe Leroy


Le 19/05/2023 à 21:26, Naveen N Rao a écrit :
> [Vous ne recevez pas souvent de courriers de nav...@kernel.org. Découvrez 
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Refactor ftrace code and move to using ftrace_replace_code() to help
> simplify and make the code more maintainable.
> 
> - The existing ftrace.c code is moved to a separate file so that ppc64
>elfv1 and clang -pg only support continue. This makes it possible to
>converge ppc32 and ppc64 support further.
> - Drop code to re-purpose compiler-generated long branches for ftrace
>use in support of large kernels. We still retain the ftrace stubs at
>the end of .text, so we now support kernels upto ~64MB.
> - Add ftrace_init_nop() to keep boot-time validations and init separate
>from runtime.
> - Implement ftrace_replace_code() to simplify overall ftrace setup. This
>will be especially useful when adding ability to nop out 'mflr r0'
>later, and for other subsequent ftrace features.
> - Add support for -fpatchable-function-entry. On ppc64, this needs gcc
>v13.1 so that the nops are generated at LEP. This also moves ppc32 to
>using the same two-instruction sequence as that of ppc64.
> 
> This applies atop patches 1-3 of Nick's series for elfv2 conversion, as
> well as Nick's patch enabling -mprofile-kernel for elfv2 BE:
> - https://lore.kernel.org/all/20230505071850.228734-1-npig...@gmail.com/
> - https://lore.kernel.org/all/20230506011814.8766-1-npig...@gmail.com/
> 
> This builds for me and passes a quick test, posting this as an early
> RFC.
> 
> Signed-off-by: Naveen N Rao 

Looks good, works on PPC32 but I observed some performance degradation, 
around 25% more time needed to activate function tracer and around 10% 
more time needed to de-activate function tracer (by writting 
function/nop into /sys/kernel/debug/tracing/current_tracer.

Note that the trampoline at end of .text is only on PPC64 at the moment, 
so if PPC32 kernel goes beyond 32M we will have a problem (it happens 
with allyesconfig). It should be easy to extend it to PPC32.

At the begining of ftrace_replace_code(), don't you miss:

if (unlikely(ftrace_disabled))
return;

Below fix needed in order to build:

diff --git a/arch/powerpc/kernel/trace/ftrace.c 
b/arch/powerpc/kernel/trace/ftrace.c
index a9d57f338bd7..81d5bd69b660 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -96,7 +96,6 @@ static unsigned long find_ftrace_tramp(unsigned long ip)

  static int ftrace_get_call_inst(struct dyn_ftrace *rec, unsigned long 
addr, ppc_inst_t *call_inst)
  {
-   struct module *mod = rec->arch.mod;
unsigned long ip = rec->ip;
unsigned long stub;

@@ -112,7 +111,11 @@ static int ftrace_get_call_inst(struct dyn_ftrace 
*rec, unsigned long addr, ppc_
}
} else if (IS_ENABLED(CONFIG_MODULES)) {
/* Module code would be going to one of the module stubs */
+#ifdef CONFIG_MODULES
+   struct module *mod = rec->arch.mod;
+
stub = (addr == (unsigned long)ftrace_caller ? mod->arch.tramp 
: 
mod->arch.tramp_regs);
+#endif
} else {
return -EINVAL;
}


Christophe

> ---
>   arch/powerpc/Kconfig  |  10 +
>   arch/powerpc/Makefile |   5 +
>   arch/powerpc/include/asm/ftrace.h |  10 +-
>   arch/powerpc/include/asm/module.h |   4 -
>   arch/powerpc/kernel/trace/Makefile|   8 +-
>   arch/powerpc/kernel/trace/ftrace.c| 816 +
>   arch/powerpc/kernel/trace/ftrace_pg.c | 846 ++
>   .../gcc-check-fpatchable-function-entry.sh|  20 +
>   8 files changed, 1106 insertions(+), 613 deletions(-)
>   create mode 100644 arch/powerpc/kernel/trace/ftrace_pg.c
>   create mode 100755 arch/powerpc/tools/gcc-check-fpatchable-function-entry.sh
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 902b6b99f7ecd5..6db94723af7d30 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -187,6 +187,7 @@ config PPC
>  select DYNAMIC_FTRACE   if FUNCTION_TRACER
>  select EDAC_ATOMIC_SCRUB
>  select EDAC_SUPPORT
> +   select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if 
> ARCH_USING_PATCHABLE_FUNCTION_ENTRY
>  select GENERIC_ATOMIC64 if PPC32
>  select GENERIC_CLOCKEVENTS_BROADCASTif SMP
>  select GENERIC_CMOS_UPDATE
> @@ -552,6 +553,15 @@ config MPROFILE_KERNEL
>  def_bool 
> $(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) 
> -mlittle-endian) if CPU_LITTLE_ENDIAN
>  def_bool 
> $(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) 
> -mbig-endian) if CPU_BIG_ENDIAN
> 
> +config ARCH_HAS_PATCHABLE_FUNCTION_ENTRY_AT_LEP
> +   depends on PPC64_ELF_ABI_V2 && 

Re: [PATCH] mm: kfence: Fix false positives on big endian

2023-05-18 Thread Christophe Leroy


Le 18/05/2023 à 00:20, Andrew Morton a écrit :
> On Fri, 5 May 2023 16:02:17 + David Laight  
> wrote:
> 
>> From: Michael Ellerman
>>> Sent: 05 May 2023 04:51
>>>
>>> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
>>> __kfence_alloc() and __kfence_free()"), kfence reports failures in
>>> random places at boot on big endian machines.
>>>
>>> The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the
>>> address of each byte in its value, so it needs to be byte swapped on big
>>> endian machines.
>>>
>>> The compiler is smart enough to do the le64_to_cpu() at compile time, so
>>> there is no runtime overhead.
>>>
>>> Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of 
>>> __kfence_alloc() and __kfence_free()")
>>> Signed-off-by: Michael Ellerman 
>>> ---
>>>   mm/kfence/kfence.h | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
>>> index 2aafc46a4aaf..392fb273e7bd 100644
>>> --- a/mm/kfence/kfence.h
>>> +++ b/mm/kfence/kfence.h
>>> @@ -29,7 +29,7 @@
>>>* canary of every 8 bytes is the same. 64-bit memory can be filled and 
>>> checked
>>>* at a time instead of byte by byte to improve performance.
>>>*/
>>> -#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^ 
>>> (u64)(0x0706050403020100))
>>> +#define KFENCE_CANARY_PATTERN_U64 ((u64)0x ^ 
>>> (u64)(le64_to_cpu(0x0706050403020100)))
>>
>> What at the (u64) casts for?
>> The constants should probably have a ul (or ull) suffix.
>>
> 
> I tried that, didn't fix the sparse warnings described at
> https://lkml.kernel.org/r/202305132244.dwzbucud-...@intel.com.
> 
> Michael, have you looked into this?
> 
> I'll merge it upstream - I guess we can live with the warnings for a while.
> 

sparse warning goes away with:

#define KFENCE_CANARY_PATTERN_U64 (0xULL ^ 
le64_to_cpu((__force __le64)0x0706050403020100))

Christophe


Re: next: gcc-8-ppc6xx_defconfig: ERROR: modpost: "__divdi3" [sound/pci/emu10k1/snd-emu10k1.ko] undefined!

2023-05-17 Thread Christophe Leroy


Le 17/05/2023 à 16:02, Naresh Kamboju a écrit :
> Linux next powerpc gcc-8 build failed on Linux next 20230516 and 20230517.
>   - build/gcc-8-ppc6xx_defconfig
> 
> Reported-by: Linux Kernel Functional Testing 
> 
> Build log:
> 
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build \
>ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- \
>'CC=sccache powerpc64le-linux-gnu-gcc' \
>'HOSTCC=sccache gcc'
> 
> ERROR: modpost: "__divdi3" [sound/pci/emu10k1/snd-emu10k1.ko] undefined!
> ERROR: modpost: "__udivdi3" [sound/pci/emu10k1/snd-emu10k1.ko] undefined!
> make[2]: *** [/builds/linux/scripts/Makefile.modpost:136:
> Module.symvers] Error 1
> make[2]: Target '__modpost' not remade because of errors.
> make[1]: *** [/builds/linux/Makefile:1978: modpost] Error 2

Problem introduced by commits:
bb5ceb43b7bf ("ALSA: emu10k1: fix non-zero mixer control defaults in 
highres mode")
1298bc978afb ("ALSA: emu10k1: enable bit-exact playback, part 1: DSP 
attenuation")

More exactly by :

+  defval = defval * 0x7fffLL / 100;

or

+  defval = defval * 0x8000LL / 100 - 1;


powerpc/32 doesn't expect raw 64 bits division.

You have to use function div_u64() as defined in include/linux/math64.h 
for this kind of operation.

Christophe


> 
> 
> links,
>   - 
> https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230517/testrun/17031706/suite/build/test/gcc-8-ppc6xx_defconfig/log
>   - 
> https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230517/testrun/17031706/suite/build/test/gcc-8-ppc6xx_defconfig/history/
> 
> Steps to reproduce:
> ===
> # To install tuxmake on your system globally:
> # sudo pip3 install -U tuxmake
> #
> # See https://docs.tuxmake.org/ for complete documentation.
> # Original tuxmake command with fragments listed below.
> 
>   tuxmake --runtime podman --target-arch powerpc --toolchain gcc-8
> --kconfig ppc6xx_defconfig
> 
> 
> --
> Linaro LKFT
> https://lkft.linaro.org


Re: [PATCH v2 6/6] powerpc/64: Rename entry_64.S to prom_entry_64.S

2023-05-15 Thread Christophe Leroy


Le 15/05/2023 à 15:17, Nicholas Piggin a écrit :
> On Mon May 15, 2023 at 2:45 PM AEST, Nicholas Piggin wrote:
>> This file contains only the enter_prom implementation now.
>> Trim includes and update header comment while we're here.
>>
>> Signed-off-by: Nicholas Piggin 
>> ---
>>   arch/powerpc/kernel/Makefile  |  8 +++--
>>   .../kernel/{entry_64.S => prom_entry_64.S}| 30 ++-
>>   scripts/head-object-list.txt  |  2 +-
>>   3 files changed, 9 insertions(+), 31 deletions(-)
>>   rename arch/powerpc/kernel/{entry_64.S => prom_entry_64.S} (73%)
>>
>> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
>> index ec70a1748506..f94c893e014d 100644
>> --- a/arch/powerpc/kernel/Makefile
>> +++ b/arch/powerpc/kernel/Makefile
>> @@ -209,10 +209,12 @@ CFLAGS_paca.o  += -fno-stack-protector
>>   
>>   obj-$(CONFIG_PPC_FPU)  += fpu.o
>>   obj-$(CONFIG_ALTIVEC)  += vector.o
>> -obj-$(CONFIG_PPC64) += entry_64.o
>> -obj-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE)+= prom_init.o
>>   
>> -extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE)  += prom_init_check
>> +ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE
>> +obj-y   += prom_init.o
>> +obj64-y += prom_entry_64.o
>> +extra-y += prom_init_check
>> +endif
> 
> Oops that doesn't work, obj64-y is merged into obj-y before this. Need
> to move that merge down below here.
> 
> Thanks,
> Nick


And instead of the ifdef/endif, you can:

obj-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init.o
obj64-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_entry_64.o
extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init_check


[PATCH 1/3][For 4.19/4.14] spi: spi-fsl-spi: automatically adapt bits-per-word in cpu mode

2023-05-15 Thread Christophe Leroy
From: Rasmus Villemoes 

(cherry picked from upstream af0e6242909c3c4297392ca3e94eff1b4db71a97)

Taking one interrupt for every byte is rather slow. Since the
controller is perfectly capable of transmitting 32 bits at a time,
change t->bits_per-word to 32 when the length is divisible by 4 and
large enough that the reduced number of interrupts easily compensates
for the one or two extra fsl_spi_setup_transfer() calls this causes.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Signed-off-by: Christophe Leroy 
---
 drivers/spi/spi-fsl-spi.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index 479d10dc6cb8..946b417f2d1c 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -357,12 +357,28 @@ static int fsl_spi_bufs(struct spi_device *spi, struct 
spi_transfer *t,
 static int fsl_spi_do_one_msg(struct spi_master *master,
  struct spi_message *m)
 {
+   struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(master);
struct spi_device *spi = m->spi;
struct spi_transfer *t, *first;
unsigned int cs_change;
const int nsecs = 50;
int status;
 
+   /*
+* In CPU mode, optimize large byte transfers to use larger
+* bits_per_word values to reduce number of interrupts taken.
+*/
+   if (!(mpc8xxx_spi->flags & SPI_CPM_MODE)) {
+   list_for_each_entry(t, >transfers, transfer_list) {
+   if (t->len < 256 || t->bits_per_word != 8)
+   continue;
+   if ((t->len & 3) == 0)
+   t->bits_per_word = 32;
+   else if ((t->len & 1) == 0)
+   t->bits_per_word = 16;
+   }
+   }
+
/* Don't allow changes if CS is active */
first = list_first_entry(>transfers, struct spi_transfer,
transfer_list);
-- 
2.40.1



[PATCH 1/2][For 5.15/5.10/5.4] spi: fsl-spi: Re-organise transfer bits_per_word adaptation

2023-05-15 Thread Christophe Leroy
(backported from upstream 8a5299a1278eadf1e08a598a5345c376206f171e)

For different reasons, fsl-spi driver performs bits_per_word
modifications for different reasons:
- On CPU mode, to minimise amount of interrupts
- On CPM/QE mode to work around controller byte order

For CPU mode that's done in fsl_spi_prepare_message() while
for CPM mode that's done in fsl_spi_setup_transfer().

Reunify all of it in fsl_spi_prepare_message(), and catch
impossible cases early through master's bits_per_word_mask
instead of returning EINVAL later.

Signed-off-by: Christophe Leroy 
Link: 
https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.le...@csgroup.eu
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-spi.c | 50 ++-
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index 1bad0ceac81b..f1d4aa310233 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -203,26 +203,6 @@ static int mspi_apply_cpu_mode_quirks(struct 
spi_mpc8xxx_cs *cs,
return bits_per_word;
 }
 
-static int mspi_apply_qe_mode_quirks(struct spi_mpc8xxx_cs *cs,
-   struct spi_device *spi,
-   int bits_per_word)
-{
-   /* CPM/QE uses Little Endian for words > 8
-* so transform 16 and 32 bits words into 8 bits
-* Unfortnatly that doesn't work for LSB so
-* reject these for now */
-   /* Note: 32 bits word, LSB works iff
-* tfcr/rfcr is set to CPMFCR_GBL */
-   if (spi->mode & SPI_LSB_FIRST &&
-   bits_per_word > 8)
-   return -EINVAL;
-   if (bits_per_word <= 8)
-   return bits_per_word;
-   if (bits_per_word == 16 || bits_per_word == 32)
-   return 8; /* pretend its 8 bits */
-   return -EINVAL;
-}
-
 static int fsl_spi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
 {
@@ -250,9 +230,6 @@ static int fsl_spi_setup_transfer(struct spi_device *spi,
bits_per_word = mspi_apply_cpu_mode_quirks(cs, spi,
   mpc8xxx_spi,
   bits_per_word);
-   else
-   bits_per_word = mspi_apply_qe_mode_quirks(cs, spi,
- bits_per_word);
 
if (bits_per_word < 0)
return bits_per_word;
@@ -370,14 +347,27 @@ static int fsl_spi_do_one_msg(struct spi_master *master,
 * In CPU mode, optimize large byte transfers to use larger
 * bits_per_word values to reduce number of interrupts taken.
 */
-   if (!(mpc8xxx_spi->flags & SPI_CPM_MODE)) {
-   list_for_each_entry(t, >transfers, transfer_list) {
+   list_for_each_entry(t, >transfers, transfer_list) {
+   if (!(mpc8xxx_spi->flags & SPI_CPM_MODE)) {
if (t->len < 256 || t->bits_per_word != 8)
continue;
if ((t->len & 3) == 0)
t->bits_per_word = 32;
else if ((t->len & 1) == 0)
t->bits_per_word = 16;
+   } else {
+   /*
+* CPM/QE uses Little Endian for words > 8
+* so transform 16 and 32 bits words into 8 bits
+* Unfortnatly that doesn't work for LSB so
+* reject these for now
+* Note: 32 bits word, LSB works iff
+* tfcr/rfcr is set to CPMFCR_GBL
+*/
+   if (m->spi->mode & SPI_LSB_FIRST && t->bits_per_word > 
8)
+   return -EINVAL;
+   if (t->bits_per_word == 16 || t->bits_per_word == 32)
+   t->bits_per_word = 8; /* pretend its 8 bits */
}
}
 
@@ -635,8 +625,14 @@ static struct spi_master *fsl_spi_probe(struct device *dev,
if (mpc8xxx_spi->type == TYPE_GRLIB)
fsl_spi_grlib_probe(dev);
 
-   master->bits_per_word_mask =
-   (SPI_BPW_RANGE_MASK(4, 16) | SPI_BPW_MASK(32)) &
+   if (mpc8xxx_spi->flags & SPI_CPM_MODE)
+   master->bits_per_word_mask =
+   (SPI_BPW_RANGE_MASK(4, 8) | SPI_BPW_MASK(16) | 
SPI_BPW_MASK(32));
+   else
+   master->bits_per_word_mask =
+   (SPI_BPW_RANGE_MASK(4, 16) | SPI_BPW_MASK(32));
+
+   master->bits_per_word_mask &=
SPI_BPW_RANGE_MASK(1, mpc8xxx_spi->max_bits_per_word);
 
if (mpc8xxx_spi->flags & SPI_QE_CPU_MODE)
-- 
2.40.1



[PATCH 2/3][For 4.19/4.14] spi: fsl-spi: Re-organise transfer bits_per_word adaptation

2023-05-15 Thread Christophe Leroy
(backported from upstream 8a5299a1278eadf1e08a598a5345c376206f171e)

For different reasons, fsl-spi driver performs bits_per_word
modifications for different reasons:
- On CPU mode, to minimise amount of interrupts
- On CPM/QE mode to work around controller byte order

For CPU mode that's done in fsl_spi_prepare_message() while
for CPM mode that's done in fsl_spi_setup_transfer().

Reunify all of it in fsl_spi_prepare_message(), and catch
impossible cases early through master's bits_per_word_mask
instead of returning EINVAL later.

Signed-off-by: Christophe Leroy 
Link: 
https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.le...@csgroup.eu
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-spi.c | 50 ++-
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index 946b417f2d1c..e08a11070c5c 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -201,26 +201,6 @@ static int mspi_apply_cpu_mode_quirks(struct 
spi_mpc8xxx_cs *cs,
return bits_per_word;
 }
 
-static int mspi_apply_qe_mode_quirks(struct spi_mpc8xxx_cs *cs,
-   struct spi_device *spi,
-   int bits_per_word)
-{
-   /* CPM/QE uses Little Endian for words > 8
-* so transform 16 and 32 bits words into 8 bits
-* Unfortnatly that doesn't work for LSB so
-* reject these for now */
-   /* Note: 32 bits word, LSB works iff
-* tfcr/rfcr is set to CPMFCR_GBL */
-   if (spi->mode & SPI_LSB_FIRST &&
-   bits_per_word > 8)
-   return -EINVAL;
-   if (bits_per_word <= 8)
-   return bits_per_word;
-   if (bits_per_word == 16 || bits_per_word == 32)
-   return 8; /* pretend its 8 bits */
-   return -EINVAL;
-}
-
 static int fsl_spi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
 {
@@ -248,9 +228,6 @@ static int fsl_spi_setup_transfer(struct spi_device *spi,
bits_per_word = mspi_apply_cpu_mode_quirks(cs, spi,
   mpc8xxx_spi,
   bits_per_word);
-   else
-   bits_per_word = mspi_apply_qe_mode_quirks(cs, spi,
- bits_per_word);
 
if (bits_per_word < 0)
return bits_per_word;
@@ -368,14 +345,27 @@ static int fsl_spi_do_one_msg(struct spi_master *master,
 * In CPU mode, optimize large byte transfers to use larger
 * bits_per_word values to reduce number of interrupts taken.
 */
-   if (!(mpc8xxx_spi->flags & SPI_CPM_MODE)) {
-   list_for_each_entry(t, >transfers, transfer_list) {
+   list_for_each_entry(t, >transfers, transfer_list) {
+   if (!(mpc8xxx_spi->flags & SPI_CPM_MODE)) {
if (t->len < 256 || t->bits_per_word != 8)
continue;
if ((t->len & 3) == 0)
t->bits_per_word = 32;
else if ((t->len & 1) == 0)
t->bits_per_word = 16;
+   } else {
+   /*
+* CPM/QE uses Little Endian for words > 8
+* so transform 16 and 32 bits words into 8 bits
+* Unfortnatly that doesn't work for LSB so
+* reject these for now
+* Note: 32 bits word, LSB works iff
+* tfcr/rfcr is set to CPMFCR_GBL
+*/
+   if (m->spi->mode & SPI_LSB_FIRST && t->bits_per_word > 
8)
+   return -EINVAL;
+   if (t->bits_per_word == 16 || t->bits_per_word == 32)
+   t->bits_per_word = 8; /* pretend its 8 bits */
}
}
 
@@ -658,8 +648,14 @@ static struct spi_master * fsl_spi_probe(struct device 
*dev,
if (mpc8xxx_spi->type == TYPE_GRLIB)
fsl_spi_grlib_probe(dev);
 
-   master->bits_per_word_mask =
-   (SPI_BPW_RANGE_MASK(4, 16) | SPI_BPW_MASK(32)) &
+   if (mpc8xxx_spi->flags & SPI_CPM_MODE)
+   master->bits_per_word_mask =
+   (SPI_BPW_RANGE_MASK(4, 8) | SPI_BPW_MASK(16) | 
SPI_BPW_MASK(32));
+   else
+   master->bits_per_word_mask =
+   (SPI_BPW_RANGE_MASK(4, 16) | SPI_BPW_MASK(32));
+
+   master->bits_per_word_mask &=
SPI_BPW_RANGE_MASK(1, mpc8xxx_spi->max_bits_per_word);
 
if (mpc8xxx_spi->flags & SPI_QE_CPU_MODE)
-- 
2.40.1



[PATCH 2/2][For 5.15/5.10/5.4] spi: fsl-cpm: Use 16 bit mode for large transfers with even size

2023-05-15 Thread Christophe Leroy
(cherry picked from upstream fc96ec826bced75cc6b9c07a4ac44bbf651337ab)

On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped as seen in a previous commit.

So, for large tranfers with an even size, allocate a temporary tx
buffer and byte-swap data before and after transfer.

This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.

For the time being, only do it on CPM1 as there must be a
trade-off between the CPM load reduction and the CPU load required
to byte swap the data.

Signed-off-by: Christophe Leroy 
Link: 
https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.le...@csgroup.eu
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-cpm.c | 23 +++
 drivers/spi/spi-fsl-spi.c |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index ee905880769e..7832ce330b29 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "spi-fsl-cpm.h"
 #include "spi-fsl-lib.h"
@@ -120,6 +121,21 @@ int fsl_spi_cpm_bufs(struct mpc8xxx_spi *mspi,
mspi->rx_dma = mspi->dma_dummy_rx;
mspi->map_rx_dma = 0;
}
+   if (t->bits_per_word == 16 && t->tx_buf) {
+   const u16 *src = t->tx_buf;
+   u16 *dst;
+   int i;
+
+   dst = kmalloc(t->len, GFP_KERNEL);
+   if (!dst)
+   return -ENOMEM;
+
+   for (i = 0; i < t->len >> 1; i++)
+   dst[i] = cpu_to_le16p(src + i);
+
+   mspi->tx = dst;
+   mspi->map_tx_dma = 1;
+   }
 
if (mspi->map_tx_dma) {
void *nonconst_tx = (void *)mspi->tx; /* shut up gcc */
@@ -173,6 +189,13 @@ void fsl_spi_cpm_bufs_complete(struct mpc8xxx_spi *mspi)
if (mspi->map_rx_dma)
dma_unmap_single(dev, mspi->rx_dma, t->len, DMA_FROM_DEVICE);
mspi->xfer_in_progress = NULL;
+
+   if (t->bits_per_word == 16 && t->rx_buf) {
+   int i;
+
+   for (i = 0; i < t->len; i += 2)
+   le16_to_cpus(t->rx_buf + i);
+   }
 }
 EXPORT_SYMBOL_GPL(fsl_spi_cpm_bufs_complete);
 
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index f1d4aa310233..63302e21e574 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -368,6 +368,9 @@ static int fsl_spi_do_one_msg(struct spi_master *master,
return -EINVAL;
if (t->bits_per_word == 16 || t->bits_per_word == 32)
t->bits_per_word = 8; /* pretend its 8 bits */
+   if (t->bits_per_word == 8 && t->len >= 256 &&
+   (mpc8xxx_spi->flags & SPI_CPM1))
+   t->bits_per_word = 16;
}
}
 
-- 
2.40.1



[PATCH 3/3][For 4.19/4.14] spi: fsl-cpm: Use 16 bit mode for large transfers with even size

2023-05-15 Thread Christophe Leroy
(cherry picked from upstream fc96ec826bced75cc6b9c07a4ac44bbf651337ab)

On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped as seen in a previous commit.

So, for large tranfers with an even size, allocate a temporary tx
buffer and byte-swap data before and after transfer.

This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.

For the time being, only do it on CPM1 as there must be a
trade-off between the CPM load reduction and the CPU load required
to byte swap the data.

Signed-off-by: Christophe Leroy 
Link: 
https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.le...@csgroup.eu
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-cpm.c | 23 +++
 drivers/spi/spi-fsl-spi.c |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index 8f7b26ec181e..0485593dc2f5 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "spi-fsl-cpm.h"
 #include "spi-fsl-lib.h"
@@ -124,6 +125,21 @@ int fsl_spi_cpm_bufs(struct mpc8xxx_spi *mspi,
mspi->rx_dma = mspi->dma_dummy_rx;
mspi->map_rx_dma = 0;
}
+   if (t->bits_per_word == 16 && t->tx_buf) {
+   const u16 *src = t->tx_buf;
+   u16 *dst;
+   int i;
+
+   dst = kmalloc(t->len, GFP_KERNEL);
+   if (!dst)
+   return -ENOMEM;
+
+   for (i = 0; i < t->len >> 1; i++)
+   dst[i] = cpu_to_le16p(src + i);
+
+   mspi->tx = dst;
+   mspi->map_tx_dma = 1;
+   }
 
if (mspi->map_tx_dma) {
void *nonconst_tx = (void *)mspi->tx; /* shut up gcc */
@@ -177,6 +193,13 @@ void fsl_spi_cpm_bufs_complete(struct mpc8xxx_spi *mspi)
if (mspi->map_rx_dma)
dma_unmap_single(dev, mspi->rx_dma, t->len, DMA_FROM_DEVICE);
mspi->xfer_in_progress = NULL;
+
+   if (t->bits_per_word == 16 && t->rx_buf) {
+   int i;
+
+   for (i = 0; i < t->len; i += 2)
+   le16_to_cpus(t->rx_buf + i);
+   }
 }
 EXPORT_SYMBOL_GPL(fsl_spi_cpm_bufs_complete);
 
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index e08a11070c5c..5e49fed487f8 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -366,6 +366,9 @@ static int fsl_spi_do_one_msg(struct spi_master *master,
return -EINVAL;
if (t->bits_per_word == 16 || t->bits_per_word == 32)
t->bits_per_word = 8; /* pretend its 8 bits */
+   if (t->bits_per_word == 8 && t->len >= 256 &&
+   (mpc8xxx_spi->flags & SPI_CPM1))
+   t->bits_per_word = 16;
}
}
 
-- 
2.40.1



Re: [PATCH 1/3] kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures

2023-05-12 Thread Christophe Leroy


Le 12/05/2023 à 18:09, Marco Elver a écrit :
> On Fri, 12 May 2023 at 17:31, Christophe Leroy
>  wrote:
>>
>> Activating KCSAN on a 32 bits architecture leads to the following
>> link-time failure:
>>
>>  LD  .tmp_vmlinux.kallsyms1
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_load':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_store':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_exchange':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_add':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_sub':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_and':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_or':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_xor':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_fetch_nand':
>>kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_strong':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_weak':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>powerpc64-linux-ld: kernel/kcsan/core.o: in function 
>> `__tsan_atomic64_compare_exchange_val':
>>kernel/kcsan/core.c:1273: undefined reference to 
>> `__atomic_compare_exchange_8'
>>
>> 32 bits architectures don't have 64 bits atomic builtins. Only
>> include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.
>>
>> Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
>> Suggested-by: Marco Elver 
>> Signed-off-by: Christophe Leroy 
> 
> Reviewed-by: Marco Elver 
> 
> Do you have your own tree to take this through with the other patches?

I don't have my own tree but I guess that it can be taken by Michael for 
6.5 via powerpc tree with acks from you and Max.

Michael is that ok for you ?

Christophe


[PATCH 2/3] powerpc/{32,book3e}: kcsan: Extend KCSAN Support

2023-05-12 Thread Christophe Leroy
From: Rohan McLure 

Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.

Boots and passes selftests on 32-bit and 64-bit platforms. See
documentation in Documentation/dev-tools/kcsan.rst for more information.

Signed-off-by: Rohan McLure 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 539d1f03ff42..2f6af3cb75d6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -211,7 +211,7 @@ config PPC
select HAVE_ARCH_KASAN  if PPC_RADIX_MMU
select HAVE_ARCH_KASAN  if PPC_BOOK3E_64
select HAVE_ARCH_KASAN_VMALLOC  if HAVE_ARCH_KASAN
-   select HAVE_ARCH_KCSAN  if PPC_BOOK3S_64
+   select HAVE_ARCH_KCSAN
select HAVE_ARCH_KFENCE if ARCH_SUPPORTS_DEBUG_PAGEALLOC
select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
select HAVE_ARCH_WITHIN_STACK_FRAMES
-- 
2.40.1



[PATCH 0/3] Extend KCSAN to all powerpc

2023-05-12 Thread Christophe Leroy
This series enables KCSAN on all powerpc.

To do this, a fix is required to KCSAN core.

Once that fix is done, the stubs can also be removed from xtensa.

It would be nice if patch 1 could go in v6.4 as a fix, then patches 2 and 3
could be handled separately in each architecture in next cycle.

Christophe Leroy (2):
  kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures
  xtensa: Remove 64 bits atomic builtins stubs

Rohan McLure (1):
  powerpc/{32,book3e}: kcsan: Extend KCSAN Support

 arch/powerpc/Kconfig  |  2 +-
 arch/xtensa/lib/Makefile  |  2 --
 arch/xtensa/lib/kcsan-stubs.c | 54 ---
 kernel/kcsan/core.c   |  2 ++
 4 files changed, 3 insertions(+), 57 deletions(-)
 delete mode 100644 arch/xtensa/lib/kcsan-stubs.c

-- 
2.40.1



[PATCH 3/3] xtensa: Remove 64 bits atomic builtins stubs

2023-05-12 Thread Christophe Leroy
The stubs were provided by commit 725aea873261 ("xtensa: enable KCSAN")
to make linker happy allthought they are not meant to be used at all.

KCSAN core has been fixed to not require them anymore on
32 bits architectures.

Then they can be removed.

Signed-off-by: Christophe Leroy 
---
 arch/xtensa/lib/Makefile  |  2 --
 arch/xtensa/lib/kcsan-stubs.c | 54 ---
 2 files changed, 56 deletions(-)
 delete mode 100644 arch/xtensa/lib/kcsan-stubs.c

diff --git a/arch/xtensa/lib/Makefile b/arch/xtensa/lib/Makefile
index 7ecef0519a27..23c22411d1d9 100644
--- a/arch/xtensa/lib/Makefile
+++ b/arch/xtensa/lib/Makefile
@@ -8,5 +8,3 @@ lib-y   += memcopy.o memset.o checksum.o \
   divsi3.o udivsi3.o modsi3.o umodsi3.o mulsi3.o umulsidi3.o \
   usercopy.o strncpy_user.o strnlen_user.o
 lib-$(CONFIG_PCI) += pci-auto.o
-lib-$(CONFIG_KCSAN) += kcsan-stubs.o
-KCSAN_SANITIZE_kcsan-stubs.o := n
diff --git a/arch/xtensa/lib/kcsan-stubs.c b/arch/xtensa/lib/kcsan-stubs.c
deleted file mode 100644
index 2b08faa62b86..
--- a/arch/xtensa/lib/kcsan-stubs.c
+++ /dev/null
@@ -1,54 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include 
-#include 
-
-void __atomic_store_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_load_8(const volatile void *p, int i)
-{
-   BUG();
-}
-
-u64 __atomic_exchange_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-bool __atomic_compare_exchange_8(volatile void *p1, void *p2, u64 v, bool b, 
int i1, int i2)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_add_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_sub_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_and_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_or_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_xor_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-
-u64 __atomic_fetch_nand_8(volatile void *p, u64 v, int i)
-{
-   BUG();
-}
-- 
2.40.1



[PATCH 1/3] kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures

2023-05-12 Thread Christophe Leroy
Activating KCSAN on a 32 bits architecture leads to the following
link-time failure:

LD  .tmp_vmlinux.kallsyms1
  powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_load':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_store':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_exchange':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_add':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_sub':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_and':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_or':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_xor':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_fetch_nand':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_strong':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_weak':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'
  powerpc64-linux-ld: kernel/kcsan/core.o: in function 
`__tsan_atomic64_compare_exchange_val':
  kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8'

32 bits architectures don't have 64 bits atomic builtins. Only
include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures.

Fixes: 0f8ad5f2e934 ("kcsan: Add support for atomic builtins")
Suggested-by: Marco Elver 
Signed-off-by: Christophe Leroy 
---
 kernel/kcsan/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index 5a60cc52adc0..8a7baf4e332e 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -1270,7 +1270,9 @@ static __always_inline void 
kcsan_atomic_builtin_memorder(int memorder)
 DEFINE_TSAN_ATOMIC_OPS(8);
 DEFINE_TSAN_ATOMIC_OPS(16);
 DEFINE_TSAN_ATOMIC_OPS(32);
+#ifdef CONFIG_64BIT
 DEFINE_TSAN_ATOMIC_OPS(64);
+#endif
 
 void __tsan_atomic_thread_fence(int memorder);
 void __tsan_atomic_thread_fence(int memorder)
-- 
2.40.1



Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

2023-05-12 Thread Christophe Leroy


Le 12/05/2023 à 17:16, Christophe Leroy a écrit :
> 
> 
> Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
>> [Vous ne recevez pas souvent de courriers de 
>> darkba...@linuxsystems.it. D?couvrez pourquoi ceci est important ? 
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
>>> #regzbot introduced: f4f3b7dedbe849
>>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
>>
>> It doesn't look like the aforementioned patch made its way into 6.3 yet:
>>
>> niko@talos2 ~/devel/linux-stable $ git branch
>> * linux-6.3.y
>>    master
>> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
>> patching file
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>> Hunk #1 succeeded at 227 (offset 15 lines).
>> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
>> patching file
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
>> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
> 
> As far as I can see that patch has no Fixes: tag, so it will unlikely be 
> automatically merged into stable.
> 
> Has anybody requested greg/sasha to get it into 6.3 ?
> 

In fact, it seems that patch is already part of 6.3:

$ git tag --contains f4f3b7dedbe8
v6.3
v6.3-rc5
v6.3-rc6
v6.3-rc7
v6.3.1
v6.3.2
v6.4-rc1


Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

2023-05-12 Thread Christophe Leroy


Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> [Vous ne recevez pas souvent de courriers de darkba...@linuxsystems.it. 
> D?couvrez pourquoi ceci est important ? 
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
>> #regzbot introduced: f4f3b7dedbe849
>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> 
> It doesn't look like the aforementioned patch made its way into 6.3 yet:
> 
> niko@talos2 ~/devel/linux-stable $ git branch
> * linux-6.3.y
>    master
> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> patching file
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> Hunk #1 succeeded at 227 (offset 15 lines).
> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> patching file
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).

As far as I can see that patch has no Fixes: tag, so it will unlikely be 
automatically merged into stable.

Has anybody requested greg/sasha to get it into 6.3 ?

Christophe


Re: [PATCH 0/4] powerpc/64: ELFv2 conversion

2023-05-05 Thread Christophe Leroy


Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
> This series has the steps to remove ELFv1 from the kernel build.
> Patch 1 is a build fix, 2 defaults everything to ELFv2, 3 is
> really a separate issue that concerns userspace. 4 removes v1
> support.

I see CONFIG_MPROFILE_KERNEL is restricted to LITTLE_ENDIAN. Is that 
correct ? Don't we have mprofile_kernel as well on BIG ENDIAN once 
switched to ABI v2 ? If so, can we drop the -pg based profiling 
completely, or is CLANG still not supporting mprofile_kernel ?

Christophe

> 
> Would like to try getting patch 1 in as a fix, then 2,3 merged in
> the next merge window.
> 
> Thanks,
> Nick
> 
> Nicholas Piggin (4):
>powerpc/64: Force ELFv2 when building with LLVM linker
>powerpc/64: Make ELFv2 the default for big-endian builds
>powerpc/64s: Remove support for ELFv1 little endian userspace
>powerpc/64: Remove support for kernel's built with ELFv1 ABI
> 
>   arch/powerpc/Kconfig | 21 --
>   arch/powerpc/Makefile| 15 +
>   arch/powerpc/boot/Makefile   |  4 +-
>   arch/powerpc/include/asm/code-patching.h | 36 ++
>   arch/powerpc/include/asm/elf.h   |  6 ++
>   arch/powerpc/include/asm/kfence.h|  4 --
>   arch/powerpc/include/asm/linkage.h   |  9 ---
>   arch/powerpc/include/asm/module.h|  3 -
>   arch/powerpc/include/asm/ppc_asm.h   | 38 +--
>   arch/powerpc/include/asm/ptrace.h| 17 +
>   arch/powerpc/include/asm/sections.h  |  4 --
>   arch/powerpc/include/asm/thread_info.h   |  6 +-
>   arch/powerpc/kernel/exceptions-64s.S |  2 +-
>   arch/powerpc/kernel/fadump.c |  6 +-
>   arch/powerpc/kernel/head_64.S|  5 +-
>   arch/powerpc/kernel/interrupt_64.S   |  4 --
>   arch/powerpc/kernel/kprobes.c| 39 +--
>   arch/powerpc/kernel/misc_64.S|  4 --
>   arch/powerpc/kernel/module.c |  8 ---
>   arch/powerpc/kernel/module_64.c  | 84 
>   arch/powerpc/kernel/trace/ftrace.c   | 10 ---
>   arch/powerpc/kernel/vdso/Makefile|  2 +-
>   arch/powerpc/kernel/vdso/gettimeofday.S  |  2 +-
>   arch/powerpc/kernel/vmlinux.lds.S|  8 ---
>   arch/powerpc/kvm/book3s_hv_rmhandlers.S  | 36 +-
>   arch/powerpc/kvm/book3s_interrupts.S | 14 ++--
>   arch/powerpc/kvm/book3s_rmhandlers.S | 12 +---
>   arch/powerpc/net/bpf_jit.h   |  6 --
>   arch/powerpc/net/bpf_jit_comp.c  | 14 ++--
>   arch/powerpc/net/bpf_jit_comp64.c| 13 ++--
>   arch/powerpc/platforms/Kconfig.cputype   |  6 --
>   drivers/crypto/vmx/Makefile  |  4 --
>   kernel/extable.c |  2 +-
>   kernel/trace/ftrace.c| 12 
>   34 files changed, 79 insertions(+), 377 deletions(-)
> 


Re: [RFC PATCH 4/4] powerpc/64: Remove support for kernel's built with ELFv1 ABI

2023-05-05 Thread Christophe Leroy


Le 05/05/2023 à 09:18, Nicholas Piggin a écrit :
> User code must still support ELFv1, e.g., see is_elf2_task().
> 
> This one should wait a while until ELFv2 fallout settles, so
> just posting it out of interest.

Can't ELFv1 user code run on an ELFv2 kernel ?

Christophe

> 
> Thanks,
> Nick
> ---
>   arch/powerpc/Kconfig | 19 --
>   arch/powerpc/Makefile| 15 +
>   arch/powerpc/boot/Makefile   |  4 +-
>   arch/powerpc/include/asm/code-patching.h | 36 ++
>   arch/powerpc/include/asm/kfence.h|  4 --
>   arch/powerpc/include/asm/linkage.h   |  9 ---
>   arch/powerpc/include/asm/module.h|  3 -
>   arch/powerpc/include/asm/ppc_asm.h   | 38 +--
>   arch/powerpc/include/asm/ptrace.h| 17 +
>   arch/powerpc/include/asm/sections.h  |  4 --
>   arch/powerpc/kernel/exceptions-64s.S |  2 +-
>   arch/powerpc/kernel/fadump.c |  6 +-
>   arch/powerpc/kernel/head_64.S|  5 +-
>   arch/powerpc/kernel/interrupt_64.S   |  4 --
>   arch/powerpc/kernel/kprobes.c| 39 +--
>   arch/powerpc/kernel/misc_64.S|  4 --
>   arch/powerpc/kernel/module.c |  8 ---
>   arch/powerpc/kernel/module_64.c  | 84 
>   arch/powerpc/kernel/trace/ftrace.c   | 10 ---
>   arch/powerpc/kernel/vdso/Makefile|  2 +-
>   arch/powerpc/kernel/vdso/gettimeofday.S  |  2 +-
>   arch/powerpc/kernel/vmlinux.lds.S|  8 ---
>   arch/powerpc/kvm/book3s_hv_rmhandlers.S  | 36 +-
>   arch/powerpc/kvm/book3s_interrupts.S | 14 ++--
>   arch/powerpc/kvm/book3s_rmhandlers.S | 12 +---
>   arch/powerpc/net/bpf_jit.h   |  6 --
>   arch/powerpc/net/bpf_jit_comp.c  | 14 ++--
>   arch/powerpc/net/bpf_jit_comp64.c| 13 ++--
>   arch/powerpc/platforms/Kconfig.cputype   |  6 --
>   drivers/crypto/vmx/Makefile  |  4 --
>   kernel/extable.c |  2 +-
>   kernel/trace/ftrace.c| 12 
>   32 files changed, 68 insertions(+), 374 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a64bfd9b8a1d..6cbcaf1d01a6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -1,9 +1,6 @@
>   # SPDX-License-Identifier: GPL-2.0
>   source "arch/powerpc/platforms/Kconfig.cputype"
>   
> -config CC_HAS_ELFV2
> - def_bool PPC64 && $(cc-option, -mabi=elfv2)
> -
>   config CC_HAS_PREFIXED
>   def_bool PPC64 && $(cc-option, -mcpu=power10 -mprefixed)
>   
> @@ -232,7 +229,6 @@ config PPC
>   select HAVE_EFFICIENT_UNALIGNED_ACCESS
>   select HAVE_FAST_GUP
>   select HAVE_FTRACE_MCOUNT_RECORD
> - select HAVE_FUNCTION_DESCRIPTORSif PPC64_ELF_ABI_V1
>   select HAVE_FUNCTION_ERROR_INJECTION
>   select HAVE_FUNCTION_GRAPH_TRACER
>   select HAVE_FUNCTION_TRACER
> @@ -623,21 +619,6 @@ config KEXEC_FILE
>   config ARCH_HAS_KEXEC_PURGATORY
>   def_bool KEXEC_FILE
>   
> -config PPC64_BIG_ENDIAN_ELF_ABI_V2
> - prompt "Build big-endian kernel using ELF ABI V2" if LD_IS_BFD && EXPERT
> - def_bool y
> - depends on PPC64 && CPU_BIG_ENDIAN
> - depends on CC_HAS_ELFV2
> - help
> -   This builds the kernel image using the "Power Architecture 64-Bit ELF
> -   V2 ABI Specification", which has a reduced stack overhead and faster
> -   function calls. This internal kernel ABI option does not affect
> -  userspace compatibility.
> -
> -   The V2 ABI is standard for 64-bit little-endian, but for big-endian
> -   it is less well tested by kernel and toolchain. However some distros
> -   build userspace this way, and it can produce a functioning kernel.
> -
>   config RELOCATABLE
>   bool "Build a relocatable kernel"
>   depends on PPC64 || (FLATMEM && (44x || PPC_85xx))
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index dca73f673d70..8ddc779e675f 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -72,10 +72,8 @@ endif
>   
>   ifdef CONFIG_PPC64
>   ifndef CONFIG_CC_IS_CLANG
> -cflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mabi=elfv1)
> -cflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mcall-aixdesc)
> -aflags-$(CONFIG_PPC64_ELF_ABI_V1)+= $(call cc-option,-mabi=elfv1)
> -aflags-$(CONFIG_PPC64_ELF_ABI_V2)+= -mabi=elfv2
> +#Is this even needed?
> +aflags-y += -mabi=elfv2
>   endif
>   endif
>   
> @@ -125,14 +123,7 @@ endif
>   endif
>   
>   CFLAGS-$(CONFIG_PPC64)  := $(call cc-option,-mtraceback=no)
> -ifdef CONFIG_PPC64_ELF_ABI_V2
> -CFLAGS-$(CONFIG_PPC64)   += $(call cc-option,-mabi=elfv2,$(call 
> cc-option,-mcall-aixdesc))
> -else
> -ifndef CONFIG_CC_IS_CLANG
> -CFLAGS-$(CONFIG_PPC64)   += $(call cc-option,-mabi=elfv1)
> -CFLAGS-$(CONFIG_PPC64)   += $(call cc-option,-mcall-aixdesc)
> -endif
> -endif
> +CFLAGS-$(CONFIG_PPC64)   

Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1

2023-05-03 Thread Christophe Leroy
+Rob as he's the commit's Author.

Le 03/05/2023 à 17:46, Christian Zigotzky a écrit :
> On 02 May 2023 at 11:28 am, Michael Ellerman wrote:
>> Christian Zigotzky  writes:
>>> Hello,
>>>
>>> Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 
>>> [2].
>>>
>>> The kernel hangs right after the booting Linux via __start() @
>>> 0x ...
>>>
>>> I was able to revert the PowerPC updates 6.4-1 [2] with the following
>>> command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1
>>>
>>> After a re-compiling, the kernel boots without any problems without the
>>> PowerPC updates 6.4-1 [2].
>>>
>>> Could you please explain me, what you have done in the boot area?
>> There's a few possibilities, but nothing obvious.
>>
>> To begin with can you please test the following commits?
>>
>> 77e69ee7ce07
>> e4ab08be5b49
>> eeac8ede1755
>>
>> cheers
> git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4
> 
> [master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded 
> "ranges" parsing"
>   1 file changed, 129 insertions(+), 37 deletions(-)
> 
> After a recompiling it boots without any problems.
> 
> e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing 
> is the bad commit.
> 
> Thanks


Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1

2023-05-02 Thread Christophe Leroy
Hello,

Le 02/05/2023 à 04:22, Christian Zigotzky a écrit :
> Hello,
> 
> Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 [2].
> 
> The kernel hangs right after the booting Linux via __start() @ 
> 0x ...
> 
> I was able to revert the PowerPC updates 6.4-1 [2] with the following 
> command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1
> 
> After a re-compiling, the kernel boots without any problems without the 
> PowerPC updates 6.4-1 [2].

You are reverting the entire powerpc changes, that's helpless.

Can you do a bisect ?

Thanks
Christophe

> 
> Could you please explain me, what you have done in the boot area?
> 
> Please find attached the kernel config.
> 
> Thanks,
> Christian
> 
> 
> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7


Re: [PATCH] powerpc: remove unneeded if-checks

2023-04-29 Thread Christophe Leroy


Le 29/04/2023 à 00:12, Tom Rix a écrit :
> For ppc64, gcc with W=1 reports
> arch/powerpc/platforms/cell/spu_base.c:330:17: error:
>suggest braces around empty body in an 'if' statement [-Werror=empty-body]
>330 | ;
>| ^
> arch/powerpc/platforms/cell/spu_base.c:333:17: error:
>suggest braces around empty body in an 'if' statement [-Werror=empty-body]
>333 | ;
>| ^
> 
> These if-checks do not do anything so remove them.
> 
> Signed-off-by: Tom Rix 

Fixes: 67207b9664a8 ("[PATCH] spufs: The SPU file system, base")

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/platforms/cell/spu_base.c | 6 --
>   1 file changed, 6 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/cell/spu_base.c 
> b/arch/powerpc/platforms/cell/spu_base.c
> index 7bd0b563e163..dea6f0f25897 100644
> --- a/arch/powerpc/platforms/cell/spu_base.c
> +++ b/arch/powerpc/platforms/cell/spu_base.c
> @@ -326,12 +326,6 @@ spu_irq_class_1(int irq, void *data)
>   if (stat & CLASS1_STORAGE_FAULT_INTR)
>   __spu_trap_data_map(spu, dar, dsisr);
>   
> - if (stat & CLASS1_LS_COMPARE_SUSPEND_ON_GET_INTR)
> - ;
> -
> - if (stat & CLASS1_LS_COMPARE_SUSPEND_ON_PUT_INTR)
> - ;
> -
>   spu->class_1_dsisr = 0;
>   spu->class_1_dar = 0;
>   


Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-28 Thread Christophe Leroy


Le 26/04/2023 à 14:29, Michael Ellerman a écrit :
> Joel Fernandes  writes:
>> On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou  wrote:
> ...
>>
>> Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
>> canary? Michael, is this an optimization? Adding Christophe as well
>> since it came in a few years ago via the following commit:
> 
> I think Christophe also answered these in his reply.
> 
> We do use a per-task canary, but because we don't have "current" in a
> register, we can't use the value in current for GCC.
> 
> In one of my replies I said a possible solution would be to keep current
> in a register on 64-bit, but we'd need to do that in addition to the
> paca, so that would consume another GPR which we'd need to think hard
> about.

An analysis was done here https://github.com/linuxppc/issues/issues/45 
showing that r14 is very little used.

> 
> There's another reason to have it in the paca, which is that the paca is
> always accessible, even when the MMU is off, whereas current isn't (in
> some situations).

Even now that powerpc is converted to CONFIG_THREAD_INFO_IN_TASK ?

Christophe


Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-25 Thread Christophe Leroy


Le 25/04/2023 à 13:06, Joel Fernandes a écrit :
> On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou  wrote:
>>
>> hi
>>
>> On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra  wrote:
>>>
>>> On Mon, Apr 24, 2023 at 02:55:11PM -0400, Joel Fernandes wrote:
>>>> This is amazing debugging Boqun, like a boss! One comment below:
>>>>
>>>>>>> Or something simple I haven't thought of? :)
>>>>>>
>>>>>> At what points can r13 change?  Only when some particular functions are
>>>>>> called?
>>>>>>
>>>>>
>>>>> r13 is the local paca:
>>>>>
>>>>>  register struct paca_struct *local_paca asm("r13");
>>>>>
>>>>> , which is a pointer to percpu data.
>>>>>
>>>>> So if a task schedule from one CPU to anotehr CPU, the value gets
>>>>> changed.
>>>>
>>>> It appears the whole issue, per your analysis, is that the stack
>>>> checking code in gcc should not cache or alias r13, and must read its
>>>> most up-to-date value during stack checking, as its value may have
>>>> changed during a migration to a new CPU.
>>>>
>>>> Did I get that right?
>>>>
>>>> IMO, even without a reproducer, gcc on PPC should just not do that,
>>>> that feels terribly broken for the kernel. I wonder what clang does,
>>>> I'll go poke around with compilerexplorer after lunch.
>>>>
>>>> Adding +Peter Zijlstra as well to join the party as I have a feeling
>>>> he'll be interested. ;-)
>>>
>>> I'm a little confused; the way I understand the whole stack protector
>>> thing to work is that we push a canary on the stack at call and on
>>> return check it is still valid. Since in general tasks randomly migrate,
>>> the per-cpu validation canary should be the same on all CPUs.
>>>
>>> Additionally, the 'new' __srcu_read_{,un}lock_nmisafe() functions use
>>> raw_cpu_ptr() to get 'a' percpu sdp, preferably that of the local cpu,
>>> but no guarantees.
>>>
>>> Both cases use r13 (paca) in a racy manner, and in both cases it should
>>> be safe.
>> New test results today: both gcc build from git (git clone
>> git://gcc.gnu.org/git/gcc.git) and Ubuntu 22.04 gcc-12.1.0
>> are immune from the above issue. We can see the assembly code on
>> http://140.211.169.189/0425/srcu_gp_start_if_needed-gcc-12.txt
>>
>> while
>> Both native gcc on PPC vm (gcc version 9.4.0), and gcc cross compiler
>> on my x86 laptop (gcc version 10.4.0) will reproduce the bug.
> 
> Do you know what fixes the issue? I would not declare victory yet. My
> feeling is something changes in timing, or compiler codegen which
> hides the issue. So the issue is still there but it is just a matter
> of time before someone else reports it.
> 
> Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> canary? Michael, is this an optimization? Adding Christophe as well
> since it came in a few years ago via the following commit:

It uses per-task canary. But unlike PPC32, PPC64 doesn't have a fixed 
register pointing to 'current' at all time so the canary is copied into 
a per-cpu struct during _switch().

If GCC keeps an old value of the per-cpu struct pointer, it then gets 
the canary from the wrong CPU struct so from a different task.

Christophe

> 
> commit 06ec27aea9fc84d9c6d879eb64b5bcf28a8a1eb7
> Author: Christophe Leroy 
> Date:   Thu Sep 27 07:05:55 2018 +
> 
>  powerpc/64: add stack protector support
> 
>  On PPC64, as register r13 points to the paca_struct at all time,
>  this patch adds a copy of the canary there, which is copied at
>  task_switch.
>  That new canary is then used by using the following GCC options:
>  -mstack-protector-guard=tls
>  -mstack-protector-guard-reg=r13
>  -mstack-protector-guard-offset=offsetof(struct paca_struct, canary))
> 
>  Signed-off-by: Christophe Leroy 
>  Signed-off-by: Michael Ellerman 
> 
>   - Joel


Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-25 Thread Christophe Leroy


Le 25/04/2023 à 13:53, Peter Zijlstra a écrit :
> On Tue, Apr 25, 2023 at 06:59:29AM -0400, Joel Fernandes wrote:
>>> I'm a little confused; the way I understand the whole stack protector
>>> thing to work is that we push a canary on the stack at call and on
>>> return check it is still valid. Since in general tasks randomly migrate,
>>> the per-cpu validation canary should be the same on all CPUs.
> 
>> AFAICS, the canary is randomly chosen both in the kernel [1]. This
> 
> Yes, at boot, once. But thereafter it should be the same for all CPUs.

Each task has its own canary, stored in task struct :

kernel/fork.c:1012: tsk->stack_canary = get_random_canary();

On PPC32 we have register 'r2' that points to task struct at all time, 
so GCC is instructed to find canary at an offset from r2.

But on PPC64 we have no such register. Instead we have r13 that points 
to the PACA struct which is a per-cpu structure, and we have a pointer 
to 'current' task struct in the PACA struct. So in order to be able to 
have the canary as an offset of a fixed register as expected by GCC, we 
copy the task canary into the cpu's PACA struct during _switch():

addir6,r4,-THREAD   /* Convert THREAD to 'current' */
std r6,PACACURRENT(r13) /* Set new 'current' */
#if defined(CONFIG_STACKPROTECTOR)
ld  r6, TASK_CANARY(r6)
std r6, PACA_CANARY(r13)
#endif

The problem is that r13 will change if a task is switched to another 
CPU. But if GCC is using a copy of an older value of r13, then it will 
take the canary from another CPU's PACA struct hence it'll get the 
canary of the task running on that CPU instead of getting the canary of 
the current task running on the current CPU.

Christophe


Re: [PATCH] powerpc/bpf: populate extable entries only during the last pass

2023-04-07 Thread Christophe Leroy


Le 06/04/2023 à 09:35, Hari Bathini a écrit :
> Since commit 85e031154c7c ("powerpc/bpf: Perform complete extra passes
> to update addresses"), two additional passes are performed to avoid
> space and CPU time wastage on powerpc. But these extra passes led to
> WARN_ON_ONCE() hits in bpf_add_extable_entry(). Fix it by not adding
> extable entries during the extra pass.

Are you sure this change is correct ?
During the extra pass the code can get shrinked or expanded (within the 
limits of the size of the preliminary pass). Shouldn't extable entries 
be populated during the last pass ?

Christophe

> 
> Fixes: 85e031154c7c ("powerpc/bpf: Perform complete extra passes to update 
> addresses")
> Signed-off-by: Hari Bathini 
> ---
>   arch/powerpc/net/bpf_jit_comp32.c | 2 +-
>   arch/powerpc/net/bpf_jit_comp64.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/net/bpf_jit_comp32.c 
> b/arch/powerpc/net/bpf_jit_comp32.c
> index 7f91ea064c08..e788b1fbeee6 100644
> --- a/arch/powerpc/net/bpf_jit_comp32.c
> +++ b/arch/powerpc/net/bpf_jit_comp32.c
> @@ -977,7 +977,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, 
> struct codegen_context *
>   if (size != BPF_DW && !fp->aux->verifier_zext)
>   EMIT(PPC_RAW_LI(dst_reg_h, 0));
>   
> - if (BPF_MODE(code) == BPF_PROBE_MEM) {
> + if (BPF_MODE(code) == BPF_PROBE_MEM && !extra_pass) {
>   int insn_idx = ctx->idx - 1;
>   int jmp_off = 4;
>   
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c 
> b/arch/powerpc/net/bpf_jit_comp64.c
> index 8dd3cabaa83a..1cc2777ec846 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -921,7 +921,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, 
> struct codegen_context *
>   if (size != BPF_DW && insn_is_zext([i + 1]))
>   addrs[++i] = ctx->idx * 4;
>   
> - if (BPF_MODE(code) == BPF_PROBE_MEM) {
> + if (BPF_MODE(code) == BPF_PROBE_MEM && !extra_pass) {
>   ret = bpf_add_extable_entry(fp, image, pass, 
> ctx, ctx->idx - 1,
>   4, dst_reg);
>   if (ret)


Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs

2023-03-30 Thread Christophe Leroy


Le 28/03/2023 à 13:47, Michael Ellerman a écrit :
> "Nicholas Piggin"  writes:
>> On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote:
> ...
>>>
>>> Now that thread.regs doesn't change anymore at each interrupt, it would
>>> probably be worth dropping it and falling back to task_pt_regs() as
>>> defined on most architecture.
>>> Knowing whether a thread is a kernel or user thread can for instance be
>>> known with PF_KTHREAD flag, so no need of thread.regs for that.
>>
>> That would be nice if we can define regs that way, I agree. We should
>> look into doing that.
> 
> Yeah it's on the long-list of things that need cleaning up.
> 
> I think there's some complication in working out which sites are OK to
> use/give-out the value in pt_regs that's potentially a dummy value, vs
> cases that actually want to check PF_KTHREAD and do something different.
> But that's just my hunch I haven't looked through all the sites.
> 
> The thread.regs = NULL for kernel threads goes back to arch/ppc, about
> 2002 by the looks:
> 
>
> https://github.com/mpe/linux-fullhistory/commit/2a8e186c384c0c911f91cd12367658eabdc820d8#diff-939b705cff722ee75595fad30d56bb1175dfdce49a69adb4d5656f354be076c6
> 
> There's no change log of course :)
> 
> Still maybe it doesn't matter why it was originally done that way, if we
> can do it differently now.
> 

I have the feeling that our logic is broken after commit 5bd2e97c868a 
("fork: Generalize PF_IO_WORKER handling")

Christophe


Re: [PATCH 2/2] powerpc/64: Rename entry_64.S to prom_entry.S

2023-03-28 Thread Christophe Leroy


Le 28/03/2023 à 08:51, Nicholas Piggin a écrit :
> On Tue Mar 28, 2023 at 3:48 AM AEST, Christophe Leroy wrote:
>>
>>
>> Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
>>> This file contains only the enter_prom implementation now.
>>> Trim includes and update header comment while we're here.
>>>
>>> Signed-off-by: Nicholas Piggin 
>>> ---
>>>arch/powerpc/kernel/Makefile  |  8 +++--
>>>.../kernel/{entry_64.S => prom_entry.S}   | 30 ++-
>>>scripts/head-object-list.txt  |  2 +-
>>>3 files changed, 9 insertions(+), 31 deletions(-)
>>>rename arch/powerpc/kernel/{entry_64.S => prom_entry.S} (73%)
>>>
>>> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
>>> index ec70a1748506..ebba0896998a 100644
>>> --- a/arch/powerpc/kernel/Makefile
>>> +++ b/arch/powerpc/kernel/Makefile
>>> @@ -209,10 +209,12 @@ CFLAGS_paca.o += -fno-stack-protector
>>>
>>>obj-$(CONFIG_PPC_FPU)+= fpu.o
>>>obj-$(CONFIG_ALTIVEC)+= vector.o
>>> -obj-$(CONFIG_PPC64)+= entry_64.o
>>> -obj-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE)   += prom_init.o
>>>
>>> -extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init_check
>>> +ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE
>>
>> You don't need that ifdef construct, you can do:
>>
>> obj64-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_entry.o
> 
> Nice. So that could have been obj64-y from the start?

Yes, allthought it is not used that way in ppc/kernel/Makefile:

$ git grep -e obj64 -e obj32 arch/powerpc/kernel/Makefile
arch/powerpc/kernel/Makefile:obj64-$(CONFIG_HIBERNATION)+= 
swsusp_asm64.o
arch/powerpc/kernel/Makefile:obj64-$(CONFIG_AUDIT)  += 
compat_audit.o
arch/powerpc/kernel/Makefile:obj64-$(CONFIG_PPC_TRANSACTIONAL_MEM) 
+= tm.o
arch/powerpc/kernel/Makefile:obj-$(CONFIG_PPC64)+= 
$(obj64-y)
arch/powerpc/kernel/Makefile:obj-$(CONFIG_PPC32)+= 
$(obj32-y)

But it is in ppc/lib/Makefile:

$ git grep -e obj64 -e obj32 arch/powerpc/lib/Makefile
arch/powerpc/lib/Makefile:obj64-y   += copypage_64.o copyuser_64.o 
mem_64.o hweight_64.o \
arch/powerpc/lib/Makefile:obj64-$(CONFIG_SMP)   += locks.o
arch/powerpc/lib/Makefile:obj64-$(CONFIG_ALTIVEC)   += vmx-helper.o
arch/powerpc/lib/Makefile:obj64-$(CONFIG_KPROBES_SANITY_TEST)   += 
test_emulate_step.o \
arch/powerpc/lib/Makefile:obj64-y   += quad.o
arch/powerpc/lib/Makefile:obj-$(CONFIG_PPC64) += $(obj64-y)

Christophe


Re: [PATCH 2/2] powerpc/64: Rename entry_64.S to prom_entry.S

2023-03-27 Thread Christophe Leroy


Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> This file contains only the enter_prom implementation now.
> Trim includes and update header comment while we're here.
> 
> Signed-off-by: Nicholas Piggin 
> ---
>   arch/powerpc/kernel/Makefile  |  8 +++--
>   .../kernel/{entry_64.S => prom_entry.S}   | 30 ++-
>   scripts/head-object-list.txt  |  2 +-
>   3 files changed, 9 insertions(+), 31 deletions(-)
>   rename arch/powerpc/kernel/{entry_64.S => prom_entry.S} (73%)
> 
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ec70a1748506..ebba0896998a 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -209,10 +209,12 @@ CFLAGS_paca.o   += -fno-stack-protector
>   
>   obj-$(CONFIG_PPC_FPU)   += fpu.o
>   obj-$(CONFIG_ALTIVEC)   += vector.o
> -obj-$(CONFIG_PPC64)  += entry_64.o
> -obj-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init.o
>   
> -extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE)   += prom_init_check
> +ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE

You don't need that ifdef construct, you can do:

obj64-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_entry.o

> +obj-y+= prom_init.o
> +obj-$(CONFIG_PPC64)  += prom_entry.o
> +extra-y  += prom_init_check
> +endif
>   
>   quiet_cmd_prom_init_check = PROMCHK $@
> cmd_prom_init_check = $(CONFIG_SHELL) $< "$(NM)" $(obj)/prom_init.o; 
> touch $@


Christophe


Re: [PATCH 1/2] powerpc: merge 32-bit and 64-bit _switch implementation

2023-03-27 Thread Christophe Leroy


Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> The _switch stack frame setup are substantially the same, so are the
> comments. The difference in how the stack and current are switched,
> and other hardware and software housekeeping is done is moved into
> macros.
> 
> Signed-off-by: Nicholas Piggin 
> ---
> These patches are mostly just shuffling code around. Better? Worse?

I find it nice, at least for PPC32 part.

For PPC32 generated code is almost the same, only a few reordering at 
the start of the function.

Before the change I have:

0238 <_switch>:
  238:  94 21 ff 30 stwur1,-208(r1)
  23c:  7c 08 02 a6 mflrr0
  240:  90 01 00 d4 stw r0,212(r1)
  244:  91 a1 00 44 stw r13,68(r1)
...
  28c:  93 e1 00 8c stw r31,140(r1)
  290:  90 01 00 90 stw r0,144(r1)
  294:  7d 40 00 26 mfcrr10
  298:  91 41 00 a8 stw r10,168(r1)
  29c:  90 23 00 00 stw r1,0(r3)
  2a0:  3c 04 40 00 addis   r0,r4,16384
  2a4:  7c 13 43 a6 mtsprg  3,r0
...

After the change I have:

 <_switch>:
0:  7c 08 02 a6 mflrr0
4:  90 01 00 04 stw r0,4(r1)
8:  94 21 ff 30 stwur1,-208(r1)
c:  90 23 00 00 stw r1,0(r3)
   10:  91 a1 00 44 stw r13,68(r1)
...
   58:  93 e1 00 8c stw r31,140(r1)
   5c:  90 01 00 90 stw r0,144(r1)
   60:  7c 00 00 26 mfcrr0
   64:  90 01 00 a8 stw r0,168(r1)
   68:  3c 04 40 00 addis   r0,r4,16384
   6c:  7c 13 43 a6 mtsprg  3,r0
...

Everything else is identical.

Not sure, maybe re-using r1 immediately after stwu will introduce latency.

Christophe



Re: [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing

2023-03-27 Thread Christophe Leroy


Le 27/03/2023 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann 
> 
> The powerpc dma_sync_*_for_cpu() variants do more flushes than on other
> architectures. Reduce it to what everyone else does:
> 
>   - No flush is needed after data has been sent to a device
> 
>   - When data has been received from a device, the cache only needs to
> be invalidated to clear out cache lines that were speculatively
> prefetched.
> 
> In particular, the second flushing of partial cache lines of bidirectional
> buffers is actively harmful -- if a single cache line is written by both
> the CPU and the device, flushing it again does not maintain coherency
> but instead overwrite the data that was just received from the device.

Hum . Who is right ?

That behaviour was introduced by commit 03d70617b8a7 ("powerpc: Prevent 
memory corruption due to cache invalidation of unaligned DMA buffer")

I think your commit log should explain why that commit was wrong, and 
maybe say that your patch is a revert of that commit ?

Christophe


> 
> Signed-off-by: Arnd Bergmann 
> ---
>   arch/powerpc/mm/dma-noncoherent.c | 18 --
>   1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/powerpc/mm/dma-noncoherent.c 
> b/arch/powerpc/mm/dma-noncoherent.c
> index f10869d27de5..e108cacf877f 100644
> --- a/arch/powerpc/mm/dma-noncoherent.c
> +++ b/arch/powerpc/mm/dma-noncoherent.c
> @@ -132,21 +132,11 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t 
> size,
>   switch (direction) {
>   case DMA_NONE:
>   BUG();
> - case DMA_FROM_DEVICE:
> - /*
> -  * invalidate only when cache-line aligned otherwise there is
> -  * the potential for discarding uncommitted data from the cache
> -  */
> - if ((start | end) & (L1_CACHE_BYTES - 1))
> - __dma_phys_op(start, end, DMA_CACHE_FLUSH);
> - else
> - __dma_phys_op(start, end, DMA_CACHE_INVAL);
> - break;
> - case DMA_TO_DEVICE: /* writeback only */
> - __dma_phys_op(start, end, DMA_CACHE_CLEAN);
> + case DMA_TO_DEVICE:
>   break;
> - case DMA_BIDIRECTIONAL: /* writeback and invalidate */
> - __dma_phys_op(start, end, DMA_CACHE_FLUSH);
> + case DMA_FROM_DEVICE:
> + case DMA_BIDIRECTIONAL:
> + __dma_phys_op(start, end, DMA_CACHE_INVAL);
>   break;
>   }
>   }


Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs

2023-03-27 Thread Christophe Leroy


Le 27/03/2023 à 08:36, Nicholas Piggin a écrit :
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's have been created and
>> the task does something that causes a coredump to be generated. Then we
>> get this crash:
> 
> Hey Jens,
> 
> Thanks for the testing and the patch.
> 
> I think your patch would work, but I'd be inclined to give the IO worker
> a pt_regs so it looks more like other archs and a regular user thread.
> 
> Your IO worker bug reminded me to resurrect some copy_thread patches I
> had and I think they should do that
> 
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2023-March/256271.html
> 
> I wouldn't ask you to test it until I've at least tried, do you have a
> test case that triggers this?

I fact, most architectures don't have thread.regs, but rely on something 
like:

#define task_pt_regs(p) \
((struct pt_regs *)(THREAD_SIZE + task_stack_page(p)) - 1)


In powerpc, thread.regs was there because of the regs not being at the 
same place in the stack depending on which interrupt it was.

However with the two commits below, we now have stable fixed location 
for the regs, so thread.regs shouldn't be needed anymore:
- db297c3b07af ("powerpc/32: Don't save thread.regs on interrupt entry")
- b5cfc9cd7b04 ("powerpc/32: Fix critical and debug interrupts on BOOKE")

But in the meantime, thread.regs started to be used for additional 
purpose, like knowing if it is a user thread or a kernel thread by using 
thread.regs nullity.


Now that thread.regs doesn't change anymore at each interrupt, it would 
probably be worth dropping it and falling back to task_pt_regs() as 
defined on most architecture.
Knowing whether a thread is a kernel or user thread can for instance be 
known with PF_KTHREAD flag, so no need of thread.regs for that.

Christophe


Re: Memory coherency issue with IO thread offloading?

2023-03-24 Thread Christophe Leroy
Hi,

Le 23/03/2023 à 19:54, Jens Axboe a écrit :
> Hi,
> 
> I got a report sent to me from mariadb, in where 5.10.158 works fine and
> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
> case. Beware that this email is long, as I'm trying to include
> everything that may be relevant...

Which variant of powerpc ? 32 or 64 bits ? Book3S or BookE ?

Christophe


> 
> The test case in question is pretty simple. On debian testing, do:
> 
> $ sudo apt-get install mariadb-test
> $ cd /usr/share/mysql/mysql-test
> $ ./mtr --mysqld=--innodb-flush-method=fsync 
> --mysqld=--innodb-use-native-aio=1 --vardir=/dev/shm/mysql  --force 
> encryption.innodb_encryption,innodb,undo0 --repeat=200
> 
> and if it fails, you'll see something like:
> 
> encryption.innodb_encryption 'innodb,undo0' [ 6 pass ]   3120
> encryption.innodb_encryption 'innodb,undo0' [ 7 pass ]   3123
> encryption.innodb_encryption 'innodb,undo0' [ 8 pass ]   3042
> encryption.innodb_encryption 'innodb,undo0' [ 9 fail ]
>  Test ended at 2023-03-23 16:55:17
> 
> CURRENT_TEST: encryption.innodb_encryption
> mysqltest: At line 11: query 'SET @start_global_value = 
> @@global.innodb_encryption_threads' failed: ER_UNKNOWN_SYSTEM_VARIABLE 
> (1193): Unknown system variable 'innodb_encryption_threads'
> 
> The result from queries just before the failure was:
> SET @start_global_value = @@global.innodb_encryption_threads;
> 
>   - saving '/dev/shm/mysql/log/encryption.innodb_encryption-innodb,undo0/' to 
> '/dev/shm/mysql/log/encryption.innodb_encryption-innodb,undo0/'
> ***Warnings generated in error logs during shutdown after running tests: 
> encryption.innodb_encryption
> 
> 2023-03-23 16:55:17 0 [Warning] Plugin 'example_key_management' is of 
> maturity level experimental while the server is stable
> 2023-03-23 16:55:17 0 [ERROR] InnoDB: Database page corruption on disk or a 
> failed read of file './ibdata1' page [page id: space=0, page number=221]. You 
> may have to recover from a backup.
> 
> where data read was not as expected.
> 
> Now, there are a number of io_uring changes between .158 and .162, as it
> includes the backport that brought 5.10-stable into line with what
> 5.15-stable includes. I'll spare you all the digging I did to vet those
> changes, but the key thing is that it STILL happens on 6.3-git on
> powerpc.
> 
> After ruling out many things, one key difference between 158 and 162 is
> that the former offloaded requests that could not be done nonblocking to
> a kthread, and 162 and newer offloads to an IO thread. An IO thread is
> just a normal thread created from the application submitting IO, the
> only difference is that it never exits to userspace. An IO thread has
> the same mm/files/you-name-it from the original task. It really is the
> same as a userspace thread created by the application The switch to IO
> threads was done exactly because of that, rather than rely on a fragile
> scheme of having the kthread worker assume all sorts of identify from
> the original task. surprises if things were missed. This is what caused
> most of the io_uring security issues in the past.
> 
> The IO that mariadb does in this test is pretty simple - a bunch of
> largish buffered writes with IORING_OP_WRITEV, and some smallish (16K)
> buffered reads with IORING_OP_READV.
> 
> Today I finally gave up and ran a basic experiment, which simply
> offloads the writes to a kthread. Since powerpc has an interesting
> memory coherency model, my suspicion was that the work involved with
> switching MMs for the kthread could just be the main difference here.
> The patch is really dumb and simple - rather than queue the write to an
> IO thread, it just offloads it to a kthread that then does
> kthread_use_mm(), perform write with the same write handler,
> kthread_unuse_mm(). AND THIS WORKS! Usually the above mtr test would
> fail in 2..20 loops, I've now done 200 and 500 loops and it's fine.
> 
> Which then leads me to the question, what about the IO thread offload
> makes this fail on powerpc (and no other arch I've tested on, including
> x86/x86-64/aarch64/hppa64)? The offload should be equivalent to having a
> thread in userspace in the application, and having that thread just
> perform the writes. Is there some magic involved with the kthread mm
> use/unuse that makes this sufficiently consistent on powerpc? I've tried
> any mix of isync()/mb and making the flush_dcache_page() unconditionally
> done in the filemap read/write helpers, and it still falls flat on its
> face with the offload to an IO thread.
> 
> I must clearly be missing something here, which is why I'm emailing the
> powerpc Gods for help :-)
> 


Re: [PATCH v2] soc: fsl: qe: remove unused qe_ic_from_irq function

2023-03-20 Thread Christophe Leroy


Le 20/03/2023 à 13:52, Tom Rix a écrit :
> clang with W=1 reports
> drivers/soc/fsl/qe/qe_ic.c:235:29: error: unused function
>'qe_ic_from_irq' [-Werror,-Wunused-function]
> static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
>  ^
> The use of this function was removed with
> commit d7c2878cfcfa ("soc: fsl: qe: remove unused qe_ic_set_* functions")
> 
> This function is not used, so remove it.
> 
> Signed-off-by: Tom Rix 

Reviewed-by: Christophe Leroy 

> ---
> v2: Add to commit log when the use was removed.
> 
> ---
>   drivers/soc/fsl/qe/qe_ic.c | 5 -
>   1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
> index bbae3d39c7be..c0b4f865fba9 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -232,11 +232,6 @@ static inline void qe_ic_write(__be32  __iomem *base, 
> unsigned int reg,
>   iowrite32be(value, base + (reg >> 2));
>   }
>   
> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
> -{
> - return irq_get_chip_data(virq);
> -}
> -
>   static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>   {
>   return irq_data_get_irq_chip_data(d);


Re: [PATCH] soc: fsl: qe: remove unused qe_ic_from_irq function

2023-03-20 Thread Christophe Leroy


Le 19/03/2023 à 16:37, Tom Rix a écrit :
> clang with W=1 reports
> drivers/soc/fsl/qe/qe_ic.c:235:29: error: unused function
>'qe_ic_from_irq' [-Werror,-Wunused-function]
> static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
>  ^
> This function is not used, so remove it.

You should mention that it is not used anymore since commit d7c2878cfcfa 
("soc: fsl: qe: remove unused qe_ic_set_* functions")

> 
> Signed-off-by: Tom Rix 
> ---
>   drivers/soc/fsl/qe/qe_ic.c | 5 -
>   1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
> index bbae3d39c7be..c0b4f865fba9 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -232,11 +232,6 @@ static inline void qe_ic_write(__be32  __iomem *base, 
> unsigned int reg,
>   iowrite32be(value, base + (reg >> 2));
>   }
>   
> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
> -{
> - return irq_get_chip_data(virq);
> -}
> -
>   static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>   {
>   return irq_data_get_irq_chip_data(d);


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

2023-03-18 Thread Christophe Leroy


Le 17/03/2023 à 04:47, Matthew Wilcox a écrit :
> On Wed, Mar 15, 2023 at 10:18:22AM +0000, Christophe Leroy wrote:
>> I investigated a bit further and can confirm now that the above won't
>> always work, see comment
>> https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/32/pgtable.h#L147
>>
>> And then you see
>> https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/pte-e500.h#L63
> 
> Got it.  Here's what I intend to fold in for the next version:
> 
> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h 
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 7bf1fe7297c6..5f12b9382909 100644
> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -462,11 +462,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t 
> pgprot)
>pgprot_val(pgprot));
>   }
>   
> -static inline unsigned long pte_pfn(pte_t pte)
> -{
> - return pte_val(pte) >> PTE_RPN_SHIFT;
> -}
> -
>   /* Generic modifiers for PTE bits */
>   static inline pte_t pte_wrprotect(pte_t pte)
>   {
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 4acc9690f599..c5baa3082a5a 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -104,6 +104,7 @@
>* and every thing below PAGE_SHIFT;
>*/
>   #define PTE_RPN_MASK(((1UL << _PAGE_PA_MAX) - 1) & (PAGE_MASK))
> +#define PTE_RPN_SHIFTPAGE_SHIFT
>   /*
>* set of bits not changed in pmd_modify. Even though we have hash specific 
> bits
>* in here, on radix we expect them to be zero.
> @@ -569,11 +570,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t 
> pgprot)
>   return __pte(((pte_basic_t)pfn << PAGE_SHIFT) | pgprot_val(pgprot) | 
> _PAGE_PTE);
>   }
>   
> -static inline unsigned long pte_pfn(pte_t pte)
> -{
> - return (pte_val(pte) & PTE_RPN_MASK) >> PAGE_SHIFT;
> -}
> -
>   /* Generic modifiers for PTE bits */
>   static inline pte_t pte_wrprotect(pte_t pte)
>   {
> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h 
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 69a7dd47a9f0..03be8b22aaea 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -101,8 +101,6 @@ static inline bool pte_access_permitted(pte_t pte, bool 
> write)
>   static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot) {
>   return __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |
>pgprot_val(pgprot)); }
> -static inline unsigned long pte_pfn(pte_t pte)   {
> - return pte_val(pte) >> PTE_RPN_SHIFT; }
>   
>   /* Generic modifiers for PTE bits */
>   static inline pte_t pte_exprotect(pte_t pte)
> @@ -279,7 +277,7 @@ static inline int pud_huge(pud_t pud)
>   void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long 
> address,
>   pte_t *ptep, unsigned int nr);
>   #else
> -static inline void update_mmu_cache(struct vm_area_struct *vma,
> +static inline void update_mmu_cache_range(struct vm_area_struct *vma,
>   unsigned long address, pte_t *ptep, unsigned int nr) {}
>   #endif
>   
> diff --git a/arch/powerpc/include/asm/pgtable.h 
> b/arch/powerpc/include/asm/pgtable.h
> index 656ecf2b10cd..491a2720f835 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -54,6 +54,12 @@ void set_ptes(struct mm_struct *mm, unsigned long addr, 
> pte_t *ptep,
>   /* Keep these as a macros to avoid include dependency mess */
>   #define pte_page(x) pfn_to_page(pte_pfn(x))
>   #define mk_pte(page, pgprot)pfn_pte(page_to_pfn(page), (pgprot))
> +
> +static inline unsigned long pte_pfn(pte_t pte)
> +{
> + return (pte_val(pte) & PTE_RPN_MASK) >> PTE_RPN_SHIFT;
> +}
> +
>   /*
>* Select all bits except the pfn
>*/
> diff --git a/arch/powerpc/mm/nohash/e500_hugetlbpage.c 
> b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
> index f3cb91107a47..583b3098763f 100644
> --- a/arch/powerpc/mm/nohash/e500_hugetlbpage.c
> +++ b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
> @@ -178,7 +178,7 @@ book3e_hugetlb_preload(struct vm_area_struct *vma, 
> unsigned long ea, pte_t pte)
>*
>* This must always be called with the pte lock held.
>*/
> -void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
> +void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long 
> address,
>   pte_t *ptep, u

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

2023-03-15 Thread Christophe Leroy


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

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

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

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

Christophe


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

2023-03-15 Thread Christophe Leroy


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

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

2023-03-14 Thread Christophe Leroy
Hi,

Le 14/03/2023 à 09:31, ye.xingc...@zte.com.cn a écrit :
> From: Ye Xingchen 
> 
> crypto/algapi.h is included more than once.
> 
> Signed-off-by: Ye Xingchen 

You already sent this patch, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/202301171601080312...@zte.com.cn/

Any reason for resending ?

Christophe


> ---
>   arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c 
> b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> index c95f5b7cc456..1533c8cdd26f 100644
> --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
> +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> @@ -8,7 +8,6 @@
>   #include 
>   #include 
>   #include 
> -#include 
>   #include 
>   #include 
>   #include 


Re: Question about the dependency on the config SOC_FSL in CPM_QMC

2023-03-14 Thread Christophe Leroy
Hi Lukas

Le 14/03/2023 à 08:21, Lukas Bulwahn a écrit :
> Dear Herve,
> 
> In your patch below, you added the config CPM_QMC which depends on the
> non-existing config SOC_FSL:
> 
> https://lore.kernel.org/r/20230217145645.1768659-7-herve.cod...@bootlin.com
> 
> Up to my knowledge, the config SOC_FSL never existed in the mainline
> tree. Is this dependency really required or can the expression simply
> be reduced to COMPILE_TEST and we drop the dependency to SOC_FSL?

That's a mistake, should be FSL_SOC.

See 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230126083222.374243-7-herve.cod...@bootlin.com/#3058690

Christophe


Re: [PATCH v2 4/4] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free]

2023-03-11 Thread Christophe Leroy


Le 09/03/2023 à 19:02, Hari Bathini a écrit :
> Use bpf_jit_binary_pack_alloc in powerpc jit. The jit engine first
> writes the program to the rw buffer. When the jit is done, the program
> is copied to the final location with bpf_jit_binary_pack_finalize.
> With multiple jit_subprogs, bpf_jit_free is called on some subprograms
> that haven't got bpf_jit_binary_pack_finalize() yet. Implement custom
> bpf_jit_free() like in commit 1d5f82d9dd47 ("bpf, x86: fix freeing of
> not-finalized bpf_prog_pack") to call bpf_jit_binary_pack_finalize(),
> if necessary. While here, correct the misnomer powerpc64_jit_data to
> powerpc_jit_data as it is meant for both ppc32 and ppc64.

root@vgoip:~# echo 1 > /proc/sys/net/core/bpf_jit_enable
root@vgoip:~# insmod test_bpf.ko
[  570.270983] kernel tried to execute exec-protected page (bd42c198) - 
exploit attempt? (uid: 0)
[  570.279414] BUG: Unable to handle kernel instruction fetch
[  570.284822] Faulting instruction address: 0xbd42c198
[  570.289734] Oops: Kernel access of bad area, sig: 11 [#1]
[  570.295062] BE PAGE_SIZE=16K PREEMPT CMPC885
[  570.302811] Modules linked in: test_bpf(+) test_module
[  570.307891] CPU: 0 PID: 559 Comm: insmod Not tainted 
6.3.0-rc1-s3k-dev-g4ae0418b3500 #258
[  570.315975] Hardware name: MIAE 8xx 0x50 CMPC885
[  570.320882] NIP:  bd42c198 LR: be8180ec CTR: be818010
[  570.325873] REGS: cae2bc40 TRAP: 0400   Not tainted 
(6.3.0-rc1-s3k-dev-g4ae0418b3500)
[  570.333704] MSR:  40009032   CR: 88008222  XER: 
[  570.340503]
[  570.340503] GPR00: be806eac cae2bd00 c2977340  c2c40900 
 c1a18a80 
[  570.340503] GPR08: 0002 0001    
100d815e ca6a 0001
[  570.340503] GPR16: 1234 ca242250 c118 0001 1234aaab 
c9050030  
[  570.340503] GPR24: c2c40900    c1a18a80 
 0002 ca24225c
[  570.376819] NIP [bd42c198] 0xbd42c198
[  570.380436] LR [be8180ec] 0xbe8180ec
[  570.383965] Call Trace:
[  570.386373] [cae2bd00] [000b] 0xb (unreliable)
[  570.391107] [cae2bd50] [be806eac] __run_one+0x58/0x224 [test_bpf]
[  570.397390] [cae2bd90] [be80ca94] test_bpf_init+0x8d8/0x1010 [test_bpf]
[  570.404189] [cae2be20] [c00049f0] do_one_initcall+0x38/0x1e4
[  570.409782] [cae2be80] [c0090aa8] do_init_module+0x50/0x234
[  570.415291] [cae2bea0] [c0092e08] sys_finit_module+0xb4/0xf8
[  570.420884] [cae2bf20] [c000e344] system_call_exception+0x94/0x150
[  570.426995] [cae2bf30] [c00120a8] ret_from_syscall+0x0/0x28
[  570.432502] --- interrupt: c00 at 0xfd5fca0
[  570.436632] NIP:  0fd5fca0 LR: 10014568 CTR: 10013294
[  570.441625] REGS: cae2bf40 TRAP: 0c00   Not tainted 
(6.3.0-rc1-s3k-dev-g4ae0418b3500)
[  570.449455] MSR:  d032   CR: 44002224  XER: 

[  570.456513]
[  570.456513] GPR00: 0161 7f868d30 77ed34d0 0003 100bc4ef 
 0fd51868 d032
[  570.456513] GPR08: 07b1 10013294  0002 52454753 
100d815e 100a44b8 
[  570.456513] GPR16: 100d167c 100b 1198426c 119854cd 100d 
100d  100a4498
[  570.456513] GPR24: ffa2  11984244 0003 1198426c 
100bc4ef 11984288 1198426c
[  570.492828] NIP [0fd5fca0] 0xfd5fca0
[  570.496358] LR [10014568] 0x10014568
[  570.499887] --- interrupt: c00
[  570.502902] Code:      
        
  
[  570.517973] ---[ end trace  ]---
[  570.522523]
[  570.523986] note: insmod[559] exited with irqs disabled
Segmentation fault

Christophe

> 
> Signed-off-by: Hari Bathini 
> ---
>   arch/powerpc/net/bpf_jit.h|   7 +-
>   arch/powerpc/net/bpf_jit_comp.c   | 104 +-
>   arch/powerpc/net/bpf_jit_comp32.c |   4 +-
>   arch/powerpc/net/bpf_jit_comp64.c |   6 +-
>   4 files changed, 83 insertions(+), 38 deletions(-)
> 
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index d767e39d5645..a8b7480c4d43 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -168,15 +168,16 @@ static inline void bpf_clear_seen_register(struct 
> codegen_context *ctx, int i)
>   
>   void bpf_jit_init_reg_mapping(struct codegen_context *ctx);
>   int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 
> func);
> -int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct 
> codegen_context *ctx,
> +int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32 *fimage, struct 
> codegen_context *ctx,
>  u32 *addrs, int pass, bool extra_pass);
>   void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx);
>   void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx);
>   void bpf_jit_realloc_regs(struct codegen_context *ctx);
>   int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx, int 
> tmp_reg, long exit_addr);
>   
> -int bpf_add_extable_entry(struct 

Re: [PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()

2023-03-11 Thread Christophe Leroy


Le 09/03/2023 à 19:02, Hari Bathini a écrit :
> patch_instruction() entails setting up pte, patching the instruction,
> clearing the pte and flushing the tlb. If multiple instructions need
> to be patched, every instruction would have to go through the above
> drill unnecessarily. Instead, introduce function patch_instructions()
> that patches multiple instructions at one go while setting up the pte,
> clearing the pte and flushing the tlb only once per page range of
> instructions. Observed ~5X improvement in speed of execution using
> patch_instructions() over patch_instructions(), when more instructions
> are to be patched.
> 
> Signed-off-by: Hari Bathini 
> ---
>   arch/powerpc/include/asm/code-patching.h |   1 +
>   arch/powerpc/lib/code-patching.c | 151 ---
>   2 files changed, 106 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/code-patching.h 
> b/arch/powerpc/include/asm/code-patching.h
> index 3f881548fb61..059fc4fe700e 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
>   int patch_branch(u32 *addr, unsigned long target, int flags);
>   int patch_instruction(u32 *addr, ppc_inst_t instr);
>   int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
> +int patch_instructions(u32 *addr, u32 *code, bool fill_inst, size_t len);
>   
>   static inline unsigned long patch_site_addr(s32 *site)
>   {
> diff --git a/arch/powerpc/lib/code-patching.c 
> b/arch/powerpc/lib/code-patching.c
> index b00112d7ad46..33857b9b53de 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -278,77 +278,117 @@ static void unmap_patch_area(unsigned long addr)
>   flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>   }
>   
> -static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
> +static int __do_patch_instructions_mm(u32 *addr, u32 *code, bool fill_inst, 
> size_t len)

Some time ago we did a huge work to clean up use of u32 as code versus 
ppc_inst_t.

Please carefully audit all places where you use u32 instead of 
ppc_inst_t. If you do so, don't use anymore the word 'instruction' in 
the function name.

>   {
> - int err;
> - u32 *patch_addr;
> - unsigned long text_poke_addr;
> - pte_t *pte;
> - unsigned long pfn = get_patch_pfn(addr);
> - struct mm_struct *patching_mm;
> - struct mm_struct *orig_mm;
> + struct mm_struct *patching_mm, *orig_mm;

This change is cosmetic and not functionnaly liked to the patch.

> + unsigned long text_poke_addr, pfn;
> + u32 *patch_addr, *end, *pend;
> + ppc_inst_t instr;
>   spinlock_t *ptl;
> + int ilen, err;
> + pte_t *pte;

Why move this declaration ?

>   
>   patching_mm = __this_cpu_read(cpu_patching_context.mm);
>   text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
> - patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
>   
>   pte = get_locked_pte(patching_mm, text_poke_addr, );
>   if (!pte)
>   return -ENOMEM;
>   
> - __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn, 
> PAGE_KERNEL), 0);
> + end = (void *)addr + len;
> + do {
> + pfn = get_patch_pfn(addr);
> + __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn, 
> PAGE_KERNEL), 0);
>   
> - /* order PTE update before use, also serves as the hwsync */
> - asm volatile("ptesync": : :"memory");
> -
> - /* order context switch after arbitrary prior code */
> - isync();
> -
> - orig_mm = start_using_temp_mm(patching_mm);
> -
> - err = __patch_instruction(addr, instr, patch_addr);
> + /* order PTE update before use, also serves as the hwsync */
> + asm volatile("ptesync": : :"memory");
>   
> - /* hwsync performed by __patch_instruction (sync) if successful */
> - if (err)
> - mb();  /* sync */
> + /* order context switch after arbitrary prior code */
> + isync();
> +
> + orig_mm = start_using_temp_mm(patching_mm);
> +
> + patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
> + pend = (void *)addr + PAGE_SIZE - offset_in_page(addr);
> + if (end < pend)
> + pend = end;
> +
> + while (addr < pend) {
> + instr = ppc_inst_read(code);
> + ilen = ppc_inst_len(instr);
> + err = __patch_instruction(addr, instr, patch_addr);
> + /* hwsync performed by __patch_instruction (sync) if 
> successful */

As you aim at optimising the loops, you should before cache flushed 
outside this loop, with flush_dcache_range() and invalidate_dcache_range().

> + if (err) {
> + mb();  /* sync */
> + break;
> +

Re: [PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()

2023-03-10 Thread Christophe Leroy


Le 10/03/2023 à 19:26, Christophe Leroy a écrit :
> 
> 
> Le 09/03/2023 à 19:02, Hari Bathini a écrit :
>> patch_instruction() entails setting up pte, patching the instruction,
>> clearing the pte and flushing the tlb. If multiple instructions need
>> to be patched, every instruction would have to go through the above
>> drill unnecessarily. Instead, introduce function patch_instructions()
>> that patches multiple instructions at one go while setting up the pte,
>> clearing the pte and flushing the tlb only once per page range of
>> instructions. Observed ~5X improvement in speed of execution using
>> patch_instructions() over patch_instructions(), when more instructions
>> are to be patched.
> 
> I get a 13% degradation on the time needed to activate ftrace on a 
> powerpc 8xx.
> 
> Before your patch, activation ftrace takes 550k timebase ticks. After 
> your patch it takes 620k timebase ticks.
> 

More details about the problem:

Before your patch, patch_instruction() is a simple, stackless function 
(Note that the first branch is noped out after startup).

0254 :
  254:  48 00 00 6c b   2c0 
  258:  7c e0 00 a6 mfmsr   r7
  25c:  7c 51 13 a6 mtspr   81,r2
  260:  3d 40 00 00 lis r10,0
262: R_PPC_ADDR16_HA.data
  264:  39 4a 00 00 addir10,r10,0
266: R_PPC_ADDR16_LO.data
  268:  7c 69 1b 78 mr  r9,r3
  26c:  3d 29 40 00 addis   r9,r9,16384
  270:  81 0a 00 08 lwz r8,8(r10)
  274:  55 29 00 26 rlwinm  r9,r9,0,0,19
  278:  81 4a 00 04 lwz r10,4(r10)
  27c:  61 29 01 25 ori r9,r9,293
  280:  91 28 00 00 stw r9,0(r8)
  284:  55 49 00 26 rlwinm  r9,r10,0,0,19
  288:  50 6a 05 3e rlwimi  r10,r3,0,20,31
  28c:  90 8a 00 00 stw r4,0(r10)
  290:  7c 00 50 6c dcbst   0,r10
  294:  7c 00 04 ac hwsync
  298:  7c 00 1f ac icbi0,r3
  29c:  7c 00 04 ac hwsync
  2a0:  4c 00 01 2c isync
  2a4:  38 60 00 00 li  r3,0
  2a8:  39 40 00 00 li  r10,0
  2ac:  91 48 00 00 stw r10,0(r8)
  2b0:  7c 00 4a 64 tlbie   r9,r0
  2b4:  7c 00 04 ac hwsync
  2b8:  7c e0 01 24 mtmsr   r7
  2bc:  4e 80 00 20 blr

  2c0:  90 83 00 00 stw r4,0(r3)
  2c4:  7c 00 18 6c dcbst   0,r3
  2c8:  7c 00 04 ac hwsync
  2cc:  7c 00 1f ac icbi0,r3
  2d0:  7c 00 04 ac hwsync
  2d4:  4c 00 01 2c isync
  2d8:  38 60 00 00 li  r3,0
  2dc:  4e 80 00 20 blr
  2e0:  38 60 ff ff li  r3,-1
  2e4:  4b ff ff c4 b   2a8 
  2e8:  38 60 ff ff li  r3,-1
  2ec:  4e 80 00 20 blr


Once your patch is there, patch_instruction() becomes a function that 
has to step up a stack in order to call __do_patch_instructions().
And __do_patch_instructions() is quite a big function.

022c <__do_patch_instructions>:
  22c:  3d 20 00 00 lis r9,0
22e: R_PPC_ADDR16_HA.data
  230:  39 29 00 00 addir9,r9,0
232: R_PPC_ADDR16_LO.data
  234:  81 69 00 04 lwz r11,4(r9)
  238:  2c 05 00 00 cmpwi   r5,0
  23c:  81 89 00 08 lwz r12,8(r9)
  240:  7c c3 32 14 add r6,r3,r6
  244:  55 6b 00 26 rlwinm  r11,r11,0,0,19
  248:  38 00 00 00 li  r0,0
  24c:  54 6a 05 3e clrlwi  r10,r3,20
  250:  21 0a 10 00 subfic  r8,r10,4096
  254:  7d 03 42 14 add r8,r3,r8
  258:  7c 69 1b 78 mr  r9,r3
  25c:  7f 88 30 40 cmplw   cr7,r8,r6
  260:  3d 29 40 00 addis   r9,r9,16384
  264:  55 29 00 26 rlwinm  r9,r9,0,0,19
  268:  61 29 01 25 ori r9,r9,293
  26c:  91 2c 00 00 stw r9,0(r12)
  270:  7d 4a 5b 78 or  r10,r10,r11
  274:  40 9d 00 08 ble cr7,27c <__do_patch_instructions+0x50>
  278:  7c c8 33 78 mr  r8,r6
  27c:  7f 83 40 40 cmplw   cr7,r3,r8
  280:  40 9c 01 2c bge cr7,3ac <__do_patch_instructions+0x180>
  284:  7c 69 18 f8 not r9,r3
  288:  7d 28 4a 14 add r9,r8,r9
  28c:  55 29 f7 fe rlwinm  r9,r9,30,31,31
  290:  7c e3 50 50 subfr7,r3,r10
  294:  80 a4 00 00 lwz r5,0(r4)
  298:  90 aa 00 00 stw r5,0(r10)
  29c:  7c 00 50 6c dcbst   0,r10
  2a0:  7c 00 04 ac hwsync
  2a4:  7c 00 1f ac icbi0,r3
  2a8:  7c 00 04 ac hwsync
  2ac:  4c 00 01 2c isync
  2b0:  38 63 00 04 addir3,r3,4
  2b4:  40 82 00 08 bne 2bc <__do_patch_instructions+0x90>
  2b8:  38 84 00 04 addir4,r4,4
  2bc:  7f 83 40 40 cmplw   cr7,r3,r8
  2c0:  40 9c 00 a4 bge cr7,364 <__do_patch_instructions+0x138>
  2c4:  2f 89 00 00 cmpwi   cr7,r9,0
  2c8:  41 9e 00 38 beq cr7,300 <__do_patch_instructions+0xd4>
  2cc:  7d 23 3a 14 add r9,r3,r7
  2d0:  81 44 00 00 lwz r10,0(r4)
  2d4:  91 49 00 00 stw r10,0(r9)
  2d

Re: [PATCH v2 1/4] powerpc/code-patching: introduce patch_instructions()

2023-03-10 Thread Christophe Leroy


Le 09/03/2023 à 19:02, Hari Bathini a écrit :
> patch_instruction() entails setting up pte, patching the instruction,
> clearing the pte and flushing the tlb. If multiple instructions need
> to be patched, every instruction would have to go through the above
> drill unnecessarily. Instead, introduce function patch_instructions()
> that patches multiple instructions at one go while setting up the pte,
> clearing the pte and flushing the tlb only once per page range of
> instructions. Observed ~5X improvement in speed of execution using
> patch_instructions() over patch_instructions(), when more instructions
> are to be patched.

I get a 13% degradation on the time needed to activate ftrace on a 
powerpc 8xx.

Before your patch, activation ftrace takes 550k timebase ticks. After 
your patch it takes 620k timebase ticks.

Christophe

> 
> Signed-off-by: Hari Bathini 
> ---
>   arch/powerpc/include/asm/code-patching.h |   1 +
>   arch/powerpc/lib/code-patching.c | 151 ---
>   2 files changed, 106 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/code-patching.h 
> b/arch/powerpc/include/asm/code-patching.h
> index 3f881548fb61..059fc4fe700e 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -74,6 +74,7 @@ int create_cond_branch(ppc_inst_t *instr, const u32 *addr,
>   int patch_branch(u32 *addr, unsigned long target, int flags);
>   int patch_instruction(u32 *addr, ppc_inst_t instr);
>   int raw_patch_instruction(u32 *addr, ppc_inst_t instr);
> +int patch_instructions(u32 *addr, u32 *code, bool fill_inst, size_t len);
>   
>   static inline unsigned long patch_site_addr(s32 *site)
>   {
> diff --git a/arch/powerpc/lib/code-patching.c 
> b/arch/powerpc/lib/code-patching.c
> index b00112d7ad46..33857b9b53de 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -278,77 +278,117 @@ static void unmap_patch_area(unsigned long addr)
>   flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>   }
>   
> -static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
> +static int __do_patch_instructions_mm(u32 *addr, u32 *code, bool fill_inst, 
> size_t len)
>   {
> - int err;
> - u32 *patch_addr;
> - unsigned long text_poke_addr;
> - pte_t *pte;
> - unsigned long pfn = get_patch_pfn(addr);
> - struct mm_struct *patching_mm;
> - struct mm_struct *orig_mm;
> + struct mm_struct *patching_mm, *orig_mm;
> + unsigned long text_poke_addr, pfn;
> + u32 *patch_addr, *end, *pend;
> + ppc_inst_t instr;
>   spinlock_t *ptl;
> + int ilen, err;
> + pte_t *pte;
>   
>   patching_mm = __this_cpu_read(cpu_patching_context.mm);
>   text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
> - patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
>   
>   pte = get_locked_pte(patching_mm, text_poke_addr, );
>   if (!pte)
>   return -ENOMEM;
>   
> - __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn, 
> PAGE_KERNEL), 0);
> + end = (void *)addr + len;
> + do {
> + pfn = get_patch_pfn(addr);
> + __set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn, 
> PAGE_KERNEL), 0);
>   
> - /* order PTE update before use, also serves as the hwsync */
> - asm volatile("ptesync": : :"memory");
> -
> - /* order context switch after arbitrary prior code */
> - isync();
> -
> - orig_mm = start_using_temp_mm(patching_mm);
> -
> - err = __patch_instruction(addr, instr, patch_addr);
> + /* order PTE update before use, also serves as the hwsync */
> + asm volatile("ptesync": : :"memory");
>   
> - /* hwsync performed by __patch_instruction (sync) if successful */
> - if (err)
> - mb();  /* sync */
> + /* order context switch after arbitrary prior code */
> + isync();
> +
> + orig_mm = start_using_temp_mm(patching_mm);
> +
> + patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
> + pend = (void *)addr + PAGE_SIZE - offset_in_page(addr);
> + if (end < pend)
> + pend = end;
> +
> + while (addr < pend) {
> + instr = ppc_inst_read(code);
> + ilen = ppc_inst_len(instr);
> + err = __patch_instruction(addr, instr, patch_addr);
> + /* hwsync performed by __patch_instruction (sync) if 
> successful */
> + if (err) {
> + mb();  /* sync */
> + break;
> + }
> +
> + patch_addr = (void *)patch_addr + ilen;
> + addr = (void *)addr + ilen;
> + if (!fill_inst)
> + code = (void *)code + ilen;
> + }
>   
> - /* context 

Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

2023-03-03 Thread Christophe Leroy


Le 03/03/2023 à 20:41, Crystal Wood a écrit :
> On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote:
>> On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote:
>>> 01/03/2023 (Wed 14:23) Christophe Leroy wrote:
>>>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??:
>>>> Hope it clarifies how those reference boards are used.
>>>
>>> It was really useful input and gave an insight into how things get used.
>>>
>>> But let me put a slightly different slant on things.  If there is no
>>> maintainer for the platform/architecture/CPU, then where is the
>>> obligation for mainline to keep it up to date just for your company to
>>> use the code/BSP as a reference?
>>>
>>> Do they continue to do this for one more year, or three or ...  ???
>>> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ?
>> ...
>>>
>>> If you see change 0123abcdef breaks boot on your platform, you have a
>>> legit voice to gripe about it right then and there.  Don't wait!!!
>>
>> I think the answer here is that Christophe is already the only person
>> that does this, so he is the de-facto maintainer for ppc32 regardless
>> of whether he wants himself listed in the file or not:
>>
>> $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* |
>> sort | uniq -c | sort -rn | grep -vw 1
>>   61 Christophe Leroy
>>   12 Michael Ellerman
>>   11 Thomas Gleixner
>>   11 Oliver O'Halloran
>>   11 Liang He
>>    7 Uwe Kleine-König
>>    6 Nick Child
>>    4 Rasmus Villemoes
>>    4 Randy Dunlap
>>    4 Mike Rapoport
>>    4 Julia Lawall
>>    4 Andy Shevchenko
>>    3 Xiaoming Ni
>>    3 Nicholas Piggin
>>    3 Marc Zyngier
>>    3 Christophe JAILLET
>>    3 Christoph Hellwig
>>    2 Paul Gortmaker
>>    2 Mathieu Malaterre
>>    2 Markus Elfring
>>    2 Jordan Niethe
>>    2 Dmitry Torokhov
>>    2 Arnd Bergmann
>>
>> Pretty much everyone else on the list above only did treewide
>> cleanups, dead code removal or compile-time fixes, while Christophe
>> is the one that fixed machine specific bugs and added new features.
> 
> Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR
> POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more
> involved than me lately.

MPC83XX yes I can, I have MPC8321E Hardware, but PPC85XX I'm not sure. I 
don't know much more than what I can experiment with QEMU.

Maybe Pali for MPC85XX ?

Christophe


Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

2023-03-01 Thread Christophe Leroy


Le 28/02/2023 à 18:51, Arnd Bergmann a écrit :
> On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote:
>> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote:
>>
>> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
>> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
>>
>> There will still exist several e300 Freescale Reference Design System 
>> (RDS)
>> boards[5] and mini-ITX boards[6] with support in the kernel.  While these
>> were more of a COTS "ready to deploy" design more suited to hobbyists, it
>> probably makes sense to consider removing these as well, based on age.
>
> These boards are mass market boards that sold in larger amount and are 
> much more likely to still be used.  We would suggest we keep them for now.
>>
>> Agreed, the RDS design is still used here.
> 
> Can you elaborate what the typical kernel upgrade schedule for
> these boards?
> 
> Note that for the debate about dropping the machines from future
> kernels, it does not really matter how many remaining users there
> are or how many boards get sold. The only question is whether
> someone is still planning to provide upgrades to kernels later
> than linux-6.3 in the future.
> 
> It sounds like there are commercial requirements for validating
> and distributing kernel upgrades (in addition to hobbyist uses), so
> I would expect that whoever is paying for the upgrades has a clear
> plan for how much longer they are going to do that, or at least
> a some idea of how many of the previous LTS kernels (5.10, 5.15,
> 6.1) ended up actually getting shipped to users.
> 
> It may be worth pointing out that the official webpage for
> the MPC8313ERDB board in the example only lists a hilariously
> outdated BSP kernel based on a patched linux-2.6.23 release,
> so maybe the marketing team can change that to point to the
> latest validated LTS kernel instead.

Let me present things in a slightly different way.

My company has designed and manufactured and sold communication systems 
embedding three types of boards:
- First generation, with MPC 866, designed around 2002.
- Second generation, with MPC 885, designed around 2010.
- Third generation, with MPC 8321, designed around 2014.

When NXP announced end of life of MPC 866 and 885, we bought enough CPUs 
to be able to produce boards for the 10 following years so we still 
produce some.

MPC 8321 is still in production.

All those boards are used in critical systems where we have a customer 
requirement to keep all software including U-boot and Linux kernel up to 
date, for IT security reason mainly.

Until now, the boards were delivered with kernel 4.14, with is due to 
EOL early next year.
At the moment we are working on upgrading to mainline kernel with the 
target being to be able to upgrade our customers to next LTS kernel at 
the begining of 2024.

Note that because our kernel code is prehistoric, it is not mergeable to 
mainline. Not because of licence issues but because the code is just not 
following at all linux standard. So our boards are not in mainline. Two 
of them are in U-boot and the third one should soon be as well.

So, to come back about the RDB boards, we have a couple of MPC 885 ADS 
and a couple of MPC 8321 RDB. They are reference boards and we always 
check that a given kernel version properly runs on them before starting 
to port it to our hardware.

Hope it clarifies how those reference boards are used.

Christophe


Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA

2023-03-01 Thread Christophe Leroy


Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
> 
> One of these unusual properties is that shadow stack memory is writable,
> but only in limited ways. These limits are applied via a specific PTE
> bit combination. Nevertheless, the memory is writable, and core mm code
> will need to apply the writable permissions in the typical paths that
> call pte_mkwrite().
> 
> In addition to VM_WRITE, the shadow stack VMA's will have a flag denoting
> that they are special shadow stack flavor of writable memory. So make
> pte_mkwrite() take a VMA, so that the x86 implementation of it can know to
> create regular writable memory or shadow stack memory.
> 
> Apply the same changes for pmd_mkwrite() and huge_pte_mkwrite().

I'm not sure it is a good idea to add a second argument to 
pte_mkwrite(). All pte_mk() only take a pte and nothing else.

I think you should do the same as commit d9ed9faac283 ("mm: add new 
arch_make_huge_pte() method for tile support")

Christophe

> 
> No functional change.
> 
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c...@vger.kernel.org
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@lists.linux-m68k.org
> Cc: Michal Simek 
> Cc: Dinh Nguyen 
> Cc: linux-m...@vger.kernel.org
> Cc: linux-openr...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Tested-by: Pengfei Xu 
> Tested-by: John Allen 
> Tested-by: Kees Cook 
> Acked-by: Mike Rapoport (IBM) 
> Acked-by: Michael Ellerman 
> Acked-by: David Hildenbrand 
> Reviewed-by: Kees Cook 
> Suggested-by: David Hildenbrand 
> Signed-off-by: Rick Edgecombe 
> 
> ---
> Hi Non-x86 Arch’s,
> 
> x86 has a feature that allows for the creation of a special type of
> writable memory (shadow stack) that is only writable in limited specific
> ways. Previously, changes were proposed to core MM code to teach it to
> decide when to create normally writable memory or the special shadow stack
> writable memory, but David Hildenbrand suggested[0] to change
> pXX_mkwrite() to take a VMA, so awareness of shadow stack memory can be
> moved into x86 code.
> 
> Since pXX_mkwrite() is defined in every arch, it requires some tree-wide
> changes. So that is why you are seeing some patches out of a big x86
> series pop up in your arch mailing list. There is no functional change.
> After this refactor, the shadow stack series goes on to use the arch
> helpers to push shadow stack memory details inside arch/x86.
> 
> Testing was just 0-day build testing.
> 
> Hopefully that is enough context. Thanks!
> 
> [0] 
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t
> 
> v6:
>   - New patch
> ---
>   Documentation/mm/arch_pgtable_helpers.rst|  9 ++---
>   arch/alpha/include/asm/pgtable.h |  6 +-
>   arch/arc/include/asm/hugepage.h  |  2 +-
>   arch/arc/include/asm/pgtable-bits-arcv2.h|  7 ++-
>   arch/arm/include/asm/pgtable-3level.h|  7 ++-
>   arch/arm/include/asm/pgtable.h   |  2 +-
>   arch/arm64/include/asm/pgtable.h |  4 ++--
>   arch/csky/include/asm/pgtable.h  |  2 +-
>   arch/hexagon/include/asm/pgtable.h   |  2 +-
>   arch/ia64/include/asm/pgtable.h  |  2 +-
>   arch/loongarch/include/asm/pgtable.h |  4 ++--
>   arch/m68k/include/asm/mcf_pgtable.h  |  2 +-
>   arch/m68k/include/asm/motorola_pgtable.h |  6 +-
>   arch/m68k/include/asm/sun3_pgtable.h |  6 +-
>   arch/microblaze/include/asm/pgtable.h|  2 +-
>   arch/mips/include/asm/pgtable.h  |  6 +++---
>   arch/nios2/include/asm/pgtable.h |  2 +-
>   arch/openrisc/include/asm/pgtable.h  |  2 +-
>   arch/parisc/include/asm/pgtable.h|  6 +-
>   arch/powerpc/include/asm/book3s/32/pgtable.h |  2 +-
>   arch/powerpc/include/asm/book3s/64/pgtable.h |  4 ++--
>   arch/powerpc/include/asm/nohash/32/pgtable.h |  2 +-
>   arch/powerpc/include/asm/nohash/32/pte-8xx.h |  2 +-
>   arch/powerpc/include/asm/nohash/64/pgtable.h |  2 +-
>   arch/riscv/include/asm/pgtable.h |  6 +++---
>   arch/s390/include/asm/hugetlb.h  |  4 ++--
>   arch/s390/include/asm/pgtable.h  |  4 ++--
>   arch/sh/include/asm/pgtable_32.h   

Re: Patch for audio on iBook G4 (powerbook6,5)

2023-02-28 Thread Christophe Leroy


Le 28/02/2023 à 22:17, m...@thaison-nguyen.de a écrit :
> Hi
> 
> I have added a bug report and a patch regarding audio for iBook G4 
> (powerbook6,5) on kernel.org bugzilla, but nobody has picked it up.
> https://bugzilla.kernel.org/show_bug.cgi?id=216504
> 
> Now I am trying to submit the patch here.
> 

Please read and follow the process to submit a patch : 
https://docs.kernel.org/process/5.Posting.html

Patches must be in the core part of the mail and not as an attached file.
Patches must have a description of the change.
Patches must be signed
Patches must be sent to the relevant maintainer(s) based on the modified 
files. As far as I can see your patch is for the sound subsystem.

Christophe


Re: [PATCH V2] mm: Merge pte_mkhuge() call into arch_make_huge_pte()

2023-02-28 Thread Christophe Leroy
Hi,

Le 03/02/2022 à 04:57, Anshuman Khandual a écrit :
> Each call into pte_mkhuge() is invariably followed by arch_make_huge_pte().
> Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beginning.
> This updates generic fallback stub for arch_make_huge_pte() and available
> platforms definitions. This makes huge pte creation much cleaner and easier
> to follow.

I can't remember, what was the reason for not doing it in 
remove_migration_pte() as well ?
Looking at it, I have the feeling that we now have a redundant 
pte_mkhuge() there.

Also, could we get rid of the one in mm/debug_vm_pgtable.c ?

Also, shouldn't arch_make_huge_pte() be documented in 
Documentation/vm/arch_pgtable_helpers.rst instead of pte_mkhuge() ?

Christophe

> 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Michael Ellerman 
> Cc: Paul Mackerras 
> Cc: "David S. Miller" 
> Cc: Mike Kravetz 
> Cc: Andrew Morton 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: sparcli...@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Reviewed-by: Christophe Leroy 
> Acked-by: Mike Kravetz 
> Signed-off-by: Anshuman Khandual 
> ---
> This applies on v5.17-rc2
> 
> Changes in V2:
> 
> - Direct PTE encode in arch_make_huge_pte() on powerpc platform per Christophe
> 
> Changes in V1:
> 
> https://lore.kernel.org/all/1643780286-18798-1-git-send-email-anshuman.khand...@arm.com/
> 
>   arch/arm64/mm/hugetlbpage.c  | 1 +
>   arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 4 ++--
>   arch/sparc/mm/hugetlbpage.c  | 1 +
>   include/linux/hugetlb.h  | 2 +-
>   mm/hugetlb.c | 3 +--
>   mm/vmalloc.c | 1 -
>   6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index ffb9c229610a..228226c5fa80 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -347,6 +347,7 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, 
> vm_flags_t flags)
>   {
>   size_t pagesize = 1UL << shift;
>   
> + entry = pte_mkhuge(entry);
>   if (pagesize == CONT_PTE_SIZE) {
>   entry = pte_mkcont(entry);
>   } else if (pagesize == CONT_PMD_SIZE) {
> diff --git a/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h 
> b/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
> index 64b6c608eca4..de092b04ee1a 100644
> --- a/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
> +++ b/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
> @@ -71,9 +71,9 @@ static inline pte_t arch_make_huge_pte(pte_t entry, 
> unsigned int shift, vm_flags
>   size_t size = 1UL << shift;
>   
>   if (size == SZ_16K)
> - return __pte(pte_val(entry) & ~_PAGE_HUGE);
> + return __pte(pte_val(entry) | _PAGE_SPS);
>   else
> - return entry;
> + return __pte(pte_val(entry) | _PAGE_SPS | _PAGE_HUGE);
>   }
>   #define arch_make_huge_pte arch_make_huge_pte
>   #endif
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index 0f49fada2093..d8e0e3c7038d 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -181,6 +181,7 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, 
> vm_flags_t flags)
>   {
>   pte_t pte;
>   
> + entry = pte_mkhuge(entry);
>   pte = hugepage_shift_to_tte(entry, shift);
>   
>   #ifdef CONFIG_SPARC64
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index d1897a69c540..52c462390aee 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -754,7 +754,7 @@ static inline void arch_clear_hugepage_flags(struct page 
> *page) { }
>   static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift,
>  vm_flags_t flags)
>   {
> - return entry;
> + return pte_mkhuge(entry);
>   }
>   #endif
>   
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 61895cc01d09..5ca253c1b4e4 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4637,7 +4637,6 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, 
> struct page *page,
>  vma->vm_page_prot));
>   }
>   entry = pte_mkyoung(entry);
> - entry = pte_mkhuge(entry);
>   entry = arch_make_huge_pte(entry, shift, vma->vm_flags);
>   
>   return entry;
> @@ -6172,7 +6171,7 @@ unsigned long hugetlb_change_protection(struct 
> vm_area_struct *vma,
>   

Re: [PATCH v2 18/30] powerpc: Implement the new page table range API

2023-02-27 Thread Christophe Leroy


Le 27/02/2023 à 21:20, Matthew Wilcox a écrit :
> On Mon, Feb 27, 2023 at 07:45:08PM +0000, Christophe Leroy wrote:
>> Hi,
>>
>> Le 27/02/2023 à 18:57, Matthew Wilcox (Oracle) a écrit :
>>> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
>>> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
>>> per-folio.
>>>
>>> I'm unsure about my merging of flush_dcache_icache_hugepage() and
>>> flush_dcache_icache_page() into flush_dcache_icache_folio() and subsequent
>>> removal of flush_dcache_icache_phys().  Please review.
>>
>> Not sure why you want to remove flush_dcache_icache_phys().
> 
> Well, I didn't, necessarily.  It's just that when I merged
> flush_dcache_icache_hugepage() and flush_dcache_icache_page()
> together, it was left with no callers.
> 
>> Allthough that's only feasible when address bus is not wider than 32
>> bits and cannot be done on BOOKE as you can't switch off MMU on BOOKE,
>> flush_dcache_icache_phys() allows to flush not mapped pages without
>> having to map them. So it is more efficient.
> 
> And it was just never done for the hugepage case?

I think on PPC32 hugepages are available only on 8xx and BOOKE. 8xx 
doesn't have HIGHMEM and BOOKE cannot switch MMU off. So there is no use 
case for flush_dcache_icache_phys() with hugepages.

> 
>>> @@ -148,17 +103,20 @@ static void __flush_dcache_icache(void *p)
>>> invalidate_icache_range(addr, addr + PAGE_SIZE);
>>>}
>>>
>>> -static void flush_dcache_icache_hugepage(struct page *page)
>>> +void flush_dcache_icache_folio(struct folio *folio)
>>>{
>>> -   int i;
>>> -   int nr = compound_nr(page);
>>> +   unsigned int i, nr = folio_nr_pages(folio);
>>>
>>> -   if (!PageHighMem(page)) {
>>> +   if (flush_coherent_icache())
>>> +   return;
>>> +
>>> +   if (!folio_test_highmem(folio)) {
>>> +   void *addr = folio_address(folio);
>>> for (i = 0; i < nr; i++)
>>> -   __flush_dcache_icache(lowmem_page_address(page + i));
>>> +   __flush_dcache_icache(addr + i * PAGE_SIZE);
>>> } else {
>>> for (i = 0; i < nr; i++) {
>>> -   void *start = kmap_local_page(page + i);
>>> +   void *start = kmap_local_folio(folio, i * PAGE_SIZE);
>>>
>>> __flush_dcache_icache(start);
>>> kunmap_local(start);
> 
> So you'd like this to be:
> 
>   } else if (IS_ENABLED(CONFIG_BOOKE) || sizeof(phys_addr_t) > 
> sizeof(void *)) {
>   for (i = 0; i < nr; i++) {
>void *start = kmap_local_folio(folio, i * PAGE_SIZE);
>__flush_dcache_icache(start);
>kunmap_local(start);
>   }
>   } else {
>   unsigned long pfn = folio_pfn(folio);
>   for (i = 0; i < nr; i++)
>   flush_dcache_icache_phys((pfn + i) * PAGE_SIZE;
>   }
> 
> (or maybe you'd prefer a flush_dcache_icache_pfn() that doesn't need to
> worry about PAGE_MASK).

Yes looks good.


Christophe


Re: [PATCH v2 18/30] powerpc: Implement the new page table range API

2023-02-27 Thread Christophe Leroy
Hi,

Le 27/02/2023 à 18:57, Matthew Wilcox (Oracle) a écrit :
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
> 
> I'm unsure about my merging of flush_dcache_icache_hugepage() and
> flush_dcache_icache_page() into flush_dcache_icache_folio() and subsequent
> removal of flush_dcache_icache_phys().  Please review.

Not sure why you want to remove flush_dcache_icache_phys().

Allthough that's only feasible when address bus is not wider than 32 
bits and cannot be done on BOOKE as you can't switch off MMU on BOOKE, 
flush_dcache_icache_phys() allows to flush not mapped pages without 
having to map them. So it is more efficient.

Christophe

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

[PATCH] powerpc/perf: Properly detect mpc7450 family

2023-02-27 Thread Christophe Leroy
Unlike PVR_POWER8, etc , PVR_7450 represents a full PVR
value and not a family value.

To avoid confusion, do like E500 family and define the relevant
PVR_VER_ values for the 7450 family:
  0x8000 ==> 7450
  0x8001 ==> 7455
  0x8002 ==> 7447
  0x8003 ==> 7447A
  0x8004 ==> 7448

And use them to detect 7450 family for perf events.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Link: https://lore.kernel.org/r/202302260657.7dm9uwev-...@intel.com/
Fixes: ec3eb9d941a9 ("powerpc/perf: Use PVR rather than oprofile field to 
determine CPU version")
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/reg.h  | 5 +
 arch/powerpc/perf/mpc7450-pmu.c | 6 +++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1e8b2e04e626..8fda87af2fa5 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1310,6 +1310,11 @@
 #define PVR_VER_E500MC 0x8023
 #define PVR_VER_E5500  0x8024
 #define PVR_VER_E6500  0x8040
+#define PVR_VER_7450   0x8000
+#define PVR_VER_7455   0x8001
+#define PVR_VER_7447   0x8002
+#define PVR_VER_7447A  0x8003
+#define PVR_VER_7448   0x8004
 
 /*
  * For the 8xx processors, all of them report the same PVR family for
diff --git a/arch/powerpc/perf/mpc7450-pmu.c b/arch/powerpc/perf/mpc7450-pmu.c
index 552d51a925d3..db451b9aac35 100644
--- a/arch/powerpc/perf/mpc7450-pmu.c
+++ b/arch/powerpc/perf/mpc7450-pmu.c
@@ -417,9 +417,9 @@ struct power_pmu mpc7450_pmu = {
 
 static int __init init_mpc7450_pmu(void)
 {
-   unsigned int pvr = mfspr(SPRN_PVR);
-
-   if (PVR_VER(pvr) != PVR_7450)
+   if (!pvr_version_is(PVR_VER_7450) && !pvr_version_is(PVR_VER_7455) &&
+   !pvr_version_is(PVR_VER_7447) && !pvr_version_is(PVR_VER_7447A) &&
+   !pvr_version_is(PVR_VER_7448))
return -ENODEV;
 
return register_power_pmu(_pmu);
-- 
2.39.1



Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms

2023-02-24 Thread Christophe Leroy


Le 20/02/2023 à 12:59, Paul Gortmaker a écrit :
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
> 
> This series removes support for four e300 (MPC83xx) Freescale processor
> family evaluation boards that were added to the kernel in the 2006 era.
> 
> These boards were all of a very similar form factor, a largish PCI or PCI-X
> card that could also be used standalone with an external power brick, and
> all shared the Modular Development System (MDS) designation.
> 
> These platforms were made in limited quantity and were generally designed
> to get early silicon into the hands of OEMs who would later develop their
> own boards/platforms.  As such, availability was limited to those who would
> be working on boards and/or BSP support.
> 
> Many early revision MDS platforms used a mechanical clamping system to hold
> the BGA CPU in place to facilitate CPU updates -- something not normally
> possible for a soldered down BGA in a COTS system.
> 
> The point of these details is to give context that reflects that these four
> boards were made in limited quantities, were not in a form factor that is
> really "hobbyist" friendly and hence make sense for removal 17 years later.
> 
> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel.
> 
> There will still exist several e300 Freescale Reference Design System (RDS)
> boards[5] and mini-ITX boards[6] with support in the kernel.  While these
> were more of a COTS "ready to deploy" design more suited to hobbyists, it
> probably makes sense to consider removing these as well, based on age.

Those boards are still being sold, see 
https://www.components-store.fr/product/NXP-Semiconductors-Freescale/MPC8323E-RDB.html
 
they have 4600 pieces in stock.

Christophe


Re: [PATCH] powerpc/atomics: Remove unused function

2023-02-24 Thread Christophe Leroy


Le 24/02/2023 à 11:39, Nysal Jan K.A a écrit :
> [Vous ne recevez pas souvent de courriers de ny...@linux.ibm.com. Découvrez 
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> Remove arch_atomic_try_cmpxchg_lock function as it is no longer used
> since commit 9f61521c7a28 ("powerpc/qspinlock: powerpc qspinlock
> implementation")
> 
> Signed-off-by: Nysal Jan K.A 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/include/asm/atomic.h | 29 -
>   1 file changed, 29 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/atomic.h 
> b/arch/powerpc/include/asm/atomic.h
> index 486ab7889121..b3a53830446b 100644
> --- a/arch/powerpc/include/asm/atomic.h
> +++ b/arch/powerpc/include/asm/atomic.h
> @@ -130,35 +130,6 @@ ATOMIC_OPS(xor, xor, "", K)
>   #define arch_atomic_xchg_relaxed(v, new) \
>  arch_xchg_relaxed(&((v)->counter), (new))
> 
> -/*
> - * Don't want to override the generic atomic_try_cmpxchg_acquire, because
> - * we add a lock hint to the lwarx, which may not be wanted for the
> - * _acquire case (and is not used by the other _acquire variants so it
> - * would be a surprise).
> - */
> -static __always_inline bool
> -arch_atomic_try_cmpxchg_lock(atomic_t *v, int *old, int new)
> -{
> -   int r, o = *old;
> -   unsigned int eh = IS_ENABLED(CONFIG_PPC64);
> -
> -   __asm__ __volatile__ (
> -"1:lwarx   %0,0,%2,%[eh]   # atomic_try_cmpxchg_acquire\n"
> -"  cmpw0,%0,%3 \n"
> -"  bne-2f  \n"
> -"  stwcx.  %4,0,%2 \n"
> -"  bne-1b  \n"
> -"\t"   PPC_ACQUIRE_BARRIER "   \n"
> -"2:\n"
> -   : "=" (r), "+m" (v->counter)
> -   : "r" (>counter), "r" (o), "r" (new), [eh] "n" (eh)
> -   : "cr0", "memory");
> -
> -   if (unlikely(r != o))
> -   *old = r;
> -   return likely(r == o);
> -}
> -
>   /**
>* atomic_fetch_add_unless - add unless the number is a given value
>* @v: pointer of type atomic_t
> --
> 2.39.2
> 


Re: [PATCH v4 00/17] powerpc/85xx: p2020: Create one unified machine description

2023-02-23 Thread Christophe Leroy


Le 22/02/2023 à 19:22, Pali Rohár a écrit :
> On Wednesday 22 February 2023 15:42:47 Christophe Leroy wrote:
>> This patch series unifies all P2020 boards and machine descriptions into
>> one generic unified P2020 machine description. With this generic machine
>> description, kernel can boot on any P2020-based board with correct DTS
>> file.
>>
>> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
>> Kernel during booting correctly detects P2020 and prints:
>> [0.00] Using Freescale P2020 machine description
>>
>> Changes in v4:
>> * Added several preparatory cleanup patchs
>> * Minimised churn by not duplicating helpers at the first place
>> * Split main patch in two
>> * Dropped patchs 1 and 2
>> * Untested beyond basic build test
> 
> Changes looks good. I'm happy with them. You can add my:
> 
> Reviewed-by: Pali Rohár 

Thanks.

However this series doesn't have the shape for getting merged yet, I've 
been very quick with the additional patches descriptions and I have not 
revisited the descriptions of pre-existing patches.

I was expecting you to take over. By the way there's no hurry I guess, 
we are already in the middle of the merge window, Michael usually 
doesn't take any more non-fixes patches once the merge window is open, 
so that series will go in 6.4

Christophe

> 
>> Changes in v3:
>> * Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef 
>> CONFIG_PPC_I8259'
>> * Simplify p2020_probe()
>> * Patches generated by -M and -C git options
>>
>> Link to v2: 
>> https://lore.kernel.org/linuxppc-dev/20221224211425.14983-1-p...@kernel.org/
>>
>> Changes in v2:
>> * Added patch "p2020: Move i8259 code into own function" (separated from the 
>> next one)
>> * Renamed CONFIG_P2020 to CONFIG_PPC_P2020
>> * Fixed descriptions
>>
>> Link to v1: 
>> https://lore.kernel.org/linuxppc-dev/20220819191557.28116-1-p...@kernel.org/
>>
>> Christophe Leroy (9):
>>powerpc/fsl_uli1575: Misc cleanup
>>powerpc/85xx: Rename setup_arch and pic_init on p1023
>>powerpc/85xx: Remove DBG() macro
>>powerpc/85xx: Remove #ifdefs CONFIG_PCI in mpc85xx_ds
>>powerpc/85xx: mpc85xx_{ds/rdb} compact the call to mpic_alloc()
>>powerpc/85xx: mpc85xx_{ds/rdb} replace BUG_ON() by WARN_ON()
>>powerpc/85xx: mpc85xx_{ds/rdb} replace prink by pr_xxx macro
>>powerpc/85xx: Remove #ifdefs CONFIG_PPC_I8259 in mpc85xx_ds
>>powerpc/85xx: Remove #ifdef CONFIG_QUICC_ENGINE in mpc85xx_rdb
>>
>> Pali Rohár (8):
>>powerpc/85xx: p2020: Move all P2020 DS machine descriptions to p2020.c
>>powerpc/85xx: p2020: Move all P2020 RDB machine descriptions to
>>  p2020.c
>>powerpc/85xx: p2020: Move i8259 code into own function
>>powerpc/85xx: mpc85xx_ds: Move PCI code into own file
>>powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
>>powerpc/85xx: p2020: Define just one machine description
>>powerpc/85xx: p2020: Enable boards by new config option
>>  CONFIG_PPC_P2020
>>powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
>>
>>   arch/powerpc/boot/dts/turris1x.dts |   2 +-
>>   arch/powerpc/include/asm/ppc-pci.h |   2 +
>>   arch/powerpc/platforms/85xx/Kconfig|  22 +++-
>>   arch/powerpc/platforms/85xx/Makefile   |   5 +-
>>   arch/powerpc/platforms/85xx/mpc85xx.h  |  12 ++
>>   arch/powerpc/platforms/85xx/mpc85xx_8259.c |  78 
>>   arch/powerpc/platforms/85xx/mpc85xx_ds.c   | 133 ++---
>>   arch/powerpc/platforms/85xx/mpc85xx_mds.c  |   7 --
>>   arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |  79 ++--
>>   arch/powerpc/platforms/85xx/mpc85xx_uli.c  |  64 ++
>>   arch/powerpc/platforms/85xx/p1023_rdb.c|   8 +-
>>   arch/powerpc/platforms/85xx/p2020.c|  95 +++
>>   arch/powerpc/platforms/fsl_uli1575.c   |   6 +-
>>   13 files changed, 301 insertions(+), 212 deletions(-)
>>   create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_8259.c
>>   create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_uli.c
>>   create mode 100644 arch/powerpc/platforms/85xx/p2020.c
>>
>> -- 
>> 2.39.1
>>


[PATCH v4 09/17] powerpc/85xx: Remove #ifdef CONFIG_QUICC_ENGINE in mpc85xx_rdb

2023-02-22 Thread Christophe Leroy
mpc85xx_qe_par_io_init() is a stub when CONFIG_QUICC_ENGINE is not set.

CONFIG_UCC_GETH and CONFIG_SERIAL_QE depend on CONFIG_QUICC_ENGINE.

Remove #ifdef CONFIG_QUICC_ENGINE

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 8b0d81f0e1c9..b23f826339b5 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -57,7 +57,6 @@ static void __init mpc85xx_rdb_setup_arch(void)
 
fsl_pci_assign_primary();
 
-#ifdef CONFIG_QUICC_ENGINE
mpc85xx_qe_par_io_init();
 #if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
if (machine_is(p1025_rdb)) {
@@ -90,7 +89,6 @@ static void __init mpc85xx_rdb_setup_arch(void)
 
}
 #endif
-#endif /* CONFIG_QUICC_ENGINE */
 
pr_info("MPC85xx RDB board from Freescale Semiconductor\n");
 }
-- 
2.39.1



[PATCH v4 11/17] powerpc/85xx: p2020: Move all P2020 RDB machine descriptions to p2020.c

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

This moves machine descriptions and all related code for all P2020 boards
into new p2020.c source file.
This is preparation for code de-duplication and
providing one unified machine description for all P2020 boards. In
follow-up patches would be copied functions refactored and simplified to be
specific just for P2020 boards.

Signed-off-by: Pali Rohár 
[chleroy: Split in two patches: one for DS, one for RDB and keep helpers out]
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/Makefile  |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx.h |  2 +
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 46 +-
 arch/powerpc/platforms/85xx/p2020.c   | 57 +++
 4 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 1f54623db9b7..93451850ed83 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
 obj-$(CONFIG_MPC8536_DS)  += mpc8536_ds.o
 obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o
 obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
-obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
+obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o p2020.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
 obj-$(CONFIG_P1022_DS)+= p1022_ds.o
 obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index ca8b39e6b05a..8f7b37c1de87 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -17,5 +17,7 @@ static inline void __init mpc85xx_qe_par_io_init(void) {}
 
 void __init mpc85xx_ds_pic_init(void);
 void __init mpc85xx_ds_setup_arch(void);
+void __init mpc85xx_rdb_setup_arch(void);
+void __init mpc85xx_rdb_pic_init(void);
 
 #endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index b23f826339b5..d1f497e086ed 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -48,7 +48,7 @@ void __init mpc85xx_rdb_pic_init(void)
 /*
  * Setup the architecture
  */
-static void __init mpc85xx_rdb_setup_arch(void)
+void __init mpc85xx_rdb_setup_arch(void)
 {
if (ppc_md.progress)
ppc_md.progress("mpc85xx_rdb_setup_arch()", 0);
@@ -93,8 +93,6 @@ static void __init mpc85xx_rdb_setup_arch(void)
pr_info("MPC85xx RDB board from Freescale Semiconductor\n");
 }
 
-machine_arch_initcall(p2020_rdb, mpc85xx_common_publish_devices);
-machine_arch_initcall(p2020_rdb_pc, mpc85xx_common_publish_devices);
 machine_arch_initcall(p1020_mbg_pc, mpc85xx_common_publish_devices);
 machine_arch_initcall(p1020_rdb, mpc85xx_common_publish_devices);
 machine_arch_initcall(p1020_rdb_pc, mpc85xx_common_publish_devices);
@@ -107,13 +105,6 @@ machine_arch_initcall(p1024_rdb, 
mpc85xx_common_publish_devices);
 /*
  * Called very early, device-tree isn't unflattened
  */
-static int __init p2020_rdb_probe(void)
-{
-   if (of_machine_is_compatible("fsl,P2020RDB"))
-   return 1;
-   return 0;
-}
-
 static int __init p1020_rdb_probe(void)
 {
if (of_machine_is_compatible("fsl,P1020RDB"))
@@ -138,13 +129,6 @@ static int __init p1021_rdb_pc_probe(void)
return 0;
 }
 
-static int __init p2020_rdb_pc_probe(void)
-{
-   if (of_machine_is_compatible("fsl,P2020RDB-PC"))
-   return 1;
-   return 0;
-}
-
 static int __init p1025_rdb_probe(void)
 {
return of_machine_is_compatible("fsl,P1025RDB");
@@ -165,20 +149,6 @@ static int __init p1024_rdb_probe(void)
return of_machine_is_compatible("fsl,P1024RDB");
 }
 
-define_machine(p2020_rdb) {
-   .name   = "P2020 RDB",
-   .probe  = p2020_rdb_probe,
-   .setup_arch = mpc85xx_rdb_setup_arch,
-   .init_IRQ   = mpc85xx_rdb_pic_init,
-#ifdef CONFIG_PCI
-   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
-#endif
-   .get_irq= mpic_get_irq,
-   .calibrate_decr = generic_calibrate_decr,
-   .progress   = udbg_progress,
-};
-
 define_machine(p1020_rdb) {
.name   = "P1020 RDB",
.probe  = p1020_rdb_probe,
@@ -207,20 +177,6 @@ define_machine(p1021_rdb_pc) {
.progress   = udbg_progress,
 };
 
-define_machine(p2020_rdb_pc) {
-   .name   = "P2020RDB-PC",
-   .probe  = p2020_rdb_pc_probe,
-   .setup_arch = mpc85xx_rdb_setup_arch,
-   .init_IRQ   = mpc85xx_rdb_pic_init,
-#ifdef CONFIG_PCI
-   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fs

[PATCH v4 12/17] powerpc/85xx: p2020: Move i8259 code into own function

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

Splits mpic and i8259 initialization codes into separate functions.
Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef CONFIG_PPC_I8259'.

Signed-off-by: Pali Rohár 
[chleroy: Put into own C file]
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/Makefile   |  3 +-
 arch/powerpc/platforms/85xx/mpc85xx.h  |  6 ++
 arch/powerpc/platforms/85xx/mpc85xx_8259.c | 78 ++
 arch/powerpc/platforms/85xx/mpc85xx_ds.c   | 46 -
 4 files changed, 86 insertions(+), 47 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_8259.c

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 93451850ed83..0a0011e8c63c 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -16,7 +16,8 @@ obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
 obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
 obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
 obj-$(CONFIG_MPC8536_DS)  += mpc8536_ds.o
-obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o
+obj8259-$(CONFIG_PPC_I8259)   += mpc85xx_8259.o
+obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o $(obj8259-y)
 obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
 obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o p2020.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index 8f7b37c1de87..e792907ee3d5 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -15,6 +15,12 @@ extern void mpc85xx_qe_par_io_init(void);
 static inline void __init mpc85xx_qe_par_io_init(void) {}
 #endif
 
+#ifdef CONFIG_PPC_I8259
+void __init mpc85xx_8259_init(void);
+#else
+static inline void __init mpc85xx_8259_init(void) {}
+#endif
+
 void __init mpc85xx_ds_pic_init(void);
 void __init mpc85xx_ds_setup_arch(void);
 void __init mpc85xx_rdb_setup_arch(void);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_8259.c 
b/arch/powerpc/platforms/85xx/mpc85xx_8259.c
new file mode 100644
index ..eeb541b9f4bd
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/mpc85xx_8259.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * MPC85xx 8259 functions for DS Board Setup
+ *
+ * Author Xianghua Xiao (x.x...@freescale.com)
+ * Roy Zang 
+ * - Add PCI/PCI Exprees support
+ * Copyright 2007 Freescale Semiconductor Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+static void mpc85xx_8259_cascade(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   unsigned int cascade_irq = i8259_irq();
+
+   if (cascade_irq) {
+   generic_handle_irq(cascade_irq);
+   }
+   chip->irq_eoi(>irq_data);
+}
+
+void __init mpc85xx_8259_init(void)
+{
+   struct device_node *np;
+   struct device_node *cascade_node = NULL;
+   int cascade_irq;
+
+   /* Initialize the i8259 controller */
+   for_each_node_by_type(np, "interrupt-controller")
+   if (of_device_is_compatible(np, "chrp,iic")) {
+   cascade_node = np;
+   break;
+   }
+
+   if (cascade_node == NULL) {
+   pr_debug("Could not find i8259 PIC\n");
+   return;
+   }
+
+   cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+   if (!cascade_irq) {
+   pr_err("Failed to map cascade interrupt\n");
+   return;
+   }
+
+   pr_debug("mpc85xxds: cascade mapped to irq %d\n", cascade_irq);
+
+   i8259_init(cascade_node, 0);
+   of_node_put(cascade_node);
+
+   irq_set_chained_handler(cascade_irq, mpc85xx_8259_cascade);
+}
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 8594862ab3a4..011ae86d72f4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -34,52 +34,6 @@
 
 #include "mpc85xx.h"
 
-static void mpc85xx_8259_cascade(struct irq_desc *desc)
-{
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   unsigned int cascade_irq = i8259_irq();
-
-   if (cascade_irq) {
-   generic_handle_irq(cascade_irq);
-   }
-   chip->irq_eoi(>irq_data);
-}
-
-static void __init mpc85xx_8259_init(void)
-{
-   struct device_node *np;
-   struct device_node *cascade_node = NULL;
-   int cascade_irq;
-
-   if (!IS_ENABLED(CONFIG_PPC_I8259))
-   return;
-
-   /* Initialize the i8259 controller */
-   for_each_node_by_type(np, "interrupt-controller")
-   if (of_device_is_compatible(np, "chrp,iic")) {
-   cascade_n

[PATCH v4 05/17] powerpc/85xx: mpc85xx_{ds/rdb} compact the call to mpic_alloc()

2023-02-22 Thread Christophe Leroy
Reduce number of lines in the call to mpic_alloc().

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 18 ++
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 +---
 2 files changed, 11 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index f385cd288a76..1e6e89136948 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -50,23 +50,17 @@ static void mpc85xx_8259_cascade(struct irq_desc *desc)
 void __init mpc85xx_ds_pic_init(void)
 {
struct mpic *mpic;
+   int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
 #ifdef CONFIG_PPC_I8259
struct device_node *np;
struct device_node *cascade_node = NULL;
int cascade_irq;
 #endif
-   if (of_machine_is_compatible("fsl,MPC8572DS-CAMP")) {
-   mpic = mpic_alloc(NULL, 0,
-   MPIC_NO_RESET |
-   MPIC_BIG_ENDIAN |
-   MPIC_SINGLE_DEST_CPU,
-   0, 256, " OpenPIC  ");
-   } else {
-   mpic = mpic_alloc(NULL, 0,
- MPIC_BIG_ENDIAN |
- MPIC_SINGLE_DEST_CPU,
-   0, 256, " OpenPIC  ");
-   }
+
+   if (of_machine_is_compatible("fsl,MPC8572DS-CAMP"))
+   flags |= MPIC_NO_RESET;
+
+   mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
 
BUG_ON(mpic == NULL);
mpic_init(mpic);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index b5e9a6374edb..110365d7b997 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -32,18 +32,12 @@
 void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
+   int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
 
-   if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP")) {
-   mpic = mpic_alloc(NULL, 0, MPIC_NO_RESET |
-   MPIC_BIG_ENDIAN |
-   MPIC_SINGLE_DEST_CPU,
-   0, 256, " OpenPIC  ");
-   } else {
-   mpic = mpic_alloc(NULL, 0,
- MPIC_BIG_ENDIAN |
- MPIC_SINGLE_DEST_CPU,
- 0, 256, " OpenPIC  ");
-   }
+   if (of_machine_is_compatible("fsl,MPC85XXRDB-CAMP"))
+   flags |= MPIC_NO_RESET;
+
+   mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
 
BUG_ON(mpic == NULL);
mpic_init(mpic);
-- 
2.39.1



[PATCH v4 13/17] powerpc/85xx: mpc85xx_ds: Move PCI code into own file

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

In order to share between DS and P2020.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/Makefile  |  3 +-
 arch/powerpc/platforms/85xx/mpc85xx.h |  6 +++
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 32 
 arch/powerpc/platforms/85xx/mpc85xx_uli.c | 64 +++
 4 files changed, 72 insertions(+), 33 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_uli.c

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 0a0011e8c63c..65abd5a161c0 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -17,7 +17,8 @@ obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
 obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
 obj-$(CONFIG_MPC8536_DS)  += mpc8536_ds.o
 obj8259-$(CONFIG_PPC_I8259)   += mpc85xx_8259.o
-obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o $(obj8259-y)
+objpci-$(CONFIG_PCI)   += mpc85xx_uli.o
+obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o $(obj8259-y) $(objpci-y)
 obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
 obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o p2020.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index e792907ee3d5..b77bb9e7e79c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -21,6 +21,12 @@ void __init mpc85xx_8259_init(void);
 static inline void __init mpc85xx_8259_init(void) {}
 #endif
 
+#ifdef CONFIG_PCI
+void __init mpc85xx_ds_uli_init(void);
+#else
+static inline void __init mpc85xx_ds_uli_init(void) {}
+#endif
+
 void __init mpc85xx_ds_pic_init(void);
 void __init mpc85xx_ds_setup_arch(void);
 void __init mpc85xx_rdb_setup_arch(void);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 011ae86d72f4..f9ac0b6022b1 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -52,38 +52,6 @@ void __init mpc85xx_ds_pic_init(void)
mpc85xx_8259_init();
 }
 
-static struct device_node *pci_with_uli;
-
-static int mpc85xx_exclude_device(struct pci_controller *hose,
-  u_char bus, u_char devfn)
-{
-   if (hose->dn == pci_with_uli)
-   return uli_exclude_device(hose, bus, devfn);
-
-   return PCIBIOS_SUCCESSFUL;
-}
-
-static void __init mpc85xx_ds_uli_init(void)
-{
-   struct device_node *node;
-
-   if (!IS_ENABLED(CONFIG_PCI))
-   return;
-
-   /* See if we have a ULI under the primary */
-
-   node = of_find_node_by_name(NULL, "uli1575");
-   while ((pci_with_uli = of_get_parent(node))) {
-   of_node_put(node);
-   node = pci_with_uli;
-
-   if (pci_with_uli == fsl_pci_primary) {
-   ppc_md.pci_exclude_device = mpc85xx_exclude_device;
-   break;
-   }
-   }
-}
-
 /*
  * Setup the architecture
  */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_uli.c 
b/arch/powerpc/platforms/85xx/mpc85xx_uli.c
new file mode 100644
index ..f91fe860985b
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/mpc85xx_uli.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * MPC85xx PCI functions for DS Board Setup
+ *
+ * Author Xianghua Xiao (x.x...@freescale.com)
+ * Roy Zang 
+ * - Add PCI/PCI Exprees support
+ * Copyright 2007 Freescale Semiconductor Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+static struct device_node *pci_with_uli;
+
+static int mpc85xx_exclude_device(struct pci_controller *hose,
+  u_char bus, u_char devfn)
+{
+   if (hose->dn == pci_with_uli)
+   return uli_exclude_device(hose, bus, devfn);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
+void __init mpc85xx_ds_uli_init(void)
+{
+   struct device_node *node;
+
+   /* See if we have a ULI under the primary */
+
+   node = of_find_node_by_name(NULL, "uli1575");
+   while ((pci_with_uli = of_get_parent(node))) {
+   of_node_put(node);
+   node = pci_with_uli;
+
+   if (pci_with_uli == fsl_pci_primary) {
+   ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+   break;
+   }
+   }
+}
-- 
2.39.1



[PATCH v4 15/17] powerpc/85xx: p2020: Define just one machine description

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

Combine machine descriptions and code of all P2020 boards into just one
generic unified P2020 machine description. This allows kernel to boot on
any P2020-based board with P2020 DTS file without need to patch kernel and
define a new machine description in 85xx powerpc platform directory.

Signed-off-by: Pali Rohár 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/p2020.c | 77 ++---
 1 file changed, 15 insertions(+), 62 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/p2020.c 
b/arch/powerpc/platforms/85xx/p2020.c
index 684ad1ea7362..21584d81f3d9 100644
--- a/arch/powerpc/platforms/85xx/p2020.c
+++ b/arch/powerpc/platforms/85xx/p2020.c
@@ -60,83 +60,36 @@ static void __init p2020_setup_arch(void)
mpc85xx_qe_par_io_init();
 }
 
-#ifdef CONFIG_MPC85xx_DS
-machine_arch_initcall(p2020_ds, mpc85xx_common_publish_devices);
-#endif /* CONFIG_MPC85xx_DS */
-
-#ifdef CONFIG_MPC85xx_RDB
-machine_arch_initcall(p2020_rdb, mpc85xx_common_publish_devices);
-machine_arch_initcall(p2020_rdb_pc, mpc85xx_common_publish_devices);
-#endif /* CONFIG_MPC85xx_RDB */
+machine_arch_initcall(p2020, mpc85xx_common_publish_devices);
 
 /*
  * Called very early, device-tree isn't unflattened
  */
-#ifdef CONFIG_MPC85xx_DS
-static int __init p2020_ds_probe(void)
+static int __init p2020_probe(void)
 {
-   return !!of_machine_is_compatible("fsl,P2020DS");
-}
-#endif /* CONFIG_MPC85xx_DS */
+   struct device_node *p2020_cpu;
 
-#ifdef CONFIG_MPC85xx_RDB
-static int __init p2020_rdb_probe(void)
-{
-   if (of_machine_is_compatible("fsl,P2020RDB"))
-   return 1;
-   return 0;
-}
+   /*
+* There is no common compatible string for all P2020 boards.
+* The only common thing is "PowerPC,P2020@0" cpu node.
+* So check for P2020 board via this cpu node.
+*/
+   p2020_cpu = of_find_node_by_path("/cpus/PowerPC,P2020@0");
+   of_node_put(p2020_cpu);
 
-static int __init p2020_rdb_pc_probe(void)
-{
-   if (of_machine_is_compatible("fsl,P2020RDB-PC"))
-   return 1;
-   return 0;
+   return !!p2020_cpu;
 }
-#endif /* CONFIG_MPC85xx_RDB */
-
-#ifdef CONFIG_MPC85xx_DS
-define_machine(p2020_ds) {
-   .name   = "P2020 DS",
-   .probe  = p2020_ds_probe,
-   .setup_arch = p2020_setup_arch,
-   .init_IRQ   = p2020_pic_init,
-#ifdef CONFIG_PCI
-   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
-#endif
-   .get_irq= mpic_get_irq,
-   .calibrate_decr = generic_calibrate_decr,
-   .progress   = udbg_progress,
-};
-#endif /* CONFIG_MPC85xx_DS */
-
-#ifdef CONFIG_MPC85xx_RDB
-define_machine(p2020_rdb) {
-   .name   = "P2020 RDB",
-   .probe  = p2020_rdb_probe,
-   .setup_arch = p2020_setup_arch,
-   .init_IRQ   = p2020_pic_init,
-#ifdef CONFIG_PCI
-   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
-#endif
-   .get_irq= mpic_get_irq,
-   .calibrate_decr = generic_calibrate_decr,
-   .progress   = udbg_progress,
-};
 
-define_machine(p2020_rdb_pc) {
-   .name   = "P2020RDB-PC",
-   .probe  = p2020_rdb_pc_probe,
+define_machine(p2020) {
+   .name   = "Freescale P2020",
+   .probe  = p2020_probe,
.setup_arch = p2020_setup_arch,
.init_IRQ   = p2020_pic_init,
 #ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
+   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
 #endif
.get_irq= mpic_get_irq,
.calibrate_decr = generic_calibrate_decr,
.progress   = udbg_progress,
 };
-#endif /* CONFIG_MPC85xx_RDB */
-- 
2.39.1



[PATCH v4 02/17] powerpc/85xx: Rename setup_arch and pic_init on p1023

2023-02-22 Thread Christophe Leroy
Avoid conflict with other functions, rename mpc85xx_rdb_setup_arch()
to p1023_rdb_setup_arch(), same for mpc85xx_rdb_pic_init().

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/p1023_rdb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/p1023_rdb.c 
b/arch/powerpc/platforms/85xx/p1023_rdb.c
index c04868eb2eb1..5d434ee96445 100644
--- a/arch/powerpc/platforms/85xx/p1023_rdb.c
+++ b/arch/powerpc/platforms/85xx/p1023_rdb.c
@@ -37,7 +37,7 @@
  * Setup the architecture
  *
  */
-static void __init mpc85xx_rdb_setup_arch(void)
+static void __init p1023_rdb_setup_arch(void)
 {
struct device_node *np;
 
@@ -83,7 +83,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
 
 machine_arch_initcall(p1023_rdb, mpc85xx_common_publish_devices);
 
-static void __init mpc85xx_rdb_pic_init(void)
+static void __init p1023_rdb_pic_init(void)
 {
struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
MPIC_SINGLE_DEST_CPU,
@@ -103,8 +103,8 @@ static int __init p1023_rdb_probe(void)
 define_machine(p1023_rdb) {
.name   = "P1023 RDB",
.probe  = p1023_rdb_probe,
-   .setup_arch = mpc85xx_rdb_setup_arch,
-   .init_IRQ   = mpc85xx_rdb_pic_init,
+   .setup_arch = p1023_rdb_setup_arch,
+   .init_IRQ   = p1023_rdb_pic_init,
.get_irq= mpic_get_irq,
.calibrate_decr = generic_calibrate_decr,
.progress   = udbg_progress,
-- 
2.39.1



[PATCH v4 03/17] powerpc/85xx: Remove DBG() macro

2023-02-22 Thread Christophe Leroy
DBG() macro is defined at three places while used only
one time at one place.

Replace its only use by a pr_debug() and remove the macro.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 10 +-
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  7 ---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  9 -
 3 files changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 97e441878409..26257509aabf 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -34,14 +34,6 @@
 
 #include "mpc85xx.h"
 
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt, args...) printk(KERN_ERR "%s: " fmt, __func__, ## args)
-#else
-#define DBG(fmt, args...)
-#endif
-
 #ifdef CONFIG_PPC_I8259
 static void mpc85xx_8259_cascade(struct irq_desc *desc)
 {
@@ -98,7 +90,7 @@ void __init mpc85xx_ds_pic_init(void)
return;
}
 
-   DBG("mpc85xxds: cascade mapped to irq %d\n", cascade_irq);
+   pr_debug("mpc85xxds: cascade mapped to irq %d\n", cascade_irq);
 
i8259_init(cascade_node, 0);
of_node_put(cascade_node);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 3a2ac410af18..540ce17f0577 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -49,13 +49,6 @@
 
 #include "mpc85xx.h"
 
-#undef DEBUG
-#ifdef DEBUG
-#define DBG(fmt...) udbg_printf(fmt)
-#else
-#define DBG(fmt...)
-#endif
-
 #if IS_BUILTIN(CONFIG_PHYLIB)
 
 #define MV88E_SCR  0x10
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index d99aba158235..b5e9a6374edb 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -29,15 +29,6 @@
 
 #include "mpc85xx.h"
 
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt, args...) printk(KERN_ERR "%s: " fmt, __func__, ## args)
-#else
-#define DBG(fmt, args...)
-#endif
-
-
 void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
-- 
2.39.1



[PATCH v4 06/17] powerpc/85xx: mpc85xx_{ds/rdb} replace BUG_ON() by WARN_ON()

2023-02-22 Thread Christophe Leroy
No need to BUG() in case mpic_alloc() fails. Use WARN_ON().

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 4 +++-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 1e6e89136948..60d473d9b8ee 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -62,7 +62,9 @@ void __init mpc85xx_ds_pic_init(void)
 
mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
 
-   BUG_ON(mpic == NULL);
+   if (WARN_ON(!mpic))
+   return;
+
mpic_init(mpic);
 
 #ifdef CONFIG_PPC_I8259
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 110365d7b997..34b65441661e 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -39,7 +39,9 @@ void __init mpc85xx_rdb_pic_init(void)
 
mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
 
-   BUG_ON(mpic == NULL);
+   if (WARN_ON(!mpic))
+   return;
+
mpic_init(mpic);
 }
 
-- 
2.39.1



[PATCH v4 14/17] powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

Make just one .setup_arch and one .init_IRQ callback implementation for all
P2020 board code. This deduplicate repeated and same code.

Signed-off-by: Pali Rohár 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx.h |  5 ---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  4 +--
 arch/powerpc/platforms/85xx/p2020.c   | 38 +++
 3 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index b77bb9e7e79c..0be681526a1a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -27,9 +27,4 @@ void __init mpc85xx_ds_uli_init(void);
 static inline void __init mpc85xx_ds_uli_init(void) {}
 #endif
 
-void __init mpc85xx_ds_pic_init(void);
-void __init mpc85xx_ds_setup_arch(void);
-void __init mpc85xx_rdb_setup_arch(void);
-void __init mpc85xx_rdb_pic_init(void);
-
 #endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index d1f497e086ed..aee12e68e46d 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -29,7 +29,7 @@
 
 #include "mpc85xx.h"
 
-void __init mpc85xx_rdb_pic_init(void)
+static void __init mpc85xx_rdb_pic_init(void)
 {
struct mpic *mpic;
int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
@@ -48,7 +48,7 @@ void __init mpc85xx_rdb_pic_init(void)
 /*
  * Setup the architecture
  */
-void __init mpc85xx_rdb_setup_arch(void)
+static void __init mpc85xx_rdb_setup_arch(void)
 {
if (ppc_md.progress)
ppc_md.progress("mpc85xx_rdb_setup_arch()", 0);
diff --git a/arch/powerpc/platforms/85xx/p2020.c 
b/arch/powerpc/platforms/85xx/p2020.c
index 1b0def607749..684ad1ea7362 100644
--- a/arch/powerpc/platforms/85xx/p2020.c
+++ b/arch/powerpc/platforms/85xx/p2020.c
@@ -34,6 +34,32 @@
 
 #include "mpc85xx.h"
 
+static void __init p2020_pic_init(void)
+{
+   struct mpic *mpic;
+   int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
+
+   mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
+
+   if (WARN_ON(!mpic))
+   return;
+
+   mpic_init(mpic);
+   mpc85xx_8259_init();
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init p2020_setup_arch(void)
+{
+   swiotlb_detect_4g();
+   fsl_pci_assign_primary();
+   mpc85xx_ds_uli_init();
+   mpc85xx_smp_init();
+   mpc85xx_qe_par_io_init();
+}
+
 #ifdef CONFIG_MPC85xx_DS
 machine_arch_initcall(p2020_ds, mpc85xx_common_publish_devices);
 #endif /* CONFIG_MPC85xx_DS */
@@ -73,8 +99,8 @@ static int __init p2020_rdb_pc_probe(void)
 define_machine(p2020_ds) {
.name   = "P2020 DS",
.probe  = p2020_ds_probe,
-   .setup_arch = mpc85xx_ds_setup_arch,
-   .init_IRQ   = mpc85xx_ds_pic_init,
+   .setup_arch = p2020_setup_arch,
+   .init_IRQ   = p2020_pic_init,
 #ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
.pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
@@ -89,8 +115,8 @@ define_machine(p2020_ds) {
 define_machine(p2020_rdb) {
.name   = "P2020 RDB",
.probe  = p2020_rdb_probe,
-   .setup_arch = mpc85xx_rdb_setup_arch,
-   .init_IRQ   = mpc85xx_rdb_pic_init,
+   .setup_arch = p2020_setup_arch,
+   .init_IRQ   = p2020_pic_init,
 #ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
.pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
@@ -103,8 +129,8 @@ define_machine(p2020_rdb) {
 define_machine(p2020_rdb_pc) {
.name   = "P2020RDB-PC",
.probe  = p2020_rdb_pc_probe,
-   .setup_arch = mpc85xx_rdb_setup_arch,
-   .init_IRQ   = mpc85xx_rdb_pic_init,
+   .setup_arch = p2020_setup_arch,
+   .init_IRQ   = p2020_pic_init,
 #ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
.pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
-- 
2.39.1



[PATCH v4 17/17] powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

"fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just
because Linux kernel required it for proper detection of P2020 processor
during boot.

This was quite a hack as CZ.NIC Turris 1.x is not compatible with
Freescale P2020-RDB-PC board.

Now when kernel has generic unified support for boards with P2020
processors, there is no need to have this "hack" in turris1x.dts file.

So remove incorrect "fsl,P2020RDB-PC" compatible string from turris1x.dts.

Signed-off-by: Pali Rohár 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/boot/dts/turris1x.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/turris1x.dts 
b/arch/powerpc/boot/dts/turris1x.dts
index e9cda34a140e..a95857de6858 100644
--- a/arch/powerpc/boot/dts/turris1x.dts
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -15,7 +15,7 @@
 
 / {
model = "Turris 1.x";
-   compatible = "cznic,turris1x", "fsl,P2020RDB-PC"; /* fsl,P2020RDB-PC is 
required for booting Linux */
+   compatible = "cznic,turris1x";
 
aliases {
ethernet0 = 
-- 
2.39.1



[PATCH v4 08/17] powerpc/85xx: Remove #ifdefs CONFIG_PPC_I8259 in mpc85xx_ds

2023-02-22 Thread Christophe Leroy
All necessary items are declared all the time, no need to use
a #ifdef CONFIG_PPC_I8259.

Refactor CONFIG_PPC_I8259 actions into a dedicated init function.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c | 37 +---
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index e995c939c14d..2b3e9aecb3ad 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -34,7 +34,6 @@
 
 #include "mpc85xx.h"
 
-#ifdef CONFIG_PPC_I8259
 static void mpc85xx_8259_cascade(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -45,29 +44,16 @@ static void mpc85xx_8259_cascade(struct irq_desc *desc)
}
chip->irq_eoi(>irq_data);
 }
-#endif /* CONFIG_PPC_I8259 */
 
-void __init mpc85xx_ds_pic_init(void)
+static void __init mpc85xx_8259_init(void)
 {
-   struct mpic *mpic;
-   int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
-#ifdef CONFIG_PPC_I8259
struct device_node *np;
struct device_node *cascade_node = NULL;
int cascade_irq;
-#endif
 
-   if (of_machine_is_compatible("fsl,MPC8572DS-CAMP"))
-   flags |= MPIC_NO_RESET;
-
-   mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
-
-   if (WARN_ON(!mpic))
+   if (!IS_ENABLED(CONFIG_PPC_I8259))
return;
 
-   mpic_init(mpic);
-
-#ifdef CONFIG_PPC_I8259
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -92,7 +78,24 @@ void __init mpc85xx_ds_pic_init(void)
of_node_put(cascade_node);
 
irq_set_chained_handler(cascade_irq, mpc85xx_8259_cascade);
-#endif /* CONFIG_PPC_I8259 */
+}
+
+void __init mpc85xx_ds_pic_init(void)
+{
+   struct mpic *mpic;
+   int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU;
+
+   if (of_machine_is_compatible("fsl,MPC8572DS-CAMP"))
+   flags |= MPIC_NO_RESET;
+
+   mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC  ");
+
+   if (WARN_ON(!mpic))
+   return;
+
+   mpic_init(mpic);
+
+   mpc85xx_8259_init();
 }
 
 static struct device_node *pci_with_uli;
-- 
2.39.1



[PATCH v4 01/17] powerpc/fsl_uli1575: Misc cleanup

2023-02-22 Thread Christophe Leroy
Use a single line for uli_exclude_device()

Add uli_exclude_device() prototype in ppc-pci.h

Remove that prototype from mpc85xx_ds.c

Make uli_pirq_to_irq[] static as it is used only in that file.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/ppc-pci.h   | 2 ++
 arch/powerpc/platforms/85xx/mpc85xx_ds.c | 4 +---
 arch/powerpc/platforms/fsl_uli1575.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc-pci.h 
b/arch/powerpc/include/asm/ppc-pci.h
index f6cf0159024e..1e9a7f8b05c9 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -57,6 +57,8 @@ void eeh_sysfs_remove_device(struct pci_dev *pdev);
 
 #endif /* CONFIG_EEH */
 
+int uli_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn);
+
 #define PCI_BUSNO(bdfn) ((bdfn >> 8) & 0xff)
 
 #else /* CONFIG_PCI */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index f8d2c97f39bd..97e441878409 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,9 +108,6 @@ void __init mpc85xx_ds_pic_init(void)
 }
 
 #ifdef CONFIG_PCI
-extern int uli_exclude_device(struct pci_controller *hose,
-   u_char bus, u_char devfn);
-
 static struct device_node *pci_with_uli;
 
 static int mpc85xx_exclude_device(struct pci_controller *hose,
diff --git a/arch/powerpc/platforms/fsl_uli1575.c 
b/arch/powerpc/platforms/fsl_uli1575.c
index 84afae7a2561..a32f9cef7845 100644
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -13,6 +13,7 @@
 #include 
 
 #include 
+#include 
 
 #define ULI_PIRQA  0x08
 #define ULI_PIRQB  0x09
@@ -36,7 +37,7 @@
 #define ULI_8259_IRQ14 0x0d
 #define ULI_8259_IRQ15 0x0f
 
-u8 uli_pirq_to_irq[8] = {
+static u8 uli_pirq_to_irq[8] = {
ULI_8259_IRQ9,  /* PIRQA */
ULI_8259_IRQ10, /* PIRQB */
ULI_8259_IRQ11, /* PIRQC */
@@ -341,8 +342,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5288, 
hpcd_quirk_uli5288);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229, hpcd_quirk_uli5229);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AL, 0x5288, hpcd_final_uli5288);
 
-int uli_exclude_device(struct pci_controller *hose,
-   u_char bus, u_char devfn)
+int uli_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
 {
if (bus == (hose->first_busno + 2)) {
/* exclude Modem controller */
-- 
2.39.1



[PATCH v4 10/17] powerpc/85xx: p2020: Move all P2020 DS machine descriptions to p2020.c

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

This moves machine descriptions and all related code for all P2020 boards
into new p2020.c source file.
This is preparation for code de-duplication and
providing one unified machine description for all P2020 boards. In
follow-up patches would be copied functions refactored and simplified to be
specific just for P2020 boards.

Signed-off-by: Pali Rohár 
[chleroy: Split in two patches: one for DS, one for RDB and keep helpers out]
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/Makefile |  2 +-
 arch/powerpc/platforms/85xx/mpc85xx.h|  3 ++
 arch/powerpc/platforms/85xx/mpc85xx_ds.c | 25 +-
 arch/powerpc/platforms/85xx/p2020.c  | 59 
 4 files changed, 64 insertions(+), 25 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/p2020.c

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 260fbad7967b..1f54623db9b7 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
 obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
 obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
 obj-$(CONFIG_MPC8536_DS)  += mpc8536_ds.o
-obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o
+obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o
 obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
 obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index cb84c5c56c36..ca8b39e6b05a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -15,4 +15,7 @@ extern void mpc85xx_qe_par_io_init(void);
 static inline void __init mpc85xx_qe_par_io_init(void) {}
 #endif
 
+void __init mpc85xx_ds_pic_init(void);
+void __init mpc85xx_ds_setup_arch(void);
+
 #endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 2b3e9aecb3ad..8594862ab3a4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -133,7 +133,7 @@ static void __init mpc85xx_ds_uli_init(void)
 /*
  * Setup the architecture
  */
-static void __init mpc85xx_ds_setup_arch(void)
+void __init mpc85xx_ds_setup_arch(void)
 {
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
@@ -156,7 +156,6 @@ static int __init mpc8544_ds_probe(void)
 
 machine_arch_initcall(mpc8544_ds, mpc85xx_common_publish_devices);
 machine_arch_initcall(mpc8572_ds, mpc85xx_common_publish_devices);
-machine_arch_initcall(p2020_ds, mpc85xx_common_publish_devices);
 
 /*
  * Called very early, device-tree isn't unflattened
@@ -166,14 +165,6 @@ static int __init mpc8572_ds_probe(void)
return !!of_machine_is_compatible("fsl,MPC8572DS");
 }
 
-/*
- * Called very early, device-tree isn't unflattened
- */
-static int __init p2020_ds_probe(void)
-{
-   return !!of_machine_is_compatible("fsl,P2020DS");
-}
-
 define_machine(mpc8544_ds) {
.name   = "MPC8544 DS",
.probe  = mpc8544_ds_probe,
@@ -201,17 +192,3 @@ define_machine(mpc8572_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress   = udbg_progress,
 };
-
-define_machine(p2020_ds) {
-   .name   = "P2020 DS",
-   .probe  = p2020_ds_probe,
-   .setup_arch = mpc85xx_ds_setup_arch,
-   .init_IRQ   = mpc85xx_ds_pic_init,
-#ifdef CONFIG_PCI
-   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
-   .pcibios_fixup_phb  = fsl_pcibios_fixup_phb,
-#endif
-   .get_irq= mpic_get_irq,
-   .calibrate_decr = generic_calibrate_decr,
-   .progress   = udbg_progress,
-};
diff --git a/arch/powerpc/platforms/85xx/p2020.c 
b/arch/powerpc/platforms/85xx/p2020.c
new file mode 100644
index ..2dfd150c6375
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/p2020.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Freescale P2020 board Setup
+ *
+ * Copyright 2007,2009,2012-2013 Freescale Semiconductor Inc.
+ * Copyright 2022 Pali Rohár 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+machine_arch_initcall(p2020_ds, mpc85xx_common_publish_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p2020_ds_probe(void)
+{
+   return !!of_machine_is_compatible("fsl,P2020DS");
+}
+
+define_machine(p2020_ds) {
+   .name   = "P2020 DS",
+   .probe  = 

[PATCH v4 04/17] powerpc/85xx: Remove #ifdefs CONFIG_PCI in mpc85xx_ds

2023-02-22 Thread Christophe Leroy
All necessary items are declared all the time, no need to use
a #ifdef CONFIG_PCI.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 26257509aabf..f385cd288a76 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -99,7 +99,6 @@ void __init mpc85xx_ds_pic_init(void)
 #endif /* CONFIG_PPC_I8259 */
 }
 
-#ifdef CONFIG_PCI
 static struct device_node *pci_with_uli;
 
 static int mpc85xx_exclude_device(struct pci_controller *hose,
@@ -110,13 +109,14 @@ static int mpc85xx_exclude_device(struct pci_controller 
*hose,
 
return PCIBIOS_SUCCESSFUL;
 }
-#endif /* CONFIG_PCI */
 
 static void __init mpc85xx_ds_uli_init(void)
 {
-#ifdef CONFIG_PCI
struct device_node *node;
 
+   if (!IS_ENABLED(CONFIG_PCI))
+   return;
+
/* See if we have a ULI under the primary */
 
node = of_find_node_by_name(NULL, "uli1575");
@@ -129,7 +129,6 @@ static void __init mpc85xx_ds_uli_init(void)
break;
}
}
-#endif
 }
 
 /*
-- 
2.39.1



[PATCH v4 16/17] powerpc/85xx: p2020: Enable boards by new config option CONFIG_PPC_P2020

2023-02-22 Thread Christophe Leroy
From: Pali Rohár 

Generic unified P2020 machine description which supports all P2020-based
boards is now in separate file p2020.c. So create a separate config option
CONFIG_PPC_P2020 for it.

Previously machine descriptions for P2020 boards were enabled by
CONFIG_MPC85xx_DS or CONFIG_MPC85xx_RDB option. So set CONFIG_PPC_P2020 to
be enabled by default when one of those option is enabled.

This allows to compile support for P2020 boards without need to have
enabled support for older mpc85xx boards. And to compile kernel for old
mpc85xx boards without having enabled support for new P2020 boards.

Signed-off-by: Pali Rohár 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/Kconfig  | 22 ++
 arch/powerpc/platforms/85xx/Makefile |  5 +++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index b92cb2b4d54d..90665882143b 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -78,16 +78,16 @@ config MPC8536_DS
  This option enables support for the MPC8536 DS board
 
 config MPC85xx_DS
-   bool "Freescale MPC8544 DS / MPC8572 DS / P2020 DS"
+   bool "Freescale MPC8544 DS / MPC8572 DS"
select PPC_I8259
select DEFAULT_UIMAGE
select FSL_ULI1575 if PCI
select SWIOTLB
help
- This option enables support for the MPC8544 DS, MPC8572 DS and P2020 
DS boards
+ This option enables support for the MPC8544 DS and MPC8572 DS boards
 
 config MPC85xx_RDB
-   bool "Freescale P102x MBG/UTM/RDB and P2020 RDB"
+   bool "Freescale P102x MBG/UTM/RDB"
select PPC_I8259
select DEFAULT_UIMAGE
select FSL_ULI1575 if PCI
@@ -95,7 +95,21 @@ config MPC85xx_RDB
help
  This option enables support for the P1020 MBG PC, P1020 UTM PC,
  P1020 RDB PC, P1020 RDB PD, P1020 RDB, P1021 RDB PC, P1024 RDB,
- P1025 RDB, P2020 RDB and P2020 RDB PC boards
+ and P1025 RDB boards
+
+config PPC_P2020
+   bool "Freescale P2020"
+   default y if MPC85xx_DS || MPC85xx_RDB
+   select DEFAULT_UIMAGE
+   select SWIOTLB
+   imply PPC_I8259
+   imply FSL_ULI1575 if PCI
+   help
+ This option enables generic unified support for any board with the
+ Freescale P2020 processor.
+
+ For example: P2020 DS board, P2020 RDB board, P2020 RDB PC board or
+ CZ.NIC Turris 1.x boards.
 
 config P1010_RDB
bool "Freescale P1010 RDB"
diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 65abd5a161c0..82cf7d5b4913 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,13 +18,14 @@ obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
 obj-$(CONFIG_MPC8536_DS)  += mpc8536_ds.o
 obj8259-$(CONFIG_PPC_I8259)   += mpc85xx_8259.o
 objpci-$(CONFIG_PCI)   += mpc85xx_uli.o
-obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o p2020.o $(obj8259-y) $(objpci-y)
+obj-$(CONFIG_MPC85xx_DS)  += mpc85xx_ds.o $(obj8259-y) $(objpci-y)
 obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
-obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o p2020.o
+obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
 obj-$(CONFIG_P1022_DS)+= p1022_ds.o
 obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
 obj-$(CONFIG_P1023_RDB)   += p1023_rdb.o
+obj-$(CONFIG_PPC_P2020)   += p2020.o $(obj8259-y) $(objpci-y)
 obj-$(CONFIG_TWR_P102x)   += twr_p102x.o
 obj-$(CONFIG_CORENET_GENERIC)   += corenet_generic.o
 obj-$(CONFIG_FB_FSL_DIU)   += t1042rdb_diu.o
-- 
2.39.1



[PATCH v4 07/17] powerpc/85xx: mpc85xx_{ds/rdb} replace prink by pr_xxx macro

2023-02-22 Thread Christophe Leroy
Use pr_debug() instead of printk(KERN_DEBUG
Use pr_err() instead of printk(KERN_ERR
Use pr_info() instead of printk(KERN_INFO or printk("

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  | 6 +++---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 60d473d9b8ee..e995c939c14d 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -76,13 +76,13 @@ void __init mpc85xx_ds_pic_init(void)
}
 
if (cascade_node == NULL) {
-   printk(KERN_DEBUG "Could not find i8259 PIC\n");
+   pr_debug("Could not find i8259 PIC\n");
return;
}
 
cascade_irq = irq_of_parse_and_map(cascade_node, 0);
if (!cascade_irq) {
-   printk(KERN_ERR "Failed to map cascade interrupt\n");
+   pr_err("Failed to map cascade interrupt\n");
return;
}
 
@@ -140,7 +140,7 @@ static void __init mpc85xx_ds_setup_arch(void)
mpc85xx_ds_uli_init();
mpc85xx_smp_init();
 
-   printk("MPC85xx DS board from Freescale Semiconductor\n");
+   pr_info("MPC85xx DS board from Freescale Semiconductor\n");
 }
 
 /*
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 34b65441661e..8b0d81f0e1c9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -92,7 +92,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
 #endif
 #endif /* CONFIG_QUICC_ENGINE */
 
-   printk(KERN_INFO "MPC85xx RDB board from Freescale Semiconductor\n");
+   pr_info("MPC85xx RDB board from Freescale Semiconductor\n");
 }
 
 machine_arch_initcall(p2020_rdb, mpc85xx_common_publish_devices);
-- 
2.39.1



[PATCH v4 00/17] powerpc/85xx: p2020: Create one unified machine description

2023-02-22 Thread Christophe Leroy
This patch series unifies all P2020 boards and machine descriptions into
one generic unified P2020 machine description. With this generic machine
description, kernel can boot on any P2020-based board with correct DTS
file.

Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
Kernel during booting correctly detects P2020 and prints:
[0.00] Using Freescale P2020 machine description

Changes in v4:
* Added several preparatory cleanup patchs
* Minimised churn by not duplicating helpers at the first place
* Split main patch in two
* Dropped patchs 1 and 2
* Untested beyond basic build test

Changes in v3:
* Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef CONFIG_PPC_I8259'
* Simplify p2020_probe()
* Patches generated by -M and -C git options

Link to v2: 
https://lore.kernel.org/linuxppc-dev/20221224211425.14983-1-p...@kernel.org/

Changes in v2:
* Added patch "p2020: Move i8259 code into own function" (separated from the 
next one)
* Renamed CONFIG_P2020 to CONFIG_PPC_P2020
* Fixed descriptions

Link to v1: 
https://lore.kernel.org/linuxppc-dev/20220819191557.28116-1-p...@kernel.org/

Christophe Leroy (9):
  powerpc/fsl_uli1575: Misc cleanup
  powerpc/85xx: Rename setup_arch and pic_init on p1023
  powerpc/85xx: Remove DBG() macro
  powerpc/85xx: Remove #ifdefs CONFIG_PCI in mpc85xx_ds
  powerpc/85xx: mpc85xx_{ds/rdb} compact the call to mpic_alloc()
  powerpc/85xx: mpc85xx_{ds/rdb} replace BUG_ON() by WARN_ON()
  powerpc/85xx: mpc85xx_{ds/rdb} replace prink by pr_xxx macro
  powerpc/85xx: Remove #ifdefs CONFIG_PPC_I8259 in mpc85xx_ds
  powerpc/85xx: Remove #ifdef CONFIG_QUICC_ENGINE in mpc85xx_rdb

Pali Rohár (8):
  powerpc/85xx: p2020: Move all P2020 DS machine descriptions to p2020.c
  powerpc/85xx: p2020: Move all P2020 RDB machine descriptions to
p2020.c
  powerpc/85xx: p2020: Move i8259 code into own function
  powerpc/85xx: mpc85xx_ds: Move PCI code into own file
  powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
  powerpc/85xx: p2020: Define just one machine description
  powerpc/85xx: p2020: Enable boards by new config option
CONFIG_PPC_P2020
  powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string

 arch/powerpc/boot/dts/turris1x.dts |   2 +-
 arch/powerpc/include/asm/ppc-pci.h |   2 +
 arch/powerpc/platforms/85xx/Kconfig|  22 +++-
 arch/powerpc/platforms/85xx/Makefile   |   5 +-
 arch/powerpc/platforms/85xx/mpc85xx.h  |  12 ++
 arch/powerpc/platforms/85xx/mpc85xx_8259.c |  78 
 arch/powerpc/platforms/85xx/mpc85xx_ds.c   | 133 ++---
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |   7 --
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |  79 ++--
 arch/powerpc/platforms/85xx/mpc85xx_uli.c  |  64 ++
 arch/powerpc/platforms/85xx/p1023_rdb.c|   8 +-
 arch/powerpc/platforms/85xx/p2020.c|  95 +++
 arch/powerpc/platforms/fsl_uli1575.c   |   6 +-
 13 files changed, 301 insertions(+), 212 deletions(-)
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_8259.c
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_uli.c
 create mode 100644 arch/powerpc/platforms/85xx/p2020.c

-- 
2.39.1



Re: [PATCH v3 0/8] powerpc/85xx: p2020: Create one unified machine description

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 08:52, Pali Rohár a écrit :
> On Wednesday 22 February 2023 06:39:07 Christophe Leroy wrote:
>> Hi,
>>
>> Le 21/02/2023 à 23:07, Pali Rohár a écrit :
>>> Hello Christophe! Could you look at this v3 series?
>>> I addressed those small issues and hopefully it should be ready.
>>> It would be great to have this finally in v6.3 release.
>>
>> I started looking at your series and I will try to provide a feedback
>> within a few days.
>>
>> By the way I see that Paul Gortmaker has started removal of several 85xx
>> boards. Should we first take Paul's removal series then see what remains
>> before applying yours ? That would make your series even more efficient.
> 
> I have already replied to Paul patch series. The important thing is that
> we are touching different files, so patch series should be independent.

Ok.

Because exemples are always better than long writings, I have prepared a 
v4 of your series and will send it out shortly.

If that approach is ok for you, feel free to restart from there.

Christophe

> 
>> Christoph
>>
>>>
>>> On Saturday 18 February 2023 12:13:57 Pali Rohár wrote:
>>>> This patch series unifies all P2020 boards and machine descriptions into
>>>> one generic unified P2020 machine description. With this generic machine
>>>> description, kernel can boot on any P2020-based board with correct DTS
>>>> file.
>>>>
>>>> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
>>>> Kernel during booting correctly detects P2020 and prints:
>>>> [0.00] Using Freescale P2020 machine description
>>>>
>>>> Changes in v3:
>>>> * Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef 
>>>> CONFIG_PPC_I8259'
>>>> * Simplify p2020_probe()
>>>> * Patches generated by -M and -C git options
>>>>
>>>> Link to v2: 
>>>> https://lore.kernel.org/linuxppc-dev/20221224211425.14983-1-p...@kernel.org/
>>>>
>>>> Changes in v2:
>>>> * Added patch "p2020: Move i8259 code into own function" (separated from 
>>>> the next one)
>>>> * Renamed CONFIG_P2020 to CONFIG_PPC_P2020
>>>> * Fixed descriptions
>>>>
>>>> Link to v1: 
>>>> https://lore.kernel.org/linuxppc-dev/20220819191557.28116-1-p...@kernel.org/
>>>>
>>>> Pali Rohár (8):
>>>> powerpc/85xx: Mark mpc85xx_rdb_pic_init() as static
>>>> powerpc/85xx: Mark mpc85xx_ds_pic_init() as static
>>>> powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
>>>> powerpc/85xx: p2020: Move i8259 code into own function
>>>> powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
>>>> powerpc/85xx: p2020: Define just one machine description
>>>> powerpc/85xx: p2020: Enable boards by new config option
>>>>   CONFIG_PPC_P2020
>>>> powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
>>>>
>>>>arch/powerpc/boot/dts/turris1x.dts|   2 +-
>>>>arch/powerpc/platforms/85xx/Kconfig   |  22 ++-
>>>>arch/powerpc/platforms/85xx/Makefile  |   1 +
>>>>arch/powerpc/platforms/85xx/mpc85xx_ds.c  |  25 +---
>>>>arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  46 +-
>>>>.../platforms/85xx/{mpc85xx_ds.c => p2020.c}  | 135 ++
>>>>6 files changed, 68 insertions(+), 163 deletions(-)
>>>>copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (52%)
>>>>
>>>> -- 
>>>> 2.20.1
>>>>


Re: [PATCH v2] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 10:46, Kautuk Consul a écrit :
>>
>> Reviewed-by: Christophe Leroy 
> Thanks!
>>
>>> ---
>>>arch/powerpc/include/asm/barrier.h | 7 +++
>>>1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/barrier.h 
>>> b/arch/powerpc/include/asm/barrier.h
>>> index b95b666f0374..e088dacc0ee8 100644
>>> --- a/arch/powerpc/include/asm/barrier.h
>>> +++ b/arch/powerpc/include/asm/barrier.h
>>> @@ -36,8 +36,15 @@
>>> * heavy-weight sync, so smp_wmb() can be a lighter-weight eieio.
>>> */
>>>#define __mb()   __asm__ __volatile__ ("sync" : : : "memory")
>>> +
>>> +/* The sub-arch has lwsync. */
>>> +#if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
>>> +#define __rmb() __asm__ __volatile__ ("lwsync" : : : "memory")
>>> +#define __wmb() __asm__ __volatile__ ("lwsync" : : : "memory")
>>
>> I'd have preferred with 'asm volatile' though.
> Sorry about that! That wasn't the intent of this patch.
> Probably another patch series should change this manner of #defining
> assembly.

Why adding new line wrong then have to have another patch to make them 
right ?

When you build a new house in an old village, you first build your house 
with old materials and then you replace everything with new material ?


Re: [PATCH v2] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 10:30, Kautuk Consul a écrit :
> Again, could some IBM/non-IBM employees do basic sanity kernel load
> testing on PPC64 UP and SMP systems for this patch?
> would deeply appreciate it! :-)

And can 'non-IBM' 'non employees' do something ? :)

> 
> Thanks again!
> 

Did you try on QEMU ?


Re: [PATCH v2] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 10:03, Kautuk Consul a écrit :
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
>   complete before any subsequent store instructions can be executed
>   on the processor that executed the function. Also, it ensures that
>   all load instructions preceding the call to __lwsync complete before
>   any subsequent load instructions can be executed on the processor
>   that executed the function. This allows you to synchronize between
>   multiple processors with minimal performance impact, as __lwsync
>   does not wait for confirmation from each processor."
> 
> Thats why smp_rmb() and smp_wmb() are defined to lwsync.
> But this same understanding applies to parallel pipeline
> execution on each PowerPC processor.
> So, use the lwsync instruction for rmb() and wmb() on the PPC
> architectures that support it.
> 
> Signed-off-by: Kautuk Consul 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/include/asm/barrier.h | 7 +++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/barrier.h 
> b/arch/powerpc/include/asm/barrier.h
> index b95b666f0374..e088dacc0ee8 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -36,8 +36,15 @@
>* heavy-weight sync, so smp_wmb() can be a lighter-weight eieio.
>*/
>   #define __mb()   __asm__ __volatile__ ("sync" : : : "memory")
> +
> +/* The sub-arch has lwsync. */
> +#if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
> +#define __rmb() __asm__ __volatile__ ("lwsync" : : : "memory")
> +#define __wmb() __asm__ __volatile__ ("lwsync" : : : "memory")

I'd have preferred with 'asm volatile' though.

> +#else
>   #define __rmb()  __asm__ __volatile__ ("sync" : : : "memory")
>   #define __wmb()  __asm__ __volatile__ ("sync" : : : "memory")
> +#endif
>   
>   /* The sub-arch has lwsync */
>   #if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)


Re: [PATCH] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 09:16, Kautuk Consul a écrit :
> On Wed, Feb 22, 2023 at 07:02:34AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 22/02/2023 à 07:01, Kautuk Consul a écrit :
>>> A link from ibm.com states:
>>> "Ensures that all instructions preceding the call to __lwsync
>>>complete before any subsequent store instructions can be executed
>>>on the processor that executed the function. Also, it ensures that
>>>all load instructions preceding the call to __lwsync complete before
>>>any subsequent load instructions can be executed on the processor
>>>that executed the function. This allows you to synchronize between
>>>multiple processors with minimal performance impact, as __lwsync
>>>does not wait for confirmation from each processor."
>>>
>>> Thats why smp_rmb() and smp_wmb() are defined to lwsync.
>>> But this same understanding applies to parallel pipeline
>>> execution on each PowerPC processor.
>>> So, use the lwsync instruction for rmb() and wmb() on the PPC
>>> architectures that support it.
>>>
>>> Also removed some useless spaces.
>>>
>>> Signed-off-by: Kautuk Consul 
>>> ---
>>>arch/powerpc/include/asm/barrier.h | 12 +---
>>>1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/barrier.h 
>>> b/arch/powerpc/include/asm/barrier.h
>>> index e80b2c0e9315..553f5a5d20bd 100644
>>> --- a/arch/powerpc/include/asm/barrier.h
>>> +++ b/arch/powerpc/include/asm/barrier.h
>>> @@ -41,11 +41,17 @@
>>>
>>>/* The sub-arch has lwsync */
>>>#if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
>>> -#define SMPWMB  LWSYNC
>>
>> This line shouldn't be changed by your patch
> I mentioned it in the commit message.
> But if you want I'll remove this. Did this because the rest
> of the file doesn't have these spaces.
>>
>>> +#undef rmb
>>> +#undef wmb
>>
>> I see no point with defining something and undefining them a few lines
>> later.
>>
>> Instead, why not do:
>>
>> #define mb()   __asm__ __volatile__ ("sync" : : : "memory")
>>
>> #if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
>> #define rmb()({__asm__ __volatile__ ("lwsync" : : : "memory"); })
>> #define wmb()({__asm__ __volatile__ ("lwsync" : : : "memory"); })
>> #else
>> #define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
>> #define wmb()  __asm__ __volatile__ ("sync" : : : "memory")
>> #endif
>>
> I thought of doing that earlier, but there exists one more #elif
> for CONFIG_BOOKE and then the #else.
> That way we would have to put 3 different #defines for rmb and wmb
> and I wanted to avoid that.

No, I don't mean to use the existing #ifdef/elif/else.

Define an #ifdef /#else dedicated to xmb macros.

Something like that:

@@ -35,9 +35,15 @@
   * However, on CPUs that don't support lwsync, lwsync actually maps to a
   * heavy-weight sync, so smp_wmb() can be a lighter-weight eieio.
   */
+#if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
+#define __mb()   asm volatile ("lwsync" : : : "memory")
+#define __rmb()  asm volatile ("lwsync" : : : "memory")
+#define __wmb()  asm volatile ("lwsync" : : : "memory")
+#else
  #define __mb()   __asm__ __volatile__ ("sync" : : : "memory")
  #define __rmb()  __asm__ __volatile__ ("sync" : : : "memory")
  #define __wmb()  __asm__ __volatile__ ("sync" : : : "memory")
+#endif

  /* The sub-arch has lwsync */
  #if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)



>> By the way, why put it inside a ({ }) ?
> checkpatch.pl asks for ({}).
>> And I think nowdays we use "asm volatile" not "__asm__ __volatile__"
> I was just following what was there in the file already.
> Can change this if required.
>>
>> Shouldn't you also consider the same for mb() ?
> My change wasn't meant to address newer usages of as volatile
> #defines. I just wanted to redefine the rmb and wmb #defines
> to lwsync.

That's my point, why not also redefine mb to lwsync ?

>>
>> Note that your series will conflict with b6e259297a6b ("powerpc/kcsan:
>> Memory barriers semantics") in powerpc/next tree.
> I thought of defining the __rmb and __wmb macros but I decided against
> it because I didn't understand kcsan completely.
> I u

Re: [PATCH] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-22 Thread Christophe Leroy


Le 22/02/2023 à 09:21, Kautuk Consul a écrit :
>> On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
>>>> +/* Redefine rmb() to lwsync. */
>>>
>>> WHat's the added value of this comment ? Isn't it obvious in the line
>>> below that rmb() is being defined to lwsync ? Please avoid useless comments.
>> Sure.
> Sorry, forgot to add that I wasn't adding this useless comment.
> Its just that checkpatch.pl complains that the memory barrier #define
> doesn't have a comment for it.
>>>

See https://docs.kernel.org/dev-tools/checkpatch.html, it says:

Checkpatch is not always right. Your judgement takes precedence over 
checkpatch messages. If your code looks better with the violations, then 
its probably best left alone.

checkpatch wants a comment for uses of memory barriers. Here I think it 
is a false positive.


Re: [PATCH] arch/powerpc/include/asm/barrier.h: redefine rmb and wmb to lwsync

2023-02-21 Thread Christophe Leroy


Le 22/02/2023 à 07:01, Kautuk Consul a écrit :
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
>   complete before any subsequent store instructions can be executed
>   on the processor that executed the function. Also, it ensures that
>   all load instructions preceding the call to __lwsync complete before
>   any subsequent load instructions can be executed on the processor
>   that executed the function. This allows you to synchronize between
>   multiple processors with minimal performance impact, as __lwsync
>   does not wait for confirmation from each processor."
> 
> Thats why smp_rmb() and smp_wmb() are defined to lwsync.
> But this same understanding applies to parallel pipeline
> execution on each PowerPC processor.
> So, use the lwsync instruction for rmb() and wmb() on the PPC
> architectures that support it.
> 
> Also removed some useless spaces.
> 
> Signed-off-by: Kautuk Consul 
> ---
>   arch/powerpc/include/asm/barrier.h | 12 +---
>   1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/barrier.h 
> b/arch/powerpc/include/asm/barrier.h
> index e80b2c0e9315..553f5a5d20bd 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -41,11 +41,17 @@
>   
>   /* The sub-arch has lwsync */
>   #if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
> -#define SMPWMB  LWSYNC

This line shouldn't be changed by your patch

> +#undef rmb
> +#undef wmb

I see no point with defining something and undefining them a few lines 
later.

Instead, why not do:

#define mb()   __asm__ __volatile__ ("sync" : : : "memory")

#if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
#define rmb()   ({__asm__ __volatile__ ("lwsync" : : : "memory"); })
#define wmb()   ({__asm__ __volatile__ ("lwsync" : : : "memory"); })
#else
#define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
#define wmb()  __asm__ __volatile__ ("sync" : : : "memory")
#endif

By the way, why put it inside a ({ }) ?
And I think nowdays we use "asm volatile" not "__asm__ __volatile__"

Shouldn't you also consider the same for mb() ?

Note that your series will conflict with b6e259297a6b ("powerpc/kcsan: 
Memory barriers semantics") in powerpc/next tree.

> +/* Redefine rmb() to lwsync. */

WHat's the added value of this comment ? Isn't it obvious in the line 
below that rmb() is being defined to lwsync ? Please avoid useless comments.

> +#define rmb()({__asm__ __volatile__ ("lwsync" : : : "memory"); })
> +/* Redefine wmb() to lwsync. */
> +#define wmb()({__asm__ __volatile__ ("lwsync" : : : "memory"); })
> +#define SMPWMB  LWSYNC
>   #elif defined(CONFIG_BOOKE)
> -#define SMPWMB  mbar

This line shouldn't be changed by your patch

> +#define SMPWMB  mbar
>   #else
> -#define SMPWMB  eieio

This line shouldn't be changed by your patch

> +#define SMPWMB  eieio
>   #endif
>   
>   /* clang defines this macro for a builtin, which will not work with runtime 
> patching */


Re: [PATCH v3 0/8] powerpc/85xx: p2020: Create one unified machine description

2023-02-21 Thread Christophe Leroy
Hi,

Le 21/02/2023 à 23:07, Pali Rohár a écrit :
> Hello Christophe! Could you look at this v3 series?
> I addressed those small issues and hopefully it should be ready.
> It would be great to have this finally in v6.3 release.

I started looking at your series and I will try to provide a feedback 
within a few days.

By the way I see that Paul Gortmaker has started removal of several 85xx 
boards. Should we first take Paul's removal series then see what remains 
before applying yours ? That would make your series even more efficient.

Christoph

> 
> On Saturday 18 February 2023 12:13:57 Pali Rohár wrote:
>> This patch series unifies all P2020 boards and machine descriptions into
>> one generic unified P2020 machine description. With this generic machine
>> description, kernel can boot on any P2020-based board with correct DTS
>> file.
>>
>> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
>> Kernel during booting correctly detects P2020 and prints:
>> [0.00] Using Freescale P2020 machine description
>>
>> Changes in v3:
>> * Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef 
>> CONFIG_PPC_I8259'
>> * Simplify p2020_probe()
>> * Patches generated by -M and -C git options
>>
>> Link to v2: 
>> https://lore.kernel.org/linuxppc-dev/20221224211425.14983-1-p...@kernel.org/
>>
>> Changes in v2:
>> * Added patch "p2020: Move i8259 code into own function" (separated from the 
>> next one)
>> * Renamed CONFIG_P2020 to CONFIG_PPC_P2020
>> * Fixed descriptions
>>
>> Link to v1: 
>> https://lore.kernel.org/linuxppc-dev/20220819191557.28116-1-p...@kernel.org/
>>
>> Pali Rohár (8):
>>powerpc/85xx: Mark mpc85xx_rdb_pic_init() as static
>>powerpc/85xx: Mark mpc85xx_ds_pic_init() as static
>>powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
>>powerpc/85xx: p2020: Move i8259 code into own function
>>powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
>>powerpc/85xx: p2020: Define just one machine description
>>powerpc/85xx: p2020: Enable boards by new config option
>>  CONFIG_PPC_P2020
>>powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
>>
>>   arch/powerpc/boot/dts/turris1x.dts|   2 +-
>>   arch/powerpc/platforms/85xx/Kconfig   |  22 ++-
>>   arch/powerpc/platforms/85xx/Makefile  |   1 +
>>   arch/powerpc/platforms/85xx/mpc85xx_ds.c  |  25 +---
>>   arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  46 +-
>>   .../platforms/85xx/{mpc85xx_ds.c => p2020.c}  | 135 ++
>>   6 files changed, 68 insertions(+), 163 deletions(-)
>>   copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (52%)
>>
>> -- 
>> 2.20.1
>>


Re: [PATCH v3] powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage

2023-02-19 Thread Christophe Leroy




Le 25/01/2023 à 08:40, Christophe Leroy a écrit :



Le 22/01/2023 à 12:19, Pali Rohár a écrit :

On Saturday 24 December 2022 18:44:52 Pali Rohár wrote:

On Thursday 08 December 2022 19:57:39 Christophe Leroy wrote:

Le 08/12/2022 à 20:16, Pali Rohár a écrit :


With "[PATCH v1] powerpc/64: Set default CPU in Kconfig" patch from
https://lore.kernel.org/linuxppc-dev/3fd60c2d8a28668a42b766b18362a526ef47e757.1670420281.git.christophe.le...@csgroup.eu/
this change does not throw above compile error anymore.



That patch should land in powerpc/next soon. When it has landed, could
you resent this patch so that snowpatch checks the build again ?


Yes. But I'm still waiting because patch is not in powerpc/next yet.


Seems that it still has not landed. Any suggestions to move forward?


Hi

I just reposted to see if it passed the CI tests this time.


It is now in the tree.

Christophe


[PATCH] powerpc/e500: Add missing prototype for 'relocate_init'

2023-02-18 Thread Christophe Leroy
Kernel test robot reports:

 arch/powerpc/mm/nohash/e500.c:314:21: warning: no previous prototype for 
'relocate_init' [-Wmissing-prototypes]
 314 | notrace void __init relocate_init(u64 dt_ptr, phys_addr_t start)
 | ^

Add it in mm/mmu_decl.h, close to associated is_second_reloc
variable declaration.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/oe-kbuild-all/202302181136.wgyckucs-...@intel.com/
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/mm/mmu_decl.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index bd9784f77f2e..c6dccb4f06dc 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -120,6 +120,7 @@ extern int switch_to_as1(void);
 extern void restore_to_as0(int esel, int offset, void *dt_ptr, int bootcpu);
 void create_kaslr_tlb_entry(int entry, unsigned long virt, phys_addr_t phys);
 void reloc_kernel_entry(void *fdt, int addr);
+void relocate_init(u64 dt_ptr, phys_addr_t start);
 extern int is_second_reloc;
 #endif
 extern void loadcam_entry(unsigned int index);
-- 
2.39.1



[PATCH v2 07/10] powerpc: Make generic_calibrate_decr() the default

2023-02-18 Thread Christophe Leroy
ppc_md.calibrate_decr() is a mandatory item. Its nullity is never
checked so it must be non null on all platforms.

Most platforms define generic_calibrate_decr() as their
ppc_md.calibrate_decr(). Have time_init() call
generic_calibrate_decr() when ppc_md.calibrate_decr() is NULL,
and remove default assignment from all machines.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/time.c|  6 +-
 arch/powerpc/platforms/40x/ppc40x_simple.c|  1 -
 arch/powerpc/platforms/44x/canyonlands.c  |  1 -
 arch/powerpc/platforms/44x/ebony.c|  1 -
 arch/powerpc/platforms/44x/fsp2.c |  1 -
 arch/powerpc/platforms/44x/iss4xx.c   |  1 -
 arch/powerpc/platforms/44x/ppc44x_simple.c|  1 -
 arch/powerpc/platforms/44x/ppc476.c   |  2 --
 arch/powerpc/platforms/44x/sam440ep.c |  1 -
 arch/powerpc/platforms/44x/warp.c |  1 -
 arch/powerpc/platforms/512x/mpc5121_ads.c |  1 -
 arch/powerpc/platforms/512x/mpc512x_generic.c |  1 -
 arch/powerpc/platforms/512x/pdm360ng.c|  1 -
 arch/powerpc/platforms/52xx/efika.c   |  1 -
 arch/powerpc/platforms/52xx/lite5200.c|  1 -
 arch/powerpc/platforms/52xx/media5200.c   |  1 -
 arch/powerpc/platforms/52xx/mpc5200_simple.c  |  1 -
 arch/powerpc/platforms/82xx/ep8248e.c |  1 -
 arch/powerpc/platforms/82xx/km82xx.c  |  1 -
 arch/powerpc/platforms/82xx/mpc8272_ads.c |  1 -
 arch/powerpc/platforms/82xx/pq2fads.c |  1 -
 arch/powerpc/platforms/83xx/asp834x.c |  1 -
 arch/powerpc/platforms/83xx/km83xx.c  |  1 -
 arch/powerpc/platforms/83xx/mpc830x_rdb.c |  1 -
 arch/powerpc/platforms/83xx/mpc831x_rdb.c |  1 -
 arch/powerpc/platforms/83xx/mpc832x_mds.c |  1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |  1 -
 arch/powerpc/platforms/83xx/mpc834x_itx.c |  1 -
 arch/powerpc/platforms/83xx/mpc834x_mds.c |  1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |  1 -
 arch/powerpc/platforms/83xx/mpc836x_rdk.c |  1 -
 arch/powerpc/platforms/83xx/mpc837x_mds.c |  1 -
 arch/powerpc/platforms/83xx/mpc837x_rdb.c |  1 -
 arch/powerpc/platforms/85xx/bsc913x_qds.c |  1 -
 arch/powerpc/platforms/85xx/bsc913x_rdb.c |  1 -
 arch/powerpc/platforms/85xx/c293pcie.c|  1 -
 arch/powerpc/platforms/85xx/corenet_generic.c |  1 -
 arch/powerpc/platforms/85xx/ge_imp3a.c|  1 -
 arch/powerpc/platforms/85xx/ksi8560.c |  1 -
 arch/powerpc/platforms/85xx/mpc8536_ds.c  |  1 -
 arch/powerpc/platforms/85xx/mpc85xx_ads.c |  1 -
 arch/powerpc/platforms/85xx/mpc85xx_cds.c |  1 -
 arch/powerpc/platforms/85xx/mpc85xx_ds.c  |  3 ---
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  3 ---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 10 --
 arch/powerpc/platforms/85xx/mvme2500.c|  1 -
 arch/powerpc/platforms/85xx/p1010rdb.c|  1 -
 arch/powerpc/platforms/85xx/p1022_ds.c|  1 -
 arch/powerpc/platforms/85xx/p1022_rdk.c   |  1 -
 arch/powerpc/platforms/85xx/p1023_rdb.c   |  1 -
 arch/powerpc/platforms/85xx/ppa8548.c |  1 -
 arch/powerpc/platforms/85xx/qemu_e500.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/85xx/twr_p102x.c   |  1 -
 arch/powerpc/platforms/85xx/xes_mpc85xx.c |  3 ---
 arch/powerpc/platforms/86xx/gef_ppc9a.c   |  1 -
 arch/powerpc/platforms/86xx/gef_sbc310.c  |  1 -
 arch/powerpc/platforms/86xx/gef_sbc610.c  |  1 -
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c|  1 -
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|  1 -
 arch/powerpc/platforms/86xx/mvme7100.c|  1 -
 arch/powerpc/platforms/8xx/adder875.c |  1 -
 arch/powerpc/platforms/amigaone/setup.c   |  1 -
 arch/powerpc/platforms/cell/setup.c   |  1 -
 arch/powerpc/platforms/chrp/setup.c   |  1 -
 arch/powerpc/platforms/embedded6xx/gamecube.c |  1 -
 arch/powerpc/platforms/embedded6xx/holly.c|  1 -
 arch/powerpc/platforms/embedded6xx/linkstation.c  |  1 -
 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |  1 -
 arch/powerpc/platforms/embedded6xx/mvme5100.c |  1 -
 arch/powerpc/platforms/embedded6xx/storcenter.c   |  1 -
 arch/powerpc/platforms/embedded6xx/wii.c  |  1 -
 arch/powerpc/platforms/maple/setup.c  |  1 -
 arch/powerpc/platforms/microwatt/setup.c  |  1 -
 arch/powerpc/platforms/pasemi/setup.c |  1 -
 arch/powerpc/platforms/powernv/setup.c|  1 -
 arch/powerpc/platforms/pseries/setup.c|  1 -
 79 files changed, 5

[PATCH v2 09/10] powerpc: Use ppc_md_progress()

2023-02-18 Thread Christophe Leroy
Many places have:

if (ppc.md_progress)
ppc.md_progress();

Use ppc_md_progress() instead.

Note that checkpatch complains about using function names,
but this is not a function taking format strings, so we
leave the function names for now.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/setup_32.c |  3 +--
 arch/powerpc/mm/book3s32/mmu.c | 10 --
 arch/powerpc/mm/init_32.c  | 12 
 arch/powerpc/platforms/52xx/efika.c|  3 +--
 arch/powerpc/platforms/52xx/lite5200.c |  3 +--
 arch/powerpc/platforms/52xx/media5200.c|  3 +--
 arch/powerpc/platforms/52xx/mpc5200_simple.c   |  3 +--
 arch/powerpc/platforms/82xx/ep8248e.c  |  6 ++
 arch/powerpc/platforms/82xx/km82xx.c   |  6 ++
 arch/powerpc/platforms/82xx/mpc8272_ads.c  |  6 ++
 arch/powerpc/platforms/82xx/pq2fads.c  |  6 ++
 arch/powerpc/platforms/83xx/misc.c |  3 +--
 arch/powerpc/platforms/85xx/bsc913x_qds.c  |  3 +--
 arch/powerpc/platforms/85xx/bsc913x_rdb.c  |  3 +--
 arch/powerpc/platforms/85xx/c293pcie.c |  3 +--
 arch/powerpc/platforms/85xx/ge_imp3a.c |  3 +--
 arch/powerpc/platforms/85xx/ksi8560.c  |  3 +--
 arch/powerpc/platforms/85xx/mpc8536_ds.c   |  3 +--
 arch/powerpc/platforms/85xx/mpc85xx_ads.c  |  3 +--
 arch/powerpc/platforms/85xx/mpc85xx_cds.c  |  5 ++---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c   |  3 +--
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |  3 +--
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |  3 +--
 arch/powerpc/platforms/85xx/mvme2500.c |  3 +--
 arch/powerpc/platforms/85xx/p1010rdb.c |  3 +--
 arch/powerpc/platforms/85xx/p1022_ds.c |  3 +--
 arch/powerpc/platforms/85xx/p1022_rdk.c|  3 +--
 arch/powerpc/platforms/85xx/p1023_rdb.c|  3 +--
 arch/powerpc/platforms/85xx/ppa8548.c  |  3 +--
 arch/powerpc/platforms/85xx/qemu_e500.c|  2 +-
 arch/powerpc/platforms/85xx/socrates.c |  3 +--
 arch/powerpc/platforms/85xx/stx_gp3.c  |  3 +--
 arch/powerpc/platforms/85xx/tqm85xx.c  |  3 +--
 arch/powerpc/platforms/85xx/twr_p102x.c|  3 +--
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c |  3 +--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  3 +--
 arch/powerpc/platforms/86xx/mvme7100.c |  3 +--
 arch/powerpc/platforms/amigaone/setup.c|  3 +--
 arch/powerpc/platforms/chrp/setup.c|  5 ++---
 arch/powerpc/platforms/embedded6xx/holly.c |  6 ++
 .../platforms/embedded6xx/mpc7448_hpc2.c   |  7 +++
 arch/powerpc/platforms/embedded6xx/mvme5100.c  |  3 +--
 arch/powerpc/platforms/powermac/smp.c  | 18 --
 arch/powerpc/platforms/pseries/setup.c |  8 
 44 files changed, 69 insertions(+), 121 deletions(-)

diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index b761cc1a403c..843f64050efc 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -127,8 +127,7 @@ __setup("l3cr=", ppc_setup_l3cr);
 static int __init ppc_init(void)
 {
/* clear the progress line */
-   if (ppc_md.progress)
-   ppc_md.progress(" ", 0x);
+   ppc_md_progress(" ", 0x);
 
/* call platform init */
if (ppc_md.init != NULL) {
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 850783cfa9c7..ec6facff2779 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -347,7 +347,7 @@ void __init MMU_init_hw(void)
if (!mmu_has_feature(MMU_FTR_HPTE_TABLE))
return;
 
-   if ( ppc_md.progress ) ppc_md.progress("hash:enter", 0x105);
+   ppc_md_progress("hash:enter", 0x105);
 
 #define LG_HPTEG_SIZE  6   /* 64 bytes per HPTEG */
 #define SDR1_LOW_BITS  ((n_hpteg - 1) >> 10)
@@ -371,7 +371,7 @@ void __init MMU_init_hw(void)
/*
 * Find some memory for the hash table.
 */
-   if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
+   ppc_md_progress("hash:find piece", 0x322);
Hash = memblock_alloc(Hash_size, Hash_size);
if (!Hash)
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
@@ -396,10 +396,8 @@ void __init MMU_init_hw_patch(void)
if (!mmu_has_feature(MMU_FTR_HPTE_TABLE))
return;
 
-   if (ppc_md.progress)
-   ppc_md.progress("hash:patch", 0x345);
-   if (ppc_md.progress)
-   ppc_md.progress("hash:done", 0x205);
+   ppc_md_progress("hash:patch", 0x345);
+   ppc_md_progress("hash:done", 0x205);
 
/* WARNING: Make sure nothing can trigger a KASAN check past this point 
*/
 
di

<    4   5   6   7   8   9   10   11   12   13   >