On Wed, 2022-11-09 at 15:51 +1100, Benjamin Gray wrote:
> The generic implementation of this function isn't really generic
> (Hash
> is not implemented). Unfortunately, the runtime warnings cannot be
> replaced with BUILD_BUG's, so it seems safer not to provide a stub in
> the first place.
>
> Signed-off-by: Benjamin Gray <bg...@linux.ibm.com>
[+ Fred]
This seems fine to me.
Reviewed-by: Andrew Donnellan <a...@linux.ibm.com>
> ---
> v10: * New in v10 to remove hash__flush_all_mm,
> hash__local_flush_all_mm
> ---
> arch/powerpc/include/asm/mmu_context.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h
> b/arch/powerpc/include/asm/mmu_context.h
> index c1ea270bb848..57f5017111f4 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -151,8 +151,8 @@ static inline void mm_context_remove_copro(struct
> mm_struct *mm)
> * nMMU and/or PSL need to be cleaned up.
> *
> * Both the 'copros' and 'active_cpus' counts are looked at
> in
> - * flush_all_mm() to determine the scope (local/global) of
> the
> - * TLBIs, so we need to flush first before decrementing
> + * radix__flush_all_mm() to determine the scope
> (local/global)
> + * of the TLBIs, so we need to flush first before
> decrementing
> * 'copros'. If this API is used by several callers for the
> * same context, it can lead to over-flushing. It's hopefully
> * not common enough to be a problem.
> @@ -164,7 +164,7 @@ static inline void mm_context_remove_copro(struct
> mm_struct *mm)
> * in-between.
> */
> if (radix_enabled()) {
> - flush_all_mm(mm);
> + radix__flush_all_mm(mm);
>
> c = atomic_dec_if_positive(&mm->context.copros);
> /* Detect imbalance between add and remove */
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
