The MCx_MISC0[BlkPtr] field was used on legacy systems to hold a
register offset for the next MCx_MISC* register. In this way, an
implementation-specific number of registers can be discovered at
runtime.

The MCAX/SMCA register space simplifies this by always including
the MCx_MISC[1-4] registers. The MCx_MISC0[BlkPtr] field is used to
indicate (true/false) whether any MCx_MISC[1-4] registers are present.
But it does not indicate which ones nor how many. Therefore, all the
registers are accessed and their bits are checked.

AMD systems generally enforce a Read-as-Zero/Writes-Ignored policy for
unused registers. Therefore, there is no harm to read an unused
register. This is already done in practice for most of the MCx_MISC
registers.

Remove the smca_banks_map variable as it is effectively redundant.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
---

Notes:
    v1->v2:
    * New in v2.

 arch/x86/kernel/cpu/mce/amd.c | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index 4ea691006c3b..f8ad40c5c887 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -252,9 +252,6 @@ static DEFINE_PER_CPU(struct threshold_bank **, threshold_banks);
  */
 static DEFINE_PER_CPU(u64, bank_map);
 
-/* Map of banks that have more than MCA_MISC0 available. */
-static DEFINE_PER_CPU(u64, smca_misc_banks_map);
-
 static void amd_threshold_interrupt(void);
 static void amd_deferred_error_interrupt(void);
 
@@ -264,28 +261,6 @@ static void default_deferred_error_interrupt(void)
 }
 void (*deferred_error_int_vector)(void) = default_deferred_error_interrupt;
 
-static void smca_set_misc_banks_map(unsigned int bank, unsigned int cpu)
-{
-	u32 low, high;
-
-	/*
-	 * For SMCA enabled processors, BLKPTR field of the first MISC register
-	 * (MCx_MISC0) indicates presence of additional MISC regs set (MISC1-4).
-	 */
-	if (rdmsr_safe(MSR_AMD64_SMCA_MCx_CONFIG(bank), &low, &high))
-		return;
-
-	if (!(low & MCI_CONFIG_MCAX))
-		return;
-
-	if (rdmsr_safe(MSR_AMD64_SMCA_MCx_MISC(bank), &low, &high))
-		return;
-
-	if (low & MASK_BLKPTR_LO)
-		per_cpu(smca_misc_banks_map, cpu) |= BIT_ULL(bank);
-
-}
-
 static void smca_configure(unsigned int bank, unsigned int cpu)
 {
 	u8 *bank_counts = this_cpu_ptr(smca_bank_counts);
@@ -326,8 +301,6 @@ static void smca_configure(unsigned int bank, unsigned int cpu)
 		wrmsr(smca_config, low, high);
 	}
 
-	smca_set_misc_banks_map(bank, cpu);
-
 	if (rdmsr_safe(MSR_AMD64_SMCA_MCx_IPID(bank), &low, &high)) {
 		pr_warn("Failed to read MCA_IPID for bank %d\n", bank);
 		return;
@@ -532,9 +505,6 @@ static u32 smca_get_block_address(unsigned int bank, unsigned int block,
 	if (!block)
 		return MSR_AMD64_SMCA_MCx_MISC(bank);
 
-	if (!(per_cpu(smca_misc_banks_map, cpu) & BIT_ULL(bank)))
-		return 0;
-
 	return MSR_AMD64_SMCA_MCx_MISCy(bank, block - 1);
 }
 

-- 
2.43.0

> From: Yazen Ghannam <yazen.ghannam@amd.com>
> Sent: Friday, February 14, 2025 12:46 AM
> To: x86@kernel.org; Luck, Tony <tony.luck@intel.com>
> Cc: linux-kernel@vger.kernel.org; linux-edac@vger.kernel.org;
> Smita.KoralahalliChannabasappa@amd.com; Yazen Ghannam
> <yazen.ghannam@amd.com>
> Subject: [PATCH v2 03/16] x86/mce/amd: Remove smca_banks_map
> 
> The MCx_MISC0[BlkPtr] field was used on legacy systems to hold a register
> offset for the next MCx_MISC* register. In this way, an implementation-
> specific number of registers can be discovered at runtime.
> 
> The MCAX/SMCA register space simplifies this by always including the
> MCx_MISC[1-4] registers. The MCx_MISC0[BlkPtr] field is used to indicate
> (true/false) whether any MCx_MISC[1-4] registers are present.
> But it does not indicate which ones nor how many. Therefore, all the registers

s/nor/or     (suggested by AI 😊)
OR
s/does not indicate/indicates neither

> are accessed and their bits are checked.
> 
> AMD systems generally enforce a Read-as-Zero/Writes-Ignored policy for
> unused registers. Therefore, there is no harm to read an unused register. This
> is already done in practice for most of the MCx_MISC registers.
> 
> Remove the smca_banks_map variable as it is effectively redundant.
> 
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>

Aside from the small nit above,

    Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> 

On Mon, Feb 17, 2025 at 07:57:47AM +0000, Zhuo, Qiuxu wrote:
> > From: Yazen Ghannam <yazen.ghannam@amd.com>
> > Sent: Friday, February 14, 2025 12:46 AM
> > To: x86@kernel.org; Luck, Tony <tony.luck@intel.com>
> > Cc: linux-kernel@vger.kernel.org; linux-edac@vger.kernel.org;
> > Smita.KoralahalliChannabasappa@amd.com; Yazen Ghannam
> > <yazen.ghannam@amd.com>
> > Subject: [PATCH v2 03/16] x86/mce/amd: Remove smca_banks_map
> > 
> > The MCx_MISC0[BlkPtr] field was used on legacy systems to hold a register
> > offset for the next MCx_MISC* register. In this way, an implementation-
> > specific number of registers can be discovered at runtime.
> > 
> > The MCAX/SMCA register space simplifies this by always including the
> > MCx_MISC[1-4] registers. The MCx_MISC0[BlkPtr] field is used to indicate
> > (true/false) whether any MCx_MISC[1-4] registers are present.
> > But it does not indicate which ones nor how many. Therefore, all the registers
> 
> s/nor/or     (suggested by AI 😊)
> OR
> s/does not indicate/indicates neither
> 

Hmm, okay, I think the second one.

  "But it indicates neither which ones nor how many".

I guess this falls under "Using 'nor' without a correlative pair".
https://www.learngrammar.net/a/how-to-use-nor-properly-in-a-sentence

:)

> > are accessed and their bits are checked.
> > 
> > AMD systems generally enforce a Read-as-Zero/Writes-Ignored policy for
> > unused registers. Therefore, there is no harm to read an unused register. This
> > is already done in practice for most of the MCx_MISC registers.
> > 
> > Remove the smca_banks_map variable as it is effectively redundant.
> > 
> > Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> 
> Aside from the small nit above,
> 
>     Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> 

Thanks,
Yazen