From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EED3C43331 for ; Thu, 7 Nov 2019 19:34:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 575E62075C for ; Thu, 7 Nov 2019 19:34:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="DnHO5zxJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725844AbfKGTej (ORCPT ); Thu, 7 Nov 2019 14:34:39 -0500 Received: from mail.skyhub.de ([5.9.137.197]:52072 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbfKGTei (ORCPT ); Thu, 7 Nov 2019 14:34:38 -0500 Received: from zn.tnic (p200300EC2F0EAD0094343B71594E3CFE.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:ad00:9434:3b71:594e:3cfe]) (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 542881EC0CF0; Thu, 7 Nov 2019 20:34:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1573155273; 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=GenYAH9kQ7BwOZzZLD61Q4hP43MBwiw5oE3TXDHvPdQ=; b=DnHO5zxJqcw3UlGOo8wxx5KTfMQrz5Iyw78c2GbifobaR+bLZD/attNfId8h8/ht3i0LXT FKPnZ+8GMn73MhhpIPLWg9Q1v1+SxSajCe6ljfAcc0lkOfV0Si9hsAA80f3ltbbYEoM9Id 93o7HehccAlz+u3ZfmOxbzcRSxOX8nM= Date: Thu, 7 Nov 2019 20:34:29 +0100 From: Borislav Petkov To: "Ghannam, Yazen" Cc: "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 0/5] AMD64 EDAC: Check for nodes without memory, etc. Message-ID: <20191107193429.GI19501@zn.tnic> References: <20191106012448.243970-1-Yazen.Ghannam@amd.com> <20191106160607.GC28380@zn.tnic> <20191106195417.GF28380@zn.tnic> <20191107103857.GC19501@zn.tnic> <20191107154006.GF19501@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-edac-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-edac@vger.kernel.org On Thu, Nov 07, 2019 at 07:20:25PM +0000, Ghannam, Yazen wrote: > Yes, that's right. But it looks like future systems will re-use PCI IDs even > across families and models. And the PCI IDs will be more closely related to > hardware capabilities than family and model. > > In any case, we can address that when we get there. I'd be fine with it if this really is the case and we don't end up having to keep adding PCI IDs like crazy again. That was a moderate PITA, AFAIR, especially for distro kernels having to constantly pick up enablement patches and people complaining about it. So you need to make sure the PCI IDs will really get reused before converting back... > > if (!ecc_en || !nb_mce_en) > > return false; > > else > > Right, I meant you can drop this else and just return true. > > > return true; I prefer the regular if-else way because it reads faster and it is straight-forward when one skims over the code. But I can drop if if you insist. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette