Re: [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()

2022-06-24 Thread Christophe Leroy


Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
> objtool is throwing *unannotated intra-function call*
> warnings with a few instructions that are marked
> unreachable. Remove unreachable() from WARN_ON()
> to fix these warnings, as the codegen remains same
> with and without unreachable() in WARN_ON().

Did you try the two exemples described in commit 1e688dd2a3d6 
("powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with 
asm goto") ?

Without your patch:

0640 :
  640:  81 23 00 84 lwz r9,132(r3)
  644:  71 29 40 00 andi.   r9,r9,16384
  648:  40 82 00 0c bne 654 
  64c:  80 63 00 0c lwz r3,12(r3)
  650:  4e 80 00 20 blr
  654:  0f e0 00 00 twuir0,0

0658 :
  658:  2c 04 00 00 cmpwi   r4,0
  65c:  41 82 00 0c beq 668 
  660:  7c 63 23 96 divwu   r3,r3,r4
  664:  4e 80 00 20 blr
  668:  0f e0 00 00 twuir0,0
  66c:  38 60 00 00 li  r3,0
  670:  4e 80 00 20 blr


With your patch:

0640 :
  640:  81 23 00 84 lwz r9,132(r3)
  644:  71 29 40 00 andi.   r9,r9,16384
  648:  40 82 00 0c bne 654 
  64c:  80 63 00 0c lwz r3,12(r3)
  650:  4e 80 00 20 blr
  654:  0f e0 00 00 twuir0,0
  658:  4b ff ff f4 b   64c   <==

065c :
  65c:  2c 04 00 00 cmpwi   r4,0
  660:  41 82 00 0c beq 66c 
  664:  7c 63 23 96 divwu   r3,r3,r4
  668:  4e 80 00 20 blr
  66c:  0f e0 00 00 twuir0,0
  670:  38 60 00 00 li  r3,0<==
  674:  4e 80 00 20 blr <==
  678:  38 60 00 00 li  r3,0
  67c:  4e 80 00 20 blr


Christophe

> 
> Signed-off-by: Sathvika Vasireddy 
> ---
>   arch/powerpc/include/asm/bug.h | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
> index ecbae1832de3..df6c11e008b9 100644
> --- a/arch/powerpc/include/asm/bug.h
> +++ b/arch/powerpc/include/asm/bug.h
> @@ -97,7 +97,6 @@
>   __label__ __label_warn_on;  \
>   \
>   WARN_ENTRY("twi 31, 0, 0", BUGFLAG_WARNING | (flags), __label_warn_on); 
> \
> - unreachable();  \
>   \
>   __label_warn_on:\
>   break;  \

Re: [PATCH V4 10/26] openrisc/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

2022-06-24 Thread Stafford Horne
On Fri, Jun 24, 2022 at 10:13:23AM +0530, Anshuman Khandual wrote:
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] array. Subsequently all __SXXX and
> __PXXX macros can be dropped which are no longer needed.
> 
> Cc: Jonas Bonn 
> Cc: openr...@lists.librecores.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>  arch/openrisc/Kconfig   |  1 +
>  arch/openrisc/include/asm/pgtable.h | 18 --
>  arch/openrisc/mm/init.c | 20 
>  3 files changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
> index e814df4c483c..fe0dfb50eb86 100644
> --- a/arch/openrisc/Kconfig
> +++ b/arch/openrisc/Kconfig
> @@ -10,6 +10,7 @@ config OPENRISC
>   select ARCH_HAS_DMA_SET_UNCACHED
>   select ARCH_HAS_DMA_CLEAR_UNCACHED
>   select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> + select ARCH_HAS_VM_GET_PAGE_PROT
>   select COMMON_CLK
>   select OF
>   select OF_EARLY_FLATTREE
> diff --git a/arch/openrisc/include/asm/pgtable.h 
> b/arch/openrisc/include/asm/pgtable.h
> index c3abbf71e09f..dcae8aea132f 100644
> --- a/arch/openrisc/include/asm/pgtable.h
> +++ b/arch/openrisc/include/asm/pgtable.h
> @@ -176,24 +176,6 @@ extern void paging_init(void);
>   __pgprot(_PAGE_ALL | _PAGE_SRE | _PAGE_SWE \
>| _PAGE_SHARED | _PAGE_DIRTY | _PAGE_EXEC | _PAGE_CI)
>  
> -#define __P000   PAGE_NONE
> -#define __P001   PAGE_READONLY_X
> -#define __P010   PAGE_COPY
> -#define __P011   PAGE_COPY_X
> -#define __P100   PAGE_READONLY
> -#define __P101   PAGE_READONLY_X
> -#define __P110   PAGE_COPY
> -#define __P111   PAGE_COPY_X
> -
> -#define __S000   PAGE_NONE
> -#define __S001   PAGE_READONLY_X
> -#define __S010   PAGE_SHARED
> -#define __S011   PAGE_SHARED_X
> -#define __S100   PAGE_READONLY
> -#define __S101   PAGE_READONLY_X
> -#define __S110   PAGE_SHARED
> -#define __S111   PAGE_SHARED_X
> -
>  /* zero page used for uninitialized stuff */
>  extern unsigned long empty_zero_page[2048];
>  #define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
> diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
> index 3a021ab6f1ae..a654b9dcba91 100644
> --- a/arch/openrisc/mm/init.c
> +++ b/arch/openrisc/mm/init.c
> @@ -208,3 +208,23 @@ void __init mem_init(void)
>   mem_init_done = 1;
>   return;
>  }
> +
> +static pgprot_t protection_map[16] __ro_after_init = {
> + [VM_NONE]   = PAGE_NONE,
> + [VM_READ]   = PAGE_READONLY_X,
> + [VM_WRITE]  = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY_X,
> + [VM_EXEC]   = PAGE_READONLY,
> + [VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_EXEC | VM_WRITE]= PAGE_COPY,
> + [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_COPY_X,
> + [VM_SHARED] = PAGE_NONE,
> + [VM_SHARED | VM_READ]   = PAGE_READONLY_X,
> + [VM_SHARED | VM_WRITE]  = PAGE_SHARED,
> + [VM_SHARED | VM_WRITE | VM_READ]= PAGE_SHARED_X,
> + [VM_SHARED | VM_EXEC]   = PAGE_READONLY,
> + [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READONLY_X,
> + [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_SHARED,
> + [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_SHARED_X
> +};
> +DECLARE_VM_GET_PAGE_PROT

Looks good.

Acked-by: Stafford Horne 



Re: [PATCH V4 17/26] csky/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT

2022-06-24 Thread Guo Ren
For csky part.

Acked-by: Guo Ren 


On Fri, Jun 24, 2022 at 12:48 PM Anshuman Khandual
 wrote:
>
> This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
> vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
> up a private and static protection_map[] array. Subsequently all __SXXX and
> __PXXX macros can be dropped which are no longer needed.
>
> Cc: Geert Uytterhoeven 
> Cc: linux-c...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 
> ---
>  arch/csky/Kconfig   |  1 +
>  arch/csky/include/asm/pgtable.h | 18 --
>  arch/csky/mm/init.c | 20 
>  3 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index 21d72b078eef..588b8a9c68ed 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -6,6 +6,7 @@ config CSKY
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_HAS_SYNC_DMA_FOR_CPU
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> +   select ARCH_HAS_VM_GET_PAGE_PROT
> select ARCH_USE_BUILTIN_BSWAP
> select ARCH_USE_QUEUED_RWLOCKS
> select ARCH_WANT_FRAME_POINTERS if !CPU_CK610 && 
> $(cc-option,-mbacktrace)
> diff --git a/arch/csky/include/asm/pgtable.h b/arch/csky/include/asm/pgtable.h
> index bbe24511..229a5f4ad7fc 100644
> --- a/arch/csky/include/asm/pgtable.h
> +++ b/arch/csky/include/asm/pgtable.h
> @@ -77,24 +77,6 @@
>  #define MAX_SWAPFILES_CHECK() \
> BUILD_BUG_ON(MAX_SWAPFILES_SHIFT != 5)
>
> -#define __P000 PAGE_NONE
> -#define __P001 PAGE_READ
> -#define __P010 PAGE_READ
> -#define __P011 PAGE_READ
> -#define __P100 PAGE_READ
> -#define __P101 PAGE_READ
> -#define __P110 PAGE_READ
> -#define __P111 PAGE_READ
> -
> -#define __S000 PAGE_NONE
> -#define __S001 PAGE_READ
> -#define __S010 PAGE_WRITE
> -#define __S011 PAGE_WRITE
> -#define __S100 PAGE_READ
> -#define __S101 PAGE_READ
> -#define __S110 PAGE_WRITE
> -#define __S111 PAGE_WRITE
> -
>  extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>  #define ZERO_PAGE(vaddr)   (virt_to_page(empty_zero_page))
>
> diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c
> index bf2004aa811a..1bf7b2a748fd 100644
> --- a/arch/csky/mm/init.c
> +++ b/arch/csky/mm/init.c
> @@ -197,3 +197,23 @@ void __init fixaddr_init(void)
> vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
> fixrange_init(vaddr, vaddr + PMD_SIZE, swapper_pg_dir);
>  }
> +
> +static pgprot_t protection_map[16] __ro_after_init = {
> +   [VM_NONE]   = PAGE_NONE,
> +   [VM_READ]   = PAGE_READ,
> +   [VM_WRITE]  = PAGE_READ,
> +   [VM_WRITE | VM_READ]= PAGE_READ,
> +   [VM_EXEC]   = PAGE_READ,
> +   [VM_EXEC | VM_READ] = PAGE_READ,
> +   [VM_EXEC | VM_WRITE]= PAGE_READ,
> +   [VM_EXEC | VM_WRITE | VM_READ]  = PAGE_READ,
> +   [VM_SHARED] = PAGE_NONE,
> +   [VM_SHARED | VM_READ]   = PAGE_READ,
> +   [VM_SHARED | VM_WRITE]  = PAGE_WRITE,
> +   [VM_SHARED | VM_WRITE | VM_READ]= PAGE_WRITE,
> +   [VM_SHARED | VM_EXEC]   = PAGE_READ,
> +   [VM_SHARED | VM_EXEC | VM_READ] = PAGE_READ,
> +   [VM_SHARED | VM_EXEC | VM_WRITE]= PAGE_WRITE,
> +   [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ]  = PAGE_WRITE
> +};
> +DECLARE_VM_GET_PAGE_PROT
> --
> 2.25.1
>


--
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/


Re: power9 slab-out-of-bounds in _find_First_zero_bit

2022-06-24 Thread Liam Howlett
* Nathan Lynch  [220624 19:51]:
> Hi Liam,
> 
> Liam Howlett  writes:
> >
> > When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
> > following on boot:
> >
> > [0.174621] 
> > ==
> > [0.175501] BUG: KASAN: slab-out-of-bounds in 
> > _find_first_zero_bit+0x40/0x140
> > [0.176132] Read of size 8 at addr cf7f0410 by task swapper/0/1
> > [0.176900] 
> > [0.177844] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
> > 5.19.0-rc3+ #8
> > [0.179461] Call Trace:
> > [0.179907] [c000119677d0] [c75af350] 
> > dump_stack_lvl+0x74/0xa8 (unreliable)
> > [0.181107] [c00011967810] [c0632220] 
> > print_report+0x330/0x740
> > [0.181977] [c000119678e0] [c0632980] 
> > kasan_report+0x100/0x1f0
> > [0.182788] [c000119679c0] [c0634de4] __asan_load8+0xa4/0xe0
> > [0.183560] [c000119679e0] [c18b92b0] 
> > _find_first_zero_bit+0x40/0x140
> > [0.184119] [c00011967a20] [c00c5f7c] 
> > xive_spapr_get_ipi+0xcc/0x220
> > [0.184689] [c00011967ad0] [c00c1adc] 
> > xive_setup_cpu_ipi+0x1ec/0x420
> > [0.185231] [c00011967b90] [ca033b3c] 
> > pSeries_smp_probe+0x44/0xd4
> > [0.185825] [c00011967bc0] [ca01c77c] 
> > smp_prepare_cpus+0x62c/0x688
> > [0.186359] [c00011967cb0] [ca00ea94] 
> > kernel_init_freeable+0x24c/0x520
> > [0.186893] [c00011967d90] [c0012b00] kernel_init+0x30/0x1c0
> > [0.187395] [c00011967e10] [c000ce54] 
> > ret_from_kernel_thread+0x5c/0x64
> 
> [...]
> 
> Please try "powerpc/xive/spapr: correct bitmap allocation size", posted 
> yesterday:
> 
> https://lore.kernel.org/linuxppc-dev/20220623182509.3985625-1-nath...@linux.ibm.com/

Thanks, that works.


Re: power9 slab-out-of-bounds in _find_First_zero_bit

2022-06-24 Thread Nathan Lynch
Hi Liam,

Liam Howlett  writes:
>
> When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
> following on boot:
>
> [0.174621] 
> ==
> [0.175501] BUG: KASAN: slab-out-of-bounds in 
> _find_first_zero_bit+0x40/0x140
> [0.176132] Read of size 8 at addr cf7f0410 by task swapper/0/1
> [0.176900] 
> [0.177844] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
> 5.19.0-rc3+ #8
> [0.179461] Call Trace:
> [0.179907] [c000119677d0] [c75af350] dump_stack_lvl+0x74/0xa8 
> (unreliable)
> [0.181107] [c00011967810] [c0632220] print_report+0x330/0x740
> [0.181977] [c000119678e0] [c0632980] kasan_report+0x100/0x1f0
> [0.182788] [c000119679c0] [c0634de4] __asan_load8+0xa4/0xe0
> [0.183560] [c000119679e0] [c18b92b0] 
> _find_first_zero_bit+0x40/0x140
> [0.184119] [c00011967a20] [c00c5f7c] 
> xive_spapr_get_ipi+0xcc/0x220
> [0.184689] [c00011967ad0] [c00c1adc] 
> xive_setup_cpu_ipi+0x1ec/0x420
> [0.185231] [c00011967b90] [ca033b3c] 
> pSeries_smp_probe+0x44/0xd4
> [0.185825] [c00011967bc0] [ca01c77c] 
> smp_prepare_cpus+0x62c/0x688
> [0.186359] [c00011967cb0] [ca00ea94] 
> kernel_init_freeable+0x24c/0x520
> [0.186893] [c00011967d90] [c0012b00] kernel_init+0x30/0x1c0
> [0.187395] [c00011967e10] [c000ce54] 
> ret_from_kernel_thread+0x5c/0x64

[...]

Please try "powerpc/xive/spapr: correct bitmap allocation size", posted 
yesterday:

https://lore.kernel.org/linuxppc-dev/20220623182509.3985625-1-nath...@linux.ibm.com/


Re: [PATCH RESEND v9 1/5] arc: dts: Harmonize EHCI/OHCI DT nodes name

2022-06-24 Thread Serge Semin
On Fri, Jun 24, 2022 at 03:11:43PM -0700, Vineet Gupta wrote:
> 
> On 6/24/22 07:16, Serge Semin wrote:
> > In accordance with the Generic EHCI/OHCI bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acceptable by the regexp:
> > "^usb(@.*)?"  . Make sure the "generic-ehci" and "generic-ohci"-compatible
> > nodes are correctly named.
> > 
> > Signed-off-by: Serge Semin
> > Acked-by: Alexey Brodkin
> > Acked-by: Krzysztof Kozlowski
> 

> This slipped thru cracks. Now on for-curr.

Great! Thanks.

-Sergey

> 
> Thx,
> -Vineet


Re: [PATCH RESEND v9 1/5] arc: dts: Harmonize EHCI/OHCI DT nodes name

2022-06-24 Thread Vineet Gupta



On 6/24/22 07:16, Serge Semin wrote:

In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?"  . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin
Acked-by: Alexey Brodkin
Acked-by: Krzysztof Kozlowski


This slipped thru cracks. Now on for-curr.

Thx,
-Vineet


power9 slab-out-of-bounds in _find_First_zero_bit

2022-06-24 Thread Liam Howlett
Hello,

When trying v5.19-rc3 on my ppc64 VM with KASANs enabled, I get the
following on boot:

[0.174621] 
==
[0.175501] BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
[0.176132] Read of size 8 at addr cf7f0410 by task swapper/0/1
[0.176900] 
[0.177844] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 
5.19.0-rc3+ #8
[0.179461] Call Trace:
[0.179907] [c000119677d0] [c75af350] dump_stack_lvl+0x74/0xa8 
(unreliable)
[0.181107] [c00011967810] [c0632220] print_report+0x330/0x740
[0.181977] [c000119678e0] [c0632980] kasan_report+0x100/0x1f0
[0.182788] [c000119679c0] [c0634de4] __asan_load8+0xa4/0xe0
[0.183560] [c000119679e0] [c18b92b0] 
_find_first_zero_bit+0x40/0x140
[0.184119] [c00011967a20] [c00c5f7c] 
xive_spapr_get_ipi+0xcc/0x220
[0.184689] [c00011967ad0] [c00c1adc] 
xive_setup_cpu_ipi+0x1ec/0x420
[0.185231] [c00011967b90] [ca033b3c] pSeries_smp_probe+0x44/0xd4
[0.185825] [c00011967bc0] [ca01c77c] 
smp_prepare_cpus+0x62c/0x688
[0.186359] [c00011967cb0] [ca00ea94] 
kernel_init_freeable+0x24c/0x520
[0.186893] [c00011967d90] [c0012b00] kernel_init+0x30/0x1c0
[0.187395] [c00011967e10] [c000ce54] 
ret_from_kernel_thread+0x5c/0x64
[0.188124] 
[0.188429] Allocated by task 0:
[0.188820]  kasan_save_stack+0x34/0x70
[0.189298]  __kasan_kmalloc+0xb8/0xf0
[0.189617]  __kmalloc+0x148/0x570
[0.189909]  xive_spapr_init+0x478/0x6fc
[0.190212]  pseries_init_irq+0x48/0x284
[0.190523]  init_IRQ+0x4c/0x8c
[0.190810]  start_kernel+0x25c/0x4d0
[0.191130]  start_here_common+0x1c/0x20
[0.191549] 
[0.191845] The buggy address belongs to the object at cf7f0410
[0.191845]  which belongs to the cache kmalloc-8 of size 8
[0.192594] The buggy address is located 0 bytes inside of
[0.192594]  8-byte region [cf7f0410, cf7f0418)
[0.193250] 
[0.193499] The buggy address belongs to the physical page:
[0.194324] page:c00c0003dfc0 refcount:1 mapcount:0 
mapping: index:0x0 pfn:0xf7f
[0.195277] flags: 0x700200(slab|node=0|zone=0|lastcpupid=0x7)
[0.196521] raw: 00700200  5deadbeef122 
cf7e0300
[0.197023] raw:  86660666 0001 

[0.197558] page dumped because: kasan: bad access detected
[0.197938] 
[0.198128] Memory state around the buggy address:
[0.198676]  cf7f0300: fc fc fc fc 03 fc fc fc fc 03 fc fc fc fc 03 
fc
[0.199218]  cf7f0380: fc fc fc 03 fc fc fc fc 03 fc fc fc fc 03 fc 
fc
[0.199671] >cf7f0400: fc fc 02 fc fc fc fc 04 fc fc fc fc 04 fc fc 
fc
[0.200122]  ^
[0.200464]  cf7f0480: fc 00 fc fc fc fc fa fc fc fc fc 02 fc fc fc 
fc
[0.200905]  cf7f0500: fa fc fc fc fc fa fc fc fc fc fa fc fc fc fc 
00
[0.201379] 
==


Thanks,
Liam

Re: [PATCH RESEND v9 5/5] arm64: dts: apm: Harmonize DWC USB3 DT nodes name

2022-06-24 Thread Serge Semin
On Fri, Jun 24, 2022 at 07:17:53PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the DWC USB3 bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acceptable by the regexp:
> > "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> > named despite of the warning comment about possible backward
> > compatibility issues.
> 

> Sometimes node name is exposed to user-space which depends on it. How
> did you check there is no issue here?

I well remember the Qcom problem caused by one of my patch:
https://lore.kernel.org/lkml/calaqxlx_fnvfndedwtgbfpjszuabfqxqe07dibjfztftwej...@mail.gmail.com/

The next patch caused the same problem, but hasn't been reverted.
https://lore.kernel.org/lkml/calaqxlwgujgr7p8vb5s_rimrvyxwm5xf-c4nkkgmh-43web...@mail.gmail.com/

As before I am more inclined to thinking that the problem was mainly caused
by the improper node-name utilization. Anyway John later noted that the
problem was fixed in the user-space. That why afterwards you were able
to provide the commit b77a1c4d6b05 ("arm64: dts: qcom: correct DWC3
node names and unit addresses").

Anyway I am not able to track the way the node-name is used on the
affected platform and can't make sure that the dts would be still
working well on that devices. But seeing nobody responded/commented on
this patch for more than a year we can at least try to merge this in
and see whether it causes any problem should the denoted platform is
still in use. If it does we can revert the update back and forget
about it.

-Sergey

> 
> > 
> > Signed-off-by: Serge Semin 
> > Acked-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
> >  arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
> > b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> > index a83c82c50e29..832dd85b00bd 100644
> > --- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> > +++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> > @@ -597,8 +597,8 @@ serial0: serial@1060 {
> > interrupts = <0x0 0x4c 0x4>;
> > };
> >  
> > -   /* Do not change dwusb name, coded for backward compatibility */
> > -   usb0: dwusb@1900 {
> > +   /* Node-name might need to be coded as dwusb for backward 
> > compatibility */
> > +   usb0: usb@1900 {
> > status = "disabled";
> > compatible = "snps,dwc3";
> > reg =  <0x0 0x1900 0x0 0x10>;
> > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> > b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> > index 0f37e77f5459..1520a945b7f9 100644
> > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> > @@ -923,8 +923,8 @@ sata3: sata@1a80 {
> > phy-names = "sata-phy";
> > };
> >  
> > -   /* Do not change dwusb name, coded for backward compatibility */
> > -   usb0: dwusb@1900 {
> > +   /* Node-name might need to be coded as dwusb for backward 
> > compatibility */
> > +   usb0: usb@1900 {
> > status = "disabled";
> > compatible = "snps,dwc3";
> > reg =  <0x0 0x1900 0x0 0x10>;
> > @@ -933,7 +933,7 @@ usb0: dwusb@1900 {
> > dr_mode = "host";
> > };
> >  
> > -   usb1: dwusb@1980 {
> > +   usb1: usb@1980 {
> > status = "disabled";
> > compatible = "snps,dwc3";
> > reg =  <0x0 0x1980 0x0 0x10>;
> 
> 
> Best regards,
> Krzysztof


Re: [PATCH RESEND v9 4/5] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name

2022-06-24 Thread Serge Semin
On Fri, Jun 24, 2022 at 07:18:57PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the DWC USB3 bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acceptable by the regexp:
> > "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> > named.
> > 
> > Signed-off-by: Serge Semin 
> > Acked-by: Krzysztof Kozlowski 
> > Reviewed-by: Patrice Chotard 
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> > b/arch/arm/boot/dts/stih407-family.dtsi
> > index 1713f7878117..7ba528315dbe 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -725,7 +725,7 @@ st_dwc3: dwc3@8f94000 {
> >  
> > status = "disabled";
> >  
> > -   dwc3: dwc3@990 {
> > +   dwc3: usb@990 {
> 

> This does not apply. What tree is it based on?

That's weird. The series has been rebased onto the mainline kernel v5.19-rc3.
Do you have the stih407 dtsi fixed on your local repo?

-Sergey

> 
> 
> Best regards,
> Krzysztof


Re: [PATCH RESEND v9 2/5] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name

2022-06-24 Thread Serge Semin
On Fri, Jun 24, 2022 at 07:14:44PM +0200, Krzysztof Kozlowski wrote:
> On 24/06/2022 16:16, Serge Semin wrote:
> > In accordance with the Generic EHCI/OHCI bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes to have the name acceptable by the regexp:
> > "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> > nodes are correctly named.
> > 
> > Signed-off-by: Serge Semin 
> > Acked-by: Vladimir Zapolskiy 
> > Acked-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
> 

> You should split the patchset per architecture, because maybe that's why
> no one picks it up?

Each patch is sent out to the corresponding mailing list and the
maintainers. I don't think splitting the patchset into the subsets will
be more efficient especially seeing the initial patchset consisted of
30 patches of which only five left.

I was very busy last year with another activities so what was left of this
patchset was stalling on my local repo all that time. I have been very
surprised to realise that the submitted part still hasn't been merged in for
all that time. So I've got back to resubmitting the series.

* Though the Qualcom dts have been fixed by you lately.

> 
> Let me pick up ARM bits through my cleanup series. If anyone objects,
> please let me know.

Ok. Thanks.

-Sergey

> 
> Best regards,
> Krzysztof


[linux-next:master] BUILD REGRESSION 2f9cb3d3bd73fc2225d66aa8fcffb632ed3eb235

2022-06-24 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2f9cb3d3bd73fc2225d66aa8fcffb632ed3eb235  Add linux-next specific 
files for 20220624

Error/Warning reports:

https://lore.kernel.org/llvm/202206221813.dn1s6uuh-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

arch/powerpc/kernel/interrupt.c:542:55: error: suggest braces around empty body 
in an 'if' statement [-Werror=empty-body]
arch/powerpc/kernel/interrupt.c:542:55: warning: suggest braces around empty 
body in an 'if' statement [-Wempty-body]
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1025:33: warning: 
variable 'pre_connection_type' set but not used [-Wunused-but-set-variable]
drivers/ntb/test/ntb_perf.c:1145: undefined reference to `__umoddi3'
drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous 
prototype for function 'pci_read' [-Wmissing-prototypes]
drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous 
prototype for function 'pci_write' [-Wmissing-prototypes]
include/linux/fs.h:1656: warning: expecting prototype for i_gid_into_mnt(). 
Prototype was for i_gid_into_vfsgid() instead

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

drivers/net/pcs/pcs-xpcs.c:1031: undefined reference to 
`phylink_mii_c22_pcs_decode_state'
drivers/net/pcs/pcs-xpcs.c:832: undefined reference to 
`phylink_mii_c22_pcs_encode_advertisement'

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- arc-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- arc-randconfig-m031-20220624
|   |-- 
drivers-gpu-drm-vc4-vc4_perfmon.c-vc4_perfmon_get()-warn:variable-dereferenced-before-check-perfmon-(see-line-)
|   `-- 
drivers-gpu-drm-vc4-vc4_perfmon.c-vc4_perfmon_get_values_ioctl()-warn:variable-dereferenced-before-check-perfmon-(see-line-)
|-- arm-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- arm64-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- arm64-buildonly-randconfig-r004-20220624
|   `-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|-- i386-allnoconfig
|   `-- 
include-linux-fs.h:warning:expecting-prototype-for-i_gid_into_mnt().-Prototype-was-for-i_gid_into_vfsgid()-instead
|-- i386-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   |-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|   `-- ntb_perf.c:(.text):undefined-reference-to-__umoddi3
|-- i386-randconfig-a001
|   `-- ntb_perf.c:(.text):undefined-reference-to-__umoddi3
|-- i386-randconfig-a005
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- i386-randconfig-m021
|   `-- arch-x86-events-core.c-init_hw_perf_events()-warn:missing-error-code-err
|-- ia64-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- m68k-allmodconfig
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- m68k-allyesconfig
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- microblaze-randconfig-r006-20220624
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- drivers-ntb-test-ntb_perf.c:undefined-reference-to-__umoddi3
|-- mips-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link.c:warning:variable-pre_connection_type-set-but-not-used
|   `-- 
drivers-staging-rtl8723bs-hal-hal_btcoex.c:warning:variable-pHalData-set-but-not-used
|-- nios2-randconfig-r016-20220624
|   |-- 
drivers-net-pcs-pcs-xpcs.c:undefined-reference-to-phylink_mii_c22_pcs_decode_state
|   `-- 
drivers-net-pcs-pcs-xpcs.c:undefined-reference-to-phylink_mii_c22_pcs_encode_advertisement
|-- powerpc-allmodconfig
|   |-- ERROR:__umoddi3-drivers-ntb-test-ntb_perf.ko-undefined
|   |

Re: [RFC PATCH v2 0/7] objtool: Enable and implement --mcount option on powerpc

2022-06-24 Thread Sathvika Vasireddy

Hi Christophe,

On 24/06/22 12:38, Christophe Leroy wrote:

Is everything going ok ? Don't hesitate if you need help.


Yeah, sure. Thanks!

I just posted RFC v3 here: 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20220624183238.388144-1...@linux.ibm.com/




[RFC PATCH v3 12/12] objtool/powerpc: Fix unannotated intra-function call warnings

2022-06-24 Thread Sathvika Vasireddy
objtool throws unannotated intra-function call warnings
in the following assembly files.

arch/powerpc/kernel/head_64.o: warning: objtool: .text+0x358: unannotated 
intra-function call
arch/powerpc/kernel/vector.o: warning: objtool: .text+0x53c: unannotated 
intra-function call
arch/powerpc/kernel/entry_64.o: warning: objtool: .text+0x4: unannotated 
intra-function call
arch/powerpc/kernel/misc_64.o: warning: objtool: .text+0x64: unannotated 
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0x60: 
unannotated intra-function call
arch/powerpc/kvm/book3s_hv_interrupts.o: warning: objtool: .text+0x6c: 
unannotated intra-function call

Remove a few of these warnings by putting ANNOTATE_INTRA_FUNCTION_CALL
directive before the call. And, the rest by annotating those functions
with SYM_FUNC_START_LOCAL() and SYM_FUNC_END() macros.

Signed-off-by: Sathvika Vasireddy 
---
 arch/powerpc/kernel/entry_64.S  |  2 ++
 arch/powerpc/kernel/exceptions-64s.S|  7 +--
 arch/powerpc/kernel/head_64.S   |  7 +--
 arch/powerpc/kernel/misc_64.S   |  4 +++-
 arch/powerpc/kernel/vector.S|  4 +++-
 arch/powerpc/kvm/book3s_hv_interrupts.S |  4 +++-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 25 ++---
 7 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9581906b5ee9..11249cd6cfc5 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -14,6 +14,7 @@
  *  code, and exception/interrupt return code for PowerPC.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +74,7 @@ flush_branch_caches:
 
// Flush the link stack
.rept 64
+   ANNOTATE_INTRA_FUNCTION_CALL
bl  .+4
.endr
b   1f
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index b66dd6f775a4..14ed17b8fe33 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -13,6 +13,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -3075,7 +3076,7 @@ CLOSE_FIXED_SECTION(virt_trampolines);
 USE_TEXT_SECTION()
 
 /* MSR[RI] should be clear because this uses SRR[01] */
-enable_machine_check:
+SYM_FUNC_START_LOCAL(enable_machine_check)
mflrr0
bcl 20,31,$+4
 0: mflrr3
@@ -3087,9 +3088,10 @@ enable_machine_check:
RFI_TO_KERNEL
 1: mtlrr0
blr
+SYM_FUNC_END(enable_machine_check)
 
 /* MSR[RI] should be clear because this uses SRR[01] */
-disable_machine_check:
+SYM_FUNC_START_LOCAL(disable_machine_check)
mflrr0
bcl 20,31,$+4
 0: mflrr3
@@ -3102,3 +3104,4 @@ disable_machine_check:
RFI_TO_KERNEL
 1: mtlrr0
blr
+SYM_FUNC_END(disable_machine_check)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 5c5181e8d5f1..d5b01a15cb39 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -18,6 +18,7 @@
  *  variants.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -465,7 +466,7 @@ generic_secondary_common_init:
  * Assumes we're mapped EA == RA if the MMU is on.
  */
 #ifdef CONFIG_PPC_BOOK3S
-__mmu_off:
+SYM_FUNC_START_LOCAL(__mmu_off)
mfmsr   r3
andi.   r0,r3,MSR_IR|MSR_DR
beqlr
@@ -476,6 +477,7 @@ __mmu_off:
sync
rfid
b   .   /* prevent speculative execution */
+SYM_FUNC_END(__mmu_off)
 #endif
 
 
@@ -869,7 +871,7 @@ _GLOBAL(start_secondary_resume)
 /*
  * This subroutine clobbers r11 and r12
  */
-enable_64b_mode:
+SYM_FUNC_START_LOCAL(enable_64b_mode)
mfmsr   r11 /* grab the current MSR */
 #ifdef CONFIG_PPC_BOOK3E
orisr11,r11,0x8000  /* CM bit set, we'll set ICM later */
@@ -881,6 +883,7 @@ enable_64b_mode:
isync
 #endif
blr
+SYM_FUNC_END(enable_64b_mode)
 
 /*
  * This puts the TOC pointer into r2, offset by 0x8000 (as expected
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index d38a019b38e1..372d3dae25af 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -9,6 +9,7 @@
  * PPC64 updates by Dave Engebretsen (engeb...@us.ibm.com)
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -353,7 +354,7 @@ _GLOBAL(kexec_smp_wait)
  *
  * don't overwrite r3 here, it is live for kexec_wait above.
  */
-real_mode: /* assume normal blr return */
+SYM_FUNC_START_LOCAL(real_mode)/* assume normal blr return */
 #ifdef CONFIG_PPC_BOOK3E
/* Create an identity mapping. */
b   kexec_create_tlb
@@ -370,6 +371,7 @@ real_mode:  /* assume normal blr return */
mtspr   SPRN_SRR0,r11
rfid
 #endif
+SYM_FUNC_END(real_mode)
 
 /*
  * kexec_sequence(newstack, start, image, control, clear_all(),
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index 5cc24d8cce94.

[RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()

2022-06-24 Thread Sathvika Vasireddy
objtool is throwing *unannotated intra-function call*
warnings with a few instructions that are marked
unreachable. Remove unreachable() from WARN_ON()
to fix these warnings, as the codegen remains same
with and without unreachable() in WARN_ON().

Signed-off-by: Sathvika Vasireddy 
---
 arch/powerpc/include/asm/bug.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index ecbae1832de3..df6c11e008b9 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -97,7 +97,6 @@
__label__ __label_warn_on;  \
\
WARN_ENTRY("twi 31, 0, 0", BUGFLAG_WARNING | (flags), __label_warn_on); 
\
-   unreachable();  \
\
 __label_warn_on:   \
break;  \
-- 
2.25.1



[RFC PATCH v3 10/12] objtool/powerpc: Add --mcount specific implementation

2022-06-24 Thread Sathvika Vasireddy
This patch enables objtool --mcount on powerpc, and
adds implementation specific to powerpc.

Signed-off-by: Sathvika Vasireddy 
---
 arch/powerpc/Kconfig  |  1 +
 tools/objtool/arch/powerpc/decode.c   | 22 +++
 tools/objtool/arch/powerpc/include/arch/elf.h |  2 ++
 3 files changed, 25 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 732a3f91ee5e..3373d44a1298 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -233,6 +233,7 @@ config PPC
select HAVE_NMI if PERF_EVENTS || (PPC64 && 
PPC_BOOK3S)
select HAVE_OPTPROBES
select HAVE_OBJTOOL if PPC64
+   select HAVE_OBJTOOL_MCOUNT  if HAVE_OBJTOOL
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/tools/objtool/arch/powerpc/decode.c 
b/tools/objtool/arch/powerpc/decode.c
index 8b6a14680da7..06fc0206bf8e 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -9,6 +9,14 @@
 #include 
 #include 
 
+bool arch_ftrace_match(char *name)
+{
+   if ((!strcmp(name, "_mcount")) || (!strcmp(name, "._mcount")))
+   return true;
+
+   return false;
+}
+
 unsigned long arch_dest_reloc_offset(int addend)
 {
return addend;
@@ -41,12 +49,26 @@ int arch_decode_instruction(struct objtool_file *file, 
const struct section *sec
struct list_head *ops_list)
 {
u32 insn;
+   unsigned int opcode;
 
*immediate = 0;
insn = bswap_if_needed(file->elf, *(u32 *)(sec->data->d_buf + offset));
*len = 4;
*type = INSN_OTHER;
 
+   opcode = insn >> 26;
+
+   switch (opcode) {
+   case 18: /* bl */
+   if ((insn & 3) == 1) {
+   *type = INSN_CALL;
+   *immediate = insn & 0x3fc;
+   if (*immediate & 0x200)
+   *immediate -= 0x400;
+   }
+   break;
+   }
+
return 0;
 }
 
diff --git a/tools/objtool/arch/powerpc/include/arch/elf.h 
b/tools/objtool/arch/powerpc/include/arch/elf.h
index 3c8ebb7d2a6b..73f9ae172fe5 100644
--- a/tools/objtool/arch/powerpc/include/arch/elf.h
+++ b/tools/objtool/arch/powerpc/include/arch/elf.h
@@ -4,5 +4,7 @@
 #define _OBJTOOL_ARCH_ELF
 
 #define R_NONE R_PPC_NONE
+#define R_ABS64 R_PPC64_ADDR64
+#define R_ABS32 R_PPC_ADDR32
 
 #endif /* _OBJTOOL_ARCH_ELF */
-- 
2.25.1



[RFC PATCH v3 09/12] objtool/powerpc: Enable objtool to be built on ppc

2022-06-24 Thread Sathvika Vasireddy
This patch adds [stub] implementations for required
functions, inorder to enable objtool build on powerpc.

Signed-off-by: Sathvika Vasireddy 
---
 arch/powerpc/Kconfig  |  1 +
 tools/objtool/arch/powerpc/Build  |  2 +
 tools/objtool/arch/powerpc/decode.c   | 74 +++
 .../arch/powerpc/include/arch/cfi_regs.h  | 11 +++
 tools/objtool/arch/powerpc/include/arch/elf.h |  8 ++
 .../arch/powerpc/include/arch/special.h   | 21 ++
 tools/objtool/arch/powerpc/special.c  | 19 +
 7 files changed, 136 insertions(+)
 create mode 100644 tools/objtool/arch/powerpc/Build
 create mode 100644 tools/objtool/arch/powerpc/decode.c
 create mode 100644 tools/objtool/arch/powerpc/include/arch/cfi_regs.h
 create mode 100644 tools/objtool/arch/powerpc/include/arch/elf.h
 create mode 100644 tools/objtool/arch/powerpc/include/arch/special.h
 create mode 100644 tools/objtool/arch/powerpc/special.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 174edabb74fa..732a3f91ee5e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -232,6 +232,7 @@ config PPC
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 && 
PPC_BOOK3S)
select HAVE_OPTPROBES
+   select HAVE_OBJTOOL if PPC64
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/tools/objtool/arch/powerpc/Build b/tools/objtool/arch/powerpc/Build
new file mode 100644
index ..d24d5636a5b8
--- /dev/null
+++ b/tools/objtool/arch/powerpc/Build
@@ -0,0 +1,2 @@
+objtool-y += decode.o
+objtool-y += special.o
diff --git a/tools/objtool/arch/powerpc/decode.c 
b/tools/objtool/arch/powerpc/decode.c
new file mode 100644
index ..8b6a14680da7
--- /dev/null
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+unsigned long arch_dest_reloc_offset(int addend)
+{
+   return addend;
+}
+
+bool arch_callee_saved_reg(unsigned char reg)
+{
+   return false;
+}
+
+int arch_decode_hint_reg(u8 sp_reg, int *base)
+{
+   exit(-1);
+}
+
+const char *arch_nop_insn(int len)
+{
+   exit(-1);
+}
+
+const char *arch_ret_insn(int len)
+{
+   exit(-1);
+}
+
+int arch_decode_instruction(struct objtool_file *file, const struct section 
*sec,
+   unsigned long offset, unsigned int maxlen,
+   unsigned int *len, enum insn_type *type,
+   unsigned long *immediate,
+   struct list_head *ops_list)
+{
+   u32 insn;
+
+   *immediate = 0;
+   insn = bswap_if_needed(file->elf, *(u32 *)(sec->data->d_buf + offset));
+   *len = 4;
+   *type = INSN_OTHER;
+
+   return 0;
+}
+
+unsigned long arch_jump_destination(struct instruction *insn)
+{
+   return insn->offset +  insn->immediate;
+}
+
+void arch_initial_func_cfi_state(struct cfi_init_state *state)
+{
+   int i;
+
+   for (i = 0; i < CFI_NUM_REGS; i++) {
+   state->regs[i].base = CFI_UNDEFINED;
+   state->regs[i].offset = 0;
+   }
+
+   /* initial CFA (call frame address) */
+   state->cfa.base = CFI_SP;
+   state->cfa.offset = 0;
+
+   /* initial LR (return address) */
+   state->regs[CFI_RA].base = CFI_CFA;
+   state->regs[CFI_RA].offset = 0;
+}
diff --git a/tools/objtool/arch/powerpc/include/arch/cfi_regs.h 
b/tools/objtool/arch/powerpc/include/arch/cfi_regs.h
new file mode 100644
index ..59638ebeafc8
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/cfi_regs.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _OBJTOOL_CFI_REGS_H
+#define _OBJTOOL_CFI_REGS_H
+
+#define CFI_BP 1
+#define CFI_SP CFI_BP
+#define CFI_RA 32
+#define CFI_NUM_REGS 33
+
+#endif
diff --git a/tools/objtool/arch/powerpc/include/arch/elf.h 
b/tools/objtool/arch/powerpc/include/arch/elf.h
new file mode 100644
index ..3c8ebb7d2a6b
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/elf.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _OBJTOOL_ARCH_ELF
+#define _OBJTOOL_ARCH_ELF
+
+#define R_NONE R_PPC_NONE
+
+#endif /* _OBJTOOL_ARCH_ELF */
diff --git a/tools/objtool/arch/powerpc/include/arch/special.h 
b/tools/objtool/arch/powerpc/include/arch/special.h
new file mode 100644
index ..ffef9ada7133
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/special.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _PPC_ARCH_SPECIAL_H
+#define _PPC_ARCH_SPECIAL_H
+
+#define EX_ENTRY_SIZE 8
+#define EX_ORIG_OFFSET 0
+#define EX_NEW_OFFSET 4
+
+#define JUMP_ENTRY_SIZE 16
+#define JUMP_ORIG_OFFSET 0
+#define JUMP_NEW_OFFSET 4
+#define JUMP_KEY_OFFSE

[RFC PATCH v3 08/12] objtool: Add arch specific function arch_ftrace_match()

2022-06-24 Thread Sathvika Vasireddy
Add architecture specific function to look for
relocation records pointing to arch specific
symbols.

Suggested-by: Christophe Leroy 
Signed-off-by: Sathvika Vasireddy 
---
 tools/objtool/arch/x86/decode.c  | 8 
 tools/objtool/check.c| 2 +-
 tools/objtool/include/objtool/arch.h | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index 8b990a52aada..6a66b0c0dd2c 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -23,6 +23,14 @@
 #include 
 #include 
 
+bool arch_ftrace_match(char *name)
+{
+   if (!strcmp(func->name, "__fentry__"))
+   return true;
+
+   return false;
+}
+
 static int is_x86_64(const struct elf *elf)
 {
switch (elf->ehdr.e_machine) {
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 88f68269860e..51b6dcec8d6a 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2185,7 +2185,7 @@ static int classify_symbols(struct objtool_file *file)
if (arch_is_retpoline(func))
func->retpoline_thunk = true;
 
-   if (!strcmp(func->name, "__fentry__"))
+   if (arch_ftrace_match(func->name))
func->fentry = true;
 
if (is_profiling_func(func->name))
diff --git a/tools/objtool/include/objtool/arch.h 
b/tools/objtool/include/objtool/arch.h
index 9b19cc304195..99d0c8ba1b69 100644
--- a/tools/objtool/include/objtool/arch.h
+++ b/tools/objtool/include/objtool/arch.h
@@ -69,6 +69,8 @@ struct stack_op {
 
 struct instruction;
 
+bool arch_ftrace_match(char *name);
+
 void arch_initial_func_cfi_state(struct cfi_init_state *state);
 
 int arch_decode_instruction(struct objtool_file *file, const struct section 
*sec,
-- 
2.25.1



[RFC PATCH v3 07/12] objtool: Use macros to define arch specific reloc types

2022-06-24 Thread Sathvika Vasireddy
Make relocation types architecture specific.

Signed-off-by: Sathvika Vasireddy 
---
 tools/objtool/arch/x86/include/arch/elf.h | 2 ++
 tools/objtool/check.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/arch/x86/include/arch/elf.h 
b/tools/objtool/arch/x86/include/arch/elf.h
index 69cc4264b28a..ac14987cf687 100644
--- a/tools/objtool/arch/x86/include/arch/elf.h
+++ b/tools/objtool/arch/x86/include/arch/elf.h
@@ -2,5 +2,7 @@
 #define _OBJTOOL_ARCH_ELF
 
 #define R_NONE R_X86_64_NONE
+#define R_ABS64 R_X86_64_64
+#define R_ABS32 R_X86_64_32
 
 #endif /* _OBJTOOL_ARCH_ELF */
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 98e869721bc4..88f68269860e 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -834,7 +834,7 @@ static int create_mcount_loc_sections(struct objtool_file 
*file)
memset(loc, 0, size);
 
if (elf_add_reloc_to_insn(file->elf, sec, idx,
- R_X86_64_64,
+ size == sizeof(u64) ? R_ABS64 : 
R_ABS32,
  insn->sec, insn->offset))
return -1;
 
-- 
2.25.1



[RFC PATCH v3 06/12] objtool: Read special sections with alts only when specific options are selected

2022-06-24 Thread Sathvika Vasireddy
This patch reads special sections which have alternate
instructions, only when stackval or orc or uaccess or
noinstr options are passed to objtool.

Signed-off-by: Sathvika Vasireddy 
---
 tools/objtool/check.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 7f0dc504dd92..98e869721bc4 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2261,9 +2261,11 @@ static int decode_sections(struct objtool_file *file)
 * Must be before add_jump_destinations(), which depends on 'func'
 * being set for alternatives, to enable proper sibling call detection.
 */
-   ret = add_special_section_alts(file);
-   if (ret)
-   return ret;
+   if (opts.stackval || opts.orc || opts.uaccess || opts.noinstr) {
+   ret = add_special_section_alts(file);
+   if (ret)
+   return ret;
+   }
 
ret = add_jump_destinations(file);
if (ret)
-- 
2.25.1



[RFC PATCH v3 05/12] powerpc: Skip objtool from running on VDSO files

2022-06-24 Thread Sathvika Vasireddy
Do not run objtool on VDSO files, by using
OBJECT_FILES_NON_STANDARD

Suggested-by: Christophe Leroy 
Signed-off-by: Sathvika Vasireddy 
---
 arch/powerpc/kernel/vdso/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/vdso/Makefile 
b/arch/powerpc/kernel/vdso/Makefile
index 954974287ee7..853cda220467 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -101,3 +101,5 @@ quiet_cmd_vdso64ld_and_check = VDSO64L $@
   cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@ 
-Wl,-T$(filter %.lds,$^) $(filter %.o,$^) ; $(cmd_vdso_check)
 quiet_cmd_vdso64as = VDSO64A $@
   cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o $@ $<
+
+OBJECT_FILES_NON_STANDARD := y
-- 
2.25.1



[RFC PATCH v3 04/12] objtool: Add --mnop as an option to --mcount

2022-06-24 Thread Sathvika Vasireddy
Architectures can select HAVE_NOP_MCOUNT if they choose
to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to objtool,
along with --mcount.

Also, make sure that --mnop can be passed as an option
to objtool only when --mcount is passed.

Signed-off-by: Sathvika Vasireddy 
---
 Makefile|  4 +++-
 arch/x86/Kconfig|  1 +
 scripts/Makefile.build  |  1 +
 tools/objtool/builtin-check.c   | 14 ++
 tools/objtool/check.c   | 19 ++-
 tools/objtool/include/objtool/builtin.h |  1 +
 6 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index 250707647359..acaf88e3c694 100644
--- a/Makefile
+++ b/Makefile
@@ -851,7 +851,9 @@ ifdef CONFIG_FTRACE_MCOUNT_USE_CC
   endif
 endif
 ifdef CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
-  CC_FLAGS_USING   += -DCC_USING_NOP_MCOUNT
+  ifdef CONFIG_HAVE_NOP_MCOUNT
+CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT
+  endif
 endif
 ifdef CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT
   ifdef CONFIG_HAVE_C_RECORDMCOUNT
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1847d6e974a1..4a41bfb644f0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -189,6 +189,7 @@ config X86
select HAVE_CONTEXT_TRACKING_OFFSTACK   if HAVE_CONTEXT_TRACKING
select HAVE_C_RECORDMCOUNT
select HAVE_OBJTOOL_MCOUNT  if HAVE_OBJTOOL
+   select HAVE_NOP_MCOUNT  if HAVE_OBJTOOL_MCOUNT
select HAVE_BUILDTIME_MCOUNT_SORT
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index ac8167227bc0..2e0c3f9c1459 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -231,6 +231,7 @@ objtool_args =  
\
$(if $(CONFIG_HAVE_NOINSTR_HACK), --hacks=noinstr)  \
$(if $(CONFIG_X86_KERNEL_IBT), --ibt)   \
$(if $(CONFIG_FTRACE_MCOUNT_USE_OBJTOOL), --mcount) \
+   $(if $(CONFIG_HAVE_NOP_MCOUNT), --mnop) \
$(if $(CONFIG_UNWINDER_ORC), --orc) \
$(if $(CONFIG_RETPOLINE), --retpoline)  \
$(if $(CONFIG_SLS), --sls)  \
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index f4c3a5091737..b05e2108c0c3 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -80,6 +80,7 @@ const struct option check_options[] = {
OPT_BOOLEAN(0, "dry-run", &opts.dryrun, "don't write modifications"),
OPT_BOOLEAN(0, "link", &opts.link, "object is a linked object"),
OPT_BOOLEAN(0, "module", &opts.module, "object is part of a kernel 
module"),
+   OPT_BOOLEAN(0, "mnop", &opts.mnop, "nop out mcount call sites"),
OPT_BOOLEAN(0, "no-unreachable", &opts.no_unreachable, "skip 
'unreachable instruction' warnings"),
OPT_BOOLEAN(0, "sec-address", &opts.sec_address, "print section 
addresses in warnings"),
OPT_BOOLEAN(0, "stats", &opts.stats, "print statistics"),
@@ -142,6 +143,16 @@ static bool opts_valid(void)
return false;
 }
 
+static bool mnop_opts_valid(void)
+{
+   if (opts.mnop && !opts.mcount) {
+   ERROR("--mnop requires --mcount");
+   return false;
+   }
+
+   return true;
+}
+
 static bool link_opts_valid(struct objtool_file *file)
 {
if (opts.link)
@@ -185,6 +196,9 @@ int objtool_run(int argc, const char **argv)
if (!file)
return 1;
 
+   if (!mnop_opts_valid())
+   return 1;
+
if (!link_opts_valid(file))
return 1;
 
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index fabc0ea88747..7f0dc504dd92 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1177,17 +1177,18 @@ static void annotate_call_site(struct objtool_file 
*file,
if (opts.mcount && sym->fentry) {
if (sibling)
WARN_FUNC("Tail call to __fentry__ !?!?", insn->sec, 
insn->offset);
+   if (opts.mnop) {
+   if (reloc) {
+   reloc->type = R_NONE;
+   elf_write_reloc(file->elf, reloc);
+   }
 
-   if (reloc) {
-   reloc->type = R_NONE;
-   elf_write_reloc(file->elf, reloc);
-   }
-
-   elf_write_insn(file->elf, insn->sec,
-  insn->offset, insn->len,
-  arch_nop_insn(insn->len));
+   elf_write_insn(file->elf, insn->sec,
+  insn->offset, insn->len,
+  arch_nop_insn(insn->len));
 
- 

[RFC PATCH v3 03/12] objtool: Use target file class size instead of a compiled constant

2022-06-24 Thread Sathvika Vasireddy
From: Christophe Leroy 

In order to allow using objtool on cross-built kernels,
determine size of long from elf data instead of using
sizeof(long) at build time.

For the time being this covers only mcount.

Signed-off-by: Christophe Leroy 
---
 tools/objtool/check.c   | 16 +---
 tools/objtool/elf.c |  8 ++--
 tools/objtool/include/objtool/elf.h |  8 
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index cef1dd54d505..fabc0ea88747 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -802,9 +802,9 @@ static int create_ibt_endbr_seal_sections(struct 
objtool_file *file)
 static int create_mcount_loc_sections(struct objtool_file *file)
 {
struct section *sec;
-   unsigned long *loc;
struct instruction *insn;
int idx;
+   int size = elf_class_size(file->elf);
 
sec = find_section_by_name(file->elf, "__mcount_loc");
if (sec) {
@@ -820,23 +820,25 @@ static int create_mcount_loc_sections(struct objtool_file 
*file)
list_for_each_entry(insn, &file->mcount_loc_list, call_node)
idx++;
 
-   sec = elf_create_section(file->elf, "__mcount_loc", 0, sizeof(unsigned 
long), idx);
+   sec = elf_create_section(file->elf, "__mcount_loc", 0, size, idx);
if (!sec)
return -1;
 
+   sec->sh.sh_addralign = size;
+
idx = 0;
list_for_each_entry(insn, &file->mcount_loc_list, call_node) {
+   void *loc;
 
-   loc = (unsigned long *)sec->data->d_buf + idx;
-   memset(loc, 0, sizeof(unsigned long));
+   loc = sec->data->d_buf + idx;
+   memset(loc, 0, size);
 
-   if (elf_add_reloc_to_insn(file->elf, sec,
- idx * sizeof(unsigned long),
+   if (elf_add_reloc_to_insn(file->elf, sec, idx,
  R_X86_64_64,
  insn->sec, insn->offset))
return -1;
 
-   idx++;
+   idx += size;
}
 
return 0;
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index c25e957c1e52..63218f5799c2 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -1124,6 +1124,7 @@ static struct section 
*elf_create_rela_reloc_section(struct elf *elf, struct sec
 {
char *relocname;
struct section *sec;
+   int size = elf_class_size(elf);
 
relocname = malloc(strlen(base->name) + strlen(".rela") + 1);
if (!relocname) {
@@ -1133,7 +1134,10 @@ static struct section 
*elf_create_rela_reloc_section(struct elf *elf, struct sec
strcpy(relocname, ".rela");
strcat(relocname, base->name);
 
-   sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rela), 0);
+   if (size == sizeof(u32))
+   sec = elf_create_section(elf, relocname, 0, sizeof(Elf32_Rela), 
0);
+   else
+   sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rela), 
0);
free(relocname);
if (!sec)
return NULL;
@@ -1142,7 +1146,7 @@ static struct section 
*elf_create_rela_reloc_section(struct elf *elf, struct sec
sec->base = base;
 
sec->sh.sh_type = SHT_RELA;
-   sec->sh.sh_addralign = 8;
+   sec->sh.sh_addralign = size;
sec->sh.sh_link = find_section_by_name(elf, ".symtab")->idx;
sec->sh.sh_info = base->idx;
sec->sh.sh_flags = SHF_INFO_LINK;
diff --git a/tools/objtool/include/objtool/elf.h 
b/tools/objtool/include/objtool/elf.h
index adebfbc2b518..c720c4476828 100644
--- a/tools/objtool/include/objtool/elf.h
+++ b/tools/objtool/include/objtool/elf.h
@@ -141,6 +141,14 @@ static inline bool has_multiple_files(struct elf *elf)
return elf->num_files > 1;
 }
 
+static inline int elf_class_size(struct elf *elf)
+{
+   if (elf->ehdr.e_ident[EI_CLASS] == ELFCLASS32)
+   return sizeof(u32);
+   else
+   return sizeof(u64);
+}
+
 struct elf *elf_open_read(const char *name, int flags);
 struct section *elf_create_section(struct elf *elf, const char *name, unsigned 
int sh_flags, size_t entsize, int nr);
 
-- 
2.25.1



[RFC PATCH v3 02/12] objtool: Use target file endianness instead of a compiled constant

2022-06-24 Thread Sathvika Vasireddy
From: Christophe Leroy 

Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.

Use the endianness recorded in the file objtool is working on.

Signed-off-by: Christophe Leroy 
---
 .../arch/x86/include/arch/endianness.h|  9 --
 tools/objtool/check.c |  2 +-
 tools/objtool/include/objtool/endianness.h| 32 +--
 tools/objtool/orc_dump.c  | 11 +--
 tools/objtool/orc_gen.c   |  4 +--
 tools/objtool/special.c   |  3 +-
 6 files changed, 30 insertions(+), 31 deletions(-)
 delete mode 100644 tools/objtool/arch/x86/include/arch/endianness.h

diff --git a/tools/objtool/arch/x86/include/arch/endianness.h 
b/tools/objtool/arch/x86/include/arch/endianness.h
deleted file mode 100644
index 7c362527da20..
--- a/tools/objtool/arch/x86/include/arch/endianness.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-#ifndef _ARCH_ENDIANNESS_H
-#define _ARCH_ENDIANNESS_H
-
-#include 
-
-#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN
-
-#endif /* _ARCH_ENDIANNESS_H */
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 6cb07e151588..cef1dd54d505 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1971,7 +1971,7 @@ static int read_unwind_hints(struct objtool_file *file)
return -1;
}
 
-   cfi.cfa.offset = bswap_if_needed(hint->sp_offset);
+   cfi.cfa.offset = bswap_if_needed(file->elf, hint->sp_offset);
cfi.type = hint->type;
cfi.end = hint->end;
 
diff --git a/tools/objtool/include/objtool/endianness.h 
b/tools/objtool/include/objtool/endianness.h
index 10241341eff3..4d2aa9b0fe2f 100644
--- a/tools/objtool/include/objtool/endianness.h
+++ b/tools/objtool/include/objtool/endianness.h
@@ -2,33 +2,33 @@
 #ifndef _OBJTOOL_ENDIANNESS_H
 #define _OBJTOOL_ENDIANNESS_H
 
-#include 
 #include 
 #include 
-
-#ifndef __TARGET_BYTE_ORDER
-#error undefined arch __TARGET_BYTE_ORDER
-#endif
-
-#if __BYTE_ORDER != __TARGET_BYTE_ORDER
-#define __NEED_BSWAP 1
-#else
-#define __NEED_BSWAP 0
-#endif
+#include 
 
 /*
- * Does a byte swap if target endianness doesn't match the host, i.e. cross
+ * Does a byte swap if target file endianness doesn't match the host, i.e. 
cross
  * compilation for little endian on big endian and vice versa.
  * To be used for multi-byte values conversion, which are read from / about
  * to be written to a target native endianness ELF file.
  */
-#define bswap_if_needed(val)   \
+static inline bool need_bswap(struct elf *elf)
+{
+   return (__BYTE_ORDER == __LITTLE_ENDIAN) ^
+  (elf->ehdr.e_ident[EI_DATA] == ELFDATA2LSB);
+}
+
+#define bswap_if_needed(elf, val)  \
 ({ \
__typeof__(val) __ret;  \
+   bool __need_bswap = need_bswap(elf);\
switch (sizeof(val)) {  \
-   case 8: __ret = __NEED_BSWAP ? bswap_64(val) : (val); break;\
-   case 4: __ret = __NEED_BSWAP ? bswap_32(val) : (val); break;\
-   case 2: __ret = __NEED_BSWAP ? bswap_16(val) : (val); break;\
+   case 8: \
+   __ret = __need_bswap ? bswap_64(val) : (val); break;\
+   case 4: \
+   __ret = __need_bswap ? bswap_32(val) : (val); break;\
+   case 2: \
+   __ret = __need_bswap ? bswap_16(val) : (val); break;\
default:\
BUILD_BUG(); break; \
}   \
diff --git a/tools/objtool/orc_dump.c b/tools/objtool/orc_dump.c
index f5a8508c42d6..4f1211fec82c 100644
--- a/tools/objtool/orc_dump.c
+++ b/tools/objtool/orc_dump.c
@@ -76,6 +76,7 @@ int orc_dump(const char *_objname)
GElf_Rela rela;
GElf_Sym sym;
Elf_Data *data, *symtab = NULL, *rela_orc_ip = NULL;
+   struct elf dummy_elf = {};
 
 
objname = _objname;
@@ -94,6 +95,12 @@ int orc_dump(const char *_objname)
return -1;
}
 
+   if (!elf64_getehdr(elf)) {
+   WARN_ELF("elf64_getehdr");
+   return -1;
+   }
+   memcpy(&dummy_elf.ehdr, elf64_getehdr(elf), sizeof(dummy_elf.ehdr));
+
if (elf_getshdrnum(elf, &nr_sections)) {
WARN_ELF("elf_getshdrnum");
return -1;

[RFC PATCH v3 01/12] objtool: Fix SEGFAULT

2022-06-24 Thread Sathvika Vasireddy
From: Christophe Leroy 

Signed-off-by: Christophe Leroy 
---
 tools/objtool/check.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 190b2f6e360a..6cb07e151588 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -203,7 +203,7 @@ static bool __dead_end_function(struct objtool_file *file, 
struct symbol *func,
return false;
 
insn = find_insn(file, func->sec, func->offset);
-   if (!insn->func)
+   if (!insn || !insn->func)
return false;
 
func_for_each_insn(file, func, insn) {
-- 
2.25.1



[RFC PATCH v3 00/12] objtool: Enable and implement --mcount option on powerpc

2022-06-24 Thread Sathvika Vasireddy
These patches are rebased on top of objtool/core
branch of the tip tree, and are tested on
ppc64le with ppc64le_defconfig.

Christophe Leroy (3):
  objtool: Fix SEGFAULT
  objtool: Use target file endianness instead of a compiled constant
  objtool: Use target file class size instead of a compiled constant

Sathvika Vasireddy(9):
  objtool: Add --mnop as an option to --mcount
  powerpc: Skip objtool from running on VDSO files
  objtool: Read special sections with alts only when specific options are 
selected
  objtool: Use macros to define arch specific reloc types
  objtool: Add arch specific function arch_ftrace_match()
  objtool/powerpc: Enable objtool to be built on ppc
  objtool/powerpc: Add --mcount specific implementation
  powerpc: Remove unreachable() from WARN_ON()
  objtool/powerpc: Fix unannotated intra-function call warnings

 Makefile  |  4 +-
 arch/powerpc/Kconfig  |  2 +
 arch/powerpc/include/asm/bug.h|  1 -
 arch/powerpc/kernel/entry_64.S|  2 +
 arch/powerpc/kernel/exceptions-64s.S  |  7 +-
 arch/powerpc/kernel/head_64.S |  7 +-
 arch/powerpc/kernel/misc_64.S |  4 +-
 arch/powerpc/kernel/vdso/Makefile |  2 +
 arch/powerpc/kernel/vector.S  |  4 +-
 arch/powerpc/kvm/book3s_hv_interrupts.S   |  4 +-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S   | 25 +++--
 arch/x86/Kconfig  |  1 +
 scripts/Makefile.build|  1 +
 tools/objtool/arch/powerpc/Build  |  2 +
 tools/objtool/arch/powerpc/decode.c   | 96 +++
 .../arch/powerpc/include/arch/cfi_regs.h  | 11 +++
 tools/objtool/arch/powerpc/include/arch/elf.h | 10 ++
 .../arch/powerpc/include/arch/special.h   | 21 
 tools/objtool/arch/powerpc/special.c  | 19 
 tools/objtool/arch/x86/decode.c   |  8 ++
 tools/objtool/arch/x86/include/arch/elf.h |  2 +
 .../arch/x86/include/arch/endianness.h|  9 --
 tools/objtool/builtin-check.c | 14 +++
 tools/objtool/check.c | 51 +-
 tools/objtool/elf.c   |  8 +-
 tools/objtool/include/objtool/arch.h  |  2 +
 tools/objtool/include/objtool/builtin.h   |  1 +
 tools/objtool/include/objtool/elf.h   |  8 ++
 tools/objtool/include/objtool/endianness.h| 32 +++
 tools/objtool/orc_dump.c  | 11 ++-
 tools/objtool/orc_gen.c   |  4 +-
 tools/objtool/special.c   |  3 +-
 32 files changed, 305 insertions(+), 71 deletions(-)
 create mode 100644 tools/objtool/arch/powerpc/Build
 create mode 100644 tools/objtool/arch/powerpc/decode.c
 create mode 100644 tools/objtool/arch/powerpc/include/arch/cfi_regs.h
 create mode 100644 tools/objtool/arch/powerpc/include/arch/elf.h
 create mode 100644 tools/objtool/arch/powerpc/include/arch/special.h
 create mode 100644 tools/objtool/arch/powerpc/special.c
 delete mode 100644 tools/objtool/arch/x86/include/arch/endianness.h

-- 
2.25.1



Re: (subset) [PATCH RESEND v9 2/5] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name

2022-06-24 Thread Krzysztof Kozlowski
On Fri, 24 Jun 2022 17:16:18 +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> nodes are correctly named.
> 
> 
> [...]

Applied, thanks!

[2/5] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
  
https://git.kernel.org/krzk/linux/c/986fd5fe55cb369c34a1dc65b1469aac536a6d50

Best regards,
-- 
Krzysztof Kozlowski 


Re: [PATCH RESEND v9 4/5] arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name

2022-06-24 Thread Krzysztof Kozlowski
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named.
> 
> Signed-off-by: Serge Semin 
> Acked-by: Krzysztof Kozlowski 
> Reviewed-by: Patrice Chotard 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index 1713f7878117..7ba528315dbe 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -725,7 +725,7 @@ st_dwc3: dwc3@8f94000 {
>  
>   status = "disabled";
>  
> - dwc3: dwc3@990 {
> + dwc3: usb@990 {

This does not apply. What tree is it based on?


Best regards,
Krzysztof


Re: [PATCH RESEND v9 5/5] arm64: dts: apm: Harmonize DWC USB3 DT nodes name

2022-06-24 Thread Krzysztof Kozlowski
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named despite of the warning comment about possible backward
> compatibility issues.

Sometimes node name is exposed to user-space which depends on it. How
did you check there is no issue here?

> 
> Signed-off-by: Serge Semin 
> Acked-by: Krzysztof Kozlowski 
> ---
>  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
>  arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
> b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> index a83c82c50e29..832dd85b00bd 100644
> --- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
> @@ -597,8 +597,8 @@ serial0: serial@1060 {
>   interrupts = <0x0 0x4c 0x4>;
>   };
>  
> - /* Do not change dwusb name, coded for backward compatibility */
> - usb0: dwusb@1900 {
> + /* Node-name might need to be coded as dwusb for backward 
> compatibility */
> + usb0: usb@1900 {
>   status = "disabled";
>   compatible = "snps,dwc3";
>   reg =  <0x0 0x1900 0x0 0x10>;
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index 0f37e77f5459..1520a945b7f9 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -923,8 +923,8 @@ sata3: sata@1a80 {
>   phy-names = "sata-phy";
>   };
>  
> - /* Do not change dwusb name, coded for backward compatibility */
> - usb0: dwusb@1900 {
> + /* Node-name might need to be coded as dwusb for backward 
> compatibility */
> + usb0: usb@1900 {
>   status = "disabled";
>   compatible = "snps,dwc3";
>   reg =  <0x0 0x1900 0x0 0x10>;
> @@ -933,7 +933,7 @@ usb0: dwusb@1900 {
>   dr_mode = "host";
>   };
>  
> - usb1: dwusb@1980 {
> + usb1: usb@1980 {
>   status = "disabled";
>   compatible = "snps,dwc3";
>   reg =  <0x0 0x1980 0x0 0x10>;


Best regards,
Krzysztof


Re: [PATCH RESEND v9 2/5] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name

2022-06-24 Thread Krzysztof Kozlowski
On 24/06/2022 16:16, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> nodes are correctly named.
> 
> Signed-off-by: Serge Semin 
> Acked-by: Vladimir Zapolskiy 
> Acked-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--

You should split the patchset per architecture, because maybe that's why
no one picks it up?

Let me pick up ARM bits through my cleanup series. If anyone objects,
please let me know.

Best regards,
Krzysztof


Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
On Fri, Jun 24, 2022 at 5:52 PM Arnd Bergmann  wrote:

> Arnd Bergmann (3):
>   scsi: BusLogic remove bus_to_virt
>   scsi: dpt_i2o: remove obsolete driver

The dpt_i2o removal is overly large and got dropped by some of the
mailing lists,
if anyone wants to see the full patch, it did make it through to the linux-scsi
list at least:

https://lore.kernel.org/all/20220624155226.2889613-3-a...@kernel.org/

 Arnd


Re: [PATCH v3 1/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Khalid Aziz

On 6/24/22 09:52, Arnd Bergmann wrote:

From: Arnd Bergmann 

The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.

Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit."),
the driver had a dependency on x86-32, presumably because of this
problem. However, the change introduced another bug that made it still
impossible to use the driver on any 64-bit machine.

This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
64-bit system enumeration error for Buslogic"), 8 years later, which
shows that there are not a lot of users.

Maciej is still using the driver on 32-bit hardware, and Khalid mentioned
that the driver works with the device emulation used in VirtualBox
and VMware. Both of those only emulate it for Windows 2000 and older
operating systems that did not ship with the better LSI logic driver.

Do a minimum fix that searches through the list of descriptors to find
one that matches the bus address. This is clearly as inefficient as
was indicated in the code comment about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.

Cc: Maciej W. Rozycki 
Cc: Matt Wang 
Tested-by: Khalid Aziz 
Reviewed-by: Robin Murphy 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Arnd Bergmann 
---
v3: Address issues pointed out by Khalid Aziz
v2: Attempt to fix the driver instead of removing it
---
  drivers/scsi/BusLogic.c | 35 +++
  drivers/scsi/Kconfig|  2 +-
  2 files changed, 24 insertions(+), 13 deletions(-)



This looks good.

Acked-by: Khalid Aziz 



diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index a897c8f914cf..f2abffce2659 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2515,12 +2515,26 @@ static int blogic_resultcode(struct blogic_adapter 
*adapter,
return (hoststatus << 16) | tgt_status;
  }
  
+/*

+ * turn the dma address from an inbox into a ccb pointer
+ * This is rather inefficient.
+ */
+static struct blogic_ccb *
+blogic_inbox_to_ccb(struct blogic_adapter *adapter, struct blogic_inbox *inbox)
+{
+   struct blogic_ccb *ccb;
+
+   for (ccb = adapter->all_ccbs; ccb; ccb = ccb->next_all)
+   if (inbox->ccb == ccb->dma_handle)
+   break;
+
+   return ccb;
+}
  
  /*

blogic_scan_inbox scans the Incoming Mailboxes saving any
Incoming Mailbox entries for completion processing.
  */
-
  static void blogic_scan_inbox(struct blogic_adapter *adapter)
  {
/*
@@ -2540,17 +2554,14 @@ static void blogic_scan_inbox(struct blogic_adapter 
*adapter)
enum blogic_cmplt_code comp_code;
  
  	while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {

-   /*
-  We are only allowed to do this because we limit our
-  architectures we run on to machines where bus_to_virt(
-  actually works.  There *needs* to be a dma_addr_to_virt()
-  in the new PCI DMA mapping interface to replace
-  bus_to_virt() or else this code is going to become very
-  innefficient.
-*/
-   struct blogic_ccb *ccb =
-   (struct blogic_ccb *) bus_to_virt(next_inbox->ccb);
-   if (comp_code != BLOGIC_CMD_NOTFOUND) {
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, 
next_inbox);
+   if (!ccb) {
+   /*
+* This should never happen, unless the CCB list is
+* corrupted in memory.
+*/
+   blogic_warn("Could not find CCB for dma address %x\n", 
adapter, next_inbox->ccb);
+   } else if (comp_code != BLOGIC_CMD_NOTFOUND) {
if (ccb->status == BLOGIC_CCB_ACTIVE ||
ccb->status == BLOGIC_CCB_RESET) {
/*
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..689186f3a908 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -514,7 +514,7 @@ config SCSI_HPTIOP
  
  config SCSI_BUSLOGIC

tristate "BusLogic SCSI support"
-   depends on PCI && SCSI && VIRT_TO_BUS
+   depends on PCI && SCSI
help
  This is support for BusLogic MultiMaster and FlashPoint SCSI Host
  Adapters. Consult the SCSI-HOWTO, available from




[PATCH v3 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann 

All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now.  This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.

The only exceptions to this are a few network and scsi drivers for m68k
Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
with the old interfaces and are probably not worth changing.

On alpha and parisc, virt_to_bus() were still used in asm/floppy.h.
alpha can use isa_virt_to_bus() like x86 does, and parisc can just
open-code the virt_to_phys() here, as this is architecture specific
code.

I tried updating the bus-virt-phys-mapping.rst documentation, which
started as an email from Linus to explain some details of the Linux-2.0
driver interfaces. The bits about virt_to_bus() were declared obsolete
backin 2000, and the rest is not all that relevant any more, so in the
end I just decided to remove the file completely.

Reviewed-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Acked-by: Michael Ellerman  (powerpc)
Signed-off-by: Arnd Bergmann 
---
 .../core-api/bus-virt-phys-mapping.rst| 220 --
 Documentation/core-api/dma-api-howto.rst  |  14 --
 Documentation/core-api/index.rst  |   1 -
 .../translations/zh_CN/core-api/index.rst |   1 -
 arch/alpha/Kconfig|   1 -
 arch/alpha/include/asm/floppy.h   |   2 +-
 arch/alpha/include/asm/io.h   |   8 +-
 arch/ia64/Kconfig |   1 -
 arch/ia64/include/asm/io.h|   8 -
 arch/m68k/Kconfig |   1 -
 arch/m68k/include/asm/virtconvert.h   |   4 +-
 arch/microblaze/Kconfig   |   1 -
 arch/microblaze/include/asm/io.h  |   2 -
 arch/mips/Kconfig |   1 -
 arch/mips/include/asm/io.h|   9 -
 arch/parisc/Kconfig   |   1 -
 arch/parisc/include/asm/floppy.h  |   4 +-
 arch/parisc/include/asm/io.h  |   2 -
 arch/powerpc/Kconfig  |   1 -
 arch/powerpc/include/asm/io.h |   2 -
 arch/riscv/include/asm/page.h |   1 -
 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/io.h |   9 -
 arch/xtensa/Kconfig   |   1 -
 arch/xtensa/include/asm/io.h  |   3 -
 include/asm-generic/io.h  |  14 --
 mm/Kconfig|   8 -
 27 files changed, 10 insertions(+), 311 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst

diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst 
b/Documentation/core-api/bus-virt-phys-mapping.rst
deleted file mode 100644
index c72b24a7d52c..
--- a/Documentation/core-api/bus-virt-phys-mapping.rst
+++ /dev/null
@@ -1,220 +0,0 @@
-==
-How to access I/O mapped memory from within device drivers
-==
-
-:Author: Linus
-
-.. warning::
-
-   The virt_to_bus() and bus_to_virt() functions have been
-   superseded by the functionality provided by the PCI DMA interface
-   (see Documentation/core-api/dma-api-howto.rst).  They continue
-   to be documented below for historical purposes, but new code
-   must not use them. --davidm 00/12/12
-
-::
-
-  [ This is a mail message in response to a query on IO mapping, thus the
-strange format for a "document" ]
-
-The AHA-1542 is a bus-master device, and your patch makes the driver give the
-controller the physical address of the buffers, which is correct on x86
-(because all bus master devices see the physical memory mappings directly). 
-
-However, on many setups, there are actually **three** different ways of looking
-at memory addresses, and in this case we actually want the third, the
-so-called "bus address". 
-
-Essentially, the three ways of addressing memory are (this is "real memory",
-that is, normal RAM--see later about other details): 
-
- - CPU untranslated.  This is the "physical" address.  Physical address 
-   0 is what the CPU sees when it drives zeroes on the memory bus.
-
- - CPU translated address. This is the "virtual" address, and is 
-   completely internal to the CPU itself with the CPU doing the appropriate
-   translations into "CPU untranslated". 
-
- - bus address. This is the address of memory as seen by OTHER devices, 
-   not the CPU. Now, in theory there could be many different bus 
-   addresses, with each device seeing memory in some device-specific way, but
-   happily most hardware designers aren't actually actively trying to make
-   things any more complex than necessary, so you can assume that all 
-   external hardwar

[PATCH v3 1/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann 

The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.

Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit."),
the driver had a dependency on x86-32, presumably because of this
problem. However, the change introduced another bug that made it still
impossible to use the driver on any 64-bit machine.

This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
64-bit system enumeration error for Buslogic"), 8 years later, which
shows that there are not a lot of users.

Maciej is still using the driver on 32-bit hardware, and Khalid mentioned
that the driver works with the device emulation used in VirtualBox
and VMware. Both of those only emulate it for Windows 2000 and older
operating systems that did not ship with the better LSI logic driver.

Do a minimum fix that searches through the list of descriptors to find
one that matches the bus address. This is clearly as inefficient as
was indicated in the code comment about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.

Cc: Maciej W. Rozycki 
Cc: Matt Wang 
Tested-by: Khalid Aziz 
Reviewed-by: Robin Murphy 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Arnd Bergmann 
---
v3: Address issues pointed out by Khalid Aziz
v2: Attempt to fix the driver instead of removing it
---
 drivers/scsi/BusLogic.c | 35 +++
 drivers/scsi/Kconfig|  2 +-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index a897c8f914cf..f2abffce2659 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2515,12 +2515,26 @@ static int blogic_resultcode(struct blogic_adapter 
*adapter,
return (hoststatus << 16) | tgt_status;
 }
 
+/*
+ * turn the dma address from an inbox into a ccb pointer
+ * This is rather inefficient.
+ */
+static struct blogic_ccb *
+blogic_inbox_to_ccb(struct blogic_adapter *adapter, struct blogic_inbox *inbox)
+{
+   struct blogic_ccb *ccb;
+
+   for (ccb = adapter->all_ccbs; ccb; ccb = ccb->next_all)
+   if (inbox->ccb == ccb->dma_handle)
+   break;
+
+   return ccb;
+}
 
 /*
   blogic_scan_inbox scans the Incoming Mailboxes saving any
   Incoming Mailbox entries for completion processing.
 */
-
 static void blogic_scan_inbox(struct blogic_adapter *adapter)
 {
/*
@@ -2540,17 +2554,14 @@ static void blogic_scan_inbox(struct blogic_adapter 
*adapter)
enum blogic_cmplt_code comp_code;
 
while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {
-   /*
-  We are only allowed to do this because we limit our
-  architectures we run on to machines where bus_to_virt(
-  actually works.  There *needs* to be a dma_addr_to_virt()
-  in the new PCI DMA mapping interface to replace
-  bus_to_virt() or else this code is going to become very
-  innefficient.
-*/
-   struct blogic_ccb *ccb =
-   (struct blogic_ccb *) bus_to_virt(next_inbox->ccb);
-   if (comp_code != BLOGIC_CMD_NOTFOUND) {
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, 
next_inbox);
+   if (!ccb) {
+   /*
+* This should never happen, unless the CCB list is
+* corrupted in memory.
+*/
+   blogic_warn("Could not find CCB for dma address %x\n", 
adapter, next_inbox->ccb);
+   } else if (comp_code != BLOGIC_CMD_NOTFOUND) {
if (ccb->status == BLOGIC_CCB_ACTIVE ||
ccb->status == BLOGIC_CCB_RESET) {
/*
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..689186f3a908 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -514,7 +514,7 @@ config SCSI_HPTIOP
 
 config SCSI_BUSLOGIC
tristate "BusLogic SCSI support"
-   depends on PCI && SCSI && VIRT_TO_BUS
+   depends on PCI && SCSI
help
  This is support for BusLogic MultiMaster and FlashPoint SCSI Host
  Adapters. Consult the SCSI-HOWTO, available from
-- 
2.29.2



[PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann 

The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old interface for good.

Any out of tree drivers using virt_to_bus() should be converted to
using the dma-mapping interfaces, typically dma_alloc_coherent()
or dma_map_single()).

There are a few m68k and ppc32 specific drivers that keep using the
interfaces, but these are all guarded with architecture-specific
Kconfig dependencies, and are not actually broken. It might be
helpful as a follow-up to replace them with platform specific
helpers for amiga, m68k-vme and powermac.

There are still a number of drivers that are using virt_to_phys()
and phys_to_virt() in place of dma-mapping operations, and these
are often broken, but they are out of scope for this series.

If there are no more issues identified with this series, I'll
merge it through the asm-generic tree. The SCSI patches can
also get merged separately through the SCSI maintainers' tree
if they prefer.

  Arnd

---
Changes since v2:
 - Drop the dpt_i2o driver completely rather than fixing it
 - fix mistake in BusLogic patch

Changes since v1:
 - dropped VME patches that are already in staging-next
 - dropped media patch that gets merged independently
 - added a networking patch and dropped it again after it got merged
 - replace BusLogic removal with a workaround

Cc: Jakub Kicinski 
Cc: Christoph Hellwig  # dma-mapping
Cc: Marek Szyprowski  # dma-mapping
Cc: Robin Murphy  # dma-mapping
Cc: io...@lists.linux-foundation.org
Cc: Khalid Aziz  # buslogic
Cc: Maciej W. Rozycki  # buslogic
Cc: Matt Wang  # buslogic
Cc: Miquel van Smoorenburg  # dpt_i2o
Cc: Mark Salyzyn  # dpt_i2o
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-par...@vger.kernel.org
Cc: Denis Efremov  # floppy

Arnd Bergmann (3):
  scsi: BusLogic remove bus_to_virt
  scsi: dpt_i2o: remove obsolete driver
  arch/*/: remove CONFIG_VIRT_TO_BUS

 .../core-api/bus-virt-phys-mapping.rst|  220 -
 Documentation/core-api/dma-api-howto.rst  |   14 -
 Documentation/core-api/index.rst  |1 -
 .../translations/zh_CN/core-api/index.rst |1 -
 .../userspace-api/ioctl/ioctl-number.rst  |2 +-
 MAINTAINERS   |8 -
 arch/alpha/Kconfig|1 -
 arch/alpha/include/asm/floppy.h   |2 +-
 arch/alpha/include/asm/io.h   |8 +-
 arch/ia64/Kconfig |1 -
 arch/ia64/include/asm/io.h|8 -
 arch/m68k/Kconfig |1 -
 arch/m68k/include/asm/virtconvert.h   |4 +-
 arch/microblaze/Kconfig   |1 -
 arch/microblaze/include/asm/io.h  |2 -
 arch/mips/Kconfig |1 -
 arch/mips/include/asm/io.h|9 -
 arch/parisc/Kconfig   |1 -
 arch/parisc/include/asm/floppy.h  |4 +-
 arch/parisc/include/asm/io.h  |2 -
 arch/powerpc/Kconfig  |1 -
 arch/powerpc/include/asm/io.h |2 -
 arch/riscv/include/asm/page.h |1 -
 arch/x86/Kconfig  |1 -
 arch/x86/include/asm/io.h |9 -
 arch/xtensa/Kconfig   |1 -
 arch/xtensa/include/asm/io.h  |3 -
 drivers/scsi/BusLogic.c   |   35 +-
 drivers/scsi/Kconfig  |   13 +-
 drivers/scsi/Makefile |1 -
 drivers/scsi/dpt/dpti_i2o.h   |  441 --
 drivers/scsi/dpt/dpti_ioctl.h |  136 -
 drivers/scsi/dpt/dptsig.h |  336 --
 drivers/scsi/dpt/osd_defs.h   |   79 -
 drivers/scsi/dpt/osd_util.h   |  358 --
 drivers/scsi/dpt/sys_info.h   |  417 --
 drivers/scsi/dpt_i2o.c| 3546 -
 drivers/scsi/dpti.h   |  331 --
 include/asm-generic/io.h  |   14 -
 mm/Kconfig|8 -
 40 files changed, 35 insertions(+), 5989 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst
 delete mode 100644 drivers/scsi/dpt/dpti_i2o.h
 delete mode 100644 drivers/scsi/dpt/dpti_ioctl.h
 delete mode 100644 drivers/scsi/dpt/dptsig.h
 delete mode 100644 drivers/scsi/dpt/osd_defs.h
 delete mode 100644 drivers/scsi/dpt/osd_util.h
 delete mode 100644 drivers/scsi/dpt/sys_info.h
 delete mode 100644 drivers/scsi/dpt_i2o.c
 delete mode 100644 drivers/scsi/dpti.h

-- 
2.29.2



Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
On Fri, Jun 24, 2022 at 5:38 PM Khalid Aziz  wrote:
> On 6/23/22 08:47, Arnd Bergmann wrote:
>
> Driver works with this change. next_inbox is the correct pointer to pass.

Ok, great! I'll add a 'Tested-by' line then. I was already in the process of
preparing a v3 patch set, will send out the fixed patch in a bit.

 Arnd


Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Khalid Aziz

On 6/23/22 08:47, Arnd Bergmann wrote:



Can you test it again with this patch on top?

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index d057abfcdd5c..9e67f2ee25ee 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2554,8 +2554,14 @@ static void blogic_scan_inbox(struct
blogic_adapter *adapter)
 enum blogic_cmplt_code comp_code;

 while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {
-   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter,
adapter->next_inbox);
-   if (comp_code != BLOGIC_CMD_NOTFOUND) {
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter,
next_inbox);
+   if (!ccb) {
+   /*
+* This should never happen, unless the CCB list is
+* corrupted in memory.
+*/
+   blogic_warn("Could not find CCB for dma
address 0x%x\n", adapter, next_inbox->ccb);
+   } else if (comp_code != BLOGIC_CMD_NOTFOUND) {
 if (ccb->status == BLOGIC_CCB_ACTIVE ||
 ccb->status == BLOGIC_CCB_RESET) {


Hi Arnd,

Driver works with this change. next_inbox is the correct pointer to pass.

Thanks,
Khalid


Re: [PATCH v2 4/4] watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers

2022-06-24 Thread Segher Boessenkool
On Fri, Jun 24, 2022 at 11:27:24PM +1000, Michael Ellerman wrote:
> Scott Cheloha  writes:
> > + * - For the "Query Watchdog Capabilities" operation, a 64-bit
> > + *   value structured as follows:
> > + *
> > + *   Bits  0-15: The minimum supported timeout in milliseconds.
> > + *   Bits 16-31: The number of watchdogs supported.
> > + *   Bits 32-63: Reserved.
> > + */
> > +#define PSERIES_WDTQ_MIN_TIMEOUT(cap)  GETFIELD((cap), 0, 15)
> 
> This one is less obviously better, but I still think it's clearer as all
> the logic is there in front of you, rather than hidden in the macro. It
> is clearer that we're only returning a 16-bit value.
> 
> #define PSERIES_WDTQ_MIN_TIMEOUT(cap) (((cap) >> 48) & 0x)

Or even
  ((cap) >> 48)
since it is a 64-bit value.  If you want better defences you should not
use macros here at all, anyway (but inline functions, instead).

I could rant about the 1000UL being meaningless and/or misleading, or
that 0x1 is just silly, but it is a sunny day :-)


Segher


Re: [PATCH v2 2/2] powerpc/kvm: don't crash on missing rng, and use darn

2022-06-24 Thread Fabiano Rosas
"Jason A. Donenfeld"  writes:

> On POWER8 systems that don't have ibm,power-rng available, a guest that
> ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> dereference a NULL pointer. And on machines with darn instead of
> ibm,power-rng, H_RANDOM won't work at all.
>
> This patch kills two birds with one stone, by routing H_RANDOM calls to
> ppc_md.get_random_seed, and doing the real mode check inside of it.
>
> Cc: sta...@vger.kernel.org # v4.1+
> Cc: Michael Ellerman 
> Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM 
> implementation.")
> Signed-off-by: Jason A. Donenfeld 

Reviewed-by: Fabiano Rosas 



Re: [PATCH v2 1/2] powerpc/powernv: rename remaining rng powernv_ functions to pnv_

2022-06-24 Thread Fabiano Rosas
"Jason A. Donenfeld"  writes:

> The preferred nomenclature is pnv_, not powernv_, but rng.c used
> powernv_ for some reason, which isn't consistent with the rest. A recent
> commit added a few pnv_ functions to rng.c, making the file a bit of a
> mishmash. This commit just replaces the rest of them.
>
> Cc: Michael Ellerman 
> Fixes: f3eac426657 ("powerpc/powernv: wire up rng during setup_arch")
> Signed-off-by: Jason A. Donenfeld 

Reviewed-by: Fabiano Rosas 



[PATCH v2] KVM: PPC: Align pt_regs in kvm_vcpu_arch structure

2022-06-24 Thread Fabiano Rosas
The H_ENTER_NESTED hypercall receives as second parameter the address
of a region of memory containing the values for the nested guest
privileged registers. We currently use the pt_regs structure contained
within kvm_vcpu_arch for that end.

Most hypercalls that receive a memory address expect that region to
not cross a 4K page boundary. We would want H_ENTER_NESTED to follow
the same pattern so this patch ensures the pt_regs structure sits
within a page.

Note: the pt_regs structure is currently 384 bytes in size, so
aligning to 512 is sufficient to ensure it will not cross a 4K page
and avoids punching too big a hole in struct kvm_vcpu_arch.

Signed-off-by: Fabiano Rosas 
Signed-off-by: Murilo Opsfelder Araújo 
---
v2:
 - updated commit message to inform the rationale for aligning to 512;

 - added Murilo's sign-off which I had forgotten, we worked on this
   together.
---
 arch/powerpc/include/asm/kvm_host.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 2909a88acd16..2c7219cef4ec 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -523,7 +523,11 @@ struct kvm_vcpu_arch {
struct kvmppc_book3s_shadow_vcpu *shadow_vcpu;
 #endif
 
-   struct pt_regs regs;
+   /*
+* This is passed along to the HV via H_ENTER_NESTED. Align to
+* prevent it crossing a real 4K page.
+*/
+   struct pt_regs regs __aligned(512);
 
struct thread_fp_state fp;
 
-- 
2.35.3



[PATCH v2 2/2] powerpc/kvm: don't crash on missing rng, and use darn

2022-06-24 Thread Jason A. Donenfeld
On POWER8 systems that don't have ibm,power-rng available, a guest that
ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
dereference a NULL pointer. And on machines with darn instead of
ibm,power-rng, H_RANDOM won't work at all.

This patch kills two birds with one stone, by routing H_RANDOM calls to
ppc_md.get_random_seed, and doing the real mode check inside of it.

Cc: sta...@vger.kernel.org # v4.1+
Cc: Michael Ellerman 
Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM 
implementation.")
Signed-off-by: Jason A. Donenfeld 
---
 arch/powerpc/include/asm/archrandom.h |  5 
 arch/powerpc/kvm/book3s_hv_builtin.c  |  7 +++---
 arch/powerpc/platforms/powernv/rng.c  | 33 +++
 3 files changed, 12 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/include/asm/archrandom.h 
b/arch/powerpc/include/asm/archrandom.h
index 11d4815841ab..3af27bb84a3d 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -38,12 +38,7 @@ static inline bool __must_check 
arch_get_random_seed_int(unsigned int *v)
 #endif /* CONFIG_ARCH_RANDOM */
 
 #ifdef CONFIG_PPC_POWERNV
-int pnv_hwrng_present(void);
 int pnv_get_random_long(unsigned long *v);
-int pnv_get_random_real_mode(unsigned long *v);
-#else
-static inline int pnv_hwrng_present(void) { return 0; }
-static inline int pnv_get_random_real_mode(unsigned long *v) { return 0; }
 #endif
 
 #endif /* _ASM_POWERPC_ARCHRANDOM_H */
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 799d40c2ab4f..3abaef5f9ac2 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -176,13 +176,14 @@ EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode);
 
 int kvmppc_hwrng_present(void)
 {
-   return pnv_hwrng_present();
+   return ppc_md.get_random_seed != NULL;
 }
 EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
 
 long kvmppc_rm_h_random(struct kvm_vcpu *vcpu)
 {
-   if (pnv_get_random_real_mode(&vcpu->arch.regs.gpr[4]))
+   if (ppc_md.get_random_seed &&
+   ppc_md.get_random_seed(&vcpu->arch.regs.gpr[4]))
return H_SUCCESS;
 
return H_HARDWARE;
diff --git a/arch/powerpc/platforms/powernv/rng.c 
b/arch/powerpc/platforms/powernv/rng.c
index 868bb9777425..c748567cd47e 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -29,15 +29,6 @@ struct pnv_rng {
 
 static DEFINE_PER_CPU(struct pnv_rng *, pnv_rng);
 
-int pnv_hwrng_present(void)
-{
-   struct pnv_rng *rng;
-
-   rng = get_cpu_var(pnv_rng);
-   put_cpu_var(rng);
-   return rng != NULL;
-}
-
 static unsigned long rng_whiten(struct pnv_rng *rng, unsigned long val)
 {
unsigned long parity;
@@ -58,17 +49,6 @@ static unsigned long rng_whiten(struct pnv_rng *rng, 
unsigned long val)
return val;
 }
 
-int pnv_get_random_real_mode(unsigned long *v)
-{
-   struct pnv_rng *rng;
-
-   rng = raw_cpu_read(pnv_rng);
-
-   *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));
-
-   return 1;
-}
-
 static int pnv_get_random_darn(unsigned long *v)
 {
unsigned long val;
@@ -105,11 +85,14 @@ int pnv_get_random_long(unsigned long *v)
 {
struct pnv_rng *rng;
 
-   rng = get_cpu_var(pnv_rng);
-
-   *v = rng_whiten(rng, in_be64(rng->regs));
-
-   put_cpu_var(rng);
+   if (mfmsr() & MSR_DR) {
+   rng = raw_cpu_read(pnv_rng);
+   *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));
+   } else {
+   rng = get_cpu_var(pnv_rng);
+   *v = rng_whiten(rng, in_be64(rng->regs));
+   put_cpu_var(rng);
+   }
 
return 1;
 }
-- 
2.35.1



[PATCH v2 1/2] powerpc/powernv: rename remaining rng powernv_ functions to pnv_

2022-06-24 Thread Jason A. Donenfeld
The preferred nomenclature is pnv_, not powernv_, but rng.c used
powernv_ for some reason, which isn't consistent with the rest. A recent
commit added a few pnv_ functions to rng.c, making the file a bit of a
mishmash. This commit just replaces the rest of them.

Cc: Michael Ellerman 
Fixes: f3eac426657 ("powerpc/powernv: wire up rng during setup_arch")
Signed-off-by: Jason A. Donenfeld 
---
 arch/powerpc/include/asm/archrandom.h | 10 +++
 arch/powerpc/kvm/book3s_hv_builtin.c  |  4 +--
 arch/powerpc/platforms/powernv/rng.c  | 42 +--
 drivers/char/hw_random/powernv-rng.c  |  2 +-
 4 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/include/asm/archrandom.h 
b/arch/powerpc/include/asm/archrandom.h
index 9a53e29680f4..11d4815841ab 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -38,12 +38,12 @@ static inline bool __must_check 
arch_get_random_seed_int(unsigned int *v)
 #endif /* CONFIG_ARCH_RANDOM */
 
 #ifdef CONFIG_PPC_POWERNV
-int powernv_hwrng_present(void);
-int powernv_get_random_long(unsigned long *v);
-int powernv_get_random_real_mode(unsigned long *v);
+int pnv_hwrng_present(void);
+int pnv_get_random_long(unsigned long *v);
+int pnv_get_random_real_mode(unsigned long *v);
 #else
-static inline int powernv_hwrng_present(void) { return 0; }
-static inline int powernv_get_random_real_mode(unsigned long *v) { return 0; }
+static inline int pnv_hwrng_present(void) { return 0; }
+static inline int pnv_get_random_real_mode(unsigned long *v) { return 0; }
 #endif
 
 #endif /* _ASM_POWERPC_ARCHRANDOM_H */
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 88a8f6473c4e..799d40c2ab4f 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -176,13 +176,13 @@ EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode);
 
 int kvmppc_hwrng_present(void)
 {
-   return powernv_hwrng_present();
+   return pnv_hwrng_present();
 }
 EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
 
 long kvmppc_rm_h_random(struct kvm_vcpu *vcpu)
 {
-   if (powernv_get_random_real_mode(&vcpu->arch.regs.gpr[4]))
+   if (pnv_get_random_real_mode(&vcpu->arch.regs.gpr[4]))
return H_SUCCESS;
 
return H_HARDWARE;
diff --git a/arch/powerpc/platforms/powernv/rng.c 
b/arch/powerpc/platforms/powernv/rng.c
index 463c78c52cc5..868bb9777425 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -21,24 +21,24 @@
 
 #define DARN_ERR 0xul
 
-struct powernv_rng {
+struct pnv_rng {
void __iomem *regs;
void __iomem *regs_real;
unsigned long mask;
 };
 
-static DEFINE_PER_CPU(struct powernv_rng *, powernv_rng);
+static DEFINE_PER_CPU(struct pnv_rng *, pnv_rng);
 
-int powernv_hwrng_present(void)
+int pnv_hwrng_present(void)
 {
-   struct powernv_rng *rng;
+   struct pnv_rng *rng;
 
-   rng = get_cpu_var(powernv_rng);
+   rng = get_cpu_var(pnv_rng);
put_cpu_var(rng);
return rng != NULL;
 }
 
-static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
+static unsigned long rng_whiten(struct pnv_rng *rng, unsigned long val)
 {
unsigned long parity;
 
@@ -58,18 +58,18 @@ static unsigned long rng_whiten(struct powernv_rng *rng, 
unsigned long val)
return val;
 }
 
-int powernv_get_random_real_mode(unsigned long *v)
+int pnv_get_random_real_mode(unsigned long *v)
 {
-   struct powernv_rng *rng;
+   struct pnv_rng *rng;
 
-   rng = raw_cpu_read(powernv_rng);
+   rng = raw_cpu_read(pnv_rng);
 
*v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));
 
return 1;
 }
 
-static int powernv_get_random_darn(unsigned long *v)
+static int pnv_get_random_darn(unsigned long *v)
 {
unsigned long val;
 
@@ -93,19 +93,19 @@ static int __init initialise_darn(void)
return -ENODEV;
 
for (i = 0; i < 10; i++) {
-   if (powernv_get_random_darn(&val)) {
-   ppc_md.get_random_seed = powernv_get_random_darn;
+   if (pnv_get_random_darn(&val)) {
+   ppc_md.get_random_seed = pnv_get_random_darn;
return 0;
}
}
return -EIO;
 }
 
-int powernv_get_random_long(unsigned long *v)
+int pnv_get_random_long(unsigned long *v)
 {
-   struct powernv_rng *rng;
+   struct pnv_rng *rng;
 
-   rng = get_cpu_var(powernv_rng);
+   rng = get_cpu_var(pnv_rng);
 
*v = rng_whiten(rng, in_be64(rng->regs));
 
@@ -113,9 +113,9 @@ int powernv_get_random_long(unsigned long *v)
 
return 1;
 }
-EXPORT_SYMBOL_GPL(powernv_get_random_long);
+EXPORT_SYMBOL_GPL(pnv_get_random_long);
 
-static __init void rng_init_per_cpu(struct powernv_rng *rng,
+static __init void rng_init_per_cpu(struct pnv_rng *rng,
struct device_node *dn)

[PATCH v2 0/2] powerpc rng cleanups

2022-06-24 Thread Jason A. Donenfeld
These are two small cleanups for -next.

Jason A. Donenfeld (2):
  powerpc/powernv: rename remaining rng powernv_ functions to pnv_
  powerpc/kvm: don't crash on missing rng, and use darn

 arch/powerpc/include/asm/archrandom.h |  7 +--
 arch/powerpc/kvm/book3s_hv_builtin.c  |  7 +--
 arch/powerpc/platforms/powernv/rng.c  | 63 ++-
 drivers/char/hw_random/powernv-rng.c  |  2 +-
 4 files changed, 29 insertions(+), 50 deletions(-)

-- 
2.35.1



Re: [PATCH] powerpc/kvm: don't crash on missing rng, and use darn

2022-06-24 Thread Jason A. Donenfeld
Hi Fabiano,

On Fri, Jun 24, 2022 at 3:43 PM Fabiano Rosas  wrote:
>
> "Jason A. Donenfeld"  writes:
>
> > On POWER8 systems that don't have ibm,power-rng available, a guest that
> > ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> > dereference a NULL pointer. And on machines with darn instead of
> > ibm,power-rng, H_RANDOM won't work at all.
> >
> > This patch kills two birds with one stone, by routing H_RANDOM calls to
> > ppc_md.get_random_seed, and doing the real mode check inside of it.
> >
> > Cc: sta...@vger.kernel.org # v4.1+
> > Cc: Michael Ellerman 
> > Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM 
> > implementation.")
> > Signed-off-by: Jason A. Donenfeld 
> > ---
> >
> > This patch must be applied ontop of:
> > 1) 
> > https://github.com/linuxppc/linux/commit/f3eac426657d985b97c92fa5f7ae1d43f04721f3
> > 2) https://lore.kernel.org/all/20220622102532.173393-1-ja...@zx2c4.com/
> >
> >
> >  arch/powerpc/include/asm/archrandom.h |  5 
> >  arch/powerpc/kvm/book3s_hv_builtin.c  |  5 ++--
> >  arch/powerpc/platforms/powernv/rng.c  | 33 +++
> >  3 files changed, 11 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/archrandom.h 
> > b/arch/powerpc/include/asm/archrandom.h
> > index 11d4815841ab..3af27bb84a3d 100644
> > --- a/arch/powerpc/include/asm/archrandom.h
> > +++ b/arch/powerpc/include/asm/archrandom.h
> > @@ -38,12 +38,7 @@ static inline bool __must_check 
> > arch_get_random_seed_int(unsigned int *v)
> >  #endif /* CONFIG_ARCH_RANDOM */
> >
> >  #ifdef CONFIG_PPC_POWERNV
> > -int pnv_hwrng_present(void);
> >  int pnv_get_random_long(unsigned long *v);
> > -int pnv_get_random_real_mode(unsigned long *v);
> > -#else
> > -static inline int pnv_hwrng_present(void) { return 0; }
> > -static inline int pnv_get_random_real_mode(unsigned long *v) { return 0; }
> >  #endif
> >
> >  #endif /* _ASM_POWERPC_ARCHRANDOM_H */
> > diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
> > b/arch/powerpc/kvm/book3s_hv_builtin.c
> > index 799d40c2ab4f..1c6672826db5 100644
> > --- a/arch/powerpc/kvm/book3s_hv_builtin.c
> > +++ b/arch/powerpc/kvm/book3s_hv_builtin.c
> > @@ -176,13 +176,14 @@ EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode);
> >
> >  int kvmppc_hwrng_present(void)
> >  {
> > - return pnv_hwrng_present();
> > + return ppc_md.get_random_seed != NULL;
> >  }
> >  EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
> >
> >  long kvmppc_rm_h_random(struct kvm_vcpu *vcpu)
> >  {
> > - if (pnv_get_random_real_mode(&vcpu->arch.regs.gpr[4]))
> > + if (ppc_md.get_random_seed &&
> > + ppc_md.get_random_seed(&vcpu->arch.regs.gpr[4]))
> >   return H_SUCCESS;
>
> This is the same as arch_get_random_seed_long, perhaps you could use it
> instead.

Sure, why not. Will send a v2.

Jason


Re: [PATCH v2 4/4] pseries/mobility: Set NMI watchdog factor during LPM

2022-06-24 Thread Laurent Dufour
On 23/06/2022, 19:28:34, Nathan Lynch wrote:
> Laurent Dufour  writes:
>> diff --git a/arch/powerpc/platforms/pseries/mobility.c 
>> b/arch/powerpc/platforms/pseries/mobility.c
>> index 179bbd4ae881..4284ceaf9060 100644
>> --- a/arch/powerpc/platforms/pseries/mobility.c
>> +++ b/arch/powerpc/platforms/pseries/mobility.c
>> @@ -48,6 +48,39 @@ struct update_props_workarea {
>>  #define MIGRATION_SCOPE (1)
>>  #define PRRN_SCOPE -2
>>  
>> +#ifdef CONFIG_PPC_WATCHDOG
>> +static unsigned int lpm_nmi_wd_factor = 200;
>> +
>> +#ifdef CONFIG_SYSCTL
>> +static struct ctl_table lpm_nmi_wd_factor_ctl_table[] = {
>> +{
>> +.procname   = "lpm_nmi_watchdog_factor",
> 
> Assuming the basic idea is acceptable, I suggest making the user-visible
> name more generic (e.g. "nmi_watchdog_factor") in case it makes sense to
> apply this to other contexts in the future.

Fair enough, indeed, I was wondering if "lpm" is meaningful.

> 
>> +.data   = &lpm_nmi_wd_factor,
>> +.maxlen = sizeof(int),
>> +.mode   = 0644,
>> +.proc_handler   = proc_douintvec_minmax,
>> +},
>> +{}
>> +};
>> +static struct ctl_table lpm_nmi_wd_factor_sysctl_root[] = {
>> +{
>> +.procname   = "kernel",
>> +.mode   = 0555,
>> +.child  = lpm_nmi_wd_factor_ctl_table,
>> +},
>> +{}
>> +};
>> +
>> +static int __init register_lpm_nmi_wd_factor_sysctl(void)
>> +{
>> +register_sysctl_table(lpm_nmi_wd_factor_sysctl_root);
>> +
>> +return 0;
>> +}
>> +device_initcall(register_lpm_nmi_wd_factor_sysctl);
>> +#endif /* CONFIG_SYSCTL */
>> +#endif /* CONFIG_PPC_WATCHDOG */
>> +
>>  static int mobility_rtas_call(int token, char *buf, s32 scope)
>>  {
>>  int rc;
>> @@ -702,6 +735,7 @@ static int pseries_suspend(u64 handle)
>>  static int pseries_migrate_partition(u64 handle)
>>  {
>>  int ret;
>> +unsigned int factor = lpm_nmi_wd_factor;
>>  
>>  ret = wait_for_vasi_session_suspending(handle);
>>  if (ret)
>> @@ -709,6 +743,13 @@ static int pseries_migrate_partition(u64 handle)
>>  
>>  vas_migration_handler(VAS_SUSPEND);
>>  
>> +#ifdef CONFIG_PPC_WATCHDOG
>> +if (factor) {
>> +pr_info("Set the NMI watchdog factor to %u%%\n", factor);
>> +watchdog_nmi_set_lpm_factor(factor);
>> +}
>> +#endif /* CONFIG_PPC_WATCHDOG */
>> +
>>  ret = pseries_suspend(handle);
>>  if (ret == 0) {
>>  post_mobility_fixup();
>> @@ -716,6 +757,13 @@ static int pseries_migrate_partition(u64 handle)
>>  } else
>>  pseries_cancel_migration(handle, ret);
>>  
>> +#ifdef CONFIG_PPC_WATCHDOG
>> +if (factor) {
>> +pr_info("Restoring NMI watchdog timer\n");
>> +watchdog_nmi_set_lpm_factor(0);
>> +}
>> +#endif /* CONFIG_PPC_WATCHDOG */
>> +
> 
> A couple more suggestions:
> 
> * Move the prints into a single statement in watchdog_nmi_set_lpm_factor().

You're right that sounds a better place.

> 
> * Add no-op versions of watchdog_nmi_set_lpm_factor for
>   !CONFIG_PPC_WATCHDOG so we can minimize the #ifdef here.
>

Furthermore, this breaks compilation when !CONFIG_PPC_WATCHDOG because
lpm_nmi_wd_factor is not defined. I'll rework that part.

> Otherwise this looks fine to me.

Thanks,
Laurent.



Re: [PATCH v2 4/4] watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers

2022-06-24 Thread Michael Ellerman
Scott Cheloha  writes:
...
> +
> +static struct platform_driver pseries_wdt_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,

That owner assignment is not required.

It's set for you by platform_driver_register() via
module_platform_driver().

cheers


Re: [PATCH] powerpc/kvm: don't crash on missing rng, and use darn

2022-06-24 Thread Fabiano Rosas
"Jason A. Donenfeld"  writes:

> On POWER8 systems that don't have ibm,power-rng available, a guest that
> ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
> dereference a NULL pointer. And on machines with darn instead of
> ibm,power-rng, H_RANDOM won't work at all.
>
> This patch kills two birds with one stone, by routing H_RANDOM calls to
> ppc_md.get_random_seed, and doing the real mode check inside of it.
>
> Cc: sta...@vger.kernel.org # v4.1+
> Cc: Michael Ellerman 
> Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM 
> implementation.")
> Signed-off-by: Jason A. Donenfeld 
> ---
>
> This patch must be applied ontop of:
> 1) 
> https://github.com/linuxppc/linux/commit/f3eac426657d985b97c92fa5f7ae1d43f04721f3
> 2) https://lore.kernel.org/all/20220622102532.173393-1-ja...@zx2c4.com/
>
>
>  arch/powerpc/include/asm/archrandom.h |  5 
>  arch/powerpc/kvm/book3s_hv_builtin.c  |  5 ++--
>  arch/powerpc/platforms/powernv/rng.c  | 33 +++
>  3 files changed, 11 insertions(+), 32 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/archrandom.h 
> b/arch/powerpc/include/asm/archrandom.h
> index 11d4815841ab..3af27bb84a3d 100644
> --- a/arch/powerpc/include/asm/archrandom.h
> +++ b/arch/powerpc/include/asm/archrandom.h
> @@ -38,12 +38,7 @@ static inline bool __must_check 
> arch_get_random_seed_int(unsigned int *v)
>  #endif /* CONFIG_ARCH_RANDOM */
>
>  #ifdef CONFIG_PPC_POWERNV
> -int pnv_hwrng_present(void);
>  int pnv_get_random_long(unsigned long *v);
> -int pnv_get_random_real_mode(unsigned long *v);
> -#else
> -static inline int pnv_hwrng_present(void) { return 0; }
> -static inline int pnv_get_random_real_mode(unsigned long *v) { return 0; }
>  #endif
>
>  #endif /* _ASM_POWERPC_ARCHRANDOM_H */
> diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
> b/arch/powerpc/kvm/book3s_hv_builtin.c
> index 799d40c2ab4f..1c6672826db5 100644
> --- a/arch/powerpc/kvm/book3s_hv_builtin.c
> +++ b/arch/powerpc/kvm/book3s_hv_builtin.c
> @@ -176,13 +176,14 @@ EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode);
>
>  int kvmppc_hwrng_present(void)
>  {
> - return pnv_hwrng_present();
> + return ppc_md.get_random_seed != NULL;
>  }
>  EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
>
>  long kvmppc_rm_h_random(struct kvm_vcpu *vcpu)
>  {
> - if (pnv_get_random_real_mode(&vcpu->arch.regs.gpr[4]))
> + if (ppc_md.get_random_seed &&
> + ppc_md.get_random_seed(&vcpu->arch.regs.gpr[4]))
>   return H_SUCCESS;

This is the same as arch_get_random_seed_long, perhaps you could use it
instead.

Otherwise, the archrandom.h include is not needed anymore and could be
replaced with #include  for ppc_md.

>
>   return H_HARDWARE;
> diff --git a/arch/powerpc/platforms/powernv/rng.c 
> b/arch/powerpc/platforms/powernv/rng.c
> index 868bb9777425..c748567cd47e 100644
> --- a/arch/powerpc/platforms/powernv/rng.c
> +++ b/arch/powerpc/platforms/powernv/rng.c
> @@ -29,15 +29,6 @@ struct pnv_rng {
>
>  static DEFINE_PER_CPU(struct pnv_rng *, pnv_rng);
>
> -int pnv_hwrng_present(void)
> -{
> - struct pnv_rng *rng;
> -
> - rng = get_cpu_var(pnv_rng);
> - put_cpu_var(rng);
> - return rng != NULL;
> -}
> -
>  static unsigned long rng_whiten(struct pnv_rng *rng, unsigned long val)
>  {
>   unsigned long parity;
> @@ -58,17 +49,6 @@ static unsigned long rng_whiten(struct pnv_rng *rng, 
> unsigned long val)
>   return val;
>  }
>
> -int pnv_get_random_real_mode(unsigned long *v)
> -{
> - struct pnv_rng *rng;
> -
> - rng = raw_cpu_read(pnv_rng);
> -
> - *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));
> -
> - return 1;
> -}
> -
>  static int pnv_get_random_darn(unsigned long *v)
>  {
>   unsigned long val;
> @@ -105,11 +85,14 @@ int pnv_get_random_long(unsigned long *v)
>  {
>   struct pnv_rng *rng;
>
> - rng = get_cpu_var(pnv_rng);
> -
> - *v = rng_whiten(rng, in_be64(rng->regs));
> -
> - put_cpu_var(rng);
> + if (mfmsr() & MSR_DR) {
> + rng = raw_cpu_read(pnv_rng);
> + *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real));
> + } else {
> + rng = get_cpu_var(pnv_rng);
> + *v = rng_whiten(rng, in_be64(rng->regs));
> + put_cpu_var(rng);
> + }
>
>   return 1;
>  }


Re: [PATCH v2 3/4] powerpc/pseries: register pseries-wdt device with platform bus

2022-06-24 Thread Michael Ellerman
Nathan Lynch  writes:
> Scott Cheloha  writes:
>> PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
>> guest control of one or more virtual watchdog timers.
...
>
> Seems like we don't need pseries_wdt_pdev as it's unused elsewhere? But
> that's quite minor.

It's minor but please drop it in the next version.

cheers


Re: [PATCH v2 4/4] watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers

2022-06-24 Thread Michael Ellerman
Hi Scott,

A few comments below ...

Scott Cheloha  writes:
> PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
> guest control of one or more virtual watchdog timers.  The timers have
> millisecond granularity.  The guest is terminated when a timer
> expires.
>
> This patch adds a watchdog driver for these timers, "pseries-wdt".
>
> pseries_wdt_probe() currently assumes the existence of only one
> platform device and always assigns it watchdogNumber 1.  If we ever
> expose more than one timer to userspace we will need to devise a way
> to assign a distinct watchdogNumber to each platform device at device
> registration time.
>
> Signed-off-by: Scott Cheloha 
> ---
>  .../watchdog/watchdog-parameters.rst  |  12 +
>  drivers/watchdog/Kconfig  |   8 +
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/pseries-wdt.c| 264 ++
>  4 files changed, 285 insertions(+)
>  create mode 100644 drivers/watchdog/pseries-wdt.c
>
> diff --git a/Documentation/watchdog/watchdog-parameters.rst 
> b/Documentation/watchdog/watchdog-parameters.rst
> index 223c99361a30..29153eed6689 100644
> --- a/Documentation/watchdog/watchdog-parameters.rst
> +++ b/Documentation/watchdog/watchdog-parameters.rst
> @@ -425,6 +425,18 @@ pnx833x_wdt:
>  
>  -
>  
> +pseries-wdt:
> +action:
> + Action taken when watchdog expires: 0 (power off), 1 (restart),
> + 2 (dump and restart). (default=1)

I doesn't look like these values match what other drivers use to any
great extent.

So why not use the values from PAPR directly?

ie. 1 = power off, 2 = hard reset, 3 = dump & restart.

It seems like it would be easier to follow if the values map directly.

It's possible in future PAPR adds 247 to mean something, in which case
maybe we'd want to map that to a less silly value, but at least for now
the PAPR values are sensible enough.

> +timeout:
> + Initial watchdog timeout in seconds. (default=60)

That seems like a pretty common value, I don't see any guidance in PAPR.
Do we have any input from PowerVM on whether that's a good value?

> diff --git a/drivers/watchdog/pseries-wdt.c b/drivers/watchdog/pseries-wdt.c
> new file mode 100644
> index ..cfe53587457d
> --- /dev/null
> +++ b/drivers/watchdog/pseries-wdt.c
> @@ -0,0 +1,264 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022 International Business Machines, Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME "pseries-wdt"
> +
> +/*
> + * The PAPR's MSB->LSB bit ordering is 0->63.  These macros simplify
> + * defining bitfields as described in the PAPR without needing to
> + * transpose values to the more C-like 63->0 ordering.
> + */
> +#define SETFIELD(_v, _b, _e) \
> + (((unsigned long)(_v) << PPC_BITLSHIFT(_e)) & PPC_BITMASK((_b), (_e)))
> +#define GETFIELD(_v, _b, _e) \
> + (((unsigned long)(_v) & PPC_BITMASK((_b), (_e))) >> PPC_BITLSHIFT(_e))

This will probably sound like a cranky maintainer rant, but ...,
I really dislike these GETFIELD/SETFIELD macros.

I know you didn't invent them, but I would be much happier if you didn't
use them.

I know they (slightly) simplify things when you're transcribing values
from PAPR into the source, but that happens only once.

And then for the rest of eternity the source is harder to read because
there's this ridiculous level of indirection through insane macros just
to define some constants.

Anyone trying to use a debugger against this code will see a value in
memory like 0x200 and have to sit down and work out which SETFIELD()
macro it corresponds to.

> +/*
> + * The H_WATCHDOG hypercall first appears in PAPR v2.12 and is
> + * described fully in sections 14.5 and 14.15.6.
> + *
> + *
> + * H_WATCHDOG Input
> + *
> + * R4: "flags":
> + *
> + * Bits 48-55: "operation"
> + *
> + * 0x01  Start Watchdog
> + * 0x02  Stop Watchdog
> + * 0x03  Query Watchdog Capabilities
> + */
> +#define PSERIES_WDTF_OP(op)  SETFIELD((op), 48, 55)
> +#define PSERIES_WDTF_OP_STARTPSERIES_WDTF_OP(0x1)
> +#define PSERIES_WDTF_OP_STOP PSERIES_WDTF_OP(0x2)
> +#define PSERIES_WDTF_OP_QUERYPSERIES_WDTF_OP(0x3)
 
eg, IMHO these are much more reader friendly:

#define PSERIES_WDTF_OP_START   (1 << 8)
#define PSERIES_WDTF_OP_STOP(2 << 8)
#define PSERIES_WDTF_OP_QUERY   (3 << 8)

> +/*
> + * Bits 56-63: "timeoutAction" (for "Start Watchdog" only)
> + *
> + * 0x01  Hard poweroff
> + * 0x02  Hard restart
> + * 0x03  Dump restart
> + */
> +#define PSERIES_WDTF_ACTION(ac)  SETFIELD(ac, 56, 63)
> +#define PSERIES_WDTF_ACTION_HARD_POWEROFFPSERIES_WDTF_ACTION(0x1)
> +#define PSERIES_WDTF

Re: [PATCH v2 2/4] watchdog: export watchdog_mutex and lockup_detector_reconfigure

2022-06-24 Thread Laurent Dufour
On 24/06/2022, 11:37:23, Christoph Hellwig wrote:
> On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
>> The watchdog_mutex is exported to allow some variable to be changed under
>> its protection and prevent any conflict.
>> The lockup_detector_reconfigure() function is exported and is expected to
>> be called under the protection of watchdog_mutex.
> 
> Please provide an actual function accessor instead of directly touching
> a global lock.

Thanks Christoph,

I'll try to not touch to that mutex, if that's not doable, I'll create
function accessor as you're suggesting.



Re: [PATCH V4 05/26] arm64/mm: Move protection_map[] inside the platform

2022-06-24 Thread Catalin Marinas
On Fri, Jun 24, 2022 at 10:13:18AM +0530, Anshuman Khandual wrote:
> This moves protection_map[] inside the platform and makes it a static.
> 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual 

Reviewed-by: Catalin Marinas 


Re: [PATCH 3/3] powerpc/mm: Use VMALLOC_START to validate addr

2022-06-24 Thread Christophe Leroy


Le 23/06/2022 à 14:29, Aneesh Kumar K.V a écrit :
> Instead of high_memory use VMALLOC_START to validate that the address is
> not in the vmalloc range.

What's the reason for using VMALLOC_START instead ?
The gap between high_memory and VMALLOC_START should not be seen as 
valid memory either, should it ?

If the problem is book3s/64, commit ffa0b64e3be5 ("powerpc: Fix 
virt_addr_valid() for 64-bit Book3E & 32-bit") says that those 
additional tests are superfluous for boo3s/64. Maybe it's time to drop 
unnecessary tests for book3s/64 ?

> 
> Cc: Kefeng Wang 
> Cc: Christophe Leroy 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>   arch/powerpc/include/asm/page.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index e5f75c70eda8..256cad69e42e 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -134,7 +134,7 @@ static inline bool pfn_valid(unsigned long pfn)
>   
>   #define virt_addr_valid(vaddr)  ({  
> \
>   unsigned long _addr = (unsigned long)vaddr; \
> - _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory &&   \
> + _addr >= PAGE_OFFSET && _addr < (unsigned long)VMALLOC_START && \
>   pfn_valid(virt_to_pfn(_addr));  \
>   })
>   

Re: [PATCH v2 5/5] bpf ppc32: Add instructions for atomic_[cmp]xchg

2022-06-24 Thread Naveen N. Rao

Hari Bathini wrote:



On 14/06/22 12:41 am, Hari Bathini wrote:



On 11/06/22 11:04 pm, Christophe Leroy wrote:



Le 10/06/2022 à 17:55, Hari Bathini a écrit :

This adds two atomic opcodes BPF_XCHG and BPF_CMPXCHG on ppc32, both
of which include the BPF_FETCH flag.  The kernel's atomic_cmpxchg
operation fundamentally has 3 operands, but we only have two register
fields. Therefore the operand we compare against (the kernel's API
calls it 'old') is hard-coded to be BPF_REG_R0. Also, kernel's
atomic_cmpxchg returns the previous value at dst_reg + off. JIT the
same for BPF too with return value put in BPF_REG_0.

    BPF_REG_R0 = atomic_cmpxchg(dst_reg + off, BPF_REG_R0, src_reg);

Signed-off-by: Hari Bathini 
---

Changes in v2:
* Moved variable declaration to avoid late declaration error on
    some compilers.
* Tried to make code readable and compact.


   arch/powerpc/net/bpf_jit_comp32.c | 25 ++---
   1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp32.c 
b/arch/powerpc/net/bpf_jit_comp32.c

index 28dc6a1a8f2f..43f1c76d48ce 100644
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -297,6 +297,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 
*image, struct codegen_context *

   u32 ax_reg = bpf_to_ppc(BPF_REG_AX);
   u32 tmp_reg = bpf_to_ppc(TMP_REG);
   u32 size = BPF_SIZE(code);
+    u32 save_reg, ret_reg;
   s16 off = insn[i].off;
   s32 imm = insn[i].imm;
   bool func_addr_fixed;
@@ -799,6 +800,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 
*image, struct codegen_context *

    * BPF_STX ATOMIC (atomic ops)
    */
   case BPF_STX | BPF_ATOMIC | BPF_W:
+    save_reg = _R0;
+    ret_reg = src_reg;
+
   bpf_set_seen_register(ctx, tmp_reg);
   bpf_set_seen_register(ctx, ax_reg);
@@ -829,6 +833,21 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 
*image, struct codegen_context *

   case BPF_XOR | BPF_FETCH:
   EMIT(PPC_RAW_XOR(_R0, _R0, src_reg));
   break;
+    case BPF_CMPXCHG:
+    /*
+ * Return old value in BPF_REG_0 for BPF_CMPXCHG &
+ * in src_reg for other cases.
+ */
+    ret_reg = bpf_to_ppc(BPF_REG_0);
+
+    /* Compare with old value in BPF_REG_0 */
+    EMIT(PPC_RAW_CMPW(bpf_to_ppc(BPF_REG_0), _R0));
+    /* Don't set if different from old value */
+    PPC_BCC_SHORT(COND_NE, (ctx->idx + 3) * 4);
+    fallthrough;
+    case BPF_XCHG:
+    save_reg = src_reg;


I'm a bit lost, when save_reg is src_reg, don't we expect the upper part
(ie src_reg - 1) to be explicitely zeroised ?



For BPF_FETCH variants, old value is returned in src_reg (ret_reg).
In all such cases, higher 32-bit is zero'ed. But in case of BPF_CMPXCHG,
src_reg is untouched as BPF_REG_0 is used instead. So, higher 32-bit
remains untouched for that case alone..



+    break;
   default:
   pr_err_ratelimited("eBPF filter atomic op code 
%02x (@%d) unsupported\n",

  code, i);
@@ -836,15 +855,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 
*image, struct codegen_context *

   }
   /* store new value */
-    EMIT(PPC_RAW_STWCX(_R0, tmp_reg, dst_reg));
+    EMIT(PPC_RAW_STWCX(save_reg, tmp_reg, dst_reg));
   /* we're done if this succeeded */
   PPC_BCC_SHORT(COND_NE, tmp_idx);




   /* For the BPF_FETCH variant, get old data into 
src_reg */


With this commit, this comment is not true for BPF_CMPXCHG. So, this
comment should not be removed..


Sorry, the above should read:
   "should be removed" instead of "should not be removed"..



Or, just add BPF_REG_0 at the end:
 /* For the BPF_FETCH variant, get old data into src_reg/BPF_REG_0 */

The comment in CMPXCHG anyway details the difference. In any case, we 
can clean this up subsequently.



- Naveen



Re: [PATCH v2 0/5] Atomics support for eBPF on powerpc

2022-06-24 Thread Naveen N. Rao

Hi Hari,

Hari Bathini wrote:

This patchset adds atomic operations to the eBPF instruction set on
powerpc. The instructions that are added here can be summarised with
this list of kernel operations for ppc64:

* atomic[64]_[fetch_]add
* atomic[64]_[fetch_]and
* atomic[64]_[fetch_]or
* atomic[64]_[fetch_]xor
* atomic[64]_xchg
* atomic[64]_cmpxchg

and this list of kernel operations for ppc32:

* atomic_[fetch_]add
* atomic_[fetch_]and
* atomic_[fetch_]or
* atomic_[fetch_]xor
* atomic_xchg
* atomic_cmpxchg


Thanks for your work on this. For this series:
Reviewed-by: Naveen N. Rao 



The following are left out of scope for this effort:

* 64 bit operations on ppc32.
* Explicit memory barriers, 16 and 8 bit operations on both ppc32
  & ppc64.


The latter is a limitation of the eBPF instruction set itself today, 
rather than a powerpc-specific limitation.




The first patch adds support for bitwsie atomic operations on ppc64.
The next patch adds fetch variant support for these instructions. The
third patch adds support for xchg and cmpxchg atomic operations on
ppc64. Patch #4 adds support for 32-bit atomic bitwise operations on
ppc32. patch #5 adds support for xchg and cmpxchg atomic operations
on ppc32.

Validated these changes successfully with atomics test cases in
test_bpf testsuite and  test_verifier & test_progs selftests.
With test_bpf testsuite:

  all 147 atomics related test cases (both 32-bit & 64-bit) JIT'ed
  successfully on ppc64:

test_bpf: Summary: 1026 PASSED, 0 FAILED, [1014/1014 JIT'ed]

  all 76 atomics related test cases (32-bit) JIT'ed successfully
  on ppc32:

test_bpf: Summary: 1027 PASSED, 0 FAILED, [915/1015 JIT'ed]


Indeed. In my tests, before this series, with CONFIG_BPF_JIT_ALWAYS_ON=y:
test_bpf: Summary: 894 PASSED, 132 FAILED, [882/882 JIT'ed]
test_progs --name=atomic: Summary: 0/0 PASSED, 0 SKIPPED, 2 FAILED
test_verifier 0 100: Summary: 46 PASSED, 151 SKIPPED, 0 FAILED

With your patches:
test_bpf: Summary: 1026 PASSED, 0 FAILED, [1014/1014 JIT'ed]
test_progs --name=atomic: Summary: 2/7 PASSED, 0 SKIPPED, 0 FAILED
test_verifier 0 100: Summary: 101 PASSED, 96 SKIPPED, 0 FAILED

It is nice to see all the test_bpf tests pass again on ppc64le!

Tested-by: Naveen N. Rao  (ppc64le)


- Naveen



Re: [PATCH v2 2/4] watchdog: export watchdog_mutex and lockup_detector_reconfigure

2022-06-24 Thread Christoph Hellwig
On Tue, Jun 14, 2022 at 03:54:12PM +0200, Laurent Dufour wrote:
> The watchdog_mutex is exported to allow some variable to be changed under
> its protection and prevent any conflict.
> The lockup_detector_reconfigure() function is exported and is expected to
> be called under the protection of watchdog_mutex.

Please provide an actual function accessor instead of directly touching
a global lock.


Re: [PATCH] powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers

2022-06-24 Thread Pali Rohár
On Friday 24 June 2022 10:27:00 Pali Rohár wrote:
> On Friday 24 June 2022 13:08:59 Michael Ellerman wrote:
> > Pali Rohár  writes:
> > > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> > > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A 
> > > board.
> > > Hardware design is fully open source, all firmware and hardware design
> > > files are available at Turris project website:
> > >
> > > https://docs.turris.cz/hw/turris-1x/turris-1x/
> > > https://project.turris.cz/en/hardware.html
> > >
> > > Signed-off-by: Pali Rohár 
> > > ---
> > >  arch/powerpc/boot/dts/turris1x.dts | 470 +
> > >  1 file changed, 470 insertions(+)
> > >  create mode 100644 arch/powerpc/boot/dts/turris1x.dts
> > 
> > The headers say you Cc'ed this to the devicetree list, but I don't see
> > it in the devicetree patchwork:
> > 
> >   
> > https://patchwork.ozlabs.org/project/devicetree-bindings/list/?state=*&q=turris&archive=both
> 
> Email is on the devicetree list:
> https://lore.kernel.org/linux-devicetree/20220511143712.22550-1-p...@kernel.org/
> 
> > Which means it hasn't been run through Rob's CI scripts.
> > 
> > Maybe try a resend?
> > 
> > cheers

Now I sent V2 and it appeared in devicetree list archive too:
https://lore.kernel.org/linux-devicetree/20220624085550.20570-1-p...@kernel.org/


[PATCH v2] powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers

2022-06-24 Thread Pali Rohár
CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:

https://docs.turris.cz/hw/turris-1x/turris-1x/
https://project.turris.cz/en/hardware.html

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Sort all nodes by addresses
* Fix i2c address for MCU and SPD/EEPROM PSWP
---
 arch/powerpc/boot/dts/turris1x.dts | 475 +
 1 file changed, 475 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/turris1x.dts

diff --git a/arch/powerpc/boot/dts/turris1x.dts 
b/arch/powerpc/boot/dts/turris1x.dts
new file mode 100644
index ..c76b628cf026
--- /dev/null
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -0,0 +1,475 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Turris 1.x Device Tree Source
+ *
+ * Copyright 2013 - 2022 CZ.NIC z.s.p.o. (http://www.nic.cz/)
+ *
+ * Pinout, Schematics and Altium hardware design files are open source
+ * and available at: https://docs.turris.cz/hw/turris-1x/turris-1x/
+ */
+
+#include 
+#include 
+#include 
+/include/ "fsl/p2020si-pre.dtsi"
+
+/ {
+   model = "Turris 1.x";
+   compatible = "cznic,turris1x", "fsl,P2020RDB-PC"; /* fsl,P2020RDB-PC is 
required for booting Linux */
+
+   aliases {
+   ethernet0 = &enet0;
+   ethernet1 = &enet1;
+   ethernet2 = &enet2;
+   serial0 = &serial0;
+   serial1 = &serial1;
+   pci0 = &pci0;
+   pci1 = &pci1;
+   pci2 = &pci2;
+   spi0 = &spi0;
+   };
+
+   memory {
+   device_type = "memory";
+   };
+
+   soc: soc@ffe0 {
+   ranges = <0x0 0x0 0xffe0 0x0010>;
+
+   i2c@3000 {
+   /* PCA9557PW GPIO controller for boot config */
+   gpio-controller@18 {
+   compatible = "nxp,pca9557";
+   label = "bootcfg";
+   reg = <0x18>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   polarity = <0x00>;
+   };
+
+   /* STM32F030R8T6 MCU for power control */
+   power-control@2a {
+   /*
+* Turris Power Control firmware runs on 
STM32F0 MCU.
+* This firmware is open source and available 
at:
+* 
https://gitlab.nic.cz/turris/hw/turris_power_control
+*/
+   reg = <0x2a>;
+   };
+
+   /* DDR3 SPD/EEPROM PSWP instruction */
+   eeprom@32 {
+   reg = <0x32>;
+   };
+
+   /* SA56004ED temperature control */
+   temperature-sensor@4c {
+   compatible = "nxp,sa56004";
+   reg = <0x4c>;
+   interrupt-parent = <&gpio>;
+   interrupts = <12 IRQ_TYPE_LEVEL_LOW>, /* GPIO12 
- ALERT pin */
+<13 IRQ_TYPE_LEVEL_LOW>; /* GPIO13 
- CRIT pin */
+   };
+
+   /* DDR3 SPD/EEPROM */
+   eeprom@52 {
+   compatible = "atmel,spd";
+   reg = <0x52>;
+   };
+
+   /* MCP79402-I/ST Protected EEPROM */
+   eeprom@57 {
+   reg = <0x57>;
+   };
+
+   /* ATSHA204-TH-DA-T crypto module */
+   crypto@64 {
+   compatible = "atmel,atsha204";
+   reg = <0x64>;
+   };
+
+   /* IDT6V49205BNLGI clock generator */
+   clock-generator@69 {
+   compatible = "idt,6v49205b";
+   reg = <0x69>;
+   };
+
+   /* MCP79402-I/ST RTC */
+   rtc@6f {
+   compatible = "microchip,mcp7940x";
+   reg = <0x6f>;
+   interrupt-parent = <&gpio>;
+   interrupts = <14 0>; /* GPIO14 - MFP pin */
+   };
+   };
+
+   /* SPI on connector P1 */
+   spi0: spi@7000 {
+   };
+
+   gpio: gpio-controller@fc00 {
+   #interrupt-cells = <2>;
+   interrupt-controller

Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz  wrote:
> Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:
> >
> > All architecture-independent users of virt_to_bus() and bus_to_virt()
> > have been fixed to use the dma mapping interfaces or have been
> > removed now.  This means the definitions on most architectures, and the
> > CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
> >
> > The only exceptions to this are a few network and scsi drivers for m68k
> > Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
> > with the old interfaces and are probably not worth changing.
>
> The Amiga SCSI drivers are all old WD33C93 ones, and replacing
> virt_to_bus by virt_to_phys in the dma_setup() function there would
> cause no functional change at all.

Ok, thanks for taking a look here.

> drivers/vme/bridges/vme_ca91cx42.c hasn't been used at all on m68k (it
> is a PCI-to-VME bridge chipset driver that would be needed on
> architectures that natively use a PCI bus). I haven't found anything
> that selects that driver, so not sure it is even still in use??

It's gone now, Greg has already taken my patches for this through
the staging tree.

> That would allow you to drop the remaining virt_to_bus define from
> arch/m68k/include/asm/virtconvert.h.
>
> I could submit a patch to convert the Amiga SCSI drivers to use
> virt_to_phys if Geert and the SCSI maintainers think it's worth the churn.

I don't think using virt_to_phys() is an improvement here, as
virt_to_bus() was originally meant as a better abstraction to
replace the use of virt_to_phys() to make drivers portable, before
it got replaced by the dma-mapping interface in turn.

It looks like the Amiga SCSI drivers have an open-coded version of
what dma_map_single() does, to do bounce buffering and cache
management. The ideal solution would be to convert the drivers
actually use the appropriate dma-mapping interfaces and remove
this custom code.

The same could be done for the two vme drivers (scsi/mvme147.c
and ethernet/82596.c), which do the cache management but
apparently don't need swiotlb bounce buffering.

Rewriting the drivers to modern APIs is of course non-trivial,
and if you want a shortcut here, I would suggest introducing
platform specific helpers similar to isa_virt_to_bus() and call
them amiga_virt_to_bus() and vme_virt_to_bus, respectively.

Putting these into a platform specific header file at least helps
clarify that both the helper functions and the drivers using them
are non-portable.

> 32bit powerpc is a different matter though.

It's similar, but unrelated. The two apple ethernet drivers
(bmac and mace) can again either get changed to use the
dma-mapping interfaces, or get a custom pmac_virt_to_bus()/
pmac_bus_to_virt() helper.

There is also drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c,
which I think just needs a trivial change, but I'm not sure
how to do it correctly.

  Arnd


Re: [PATCH 2/2] powerpc/numa: Return the first online node if device tree mapping returns a not online node

2022-06-24 Thread Srikar Dronamraju
* Aneesh Kumar K.V  [2022-06-23 18:24:42]:

> While building the cpu_to_node map make sure we always use the online node
> to build the mapping table. In general this should not be an issue
> because the kernel use similar lookup mechanism (vphn_get_nid()) to mark
> nodes online (setup_node_data()). Hence NUMA nodes we find during
> lookup in numa_setup_cpu() will always be found online.
> 
> To keep logic simpler/correct, make sure that if the hypervisor
> or device tree returned a not online node, don't use that to build
> the map table. Instead, use the first_online_node.

Why should the returned nid be already online. Are we facing any problem
with the current code?

Since general idea is to keep cpu_to_node constant, By assigining it the
first_online_node, we may be ending up assigning a wrong node, resulting a
performance penalty later on. i.e CPU may actually belong to node 4 but we
assigned it to node 1. Also the coregroup id is derived from associavity
array. If there is a mismatch between the coregroup id and nid,
scheduler will crib.

> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/mm/numa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 0801b2ce9b7d..f387b9eb9dc9 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -741,7 +741,7 @@ static int numa_setup_cpu(unsigned long lcpu)
>   of_node_put(cpu);
> 
>  out_present:
> - if (nid < 0 || !node_possible(nid))
> + if (nid < 0 || !node_online(nid))
>   nid = first_online_node;
> 
>   /*
> -- 
> 2.36.1
> 

-- 
Thanks and Regards
Srikar Dronamraju


Re: [PATCH 1/2] powerpc/numa: Return the first online node instead of 0

2022-06-24 Thread Srikar Dronamraju
* Aneesh Kumar K.V  [2022-06-23 18:24:41]:

> If early cpu to node mapping finds an invalid node id, return
> the first online node instead of node 0.
> 
> With commit e75130f20b1f ("powerpc/numa: Offline memoryless cpuless node 0")
> the kernel marks node 0 offline in certain scenarios.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/topology.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/topology.h 
> b/arch/powerpc/include/asm/topology.h
> index 8a4d4f4d9749..704088b1d53c 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -60,7 +60,7 @@ static inline int early_cpu_to_node(int cpu)
>* Fall back to node 0 if nid is unset (it should be, except bugs).
>* This allows callers to safely do NODE_DATA(early_cpu_to_node(cpu)).
>*/
> - return (nid < 0) ? 0 : nid;
> + return (nid < 0) ? first_online_node : nid;

Looks good but just two queries.

1. Is there a possibility of early_cpu_to_node() being called before any
node is online?

2. first_online_node is actually not a variable, it returns the lowest
online node. Right? If lets a early_cpu_to_node() for the same CPU across a
node online/offline may end up giving two different nids. Right?


>  }
> 
>  int of_drconf_to_nid_single(struct drmem_lmb *lmb);
> -- 
> 2.36.1
> 

-- 
Thanks and Regards
Srikar Dronamraju


Re: [PATCH v2 2/4] watchdog: export watchdog_mutex and lockup_detector_reconfigure

2022-06-24 Thread Laurent Dufour
On 24/06/2022, 08:31:55, Michael Ellerman wrote:
> Laurent Dufour  writes:
>> In some cricunstances it may be interesting to reconfigure the watchdog
>> from inside the kernel.
>>
>> On PowerPC, this may helpful before and after a LPAR migration (LPM) is
>> initiated, because it implies some latencies, watchdog, and especially NMI
>> watchdog is expected to be triggered during this operation. Reconfiguring
>> the watchdog, would prevent it to happen too frequently during LPM.
>>
>> The watchdog_mutex is exported to allow some variable to be changed under
>> its protection and prevent any conflict.
>> The lockup_detector_reconfigure() function is exported and is expected to
>> be called under the protection of watchdog_mutex.
>>
>> Signed-off-by: Laurent Dufour 
>> ---
>>  include/linux/nmi.h | 3 +++
>>  kernel/watchdog.c   | 6 +++---
>>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> Is there a maintainer for kernel/watchdog.c ?

Nothing clearly identified AFAICT.

I'll add the commit signers reported by get_maintainer.pl.

> There's Wim & Guenter at linux-watchdog@vger but I think that's only for
> drivers/watchdog?
> 
> Maybe we should Cc that list anyway?

Yes, that's a good idea.

> 
> 
>> diff --git a/include/linux/nmi.h b/include/linux/nmi.h
>> index 750c7f395ca9..84300fb0f90a 100644
>> --- a/include/linux/nmi.h
>> +++ b/include/linux/nmi.h
>> @@ -122,6 +122,9 @@ int watchdog_nmi_probe(void);
>>  int watchdog_nmi_enable(unsigned int cpu);
>>  void watchdog_nmi_disable(unsigned int cpu);
>>  
>> +extern struct mutex watchdog_mutex;
>> +void lockup_detector_reconfigure(void);
> 
> It would be preferable if we didn't export the mutex.
> 
> I think you could arrange that by ...
> 
> Renaming lockup_detector_configure() to __lockup_detector_configure()
> and then adding a new lockup_detector_configure() that is non-static and
> takes the lock around __lockup_detector_configure().

Unfortunately, that will not be enough, because this mutex is also used to
protect wd_watchdog, to ensure it is not changed while another operation is
in progress.

I may try finding another way to protect that value, may be using
WRITE/READ_ONCE(). Indeed, the only requirement is to read a stable value
in watchdog_calc_timeouts().

Thanks,
Laurent.





Re: [PATCH] powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers

2022-06-24 Thread Pali Rohár
On Friday 24 June 2022 13:08:59 Michael Ellerman wrote:
> Pali Rohár  writes:
> > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
> > Hardware design is fully open source, all firmware and hardware design
> > files are available at Turris project website:
> >
> > https://docs.turris.cz/hw/turris-1x/turris-1x/
> > https://project.turris.cz/en/hardware.html
> >
> > Signed-off-by: Pali Rohár 
> > ---
> >  arch/powerpc/boot/dts/turris1x.dts | 470 +
> >  1 file changed, 470 insertions(+)
> >  create mode 100644 arch/powerpc/boot/dts/turris1x.dts
> 
> The headers say you Cc'ed this to the devicetree list, but I don't see
> it in the devicetree patchwork:
> 
>   
> https://patchwork.ozlabs.org/project/devicetree-bindings/list/?state=*&q=turris&archive=both

Email is on the devicetree list:
https://lore.kernel.org/linux-devicetree/20220511143712.22550-1-p...@kernel.org/

> Which means it hasn't been run through Rob's CI scripts.
> 
> Maybe try a resend?
> 
> cheers


Re: [RFC PATCH v2 0/7] objtool: Enable and implement --mcount option on powerpc

2022-06-24 Thread Christophe Leroy
Hi Sathvika

Le 18/06/2022 à 06:56, Sathvika Vasireddy a écrit :
> Hi Christophe,
> 
> On 15/06/22 21:33, Christophe Leroy wrote:
>> Do you have any idea when you plan to send next revision ?
>>
>> I'm really looking forward to submitting the inline static calls on top
>> of your series.
> 
> I'm planning to send RFC v3 next week.
> 

Is everything going ok ? Don't hesitate if you need help.

Christophe

Re: [PATCH v1 0/4] Kill the time spent in patch_instruction()

2022-06-24 Thread Christophe Leroy

Michael ?

Le 31/05/2022 à 08:24, Christophe Leroy a écrit :



Le 17/05/2022 à 14:37, Michael Ellerman a écrit :

Christophe Leroy  writes:

Le 15/05/2022 à 12:28, Michael Ellerman a écrit :

On Tue, 22 Mar 2022 16:40:17 +0100, Christophe Leroy wrote:

This series reduces by 70% the time required to activate
ftrace on an 8xx with CONFIG_STRICT_KERNEL_RWX.

Measure is performed in function ftrace_replace_code() using mftb()
around the loop.

With the series,
- Without CONFIG_STRICT_KERNEL_RWX, 416000 TB ticks are measured.
- With CONFIG_STRICT_KERNEL_RWX, 546000 TB ticks are measured.

[...]


Patches 1, 3 and 4 applied to powerpc/next.

[1/4] powerpc/code-patching: Don't call is_vmalloc_or_module_addr() 
without CONFIG_MODULES

https://git.kernel.org/powerpc/c/cb3ac45214c03852430979a43180371a44b74596 


[3/4] powerpc/code-patching: Use jump_label for testing freed initmem

https://git.kernel.org/powerpc/c/b033767848c4115e486b1a51946de3bee2ac0fa6 

[4/4] powerpc/code-patching: Use jump_label to check if 
poking_init() is done

https://git.kernel.org/powerpc/c/1751289268ef959db68b0b6f798d904d6403309a 





Patch 2 was the keystone of this series. What happened to it ?


It broke on 64-bit. I think I know why but I haven't had time to test
it. Will try and get it fixed in the next day or two.



You didn't find any solution at the end, or didn't have time ?

What was the problem exactly ? I made a quick try on QEMU and it was 
working as expected.




Should I make it a ppc32-only change ?