Re: [PATCH] MIPS: clean up CONFIG_MIPS_PGD_C0_CONTEXT handling
From: Huang Pei <hidden>
Date: 2021-03-04 01:06:39
Also in:
linux-arch, linux-mm
Hi, On Mon, Mar 01, 2021 at 12:00:28AM +0100, Maciej W. Rozycki wrote:
On Sat, 27 Feb 2021, Huang Pei wrote:quoted
index 2000bb2b0220..517509ad8596 100644--- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig@@ -2142,6 +2142,7 @@ config CPU_SUPPORTS_HUGEPAGES depends on !(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA)) config MIPS_PGD_C0_CONTEXT bool + depends on 64BIT default y if 64BIT && (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLPI guess you want: default y if (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLP at the same time too. Otherwise you have cruft left behind.
Yes, it is much better
quoted
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index a7521b8f7658..5bb9724578f7 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c@@ -1106,6 +1106,7 @@ struct mips_huge_tlb_info { bool need_reload_pte; }; +#ifdef CONFIG_64BIT static struct mips_huge_tlb_info build_fast_tlb_refill_handler (u32 **p, struct uasm_label **l, struct uasm_reloc **r, unsigned int tmp,Does it actually build without a warning for !CONFIG_64BIT given the reference below?
No, my bad, my first reaction when seeing "IS_ENABLED(CONFIG_64BIT)" is "#ifdef CONFIG_64BIT"
quoted
@@ -1164,8 +1165,8 @@ build_fast_tlb_refill_handler (u32 **p, struct uasm_label **l, if (pgd_reg == -1) { vmalloc_branch_delay_filled = 1; - /* 1 0 1 0 1 << 6 xkphys cached */ - uasm_i_ori(p, ptr, ptr, 0x540); + /* insert bit[63:59] of CAC_BASE into bit[11:6] of ptr */ + uasm_i_ori(p, ptr, ptr, (CAC_BASE >> 53));Instead I'd paper the issue over by casting the constant to `s64'. Or better yet fixed it properly by defining CAC_BASE, etc. as `unsigned long long' long rather than `unsigned long' to stop all this nonsense (e.g. PHYS_TO_XKPHYS already casts the result to `s64'). Thomas, WDYT?
Sorry, I do not get it , on MIPS32, how can CAC_BASE be unsigned long long ? If this did not work, how about one step back, just explicit comment wihtout "(CAC_BASE << 53)" ?
Maciej