[RESEND,v2] powerpc: mute unused-but-set-variable warnings

pte_unmap() compiles away on some powerpc platforms, so silence the
warnings below by making it a static inline function.

mm/memory.c: In function 'copy_pte_range':
mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
[-Wunused-but-set-variable]
mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
[-Wunused-but-set-variable]
mm/madvise.c: In function 'madvise_free_pte_range':
mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
mm/swap_state.c: In function 'swap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]

Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by:: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Qian Cai <cai@lca.pw>
---

v2: make it a static inline function.

 arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++-
 arch/powerpc/include/asm/nohash/64/pgtable.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

Is there a reason for resending ? AFAICS, both are identical and still 
marked new in patchwork: 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055

Indeed, the resend has an issue in the commit log and fails the 
checkpatch (a :: in Reviewed-by::)

Christophe

Le 17/03/2019 à 23:05, Qian Cai a écrit :
> pte_unmap() compiles away on some powerpc platforms, so silence the
> warnings below by making it a static inline function.
> 
> mm/memory.c: In function 'copy_pte_range':
> mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
> [-Wunused-but-set-variable]
> mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
> [-Wunused-but-set-variable]
> mm/madvise.c: In function 'madvise_free_pte_range':
> mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
> mm/swap_state.c: In function 'swap_ra_info':
> mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
> 
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by:: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> 
> v2: make it a static inline function.
> 
>   arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++-
>   arch/powerpc/include/asm/nohash/64/pgtable.h | 3 ++-
>   2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 868fcaf56f6b..d798e33a0c86 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -1006,7 +1006,8 @@ extern struct page *pgd_page(pgd_t pgd);
>   	(((pte_t *) pmd_page_vaddr(*(dir))) + pte_index(addr))
>   
>   #define pte_offset_map(dir,addr)	pte_offset_kernel((dir), (addr))
> -#define pte_unmap(pte)			do { } while(0)
> +
> +static inline void pte_unmap(pte_t *pte) { }
>   
>   /* to find an entry in a kernel page-table-directory */
>   /* This now only contains the vmalloc pages */
> diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h
> index e77ed9761632..0384a3302fb6 100644
> --- a/arch/powerpc/include/asm/nohash/64/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
> @@ -205,7 +205,8 @@ static inline void pgd_set(pgd_t *pgdp, unsigned long val)
>     (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)))
>   
>   #define pte_offset_map(dir,addr)	pte_offset_kernel((dir), (addr))
> -#define pte_unmap(pte)			do { } while(0)
> +
> +static inline void pte_unmap(pte_t *pte) { }
>   
>   /* to find an entry in a kernel page-table-directory */
>   /* This now only contains the vmalloc pages */
>

On 3/19/19 5:21 AM, Christophe Leroy wrote:
> Is there a reason for resending ? AFAICS, both are identical and still marked
> new in patchwork:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055
> 

"RESEND" because of no maintainer response for more than one week.

> Indeed, the resend has an issue in the commit log and fails the checkpatch (a ::
> in Reviewed-by::)

Yes, my bad for a copy-and-paste error.

Qian Cai <cai@lca.pw> writes:
> On 3/19/19 5:21 AM, Christophe Leroy wrote:
>> Is there a reason for resending ? AFAICS, both are identical and still marked
>> new in patchwork:
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=76055
>> 
>
> "RESEND" because of no maintainer response for more than one week.

I don't know who told you to RESEND after a week, but especially at this
point in the development cycle a week is *way* too short.

And for trivial patches like this I may not get to them for several
weeks, I have other problems to fix like time going backward :)

In future please check patchwork and then if the patch is still new
after several weeks just send a ping in reply to that patch. A full
RESEND means I now have two identical patches to deal with in patchwork,
which makes more work for me.

cheers