LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] powerpc/mm: Add mask of always present MMU features
Date: Wed, 21 Oct 2020 18:37:41 +0200	[thread overview]
Message-ID: <f6081e25-5525-e7e0-c540-0e340913e8fd@csgroup.eu> (raw)
In-Reply-To: <871rhrejw8.fsf@linux.ibm.com>



Le 21/10/2020 à 16:25, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> 
>> Le 12/10/2020 à 17:39, Christophe Leroy a écrit :
>>> On the same principle as commit 773edeadf672 ("powerpc/mm: Add mask
>>> of possible MMU features"), add mask for MMU features that are
>>> always there in order to optimise out dead branches.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>> v2: Features must be anded with MMU_FTRS_POSSIBLE instead of ~0, otherwise
>>>       MMU_FTRS_ALWAYS is ~0 when no #ifdef matches.
>>
>> This is still not enough. For BOOK3S/32, MMU_FTRS_POSSIBLE is still too much.
>> We need a #ifdef CONFIG_PPC_BOOK3S_32 with 0.
>>
>> Christophe
>>
>>> ---
>>>    arch/powerpc/include/asm/mmu.h | 25 +++++++++++++++++++++++++
>>>    1 file changed, 25 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
>>> index 255a1837e9f7..64e7e7f7cda9 100644
>>> --- a/arch/powerpc/include/asm/mmu.h
>>> +++ b/arch/powerpc/include/asm/mmu.h
>>> @@ -201,8 +201,30 @@ enum {
>>>    		0,
>>>    };
>>>    
>>> +enum {
>>> +	MMU_FTRS_ALWAYS =
>>> +#ifdef CONFIG_PPC_8xx
>>> +		MMU_FTR_TYPE_8xx &
>>> +#endif
>>> +#ifdef CONFIG_40x
>>> +		MMU_FTR_TYPE_40x &
>>> +#endif
>>> +#ifdef CONFIG_PPC_47x
>>> +		MMU_FTR_TYPE_47x &
>>> +#elif defined(CONFIG_44x)
>>> +		MMU_FTR_TYPE_44x &
>>> +#endif
>>> +#if defined(CONFIG_E200) || defined(CONFIG_E500)
>>> +		MMU_FTR_TYPE_FSL_E &
>>> +#endif
>>> +		MMU_FTRS_POSSIBLE,
>>> +};
> 
> Will it be simpler if we make it a #define like below?
> 
> #ifdef CONFIG_PPC_8XX
> #define MMU_FTR_ALWAYS  MMU_FTR_TYPE_8XX & MMU_FTR_POSSIBLE
> #endif

Yes you are right, it will be simpler, and consistant with CPU_FTR_ALWAYS which is partly set with 
defines after all.

Christophe

> 
> 
> 
>>> +
>>>    static inline bool early_mmu_has_feature(unsigned long feature)
>>>    {
>>> +	if (MMU_FTRS_ALWAYS & feature)
>>> +		return true;
>>> +
>>>    	return !!(MMU_FTRS_POSSIBLE & cur_cpu_spec->mmu_features & feature);
>>>    }
>>>    
>>> @@ -231,6 +253,9 @@ static __always_inline bool mmu_has_feature(unsigned long feature)
>>>    	}
>>>    #endif
>>>    
>>> +	if (MMU_FTRS_ALWAYS & feature)
>>> +		return true;
>>> +
>>>    	if (!(MMU_FTRS_POSSIBLE & feature))
>>>    		return false;
>>>    
>>>

      reply	other threads:[~2020-10-21 16:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12 15:39 [PATCH v2] powerpc/mm: Add mask of always present MMU features Christophe Leroy
2020-10-21 10:32 ` Christophe Leroy
2020-10-21 14:25   ` Aneesh Kumar K.V
2020-10-21 16:37     ` Christophe Leroy [this message]

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=f6081e25-5525-e7e0-c540-0e340913e8fd@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox