Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3723583pxj; Tue, 11 May 2021 10:28:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEkLQU08sB0Kfqkh6SFxbbgKkAkwYBwy7M80VWXlgthXQoXSJ3BjLYvIv4EKhXkcdN06YG X-Received: by 2002:a17:906:a0a:: with SMTP id w10mr32618009ejf.416.1620754134814; Tue, 11 May 2021 10:28:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620754134; cv=none; d=google.com; s=arc-20160816; b=udhTAzYlXI25MfgjdQFAr+e+5P/u05CekJRSJNwdHyaf6iUoNxVFgufdYjMf4EqzUz 8rz/8UlOCp7AC8hySf/u+SzXfM6HQCO9VH/8rOgslFewyGTf+5qZrlwhhNAx53fHWPiY /b/BOQ3jlYDzib7tyHU5z2xylWUQo54g98Vho8CjuOHoNntaRQFeQAODjX27t3rMVJ8x /Uj0DRg7ohYYDDg7sHTPhT61ZyneiEmfvE+SNJcRKV/DCtzOyxUD1LWarG9ZjOUraCd8 u0Vmbq5W8qe9ly186IyRFmZ0d6q9ojc37LQki8MiQbpWr3KwlPxsuMfqtz5uI5RFGNGk ta0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=B3r/YO4GVHpZhNHppOEhHaJZiEO73O06Xor7sWfCBJg=; b=pif/x8nM/6sGFZA8yjgjE5pBLWLG6B834bj+7aPV6738JKWfPswUO4t5Z5aFBktkg7 GwBVhmKMtvNGRgjYHmOGEbTUzqtyByOr36lkj2DK5t65oF1d1VFFq8Gbv5qOTGWJJT5M kE3R40fZpMGvFkuzBJYLvfnY9kNhNhCPm4BaC+CckIAwk3Lto2fBkLDYnnpZ/mALKUjk +YloFN6245BajC1t5VwnIQ9RiQHVYh43hRADCl0TK57pPsviE7As0KP0iwqDXMOYh0gM ZD1AlQKMGe2V2Vif34EUpcVSjMbhWjK58+PlyCzOfEmsL+bd7SxFwIfty6FLpRh0ng/T lWcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=HKDtVnk8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i8si20988994ejj.196.2021.05.11.10.28.31; Tue, 11 May 2021 10:28:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=HKDtVnk8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231502AbhEKR22 (ORCPT + 99 others); Tue, 11 May 2021 13:28:28 -0400 Received: from mail.skyhub.de ([5.9.137.197]:42602 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231407AbhEKR2Y (ORCPT ); Tue, 11 May 2021 13:28:24 -0400 Received: from zn.tnic (p200300ec2f0ec70020ab858661d7f414.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:c700:20ab:8586:61d7:f414]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 45B771EC02E6; Tue, 11 May 2021 19:27:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1620754037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=B3r/YO4GVHpZhNHppOEhHaJZiEO73O06Xor7sWfCBJg=; b=HKDtVnk855QV7vLOW2EqBGvdL5dVylFBP/gFe7MQ/dzTxDmYSfXzIJUgwIaTtg3uP4sDEA bb4L3PWBo7/cMO9PJUsEsJL+B1KYVLpRid+IA6r3fXJ/8JNYWOC0NiTgTHaexiAOnvLth0 HVYns2auhDoC5XX6KTAeNHrUG+Xtgyo= Date: Tue, 11 May 2021 19:27:13 +0200 From: Borislav Petkov To: Naveen Krishna Chatradhi Cc: linux-edac@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, mchehab@kernel.org, Muralidhara M K Subject: Re: [PATCH 1/3] x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank types. Message-ID: References: <20210511152538.148084-1-nchatrad@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210511152538.148084-1-nchatrad@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 11, 2021 at 08:55:36PM +0530, Naveen Krishna Chatradhi wrote: > diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c > index e486f96b3cb3..055f3a0acf5e 100644 > --- a/arch/x86/kernel/cpu/mce/amd.c > +++ b/arch/x86/kernel/cpu/mce/amd.c > @@ -90,6 +90,7 @@ static struct smca_bank_name smca_names[] = { > [SMCA_CS_V2] = { "coherent_slave", "Coherent Slave" }, > [SMCA_PIE] = { "pie", "Power, Interrupts, etc." }, > [SMCA_UMC] = { "umc", "Unified Memory Controller" }, > + [SMCA_UMC_V2] = { "umc_v2", "Unified Memory Controller" }, So this is called "umc_v2" but the other V2 FUs's strings are the same. Why? Also, if you're going to repeat strings, you can just as well group all those which are the same this way: [ SMCA_UMC ... SMCA_UMC_V2 ] = { "umc", "Unified Memory Controller" }, and do that for all which have V1 and V2. I mean, gcc is smart enough to do that behind the scenes for identical strings but you should do that in C too. > diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c > index 5dd905a3f30c..5515fd9336b1 100644 > --- a/drivers/edac/mce_amd.c > +++ b/drivers/edac/mce_amd.c > @@ -323,6 +323,21 @@ static const char * const smca_umc_mce_desc[] = { > "AES SRAM ECC error", > }; > > +static const char * const smca_umc2_mce_desc[] = { Ok, gcc reuses the identical string pointers from smca_umc_mce_desc[] so we should be ok wrt duplication. > + "DRAM ECC error", > + "Data poison error", > + "SDP parity error", > + "Reserved", > + "Address/Command parity error", > + "Write data parity error", > + "DCQ SRAM ECC error", > + "Reserved", > + "Read data parity error", > + "Rdb SRAM ECC error", > + "RdRsp SRAM ECC error", > + "LM32 MP errors", > +}; ... > +static const char * const smca_xgmipcs_mce_desc[] = { > + "DataLossErr", > + "TrainingErr", > + "FlowCtrlAckErr", > + "RxFifoUnderflowErr", > + "RxFifoOverflowErr", > + "CRCErr", > + "BERExceededErr", > + "TxVcidDataErr", > + "ReplayBufParityErr", > + "DataParityErr", > + "ReplayFifoOverflowErr", > + "ReplayFIfoUnderflowErr", > + "ElasticFifoOverflowErr", > + "DeskewErr", > + "FlowCtrlCRCErr", > + "DataStartupLimitErr", > + "FCInitTimeoutErr", > + "RecoveryTimeoutErr", > + "ReadySerialTimeoutErr", > + "ReadySerialAttemptErr", > + "RecoveryAttemptErr", > + "RecoveryRelockAttemptErr", > + "ReplayAttemptErr", > + "SyncHdrErr", > + "TxReplayTimeoutErr", > + "RxReplayTimeoutErr", > + "LinkSubTxTimeoutErr", > + "LinkSubRxTimeoutErr", > + "RxCMDPktErr", What happened to those and why aren't they proper words like the other error descriptions? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette