From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Nicholas Piggin <npiggin@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
Date: Mon, 14 Aug 2023 08:43:06 +0000 [thread overview]
Message-ID: <253aea00-d60d-377e-d696-cad83896b53e@csgroup.eu> (raw)
In-Reply-To: <CUS1WM4XRDIT.2GTHPR1FHQKS2@wheely>
Le 14/08/2023 à 08:24, Nicholas Piggin a écrit :
> On Wed Aug 9, 2023 at 6:01 PM AEST, Christophe Leroy wrote:
>> With skiboot_defconfig, Clang reports:
>>
>> CC arch/powerpc/mm/book3s64/radix_tlb.o
>> arch/powerpc/mm/book3s64/radix_tlb.c:419:20: error: unused function '_tlbie_pid_lpid' [-Werror,-Wunused-function]
>> static inline void _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
>> ^
>> arch/powerpc/mm/book3s64/radix_tlb.c:663:20: error: unused function '_tlbie_va_range_lpid' [-Werror,-Wunused-function]
>> static inline void _tlbie_va_range_lpid(unsigned long start, unsigned long end,
>> ^
>>
>> This is because those functions are only called from functions
>> enclosed in a #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>>
>> Move below functions inside that #ifdef
>> * __tlbie_pid_lpid(unsigned long pid,
>> * __tlbie_va_lpid(unsigned long va, unsigned long pid,
>> * fixup_tlbie_pid_lpid(unsigned long pid, unsigned long lpid)
>> * _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
>> * fixup_tlbie_va_range_lpid(unsigned long va,
>> * __tlbie_va_range_lpid(unsigned long start, unsigned long end,
>> * _tlbie_va_range_lpid(unsigned long start, unsigned long end,
>
> Thanks for doing this. Functions vaguely belong where they are, which
> makes it slightly annoying to move them. Is it also annoying to add
> ifdefs for each one where they are?
Looking at it once more, we can even move all those functions out in a
separate file that would only be built when
CONFIG_KVM_BOOK3S_HV_POSSIBLE is selected. The only dependency with
other part of the file is the static tlb_single_page_flush_ceiling,
which can easily be made global.
In principle we try to avoid #ifdefs in C-files.
Why would we want to keep those functions at the current place and
spreat several more #ifdefs inside the file ?
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Nicholas Piggin <npiggin@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
Date: Mon, 14 Aug 2023 08:43:06 +0000 [thread overview]
Message-ID: <253aea00-d60d-377e-d696-cad83896b53e@csgroup.eu> (raw)
In-Reply-To: <CUS1WM4XRDIT.2GTHPR1FHQKS2@wheely>
Le 14/08/2023 à 08:24, Nicholas Piggin a écrit :
> On Wed Aug 9, 2023 at 6:01 PM AEST, Christophe Leroy wrote:
>> With skiboot_defconfig, Clang reports:
>>
>> CC arch/powerpc/mm/book3s64/radix_tlb.o
>> arch/powerpc/mm/book3s64/radix_tlb.c:419:20: error: unused function '_tlbie_pid_lpid' [-Werror,-Wunused-function]
>> static inline void _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
>> ^
>> arch/powerpc/mm/book3s64/radix_tlb.c:663:20: error: unused function '_tlbie_va_range_lpid' [-Werror,-Wunused-function]
>> static inline void _tlbie_va_range_lpid(unsigned long start, unsigned long end,
>> ^
>>
>> This is because those functions are only called from functions
>> enclosed in a #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>>
>> Move below functions inside that #ifdef
>> * __tlbie_pid_lpid(unsigned long pid,
>> * __tlbie_va_lpid(unsigned long va, unsigned long pid,
>> * fixup_tlbie_pid_lpid(unsigned long pid, unsigned long lpid)
>> * _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
>> * fixup_tlbie_va_range_lpid(unsigned long va,
>> * __tlbie_va_range_lpid(unsigned long start, unsigned long end,
>> * _tlbie_va_range_lpid(unsigned long start, unsigned long end,
>
> Thanks for doing this. Functions vaguely belong where they are, which
> makes it slightly annoying to move them. Is it also annoying to add
> ifdefs for each one where they are?
Looking at it once more, we can even move all those functions out in a
separate file that would only be built when
CONFIG_KVM_BOOK3S_HV_POSSIBLE is selected. The only dependency with
other part of the file is the static tlb_single_page_flush_ceiling,
which can easily be made global.
In principle we try to avoid #ifdefs in C-files.
Why would we want to keep those functions at the current place and
spreat several more #ifdefs inside the file ?
Christophe
next prev parent reply other threads:[~2023-08-14 8:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 8:01 [PATCH] powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE Christophe Leroy
2023-08-09 8:01 ` Christophe Leroy
2023-08-14 6:24 ` Nicholas Piggin
2023-08-14 6:24 ` Nicholas Piggin
2023-08-14 8:43 ` Christophe Leroy [this message]
2023-08-14 8:43 ` Christophe Leroy
2023-08-23 11:55 ` Michael Ellerman
2023-08-23 11:55 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=253aea00-d60d-377e-d696-cad83896b53e@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.