Re: [PATCH v7 10/14] mips: move has_transparent_hugepage() out of THP guard

[Thomas Bogendoerfer]

On Tue, Sep 01, 2026 at 03:53:18PM -0400, Luiz Capitulino wrote:
> On 2026-09-01 07:42, Lance Yang wrote:
> > 
> > 
> > On 2026/9/1 11:12, Luiz Capitulino wrote:
> > > A future commit will introduce a kernel API to allow for checking if the
> > > CPU supports PMD-sized pages. This API will be based on the
> > > has_transparent_hugepage() implementation but will be orthogonal to THP
> > > and therefore must work when CONFIG_TRANSPARENT_HUGEPAGE=n.
> > > 
> > > Move its definition out of the THP guard.
> > > 
> > > Signed-off-by: Luiz Capitulino <luizcap@xxxxxxxxxx>
> > > ---
> > >   arch/mips/include/asm/pgtable.h | 6 +++---
> > >   arch/mips/mm/tlb-r4k.c          | 4 ----
> > >   2 files changed, 3 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> > > index fa7b935f947c..b038da872ec6 100644
> > > --- a/arch/mips/include/asm/pgtable.h
> > > +++ b/arch/mips/include/asm/pgtable.h
> > > @@ -615,9 +615,6 @@ unsigned long io_remap_pfn_range_pfn(unsigned long pfn, unsigned long size);
> > >   /* We don't have hardware dirty/accessed bits, generic_pmdp_establish is fine.*/
> > >   #define pmdp_establish generic_pmdp_establish
> > > -#define has_transparent_hugepage has_transparent_hugepage
> > > -extern int has_transparent_hugepage(void);
> > 
> > Assume a decstation_defconfig build. CPU_R3000 selects CPU_R3K_TLB, so the
> > Makefile builds tlb-r3k.o but not tlb-r4k.o IIUC ...
> > 
> > The only MIPS definition is in tlb-r4k.c, so R3000 would fail to link with
> > an undefined reference ... no?
> 
> Yes, you're right. I can reproduce this. Would the solution below be
> acceptable?
> 
> diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> index fa7b935f947c..b038da872ec6 100644
> --- a/arch/mips/include/asm/pgtable.h
> +++ b/arch/mips/include/asm/pgtable.h
> @@ -615,9 +615,6 @@ unsigned long io_remap_pfn_range_pfn(unsigned long pfn, unsigned long size);
>  /* We don't have hardware dirty/accessed bits, generic_pmdp_establish is fine.*/
>  #define pmdp_establish generic_pmdp_establish
> -#define has_transparent_hugepage has_transparent_hugepage
> -extern int has_transparent_hugepage(void);
> -
>  static inline int pmd_trans_huge(pmd_t pmd)
>  {
>  	return !!(pmd_val(pmd) & _PAGE_HUGE);
> @@ -743,6 +740,9 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> +#define has_transparent_hugepage has_transparent_hugepage
> +extern int has_transparent_hugepage(void);
> +
>  #ifdef _PAGE_HUGE
>  #define pmd_leaf(pmd)	((pmd_val(pmd) & _PAGE_HUGE) != 0)
>  #define pud_leaf(pud)	((pud_val(pud) & _PAGE_HUGE) != 0)
> diff --git a/arch/mips/mm/pgtable.c b/arch/mips/mm/pgtable.c
> index 10835414819f..3a5b411493d9 100644
> --- a/arch/mips/mm/pgtable.c
> +++ b/arch/mips/mm/pgtable.c
> @@ -23,3 +23,30 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(pgd_alloc);
> +
> +#if defined(CONFIG_CPU_R4K_CACHE_TLB) || \
> +    defined(CONFIG_CPU_SB1) || \
> +    defined(CONFIG_CPU_CAVIUM_OCTEON)

I guess using CONFIG_CPU_SUPPORTS_HUGEPAGES is a better approach

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]