lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230805101059.GMZM4gM4yA9AgBSEpw@fat_crate.local>
Date:   Sat, 5 Aug 2023 12:10:59 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Muralidhara M K <muralimk@....com>
Cc:     linux-edac@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com, mchehab@...nel.org,
        nchatrad@....com, yazen.ghannam@....com,
        Muralidhara M K <muralidhara.mk@....com>
Subject: Re: [PATCH 5/7] EDAC/amd64: Add Fam19h Model 90h ~ 9fh enumeration
 support

On Thu, Jul 20, 2023 at 12:54:23PM +0000, Muralidhara M K wrote:
> From: Muralidhara M K <muralidhara.mk@....com>
> 
> Add AMD family 19h Model 90h-9fh. Models 90h-9fh are APUs, and
> they have built-in HBM3 memory. ECC support is enabled by default.
> 
> APU models have a single Data Fabric (DF) per Package. Each DF is
> visible to the OS in the same way as chiplet-based systems like
> Rome and later. However, the Unified Memory Controllers (UMCs) are
> arranged in the same way as GPU-based MI200 devices rather than
> CPU-based systems.
> So, it uses the gpu_ops for enumeration and adds a few fixups.

s/it uses/use/

Imperative tone:

Pls read section "2) Describe your changes" in
Documentation/process/submitting-patches.rst for more details.

> 
> Signed-off-by: Muralidhara M K <muralidhara.mk@....com>
> ---
>  drivers/edac/amd64_edac.c | 65 +++++++++++++++++++++++++++++++--------
>  1 file changed, 53 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 597dae7692b1..45d8093c117a 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -996,12 +996,16 @@ static struct local_node_map {
>  #define LNTM_NODE_COUNT				GENMASK(27, 16)
>  #define LNTM_BASE_NODE_ID			GENMASK(11, 0)
>  
> -static int gpu_get_node_map(void)
> +static int gpu_get_node_map(struct amd64_pvt *pvt)
>  {
>  	struct pci_dev *pdev;
>  	int ret;
>  	u32 tmp;
>  
> +	/* return early for non heterogeneous systems */

Superfluous comment.

> +	if (pvt->F3->device != PCI_DEVICE_ID_AMD_MI200_DF_F3)
> +		return 0;
> +
>  	/*
>  	 * Node ID 0 is reserved for CPUs.
>  	 * Therefore, a non-zero Node ID means we've already cached the values.
> @@ -3851,7 +3855,7 @@ static void gpu_init_csrows(struct mem_ctl_info *mci)
>  
>  			dimm->nr_pages = gpu_get_csrow_nr_pages(pvt, umc, cs);
>  			dimm->edac_mode = EDAC_SECDED;
> -			dimm->mtype = MEM_HBM2;
> +			dimm->mtype = pvt->dram_type;
>  			dimm->dtype = DEV_X16;
>  			dimm->grain = 64;
>  		}
> @@ -3880,6 +3884,9 @@ static bool gpu_ecc_enabled(struct amd64_pvt *pvt)
>  	return true;
>  }
>  
> +/* Base address used for channels selection on GPUs */
> +static u32 gpu_umc_base = 0x50000;

Why isn't this part of amd64_pvt like the rest of the fields?

> +
>  static inline u32 gpu_get_umc_base(u8 umc, u8 channel)
>  {
>  	/*
> @@ -3893,13 +3900,32 @@ static inline u32 gpu_get_umc_base(u8 umc, u8 channel)
>  	 * On GPU nodes channels are selected in 3rd nibble
>  	 * HBM chX[3:0]= [Y  ]5X[3:0]000;
>  	 * HBM chX[7:4]= [Y+1]5X[3:0]000
> +	 *
> +	 * On APU nodes, same as GPU but with diff base 0x90000;

"diff"?

>  	 */
>  	umc *= 2;
>  
>  	if (channel >= 4)
>  		umc++;
>  
> -	return 0x50000 + (umc << 20) + ((channel % 4) << 12);
> +	return gpu_umc_base + (umc << 20) + ((channel % 4) << 12);
> +}
> +

...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ