Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2692202imm; Mon, 24 Sep 2018 08:26:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV618O7vICSzccSDMSwWYQIgipoBVWifMLELTJq1b2wFUx+uwCK/VM8M+VNrMuq7+xqkxTu8n X-Received: by 2002:a17:902:6102:: with SMTP id t2-v6mr2058848plj.278.1537802805332; Mon, 24 Sep 2018 08:26:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537802805; cv=none; d=google.com; s=arc-20160816; b=HcoIBz6qdmq1bZ/CzoJDdawqQoQ8Jt42UfQT9ViubtXMfErNXGTG7CixKy1k+ylpBG ZiocldOV2fKxcjWnDPPVP+8WrdaKVlAc4d+MRHKgArGUhYGNkE05EEFOKIyjWdBndr+e 8RVKQWA2w+Cxy7XsYklZOjWSNioF/2KaM+IJ/NhSmhmXpG81rX1P3uQpAKrkdZpDVIhw S6QHN3LgwrC+zl8osq+FbYAYn30rZGoPdZqNresPO1jatkSS7SUlRp3WE7NF2JjNE+oe LKOuW6IxItxxXrtMzt5d2BZQL4f39/GeaYTQFRuXmqx0xbmpnAy4t2hNI65Ie4B/mGtR kdnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3RMB9jUaOZmAIagCQMtgKlsXjNSCx/Omb/X7tqrOzmk=; b=O3t5Vp+un6pWZ8m084fnOn/aUB495WCkcKtkEKw2uWRV1lhJTBJiYD1wALepifIyHy +u4uE1wvRr45/9zSmmBwdXpWOqhOO3sbrYbybNXy5d70bzFyoJdjqQzE+Ux1uQLaPdZn 1KmmU9Tm72of8Wg19xg8V/XKBBbsK22u8Q7lOY31TULmz7R5rvrAr9VsZSlcYQ9uEmb5 lCym892fUPh8cj+OBcbiqC6rmmUxaZHNVyEX8fR7y3kWgWFctUJXf+kRbzDl/wZI5LAl kyhSo1DFXbowz/rIbVKagFva03o+D90N8+mg3CCyJc0XbApDCRHNyoNMtOgbxI/msodF i5kg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d17-v6si32743646pgp.549.2018.09.24.08.25.59; Mon, 24 Sep 2018 08:26:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730106AbeIXV12 (ORCPT + 99 others); Mon, 24 Sep 2018 17:27:28 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39680 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728962AbeIXV11 (ORCPT ); Mon, 24 Sep 2018 17:27:27 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5_tnEv_XDxvo; Mon, 24 Sep 2018 17:24:44 +0200 (CEST) Received: from zn.tnic (p200300EC2BC69500329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2bc6:9500:329c:23ff:fea6:a903]) (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 A22731EC0118; Mon, 24 Sep 2018 17:24:44 +0200 (CEST) Date: Mon, 24 Sep 2018 17:24:48 +0200 From: Borislav Petkov To: Pu Wen Cc: bhelgaas@google.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, thomas.lendacky@amd.com, helgaas@kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v8 07/16] x86/pci: Add Hygon Dhyana support to PCI and north bridge Message-ID: <20180924152448.GE20187@zn.tnic> References: <580dc519d37ad9257520fe8c533f2c61d3e0cd83.1537533369.git.puwen@hygon.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <580dc519d37ad9257520fe8c533f2c61d3e0cd83.1537533369.git.puwen@hygon.cn> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 23, 2018 at 05:35:13PM +0800, Pu Wen wrote: > As Hygon registered its PCI Vendor ID as a new one 0x1d94, and there > are PCI Devices 0x1450/0x1463/0x1464 for Host bridge on Hygon Dhyana > platform, so add Hygon Dhyana support to the PCI and north bridge > subsystem by using the code path of AMD family 17h. > > To prevent further checking PCI device ids which cannot happen both on > Hygon and Intel platform, the function amd_gart_present should return > if it's not a AMD CPU. > > Signed-off-by: Pu Wen > Acked-by: Bjorn Helgaas # pci_ids.h > Reviewed-by: Borislav Petkov > --- > arch/x86/include/asm/amd_nb.h | 3 +++ > arch/x86/kernel/amd_nb.c | 47 +++++++++++++++++++++++++++++++++++++------ > arch/x86/pci/amd_bus.c | 6 ++++-- > include/linux/pci_ids.h | 2 ++ > 4 files changed, 50 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/include/asm/amd_nb.h b/arch/x86/include/asm/amd_nb.h > index fddb6d2..1ae4e57 100644 > --- a/arch/x86/include/asm/amd_nb.h > +++ b/arch/x86/include/asm/amd_nb.h > @@ -103,6 +103,9 @@ static inline u16 amd_pci_dev_to_node_id(struct pci_dev *pdev) > > static inline bool amd_gart_present(void) > { > + if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) > + return false; > + What is that for? Hygon doesn't have F15h so that function will return false there too... ... or is that because the qemu script you got from the 0day bot guys uses -cpu kvm64 which is family 0xf: [ 0.214353] smpboot: CPU0: AMD Common KVM processor (family: 0xf, model: 0x6, stepping: 0x1) ? and that makes amd_gart_present() say yes. In that case, please make a *prepatch* which adds the vendor check to both amd_gart_present() and early_is_amd_nb() and send it as a reply to this message. *Then*, do this patch ontop and also as a reply. > /* GART present only on Fam15h, upto model 0fh */ > if (boot_cpu_data.x86 == 0xf || boot_cpu_data.x86 == 0x10 || > (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model < 0x10)) > diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c > index b481b95..dcc4130 100644 > --- a/arch/x86/kernel/amd_nb.c > +++ b/arch/x86/kernel/amd_nb.c > @@ -61,6 +61,21 @@ static const struct pci_device_id amd_nb_link_ids[] = { > {} > }; > > +static const struct pci_device_id hygon_root_ids[] = { > + { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_ROOT) }, > + {} > +}; > + > +const struct pci_device_id hygon_nb_misc_ids[] = { > + { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) }, > + {} > +}; > + > +static const struct pci_device_id hygon_nb_link_ids[] = { > + { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_DF_F4) }, > + {} > +}; > + > const struct amd_nb_bus_dev_range amd_nb_bus_dev_ranges[] __initconst = { > { 0x00, 0x18, 0x20 }, > { 0xff, 0x00, 0x20 }, > @@ -197,12 +212,25 @@ int amd_cache_northbridges(void) > u16 i = 0; > struct amd_northbridge *nb; > struct pci_dev *root, *misc, *link; > + const struct pci_device_id *root_ids = NULL; > + const struct pci_device_id *misc_ids = NULL; > + const struct pci_device_id *link_ids = NULL; > + > + if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { > + root_ids = hygon_root_ids; > + misc_ids = hygon_nb_misc_ids; > + link_ids = hygon_nb_link_ids; > + } else { > + root_ids = amd_root_ids; > + misc_ids = amd_nb_misc_ids; > + link_ids = amd_nb_link_ids; > + } Also, you can make this assignment differently: const struct pci_device_id *root_ids = amd_root_ids; const struct pci_device_id *misc_ids = amd_nb_misc_ids; const struct pci_device_id *link_ids = amd_nb_link_ids; if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { root_ids = hygon_root_ids; misc_ids = hygon_nb_misc_ids; link_ids = hygon_nb_link_ids; } This way the change is obvious and it is only for Hygon without affecting the other vendors. Ditto for the other assignment. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.