Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2394785imm; Tue, 4 Sep 2018 03:50:32 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdad0l9tynD6taxwKbS3SIrWu5HGIz0zHJ61o7/wPqeft56ELRMtC6/cPK8w5CW3z+QcLgVe X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr32951242plb.172.1536058231954; Tue, 04 Sep 2018 03:50:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536058231; cv=none; d=google.com; s=arc-20160816; b=ZCbVnQAJkQ0hYy7dfeWGFmIaSAKAgOC2Hpit720d8zD5dXqCNpf7k65vJ68k0sl1TA RQg++rEuPsQMaU3tZh4X61tKX+PaXcIxg5CspcLJe8a6NWtP83QIG77MNH9JZ/8YA5XT nAFqOus3YG1TzyeMYOsT2oTr8wKHh+kSn6ssj9HShtmFcn5T9UBX1LznDRtZsdnidflC Om8wpBv95dHfhZvK/9X3CCntDH0/3Q3AZHJtZ+lTQugMlYjIsVKjOVW9yEvTcFOuaf35 wLhDbHKsfxZuj1hGxlft0v6KEBMoiALqWqIPwiJfSILYYEbOb95yMXOZqWJLHoM4tISu 8ioQ== 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:arc-authentication-results; bh=RE47WNNX0AhD3DM4PJmOdCAG6szFqVCNr/f31u31R6c=; b=GHrSj/F2BYGG5PvtPm/lazJd4OiRMzOKBNQolafQhI6vJN2oZy8mA2+mxvB2+nZs/i RUMB785HhHWoQMWskkXbx3iITtJ06PZBk8pE/z7FZoiOJXOOYod+/A3s2sBE2i5tMIXY 4clfYR2fg72ZupXlW3tJiO02uzX1luObJCzBYdhS7mfgoQGpwcexGihMV5BzFdO2BbYO hpW9smvPGpNq+5yqAURfIMb/EiqEBdVPVxHFu3LC2Bg2zOuvRZtHOojdZIu0Uyzg4fTS kV9tnApaWM3xOJ6sBb5FH4YjBoHnvsBhIxuhcRaWZHLo8bkdBlLVtc3aRKxxKaQIbjLk WTqQ== 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 t9-v6si20287229pgr.244.2018.09.04.03.50.17; Tue, 04 Sep 2018 03:50:31 -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 S1727505AbeIDPNL (ORCPT + 99 others); Tue, 4 Sep 2018 11:13:11 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39388 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726376AbeIDPNL (ORCPT ); Tue, 4 Sep 2018 11:13:11 -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 N_De4pobJ573; Tue, 4 Sep 2018 12:48:19 +0200 (CEST) Received: from zn.tnic (p200300EC2BC9A500329C23FFFEA6A903.dip0.t-ipconnect.de [IPv6:2003:ec:2bc9:a500: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 CB1131EC0513; Tue, 4 Sep 2018 12:48:18 +0200 (CEST) Date: Tue, 4 Sep 2018 12:48:12 +0200 From: Borislav Petkov To: Pu Wen Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, thomas.lendacky@amd.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v5 05/16] x86/pmu: enable Hygon support to PMU infrastructure Message-ID: <20180904104812.GF32615@zn.tnic> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 29, 2018 at 08:43:54PM +0800, Pu Wen wrote: > Hygon PMU arch is similar to AMD Family 17h. To support Hygon PMU, the > initialization flow for it just call amd_pmu_init() and change PMU name That sentence reads funny. > to "HYGON". To share AMD's flow, add code check for Hygon family ID 18h s/family ID/family/ > to run the code path of AMD family 17h in core/uncore functions. > > Also it returns the bit offset of the performance counter register and > event selection register for Hygon CPU in the similar way as AMD does. In general, you seem to be explaining *what* your patches do and not *why*. This is the wrong. Always explain the *why* - the *what* is visible from the diff. You probably need to brush up on Documentation/process/submitting-patches.rst, section 2. > Signed-off-by: Pu Wen > --- > arch/x86/events/amd/core.c | 6 ++++++ > arch/x86/events/amd/uncore.c | 15 ++++++++++----- > arch/x86/events/core.c | 4 ++++ > arch/x86/kernel/cpu/perfctr-watchdog.c | 2 ++ > 4 files changed, 22 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c > index c84584b..6c13c9d 100644 > --- a/arch/x86/events/amd/core.c > +++ b/arch/x86/events/amd/core.c > @@ -669,6 +669,12 @@ static int __init amd_core_pmu_init(void) > * We fallback to using default amd_get_event_constraints. > */ > break; > + case 0x18: > + if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { > + pr_cont("Fam18h "); Didn't we agree that you'll verify whether family 0x18 is going to be Hygon only? What happened to that checking? > + /* Using default amd_get_event_constraints. */ > + break; > + } > default: > pr_err("core perfctr but no constraints; unknown hardware!\n"); > return -ENODEV; > diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c > index 981ba5e..9f2eb43 100644 > --- a/arch/x86/events/amd/uncore.c > +++ b/arch/x86/events/amd/uncore.c > @@ -507,17 +507,22 @@ static int __init amd_uncore_init(void) > { > int ret = -ENODEV; > > - if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) > + if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD && > + boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) > return -ENODEV; > > if (!boot_cpu_has(X86_FEATURE_TOPOEXT)) > return -ENODEV; > > - if (boot_cpu_data.x86 == 0x17) { > + if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD && > + boot_cpu_data.x86 == 0x17) || > + (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON && > + boot_cpu_data.x86 == 0x18)) { Same here. What's up? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.